RFC 882
Domain names: Concepts and facilities
DOMAIN NAMES - CONCEPTS and FACILITIES 🎀
Okay bestie, let's look at RFC 882 📜✨ It was written by P. Mockapetris at ISI and dated November 1983. It's filed under the Network Working Group, and this document is the concepts-and-facilities one. 💅
+-----------------------------------------------------+
| |
| This RFC introduces domain style names, their use |
| for ARPA Internet mail and host address support, |
| and the protocols and servers used to implement |
| domain name facilities. |
| |
| This memo describes the conceptual framework of the |
| domain system and some uses, but it omits many |
| uses, fields, and implementation details. A |
| complete specification of formats, timeouts, etc. |
| is presented in RFC 883, "Domain Names - |
| Implementation and Specification". That RFC |
| assumes that the reader is familiar with the |
| concepts discussed in this memo. |
| |
+-----------------------------------------------------+So the box up there is the vibe check 🦋 This RFC introduces domain-style names, how they're used for ARPA Internet mail and host address support, and the protocols and servers that make it all work. It's the concept tour, not the full rulebook. It skips a bunch of uses, fields, and implementation details. If you want the complete specs for formats, timeouts, and everything else, that's RFC 883, "Domain Names - Implementation and Specification." And heads up: RFC 883 assumes you already know the concepts in this memo, so read this one first 🧚
INTRODUCTION ✨
The need for domain names 🌸
Okay so, as applications grow to span multiple hosts, then networks, and finally whole internets, they also have to span multiple administrative boundaries and different ways of doing things (protocols, data formats, etc). The number of resources (like mailboxes), the number of places those resources live, and how wildly different the whole environment is cause serious problems when we want consistent ways to reference resources that are similar but scattered all over. It's giving chaos 😭
The ARPA Internet shows the size problems super clearly. It's already big and it's probably going to get way bigger. Mapping host names (like USC-ISIF) to ARPA Internet addresses (like 10.2.0.52) is starting to stress the existing mechanisms. Right now, hosts in the ARPA Internet get registered with the Network Information Center (NIC) and listed in one global table (available as the file <NETINFO>HOSTS.TXT on the SRI-NIC host) [1]. That table is getting huge, and how often it has to be updated is near the limit of what anyone can manage 🙈 What we need is a distributed database that does the same job, so we dodge all the problems that come with one centralized database 💜
Mail is even messier, ngl. Mail system implementers figured out a long time ago that you can't centralize mailbox names, and then they built this increasingly big and irregular pile of methods for finding where a mailbox lives. Some of those methods stick routes and forwarding hosts right into the mail destination address. That forces mail users to memorize multiple address formats, know what each forwarder can do, and use ad hoc tricks to pass address specs through middlemen. Not it 💀
These problems share some common traits, and those traits hint at what any solution should look like 🍓
- The basic need is a consistent name space that gets used for referring to resources. To avoid the problems caused by ad hoc encodings, names should not contain addresses, routes, or similar information as part of the name.
- The sheer size of the database and how often it updates suggest it must be maintained in a distributed way, with local caching to improve performance. Approaches that try to collect a consistent copy of the entire database get more and more expensive and difficult, so they should be avoided. The same principle applies to the structure of the name space, especially the mechanisms for creating and deleting names. Those should be distributed too.
- Implementing a facility like this is expensive, so it has to be generally useful and not restricted to a single application. We should be able to use names to retrieve host addresses, mailbox data, and other information that hasn't been figured out yet ✨
- Because we want the name space to be useful across dissimilar networks, it's unlikely that every user of domain names will agree on the set of resources, or the resource information, that names will be used to retrieve. So names refer to a set of resources, and queries contain resource identifiers. The only standard types of information we expect to see throughout the name space are the structuring information for the name space itself, and resources that are described using domain names and no nonstandard data 🎀
- We also want name server transactions to be independent of the communications system that carries them. Some systems may want to use datagrams for simple queries and responses, and only set up virtual circuits for transactions that need reliability (e.g. database updates, long transactions). Other systems will use virtual circuits exclusively 🦋
Elements of the solution 💅
The proposed solution has three major components, and honestly they're the whole main character lineup 👑
- The DOMAIN NAME SPACE is a specification for a tree-structured name space. Conceptually, each node and leaf of the domain name space tree names a set of information, and query operations are attempts to extract specific types of information from a particular set. A query names the domain name of interest and describes the type of resource information that's wanted. For example, the ARPA Internet uses some of its domain names to identify hosts, and queries for address resources return ARPA Internet host addresses. However, to preserve the generality of the domain mechanism, domain names are not required to have a one-to-one correspondence with host names, host addresses, or any other type of information.
- NAME SERVERS are server programs that hold information about the domain tree's structure and set information. A name server may cache structure or set information about any part of the domain tree, but in general a particular name server has complete information about a subset of the domain space, plus pointers to other name servers that can lead to information from any part of the domain tree. Name servers know which parts of the domain tree they have complete information for. Those parts are called ZONEs, and a name server is an AUTHORITY for these parts of the name space 👑
- RESOLVERS are programs that extract information from name servers in response to user requests. Resolvers must be able to access at least one name server and use that server's information to answer a query directly, or pursue the query using referrals to other name servers. A resolver will typically be a system routine that's directly accessible to user programs, so no protocol is necessary between the resolver and the user program ✨
These three components roughly line up with the three layers or views of the domain system 🌈
- From the user's point of view, the domain system is accessed through simple procedure or OS calls to resolvers. The domain space consists of a single tree, and the user can request information from any section of the tree.
- From the resolver's point of view, the domain system is made up of an unknown number of name servers. Each name server has one or more pieces of the whole domain tree's data, but the resolver views each of these databases as essentially static.
- From a name server's point of view, the domain system consists of separate sets of local information called zones. The name server has local copies of some of the zones. The name server must periodically refresh its zones from master copies in local files or foreign name servers. It must also concurrently process queries that arrive from resolvers using the local zones 🫶
These layers blur a little bit in the name of performance. For example, resolvers on the same machine as a name server may share a database and may also introduce foreign information for use in later queries. This cached information is treated differently from the authoritative data in zones.
Database model 🧚
The organization of the domain system comes from some assumptions about the needs and usage patterns of its user community. It's designed to avoid a lot of the complicated problems found in general-purpose database systems 💖
The assumptions are:
- The size of the total database will start out proportional to the number of hosts using the system, but will eventually grow to be proportional to the number of users on those hosts, as mailboxes and other information get added to the domain system.
- Most of the data in the system will change very slowly (e.g., mailbox bindings, host addresses), but the system should be able to deal with subsets that change more rapidly (on the order of minutes).
- The administrative boundaries used to distribute responsibility for the database will usually correspond to organizations that have one or more hosts. Each organization responsible for a particular set of domains will provide redundant name servers, either on the organization's own hosts or on other hosts that the organization arranges to use 🌸
- Clients of the domain system should be able to identify trusted name servers they prefer to use before accepting referrals to name servers outside of this "trusted" set.
- Access to information is more critical than instantaneous updates or guarantees of consistency. So the update process lets updates percolate out through the users of the domain system, rather than guaranteeing that all copies are updated at the same time. When updates are unavailable because of network or host failure, the usual course is to believe the old information while continuing efforts to update it. The general model is that copies are distributed with timeouts for refreshing. The distributor sets the timeout value, and the recipient of the distribution is responsible for performing the refresh. In special situations, very short intervals can be specified, or the owner can prohibit copies 🙈
- Some users will want to access the database via datagrams, while others will prefer virtual circuits. The domain system is designed so that simple queries and responses can use either style, although refreshing operations need the reliability of virtual circuits. The same overall message format is used for all communication. The domain system doesn't assume any special properties of the communications system, so it could be used with any datagram or virtual circuit protocol 🦋
In any system that has a distributed database, a name server can get a query that only some other server can answer. 🤔 There are two main ways to handle that. In "recursive", the first server goes off and chases the query for the client. In "iterative", the server points the client to another server and lets the client do the chasing. 🦋 Both have pros and cons, but the iterative approach is preferred for the datagram style of access. The domain system requires implementing the iterative approach, and it allows the recursive one as an option. The optional recursive style is covered in [14], and we're skipping it for the rest of this memo. 💅
The domain system assumes all the data starts out in master files scattered across the hosts that use it. Local system administrators keep those files up to date. ✨ Master files are plain text files that a local name server reads, which makes them available to domain system users. A standard format for these files is given in [14].
The standard format means these files can be shared between hosts (over FTP, mail, or some other method) 📬. This is super handy when an organization wants a domain but doesn't want to run a name server. They can keep their master files locally in a text editor, send them to a foreign host that runs a name server, and then ask that server's administrator to get the files loaded. 🌸
Each host's name servers and resolvers are set up by a local system administrator. 🎀 For a name server, that config includes which local master files to use, plus instructions on which non-local master files should be loaded from foreign servers. The name server uses those master files or copies to load its zones. For resolvers, the config says which name servers should be the primary sources of information.
The domain system defines how to access the data and how referrals to other name servers work. It also defines how to cache retrieved data and how to periodically refresh data that the system administrator has defined. 🔥
The system administrators provide:
- The definition of zone boundaries
- Master files of data
- Updates to master files
- Statements of the refresh policies desired
The domain system provides:
- Standard formats for resource data
- Standard methods for querying the database
- Standard methods for name servers to refresh local data from foreign name servers
DOMAIN NAME SPACE 🌳
Name space specifications and terminology
Okay, bestie, picture a tree. 🌲 The domain name space is a tree structure. Every node and every leaf on the tree corresponds to a resource set (which might be empty). Each node and leaf also has a label. Labels are NOT guaranteed to be unique, with one exception: the root node, which has a null label. The domain name of a node or leaf is the path from the root of the tree down to that node or leaf. By convention, the labels in a domain name are read left to right, from the most specific (lowest) to the least specific (highest). 💜
Internally, programs that handle domain names store them as sequences of labels, where each label is a length octet followed by an octet string. Since every domain name ends at the root, and the root has a null string for its label, these internal representations can use a length byte of zero to end a domain name. When domain names get printed, the labels are separated by dots (.). The root label and its dot are left out of printed domain names, but the root can be named by a null domain name (" " in this memo). 🙈
To keep implementations simple, the total number of octets used for label octets and label lengths is limited to 255. So a printed domain name can be up to 254 characters. 📏
There is a special label that matches any other label: the asterisk *. An asterisk matches a single label. So *.ARPA matches FOO.ARPA, but does not match FOO.BAR.ARPA. The asterisk is mainly used to create default resource records at the boundary between protocol families, and it needs prudence when you use it. ⚠️
A domain is identified by a domain name, and it consists of the part of the domain name space that is at or below the domain name that specifies it. A domain is a subdomain of another domain if it is contained within that domain. You can test this by checking whether the subdomain's name has the containing domain's name as its right part. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". 🧁
This tree structure is meant to mirror the administrative organization and the delegation of authority. In principle, each node or leaf on the tree can create new subdomains ad infinitum. In practice, the administrator of the name servers that manage the domain space and resource data can limit that delegation. 🦄
The following figure shows an example of a domain name space. 👀
|
+------------------+------------------+
| | |
COLORS FLAVORS TRUTH
| |
+-----+-----+ |
| | | NATURAL
RED BLUE GREEN |
|
+---------------+---------------+
| | |
CHOCOLATE VANILLA STRAWBERRYIn this example, the root domain has three immediate subdomains: COLORS, FLAVORS, and TRUTH. The FLAVORS domain has one immediate subdomain, NATURAL.FLAVORS. All of the leaves are domains too. This domain tree has the names " " (the root), COLORS, RED.COLORS, BLUE.COLORS, GREEN.COLORS, FLAVORS, NATURAL.FLAVORS, CHOCOLATE.NATURAL.FLAVORS, VANILLA.NATURAL.FLAVORS, STRAWBERRY.NATURAL.FLAVORS, and TRUTH. 🍓 If we wanted to add a new domain called ARTIFICIAL under FLAVORS, FLAVORS would typically be the administrative entity that decides. If we wanted to create CHIP and MOCHA names under CHOCOLATE, then CHOCOLATE.NATURAL.FLAVORS would typically be the right administrative entity. 🍫
Resource set information
A domain name identifies a set of resource information. The resource information tied to a particular name is made up of separate resource records (RRs). 💖
Each resource record has these major components:
- The domain name that identifies the resource set holding this record, which makes it the "owner" of the information. For example, an RR that specifies a host address has a domain name that names the host with that address. So F.ISI.ARPA might be the owner of an RR that specifies an address field of 10.2.0.52. Since name servers usually store their resource information in tree structures that mirror the organization of the domain space, this information can often be stored implicitly in the database. It is always included in each resource record carried in a message, though. 🏠
- Other information used to manage the RR, such as length fields, timeouts, and so on. This information is left out of much of this memo, but it's discussed in
[14]. ⏱️ - A resource type field that specifies the type of the resource in this record. Types refer to abstract resources, like host addresses or mail delivery agents. The type field is two octets long and uses an encoding that is standard throughout the domain name system. 🎫
- A class field that identifies the format of the resource data, such as the ARPA Internet format (IN) or the Computer Science Network format (CSNET), for certain RR types (like address data). Note that while the class can separate different protocol families, networks, and so on, it doesn't do that in every case. For example, the IN class uses 32 bit IP addresses exclusively, but the CSNET class uses 32 bit IP addresses, X.25 addresses, and phone numbers. So the class field should be used as a guide for interpreting the resource data. The class field is two octets long and uses an encoding that is standard throughout the domain name system. 🌈
- Resource data that describes the resource. The format of this data can be determined from the type and class fields, but it always starts with a two octet length field. That length lets a name server or resolver figure out where the resource data begins and ends in any transaction, even if it can't "understand" the data itself. So name servers and resolvers can hold and pass on records they can't interpret. The format of the internal data is only restricted by the maximum length of 65535 octets. For example, the host address record might specify a fixed 32 bit number for one class, and a variable length list of addresses in another class. 🧩
While the class field effectively splits the resource data in the domain name system into separate parallel sections by class, services can span class boundaries if they use compatible resource data formats. For example, the domain name system uses compatible formats for structure information, and the mail data separates mail agent identification from the details of how to contact the agent (for example, host addresses). 💌
This memo uses the following types in its examples:
A- the host address associated with the domain nameMF- identifies a mail forwarder for the domainMD- identifies a mail destination for the domainNS- the authoritative name server for the domainSOA- identifies the start of a zone of authorityCNAME- identifies the canonical name of an alias
This memo uses the following classes in its examples:
IN- the ARPA Internet systemCS- the CSNET system
The first type of resource record holds a host name to host address binding. Its fields are: 🦋
+--------+--------+--------+--------------//----------------------+
|<owner> | A | <class>| <class specific address>information |
+--------+--------+--------+--------------//----------------------+The content of the class specific information changes based on the value in the CLASS field. For the ARPA Internet, it's the 32 bit ARPA Internet address of the host. For CSNET, it might be the phone number of the host. 📞 For example, F.ISI.ARPA might have two A records of the form:
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| A | IN | 10.2.0.52 |
+----------+--------+--------+----------------------------+
and
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| A | CS | 213-822-2112 |
+----------+--------+--------+----------------------------+Okay so the data format for type A is class dependent, bestie 🎀 The internet address and phone number up there are just for illustration, so don't copy them as the real deal 💅 The actual formats live in [14]. For example, CS class data for type A records could literally be a list of Internet addresses, phone numbers, and TELENET addresses. Wild 😭🌈
The mail forwarder (MF) and mail delivery (MD) records look like this 💌
+--------+--------+--------+----------------------------+
|<owner> | MD/MF | <class>| <domain name> |
+--------+--------+--------+----------------------------+The <domain name> field is the domain name of the host that will handle mail. Lowkey important: this name can be totally different from the domain name that names the resource record 👀 For example, F.ISI.ARPA might have two records like these:
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| MD | IN | F.ISI.ARPA |
+----------+--------+--------+----------------------------+
and
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| MF | IN | B.ISI.ARPA |
+----------+--------+--------+----------------------------+So these records mean mail for F.ISI.ARPA can either be delivered to the host F.ISI.ARPA, or forwarded to B.ISI.ARPA, which takes responsibility for its eventual delivery 📬✨ In principle, you'd need an extra name lookup to map the host's domain name to its address. In practice though, that info is usually sent back in the response to the mail query, so it's giving efficiency 🧚
The SOA and NS record types are the ones that define limits of authority 🦋 The domain name in the owner field of a SOA record is the start of a zone. The domain name in the owner field of an NS record marks a point in the name space where authority has been delegated, which means it marks the zone boundary. The only exception is when a name server delegates authority to itself. Otherwise, the SOA sets the top limit of authority, and NS records define the first name outside of a zone. Both of these have a standard format across the whole name space:
+----------+--------+--------+-----------------------------+
| <owner> | SOA | <class>| <domain name, etc> |
+----------+--------+--------+-----------------------------++----------+--------+--------+-----------------------------+
| <owner> | NS | <class>| <domain name> |
+----------+--------+--------+-----------------------------+The SOA record marks the start of a zone when it's present in a database. The NS record does two jobs: it marks the end of a zone started by an SOA (if a higher SOA is present), and it points to a name server that has a copy of the zone named in the <owner> field of the NS record 🌸
The <domain name, etc> part of the SOA record tells you the original source of the information in the zone, plus other info name servers use to organize their activities. SOA records are never cached, because otherwise they would create false zones 🙈 They can only be created during special name server maintenance operations.
The NS record says that a name server, which is authoritative for records of the given CLASS, can be found at <domain name> 💜
Queries
Queries to a name server must include a domain name that identifies the target resource set (QNAME), plus the type and class of the desired resource records. The type and class fields in a query can include any of the matching type and class fields defined for resource records. On top of that, the query type (QTYPE) and query class (QCLASS) fields can contain special values that match more than one of the matching fields in RRs 🔥
For example, the QTYPE field may contain:
MAILA - matches all mail agent RRs (e.g. MD and MF).
- - matches any RR type.
The QCLASS field may contain:
- - matches any RR class.
Using the query domain name, QTYPE, and QCLASS, the name server looks for matching RRs. Besides the relevant records, the name server may also return RRs that point toward a name server that has the desired information, or RRs that are expected to be useful in interpreting the relevant RRs 👑 For example, a name server that doesn't have the requested information may know a name server that does. And a name server that returns a domain name in a relevant RR may also return the RR that binds that domain name to an address.
Heads up, bestie 🚨 TheQCLASS=*construct needs special interpretation when it comes to authority. A name server may not know every class available in the domain system, so it can never know whether it's authoritative for all classes. That means responses toQCLASS=*queries can never be authoritative. Not me getting this wrong 💀
Example space
For the sake of explanation, the following name space is used for the rest of this memo 🌈
|
+------------------+------------------+
| | |
DDN ARPA CSNET
| | |
+-----+-----+ | +-----+-----+
| | | | | |
JCS ARMY NAVY | UDEL UCI
|
+--------+---------------+---------------+--------+
| | | | |
DTI MIT ISI UDEL NBS
| |
+---+---+ +---+---+
| | | | |
DMS AI A B FNAME SERVERS 🧚
Introduction
Name servers store a distributed database. It holds the structure of the domain name space, the resource sets tied to domain names, and other info used to coordinate actions between name servers 💖
In general, a name server is an authority for all or part of a particular domain. The region this authority covers is called a zone. A name server might be responsible for no authoritative data, so it has no zones, or it might have several zones. When a name server has multiple zones, those zones may have no common borders, or they may be contiguous ✨
Administrators should not construct overlapping zones, and name servers must defend against overlapping zones. Still, overlapping is treated as a non-fatal flaw in the database, so the measures taken to protect against it are left out for the rest of this memo. A detailed discussion can be found in [14] 🫶
When a name server gets a query for a domain name it has authority over, it returns the desired resource information, or an indication that the domain name or resource doesn't exist. If a name server gets a query for a domain name outside its authority, it might have the desired information, but it will also return a response that points toward an authoritative name server. If a name server isn't an authority for a query, it can never return a negative response 🙅♀️
There's no requirement that a domain's name server lives on a host with a name in the same domain, although that's usually the case. There's also no restriction on how many name servers can have authority over a particular domain. Most domains will have redundant authoritative name servers 🎀 The assumption is that different authoritative copies are identical, even though inconsistencies are possible while updates are being made.
Name server functions are designed to allow for very simple implementations. The simplest name server has a static set of information and uses datagrams to receive queries and return responses 🍓
More sophisticated name server implementations can improve performance for their clients by caching information from other domains. There are a bunch of ways to get this info, but the normal method is to store the information a resolver acquires when it consults other name servers. In a sophisticated host, the resolver and name server coordinate their actions and use a shared database. This cooperation requires a time-to-live (TTL) field in all cached resource records. Caching is discussed in the resolver section of this memo. This section is devoted to the actions of name servers that don't cache 🌸
To free simple name servers from managing these timeouts, simple name servers should only contain resource records that are expected to stay constant over very long periods, or resource records for which the name server is an authority. In the discussion that follows, the TTL field is assumed to be stored in the resource record, but it's left out of descriptions of databases and responses for clarity 💅
Authority and administrative control of domains
We want every node to have the potential to delegate privileges for name space management. But we don't want delegation to be required 🦋
So we introduce the concept of authority. Authority is vested in name servers. A name server has authority over all of its domain until it delegates authority for a subdomain to some other name server 👑
Any administrative entity that wants its own domain must provide a name server, and have that server accepted by the parent name server (the name server with authority over the place in the domain name space that will hold the new domain). Acceptance can be at the discretion of parent name servers. The following criteria are used by the root, and are recommended to all name servers, because they're responsible for their children's actions 🔥
- It must register with the parent administrator of domains.
- It must identify a responsible person.
- It must provide redundant name servers.
The domain name must be registered with the administrator to avoid name conflicts and to make the domain-related information available to other domains. The central administrator may have further requirements, and a domain isn't registered until the central administrator agrees that all requirements are met 🌈
There MUST be a responsible person associated with each domain 💖 This is the contact point for questions about the domain, the one who verifies and updates the domain-related info, and the one who sorts out any problems (like protocol violations) with hosts in the domain. Honestly, they're the domain's main character 👑
The domain MUST provide redundant (i.e., two or more) name servers to provide the name to address resolution service ✨ These name servers MUST be accessible from outside the domain (as well as inside) and MUST resolve names for at least all the hosts in the domain. Redundancy is the whole vibe here 🫶
Once the central administrator is satisfied, he will communicate the existence to the appropriate administrators of other domains so that they can incorporate NS records for the new name server into their databases 📬
Name server logic 🧠
The processing steps a name server takes to respond to a query are conceptually simple, although implementations MAY have internal databases that are quite complex 🌸
For purposes of explanation, we assume that the query consists of a type QTYPE, a class QCLASS, and a domain name QNAME. We also assume that the name server stores its RRs in sets, where each set has all of the RRs for a particular domain. Note that this database structure and the following algorithms are meant to illustrate one possible implementation, rather than a specification of how all servers MUST be implemented. It's giving "example," not "rulebook" 🦋
The following notation is used:
ord(DOMAIN-NAME) returns the number of labels in DOMAIN-NAME.
findset(DOMAIN-NAME) returns a pointer to the set of stored RRs
for DOMAIN-NAME, or NULL if there is no such
information.
set(POINTER) refers to a set located previously by
findset, where POINTER is the value returned
by findset.
relevant(QTYPE,TYPE) returns true if a RR of the specified TYPE is
relevant to the specified QTYPE. For
example, relevant(MAILA,MF) is true and
relevant(MAILA,NS) is false.
right(NAME,NUMBER) returns a domain name that is the rightmost
NUMBER labels in the string NAME.
copy(RR) copies the resource record specified by RR
into the response.The name server code could be represented as the following sequence of steps 📝
{ find out whether the database makes this server
authoritative for the domain name specified by QNAME }
for i:=0 to ord(QNAME) { sequence through all nodes in QNAME }
do begin
ptr:=findset(right(QNAME,i));
if ptr<>NULL
then { there is domain data for this domain name }
begin
for all RRs in set(ptr)
do if type(RR)=NS and class(RR)=QCLASS
then begin
auth=false;
NSptr:=ptr
end;
for all RRs in set(ptr)
do if type(RR)=SOA and class(RR)=QCLASS
then auth:=true
end
end;
end;
{ copy out authority search results }
if auth
then { if authority check for domain found }
if ptr=null
then return(Name error)
else
else { if not authority, copy NS RRs }
for all RRs in set(nsptr)
do if (type(RR)=NS and class(RR)=QCLASS)
or
(QCLASS=*)
then copy(RR);
{ Copy all RRs that answer the question }
for all RRs in set(ptr)
do if class(RR)=QCLASS and relevant(QTYPE,type(RR))
then copy(RR);The first section of the code (the for loop over all of the subnodes of QNAME) figures out whether the name server is authoritative for the domain specified by QNAME 🔍 It sequences through all containing domains of QNAME, starting at the root. If it runs into a SOA, it knows the name server is authoritative, unless it finds a lower NS RR that delegates authority. If the name server is authoritative, it sets auth=true. If it isn't, it sets NSptr to point to the set which contains the NS RR closest to the domain specified by QNAME.
The second section reflects the result of the authority search into the response 💅 If the name server is authoritative, the code checks that the domain specified by QNAME exists. If it doesn't, a name error gets returned. If the name server is not authoritative, the code copies the RRs for a closer name server into the response.
The last section copies all the relevant RRs into the response 🎀
Note that this code is not meant as an actual implementation, and it's incomplete in several aspects 🙈 For example, it doesn't deal with providing additional information, wildcards, QCLASS=*, or overlapping zones. The first two of these issues are dealt with in the following discussions. The remaining issues are discussed in [14].
Additional information 🎁
When a resolver returns information to a user program, that information will often lead to a second query. For example, if a mailer asks a resolver for the appropriate mail agent for a particular domain name, the name server queried by the resolver returns a domain name that identifies the agent. In general, we would expect the mailer to then request the domain name to address binding for the mail agent, and a brand new name server query would happen 😩
To avoid this duplication of effort, name servers return additional information with a response that satisfies the anticipated query. This information is kept in a separate section of the response. Name servers are REQUIRED to complete the appropriate additional information if such information is available. The requestor SHOULD NOT depend on the presence of the information, though, since the name server MAY not have it. If the resolver caches the additional information, it can answer the second query without an additional network transaction ⚡
The appropriate information is defined in [14], but generally it consists of host to address bindings for domain names in returned RRs.
Aliases and canonical names 🪞
In existing systems, hosts and other resources often have several names that identify the same resource. For example, under current ARPA Internet naming support, USC-ISIF and ISIF both identify the same host. Similarly, for mailboxes, many organizations provide many names that actually go to the same mailbox. For example, Mockapetris@ISIF, Mockapetris@ISIB, etc., all go to the same mailbox (although the mechanism behind this is somewhat complicated) 📭
Most of these systems have a notion that one of the equivalent set of names is the canonical name, and all the others are aliases 👑
The domain system provides a similar feature using the canonical name (CNAME) RR. When a name server fails to find a desired RR in a set associated with some domain name, it checks to see if the resource set contains a CNAME record with a matching class. If it does, the name server includes the CNAME record in the response, and continues the query at the domain name specified in the data field of the CNAME record 🔁
Suppose a name server was processing a query with QNAME=ISIF.ARPA, QTYPE=A, and QCLASS=IN, and had the following resource records:
ISIF.ARPA CNAME IN F.ISI.ARPA
F.ISI.ARPA A IN 10.2.0.52Both of these RRs would be returned in the response 💖
In the above example, because ISIF.ARPA has no RRs other than the CNAME RR, the resources associated with ISIF.ARPA will appear to be exactly those associated with F.ISI.ARPA for the IN CLASS 🦋 Since the CNAME is only effective when the search fails, a CNAME can also be used to construct defaults. For example, suppose the name server had the following set of RRs:
F.ISI.ARPA A IN 10.2.0.52
F.ISI.ARPA MD IN F.ISI.ARPA
XXXX.ARPA CNAME IN F.ISI.ARPA
XXXX.ARPA MF IN A.ISI.ARPAUsing this database, type A queries for XXXX.ARPA would return the XXXX.ARPA CNAME RR and the F.ISI.ARPA A RR. But MAILA or MF queries to XXXX.ARPA would return the XXXX.ARPA MF RR without any information from F.ISI.ARPA 🧚 This structure might be used to send mail addressed to XXXX.ARPA to A.ISI.ARPA, and to direct TELNET for XXXX.ARPA to F.ISI.ARPA 📮
Wildcards 🃏
In certain cases, an administrator MAY wish to associate default resource information for all or part of a domain. For example, the CSNET domain administrator MAY wish to set up IN class mail forwarding for all hosts in the CSNET domain without IN capability. In a case like that, the domain system provides a special label * that matches any other label. Note that * matches only a single label, and not zero or more than one label. Also, * is distinct from the * values for QCLASS and QTYPE 🙃
The semantics of * depend on whether it appears in a query domain name (QNAME) or in an RR in a database:
- When a
*is used in a QNAME, it can only match a*in a resource record. - When
*appears in an RR in a database, it can never override an existing exact match. For example, if a name server received a query for the domain UDEL.CSNET, and had appropriate RRs for both UDEL.CSNET and *.CSNET, the UDEL.CSNET RRs would be used and the *.CSNET RRs would be ignored. If a query to the same database specified FOO.CSNET, the *.CSNET RR would be used, but the corresponding labels from the QNAME would replace the*. Thus the FOO.CSNET query would match the *.CSNET RR and return a RR for FOO.CSNET rather than *.CSNET. - RRs containing
*labels are copied exactly when zones are transfered via name server maintenance operations.
These semantics are easily implemented by having the name server first search for an exact match for a query. Then it replaces the leftmost label with a * and tries again, repeating the process until all labels became * or the search succeeded 🔎
TYPE=* in RRs is prohibited. If it were allowed, the requestor would have no way of interpreting the data in the RR, because this data is type dependent 🚫
CLASS=* is also prohibited. Similar effects can be achieved using QCLASS=, and allowing both QCLASS= and CLASS=* leads to complexities without any apparent benefit 💀
A scenario 🎬
In our sample domain space, suppose we wanted separate administrative control for the root, DDN, ARPA, CSNET, MIT and ISI domains. We might allocate name servers as follows:
|(B.ISI.ARPA)
|(UDEL.CSNET)
+------------------+------------------+
| | |
DDN ARPA CSNET
|(JCS.DDN) |(F.ISI.ARPA) |(UDEL.ARPA)
+-----+-----+ |(A.ISI.ARPA)+-----+-----+
| | | | | |
JCS ARMY NAVY | UDEL UCI
|
+--------+---------------+---------------+--------+
| | | | |
DTI MIT ISI UDEL NBS
|(AI.MIT.ARPA) |(F.ISI.ARPA)
+---+---+ +---+---+
| | | | |
DMS AI A B Fokay so this diagram is the whole sample domain tree 🌳✨ the authoritative name server is shown in parentheses at the point in the tree where it takes over control, and that's the key bit 🔑
so, the root name servers live on B.ISI.ARPA and UDEL.CSNET, the DDN name server is on JCS.DDN, the CSNET domain server is on UDEL.ARPA, and so on 💅
quick flag 🚩: in a real system, every domain should have redundant name servers 🫶 in this example though, only the ARPA domain gets redundant servers, A.ISI.ARPA and F.ISI.ARPA 👑 the B.ISI.ARPA and UDEL.CSNET servers aren't redundant on purpose, because they handle different classes 🙈 the F.ISI.ARPA server has authority over the ARPA domain but hands off MIT.ARPA to the name server on AI.MIT.ARPA 🧚 and the A.ISI.ARPA server also has authority over ARPA, but it delegates both ISI.ARPA and MIT.ARPA to other name servers 🌸
B.ISI.ARPA Name server for " "
B.ISI.ARPA is the root name server for the IN class 💜 its database might look like this:
Domain Resource Record
" " SOA IN A.ISI.ARPA
DDN NS IN JCS.DDN
ARPA NS IN F.ISI.ARPA
CSNET NS IN UDEL.ARPA
" " NS IN B.ISI.ARPA
" " NS CS UDEL.CSNET
JCS.DDN A IN 9.0.0.1
F.ISI.ARPA A IN 10.2.0.52
UDEL.CSNET A CS 302-555-0000
UDEL.ARPA A IN 10.0.0.96the SOA record for the root is necessary so the name server knows it's authoritative for the root domain for class IN ✨ the SOA contents point back to A.ISI.ARPA and say that the master data for this zone of authority originally comes from that host 🎀 the first three NS records show delegation of authority 💅 the NS root entry for B.ISI.ARPA is needed so this name server knows about itself and can answer correctly when someone asks for NS info about the root (which it's an authority for) 🫶 the root entry for class CS says UDEL.CSNET is the authoritative name server for the CS class root 🦋 and ngl, from this info alone it's impossible to tell whether UDEL.CSNET and UDEL.ARPA are the same name server 🙃
if this name server gets a query with QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA, it starts processing with the previous algorithm 🧠 it figures out it's not an authority for F.ISI.ARPA 😭 it notices it has authority at " ", but also that the authority was delegated at ARPA and never re-established with another SOA 💀 so the response returns the NS record for the domain ARPA 🌈
and any query with QCLASS=CS gets the UDEL.CSNET NS record back in the response 💖
F.ISI.ARPA Name server for ARPA and ISI.ARPA
in the same domain space, the F.ISI.ARPA database for the domains ARPA and ISI.ARPA might look like this:
Domain Resource Record
" " NS IN B.ISI.ARPA
" " NS CS CSNET.UDEL
ARPA SOA IN B.ISI.ARPA
ARPA NS IN A.ISI.ARPA
ARPA NS IN F.ISI.ARPA
MIT.ARPA NS IN AI.MIT.ARPA
ISI.ARPA SOA IN F.ISI.ARPA
ISI.ARPA NS IN F.ISI.ARPA
A.ISI.ARPA MD IN A.ISI.ARPA
ISI.ARPA MD IN F.ISI.ARPA
A.ISI.ARPA MF IN F.ISI.ARPA
B.ISI.ARPA MD IN B.ISI.ARPA
B.ISI.ARPA MF IN F.ISI.ARPA
F.ISI.ARPA MD IN F.ISI.ARPA
F.ISI.ARPA MF IN A.ISI.ARPA
DTI.ARPA MD IN DTI.ARPA
NBS.ARPA MD IN NBS.ARPA
UDEL.ARPA MD IN UDEL.ARPA
A.ISI.ARPA A IN 10.1.0.32
F.ISI.ARPA A IN 10.2.0.52
B.ISI.ARPA A IN 10.3.0.52
DTI.ARPA A IN 10.0.0.12
AI.MIT.ARPA A IN 10.2.0.6
DMS.MIT.ARPA A IN 10.1.0.6
NBS.ARPA A IN 10.0.0.19
UDEL.ARPA A IN 10.0.0.96for the IN class, the SOA RR for ARPA says this server is authoritative for ARPA, and that the master file for that authority lives on B.ISI.ARPA 🧁 this zone stretches out to ISI.ARPA, where the database hands authority back to this server in a separate zone 🔁 it doesn't include MIT.ARPA, which is served by a name server on AI.MIT.ARPA 💫
this name server isn't authoritative for anything in the CS class 🙅♀️ but it has a pointer to the CS root server, which can be used to resolve CS class queries 🗺️
say this server gets QNAME=A.ISI.ARPA, QTYPE=A, QCLASS=IN 🎯 the authority search spots the NS record for " ", its SOA at ARPA, a delegation at ISI.ARPA, and authority being reassumed at ISI.ARPA 🤓 so it knows it's an authority for this query, finds the A record for A.ISI.ARPA, and returns a datagram containing that record 💌
another query could be QNAME=B.ISI.ARPA, QTYPE=MAILA, QCLASS=. here the name server knows it can't be authoritative because of the "" value of QCLASS 🙈 so it looks for matching records for the domain B.ISI.ARPA instead 🔍 assuming it does the additional record inclusion from the name server algorithm, the returned datagram would include:
ISI.ARPA NS IN F.ISI.ARPA
" " NS CS UDEL.CSNET
B.ISI.ARPA MD IN B.ISI.ARPA
B.ISI.ARPA MF IN F.ISI.ARPA
B.ISI.ARPA A IN 10.3.0.52
F.ISI.ARPA A IN 10.2.0.52and if the query were QNAME=DMS.MIT.ARPA, QTYPE=MAILA, QCLASS=IN, the name server would find that AI.MIT.ARPA is the authoritative name server and return this:
MIT.ARPA NS IN AI.MIT.ARPA
AI.MIT.ARPA A IN 10.2.0.6so the requestor gets sent off to seek info from the MIT.ARPA domain name server living on AI.MIT.ARPA 🏃♀️💨
UDEL.ARPA and UDEL.CSNET name server
earlier we said UDEL.CSNET and UDEL.ARPA might be the same name server 🤔 for this example, we're going to assume that they are 💅 so this name server is an authority for the root of class CS, and also an authority for the CSNET domain in class IN 👑
this server handles mail forwarding between the ARPA Internet and CSNET systems 📬 its RRs show one approach to solving that problem 🧩 the name server has these resource records:
" " SOA CS UDEL.CSNET
" " NS CS UDEL.CSNET
" " NS IN B.ISI.ARPA
CSNET SOA IN UDEL.ARPA
CSNET NS IN UDEL.ARPA
ARPA NS IN A.ISI.ARPA
*.CSNET MF IN UDEL.ARPA
UDEL.CSNET MD CS UDEL.CSNET
UCI.CSNET MD CS UCI.CSNET
UDEL.ARPA MD IN UDEL.ARPA
B.ISI.ARPA A IN 10.3.0.52
UDEL.ARPA A IN 10.0.0.96
UDEL.CSNET A CS 302-555-0000
UCI.CSNET A CS 714-555-0000say this name server gets QNAME=UCI.CSNET, QTYPE=MAILA, QCLASS=IN 💌 it finds out it's authoritative for the CSNET domain under class IN, but there's no explicit mail data for UCI.CSNET 🥺 no worries though, because the *.CSNET record lets it build a reply:
UCI.CSNET MF IN UDEL.ARPA
UDEL.ARPA A IN 10.0.0.96and if it gets QNAME=UCI.CSNET, QTYPE=MAILA, QCLASS=CS instead, it returns:
UCI.CSNET MD CS UCI.CSNET
UCI.CSNET A CS 714-555-0000okay but here's the catch 🌈 although this scheme forwards all mail addressed as <anything>.CSNET, it doesn't help with names that have more than two components, like A.B.CSNET 😩 you could "fix" that with a series of MF entries for ..CSNET, ..*.CSNET, and so on, but a more tasteful solution would be a cleverer pattern matching algorithm in the CSNET name server 🧠✨
Summary of requirements for name servers
the requirements for a name server are as follows 📋
- It must be recognized by its parent.
- It must have complete resource information for all domain names for which it is the authority.
- It must periodically refresh authoritative information from a master file or name server which holds the master.
- If it caches information it must also handle TTL management for that information.
- It must answer simple queries.
Inverse queries
name servers may also support inverse queries, which map a particular resource to the domain name or names that have that resource 🔄 for example, a regular query might map a domain name to a host address, and the matching inverse query might map the address back to the domain name 🪞
implementing this service is optional in a name server 🙌 but all name servers must at least be able to understand an inverse query message and return an error response 🙏
the domain system can't guarantee completeness or uniqueness for inverse queries 😭 that's because the domain system is organized by domain name, not by host address or any other resource type 🗂️ so if a resolver (or any other program) wants an inverse query to work for sure, it has to use a name server that's known to have the right data, or ask all the name servers in the domain of interest 💅💖
For example, if a resolver wants to run an inverse query for some random host on the ARPA Internet 🔍, it must consult a set of name servers that's big enough to know that all IN data was considered 💅. Tbh though, in practice a single inverse query to a name server with a pretty comprehensive database should handle the vast majority of inverse queries ✨.
A detailed discussion of inverse queries is contained in [14] 🧚.
Completion services
Some existing systems can complete partial specifications of arguments 🪄. The vibe is that the user types the first few characters of the argument, then hits an escape character to prompt the system to finish the rest. Some completion systems require the user to type enough of the argument to be unique, and others don't, periodt 💖.
Other systems let the user specify one argument and ask the system to fill in the other arguments. For example, lots of mail systems let you type a username without a host for local mail delivery 📬.
The domain system defines name server completion transactions that do the analogous thing for the domain system 🌸. Implementing this service is optional in a name server, but all name servers must at least be able to understand a completion request and return an error response. Even if you skip the feature, you still gotta handle it politely 🙈.
When a resolver wants a completion, it sends a name server a message that sets QNAME to the partial string, QTYPE to the type of resource desired, and QCLASS to the desired class 🎀. The completion request also includes a RR for the target domain, and that target domain RR tells you the preferred location of the resource. In completion requests, QNAME must still have a null label to terminate the name, but its presence is ignored. Note that a completion request is not a query, but it shares some of the same field formats 👀.
Like, a completion request might contain QTYPE=A, QNAME=B, QCLASS=IN and a RR for ISI.ARPA. This asks for completion for a resource whose name begins with "B" and is "close" to ISI.ARPA. It's a super typical shorthand in the ISI community, where "B" is a way of referring to B.ISI.ARPA 🦋.
The first step in processing a completion request is to look for a "whole label" match. When the name server gets the request above, it looks at all records that are of type A, class IN, and whose domain name starts (on the left) with the labels of QNAME, which in this case is "B". If multiple records match, the name server selects the ones whose domain names match (from the right) the most labels of the preferred domain name. If there are still multiple candidates, the name server selects the records that have the shortest (in terms of octets in the name) domain name. If several records remain, then the name server returns them all 🔥.
If no records are found in the previous algorithm, the name server assumes that the rightmost label in QNAME is not complete, and looks for records that match but require addition of characters to the rightmost label of QNAME. For example, the previous search would not match BB.ARPA to B, but this search would. If multiple hits are found, the same discarding strategy is followed 💅.
A detailed discussion of completion can be found in [14] ✨.
RESOLVERS
Introduction
Resolvers are the programs that connect user programs to domain name servers 🌈. In the simplest case, a resolver gets a request from a user program (e.g. mail programs, TELNET, FTP) in the form of a subroutine call, system call etc., and hands back the desired information in a form that's compatible with the local host's data formats 💖.
Because a resolver may need to consult several name servers, the amount of time a resolver takes to finish can vary. This variance is part of the justification for the split between name servers and resolvers. Name servers may use datagrams and have a response time that's essentially equal to network delay plus a short service time, while resolvers may take an essentially indeterminate amount of time 🦋.
We expect to see two types of resolvers: simple resolvers that can chain through multiple name servers when required, and more complicated resolvers that cache resource records for use in future queries 🧚.
Simple resolvers
A simple resolver needs the following capabilities 💅:
- It must know how to access a name server, and should know the authoritative name server for the host that it services.
- It must know the protocol capabilities for its clients so that it can set the class fields of the queries it sends, which gets it returning information that's useful to its clients. If the resolver serves a client that has multiple protocol capabilities, it should be able to support the preferences of the client.
The resolver for a multiple protocol client can either collect information for all classes using the * class value, or iterate on the classes supported by the client. Note that in either case, the resolver must understand the preferences of the host. For example, a host that supports both CSNET and ARPA Internet protocols might prefer mail delivery (MD) to mail forwarding (MF), regardless of protocol, or might prefer one protocol regardless of whether MD or MF is required. Care is required to prevent loops 🙈.
- The resolver must be capable of chaining through multiple name servers to get to an authoritative name server for any query. The resolver should guard against loops in referrals. A simple policy is to discard referrals that don't match more of the query name than the referring name server, and also to avoid querying the same name server twice. (This test should be done using addresses of name servers instead of domain names, to avoid problems when a name server has multiple domain names or errors are present in aliases 🫶.)
- The resolver must be able to try alternate name servers when a name server doesn't respond 🔥.
- The resolver must be able to communicate different failure conditions to its client. These failure conditions include unknown domain name, unknown resource for a know domain name, and inability to access any of the authoritative name servers for a domain 💀.
- If the resolver uses datagrams for queries, it must recover from lost and duplicate datagrams 👑.
Resolvers with cache management
Caching is a tool for improving the performance of name service, but it's also a potential source of incorrect results 👀. For example, a database might cache information that is later changed in the authoritative name servers. While this problem can't be eliminated without eliminating caching, it can be reduced to an infrequent problem through the use of timeouts ⏳.
When name servers return resource records, each record has an associated time-to-live (TTL) field. This field is expressed in seconds, and has 16 bits of significance 🍓.
When a resolver caches a returned resource record, it must also remember the TTL field. The resolver must discard the record when the equivalent amount of time has passed. If the resolver shares a database with a name server, it must decrement the TTL field of imported records periodically, rather than simply deleting the record. This strategy is necessary to avoid exporting a resource record whose TTL field doesn't reflect the amount of time that the resource record has been cached. Of course, the resolver should not decrement the TTL fields of records for which the associated name server is an authority 🎀.
Appendix 1 - Domain Name Syntax Specification ✨
The preferred syntax of domain names is given by the following BNF rules. Sticking to this syntax means fewer problems with many applications that use domain names (e.g., mail, TELNET) 💖. Note that some applications described in [14] use domain names containing binary information, and hence do not follow this syntax 🙈.
<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 while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if 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 the length. Labels must be 63 characters or less 💅.
For example, the following strings identify hosts in the ARPA Internet 🧚:
F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPAREFERENCES and BIBLIOGRAPHY
[1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet Host Table Specification", RFC 810, Network Information Center, SRI International, March 1982.
[2] J. Postel, "Computer Mail Meeting Notes", RFC 805, USC/Information Sciences Institute, February 1982.
[3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet User Applications", RFC 819, Network Information Center, SRI International, August 1982.
[4] Z. Su, "A Distributed System for Internet Name Service", RFC 830, Network Information Center, SRI International, October 1982.
[5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network Information Center, SRI International, March 1982.
[6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name Server", Computer Networks, vol 6, nr 3, July 1982.
[7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information Center, SRI International, December 1977.
[8] J. Postel, "Internet Name Server", IEN 116, USC/Information Sciences Institute, August 1979.
[9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server", RFC 811, Network Information Center, SRI International, March 1982.
[10] J. Postel, "Transmission Control Protocol", RFC 793, USC/Information Sciences Institute, September 1981.
[11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980.
[12] J. Postel, "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1980.
[13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870, USC/Information Sciences Institute, October 1983.
[14] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 883, USC/Information Sciences Institute, November 1983.
📦 where this page comes from
- ietf: rfc882 1983-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms