+++ /dev/null
-
-
-
-INTERNET-DRAFT Andreas Gustafsson
-draft-ietf-dnsext-axfr-clarify-05.txt Nominum Inc.
- November 2002
-
-
- DNS Zone Transfer Protocol Clarifications
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Abstract
-
- In the Domain Name System, zone data is replicated among
- authoritative DNS servers by means of the "zone transfer" protocol,
- also known as the "AXFR" protocol. This memo clarifies, updates, and
- adds missing detail to the original AXFR protocol specification in
- RFC1034.
-
-1. Introduction
-
- The original definition of the DNS zone transfer protocol consists of
- a single paragraph in [RFC1034] section 4.3.5 and some additional
- notes in [RFC1035] section 6.3. It is not sufficiently detailed to
- serve as the sole basis for constructing interoperable
- implementations. This document is an attempt to provide a more
- complete definition of the protocol. Where the text in RFC1034
- conflicts with existing practice, the existing practice has been
- codified in the interest of interoperability.
-
-
-
-
-Expires May 2003 [Page 1]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-2. The zone transfer request
-
- To initiate a zone transfer, the slave server sends a zone transfer
- request to the master server over a reliable transport such as TCP.
- The form of this request is specified in sufficient detail in RFC1034
- and needs no further clarification.
-
- Implementers are advised that one server implementation in widespread
- use sends AXFR requests where the TCP message envelope size exceeds
- the DNS request message size by two octets.
-
-3. The zone transfer response
-
- If the master server is unable or unwilling to provide a zone
- transfer, it MUST respond with a single DNS message containing an
- appropriate RCODE other than NOERROR. If the master is not
- authoritative for the requested zone, the RCODE SHOULD be 9
- (NOTAUTH).
-
- Slave servers should note that some master server implementations
- will simply close the connection when denying the slave access to the
- zone. Therefore, slaves MAY interpret an immediate graceful close of
- the TCP connection as equivalent to a "Refused" response (RCODE 5).
-
- If a zone transfer can be provided, the master server sends one or
- more DNS messages containing the zone data as described below.
-
-3.1. Multiple answers per message
-
- The zone data in a zone transfer response is a sequence of answer
- RRs. These RRs are transmitted in the answer section(s) of one or
- more DNS response messages.
-
- The AXFR protocol definition in RFC1034 does not make a clear
- distinction between response messages and answer RRs. Historically,
- DNS servers always transmitted a single answer RR per message. This
- encoding is wasteful due to the overhead of repeatedly sending DNS
- message headers and the loss of domain name compression
- opportunities. To improve efficiency, some newer servers support a
- mode where multiple RRs are transmitted in a single DNS response
- message.
-
- A master MAY transmit multiple answer RRs per response message up to
- the largest number that will fit within the 65535 byte limit on TCP
-
-
-
-Expires May 2003 [Page 2]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- DNS message size. In the case of a small zone, this can cause the
- entire transfer to be transmitted in a single response message.
-
- Slaves MUST accept messages containing any number of answer RRs. For
- compatibility with old slaves, masters that support sending multiple
- answers per message SHOULD be configurable to revert to the
- historical mode of one answer per message, and the configuration
- SHOULD be settable on a per-slave basis.
-
-3.2. DNS message header contents
-
- RFC1034 does not specify the contents of the DNS message header of
- the zone transfer response messages. The header of each message MUST
- be as follows:
-
- ID Copy from request
- QR 1
- OPCODE QUERY
- AA 1, but MAY be 0 when RCODE is not NOERROR
- TC 0
- RD Copy from request, or 0
- RA Set according to availability of recursion, or 0
- Z 0
- AD 0
- CD 0
- RCODE NOERROR on success, error code otherwise
-
- The slave MUST check the RCODE in each message and abort the transfer
- if it is not NOERROR. It SHOULD check the ID of the first message
- received and abort the transfer if it does not match the ID of the
- request. The ID SHOULD be ignored in subsequent messages, and fields
- other than RCODE and ID SHOULD be ignored in all messages, to ensure
- interoperability with certain older implementations which transmit
- incorrect or arbitrary values in these fields.
-
-3.3. Additional section and SIG processing
-
- Zone transfer responses are not subject to any kind of additional
- section processing or automatic inclusion of SIG records. SIG RRs in
- the zone data are treated exactly the same as any other RR type.
-
-3.4. The question section
-
- RFC1034 does not specify whether zone transfer response messages have
- a question section or not. The initial message of a zone transfer
- response SHOULD have a question section identical to that in the
- request. Subsequent messages SHOULD NOT have a question section,
- though the final message MAY. The receiving slave server MUST accept
-
-
-
-Expires May 2003 [Page 3]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- any combination of messages with and without a question section.
-
-3.5. The authority section
-
- The master server MUST transmit messages with an empty authority
- section. Slaves MUST ignore any authority section contents they may
- receive from masters that do not comply with this requirement.
-
-3.6. The additional section
-
- The additional section MAY contain additional RRs such as transaction
- signatures. The slave MUST ignore any unexpected RRs in the
- additional section. It MUST NOT treat additional section RRs as zone
- data.
-
-4. Zone data
-
- The purpose of the zone transfer mechanism is to exactly replicate at
- each slave the set of RRs associated with a particular zone at its
- primary master. An RR is associated with a zone by being loaded from
- the master file of that zone at the primary master server, or by some
- other, equivalent method for configuring zone data.
-
- This replication shall be complete and unaltered, regardless of how
- many and which intermediate masters/slaves are involved, and
- regardless of what other zones those intermediate masters/slaves do
- or do not serve, and regardless of what data may be cached in
- resolvers associated with the intermediate masters/slaves.
-
- Therefore, in a zone transfer the master MUST send exactly those
- records that are associated with the zone, whether or not their owner
- names would be considered to be "in" the zone for purposes of
- resolution, and whether or not they would be eligible for use as glue
- in responses. The transfer MUST NOT include any RRs that are not
- associated with the zone, such as RRs associated with zones other
- than the one being transferred or present in the cache of the local
- resolver, even if their owner names are in the zone being transferred
- or are pointed to by NS records in the zone being transferred.
-
- The slave MUST associate the RRs received in a zone transfer with the
- specific zone being transferred, and maintain that association for
- purposes of acting as a master in outgoing transfers.
-
-5. Transmission order
-
- RFC1034 states that "The first and last messages must contain the
- data for the top authoritative node of the zone". This is not
- consistent with existing practice. All known master implementations
-
-
-
-Expires May 2003 [Page 4]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- send, and slave implementations expect to receive, the zone's SOA RR
- as the first and last record of the transfer.
-
- Therefore, the quoted sentence is hereby superseded by the sentence
- "The first and last RR transmitted must be the SOA record of the
- zone".
-
- The initial and final SOA record MUST be identical, with the possible
- exception of case and compression. In particular, they MUST have the
- same serial number. The slave MUST consider the transfer to be
- complete when, and only when, it has received the message containing
- the second SOA record.
-
- The transmission order of all other RRs in the zone is undefined.
- Each of them SHOULD be transmitted only once, and slaves MUST ignore
- any duplicate RRs received.
-
-6. Security Considerations
-
- The zone transfer protocol as defined in [RFC1034] and clarified by
- this memo does not have any built-in mechanisms for the slave to
- securely verify the identity of the master server and the integrity
- of the transferred zone data. The use of a cryptographic mechanism
- for ensuring authenticity and integrity, such as TSIG [RFC2845],
- IPSEC, or TLS, is RECOMMENDED.
-
- The zone transfer protocol allows read-only public access to the
- complete zone data. Since data in the DNS is public by definition,
- this is generally acceptable. Sites that wish to avoid disclosing
- their full zone data MAY restrict zone transfer access to authorized
- slaves.
-
- These clarifications are not believed to themselves introduce any new
- security problems, nor to solve any existing ones.
-
-Acknowledgements
-
- Many people have contributed input and commentary to earlier versions
- of this document, including but not limited to Bob Halley, Dan
- Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
- Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
- Trenholme, and Brian Wellington.
-
-References
-
- [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
- November 1987.
-
-
-
-
-Expires May 2003 [Page 5]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- [RFC1035] - Domain Names - Implementation and Specifications, P.
- Mockapetris, November 1987.
-
- [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
- S. Bradner, BCP 14, March 1997.
-
- [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P.
- Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
-
-Author's Address
-
- Andreas Gustafsson
- Nominum Inc.
- 2385 Bay Rd
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6004
-
- Email: gson@nominum.com
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000 - 2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implmentation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-
-
-
-Expires May 2003 [Page 6]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May 2003 [Page 7]
-\f
-
+++ /dev/null
-
-
-
-Network Working Group S. Weiler
-Internet-Draft SPARTA, Inc
-Updates: 4034, 4035 (if approved) May 23, 2005
-Expires: November 24, 2005
-
-
- Clarifications and Implementation Notes for DNSSECbis
- draft-ietf-dnsext-dnssec-bis-updates-01
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- 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."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on November 24, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This document is a collection of minor technical clarifications to
- the DNSSECbis document set. It is meant to serve as a resource to
- implementors as well as an interim repository of possible DNSSECbis
- errata.
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 1]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-Proposed additions in future versions
-
- An index sorted by the section of DNSSECbis being clarified.
-
- A list of proposed protocol changes being made in other documents,
- such as NSEC3 and Epsilon. This document would not make those
- changes, merely provide an index into the documents that are making
- changes.
-
-Changes between -00 and -01
-
- Document significantly restructured.
-
- Added section on QTYPE=ANY.
-
-Changes between personal submission and first WG draft
-
- Added Section 2.1 based on namedroppers discussions from March 9-10,
- 2005.
-
- Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
-
- Added the DNSSECbis RFC numbers.
-
- Figured out the confusion in Section 4.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 2]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-Table of Contents
-
- 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
- 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4
- 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4
- 2.1 Clarifications on Non-Existence Proofs . . . . . . . . . . 4
- 2.2 Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5
- 2.3 Validating Responses to an ANY Query . . . . . . . . . . . 5
- 3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
- 3.1 Unknown DS Message Digest Algorithms . . . . . . . . . . . 5
- 3.2 Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
- 3.3 Caution About Local Policy and Multiple RRSIGs . . . . . . 6
- 3.4 Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
- 4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7
- 4.1 Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7
- 4.2 Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7
- 4.3 Errors in Examples . . . . . . . . . . . . . . . . . . . . 8
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8
- 7.2 Informative References . . . . . . . . . . . . . . . . . . 9
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
- A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
- Intellectual Property and Copyright Statements . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 3]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-1. Introduction and Terminology
-
- This document lists some minor clarifications and corrections to
- DNSSECbis, as described in [1], [2], and [3].
-
- It is intended to serve as a resource for implementors and as a
- repository of items that need to be addressed when advancing the
- DNSSECbis documents from Proposed Standard to Draft Standard.
-
- In this version (-01 of the WG document), feedback is particularly
- solicited on the structure of the document and whether the text in
- the recently added sections is correct and sufficient.
-
- Proposed substantive additions to this document should be sent to the
- namedroppers mailing list as well as to the editor of this document.
- The editor would greatly prefer text suitable for direct inclusion in
- this document.
-
-1.1 Structure of this Document
-
- The clarifications to DNSSECbis are sorted according to the editor's
- impression of their importance, starting with ones which could, if
- ignored, lead to security and stability problems and progressing down
- to clarifications that are likely to have little operational impact.
- Mere typos and awkward phrasings are not addressed unless they could
- lead to misinterpretation of the DNSSECbis documents.
-
-1.2 Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [4].
-
-2. Significant Concerns
-
- This section provides clarifications that, if overlooked, could lead
- to security issues or major interoperability problems.
-
-2.1 Clarifications on Non-Existence Proofs
-
- RFC4035 Section 5.4 slightly underspecifies the algorithm for
- checking non-existence proofs. In particular, the algorithm there
- might incorrectly allow the NSEC from the parent side of a zone cut
- to prove the non-existence of either other RRs at that name in the
- child zone or other names in the child zone. It might also allow a
- NSEC at the same name as a DNAME to prove the non-existence of names
- beneath that DNAME.
-
-
-
-
-Weiler Expires November 24, 2005 [Page 4]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- A parent-side delegation NSEC (one with the NS bit set, but no SOA
- bit set, and with a singer field that's shorter than the owner name)
- must not be used to assume non-existence of any RRs below that zone
- cut (both RRs at that ownername and at ownernames with more leading
- labels, no matter their content). Similarly, an NSEC with the DNAME
- bit set must not be used to assume the non-existence of any
- descendant of that NSEC's owner name.
-
-2.2 Empty Non-Terminal Proofs
-
- To be written, based on Roy Arends' May 11th message to namedroppers.
-
-2.3 Validating Responses to an ANY Query
-
- RFC4035 does not address now to validate responses when QTYPE=*. As
- described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
- may include a subset of the RRsets at a given name -- it is not
- necessary to include all RRsets at the QNAME in the response.
-
- When validating a response to QTYPE=*, validate all received RRsets
- that match QNAME and QCLASS. If any of those RRsets fail validation,
- treat the answer as Bogus. If there are no RRsets matching QNAME and
- QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
- clarified in this document). To be clear, a validator must not
- insist on receiving all records at the QNAME in response to QTYPE=*.
-
-3. Interoperability Concerns
-
-3.1 Unknown DS Message Digest Algorithms
-
- Section 5.2 of RFC4035 includes rules for how to handle delegations
- to zones that are signed with entirely unsupported algorithms, as
- indicated by the algorithms shown in those zone's DS RRsets. It does
- not explicitly address how to handle DS records that use unsupported
- message digest algorithms. In brief, DS records using unknown or
- unsupported message digest algorithms MUST be treated the same way as
- DS records referring to DNSKEY RRs of unknown or unsupported
- algorithms.
-
- The existing text says:
-
- If the validator does not support any of the algorithms listed
- in an authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
-
-
-
-Weiler Expires November 24, 2005 [Page 5]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- To paraphrase the above, when determining the security status of a
- zone, a validator discards (for this purpose only) any DS records
- listing unknown or unsupported algorithms. If none are left, the
- zone is treated as if it were unsigned.
-
- Modified to consider DS message digest algorithms, a validator also
- discards any DS records using unknown or unsupported message digest
- algorithms.
-
-3.2 Private Algorithms
-
- As discussed above, section 5.2 of RFC4035 requires that validators
- make decisions about the security status of zones based on the public
- key algorithms shown in the DS records for those zones. In the case
- of private algorithms, as described in RFC4034 Appendix A.1.1, the
- eight-bit algorithm field in the DS RR is not conclusive about what
- algorithm(s) is actually in use.
-
- If no private algorithms appear in the DS set or if any supported
- algorithm appears in the DS set, no special processing will be
- needed. In the remaining cases, the security status of the zone
- depends on whether or not the resolver supports any of the private
- algorithms in use (provided that these DS records use supported hash
- functions, as discussed in Section 3.1). In these cases, the
- resolver MUST retrieve the corresponding DNSKEY for each private
- algorithm DS record and examine the public key field to determine the
- algorithm in use. The security-aware resolver MUST ensure that the
- hash of the DNSKEY RR's owner name and RDATA matches the digest in
- the DS RR. If they do not match, and no other DS establishes that
- the zone is secure, the referral should be considered BAD data, as
- discussed in RFC4035.
-
- This clarification facilitates the broader use of private algorithms,
- as suggested by [5].
-
-3.3 Caution About Local Policy and Multiple RRSIGs
-
- When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
- suggests that "the local resolver security policy determines whether
- the resolver also has to test these RRSIG RRs and how to resolve
- conflicts if these RRSIG RRs lead to differing results." In most
- cases, a resolver would be well advised to accept any valid RRSIG as
- sufficient. If the first RRSIG tested fails validation, a resolver
- would be well advised to try others, giving a successful validation
- result if any can be validated and giving a failure only if all
- RRSIGs fail validation.
-
- If a resolver adopts a more restrictive policy, there's a danger that
-
-
-
-Weiler Expires November 24, 2005 [Page 6]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- properly-signed data might unnecessarily fail validation, perhaps
- because of cache timing issues. Furthermore, certain zone management
- techniques, like the Double Signature Zone-signing Key Rollover
- method described in section 4.2.1.2 of [6] might not work reliably.
-
-3.4 Key Tag Calculation
-
- RFC4034 Appendix B.1 incorrectly defines the Key Tag field
- calculation for algorithm 1. It correctly says that the Key Tag is
- the most significant 16 of the least significant 24 bits of the
- public key modulus. However, RFC4034 then goes on to incorrectly say
- that this is 4th to last and 3rd to last octets of the public key
- modulus. It is, in fact, the 3rd to last and 2nd to last octets.
-
-4. Minor Corrections and Clarifications
-
-4.1 Finding Zone Cuts
-
- Appendix C.8 of RFC4035 discusses sending DS queries to the servers
- for a parent zone. To do that, a resolver may first need to apply
- special rules to discover what those servers are.
-
- As explained in Section 3.1.4.1 of RFC4035, security-aware name
- servers need to apply special processing rules to handle the DS RR,
- and in some situations the resolver may also need to apply special
- rules to locate the name servers for the parent zone if the resolver
- does not already have the parent's NS RRset. Section 4.2 of RFC4035
- specifies a mechanism for doing that.
-
-4.2 Clarifications on DNSKEY Usage
-
- Questions of the form "can I use a different DNSKEY for signing the
- X" have occasionally arisen.
-
- The short answer is "yes, absolutely". You can even use a different
- DNSKEY for each RRset in a zone, subject only to practical limits on
- the size of the DNSKEY RRset. However, be aware that there is no way
- to tell resolvers what a particularly DNSKEY is supposed to be used
- for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
- authenticate any RRset in the zone. For example, if a weaker or less
- trusted DNSKEY is being used to authenticate NSEC RRsets or all
- dynamically updated records, that same DNSKEY can also be used to
- sign any other RRsets from the zone.
-
- Furthermore, note that the SEP bit setting has no effect on how a
- DNSKEY may be used -- the validation process is specifically
- prohibited from using that bit by RFC4034 section 2.1.2. It possible
- to use a DNSKEY without the SEP bit set as the sole secure entry
-
-
-
-Weiler Expires November 24, 2005 [Page 7]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- point to the zone, yet use a DNSKEY with the SEP bit set to sign all
- RRsets in the zone (other than the DNSKEY RRset). It's also possible
- to use a single DNSKEY, with or without the SEP bit set, to sign the
- entire zone, including the DNSKEY RRset itself.
-
-4.3 Errors in Examples
-
- The text in RFC4035 Section C.1 refers to the examples in B.1 as
- "x.w.example.com" while B.1 uses "x.w.example". This is painfully
- obvious in the second paragraph where it states that the RRSIG labels
- field value of 3 indicates that the answer was not the result of
- wildcard expansion. This is true for "x.w.example" but not for
- "x.w.example.com", which of course has a label count of 4
- (antithetically, a label count of 3 would imply the answer was the
- result of a wildcard expansion).
-
- The first paragraph of RFC4035 Section C.6 also has a minor error:
- the reference to "a.z.w.w.example" should instead be "a.z.w.example",
- as in the previous line.
-
-5. IANA Considerations
-
- This document specifies no IANA Actions.
-
-6. Security Considerations
-
- This document does not make fundamental changes to the DNSSEC
- protocol, as it was generally understood when DNSSECbis was
- published. It does, however, address some ambiguities and omissions
- in those documents that, if not recognized and addressed in
- implementations, could lead to security failures. In particular, the
- validation algorithm clarifications in Section 2 are critical for
- preserving the security properties DNSSEC offers. Furthermore,
- failure to address some of the interoperability concerns in Section 3
- could limit the ability to later change or expand DNSSEC, including
- by adding new algorithms.
-
-7. References
-
-7.1 Normative References
-
- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Weiler Expires November 24, 2005 [Page 8]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-7.2 Informative References
-
- [5] Blacka, D., "DNSSEC Experiments",
- draft-blacka-dnssec-experiments-00 (work in progress),
- December 2004.
-
- [6] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
- draft-ietf-dnsop-dnssec-operational-practices-04 (work in
- progress), May 2005.
-
-
-Author's Address
-
- Samuel Weiler
- SPARTA, Inc
- 7075 Samuel Morse Drive
- Columbia, Maryland 21046
- US
-
- Email: weiler@tislabs.com
-
-Appendix A. Acknowledgments
-
- The editor is extremely grateful to those who, in addition to finding
- errors and omissions in the DNSSECbis document set, have provided
- text suitable for inclusion in this document.
-
- The lack of specificity about handling private algorithms, as
- described in Section 3.2, and the lack of specificity in handling ANY
- queries, as described in Section 2.3, were discovered by David
- Blacka.
-
- The error in algorithm 1 key tag calculation, as described in
- Section 3.4, was found by Abhijit Hayatnagarkar. Donald Eastlake
- contributed text for Section 3.4.
-
- The bug relating to delegation NSEC RR's in Section 2.1 was found by
- Roy Badami. Roy Arends found the related problem with DNAME.
-
- The errors in the RFC4035 examples were found by Roy Arends, who also
- contributed text for Section 4.3 of this document.
-
-
-
-Weiler Expires November 24, 2005 [Page 9]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- The editor would like to thank Olafur Gudmundsson and Scott Rose for
- their substantive comments on the text of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 10]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Weiler Expires November 24, 2005 [Page 11]
-\f
+++ /dev/null
-
-
-
-DNS Extensions working group J. Jansen
-Internet-Draft NLnet Labs
-Expires: July 5, 2006 January 2006
-
-
- Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC
- draft-ietf-dnsext-dnssec-rsasha256-00
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- 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."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on July 5, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG
- resource records for use in the Domain Name System Security
- Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).
-
-
-
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 1]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3
- 3. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . . . 3
- 4. Implementation Considerations . . . . . . . . . . . . . . . . . 4
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 5
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
- Intellectual Property and Copyright Statements . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 2]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical distributed
- database for Internet Addressing. The DNS has been extended to use
- digital signatures and cryptographic keys for the verification of
- data. RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS
- Security Extensions.
-
- RFC4034 describes how to store DNSKEY and RRSIG resource records, and
- specifies a list of cryptographic algorithms to use. This document
- extends that list with the algorithm RSA/SHA-256, and specifies how
- to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG
- resource records.
-
- Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in
- this document.
-
-
-2. RSA/SHA-256 DNSKEY Resource Records
-
- RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
- resource records (RRs) with the algorithm number [TBA].
-
- The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110
- [6].
-
-
-3. RSA/SHA-256 RRSIG Resource Records
-
- RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
- records (RRs) with algorithm number [TBA].
-
- The value of the signature field in the RRSIG RR is calculated as
- follows. The values for the fields that precede the signature data
- are specified in RFC4034 [2].
-
- hash = SHA-256(data)
-
- signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
- Where SHA-256 is the message digest algorithm as specified in FIPS
- 180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of
- corresponding hexadecimal value, "e" is the private exponent of the
- signing RSA key, and "n" is the public modulus of the signing key.
- The FF octet MUST be repeated the maximum number of times so that the
- total length of the signature equals the length of the modulus of the
- signer's public key ("n"). "data" is the data of the resource record
- set that is signed, as specified in RFC4034 [2].
-
-
-
-Jansen Expires July 5, 2006 [Page 3]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
- The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as
- specified in PKCS 2.1 [4]:
-
- hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
-
- This prefix should make the use of standard cryptographic libraries
- easier. These specifications are taken directly from PKCS #1 v2.1
- section 9.2 [4].
-
-
-4. Implementation Considerations
-
- DNSSEC aware implementations MUST be able to support RRSIG resource
- records with the RSA/SHA-256 algorithm.
-
- If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are
- available for a certain rrset, with a secure path to their keys, the
- validator SHOULD ignore the SHA-1 signature. If the RSA/SHA-256
- signature does not verify the data, and the RSA/SHA-1 does, the
- validator SHOULD mark the data with the security status from the RSA/
- SHA-256 signature.
-
-
-5. IANA Considerations
-
- IANA has not yet assigned an algorithm number for RSA/SHA-256.
-
- The algorithm list from RFC4034 Appendix A.1 [2] is extended with the
- following entry:
-
- Zone
- Value Algorithm [Mnemonic] Signing References Status
- ----- ----------- ----------- -------- ---------- ---------
- [tba] RSA/SHA-256 [RSASHA256] y [TBA] MANDATORY
-
-
-6. Security Considerations
-
- Recently, weaknesses have been discovered in the SHA-1 hashing
- algorithm. It is therefore strongly encouraged to deploy SHA-256
- where SHA-1 is used now, as soon as the DNS software supports it.
-
- SHA-256 is considered sufficiently strong for the immediate future,
- but predictions about future development in cryptography and
- cryptanalysis are beyond the scope of this document.
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 4]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-7. Acknowledgments
-
- This document is a minor extension to RFC4034 [2]. Also, we try to
- follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt
- [8] for consistency. The authors of and contributors to these
- documents are gratefully acknowledged for their hard work.
-
- The following people provided additional feedback and text: Jaap
- Akkerhuis, Miek Gieben and Wouter Wijngaards.
-
-
-8. References
-
-8.1. Normative References
-
- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
- (PKCS) #1: RSA Cryptography Specifications Version 2.1",
- RFC 3447, February 2003.
-
- [5] National Institute of Standards and Technology, "Secure Hash
- Standard", FIPS PUB 180-2, August 2002.
-
- [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
- System (DNS)", RFC 3110, May 2001.
-
-8.2. Informative References
-
- [7] Schneier, B., "Applied Cryptography Second Edition: protocols,
- algorithms, and source code in C", Wiley and Sons , ISBN 0-471-
- 11709-9, 1996.
-
- [8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
- Resource Records (RRs)", Work in Progress Feb 2006.
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 5]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-Author's Address
-
- Jelte Jansen
- NLnet Labs
- Kruislaan 419
- Amsterdam 1098VA
- NL
-
- Email: jelte@NLnetLabs.nl
- URI: http://www.nlnetlabs.nl/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 6]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Jansen Expires July 5, 2006 [Page 7]
-\f
+++ /dev/null
-
-
-
-DNS Extensions (DNSEXT) A. Hubert
-Internet-Draft Netherlabs Computer Consulting BV.
-Updates: 1035 R. van Mook
-Intended status: Standards Track Virtu
-Expires: July 15, 2007 January 11, 2007
-
-
- Measures for making DNS more resilient against forged answers
- draft-ietf-dnsext-forgery-resilience-00.txt
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- 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."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on July 15, 2007.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2007).
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 1]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-Abstract
-
- The current internet climate poses serious threats to the Domain Name
- System. In the interim period before the DNS protocol can be secured
- more fully, measures can already be taken to make 'spoofing' a
- recursing nameserver many orders of magnitude harder.
-
- Even a cryptographically secured DNS benefits from having the ability
- to discard bogus answers quickly, as this potentially saves large
- amounts of computation.
-
- By describing certain behaviour that has previously not been
- standardised, this document sets out how to make the DNS more
- resilient against accepting incorrect answers. This document updates
- RFC1034.
-
-
-Table of Contents
-
- 1. Requirements and definitions . . . . . . . . . . . . . . . . . 3
- 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 6
- 4. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 4.1. Matching the question . . . . . . . . . . . . . . . . . . 7
- 4.2. Matching the ID field . . . . . . . . . . . . . . . . . . 8
- 4.3. Matching the source address of the authentic answer . . . 8
- 4.4. Matching the destination address of the authentic
- answer . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4.5. Have the answer arrive before the authentic answer . . . . 9
- 5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10
- 6. Accepting only in-zone answers . . . . . . . . . . . . . . . . 11
- 7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 12
- 7.1. Symbols used in calculation . . . . . . . . . . . . . . . 12
- 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 13
- 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
- 9. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16
- 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
- 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
- 12. Normative References . . . . . . . . . . . . . . . . . . . . . 20
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
- Intellectual Property and Copyright Statements . . . . . . . . . . 22
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 2]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-1. Requirements and definitions
-
-1.1. Definitions
-
- This document uses the following definitions:
-
- Client: typically a 'stub-resolver' on an end-user's computer
-
- Resolver: a nameserver performing recursive service for clients,
- also known as a caching server
-
- Question: a question sent out by a resolver, typically in a UDP
- packet
-
- Answer: the answer sent back by an authoritative nameserver,
- typically in a UDP packet
-
- Third party: any host other than the resolver or the intended
- recipient of a question. The third party may have access to a
- random authoritative nameserver, but has no access to packets
- transmitted by the Resolver ot authoritative server
-
- Attacker: malicious third party.
-
- Spoof: the activity of attempting to subvert the DNS process by
- getting a chosen answer accepted
-
- Authentic answer: the answer that would be accepted if no third
- party interferes
-
- Target domain: domain for which the attacker wishes to spoof in an
- answer
-
- Fake data: answer chosen by the attacker
-
- TBD: Do we need to talk about stub resolvers? Does this draft apply
- to them?
-
-1.2. Key words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 3]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-2. Introduction
-
- This document describes several common problems in DNS
- implementations which, although previously recognized, remain largely
- unsolved. Besides briefly recapping these problems, this RFC
- contains rules that, if implemented, make complying resolvers vastly
- more resistant to the attacks described.
-
- Almost every transaction on the internet involves the Domain Name
- System, which is described in [RFC1034], [RFC1035] and beyond.
-
- Additionally, it has recently become possible to acquire SSL
- certificates with no other confirmation of identity than the ability
- to respond to a verification email sent via SMTP ([RFC2821]) - which
- generally uses DNS for its routing.
-
- In other words, any party that (temporarily) controls the Domain Name
- System is in a position to reroute most kinds of Internet
- transactions, including the verification steps in acquiring an SSL
- certificate for a domain. This in turn means that even transactions
- protected by SSL could be diverted.
-
- It is entirely conceivable that such rerouted traffic could be used
- to the disadvantage of internet users.
-
- These and other developments have made the security and
- trustworthiness of DNS of renewed importance. Although the DNS
- community is working hard on finalising and implementing a
- cryptographically enhanced DNS protocol, steps should be taken to
- make sure that the existing use of DNS is as secure as possible
- within the bounds of the relevant standards.
-
- It should be noted that the most commonly used resolver currently
- does not perform as well as possible in this respect, making this
- document of urgent importance.
-
- A thorough analysis of risks facing DNS can be found in [RFC3833].
-
- This document expands on some of the risks mentioned in RFC 3833,
- especially those outlined in the sections on 'ID Guessing and Query
- Prediction' and 'Name Chaining'. Furthermore, it emphasises a number
- of existing rules and guidelines embodied in the relevant STDs and
- RFCs. The following also specifies new requirements to make sure the
- Domain Name System can be relied upon until a more secure protocol
- has been standardised and deployed.
-
- It should be noted that even when all measures suggested below are
- implemented, protocol users are not protected against third parties
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 4]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
- with the ability to intercept, change or inject packets sent to the
- resolver.
-
- For protocol extensions under development that offer protection
- against these scenarios, see [RFC4033] and beyond.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 5]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-3. Description of DNS spoofing
-
- When certain steps are taken it is feasible to 'spoof' the current
- deployed majority of caching resolvers with carefully crafted and
- timed DNS packets. Once spoofed, a caching server will repeat the
- data it wrongfully accepted, and make its clients contact the wrong,
- and possibly malicious, servers.
-
- To understand how this process works it is important to know what
- makes a resolver (and more specifically a caching server) accept an
- answer.
-
- Section 5.3.3 of [RFC1034] presaged the present problem:
-
- The resolver should be highly paranoid in its parsing of responses.
- It should also check that the response matches the query it sent
- using the ID field in the response.
-
- DNS data is accepted by a resolver if and only if:
-
- 1. The question section of the reply packet is identical to that of
- a question packet currently waiting for an answer
-
- 2. The ID field of the reply packet matches that of the question
- packet
-
- 3. The answer comes from the same network address the question was
- sent to
-
- 4. The answer comes in on the same network address, including port
- number, as the question was sent from
-
- 5. It is the first answer to match the previous four conditions.
-
- Note that the fifth condition can strictly speaking be derived from
- the first. It is included for clarity reasons only.
-
- If a third party succeeds in meeting the first four conditions before
- the answer from the authentic answer does so, it is in a position to
- feed a resolver fabricated data. When it does so, we dub it an
- attacker, attempting to spoof in fake data.
-
- All conditions mentioned above can theoretically be met, with the
- difficulty being a function of the resolver implementation and zone
- configuration.
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 6]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-4. Details
-
- The previous paragraph discussed a number of requirements an attacker
- must match in order to spoof in manipulated (or fake) data. This
- section discusses the relative difficulties and how implementation
- defined choices impact the amount of work an attacker has to perform
- to meet said difficulties.
-
- Some more details can be found in section 2.2 of [RFC3833].
-
-4.1. Matching the question
-
- Formally, there is no need for a nameserver to perform service except
- for its operator, its customers or more generally its users.
- Recently, open recursing nameservers have been used to amplify denial
- of service attacks.
-
- In spite of this, many resolvers perform at least partial service for
- the whole world. This is partially out of lack of concern, and is
- reminiscent of the open relay SMTP service the net enjoyed up to the
- early 1990s. Some access providers may serve so many subnets that it
- is hard to enumerate these all in the DNS configuration.
-
- Providing full service enables the third party to send the target
- resolver a question for the domain name it intends to spoof. On
- receiving this question, and not finding the answer in its cache, the
- resolver will transmit questions to relevant authoritative
- nameservers. This opens up a window of opportunity for getting fake
- answer data accepted.
-
- Some operators restrict access by not recursing for unauthorised IP
- addresses, but only respond with data from the cache. This makes
- spoofing harder for a third party as it cannot then force the exact
- moment a question will be asked. It is still possible however to
- determine a time range when this will happen, because nameservers
- helpfully publish the decreasing TTL of entries in the cache, which
- indicate from which absolute time onwards a new query could be sent
- to refresh the expired entry.
-
- The time to live of the 'target domain' determines how often a window
- of opportunity is available, which implies that a short TTL makes
- spoofing far more viable.
-
- Note that the attacker might very well have authorised access to the
- target resolver by virtue of being a customer or employee of its
- operator.
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 7]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-4.2. Matching the ID field
-
- The DNS ID field is 16 bits wide, meaning that if full use is made of
- all these bits, and if their contents are truly random, it will
- require on average 32768 attempts to guess. Anecdotal evidence
- suggests there are implementations utilising only 14 bits, meaning on
- average 8192 attempts will suffice.
-
- Additionally, if the target nameserver can be forced into having
- multiple identical questions outstanding, the 'Birthday Attack'
- phenomenon means that any fake data sent by the attacker is matched
- against multiple outstanding questions, significantly raising the
- chance of success. Further details in Section 5.
-
-4.3. Matching the source address of the authentic answer
-
- Most domains have two or three authoritative nameservers, which make
- matching the source address of the authentic answer very likely with
- even a naive choice having a double digit success rate.
-
- Most recursing nameservers store relative performance indications of
- authoritative nameservers, which may make it easier to predict which
- nameserver would originally be queried - the one most likely to
- respond the quickest.
-
- Generally, this condition requires at most two or three attempts
- before it is matched.
-
- It should be noted that meeting this condition entails being able to
- transmit packets on behalf of the address of the authoritative
- nameserver. While several important documents ([RFC2827] and
- [RFC3013] specifically) direct internet access providers to prevent
- their customers from assuming IP addresses that are not assigned to
- them, these recommendations are not universally (nor even widely)
- implemented.
-
-4.4. Matching the destination address of the authentic answer
-
- Note that the destination address of the authentic answer is the
- source address of the original question.
-
- The actual address of a recursing nameserver is generally known; the
- port used for asking questions is harder to determine. Most current
- resolvers pick a random port at startup and use this for all outgoing
- questions. In quite a number of cases the source port of outgoing
- questions is fixed at the traditional DNS assigned port of 53.
-
- If the source port of the original question is random, but static,
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 8]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
- any authoritative nameserver under observation by the attacker can be
- used to determine this port. This means that matching this
- conditions often requires no guess work.
-
- If multiple ports are used for sending questions, this enlarges the
- effective address space by a factor equal to the number of ports
- used.
-
- Less common resolving servers choose a random port per outgoing
- question. If this strategy is followed, this port number can be
- regarded as an additional ID field, again containing up to 16 bits.
-
- If the maximum ports range is utilized, on average, around 32128
- source ports would have to be tried before matching the source port
- of the original question as ports below 1024 may be unavailable for
- use, leaving 64512 options.
-
- It should be noted that a firewall will not prevent the matching of
- this address, as it will accept answers that (appear) to come from
- the correct address, offering no additional security.
-
-4.5. Have the answer arrive before the authentic answer
-
- Once any packet has matched the previous four conditions, no further
- answers should be accepted.
-
- This means that the third party has a limited time in which to inject
- its spoofed answer, typically in the order of at most 100ms.
-
- This time period can be far longer if the authentic authoritative
- nameservers are (briefly) overloaded by queries, perhaps by the
- attacker.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 9]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-5. Birthday attacks
-
- A curious mathematical phenomenon means that a group of 22 people
- suffices to have a more than even chance at having two or more
- members of the group share a birthday.
-
- An attacker can benefit from this phenomenon if it can force the
- target resolver to have multiple outstanding questions at any one
- time for the same domain to the same authoritative server.
-
- Any packet the attacker sends then has a much higher chance of being
- accepted because it only has to match any of the outstanding queries
- for that single domain. Compared to the birthday analogy above, of
- the group composed of questions and answers, the chance of having any
- of these share an ID rises quickly.
-
- As long as small numbers of questions are sent out, the chance of
- successfully spoofing an anwers rises linearly with the number of
- outstanding questions for the exact domain and nameserver.
-
- For larger numbers this effect is less pronounced.
-
- More details are available in US-CERT [vu-457875].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 10]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-6. Accepting only in-zone answers
-
- Answers from authoritative nameservers often contain information that
- is not part of the zone for which we deem it authoritative. As an
- example, a query for the MX record of a domain might get as its
- answer a mail exchanger in another domain, and additionally the IP
- address of this mail exchanger.
-
- If accepted uncritically, the resolver stands the chance of accepting
- data from an untrusted source. Care must be taken to only accept
- data if it is known that the originator is authoritative for that
- data.
-
- One very simple way to achieve this is to only accept data if it is
- part of the domain we asked the question for.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 11]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-7. Combined difficulty
-
- Given a known or static destination port, matching ID field, source
- and destination address requires on average in the order of 2 * 2^15
- = 65000 packets, assuming a domain has 2 authoritative nameservers.
-
- If the window of opportunity available is around 100ms, as assumed
- above, an attacker would need to be able to briefly transmit 650000
- packets/s to have a 50% chance to get spoofed data accepted on the
- first attempt.
-
- A realistic minimal DNS answer consists of around 80 bytes, including
- IP headers, making the packet rate above correspond to a respectable
- burst of 416Mb/s.
-
- As of mid-2006, this kind of bandwidth was not common but not scarce
- either, especially among those in a position to control many servers.
-
- These numbers change when a window of a full second is assumed,
- possibly because the arrival of the authentic answer can be prevented
- by overloading the bonafide authoritative hosts with decoy questions.
- This reduces the needed bandwith to 42 Mb/s.
-
- If in addition the attacker is granted more than a single chance and
- allowed up to 60 minutes of work on a domain with a time to live of
- 300 seconds, a meagre 4Mb/s suffices for a 50% chance at getting fake
- data accepted. Once equipped with a longer time, matching condition
- 1 mentioned above is straightforward - any popular domain will have
- been queried a number of times within this hour, and given the short
- TTL, this would lead to questions to authoritative nameservers,
- opening windows of opportunity.
-
-7.1. Symbols used in calculation
-
- Assume the following symbols are used:
-
- I: Number distinct IDs available (maximum 65536)
-
- P: Number of ports used (maximum around 64000, but often 1)
-
- N: Number of authoritative nameservers for a domain (averages
- around 2.5)
-
- F: Number of 'fake' packets sent by the attacker
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 12]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
- R: Number of packets sent per second by the attacker
-
- W: Window of opportunity, in seconds. Bounded by the response
- time of the authoritative servers (often 0.1s)
-
- D: Average number of identical outstanding questions of a resolver
- (typically 1, see Section 5)
-
- A: Number of attempts, one for each window of opportunity
-
-7.2. Calculation
-
- The probability of spoofing a resolver is equal to amount of fake
- packets that arrive within the window of opportunity, divided by the
- size of the problem space.
-
- When the resolver has 'D' multiple identical outstanding questions,
- each fake packet has a proportionally higher chance of matching any
- of these questions. This assumption only holds for small values of
- 'D'.
-
- In symbols, if the probability of being spoofed is denoted as P_s:
-
- D * F
- P_s = ---------
- N * P * I
-
- It is more useful to reason not in terms of aggregate packets but to
- convert to packet rate, which can easily be converted to bandwidth if
- needed.
-
- If the Window of opportunity length is 'W' and the attacker can send
- 'R' packets per second, the number of fake packets 'F' that are
- candidates to be accepted is:
-
- D * R * W
- F = R * W -> P_s = ----------
- N * P * I
-
- Finally, to calculate the combined chance 'P_cs' of spoofing over a
- chosen time period 'T', it should be realised that the attacker has a
- new window of opportunity each time the TTL 'TTL' of the target
- domain expires. This means that the number of attempts 'A' is equal
- to 'T / TTL'.
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 13]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
- To calculate the combined chance of at least one success, the
- following formula holds:
-
- (T / TTL)
- A ( D * R * W )
- P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- )
- ( N * P * I )
-
- When common numbers (as listed above) for D, W, N, P and I are
- inserted, this formula reduces to:
-
- (T / TTL)
- ( R )
- P_cs = 1 - ( 1 - ------- )
- ( 1638400 )
-
- From this formula it can be seen that, if the nameserver
- implementation is unchanged, only raising the TTL offers protection.
- Raising N, the number of authoritative nameservers, is not feasible
- beyond a small number.
-
- For the degenerate case of a zero-second TTL, a window of opportunity
- opens for each question asked, making the effective TTL equal to 'W'
- above, the response time of the authoritative server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 14]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-8. Discussion
-
- The calculations above indicate the relative ease with which DNS data
- can be spoofed. For example, using the formula derived earlier on a
- domain with a 3600 second TTL, an attacker sending 7000 fake answer
- packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a
- record in the first 24 hours, which rises to 50% after a week.
-
- For a domain with a TTL of 60 seconds, the 10% level is hit after 24
- minutes, 50% after less than 3 hours, 90% after around 9 hours.
-
- Note that the attacks mentioned above can be detected by watchful
- server operators - an unexpected incoming stream of 4.5mbit/s of
- packets might be noticed.
-
- An important assumption however in these calculations is a known or
- static destination port of the authentic answer.
-
- If that port number is unknown and needs to be guessed as well, the
- problem space expands by a factor of 64000, leading the attacker to
- need in excess of 285Gb/s to achieve similar success rates.
-
- Such bandwidth is not generally available, nor expected to be so in
- the foreseeable future.
-
- Note that some firewalls may need reconfiguring if they are currently
- setup to only allow outgoing queries from a single DNS source port.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 15]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-9. Countermeasures
-
- NOTE: This section is expected to change, and is very much open to
- discussion!
-
- Implementations MUST be able to send queries from ANY UDP port
-
- Implementations SHOULD use good random source to select Query ID for
- next query
-
- Implementations SHOULD be configurable to use one or multiple ports
- for queries.
-
- Implementations MAY be configurable to use one or more addresses for
- queries
-
- Implementations MUST suppress multiple identical queries to the SAME
- server.
-
- Implementations MUST match answers to the following
-
- o Remote address
-
- o Local address
-
- o Query port
-
- o Query ID
-
- o Question
-
- before applying DNS credibility rules.
-
- The document can not require the use of either multiple ports or
- addresses as that is an operational issue and should be addressed in
- a separate document in DNSOP.
-
- NOTE! A previous version of requirements is listed below as an
- inspiration to further discussions:
-
- Given the above, a resolver MAY/SHOULD/MUST:
-
- o Use an unpredictable source port from its available range for each
- outgoing query
-
- o Make full use of all 16 bits of the ID field
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 16]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
- o Assure that its choices of port and ID cannot be predicted by an
- attacker having knowledge of its (pseudo-)random generator
-
- o Not send out multiple equivalent questions outstanding to any
- authoritative server, unless all with identical ID and source port
-
- A resolver SHOULD offer diagnostics that enable the operator to
- determine a spoofing attempt is under way.
-
- Operators SHOULD attempt to restrict recursing service, either full
- or partial, to authorised users.
-
- A resolver MAY use heuristics to detect an excess of unacceptable
- answers and take measures if it believes an attempt is made to spoof
- it.
-
- Futhermore, zone operators are urged not to configure the Time To
- Live of domains to be lower than realistically needed for proper
- operations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 17]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-10. Security Considerations
-
- This document directly impacts the operational security of the Domain
- Name System, readers are urged to implement its recommendations.
-
- TBD!
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 18]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-11. Acknowledgements
-
- Source port randomisation in DNS was first implemented and possibly
- invented by Dan. J. Bernstein.
-
- Although any mistakes remain our own, the authors gratefully
- acknowledge the help and contributions of:
-
- Stephane Bortzmeyer,
-
- Sean Leach,
-
- Norbert Sendetzky
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 19]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-12. Normative 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.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
- April 2001.
-
- [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
- Defeating Denial of Service Attacks which employ IP Source
- Address Spoofing", BCP 38, RFC 2827, May 2000.
-
- [RFC3013] Killalea, T., "Recommended Internet Service Provider
- Security Services and Procedures", BCP 46, RFC 3013,
- November 2000.
-
- [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
- Name System (DNS)", RFC 3833, August 2004.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [vu-457875]
- United States CERT, "Various DNS service implementations
- generate multiple simultaneous queries for the same
- resource record", VU 457875, November 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 20]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-Authors' Addresses
-
- bert hubert
- Netherlabs Computer Consulting BV.
- Braillelaan 10
- Rijswijk (ZH) 2289 CM
- The Netherlands
-
- Email: bert.hubert@netherlabs.nl
-
-
- Remco van Mook
- Virtu
- Auke Vleerstraat 1
- Enschede 7521 PE
- The Netherlands
-
- Email: remco@virtu.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 21]
-\f
-Internet-Draft DNS resilience against forged answers January 2007
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2007).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-Hubert & van Mook Expires July 15, 2007 [Page 22]
-\f
+++ /dev/null
-
-
-
-Network Working Group B. Laurie
-Internet-Draft G. Sisson
-Intended status: Standards Track R. Arends
-Expires: January 2, 2008 Nominet
- D. Blacka
- VeriSign, Inc.
- July 2007
-
-
- DNSSEC Hashed Authenticated Denial of Existence
- draft-ietf-dnsext-nsec3-12
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- 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."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on January 2, 2008.
-
-Copyright Notice
-
- Copyright (C) The IETF Trust (2007).
-
-Abstract
-
- The Domain Name System Security Extensions (DNSSEC) introduced the
- NSEC resource record (RR) for authenticated denial of existence.
- This document introduces an alternative resource record, NSEC3, which
- similarly provides authenticated denial of existence. However, it
- also provides measures against zone enumeration and permits gradual
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 1]
-\f
-Internet-Draft nsec3 July 2007
-
-
- expansion of delegation-centric zones.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6
- 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 7
- 3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8
- 3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 8
- 3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1.6. Hash Length . . . . . . . . . . . . . . . . . . . . . 9
- 3.1.7. Next Hashed Owner Name . . . . . . . . . . . . . . . . 9
- 3.1.8. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 9
- 3.2. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 9
- 3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10
- 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 11
- 4. The NSEC3PARAM Record . . . . . . . . . . . . . . . . . . . . 12
- 4.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12
- 4.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12
- 4.1.2. Flag Fields . . . . . . . . . . . . . . . . . . . . . 12
- 4.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 13
- 4.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 13
- 4.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 4.2. NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13
- 4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 13
- 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 14
- 6. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
- 7. Authoritative Server Considerations . . . . . . . . . . . . . 15
- 7.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 15
- 7.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17
- 7.2.1. Closest Encloser Proof . . . . . . . . . . . . . . . . 18
- 7.2.2. Name Error Responses . . . . . . . . . . . . . . . . . 18
- 7.2.3. No Data Responses, QTYPE is not DS . . . . . . . . . . 19
- 7.2.4. No Data Responses, QTYPE is DS . . . . . . . . . . . . 19
- 7.2.5. Wildcard No Data Responses . . . . . . . . . . . . . . 19
- 7.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 19
- 7.2.7. Referrals to Unsigned Subzones . . . . . . . . . . . . 20
- 7.2.8. Responding to Queries for NSEC3 Owner Names . . . . . 20
- 7.2.9. Server Response to a Run-time Collision . . . . . . . 20
- 7.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 20
- 7.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 21
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 2]
-\f
-Internet-Draft nsec3 July 2007
-
-
- 7.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21
- 8. Validator Considerations . . . . . . . . . . . . . . . . . . . 22
- 8.1. Responses with Unknown Hash Types . . . . . . . . . . . . 22
- 8.2. Verifying NSEC3 RRs . . . . . . . . . . . . . . . . . . . 22
- 8.3. Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23
- 8.4. Validating Name Error Responses . . . . . . . . . . . . . 24
- 8.5. Validating No Data Responses, QTYPE is not DS . . . . . . 24
- 8.6. Validating No Data Responses, QTYPE is DS . . . . . . . . 24
- 8.7. Validating Wildcard No Data Responses . . . . . . . . . . 24
- 8.8. Validating Wildcard Answer Responses . . . . . . . . . . . 24
- 8.9. Validating Referrals to Unsigned Subzones . . . . . . . . 25
- 9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 25
- 9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 25
- 9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 25
- 10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26
- 10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26
- 10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 26
- 10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 26
- 10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 27
- 10.5. Transitioning a Signed Zone From NSEC3 to NSEC . . . . . . 28
- 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
- 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
- 12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30
- 12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30
- 12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 30
- 12.1.3. Transitioning to a New Hash Algorithm . . . . . . . . 30
- 12.1.4. Using High Iteration Values . . . . . . . . . . . . . 31
- 12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32
- 12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 32
- 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
- 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
- 13.2. Informative References . . . . . . . . . . . . . . . . . . 34
- Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 34
- Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 39
- B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 39
- B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 41
- B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 42
- B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 43
- B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45
- B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 47
- B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 48
- Appendix C. Special Considerations . . . . . . . . . . . . . . . 49
- C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 49
- C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 50
- C.2.1. Avoiding Hash Collisions During Generation . . . . . . 50
- C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 51
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
- Intellectual Property and Copyright Statements . . . . . . . . . . 53
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 3]
-\f
-Internet-Draft nsec3 July 2007
-
-
-1. Introduction
-
-1.1. Rationale
-
- The DNS Security Extensions included the NSEC RR to provide
- authenticated denial of existence. Though the NSEC RR meets the
- requirements for authenticated denial of existence, it introduces a
- side-effect in that the contents of a zone can be enumerated. This
- property introduces undesired policy issues.
-
- The enumeration is enabled by the set of NSEC records that exists in
- a side signed zone. An NSEC record lists two names that are ordered
- canonically, in order to show that nothing exists between the two
- names. The complete set of NSEC records lists all the names in a
- zone. It is trivial to enumerate the content of a zone by querying
- for names that do not exist.
-
- An enumerated zone can be used, for example, as a source of probable
- e-mail addresses for spam, or as a key for multiple WHOIS queries to
- reveal registrant data which many registries may have legal
- obligations to protect. Many registries therefore prohibit copying
- of their zone data; however, the use of NSEC RRs renders these
- policies unenforceable.
-
- A second problem is that the cost to cryptographically secure
- delegations to unsigned zones is high, relative to the perceived
- security benefit, in two cases: large, delegation-centric zones, and
- zones where insecure delegations will be updated rapidly. In these
- cases, the costs of maintaining the NSEC RR chain may be extremely
- high and use of the "Opt-Out" convention may be more appropriate (for
- these unsecured zones).
-
- This document presents the NSEC3 Resource Record which can be used as
- an alternative to NSEC to mitigate these issues.
-
- Earlier work to address these issues include [I-D.jas-dnsext-no],
- [RFC4956] and [I-D.laurie-dnsext-nsec2v2].
-
-1.2. Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-1.3. Terminology
-
- The reader is assumed to be familiar with the basic DNS and DNSSEC
- concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034],
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 4]
-\f
-Internet-Draft nsec3 July 2007
-
-
- [RFC4035] and subsequent RFCs that update them: [RFC2136], [RFC2181]
- and [RFC2308].
-
- The following terminology is used throughout this document:
-
- Zone enumeration: the practice of discovering the full content of a
- zone via successive queries. Zone enumeration was non-trivial
- prior to the introduction of DNSSEC.
-
- Original owner name: the owner name corresponding to a hashed owner
- name.
-
- Hashed owner name: the owner name created after applying the hash
- function to an owner name.
-
- Hash order: the order in which hashed owner names are arranged
- according to their numerical value, treating the leftmost (lowest
- numbered) octet as the most significant octet. Note that this
- order is the same as the canonical DNS name order specified in
- [RFC4034] when the hashed owner names are in base32 encoded with
- Extended Hex Alphabet [RFC4648].
-
- Empty non-terminal: a domain name that owns no resource records, but
- has one or more subdomains that do.
-
- Delegation: an NS RRSet with a name different from the current zone
- apex (non-zone-apex), signifying a delegation to a child zone.
-
- Secure delegation: a name containing a delegation (NS RRSet), and a
- signed DS RRSet, signifying a delegation to a signed child zone.
-
- Insecure delegation: a name containing a delegation (NS RRSet), but
- lacking a DS RRSet, signifying a delegation to an unsigned child
- zone.
-
- Opt-Out NSEC3 resource record: an NSEC3 resource record which has
- the Opt-Out flag set to 1.
-
- Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR.
-
- Closest encloser: the longest existing ancestor of a name. See also
- section 3.3.1 of [RFC4592].
-
- Closest provable encloser: the longest ancestor of a name that can
- be proven to exist. Note that this is only different from the
- closest encloser in an Opt-Out zone.
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 5]
-\f
-Internet-Draft nsec3 July 2007
-
-
- Next closer name: the name one label longer than the closest
- provable encloser of a name.
-
- Base32: the "Base 32 Encoding with Extended Hex Alphabet" as
- specified in [RFC4648]. Note that trailing padding characters
- ("=") are not used in the NSEC3 specification.
-
- To cover: An NSEC3 RR is said to "cover" a name if the hash of the
- name or "next closer" name falls between the owner name and the
- next hashed owner name of the NSEC3. In other words, if it proves
- the nonexistence of the name, either directly or by proving the
- nonexistence of an ancestor of the name.
-
- To match: An NSEC3 RR is said to "match" a name if the owner name of
- the NSEC3 RR is the same as the hashed owner name of that name.
-
-
-2. Backwards Compatibility
-
- This specification describes a protocol change that is not generally
- backwards compatible with [RFC4033], [RFC4034] and [RFC4035]. In
- particular, security-aware resolvers that are unaware of this
- specification (NSEC3-unaware resolvers) may fail to validate the
- responses introduced by this document.
-
- In order to aid deployment, this specification uses a signaling
- technique to prevent NSEC3-unaware resolvers from attempting to
- validate responses from NSEC3-signed zones.
-
- This specification allocates two new DNSKEY algorithm identifiers for
- this purpose. Algorithm XX, DSA-NSEC3-SHA1 [### RFC-editor update
- required, temporarily, XX=131] is an alias for algorithm 3, DSA.
- Algorithm YY, RSASHA1-NSEC3-SHA1 [### RFC-editor update required,
- temporarily, YY=133] is an alias for algorithm 5, RSASHA1. These are
- not new algorithms, they are additional identifiers for the existing
- algorithms.
-
- Zones signed according to this specification MUST only use these
- algorithm identifiers for their DNSKEY RRs. Because these new
- identifiers will be unknown algorithms to existing, NSEC3-unaware
- resolvers, those resolvers will then treat responses from the NSEC3
- signed zone as insecure, as detailed in [RFC4035], section 5.2.
-
- These algorithm identifiers are used with the NSEC3 hash algorithm
- SHA1. Using other NSEC3 hash algorithms requires allocation of a new
- alias (see Section 12.1.3).
-
- Security aware resolvers that are aware of this specification MUST
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 6]
-\f
-Internet-Draft nsec3 July 2007
-
-
- recognize the new algorithm identifiers and treat them as equivalent
- to the algorithms that they alias.
-
- A methodology for transitioning from a DNSSEC signed zone to a zone
- signed using NSEC3 is discussed in Section 10.4.
-
-
-3. The NSEC3 Resource Record
-
- The NSEC3 Resource Record (RR) provides authenticated denial of
- existence for DNS Resource Record Sets.
-
- The NSEC3 RR lists RR types present at the original owner name of the
- NSEC3 RR. It includes the next hashed owner name in the hash order
- of the zone. The complete set of NSEC3 RRs in a zone indicates which
- RRSets exist for the original owner name of the RR and form a chain
- of hashed owner names in the zone. This information is used to
- provide authenticated denial of existence for DNS data. To provide
- protection against zone enumeration, the owner names used in the
- NSEC3 RR are cryptographic hashes of the original owner name
- prepended as a single label to the name of the zone. The NSEC3 RR
- indicates which hash function is used to construct the hash, which
- salt is used, and how many iterations of the hash function are
- performed over the original owner name. The hashing technique is
- described fully in Section 5.
-
- Hashed owner names of unsigned delegations may be excluded from the
- chain. An NSEC3 RR whose span covers the hash of an owner name or
- "next closer" name of an unsigned delegation is referred to as an
- Opt-Out NSEC3 RR and is indicated by the presence of a flag.
-
- The owner name for the NSEC3 RR is the base32 encoding of the hashed
- owner name prepended as a single label to the name of the zone.
-
- The type value for the NSEC3 RR is NN. [### RFC-editor update
- required, the examples assume NN=50]
-
- The NSEC3 RR RDATA format is class independent and is described
- below.
-
- The class MUST be the same as the class of the original owner name.
-
- The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
- field. This is in the spirit of negative caching [RFC2308].
-
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 7]
-\f
-Internet-Draft nsec3 July 2007
-
-
-3.1. RDATA Fields
-
-3.1.1. Hash Algorithm
-
- The Hash Algorithm field identifies the cryptographic hash algorithm
- used to construct the hash-value.
-
- The values for this field are defined in the NSEC3 hash algorithm
- registry, described in Section 11.
-
-3.1.2. Flags
-
- The Flags field contains 8 one-bit flags that can be used to indicate
- different processing. All undefined flags must be zero. The only
- flag defined by this specification is the Opt-Out flag.
-
-3.1.2.1. Opt-Out Flag
-
- If the Opt-Out flag is set, the NSEC3 record covers zero or more
- unsigned delegations.
-
- If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned
- delegations.
-
- The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned
- delegations. It is the least significant bit in the Flags field.
- See Section 6 for details about the use of this flag.
-
-3.1.3. Iterations
-
- The Iterations field defines the number of additional times the hash
- function has been performed. More iterations result in greater
- resiliency of the hash value against dictionary attacks, but at a
- higher computational cost for both the server and resolver. See
- Section 5 for details of the use of this field, and Section 10.3 for
- limitations on the value.
-
-3.1.4. Salt Length
-
- The Salt Length field defines the length of the Salt field in octets,
- ranging in value from 0 to 255.
-
-3.1.5. Salt
-
- The Salt field is appended to the original owner name before hashing
- in order to defend against pre-calculated dictionary attacks. See
- Section 5 for details on how the salt is used.
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 8]
-\f
-Internet-Draft nsec3 July 2007
-
-
-3.1.6. Hash Length
-
- The Hash Length field defines the length of the Next Hashed Owner
- Name field, ranging in value from 1 to 255 octets.
-
-3.1.7. Next Hashed Owner Name
-
- The Next Hashed Owner Name field contains the next hashed owner name
- in hash order. This value is in binary format. Given the ordered
- set of all hashed owner names, the Next Hashed Owner Name field
- contains the hash of an owner name that immediately follows the owner
- name of the given NSEC3 RR. The value of the Next Hashed Owner Name
- field in the last NSEC3 RR in the zone is the same as the hashed
- owner name of the first NSEC3 RR in the zone in hash order. Note
- that, unlike the owner name of the NSEC3 RR, the value of this field
- does not contain the appended zone name.
-
-3.1.8. Type Bit Maps
-
- The Type Bit Maps field identifies the RRSet types which exist at the
- original owner name of the NSEC3 RR.
-
-3.2. NSEC3 RDATA Wire Format
-
- The RDATA of the NSEC3 RR is as shown below:
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Hash Alg. | Flags | Iterations |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Salt Length | Salt /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Hash Length | Next Hashed Owner Name /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Type Bit Maps /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Hash Algorithm is a single octet.
-
- Flags field is a single octet, the Opt-Out flag is the least
- significant bit, as shown below:
-
- 0 1 2 3 4 5 6 7
- +-+-+-+-+-+-+-+-+
- | |O|
- +-+-+-+-+-+-+-+-+
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 9]
-\f
-Internet-Draft nsec3 July 2007
-
-
- Iterations is represented as a 16-bit unsigned integer, with the most
- significant bit first.
-
- Salt Length is represented as an unsigned octet. Salt Length
- represents the length of the Salt field in octets. If the value is
- zero, the following Salt field is omitted.
-
- Salt, if present, is encoded as a sequence of binary octets. The
- length of this field is determined by the preceding Salt Length
- field.
-
- Hash Length is represented as an unsigned octet. Hash Length
- represents the length of the Next Hashed Owner Name field in octets.
-
- The next hashed owner name is not base32 encoded, unlike the owner
- name of the NSEC3 RR. It is the unmodified binary hash value. It
- does not include the name of the containing zone. The length of this
- field is determined by the preceding Hash Length field.
-
-3.2.1. Type Bit Maps Encoding
-
- The encoding of the Type Bit Maps field is the same as that used by
- the NSEC RR, described in [RFC4034]. It is explained and clarified
- here for clarity.
-
- The RR type space is split into 256 window blocks, each representing
- the low-order 8 bits of the 16-bit RR type space. Each block that
- has at least one active RR type is encoded using a single octet
- window number (from 0 to 255), a single octet bitmap length (from 1
- to 32) indicating the number of octets used for the bitmap of the
- window block, and up to 32 octets (256 bits) of bitmap.
-
- Blocks are present in the NSEC3 RR RDATA in increasing numerical
- order.
-
- Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
- where "|" denotes concatenation.
-
- Each bitmap encodes the low-order 8 bits of RR types within the
- window block, in network bit order. The first bit is bit 0. For
- window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
- to RR type 2 (NS), and so forth. For window block 1, bit 1
- corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
- 1, it indicates that an RRSet of that type is present for the
- original owner name of the NSEC3 RR. If a bit is set to 0, it
- indicates that no RRSet of that type is present for the original
- owner name of the NSEC3 RR.
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 10]
-\f
-Internet-Draft nsec3 July 2007
-
-
- Since bit 0 in window block 0 refers to the non-existing RR type 0,
- it MUST be set to 0. After verification, the validator MUST ignore
- the value of bit 0 in window block 0.
-
- Bits representing Meta-TYPEs or QTYPEs as specified in [RFC2929]
- (section 3.1) or within the range reserved for assignment only to
- QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
- zone data. If encountered, they must be ignored upon reading.
-
- Blocks with no types present MUST NOT be included. Trailing zero
- octets in the bitmap MUST be omitted. The length of the bitmap of
- each block is determined by the type code with the largest numerical
- value, within that block, among the set of RR types present at the
- original owner name of the NSEC3 RR. Trailing octets not specified
- MUST be interpreted as zero octets.
-
-3.3. Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- o The Hash Algorithm field is represented as an unsigned decimal
- integer. The value has a maximum of 255.
-
- o The Flags field is represented as an unsigned decimal integer.
- The value has a maximum of 255.
-
- o The Iterations field is represented as an unsigned decimal
- integer. The value is between 0 and 65535, inclusive.
-
- o The Salt Length field is not represented.
-
- o The Salt field is represented as a sequence of case-insensitive
- hexadecimal digits. Whitespace is not allowed within the
- sequence. The Salt field is represented as "-" (without the
- quotes) when the Salt Length field has value 0.
-
- o The Hash Length field is not represented.
-
- o The Next Hashed Owner Name field is represented as an unpadded
- sequence of case-insensitive base32 digits, without whitespace.
-
- o The Type Bit Maps field is represented as a sequence of RR type
- mnemonics. When the mnemonic is not known, the TYPE
- representation as described in [RFC3597] (section 5) MUST be used.
-
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 11]
-\f
-Internet-Draft nsec3 July 2007
-
-
-4. The NSEC3PARAM Record
-
- The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm,
- flags, iterations and salt) needed by authoritative servers to
- calculate hashed owner names. The presence of an NSEC3PARAM RR at a
- zone apex indicates that the specified parameters may be used by
- authoritative servers to choose an appropriate set of NSEC3 RRs for
- negative responses. The NSEC3PARAM RR is not used by validators or
- resolvers.
-
- If an NSEC3PARAM RR is present at the apex of a zone with a Flags
- field value of zero, then there MUST be an NSEC3 RR using the same
- hash algorithm, iterations and salt parameters present at every
- hashed owner name in the zone. That is, the zone MUST contain a
- complete set of NSEC3 RRs with the same hash algorithm, iterations
- and salt parameters.
-
- The owner name for the NSEC3PARAM RR is the name of the zone apex.
-
- The type value for the NSEC3PARAM RR is MM. [### RFC-editor update
- required, the examples assume MM=51]
-
- The NSEC3PARAM RR RDATA format is class independent and is described
- below.
-
- The class MUST be the same as the NSEC3 RRs to which this RR refers.
-
-4.1. RDATA Fields
-
- The RDATA for this RR mirrors the first four fields in the NSEC3 RR.
-
-4.1.1. Hash Algorithm
-
- The Hash Algorithm field identifies the cryptographic hash algorithm
- used to construct the hash-value.
-
- The acceptable values are the same as the corresponding field in the
- NSEC3 RR.
-
-4.1.2. Flag Fields
-
- The Opt-Out flag is not used and is set to zero.
-
- All other flags are reserved for future use, and must be zero.
-
- NSEC3PARAM RRs with a Flags field value other than zero MUST be
- ignored.
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 12]
-\f
-Internet-Draft nsec3 July 2007
-
-
-4.1.3. Iterations
-
- The Iterations field defines the number of additional times the hash
- is performed.
-
- Its acceptable values are the same as the corresponding field in the
- NSEC3 RR.
-
-4.1.4. Salt Length
-
- The Salt Length field defines the length of the salt in octets,
- ranging in value from 0 to 255.
-
-4.1.5. Salt
-
- The Salt field is appended to the original owner name before hashing.
-
-4.2. NSEC3PARAM RDATA Wire Format
-
- The RDATA of the NSEC3PARAM RR is as shown below:
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Hash Alg. | Flags | Iterations |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Salt Length | Salt /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Hash Algorithm is a single octet.
-
- Flags field is a single octet.
-
- Iterations is represented as a 16-bit unsigned integer, with the most
- significant bit first.
-
- Salt Length is represented as an unsigned octet. Salt Length
- represents the length of the following Salt field in octets. If the
- value is zero, the Salt field is omitted.
-
- Salt, if present, is encoded as a sequence of binary octets. The
- length of this field is determined by the preceding Salt Length
- field.
-
-4.3. Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 13]
-\f
-Internet-Draft nsec3 July 2007
-
-
- o The Hash Algorithm field is represented as an unsigned decimal
- integer. The value has a maximum of 255.
-
- o The Flags field is represented as an unsigned decimal integer.
- The value has a maximum value of 255.
-
- o The Iterations field is represented as an unsigned decimal
- integer. The value is between 0 and 65535, inclusive.
-
- o The Salt Length field is not represented.
-
- o The Salt field is represented as a sequence of case-insensitive
- hexadecimal digits. Whitespace is not allowed within the
- sequence. This field is represented as "-" (without the quotes)
- when the Salt Length field is zero.
-
-
-5. Calculation of the Hash
-
- The hash calculation uses three of the NSEC3 RDATA fields: Hash
- Algorithm, Salt, and Iterations.
-
- Define H(x) to be the hash of x using the Hash Algorithm selected by
- the NSEC3 RR, k to be the number of Iterations, and || to indicate
- concatenation. Then define:
-
- IH(salt, x, 0) = H(x || salt), and
-
- IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
-
- Then the calculated hash of an owner name is
-
- IH(salt, owner name, iterations),
-
- where the owner name is in the canonical form, defined as:
-
- The wire format of the owner name where:
-
- 1. The owner name is fully expanded (no DNS name compression) and
- fully qualified;
-
- 2. All uppercase US-ASCII letters are replaced by the corresponding
- lowercase US-ASCII letters;
-
- 3. If the owner name is a wildcard name, the owner name is in its
- original unexpanded form, including the "*" label (no wildcard
- substitution);
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 14]
-\f
-Internet-Draft nsec3 July 2007
-
-
- This form is as defined in section 6.2 of [RFC4034].
-
- The method to calculate the Hash is based on [RFC2898].
-
-
-6. Opt-Out
-
- In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS
- RRSets at delegation points are not signed and may be accompanied by
- a DS RRSet. With the Opt-Out bit clear, the security status of the
- child zone is determined by the presence or absence of this DS RRSet,
- cryptographically proven by the signed NSEC3 RR at the hashed owner
- name of the delegation. Setting the Opt-Out flag modifies this by
- allowing insecure delegations to exist within the signed zone without
- a corresponding NSEC3 RR at the hashed owner name of the delegation.
-
- An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the
- owner name or "next closer" name of the delegation is between the
- owner name of the NSEC3 RR and the next hashed owner name.
-
- An Opt-Out NSEC3 RR does not assert the existence or non-existence of
- the insecure delegations that it may cover. This allows for the
- addition or removal of these delegations without recalculating or re-
- signing RRs in the NSEC3 RR chain. However, Opt-Out NSEC3 RRs do
- assert the (non)existence of other, authoritative RRSets.
-
- An Opt-Out NSEC3 RR MAY have the same original owner name as an
- insecure delegation. In this case, the delegation is proven insecure
- by the lack of a DS bit in the type map and the signed NSEC3 RR does
- assert the existence of the delegation.
-
- Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and
- non-Opt-Out NSEC3 RRs. If an NSEC3 RR is not Opt-Out, there MUST NOT
- be any hashed owner names of insecure delegations (nor any other RRs)
- between it and the name indicated by the next hashed owner name in
- the NSEC3 RDATA. If it is Opt-Out, it MUST only cover hashed owner
- names or hashed "next closer" names of insecure delegations.
-
- The effects of the Opt-Out flag on signing, serving, and validating
- responses are covered in following sections.
-
-
-7. Authoritative Server Considerations
-
-7.1. Zone Signing
-
- Zones using NSEC3 must satisfy the following properties:
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 15]
-\f
-Internet-Draft nsec3 July 2007
-
-
- o Each owner name within the zone that owns authoritative RRSets
- MUST have a corresponding NSEC3 RR. Owner names that correspond
- to unsigned delegations MAY have a corresponding NSEC3 RR.
- However, if there is not a corresponding NSEC3 RR, there MUST be
- an Opt-Out NSEC3 RR that covers the "next closer" name to the
- delegation. Other non-authoritative RRs are not represented by
- NSEC3 RRs.
-
- o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
- the empty non-terminal is only derived from an insecure delegation
- covered by an Opt-Out NSEC3 RR.
-
- o The TTL value for any NSEC3 RR SHOULD be the same as the minimum
- TTL value field in the zone SOA RR.
-
- o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST
- indicate the presence of all types present at the original owner
- name, except for the types solely contributed by an NSEC3 RR
- itself. Note that this means that the NSEC3 type itself will
- never be present in the Type Bit Maps.
-
- The following steps describe a method of proper construction of NSEC3
- RRs. This is not the only such possible method.
-
- 1. Select the hash algorithm and the values for salt and iterations.
-
- 2. For each unique original owner name in the zone add an NSEC3 RR.
-
- * If Opt-Out is being used, owner names of unsigned delegations
- MAY be excluded.
-
- * The owner name of the NSEC3 RR is the hash of the original
- owner name, prepended as a single label to the zone name.
-
- * The Next Hashed Owner Name field is left blank for the moment.
-
- * If Opt-Out is being used, set the Opt-Out bit to one.
-
- * For collision detection purposes, optionally keep track of the
- original owner name with the NSEC3 RR.
-
- * Additionally, for collision detection purposes, optionally
- create an additional NSEC3 RR corresponding to the original
- owner name with the asterisk label prepended (i.e., as if a
- wildcard existed as a child of this owner name) and keep track
- of this original owner name. Mark this NSEC3 RR as temporary.
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 16]
-\f
-Internet-Draft nsec3 July 2007
-
-
- 3. For each RRSet at the original owner name, set the corresponding
- bit in the Type Bit Maps field.
-
- 4. If the difference in number of labels between the apex and the
- original owner name is greater than 1, additional NSEC3 RRs need
- to be added for every empty non-terminal between the apex and the
- original owner name. This process may generate NSEC3 RRs with
- duplicate hashed owner names. Optionally, for collision
- detection, track the original owner names of these NSEC3 RRs and
- create temporary NSEC3 RRs for wildcard collisions in a similar
- fashion to step 1.
-
- 5. Sort the set of NSEC3 RRs into hash order.
-
- 6. Combine NSEC3 RRs with identical hashed owner names by replacing
- them with a single NSEC3 RR with the Type Bit Maps field
- consisting of the union of the types represented by the set of
- NSEC3 RRs. If the original owner name was tracked, then
- collisions may be detected when combining, as all of the matching
- NSEC3 RRs should have the same original owner name. Discard any
- possible temporary NSEC3 RRs.
-
- 7. In each NSEC3 RR, insert the next hashed owner name by using the
- value of the next NSEC3 RR in hash order. The next hashed owner
- name of the last NSEC3 RR in the zone contains the value of the
- hashed owner name of the first NSEC3 RR in the hash order.
-
- 8. Finally, add an NSEC3PARAM RR with the same Hash Algorithm,
- Iterations and Salt fields to the zone apex.
-
- If a hash collision is detected, then a new salt has to be chosen and
- the signing process restarted.
-
-7.2. Zone Serving
-
- This specification modifies DNSSEC-enabled DNS responses generated by
- authoritative servers. In particular, it replaces the use of NSEC
- RRs in such responses with NSEC3 RRs.
-
- In the following response cases, the NSEC RRs dictated by DNSSEC
- [RFC4035] are replaced with NSEC3 RRs that prove the same facts.
- Responses that would not contain NSEC RRs are unchanged by this
- specification.
-
- When returning responses containing multiple NSEC3 RRs, all of the
- NSEC3 RRs MUST use the same hash algorithm, iteration, and salt
- values. The Flags field value MUST be either zero or one.
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 17]
-\f
-Internet-Draft nsec3 July 2007
-
-
-7.2.1. Closest Encloser Proof
-
- For many NSEC3 responses a proof of the closest encloser is required.
- This is a proof that some ancestor of the QNAME is the closest
- encloser of QNAME.
-
- This proof consists of (up to) two different NSEC3 RRs:
-
- o An NSEC3 RR that matches the closest (provable) encloser.
-
- o An NSEC3 RR that covers the "next closer" name to the closest
- encloser.
-
- The first NSEC3 RR essentially proposes a possible closest encloser,
- and proves that the particular encloser does, in fact, exist. The
- second NSEC3 RR proves that the possible closest encloser is the
- closest, and proves that QNAME (and any ancestors between QNAME and
- the closest encloser) do not exist.
-
- These NSEC3 RRs are collectively referred to as the "closest encloser
- proof" in the subsequent descriptions.
-
- For example, the closest encloser proof for the nonexistent
- "alpha.beta.gamma.example." owner name might prove that
- "gamma.example." is the closest encloser. This response would
- contain the NSEC3 RR that matches "gamma.example.", and would also
- contain the NSEC3 RR that covers "beta.gamma.example." (which is the
- "next closer" name.)
-
- It is possible, when using Opt-Out (Section 6), to not be able to
- prove the actual closest encloser because it is, or is part of an
- insecure delegation covered by an Opt-Out span. In this case,
- instead of proving the actual closest encloser, the closest provable
- encloser is used. That is, the closest enclosing authoritative name
- is used instead. In this case, the set of NSEC3 RRs used for this
- proof is referred to as the "closest provable encloser proof."
-
-7.2.2. Name Error Responses
-
- To prove the nonexistence of QNAME a closest encloser proof and an
- NSEC3 RR covering the (nonexistent) wildcard RR at the closest
- encloser MUST be included in the response. This collection of (up
- to) three NSEC3 RRs proves both that QNAME does not exist and that a
- wildcard that could have matched QNAME also does not exist.
-
- For example, if "gamma.example." is the closest provable encloser to
- QNAME, then a NSEC3 RR covering "*.gamma.example." is included in the
- authority section of the response.
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 18]
-\f
-Internet-Draft nsec3 July 2007
-
-
-7.2.3. No Data Responses, QTYPE is not DS
-
- The server MUST include the NSEC3 RR that matches QNAME. This NSEC3
- RR MUST NOT have the bits corresponding to either the QTYPE or CNAME
- set in its Type Bit Maps field.
-
-7.2.4. No Data Responses, QTYPE is DS
-
- If there is an NSEC3 RR that matches QNAME, the server MUST return it
- in the response. The bits corresponding with DS and CNAME MUST NOT
- be set in the Type Bit Maps field of this NSEC3 RR.
-
- If no NSEC3 RR matches QNAME, the server MUST return a closest
- provable encloser proof for QNAME. The NSEC3 RR that covers the
- "next closer" name MUST have the Opt-Out bit set (note that this is
- true by definition - if the Opt-Out bit is not set, something has
- gone wrong).
-
- If a server is authoritative for both sides of a zone cut at QNAME,
- the server MUST return the proof from the parent side of the zone
- cut.
-
-7.2.5. Wildcard No Data Responses
-
- If there is a wildcard match for QNAME, but QTYPE is not present at
- that name, the response MUST include a closest encloser proof for
- QNAME and MUST include the NSEC3 RR that matches the wildcard. This
- combination proves both that QNAME itself does not exist and that a
- wildcard that matches QNAME does exist. Note that the closest
- encloser to QNAME MUST be the immediate ancestor of the wildcard RR
- (if this is not the case, then something has gone wrong).
-
-7.2.6. Wildcard Answer Responses
-
- If there is a wildcard match for QNAME and QTYPE, then, in addition
- to the expanded wildcard RRSet returned in the answer section of the
- response, proof that the wildcard match was valid must be returned.
-
- This proof is accomplished by proving that both QNAME does not exist,
- and that the closest encloser of the QNAME and the immediate ancestor
- of the wildcard are the same (i.e., the correct wildcard matched).
-
- To this end, the NSEC3 RR that covers the "next closer" name of the
- immediate ancestor of the wildcard MUST be returned. It is not
- necessary to return an NSEC3 RR that matches the closest encloser, as
- the existence of this closest encloser is proven by the presence of
- the expanded wildcard in the response.
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 19]
-\f
-Internet-Draft nsec3 July 2007
-
-
-7.2.7. Referrals to Unsigned Subzones
-
- If there is an NSEC3 RR that matches the delegation name, then that
- NSEC3 RR MUST be included in the response. The DS bit in the type
- bit maps of the NSEC3 RR MUST NOT be set.
-
- If the zone is Opt-Out, then there may not be an NSEC3 RR
- corresponding to the delegation. In this case, the closest provable
- encloser proof MUST be included in the response. The included NSEC3
- RR that covers the "next closer" name for the delegation MUST have
- the Opt-Out flag set to one. (Note that this will be the case unless
- something has gone wrong).
-
-7.2.8. Responding to Queries for NSEC3 Owner Names
-
- The owner names of NSEC3 RRs are not represented in the NSEC3 RR
- chain like other owner names. As a result, each NSEC3 owner name is
- covered by another NSEC3 RR, effectively negating the existence of
- the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR
- can be proven by its RRSIG RRSet.
-
- If the following conditions are all true:
-
- o The QNAME equals the owner name of an existing NSEC3 RR, and
-
- o No RR types exist at the QNAME, nor at any descendant of QNAME.
-
- Then the response MUST be constructed as a Name Error response
- (Section 7.2.2). Or, in other words, the authoritative name server
- will act, as if the owner name of the NSEC3 RR did not exist.
-
- Note that NSEC3 RRs are returned as a result of an AXFR or IXFR
- query.
-
-7.2.9. Server Response to a Run-time Collision
-
- If the hash of a non-existing QNAME collides with the owner name of
- an existing NSEC3 RR, then the server will be unable to return a
- response that proves that QNAME does not exist. In this case, the
- server MUST return a response with an RCODE of 2 (server failure).
-
- Note that with the hash algorithm specified in this document, SHA-1,
- such collisions are highly unlikely.
-
-7.3. Secondary Servers
-
- Secondary servers (and perhaps other entities) need to reliably
- determine which NSEC3 parameters (i.e., hash, salt and iterations)
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 20]
-\f
-Internet-Draft nsec3 July 2007
-
-
- are present at every hashed owner name, in order to be able to choose
- an appropriate set of NSEC3 RRs for negative responses. This is
- indicated by an NSEC3PARAM RR present at the zone apex.
-
- If there are multiple NSEC3PARAM RRs present, there are multiple
- valid NSEC3 chains present. The server must choose one of them, but
- may use any criteria to do so.
-
-7.4. Zones Using Unknown Hash Algorithms
-
- Zones that are signed according to this specification, but are using
- an unrecognized NSEC3 hash algorithm value, cannot be effectively
- served. Such zones SHOULD be rejected when loading. Servers SHOULD
- respond with RCODE=2 (server failure) responses when handling queries
- that would fall under such zones.
-
-7.5. Dynamic Update
-
- A zone signed using NSEC3 may accept dynamic updates [RFC2136].
- However, NSEC3 introduces some special considerations for dynamic
- updates.
-
- Adding and removing names in a zone MUST account for the creation or
- removal of empty non-terminals.
-
- o When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs
- corresponding to empty non-terminals created by that name MUST be
- removed. Note that more than one name may be asserting the
- existence of a particular empty non-terminal.
-
- o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs
- MUST also be added for any empty non-terminals that are created.
- That is, if there is not an existing NSEC3 RR matching an empty
- non-terminal, it must be created and added.
-
- The presence of Opt-Out in a zone means that some additions or
- delegations of names will not require changes to the NSEC3 RRs in a
- zone.
-
- o When removing a delegation RRSet, if that delegation does not have
- a matching NSEC3 RR, then it was opted out. In this case, nothing
- further needs to be done.
-
- o When adding a delegation RRSet, if the "next closer" name of the
- delegation is covered by an existing Opt-Out NSEC3 RR, then the
- delegation MAY be added without modifying the NSEC3 RRs in the
- zone.
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 21]
-\f
-Internet-Draft nsec3 July 2007
-
-
- The presence of Opt-Out in a zone means that when adding or removing
- NSEC3 RRs, the value of the Opt-Out flag that should be set in new or
- modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of
- basic rules to resolve the ambiguity.
-
- The central concept to these rules is that the state of the Opt-Out
- flag of the covering NSEC3 RR is preserved.
-
- o When removing an NSEC3 RR, the value of the Opt-Out flag for the
- previous NSEC3 RR (the one whose next hashed owner name is
- modified) should not be changed.
-
- o When adding an NSEC3 RR, the value of the Opt-Out flag is set to
- the value of the Opt-Out flag of the NSEC3 RR that previously
- covered the owner name of the NSEC3 RR. That is, the now previous
- NSEC3 RR.
-
- If the zone in question is consistent with its use of the Opt-Out
- flag (that is, all NSEC3 RRs in the zone have the same value for the
- flag) then these rules will retain that consistency. If the zone is
- not consistent in the use of the flag (i.e., a partially Opt-Out
- zone), then these rules will not retain the same pattern of use of
- the Opt-Out flag.
-
- For zones that partially use the Opt-Out flag, if there is a logical
- pattern for that use, the pattern could be maintained by using a
- local policy on the server.
-
-
-8. Validator Considerations
-
-8.1. Responses with Unknown Hash Types
-
- A validator MUST ignore NSEC3 RRs with unknown hash types. The
- practical result of this is that responses containing only such NSEC3
- RRs will generally be considered bogus.
-
-8.2. Verifying NSEC3 RRs
-
- A validator MUST ignore NSEC3 RRs with a Flag fields value other than
- zero or one.
-
- A validator MAY treat a response as bogus if the response contains
- NSEC3 RRs that contain different values for hash algorithm,
- iterations, or salt from each other for that zone.
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 22]
-\f
-Internet-Draft nsec3 July 2007
-
-
-8.3. Closest Encloser Proof
-
- In order to verify a closest encloser proof, the validator MUST find
- the longest name, X, such that
-
- o X is an ancestor of QNAME that is matched by an NSEC3 RR present
- in the response. This is a candidate for the closest encloser.
- And:
-
- o The name one label longer than X (but still an ancestor of--or
- equal to--QNAME) is covered by an NSEC3 RR present in the
- response.
-
- One possible algorithm for verifying this proof is as follows:
-
- 1. Set SNAME=QNAME. Clear the flag.
-
- 2. Check whether SNAME exists:
-
- * If there is no NSEC3 RR in the response that matches SNAME
- (i.e., an NSEC3 RR whose owner name is the same as the hash of
- SNAME, prepended as a single label to the zone name), clear
- the flag.
-
- * If there is an NSEC3 RR in the response that covers SNAME, set
- the flag.
-
- * If there is a matching NSEC3 RR in the response and the flag
- was set, then the proof is complete, and SNAME is the closest
- encloser.
-
- * If there is a matching NSEC3 RR in the response, but the flag
- is not set, then the response is bogus.
-
- 3. Truncate SNAME by one label from the left, go to step 2.
-
- Once the closest encloser has been discovered, the validator MUST
- check that the NSEC3 RR that has the closest encloser as the original
- owner name is from the proper zone. The DNAME type bit must not be
- set and the NS type bit may only be set if the SOA type bit is set.
- If this is not the case, it would be an indication that an attacker
- is using them to falsely deny the existence of RRs for which the
- server is not authoritative.
-
- In the following descriptions, the phrase "a closest (provable)
- encloser proof for X" means that the algorithm above (or an
- equivalent algorithm) proves that X does not exist by proving that an
- ancestor of X is its closest encloser.
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 23]
-\f
-Internet-Draft nsec3 July 2007
-
-
-8.4. Validating Name Error Responses
-
- A validator MUST verify that there is a closest encloser proof for
- QNAME present in the response and that there is an NSEC3 RR that
- covers the wildcard at the closest encloser (i.e., the name formed by
- prepending the asterisk label to the closest encloser.)
-
-8.5. Validating No Data Responses, QTYPE is not DS
-
- The validator MUST verify that an NSEC3 RR that matches QNAME is
- present and that both the QTYPE and the CNAME type are not set in its
- Type Bit Maps field.
-
- Note that this test also covers the case where the NSEC3 RR exists
- because it corresponds to an empty non-terminal, in which case the
- NSEC3 RR will have an empty Type Bit Maps field.
-
-8.6. Validating No Data Responses, QTYPE is DS
-
- If there is an NSEC3 RR that matches QNAME present in the response,
- then that NSEC3 RR MUST NOT have the bits corresponding to DS and
- CNAME set in its Type Bit Maps field.
-
- If there is no such NSEC3 RR, then the validator MUST verify that a
- closest provable encloser proof for QNAME is present in the response,
- and that the NSEC3 RR that covers the "next closer" name has the Opt-
- Out bit set.
-
-8.7. Validating Wildcard No Data Responses
-
- The validator MUST verify a closest encloser proof for QNAME and MUST
- find an NSEC3 RR present in the response that matches the wildcard
- name generated by prepending the asterisk label to the closest
- encloser. Furthermore, the bits corresponding to both QTYPE and
- CNAME MUST NOT be set in the wildcard matching NSEC3 RR.
-
-8.8. Validating Wildcard Answer Responses
-
- The verified wildcard answer RRSet in the response provides the
- validator with a (candidate) closest encloser for QNAME. This
- closest encloser is the immediate ancestor to the generating
- wildcard.
-
- Validators MUST verify that there is an NSEC3 RR that covers the
- "next closer" name to QNAME present in the response. This proves
- that QNAME itself did not exist and that the correct wildcard was
- used to generate the response.
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 24]
-\f
-Internet-Draft nsec3 July 2007
-
-
-8.9. Validating Referrals to Unsigned Subzones
-
- The delegation name in a referral is the owner name of the NS RRSet
- present in the authority section of the referral response.
-
- If there is an NSEC3 RR present in the response that matches the
- delegation name, then the validator MUST ensure that the NS bit is
- set and that the DS bit is not set in the Type Bit Maps field of the
- NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from
- the correct (i.e., parent) zone. This is done by ensuring that the
- SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.
-
- Note that the presence of an NS bit implies the absence of a DNAME
- bit, so there is no need to check for the DNAME bit in the Type Bit
- Maps field of the NSEC3 RR.
-
- If there is no NSEC3 RR present that matches the delegation name,
- then the validator MUST verify a closest provable encloser proof for
- the delegation name. The validator MUST verify that the Opt-Out bit
- is set in the NSEC3 RR that covers the "next closer" name to the
- delegation name.
-
-
-9. Resolver Considerations
-
-9.1. NSEC3 Resource Record Caching
-
- Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs
- when returning responses that contain them. In DNSSEC [RFC4035], in
- many cases it is possible to find the correct NSEC RR to return in a
- response by name (e.g., when returning a referral, the NSEC RR will
- always have the same owner name as the delegation.) With this
- specification, that will not be true, nor will a cache be able to
- calculate the name(s) of the appropriate NSEC3 RR(s).
- Implementations may need to use new methods for caching and
- retrieving NSEC3 RRs.
-
-9.2. Use of the AD Bit
-
- The AD bit, as defined by [RFC4035], MUST NOT be set when returning a
- response containing a closest (provable) encloser proof in which the
- NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
-
- This rule is based on what this closest encloser proof actually
- proves: names that would be covered by the Opt-Out NSEC3 RR may or
- may not exist as insecure delegations. As such, not all the data in
- responses containing such closest encloser proofs will have been
- cryptographically verified, so the AD bit cannot be set.
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 25]
-\f
-Internet-Draft nsec3 July 2007
-
-
-10. Special Considerations
-
-10.1. Domain Name Length Restrictions
-
- Zones signed using this specification have additional domain name
- length restrictions imposed upon them. In particular, zones with
- names that, when converted into hashed owner names, exceed the 255
- octet length limit imposed by [RFC1035] cannot use this
- specification.
-
- The actual maximum length of a domain name in a particular zone
- depends on both the length of the zone name (versus the whole domain
- name) and the particular hash function used.
-
- As an example, SHA-1 produces a hash of 160 bits. The base-32
- encoding of 160 bits results in 32 characters. The 32 characters are
- prepended to the name of the zone as a single label, which includes a
- length field of a single octet. The maximum length of the zone name,
- when using SHA-1, is 222 octets (255 - 33).
-
-10.2. DNAME at the Zone Apex
-
- The DNAME specification [RFC2672] section 3 has a 'no-descendants'
- limitation. If a DNAME RR is present at node N, there MUST be no
- data at any descendant of N.
-
- If N is the apex of the zone, there will be NSEC3 and RRSIG types
- present at descendants of N. This specification updates the DNAME
- specification to allow NSEC3 and RRSIG types at descendants of the
- apex regardless of the existence of DNAME at the apex.
-
-10.3. Iterations
-
- Setting the number of iterations used allows the zone owner to choose
- the cost of computing a hash, and so the cost of generating a
- dictionary. Note that this is distinct from the effect of salt,
- which prevents the use of a single precomputed dictionary for all
- time.
-
- Obviously the number of iterations also affects the zone owner's cost
- of signing and serving the zone as well as the validator's cost of
- verifying responses from the zone. We therefore impose an upper
- limit on the number of iterations. We base this on the number of
- iterations that approximates the cost of verifying an RRSet.
-
- The limits, therefore, are based on the size of the smallest zone
- signing key, rounded up to the nearest table value (or rounded down
- if the key is larger than the largest table value.)
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 26]
-\f
-Internet-Draft nsec3 July 2007
-
-
- A zone owner MUST NOT use a value higher than shown in the table
- below for iterations for the given key size. A resolver MAY treat a
- response with a higher value as insecure, after the validator has
- verified that the signature over the NSEC3 RR is correct.
-
- +----------+------------+
- | Key Size | Iterations |
- +----------+------------+
- | 1024 | 150 |
- | 2048 | 500 |
- | 4096 | 2,500 |
- +----------+------------+
-
- This table is based on an approximation of the ratio between the cost
- of an SHA-1 calculation and the cost of an RSA verification for keys
- of size 1024 bits (150 to 1), 2048 bits (500 to 1) and 4096 bits
- (2500 to 1).
-
- The ratio between SHA-1 calculation and DSA verification is higher
- (1500 to 1 for keys of size 1024). A higher iteration count degrades
- performance, while DSA verification is already more expensive than
- RSA for the same key size. Therefore the values in the table MUST be
- used independent of the key algorithm.
-
-10.4. Transitioning a Signed Zone from NSEC to NSEC3
-
- When transitioning an already signed and trusted zone to this
- specification, care must be taken to prevent client validation
- failures during the process.
-
- The basic procedure is as follows:
-
- 1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases
- described in Section 2. The actual method for safely and
- securely changing the DNSKEY RRSet of the zone is outside the
- scope of this specification. However, the end result MUST be
- that all DS RRs in the parent use the specified algorithm
- aliases.
-
- After this transition is complete, all NSEC3-unaware clients will
- treat the zone as insecure. At this point, the authoritative
- server still returns negative and wildcard responses that contain
- NSEC RRs.
-
- 2. Add signed NSEC3 RRs to the zone, either incrementally or all at
- once. If adding incrementally, then the last RRSet added MUST be
- the NSEC3PARAM RRSet.
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 27]
-\f
-Internet-Draft nsec3 July 2007
-
-
- 3. Upon the addition of the NSEC3PARAM RRSet, the server switches to
- serving negative and wildcard responses with NSEC3 RRs according
- to this specification.
-
- 4. Remove the NSEC RRs either incrementally or all at once.
-
-10.5. Transitioning a Signed Zone From NSEC3 to NSEC
-
- To safely transition back to a DNSSEC [RFC4035] signed zone, simply
- reverse the procedure above:
-
- 1. Add NSEC RRs incrementally or all at once.
-
- 2. Remove the NSEC3PARAM RRSet. This will signal the server to use
- the NSEC RRs for negative and wildcard responses.
-
- 3. Remove the NSEC3 RRs either incrementally or all at once.
-
- 4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers.
- After this transition is complete, all NSEC3-unaware clients will
- treat the zone as secure.
-
-
-11. IANA Considerations
-
- This document updates the IANA registry "DOMAIN NAME SYSTEM
- PARAMETERS" [http://www.iana.org/assignments/dns-parameters] in sub-
- registry "TYPES", by defining two new types. Section 3 defines the
- NSEC3 RR type NN, (value 50 suggested). Section 4 defines the
- NSEC3PARAM RR type MM (value 51 suggested).
-
- This document updates the IANA registry "DNS SECURITY ALGORITHM
- NUMBERS - per [RFC4035]"
- http://www.iana.org/assignments/dns-sec-alg-numbers]. Section 2
- defines the aliases DSA-NSEC3-SHA1 (XX) and RSASHA1-NSEC3-SHA1 (YY)
- for respectively existing registrations DSA and RSASHA1 in
- combination with NSEC3 hash algorithm SHA1.
-
- Since these algorithm numbers are aliases for existing DNSKEY
- algorithm numbers, the flags that exist for the original algorithm
- are valid for the alias algorithm.
-
- This document creates a new IANA registry for NSEC3 flags. This
- registry should be named "DNSSEC NSEC3 Flags". The initial contents
- of this registry are:
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 28]
-\f
-Internet-Draft nsec3 July 2007
-
-
- 0 1 2 3 4 5 6 7
- +---+---+---+---+---+---+---+---+
- | | | | | | | |Opt|
- | | | | | | | |Out|
- +---+---+---+---+---+---+---+---+
-
- bit 7 is the Opt-Out flag.
-
- bits 0 - 6 are available for assignment.
-
- Assignment of additional NSEC3 Flags in this registry requires IETF
- Standards Action [RFC2434].
-
- This document creates a new IANA registry for NSEC3PARAM flags. This
- registry should be named "DNSSEC NSEC3PARAM Flags". The initial
- contents of this registry are:
-
- 0 1 2 3 4 5 6 7
- +---+---+---+---+---+---+---+---+
- | | | | | | | | 0 |
- +---+---+---+---+---+---+---+---+
-
- bit 7 is reserved and must be 0.
-
- bits 0 - 6 are available for assignment.
-
- Assignment of additional NSEC3PARAM Flags in this registry requires
- IETF Standards Action [RFC2434].
-
- Finally, this document creates a new IANA registry for NSEC3 hash
- algorithms. This registry should be named "DNSSEC NSEC3 Hash
- Algorithms". The initial contents of this registry are:
-
- 0 is Reserved
-
- 1 is SHA-1.
-
- 2-255 Available for assignment
-
- Assignment of additional NSEC3 hash algorithms in this registry
- requires IETF Standards Action [RFC2434].
-
-
-12. Security Considerations
-
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 29]
-\f
-Internet-Draft nsec3 July 2007
-
-
-12.1. Hashing Considerations
-
-12.1.1. Dictionary Attacks
-
- The NSEC3 RRs are still susceptible to dictionary attacks (i.e. the
- attacker retrieves all the NSEC3 RRs, then calculates the hashes of
- all likely domain names, comparing against the hashes found in the
- NSEC3 RRs, and thus enumerating the zone). These are substantially
- more expensive than enumerating the original NSEC RRs would have
- been, and in any case, such an attack could also be used directly
- against the name server itself by performing queries for all likely
- names, though this would obviously be more detectable. The expense
- of this off-line attack can be chosen by setting the number of
- iterations in the NSEC3 RR.
-
- Zones are also susceptible to a pre-calculated dictionary attack --
- that is, a list of hashes for all likely names is computed once, then
- NSEC3 RR is scanned periodically and compared against the precomputed
- hashes. This attack is prevented by changing the salt on a regular
- basis.
-
- The salt SHOULD be at least 64 bits long and unpredictable, so that
- an attacker cannot anticipate the value of the salt and compute the
- next set of dictionaries before the zone is published.
-
-12.1.2. Collisions
-
- Hash collisions between QNAME and the owner name of an NSEC3 RR may
- occur. When they do, it will be impossible to prove the non-
- existence of the colliding QNAME. However, with SHA-1, this is
- highly unlikely (on the order of 1 in 2^160). Note that DNSSEC
- already relies on the presumption that a cryptographic hash function
- is second pre-image resistant, since these hash functions are used
- for generating and validating signatures and DS RRs.
-
-12.1.3. Transitioning to a New Hash Algorithm
-
- Since validators are instructed to ignore NSEC3 RRs with unknown hash
- algorithms, simply using a new or unknown hash algorithm directly
- will lead to validation failures with clients that understand NSEC3
- but do not understand the hash algorithm.
-
- When transitioning to a new hash algorithm, care must be taken to
- prevent client validation failures during the process. This is done
- using a similar procedure to transitioning from NSEC to NSEC3
- (Section 10.4)
-
- The basic procedure is as follows:
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 30]
-\f
-Internet-Draft nsec3 July 2007
-
-
- 1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases
- allocated for the new NSEC3 hash algorithm. The actual method
- for safely and securely changing the DNSKEY RRSet of the zone is
- outside the scope of this specification. However, the end result
- MUST be that all DS RRs in the parent use the specified algorithm
- aliases.
-
- After this transition is complete, all clients unaware of the new
- hash algorithm will treat the zone as insecure. At this point,
- the authoritative server still returns negative and wildcard
- responses that contain NSEC3 RRs with the known hash function.
-
- 2. Add signed NSEC3 RRs with the new hash algorithm to the zone,
- either incrementally or all at once. If adding incrementally,
- then the last RRSet added MUST be the NSEC3PARAM RRSet containing
- the new hash algorithm.
-
- 3. Upon the addition of the NSEC3PARAM RR containing the new hash
- algorithm, and after the removal of the NSEC3PARAM RR containing
- the old hash algorithm, the server switches to serving negative
- and wildcard responses with NSEC3 RRs containing the new hash
- algorithm.
-
- 4. Remove the NSEC3 RRs containing the old hash algorithm either
- incrementally or all at once.
-
-12.1.4. Using High Iteration Values
-
- Since validators should treat responses containing NSEC3 RRs with
- high iteration values as insecure, presence of just one signed NSEC3
- RR with a high iteration value in a zone provides attackers with a
- possible downgrade attack.
-
- The attack is simply to remove any existing NSEC3 RRs from a
- response, and replace or add a single (or multiple) NSEC3 RR that
- uses a high iterations value to the response. Validators will then
- be forced to treat the response as insecure. This attack would be
- effective only when all of following conditions are met:
-
- o There is at least one signed NSEC3 RR that uses a high iterations
- value present in the zone.
-
- o The attacker has access to one or more of these NSEC3 RRs. This
- is trivially true when the NSEC3 RRs with high iterations values
- are being returned in typical responses, but may also be true if
- the attacker can access the zone via AXFR or IXFR queries, or any
- other methodology.
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 31]
-\f
-Internet-Draft nsec3 July 2007
-
-
- Using a high number of iterations also introduces an additional
- denial-of-service opportunity against servers, since servers must
- calculate several hashes per negative or wildcard response.
-
-12.2. Opt-Out Considerations
-
- The Opt-Out Flag (O) allows for unsigned names, in the form of
- delegations to unsigned zones, to exist within an otherwise signed
- zone. All unsigned names are, by definition, insecure, and their
- validity or existence cannot be cryptographically proven.
-
- In general:
-
- o Resource records with unsigned names (whether existing or not)
- suffer from the same vulnerabilities as RRs in an unsigned zone.
- These vulnerabilities are described in more detail in [RFC3833]
- (note in particular sections 2.3, "Name Chaining" and 2.6,
- "Authenticated Denial of Domain Names").
-
- o Resource records with signed names have the same security whether
- or not Opt-Out is used.
-
- Note that with or without Opt-Out, an insecure delegation may be
- undetectably altered by an attacker. Because of this, the primary
- difference in security when using Opt-Out is the loss of the ability
- to prove the existence or nonexistence of an insecure delegation
- within the span of an Opt-Out NSEC3 RR.
-
- In particular, this means that a malicious entity may be able to
- insert or delete RRs with unsigned names. These RRs are normally NS
- RRs, but this also includes signed wildcard expansions (while the
- wildcard RR itself is signed, its expanded name is an unsigned name).
-
- Note that being able to add a delegation is functionally equivalent
- to being able to add any RR type: an attacker merely has to forge a
- delegation to name server under his/her control and place whatever
- RRs needed at the subzone apex.
-
- While in particular cases, this issue may not present a significant
- security problem, in general it should not be lightly dismissed.
- Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly.
- In particular, zone signing tools SHOULD NOT default to using Opt-
- Out, and MAY choose to not support Opt-Out at all.
-
-12.3. Other Considerations
-
- Walking the NSEC3 RRs will reveal the total number of RRs in the zone
- (plus empty non-terminals), and also what types there are. This
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 32]
-\f
-Internet-Draft nsec3 July 2007
-
-
- could be mitigated by adding dummy entries, but certainly an upper
- limit can always be found.
-
-
-13. References
-
-13.1. Normative 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.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2308, March 1998.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning,
- "Domain Name System (DNS) IANA Considerations", BCP 42,
- RFC 2929, September 2000.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 33]
-\f
-Internet-Draft nsec3 July 2007
-
-
- Extensions", RFC 4035, March 2005.
-
- [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
- Encodings", RFC 4648, October 2006.
-
-13.2. Informative References
-
- [I-D.jas-dnsext-no]
- Josefsson, S., "Authenticating denial of existence in DNS
- with minimum disclosure", draft-jas-dnsext-no-00 (work in
- progress), July 2000.
-
- [I-D.laurie-dnsext-nsec2v2]
- Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format",
- draft-laurie-dnsext-nsec2v2-00 (work in progress),
- December 2004.
-
- [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
- RFC 2672, August 1999.
-
- [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
- Specification Version 2.0", RFC 2898, September 2000.
-
- [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
- Name System (DNS)", RFC 3833, August 2004.
-
- [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
- System", RFC 4592, July 2006.
-
- [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security
- (DNSSEC) Opt-In", RFC 4956, July 2007.
-
-
-Appendix A. Example Zone
-
- This is a zone showing its NSEC3 RRs. They can also be used as test
- vectors for the hash algorithm.
-
- The overall TTL and class are specified in the SOA RR, and are
- subsequently omitted for clarity.
-
- The zone is preceded by a list that contains the hashes of the
- original ownernames.
-
-
- ; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
- ; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl
- ; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 34]
-\f
-Internet-Draft nsec3 July 2007
-
-
- ; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
- ; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r
- ; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
- ; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
- ; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
- ; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc
- ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
- ; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv
- ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
- ; = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
- example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
- RRSIG SOA 133 1 3600 20150420235959 20051021000000 (
- 62827 example.
- hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ
- ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+
- rynLZNqsbLm40Q== )
- NS ns1.example.
- NS ns2.example.
- RRSIG NS 133 1 3600 20150420235959 20051021000000 (
- 62827 example.
- D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM
- gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5
- JpiZcff2Cj2B0w== )
- MX 1 xx.example.
- RRSIG MX 133 1 3600 20150420235959 20051021000000 (
- 62827 example.
- jsGuTpXTTrZHzUKnViUpJ8YyGNpDd6n/sy2g
- HnSC0nj2jPxTC5VENLo3GxSpCSA5DlAz57p+
- RllUJk3DWktkjw== )
- DNSKEY 256 3 133 (
- AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
- 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
- ExXT48OGGdbfIme5 )
- DNSKEY 257 3 133 (
- AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
- cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
- zsYKWJ7BvR2894hX )
- RRSIG DNSKEY 133 1 3600 20150420235959 (
- 20051021000000 22088 example.
- Xpo9ptByXb8M1JR1i0KuRmKGc/YeOLcc6Ptn
- RJOx6ADLSL2mU6AYX5tAJRMTKTXk6waLIaxu
- liqUBOkCjLUZMw== )
- NSEC3PARAM 1 0 12 aabbccdd
- RRSIG NSEC3PARAM 133 1 3600 20150420235959 (
- 20051021000000 62827 example.
- pwUfI8cF9JJn5dTWI24nJy92HYrRPtPgHtgi
- jAlKx9QELe68pLKuGU/8Sf87kyV7yMXJYVhf
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 35]
-\f
-Internet-Draft nsec3 July 2007
-
-
- HIB8wmHllsqM+g== )
- 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
- 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
- SOA NSEC3PARAM RRSIG )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF
- xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix
- 4eI9tMfaTVgehQ== )
- 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
- RRSIG A 133 2 3600 20150420235959 20051021000000 (
- 62827 example.
- GtJTFlvT5eYaK3rNUPQjpCKoIefvWZxQrDxU
- jYsmoIWdLOVOuD5ZSDDQA3anDctOHdA/XbXn
- o2uyWso1OzVlgg== )
- NSEC3 1 1 12 aabbccdd (
- 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- fJER1Z3nGoN0HmZm99lqNLSpIf7jLXTMoGm2
- k4gIwlc0R4DztJp6Sq37OV6XnGdre4MfgRpB
- mAcgpPWC5A5eiw== )
- 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
- 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- os2mHXmu3bsaWu0XzT1R61fHL1a3LvyQ6bKq
- oKokSyJ0ch0jBqEdxP2BqUe0WW0ja19fQGCG
- 8Bc+L9MbAeYsrw== )
- 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
- b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- QrjOpXVIvodCw0O8uPMNA+yEeS/o3KKkEIPX
- r5DoEShq2hymAsRTc/t9BvRKpcSTExyc5m3T
- vYN3GgN0W/0WHQ== )
- a.example. NS ns1.a.example.
- NS ns2.a.example.
- DS 58470 5 1 (
- 3079F1593EBAD6DC121E202A8B766A6A4837206C )
- RRSIG DS 133 2 3600 20150420235959 20051021000000 (
- 62827 example.
- qxw4j5LNe70UDu121YqAaqQjyjYbdKNd/4bE
- nH0kjQswuiGs9EuArCBhcWocWQDBku+A4HMH
- JdLqJr5p4JctLg== )
- ns1.a.example. A 192.0.2.5
- ns2.a.example. A 192.0.2.6
- ai.example. A 192.0.2.9
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 36]
-\f
-Internet-Draft nsec3 July 2007
-
-
- RRSIG A 133 2 3600 20150420235959 20051021000000 (
- 62827 example.
- qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag
- lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5
- BXfXAqURwLqznA== )
- HINFO "KLH-10" "ITS"
- RRSIG HINFO 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- BuDv+No06VEcIsEnvBdjdKm6kxQGrhOgKEKb
- Gsb8DJRjY7Lia+YG2//s6OlOIfxPmLlLiYpA
- i3q2sEjTJhocGQ== )
- AAAA 2001:db8:0:0:0:0:f00:baa9
- RRSIG AAAA 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M
- hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x
- 2ruyuN0zC+PABA== )
- b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
- gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- GWDmUk8Sv0dxy/UZFol4Ss7Wz3wBiongcnVy
- strNODWwdnoO9z6pDh8JLk58ExfEgXm79i4b
- Ma6C/s/bkk1LvA== )
- c.example. NS ns1.c.example.
- NS ns2.c.example.
- ns1.c.example. A 192.0.2.7
- ns2.c.example. A 192.0.2.8
- gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
- ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
- RRSIG )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- DCkJyHQSgA9HNA2AQUENLfmAdAqQ4iIcuqZV
- pF2x/i1UyWIBuV25iESs4hhwRVIU5uMZaBGE
- lNwi0H6f66BpOA== )
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
- k8udemvp1j2f7eg6jebps17vp3n8i58h )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- fvKWkD3lXNLyUn0/gN+i3Z8301oRujSFFrJy
- SfAPS2Q1bw1Q5eQoy7IE+ZtUVO15ha6C9cUh
- CArJyEk247MADA== )
- k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
- kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- IKJfInxfypsDiXKgT6HDvCPEIBu9lZCc0CWl
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 37]
-\f
-Internet-Draft nsec3 July 2007
-
-
- c46+Gj/Jrg1NBkSJkKMjCERp1HT8tKU+zYp5
- Kyio/cddEaa5Gg== )
- kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd (
- q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- j+XRmZBLAu/s0Ah49x7SChH2VsXAMD3nJE0m
- UEjzrjFxkdjhdIAFNlvPMn8gy6mIVe5eNc3r
- 4+2KaJUEJhyUEQ== )
- ns1.example. A 192.0.2.1
- RRSIG A 133 2 3600 20150420235959 20051021000000 (
- 62827 example.
- ratEKfeWD/pJJHO/XqEINvOp3so7pn9Pphxn
- fRiCOVsa527M/ucRcQqGYCF0CN4jAXhW+6BS
- ZzT0om+VdioRmg== )
- ns2.example. A 192.0.2.2
- RRSIG A 133 2 3600 20150420235959 20051021000000 (
- 62827 example.
- mW/DJMbQyD5y5C+a70vWyIWZyQ+Xg1zzkWHX
- w3jfqmePgpdJnMrpGOcRIpy5irCFWiCwTp2o
- cPT+k0ccpxtkLQ== )
- q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
- r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- ktIfH8VRjEKYPB0Qf4EdTuSlYn4DVSRRaGWc
- kVGmKzreEU5zs97CL8OQSa6C0JZX2yMBXijC
- Wu6EvgCXrflgiQ== )
- r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
- t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- SzeyaiFOy9dFO1RKHAK4uVCb5GF4rNnxFMXu
- 6hpM44cmLcDgshlnG1CwkkcihfKOiPIBWd7I
- bGhsbhqrBrn5Dg== )
- t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
- 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
- RRSIG )
- RRSIG NSEC3 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- hkULY2VaEg8lvI0cf+YkUB0rvOORGMGJnfms
- h2OecPBYfI9XGUBvqgIyNpNpK3nIFoW/VNO+
- 3H+6P1NzivDmog== )
- *.w.example. MX 1 ai.example.
- RRSIG MX 133 2 3600 20150420235959 20051021000000 (
- 62827 example.
- DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR
- c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 38]
-\f
-Internet-Draft nsec3 July 2007
-
-
- a7Xfz/f9xzvSTw== )
- x.w.example. MX 1 xx.example.
- RRSIG MX 133 3 3600 20150420235959 20051021000000 (
- 62827 example.
- BLSDMos8kYR7+2U7iwwdqdhU82hzq0s57xtw
- F08tWU/d19jrNO6LdWfBL/FJ8zL8ZpEjhh6b
- 8cj0f5yQOUyShw== )
- x.y.w.example. MX 1 xx.example.
- RRSIG MX 133 4 3600 20150420235959 20051021000000 (
- 62827 example.
- GPzELyUCxrnyep8uMcqthUXjTqYBmgeaveb9
- 2vQgzUyPLLamNN/YqMHr6tGQNxeMAhclxUSQ
- eoCggUBVhFfB1Q== )
- xx.example. A 192.0.2.10
- RRSIG A 133 2 3600 20150420235959 20051021000000 (
- 62827 example.
- Sz+fPqY8II1VDq+dY48Q40dq1aoBR2RAuhKg
- QNKXEYcULtJo/hxxfEAkJSNBKU5QnHpnnT9L
- jqaSdob7ZhdxHg== )
- HINFO "KLH-10" "TOPS-20"
- RRSIG HINFO 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- YJFwmD0By0NpGEvO1nE1ZTH10XrmpKnVuAEI
- cAxLLHyPs3qyGQdDEG7sQX5+PfiOGZrNmZef
- 8NgQhW8kGEgN1Q== )
- AAAA 2001:db8:0:0:0:0:f00:baaa
- RRSIG AAAA 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- VAJBlXoTOScrIM6yPlDsd9o05v39qIzFnemR
- 2vgw1s4l8maJVWi9IHEg8oiypJvGwSCP1nFs
- EOlXyNFQJ0fWGA== )
-
-
-Appendix B. Example Responses
-
- The examples in this section show response messages using the signed
- zone example in Appendix A.
-
-B.1. Name Error
-
- An authoritative name error. The NSEC3 RRs prove that the name does
- not exist and that there is no wildcard RR that should have been
- expanded.
-
-;; Header: QR AA DO RCODE=3
-;;
-;; Question
-a.c.x.w.example. IN A
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 39]
-\f
-Internet-Draft nsec3 July 2007
-
-
-;; Answer
-;; (empty)
-
-;; Authority
-
-example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
-example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 (
- 62827 example.
- hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ
- ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+
- rynLZNqsbLm40Q== )
-
-;; NSEC3 RR that covers the "next closer" name (c.x.w.example)
-;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh
-
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
- 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
- SOA NSEC3PARAM RRSIG )
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF
- xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix
- 4eI9tMfaTVgehQ== )
-
-;; NSEC3 RR that matches the closest encloser (x.w.example)
-;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
-
-b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
- gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
-b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- GWDmUk8Sv0dxy/UZFol4Ss7Wz3wBiongcnVy
- strNODWwdnoO9z6pDh8JLk58ExfEgXm79i4b
- Ma6C/s/bkk1LvA== )
-
-;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example)
-;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m
-
-35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
- b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- QrjOpXVIvodCw0O8uPMNA+yEeS/o3KKkEIPX
- r5DoEShq2hymAsRTc/t9BvRKpcSTExyc5m3T
- vYN3GgN0W/0WHQ== )
-
-;; Additional
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 40]
-\f
-Internet-Draft nsec3 July 2007
-
-
-;; (empty)
-
- The query returned three NSEC3 RRs that prove that the requested data
- does not exist and that no wildcard expansion applies. The negative
- response is authenticated by verifying the NSEC3 RRs. The
- corresponding RRSIGs indicate that the NSEC3 RRs are signed by an
- "example" DNSKEY of algorithm 133 and with key tag 62827. The
- resolver needs the corresponding DNSKEY RR in order to authenticate
- this answer.
-
- One of the owner names of the NSEC3 RRs matches the closest encloser.
- One of the NSEC3 RRs prove that there exists no longer name. One of
- the NSEC3 RRs prove that there exists no wildcard RRSets that should
- have been expanded. The closest encloser can be found by applying
- the algorithm in section Section 8.3.
-
- In the above example, the name 'x.w.example' hashes to
- 'b4um86eghhds6nea196smvmlo4ors995'. This indicates that this might
- be the closest encloser. To prove that 'c.x.w.example' and
- '*.x.w.example' do not exist, these names are hashed to,
- respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and
- '92pqneegtaue7pjatc3l3qnk738c6v5m'. The first and last NSEC3 RRs
- prove that these hashed owner names do not exist.
-
-B.2. No Data Error
-
- A "no data" response. The NSEC3 RR proves that the name exists and
- that the requested RR type does not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 41]
-\f
-Internet-Draft nsec3 July 2007
-
-
-;; Header: QR AA DO RCODE=0
-;;
-;; Question
-ns1.example. IN MX
-
-;; Answer
-;; (empty)
-
-;; Authority
-example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
-example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 (
- 62827 example.
- hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ
- ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+
- rynLZNqsbLm40Q== )
-
-;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set.
-
-2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd (
- 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
-2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- fJER1Z3nGoN0HmZm99lqNLSpIf7jLXTMoGm2
- k4gIwlc0R4DztJp6Sq37OV6XnGdre4MfgRpB
- mAcgpPWC5A5eiw== )
-;; Additional
-;; (empty)
-
- The query returned an NSEC3 RR that proves that the requested name
- exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"),
- but the requested RR type does not exist (type MX is absent in the
- type code list of the NSEC3 RR), and was not a CNAME (type CNAME is
- also absent in the type code list of the NSEC3 RR.)
-
-B.2.1. No Data Error, Empty Non-Terminal
-
- A "no data" response because of an empty non-terminal. The NSEC3 RR
- proves that the name exists and that the requested RR type does not.
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 42]
-\f
-Internet-Draft nsec3 July 2007
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- y.w.example. IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
- example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 (
- 62827 example.
- hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ
- ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+
- rynLZNqsbLm40Q== )
-
- ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set.
-
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
- k8udemvp1j2f7eg6jebps17vp3n8i58h )
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- fvKWkD3lXNLyUn0/gN+i3Z8301oRujSFFrJy
- SfAPS2Q1bw1Q5eQoy7IE+ZtUVO15ha6C9cUh
- CArJyEk247MADA== )
-
- ;; Additional
- ;; (empty)
-
-
- The query returned an NSEC3 RR that proves that the requested name
- exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"),
- but the requested RR type does not exist (Type A is absent in the
- Type Bit Maps field of the NSEC3 RR). Note that, unlike an empty
- non-terminal proof using NSECs, this is identical to a No Data Error.
- This example is solely mentioned to be complete.
-
-B.3. Referral to an Opt-Out Unsigned Zone
-
- The NSEC3 RRs prove that nothing for this delegation was signed.
- There is no proof that the unsigned delegation exists.
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 43]
-\f
-Internet-Draft nsec3 July 2007
-
-
- ;; Header: QR DO RCODE=0
- ;;
- ;; Question
- mc.c.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- c.example. NS ns1.c.example.
- NS ns2.c.example.
-
- ;; NSEC3 RR that covers the "next closer" name (c.example)
- ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck
-
- 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
- b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
- 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- QrjOpXVIvodCw0O8uPMNA+yEeS/o3KKkEIPX
- r5DoEShq2hymAsRTc/t9BvRKpcSTExyc5m3T
- vYN3GgN0W/0WHQ== )
-
- ;; NSEC3 RR that matches the closest encloser (example)
- ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
-
- 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
- 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
- SOA NSEC3PARAM RRSIG )
- 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF
- xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix
- 4eI9tMfaTVgehQ== )
-
- ;; Additional
- ns1.c.example. A 192.0.2.7
- ns2.c.example. A 192.0.2.8
-
-
- The query returned a referral to the unsigned "c.example." zone. The
- response contains the closest provable encloser of "c.example" to be
- "example", since the hash of "c.example"
- ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR
- and its Opt-Out bit is set.
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 44]
-\f
-Internet-Draft nsec3 July 2007
-
-
-B.4. Wildcard Expansion
-
- A query that was answered with a response containing a wildcard
- expansion. The label count in the RRSIG RRSet in the answer section
- indicates that a wildcard RRSet was expanded to produce this
- response, and the NSEC3 RR proves that no "next closer" name exists
- in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 45]
-\f
-Internet-Draft nsec3 July 2007
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN MX
-
- ;; Answer
- a.z.w.example. MX 1 ai.example.
- a.z.w.example. RRSIG MX 133 2 3600 20150420235959 20051021000000 (
- 62827 example.
- DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR
- c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq
- a7Xfz/f9xzvSTw== )
-
- ;; Authority
- example. NS ns1.example.
- example. NS ns2.example.
- example. RRSIG NS 133 1 3600 20150420235959 20051021000000 (
- 62827 example.
- D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM
- gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5
- JpiZcff2Cj2B0w== )
-
- ;; NSEC3 RR that covers the "next closer" name (z.w.example)
- ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
-
- q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
- r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
- q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- ktIfH8VRjEKYPB0Qf4EdTuSlYn4DVSRRaGWc
- kVGmKzreEU5zs97CL8OQSa6C0JZX2yMBXijC
- Wu6EvgCXrflgiQ== )
-
- ;; Additional
- ai.example. A 192.0.2.9
- ai.example. RRSIG A 133 2 3600 20150420235959 20051021000000 (
- 62827 example.
- qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag
- lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5
- BXfXAqURwLqznA== )
- ai.example. AAAA 2001:db8:0:0:0:0:f00:baa9
- ai.example. RRSIG AAAA 133 2 3600 20150420235959 (
- 20051021000000 62827 example.
- m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M
- hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x
- 2ruyuN0zC+PABA== )
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 46]
-\f
-Internet-Draft nsec3 July 2007
-
-
- The query returned an answer that was produced as a result of
- wildcard expansion. The answer section contains a wildcard RRSet
- expanded as it would be in a traditional DNS response. The RRSIG
- Labels field value of 2 indicates that the answer is the result of
- wildcard expansion, as the "a.z.w.example" name contains 4 labels.
- This also shows that "w.example" exists, so there is no need for an
- NSEC3 RR that matches the closest encloser.
-
- The NSEC3 RR proves that no closer match could have been used to
- answer this query.
-
-B.5. Wildcard No Data Error
-
- A "no data" response for a name covered by a wildcard. The NSEC3 RRs
- prove that the matching wildcard name does not have any RRs of the
- requested type and that no closer match exists in the zone.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN AAAA
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
- example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 (
- 62827 example.
- hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ
- ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+
- rynLZNqsbLm40Q== )
-
- ;; NSEC3 RR that matches the closest encloser (w.example)
- ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
-
- k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
- kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
- k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- IKJfInxfypsDiXKgT6HDvCPEIBu9lZCc0CWl
- c46+Gj/Jrg1NBkSJkKMjCERp1HT8tKU+zYp5
- Kyio/cddEaa5Gg== )
-
- ;; NSEC3 RR that covers the "next closer" name (z.w.example)
- ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 47]
-\f
-Internet-Draft nsec3 July 2007
-
-
- q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
- r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
- q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- ktIfH8VRjEKYPB0Qf4EdTuSlYn4DVSRRaGWc
- kVGmKzreEU5zs97CL8OQSa6C0JZX2yMBXijC
- Wu6EvgCXrflgiQ== )
-
- ;; NSEC3 RR that matches a wildcard at the closest encloser.
- ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
-
- r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
- t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
- r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- SzeyaiFOy9dFO1RKHAK4uVCb5GF4rNnxFMXu
- 6hpM44cmLcDgshlnG1CwkkcihfKOiPIBWd7I
- bGhsbhqrBrn5Dg== )
-
- ;; Additional
- ;; (empty)
-
- The query returned the NSEC3 RRs that prove that the requested data
- does not exist and no wildcard RR applies.
-
-B.6. DS Child Zone No Data Error
-
- A "no data" response for a QTYPE=DS query that was mistakenly sent to
- a name server for the child zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 48]
-\f
-Internet-Draft nsec3 July 2007
-
-
-;; Header: QR AA DO RCODE=0
-;;
-;; Question
-example. IN DS
-
-;; Answer
-;; (empty)
-
-;; Authority
-example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
-example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 (
- 62827 example.
- hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ
- ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+
- rynLZNqsbLm40Q== )
-
-;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set.
-
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
- 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
- SOA NSEC3PARAM RRSIG )
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 (
- 20150420235959 20051021000000 62827 example.
- rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF
- xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix
- 4eI9tMfaTVgehQ== )
-
-;; Additional
-;; (empty)
-
- The query returned an NSEC3 RR showing that the requested was
- answered by the server authoritative for the zone "example". The
- NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3
- RR is from the apex of the child, not from the zone cut of the
- parent. Queries for the "example" DS RRSet should be sent to the
- parent servers (which are in this case the root servers).
-
-
-Appendix C. Special Considerations
-
- The following paragraphs clarify specific behavior and explain
- special considerations for implementations.
-
-C.1. Salting
-
- Augmenting original owner names with salt before hashing increases
- the cost of a dictionary of pre-generated hash-values. For every bit
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 49]
-\f
-Internet-Draft nsec3 July 2007
-
-
- of salt, the cost of a precomputed dictionary doubles (because there
- must be an entry for each word combined with each possible salt
- value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
- salt, multiplying the cost by 2^2040. This means that an attacker
- must, in practice, recompute the dictionary each time the salt is
- changed.
-
- Including a salt, regardless of size, does not affect the cost of
- constructing NSEC3 RRs. It does increase the size of the NSEC3 RR.
-
- There MUST be at least one complete set of NSEC3 RRs for the zone
- using the same salt value.
-
- The salt SHOULD be changed periodically to prevent pre-computation
- using a single salt. It is RECOMMENDED that the salt be changed for
- every re-signing.
-
- Note that this could cause a resolver to see RRs with different salt
- values for the same zone. This is harmless, since each RR stands
- alone (that is, it denies the set of owner names whose hashes, using
- the salt in the NSEC3 RR, fall between the two hashes in the NSEC3
- RR) - it is only the server that needs a complete set of NSEC3 RRs
- with the same salt in order to be able to answer every possible
- query.
-
- There is no prohibition with having NSEC3 RRs with different salts
- within the same zone. However, in order for authoritative servers to
- be able to consistently find covering NSEC3 RRs, the authoritative
- server MUST choose a single set of parameters (algorithm, salt, and
- iterations) to use when selecting NSEC3 RRs.
-
-C.2. Hash Collision
-
- Hash collisions occur when different messages have the same hash
- value. The expected number of domain names needed to give a 1 in 2
- chance of a single collision is about 2^(n/2) for a hash of length n
- bits (i.e. 2^80 for SHA-1). Though this probability is extremely
- low, the following paragraphs deal with avoiding collisions and
- assessing possible damage in the event of an attack using hash
- collisions.
-
-C.2.1. Avoiding Hash Collisions During Generation
-
- During generation of NSEC3 RRs, hash values are supposedly unique.
- In the (academic) case of a collision occurring, an alternative salt
- MUST be chosen and all hash values MUST be regenerated.
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 50]
-\f
-Internet-Draft nsec3 July 2007
-
-
-C.2.2. Second Preimage Requirement Analysis
-
- A cryptographic hash function has a second-preimage resistance
- property. The second-preimage resistance property means that it is
- computationally infeasible to find another message with the same hash
- value as a given message, i.e. given preimage X, to find a second
- preimage X' != X such that hash(X) = hash(X'). The work factor for
- finding a second preimage is of the order of 2^160 for SHA-1. To
- mount an attack using an existing NSEC3 RR, an adversary needs to
- find a second preimage.
-
- Assuming an adversary is capable of mounting such an extreme attack,
- the actual damage is that a response message can be generated which
- claims that a certain QNAME (i.e. the second pre-image) does exist,
- while in reality QNAME does not exist (a false positive), which will
- either cause a security aware resolver to re-query for the non-
- existent name, or to fail the initial query. Note that the adversary
- can't mount this attack on an existing name but only on a name that
- the adversary can't choose and does not yet exist.
-
-
-Authors' Addresses
-
- Ben Laurie
- Nominet
- 17 Perryn Road
- London W3 7LR
- England
-
- Phone: +44 20 8735 0686
- Email: ben@links.org
-
-
- Geoffrey Sisson
- Nominet
- Sandford Gate
- Sandy Lane West
- Oxford OX4 6LB
- UNITED KINGDOM
-
- Phone: +44 1865 332211
- Email: geoff@nominet.org.uk
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 51]
-\f
-Internet-Draft nsec3 July 2007
-
-
- Roy Arends
- Nominet
- Sandford Gate
- Sandy Lane West
- Oxford OX4 6LB
- UNITED KINGDOM
-
- Phone: +44 1865 332211
- Email: roy@nominet.org.uk
-
-
- David Blacka
- VeriSign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- Email: davidb@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 52]
-\f
-Internet-Draft nsec3 July 2007
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2007).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-Laurie, et al. Expires January 2, 2008 [Page 53]
-\f
+++ /dev/null
-
-
-
-DNS Extensions Working Group S. Rose
-Internet-Draft NIST
-Intended status: Standards Track W. Wijngaards
-Expires: May 17, 2008 NLnet Labs
- November 14, 2007
-
-
- Update to DNAME Redirection in the DNS
- draft-ietf-dnsext-rfc2672bis-dname-06
-
-Status of This Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- 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."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on May 17, 2008.
-
-Copyright Notice
-
- Copyright (C) The IETF Trust (2007).
-
-Abstract
-
- The DNAME record provides redirection for a sub-tree of the domain
- name tree in the DNS system. That is, all names that end with a
- particular suffix are redirected to another part of the DNS. This is
- an update to the original specification in RFC 2672.
-
-
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 1]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
-Requirements Language
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
- 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 3
- 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 4
- 2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 5
- 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 5
- 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 6
-
- 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.2. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 7
- 3.3. Acceptance and Intermediate Storage . . . . . . . . . . . 7
- 3.4. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8
-
- 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 10
-
- 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 11
- 5.1. MX, NS and PTR Records Must Point to Target of DNAME . . . 11
- 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 11
- 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 11
- 5.3.1. DNAME bit in NSEC type map . . . . . . . . . . . . . . 11
- 5.3.2. Validators Must Understand DNAME . . . . . . . . . . . 12
- 5.3.2.1. DNAME in Bitmap Causes Invalid Name Error . . . . 12
- 5.3.2.2. Valid Name Error Response Involving DNAME in
- Bitmap . . . . . . . . . . . . . . . . . . . . . . 12
- 5.3.2.3. Response With Synthesized CNAME . . . . . . . . . 12
-
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
-
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
-
- 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
-
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
-
-
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 2]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
-1. Introduction
-
- DNAME is a DNS Resource Record type. DNAME provides redirection from
- a part of the DNS name tree to another part of the DNS name tree.
-
- Take for example, looking through a zone (see RFC 1034 [RFC1034],
- section 4.3.2, step 3) for the domain name "foo.example.com" and a
- DNAME resource record is found at "example.com" indicating that all
- queries under "example.com" be directed to "example.net". The lookup
- process will return to step 1 with the new query name of
- "foo.example.net". Had the query name been "www.foo.example.com" the
- new query name would be "www.foo.example.net".
-
- The DNAME RR is similar to the CNAME RR in that it provides
- redirection. The CNAME RR only provides redirection for exactly one
- name while the DNAME RR provides redirection for all names in a sub-
- tree of the DNS name tree.
-
- This document is an update to the original specification of DNAME in
- RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of
- maintaining address-to-name mappings in a context of network
- renumbering. With a careful set-up, a renumbering event in the
- network causes no change to the authoritative server that has the
- address-to-name mappings. Examples in practice are classless reverse
- address space delegations and punycode alternates for domain spaces.
-
- Another usage of DNAME lies in redirection of name spaces. For
- example, a zone administrator may want sub-trees of the DNS to
- contain the same information. DNAME is also used for redirection of
- ENUM domains to another maintaining party.
-
- This update to DNAME does not change the wire format or the handling
- of DNAME Resource Records by existing software. A new UD (Understand
- Dname) bit in the EDNS flags field can be used to signal that CNAME
- synthesis is not needed. Discussion is added on problems that may be
- encountered when using DNAME.
-
-2. The DNAME Resource Record
-
-2.1. Format
-
- The DNAME RR has mnemonic DNAME and type code 39 (decimal).
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 3]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
- The format of the DNAME record has not changed from the original
- specification in RFC 2672. DNAME has the following format:
-
- <owner> <ttl> <class> DNAME <target>
-
- The format is not class-sensitive. All fields are required. The
- RDATA field target is a domain name. The RDATA field target name
- MUST be sent uncompressed [RFC3597].
-
- The DNAME RR causes type NS additional section processing.
-
-2.2. The DNAME Substitution
-
- DNAMEs cause a name substitution to happen to query names. This is
- called the DNAME substitution. The portion of the QNAME ending with
- the root label that matches the owner name of the DNAME RR is
- replaced with the contents of the DNAME RR's RDATA. The owner name
- of the DNAME is not itself redirected, only domain names below the
- owner name are redirected. Only whole labels are replaced. A name
- is considered below the owner name if it has more labels than the
- owner name, and the labels of the owner name appear at the end of the
- query name. See the table of examples for common cases and corner
- cases.
-
- In the table below, the QNAME refers to the query name. The owner is
- the DNAME owner domain name, and the target refers to the target of
- the DNAME record. The result is the resulting name after performing
- the DNAME substitution on the query name. "no match" means that the
- query did not match the DNAME and thus no substitution is performed
- and a possible error message is returned (if no other result is
- possible). In the examples below, 'cyc' and 'shortloop' contain
- loops.
-
- QNAME owner DNAME target result
- ---------------- -------------- -------------- -----------------
- com. example.com. example.net. <no match>
- example.com. example.com. example.net. <no match>
- a.example.com. example.com. example.net. a.example.net.
- a.b.example.com. example.com. example.net. a.b.example.net.
- ab.example.com. b.example.com. example.net. <no match>
- foo.example.com. example.com. example.net. foo.example.net.
- a.x.example.com. x.example.com. example.net. a.example.net.
- a.example.com. example.com. y.example.net. a.y.example.net.
- cyc.example.com. example.com. example.com. cyc.example.com.
- cyc.example.com. example.com. c.example.com. cyc.c.example.com.
- shortloop.x.x. x. . shortloop.x.
- shortloop.x. x. . shortloop.
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 4]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
- Table 1. DNAME Substitution Examples.
-
- It is possible for DNAMEs to form loops, just as CNAMEs can form
- loops. DNAMEs and CNAMEs can chain together to form loops. A single
- corner case DNAME can form a loop. Resolvers and servers should be
- cautious in devoting resources to a query, but be aware that fairly
- long chains of DNAMEs may be valid. Zone content administrators
- should take care to insure that there are no loops that could occur
- when using DNAME or DNAME/CNAME redirection.
-
- The domain name can get too long during substitution. For example,
- suppose the target name of the DNAME RR is 250 octets in length
- (multiple labels), if an incoming QNAME that has a first label over 5
- octets in length, the result of the result would be a name over 255
- octets. If this occurs the server returns an RCODE of YXDOMAIN
- [RFC2136]. The DNAME record and its signature (if the zone is
- signed) are included in the answer as proof for the YXDOMAIN (value
- 6) RCODE.
-
-2.3. DNAME Apex not Redirected itself
-
- The owner name of a DNAME is not redirected itself. The reason for
- the original decision was that one can have a DNAME at the zone apex
- without problem. Then use this DNAME at the zone apex to point
- queries to the target zone. There still is a need to have the
- customary SOA and NS resource records at the zone apex. This means
- that DNAME does not mirror a zone completely, as it does not mirror
- the zone apex.
-
- Another reason for excluding the DNAME owner from the DNAME
- substitution is that one can then query for the DNAME through RFC
- 1034 [RFC1034] caches.
-
- This means that a DNAME RR is not allowed at the same domain name as
- NS records unless there is also a SOA record present. DNAME RRs are
- not allowed at the parent side of a delegation point but are allowed
- at a zone apex.
-
-2.4. Names Next to and Below a DNAME Record
-
- Other resource records MUST NOT exist below the owner of a DNAME RR.
- To get the contents for names subordinate to that owner, the DNAME
- redirection must be invoked and the resulting target queried. A
- server SHOULD refuse to load a zone that has data below a domain name
- owning a DNAME RR. Also a server SHOULD refuse to load a zone
- subordinate to the owner of a DNAME record in the ancestor zone. See
- Section 5.2 for further restrictions related to dynamic update.
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 5]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
- DNAME is a singleton type, meaning only one DNAME is allowed per
- name. The owner name of a DNAME can only have one DNAME RR, and no
- CNAME RRs can exist at that name. These rules make sure that for a
- single domain name only one redirection exists, and thus no confusion
- which one to follow. A server SHOULD refuse to load a zone that
- violates these rules.
-
- The domain name that owns a DNAME record is allowed to have other
- resource record types at that domain name, except DNAMEs or CNAMEs.
-
- These rules allow DNAME records to be queried through DNAME unaware
- caches.
-
-2.5. Compression of the DNAME record.
-
- The DNAME owner name can be compressed like any other owner name.
- The DNAME RDATA target name MUST NOT be sent out in compressed form,
- so that a DNAME RR can be treated as an unknown type.
-
- Although the previous specification [RFC2672] talked about signaling
- to allow compression of the target name, no such signaling is
- explicitly specified.
-
- RFC2672 stated that the EDNS version had a meaning for understanding
- of DNAME and DNAME target name compression. This document updates
- RFC2672, in that there is no EDNS version signaling for DNAME as of
- yet. However, the flags section of EDNS(0) is updated with a
- Understand-DNAME flag by this document (See Section 3.2).
-
-3. Processing
-
-3.1. Wildcards
-
- The use of DNAME in conjunction with wildcards is discouraged
- [RFC4592]. Thus records of the form "*.example.com DNAME
- example.net" SHOULD NOT be used.
-
- The interaction between the expansion of the wildcard and the
- redirection of the DNAME is non-deterministic. Because the
- processing is non-deterministic, DNSSEC validating resolvers may not
- be able to validate a wildcarded DNAME.
-
- A server MAY give a warning that the behavior is unspecified if such
- a wildcarded DNAME is loaded. The server MAY refuse it, refuse to
- load or refuse dynamic update.
-
-
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 6]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
-3.2. CNAME synthesis
-
- On the server side, the DNAME RR record is always included in the
- answer section of a query, when one is encountered. A CNAME RR
- record with TTL equal to the corresponding DNAME RR is synthesized
- for old resolvers, specifically for the QNAME in the query. DNSSEC
- [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does
- not have to be signed. The DNAME has an RRSIG and a validating
- resolver can check the CNAME against the DNAME record and validate
- the DNAME record.
-
- It does not make sense for the authoritative server to follow the
- chain of DNAMEs, CNAMEs and wildcards outside of the zone of the
- query, as some resolver implementations will remove out-of-zone
- information from the answer.
-
- Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
- equal to the TTL of the corresponding DNAME record. The TTL of zero
- means that the CNAME can be discarded immediately after processing
- the answer. DNAME aware resolvers can set the Understand-DNAME (UD
- bit) to receive a response with only the DNAME RR and no synthesized
- CNAMEs.
-
- The UD bit is part of the EDNS extended RCODE and Flags field. It is
- used to omit server processing, transmission and resolver processing
- of unsigned synthesized CNAMEs. Resolvers can set this in a query to
- request omission of the synthesized CNAMEs. Servers copy the UD bit
- to the response, and can omit synthesized CNAMEs from the answer.
- Older resolvers do not set the UD bit, and older servers do not copy
- the UD bit to the answer, and will not omit synthesized CNAMEs.
-
- Updated EDNS extended RCODE and Flags field.
-
- +0 (MSB) +1 (LSB)
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 0: | EXTENDED-RCODE | VERSION |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 2: |DO|UD| Z |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- Servers MUST be able to answer a query for a synthesized CNAME. An
- answer containing the synthesized CNAME cannot contain an error
- (since a CNAME has been followed), as per RFC 1034 CNAME rules.
-
-3.3. Acceptance and Intermediate Storage
-
- DNS Caches MUST NOT allow data to be cached below the owner of a
- DNAME RR, except CNAME records and their signatures. CNAME records
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 7]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
- below the owner of a DNAME MUST be re-synthesized from the DNAME, or
- checked against the DNAME record before sending them out. This
- improves consistency of the DNAME and CNAME records below the owner
- of the DNAME.
-
- DNS Caches MUST perform CNAME synthesis on behalf of DNAME-ignorant
- clients. A DNS Cache that understands DNAMEs can send out queries on
- behalf of clients with the UD bit set. After receiving the answers
- the DNS Cache sends replies to DNAME ignorant clients that include
- DNAMEs and synthesized CNAMEs.
-
-3.4. Server algorithm
-
- Below the server algorithm, which appeared in RFC 2672 Section 4.1,
- is expanded to handle the UD bit.
-
- 1. Set or clear the value of recursion available in the response
- depending on whether the name server is willing to provide
- recursive service. If recursive service is available and
- requested via the RD bit in the query, go to step 5, otherwise
- step 2.
-
- 2. Search the available zones for the zone which is the nearest
- ancestor to QNAME. If such a zone is found, go to step 3,
- otherwise step 4.
-
- 3. Start matching down, label by label, in the zone. The matching
- process can terminate several ways:
-
- A. If the whole of QNAME is matched, we have found the node.
-
- If the data at the node is a CNAME, and QTYPE does not match
- CNAME, copy the CNAME RR into the answer section of the
- response, change QNAME to the canonical name in the CNAME RR,
- and go back to step 1.
-
- Otherwise, copy all RRs which match QTYPE into the answer
- section and go to step 6.
-
- B. If a match would take us out of the authoritative data, we
- have a referral. This happens when we encounter a node with
- NS RRs marking cuts along the bottom of a zone.
-
- Copy the NS RRs for the sub-zone into the authority section
- of the reply. Put whatever addresses are available into the
- additional section, using glue RRs if the addresses are not
- available from authoritative data or the cache. Go to step
- 4.
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 8]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
- C. If at some label, a match is impossible (i.e., the
- corresponding label does not exist), look to see whether the
- last label matched has a DNAME record.
-
- If a DNAME record exists at that point, copy that record into
- the answer section. If substitution of its <target> for its
- <owner> in QNAME would overflow the legal size for a <domain-
- name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
- perform the substitution and continue. If the EDNS OPT
- record is present in the query and the UD bit is set, the
- server MAY copy the UD bit to the answer EDNS OPT record, and
- omit CNAME synthesis. Else the server MUST synthesize a
- CNAME record as described above and include it in the answer
- section. Go back to step 1.
-
- If there was no DNAME record, look to see if the "*" label
- exists.
-
- If the "*" label does not exist, check whether the name we
- are looking for is the original QNAME in the query or a name
- we have followed due to a CNAME or DNAME. If the name is
- original, set an authoritative name error in the response and
- exit. Otherwise just exit.
-
- If the "*" label does exist, match RRs at that node against
- QTYPE. If any match, copy them into the answer section, but
- set the owner of the RR to be QNAME, and not the node with
- the "*" label. If the data at the node with the "*" label is
- a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
- into the answer section of the response changing the owner
- name to the QNAME, change QNAME to the canonical name in the
- CNAME RR, and go back to step 1. Otherwise, Go to step 6.
-
- 4. Start matching down in the cache. If QNAME is found in the
- cache, copy all RRs attached to it that match QTYPE into the
- answer section. If QNAME is not found in the cache but a DNAME
- record is present at an ancestor of QNAME, copy that DNAME record
- into the answer section. If there was no delegation from
- authoritative data, look for the best one from the cache, and put
- it in the authority section. Go to step 6.
-
- 5. Use the local resolver or a copy of its algorithm to answer the
- query. Store the results, including any intermediate CNAMEs and
- DNAMEs, in the answer section of the response.
-
- 6. Using local data only, attempt to add other RRs which may be
- useful to the additional section of the query. Exit.
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 9]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
- Note that there will be at most one ancestor with a DNAME as
- described in step 4 unless some zone's data is in violation of the
- no-descendants limitation in section 3. An implementation might take
- advantage of this limitation by stopping the search of step 3c or
- step 4 when a DNAME record is encountered.
-
-4. DNAME Discussions in Other Documents
-
- In [RFC2181], in Section 10.3., the discussion on MX and NS records
- touches on redirection by CNAMEs, but this also holds for DNAMEs.
-
- Excerpt from 10.3. MX and NS records (in RFC 2181).
-
- The domain name used as the value of a NS resource record,
- or part of the value of a MX resource record must not be
- an alias. Not only is the specification clear on this
- point, but using an alias in either of these positions
- neither works as well as might be hoped, nor well fulfills
- the ambition that may have led to this approach. This
- domain name must have as its value one or more address
- records. Currently those will be A records, however in
- the future other record types giving addressing
- information may be acceptable. It can also have other
- RRs, but never a CNAME RR.
-
- The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME.
- [RFC3363] does NOT RECOMMENDED the use of DNAME in the IPv6 reverse
- tree. (Hence, all references to DNAME should have been removed from
- [RFC4294].) Based on the experience gained in the meantime, RFC 3363
- should be revised, dropping all constraints on having DNAME RRs in
- these zones. This would greatly improve the manageability of the
- IPv6 reverse tree. These changes are made explicit below.
-
- In [RFC3363], section 4, DNAME is not recommended for the IPv6
- reverse tree. The opening premise of this section is demonstrably
- wrong. Everything that follows from that premise is also invalid.
-
- In [RFC3363], the paragraph
-
- "The issues for DNAME in the reverse mapping tree appears to be
- closely tied to the need to use fragmented A6 in the main tree: if
- one is necessary, so is the other, and if one isn't necessary, the
- other isn't either. Therefore, in moving RFC 2874 to experimental,
- the intent of this document is that use of DNAME RRs in the reverse
- tree be deprecated."
-
- is to be replaced with the word "DELETED".
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 10]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
- In [RFC4294], the reference to DNAME was left in as a editorial
- oversight. The paragraph
-
- "Those nodes are NOT RECOMMENDED to support the experimental A6 and
- DNAME Resource Records [RFC3363]."
-
- is to be replaced by
-
- "Those nodes are NOT RECOMMENDED to support the experimental
- A6 Resource Record [RFC3363]."
-
-5. Other Issues with DNAME
-
- There are several issues to be aware of about the use of DNAME.
-
-5.1. MX, NS and PTR Records Must Point to Target of DNAME
-
- The names listed as target names of MX, NS and PTR records must be
- canonical hostnames. This means no CNAME or DNAME redirection may be
- present during DNS lookup of the address records for the host. This
- is discussed in RFC 2181 [RFC2181], section 10.3, and RFC 1912
- [RFC1912], section 2.4.
-
- The upshot of this is that although the lookup of a PTR record can
- involve DNAMEs, the name listed in the PTR record can not fall under
- a DNAME. The same holds for NS and MX records. For example, when
- punycode alternates for a zone use DNAME then the NS, MX and PTR
- records that point to that zone must use names without punycode in
- their RDATA. What must be done then is to have the domain names with
- DNAME substitution already applied to it as the MX, NS, PTR data.
- These are valid canonical hostnames.
-
-5.2. Dynamic Update and DNAME
-
- Zones containing a DNAME RR MUST NOT accept a dynamic update message
- that would add a record or delegation with a name existing under a
- DNAME.
-
- A server MUST return an error message with RCODE=REFUSED [RFC2136] in
- response to a dynamic update message that would add a resource record
- under a DNAME in the zone.
-
-5.3. DNSSEC and DNAME
-
-5.3.1. DNAME bit in NSEC type map
-
- When a validator checks the NSEC RRs returned on a name error
- response, it SHOULD check that the DNAME bit is not set. If the
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 11]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
- DNAME bit is set then the DNAME substitution should have been done,
- but has not.
-
-5.3.2. Validators Must Understand DNAME
-
- Examples of why DNSSEC validators MUST understand DNAME.
-
-5.3.2.1. DNAME in Bitmap Causes Invalid Name Error
-
- ;; Header: QR AA DO RCODE=3(NXDOMAIN)
- ;; Question
- foo.bar.example.com. IN A
- ;; Answer
- bar.example.com. NSEC dub.example.com. A DNAME
- bar.example.com. RRSIG NSEC [valid signature]
-
- If this is the response, then only by understanding that the DNAME
- bit means that foo.bar.example.com needed to have been redirected by
- the DNAME, the validator can see that it is a BOGUS reply from an
- attacker that collated existing records from the DNS to create a
- confusing reply.
-
- If the DNAME bit had not been set in the NSEC record above then the
- answer would have validated as a correct name error response.
-
-5.3.2.2. Valid Name Error Response Involving DNAME in Bitmap
-
- ;; Header: QR AA DO RCODE=3(NXDOMAIN)
- ;; Question
- cee.example.com. IN A
- ;; Answer
- bar.example.com. NSEC dub.example.com. A DNAME
- bar.example.com. RRSIG NSEC [valid signature]
-
- This reply has the same NSEC records as the example above, but with
- this query name (cee.example.com), the answer is validated, because
- 'cee' does not get redirected by the DNAME at 'bar'.
-
-5.3.2.3. Response With Synthesized CNAME
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 12]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
- ;; Header: QR AA DO RCODE=0(NOERROR)
- ;; Question
- foo.bar.example.com. IN A
- ;; Answer
- bar.example.com. DNAME bar.example.net.
- bar.example.com. RRSIG DNAME [valid signature]
- foo.bar.example.com. CNAME foo.bar.example.net.
-
- The answer shown above has the synthesized CNAME included. However,
- the CNAME has no signature, since the server does not sign online (it
- is a slow operation and exposes the signing key). So it cannot be
- trusted. It could be altered by an attacker to be
- foo.bar.example.com CNAME bla.bla.example. The DNAME record does
- have its signature included, since it does not change for every query
- name. The validator must verify the DNAME signature and then
- recursively resolve further to query for the foo.bar.example.net A
- record.
-
-6. IANA Considerations
-
- The main purpose of this draft is to discuss issues related to the
- use of DNAME RRs in a DNS zone. The original document registered the
- DNAME Resource Record type code 39 (decimal). IANA should update the
- DNS resource record registry by adding a pointer to this document for
- RR type 39.
-
- This draft requests the second highest bit in the EDNS flags field
- for the Understand-DNAME (UD) flag.
-
-7. Security Considerations
-
- DNAME redirects queries elsewhere, which may impact security based on
- policy and the security status of the zone with the DNAME and the
- redirection zone's security status.
-
- If a validating resolver accepts wildcarded DNAMEs, this creates
- security issues. Since the processing of a wildcarded DNAME is non-
- deterministic and the CNAME that was substituted by the server has no
- signature, the resolver may choose a different result than what the
- server meant, and consequently end up at the wrong destination. Use
- of wildcarded DNAMEs is discouraged in any case [RFC4592].
-
- A validating resolver MUST understand DNAME, according to [RFC4034].
- In Section 5.3.2 examples are given that illustrate this need.
-
-
-
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 13]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
-8. Acknowledgments
-
- The authors of this draft would like to acknowledge Matt Larson for
- beginning this effort to address the issues related to the DNAME RR
- type.
-
-9. References
-
-9.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
- RFC 2672, August 1999.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
- System", RFC 4592, July 2006.
-
-9.2. Informative References
-
- [RFC1912] Barr, D., "Common DNS Operational and Configuration
- Errors", RFC 1912, February 1996.
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 14]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
- [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
- Hain, "Representing Internet Protocol version 6 (IPv6)
- Addresses in the Domain Name System (DNS)", RFC 3363,
- August 2002.
-
- [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
- April 2006.
-
-Authors' Addresses
-
- Scott Rose
- NIST
- 100 Bureau Dr.
- Gaithersburg, MD 20899
- USA
-
- Phone: +1-301-975-8439
- Fax: +1-301-975-6238
- EMail: scottr@nist.gov
-
-
- Wouter Wijngaards
- NLnet Labs
- Kruislaan 419
- Amsterdam 1098 VA
- The Netherlands
-
- Phone: +31-20-888-4551
- EMail: wouter@nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 15]
-\f
-Internet-Draft DNAME Redirection November 2007
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2007).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Rose & Wijngaards Expires May 17, 2008 [Page 16]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-UPDATES RFC 2845 Motorola Laboratories
-Expires: July 2006 January 2006
-
- HMAC SHA TSIG Algorithm Identifiers
- ---- --- ---- --------- -----------
- <draft-ietf-dnsext-tsig-sha-06.txt>
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
-
- 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."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- Use of the Domain Name System TSIG resource record requires
- specification of a cryptographic message authentication code.
- Currently identifiers have been specified only for the HMAC MD5
- (Message Digest) and GSS (Generic Security Service) TSIG algorithms.
- This document standardizes identifiers and implementation
- requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG
- algorithms and standardizes how to specify and handle the truncation
- of HMAC values in TSIG.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
-
- 2. Algorithms and Identifiers..............................4
-
- 3. Specifying Truncation...................................5
- 3.1 Truncation Specification...............................5
-
- 4. TSIG Truncation Policy and Error Provisions.............6
-
- 5. IANA Considerations.....................................7
- 6. Security Considerations.................................7
- 7. Copyright and Disclaimer................................7
-
- 8. Normative References....................................8
- 9. Informative References..................................8
-
- Author's Address...........................................9
- Additional IPR Provisions..................................9
- Expiration and File Name...................................9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-1. Introduction
-
- [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
- authenticate DNS (Domain Name System [STD 13]) queries and responses.
- This RR contains a domain name syntax data item which names the
- authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG-
- ALG.REG.INT name for authentication codes using the HMAC [RFC 2104]
- algorithm with the MD5 [RFC 1321] hash algorithm. IANA has also
- registered "gss-tsig" as an identifier for TSIG authentication where
- the cryptographic operations are delegated to the Generic Security
- Service (GSS) [RFC 3645].
-
- It should be noted that use of TSIG presumes prior agreement, between
- the resolver and server involved, as to the algorithm and key to be
- used.
-
- In Section 2, this document specifies additional names for TSIG
- authentication algorithms based on US NIST SHA (United States,
- National Institute of Science and Technology, Secure Hash Algorithm)
- algorithms and HMAC and specifies the implementation requirements for
- those algorithms.
-
- In Section 3, this document specifies the effect of inequality
- between the normal output size of the specified hash function and the
- length of MAC (message authentication code) data given in the TSIG
- RR. In particular, it specifies that a shorter length field value
- specifies truncation and a longer length field is an error.
-
- In Section 4, policy restrictions and implications related to
- truncation and a new error code to indicate truncation shorter than
- permitted by policy are described and specified.
-
- The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
- defined in [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-2. Algorithms and Identifiers
-
- TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
- queries and responses. They are intended to be efficient symmetric
- authentication codes based on a shared secret. (Asymmetric signatures
- can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
- can be used for transaction signatures.) Used with a strong hash
- function, HMAC [RFC 2104] provides a way to calculate such symmetric
- authentication codes. The only specified HMAC based TSIG algorithm
- identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
-
- The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
- compared with the 128 bits for MD5, and additional hash algorithms in
- the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
- and 512 bits, may be preferred in some cases particularly since
- increasingly successful cryptanalytic attacks are being made on the
- shorter hashes.
-
- Use of TSIG between a DNS resolver and server is by mutual agreement.
- That agreement can include the support of additional algorithms and
- criteria as to which algorithms and truncations are acceptable,
- subject to the restriction and guidelines in Section 3 and 4 below.
- Key agreement can be by the TKEY mechanism [RFC 2930] or other
- mutually agreeable method.
-
- The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
- included in the table below for convenience. Implementations which
- support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
- implement gss-tsig and the other algorithms listed below.
-
- Mandatory HMAC-MD5.SIG-ALG.REG.INT
- Optional gss-tsig
- Mandatory hmac-sha1
- Optional hmac-sha224
- Mandatory hmac-sha256
- Optional hamc-sha384
- Optional hmac-sha512
-
- SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
- When space is at a premium and the strength of the full length of an
- HMAC is not needed, it is reasonable to truncate the HMAC output and
- use the truncated value for authentication. HMAC SHA-1 truncated to
- 96 bits is an option available in several IETF protocols including
- IPSEC and TLS.
-
- The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
- size of the MAC field in octets. But [RFC 2845] does not specify what
- to do if this MAC size differs from the length of the output of HMAC
- for a particular hash function. Truncation is indicated by a MAC size
- less than the HMAC size as specified below.
-
-
-
-3.1 Truncation Specification
-
- The specification for TSIG handling is changed as follows:
-
- 1. If "MAC size" field is greater than HMAC output length:
- This case MUST NOT be generated and if received MUST cause the
- packet to be dropped and RCODE 1 (FORMERR) to be returned.
-
- 2. If "MAC size" field equals HMAC output length:
- Operation is as described in [RFC 2845] with the entire output
- HMAC output present.
-
- 3. "MAC size" field is less than HMAC output length but greater than
- that specified in case 4 below:
- This is sent when the signer has truncated the HMAC output to
- an allowable length, as described in RFC 2104, taking initial
- octets and discarding trailing octets. TSIG truncation can only be
- to an integral number of octets. On receipt of a packet with
- truncation thus indicated, the locally calculated MAC is similarly
- truncated and only the truncated values compared for
- authentication. The request MAC used when calculating the TSIG MAC
- for a reply is the truncated request MAC.
-
- 4. "MAC size" field is less than the larger of 10 (octets) and half
- the length of the hash function in use:
- With the exception of certain TSIG error messages described in
- RFC 2845 section 3.2 where it is permitted that the MAC size be
- zero, this case MUST NOT be generated and if received MUST cause
- the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
- size limit for this case can also, for the hash functions
- mentioned in this document, be stated as less than half the hash
- function length for hash functions other than MD5 and less than 10
- octets for MD5.
-
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-4. TSIG Truncation Policy and Error Provisions
-
- Use of TSIG is by mutual agreement between a resolver and server.
- Implicit in such "agreement" are criterion as to acceptable keys and
- algorithms and, with the extensions in this document, truncations.
- Note that it is common for implementations to bind the TSIG secret
- key or keys that may be in place at a resolver and server to
- particular algorithms. Thus such implementations only permit the use
- of an algorithm if there is an associated key in place. Receipt of an
- unknown, unimplemented, or disabled algorithm typically results in a
- BADKEY error.
-
- Local policies MAY require the rejection of TSIGs even though they
- use an algorithm for which implementation is mandatory.
-
- When a local policy permits acceptance of a TSIG with a particular
- algorithm and a particular non-zero amount of truncation it SHOULD
- also permit the use of that algorithm with lesser truncation (a
- longer MAC) up to the full HMAC output.
-
- Regardless of a lower acceptable truncated MAC length specified by
- local policy, a reply SHOULD be sent with a MAC at least as long as
- that in the corresponding request unless the request specified a MAC
- length longer than the HMAC output.
-
- Implementations permitting multiple acceptable algorithms and/or
- truncations SHOULD permit this list to be ordered by presumed
- strength and SHOULD allow different truncations for the same
- algorithm to be treated as separate entities in this list. When so
- implemented, policies SHOULD accept a presumed stronger algorithm and
- truncation than the minimum strength required by the policy.
-
- If a TSIG is received with truncation which is permitted under
- Section 3 above but the MAC is too short for the local policy in
- force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-5. IANA Considerations
-
- This document, on approval for publication as a standards track RFC,
- (1) registers the new TSIG algorithm identifiers listed in Section 2
- with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
- Section 4. [RFC 2845]
-
-
-
-6. Security Considerations
-
- For all of the message authentication code algorithms listed herein,
- those producing longer values are believed to be stronger; however,
- while there have been some arguments that mild truncation can
- strengthen a MAC by reducing the information available to an
- attacker, excessive truncation clearly weakens authentication by
- reducing the number of bits an attacker has to try to break the
- authentication by brute force [RFC 2104].
-
- Significant progress has been made recently in cryptanalysis of hash
- function of the type used herein, all of which ultimately derive from
- the design of MD4. While the results so far should not effect HMAC,
- the stronger SHA-1 and SHA-256 algorithms are being made mandatory
- due to caution.
-
- See the Security Considerations section of [RFC 2845]. See also the
- Security Considerations section of [RFC 2104] from which the limits
- on truncation in this RFC were taken.
-
-
-
-7. Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-8. Normative References
-
- [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
- Federal Information Processing Standard, with Change Notice 1,
- February 2004.
-
- [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
- 1321, April 1992.
-
- [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication", RFC 2104, February 1997.
-
- [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
- 1 (SHA1)", RFC 3174, September 2001.
-
- [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
- September 2004,
-
- [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
- (SHA)", draft-eastlake-sha2-*.txt, work in progress.
-
- [STD 13]
- Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
-
-
-9. Informative References.
-
- [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS
- (TKEY RR)", RFC 2930, September 2000.
-
- [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
- Signatures ( SIG(0)s )", RFC 2931, September 2000.
-
- [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
- J., and R. Hall, "Generic Security Service Algorithm for Secret Key
- Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
- 2003.
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554 (w)
-
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Additional IPR Provisions
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed
- to pertain to the implementation or use of the technology
- described in this document or the extent to which any license
- under such rights might or might not be available; nor does it
- represent that it has made any independent effort to identify any
- such rights. Information on the procedures with respect to
- rights in RFC documents can be found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use
- of such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository
- at http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention
- any copyrights, patents or patent applications, or other
- proprietary rights that may cover technology that may be required
- to implement this standard. Please address the information to the
- IETF at ietf-ipr@ietf.org.
-
-
-
-Expiration and File Name
-
- This draft expires in July 2006.
-
- Its file name is draft-ietf-dnsext-tsig-sha-06.txt
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
+++ /dev/null
-
-
-
-Network Working Group M. Andrews
-Internet-Draft ISC
-Intended status: Best Current November 19, 2007
-Practice
-Expires: May 22, 2008
-
-
- Locally-served DNS Zones
- draft-ietf-dnsop-default-local-zones-03
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- 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."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on May 22, 2008.
-
-Copyright Notice
-
- Copyright (C) The IETF Trust (2007).
-
-Abstract
-
- Experience has shown that there are a number of DNS zones all
- iterative resolvers and recursive nameservers should, unless
- configured otherwise, automatically serve. RFC 4193 specifies that
- this should occur for D.F.IP6.ARPA. This document extends the
- practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space
- and other well known zones with similar characteristics.
-
-
-
-
-Andrews Expires May 22, 2008 [Page 1]
-\f
-Internet-Draft Locally-served DNS Zones November 2007
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4
- 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4
- 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5
- 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5
- 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6
- 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6
- 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6
- 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7
- 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
- Appendix A. Change History [To Be Removed on Publication] . . . . 10
- A.1. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 10
- A.2. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 10
- A.3. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 10
- A.4. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11
- A.5. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11
- A.6. draft-andrews-full-service-resolvers-02.txt . . . . . . . 11
- Appendix B. Proposed Status [To Be Removed on Publication] . . . 11
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
- Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews Expires May 22, 2008 [Page 2]
-\f
-Internet-Draft Locally-served DNS Zones November 2007
-
-
-1. Introduction
-
- Experience has shown that there are a number of DNS [RFC 1034] [RFC
- 1035] zones that all iterative resolvers and recursive nameservers
- SHOULD, unless intentionally configured otherwise, automatically
- serve. These zones include, but are not limited to, the IN-ADDR.ARPA
- zones for the address space allocated by [RFC 1918] and the IP6.ARPA
- zones for locally assigned unique local IPv6 addresses, [RFC 4193].
-
- This recommendation is made because data has shown that significant
- leakage of queries for these name spaces is occurring, despite
- instructions to restrict them, and because it has therefore become
- necessary to deploy sacrificial name servers to protect the immediate
- parent name servers for these zones from excessive, unintentional,
- query load [AS112] [I-D.draft-ietf-dnsop-as112-ops]
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. There is every
- expectation that the query load will continue to increase unless
- steps are taken as outlined here.
-
- Additionally, queries from clients behind badly configured firewalls
- that allow outgoing queries for these name spaces but drop the
- responses, put a significant load on the root servers (forward but no
- reverse zones configured). They also cause operational load for the
- root server operators as they have to reply to enquiries about why
- the root servers are "attacking" these clients. Changing the default
- configuration will address all these issues for the zones listed in
- Section 4.
-
- [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled
- locally. This document extends the recommendation to cover the IN-
- ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and
- IP6.ARPA zones for which queries should not appear on the public
- Internet.
-
- It is hoped that by doing this the number of sacrificial servers
- [AS112] will not have to be increased, and may in time be reduced.
-
- This recommendation should also help DNS responsiveness for sites
- which are using [RFC 1918] addresses but do not follow the last
- paragraph in Section 3 of [RFC 1918].
-
-1.1. Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-
-
-
-
-Andrews Expires May 22, 2008 [Page 3]
-\f
-Internet-Draft Locally-served DNS Zones November 2007
-
-
-2. Effects on sites using RFC 1918 addresses.
-
- For most sites using [RFC 1918] addresses, the changes here will have
- little or no detrimental effect. If the site does not already have
- the reverse tree populated the only effect will be that the name
- error responses will be generated locally rather than remotely.
-
- For sites that do have the reverse tree populated, most will either
- have a local copy of the zones or will be forwarding the queries to
- servers which have local copies of the zone. Therefore this
- recommendation will not be relevant.
-
- The most significant impact will be felt at sites that make use of
- delegations for [RFC 1918] addresses and have populated these zones.
- These sites will need to override the default configuration expressed
- in this document to allow resolution to continue. Typically, such
- sites will be fully disconnected from the Internet and have their own
- root servers for their own non-Internet DNS tree.
-
-
-3. Changes to Iterative Resolver Behaviour.
-
- Unless configured otherwise, an iterative resolver will now return
- authoritatively (aa=1) name errors (RCODE=3) for queries within the
- zones in Section 4, with the obvious exception of queries for the
- zone name itself where SOA, NS and "no data" responses will be
- returned as appropriate to the query type. One common way to do this
- is to serve empty (SOA and NS only) zones.
-
- An implementation of this recommendation MUST provide a mechanism to
- disable this new behaviour, and SHOULD allow this decision on a zone
- by zone basis.
-
- If using empty zones one SHOULD NOT use the same NS and SOA records
- as used on the public Internet servers as that will make it harder to
- detect the origin of the responses and thus any leakage to the public
- Internet servers. This document recommends that the NS record
- defaults to the name of the zone and the SOA MNAME defaults to the
- name of the only NS RR's target. The SOA RNAME should default to
- "nobody.invalid." [RFC 2606]. Implementations SHOULD provide a
- mechanism to set these values. No address records need to be
- provided for the name server.
-
- Below is an example of a generic empty zone in master file format.
- It will produce a negative cache TTL of 3 hours.
-
- @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800 @ 10800
- IN NS @
-
-
-
-Andrews Expires May 22, 2008 [Page 4]
-\f
-Internet-Draft Locally-served DNS Zones November 2007
-
-
- The SOA RR is needed to support negative caching [RFC 2308] of name
- error responses and to point clients to the primary master for DNS
- dynamic updates.
-
- SOA values of particular importance are the MNAME, the SOA RR's TTL
- and the negTTL value. Both TTL values SHOULD match. The rest of the
- SOA timer values MAY be chosen arbitrarily since they are not
- intended to control any zone transfer activity.
-
- The NS RR is needed as some UPDATE clients use NS queries to discover
- the zone to be updated. Having no address records for the name
- server is expected to abort UPDATE [RFC 2136] processing in the
- client.
-
-
-4. Lists Of Zones Covered
-
- The following subsections are intended to seed the IANA registry as
- requested in the IANA Considerations Section. The zone name is the
- entity to be registered.
-
-4.1. RFC 1918 Zones
-
- The following zones correspond to the IPv4 address space reserved in
- [RFC 1918].
-
- +----------------------+
- | Zone |
- +----------------------+
- | 10.IN-ADDR.ARPA |
- | 16.172.IN-ADDR.ARPA |
- | 17.172.IN-ADDR.ARPA |
- | 18.172.IN-ADDR.ARPA |
- | 19.172.IN-ADDR.ARPA |
- | 20.172.IN-ADDR.ARPA |
- | 21.172.IN-ADDR.ARPA |
- | 22.172.IN-ADDR.ARPA |
- | 23.172.IN-ADDR.ARPA |
- | 24.172.IN-ADDR.ARPA |
- | 25.172.IN-ADDR.ARPA |
- | 26.172.IN-ADDR.ARPA |
- | 27.172.IN-ADDR.ARPA |
- | 28.172.IN-ADDR.ARPA |
- | 29.172.IN-ADDR.ARPA |
- | 30.172.IN-ADDR.ARPA |
- | 31.172.IN-ADDR.ARPA |
- | 168.192.IN-ADDR.ARPA |
- +----------------------+
-
-
-
-Andrews Expires May 22, 2008 [Page 5]
-\f
-Internet-Draft Locally-served DNS Zones November 2007
-
-
-4.2. RFC 3330 Zones
-
- The following zones correspond to those address ranges from [RFC
- 3330] that are not expected to appear as source or destination
- addresses on the public Internet and to not have a unique name to
- associate with.
-
- The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
- attempt to discourage any practice to provide a PTR RR for
- 1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse
- mapping should exist, but the exact setup is out of the scope of this
- document. Similar logic applies to the reverse mapping for ::1
- Section 4.3. The recommendations made here simply assume no other
- coverage for these domains exists.
-
- +------------------------------+------------------------+
- | Zone | Description |
- +------------------------------+------------------------+
- | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK |
- | 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK |
- | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL |
- | 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET |
- | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST |
- +------------------------------+------------------------+
-
-4.3. Local IPv6 Unicast Addresses
-
- The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for
- the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291],
- Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones:
-
- +-------------------------------------------+
- | Zone |
- +-------------------------------------------+
- | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
- | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
- | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
- | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
- +-------------------------------------------+
-
- Note: Line breaks and a escapes '\' have been inserted above for
- readability and to adhere to line width constraints. They are not
- parts of the zone names.
-
-4.4. IPv6 Locally Assigned Local Addresses
-
- Section 4.4 of [RFC 4193] already required special treatment of:
-
-
-
-
-Andrews Expires May 22, 2008 [Page 6]
-\f
-Internet-Draft Locally-served DNS Zones November 2007
-
-
- +--------------+
- | Zone |
- +--------------+
- | D.F.IP6.ARPA |
- +--------------+
-
-4.5. IPv6 Link Local Addresses
-
- IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered
- by four distinct reverse DNS zones:
-
- +----------------+
- | Zone |
- +----------------+
- | 8.E.F.IP6.ARPA |
- | 9.E.F.IP6.ARPA |
- | A.E.F.IP6.ARPA |
- | B.E.F.IP6.ARPA |
- +----------------+
-
-
-5. Zones that are Out-Of-Scope
-
- IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.57, and IPv6
- Centrally Assigned Local [RFC 4193] addresses are not covered here.
- It is expected that IPv6 site-local addresses will be self correcting
- as IPv6 implementations remove support for site-local addresses.
- However, sacrificial servers for C.E.F.IP6.ARPA through
- F.E.F.IP6.ARPA may still need to be deployed in the short term if the
- traffic becomes excessive.
-
- For IPv6 Centrally Assigned Local addresses (L = 0) [RFC 4193], there
- has been no decision made about whether the Regional Internet
- Registries (RIRs) will provide delegations in this space or not. If
- they don't, then C.F.IP6.ARPA will need to be added to the list in
- Section 4.4. If they do, then registries will need to take steps to
- ensure that name servers are provided for these addresses.
-
- This document also ignores IP6.INT. IP6.INT has been wound up with
- only legacy resolvers now generating reverse queries under IP6.INT
- [RFC 4159].
-
- This document has also deliberately ignored names immediately under
- the root domain. While there is a subset of queries to the root name
- servers which could be addressed using the techniques described here
- (e.g. .local, .workgroup and IPv4 addresses), there is also a vast
- amount of traffic that requires a different strategy (e.g. lookups
- for unqualified hostnames, IPv6 addresses).
-
-
-
-Andrews Expires May 22, 2008 [Page 7]
-\f
-Internet-Draft Locally-served DNS Zones November 2007
-
-
-6. IANA Considerations
-
- This document requests that IANA establish a registry of zones which
- require this default behaviour. The initial contents of which are in
- Section 4. Implementors are encouraged to check this registry and
- adjust their implementations to reflect changes therein.
-
- This registry can be amended through "IETF Consensus" as per [RFC
- 2434].
-
- IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
- deployed in the reverse tree, delegations for these zones are made in
- the manner described in Section 7.
-
-
-7. Security Considerations
-
- During the initial deployment phase, particularly where [RFC 1918]
- addresses are in use, there may be some clients that unexpectedly
- receive a name error rather than a PTR record. This may cause some
- service disruption until their recursive name server(s) have been re-
- configured.
-
- As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
- namespaces, the zones listed above will need to be delegated as
- insecure delegations, or be within insecure zones. This will allow
- DNSSEC validation to succeed for queries in these spaces despite not
- being answered from the delegated servers.
-
- It is recommended that sites actively using these namespaces secure
- them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust
- anchors. This will protect the clients from accidental import of
- unsigned responses from the Internet.
-
-
-8. Acknowledgements
-
- This work was supported by the US National Science Foundation
- (research grant SCI-0427144) and DNS-OARC.
-
-
-9. References
-
-9.1. Normative References
-
- [RFC 1034]
- Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
- RFC 1034, STD 13, November 1987.
-
-
-
-Andrews Expires May 22, 2008 [Page 8]
-\f
-Internet-Draft Locally-served DNS Zones November 2007
-
-
- [RFC 1035]
- Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
- SPECIFICATION", RFC 1035, STD 13, November 1987.
-
- [RFC 1918]
- Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
- and E. Lear, "Address Allocation for Private Internets",
- RFC 1918, February 1996.
-
- [RFC 2119]
- Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2136]
- Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC 2308]
- Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2398, March 1998.
-
- [RFC 2434]
- Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC 2606]
- Eastlake, D. and A. Panitz, "Reserved Top Level DNS
- Names", BCP 32, RFC 2606, June 1999.
-
- [RFC 3596]
- Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
- "DNS Extensions to Support IPv6", RFC 3596, October 2003.
-
- [RFC 4035]
- Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC 4159]
- Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
- August 2005.
-
- [RFC 4193]
- Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
- Addresses", RFC 4193, October 2005.
-
-
-
-
-Andrews Expires May 22, 2008 [Page 9]
-\f
-Internet-Draft Locally-served DNS Zones November 2007
-
-
- [RFC 4291]
- Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 4291, February 2006.
-
-9.2. Informative References
-
- [AS112] "AS112 Project", <http://www.as112.net/>.
-
- [I-D.draft-ietf-dnsop-as112-ops]
- Abley, J. and W. Maton, "AS112 Nameserver Operations",
- draft-ietf-dnsop-as112-ops-00 (work in progress),
- February 2007.
-
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help]
- Abley, J. and W. Maton, "I'm Being Attacked by
- PRISONER.IANA.ORG!",
- draft-ietf-dnsop-as112-under-attack-help-help-00 (work in
- progress), February 2007.
-
- [RFC 3330]
- "Special-Use IPv4 Addresses", RFC 3330, September 2002.
-
-
-Appendix A. Change History [To Be Removed on Publication]
-
-A.1. draft-ietf-dnsop-default-local-zones-03.txt
-
- expanded section 4 descriptions
-
- Added references [RFC 2136], [RFC 3596],
- [I-D.draft-ietf-dnsop-as112-ops] and
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help].
-
- Revised language.
-
-A.2. draft-ietf-dnsop-default-local-zones-02.txt
-
- RNAME now "nobody.invalid."
-
- Revised language.
-
-A.3. draft-ietf-dnsop-default-local-zones-01.txt
-
- Revised impact description.
-
- Updated to reflect change in IP6.INT status.
-
-
-
-
-
-Andrews Expires May 22, 2008 [Page 10]
-\f
-Internet-Draft Locally-served DNS Zones November 2007
-
-
-A.4. draft-ietf-dnsop-default-local-zones-00.txt
-
- Adopted by DNSOP.
-
- "Author's Note" re-titled "Zones that are Out-Of-Scope"
-
- Add note that these zone are expected to seed the IANA registry.
-
- Title changed.
-
-A.5. draft-andrews-full-service-resolvers-03.txt
-
- Added "Proposed Status".
-
-A.6. draft-andrews-full-service-resolvers-02.txt
-
- Added 0.IN-ADDR.ARPA.
-
-
-Appendix B. Proposed Status [To Be Removed on Publication]
-
- This Internet-Draft is being submitted for eventual publication as an
- RFC with a proposed status of Best Current Practice.
-
-
-Author's Address
-
- Mark P. Andrews
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- US
-
- Email: Mark_Andrews@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews Expires May 22, 2008 [Page 11]
-\f
-Internet-Draft Locally-served DNS Zones November 2007
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2007).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-Andrews Expires May 22, 2008 [Page 12]
-\f
projects / thirdparty / bind9.git / commitdiff
