RFC 2181

Title and Vibe Check 🎀

Okay bestie, so this is RFC 2181, called Clarifications to the DNS Specification. R. Elz from the University of Melbourne and R. Bush from RGnet, Inc. wrote it. It's a Standards Track doc, dated July 1997. It updates RFC 1034, RFC 1035, and RFC 1123 (so it's basically fixing their homework 💅). Nothing is obsoleted here.

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

1. Abstract ✨

So this doc looks at some spots that were confusing in the Domain Name System spec and suggests fixes for the defects it finds. Eight separate issues get covered:

• IP packet header address usage from multi-homed servers,
• TTLs in sets of records with the same name, class, and type,
• correct handling of zone cuts,
• three minor issues concerning SOA records and their use,
• the precise definition of the Time to Live (TTL)
• Use of the TC (truncated) header bit
• the issue of what is an authoritative, or canonical, name,
• and the issue of what makes a valid DNS label.

The first six are areas where the correct behaviour was kinda unclear, so the goal is to fix that 🙈. The other two are already spelled out properly, but people sometimes just ignore those rules, so this doc wants to reinforce them 🫶.

Contents 🧚

    1  Abstract  ...................................................   1
    2  Introduction  ...............................................   2
    3  Terminology  ................................................   3
    4  Server Reply Source Address Selection  ......................   3
    5  Resource Record Sets  .......................................   4
    6  Zone Cuts  ..................................................   8
    7  SOA RRs  ....................................................  10
    8  Time to Live (TTL)  .........................................  10
    9  The TC (truncated) header bit  ..............................  11
   10  Naming issues  ..............................................  11
   11  Name syntax  ................................................  13
   12  Security Considerations  ....................................  14
   13  References  .................................................  14
   14  Acknowledgements  ...........................................  15
   15  Authors' Addresses  .........................................  15

2. Introduction 🌸

Several problem areas in the Domain Name System specification [RFC1034, RFC1035] have been noted through the years [RFC1123]. This document addresses several additional problem areas. The issues here are independent. Those issues are the question of which source address a multi-homed DNS server should use when replying to a query, the issue of differing TTLs for DNS records with the same label, class and type, and the issue of canonical names, what they are, how CNAME records relate, what names are legal in what parts of the DNS, and what is the valid syntax of a DNS name.

Clarifications to the DNS specification to avoid these problems are made in this memo. A minor ambiguity in RFC1034 concerned with SOA records is also corrected, as is one in the definition of the TTL (Time To Live) and some possible confusion in use of the TC bit.

3. Terminology 💅

This memo does not use the oft used expressions MUST, SHOULD, MAY, or their negative forms. In some sections it may seem that a specification is worded mildly, and hence some may infer that the specification is optional. That is not correct. Anywhere that this memo suggests that some action should be carried out, or must be carried out, or that some behaviour is acceptable, or not, that is to be considered as a fundamental aspect of this specification, regardless of the specific words used. If some behaviour or action is truly optional, that will be clearly specified by the text.

4. Server Reply Source Address Selection 🦋

Most, if not all, DNS clients, expect the address from which a reply is received to be the same address as that to which the query eliciting the reply was sent. This is true for servers acting as clients for the purposes of recursive query resolution, as well as simple resolver clients. The address, along with the identifier (ID) in the reply is used for disambiguating replies, and filtering spurious responses. This may, or may not, have been intended when the DNS was designed, but is now a fact of life.

Some multi-homed hosts running DNS servers generate a reply using a source address that is not the same as the destination address from the client's request packet. Such replies will be discarded by the client because the source address of the reply does not match that of a host to which the client sent the original request. That is, it appears to be an unsolicited response.

4.1. UDP Source Address Selection

To avoid these problems, servers when responding to queries using UDP must cause the reply to be sent with the source address field in the IP header set to the address that was in the destination address field of the IP header of the packet containing the query causing the response. If this would cause the response to be sent from an IP address that is not permitted for this purpose, then the response may be sent from any legal IP address allocated to the server. That address should be chosen to maximise the possibility that the client will be able to use it for further queries. Servers configured in such a way that not all their addresses are equally reachable from all potential clients need take particular care when responding to queries sent to anycast, multicast, or similar, addresses.

4.2. Port Number Selection

Replies to all queries must be directed to the port from which they were sent. When queries are received via TCP this is an inherent part of the transport protocol. For queries received by UDP the server must take note of the source port and use that as the destination port in the response. Replies should always be sent from the port to which they were directed. Except in extraordinary circumstances, this will be the well known port assigned for DNS queries [RFC1700].

5. Resource Record Sets 💖

Each DNS Resource Record (RR) has a label, class, type, and data. It is meaningless for two records to ever have label, class, type and data all equal - servers should suppress such duplicates if encountered. It is however possible for most record types to exist with the same label, class and type, but with different data. Such a group of records is hereby defined to be a Resource Record Set (RRSet).

5.1. Sending RRs from an RRSet

A query for a specific (or non-specific) label, class, and type, will always return all records in the associated RRSet - whether that be one or more RRs. The response must be marked as "truncated" if the entire RRSet will not fit in the response.

5.2. TTLs of RRs in an RRSet

Resource Records also have a time to live (TTL). It is possible for the RRs in an RRSet to have different TTLs. No uses for this have been found that cannot be better accomplished in other ways. This can, however, cause partial replies (not marked "truncated") from a caching server, where the TTLs for some but not all the RRs in the RRSet have expired.

Consequently the use of differing TTLs in an RRSet is hereby deprecated, the TTLs of all RRs in an RRSet must be the same.

Should a client receive a response containing RRs from an RRSet with differing TTLs, it should treat this as an error. If the RRSet concerned is from a non-authoritative source for this data, the client should simply ignore the RRSet, and if the values were required, seek to acquire them from an authoritative source. Clients that are configured to send all queries to one, or more, particular servers should treat those servers as authoritative for this purpose. Should an authoritative source send such a malformed RRSet, the client should treat the RRs for all purposes as if all TTLs in the RRSet had been set to the value of the lowest TTL in the RRSet. In no case may a server send an RRSet with TTLs not all equal.

5.3. DNSSEC Special Cases

Two of the record types added by DNS Security (DNSSEC) [RFC2065] require special attention when considering the formation of Resource Record Sets. Those are the SIG and NXT records. It should be noted that DNS Security is still very new, and there is, as yet, little experience with it. Readers should be prepared for the information related to DNSSEC contained in this document to become outdated as the DNS Security specification matures.

5.3.1. SIG records and RRSets

A SIG record provides signature (validation) data for another RRSet in the DNS. Where a zone has been signed, every RRSet in the zone will have had a SIG record associated with it. The data type of the RRSet is included in the data of the SIG RR, to indicate with which particular RRSet this SIG record is associated. Were the rules above applied, whenever a SIG record was included with a response to validate that response, the SIG records for all other RRSets associated with the appropriate node would also need to be included. In some cases, this could be a very large number of records, not helped by their being rather large RRs.

Thus, it is specifically permitted for the authority section to contain only those SIG RRs with the "type covered" field equal to the type field of an answer being returned. However, where SIG records are being returned in the answer section, in response to a query for SIG records, or a query for all records associated with a name (type=ANY) the entire SIG RRSet must be included, as for any other RR type.

Servers that receive responses containing SIG records in the authority section, or (probably incorrectly) as additional data, must understand that the entire RRSet has almost certainly not been included. Thus, they must not cache that SIG record in a way that would permit it to be returned should a query for SIG records be received at that server. RFC2065 actually requires that SIG queries be directed only to authoritative servers to avoid the problems that could be caused here, and while servers exist that do not understand the special properties of SIG records, this will remain necessary. However, careful design of SIG record processing in new implementations should permit this restriction to be relaxed in the future, so resolvers do not need to treat SIG record queries specially.

It has been occasionally stated that a received request for a SIG record should be forwarded to an authoritative server, rather than being answered from data in the cache. This is not necessary - a server that has the knowledge of SIG as a special case for processing this way would be better to correctly cache SIG records, taking into account their characteristics. Then the server can determine when it is safe to reply from the cache, and when the answer is not available and the query must be forwarded.

5.3.2. NXT RRs ✨

