draft-ietf-dnsext-nsec3-02.txt revision 1d24d9f5c9239f60414d1eb78cde8755650b1bed
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinNetwork Working Group B. Laurie
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinInternet-Draft G. Sisson
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinExpires: December 3, 2005 Nominet
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Telematica Instituut
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein DNSSEC Hash Authenticated Denial of Existence
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein draft-ietf-dnsext-nsec3-02
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinStatus of this Memo
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews By submitting this Internet-Draft, each author represents that any
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein applicable patent or other IPR claims of which he or she is aware
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein have been or will be disclosed, and any of which he or she becomes
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein aware will be disclosed, in accordance with Section 6 of BCP 79.
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews Internet-Drafts are working documents of the Internet Engineering
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Task Force (IETF), its areas, and its working groups. Note that
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein other groups may also distribute working documents as Internet-
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Internet-Drafts are draft documents valid for a maximum of six months
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein and may be updated, replaced, or obsoleted by other documents at any
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein time. It is inappropriate to use Internet-Drafts as reference
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein material or to cite them other than as "work in progress."
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The list of current Internet-Drafts can be accessed at
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The list of Internet-Draft Shadow Directories can be accessed at
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein This Internet-Draft will expire on December 3, 2005.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinCopyright Notice
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Copyright (C) The Internet Society (2005).
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein used to provide authenticated denial of existence of DNS ownernames
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews and types; however, it permits any user to traverse a zone and obtain
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews a listing of all ownernames.
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews A complete zone file can be used either directly as a source of
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark AndrewsLaurie, et al. Expires December 3, 2005 [Page 1]
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark AndrewsInternet-Draft nsec3 june 2005
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein probable e-mail addresses for spam, or indirectly as a key for
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein multiple WHOIS queries to reveal registrant data which many
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein registries (particularly in Europe) may be under strict legal
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews obligations to protect. Many registries therefore prohibit copying
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein of their zone file; however the use of NSEC RRs renders policies
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein unenforceable.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein This document proposes a scheme which obscures original ownernames
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews while permitting authenticated denial of existence of non-existent
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein names. Non-authoritative delegation point NS RR types may be
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinTable of Contents
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
c48c7872a0e020a63a96faed166c6ae960e4c1e9Mark Andrews 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 7
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 7
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 7
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 8
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 9
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 3. Creating Additional NSEC3 RRs for Empty Non Terminals . . . . 9
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 10
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 10
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 11
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 6.1 Delegation Points . . . . . . . . . . . . . . . . . . . . 11
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews 6.2 Proving Nonexistence . . . . . . . . . . . . . . . . . . . 12
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 13
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 13
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 6.4.1 Avoiding Hash Collisions during generation . . . . . . 14
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 14
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 14
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 7. Performance Considerations . . . . . . . . . . . . . . . . . . 15
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 10.2 Informative References . . . . . . . . . . . . . . . . . . 17
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 18
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinLaurie, et al. Expires December 3, 2005 [Page 2]
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinInternet-Draft nsec3 june 2005
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 23
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein B.1 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 23
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein B.1.1 Authenticating the Example DNSKEY RRset . . . . . . . 25
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 26
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 28
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein B.3.1 No Data Error, Empty Non-Terminal . . . . . . . . . . 29
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 30
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein B.5 Referral to Unsigned Zone using Opt-In . . . . . . . . . . 31
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 32
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 34
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 35
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Intellectual Property and Copyright Statements . . . . . . . . 37
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinLaurie, et al. Expires December 3, 2005 [Page 3]
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinInternet-Draft nsec3 june 2005
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein1. Introduction
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The DNS Security Extensions (DNSSEC) introduced the NSEC Resource
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Record (RR) for authenticated denial of existence. This document
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein introduces a new RR as an alternative to NSEC that provides measures
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein against zone traversal and allows for gradual expansion of
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein delegation-centric zones.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein1.1 Rationale
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The DNS Security Extensions included the NSEC RR to provide
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein authenticated denial of existence. Though the NSEC RR meets the
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews requirements for authenticated denial of existence, it introduced a
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein side-effect in that the contents of a zone can be enumerated. This
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein property introduces undesired policy issues.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein A second problem was the requirement that the existence of all record
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein types in a zone - including delegation point NS record types - must
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein be accounted for, despite the fact that delegation point NS RRsets
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein are not authoritative and not signed. This requirement has a side-
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein effect that the overhead of delegation-centric signed zones is not
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein related to the increase in security of subzones. This requirement
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein does not allow delegation-centric zones size to grow in relation to
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein the growth of signed subzones.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein In the past, solutions have been proposed as a measure against these
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein side effects but at the time were regarded as secondary over the need
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter)
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein a graceful transition path to future enhancements is introduced,
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein while current DNSSEC deployment can continue. This document presents
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein the NSEC3 Resource Record which mitigates these issues with the NSEC
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The reader is assumed to be familiar with the basic DNS concepts
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein1.2 Reserved Words
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein document are to be interpreted as described in RFC 2119 [RFC2119].
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein1.3 Terminology
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein In this document the term "original ownername" refers to a standard
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein ownername. Because this proposal uses the result of a hash function
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinLaurie, et al. Expires December 3, 2005 [Page 4]
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinInternet-Draft nsec3 june 2005
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein over the original (unmodified) ownername, this result is referred to
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein as "hashed ownername".
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein "Canonical ordering of the zone" means the order in which hashed
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein ownernames are arranged according to their numerical value, treating
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein the leftmost (lowest numbered) byte as the most significant byte.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein2. The NSEC3 Resource Record
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The NSEC3 RR provides Authenticated Denial of Existence for DNS
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Resource Record Sets.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The NSEC3 Resource Record lists RR types present at the NSEC3 RR's
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein original ownername. It includes the next hashed ownername in the
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein canonical ordering of the zone. The complete set of NSEC3 RRs in a
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein zone indicates which RRsets exist for the original ownername of the
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein RRset and form a chain of hashed ownernames in the zone. This
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein information is used to provide authenticated denial of existence for
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews DNS data, as described in RFC 4035 [RFC4035]. Unsigned delegation
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein point NS RRsets can optionally be excluded. To provide protection
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein against zone traversal, the ownernames used in the NSEC3 RR are
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews cryptographic hashes of the original ownername prepended to the name
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein of the zone. The NSEC3 RR indicates which hash function is used to
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein construct the hash, which salt is used, and how many iterations of
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews the hash function are performed over the original ownername.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The ownername for the NSEC3 RR is the base32 encoding of the hashed
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The type value for the NSEC3 RR is XX.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The NSEC3 RR RDATA format is class independent.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein field. This is in the spirit of negative caching [RFC2308].
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein2.1 NSEC3 RDATA Wire Format
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The RDATA of the NSEC3 RR is as shown below:
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinLaurie, et al. Expires December 3, 2005 [Page 5]
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinInternet-Draft nsec3 june 2005
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 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
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein |A|Hash Function| Iterations |
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein | Salt Length | Salt /
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews / Next Hashed Ownername /
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein / Type Bit Maps /
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein2.1.1 The Authoritative Only Flag Field
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Authoritative Only Flag field indicates whether the Type Bit Maps
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein include delegation point NS record types.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein If the flag is set to 1, the NS RR type bit for a delegation point
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein type bit MUST be ignored during processing of the NSEC3 RR. The NS
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein RR type bit has no meaning in this context (it is not authoritative),
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein hence the NSEC3 does not contest the existence of a NS RRset for this
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein ownername. When a delegation is not secured, there exist no DS RR
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein type nor any other authoritative types for this delegation, hence the
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein unsecured delegation has no NSEC3 record associated. Please see the
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews Special Consideration section for implications for unsigned
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein delegations.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein If the flag is set to 0, the NS RR type bit for a delegation point
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein ownername MUST be set if the NSEC3 covers a delegation, even though
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein the NS RR itself is not authoritative. This implies that all
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein delegations, signed or unsigned, have an NSEC3 record associated.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein This behaviour is identical to NSEC behaviour.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein2.1.2 The Hash Function Field
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Hash Function field identifies the cryptographic hash function
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews used to construct the hash-value.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein This document defines Value 1 for SHA-1 and Value 127 for
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein experimental. All other values are reserved.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein On reception, a resolver MUST discard an NSEC3 RR with an unknown
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein hash function value.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinLaurie, et al. Expires December 3, 2005 [Page 6]
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinInternet-Draft nsec3 june 2005
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein2.1.3 The Iterations Field
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Iterations field defines the number of times the hash has been
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein iterated. More iterations results in greater resiliency of the hash
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein value against dictionary attacks, but at a higher cost for both the
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein server and resolver.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein2.1.4 The Salt Length Field
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The salt length field defines the length of the salt in octets.
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews2.1.5 The Salt Field
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Salt field is not present when the Salt Length Field has a value
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Salt field is prepended to the original ownername before hashing
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein in order to defend against precalculated dictionary attacks.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The salt is also prepended during iterations of the hash function.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Note that although it is theoretically possible to cover the entire
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein possible ownername space with different salt values, it is
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews computationally infeasible to do so, and so there MUST be at least
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein one salt which is the same for all NSEC3 records. This means that no
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein matter what name is asked for in a query, it is guaranteed to be
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein possible to find a covering NSEC3 record. Note that this does not
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein preclude the use of two different salts at the same time - indeed
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein this may well occur naturally, due to rolling the salt value
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein periodically.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The salt value SHOULD be changed from time to time - this is to
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein prevent the use of a precomputed dictionary to reduce the cost of
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein enumeration.
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews2.1.6 The Next Hashed Ownername Field
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Next Hashed Ownername field contains the hash of the ownername of
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein the next RR in the canonical ordering of the hashed ownernames of the
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein zone. The value of the Next Hashed Ownername Field in the last NSEC3
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein record in the zone is the same as the ownername of the first NSEC3 RR
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews in the zone in canonical order.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Hashed ownernames of RRsets not authoritative for the given zone
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein (such as glue records) MUST NOT be listed in the Next Hashed
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Ownername unless at least one authoritative RRset exists at the same
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinLaurie, et al. Expires December 3, 2005 [Page 7]
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark AndrewsInternet-Draft nsec3 june 2005
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews Note that the Next Hashed Ownername field is not encoded, unlike the
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews NSEC3 RR's ownername. It is the unmodified binary hash value.
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews2.1.7 The list of Type Bit Map(s) Field
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews The Type Bit Maps field identifies the RRset types which exist at the
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews NSEC3 RR's ownername.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews generation, and MUST be ignored during processing.
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews The RR type space is split into 256 window blocks, each representing
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein the low-order 8 bits of the 16-bit RR type space. Each block that
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein has at least one active RR type is encoded using a single octet
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein window number (from 0 to 255), a single octet bitmap length (from 1
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein to 32) indicating the number of octets used for the window block's
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews bitmap, and up to 32 octets (256 bits) of bitmap.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Blocks are present in the NSEC3 RR RDATA in increasing numerical
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein "|" denotes concatenation
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Each bitmap encodes the low-order 8 bits of RR types within the
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein window block, in network bit order. The first bit is bit 0. For
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein to RR type 2 (NS), and so forth. For window block 1, bit 1
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 1, it indicates that an RRset of that type is present for the NSEC3
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein RR's ownername. If a bit is set to 0, it indicates that no RRset of
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews that type is present for the NSEC3 RR's ownername.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The RR type 2 (NS) is authoritative at the apex of a zone and is not
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein authoritative at delegation points. If the Authoritative Only Flag
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein is set to 1, the delegation point NS RR type MUST NOT be included in
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein the type bit maps. If the Authoritative Only Flag is set to 0, the
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein NS RR type at a delegation point MUST be included in the type bit
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Since bit 0 in window block 0 refers to the non-existing RR type 0,
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein it MUST be set to 0. After verification, the validator MUST ignore
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein the value of bit 0 in window block 0.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein [RFC2929] (section 3.1) or within the range reserved for assignment
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein only to QTYPEs and Meta-TYPEs MUST be set to 0, since they do not
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinLaurie, et al. Expires December 3, 2005 [Page 8]
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinInternet-Draft nsec3 june 2005
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein appear in zone data. If encountered, they must be ignored upon
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Blocks with no types present MUST NOT be included. Trailing zero
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein octets in the bitmap MUST be omitted. The length of each block's
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein bitmap is determined by the type code with the largest numerical
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein value, within that block, among the set of RR types present at the
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein NSEC3 RR's actual ownername. Trailing zero octets not specified MUST
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein be interpreted as zero octets.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein2.2 The NSEC3 RR Presentation Format
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The presentation format of the RDATA portion is as follows:
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Authoritative Only Field is represented as an unsigned decimal
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein integer. The value are either 0 or 1.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Hash field is presented as the name of the hash or as an unsigned
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein decimal integer. The value has a maximum of 127.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Iterations field is presented as an unsigned decimal integer.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Salt Length field is not presented.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Salt field is represented as a sequence of case-insensitive
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein hexadecimal digits. Whitespace is not allowed within the sequence.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Salt Field is represented as 00 when the Salt Length field has
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The Next Hashed Ownername field is represented as a sequence of case-
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein insensitive base32 digits. Whitespace is allowed within the
b05bdb520d83f7ecaad708fe305268c3420be01dMark Andrews The List of Type Bit Map(s) Field is represented as a sequence of RR
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein type mnemonics. When the mnemonic is not known, the TYPE
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein representation as described in RFC 3597 [RFC3597] (section 5) MUST be
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews3. Creating Additional NSEC3 RRs for Empty Non Terminals
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein In order to prove the non-existence of a record that might be covered
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein by a wildcard, it is necessary to prove the existence of its closest
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein encloser. A closest encloser might be an Empty Non Terminal.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Additional NSEC3 RRs are synthesized which cover every existing
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein intermediate label level. Additional NSEC3 RRs are identical in
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein format to NSEC3 RRs that cover existing RRs in the zone. The
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein difference is that the type-bit-maps only indicate the existence of
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinLaurie, et al. Expires December 3, 2005 [Page 9]
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinInternet-Draft nsec3 june 2005
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein an NSEC3 RR type and an RRSIG RR type.
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews4. Calculation of the Hash
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Define H(x) to be the hash of x using the hash function selected by
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein the NSEC3 record and || to indicate concatenation. Then define:
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein IH(salt,x,0)=H(x || salt)
e21a2904f02a03fa06b6db04d348f65fe9c67b2bMark Andrews IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews Then the calculated hash of an ownername is
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein IH(salt,ownername,iterations-1), where the ownername is the canonical
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The canonical form of the ownername is the wire format of the
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein ownername where:
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 1. The ownername is fully expanded (no DNS name compression) and
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein fully qualified;
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 2. All uppercase US-ASCII letters are replaced by the corresponding
b9c96971964d87c2705c8dc29300ff8103479ee6Andreas Gustafsson lowercase US-ASCII letters;
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein 3. If the ownername is a wildcard name, the ownername is in its
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein original unexpanded form, including the "*" label (no wildcard
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein substitution);
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein5. Including NSEC3 RRs in a Zone
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein Each owner name in the zone which has authoritative data or a secured
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein delegation point NS RRset MUST have an NSEC3 resource record.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein An unsecured delegation point NS RRset MAY have an NSEC3 resource
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein record. This is different from NSEC records where an unsecured
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein delegation point NS RRset MUST have an NSEC record.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein value field in the zone SOA RR.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The type bitmap of every NSEC3 resource record in a signed zone MUST
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein indicate the presence of both the NSEC3 RR type itself and its
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein corresponding RRSIG RR type.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein The bitmap for the NSEC3 RR at a delegation point requires special
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein attention. Bits corresponding to the delegation NS RRset and any
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein RRsets for which the parent zone has authoritative data MUST be set;
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein bits corresponding to any non-NS RRset for which the parent is not
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein authoritative MUST be clear.
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews The following steps describe the proper construction of NSEC3
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinLaurie, et al. Expires December 3, 2005 [Page 10]
(the nearest ancestor to omega.alfa.beta.example), then the server
alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
*.beta.example, and an NSEC3 that demonstrates the existence of
beta.example. This takes between one and three NSEC3 records, since
proves that the closest encloser is indeed beta.example. The non-
existence of *.beta.example shows that there is no wildcard at the
omega.alfa.beta.example. These two facts are sufficient to satisfy
server responds with an NSEC3 for beta.example, the resolver will
alfa.beta.example). Once it has done this, it knows the closest
bits (i.e. 2^80 for SHA-1). Though this probability is extremely
value as a given message, i.e. given preimage X, to find a second
claims that a certain QNAME (i.e. the second pre-image) does exist,
The NSEC3 records are still susceptible to dictionary attacks (i.e.
3600 NS ns1.example.
3600 NS ns2.example.
3600 MX 1 xx.example.
S/o/g5C8VM6ftQ== )
5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 (
sb7KfbaUo/vzAg== )
7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 (
MEFQmc/gEuxojA== )
3600 IN NS ns2.a.example.
cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
ns1.a.example. 3600 IN A 192.0.2.5
ns2.a.example. 3600 IN A 192.0.2.6
ai.example. 3600 IN A 192.0.2.9
PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
l5/UqLCJJ9BDMg== )
3600 IN NS ns2.b.example.
ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8
dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 (
gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 (
OwQBGbOegrW/Zw== )
jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 (
kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 (
n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 (
nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 (
ns1.example. 3600 A 192.0.2.1
ns2.example. 3600 A 192.0.2.2
vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 (
wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 (
xx.example. 3600 A 192.0.2.10
rzKKwb8J04/ILw== )
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 (
x.w.example. IN MX
x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
example. 3600 IN NS ns1.example.
example. 3600 IN NS ns2.example.
xx.example. 3600 IN A 192.0.2.10
xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
xx.example. 3600 IN AAAA 2001:db8::f00:baaa
xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
rzKKwb8J04/ILw== )
ns1.example. 3600 IN A 192.0.2.1
ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
ns2.example. 3600 IN A 192.0.2.2
ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
The query returned an MX RRset for "x.w.example". The corresponding
answer was not the result of wildcard expansion. The "x.w.example"
a.c.x.w.example. IN A
7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 (
7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 (
MEFQmc/gEuxojA== )
nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 (
nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 (
In the above example, the name 'x.w.example' hashes to
be the closest encloser. To prove that 'c.x.w.example' and
'*.x.w.example' do not exists, these names are hashed to respectively
ns1.example. IN MX
wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 (
wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 (
exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
y.w.example. IN A
jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 (
jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 (
exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
mc.a.example. IN MX
a.example. 3600 IN DS 58470 5 1 (
a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 (
cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
ns1.a.example. 3600 IN A 192.0.2.5
ns2.a.example. 3600 IN A 192.0.2.6
The query returned a referral to the signed "a.example." zone. The
discussed above. This DS RR is used to authenticate the "a.example"
Once the "a.example" DS RRset has been authenticated using the
"example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
for some "a.example" DNSKEY RR that matches the DS RR. If such a
matching "a.example" DNSKEY is found, the resolver checks whether
this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
all keys in the "a.example" DNSKEY RRset are considered
mc.b.example. IN MX
kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 (
kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 (
ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8
The query returned a referral to the unsigned "b.example." zone. The
a.z.w.example. IN MX
a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
ai.example. 3600 IN A 192.0.2.9
ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
ai.example. 3600 AAAA 2001:db8::f00:baa9
ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
l5/UqLCJJ9BDMg== )
is the result of wildcard expansion, as the "a.z.w.example" name
contains 4 labels. The name "a.z.w.example" is replaced by
"*.w.example", the MX RRset is placed in canonical form, and,
a.z.w.example. IN AAAA
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 (
dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 (
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS