mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-29 13:38:26 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews 2003-12-18 21:01:57 +00:00
parent de0c09be9c
commit 18fff72430
5 changed files with 1664 additions and 1437 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

351
doc/draft/draft-ietf-dnsext-dnssec-intro-07.txt → doc/draft/draft-ietf-dnsext-dnssec-intro-08.txt
View File

@ -2,7 +2,7 @@
DNS Extensions R. Arends
Internet-Draft Telematica Instituut
Expires: April 26, 2004 R. Austein
Expires: June 16, 2004 R. Austein
ISC
M. Larson
VeriSign
@ -10,11 +10,11 @@ Expires: April 26, 2004 R. Austein
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
@ -36,7 +36,7 @@ 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
@ -52,9 +52,9 @@ Abstract
Arends, et al. Expires April 26, 2004 [Page 1]
Arends, et al. Expires June 16, 2004 [Page 1]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
Last, this document describes the interrelationships between the
@ -83,7 +83,7 @@ Table of Contents
Normative References . . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 25
@ -108,9 +108,9 @@ Table of Contents
Arends, et al. Expires April 26, 2004 [Page 2]
Arends, et al. Expires June 16, 2004 [Page 2]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
1. Introduction
@ -136,7 +136,10 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
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
@ -161,18 +164,21 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 3]
Arends, et al. Expires June 16, 2004 [Page 3]
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
@ -183,9 +189,10 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
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
@ -202,35 +209,42 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
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.
parent. That is, there is no DS RR with the island's public key
Arends, et al. Expires June 16, 2004 [Page 4]
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
Arends, et al. Expires April 26, 2004 [Page 4]
Internet-Draft DNSSEC Introduction and Requirements October 2003
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
@ -259,6 +273,14 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
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]
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
@ -273,14 +295,6 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
own DNSSEC signature validity checks, while a security-aware stub
resolver does not, by definition.
Arends, et al. Expires April 26, 2004 [Page 5]
Internet-Draft DNSSEC Introduction and Requirements October 2003
security-oblivious (server or resolver): The opposite of
"security-aware".
@ -295,6 +309,7 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
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.
@ -317,24 +332,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 6]
Arends, et al. Expires June 16, 2004 [Page 6]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
3. Services Provided by DNS Security
@ -388,9 +388,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 7]
Arends, et al. Expires June 16, 2004 [Page 7]
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.
@ -444,9 +444,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 8]
Arends, et al. Expires June 16, 2004 [Page 8]
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
@ -500,9 +500,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 9]
Arends, et al. Expires June 16, 2004 [Page 9]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
4. Services Not Provided by DNS Security
@ -556,9 +556,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 10]
Arends, et al. Expires June 16, 2004 [Page 10]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
5. Resolver Considerations
@ -596,12 +596,11 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
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.
@ -612,9 +611,10 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 11]
Arends, et al. Expires June 16, 2004 [Page 11]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
6. Stub Resolver Considerations
@ -633,16 +633,17 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
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
@ -667,10 +668,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 12]
Arends, et al. Expires June 16, 2004 [Page 12]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
7. Zone Considerations
@ -724,9 +724,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 13]
Arends, et al. Expires June 16, 2004 [Page 13]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
8. Name Server Considerations
@ -747,7 +747,7 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
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
@ -780,9 +780,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 14]
Arends, et al. Expires June 16, 2004 [Page 14]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
9. DNS Security Document Family
@ -836,9 +836,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 15]
Arends, et al. Expires June 16, 2004 [Page 15]
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
@ -892,9 +892,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 16]
Arends, et al. Expires June 16, 2004 [Page 16]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
10. IANA Considerations
@ -948,9 +948,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 17]
Arends, et al. Expires June 16, 2004 [Page 17]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
11. Security Considerations
@ -1004,9 +1004,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 18]
Arends, et al. Expires June 16, 2004 [Page 18]
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
@ -1025,6 +1025,10 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
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.
@ -1035,6 +1039,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
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.
@ -1053,26 +1060,31 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 19]
Arends, et al. Expires June 16, 2004 [Page 19]
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.
@ -1104,21 +1116,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003
Arends, et al. Expires April 26, 2004 [Page 20]
Arends, et al. Expires June 16, 2004 [Page 20]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
Normative References
@ -1172,13 +1172,23 @@ Normative References
Arends, et al. Expires April 26, 2004 [Page 21]
Arends, et al. Expires June 16, 2004 [Page 21]
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.
@ -1198,6 +1208,9 @@ Informative References
[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
@ -1213,6 +1226,13 @@ Informative References
draft-ietf-dnsext-delegation-signer-15 (work in progress),
June 2003.
Arends, et al. Expires June 16, 2004 [Page 22]
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
@ -1225,14 +1245,6 @@ Informative References
progress), October 2003.
Arends, et al. Expires April 26, 2004 [Page 22]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Authors' Addresses
Roy Arends
@ -1271,6 +1283,12 @@ Authors' Addresses
EMail: masseyd@isi.edu
Arends, et al. Expires June 16, 2004 [Page 23]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
@ -1284,9 +1302,47 @@ Authors' Addresses
Arends, et al. Expires April 26, 2004 [Page 23]
Arends, et al. Expires June 16, 2004 [Page 24]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Internet-Draft DNSSEC Introduction and Requirements December 2003
Intellectual Property Statement
@ -1340,9 +1396,9 @@ Full Copyright Statement
Arends, et al. Expires April 26, 2004 [Page 24]
Arends, et al. Expires June 16, 2004 [Page 25]
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
@ -1396,5 +1452,6 @@ Acknowledgement
Arends, et al. Expires April 26, 2004 [Page 25]
Arends, et al. Expires June 16, 2004 [Page 26]

1591
doc/draft/draft-ietf-dnsext-dnssec-protocol-03.txt → doc/draft/draft-ietf-dnsext-dnssec-protocol-04.txt
View File

File diff suppressed because it is too large Load Diff

599
doc/draft/draft-ietf-dnsext-dnssec-records-05.txt → doc/draft/draft-ietf-dnsext-dnssec-records-06.txt
View File

@ -2,7 +2,7 @@
DNS Extensions R. Arends
Internet-Draft Telematica Instituut
Expires: April 26, 2004 R. Austein
Expires: June 16, 2004 R. Austein
ISC
M. Larson
VeriSign
@ -10,11 +10,11 @@ Expires: April 26, 2004 R. Austein
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
@ -36,7 +36,7 @@ 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
@ -52,9 +52,9 @@ Abstract
Arends, et al. Expires April 26, 2004 [Page 1]
Arends, et al. Expires June 16, 2004 [Page 1]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
signature (RRSIG), and authenticated denial of existence (NSEC)
@ -90,51 +90,51 @@ Table of Contents
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]
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
@ -164,9 +164,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 3]
Arends, et al. Expires June 16, 2004 [Page 3]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
1. Introduction
@ -220,9 +220,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 4]
Arends, et al. Expires June 16, 2004 [Page 4]
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
@ -276,9 +276,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 5]
Arends, et al. Expires June 16, 2004 [Page 5]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
2. The DNSKEY Resource Record
@ -332,9 +332,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 6]
Arends, et al. Expires June 16, 2004 [Page 6]
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
@ -388,9 +388,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 7]
Arends, et al. Expires June 16, 2004 [Page 7]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
2.3 DNSKEY RR Example
@ -444,9 +444,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 8]
Arends, et al. Expires June 16, 2004 [Page 8]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
3. The RRSIG Resource Record
@ -466,6 +466,14 @@ Internet-Draft DNSSEC Resource Records October 2003
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.
@ -473,7 +481,10 @@ Internet-Draft DNSSEC Resource Records October 2003
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
@ -486,6 +497,14 @@ Internet-Draft DNSSEC Resource Records October 2003
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]
Internet-Draft DNSSEC Resource Records December 2003
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
@ -497,14 +516,6 @@ Internet-Draft DNSSEC Resource Records October 2003
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
Arends, et al. Expires April 26, 2004 [Page 9]
Internet-Draft DNSSEC Resource Records October 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
@ -542,6 +553,14 @@ Internet-Draft DNSSEC Resource Records October 2003
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]
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."
@ -552,15 +571,6 @@ Internet-Draft DNSSEC Resource Records October 2003
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]
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
@ -598,6 +608,15 @@ Internet-Draft DNSSEC Resource Records October 2003
validates this signature. Appendix B explains how to calculate Key
Tag values.
Arends, et al. Expires June 16, 2004 [Page 11]
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
@ -608,15 +627,6 @@ Internet-Draft DNSSEC Resource Records October 2003
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]
Internet-Draft DNSSEC Resource Records October 2003
3.1.8 The Signature Field
The Signature field contains the cryptographic signature which covers
@ -655,6 +665,14 @@ Internet-Draft DNSSEC Resource Records October 2003
Each RR in the RRset MUST have the TTL listed in the
RRSIG Original TTL Field;
Arends, et al. Expires June 16, 2004 [Page 12]
Internet-Draft DNSSEC Resource Records December 2003
Any DNS names in the RDATA field of each RR MUST be in
canonical form; and
@ -665,14 +683,6 @@ Internet-Draft DNSSEC Resource Records October 2003
The presentation format of the RDATA portion is as follows:
Arends, et al. Expires April 26, 2004 [Page 12]
Internet-Draft DNSSEC Resource Records October 2003
The Type Covered field value MUST be represented either as an
unsigned decimal integer or as the mnemonic for the covered RR type.
@ -711,6 +721,14 @@ Internet-Draft DNSSEC Resource Records October 2003
3.3 RRSIG RR Example
Arends, et al. Expires June 16, 2004 [Page 13]
Internet-Draft DNSSEC Resource Records December 2003
The following an RRSIG RR stores the signature for the A RRset of
host.example.com:
@ -722,13 +740,6 @@ Internet-Draft DNSSEC Resource Records October 2003
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
Arends, et al. Expires April 26, 2004 [Page 13]
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.
@ -769,20 +780,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 14]
Arends, et al. Expires June 16, 2004 [Page 14]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
4. The NSEC Resource Record
@ -796,6 +796,13 @@ Internet-Draft DNSSEC Resource Records October 2003
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.
@ -811,7 +818,7 @@ Internet-Draft DNSSEC Resource Records October 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Map /
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -826,54 +833,73 @@ Internet-Draft DNSSEC Resource Records October 2003
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]
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
Arends, et al. Expires April 26, 2004 [Page 15]
Internet-Draft DNSSEC Resource Records October 2003
4.1.2 The Type Bit Map Field
The Type Bit Map field identifies the RRset types which exist at the
The Type Bit Maps field identifies the RRset types which exist at the
NSEC RR's owner name.
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.
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.
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
where "|" denotes concatenation.
Each bitmap encodes the low-order 8 bits of RR types within the
window block, in network bit order. The first bit is bit 0. For
window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
to RR type 2 (NS), and so forth. For window block 1, bit 1
corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
1, it indicates that an RRset of that type is present for the 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.
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.
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.
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.
Arends, et al. Expires June 16, 2004 [Page 16]
Internet-Draft DNSSEC Resource Records December 2003
A zone MUST NOT generate an NSEC RR for any domain name that only
holds glue records.
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.
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.
4.1.3 Inclusion of Wildcard Names in NSEC RDATA
If a wildcard owner name appears in a zone, the wildcard label ("*")
@ -889,17 +915,9 @@ Internet-Draft DNSSEC Resource Records October 2003
The Next Domain Name field is represented as a domain name.
Arends, et al. Expires April 26, 2004 [Page 16]
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
@ -907,13 +925,33 @@ Internet-Draft DNSSEC Resource Records October 2003
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]
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
@ -948,9 +986,27 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 17]
Arends, et al. Expires June 16, 2004 [Page 18]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
5. The DS Resource Record
@ -958,11 +1014,11 @@ Internet-Draft DNSSEC Resource Records October 2003
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,
@ -1004,9 +1060,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 18]
Arends, et al. Expires June 16, 2004 [Page 19]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
5.1.1 The Key Tag Field
@ -1060,9 +1116,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 19]
Arends, et al. Expires June 16, 2004 [Page 20]
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
@ -1116,9 +1172,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 20]
Arends, et al. Expires June 16, 2004 [Page 21]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
6. Canonical Form and Order of Resource Records
@ -1172,9 +1228,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 21]
Arends, et al. Expires June 16, 2004 [Page 22]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
replaced by the corresponding lowercase US-ASCII letters;
@ -1203,6 +1259,15 @@ Internet-Draft DNSSEC Resource Records October 2003
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.
@ -1219,18 +1284,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 22]
Arends, et al. Expires June 16, 2004 [Page 23]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
7. IANA Considerations
@ -1252,22 +1308,17 @@ Internet-Draft DNSSEC Resource Records October 2003
(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
@ -1279,21 +1330,21 @@ Internet-Draft DNSSEC Resource Records October 2003
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]
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.
@ -1340,9 +1391,14 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 24]
Arends, et al. Expires June 16, 2004 [Page 25]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
8. Security Considerations
@ -1351,9 +1407,9 @@ Internet-Draft DNSSEC Resource Records October 2003
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
@ -1396,18 +1452,22 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 25]
Arends, et al. Expires June 16, 2004 [Page 26]
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.
@ -1448,13 +1508,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 26]
Arends, et al. Expires June 16, 2004 [Page 27]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
Normative References
@ -1508,9 +1564,9 @@ Normative References
Arends, et al. Expires April 26, 2004 [Page 27]
Arends, et al. Expires June 16, 2004 [Page 28]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
[I-D.ietf-dnsext-dnssec-intro]
@ -1564,9 +1620,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 28]
Arends, et al. Expires June 16, 2004 [Page 29]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
Informative References
@ -1620,9 +1676,9 @@ Authors' Addresses
Arends, et al. Expires April 26, 2004 [Page 29]
Arends, et al. Expires June 16, 2004 [Page 30]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
Scott Rose
@ -1676,9 +1732,9 @@ Internet-Draft DNSSEC Resource Records October 2003
Arends, et al. Expires April 26, 2004 [Page 30]
Arends, et al. Expires June 16, 2004 [Page 31]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
Appendix A. DNSSEC Algorithm and Digest Types
@ -1698,45 +1754,50 @@ 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:
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.
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 - -
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
Arends, et al. Expires June 16, 2004 [Page 32]
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.
Arends, et al. Expires April 26, 2004 [Page 31]
Internet-Draft DNSSEC Resource Records October 2003
Algorithm number 254 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 an unsigned
@ -1783,14 +1844,9 @@ A.2 DNSSEC Digest Types
Arends, et al. Expires April 26, 2004 [Page 32]
Arends, et al. Expires June 16, 2004 [Page 33]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
Appendix B. Key Tag Calculation
@ -1844,9 +1900,9 @@ Appendix B. Key Tag Calculation
Arends, et al. Expires April 26, 2004 [Page 33]
Arends, et al. Expires June 16, 2004 [Page 34]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
*/
@ -1900,9 +1956,9 @@ B.1 Key Tag for Algorithm 1 (RSA/MD5)
Arends, et al. Expires April 26, 2004 [Page 34]
Arends, et al. Expires June 16, 2004 [Page 35]
Internet-Draft DNSSEC Resource Records October 2003
Internet-Draft DNSSEC Resource Records December 2003
Intellectual Property Statement
@ -1956,9 +2012,9 @@ Full Copyright Statement
Arends, et al. Expires April 26, 2004 [Page 35]
Arends, et al. Expires June 16, 2004 [Page 36]
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
@ -2012,5 +2068,6 @@ Acknowledgement
Arends, et al. Expires April 26, 2004 [Page 36]
Arends, et al. Expires June 16, 2004 [Page 37]

66
doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt → doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
View File

@ -1,16 +1,15 @@
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
@ -32,7 +31,7 @@ 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
@ -52,9 +51,9 @@ Abstract
Kolkman, et al. Expires March 1, 2004 [Page 1]
Kolkman, et al. Expires June 17, 2004 [Page 1]
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
@ -108,9 +107,9 @@ Table of Contents
Kolkman, et al. Expires March 1, 2004 [Page 2]
Kolkman, et al. Expires June 17, 2004 [Page 2]
Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
1. Introduction
@ -164,9 +163,9 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
Kolkman, et al. Expires March 1, 2004 [Page 3]
Kolkman, et al. Expires June 17, 2004 [Page 3]
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
@ -220,13 +219,13 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
Kolkman, et al. Expires March 1, 2004 [Page 4]
Kolkman, et al. Expires June 17, 2004 [Page 4]
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
@ -276,9 +275,9 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
Kolkman, et al. Expires March 1, 2004 [Page 5]
Kolkman, et al. Expires June 17, 2004 [Page 5]
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
@ -311,10 +310,10 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
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
@ -332,9 +331,9 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
Kolkman, et al. Expires March 1, 2004 [Page 6]
Kolkman, et al. Expires June 17, 2004 [Page 6]
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
@ -351,8 +350,9 @@ Normative References
[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
@ -387,10 +387,9 @@ Authors' Addresses
Kolkman, et al. Expires March 1, 2004 [Page 7]
Kolkman, et al. Expires June 17, 2004 [Page 7]
Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
Edward P. Lewis
@ -444,9 +443,9 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
Kolkman, et al. Expires March 1, 2004 [Page 8]
Kolkman, et al. Expires June 17, 2004 [Page 8]
Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
Intellectual Property Statement
@ -500,9 +499,9 @@ Full Copyright Statement
Kolkman, et al. Expires March 1, 2004 [Page 9]
Kolkman, et al. Expires June 17, 2004 [Page 9]
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
@ -556,5 +555,6 @@ Acknowledgment
Kolkman, et al. Expires March 1, 2004 [Page 10]
Kolkman, et al. Expires June 17, 2004 [Page 10]

490
doc/draft/draft-ietf-dnsext-mdns-26.txt → doc/draft/draft-ietf-dnsext-mdns-27.txt
View File

@ -3,8 +3,8 @@
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)
@ -57,26 +57,25 @@ Esibov, Aboba & Thaler Standards Track [Page 1]
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
@ -111,13 +110,14 @@ Full Copyright Statement ..................................... 22
Esibov, Aboba & Thaler Standards Track [Page 2]
INTERNET-DRAFT LLMNR 11 December 2003
INTERNET-DRAFT LLMNR 17 December 2003
1. Introduction
@ -136,16 +136,14 @@ they respond with errors, as described in Section 2. Since LLMNR only
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
@ -165,9 +163,11 @@ Service discovery in general, as well as discovery of DNS servers using
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
@ -177,14 +177,9 @@ Esibov, Aboba & Thaler Standards Track [Page 3]
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].
@ -193,9 +188,6 @@ 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.
@ -208,14 +200,19 @@ Sender A host that sends an LLMNR query.
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
@ -225,9 +222,12 @@ An LLMNR sender may send a request for any name. However, by default,
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.
@ -237,38 +237,30 @@ 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.
[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.
@ -288,6 +280,14 @@ be sent.
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.
@ -297,57 +297,57 @@ Esibov, Aboba & Thaler Standards Track [Page 5]
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
@ -357,19 +357,22 @@ Esibov, Aboba & Thaler Standards Track [Page 6]
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
@ -398,16 +401,13 @@ lightweight hosts.
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
@ -417,25 +417,25 @@ Esibov, Aboba & Thaler Standards Track [Page 7]
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
@ -449,15 +449,7 @@ guard against a potential Denial of Service (DoS) attack. If a match
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
@ -469,6 +461,14 @@ A sender MUST select a source address for LLMNR queries that is "on
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]
@ -477,22 +477,11 @@ 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
@ -507,6 +496,12 @@ Hop Limit field in the IPv6 header and the TTL field in IPv4 header of
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
@ -516,6 +511,39 @@ Implementation note:
recvmsg(). [RFC2292] specifies similar options for setting and
retrieving the IPv6 Hop Limit.
2.5. 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:
[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.
Esibov, Aboba & Thaler Standards Track [Page 9]
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
@ -528,18 +556,6 @@ 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.
Esibov, Aboba & Thaler Standards Track [Page 9]
INTERNET-DRAFT LLMNR 11 December 2003
Since a multicast query sender cannot know beforehand whether it will
receive no response, one response, or more than one response, it SHOULD
wait for LLMNR_TIMEOUT in order to collect all possible responses,
@ -563,30 +579,14 @@ Recommended values are an initial RTO of 1 second, a minimum RTO of
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.
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
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 insert an SOA record into the authority section of a
negative response, to facilitate negative caching as specified in
[RFC2308]. The owner name of this SOA record MUST be equal to the query
name.
Responders SHOULD NOT perform DNS additional section processing.
@ -597,9 +597,26 @@ Esibov, Aboba & Thaler Standards Track [Page 10]
INTERNET-DRAFT LLMNR 11 December 2003
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 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 insert an SOA record into the authority section of a
negative response, to facilitate negative caching as specified in
[RFC2308]. The owner name of this SOA record MUST be equal to the query
name.
Responders SHOULD NOT perform DNS additional section processing.
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.
@ -631,23 +648,6 @@ issues with failover, and recommends that resolvers try another server
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
@ -657,22 +657,17 @@ Esibov, Aboba & Thaler Standards Track [Page 11]
INTERNET-DRAFT LLMNR 11 December 2003
INTERNET-DRAFT LLMNR 17 December 2003
used.
[RFC1536] Section 3 describes zero answer bugs, which if addressed will
also reduce unnecessary LLMNR queries.
[2] If an IPv4 address is returned, it MUST be reachable through
the link over which LLMNR is used.
[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] If a name is returned (for example in a CNAME, MX
or SRV RR), the name MUST be valid on the local interface.
Routable addresses MUST be included first in the response, if available.
This encourages use of routable address(es) for establishment of new
connections.
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
@ -708,6 +703,11 @@ DHCPv4-based dynamic update, then the names of local IPv4 hosts can be
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
@ -717,14 +717,9 @@ 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
@ -747,7 +742,10 @@ LLMNR even once the outage is repaired. Since LLMNR only enables
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
@ -768,6 +766,8 @@ query and type of the query. For example it is expected that:
- 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
@ -777,21 +777,20 @@ Esibov, Aboba & Thaler Standards Track [Page 13]
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.
@ -810,7 +809,7 @@ UNIQUE. Uniqueness verification is carried out when the host:
- 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
@ -828,6 +827,7 @@ uniqueness.
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.
@ -837,10 +837,9 @@ Esibov, Aboba & Thaler Standards Track [Page 14]
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.
@ -891,13 +890,14 @@ both interfaces.
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,
@ -957,7 +957,7 @@ Esibov, Aboba & Thaler Standards Track [Page 16]
INTERNET-DRAFT LLMNR 11 December 2003
INTERNET-DRAFT LLMNR 17 December 2003
In order to address the security vulnerabilities, the following
@ -1017,7 +1017,7 @@ Esibov, Aboba & Thaler Standards Track [Page 17]
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
@ -1077,7 +1077,7 @@ Esibov, Aboba & Thaler Standards Track [Page 18]
INTERNET-DRAFT LLMNR 11 December 2003
INTERNET-DRAFT LLMNR 17 December 2003
decreases reliance on it.
@ -1100,8 +1100,10 @@ hosts.
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
@ -1125,9 +1127,7 @@ as a link-scope multicast IPv6 address TBD.
[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.
@ -1137,9 +1137,13 @@ Esibov, Aboba & Thaler Standards Track [Page 19]
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.
@ -1184,10 +1188,6 @@ INTERNET-DRAFT LLMNR 11 December 2003
[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.
@ -1197,9 +1197,13 @@ Esibov, Aboba & Thaler Standards Track [Page 20]
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
@ -1244,10 +1248,6 @@ Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
@ -1257,9 +1257,13 @@ Esibov, Aboba & Thaler Standards Track [Page 21]
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
@ -1304,10 +1308,6 @@ perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
@ -1317,9 +1317,13 @@ Esibov, Aboba & Thaler Standards Track [Page 22]
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
@ -1329,7 +1333,7 @@ http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
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.
@ -1362,10 +1366,6 @@ June 22, 2004.