okay so NXT records are lowkey the most peculiar ones 🙈 There will only ever be one NXT record in a zone for a particular label, so superficially the RRSet problem is trivial. BUT at a zone cut, the parent zone AND the child zone (superzone and subzone in RFC2065 terminology) both have NXT records for the same name 👀 Those two NXT records do NOT form an RRSet, even when both zones are housed at the same server. NXT RRSets always contain just a single RR. Where both NXT records are visible, two RRSets exist. However, servers are NOT REQUIRED to treat this as a special case when receiving NXT records in a response. They MAY elect to notice the existence of two different NXT RRSets and treat that as they would two different RRSets of any other type. That is, cache one and ignore the other. Security aware servers will need to correctly process the NXT record in the received response though 🔐

5.4. Receiving RRSets

Servers MUST never merge RRs from a response with RRs in their cache to form an RRSet 🚫 If a response contains data that would form an RRSet with data in a server's cache, the server MUST either ignore the RRs in the response, or discard the entire RRSet currently in the cache, as appropriate. Consequently, the issue of TTLs varying between the cache and a response does not cause concern, because one will be ignored. That is, one of the data sets is always incorrect if the data from an answer differs from the data in the cache. The challenge for the server is to determine which of the data sets is correct (if one is), retain that one, and ignore the other 🧐 Note that if a server receives an answer containing an RRSet that is identical to the one in its cache, with the possible exception of the TTL value, it MAY, optionally, update the TTL in its cache with the TTL of the received answer. It SHOULD do this if the received answer would be considered more authoritative (as discussed in the next section) than the previously cached answer ✨

5.4.1. Ranking data

When considering whether to accept an RRSet in a reply, or retain an RRSet already in its cache instead, a server SHOULD consider the relative likely trustworthiness of the various data 💅 An authoritative answer from a reply SHOULD replace cached data that had been obtained from additional information in an earlier reply. However, additional information from a reply will be ignored if the cache contains data from an authoritative answer or a zone file.

The accuracy of data available is assumed from its source. Trustworthiness SHALL be, in order from most to least:

• Data from a primary zone file, other than glue data,
• Data from a zone transfer, other than glue,
• The authoritative data included in the answer section of an authoritative reply.
• Data from the authority section of an authoritative answer,
• Glue from a primary zone, or glue from a zone transfer,
• Data from the answer section of a non-authoritative answer, and non-authoritative data from the answer section of authoritative answers,
• Additional information from an authoritative answer, Data from the authority section of a non-authoritative answer, Additional information from non-authoritative answers.

Note that the answer section of an authoritative answer normally contains only authoritative data. However, when the name sought is an alias (see section 10.1.1), only the record describing that alias is necessarily authoritative. Clients SHOULD assume that other records may have come from the server's cache. Where authoritative answers are required, the client SHOULD query again, using the canonical name associated with the alias 🔁

Unauthenticated RRs received and cached from the least trustworthy of those groupings (that is, data from the additional data section, and data from the authority section of a non-authoritative answer) SHOULD NOT be cached in such a way that they would ever be returned as answers to a received query. They MAY be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse 🙅‍♀️

When DNS security [RFC2065] is in use, and an authenticated reply has been received and verified, the data thus authenticated SHALL be considered more trustworthy than unauthenticated data of the same type 🛡️ Note that throughout this document, "authoritative" means a reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY records to determine the authenticity of data, so the AA bit is almost irrelevant. However, DNSSEC aware servers MUST still correctly set the AA bit in responses to enable correct operation with servers that are not security aware (almost all currently) 💖

Note that, glue excluded, it is impossible for data from two correctly configured primary zone files, two correctly configured secondary zones (data from zone transfers), or data from correctly configured primary and secondary zones, to ever conflict 🤝 Where glue for the same name exists in multiple zones and differs in value, the nameserver SHOULD select data from a primary zone file in preference to secondary, but otherwise MAY choose any single set of such data. Choosing the one that appears to come from a source nearer the authoritative data source MAY make sense where that can be determined. Choosing primary data over secondary allows the source of incorrect glue data to be discovered more readily, when a problem with such data exists. Where a server can detect from two zone files that one or more are incorrectly configured, so as to create conflicts, it SHOULD refuse to load the zones determined to be erroneous, and issue suitable diagnostics 🚨

"Glue" above includes any record in a zone file that is not properly part of that zone, including nameserver records of delegated sub-zones (NS records), address records that accompany those NS records (A, AAAA, etc), and any other stray data that might appear 🧦

5.5. Sending RRSets (reprise)

