Domain Name System Security WG Edward Lewis INTERNET DRAFT Olafur Gudmundsson <draft-lewis-dnsnxt-semantics-00.txt> Trusted Information Systems March 7, 1997 Semantics of DNS NXT Resource Records <draft-lewis-dnsnxt-semantics-00.txt> 0.0 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This Internet Draft expires on 7 September 1997. Please send comments to the authors and dns-security@tis.com. 1.0 Abstract In "Domain Name System Security Extensions" (RFC 2065) the NXT Resource Record (along with SIG RR and KEY RR) is introduced to allow for secure denial of existence of either a domain name or a RRSet belonging to an existing domain name. The set of NXT records within a zone create a virtual "chain" of RRSets within a zone by indicating, for each name within a zone, the RRSets for which it owns records and the next name in the zone. RFC 2065 discusses security extensions for static DNS zones. An Internet Draft, draft-ietf-dnssec-update-04.txt, becoming an RFC describes security in DNS zone which can be dynamically updated. In this document, the authors build upon them to: - define some terms used colloquially in the working group - describe the semantics of the NXT record in greater detail than the two existing documents, in order to achieve interoperability - introduce and discuss unresolved issues involving NXT records Expires September 7, 1997 [Page 1] Internet Draft March 7, 1997 2.0 Introduction In Domain Name System Security Extensions [RFC2065] the NXT RR (along with SIG RR and KEY RR) is introduced to allow for secure denial of existence of either a domain name or a RRSet belonging to an existing domain name. The set of NXT records within a zone create a virtual "chain" of RRSets within a zone by indicating, for each name within a zone, the RRSets for which it owns records and the next name in the zone. Example: a.cbml. 86400 IN NXT b.cbml. A SIG NXT This record states that there is no label that fits alphabetically between 'a' and 'b' in zone cbml. Furthermore, the record indicates that a.cbml. has only A, NXT, and SIG RR's. a.cbml. does not have, for example, any TXT RR's. RFC 2065 discusses security extensions for static DNS zones. An Internet Draft [UPDATE] becoming an RFC describes security in DNS zone which can be dynamically updated. In this document, the authors build upon them to: - define some terms used colloquially in the working group - describe the semantics of the NXT record in greater detail than the two existing documents, in order to achieve interoperability - introduce and discuss unresolved issues involving NXT records This is the first release of this document. The long term goal for this document is to be used as a supplement to RFC 2065 and UPDATE, or be incorporated into future editions of these as they proceed along the standards track. There are two issues facing the NXT record. One is the concern over the ability to obtain a list of domain names systematically, called "NXT walking." The other issue is the manner in which the NXT records are maintained in dynamic update. This document contains some comments on the NXT walk issue, defining and examining the problem, but does not propose a solution. This document does propose a change to the UPDATE draft concerning the maintenance of NXT records. This document is partitioned into four main parts. Section 3 defines terms that are used throughout the document, some have also been used in discussions within the working group. Section 4 presents details of the NXT concept. Sections 4 and 5 expands upon the issues in the previous two paragraphs. 2.1 Terminology convention In the literature on DNS, different terms are used to describe Expires September 7, 1997 [Page 2] Internet Draft March 7, 1997 the relationship of zones. "Super-zone and sub-zone," "parent and child," and "delegator and delegatee" each refer to two zones joined at a "zone cut." For each of the set of terms, the former is the zone above the cut point, the latter is below the cut point. In this document, we use the terms delegator and delegatee. 2.2 Use of Capitalized MUST MUST This word means that the item is an absolute requirement of this specification. 3.0 Terminology The DNSSEC working group's efforts have resulted in a number of new concepts within DNS. In order to more clearly and accurately describe DNS security extensions, and in particular, the NXT semantics, a few terms and notations will be defined. 3.1 RRSet+ In a current internet draft, draft-ietf-dnsind-clarify-05.txt [CLARIFY], RRSet is defined as being the set of RR's that have the same owner name, class, and type. In addition, the use of differing TTL's within such a group is deprecated, so members of an RRSet also have the same TTL. If a name server finds two RR's in an RRSet also share the same data values, CLARIFY states that the duplicates should be suppressed. When discussing DNS Security Extensions it is often convenient to refer to an RRSet and the SIG record containing covering it. The term RRSet+ is used to denote this. Besides the inclusion of the covering SIG, there is one other aspect to an RRSet+. Instead of duplicates "should be suppressed" as in CLARIFY's RRSet, in an RRSet+ duplicates MUST be suppressed. The plural of RRSet+ will be written RRSet+s. Example: name1. 86400 IN A 10.33.11.23 ; record 1 name1. 86400 IN A 10.33.240.23 ; record 2 name1. 86400 IN SIG A {and other information} ; record 3 name1. 86400 IN TXT "A TXT record" ; record 4 name1. 86400 IN TXT "Another TXT record" ; record 5 name1. 86400 IN SIG TXT {and other information} ; record 6 Records 1 and 2 comprise a A RRSet according to the definition in CLARIFY. Records 1, 2, and 3 comprise a A RRSet+. Records 4, 5, and 6 comprise a TXT RRSet+. (Note: in subsequent examples, the TTL and class fields are omitted for brevity.) Expires September 7, 1997 [Page 3] Internet Draft March 7, 1997 There are two exceptions to the RRSet+ definition, one involving the NXT RR and the other involving SIG RR. 3.2 SIG(<_RR-type_>) notation This denotes that a SIG RR's "type-covered" is that specified within the parenthesis. It has been found to be a useful shorthand in discussing RRSet+s. Example: a.cbml. A 10.32.12.178 a.cbml. SIG A {....} The latter record is referred to as a "SIG(A)" record. 3.3 NXT RRSet+ A domain name's NXT RRSet+ consists of the lone NXT RR and the lone SIG(NXT) RR associated with a domain name in a particular zone. A domain name that is a delegation point (i.e., owns an NS RRSet+) is in two zones, so it has two NXT RRSet+s corresponding to each of the delegating zone and the zone in which it is an apex name. (Stated for completeness, the root zone's apex has just one NXT RRSet+.) For these names, the two NXT RRSet+s are neither combined with nor replace each other. (Section 4.7 contains an example of a delegation point and its two NXT RRSet+s.) 3.4 No SIG RRSet+ The SIG RRSet is, as defined according to CLARIFY, the collection of all resource records sharing common names, types, and classes. Unlike any other RRSet, there is no corresponding RRSet+, i.e., there is no SIG RRSet+. Instead, individual SIG RR's are members of their type-covered's RRSet+. 3.5 Apex Name The domain name at the start of the zone. If a zone is secured, then the apex name will have at least a SOA RRSet+, a NS RRSet+, and a KEY RRSet+. A domain name which is an apex name appears in two zones, the "delegating" zone above the zone cut, and in the "delegated" zone, below the cut. The domain name is only considered an apex name in the delegated zone - it is not considered an apex name in the delegating zone. There is one apex name within a zone, and only it can have the zone key(s). 3.6 NXT Chain The NXT chain is comprised of all RRSet+s represented by the aggregate collection of all NXT records in a zone. The NXT chain includes all RRSet+s in a zone, not limited to just the NXT RRSet+s. Expires September 7, 1997 [Page 4] Internet Draft March 7, 1997 In UPDATE, there are cases in which some RRSet+s are not covered by an NXT RRSet+. Those records are not in the NXT chain. This point is raised here because UPDATE and this document disagree on the importance of including all RRSet+s by the NXT chain. But the term "NXT chain" is treated consistently by the two documents. A domain name is said to be in the chain if it owns at least one RRSet+ represented in the NXT chain. 3.7 NXT Walking NXT walking is the practice of repeatedly retrieving NXT records from a zone. The reason for doing this is to obtain information on a zone, presumably a list of all domain names within a zone. This is not a desired feature. The issues associated with NXT walking are discussed further in section 5. 3.8 Name Hiding Name hiding is the practice of "skipping" domain names in the NXT chain. The RRSet+s owned by hidden names are not in the NXT chain. It is possible a name to be both in the NXT chain (by having an NXT record) and have some RRSets excluded from the NXT chain by not having them represented in a NXT record. Name hiding is an issue within the scope of the NXT walking problem. In this document, hiding is discouraged as a defense against the walk, but it is not prohibited. There is no other reason to use name hiding. 3.9 $SIGNER directive: This is a new directive in BIND-style zone master files, akin to $INCLUDE and $ORIGIN. $SIGNER has the form: $SIGNER [<dname>] <dname> is a optional domain name - if present it is either fully qualified or prepended to the default name (e.g., $ORIGIN's value). If the dname value is absent, then the records following it (and preceding the next $SIGNER) are not signed. The value of $SIGNER may be changed repeatedly in a file, and does carry over a $INCLUDE. The $SIGNER directive has no impact on deciding which domain name signs NXT RRSets and KEY RRSets. (See section 4.1.) 3.10 Mode A/Mode B: In UPDATE, Mode A zones are zones for which the private zone key Expires September 7, 1997 [Page 5] Internet Draft March 7, 1997 is inaccessible to any on-line name server. In mode B, an on- line name server has access to the private zone key. (Multiple zone keys and name servers are possible, plurals are omitted here for editing purposes.) The impact is that RRSet+s signed in Mode A by the off-line key are immutable, but all RRSet+s in Mode B can be resigned by the name servers. 4.0 NXT Tenets The tenets listed here deviate at times from what is in UPDATE for Mode A. The authors have tried to note wherever the tenets deviate from UPDATE. For the purposes of examples in this section, assume that each portion of a master file (unless otherwise stated) is begun with the following: $ORIGIN cbml. $SIGNER cbml. @ SOA {SOA info} SIG SOA {sig info, signed by cbml.} NS {NS info} SIG NS {sig info, signed by cbml.} KEY {KEY info, flags => zone key} SIG KEY {sig info, signed by root} In some instances, what appears in brackets ({}) will have more detail, if being used to emphasize a point. 4.1 Control of the NXT RRSet+s All NXT's in a zone are controlled and signed by one of the zone keys of the apex name. Just as the apex name is granted the right to create names below it through the ownership of an NS record, the NXT chain which joins the RRSet+s belonging to the zone belongs to the apex name. The NXT chain does not descend through delegation points, just as a zone's naming authority does not. In breaking with DNS tradition, the NXT record "associated" with a domain name is not "owned" by the domain name. Each NXT record in a zone is owned by the apex name, although the records so-called owner field holds the name to which it is associated. This causes no special processing within DNS, a query for the apex name's (appropriate) NXT RRSet+ does not result in the receipt of all the NXT records in the zone, just one RRSet+. (What is appropriate is discussed in section 4.3.). Expires September 7, 1997 [Page 6] Internet Draft March 7, 1997 Example. c KEY {KEY info, flags = dynamic update} SIG KEY {sig info, signed by cbml.} $SIGNER c.cbml. A 10.43.123.5 SIG A {SIG info, signed by c.cbml.} NXT d.cbml. A KEY SIG NXT SIG NXT {sig info, signed by cbml.} $SIGNER cbml. d {some records} The SIG(NXT) is generated by cbml. It cannot be signed by c.cbml. The impact of the apex name's owning of an NXT RRSet+ associated with another domain name (within the zone) is that no domain name, other than the apex name, is permitted to add or change a NXT RRSet+. Under dynamic update, some domain names will be capable of adding and/or deleting other RRSet+s belonging to themselves and/or other names. When a dynamic update deletes or adds RRSet+s, the primary name server adjusts the NXT records affected and signs the changed NXT RRSet+s with an apex key just as it updates the SOA serial number. (This is contrary to UPDATE.) Restricting changes and signing of the NXT chain to the apex name is a necessity. A dynamic update request may not be able to determine the correct contents of an NXT record, or be allowed to sign an NXT record that it impacts. This is especially true considering possible race conditions that arise when trying to add both c1.cbml. and c2.cbml. between c.cbml. and d.cbml. 4.2 Signing of NXT RRSet+s Each NXT record MUST be signed by a private key owned by the apex name. The keys used need not be the same throughout the chain, e.g., some NXT's might be signed by an off-line zone key, others by the zone's dynamic update key (which could be the same key used to sign the updated SOA RR). An NXT RRSet MUST be signed by a key owned by the apex name. No other domain name can sign an NXT RRSet. SOA RRSet+s and NXT RRSet+s signed off-line (Mode A of dynamic update) can be altered by an update signed by an on-line key, unlike any other RRSet+ whose signature has been generated with an (off-line) zone key. (This is a deviation from UPDATE.) Expires September 7, 1997 [Page 7] Internet Draft March 7, 1997 Example. d {some records} NXT e.cbml. {the types} SIG NXT {signed by cbml., footprint=1} e {some records} NXT f.cbml. {the types} SIG NXT {signed by cbml., footprint=2} f {some records} Note that the footprints indicate a different KEY RR. 4.3 Wild Card Impact A wild card domain name is treated exactly the same way as any other domain name. The wild card sorts just prior to any of the names it matches, a wild card name matching all members of a zone appears after the apex name. Example. *.f KEY {KEY info} SIG KEY {signed by cbml.} NXT a.f.cbml. KEY SIG NXT SIG NXT {signed by cbml.} ; start of names matched by *.f.cbml. a.f A 10.75.23.19 SIG A {signed by *.f.cbml.} NXT g.cbml. A SIG NXT SIG NXT {signed by cbml.} ; end of *.f.cbml.'s matching names g {more records} Assume a query is issued for the TXT RRSet+ of b.f.cbml. In the example, there is no RRSet+ matching the query, so an NXT RRSet+ is to be returned. Which one, the NXT RRSet+ associated with a.f.cbml. or *.f.cbml.? The NXT RRSet+ associated with a.f.cbml. would be the alphabetically correct. But the search for the desired record ends after looking through *.f.cbml.'s records, so its NXT RRSet+ is at hand. The NXT RRSet+ associated with a.f.cbml. is returned, not the NXT RRSet+ associated with *.f.cbml. Even though the search for b.f.cbml. would wind up at *.f.cbml., the NXT RRSet+ returned is chosen without regard to the presence of a wild card. The wild card has no special meaning to the NXT. (This is contrary to UPDATE.) 4.4 Domain Name Ordering Prior to sorting labels, the label MUST be converted to the binary representation indicated by RFC 1035. Upper case characters in a domain name are to be converted to lower case before comparing. (The conversion to lower case is temporary - just for the purposes of the comparison.) In addition, the \DDD and \<special char> are to be converted into the binary equivalents. Expires September 7, 1997 [Page 8] Internet Draft March 7, 1997 Comparing domain names is done on a label by label basis, from right (root) to left. Within a label, bytes are compared left to right (in the same sequence of the network byte ordering). The lowest binary value of the first differing byte belongs to the prior name in the sort. If two labels are equivalent up to the end of one (but not the other) label, then the shorter label sorts prior. If two labels are equivalent, the comparison moves to the next labels to the left. Sorting based upon the form used in master files is incorrect. Examples. The following names are in sorted order: cbml., z.cbml., a.z.cbml. \000.cbml. \001.cbml. aname\.cbml. aname.cbml. The following names are equivalent: cbml. \067bml. \099bml. \042.cbml. \*.cbml. *.cbml. 4.5 Requirement for Existence A domain name with just an NXT RRSet+ is dropped from the zone in an authoritative name server. There will never be a valid NXT that only indicates the SIG and NXT type present. It is possible that just the NXT RRSet+ for a name may be in cache - if it is learned through a recursive lookup. Even in that case, the NXT will signify some other RRSet+ in its types present field. 4.6 Accurate and Dynamic Nature The NXT chain is dynamic. It is important for the correct functioning that the NXT chain be accurate and complete. The NXT chain, in order to be able to securely deny the existence of an RRSet+, MUST represent all present valid RRSet+s. (This is contrary to UPDATE, Mode A.) It may be tempting to modify the NXT chain to hide names, to either hide the existence of a particular name or to halt a NXT walk. If this is done, it opens a vulnerability to an attack in which a recorded NXT RRSet+ can be played back to deny the existence of existing RRSet+s. If there is a wild card matching the entire zone and its NXT RR next name is the apex itself, the zone is as open to a denial of service attack as if it simply relied on the SOA record return to deny existence, as is done in the pre-RFC 2065 DNS. 4.7 RRSet Inclusion in a NXT Chain Each RRSet that is associated with a domain name appears in the RR type list of the NXT RR if the zone is authoritative for at least the existence of the RRSet. This fine distinction is only Expires September 7, 1997 [Page 9] Internet Draft March 7, 1997 significant at delegation points. An apex name may have an assortment of RRSets (with some restrictions, such as no CNAME), each of which is within the zone's authority. But its counterpart entry in the delegating zone is different. In the delegating zone, a delegation MUST have a NS RRSet, a NXT RRSet, a KEY RRSet, and a SIG RRSet. Any other RRSet is invalid as input to the delegating zone via a master file. (A delegating zone may learn and cache other RRSets belonging to the apex name during operations.) The delegating zone is not authoritative for the contents of the NS RRSet+ and KEY RRSet+ members, but it is authoritative for the existence of those RRSet+s. The delegating zone makes it possible for the delegated zone to exist - by granting it an NS RRSet+. But it is up to the delegating zone to determine its fate, including the name of its name servers. Hence, the NXT RR type field for a delegation point domain name will always be "NS KEY SIG NXT." Note that an NXT type-covered field will always have a SIG RRSet denoted. If security is not in use, and no SIG RR's present, there would not be any NXT RR's to consider. Example. j NS {NS info} KEY {KEY info, flags => zone key} SIG KEY { signed by cbml.} NXT k.cbml. NS KEY SIG NXT SIG NXT {signed by cbml.} k {other records} and in the zone master file for j.cbml.: $ORIGIN j.cbml. $SIGNER j.cbml. @ SOA {SOA info} SIG SOA { signed by j.cbml.} NS {NS info} SIG NS { signed by j.cbml.} KEY {KEY info, flags => zone key} SIG KEY { signed by cbml.} RP {RP info} SIG RP { signed by j.cbml.} NXT b.j.cbml. NS SOA RP KEY SIG NXT SIG NXT { signed by j.cbml. } b {other records} Some (arbitrary) name server may wind up with both of the NXT RRSet+s for j.cbml. in its memory. The NXT RRSet+ to be returned (when required) can be determined by comparing the desired RRSet+ name with the next name in each NXT RRSet+. If the RRSet+ corresponding to the apex name (as opposed to the RRSet+ above the zone cut) matches more labels than the other RRSet+, it is returned. If the count of matching labels is Expires September 7, 1997 [Page 10]
Internet Draft March 7, 1997 equal, the RRSet+ corresponding to the delegating zone is returned. If a query is issued for a delegated name, and the query fails to match any RRSet+s for that name, then the NXT RRSet+ associated the delegated zone is returned. The delegated zone is authoritative for the contents of all of the records at the apex name. As stated in RFC2065, section 5.6, a query for the NXT records of a delegated name receives both NXT RRSet+s in the reply. Continuing with the previous example, assume that a query for a.j.cbml. is received. (Since a.j.cbml. does not exist, the query's type does not matter.) An NXT is to be returned from j.cbml., but which one? The two NXT RR's held by j.cbml. have next names b.j.cbml. and k.cbml. The failed name, a.j.cbml. is compared with b.j.cbml. and k.cbml. a.j.cbml. matches more labels in b.j.cbml. than in k.cbml (j.cbml. vs. cbml.). When the numbers of matching labels are different, the NXT RRSet+ corresponding to the longer match MUST be returned. In all cases, this will the NXT RRSet+ of the delegated zone. For a request for j1.cbml. which also does not exist, both b.j.cbml. and k.cbml. match equally well (just cbml.). When the numbers of matching labels are equal, the delegating zone NXT RRSet+ MUST be returned. Whether or not root is counted is immaterial, as long as the count is done consistently. Note: in RFC 2065, the label count field in the SIG RR is clearly defined to omit the root label, i.e., count it as label number 0. 4.8 Domain Name Inclusion in a NXT Chain Membership in the NXT chain is determined by zone membership rules. Membership is not determined by the name of the signer of the RRSet+. The use of alternate signers, e.g., wild card keys which are permitted to sign RRSet+s, does not impact the NXT chain. Changes caused by the use of such keys do not ripple into changes in the NXT chain. 4.9 One NXT Chain Per Zone There is no more than one NXT chain per zone. If the zone is secured, there will be exactly one chain. The NXT chain is complete and each member may have just one NXT RR in its lone NXT RRSet+. There are never "sub NXT chains," even if NXT walking is a concern. 4.10 NXT RDATA text version If the appearance of the next name in the NXT RR in a master Expires September 7, 1997 [Page 11]
Internet Draft March 7, 1997 file does not end in a period '.', then the default zone name (i.e., the value in $ORIGIN, or the value substituted for a '@') is to be appended to the name (separated by a period) before converting to a binary representation. This is the same as the semantics for other RR types that have domain names in the RDATA portion. The ordering of the RR types in the types present field is not significant, nor is case. The definitions of valid lexical representations is listed in Appendix A, section 11. 5.0 NXT chain "walking" Walking the NXT chain is a process in which a resolver can be used to discover the entire contents of a zone. In the pre-RFC 2065 DNS, a resolver could be prevented from systematically obtaining all of the records in a zone. Zone transfers can be administratively restricted to approved hosts - presumably the set of secondary name servers or locally connected machines. Although a resolver could query for all RRSet+s under one name, a query could not represent a query for all names. Inserting a wild card into a query resulted in just the return of records explicitly owned by a wild card entry. With the introduction of the NXT chain, there is a systematic means to discover the contents of a zone. Beginning with a query for an NXT RRSet for some name, in existence or not, a NXT RRSet+ is returned. By repeatedly requesting the NXT RRSet+ for another domain name, as indicated in a previously retrieved NXT RRSet+, one could build the complete NXT chain and know what is in the zone. Retrieving all of the (for example) RP RRSet+s would then be trivial. The reason this works is that NXT's prove non-existence by showing that there is no RRSet+ that would fit between a pair of domain names it does have. Each NXT return exposes two domain names for each failed lookup. If exposing two names is not done, then walking the NXT chain can be prevented or at least slowed. There are two ways to avoid having to expose two names. One is to expose just one domain name. The other means is to not disclose any names at all. "Bogus" next names, also called name hiding, may be accomplished as simply as having each NXT record indicate that the next name in the zone is (without loss of generality) the apex name. Example. (SIG RR's omitted to shorten.) l A {A info} NXT cbml. A SIG NXT m A {A info} NXT cbml. A SIG NXT n {other records} Expires September 7, 1997 [Page 12]
Internet Draft March 7, 1997 An interloper could claim n.cbml. does not exist by replaying the NXT record associated with either l.cbml. or m.cbml. But the recipient of a validly returned NXT record will not be able to use it to walk through the zone. There has been discussion of ways to hide all names from disclosure in the NXT. One method would return hashed values as opposed to plain text values for the names. The hashed values themselves would be valid names within the zone, but, unless that hashes also happened to own other records, would not themselves be represented in the NXT chain. (In this case, names would exist having just an NXT RRSet+, requiring a revision to section 4.5.) Currently, a zone administrator has the choice between limiting denial of existence attacks or being open to a DNS walk. In light of this, there is an open question of the degree to which DNS's "making information public" should be adhered. Currently zone transfers may be administratively prevented so as not to disclose the entire contents in one instant. In any case, applications should not rely solely on DNS, or a host's absence from DNS, for security services. Even if an Internet-attached computer has no DNS registered domain name, it can be reached and attacked. 6.0 Dynamic Maintenance of the NXT Chain In UPDATE, zones operating in Mode A do not alter the NXT chain as a result of dynamic updates. Since only wild card names owning their own dynamic update keys can create other domain names, a wild card NXT is a special case. The NXT indicates that the next name is the next domain name in the zone that does not match the wild card. Names matching the wild card are omitted from the chain. There are two reasons behind this. First is that, with the exception of the SOA RRSet+, no RRSet+ signed with the off-line private key can be changed, because no dynamic update key is considered strong enough to replace a signature generated by the off-line key. The exception made for the SOA is required for the need to increment the serial number. Part of the reason there is no key available is that the NXT RRSet+s until now have been assumed to be "owned" by the name holding them, opposed to section 4.1. The second reason is that some people have considered it desirable to hide names from the NXT chain. The authors feel that this is an incorrect approach to solving security problems, such as the NXT walk. The NXT chain, in its role of supporting verified authoritative denial of existence, needs to be a accurate representation of what is present. Expires September 7, 1997 [Page 13]
Internet Draft March 7, 1997 Further, the domain names and RRSet+s omitted from the NXT chain are relegated to a lower protection because they are more vulnerable to a denial of existence attack than RRSet+s represented by the NXT chain. By omitting the names from the chain, a zone is employing uneven security protection for its members. The authors propose that Mode A maintain a complete NXT chain. The barrier of not having a key available is addressed by treating all NXT RRSet+s as belonging to the apex name and using the same key that signs the SOA RRSet+ updates to sign all NXT RRSet+ updates. (The downside of this is that the number of signing operations required on the name server may double.) As far as the second reason, the desire to intentionally omit names to hide information, we argue that this is the wrong path to take to achieve these goals. An NXT chain that is incomplete is an unreliable source of information, source authenticated or not. 7.0 Acknowledgment Portions of this document, in particular the section suggesting hashing domain names for use in disrupting NXT walking, are based upon conversations with Donald Eastlake, 3rd. 8.0 Security Concerns This document addresses security enhancements to DNS. In particular, this document focuses on implementation level details of the NXT resource record which is used to authoritatively to indicate the absence of DNS data. (Combined with a SIG (NXT), also securely indicated the absence of data). This document presents details to assist in interoperability of software built according to RFC 2065, hopefully encouraging more rapid adoption of the DNSSEC security extensions. This document also discusses some open issues remaining, to hopefully arrive at an ever more secure and useable standard. 9.0 References [RFC2065] "Domain Name System Security Extensions," D. Eastlake, 3rd, and C. Kaufman http://ds.internic.net/rfc/rfc2065.txt [UPDATE] "Secure Domain Name System Dynamic Update," D. Eastlake, 3rd ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update- 04.txt [CLARIFY] "Clarifications to the DNS Specification," R. Elz, and R. Bush ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-clarify- 05.txt Expires September 7, 1997 [Page 14]
Internet Draft March 7, 1997 Also indirectly referenced: "Domain Names - Concepts and Facilities," RFC 1034, P. Mockapetris, http://ds.internic.net/rfc/rfc1034.txt "Domain Names - Implementation and Specification," RFC 1035, P. Mockapetris, http://ds.internic.net/rfc/rfc1035.txt "DNS and BIND," P. Albitz, and C. Liu, O'Reilly & Associates, 1992, ISBN 1-56592-236-0, http://www.ora.com/catalog/dns2/ index.html 10.0 Author's Addresses Edward Lewis Olafur Gudmundsson Trusted Information Systems Trusted Information Systems 3060 Washington Road 3060 Washington Road Glenwood, MD 21738 Glenwood, MD 21738 +1 301 854 5794 +1 301 854 5700 <lewis@tis.com> <ogud@tis.com> 11.0 Appendix A Definitions of NXT RR type-bit-map lexical representations Symbol Bit Position Meaning A 1 IPv4 Address NS 2 Name Server CNAME 5 Canonical Name SOA 6 Start of Authority MB 7 Mailbox Domain Name MG 8 Mail Group MR 9 Mail Rename WKS 11 Well Known Service PTR 12 Domain Name Pointer HINFO 13 Host Information MINFO 14 Mailbox Information MX 15 Mail Routing Information TXT 16 Text Strings RP 17 Responsible Person AFSDB 18 AFS Cell Database X25 19 X.25 Calling Address ISDN 20 ISDN Calling Address RT 21 Route Through NSAP 22 NSAP Address SIG 24 RRSet Signature KEY 25 Public Key PX 26 X.400 Mail Mapping AAAA 28 IPv6 Address LOC 29 Location Information NXT 30 Next Name in Zone EID 31 Endpoint Identifier NIMLOC 32 Nimrod Locator Expires September 7, 1997 [Page 15]
Internet Draft March 7, 1997 SRV 33 Server Selection ATMA 34 ATM Address See ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters for the up to date IANA list. These symbols MUST be recognized. As RR types are recognized by IANA, those symbols MUST be also recognized. Symbols for obsoleted or withdrawn records MUST be treated as errors. Those symbols are MD, MF, NSAP_PTR, and GPOS. Other symbols, such as NULL, and any with an IANA-assigned value over 250 MUST be treated as errors. Lewis and Gudmundsson [Page 16]