DNS Extensions R. Arends
Internet-Draft Telematica Instituut
-Expires: April 26, 2004 R. Austein
+Expires: June 16, 2004 R. Austein
ISC
M. Larson
VeriSign
USC/ISI
S. Rose
NIST
- October 27, 2003
+ December 17, 2003
DNS Security Introduction and Requirements
- draft-ietf-dnsext-dnssec-intro-07
+ draft-ietf-dnsext-dnssec-intro-08
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on April 26, 2004.
+ This Internet-Draft will expire on June 16, 2004.
Copyright Notice
-Arends, et al. Expires April 26, 2004 [Page 1]
+Arends, et al. Expires June 16, 2004 [Page 1]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
Last, this document describes the interrelationships between the
Normative References . . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
- Intellectual Property and Copyright Statements . . . . . . . . 24
+ Intellectual Property and Copyright Statements . . . . . . . . 25
-Arends, et al. Expires April 26, 2004 [Page 2]
+Arends, et al. Expires June 16, 2004 [Page 2]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
1. Introduction
AD bit" [I-D.ietf-dnsext-ad-is-secure], "Legacy Resolver
Compatibility for Delegation Signer"
[I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation Signer
- Resource Record" [I-D.ietf-dnsext-delegation-signer].
+ Resource Record" [I-D.ietf-dnsext-delegation-signer]. This document
+ set also updates, but does not obsolete, RFCs 1034 [RFC1034], 1035
+ [RFC1035], 2136 [RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597
+ [RFC3597].
The DNS security extensions provide origin authentication and
integrity protection for DNS data, as well as a means of public key
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 3]
+Arends, et al. Expires June 16, 2004 [Page 3]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
2. Definitions of Important DNSSEC Terms
- authentication chain: an alternating succession of DNSKEY RRsets and
- DS RRs forms a chain of signed data, with each link in the chain
+ This section defines a number of terms used in this document set.
+ Since this is intended to be useful as a reference while reading the
+ rest of the document set, first-time readers may wish to skim this
+ section quickly, read the rest of this document, then come back to
+ this section.
+
+ authentication chain: an alternating sequence of DNSKEY RRsets and DS
+ RRs forms a chain of signed data, with each link in the chain
vouching for the next. A DNSKEY RR is used to check the signature
covering a DS RR and allows the DS RR to be authenticated. The DS
RR contains a hash of another DNSKEY RR and this new DNSKEY RR is
signs the desired DNS data. For example, the root DNSKEY can be
used to authenticated the DS RR for "example." The "example." DS
RR contains a hash that matches some "example." DNSKEY and this
- DNSKEY signs the "example." DNSKEY RRset. Keys in the "example."
- DNSKEY RRset sign data records such as "www.example." as well as
- DS RRs for delegations such as "subzone.example."
+ DNSKEY signs the "example." DNSKEY RRset. Private key
+ counterparts in the "example." DNSKEY RRset sign data records such
+ as "www.example." as well as DS RRs for delegations such as
+ "subzone.example."
authentication key: A public key which a security-aware resolver has
verified and can therefore use to authenticate data. A
authenticate any new key for which the resolver is able verify the
signature.
+ delegation point: Term used to describe the name at the parental side
+ of a zone cut. That is, the delegation point for "foo.example"
+ would be the foo.example node in the "example" zone (as opposed to
+ the zone apex of the "foo.example" zone).
+
island of security: Term used to describe a signed, delegated zone
that does not have an authentication chain from its delegating
- parent. That is, there is no DS RR with the island's key in its
- delegating parent zone (see [I-D.ietf-dnsext-dnssec-records]). An
- island of security is served by a security-aware nameserver and
- may provide authentication chains to any delegated child zones.
- Responses from an island of security or its descendents can only
- be validated if its zone key can be obtained by some trusted means
- out of band from the DNS protocol.
-
- key signing key: An authentication key which is used to sign one or
- more other authentication keys. Typically, a key signing key will
- sign a zone signing key, which in turn will sign other zone data.
- Local policy may require the zone signing key to be changed
- frequently, while the key signing key may have a longer validity
+ parent. That is, there is no DS RR with the island's public key
-Arends, et al. Expires April 26, 2004 [Page 4]
+Arends, et al. Expires June 16, 2004 [Page 4]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
+
+ in its delegating parent zone (see
+ [I-D.ietf-dnsext-dnssec-records]). An island of security is served
+ by a security-aware nameserver and may provide authentication
+ chains to any delegated child zones. Responses from an island of
+ security or its descendents can only be validated if its zone key
+ can be obtained by some trusted means out of band from the DNS
+ protocol.
+ key signing key: An authentication key which is used to sign one or
+ more other authentication keys. Typically, a key signing key will
+ sign a zone signing key, which in turn will sign other zone data.
+ Local policy may require the zone signing key to be changed
+ frequently, while the key signing key may have a longer validity
period in order to provide a more stable secure entry point into
the zone. Designating an authentication key as a key signing key
is purely an operational issue: DNSSEC validation does not
distinguish between key signing keys and other DNSSEC
authentication keys. Key signing keys are discussed in more
- detail in [I-D.ietf-dnsext-keyrr-key-signing-flag].
+ detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. See also: zone
+ signing key.
security-aware name server: An entity acting in the role of a name
server (defined in section 2.4 of [RFC1034]) which understands the
resolver (defined in section 2.4 of [RFC1034]) which has at least
a minimal understanding the DNS security extensions defined in
this document set, but which trusts one or more security-aware
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 5]
+\f
+Internet-Draft DNSSEC Introduction and Requirements December 2003
+
+
recursive name servers to perform most of the tasks discussed in
this document set on its behalf. In particular, a security-aware
stub resolver is an entity which sends DNS queries, receives DNS
own DNSSEC signature validity checks, while a security-aware stub
resolver does not, by definition.
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 5]
-\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
-
-
security-oblivious (server or resolver): The opposite of
"security-aware".
part of the same DNSKEY RRset as the key signing key which signs
it, but is used for a slightly different purpose and may differ
from the key signing key in other ways, such as validity lifetime.
+ See also: key signing key.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 6]
+Arends, et al. Expires June 16, 2004 [Page 6]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
3. Services Provided by DNS Security
-Arends, et al. Expires April 26, 2004 [Page 7]
+Arends, et al. Expires June 16, 2004 [Page 7]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
resolver or must have been learned and verified previously.
-Arends, et al. Expires April 26, 2004 [Page 8]
+Arends, et al. Expires June 16, 2004 [Page 8]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
the gaps, or "empty space", between domain names in a zone, as well
-Arends, et al. Expires April 26, 2004 [Page 9]
+Arends, et al. Expires June 16, 2004 [Page 9]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
4. Services Not Provided by DNS Security
-Arends, et al. Expires April 26, 2004 [Page 10]
+Arends, et al. Expires June 16, 2004 [Page 10]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
5. Resolver Considerations
security-aware resolver's own clock is wrong. Thus, a security-aware
resolver which is part of a security-aware recursive name server will
need to pay careful attention to the DNSSEC "checking disabled" (CD)
- bit [I-D.ietf-dnsext-dnssec-records] in order to avoid blocking valid
- signatures from getting through to other security-aware resolvers
- which are clients of this recursive name server and which are capable
- of performing their own DNSSEC validity checks. See
- [I-D.ietf-dnsext-dnssec-protocol] for how a secure recursive server
- handles queries with the CD bit set.
+ bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid
+ blocking valid signatures from getting through to other
+ security-aware resolvers which are clients of this recursive name
+ server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure
+ recursive server handles queries with the CD bit set.
+
-Arends, et al. Expires April 26, 2004 [Page 11]
+Arends, et al. Expires June 16, 2004 [Page 11]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
6. Stub Resolver Considerations
stub resolver to place any real reliance on DNSSEC services, the stub
resolver must trust both the recursive name servers in question and
the communication channels between itself and those name servers.
- The first of these issues is a local policy issue: in essence, a stub
- resolver has no real choice but to place itself at the mercy of the
- recursive name servers that it uses, since it does not perform DNSSEC
- validity checks on its own. The second issue requires some kind of
- channel security mechanism; proper use of DNS transaction
- authentication mechanisms such as SIG(0) or TSIG would suffice, as
- would appropriate use of IPsec, and particular implementations may
- have other choices available, such as operating system specific
- interprocess communication mechanisms. Confidentiality is not needed
- for this channel, but data integrity and message authentication are.
+ The first of these issues is a local policy issue: in essence, a
+ security-oblivious stub resolver has no real choice but to place
+ itself at the mercy of the recursive name servers that it uses, since
+ it does not perform DNSSEC validity checks on its own. The second
+ issue requires some kind of channel security mechanism; proper use of
+ DNS transaction authentication mechanisms such as SIG(0) or TSIG
+ would suffice, as would appropriate use of IPsec, and particular
+ implementations may have other choices available, such as operating
+ system specific interprocess communication mechanisms.
+ Confidentiality is not needed for this channel, but data integrity
+ and message authentication are.
A security-aware stub resolver which does trust both its recursive
name servers and its communication channel to them may choose to
-
-Arends, et al. Expires April 26, 2004 [Page 12]
+Arends, et al. Expires June 16, 2004 [Page 12]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
7. Zone Considerations
-Arends, et al. Expires April 26, 2004 [Page 13]
+Arends, et al. Expires June 16, 2004 [Page 13]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
8. Name Server Considerations
updated, so the private half of the zone signing key will have to be
kept online. This is an example of a situation where the ability to
separate the zone's DNSKEY RRset into zone signing key(s) and key
- signing key(s) may be useful, since the key singing key(s) in such a
+ signing key(s) may be useful, since the key signing key(s) in such a
case can still be kept offline.
DNSSEC, by itself, is not enough to protect the integrity of an
-Arends, et al. Expires April 26, 2004 [Page 14]
+Arends, et al. Expires June 16, 2004 [Page 14]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
9. DNS Security Document Family
-Arends, et al. Expires April 26, 2004 [Page 15]
+Arends, et al. Expires June 16, 2004 [Page 15]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
record format. Each of these documents deals with a specific digital
-Arends, et al. Expires April 26, 2004 [Page 16]
+Arends, et al. Expires June 16, 2004 [Page 16]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
10. IANA Considerations
-Arends, et al. Expires April 26, 2004 [Page 17]
+Arends, et al. Expires June 16, 2004 [Page 17]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
11. Security Considerations
-Arends, et al. Expires April 26, 2004 [Page 18]
+Arends, et al. Expires June 16, 2004 [Page 18]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
dynamic update, by sending a stream of update messages that force the
NSEC queries from a single host, use of intrusion detection tools,
etc.
+ DNSSEC introduces significant additional complexity to the DNS, and
+ thus introduces many new opportunities for implementation bugs and
+ misconfigured zones.
+
DNSSEC does not provide confidentiality, due to a deliberate design
choice.
zones, and other mechanisms must be used to protect zone transfer
operations.
+ Please see [I-D.ietf-dnsext-dnssec-records] and
+ [I-D.ietf-dnsext-dnssec-protocol] for additional security
+ considerations.
-
-
-
-
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 19]
+Arends, et al. Expires June 16, 2004 [Page 19]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
12. Acknowledgements
- This document was created from the input and ideas of several members
- of the DNS Extensions Working Group. The editors would like to
- acknowledge (in alphabetical order) the following people for their
- contributions and comments on this document: Derek Atkins, Donald
- Eastlake, Miek Gieben, Olafur Gudmundsson, Olaf Kolkman, Ed Lewis,
- Ted Lindgreen, Bill Manning, and Brian Wellington.
-
-
-
-
-
-
-
-
+ This document was created from the input and ideas of the members of
+ the DNS Extensions Working Group. While explicitly listing everyone
+ who has contributed during the decade during which DNSSEC has been
+ under development would be an impossible task, the editors would
+ particularly like to thank the following people for their
+ contributions to and comments on this document set: Mark Andrews,
+ Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney,
+ Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael
+ Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip
+ Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf
+ Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted
+ Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson,
+ Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik
+ Rozendaal, Jakob Schlyter, Mike StJohns, Sam Weiler, and Brian
+ Wellington.
+ No doubt the above is an incomplete list. We apologize to anyone we
+ left out.
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 20]
+Arends, et al. Expires June 16, 2004 [Page 20]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
Normative References
-Arends, et al. Expires April 26, 2004 [Page 21]
+Arends, et al. Expires June 16, 2004 [Page 21]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
Informative References
+ [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.
+
[RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
[I-D.ietf-dnsext-dns-threats]
Atkins, D. and R. Austein, "Threat Analysis Of The Domain
Name System", draft-ietf-dnsext-dns-threats-04 (work in
draft-ietf-dnsext-delegation-signer-15 (work in progress),
June 2003.
+
+
+Arends, et al. Expires June 16, 2004 [Page 22]
+\f
+Internet-Draft DNSSEC Introduction and Requirements December 2003
+
+
[I-D.ietf-dnsext-dnssec-2535typecode-change]
Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05
progress), October 2003.
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 22]
-\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
-
-
Authors' Addresses
Roy Arends
EMail: masseyd@isi.edu
+
+Arends, et al. Expires June 16, 2004 [Page 23]
+\f
+Internet-Draft DNSSEC Introduction and Requirements December 2003
+
+
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
-Arends, et al. Expires April 26, 2004 [Page 23]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 24]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
Intellectual Property Statement
-Arends, et al. Expires April 26, 2004 [Page 24]
+Arends, et al. Expires June 16, 2004 [Page 25]
\f
-Internet-Draft DNSSEC Introduction and Requirements October 2003
+Internet-Draft DNSSEC Introduction and Requirements December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-Arends, et al. Expires April 26, 2004 [Page 25]
+Arends, et al. Expires June 16, 2004 [Page 26]
\f
+
DNS Extensions R. Arends
Internet-Draft Telematica Instituut
-Expires: April 26, 2004 M. Larson
+Expires: June 16, 2004 M. Larson
VeriSign
R. Austein
ISC
USC/ISI
S. Rose
NIST
- October 27, 2003
+ December 17, 2003
Protocol Modifications for the DNS Security Extensions
- draft-ietf-dnsext-dnssec-protocol-03
+ draft-ietf-dnsext-dnssec-protocol-04
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on April 26, 2004.
+ This Internet-Draft will expire on June 16, 2004.
Copyright Notice
-Arends, et al. Expires April 26, 2004 [Page 1]
+Arends, et al. Expires June 16, 2004 [Page 1]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
defines the concept of a signed zone, along with the requirements for
2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6
2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6
- 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 8
+ 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7
2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8
2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8
- 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8
- 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 9
- 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 10
- 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 10
- 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 11
- 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 13
- 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 14
- 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 15
- 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 16
- 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 18
- 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 4.1 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 21
- 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 21
- 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 23
- 5.1 Special Considerations for Islands of Security . . . . . . . 24
- 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 24
- 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 25
- 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 26
- 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 27
- 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 28
- 5.3.4 Authenticating A Wildcard Expanded RRset Positive
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 2]
+ 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9
+ 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10
+ 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11
+ 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 11
+ 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12
+ 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 14
+ 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 16
+ 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17
+ 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 17
+ 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19
+ 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 4.2 Signature Verification Support . . . . . . . . . . . . . . . 20
+ 4.3 Determining Security Status of Data . . . . . . . . . . . . 21
+ 4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 21
+ 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . . 21
+ 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . . 22
+ 4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 22
+ 4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 23
+ 4.8.1 ENDS Support . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 4.8.2 Handling of the CD and AD Bits . . . . . . . . . . . . . . . 23
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 2]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
-
-
- Response . . . . . . . . . . . . . . . . . . . . . . . . . . 29
- 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 29
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
- 7. Security Considerations . . . . . . . . . . . . . . . . . . 32
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
- Normative References . . . . . . . . . . . . . . . . . . . . 34
- Informative References . . . . . . . . . . . . . . . . . . . 35
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35
- A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 37
- B. Example Responses . . . . . . . . . . . . . . . . . . . . . 43
- B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
- B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 44
- B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 45
- B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 46
- B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 47
- B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 47
- B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 48
- B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 49
- C. Authentication Examples . . . . . . . . . . . . . . . . . . 51
- C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 51
- C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 51
- C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 52
- C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 52
- C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 52
- C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 52
- C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 53
- C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 53
- C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 53
- Intellectual Property and Copyright Statements . . . . . . . 54
-
-
-
-
-
-
-
+Internet-Draft DNSSEC Protocol Modifications December 2003
+ 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 25
+ 5.1 Special Considerations for Islands of Security . . . . . . . 26
+ 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 26
+ 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 27
+ 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 28
+ 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 29
+ 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30
+ 5.3.4 Authenticating A Wildcard Expanded RRset Positive
+ Response . . . . . . . . . . . . . . . . . . . . . . . . . . 31
+ 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 31
+ 5.5 Authentication Example . . . . . . . . . . . . . . . . . . . 32
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . 34
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
+ Normative References . . . . . . . . . . . . . . . . . . . . 36
+ Informative References . . . . . . . . . . . . . . . . . . . 37
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
+ A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 39
+ B. Example Responses . . . . . . . . . . . . . . . . . . . . . 45
+ B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
+ B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 46
+ B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 47
+ B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 48
+ B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 49
+ B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 49
+ B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 50
+ B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 51
+ C. Authentication Examples . . . . . . . . . . . . . . . . . . 53
+ C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 53
+ C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 53
+ C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 54
+ C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 54
+ C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 54
+ C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 54
+ C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 55
+ C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 55
+ C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 55
+ Intellectual Property and Copyright Statements . . . . . . . 56
-Arends, et al. Expires April 26, 2004 [Page 3]
+Arends, et al. Expires June 16, 2004 [Page 3]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
1. Introduction
-Arends, et al. Expires April 26, 2004 [Page 4]
+Arends, et al. Expires June 16, 2004 [Page 4]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
1.3.3 Typos and Minor Corrections
-Arends, et al. Expires April 26, 2004 [Page 5]
+Arends, et al. Expires June 16, 2004 [Page 5]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
2. Zone Signing
record. Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs
to appear at the same owner name as a CNAME RR.
- Section 2.6 shows a sample signed zone.
-
2.1 Including DNSKEY RRs in a Zone
To sign a zone, the zone's administrator generates one or more
o The RRSIG Type Covered field is equal to the RRset type;
+ o The RRSIG Original TTL field is equal to the TTL of the RRset;
-Arends, et al. Expires April 26, 2004 [Page 6]
-\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Arends, et al. Expires June 16, 2004 [Page 6]
+\f
+Internet-Draft DNSSEC Protocol Modifications December 2003
- o The RRSIG Original TTL field is equal to the TTL of the RRset;
o The RRSIG RR's TTL is equal to the TTL of the RRset;
which has an NSEC RRset will have RRSIG RRs as well in the signed
zone.
+2.3 Including NSEC RRs in a Zone
+
-Arends, et al. Expires April 26, 2004 [Page 7]
+Arends, et al. Expires June 16, 2004 [Page 7]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
-
+Internet-Draft DNSSEC Protocol Modifications December 2003
-2.3 Including NSEC RRs in a Zone
- Each owner name in the zone MUST have an NSEC resource record, except
- for the owner names of any glue address RRsets. The process for
- constructing the NSEC RR for a given name is described in
+ Each owner name in the zone which has authoritative data or a
+ delegation point NS RRset MUST have an NSEC resource record. The
+ process for constructing the NSEC RR for a given name is described in
[I-D.ietf-dnsext-dnssec-records].
+ An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
+ RRsets at any particular owner name. That is, the signing process
+ MUST NOT create (or RRSIG) RRs for owner names nodes which were not
+ the owner name of any RRset before the zone was signed.
+
The type bitmap of every NSEC resource record in a signed zone MUST
indicate the presence of both the NSEC record itself and its
corresponding RRSIG record.
The DS resource record establishes authentication chains between DNS
zones. A DS RRset SHOULD be present at a delegation point when the
child zone is signed. The DS RRset MAY contain multiple records,
- each referencing a key used by the child zone to sign its apex DNSKEY
- RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT
- appear at non-delegation points nor at a zone's apex.
+ each referencing a public key in the child zone used to verify the
+ RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS
+ RRsets MUST NOT appear at non-delegation points nor at a zone's apex.
A DS RR SHOULD point to a DNSKEY RR which is present in the child's
apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
this conflict, this specification modifies the definition of the
CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 8]
+\f
+Internet-Draft DNSSEC Protocol Modifications December 2003
+
+
2.6 Example of a Secure Zone
Appendix A shows a complete example of a small signed zone.
-Arends, et al. Expires April 26, 2004 [Page 8]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 9]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
3. Serving
the CD bit from a query into the corresponding response. The AD bit
is controlled by name servers; a security-aware name server MUST
ignore the setting of the AD bit in queries. See Section 3.1.6,
- Section 3.2.2, Section 3.2.3, Section 4, and Section 4.2 for details
+ Section 3.2.2, Section 3.2.3, Section 4, and Section 4.8 for details
on the behavior of these bits.
3.1 Authoritative Name Servers
-Arends, et al. Expires April 26, 2004 [Page 9]
+Arends, et al. Expires June 16, 2004 [Page 10]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
-Arends, et al. Expires April 26, 2004 [Page 10]
+Arends, et al. Expires June 16, 2004 [Page 11]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
3.1.3 Including NSEC RRs In a Response
-Arends, et al. Expires April 26, 2004 [Page 11]
+Arends, et al. Expires June 16, 2004 [Page 12]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
o An NSEC RR proving that there is no exact match for <SNAME,
If space does not permit inclusion of these NSEC and RRSIG RRs, the
name server MUST set the TC bit (see Section 3.1.1).
+ The owner names of these NSEC and RRSIG RRs are not subject to
+ wildcard name expansion when these RRs are included in the Authority
+ section of the response.
+
+ Note that this form of response includes cases in which SNAME
+ corresponds to an empty non-terminal name within the zone (a name
+ which is not the owner name for any RRset but which is the parent
+ name of one or more RRsets).
+
3.1.3.3 Including NSEC RRs: Wildcard Answer Response
If the zone does not contain any RRsets which exactly match <SNAME,
expansion; and
o An NSEC RR proving that there are no RRsets in the zone which
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 13]
+\f
+Internet-Draft DNSSEC Protocol Modifications December 2003
+
+
would have been a closer match for <SNAME, SCLASS>.
In some cases a single NSEC RR may prove both of these points, in
which case the name server SHOULD only include the NSEC RR and its
RRSIG RR(s) once in the Authority section.
+ The owner names of these NSEC and RRSIG RRs are not subject to
+ wildcard name expansion when these RRs are included in the Authority
+ section of the response.
+
If space does not permit inclusion of these NSEC and RRSIG RRs, the
name server MUST set the TC bit (see Section 3.1.1).
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 12]
-\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
-
-
3.1.3.5 Finding The Right NSEC RRs
As explained above, there are several situations in which a
security-aware authoritative name server returning a referral
includes DNSSEC data along with the NS RRset.
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 14]
+\f
+Internet-Draft DNSSEC Protocol Modifications December 2003
+
+
If a DS RRset is present at the delegation point, the name server
MUST return both the DS RRset and its associated RRSIG RR(s) along
with the NS RRset. The name server MUST place the NS RRset before
Including these DS, NSEC, and RRSIG RRs increases the size of
referral messages, and may cause some or all glue RRs to be omitted.
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 13]
-\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
-
-
If space does not permit inclusion of the DS or NSEC RRset and
associated RRSIG RRs, the name server MUST set the TC bit (see
Section 3.1.1).
In all other cases, the name server either has some way of obtaining
the DS RRset or could not have been expected to have the DS RRset
even by the pre-DNSSEC processing rules, so the name server can
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 15]
+\f
+Internet-Draft DNSSEC Protocol Modifications December 2003
+
+
return either the DS RRset or an error response according to the
normal processing rules.
DNSSEC does not change the DNS zone transfer process. A signed zone
will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 14]
-\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
-
-
records have no special meaning with respect to a zone transfer
operation, and these RRs are treated as any other resource record
type.
RRSIG RRs appear in both the parent and child zones at a zone cut,
and are authoritative in whichever zone contains the authoritative
RRset for which the RRSIG RR provides the signature. That is, the
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 16]
+\f
+Internet-Draft DNSSEC Protocol Modifications December 2003
+
+
RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
authoritative in the parent zone, while the RRSIG for any RRset in
the child zone's apex will be authoritative in the child zone. As
This bits are for the most part not relevant to query processing by
security-aware authoritative name servers.
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 15]
-\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
-
-
Since a security-aware name server does not perform signature
validation for authoritative data during query processing even when
the CD bit is set to zero, a security-aware name server SHOULD ignore
implements the security-aware name server role and the code which
implements the security-aware resolver role, respectively.
- A security-aware recursive name server MUST NOT attempt to answer a
- query by piecing together cached data it received in response to
- previous queries that requested different QNAMEs, QTYPEs, or
- QCLASSes. A security-aware recursive name server MUST NOT use NSEC
- RRs from one negative response to synthesize a response for a
- different query. A security-aware recursive name server MUST NOT use
- a previous wildcard expansion to generate a response to a different
- query.
-
The resolver side MUST follow the usual rules for caching and
negative caching which would apply to any security-aware resolver.
The resolver side of a security-aware recursive name server MUST set
the DO bit when sending requests, regardless of the state of the DO
- bit in the initiating request received by the name server side. If
- the DO bit in an initiating query is not set, the name server side
- MUST strip any authenticating DNSSEC RRs from the response, but but
- MUST NOT strip any DNSSEC RRs that the initiating query explicitly
-Arends, et al. Expires April 26, 2004 [Page 16]
+Arends, et al. Expires June 16, 2004 [Page 17]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
+ bit in the initiating request received by the name server side. If
+ the DO bit in an initiating query is not set, the name server side
+ MUST strip any authenticating DNSSEC RRs from the response, but but
+ MUST NOT strip any DNSSEC RRs that the initiating query explicitly
requested.
3.2.2 The CD bit
responsibility for performing its own authentication, and the
recursive name server should not interfere.
- If the resolver side implements a BAD cache (see Section 4.1) and the
- name server side receives a query which matches an entry in the
- resolver side's BAD cache, the name server side's response depends on
- the sense of the CD bit in the original query. If the CD bit is set,
-Arends, et al. Expires April 26, 2004 [Page 17]
+Arends, et al. Expires June 16, 2004 [Page 18]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
+ If the resolver side implements a BAD cache (see Section 4.7) and the
+ name server side receives a query which matches an entry in the
+ resolver side's BAD cache, the name server side's response depends on
+ the sense of the CD bit in the original query. If the CD bit is set,
the name server side SHOULD return the data from the BAD cache; if
the CD bit is not set, the name server side MUST return RCODE 2
(server failure).
-
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 18]
+Arends, et al. Expires June 16, 2004 [Page 19]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
4. Resolving
specific to security-aware recursive name servers are described in
Section 3.2.
+4.1 EDNS Support
+
A security-aware resolver MUST include an EDNS [RFC2671] OPT
pseudo-RR with the DO [RFC3225] bit set to one when sending queries.
such fragmented packets were received via IPv4 or IPv6. Please see
[RFC3226] for discussion of these requirements.
+4.2 Signature Verification Support
+
A security-aware resolver MUST support the signature verification
mechanisms described in Section 5, and MUST apply them to every
received response except when:
A security-aware resolver MUST attempt to retrieve a missing NSEC RR
which the resolver needs to authenticate a NODATA response. In
general it is not possible for a resolver to retrieve missing NSEC
- RRs, since the resolver will have no way of knowing the owner name of
- the missing NSEC RR, but in the specific case of a NODATA response,
- the resolver does know the name of the missing NSEC RR, and must
- therefore attempt to retrieve it.
-Arends, et al. Expires April 26, 2004 [Page 19]
+Arends, et al. Expires June 16, 2004 [Page 20]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
+ RRs, since the resolver will have no way of knowing the owner name of
+ the missing NSEC RR, but in the specific case of a NODATA response,
+ the resolver does know the name of the missing NSEC RR, and must
+ therefore attempt to retrieve it.
+
When attempting to retrieve missing NSEC or DS RRs which reside on
the parental side at a zone cut, a security-aware iterative-mode
resolver MUST query the name servers for the parent zone, not the
child zone.
+4.3 Determining Security Status of Data
+
A security-aware resolver MUST be able to determine whether or not it
should expect a particular RRset to be signed. More precisely, a
security-aware resolver must be able to distinguish between three
cases:
1. An RRset for which the resolver is able to build a chain of
- signed DNSKEY and DS RRs from a trusted starting point to the
+ signed DNSKEY and DS RRs from a trusted security anchor to the
RRset. In this case, the RRset should be signed, and is subject
to signature validation as described above.
security-aware resolver is not able to contact security-aware
name servers for the relevant zones.
+
+4.4 Preconfigured Public Keys
+
A security-aware resolver MUST be capable of being preconfigured with
- at least one trusted public key, and MUST be capable of being
+ at least one trusted public key, and SHOULD be capable of being
preconfigured with multiple trusted public keys or DS RRs. Since a
security-aware resolver will not be able to validate signatures
without such a preconfigured trusted key, the resolver SHOULD have
some reasonably robust mechanism for obtaining such keys when it
boots.
+4.5 Response Caching
+
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 21]
+\f
+Internet-Draft DNSSEC Protocol Modifications December 2003
+
+
A security-aware resolver SHOULD cache each response as a single
atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the
single atomic entry containing the entire answer, including the named
RRset and any associated DNSSEC RRs. The resolver SHOULD discard the
entire atomic entry when any of the RRs contained in it expire.
+4.6 Handling of the CD and AD bits
+
A security-aware resolver MAY set the CD bit in a query to one in
order to indicate that the resolver takes responsibility for
performing whatever authentication its local policy requires on the
RRsets in the response. See Section 3.2 for the effect this bit has
on the behavior of security-aware recursive name servers.
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 20]
-\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
-
-
A security-aware resolver MUST zero the AD bit when composing query
messages.
-4.1 Rate Limiting
+4.7 Rate Limiting
A security-aware resolver SHOULD NOT cache data with invalid
signatures under normal circumstances. However, a security-aware
The intent of the above rule is to provide the raw data to clients
which are capable of performing their own signature verification
checks while protecting clients which depend on this resolver to
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 22]
+\f
+Internet-Draft DNSSEC Protocol Modifications December 2003
+
+
perform such checks. Several of the possible reasons why signature
validation might fail involve conditions which may not apply equally
to this resolver and the client which invoked it: for example, this
performing its own signature validation from ever seeing the "bad"
data does not help the client.
-4.2 Stub resolvers
+4.8 Stub resolvers
+
+4.8.1 ENDS Support
A security-aware stub resolver MUST include an EDNS [RFC2671] OPT
pseudo-RR with the DO [RFC3225] bit set to one when sending queries.
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 21]
-\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
-
-
A security-aware stub resolver MUST support a message size of at
least 1220 octets, SHOULD support a message size of 4000 octets, and
MUST advertise the supported message size using the "sender's UDP
of the data that it the stub resolver hands back to the application
which invoked it but is not required to do so.
+4.8.2 Handling of the CD and AD Bits
+
A security-aware stub resolver SHOULD NOT set the CD bit when sending
- queries, since, by definition, a security-aware stub resolver does
- not validate signatures and thus depends on the security-aware
- recursive name server to perform validation on its behalf.
+ queries unless requested by the application layer, since by
+ definition, a security-aware stub resolver does not validate
+ signatures and thus depends on the security-aware recursive name
+ server to perform validation on its behalf.
A security-aware stub resolver MAY chose to examine the setting of
the AD bit in response messages that it receives in order to
resolver are heavily dependent on the local policy of the
security-aware recursive name server, so as a practical matter there
may be little practical value to checking the status of the AD bit
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 23]
+\f
+Internet-Draft DNSSEC Protocol Modifications December 2003
+
+
except perhaps as a debugging aid. In any case, a security-aware
stub resolver MUST NOT place any reliance on signature validation
allegedly performed on its behalf except when the security-aware stub
-Arends, et al. Expires April 26, 2004 [Page 22]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 24]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
5. Authenticating DNS Responses
-Arends, et al. Expires April 26, 2004 [Page 23]
+Arends, et al. Expires June 16, 2004 [Page 25]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
interfere with DNSSEC RRs or due to a deliberate attack in which an
-Arends, et al. Expires April 26, 2004 [Page 24]
+Arends, et al. Expires June 16, 2004 [Page 26]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
RRset which, when hashed using the digest algorithm specified in
-Arends, et al. Expires April 26, 2004 [Page 25]
+Arends, et al. Expires June 16, 2004 [Page 27]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
5.3.1 Checking the RRSIG RR Validity
above. In this case, the resolver can not predetermine which DNSKEY
RR to use to authenticate the signature, MUST try each matching
DNSKEY RR until the resolver has either validated the signature or
- has run out of matching keys to try.
+ has run out of matching public keys to try.
Note that this authentication process is only meaningful if the
resolver authenticates the DNSKEY RR before using it to validate
-Arends, et al. Expires April 26, 2004 [Page 26]
+Arends, et al. Expires June 16, 2004 [Page 28]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
5.3.2 Reconstructing the Signed Data
-Arends, et al. Expires April 26, 2004 [Page 27]
+Arends, et al. Expires June 16, 2004 [Page 29]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
if rrsig_labels > fqdn
authenticate the RRset.
The Algorithm field in the RRSIG RR identifies the cryptographic
- algorithm to generate the signature. The signature itself is
+ algorithm used to generate the signature. The signature itself is
contained in the Signature field of the RRSIG RDATA, and the public
- key to used generate the signature is contained in the Public Key
- field of the matching DNSKEY RR(s) (found in Section 5.3.1).
+ key used to verify the signature is contained in the Public Key field
+ of the matching DNSKEY RR(s) (found in Section 5.3.1).
[I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types,
and provides pointers to the documents that define each algorithm's
use.
-Arends, et al. Expires April 26, 2004 [Page 28]
+Arends, et al. Expires June 16, 2004 [Page 30]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
- determine which DNSKEY RR by trying each matching key until the
- resolver either succeeds in validating the signature or runs out of
- keys to try.
+ determine which DNSKEY RR by trying each matching public key until
+ the resolver either succeeds in validating the signature or runs out
+ of keys to try.
If the Labels field of the RRSIG RR is not equal to the number of
labels in the RRset's fully qualified owner name, then the RRset is
considering the RRset to be authentic. Section 5.3.4 describes how
to determine whether a wildcard was applied properly.
- If other RRSIG RRs also cover this RRSIG RR, the local resolver
- security policy determines whether the resolver also needs to test
- these RRSIG RRs, and determines how to resolve conflicts if these
- RRSIG RRs lead to differing results.
+ If other RRSIG RRs also cover this RRset, the local resolver security
+ policy determines whether the resolver also needs to test these RRSIG
+ RRs, and determines how to resolve conflicts if these RRSIG RRs lead
+ to differing results.
If the resolver accepts the RRset as authentic, the resolver MUST set
the TTL of the RRSIG RR and each RR in the authenticated RRset to a
5.3.4 Authenticating A Wildcard Expanded RRset Positive Response
- If the number of labels in an RRset's fully qualified domain name is
- greater than the Labels field in the covering RRSIG RDATA, then the
- RRset and its covering RRSIG RR were created as a result of wildcard
- expansion. Once the resolver has verified the signature as described
- in Section 5.3, the resolver must take additional steps to verify the
+ If the number of labels in an RRset's owner name is greater than the
+ Labels field of the covering RRSIG RR, then the RRset and its
+ covering RRSIG RR were created as a result of wildcard expansion.
+ Once the resolver has verified the signature as described in Section
+ 5.3, the resolver must take additional steps to verify the
non-existence of an exact match or closer wildcard match for the
- query. Section 5.4 discusses these steps.
+ query. Section 5.4 discusses these steps.
Note that the response received by the resolver should include all
NSEC RRs needed to authenticate the response (see Section 3.1.3).
-Arends, et al. Expires April 26, 2004 [Page 29]
+Arends, et al. Expires June 16, 2004 [Page 31]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
according to the standard RRset authentication rules described in
authenticated NSEC RR, then the NSEC RR's type bit map field lists
all RR types present at that owner name, and a resolver can prove
that the requested RR type does not exist by checking for the RR
- type in the bit map. Since the existence of the authenticated
- NSEC RR proves that the owner name exists in the zone, wildcard
- expansion could not have been used to match the requested RR owner
- name and type.
+ type in the bit map. If the number of labels in an authenticated
+ NSEC RR's owner name equals the Labels field of the covering RRSIG
+ RR, then the existence of the NSEC RR proves that wildcard
+ expansion could not have been used to match the request.
o If the requested RR name would appear after an authenticated NSEC
- RR owner name and before the name listed in that NSEC RR's Next
+ RR's owner name and before the name listed in that NSEC RR's Next
Domain Name field according to the canonical DNS name order
- defined in [I-D.ietf-dnsext-dnssec-records], then no exact match
- for the requested RR name exists in the zone. However, it is
- possible that a wildcard could be used to match the requested RR
- owner name and type, so proving that the requested RRset does not
- exist also requires proving that no possible wildcard exists which
+ defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with
+ the requested name exist in the zone. However, it is possible
+ that a wildcard could be used to match the requested RR owner name
+ and type, so proving that the requested RRset does not exist also
+ requires proving that no possible wildcard RRset exists which
could have been used to generate a positive response.
To prove non-existence of an RRset, the resolver must be able to
verify both that the queried RRset does not exist and that no
relevant wildcard RRset exists. Proving this may require more than
one NSEC RRset from the zone. If the complete set of necessary NSEC
- RRsets is not present in a response (perhaps due to truncation), then
- a security-aware resolver MUST resend the query in order to attempt
- to obtain the full collection of NSEC RRs necessary to verify
- non-existence of the requested RRset. As with all DNS operations,
- however, the resolver MUST bound the work it puts into answering any
- particular query.
+ RRsets is not present in a response (perhaps due to message
+ truncation), then a security-aware resolver MUST resend the query in
+ order to attempt to obtain the full collection of NSEC RRs necessary
+ to verify non-existence of the requested RRset. As with all DNS
+ operations, however, the resolver MUST bound the work it puts into
+ answering any particular query.
Since a verified NSEC RR proves the existence of both itself and its
corresponding RRSIG RR, a verifier MUST ignore the settings of the
NSEC and RRSIG bits in an NSEC RR.
- Authentication examples are given in Section Appendix C.
+5.5 Authentication Example
+ Appendix C shows an example the authentication process.
-
-Arends, et al. Expires April 26, 2004 [Page 30]
+Arends, et al. Expires June 16, 2004 [Page 32]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
6. IANA Considerations
-Arends, et al. Expires April 26, 2004 [Page 31]
+Arends, et al. Expires June 16, 2004 [Page 33]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
7. Security Considerations
This document describes how the DNS security extensions use public
key cryptography to sign and authenticate DNS resource record sets.
Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general
- security considerations related to DNSSEC.
+ security considerations related to DNSSEC; see
+ [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the
+ DNSSEC resource record types.
An active attacker who can set the CD bit in a DNS query message or
the AD bit in a DNS response message can use these bits to defeat the
protection which DNSSEC attempts to provide to security-oblivious
recursive-mode resolvers. For this reason, use of these control bits
by a security-aware recursive-mode resolver requires a secure
- channel. See Section 3.2.2 and Section 4.2 for further discussion.
-
- DNSSEC introduces a number of denial of service issues. These issues
- will also be addressed in a future version of these security
- considerations.
-
-
-
+ channel. See Section 3.2.2 and Section 4.8 for further discussion.
+ The protocol described in this document attempts to extend the
+ benefits of DNSSEC to security-oblivious stub resolvers. However,
+ since recovery from validation failures is likely to be specific to
+ particular applications, the facilities that DNSSEC provides for stub
+ resolvers may prove inadequate. Operators of security-aware
+ recursive name servers will need to pay close attention to the
+ behavior of the applications which use their services when choosing a
+ local validation policy; failure to do so could easily result in the
+ recursive name server accidently denying service to the clients it is
+ intended to support.
-
-
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 32]
+Arends, et al. Expires June 16, 2004 [Page 34]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
8. Acknowledgements
- This document was created from the input and ideas of several members
- of the DNS Extensions Working Group and working group mailing list.
- The editors would like to express their thanks for the comments and
+ This document was created from the input and ideas of the members of
+ the DNS Extensions Working Group and working group mailing list. The
+ editors would like to express their thanks for the comments and
suggestions received during the revision of these security extension
- specifications.
-
-
-
+ specifications. While explicitly listing everyone who has
+ contributed during the decade during which DNSSEC has been under
+ development would be an impossible task,
+ [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
+ participants who were kind enough to comment on these documents.
-
-Arends, et al. Expires April 26, 2004 [Page 33]
+Arends, et al. Expires June 16, 2004 [Page 35]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
Normative References
-Arends, et al. Expires April 26, 2004 [Page 34]
+Arends, et al. Expires June 16, 2004 [Page 36]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
Informative References
-Arends, et al. Expires April 26, 2004 [Page 35]
+Arends, et al. Expires June 16, 2004 [Page 37]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
Matt Larson
-Arends, et al. Expires April 26, 2004 [Page 36]
+Arends, et al. Expires June 16, 2004 [Page 38]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
Appendix A. Signed Zone Example
The following example shows a (small) complete signed zone.
- example. 3600 IN SOA ns1.example. bugs.ns1.example. (
- 1065745538
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1071609350
3600
300
3600000
3600
)
- 3600 RRSIG SOA 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
- 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
- BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
- pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
- LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
+ 3600 RRSIG SOA 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
+ hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
+ VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
+ CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
+ owLe/OV+Qqqic7ShV/S9l2YJF9I= )
3600 NS ns1.example.
3600 NS ns2.example.
- 3600 RRSIG NS 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw
- ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ
- exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ
- dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF
- BYpCn/jKFJ7lYnYYGLAUofh/+mo= )
+ 3600 RRSIG NS 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
+ +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
+ s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
+ eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
+ FTVyQbVkcaxQ6U2FbZtMbfo//go= )
3600 MX 1 xx.example.
- 3600 RRSIG MX 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- CSB4g+vSxyrfsfycsZwAx2hKhwK/x7GAIY0p
- MLBgAA/USiiMben0II4aYf5lybs0NINnFDju
- 2Kc78M8t9zBGeJcZCZEs9mKiXhW8WJanvIjg
- BwJgWXwAnVnq20TXlsHiuwuhmtrb76/Avl4i
- lnX6XA3eeDlQlOTuPe0B91MCuow= )
+ 3600 RRSIG MX 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ JE9Kcx4NaXpaO2Jjyo5yi+DT6wgxwregHg18
+ 7xOOF0KjIYQpaoFY3Kp8MAKT7aupZpr5DmHe
+ IpBNI6jC59A2uNVP+6UfqAyJMoNnq9d/paM+
+ M+adwb+xrT+dZYpFZzyeXPmBqA/PVAtw1d5Q
+ 7wxkDWyzgasGiMNIKgYrm9vXz04= )
3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
- 3600 RRSIG NSEC 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- 10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG
- krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1
- IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By
- yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2
- 2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= )
- 3600 DNSKEY 256 3 1 (
- AQPdhnap0Oj2jUq74g+vel5cukdH+wpzjiH8
- ZOQSOHrw+s3TmbhyqXbZ/j5Uu9p65ARoevvG
- yv459dxxZCKZ4wftXe5BUkJvZVf8HnhYW5R+
- kQduVeqGVlkBarL5haKX28Pxvs8tV7CyY/Rd
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 37]
+ 3600 RRSIG NSEC 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
+ vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
+ TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
+ Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
+ 7T/nOEOVZujD8IN/Utv+KUg+P6U= )
+ 3600 DNSKEY 256 3 5 (
+ AQPmfvH5TF0S/vnd08C9EbVlG/+wbmFecyjH
+ UtEh3d8h045BE36XSbr0XZU6kPLgA/Shf7TV
+ fKduDMH7ASlP8MpUX4ci9ZiXffBjUKvsHORv
+ BgtAcUYRofvzRZ/jl078bI/JJg9ee4ndY6FO
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 39]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
- cfnJlZyJcfwY0ETo4P2gntVMERZuJQ==
+ 5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q==
)
- 3600 DNSKEY 257 3 1 (
- AQOwRqeRkdYUD6UCyJXTaErj0UYLHxOHlhDb
- qik1k/j2PJFOZ7GZhc95HnYco611O5VRQ6WQ
- pK0dL9eiwcc+gSS2L6V9pWxCfDnEPWFC6eVm
- jRZAdAU6gsyNSZCT7rF1lAXdmWcwkaIdNaDL
- oNqpieIQd2t+rd/oF8/++DRtzF0toQ==
+ 3600 DNSKEY 257 3 5 (
+ AQOwHAYrbYVzzKHF0PDHSt4zY+Vz1+yLz1/U
+ Pv2j2nukkWKLipnqg8X2vI754SRpqwpPCKpv
+ klUr36CE0byYLOpRE5WlKZjXm3uzDFIVdHUE
+ 2lFwkMP9tSHUrXbjypiZWZP71qNuBeYCDAyT
+ nLu7mxrT1Y7GdSV7I6vwt0mDSWQDXQ==
)
- 3600 RRSIG DNSKEY 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- EtFrBqs8i80Ath+xOtjPHcepV/cjATf2E1fo
- +fhSggjw2vAXDY4Sygk2tKZ9Tvhahmw1rRC3
- CnApLvsjQ9qmnYAvkZdMILw9gPx1rBaq9d7H
- nt7mPc/LFrO4G9JS6JNwBCnjwcxro8kNYLo6
- 97FCO3y4T7y9Hb80OvCZ36cNdps= )
- 3600 RRSIG DNSKEY 1 1 3600 20031108232541 (
- 20031009232541 23853 example.
- VseD0IGDKqJXiZMJnRNuq89ibF5g8VGPmMJS
- h/hS8+nu5vLiyEObJcVxfanslAlBQSGHmJsM
- AvXpeJUrT/zOyZ8vfy/igMhd25rnSxAD6uhl
- 4ohJiiPtFvHgLEvT0QZHizrP4wMvpXvfwn03
- 1/VEFzXZ0rULlTdWjoNzSMIYBwg= )
+ 3600 RRSIG DNSKEY 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ Pkxt/YJHVcnm3+56YGYziM69NDFJDEernUEU
+ pU1yBY8H7TlvIWhJz/qHsWcPt79ri0lP0Ho5
+ YDVp6GOFxBcR/7ejtV/izHO5tb88WM8xJLNc
+ tJZeSSVG62kt1q5fiKKsxhhpqZFQgc+h6htG
+ PjJstq6fvRq8kX7TPJcljUmDFKM= )
+ 3600 RRSIG DNSKEY 5 1 3600 20040115201552 (
+ 20031216201552 60717 example.
+ EVJnkWJSUTdaxIRX374Ki84OhYRYB+7TM/Z/
+ C8ufeGjcZkAPpkA3XjPao+4kG/lR/qW8oyNK
+ L0g5BI9fkcptXjf+0y3n5y/con6f+FOwHgdY
+ J7/fjSW27L3Je0MSrR3T/RNaokZafWDCT/34
+ Uu/YHFJKdBxs7sMeSBJ4UPm2uwc= )
a.example. 3600 IN NS ns1.a.example.
3600 IN NS ns2.a.example.
- 3600 DS 42939 1 1 (
- 4BA08982E5739A60E02B69409B0927F9524E
- 3494 )
- 3600 RRSIG DS 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- Dp6ySNq7SgIfndS4N5wFynmqXXf+WQ7RTAW/
- gC4RPDljbV8WnjZp5P7ip9zsHO9A7hEW8LPp
- zEMMzUPfucrSnZ/Jmc60BYIkzkt493QPfz1H
- YFRaJ6VyZoF38oN0s/H+a97c+HxAt4TElW+c
- iHQEOrm7yXIHwnrre1iuzMZn1jY= )
+ 3600 DS 48327 5 1 (
+ DFEB5E00E71A4DED5CABBBD7F15F24871983
+ CAB7 )
+ 3600 RRSIG DS 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/
+ hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb
+ rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c
+ ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC
+ 0yfe2uolEkeegjesDZuF+fC61Eg= )
3600 NSEC ai.example. NS DS RRSIG NSEC
- 3600 RRSIG NSEC 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- mhov2WXDa2Swk/7/VQoI36e5OKvd/0CmMWdi
- +3k/+i7mo9omz854ZBFMLaQzFvaS7Cn//I/H
- 7tYSY/fScUrs/UfB7le0DzdocsoaMYtexSS1
- KA7ofbPdYpBHngIGbO5EHaGrqbKGY61fIQ/g
- /WvT0KXnoX+v31Oq3VstBoWmizo= )
+ 3600 RRSIG NSEC 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ iq8exEVhvdx4s3w3VmK3Mzfngwpmpv3NwOpb
+ RMtgba/u5kyD4Mf03jyLtJLUevry2rZcRjF1
+ 3kDuKmewJ0jWA4sMuljJpx10rhvwlcKaJE3O
+ ViEb66GFqDxCXExikKWsPm8qckYZLQ7ABNjf
+ YgfAHJEJJj7K88QbKEK4/Je1hyk= )
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
- 3600 RRSIG A 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
+ 3600 RRSIG A 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
-Arends, et al. Expires April 26, 2004 [Page 38]
+Arends, et al. Expires June 16, 2004 [Page 40]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
- MtQkYPqpRfM5ntlRR/Wg7pdFt5fuf+ESoV+a
- 0RTtEUW9Q5ac7uV3luTnOSmWFFjes1x9Anqn
- KVeWcZJU/wRYqbUK2Q9s/kLb3cPMFavHal9n
- 3gR5v5zNaTQxBrdFlxGNgX/aa9Bs3LfxK14F
- UU/kYIPkm9qpSE3wtELJEq2cNsU= )
+ hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8
+ jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c
+ Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk
+ OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A
+ sWifTxvcG5hv+A6TOd0O2xJYRik= )
3600 HINFO "KLH-10" "ITS"
- 3600 RRSIG HINFO 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- jDn/zgIqY5ucajWNW333u+KfxORI55wvnZDs
- pCHZQ9ISjWNT7467wUcfJKBaG+alNlCOJExg
- z8yUS5NwySlrFtGL/CBCxmrSVioKMMetg7gP
- Qb6x5A53OhsQAGT6azS9bdBM2RFbqBkeZkXA
- 8mJ/QOldXdH5iPpmZb2Pn47x7V4= )
+ 3600 RRSIG HINFO 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ 4aSnKLykRT7htnnS8HtlM0YLMwU1Z92pvf/C
+ hxETE5B6W8x+uJs9KV9nlZ/B6TNk4nFRgKg2
+ KpKvEq7xUybNKwbbeGZE9n2fDH0FeDgHjqW2
+ Ke0lQuszRxjx+McTEqVJMyHrBKnqNdUh1G92
+ xo9NLoltg0GuwggZM240pRoTwO8= )
3600 AAAA 2001:db8::f00:baa9
- 3600 RRSIG AAAA 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- LcSkeCXOOcYClsS9GYJoG/yGeuyaUJrNICK1
- ONN4PEzGWJ7kcF+C4N972x05bPX+wsWszBbC
- uP/RqMyNenc8Is25te6hZ8MU7Z0zBDtKeTTG
- qz4ir4NZfqvB6moHjcVu6Pwb5KkSb8nAobCv
- 8gB4wQFPYoozOQYTprwGtIHR2k8= )
+ 3600 RRSIG AAAA 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5
+ 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ
+ G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI
+ A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI
+ zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= )
3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
- 3600 RRSIG NSEC 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- W3fFJqdRtmpz9QikpK+v5rL+Y5iNpx5H7X7c
- 1yPMlcaS0nhowHGjCPnNbCP28Ktv9I5eqhO1
- N/A75FLTOe9L5Qzetb/C3/ME8D46apKLBEv5
- 0GWsJqTsijj4dAjup60yeLPXTWxIdO6RNdfe
- Qd56t0fY79/kd25RzRCFGs2qHXs= )
+ 3600 RRSIG NSEC 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ Xr3qBss/U0yN12SL2stWs0AACeQjvRms9+xE
+ ishTjb4B/XQ8yAfAmby5yF5DKR8900M0hT3Y
+ ikp/wIF4TmtH5W7UFN13To/GWGJygaa7wyzU
+ 4AtgtRwmmevSAgzxhC7yRXUWyhpfQoW7zwpR
+ ovChG5Ih3TOa8Qnch4IJQVfSFNU= )
b.example. 3600 IN NS ns1.b.example.
3600 IN NS ns2.b.example.
3600 NSEC ns1.example. NS RRSIG NSEC
- 3600 RRSIG NSEC 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th
- 0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM
- RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps
- TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f
- BFydo6dXwQ4WK8OUC6sMCM+OHEg= )
+ 3600 RRSIG NSEC 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
+ VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
+ VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
+ k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
+ GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8
ns1.example. 3600 IN A 192.0.2.1
- 3600 RRSIG A 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- dJTb+VNXApV4lPaEwlyZxOS17eofL95DJe58
- +ija8iaROK9a9D7bAI7lIKJ/4hSfBN8lIjhF
- cpVeuGXCxldaSTOhAU5bg2GZJfxS4onfvBTE
- HBf19SZAT9rHBeNJISau8EwDaNBHBweiaC/s
+ 3600 RRSIG A 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7
+ CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs
+ RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf
+ +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa
-Arends, et al. Expires April 26, 2004 [Page 39]
+Arends, et al. Expires June 16, 2004 [Page 41]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
- Oett68JnQVQq2l/DhWsJSjuIFBQ= )
+ WNJ/ulvIFa20d0xtlB7jazNCZ3Y= )
3600 NSEC ns2.example. A RRSIG NSEC
- 3600 RRSIG NSEC 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- M8q/t6bDqPktgMyfa2LjkEDZiGloFp+I8LaO
- KBQt96RzZ9xiXOA/7wE5ZrBrgzfl1eotLn0L
- zbOwCwpZf7XoVm/IYCOlIEPj6kJHYvIIzp3a
- ZBn7uDx1kInt7qc2AmTpPiWCPtSD5KTBwdLk
- o3hJ8fow/NDw5Lsb6RQOSQ5Qxuo= )
+ 3600 RRSIG NSEC 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ
+ sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0
+ eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA
+ s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj
+ I2A5W86mMEbSgEF/pZHX/wi5FJI= )
ns2.example. 3600 IN A 192.0.2.2
- 3600 RRSIG A 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- VGTTFv2DZ+KN+tm7dzAP1vWGZTLdYn9v/yuQ
- tu9rQYAwVWoGq7iiADgLlY0cjR58GCKCGfn4
- mXMyM9mDljOj3VmHxUjRNMgUo+AoIi8Jysr9
- +huB5dgYRKFukcCpxKb1SmXNmSLfdS75gCas
- 8Ic8f9zHwZmCUc0wnxX6x+422PM= )
+ 3600 RRSIG A 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL
+ xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK
+ HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht
+ sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG
+ wCbeY0Rl8MIRcAaiIkFos/8hd1g= )
3600 NSEC *.w.example. A RRSIG NSEC
- 3600 RRSIG NSEC 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- kkYPMaBn4zJM/iQAOO9i81X57MMCQnzk+pch
- 6tWUFF/D1ZFZf8QY2MzwDA5Bv/1DluWVbo3x
- WjzyUV7fn77k9QKLQseUSXGnpyL2HR1hGfBV
- 6ZHAqJc99t5+5vjyiflLtOpA0+Ri46SlQGZf
- IZ4X2Ksgn+hpIu77NRQMdmh59M8= )
+ 3600 RRSIG NSEC 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ Vxovi9gQjxqYBI5QF2ZcbZ/5my7C+22uXKVb
+ IN5dmV82uu2TqJ4g2a2KKywlVi+4Kcnm4O3b
+ f7pV4g7pcQopa9AFiY8byFrPftuNvraDyp6J
+ aPllr/HnIPGP4Vw78LKW4n812K2VxV8p/IJl
+ yCup5bk/Dr47eU2/6+lqrBTOV8Q= )
*.w.example. 3600 IN MX 1 ai.example.
- 3600 RRSIG MX 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- Uht2mND0Kzc4hnM4Pq4zM+fjiGTEcCzx+wSD
- b2flOHxLQPv75mXfnH1tZv7iwrzQmcyucWsd
- agwalJcGa3A2+UL45fjYR6zDEsag4cdg1D0/
- +T7gIqOGWhYfiXbXuTOgUfyZRXqyGsHsAu20
- FxfIqrcIL24dO4Ytdz2ifqvJmuM= )
+ 3600 RRSIG MX 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg
+ OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns
+ Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA
+ n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK
+ 91Ena87PA2MvoOE+A3ZpEk8MjEE= )
3600 NSEC x.w.example. MX RRSIG NSEC
- 3600 RRSIG NSEC 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- fsk9iik9+gpte3I4tffoXyca5jfuYnLLy7/9
- 7LAVd4KKj9zqSB8f3QD1mjditUK9PGTTtlPL
- 4mq8F3T8PIt0pfgV8mPl6GP+bR+iVQEEE1YH
- yzR21az4Od5KBYYdsPjZzJnOhzCtgyleAoOx
- vOHmndDhRTDwVCg179qlrEIsOgE= )
+ 3600 RRSIG NSEC 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr
+ f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45
+ 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK
+ /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW
+ ANi1i3zhPOd3+Vjt4IQzaJXqVZE= )
x.w.example. 3600 IN MX 1 xx.example.
- 3600 RRSIG MX 1 3 3600 20031108232541 (
- 20031009232541 5742 example.
- i65kcyRnXBHd3ynSNTVKpd71DS85EjGDTi7d
- NQR+E4/qtXVaU78hmG4BhyFMVbvyPNpj83z5
- UqpB0baVoSVTSqGMSLxi1T38H8gqPgaYd+4r
- uEEXZj5I+s8Cq/1RHXi0yqISqeUGAqMHqryp
+ 3600 RRSIG MX 5 3 3600 20040115201552 (
+ 20031216201552 41681 example.
+ g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW
+ ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m
+ 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY
+ MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv
-Arends, et al. Expires April 26, 2004 [Page 40]
+Arends, et al. Expires June 16, 2004 [Page 42]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
- IKZXg2219TD4UqJuRATLhxZj2fU= )
+ btznHMFDIbtuw/tAX7xXH2pDDHY= )
3600 NSEC x.y.w.example. MX RRSIG NSEC
- 3600 RRSIG NSEC 1 3 3600 20031108232541 (
- 20031009232541 5742 example.
- VTRE+Bu91QK7dBiMshr04tE/I5HCvSrjqDv+
- b4tlUqUqkv4MoxfoceUwavMkdLm9Pi/aYUrS
- m6XVGBDAjpDmjivlMKNkME8c0f7oQ3E1CtHS
- pPLjTcB9WfxEOzjJJGK5BDDT6A56P4eibLiw
- +bNx4OGknGvVqhg9pu5qEWi814s= )
+ 3600 RRSIG NSEC 5 3 3600 20040115201552 (
+ 20031216201552 41681 example.
+ zwAU3bQHLeDawvqbvlmNosGMGDz9wdEe/iia
+ CU8DbanqOzUiPfqEgBN3evFMpGBM9H3zMjGA
+ EjnP4fMerk7dzD8jfyLzNdCGsJjPtnEgctGA
+ aNd+NGtSmedzeNGvlj7mNxnAdqHFY1c902pT
+ 3lMXiX4KNWUhB87q/pT/5z+xrqY= )
x.y.w.example. 3600 IN MX 1 xx.example.
- 3600 RRSIG MX 1 4 3600 20031108232541 (
- 20031009232541 5742 example.
- yDPXa5Osa4r1AF0AjKWOo87kGNDlnVPmCbIi
- MPvBpzJ91d5TFtEZWYJpYv+eGWZCJhK7SsnL
- Zbbjthkn7YmX1tReDQhn8aCQ6DyrIU6wZpj5
- ywBx0z3HGcqoYmv+AiFtcYVPxG0elsrakIwG
- /e+CPi2yE2c9M+NnwMxhpEFVGRs= )
+ 3600 RRSIG MX 5 4 3600 20040115201552 (
+ 20031216201552 41681 example.
+ slLY7KbPseET3XMJz/yGJBJpDczy1N2W4SAD
+ v5Jx/osOWviEJBpUEwRndX+VmsmQJqKsQxtE
+ unmxl4Sh9cuVyALJy1ByF9hZ0+E3i35qoxOK
+ Oe+JZyiEiebZfZ8doH5J+keCkIQ8EHzw8Hnk
+ Iykd5UmaTO5j4LlRnAvF8Z1m9/k= )
3600 NSEC xx.example. MX RRSIG NSEC
- 3600 RRSIG NSEC 1 4 3600 20031108232541 (
- 20031009232541 5742 example.
- cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj
- R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb
- w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P
- sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa
- 66FPTb3/hhrHYkMneBO2Yvfvpj8= )
+ 3600 RRSIG NSEC 5 4 3600 20040115201552 (
+ 20031216201552 41681 example.
+ sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
+ VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
+ Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
+ AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
+ viOQHZ6I4xoZQP5G7r98/PhlrLM= )
xx.example. 3600 IN A 192.0.2.10
- 3600 RRSIG A 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- ZW+++XV6FyceT4UtcfbVwcsx3u5tRfFLfAHp
- Ji11YMdORJKIJS0uVfu+UuAbe/FImnBmQq4v
- ShjQXbLeN9BKLvde4dlMphHSKhp24913/KFd
- +N0DMDWGZ/wPoACnqrpn1gDKWdT0l+gkF3y4
- aI16ggg9/UEWRbvn+7tp2UfMYSw= )
+ 3600 RRSIG A 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap
+ tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq
+ iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS
+ KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G
+ 0ToQVY81bPc3WXKZjRxQl3jiKtU= )
3600 HINFO "KLH-10" "TOPS-20"
- 3600 RRSIG HINFO 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- vteMgDuG1ekaSmWlXlwVRoqTXjvZ8kGWCAku
- 6Rd3t/wPeVmn3YSbC8+szYRgP8n0HvYzmVYj
- qPyC1HCFoqIJIaNLkDEyCSHuhBwpVhyKGJdM
- EbJ1P8Yk3w5Szjap6wn7QxcLnr8Df3xUMXnB
- AAwDzum3fUKzVM274T9O8ggeXgE= )
+ 3600 RRSIG HINFO 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ fZIotOyJqpRTZ0KH5lsZIksuyslAMckBclZw
+ p3LJiaYAibf+rwNFpS3CPUFsyCrA8UL+iVfA
+ gTxa6O8+yKYsDXZ2x6wPPDqmBEeHT1XiKEA/
+ pC+O35tVS6oLMYWJyGAGBJitXZQGr+MiBvSp
+ EDXT07qFXtGntvBSpF9uQbEub6Y= )
3600 AAAA 2001:db8::f00:baaa
- 3600 RRSIG AAAA 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43
- YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27
- ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+
- AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0
+ 3600 RRSIG AAAA 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2
+ dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD
+ mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg
+ CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z
-Arends, et al. Expires April 26, 2004 [Page 41]
+Arends, et al. Expires June 16, 2004 [Page 43]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
- GxlD/3EneV4+IIIv0hekxzpR8Qs= )
+ D4ZubIon0XGe9fIjLnmb3pX/FUk= )
3600 NSEC example. A HINFO AAAA RRSIG NSEC
- 3600 RRSIG NSEC 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- cKkFJS6Em56M0XCjMma4zFzy5ylHh2ma62oe
- yHrqkMYS+QVUuJ8yfAoXoFbok/kDLN3rsCKK
- ICJl1dFA3fvJnMejg0JVabQHShO2W1LmWegr
- dh251WZQVtJHDRY8/ltYB+GHUuFpZ1CF4m+c
- 6EPqS1uLrFpRg3k4BV5y6146nZ8= )
+ 3600 RRSIG NSEC 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ sbF8bfC6zqyuio2iov0C9byDCejWvxMJYgjn
+ uy3nXbvVXXzcA+d2zG6uPQ8VLRSolCE+OQqE
+ NsABxmoBhBwdxCrCpnU8SvzAkrRLwuOqAu1a
+ 1yBIfd352PHkQg1sxVDHGoFo3cFKzvkuD187
+ sSNF3PAC0HPadh7SdHmXlFQtQ44= )
The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
Flags indicate that each of these DNSKEY RRs is a zone key. One of
-Arends, et al. Expires April 26, 2004 [Page 42]
+Arends, et al. Expires June 16, 2004 [Page 44]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
Appendix B. Example Responses
;; Answer
x.w.example. 3600 IN MX 1 xx.example.
- x.w.example. 3600 RRSIG MX 1 3 3600 20031108232541 (
- 20031009232541 5742 example.
- i65kcyRnXBHd3ynSNTVKpd71DS85EjGDTi7d
- NQR+E4/qtXVaU78hmG4BhyFMVbvyPNpj83z5
- UqpB0baVoSVTSqGMSLxi1T38H8gqPgaYd+4r
- uEEXZj5I+s8Cq/1RHXi0yqISqeUGAqMHqryp
- IKZXg2219TD4UqJuRATLhxZj2fU= )
+ x.w.example. 3600 RRSIG MX 5 3 3600 20040115201552 (
+ 20031216201552 41681 example.
+ g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW
+ ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m
+ 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY
+ MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv
+ btznHMFDIbtuw/tAX7xXH2pDDHY= )
;; Authority
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
- example. 3600 RRSIG NS 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw
- ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ
- exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ
- dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF
- BYpCn/jKFJ7lYnYYGLAUofh/+mo= )
+ example. 3600 RRSIG NS 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
+ +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
+ s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
+ eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
+ FTVyQbVkcaxQ6U2FbZtMbfo//go= )
;; Additional
xx.example. 3600 IN A 192.0.2.10
- xx.example. 3600 RRSIG A 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- ZW+++XV6FyceT4UtcfbVwcsx3u5tRfFLfAHp
- Ji11YMdORJKIJS0uVfu+UuAbe/FImnBmQq4v
- ShjQXbLeN9BKLvde4dlMphHSKhp24913/KFd
- +N0DMDWGZ/wPoACnqrpn1gDKWdT0l+gkF3y4
- aI16ggg9/UEWRbvn+7tp2UfMYSw= )
+ xx.example. 3600 RRSIG A 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap
+ tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq
+ iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS
+ KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G
+ 0ToQVY81bPc3WXKZjRxQl3jiKtU= )
xx.example. 3600 AAAA 2001:db8::f00:baaa
- xx.example. 3600 RRSIG AAAA 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43
+ xx.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2
-Arends, et al. Expires April 26, 2004 [Page 43]
+Arends, et al. Expires June 16, 2004 [Page 45]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
- YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27
- ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+
- AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0
- GxlD/3EneV4+IIIv0hekxzpR8Qs= )
+ dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD
+ mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg
+ CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z
+ D4ZubIon0XGe9fIjLnmb3pX/FUk= )
ns1.example. 3600 IN A 192.0.2.1
- ns1.example. 3600 RRSIG A 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- dJTb+VNXApV4lPaEwlyZxOS17eofL95DJe58
- +ija8iaROK9a9D7bAI7lIKJ/4hSfBN8lIjhF
- cpVeuGXCxldaSTOhAU5bg2GZJfxS4onfvBTE
- HBf19SZAT9rHBeNJISau8EwDaNBHBweiaC/s
- Oett68JnQVQq2l/DhWsJSjuIFBQ= )
+ ns1.example. 3600 RRSIG A 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7
+ CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs
+ RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf
+ +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa
+ WNJ/ulvIFa20d0xtlB7jazNCZ3Y= )
ns2.example. 3600 IN A 192.0.2.2
- ns2.example. 3600 RRSIG A 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- VGTTFv2DZ+KN+tm7dzAP1vWGZTLdYn9v/yuQ
- tu9rQYAwVWoGq7iiADgLlY0cjR58GCKCGfn4
- mXMyM9mDljOj3VmHxUjRNMgUo+AoIi8Jysr9
- +huB5dgYRKFukcCpxKb1SmXNmSLfdS75gCas
- 8Ic8f9zHwZmCUc0wnxX6x+422PM= )
+ ns2.example. 3600 RRSIG A 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL
+ xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK
+ HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht
+ sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG
+ wCbeY0Rl8MIRcAaiIkFos/8hd1g= )
B.2 Name Error
;; (empty)
;; Authority
- example. 3600 IN SOA ns1.example. bugs.ns1.example. (
- 1065745538
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1071609350
3600
300
3600000
3600
)
- example. 3600 RRSIG SOA 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
- 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
- BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
+ example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
+ hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
+ VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
-Arends, et al. Expires April 26, 2004 [Page 44]
+Arends, et al. Expires June 16, 2004 [Page 46]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
- pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
- LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
+ CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
+ owLe/OV+Qqqic7ShV/S9l2YJF9I= )
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
- b.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th
- 0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM
- RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps
- TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f
- BFydo6dXwQ4WK8OUC6sMCM+OHEg= )
+ b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
+ VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
+ VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
+ k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
+ GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
- example. 3600 RRSIG NSEC 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- 10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG
- krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1
- IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By
- yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2
- 2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= )
+ example. 3600 RRSIG NSEC 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
+ vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
+ TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
+ Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
+ 7T/nOEOVZujD8IN/Utv+KUg+P6U= )
;; Additional
;; (empty)
;; (empty)
;; Authority
- example. 3600 IN SOA ns1.example. bugs.ns1.example. (
- 1065745538
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1071609350
3600
300
3600000
3600
)
- example. 3600 RRSIG SOA 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
- 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
+ example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
+ hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
-Arends, et al. Expires April 26, 2004 [Page 45]
+Arends, et al. Expires June 16, 2004 [Page 47]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
- BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
- pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
- LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
+ VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
+ CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
+ owLe/OV+Qqqic7ShV/S9l2YJF9I= )
ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
- ns1.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- M8q/t6bDqPktgMyfa2LjkEDZiGloFp+I8LaO
- KBQt96RzZ9xiXOA/7wE5ZrBrgzfl1eotLn0L
- zbOwCwpZf7XoVm/IYCOlIEPj6kJHYvIIzp3a
- ZBn7uDx1kInt7qc2AmTpPiWCPtSD5KTBwdLk
- o3hJ8fow/NDw5Lsb6RQOSQ5Qxuo= )
+ ns1.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ
+ sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0
+ eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA
+ s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj
+ I2A5W86mMEbSgEF/pZHX/wi5FJI= )
;; Additional
;; (empty)
;; Authority
a.example. 3600 IN NS ns1.a.example.
a.example. 3600 IN NS ns2.a.example.
- a.example. 3600 DS 42939 1 1 (
- 4BA08982E5739A60E02B69409B0927F9524E
- 3494 )
- a.example. 3600 RRSIG DS 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- Dp6ySNq7SgIfndS4N5wFynmqXXf+WQ7RTAW/
- gC4RPDljbV8WnjZp5P7ip9zsHO9A7hEW8LPp
- zEMMzUPfucrSnZ/Jmc60BYIkzkt493QPfz1H
- YFRaJ6VyZoF38oN0s/H+a97c+HxAt4TElW+c
- iHQEOrm7yXIHwnrre1iuzMZn1jY= )
+ a.example. 3600 DS 48327 5 1 (
+ DFEB5E00E71A4DED5CABBBD7F15F24871983
+ CAB7 )
+ a.example. 3600 RRSIG DS 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/
+ hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb
+ rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c
+ ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC
+ 0yfe2uolEkeegjesDZuF+fC61Eg= )
;; Additional
ns1.a.example. 3600 IN A 192.0.2.5
-Arends, et al. Expires April 26, 2004 [Page 46]
+Arends, et al. Expires June 16, 2004 [Page 48]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
B.5 Referral to Unsigned Zone
b.example. 3600 IN NS ns1.b.example.
b.example. 3600 IN NS ns2.b.example.
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
- b.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th
- 0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM
- RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps
- TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f
- BFydo6dXwQ4WK8OUC6sMCM+OHEg= )
+ b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
+ VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
+ VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
+ k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
+ GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
;; Additional
ns1.b.example. 3600 IN A 192.0.2.7
;; Answer
a.z.w.example. 3600 IN MX 1 ai.example.
- a.z.w.example. 3600 RRSIG MX 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- Uht2mND0Kzc4hnM4Pq4zM+fjiGTEcCzx+wSD
- b2flOHxLQPv75mXfnH1tZv7iwrzQmcyucWsd
+ a.z.w.example. 3600 RRSIG MX 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg
+ OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns
-Arends, et al. Expires April 26, 2004 [Page 47]
+Arends, et al. Expires June 16, 2004 [Page 49]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
- agwalJcGa3A2+UL45fjYR6zDEsag4cdg1D0/
- +T7gIqOGWhYfiXbXuTOgUfyZRXqyGsHsAu20
- FxfIqrcIL24dO4Ytdz2ifqvJmuM= )
+ Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA
+ n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK
+ 91Ena87PA2MvoOE+A3ZpEk8MjEE= )
;; Authority
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
- example. 3600 RRSIG NS 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw
- ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ
- exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ
- dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF
- BYpCn/jKFJ7lYnYYGLAUofh/+mo= )
+ example. 3600 RRSIG NS 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
+ +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
+ s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
+ eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
+ FTVyQbVkcaxQ6U2FbZtMbfo//go= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
- x.y.w.example. 3600 RRSIG NSEC 1 4 3600 20031108232541 (
- 20031009232541 5742 example.
- cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj
- R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb
- w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P
- sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa
- 66FPTb3/hhrHYkMneBO2Yvfvpj8= )
+ x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 (
+ 20031216201552 41681 example.
+ sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
+ VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
+ Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
+ AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
+ viOQHZ6I4xoZQP5G7r98/PhlrLM= )
;; Additional
ai.example. 3600 IN A 192.0.2.9
- ai.example. 3600 RRSIG A 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- MtQkYPqpRfM5ntlRR/Wg7pdFt5fuf+ESoV+a
- 0RTtEUW9Q5ac7uV3luTnOSmWFFjes1x9Anqn
- KVeWcZJU/wRYqbUK2Q9s/kLb3cPMFavHal9n
- 3gR5v5zNaTQxBrdFlxGNgX/aa9Bs3LfxK14F
- UU/kYIPkm9qpSE3wtELJEq2cNsU= )
+ ai.example. 3600 RRSIG A 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8
+ jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c
+ Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk
+ OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A
+ sWifTxvcG5hv+A6TOd0O2xJYRik= )
ai.example. 3600 AAAA 2001:db8::f00:baa9
- ai.example. 3600 RRSIG AAAA 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- LcSkeCXOOcYClsS9GYJoG/yGeuyaUJrNICK1
- ONN4PEzGWJ7kcF+C4N972x05bPX+wsWszBbC
- uP/RqMyNenc8Is25te6hZ8MU7Z0zBDtKeTTG
- qz4ir4NZfqvB6moHjcVu6Pwb5KkSb8nAobCv
- 8gB4wQFPYoozOQYTprwGtIHR2k8= )
+ ai.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5
+ 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ
+ G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI
+ A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI
+ zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= )
B.7 Wildcard No Data Error
-Arends, et al. Expires April 26, 2004 [Page 48]
+Arends, et al. Expires June 16, 2004 [Page 50]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
;; Header: QR AA DO RCODE=0
;; (empty)
;; Authority
- example. 3600 IN SOA ns1.example. bugs.ns1.example. (
- 1065745538
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1071609350
3600
300
3600000
3600
)
- example. 3600 RRSIG SOA 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
- 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
- BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
- pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
- LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
+ example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
+ hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
+ VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
+ CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
+ owLe/OV+Qqqic7ShV/S9l2YJF9I= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
- x.y.w.example. 3600 RRSIG NSEC 1 4 3600 20031108232541 (
- 20031009232541 5742 example.
- cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj
- R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb
- w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P
- sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa
- 66FPTb3/hhrHYkMneBO2Yvfvpj8= )
+ x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 (
+ 20031216201552 41681 example.
+ sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
+ VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
+ Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
+ AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
+ viOQHZ6I4xoZQP5G7r98/PhlrLM= )
*.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
- *.w.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 (
- 20031009232541 5742 example.
- fsk9iik9+gpte3I4tffoXyca5jfuYnLLy7/9
- 7LAVd4KKj9zqSB8f3QD1mjditUK9PGTTtlPL
- 4mq8F3T8PIt0pfgV8mPl6GP+bR+iVQEEE1YH
- yzR21az4Od5KBYYdsPjZzJnOhzCtgyleAoOx
- vOHmndDhRTDwVCg179qlrEIsOgE= )
+ *.w.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
+ 20031216201552 41681 example.
+ OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr
+ f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45
+ 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK
+ /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW
+ ANi1i3zhPOd3+Vjt4IQzaJXqVZE= )
;; Additional
;; (empty)
-Arends, et al. Expires April 26, 2004 [Page 49]
+Arends, et al. Expires June 16, 2004 [Page 51]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
;; Header: QR AA DO RCODE=0
;; (empty)
;; Authority
- example. 3600 IN SOA ns1.example. bugs.ns1.example. (
- 1065745538
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1071609350
3600
300
3600000
3600
)
- example. 3600 RRSIG SOA 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
- 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
- BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
- pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
- LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
+ example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
+ hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
+ VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
+ CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
+ owLe/OV+Qqqic7ShV/S9l2YJF9I= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
- example. 3600 RRSIG NSEC 1 1 3600 20031108232541 (
- 20031009232541 5742 example.
- 10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG
- krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1
- IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By
- yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2
- 2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= )
+ example. 3600 RRSIG NSEC 5 1 3600 20040115201552 (
+ 20031216201552 41681 example.
+ kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
+ vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
+ TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
+ Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
+ 7T/nOEOVZujD8IN/Utv+KUg+P6U= )
;; Additional
;; (empty)
-Arends, et al. Expires April 26, 2004 [Page 50]
+Arends, et al. Expires June 16, 2004 [Page 52]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
Appendix C. Authentication Examples
The query in section Appendix B.1 returned an MX RRset for
"x.w.example.com". The corresponding RRSIG indicates the MX RRset was
- signed by an "example" DNSKEY with algorithm 1 and key tag 5742. The
- resolver needs the corresponding DNSKEY RR in order to authenticate
- this answer. The discussion below describes how a resolver might
- obtain this DNSKEY RR.
+ signed by an "example" DNSKEY with algorithm 5 and key tag 41681.
+ The resolver needs the corresponding DNSKEY RR in order to
+ authenticate this answer. The discussion below describes how a
+ resolver might obtain this DNSKEY RR.
The RRSIG indicates the original TTL of the MX RRset was 3600 and,
for the purpose of authentication, the current TTL is replaced by
-Arends, et al. Expires April 26, 2004 [Page 51]
+Arends, et al. Expires June 16, 2004 [Page 53]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
matching "example" DNSKEY is found, the resolver checks this DNSKEY
DNSKEY RRset are considered authenticated.
Finally the resolver checks that some DNSKEY RR in the "example"
- DNSKEY RRset uses algorithm 1 and has a key tag of 5742. This DNSKEY
- is used to authenticated the RRSIG included in the response. If
- multiple "example" DNSKEY RRs have algorithm 1 and key tag of 5742,
- then each DNSKEY RR is tried and the answer is authenticated if
- either DNSKEY RR validates the signature as described above.
+ DNSKEY RRset uses algorithm 5 and has a key tag of 41681. This
+ DNSKEY is used to authenticated the RRSIG included in the response.
+ If multiple "example" DNSKEY RRs have algorithm 5 and key tag of
+ 41681, then each DNSKEY RR is tried and the answer is authenticated
+ if either DNSKEY RR validates the signature as described above.
C.2 Name Error
-Arends, et al. Expires April 26, 2004 [Page 52]
+Arends, et al. Expires June 16, 2004 [Page 54]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
identical to that of the MX RRset discussed above.
The query in section Appendix B.6 returned an answer that was
produced as a result of wildcard expansion. The RRset expanded as
the similar to The corresponding RRSIG indicates the MX RRset was
- signed by an "example" DNSKEY with algorithm 1 and key tag 5742. The
- RRSIG indicates the original TTL of the MX RRset was 3600 and, for
- the purpose of authentication, the current TTL is replaced by 3600.
- The RRSIG labels field value of 2 indicates the answer the result of
- wildcard expansion since the "a.z.w.example" name contains 4 labels.
- The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset
- is placed in canonical form and, assuming the current time falls
- between the signature inception and expiration dates, the signature
- is authenticated.
+ signed by an "example" DNSKEY with algorithm 5 and key tag 41681.
+ The RRSIG indicates the original TTL of the MX RRset was 3600 and,
+ for the purpose of authentication, the current TTL is replaced by
+ 3600. The RRSIG labels field value of 2 indicates the answer the
+ result of wildcard expansion since the "a.z.w.example" name contains
+ 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example",
+ the MX RRset is placed in canonical form and, assuming the current
+ time falls between the signature inception and expiration dates, the
+ signature is authenticated.
The NSEC proves that no closer match (exact or closer wildcard) could
have been used to answer this query and the NSEC RR must also be
-Arends, et al. Expires April 26, 2004 [Page 53]
+Arends, et al. Expires June 16, 2004 [Page 55]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
Intellectual Property Statement
-Arends, et al. Expires April 26, 2004 [Page 54]
+Arends, et al. Expires June 16, 2004 [Page 56]
\f
-Internet-Draft DNSSEC Protocol Modifications October 2003
+Internet-Draft DNSSEC Protocol Modifications December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-Arends, et al. Expires April 26, 2004 [Page 55]
+Arends, et al. Expires June 16, 2004 [Page 57]
\f
+
DNS Extensions R. Arends
Internet-Draft Telematica Instituut
-Expires: April 26, 2004 R. Austein
+Expires: June 16, 2004 R. Austein
ISC
M. Larson
VeriSign
USC/ISI
S. Rose
NIST
- October 27, 2003
+ December 17, 2003
Resource Records for the DNS Security Extensions
- draft-ietf-dnsext-dnssec-records-05
+ draft-ietf-dnsext-dnssec-records-06
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on April 26, 2004.
+ This Internet-Draft will expire on June 16, 2004.
Copyright Notice
-Arends, et al. Expires April 26, 2004 [Page 1]
+Arends, et al. Expires June 16, 2004 [Page 1]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
signature (RRSIG), and authenticated denial of existence (NSEC)
3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11
3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11
3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11
- 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 11
+ 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 12
3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12
- 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 12
+ 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 13
3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 13
4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 15
4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15
4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15
- 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 16
- 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 16
- 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 16
+ 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . . . . 16
+ 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 17
+ 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 17
4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17
- 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18
- 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18
- 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 19
- 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19
+ 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 19
+ 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 19
+ 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 20
+ 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 20
-Arends, et al. Expires April 26, 2004 [Page 2]
+Arends, et al. Expires June 16, 2004 [Page 2]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
- 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19
- 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19
- 5.2 Processing of DS RRs When Validating Responses . . . . . . . 19
- 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 20
- 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20
- 6. Canonical Form and Order of Resource Records . . . . . . . . 21
- 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21
- 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21
- 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23
- 8. Security Considerations . . . . . . . . . . . . . . . . . . 25
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26
- Normative References . . . . . . . . . . . . . . . . . . . . 27
- Informative References . . . . . . . . . . . . . . . . . . . 29
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
- A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 31
- A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 31
- A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 31
- A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 32
- B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 33
- B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 34
- Intellectual Property and Copyright Statements . . . . . . . 35
+ 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 20
+ 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.2 Processing of DS RRs When Validating Responses . . . . . . . 20
+ 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 21
+ 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 21
+ 6. Canonical Form and Order of Resource Records . . . . . . . . 22
+ 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 22
+ 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 22
+ 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 23
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . 26
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27
+ Normative References . . . . . . . . . . . . . . . . . . . . 28
+ Informative References . . . . . . . . . . . . . . . . . . . 30
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
+ A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 32
+ A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 32
+ A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 32
+ A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 33
+ B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 34
+ B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 35
+ Intellectual Property and Copyright Statements . . . . . . . 36
-Arends, et al. Expires April 26, 2004 [Page 3]
+Arends, et al. Expires June 16, 2004 [Page 3]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
1. Introduction
-Arends, et al. Expires April 26, 2004 [Page 4]
+Arends, et al. Expires June 16, 2004 [Page 4]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
An example correction to dnssec-editors might be: Page X says
-Arends, et al. Expires April 26, 2004 [Page 5]
+Arends, et al. Expires June 16, 2004 [Page 5]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
2. The DNSKEY Resource Record
-Arends, et al. Expires April 26, 2004 [Page 6]
+Arends, et al. Expires June 16, 2004 [Page 6]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
point. This flag is only intended to be to a hint to zone signing or
-Arends, et al. Expires April 26, 2004 [Page 7]
+Arends, et al. Expires June 16, 2004 [Page 7]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
2.3 DNSKEY RR Example
-Arends, et al. Expires April 26, 2004 [Page 8]
+Arends, et al. Expires June 16, 2004 [Page 8]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
3. The RRSIG Resource Record
Key Tag to identify the DNSKEY RR containing the public key that a
resolver can use to verify the signature.
+ Because every authoritative RRset in a zone must be protected by a
+ digital signature, RRSIG RRs must be present for names containing a
+ CNAME RR. This is a change to the traditional DNS specification
+ [RFC1034] that stated that if a CNAME is present for a name, it is
+ the only type allowed at that name. A RRSIG and NSEC (see Section 4)
+ MUST exist for the same name as a CNAME resource record in a secure
+ zone.
+
The Type value for the RRSIG RR type is 46.
The RRSIG RR is class independent.
An RRSIG RR MUST have the same class as the RRset it covers.
The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset
- it covers.
+ it covers. This is an exception to the [RFC2181] rules for TTL
+ values of individuals RRs within a RRset: individual RRSIG with the
+ same owner name will have different TTLs if the RRsets that they
+ cover have different TTLs.
3.1 RRSIG RDATA Wire Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 9]
+\f
+Internet-Draft DNSSEC Resource Records December 2003
+
+
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 9]
-\f
-Internet-Draft DNSSEC Resource Records October 2003
-
-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
The value of the Label field MUST NOT count either the null (root)
label that terminates the owner name or the wildcard label (if
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 10]
+\f
+Internet-Draft DNSSEC Resource Records December 2003
+
+
present). The value of the Label field MUST be less than or equal to
the number of labels in the RRSIG owner name. For example,
"www.example.com." has a Label field value of 3, and "*.example.com."
stored in the Label field of the RRSIG RR, the wildcard label is part
of the RRset's owner name when generating or verifying the signature.
-
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 10]
-\f
-Internet-Draft DNSSEC Resource Records October 2003
-
-
3.1.4 Original TTL Field
The Original TTL field specifies the TTL of the covered RRset as it
validates this signature. Appendix B explains how to calculate Key
Tag values.
+
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 11]
+\f
+Internet-Draft DNSSEC Resource Records December 2003
+
+
3.1.7 The Signer's Name Field
The Signer's Name field value identifies the owner name of the DNSKEY
which receives an RRSIG RR containing a compressed Signer's Name
field SHOULD decompress the field value.
-
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 11]
-\f
-Internet-Draft DNSSEC Resource Records October 2003
-
-
3.1.8 The Signature Field
The Signature field contains the cryptographic signature which covers
Each RR in the RRset MUST have the TTL listed in the
RRSIG Original TTL Field;
- Any DNS names in the RDATA field of each RR MUST be in
- canonical form; and
- The RRset MUST be sorted in canonical order.
-3.2 The RRSIG RR Presentation Format
+Arends, et al. Expires June 16, 2004 [Page 12]
+\f
+Internet-Draft DNSSEC Resource Records December 2003
- The presentation format of the RDATA portion is as follows:
+ Any DNS names in the RDATA field of each RR MUST be in
+ canonical form; and
+ The RRset MUST be sorted in canonical order.
-Arends, et al. Expires April 26, 2004 [Page 12]
-\f
-Internet-Draft DNSSEC Resource Records October 2003
+3.2 The RRSIG RR Presentation Format
+ The presentation format of the RDATA portion is as follows:
The Type Covered field value MUST be represented either as an
unsigned decimal integer or as the mnemonic for the covered RR type.
3.3 RRSIG RR Example
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 13]
+\f
+Internet-Draft DNSSEC Resource Records December 2003
+
+
The following an RRSIG RR stores the signature for the A RRset of
host.example.com:
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
-
-
-Arends, et al. Expires April 26, 2004 [Page 13]
-\f
-Internet-Draft DNSSEC Resource Records October 2003
-
-
The first four fields specify the owner name, TTL, Class, and RR type
(RRSIG). The "A" represents the Type Covered field. The value 5
identifies the Algorithm used (RSA-SHA1) to create the signature.
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 14]
+Arends, et al. Expires June 16, 2004 [Page 14]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
4. The NSEC Resource Record
denial of existence for DNS data, as described in
[I-D.ietf-dnsext-dnssec-protocol].
+ Because every authoritative name in a zone must be part of the NSEC
+ chain, NSEC RRs must be present for names containing a CNAME RR.
+ This is a change to the traditional DNS specification [RFC1034] that
+ stated that if a CNAME is present for a name, it is the only type
+ allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist
+ for the same name as a CNAME resource record in a secure zone.
+
The type value for the NSEC RR is 47.
The NSEC RR is class independent.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Type Bit Map /
+ / Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A sender MUST NOT use DNS name compression on the Next Domain Name
field when transmitting an NSEC RR. A receiver which receives an
NSEC RR containing a compressed Next Domain Name field SHOULD
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 15]
+\f
+Internet-Draft DNSSEC Resource Records December 2003
+
+
decompress the field value.
Owner names of RRsets not authoritative for the given zone (such as
glue records) MUST NOT be listed in the Next Domain Name unless at
least one authoritative RRset exists at the same owner name.
+4.1.2 The Type Bit Maps Field
+ The Type Bit Maps field identifies the RRset types which exist at the
+ NSEC RR's owner name.
+ 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 window block's bitmap,
+ and up to 32 octets (256 bits) of bitmap.
+ Blocks are present in the NSEC RR RDATA in increasing numerical
+ order.
-Arends, et al. Expires April 26, 2004 [Page 15]
-\f
-Internet-Draft DNSSEC Resource Records October 2003
+ Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
+ where "|" denotes concatenation.
-4.1.2 The Type Bit Map Field
+ 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 NSEC
+ RR's owner name. If a bit is set to 0, it indicates that no RRset of
+ that type is present for the NSEC RR's owner name.
- The Type Bit Map field identifies the RRset types which exist at the
- NSEC RR's owner name.
+ Since bit 0 in window block 0 refers to the non-existent RR type 0,
+ it MUST be set to 0. After verification, the validator MUST ignore
+ the value of bit 0 in window block 0.
- Each bit in the Type Bit Map field corresponds to an RR type. Bit 1
- corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS),
- and so forth. If a bit is set to 1, it indicates that an RRset of
- that type is present for the NSEC RR's owner name. If a bit is set to
- 0, it indicates that no RRset of that type present for the NSEC RR's
- owner name.
+ Bits representing pseudo-types MUST be set to 0, since they do not
+ appear in zone data. If encountered, they MUST be ignored upon
+ reading.
- A zone MUST NOT generate an NSEC RR for any domain name that only
- holds glue records.
+ Blocks with no types present MUST NOT be included. Trailing zero
+ octets in the bitmap MUST be omitted. The length of each block's
+ bitmap is determined by the type code with the largest numerical
+ value, within that block, among the set of RR types present at the
+ NSEC RR's owner name. Trailing zero octets not specified MUST be
+ interpreted as zero octets.
- Bits representing pseudo-RR types MUST be set to 0, since they do not
- appear in zone data. If encountered, they must be ignored upon
- reading.
- Trailing zero octets MUST be omitted. The length of the Type Bit Map
- field varies, and is determined by the type code with the largest
- numerical value among the set of RR types present at the NSEC RR's
- owner name. Trailing zero octets not specified MUST be interpreted
- as zero octets.
- The above Type Bit Map format MUST NOT be used when an RR type code
- with numerical value greater than 127 is present.
+Arends, et al. Expires June 16, 2004 [Page 16]
+\f
+Internet-Draft DNSSEC Resource Records December 2003
- Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A
- value of 0 in bit 0 denotes the format described above, therefore bit
- 0 MUST have a value of 0. The format and meaning of a Type Bit Map
- with a value of 1 in bit 0 is undefined.
+
+ A zone MUST NOT generate an NSEC RR for any domain name that only
+ holds glue records.
4.1.3 Inclusion of Wildcard Names in NSEC RDATA
The Next Domain Name field is represented as a domain name.
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 16]
-\f
-Internet-Draft DNSSEC Resource Records October 2003
-
-
- The Type Bit Map field is represented either as a sequence of RR type
- mnemonics or as a sequence of unsigned decimal integers denoting the
- RR type codes.
+ 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.
4.3 NSEC RR Example
alfa.example.com. and identifies the next authoritative name after
alfa.example.com.
- alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC
+ alfa.example.com. 86400 IN NSEC host.example.com. (
+ A MX RRSIG NSEC TYPE1234 )
The first four text fields specify the name, TTL, Class, and RR type
(NSEC). The entry host.example.com. is the next authoritative name
after alfa.example.com. in canonical order. The A, MX, RRSIG and NSEC
- mnemonics indicate there are A, MX, RRSIG and NSEC RRsets associated
- with the name alfa.example.com.
+ mnemonics indicate there are A, MX, RRSIG, NSEC, and TYPE1234 RRsets
+ associated with the name alfa.example.com.
+
+ The RDATA section of the NSEC RR above would be encoded as:
+
+ 0x04 'h' 'o' 's' 't'
+ 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
+ 0x03 'c' 'o' 'm' 0x00
+ 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
+ 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x20
+
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 17]
+\f
+Internet-Draft DNSSEC Resource Records December 2003
+
Assuming that the resolver can authenticate this NSEC record, it
could be used to prove that beta.example.com does not exist, or could
-Arends, et al. Expires April 26, 2004 [Page 17]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 18]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
5. The DS Resource Record
The DS Resource Record refers to a DNSKEY RR and is used in the DNS
DNSKEY authentication process. A DS RR refers to a DNSKEY RR by
storing the key tag, algorithm number, and a digest of the DNSKEY RR.
- Note that while the digest should be sufficient to identify the key,
- storing the key tag and key algorithm helps make the identification
- process more efficient. By authenticating the DS record, a resolver
- can authenticate the DNSKEY RR to which the DS record points. The
- key authentication process is described in
+ Note that while the digest should be sufficient to identify the
+ public key, storing the key tag and key algorithm helps make the
+ identification process more efficient. By authenticating the DS
+ record, a resolver can authenticate the DNSKEY RR to which the DS
+ record points. The key authentication process is described in
[I-D.ietf-dnsext-dnssec-protocol].
The DS RR and its corresponding DNSKEY RR have the same owner name,
-Arends, et al. Expires April 26, 2004 [Page 18]
+Arends, et al. Expires June 16, 2004 [Page 19]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
5.1.1 The Key Tag Field
-Arends, et al. Expires April 26, 2004 [Page 19]
+Arends, et al. Expires June 16, 2004 [Page 20]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
have Flags bit 7 set to value 1. If the key tag does not indicate a
-Arends, et al. Expires April 26, 2004 [Page 20]
+Arends, et al. Expires June 16, 2004 [Page 21]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
6. Canonical Form and Order of Resource Records
-Arends, et al. Expires April 26, 2004 [Page 21]
+Arends, et al. Expires June 16, 2004 [Page 22]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
replaced by the corresponding lowercase US-ASCII letters;
of each RR as a left justified unsigned octet sequence. The absence
of an octet sorts before a zero octet.
+ [RFC2181] specifies that an RRset is not allowed to contain duplicate
+ records (multiple RRs with the same owner name, class, type, and
+ RDATA). Therefore, if an implementation detects duplicate RRs during
+ RRset canonicalization, the implementation MUST treat this as a
+ protocol error. If the implementation chooses to handle this
+ protocol error in the spirit of the robustness principle (being
+ liberal in what it accepts), the implementation MUST remove all but
+ one of the duplicate RR(s) for purposes of calculating the canonical
+ form of the RRset.
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 22]
+Arends, et al. Expires June 16, 2004 [Page 23]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
7. IANA Considerations
(SIG) and 25 (KEY) to the "SIG(0)" transaction security protocol
described in [RFC2931].
- SIG(0) Algorithm Numbers: [RFC2535] created an IANA registry for
- DNSSEC Resource Record Algorithm field numbers, and assigned
+ DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
+ for DNSSEC Resource Record Algorithm field numbers, and assigned
values 1-4 and 252-255. [RFC3110] assigned value 5.
- [I-D.ietf-dnsext-dnssec-2535typecode-change] renamed this registry
- to "SIG(0) Algorithm Numbers" to indicate that this registry is
- now used only by the "SIG(0)" transaction security protocol
- described in [RFC2931].
-
- DNS Security Algorithm Numbers:
- [I-D.ietf-dnsext-dnssec-2535typecode-change] created a new "DNS
- Security Algorithm Numbers" registry, assigned initial values to
- algorithms 2 (Diffie-Hellman), 3 (DSA/SHA-1), 5 (RSA/SHA-1), 253
- (private algorithms - domain name) and 254 (private algorithms -
- OID), and reserved values 0, 1, and 255. As stated in
- [I-D.ietf-dnsext-dnssec-2535typecode-change], value 4 and values
- 6-252 are available for assignment by IETF Standards Action.
+ [I-D.ietf-dnsext-dnssec-2535typecode-change] altered this registry
+ to include flags for each entry regarding its use with the DNS
+ security extensions. Each algorithm entry could refer to an
+ algorithm that can be used for zone signing, transaction security
+ (see [RFC2931]) or both. Values 6-251 are available for assignment
+ by IETF standards action. See Appendix A for a full listing of the
+ DNS Security Algorithm Numbers entries at the time of writing and
+ their status of use in DNSSEC.
[I-D.ietf-dnsext-delegation-signer] created an IANA registry for
DNSSEC DS Digest Types, and assigned value 0 to reserved and value
registry remains closed, and all KEY and DNSKEY records are
required to have Protocol Octet value of 3.
+ Flag bits in the KEY and DNSKEY RRs:
+ [I-D.ietf-dnsext-dnssec-2535typecode-change] created an IANA
+ registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
+ this registry only contains an assignment for bit 7 (the ZONE bit)
+ and a reservation for bit 15 for the Secure Entry Point flag (SEP
+ bit) [I-D.ietf-dnsext-keyrr-key-signing-flag]. Bits 0-6 and 8-14
+ are available for assignment by IETF Standards Action.
-
-
-Arends, et al. Expires April 26, 2004 [Page 23]
+Arends, et al. Expires June 16, 2004 [Page 24]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
- Flag bits in the KEY and DNSKEY RRs: The Flag bits in the KEY and
- DNSKEY RRs are not assigned by IANA, and there is no IANA registry
- for these flags. All changes to the meaning of the Flag bits in
- the KEY and DNSKEY RRs require a standards action.
-
Bit zero of Type Bit Map in NSEC RRs: The meaning of a value of 1 in
bit zero of the Type Bit Map of an NSEC RR can only be assigned by
a standards action.
-Arends, et al. Expires April 26, 2004 [Page 24]
+
+
+
+
+
+Arends, et al. Expires June 16, 2004 [Page 25]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
8. Security Considerations
by the DNS security extensions, and presents an algorithm for
calculating a key tag for a public key. Other than the items
described below, the resource records themselves introduce no
- security considerations. The use of these records is specified in a
- separate document, and security considerations related to the use
- these resource records are discussed in that document.
+ security considerations. Please see [I-D.ietf-dnsext-dnssec-intro]
+ and Please see [I-D.ietf-dnsext-dnssec-protocol] additional security
+ considerations related to the use of these records.
The DS record points to a DNSKEY RR using a cryptographic digest, the
key algorithm type and a key tag. The DS record is intended to
-Arends, et al. Expires April 26, 2004 [Page 25]
+Arends, et al. Expires June 16, 2004 [Page 26]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
9. Acknowledgments
- This document was created from the input and ideas of several members
- of the DNS Extensions Working Group and working group mailing list.
- The editors would like to express their thanks for the comments and
+ This document was created from the input and ideas of the members of
+ the DNS Extensions Working Group and working group mailing list. The
+ editors would like to express their thanks for the comments and
suggestions received during the revision of these security extension
- specifications.
-
+ specifications. While explicitly listing everyone who has
+ contributed during the decade during which DNSSEC has been under
+ development would be an impossible task,
+ [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
+ participants who were kind enough to comment on these documents.
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 26]
+Arends, et al. Expires June 16, 2004 [Page 27]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
Normative References
-Arends, et al. Expires April 26, 2004 [Page 27]
+Arends, et al. Expires June 16, 2004 [Page 28]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
[I-D.ietf-dnsext-dnssec-intro]
-Arends, et al. Expires April 26, 2004 [Page 28]
+Arends, et al. Expires June 16, 2004 [Page 29]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
Informative References
-Arends, et al. Expires April 26, 2004 [Page 29]
+Arends, et al. Expires June 16, 2004 [Page 30]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
Scott Rose
-Arends, et al. Expires April 26, 2004 [Page 30]
+Arends, et al. Expires June 16, 2004 [Page 31]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
Appendix A. DNSSEC Algorithm and Digest Types
A.1 DNSSEC Algorithm Types
- An "Algorithm Number" field in the DNSKEY, RRSIG, and DS resource
- record types identifies the cryptographic algorithm used by the
- resource record. Algorithm specific formats are described in
- separate documents. The following table lists the currently defined
- algorithm types and provides references to their supporting
- documents:
-
- VALUE Algorithm [mnemonic] RFC STATUS
- 0 Reserved - -
- 1 RSA/MD5 [RSA/MD5] RFC 2537 NOT RECOMMENDED
- 2 Diffie-Hellman [DH] RFC 2539 OPTIONAL
- 3 DSA [DSA] RFC 2536 OPTIONAL
- 4 elliptic curve [ECC] TBA OPTIONAL
- 5 RSA/SHA1 [RSA/SHA1] RFC 3110 MANDATORY
- 6-251 available for assignment -
- 252 reserved -
- 253 private [PRIVATE_DNS] see below OPTIONAL
- 254 private [PRIVATE_OID] see below OPTIONAL
- 255 reserved - -
-
+ The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify
+ the security algorithm being used. These values are stored in the
+ "Algorithm number" field in the resource record RDATA.
+
+ Some algorithms are usable only for zone signing (DNSSEC), some only
+ for transaction security mechanisms (SIG(0) and TSIG), and some for
+ both. Those usable for zone signing may appear in DNSKEY, RRSIG, and
+ DS RRs. Those usable for transaction security would be present in
+ SIG(0) and KEY RRs as described in [RFC2931]
+
+ Zone
+ Value Algorithm [Mnemonic] Signing References Status
+ ----- -------------------- --------- ---------- ---------
+ 0 reserved
+ 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED
+ 2 Diffie-Hellman [DH] n RFC 2539 -
+ 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL
+ 4 Elliptic Curve [ECC] TBA -
+ 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY
+ 252 Indirect [INDIRECT] n -
+ 253 Private [PRIVATEDNS] y see below OPTIONAL
+ 254 Private [PRIVATEOID] y see below OPTIONAL
+ 255 reserved
+
+ 6 - 251 Available for assignment by IETF Standards Action.
A.1.1 Private Algorithm Types
Algorithm number 253 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY
RR and the signature area in the RRSIG RR begin with a wire encoded
- domain name, which MUST NOT be compressed. The domain name indicates
- the private algorithm to use and the remainder of the public key area
- is determined by that algorithm. Entities should only use domain
- names they control to designate their private algorithms.
-
-Arends, et al. Expires April 26, 2004 [Page 31]
+Arends, et al. Expires June 16, 2004 [Page 32]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
+
+ domain name, which MUST NOT be compressed. The domain name indicates
+ the private algorithm to use and the remainder of the public key area
+ is determined by that algorithm. Entities should only use domain
+ names they control to designate their private algorithms.
Algorithm number 254 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY
-
-
-
-
-
-Arends, et al. Expires April 26, 2004 [Page 32]
+Arends, et al. Expires June 16, 2004 [Page 33]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
Appendix B. Key Tag Calculation
-Arends, et al. Expires April 26, 2004 [Page 33]
+Arends, et al. Expires June 16, 2004 [Page 34]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
*/
-Arends, et al. Expires April 26, 2004 [Page 34]
+Arends, et al. Expires June 16, 2004 [Page 35]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
Intellectual Property Statement
-Arends, et al. Expires April 26, 2004 [Page 35]
+Arends, et al. Expires June 16, 2004 [Page 36]
\f
-Internet-Draft DNSSEC Resource Records October 2003
+Internet-Draft DNSSEC Resource Records December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-Arends, et al. Expires April 26, 2004 [Page 36]
+Arends, et al. Expires June 16, 2004 [Page 37]
\f
+
-
DNS Extensions O. Kolkman
Internet-Draft RIPE NCC
-Expires: March 1, 2004 J. Schlyter
+Expires: June 17, 2004 J. Schlyter
E. Lewis
ARIN
- September 2003
+ December 18, 2003
DNSKEY RR Secure Entry Point Flag
- draft-ietf-dnsext-keyrr-key-signing-flag-11
+ draft-ietf-dnsext-keyrr-key-signing-flag-12
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on March 1, 2004.
+ This Internet-Draft will expire on June 17, 2004.
Copyright Notice
-Kolkman, et al. Expires March 1, 2004 [Page 1]
+Kolkman, et al. Expires June 17, 2004 [Page 1]
\f
-Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
be used in the DNS verification protocol. This document updates RFC
-Kolkman, et al. Expires March 1, 2004 [Page 2]
+Kolkman, et al. Expires June 17, 2004 [Page 2]
\f
-Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
1. Introduction
-Kolkman, et al. Expires March 1, 2004 [Page 3]
+Kolkman, et al. Expires June 17, 2004 [Page 3]
\f
-Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
An administrator has configured a DNSKEY as root for a trusted
-Kolkman, et al. Expires March 1, 2004 [Page 4]
+Kolkman, et al. Expires June 17, 2004 [Page 4]
\f
-Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
- This document assigns the 15'th bit [4] in the flags field as the
- secure entry point (SEP) bit. If the the bit is set to 1 the key is
+ This document assigns the 15'th bit in the flags field as the secure
+ entry point (SEP) bit. If the the bit is set to 1 the key is
intended to be used as secure entry point key. One SHOULD NOT assign
special meaning to the key if the bit is set to 0. Operators can
recognize the secure entry point key by the even or odd-ness of the
-Kolkman, et al. Expires March 1, 2004 [Page 5]
+Kolkman, et al. Expires June 17, 2004 [Page 5]
\f
-Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
Using the SEP flag a key roll over can be automated. The parent can
6. IANA Considerations
- IANA considerations: The flag bits in the DNSKEY RR are assigned by
- IETF consensus. This document assigns the 15th bit in the DNSKEY RR
- as the Secure Entry Point (SEP) bit. [Final text pending
- clarification of the DNSKEY flag registry]
+ The flag bits in the DNSKEY RR are assigned by IETF consensus and
+ registered in the DNSKEY Flags registry (created by [4]). This
+ document assigns the 15th bit in the DNSKEY RR as the Secure Entry
+ Point (SEP) bit.
7. Internationalization Considerations
-Kolkman, et al. Expires March 1, 2004 [Page 6]
+Kolkman, et al. Expires June 17, 2004 [Page 6]
\f
-Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
This document saw the light during a workshop on DNSSEC operations
[3] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
- [4] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
- Record (RR)", RFC 3445, December 2002.
+ [4] Weiler, S., "Legacy Resolver Compatibility for Delegation
+ Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
+ in progress), October 2003.
Informative References
-
-Kolkman, et al. Expires March 1, 2004 [Page 7]
+Kolkman, et al. Expires June 17, 2004 [Page 7]
\f
-Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
Edward P. Lewis
-Kolkman, et al. Expires March 1, 2004 [Page 8]
+Kolkman, et al. Expires June 17, 2004 [Page 8]
\f
-Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
Intellectual Property Statement
-Kolkman, et al. Expires March 1, 2004 [Page 9]
+Kolkman, et al. Expires June 17, 2004 [Page 9]
\f
-Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-Kolkman, et al. Expires March 1, 2004 [Page 10]
+Kolkman, et al. Expires June 17, 2004 [Page 10]
\f
+
DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler
-<draft-ietf-dnsext-mdns-26.txt> Microsoft
-11 December 2003
+<draft-ietf-dnsext-mdns-27.txt> Microsoft
+17 December 2003
Linklocal Multicast Name Resolution (LLMNR)
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
Table of Contents
1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
+ 1.1 Requirements .................................... 3
1.2 Terminology ..................................... 4
2. Name resolution using LLMNR ........................... 4
2.1 Sender behavior ................................. 5
2.2 Responder behavior .............................. 6
2.3 Unicast queries ................................. 7
- 2.4 Addressing ...................................... 8
- 2.5 Off-link detection .............................. 8
- 2.6 Retransmissions ................................. 9
+ 2.4 Off-link detection .............................. 8
+ 2.5 Responder responsibility ........................ 9
+ 2.6 Retransmissions ................................. 10
2.7 DNS TTL ......................................... 10
- 2.8 Use of the authority and additional sections .... 10
+ 2.8 Use of the authority and additional sections .... 11
3. Usage model ........................................... 11
- 3.1 Responder responsibility ....................... 11
- 3.2 LLMNR configuration ............................. 12
+ 3.1 LLMNR configuration ............................. 12
4. Conflict resolution ................................... 13
4.1 Considerations for multiple interfaces .......... 15
4.2 API issues ...................................... 16
+
Esibov, Aboba & Thaler Standards Track [Page 2]
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
1. Introduction
operates on the local link, it cannot be considered a substitute for
DNS.
-LLMNR queries are sent to and received on port TBD. Link-scope
-multicast addresses are used to prevent propagation of LLMNR traffic
-across routers, potentially flooding the network; for details, see
-Section 2.4. LLMNR queries can also be sent to a unicast address, as
-described in Section 2.3.
+Link-scope multicast addresses are used to prevent propagation of LLMNR
+traffic across routers, potentially flooding the network. LLMNR queries
+can also be sent to a unicast address, as described in Section 2.3.
Propagation of LLMNR packets on the local link is considered sufficient
to enable name resolution in small networks. The assumption is that if
a network has a gateway, then the network is able to provide DNS server
-configuration. Configuration issues are discussed in Section 3.2.
+configuration. Configuration issues are discussed in Section 3.1.
In the future, it may be desirable to consider use of multicast name
resolution with multicast scopes beyond the link-scope. This could
LLMNR in particular, is outside of the scope of this document, as is
name resolution over non-multicast capable media.
+1.1. Requirements
-
-
+In this document, several words are used to signify the requirements of
+the specification. These words are often capitalized. The key words
+"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
-1.1. Requirements
-
-In this document, several words are used to signify the requirements of
-the specification. These words are often capitalized. 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].
This document assumes familiarity with DNS terminology defined in
[RFC1035]. Other terminology used in this document includes:
-Owner A host is said to be the owner of a Resource Record (RR) if it
- is configured to respond to an LLMNR query for that RR.
-
Routable address
An address other than a Link-Local address. This includes
globally routable addresses, as well as private addresses.
2. Name resolution using LLMNR
LLMNR is a peer-to-peer name resolution protocol that is not intended as
-a replacement for DNS. This document does not specify how names are
-chosen or configured. This may occur via any mechanism, including
-DHCPv4 [RFC2131] or DHCPv6 [RFC3315].
+a replacement for DNS. LLMNR queries are sent to and received on port
+TBD. IPv4 administratively scoped multicast usage is specified in
+"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope
+multicast address a given responder listens to, and to which a sender
+sends queries, is TBD. The IPv6 link-scope multicast address a given
+responder listens to, and to which a sender sends all queries, is TBD.
Typically a host is configured as both an LLMNR sender and a responder.
A host MAY be configured as a sender, but not a responder. However, a
host configured as a responder MUST act as a sender to verify the
-uniqueness of names as described in Section 4.
+uniqueness of names as described in Section 4. This document does not
+specify how names are chosen or configured. This may occur via any
+mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315].
LLMNR usage MAY be configured manually or automatically on a per
interface basis. By default, LLMNR responders SHOULD be enabled on all
LLMNR requests SHOULD be sent only when one of the following conditions
are met:
-[1] No manual or automatic DNS configuration has been performed.
- If an interface has been configured with DNS server address(es),
- then LLMNR SHOULD NOT be used as the primary name resolution
+[1] No manual or automatic DNS configuration has been performed. If an
+ interface has been configured with DNS server address(es), then
+ LLMNR SHOULD NOT be used as the primary name resolution mechanism
+ on that interface, although it MAY be used as a name resolution
+ mechanism of last resort.
-Esibov, Aboba & Thaler Standards Track [Page 4]
+Esibov, Aboba & Thaler Standards Track [Page 4]
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
- mechanism on that interface, although it MAY be used as a name
- resolution mechanism of last resort.
-[2] DNS servers do not respond.
+[2] DNS servers do not respond.
-[3] DNS servers respond to a DNS query with RCODE=3
- (Authoritative Name Error) or RCODE=0, and an empty
- answer section.
+[3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name
+ Error) or RCODE=0, and an empty answer section.
A typical sequence of events for LLMNR usage is as follows:
-[1] DNS servers are not configured or do not respond to a
- DNS query, or respond with RCODE=3, or RCODE=0 and an
- empty answer section.
+[a] DNS servers are not configured or do not respond to a DNS query, or
+ respond with RCODE=3, or RCODE=0 and an empty answer section.
-[2] An LLMNR sender sends an LLMNR query to the link-scope multicast
- address(es) defined in Section 2.4, unless a unicast query is
- indicated. A sender SHOULD send LLMNR queries for PTR RRs
- via unicast, as specified in Section 2.3.
+[b] An LLMNR sender sends an LLMNR query to the link-scope multicast
+ address(es) defined in Section 2, unless a unicast query is
+ indicated. A sender SHOULD send LLMNR queries for PTR RRs via
+ unicast, as specified in Section 2.3.
-[3] A responder responds to this query only if it is authoritative
- for the domain name in the query. A responder responds to a
- multicast query by sending a unicast UDP response to the sender.
- Unicast queries are responded to as indicated in Section 2.3.
+[c] A responder responds to this query only if it is authoritative for
+ the domain name in the query. A responder responds to a multicast
+ query by sending a unicast UDP response to the sender. Unicast
+ queries are responded to as indicated in Section 2.3.
-[4] Upon the reception of the response, the sender performs the checks
- described in Section 2.5. If these conditions are met, then the
- sender uses and caches the returned response. If not, then the
- sender ignores the response and continues waiting for the response.
+[d] Upon reception of the response, the sender processes it.
Further details of sender and responder behavior are provided in the
sections that follow.
The sender MUST anticipate receiving no replies to some LLMNR queries,
in the event that no responders are available within the link-scope or
in the event no positive non-null responses exist for the transmitted
+query. If no positive response is received, a resolver treats it as a
+response that no records of the specified type and class exist for the
+specified name (it is treated the same as a response with RCODE=0 and an
+empty answer section).
+
+Since the responder may order the RRs in the response so as to indicate
+preference, the sender SHOULD preserve ordering in the response to the
+querying application.
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
-query. If no positive response is received, a resolver treats it as a
-response that no records of the specified type and class exist for the
-specified name (it is treated the same as a response with RCODE=0 and an
-empty answer section).
-
2.2. Responder behavior
A response to an LLMNR query is composed in exactly the same manner and
with the same packet format as a response to a DNS query as specified in
-[RFC1035].
+[RFC1035]. The response MUST be sent to the sender via unicast.
Upon configuring an IP address responders typically will synthesize
corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR
-queries for these RRs. However, in general whether RRs are manually or
+queries for these RRs. An SOA RR is synthesized only when a responder
+has another RR as well; the SOA RR MUST NOT be the only RR that a
+responder has. However, in general whether RRs are manually or
automatically created is an implementation decision.
-Responders MUST NOT respond using cached data, and the AA (Authoritative
-Answer) bit MUST be set. The response MUST be sent to the sender via
-unicast. If a responder receives a query with the header containing RD
-set bit, the responder MUST ignore the RD bit.
+In responding to queries:
-A responder MUST listen on UDP port TBD on the link-scope multicast
-address(es) defined in Section 2.4 and on UDP and TCP port TBD on the
-unicast address(es) that could be set as the source address(es) when the
-responder responds to the LLMNR query.
+[a] Responders MUST NOT respond using cached data, and the AA
+ (Authoritative Answer) bit MUST be set.
-Responders MUST NOT respond to LLMNR queries for names they are not
-authoritative for. Responders SHOULD respond to LLMNR queries for names
-and addresses they are authoritative for. This applies to both forward
-and reverse lookups.
+[b] If a responder receives a query with the header containing the RD
+ bit set, the responder MUST ignore the RD bit.
-A response to an LLMNR query MUST have RCODE set to zero. Responses
-with RCODE set to zero are referred to in this document as "positively
-resolved". LLMNR responders may respond only to queries which they can
-resolve positively. If a responder is authoritative for a name, it MAY
-respond with RCODE=0 and an empty answer section, if the type of query
-does not match a RR owned by the responder.
+[c] Responders MUST listen on UDP port TBD on the link-scope multicast
+ address(es) defined in Section 2, and on UDP and TCP port TBD on
+ the unicast address(es) that could be set as the source address(es)
+ when the responder responds to the LLMNR query.
-As an example, a host configured to respond to LLMNR queries for the
-name "foo.example.com." is authoritative for the name
-"foo.example.com.". On receiving an LLMNR query for an A RR with the
-name "foo.example.com." the host authoritatively responds with A RR(s)
-that contain IP address(es) in the RDATA of the resource record. If the
-responder owns a AAAA RR, but no A RR, and an A RR query is received,
-the responder would respond with RCODE=0 and an empty answer section.
+[d] Responders MUST NOT respond to LLMNR queries for names they are not
+ authoritative for.
+
+[e] A response to an LLMNR query MUST have RCODE set to zero.
+ Responses with RCODE set to zero are referred to in this document
+ as "positively resolved".
+
+[f] Responders MUST respond to LLMNR queries for names and addresses
+ they are authoritative for. This applies to both forward and
+ reverse lookups.
+
+[g] If a DNS server is running on a host that supports LLMNR, the DNS
+ server MUST respond to LLMNR queries only for the RRSets relating
+ to the host on which the server is running, but MUST NOT respond
+ for other records for which the server is authoritative. DNS
+ servers also MUST NOT send LLMNR queries in order to resolve DNS
+ queries.
+
+[h] If a responder is authoritative for a name, it MAY respond with
+ RCODE=0 and an empty answer section, if the type of query does not
+ match a RR that the responder has.
-If a DNS server is running on a host that supports LLMNR, the DNS server
-MUST respond to LLMNR queries only for the RRSets relating to the host
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
-on which the server is running, but MUST NOT respond for other records
-for which the server is authoritative. DNS servers also MUST NOT send
-LLMNR queries in order to resolve DNS queries they receive from DNS
-clients.
+As an example, a host configured to respond to LLMNR queries for the
+name "foo.example.com." is authoritative for the name
+"foo.example.com.". On receiving an LLMNR query for an A RR with the
+name "foo.example.com." the host authoritatively responds with A RR(s)
+that contain IP address(es) in the RDATA of the resource record. If the
+responder has a AAAA RR, but no A RR, and an A RR query is received, the
+responder would respond with RCODE=0 and an empty answer section.
In conventional DNS terminology a DNS server authoritative for a zone is
-authoritative for all the domain names under the zone root except for
+authoritative for all the domain names under the zone appex except for
the branches delegated into separate zones. Contrary to conventional
DNS terminology, an LLMNR responder is authoritative only for the zone
-root.
+appex.
For example the host "foo.example.com." is not authoritative for the
name "child.foo.example.com." unless the host is configured with
Unicast queries SHOULD be sent when:
- a. A sender repeats a query after it received a response
- with the TC bit set to the previous LLMNR multicast query, or
+[a] A sender repeats a query after it received a response with the TC
+ bit set to the previous LLMNR multicast query, or
+
+[b] The sender queries for a PTR RR of a fully formed IP address within
+ the "in-addr.arpa" or "ip6.arpa" zones.
- b. The sender queries for a PTR RR of a fully formed IP address
- within the "in-addr.arpa" or "ip6.arpa" zones.
-If a TC (truncation) bit is set in the response, then the sender MAY use
-the response if it contains all necessary information, or the sender MAY
-discard the response and resend the query over TCP using the unicast
-address of the responder. The RA (Recursion Available) bit in the
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
+If a TC (truncation) bit is set in the response, then the sender MAY use
+the response if it contains all necessary information, or the sender MAY
+discard the response and resend the query over TCP using the unicast
+address of the responder. The RA (Recursion Available) bit in the
header of the response MUST NOT be set. If the RA bit is set in the
response header, the sender MUST ignore the RA bit.
Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP
unicast LLMNR queries MUST be sent using TCP, using the same connection
-as the query. If the sender of a TCP query receives a response not
-using TCP, the response MUST be silently discarded.
+as the query. If the sender of a TCP query receives a response to that
+query not using TCP, the response MUST be silently discarded.
Unicast UDP queries MAY be responded to with a UDP response containing
an empty answer section and the TC bit set, so as to require the sender
to resend the query using TCP. Senders MUST support sending TCP
-queries, and Responders MUST support listening for TCP queries. The
-Responder SHOULD set the TTL or Hop Limit settings on the TCP listen
-socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop
-Limit (IPv6) set to one (1). This prevents an incoming connection from
-off-link since the Sender will not receive a SYN-ACK from the Responder.
+queries, and Responders MUST support listening for TCP queries.
If an ICMP "Time Exceeded" message is received in response to a unicast
UDP query, or if TCP connection setup cannot be completed in order to
cannot be made, then the sender relies on the retransmission and timeout
behavior described in Section 2.6.
-2.4. Addressing
-
-IPv4 administratively scoped multicast usage is specified in
-"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope
-multicast address a given responder listens to, and to which a sender
-sends queries, is TBD. The IPv6 link-scope multicast address a given
-responder listens to, and to which a sender sends all queries, is TBD.
-
-2.5. Off-link detection
+2.4. "Off link" detection
For IPv4, an "on link" address is defined as a link-local address
[IPv4Link] or an address whose prefix belongs to a subnet on the local
link". The destination address of an LLMNR query MUST be a link-scope
multicast address or an "on link" unicast address.
+A responder MUST select a source address for responses that is "on
+link". The destination address of an LLMNR response MUST be an "on link"
+unicast address.
+
+On receiving an LLMNR query, the responder MUST check whether it was
+sent to a LLMNR multicast addresses defined in Section 2. If it was
+sent to another multicast address, then the query MUST be silently
-Esibov, Aboba & Thaler Standards Track [Page 8]
+Esibov, Aboba & Thaler Standards Track [Page 8]
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
-A responder MUST select a source address for responses that is "on
-link". The destination address of an LLMNR response MUST be an "on link"
-unicast address.
-On receiving an LLMNR query, the responder MUST check whether it was
-sent to a LLMNR multicast addresses defined in Section 2.4. If it was
-sent to another multicast address, then the query MUST be silently
discarded.
-A sender SHOULD prefer RRs including reachable addresses where RRs
-involving both reachable and unreachable addresses are returned in
-response to a query.
-
In composing LLMNR queries, the sender MUST set the Hop Limit field in
the IPv6 header and the TTL field in IPv4 header of the response to one
(1). Even when LLMNR queries are sent to a link-scope multicast
the response to one (1). This is done so as to prevent the use of LLMNR
for denial of service attacks across the Internet.
+Section 2.3 discusses use of TCP for LLMNR queries and responses. The
+responder SHOULD set the TTL or Hop Limit settings on the TCP listen
+socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop
+Limit (IPv6) set to one (1). This prevents an incoming connection from
+off-link since the sender will not receive a SYN-ACK from the responder.
+
Implementation note:
In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL
recvmsg(). [RFC2292] specifies similar options for setting and
retrieving the IPv6 Hop Limit.
-2.6. Retransmissions
+2.5. Responder responsibilities
-In order to avoid synchronization, LLMNR queries and responses are
-delayed by a time randomly selected from the interval 0 to 200 ms.
+It is the responsibility of the responder to ensure that RRs returned in
+LLMNR responses MUST only include values that are valid on the local
+interface, such as IPv4 or IPv6 addresses valid on the local link or
+names defended using the mechanism described in Section 4. In
+particular:
-If an LLMNR query sent over UDP is not resolved within the timeout
-interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of
-the query in order to assure that it was received by a host capable of
-responding to it. Retransmission of UDP queries SHOULD NOT be attempted
-more than 3 times. Where LLMNR queries are sent using TCP,
-retransmission is handled by the transport layer.
+[a] If a link-scope IPv6 address is returned in a AAAA RR, that address
+ MUST be valid on the local link over which LLMNR is used.
+
+[b] If an IPv4 address is returned, it MUST be reachable through the
+ link over which LLMNR is used.
+
+[c] If a name is returned (for example in a CNAME, MX or SRV RR), the
+ name MUST be resolvable on the local link over which LLMNR is used.
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
+
+Routable addresses MUST be included first in the response, if available.
+This encourages use of routable address(es) for establishment of new
+connections.
+
+2.6. Retransmissions
+
+In order to avoid synchronization, LLMNR queries and responses are
+delayed by a time randomly selected from the interval 0 to 200 ms.
+
+If an LLMNR query sent over UDP is not resolved within the timeout
+interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of
+the query in order to assure that it was received by a host capable of
+responding to it. Retransmission of UDP queries SHOULD NOT be attempted
+more than 3 times. Where LLMNR queries are sent using TCP,
+retransmission is handled by the transport layer.
Since a multicast query sender cannot know beforehand whether it will
receive no response, one response, or more than one response, it SHOULD
2.7. DNS TTL
The responder should use a pre-configured TTL value in the records
-returned in the LLMNR query response. A default value of 0 is
-recommended in highly dynamic environments (such as mobile ad-hoc
-networks). In less dynamic environments, LLMNR traffic can be reduced
-by setting the TTL to a higher value.
+returned in the LLMNR query response. A default value of 30 seconds is
+RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
+networks), the TTL value may need to be reduced.
Due to the TTL minimalization necessary when caching an RRset, all TTLs
in an RRset MUST be set to the same value.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 10]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 December 2003
+
+
2.8. Use of the authority and additional sections
Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
concept of delegation. In LLMNR, the NS resource record type may be
stored and queried for like any other type, but it has no special
-delegation semantics as it does in the DNS. Responders MAY own NS
+delegation semantics as it does in the DNS. Responders MAY have NS
records associated with the names for which they are authoritative, but
they SHOULD NOT include these NS records in the authority sections of
responses.
Responders SHOULD NOT perform DNS additional section processing.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 11 December 2003
-
-
Senders MUST NOT cache RRs from the authority or additional section of a
response as answers, though they may be used for other purposes such as
negative caching.
when they don't receive a response to a query. These policies are
likely to avoid unnecessary LLMNR queries.
-[RFC1536] Section 3 describes zero answer bugs, which if addressed will
-also reduce unnecessary LLMNR queries.
-
-[RFC1536] Section 6 describes name error bugs and recommended searchlist
-processing that will reduce unnecessary RCODE=3 (authoritative name)
-errors, thereby also reducing unnecessary LLMNR queries.
-
-3.1. Responder responsibilities
-
-It is the responsibility of the responder to ensure that RRs returned in
-LLMNR responses MUST only include values that are valid on the local
-interface, such as IPv4 or IPv6 addresses valid on the local link or
-names defended using the mechanism described in Section 4. In
-particular:
-
-[1] If a link-scope IPv6 address is returned in a AAAA RR, that
- address MUST be valid on the local link over which LLMNR is
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
- used.
-
-[2] If an IPv4 address is returned, it MUST be reachable through
- the link over which LLMNR is used.
-
-[3] If a name is returned (for example in a CNAME, MX
- or SRV RR), the name MUST be valid on the local interface.
+[RFC1536] Section 3 describes zero answer bugs, which if addressed will
+also reduce unnecessary LLMNR queries.
-Routable addresses MUST be included first in the response, if available.
-This encourages use of routable address(es) for establishment of new
-connections.
+[RFC1536] Section 6 describes name error bugs and recommended searchlist
+processing that will reduce unnecessary RCODE=3 (authoritative name)
+errors, thereby also reducing unnecessary LLMNR queries.
-3.2. LLMNR configuration
+3.1. LLMNR configuration
Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
possible for a dual stack host to be configured with the address of a
resolved over IPv4 without LLMNR. However, if no DNS server is
authoritative for the names of local hosts, or the authoritative DNS
server(s) do not support dynamic update, then LLMNR enables linklocal
+name resolution over IPv4.
+Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
+configure LLMNR on an interface. The LLMNR Enable Option, described in
+[LLMNREnable], can be used to explicitly enable or disable use of LLMNR
-Esibov, Aboba & Thaler Standards Track [Page 12]
+Esibov, Aboba & Thaler Standards Track [Page 12]
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
-name resolution over IPv4.
-Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-configure LLMNR on an interface. The LLMNR Enable Option, described in
-[LLMNREnable], can be used to explicitly enable or disable use of LLMNR
on an interface. The LLMNR Enable Option does not determine whether or
in which order DNS itself is used for name resolution. The order in
which various name resolution mechanisms should be used can be specified
linklocal name resolution, this represents an unnecessary degradation in
capabilities. As a result, it is recommended that hosts without a
configured DNS server periodically attempt to obtain DNS configuration.
-A default retry interval of one (1) minute is RECOMMENDED.
+For example, where DHCP is used for DNS configuration, [RFC2131]
+recommends a maximum retry interval of 64 seconds. In the absence of
+other guidance, a default retry interval of one (1) minute is
+RECOMMENDED.
4. Conflict resolution
- multiple hosts may respond to a query for an SRV type record
- multiple hosts may respond to a query for an A or AAAA type
record for a cluster name (assigned to multiple hosts in
+ the cluster)
+ - only a single host may respond to a query for an A or AAAA
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
- the cluster)
- - only a single host may respond to a query for an A or AAAA
type record for a name.
Every responder that responds to an LLMNR query AND includes a UNIQUE
record in the response:
- 1. MUST verify that there is no other host within the scope of the
- LLMNR query propagation that can return a resource record
- for the same name, type and class.
- 2. MUST NOT include a UNIQUE resource record in the
- response without having verified its uniqueness.
+[1] MUST verify that there is no other host within the scope of the
+ LLMNR query propagation that can return a resource record for the
+ same name, type and class.
+
+[2] MUST NOT include a UNIQUE resource record in the response without
+ having verified its uniqueness.
Where a host is configured to issue LLMNR queries on more than one
interface, each interface should have its own independent LLMNR cache.
- is configured to respond to the LLMNR queries using additional
UNIQUE resource records
-When a host that owns a UNIQUE record receives an LLMNR query for that
+When a host that has a UNIQUE record receives an LLMNR query for that
record, the host MUST respond. After the client receives a response, it
MUST check whether the response arrived on an interface different from
the one on which the query was sent. If the response arrives on a
When name conflicts are detected, they SHOULD be logged. To detect
duplicate use of a name, an administrator can use a name resolution
+utility which employs LLMNR and lists both responses and responders.
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
-utility which employs LLMNR and lists both responses and responders.
This would allow an administrator to diagnose behavior and potentially
to intervene and reconfigure LLMNR responders who should not be
configured to respond to the same name.
+
Esibov, Aboba & Thaler Standards Track [Page 15]
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
Host myhost cannot distinguish between the situation shown in Figure 2,
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
In order to address the security vulnerabilities, the following
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
be present on the same link. These threats are most serious in wireless
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
decreases reliance on it.
This specification does not create any new name spaces for IANA
administration. LLMNR requires allocation of a port TBD for both TCP
and UDP. Assignment of the same port for both transports is requested.
-LLMNR requires allocation of a link-scope multicast IPv4 address as well
-as a link-scope multicast IPv6 address TBD.
+
+LLMNR requires allocation of a link-scope multicast IPv4 address TBD.
+LLMNR also requires allocation of a link-scope multicast IPv6 address
+TBD.
7. References
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 1998.
+
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
+[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October
+ 1998.
+
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPV4Link]
Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of IPv4 Link-Local Addresses", Internet draft (work in
- progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October
- 2003.
-
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
+ of IPv4 Link-Local Addresses", Internet draft (work in
+ progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October
+ 2003.
+
[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 6, December
EMail: bernarda@microsoft.com
Dave Thaler
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
+Microsoft Corporation
+One Microsoft Way
+Redmond, WA 98052
+
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-INTERNET-DRAFT LLMNR 11 December 2003
+INTERNET-DRAFT LLMNR 17 December 2003
+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.
+
Open Issues
Open issues with this specification are tracked on the following web
Expiration Date
-This memo is filed as <draft-ietf-dnsext-mdns-26.txt>, and expires
+This memo is filed as <draft-ietf-dnsext-mdns-27.txt>, and expires
June 22, 2004.
-
-
-
-
projects / thirdparty / bind9.git / commitdiff