A Resource Record Set SHOULD only be included once in any DNS reply 🎀 It MAY occur in any of the Answer, Authority, or Additional Information sections, as required. However, it SHOULD NOT be repeated in the same, or any other, section, except where explicitly REQUIRED by a specification. For example, an AXFR response requires the SOA record (always an RRSet containing a single RR) to be both the first and last record of the reply. Where duplicates are required this way, the TTL transmitted in each case MUST be the same ⏰

6. Zone Cuts

The DNS tree is divided into "zones", which are collections of domains that are treated as a unit for certain management purposes 🌳 Zones are delimited by "zone cuts". Each zone cut separates a "child" zone (below the cut) from a "parent" zone (above the cut). The domain name that appears at the top of a zone (just below the cut that separates the zone from its parent) is called the zone's "origin". The name of the zone is the same as the name of the domain at the zone's origin. Each zone comprises that subset of the DNS tree that is at or below the zone's origin, and that is above the cuts that separate the zone from its children (if any). The existence of a zone cut is indicated in the parent zone by the existence of NS records specifying the origin of the child zone. A child zone does not contain any explicit reference to its parent 🧚

6.1. Zone authority

The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record, are the mandatory records in every zone 👑 Such a server is authoritative for all resource records in a zone that are not in another zone. The NS records that indicate a zone cut are the property of the child zone created, as are any other records for the origin of that child zone, or any sub-domains of it. A server for a zone SHOULD NOT return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone 🙅

Other than the DNSSEC cases mentioned immediately below, servers SHOULD ignore data other than NS records, and necessary A records to locate the servers listed in the NS records, that may happen to be configured in a zone at a zone cut 🫶

6.2. DNSSEC issues

The DNS security mechanisms [RFC2065] complicate this somewhat, as some of the new resource record types added are very unusual when compared with other DNS RRs 🤯 In particular, the NXT ("next") RR type contains information about which names exist in a zone, and hence which do not, and thus must necessarily relate to the zone in which it exists. The same domain name may have different NXT records in the parent zone and the child zone, and both are valid, and they are not an RRSet. See also section 5.3.2.

Since NXT records are intended to be automatically generated, rather than configured by DNS operators, servers MAY, but are NOT REQUIRED to, retain all differing NXT records they receive, regardless of the rules in section 5.4 🤖

For a secure parent zone to securely indicate that a subzone is insecure, DNSSEC requires that a KEY RR indicating that the subzone is insecure, and the parent zone's authenticating SIG RR(s), be present in the parent zone, as they by definition cannot be in the subzone 🔑 Where a subzone is secure, the KEY and SIG records will be present, and authoritative, in that zone, but they SHOULD also always be present in the parent zone (if secure) 💜

Note that in none of these cases SHOULD a server for the parent zone, not also being a server for the subzone, set the AA bit in any response for a label at a zone cut. 🚫

7. SOA RRs

Three minor issues concerning the Start of Zone of Authority (SOA) Resource Record need some clarification 📝

7.1. Placement of SOA RRs in authoritative answers

RFC1034, in section 3.7, indicates that the authority section of an authoritative answer MAY contain the SOA record for the zone from which the answer was obtained. When discussing negative caching, RFC1034 section 4.3.4 refers to this technique but mentions the additional section of the response. The former is correct, as is implied by the example shown in section 6.2.5 of RFC1034. SOA records, if added, are to be placed in the authority section 📦

7.2. TTLs on SOA RRs

It may be observed that in section 3.2.1 of RFC1035, which defines the format of a Resource Record, the definition of the TTL field contains a throw away line which states that the TTL of an SOA record SHOULD always be sent as zero to prevent caching 🙃 This is mentioned nowhere else, and has not generally been implemented. Implementations SHOULD NOT assume that SOA records will have a TTL of zero, and they are also NOT REQUIRED to send SOA records with a TTL of zero 🌸

7.3. The SOA.MNAME field

It is quite clear in the specifications, yet seems to have been widely ignored, that the MNAME field of the SOA record SHOULD contain the name of the primary (master) server for the zone identified by the SOA. It SHOULD NOT contain the name of the zone itself. That information would be useless, because to discover it, one needs to start with the domain name of the SOA record, which is the name of the zone 🧠

8. Time to Live (TTL) ✨

