RFC 1035
Domain names - implementation and specification
Part 1 of 10 🎀
RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION 💖
Okay bestie, let's start with the title block 🫶 This one's by P. Mockapetris at ISI, it came out of the Network Working Group, and it's dated November 1987. It obsoletes RFCs 882, 883, and 973, so those older ones got replaced by this one 💀. The header doesn't list anything it updates. I'm not going to make up a category or status since the header doesn't give one. The Status of This Memo section right below is where it tells you what's official and what's still experimental.
Table of Contents 📚
1. STATUS OF THIS MEMO 1
2. INTRODUCTION 3
2.1. Overview 3
2.2. Common configurations 4
2.3. Conventions 7
2.3.1. Preferred name syntax 7
2.3.2. Data Transmission Order 8
2.3.3. Character Case 9
2.3.4. Size limits 10
3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
3.1. Name space definitions 10
3.2. RR definitions 11
3.2.1. Format 11
3.2.2. TYPE values 12
3.2.3. QTYPE values 12
3.2.4. CLASS values 13
3.2.5. QCLASS values 13
3.3. Standard RRs 13
3.3.1. CNAME RDATA format 14
3.3.2. HINFO RDATA format 14
3.3.3. MB RDATA format (EXPERIMENTAL) 14
3.3.4. MD RDATA format (Obsolete) 15
3.3.5. MF RDATA format (Obsolete) 15
3.3.6. MG RDATA format (EXPERIMENTAL) 16
3.3.7. MINFO RDATA format (EXPERIMENTAL) 16
3.3.8. MR RDATA format (EXPERIMENTAL) 17
3.3.9. MX RDATA format 17
3.3.10. NULL RDATA format (EXPERIMENTAL) 17
3.3.11. NS RDATA format 18
3.3.12. PTR RDATA format 18
3.3.13. SOA RDATA format 19
3.3.14. TXT RDATA format 20
3.4. ARPA Internet specific RRs 20
3.4.1. A RDATA format 20
3.4.2. WKS RDATA format 21
3.5. IN-ADDR.ARPA domain 22
3.6. Defining new types, classes, and special namespaces 24
4. MESSAGES 25
4.1. Format 25
4.1.1. Header section format 26
4.1.2. Question section format 28
4.1.3. Resource record format 29
4.1.4. Message compression 30
4.2. Transport 32
4.2.1. UDP usage 32
4.2.2. TCP usage 32
5. MASTER FILES 33
5.1. Format 33
5.2. Use of master files to define zones 35
5.3. Master file example 36
6. NAME SERVER IMPLEMENTATION 37
6.1. Architecture 37
6.1.1. Control 37
6.1.2. Database 37
6.1.3. Time 39
6.2. Standard query processing 39
6.3. Zone refresh and reload processing 39
6.4. Inverse queries (Optional) 40
6.4.1. The contents of inverse queries and responses 40
6.4.2. Inverse query and response example 41
6.4.3. Inverse query processing 42
6.5. Completion queries and responses 42
7. RESOLVER IMPLEMENTATION 43
7.1. Transforming a user request into a query 43
7.2. Sending the queries 44
7.3. Processing responses 46
7.4. Using the cache 47
8. MAIL SUPPORT 47
8.1. Mail exchange binding 48
8.2. Mailbox binding (Experimental) 48
9. REFERENCES and BIBLIOGRAPHY 50
Index 541. Status of This Memo ✨
This RFC gets into the details of the domain system and its protocol. It assumes you already know the concepts from a companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034] 🧠
The domain system is a mix. Some of its functions and data types are an official protocol, and others are still experimental 🔬 Because the system is built to be extensible on purpose, you should always expect new data types and experimental behavior in the parts that go beyond the official protocol. The official bits include standard queries, standard responses, and the Internet class RR data formats (like host addresses). Several definitions have changed since the previous RFC set, so some of the older definitions are now obsolete 🥀
Experimental or obsolete features are clearly marked in these RFCs, so use that info with caution ⚠️
Also, don't depend on the values in the examples being current or complete. They're mostly there to teach you the idea, not to be a perfect snapshot of real life 📖 Distribution of this memo is unlimited 🦋
2. Introduction 💖
2.1. Overview
The whole goal of domain names is to give resources a name that works across different hosts, networks, protocol families, internets, and administrative organizations. Main character energy, honestly 👑
From the user's side, domain names are the arguments you hand to a local helper called a resolver, which goes and fetches the info tied to that name. So you might ask for the host address or the mail info for a particular domain name. To get the exact kind of info you want, you pass along a query type with the name. And here's the magic: to you, the whole domain tree looks like one big information space. The resolver is the one hiding the fact that the data is spread out across a bunch of name servers 🪄
From the resolver's side, the database that makes up the domain space is distributed among lots of name servers. Different parts of the space live on different servers, although a particular data item gets stored redundantly on two or more of them 🔁 The resolver starts out knowing about at least one name server. When it processes your query, it asks a server it knows for the info. In return, it either gets the answer or gets a referral to another name server. Through those referrals, resolvers learn who the other name servers are and what they hold 🕸️ Resolvers also handle the spread-out nature of the space, and they deal with a server failing by checking the redundant databases on other servers 💪
Name servers manage two kinds of data. The first kind is held in sets called zones. Each zone is the complete database for one particular "pruned" subtree of the domain space, and this data is called authoritative ✅ A name server periodically checks that its zones are still up to date. If they aren't, it grabs a fresh copy of the updated zones from master files stored locally or from another name server. The second kind is cached data, which a local resolver picked up along the way. This data might be incomplete, but it speeds up retrieval when non-local data gets accessed over and over again. Cached data eventually gets thrown out by a timeout mechanism ⏳
This split is so clean 😭 The resolvers handle the user interface, failure recovery, and distribution, while the name servers handle database updates and refreshes. Everyone has their own lane 🛣️
2.2. Common configurations
A host can join the domain name system in a bunch of different ways. It depends on whether the host runs programs that retrieve info from the domain system, name servers that answer queries from other hosts, or some mix of both. The simplest, and maybe most typical, setup looks like this:
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| cache | |
+----------+ |User programs talk to the domain name space through resolvers. The format of user queries and user responses is specific to the host and its operating system 🖥️ User queries will usually be operating system calls, and the resolver and its cache will be part of the host's OS. Hosts with less horsepower can instead build the resolver as a subroutine that gets linked into every program that needs it. Either way, resolvers answer user queries using info they pick up from queries to foreign name servers plus the local cache 💅
Here's the tea ☕ The resolver might have to ask several different foreign name servers to answer one user query. So resolving a single query can involve several network accesses and an arbitrary amount of time ⏰ The queries sent to foreign name servers, and the responses that come back, follow a standard format described in this memo, and they may be datagrams 📦
Depending on its capabilities, a name server could be a standalone program running on its own dedicated machine, or a process (or processes) running on a large
part 2 picks up right where that sentence leaves off 🧚
timeshared host. 💅 Okay so a simple setup might look like this:
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |So here a primary name server pulls in info about one or more zones by reading master files from its local file system 📂, and then it answers questions about those zones when foreign resolvers come knocking 🚪✨
The DNS requires that every zone be redundantly supported by more than one name server 🫶 That's the whole vibe. Designated secondary servers can grab zones and check for updates from the primary server using the zone transfer protocol of the DNS. Here's how that looks:
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| +------------|->| |
| queries | |Foreign |
| | | Name |
+------------------|--| Server |
maintenance responses | +--------+In this setup, the name server periodically opens a virtual circuit to a foreign name server 🦋 It does this either to grab a copy of a zone or to check that its existing copy hasn't changed. The messages for these maintenance activities follow the same form as queries and responses, but the message sequences are kinda different, so keep your eyes peeled 👀
The information flow in a host that supports all aspects of the domain name system looks like this 💖
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| Shared | |
| database | |
+----------+ |
A | |
+---------+ refreshes | | references |
/ /| | V |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| +------------|->| |
| queries | |Foreign |
| | | Name |
+------------------|--| Server |
maintenance responses | +--------+The shared database holds domain space data for the local name server and resolver 🌸 Its contents will typically be a mix of authoritative data kept fresh by the name server's periodic refresh operations, plus cached data from earlier resolver requests. The structure of the domain data and the need to keep name servers and resolvers in sync imply the general characteristics of this database, but the actual format is up to the local implementor 🧚
Information flow can also be tailored so a group of hosts acts together to optimize things 👑 Sometimes this is done to offload less capable hosts so they don't have to implement a full resolver. This can be a good fit for PCs or hosts that want to minimize the amount of new network code they need. This scheme can also let a group of hosts share a small number of caches instead of maintaining a bunch of separate ones, on the premise that the centralized caches will have a higher hit ratio 📈 Either way, resolvers get swapped out for stub resolvers, which act as front ends to resolvers living in a recursive server, in one or more name servers known to perform that service:
Local Hosts | Foreign
|
+---------+ |
| | responses |
| Stub |<--------------------+ |
| Resolver| | |
| |----------------+ | |
+---------+ recursive | | |
queries | | |
V | |
+---------+ recursive +----------+ | +--------+
| | queries | |queries | | |
| Stub |-------------->| Recursive|---------|->|Foreign |
| Resolver| | Server | | | Name |
| |<--------------| |<--------|--| Server |
+---------+ responses | |responses| | |
+----------+ | +--------+
| Central | |
| cache | |
+----------+ |In any case, note that domain components are always replicated for reliability whenever possible 🛡️💜
2.3. Conventions 🎀
The domain system has a bunch of conventions for low-level but super fundamental stuff 🤓 You're totally free to break these conventions WITHIN THEIR OWN SYSTEM, but you have to follow them in ALL behavior that other hosts can see 🙈
2.3.1. Preferred name syntax 💅
The DNS specs try to be as general as possible about how domain names get built. The idea is that the name of any existing object can be written as a domain name with minimal changes ✨
Still, when you're assigning a domain name to an object, the prudent user will pick a name that follows both the rules of the domain system and any existing rules for that object, whether those rules are published or just implied by existing programs 🧐 For example, when naming a mail domain, the user should follow both the rules of this memo and the rules in RFC-822. When creating a new host name, the old HOSTS.TXT rules should be followed. This avoids problems when old software gets converted to use domain names 🫶
The following syntax will mean fewer problems with lots of applications that use domain names (like mail and TELNET) 💌
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9Note that upper and lower case letters are allowed in domain names, but no significance is attached to the case 🔤 Two names with the same spelling but different case are treated as if they're identical 🪞
The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on length. Labels must be 63 characters or less 📏
For example, these strings identify hosts on the Internet: A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA 🌐
2.3.2. Data Transmission Order 🦋
The order of transmission for the header and data in this document is resolved all the way down to the octet level 🔢 Whenever a diagram shows a group of octets, they get transmitted in the normal order you'd read them in English. For example, in the diagram below, the octets go out in the order they're numbered 👇
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Whenever an octet represents a numeric quantity, the leftmost bit in the diagram is the high order or most significant bit. That means the bit labeled 0 is the most significant bit 🧠 In the example below, the diagram represents the value 170 (decimal) 🍓
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+Same deal for multi-octet fields: the leftmost bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted, the most significant octet goes first 🚀
2.3.3. Character Case 🌈
For all parts of the DNS that are part of the official protocol, every comparison between character strings (like labels, domain names, etc.) is done case-insensitively 💅 This rule is in force throughout the domain system with zero exceptions right now 🙌 However, future additions beyond current usage may need to use the full binary octet capabilities in names, so you should avoid trying to store domain names in 7-bit ASCII, or using special bytes to end labels, etc. 🚫
When data enters the domain system, its original case should be preserved whenever possible ✨ Sometimes that just can't happen 😭 For example, if two RRs are stored in a database, one at x.y and one at X.Y, they're actually stored in the same spot in the database, so only one casing would be kept. The basic rule is that case can be discarded only when data is used to define structure in a database, and two names are identical when compared case-insensitively 🧩
Loss of case-sensitive data must be minimized 🫧 So while data for x.y and X.Y may both get stored under a single location (x.y or X.Y), data for a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In general, this keeps the case of the first label of a domain name, but standardizes the interior node labels 💖
Systems administrators who enter data into the domain database should
take extra care to represent the data you supply to the domain system in a case-consistent way if your system is case-sensitive 💅. The good news is that the data distribution system in the domain system will make sure consistent representations stay preserved 🫶.
2.3.4. Size limits 📏
Various objects and parameters in the DNS have size limits, and they're listed below. Some could be changed easily, and others are more fundamental 🧱.
labels 63 octets or less
names 255 octets or less
TTL positive values of a signed 32 bit number.
UDP messages 512 octets or less3. DOMAIN NAME SPACE AND RR DEFINITIONS 🌈
3.1. Name space definitions 🧭
Domain names in messages are written as a sequence of labels 🏷️. Each label is a one octet length field followed by that many octets. Every domain name ends with the null label of the root, so a domain name is always terminated by a length byte of zero. The high order two bits of every length octet MUST be zero, and the remaining six bits limit the label to 63 octets or less 🙅.
To keep implementations simple, the total length of a domain name (label octets and label length octets together) is restricted to 255 octets or less ✨.
Labels can contain any 8 bit values in the octets that make up a label, but it is strongly RECOMMENDED that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions 🫶. Name servers and resolvers MUST compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII with zero parity. Non-alphabetic codes MUST match exactly 🔥.
3.2. RR definitions 📦
3.2.1. Format 🧩
All RRs have the same top level format, shown below 👀:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Here's what each field does:
NAME: an owner name, which is the name of the node this resource record pertains to.TYPE: two octets containing one of the RR TYPE codes.CLASS: two octets containing one of the RR CLASS codes.TTL: a 32 bit signed integer that says how long the resource record MAY be cached before the source of the information SHOULD again be consulted. Zero values are interpreted to mean the RR can only be used for the transaction in progress, and it SHOULD NOT be cached. For example, SOA records are always distributed with a zero TTL to prohibit caching. Zero values can also be used for extremely volatile data 🌸.RDLENGTH: an unsigned 16 bit integer that specifies the length in octets of the RDATA field.RDATA: a variable length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record.
3.2.2. TYPE values 🎯
TYPE fields are used in resource records. Note that these types are a subset of QTYPEs 💖.
TYPE value and meaning
A 1 a host address
NS 2 an authoritative name server
MD 3 a mail destination (Obsolete - use MX)
MF 4 a mail forwarder (Obsolete - use MX)
CNAME 5 the canonical name for an alias
SOA 6 marks the start of a zone of authority
MB 7 a mailbox domain name (EXPERIMENTAL)
MG 8 a mail group member (EXPERIMENTAL)
MR 9 a mail rename domain name (EXPERIMENTAL)
NULL 10 a null RR (EXPERIMENTAL)
WKS 11 a well known service description
PTR 12 a domain name pointer
HINFO 13 host information
MINFO 14 mailbox or mail list information
MX 15 mail exchange
TXT 16 text strings3.2.3. QTYPE values 🔍
QTYPE fields appear in the question part of a query. QTYPES are a superset of TYPEs, so all TYPEs are valid QTYPEs. On top of that, these extra QTYPEs are defined:
AXFR 252 A request for a transfer of an entire zone
MAILB 253 A request for mailbox-related records (MB, MG or MR)
MAILA 254 A request for mail agent RRs (Obsolete - see MX)
* 255 A request for all records3.2.4. CLASS values 🏷️
CLASS fields appear in resource records. The following CLASS mnemonics and values are defined 🌈:
IN 1 the Internet
CS 2 the CSNET class (Obsolete - used only for examples in
some obsolete RFCs)
CH 3 the CHAOS class
HS 4 Hesiod [Dyer 87]3.2.5. QCLASS values 🎀
QCLASS fields appear in the question section of a query. QCLASS values are a superset of CLASS values, so every CLASS is a valid QCLASS. On top of the CLASS values, the following QCLASS is defined:
* 255 any class3.3. Standard RRs 💜
The following RR definitions are expected to occur, at least potentially, in all classes. In particular, NS, SOA, CNAME, and PTR will be used in all classes, and they have the same format in every class. Because their RDATA format is known, all domain names in the RDATA section of these RRs MAY be compressed 🦋.
<domain-name> is a domain name represented as a series of labels, and terminated by a label with zero length. <character-string> is a single length octet followed by that number of characters. <character-string> is treated as binary information, and can be up to 256 characters in length (including the length octet) 🤓.
3.3.1. CNAME RDATA format 🔁
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
CNAME: A<domain-name>which specifies the canonical or primary name for the owner. The owner name is an alias.
CNAME RRs cause no additional section processing, but name servers MAY choose to restart the query at the canonical name in certain cases. See the description of name server logic in [RFC-1034] for details 🧠.
3.3.2. HINFO RDATA format 🖥️
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CPU /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ OS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
CPU: A<character-string>which specifies the CPU type.OS: A<character-string>which specifies the operating system type.
Standard values for CPU and OS can be found in [RFC-1010].
HINFO records are used to acquire general information about a host. The main use is for protocols such as FTP that can use special procedures when talking between machines or operating systems of the same type 💻.
3.3.3. MB RDATA format (EXPERIMENTAL) 📫
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
MADNAME: A<domain-name>which specifies a host which has the specified mailbox.
MB records cause additional section processing, which looks up the A type RRs corresponding to MADNAME.
3.3.4. MD RDATA format (Obsolete) 🪦
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
MADNAME: A<domain-name>which specifies a host which has a mail agent for the domain which SHOULD be able to deliver mail for the domain.
MD records cause additional section processing which looks up an A type record corresponding to MADNAME.
MD is obsolete 😭. See the definition of MX and [RFC-974] for details of the new scheme. The RECOMMENDED policy for dealing with MD RRs found in a master file is to reject them, or to convert them to MX RRs with a preference of 0.
3.3.5. MF RDATA format (Obsolete) 📭
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
MADNAME: A<domain-name>which specifies a host which has a mail agent for the domain which will accept mail for forwarding to the domain.
MF records cause additional section processing which looks up an A type record corresponding to MADNAME.
MF is obsolete 💀. See the definition of MX and [RFC-974] for details of the new scheme. The RECOMMENDED policy for dealing with MD RRs found in a master file is to reject them, or to convert them to MX RRs with a preference of 10.
3.3.6. MG RDATA format (EXPERIMENTAL) 👥
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MGMNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
MGMNAME: A<domain-name>which specifies a mailbox which is a member of the mail group specified by the domain name.
MG records cause no additional section processing.
3.3.7. MINFO RDATA format (EXPERIMENTAL) 📋
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RMAILBX /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EMAILBX /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
RMAILBX: A<domain-name>which specifies a mailbox which is responsible for the mailing list or mailbox. If this domain name names the root, the owner of the MINFO RR is responsible for itself. Note that many existing mailing lists use a mailbox X-request for the RMAILBX field of mailing list X, e.g., Msgroup-request for Msgroup. This field provides a more general mechanism 📮.EMAILBX: A<domain-name>which specifies a mailbox which is to receive error messages related to the mailing list or mailbox specified by the owner of the MINFO RR (similar to the ERRORS-TO: field which has been proposed). If this domain name names the root, errors SHOULD be returned to the sender of the message.
MINFO records cause no additional section processing. Although these records can be associated with a simple mailbox, they are usually used with a mailing list ✨.
3.3.8. MR RDATA format (EXPERIMENTAL) 🔀
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NEWNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Okay so the recommended move for any MD RRs hanging out in a master file is to either reject them or convert them into MX RRs with a preference of 10 💅 no cap, that's the whole vibe.
3.3.6. MG RDATA format (EXPERIMENTAL) 🧚
where:
MG records cause no additional section processing, so the server doesn't go digging for extra stuff 🌸
3.3.7. MINFO RDATA format (EXPERIMENTAL) 🦋
where:
MINFO records cause no additional section processing 💖 Although these records can be associated with a simple mailbox, they are usually used with a mailing list, which is giving group chat energy 📬
3.3.8. MR RDATA format (EXPERIMENTAL) 💌
where:
NEWNAME: a<domain-name>that names the mailbox which is the proper rename of the specified mailbox ✨
MR records cause no additional section processing, bestie. The main use for MR is as a forwarding entry for a user who has moved over to a different mailbox 📬🫶
3.3.9. MX RDATA format 💜
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGE /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
PREFERENCE: a 16 bit integer that sets how much preference this RR gets over the others at the same owner. Lower values are preferred 🎀EXCHANGE: a<domain-name>naming a host that's willing to act as a mail exchange for the owner name 💅
MX records cause type A additional section processing for the host specified by EXCHANGE. If you want the full tea on how MX RRs work, it's explained in detail in [RFC-974] 🍓
3.3.10. NULL RDATA format (EXPERIMENTAL) 🌈
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ <anything> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Anything at all may be in the RDATA field, as long as it's 65535 octets or less 🙈
NULL records cause no additional section processing. NULL RRs are not allowed in master files, and NULLs are used as placeholders in some experimental extensions of the DNS 🧪
3.3.11. NS RDATA format 👑
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
NSDNAME: a<domain-name>naming a host which should be authoritative for the specified class and domain 🫶
NS records cause both the usual additional section processing to locate a type A record, and, when they're used in a referral, a special search of the zone they live in for glue information 🔥
The NS RR says the named host should be expected to have a zone starting at the owner name of the specified class. Note that the class may not indicate the protocol family that should be used to talk to the host, although it's typically a strong hint. For example, hosts that are name servers for either Internet (IN) or Hesiod (HS) class information are normally queried using IN class protocols 🌸
3.3.12. PTR RDATA format 🦋
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ PTRDNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
PTRDNAME: a<domain-name>that points to some location in the domain name space 🧚
PTR records cause no additional section processing. These RRs get used in special domains to point to some other location in the domain space. They're simple data, and they don't imply any special processing like the kind CNAME does for aliases. Check out the description of the IN-ADDR.ARPA domain for an example 💖
3.3.13. SOA RDATA format 👑
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SERIAL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| REFRESH |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RETRY |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EXPIRE |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MINIMUM |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
MNAME: the<domain-name>of the name server that was the original or primary source of data for this zone 🌟RNAME: a<domain-name>specifying the mailbox of the person responsible for this zone 💌SERIAL: the unsigned 32 bit version number of the original copy of the zone. Zone transfers preserve this value. It wraps around, so it should be compared using sequence space arithmetic 🔢REFRESH: a 32 bit time interval before the zone should be refreshed ⏰RETRY: a 32 bit time interval that should elapse before a failed refresh should be retried 🔁EXPIRE: a 32 bit time value setting the upper limit on how long the time interval can run before the zone is no longer authoritative 💀MINIMUM: the unsigned 32 bit minimum TTL field that should be exported with any RR from this zone 🎀
SOA records cause no additional section processing. All times are in units of seconds ⏱️
Most of these fields only matter for name server maintenance operations. However, MINIMUM gets used in all query operations that retrieve RRs from a zone. Whenever an RR is sent in a response to a query, its TTL field is set to the maximum of the TTL field from the RR and the MINIMUM field in the appropriate SOA. So MINIMUM is a lower bound on the TTL field for all RRs in a zone 🧠 Note that this use of MINIMUM should happen when the RRs are copied into the response, and not when the zone is loaded from a master file or via a zone transfer. The reason for this is to let future dynamic update facilities change the SOA RR with known semantics ✨
3.3.14. TXT RDATA format 🌈
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ TXT-DATA /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
TXT-DATA: one or more<character-string>s 🍓
TXT RRs are used to hold descriptive text. What the text means depends on the domain where it's found 📝
3.4. Internet specific RRs 🌐
3.4.1. A RDATA format 💜
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
ADDRESS: a 32 bit Internet address 🏠
Hosts that have multiple Internet addresses will have multiple A records 🏡
A records cause no additional section processing. The RDATA section of an A line in a master file is an Internet address written as four decimal numbers separated by dots, with no embedded spaces (e.g., "10.2.0.52" or "192.0.5.6") 🔢
3.4.2. WKS RDATA format 🎀
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PROTOCOL | |
+--+--+--+--+--+--+--+--+ |
| |
/ <BIT MAP> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
ADDRESS: a 32 bit Internet address 🏠PROTOCOL: an 8 bit IP protocol number 🔌<BIT MAP>: a variable length bit map. The bit map must be a multiple of 8 bits long 🗺️
The WKS record is used to describe the well known services supported by a particular protocol on a particular internet address. The PROTOCOL field specifies an IP protocol number, and the bit map has one bit per port of that protocol. The first bit corresponds to port 0, the second to port 1, and so on. If the bit map doesn't include a bit for a protocol you care about, that bit is assumed to be zero. The right values and mnemonics for ports and protocols are specified in [RFC-1010] 🧾
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port 25 (SMTP). If that bit is set, a SMTP server should be listening on TCP port 25. If it's zero, SMTP service is not supported on the specified address 📭
The whole point of WKS RRs is to provide availability information for servers over TCP and UDP. If a server supports both TCP and UDP, or has multiple Internet addresses, then multiple WKS RRs are used 🙌
WKS RRs cause no additional section processing.
In master files, both ports and protocols are expressed using mnemonics or decimal numbers 🔤
3.5. IN-ADDR.ARPA domain 🔍
The Internet uses a special domain to support gateway location and Internet address to host mapping. Other classes may use a similar strategy in other domains. The goal of this domain is to provide a guaranteed way to map a host address to a host name, and to make it easy to find all the gateways on a particular network in the Internet 🗺️
Note that both of these services are similar to functions that could be performed by inverse queries. The difference is that this part of the domain name space is structured by address, so the appropriate data can be located without an exhaustive search of the domain space 🕵️♀️
The domain begins at IN-ADDR.ARPA and has a substructure that follows the Internet addressing structure 🌳
Domain names in the IN-ADDR.ARPA domain can have up to four labels in addition to the IN-ADDR.ARPA suffix. Each label represents one octet of an Internet address, and is written as a character string for a decimal value in the range 0-255. Leading zeros are left out, except for a zero octet, which is represented by a single zero 🔢
Host addresses are represented by domain names that have all four labels specified. So data for Internet address 10.2.0.52 lives at the domain name 52.0.2.10.IN-ADDR.ARPA. The reversal is a bit awkward to read, but it lets zones be delegated so each one covers exactly one network of address space. For example, 10.IN-ADDR.ARPA can be a zone containing data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for MILNET. Address nodes hold pointers to primary host names in the normal domain space 💫
Network numbers correspond to some non-terminal nodes at various depths in the IN-ADDR.ARPA domain, since Internet network numbers are either 1, 2, or 3 octets. Network nodes hold pointers to the primary host names of the gateways attached to that network. Since a gateway is, by definition, on more than one network, it will typically have two or more network nodes pointing at it. Gateways will also have host level pointers at their fully qualified addresses 🌉
Both the gateway pointers at network nodes and the normal host pointers at full address nodes use the PTR RR to point back to the primary domain names of the corresponding hosts 🔙
For example, the IN-ADDR.ARPA domain will contain information about the ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's net 18, and the hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming the ISI gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
and a name GW.LCS.MIT.EDU 🎀, so the domain database would hold this 💅:
10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.So a program that wants to find the gateways on net 10 would send a query with QTYPE=PTR, QCLASS=IN, and QNAME=10.IN-ADDR.ARPA. 🦋 It gets back two RRs:
10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.After that, the program can send QTYPE=A, QCLASS=IN queries for MILNET-GW.ISI.EDU. and GW.LCS.MIT.EDU. to find the Internet addresses of those gateways ✨.
A resolver that wants the host name for Internet host address 10.0.0.6 goes with a query of the form QTYPE=PTR, QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and gets this back:
6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.⚠️ bestie, these services come with some cautions, so read these carefully:
- Since the IN-ADDR.ARPA special domain and the normal domain for a particular host or gateway will be in different zones, the possibility exists that the data may be inconsistent. 😭
- Gateways will often have two names in separate domains, only one of which can be primary. 🙈
- Systems that use the domain database to initialize their routing tables must start with enough gateway information to guarantee that they can access the appropriate name server. 🔥
- The gateway data only reflects the existence of a gateway in a manner equivalent to the current HOSTS.TXT file. It doesn't replace the dynamic availability information from GGP or EGP. 💀
3.6. Defining new types, classes, and special namespaces 🌈
The types and classes we've covered so far are the ones in use as of the date of this memo, but ngl, new definitions are totally going to show up. This section gives some recs to designers who are thinking about adding to the existing stuff. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is where the general design chat happens 💬.
Generally, a new type makes sense when new info needs to go into the database about an existing object, or when we need new data formats for something totally new. Designers should try to define types and their RDATA formats that work for all classes and avoid duplicating info 🧚. New classes are the move when DNS is being used for a new protocol (etc.) that needs new class-specific data formats, or when you want a copy of the existing name space but it needs its own management domain 👑.
New types and classes need mnemonics for master files, and the master file format requires that the type and class mnemonics be disjoint 🍓.
TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes respectively. 💅
The current system uses multiple RRs to represent multiple values of a type, rather than stuffing multiple values into the RDATA section of one RR. Yes, this is less efficient for most apps, but it keeps RRs shorter 🦋. The multiple-RRs approach is also part of some experimental work on dynamic update methods ✨.
The current system also tries hard to minimize duplicated data in the database so it stays consistent 🫶. So, to find the address of the host for a mail exchange, you map the mail domain name to a host name, and then map the host name to addresses, rather than mapping directly to a host address. This is the preferred approach because it avoids the chance for inconsistency 💖.
When you define a new type of data, don't use multiple RR types to create an ordering between entries or to express different formats for equivalent bindings. Instead, put that info in the body of the RR and use a single type. This policy avoids problems with caching multiple types and with defining QTYPEs to match multiple types 🌸.
For example, the original form of the mail exchange binding used two RR types: one for a "closer" exchange (MD) and one for a "less close" exchange (MF). The problem is that having one RR type in a cache doesn't tell you anything about the other, because the query that got the cached info might have used a QTYPE of MF, MD, or MAILA (which matched both). The redesigned service uses a single type (MX) with a "preference" value in the RDATA section that can order different RRs. However, if any MX RRs are in the cache, then all of them should be there 🙈.
4. MESSAGES ✨
4.1. Format 🎀
All communications inside the domain protocol are carried in one single format called a message. The top level format of a message is divided into 5 sections (some of which are empty in certain cases), shown below 💅:
+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | RRs answering the question
+---------------------+
| Authority | RRs pointing toward an authority
+---------------------+
| Additional | RRs holding additional information
+---------------------+The header section is always present. The header has fields that say which of the other sections are there, and also whether the message is a query or a response, a standard query or some other opcode, and so on 🔥.
The names of the sections after the header come from how they're used in standard queries. The question section holds fields that describe a question for a name server: a query type (QTYPE), a query class (QCLASS), and a query domain name (QNAME). The last three sections all have the same format, which is a possibly empty list of concatenated resource records (RRs). The answer section has RRs that answer the question. The authority section has RRs that point toward an authoritative name server. The additional records section has RRs that relate to the query but aren't strictly answers to the question 🧚.
4.1.1. Header section format 🌈
The header contains the following fields 🍓:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Here's what each one means 👑:
IDis a 16 bit identifier assigned by the program that generates any kind of query. It gets copied into the corresponding reply, so the requester can use it to match up replies with outstanding queries 🦋.QRis a one bit field that says whether the message is a query (0) or a response (1) 💖.OPCODEis a four bit field that says what kind of query this message is. The originator of a query sets it, and it gets copied into the response. The values are:
0 a standard query (QUERY)
1 an inverse query (IQUERY)
2 a server status request (STATUS)
3-15 reserved for future useAA(Authoritative Answer) is only valid in responses. It says the responding name server is an authority for the domain name in the question section 🌸.
Note that the answer section can have multiple owner names because of aliases. The AA bit lines up with the name that matches the query name, or with the first owner name in the answer section ✨.
TC(TrunCation) says this message got truncated because its length was greater than what the transmission channel allows 🙈.RD(Recursion Desired) may be set in a query, and it gets copied into the response. IfRDis set, it tells the name server to pursue the query recursively. Recursive query support is optional 🔥.RA(Recursion Available) is set or cleared in a response, and it shows whether the name server supports recursive queries 💅.Zis reserved for future use. Must be zero in all queries and responses 🫶.RCODEis the response code. This 4 bit field gets set as part of responses, and the values mean the following 🌈:
0 No error condition
1 Format error - The name server was
unable to interpret the query.
2 Server failure - The name server was
unable to process this query due to a
problem with the name server.
3 Name Error - Meaningful only for
responses from an authoritative name
server, this code signifies that the
domain name referenced in the query does
not exist.
4 Not Implemented - The name server does
not support the requested kind of query.
5 Refused - The name server refuses to
perform the specified operation for
policy reasons. For example, a name
server may not wish to provide the
information to the particular requester,
or a name server may not wish to perform
a particular operation (e.g., zone
transfer) for particular data.
6-15 Reserved for future use.QDCOUNTis an unsigned 16 bit integer that specifies the number of entries in the question section 🧚.ANCOUNTis an unsigned 16 bit integer that specifies the number of resource records in the answer section 🍓.NSCOUNTis an unsigned 16 bit integer that specifies the number of name server resource records in the authority records section 🎀.ARCOUNTis an unsigned 16 bit integer that specifies the number of resource records in the additional records section 💜.
4.1.2. Question section format ✨
The question section carries the "question" in most queries, which means the parameters that define what's being asked. The section
okay so it contains QDCOUNT (usually 1) entries, each of the following format: 💖
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
QNAME is a domain name, written as a sequence of labels. Each label is a length octet followed by that many octets 🧩 The name ends with the zero length octet for the null label of the root. Heads up: this field can be an odd number of octets, and no padding is used 🙈
QTYPE is a two octet code that says what type of query it is. The values here include every code that's valid for a TYPE field, plus some broader codes that can match more than one type of RR 🎀
QCLASS is a two octet code that says the class of the query. For example, QCLASS is IN for the Internet 🌐
4.1.3. Resource record format ✨
The answer, authority, and additional sections all share the same format: a variable number of resource records. The count for each one is in the matching count field in the header 📋 Every resource record looks like this:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
NAME is a domain name that this resource record is about 🏡
TYPE is two octets holding one of the RR type codes. This field decides what the data in the RDATA field means 🔑
CLASS is two octets that say what class the data in the RDATA field is in 🏷️
TTL is a 32 bit unsigned integer. It's the time interval, in seconds, that the resource record may be cached before it should be discarded ⏳ A zero value means the RR can only be used for the transaction in progress, and it should not be cached. Zero is a big "do not save this" 🙅♀️
RDLENGTH is an unsigned 16 bit integer that gives the length, in octets, of the RDATA field 📏
RDATA is a variable length string of octets that describes the resource. Its format depends on the TYPE and CLASS of the resource record. For example, if the TYPE is A and the CLASS is IN, then RDATA is a 4 octet ARPA Internet address 🌸
4.1.4. Message compression 🗜️
Okay, so to keep messages small, the domain system uses a compression scheme that gets rid of repeated domain names in a message 💅 An entire domain name, or a list of labels at the end of a domain name, gets swapped for a pointer to an earlier occurrence of the same name.
The pointer is a two octet sequence:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+The first two bits are ones. That's how you can tell a pointer apart from a label, since a label has to start with two zero bits (labels are capped at 63 octets or less) 🕵️♀️ The 10 and 01 combinations are reserved for future use 🔮 The OFFSET field is an offset from the start of the message, which means the first octet of the ID field in the domain header. An offset of zero points at the first byte of the ID field, and so on 🧭
The compression scheme lets a domain name in a message be written as any of these:
- a sequence of labels ending in a zero octet
- a pointer
- a sequence of labels ending with a pointer
Pointers can only be used for occurrences of a domain name where the format is not class specific. If that weren't the case, a name server or resolver would be required to know the format of all RRs it handled. There aren't any such cases yet, but they may show up in future RDATA formats 👀
If a domain name sits inside a part of the message that has a length field (like the RDATA section of an RR), and compression is used, the length of the compressed name is what goes into the length calculation, not the length of the expanded name 🧮
Programs are free to skip pointers in the messages they generate. Just know that this will make the datagram capacity smaller and may cause truncation 📦 However, all programs are required to understand arriving messages that contain pointers 💜
For example, a datagram might need the domain names F.ISI.ARPA, FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the message, these domain names might look like this:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 1 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 3 | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | S | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 4 | A |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | R | P |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30 | A | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | 3 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | O | O |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1| 20 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 1| 26 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
92 | 0 | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+So F.ISI.ARPA is written out at offset 20. FOO.F.ISI.ARPA is at offset 40, and it uses a pointer to stick a label for FOO onto the earlier F.ISI.ARPA 🧠 The name ARPA is defined at offset 64 with a pointer to the ARPA part of the name at 20. Note that this only works because ARPA is the last label in the string at 20 🎯 And the root domain name is a single octet of zeros at 92. The root has no labels 🌳
4.2. Transport 🚚
The DNS assumes messages get sent as datagrams, or in a byte stream carried by a virtual circuit. Virtual circuits can be used for any DNS activity, but datagrams are preferred for queries because they have lower overhead and better performance ⚡ Zone refresh activities must use virtual circuits, because they need reliable transfer 🔒
The Internet supports name server access over TCP [RFC-793] on server port 53 (decimal), and over datagrams with UDP [RFC-768] on UDP port 53 (decimal) 🌍
4.2.1. UDP usage 📨
Messages sent using UDP use server port 53 (decimal) 🔢
Messages carried by UDP are restricted to 512 bytes, not counting the IP or UDP headers. Longer messages get truncated, and the TC bit is set in the header ✂️
UDP is not acceptable for zone transfers, but it is the recommended method for standard queries on the Internet. Queries sent using UDP may be lost, so a retransmission strategy is required 🔁 The network, or processing in name servers, may reorder queries or their responses, so resolvers should not depend on getting them back in order 🌀
The best UDP retransmission policy depends on how the Internet is performing and what the client needs. Still, the following are recommended:
- The client should try other servers and server addresses before repeating a query to a specific address of a server.
- The retransmission interval should be based on prior statistics if possible. Retransmitting too aggressively can easily slow responses for everyone else, so be nice 🫶 Depending on how well connected the client is to its expected servers, the minimum retransmission interval should be 2-5 seconds ⏱️
There are more tips on server selection and retransmission policy in the resolver section of this memo 📚
4.2.2. TCP usage 🤝
Messages sent over TCP connections use server port 53 (decimal). Each message is prefixed with a two byte length field, which gives the message length without counting that two byte length field. This lets the low-level processing put together a complete message before it starts parsing 🧩
Several connection management policies are recommended:
- The server should not block other activities while it waits for TCP data 🏃♀️
- The server should support multiple connections 👯♀️
- The server should assume the client will start closing the connection, and it should hold off closing its end until all outstanding client requests have been satisfied 🤲
- If the server needs to close a dormant connection to free up resources, it should wait until the connection has been idle for something on the order of two minutes ⌛ In particular, the server should let the SOA and AXFR request sequence (which begins a refresh operation) happen on a single connection. Since the server couldn't answer queries anyway, a unilateral close or reset may be used instead of a graceful close 💀
5. MASTER FILES 📜
Master files are text files that contain RRs in text form. A zone's contents can be written as a list of RRs, so a master file is most often used to define a zone, though it can also list a cache's contents 🗂️ This section covers the format of RRs in a master file first, then the special considerations for when a master file is used to create a zone in a name server 💖
5.1. Format 🖊️
The format of these files is a sequence of entries. Entries are mostly line-oriented, but parentheses can be used to continue a list of items across a line boundary, and text literals can contain CRLF within the text 🌈 Any mix of tabs and spaces acts as a delimiter between the separate items that make up an entry. So the end of
any line in the master file can end with a comment 🎀. The comment starts with a ; (semicolon) and runs to the end of the line, so you can leave yourself notes without breaking anything ✨
The following entries are defined 👀:
<blank>[<comment>]
$ORIGIN <domain-name> [<comment>]
$INCLUDE <file-name> [<domain-name>] [<comment>]
<domain-name><rr> [<comment>]
<blank><rr> [<comment>]Blank lines, with or without comments, are totally allowed anywhere in the file 🌸
There are two control entries, $ORIGIN and $INCLUDE 💅. $ORIGIN is followed by a domain name, and it resets the current origin for relative domain names to that stated name. $INCLUDE inserts the named file into the current file, and it may optionally specify a domain name that sets the relative domain name origin for the included file. $INCLUDE may also have a comment. Also, a $INCLUDE entry never changes the relative origin of the parent file, no matter what changes were made to the relative origin inside the included file 🙈
The last two forms represent RRs. If an entry for an RR begins with a blank, then the RR is assumed to be owned by the last stated owner. If an RR entry begins with a <domain-name>, then the owner name gets reset 🦋
<rr> contents take one of the following forms:
[<TTL>] [<class>] <type> <RDATA>
[<class>] [<TTL>] <type> <RDATA>The RR begins with optional TTL and class fields, followed by a type and RDATA field that fits the type and class. Class and type use the standard mnemonics, and TTL is a decimal integer. Omitted class and TTL values default to the last explicitly stated values. Since type and class mnemonics are disjoint, the parse is unique ✨ (Note that this order is different from the order used in examples and the order used in the actual RRs. The given order allows easier parsing and defaulting, so it's giving logic 🧠)
<domain-name>s make up a large share of the data in the master file 💖. The labels in a domain name are expressed as character strings and separated by dots. Quoting conventions let you store arbitrary characters in domain names, which is wild 🌈 Domain names that end in a dot are called absolute, and they are taken as complete. Domain names which do not end in a dot are called relative. The actual domain name is the concatenation of the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as an argument to the master file loading routine. A relative name is an error when no origin is available 💀
A <character-string> is expressed in one of two ways: as a contiguous set of characters without interior spaces, or as a string that begins with a " and ends with a ". Inside a " delimited string any character can occur, except for a " itself, which must be quoted using \ (back slash) 🫶
Because these files are text files, a few special encodings are needed so arbitrary data can get loaded. Here's the lineup, bestie 🧚
of the root.
@ A free standing @ is used to denote the current origin.
\X where X is any character other than a digit (0-9), is
used to quote that character so that its special meaning
does not apply. For example, "\." can be used to place
a dot character in a label.
\DDD where each D is a digit is the octet corresponding to
the decimal number described by DDD. The resulting
octet is assumed to be text and is not checked for
special meaning.
( ) Parentheses are used to group data that crosses a line
boundary. In effect, line terminations are not
recognized within parentheses.
; Semicolon is used to start a comment; the remainder of
the line is ignored.5.2. Use of master files to define zones ✨
When a master file is used to load a zone, the operation should be suppressed if any errors are encountered in the master file 🚫 The reason is that a single error can have widespread consequences. For example, suppose the RRs defining a delegation have syntax errors. Then the server will return authoritative name errors for all names in the subzone, except in the case where the subzone is also present on the server 😭
Several other validity checks should be performed too, on top of making sure the file is syntactically correct 🔍
- All RRs in the file should have the same class.
- Exactly one SOA RR should be present at the top of the zone.
- If delegations are present and glue information is required, it should be present.
- Information present outside of the authoritative nodes in the zone should be glue information, rather than the result of an origin or similar error.
5.3. Master file example 🍓
The following is an example file which might be used to define the ISI.EDU zone, and it is loaded with an origin of ISI.EDU 👑
@ IN SOA VENERA Action\.domains (
20 ; SERIAL
7200 ; REFRESH
600 ; RETRY
3600000; EXPIRE
60) ; MINIMUM
NS A.ISI.EDU.
NS VENERA
NS VAXA
MX 10 VENERA
MX 20 VAXA
A A 26.3.0.103
VENERA A 10.1.0.52
A 128.9.0.32
VAXA A 10.2.0.27
A 128.9.0.33
$INCLUDE <SUBSYS>ISI-MAILBOXES.TXTWhere the file <SUBSYS>ISI-MAILBOXES.TXT is:
MOE MB A.ISI.EDU.
LARRY MB A.ISI.EDU.
CURLEY MB A.ISI.EDU.
STOOGES MG MOE
MG LARRY
MG CURLEYNote the use of the \ character in the SOA RR to specify the responsible person mailbox "Action.domains@E.ISI.EDU" 💜
6. NAME SERVER IMPLEMENTATION 🧚♀️
6.1. Architecture 🏗️
The optimal structure for the name server depends on the host operating system, and on whether the name server is integrated with resolver operations. That can happen by supporting recursive service, or by sharing its database with a resolver. This section discusses implementation considerations for a name server that shares a database with a resolver, but most of these concerns show up in any name server 🌸
6.1.1. Control
A name server must employ multiple concurrent activities, whether they are implemented as separate tasks in the host's OS or as multiplexing inside a single name server program. It is simply not acceptable for a name server to block the service of UDP requests while it waits for TCP data for refreshing or query activities 😤 Similarly, a name server should not attempt to provide recursive service without processing such requests in parallel. It may choose to serialize requests from a single client, or to regard identical requests from the same client as duplicates. A name server should not substantially delay requests while it reloads a zone from master files, or while it incorporates a newly refreshed zone into its database ⭐
6.1.2. Database 🗂️
While name server implementations are free to use any internal data structures they choose, the suggested structure consists of three major parts 💅
- A "catalog" data structure which lists the zones available to this server, and a "pointer" to the zone data structure. The main purpose of this structure is to find the nearest ancestor zone, if any, for arriving standard queries.
- Separate data structures for each of the zones held by the name server.
- A data structure for cached data. (or perhaps separate caches for different classes)
All of these data structures can be implemented as an identical tree structure format, with different data chained off the nodes in different parts. In the catalog, the data is pointers to zones, while in the zone and cache data structures, the data will be RRs. When designing the tree framework, the designer should recognize that query processing will need to traverse the tree using case-insensitive label comparisons. Also, in real data, a few nodes have a very high branching factor (100-1000 or more), but the vast majority have a very low branching factor (0-1) 🌳
One way to solve the case problem is to store the labels for each node in two pieces. The first is a standardized-case representation of the label, where all ASCII characters are in a single case. The second is a bit mask that denotes which characters are actually of a different case 🩷 The branching factor diversity can be handled using a simple linked list for a node until the branching factor exceeds some threshold, and then transitioning to a hash structure after the threshold is exceeded. In any case, hash structures used to store tree sections must ensure that hash functions and procedures preserve the casing conventions of the DNS 🔐
The use of separate structures for the different parts of the database is motivated by several factors 🎀
- The catalog structure can be an almost static structure that needs to change only when the system administrator changes the zones supported by the server. This structure can also be used to store parameters used to control refreshing activities.
- The individual data structures for zones allow a zone to be replaced simply by changing a pointer in the catalog. Zone refresh operations can build a new structure and, when complete, splice it into the database via a simple pointer replacement. It is very important that when a zone is refreshed, queries should not use old and new data simultaneously 🙅♀️
- With the proper search procedures, authoritative data in zones will always "hide", and hence take precedence over, cached data.
- Errors in zone definitions that cause overlapping zones, etc., may cause erroneous responses to queries. But problem determination is simplified, and the contents of one "bad" zone can't corrupt another 🧹
- Since the cache is most frequently updated, it is most vulnerable to corruption during system restarts. It can also become full of expired RR data. In either case, it can easily be discarded without disturbing zone data 🗑️
A major aspect of database design is selecting a structure which allows the name server to deal with crashes of the name server's host 💥 State information which a name server should save across system crashes includes the catalog structure (including the state of refreshing for each zone) and the zone data itself 💾
6.1.3. Time ⏰
Both the TTL data for RRs and the timing data for refreshing activities depend on 32 bit timers in units of seconds. Inside the database, refresh timers and TTLs for cached data conceptually "count down", while data in the zone stays with constant TTLs ⏳
A recommended implementation strategy is to store time in two ways: as a relative increment and as an absolute time. One way to do this is to use positive 32 bit numbers for one type and negative numbers for the other. The RRs in zones use relative times, and the refresh timers and cache data use absolute times. Absolute numbers are taken with respect to some known origin, and they get converted to relative values when placed in the response to a query. When an absolute TTL is negative after conversion to relative, then the data is expired and should be ignored 🫠
6.2. Standard query processing 🔎
The major algorithm for standard query processing is presented in [RFC-1034] 📖
When processing queries with QCLASS=*, or some other QCLASS which matches multiple classes, the response should never be authoritative unless the server can guarantee that the response covers all classes 🌈
When composing a response, RRs which are to be inserted in the additional section, but which duplicate RRs in the answer or authority sections, may be omitted from the additional section 🍭
When a response is so long that truncation is required, the truncation should start at the end of the response and work forward in the datagram. Thus, if there is any data for the authority section, the
the answer section is guaranteed to be unique, bestie 💖
okay so the MINIMUM value in the SOA should be used to set a floor on the TTL of data distributed from a zone 🎀 this floor function should be done when the data is copied into a response. this lets future dynamic update protocols change the SOA MINIMUM field without ambiguous semantics 🦋
6.3. Zone refresh and reload processing 🌸
in spite of a server's best efforts, it may be unable to load zone data from a master file due to syntax errors, etc., or be unable to refresh a zone within its expiration parameter. in this case, the name server should answer queries as if it were not supposed to possess the zone 🙈
if a master is sending a zone out via AXFR, and a new version is created during the transfer, the master should continue to send the old version if possible. in any case, it should never send part of one version and part of another. if completion is not possible, the master should reset the connection on which the zone transfer is taking place 😭
6.4. Inverse queries (Optional) 🔮
inverse queries are an optional part of the DNS. name servers are not required to support any form of inverse queries. if a name server receives an inverse query that it does not support, it returns an error response with the "Not Implemented" error set in the header. while inverse query support is optional, all name servers must be at least able to return the error response 💅
6.4.1. The contents of inverse queries and responses ✨
Inverse queries reverse the mappings performed by standard query operations. while a standard query maps a domain name to a resource, an inverse query maps a resource to a domain name. for example, a standard query might bind a domain name to a host address; the corresponding inverse query binds the host address to a domain name 🧚
inverse queries take the form of a single RR in the answer section of the message, with an empty question section. the owner name of the query RR and its TTL are not significant. the response carries questions in the question section which identify all names possessing the query RR WHICH THE NAME SERVER KNOWS. since no name server knows about all of the domain name space, the response can never be assumed to be complete. thus inverse queries are primarily useful for database management and debugging activities 🛠️
inverse queries are NOT an acceptable method of mapping host addresses to host names; use the IN-ADDR.ARPA domain instead 🚫
where possible, name servers should provide case-insensitive comparisons for inverse queries. thus an inverse query asking for an MX RR of Venera.isi.edu should get the same response as a query for VENERA.ISI.EDU; an inverse query for HINFO RR IBM-PC UNIX should produce the same result as an inverse query for IBM-pc unix. however, this cannot be guaranteed because name servers may possess RRs that contain character strings but the name server does not know that the data is character 🤷♀️
when a name server processes an inverse query, it either returns:
- zero, one, or multiple domain names for the specified resource as
QNAMEs in the question section - an error code indicating that the name server doesn't support inverse mapping of the specified resource type.
when the response to an inverse query contains one or more QNAMEs, the owner name and TTL of the RR in the answer section which defines the inverse query is modified to exactly match an RR found at the first QNAME 🎯
RRs returned in the inverse queries cannot be cached using the same mechanism as is used for the replies to standard queries. one reason for this is that a name might have multiple RRs of the same type, and only one would appear. for example, an inverse query for a single address of a multiply homed host might create the impression that only one address existed 👀
6.4.2. Inverse query and response example 🎀
The overall structure of an inverse query for retrieving the domain name that corresponds to Internet address 10.1.0.52 is shown below:
+-----------------------------------------+
Header | OPCODE=IQUERY, ID=997 |
+-----------------------------------------+
Question | <empty> |
+-----------------------------------------+
Answer | <anyname> A IN 10.1.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+this query asks for a question whose answer is the Internet style address 10.1.0.52. since the owner name is not known, any domain name can be used as a placeholder (and is ignored). a single octet of zero, signifying the root, is usually used because it minimizes the length of the message. the TTL of the RR is not significant. the response to this query might be:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=997 |
+-----------------------------------------+
Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
+-----------------------------------------+
Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+note that the QTYPE in a response to an inverse query is the same as the TYPE field in the answer section of the inverse query. responses to inverse queries may contain multiple questions when the inverse is not unique. if the question section in the response is not empty, then the RR in the answer section is modified to correspond to be an exact copy of an RR at the first QNAME 🧁
6.4.3. Inverse query processing 🧩
name servers that support inverse queries can support these operations through exhaustive searches of their databases, but this becomes impractical as the size of the database increases. an alternative approach is to invert the database according to the search key.
for name servers that support multiple zones and a large amount of data, the recommended approach is separate inversions for each zone. when a particular zone is changed during a refresh, only its inversions need to be redone 🔁
support for transfer of this type of inversion may be included in future versions of the domain system, but is not supported in this version.
6.5. Completion queries and responses 🫶
the optional completion services described in RFC-882 and RFC-883 have been deleted. redesigned services may become available in the future ⭐
7. RESOLVER IMPLEMENTATION 👑
the top levels of the recommended resolver algorithm are discussed in [RFC-1034]. this section discusses implementation details assuming the database structure suggested in the name server implementation section of this memo 💜
7.1. Transforming a user request into a query 💖
the first step a resolver takes is to transform the client's request, stated in a format suitable to the local OS, into a search specification for RRs at a specific name which match a specific QTYPE and QCLASS. where possible, the QTYPE and QCLASS should correspond to a single type and a single class, because this makes the use of cached data much simpler. the reason for this is that the presence of data of one type in a cache doesn't confirm the existence or non-existence of data of other types, hence the only way to be sure is to consult an authoritative source. if QCLASS=* is used, then authoritative answers won't be available 🙅♀️
since a resolver must be able to multiplex multiple requests if it is to perform its function efficiently, each pending request is usually represented in some block of state information. this state block will typically contain:
- A timestamp indicating the time the request began. The timestamp is used to decide whether RRs in the database can be used or are out of date. This timestamp uses the absolute time format previously discussed for RR storage in zones and caches. Note that when an RRs TTL indicates a relative time, the RR must be timely, since it is part of a zone. When the RR has an absolute time, it is part of a cache, and the TTL of the RR is compared against the timestamp for the start of the request.
Note that using the timestamp is superior to using a current time, since it allows RRs with TTLs of zero to be entered in the cache in the usual manner, but still used by the current request, even after intervals of many seconds due to system load, query retransmission timeouts, etc. ⏰
- Some sort of parameters to limit the amount of work which will be performed for this request.
The amount of work which a resolver will do in response to a client request must be limited to guard against errors in the database, such as circular CNAME references, and operational problems, such as network partition which prevents the resolver from accessing the name servers it needs. While local limits on the number of times a resolver will retransmit a particular query to a particular name server address are essential, the resolver should have a global per-request counter to limit work on a single request. The counter should be set to some initial value and decremented whenever the resolver performs any action (retransmission timeout, retransmission, etc.) If the counter passes zero, the request is terminated with a temporary error.
Note that if the resolver structure allows one request to start others in parallel, such as when the need to access a name server for one request causes a parallel resolve for the name server's addresses, the spawned request should be started with a lower counter. This prevents circular references in the database from starting a chain reaction of resolver activity. 🛑
- The SLIST data structure discussed in [RFC-1034].
This structure keeps track of the state of a request if it must wait for answers from foreign name servers 📋
7.2. Sending the queries 🦋
As described in [RFC-1034], the basic task of the resolver is to formulate a query which will answer the client's request and direct that query to name servers which can provide the information. The resolver will usually only have very strong hints about which servers to ask, in the form of NS RRs, and may have to revise the query, in response to CNAMEs, or revise the set of name servers the resolver is asking, in response to delegation responses which point the resolver to name servers closer to the desired information. In addition to the information requested by the client, the resolver may have to call upon its own services to determine the address of name servers it wishes to contact 📞
in any case, the model used in this memo assumes that the resolver is multiplexing attention between multiple requests, some from the client, and some internally generated. each request is represented by some state information, and the desired behavior is that the resolver transmit queries to name servers in a way that maximizes the probability that the request is answered, minimizes the time that the request takes, and avoids excessive transmissions. the key algorithm uses the state information of the request to select the next name server address to
...ugh okay where was I, bestie 🫶 the same step also works out a timeout, and that timeout is what tells the resolver to take its next action if no response shows up ✨ That next action is usually a transmission to some other server, but it could also be a temporary error sent back to the client 🥺
The resolver always starts with a list of server names to query, called SLIST 🎀 This list is every NS RR for the closest ancestor zone the resolver knows about. To avoid startup problems, it should have a set of default servers to ask if it doesn't have any appropriate NS RRs yet 💅 Then it adds all the known addresses for those name servers to SLIST, and it may start parallel requests to find the addresses whenever it has a name for a name server but no addresses for it 🦋
To finish setting up SLIST, the resolver attaches whatever history information it has to each address in SLIST 📊 This is usually some kind of weighted averages for the address's response time, plus its batting average (basically how often that address responded at all to the request) 🧢 Keep this info per address, not per name server, because one server's response time and batting average can vary a lot from address to address 😭 It's also specific to a resolver address / server address pair, so a resolver with several addresses might want a separate history for each one ✨ Addresses with no history are the tricky part. In that case, an expected round trip time of 5-10 seconds should be treated as the worst case, with lower estimates for the same local network, and so on 🌸
Also, every time a delegation gets followed, the resolver reinitializes SLIST from scratch 🔄
All that history gives a partial ranking of the available name server addresses 📈 Each time an address gets chosen, its state changes so it won't be picked again until all the others have been tried 🙅♀️ The timeout for each transmission should be 50-100% greater than the average predicted value, so there's room for variance in the response 🕰️
Some fine points, the little details that matter:
- The resolver may run into a situation where none of the addresses are available for any of the name servers named in SLIST, and the servers in the list are exactly the ones that would normally be used to look up their own addresses 😵 This usually happens when the glue address RRs have a smaller TTL than the
NSRRs marking the delegation, or when the resolver caches the result of anNSsearch 🙃 The resolver should detect this and restart the search at the next ancestor zone, or alternatively at the root. - If a resolver gets a server error or other bizarre response from a name server, it should remove that server from SLIST, and may want to schedule an immediate transmission to the next candidate server address 🚫
7.3. Processing responses 📬
The first step in processing arriving response datagrams is to parse the response. This procedure should include:
- Check the header for reasonableness. Discard datagrams which are queries when responses are expected.
- Parse the sections of the message, and make sure all RRs are correctly formatted.
- As an optional step, check the TTLs of arriving data for RRs with excessively long TTLs. If an RR has an excessively long TTL, say greater than 1 week, either discard the whole response, or limit all TTLs in the response to 1 week ⏳
The next step is to match the response to a current resolver request. The recommended strategy is a preliminary match using the ID field in the domain header, then verifying that the question section matches the info you currently want 🔑 That means the transmission algorithm has to devote several bits of the ID field to a request identifier of some sort. There are a few fine points here:
- Some name servers send their responses from a different address than the one the query was sent to. So a resolver can't rely on a response coming from the same address it sent the query to 😤 This name server bug is typically encountered in UNIX systems.
- If the resolver retransmits a particular request to a name server, it can use a response from any of the transmissions. But if it's using the response to sample the round trip time to that name server, it must be able to determine which transmission matches the response (and keep transmission times for each outgoing message), or only calculate round trip times based on initial transmissions ⏱️
- A name server will occasionally not have a current copy of a zone it should have according to some
NSRRs. The resolver should simply remove that name server from the current SLIST and keep going 🙆
7.4. Using the cache 🧁
In general, we expect a resolver to cache all the data it receives in responses, since it may be useful for answering future client requests 💖 But there are several types of data that should not be cached:
- When several RRs of the same type are available for a particular owner name, the resolver should either cache them all or none at all. When a response is truncated and the resolver doesn't know whether it has a complete set, it should not cache a possibly partial set of RRs 🫠
- Cached data should never be used in preference to authoritative data, so if caching would cause that to happen, the data should not be cached 👑
- The results of an inverse query should not be cached 🙅
- The results of standard queries where the QNAME contains
"*"labels, if the data might be used to construct wildcards. The reason is that the cache doesn't necessarily contain the existing RRs or zone boundary information needed to restrict the application of wildcard RRs 🃏 - RR data in responses of dubious reliability. When a resolver receives unsolicited responses or RR data other than what it requested, it should discard it without caching it. The basic takeaway is that all sanity checks on a packet should be performed before any of it is cached 🧼
Along similar lines, when a resolver has a set of RRs for some name in a response and wants to cache them, it should check its cache for RRs that already exist. Depending on the circumstances, either the data in the response or the data in the cache is preferred, but the two should never be combined 🤝 If the data in the response is authoritative data from the answer section, it is always preferred 💅
8. MAIL SUPPORT 💌
The domain system defines a standard for mapping mailboxes into domain names, plus two methods for using that mailbox info to work out mail routing. The first is called mail exchange binding, and the other is mailbox binding. The mailbox encoding standard and mail exchange binding are part of the DNS official protocol, and they're the recommended method for mail routing in the Internet ✉️ Mailbox binding is an experimental feature that's still under development and subject to change 🧪
The mailbox encoding standard assumes a mailbox name of the form <local-part>@<mail-domain>. The syntax allowed in each of these parts varies a lot between mail internets, but the preferred syntax for the ARPA Internet is given in [RFC-822] 📧
The DNS encodes the <local-part> as a single label, and encodes the <mail-domain> as a domain name. The single label from the <local-part> gets prefaced to the domain name from <mail-domain> to form the domain name for the mailbox. So the mailbox HOSTMASTER@SRI-NIC.ARPA maps to the domain name HOSTMASTER.SRI-NIC.ARPA. If the <local-part> has dots or other special characters, its representation in a master file needs backslash quoting so the domain name gets encoded properly. For example, the mailbox Action.domains@ISI.EDU would be represented as Action\.domains.ISI.EDU 🫶
8.1. Mail exchange binding 📮
Mail exchange binding uses the <mail-domain> part of a mailbox specification to decide where mail should go. The <local-part> isn't even consulted 🙈 [RFC-974] specifies this method in detail, and should be consulted before attempting to use mail exchange support.
One of the advantages of this method is that it decouples mail destination naming from the hosts used to support mail service, at the cost of another layer of indirection in the lookup function. However, the additional layer should eliminate the need for complicated "%", "!", etc. encodings in <local-part> 💖
The essence of the method: <mail-domain> is used as a domain name to locate MX RRs, which list hosts willing to accept mail for <mail-domain>, together with preference values that rank the hosts according to an order set by the administrators for <mail-domain> 🏆
In this memo, the <mail-domain> ISI.EDU is used in examples, together with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name VENERA.ISI.EDU and VAXA.ISI.EDU, and A type queries can find the host addresses 🌈
8.2. Mailbox binding (Experimental) 🎀
In mailbox binding, the mailer uses the entire mail destination specification to construct a domain name. The encoded domain name for the mailbox is used as the QNAME field in a QTYPE=MAILB query 📬
Several outcomes are possible for this query:
- The query can return a name error, which means the mailbox doesn't exist as a domain name.
In the long term, this would indicate that the specified mailbox doesn't exist. However, until mailbox binding is universal, this error condition should be interpreted to mean that the organization identified by the global part does not support mailbox binding. The appropriate procedure is to revert to exchange binding at this point 🔁
- The query can return a Mail Rename (
MR) RR.
The MR RR carries a new mailbox specification in its RDATA field. The mailer should replace the old mailbox with the new one and retry the operation ✏️
- The query can return a
MBRR.
The MB RR carries a domain name for a host in its RDATA field. The mailer should deliver the message to that host via whatever protocol is applicable, e.g., b,SMTP 📨
- The query can return one or more Mail Group (
MG) RRs.
This condition means that the mailbox was actually a mailing list or mail group, rather than a single mailbox. Each MG RR has a RDATA field that identifies a mailbox that is a member of the group. The mailer should deliver a copy of the message to each member 👯
- The query can return a
MBRR as well as one or moreMGRRs.
This condition means the mailbox was actually a mailing list. The mailer can either deliver the message to the host specified by the MB RR, which will in turn do the delivery to all members, or the mailer can use the MG RRs to do the expansion itself 🧠
In any of these cases, the response may include a Mail Information (MINFO) RR. This RR is usually associated with a mail group, but it is legal with a MB too. The MINFO RR identifies two mailboxes. One of these identifies a responsible person for the original mailbox name, and this mailbox should be used for requests to be added to a mail group, etc. The second mailbox name in the MINFO RR identifies a mailbox that should receive error messages for mail failures. This is particularly appropriate for mailing lists when errors in member names should be
reported to a person other than the one who sends a message to the list, bestie 💌 so the error pings can go to someone who isn't the sender 🙈
New fields may be added to this RR in the future 🔮 so keep your eyes peeled, the MINFO RR might get some new friends later ✨
9. REFERENCES and BIBLIOGRAPHY ✨
Okay, the reading list 📚 these are all the RFCs, papers and old notes this spec leaned on, iykyk 💅 I kept every entry exactly as written so you can go hunt them down yourself 🦋
[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
Technical Plan - Name Service, April 1987, version 1.9.
Describes the fundamentals of the Hesiod name service.
[IEN-116] J. Postel, "Internet Name Server", IEN-116,
USC/Information Sciences Institute, August 1979.
A name service obsoleted by the Domain Name System, but
still in use.
[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
Communications of the ACM, October 1986, volume 29, number
10.
[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
Information Center, SRI International, December 1977.
[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
USC/Information Sciences Institute, August 1980.
[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
USC/Information Sciences Institute, September 1981.
[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
September 1981.
Suggests introduction of a hierarchy in place of a flat
name space for the Internet.
[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
USC/Information Sciences Institute, February 1982.
[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
Internet Host Table Specification", RFC-810, Network
Information Center, SRI International, March 1982.
Obsolete. See RFC-952.
[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
Server", RFC-811, Network Information Center, SRI
International, March 1982.
Obsolete. See RFC-953.
[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
Network Information Center, SRI International, March
1982.
[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
Internet User Applications", RFC-819, Network
Information Center, SRI International, August 1982.
Early thoughts on the design of the domain system.
Current implementation is completely different.
[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
USC/Information Sciences Institute, August 1980.
[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
RFC-830, Network Information Center, SRI International,
October 1982.
Early thoughts on the design of the domain system.
Current implementation is completely different.
[RFC-882] P. Mockapetris, "Domain names - Concepts and
Facilities," RFC-882, USC/Information Sciences
Institute, November 1983.
Superceeded by this memo.
[RFC-883] P. Mockapetris, "Domain names - Implementation and
Specification," RFC-883, USC/Information Sciences
Institute, November 1983.
Superceeded by this memo.
[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
RFC-920, USC/Information Sciences Institute,
October 1984.
Explains the naming scheme for top level domains.
[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
Table Specification", RFC-952, SRI, October 1985.
Specifies the format of HOSTS.TXT, the host/address
table replaced by the DNS.
[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
RFC-953, SRI, October 1985.
This RFC contains the official specification of the
hostname server protocol, which is obsoleted by the DNS.
This TCP based protocol accesses information stored in
the RFC-952 format, and is used to obtain copies of the
host table.
[RFC-973] P. Mockapetris, "Domain System Changes and
Observations", RFC-973, USC/Information Sciences
Institute, January 1986.
Describes changes to RFC-882 and RFC-883 and reasons for
them.
[RFC-974] C. Partridge, "Mail routing and the domain system",
RFC-974, CSNET CIC BBN Labs, January 1986.
Describes the transition from HOSTS.TXT based mail
addressing to the more powerful MX system used with the
domain system.
[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Concepts and Methods",
RFC-1001, March 1987.
This RFC and RFC-1002 are a preliminary design for
NETBIOS on top of TCP/IP which proposes to base NetBIOS
name service on top of the DNS.
[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Detailed
Specifications", RFC-1002, March 1987.
[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
USC/Information Sciences Institute, May 1987.
Contains socket numbers and mnemonics for host names,
operating systems, etc.
[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
November 1987.
Describes a plan for converting the MILNET to the DNS.
[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
Administrators", RFC-1032, November 1987.
Describes the registration policies used by the NIC to
administer the top level domains and delegate subzones.
[RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
RFC-1033, November 1987.
A cookbook for domain administrators.
[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
Name Server", Computer Networks, vol 6, nr 3, July 1982.
Describes a name service for CSNET which is independent
from the DNS and DNS use in the CSNET.Index 🎀
And finally the index 🧚 every term, keyword and record type, with the spots where it pops up 🌸
* 13
; 33, 35
<character-string> 35
<domain-name> 34
@ 35
\ 35
A 12
Byte order 8
CH 13
Character case 9
CLASS 11
CNAME 12
Completion 42
CS 13
Hesiod 13
HINFO 12
HS 13
IN 13
IN-ADDR.ARPA domain 22
Inverse queries 40
Mailbox names 47
MB 12
MD 12
MF 12
MG 12
MINFO 12
MINIMUM 20
MR 12
MX 12
NS 12
NULL 12
Port numbers 32
Primary server 5
PTR 12, 18
QCLASS 13
QTYPE 12
RDATA 12
RDLENGTH 11
Secondary server 5
SOA 12
Stub resolvers 7
TCP 32
TXT 12
TYPE 11
UDP 32
WKS 12That's the whole spec, bestie 👑🌈💖
📦 where this page comes from
- ietf: rfc1035 1987-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms