RFC 1464

RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes 🦋

okay bestie, this is RFC 1464 🎀 from May 1993. It came out of the Network Working Group and was written by R. Rosenbaum (signing off as Rich Rosenbaum in the address section) at Digital Equipment Corporation 💼. The category is an Experimental Protocol 🧪, so it's a "try it and tell us" kinda vibe. The header doesn't list anything it obsoletes or updates, so no drama there 🙈.

---

Status of this Memo ✨

This memo defines an Experimental Protocol for the Internet community 🧪. They're literally asking for discussion and suggestions for improvement, so speak up! For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 📜. Distribution of this memo is unlimited 🌈.

Abstract 💜

okay so the Domain Name System (DNS) [2,3] is mostly used to store predefined stuff, like addresses of hosts 🏠. but it's totally possible to use it for info nobody has classified yet 👀. this paper describes a simple way to attach arbitrary string info (ASCII text) to attributes the DNS hasn't defined. it uses DNS TXT resource records to store the info, and it needs zero changes to current DNS implementations 💅.

---

1. Introduction ✨

the Domain Name System is built to hold stuff with a predefined type and structure, like IP addresses of hosts and names of mail exchangers 📬. it would be super useful to tap into the DNS's widespread use and scaleability to store info that hasn't been defined before 🌸.

this paper proposes using the DNS TXT resource record (defined in STD 13, RFC 1035) to hold new types of info 🎀. the main perk is that it needs no change to most existing DNS servers 🙌. it is not trying to replace the process for defining and implementing new resource records 🫶.

2. Format of TXT record 💖

okay so the TXT record uses a structured format in its TXT-DATA field 🧠. it's the attribute name, then the value of the attribute, and the two are split by an equals sign (=) ✂️.

here are some TXT records using attributes like that 👇

host.widgets.com   IN   TXT   "printer=lpr5"
sam.widgets.com    IN   TXT   "favorite drink=orange juice"

the general syntax is:

<owner> <class> <ttl> TXT "<attribute name>=<attribute value>"

Attribute Names

any printable ASCII character is allowed in the attribute name 🔤. if an equals sign is embedded in the attribute name, it MUST be quoted with a preceding grave accent (or backquote: `) 🙅. and a backquote MUST also be quoted with an additional ` 💅.

Attribute Name Matching Rules

the attribute name is case-insensitive 🌈. so a lookup for "Favorite Drink" would match a TXT record containing "favorite drink=Earl Grey tea" 🫖.

during lookups, TXT records without an unquoted "=" get ignored 🙈. TXT records that seem to have a null attribute name (so the TXT-DATA starts with the character "=") also get ignored 🚫.

leading and trailing whitespace (spaces and tabs) in the attribute name gets ignored unless it's quoted (with a `) ✨. for example, "abc" matches " abc<tab>" but does not match "` abc" 💅.

heads up though: most DNS server implementations want a backslash (\) or double quote (") in a text string quoted with a preceding backslash 🙃. that's why accent grave (`) got picked as the quoting character here: to avoid confusion with \ and skip the need for messy strings like \\\\ 🧹.

Attribute Values

all printable ASCII characters are allowed in the attribute value 🎨. no characters need quoting with a ` 🙌. so the first unquoted equals sign in the TXT record is the name/value delimiter, and everything after it is part of the value 💜.

once again, in most implementations the backslash is an active quoting character (and MUST, itself, be quoted) 🔁.

all whitespace in the attribute value gets returned to the requestor, and it's up to the application to decide if it matters 🤷.

Examples

<sp> means a space character 🫧.

Attribute    Attribute       Internal Form           External Form
Name         Value           (server to resolver)    (TXT record)

color        blue            color=blue              "color=blue"
equation     a=4             equation=a=4            "equation=a=4"
a=a          true            a`=a=true               "a`=a=true"
a\=a false           a\`=a=false             "a\\`=a=false"
=            \=              `==\=                   "`==\\="

string       "Cat"           string="Cat"            "string=\"Cat\""
string2      `abc`           string2=``abc``         "string2=``abc``"
novalue                      novalue=                "novalue="
a b          c d             a b=c d                 "a b=c d"
abc<sp>      123<sp>         abc` =123<sp>           "abc` =123 "

---

3. Application Usage 🛠️

the attributes can be reached through the standard resolver library, but it is RECOMMENDED that you use a library routine built specially for this attribute format 📚. that routine might give you something like gethostbyname:

getattributebyname(objectname,          name of object
                   attributename,       name of attribute
                   attributevalue,      pointer to buffer
                   attributevaluelen)   length of buffer

this routine would strip out all the quoting characters before handing the info back to the caller 🧹. a fancier routine could return attributes with multiple values, or several different attributes at once 🎁.

4. Attribute Name Registration 📝

to make interop easier and cut down on naming conflicts, a registration process for well-known attribute names might get set up 🤝. it could be a periodically updated list of names, and/or follow other name registration mechanisms, like published object identifiers 🗂️. this paper does not cover attribute name registration 🙅.

5. Restrictions 🚧

some DNS server implementations put limits on the size or number of TXT records tied to a particular owner 📏. certain implementations MAY not support TXT records at all 🙈.

---

6. REFERENCES and BIBLIOGRAPHY 📚

here are all the citations, bestie 🫶:

• [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network Information Center, SRI International, November 1987.
• [2] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
• [3] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
• [4] Mockapetris, P., "DNS Encoding of Network Names and Other Types", RFC 1101, USC/Information Sciences Institute, April 1989.

7. Security Considerations 🔐

security issues are not discussed in this memo 💀. bestie, that's the whole section, so don't go assuming it covers anything it doesn't. this one is serious business 😭.

8. Author's Address 📮

Rich Rosenbaum
Digital Equipment Corporation
550 King Street, LKG2-2/Z7
Littleton, MA  01460-1289

Phone: 508-486-5922
Email: rosenbaum@lkg.dec.com