okay so the TTL field in STD 13 is kinda vague about how many bits it actually has and whether the number is signed or unsigned 🙈 this doc finally settles it! a TTL value is an unsigned number, with a minimum of 0 and a maximum of 2147483647 (that's 2^31 - 1 🎀). when it gets sent, the value SHALL be encoded in the less significant 31 bits of the 32 bit TTL field, with the most significant (sign) bit set to zero. bestie, that's the whole rule 💅

Implementations SHOULD treat TTL values received with the most significant bit set as if the entire value received was zero.

Implementations are always free to put an upper bound on any TTL they receive, and treat anything larger as if it were that upper bound 🌸 and the TTL is a maximum time to live, NOT a mandatory one. so it's a ceiling, not a must-stay-exactly-this-long thing. iconic 🦋

9. The TC (truncated) header bit 🎀

okay so the TC bit SHOULD be set in responses only when an RRSet is required as part of the response but couldn't fit in its entirety. the TC bit SHOULD NOT be set just because some extra info could have been included but there wasn't room 🙅‍♀️ this includes the results of additional section processing too. in those cases the entire RRSet that won't fit in the response SHOULD be omitted, and the reply gets sent as is, with the TC bit clear. if the recipient of the reply needs that omitted data, they can build a query for it and send that separately ✨

where TC is set, the partial RRSet that wouldn't completely fit MAY be left in the response. and when a DNS client gets a reply with TC set, it SHOULD ignore that response and query again, using something like a TCP connection that lets bigger replies through 🔥 it's giving "try again with the bigger bag" energy 🛍️

10. Naming issues 💖

it has sometimes been inferred from some sections of the DNS specification [RFC1034, RFC1035] that a host (or maybe an interface of a host) is only allowed ONE official name, called the canonical name. nope! there is no such requirement in the DNS 🙌

10.1. CNAME resource records 🦋

the DNS CNAME ("canonical name") record exists to give the canonical name associated with an alias name. there may be only one such canonical name for any one alias. that name SHOULD generally be a name that exists elsewhere in the DNS, though there are some rare applications for aliases where the canonical name is undefined in the DNS 👀 an alias name (the label of a CNAME record) MAY, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but MAY have no other data. so for any label in the DNS (any domain name), exactly one of the following is true:

• one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs,
• one or more records exist, none being CNAME records,
• the name exists, but has no associated RRs of any type,
• the name does not exist at all.

10.1.1. CNAME terminology 🧠

it's been traditional to call the label of a CNAME record "a CNAME" 😭 which is sooo confusing, because "CNAME" stands for "canonical name," and the label of a CNAME record is most certainly NOT a canonical name. it's an entrenched usage tho, so we MUST be really clear about whether we mean the label or the value (the canonical name) of a CNAME resource record. in this document, the label of a CNAME resource record will always be called an alias ✨ clean and simple.

10.2. PTR records 🌈

confusion about canonical names has led to a belief that a PTR record should have exactly one RR in its RRSet. that's incorrect 🙅‍♀️ the relevant section of RFC1034 (section 3.6.2) says the value of a PTR record SHOULD be a canonical name. that means it SHOULD NOT be an alias. nothing in that section implies that only one PTR record is allowed for a name, so no such restriction SHOULD be inferred 💅

ok but this part is the plot twist 🍓 while the value of a PTR record MUST NOT be an alias, there is no requirement that resolving a PTR record avoid encountering aliases. the label being looked up for a PTR value might have a CNAME record, so it might be an alias itself. the value of that CNAME RR (if it's not another alias, which it SHOULD NOT be) tells you where the PTR record is found. that record gives the result of the PTR type lookup. and this final result, the value of the PTR RR, is the label that MUST NOT be an alias. main character energy for the PTR value 👑

10.3. MX and NS records 💜

the domain name used as the value of an NS resource record, or part of the value of an MX resource record, MUST NOT be an alias. the spec is super clear on this, and using an alias in either spot doesn't work as well as you'd hope, nor does it fully fulfill the ambition that may have led to the approach in the first place 🙃 this domain name MUST have as its value one or more address records. right now those will be A records, but in the future other record types giving addressing information MAY be acceptable. it can also have other RRs, but never a CNAME RR 🚫

searching for NS or MX records triggers "additional section processing," where the address records associated with the value of the record you asked for get tacked onto the answer ✨ this helps avoid needless extra queries that are super easy to predict once the first one happened.

additional section processing does NOT include CNAME records, let alone the address records that might be associated with the canonical name derived from the alias 😬 so if an alias is used as the value of an NS or MX record, no address comes back with the NS or MX value. that can cause extra queries and extra network burden on every query 💀 the DNS admin can dodge this easily by resolving the alias and putting the canonical name directly in the affected record once, when it's updated or installed. in some really hard cases, the missing additional section address records in an NS lookup can make the request fail 😱

11. Name syntax 🎀

people sometimes assume the Domain Name System only maps Internet host names to data and Internet addresses to host names. not quite! the DNS is a general (if somewhat limited) hierarchical database, and it can store almost any kind of data for almost any purpose 🧚

the DNS itself only puts ONE restriction on the labels you can use to identify resource records, and it's about length. a label is limited to between 1 and 63 octets. a full domain name is limited to 255 octets (separators included). the zero length full name is the root of the DNS tree, usually written and displayed as "." 🌳 beyond that, any binary string whatever can be a label of any resource record. likewise, any binary string can be the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added) 🫶 implementations of the DNS protocols MUST NOT place any restrictions on the labels that can be used. in particular, DNS servers MUST NOT refuse to serve a zone just because it has labels some DNS client programs might not like 🙅‍♀️ a DNS server MAY be configurable to issue warnings when loading a primary zone with questionable labels, or even to refuse to load it, but this SHOULD NOT happen by default.

note however (and this is important, iykyk) that the applications using DNS data can impose restrictions on which values are acceptable in their environment. for example, just because a binary label can have an MX record doesn't mean any binary name can be used as the host part of an e-mail address 📧 clients of the DNS can impose whatever restrictions suit their circumstances on the values they use as lookup keys and on the values returned by the DNS. if the client has such restrictions, it is solely responsible for validating the data from the DNS to make sure it conforms before using it 💅

see also [RFC1123] section 6.1.3.5 🔗

12. Security Considerations 💀🔐

this document does not consider security. yep, that's the tea 🫠

in particular, nothing in section 4 is in any way related to, or useful for, any security related purposes. the vibes are NOT security vibes 🙈

section 5.4.1 is also not related to security. security of DNS data will be handled by the Secure DNS [RFC2065], which is mostly orthogonal to this memo 🧩

it is not believed that anything in this document adds to any security issues the DNS may already have, nor does it do anything to that will necessarily lessen them. correctly implementing the clarifications in this document might play some small part in limiting the spread of non-malicious bad data in the DNS. BUT only DNSSEC can help with deliberate attempts to subvert DNS data. so if someone is actively trying to mess with your DNS data, this doc won't save you, periodt 😤🔥

13. References 📚

[RFC1034]   Mockapetris, P., "Domain Names - Concepts and Facilities",
            STD 13, RFC 1034, November 1987.

[RFC1035]   Mockapetris, P., "Domain Names - Implementation and
            Specification", STD 13, RFC 1035, November 1987.

[RFC1123]   Braden, R., "Requirements for Internet Hosts - application
            and support", STD 3, RFC 1123, January 1989.

[RFC1700]   Reynolds, J., Postel, J., "Assigned Numbers",
            STD 2, RFC 1700, October 1994.

[RFC2065]   Eastlake, D., Kaufman, C., "Domain Name System Security
            Extensions", RFC 2065, January 1997.

14. Acknowledgements 🫶🌷

this memo came out of discussions in the DNSIND working group of the IETF in 1995 and 1996, and the members of that group are largely responsible for the ideas in here 🙌 major thanks to Donald E. Eastlake, 3rd, and Olafur Gudmundsson for help with the DNSSEC issues, and to John Gilmore for pointing out where the clarifications weren't necessarily clarifying 😂 Bob Halley suggested clarifying where SOA records go in authoritative answers, and also provided the references. Michael Patton, as usual, plus Mark Andrews, Alan Barrett, and Stan Barber, gave tons of help with many details 💜 and Josh Littlefield made sure the clarifications didn't cause problems in some irritating corner cases. legends, all of them 👑✨

15. Authors' Addresses 🦋

Robert Elz
Computer Science
University of Melbourne
Parkville, Victoria, 3052
Australia.

EMail: kre@munnari.OZ.AU


Randy Bush
RGnet, Inc.
5147 Crystal Springs Drive NE
Bainbridge Island, Washington,  98110
United States.

EMail: randy@psg.com