+++ /dev/null
-
-
-
-INTERNET-DRAFT Andreas Gustafsson
-draft-ietf-dnsext-axfr-clarify-05.txt Nominum Inc.
- November 2002
-
-
- DNS Zone Transfer Protocol Clarifications
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Abstract
-
- In the Domain Name System, zone data is replicated among
- authoritative DNS servers by means of the "zone transfer" protocol,
- also known as the "AXFR" protocol. This memo clarifies, updates, and
- adds missing detail to the original AXFR protocol specification in
- RFC1034.
-
-1. Introduction
-
- The original definition of the DNS zone transfer protocol consists of
- a single paragraph in [RFC1034] section 4.3.5 and some additional
- notes in [RFC1035] section 6.3. It is not sufficiently detailed to
- serve as the sole basis for constructing interoperable
- implementations. This document is an attempt to provide a more
- complete definition of the protocol. Where the text in RFC1034
- conflicts with existing practice, the existing practice has been
- codified in the interest of interoperability.
-
-
-
-
-Expires May 2003 [Page 1]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-2. The zone transfer request
-
- To initiate a zone transfer, the slave server sends a zone transfer
- request to the master server over a reliable transport such as TCP.
- The form of this request is specified in sufficient detail in RFC1034
- and needs no further clarification.
-
- Implementers are advised that one server implementation in widespread
- use sends AXFR requests where the TCP message envelope size exceeds
- the DNS request message size by two octets.
-
-3. The zone transfer response
-
- If the master server is unable or unwilling to provide a zone
- transfer, it MUST respond with a single DNS message containing an
- appropriate RCODE other than NOERROR. If the master is not
- authoritative for the requested zone, the RCODE SHOULD be 9
- (NOTAUTH).
-
- Slave servers should note that some master server implementations
- will simply close the connection when denying the slave access to the
- zone. Therefore, slaves MAY interpret an immediate graceful close of
- the TCP connection as equivalent to a "Refused" response (RCODE 5).
-
- If a zone transfer can be provided, the master server sends one or
- more DNS messages containing the zone data as described below.
-
-3.1. Multiple answers per message
-
- The zone data in a zone transfer response is a sequence of answer
- RRs. These RRs are transmitted in the answer section(s) of one or
- more DNS response messages.
-
- The AXFR protocol definition in RFC1034 does not make a clear
- distinction between response messages and answer RRs. Historically,
- DNS servers always transmitted a single answer RR per message. This
- encoding is wasteful due to the overhead of repeatedly sending DNS
- message headers and the loss of domain name compression
- opportunities. To improve efficiency, some newer servers support a
- mode where multiple RRs are transmitted in a single DNS response
- message.
-
- A master MAY transmit multiple answer RRs per response message up to
- the largest number that will fit within the 65535 byte limit on TCP
-
-
-
-Expires May 2003 [Page 2]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- DNS message size. In the case of a small zone, this can cause the
- entire transfer to be transmitted in a single response message.
-
- Slaves MUST accept messages containing any number of answer RRs. For
- compatibility with old slaves, masters that support sending multiple
- answers per message SHOULD be configurable to revert to the
- historical mode of one answer per message, and the configuration
- SHOULD be settable on a per-slave basis.
-
-3.2. DNS message header contents
-
- RFC1034 does not specify the contents of the DNS message header of
- the zone transfer response messages. The header of each message MUST
- be as follows:
-
- ID Copy from request
- QR 1
- OPCODE QUERY
- AA 1, but MAY be 0 when RCODE is not NOERROR
- TC 0
- RD Copy from request, or 0
- RA Set according to availability of recursion, or 0
- Z 0
- AD 0
- CD 0
- RCODE NOERROR on success, error code otherwise
-
- The slave MUST check the RCODE in each message and abort the transfer
- if it is not NOERROR. It SHOULD check the ID of the first message
- received and abort the transfer if it does not match the ID of the
- request. The ID SHOULD be ignored in subsequent messages, and fields
- other than RCODE and ID SHOULD be ignored in all messages, to ensure
- interoperability with certain older implementations which transmit
- incorrect or arbitrary values in these fields.
-
-3.3. Additional section and SIG processing
-
- Zone transfer responses are not subject to any kind of additional
- section processing or automatic inclusion of SIG records. SIG RRs in
- the zone data are treated exactly the same as any other RR type.
-
-3.4. The question section
-
- RFC1034 does not specify whether zone transfer response messages have
- a question section or not. The initial message of a zone transfer
- response SHOULD have a question section identical to that in the
- request. Subsequent messages SHOULD NOT have a question section,
- though the final message MAY. The receiving slave server MUST accept
-
-
-
-Expires May 2003 [Page 3]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- any combination of messages with and without a question section.
-
-3.5. The authority section
-
- The master server MUST transmit messages with an empty authority
- section. Slaves MUST ignore any authority section contents they may
- receive from masters that do not comply with this requirement.
-
-3.6. The additional section
-
- The additional section MAY contain additional RRs such as transaction
- signatures. The slave MUST ignore any unexpected RRs in the
- additional section. It MUST NOT treat additional section RRs as zone
- data.
-
-4. Zone data
-
- The purpose of the zone transfer mechanism is to exactly replicate at
- each slave the set of RRs associated with a particular zone at its
- primary master. An RR is associated with a zone by being loaded from
- the master file of that zone at the primary master server, or by some
- other, equivalent method for configuring zone data.
-
- This replication shall be complete and unaltered, regardless of how
- many and which intermediate masters/slaves are involved, and
- regardless of what other zones those intermediate masters/slaves do
- or do not serve, and regardless of what data may be cached in
- resolvers associated with the intermediate masters/slaves.
-
- Therefore, in a zone transfer the master MUST send exactly those
- records that are associated with the zone, whether or not their owner
- names would be considered to be "in" the zone for purposes of
- resolution, and whether or not they would be eligible for use as glue
- in responses. The transfer MUST NOT include any RRs that are not
- associated with the zone, such as RRs associated with zones other
- than the one being transferred or present in the cache of the local
- resolver, even if their owner names are in the zone being transferred
- or are pointed to by NS records in the zone being transferred.
-
- The slave MUST associate the RRs received in a zone transfer with the
- specific zone being transferred, and maintain that association for
- purposes of acting as a master in outgoing transfers.
-
-5. Transmission order
-
- RFC1034 states that "The first and last messages must contain the
- data for the top authoritative node of the zone". This is not
- consistent with existing practice. All known master implementations
-
-
-
-Expires May 2003 [Page 4]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- send, and slave implementations expect to receive, the zone's SOA RR
- as the first and last record of the transfer.
-
- Therefore, the quoted sentence is hereby superseded by the sentence
- "The first and last RR transmitted must be the SOA record of the
- zone".
-
- The initial and final SOA record MUST be identical, with the possible
- exception of case and compression. In particular, they MUST have the
- same serial number. The slave MUST consider the transfer to be
- complete when, and only when, it has received the message containing
- the second SOA record.
-
- The transmission order of all other RRs in the zone is undefined.
- Each of them SHOULD be transmitted only once, and slaves MUST ignore
- any duplicate RRs received.
-
-6. Security Considerations
-
- The zone transfer protocol as defined in [RFC1034] and clarified by
- this memo does not have any built-in mechanisms for the slave to
- securely verify the identity of the master server and the integrity
- of the transferred zone data. The use of a cryptographic mechanism
- for ensuring authenticity and integrity, such as TSIG [RFC2845],
- IPSEC, or TLS, is RECOMMENDED.
-
- The zone transfer protocol allows read-only public access to the
- complete zone data. Since data in the DNS is public by definition,
- this is generally acceptable. Sites that wish to avoid disclosing
- their full zone data MAY restrict zone transfer access to authorized
- slaves.
-
- These clarifications are not believed to themselves introduce any new
- security problems, nor to solve any existing ones.
-
-Acknowledgements
-
- Many people have contributed input and commentary to earlier versions
- of this document, including but not limited to Bob Halley, Dan
- Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
- Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
- Trenholme, and Brian Wellington.
-
-References
-
- [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
- November 1987.
-
-
-
-
-Expires May 2003 [Page 5]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- [RFC1035] - Domain Names - Implementation and Specifications, P.
- Mockapetris, November 1987.
-
- [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
- S. Bradner, BCP 14, March 1997.
-
- [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P.
- Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
-
-Author's Address
-
- Andreas Gustafsson
- Nominum Inc.
- 2385 Bay Rd
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6004
-
- Email: gson@nominum.com
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000 - 2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implmentation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-
-
-
-Expires May 2003 [Page 6]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May 2003 [Page 7]
-\f
-
+++ /dev/null
-
-
-
-
-DNSEXT M. Stapp
-Internet-Draft Cisco Systems, Inc.
-Expires: September 1, 2006 T. Lemon
- Nominum, Inc.
- A. Gustafsson
- Araneus Information Systems Oy
- February 28, 2006
-
-
- A DNS RR for Encoding DHCP Information (DHCID RR)
- <draft-ietf-dnsext-dhcid-rr-12.txt>
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on September 1, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- It is possible for DHCP clients to attempt to update the same DNS
- FQDN or attempt to update a DNS FQDN that has been added to the DNS
- for another purpose as they obtain DHCP leases. Whether the DHCP
- server or the clients themselves perform the DNS updates, conflicts
- can arise. To resolve such conflicts, "Resolution of DNS Name
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 1]
-\f
-Internet-Draft The DHCID RR February 2006
-
-
- Conflicts" [1] proposes storing client identifiers in the DNS to
- unambiguously associate domain names with the DHCP clients to which
- they refer. This memo defines a distinct RR type for this purpose
- for use by DHCP clients and servers, the "DHCID" RR.
-
-
-Table of Contents
-
- 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 3
- 3.2. DHCID Presentation Format . . . . . . . . . . . . . . . . 4
- 3.3. The DHCID RR Identifier Type Codes . . . . . . . . . . . . 4
- 3.4. The DHCID RR Digest Type Code . . . . . . . . . . . . . . 4
- 3.5. Computation of the RDATA . . . . . . . . . . . . . . . . . 5
- 3.5.1. Using the Client's DUID . . . . . . . . . . . . . . . 5
- 3.5.2. Using the Client Identifier Option . . . . . . . . . . 5
- 3.5.3. Using the Client's htype and chaddr . . . . . . . . . 6
- 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
- 3.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
- 3.6.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 7
- 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 7
- 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
- Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 2]
-\f
-Internet-Draft The DHCID RR February 2006
-
-
-1. Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [2].
-
-
-2. Introduction
-
- A set of procedures to allow DHCP [6] [10] clients and servers to
- automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
- in "Resolution of DNS Name Conflicts" [1].
-
- Conflicts can arise if multiple DHCP clients wish to use the same DNS
- name or a DHCP client attempts to use a name added for another
- purpose. To resolve such conflicts, "Resolution of DNS Name
- Conflicts" [1] proposes storing client identifiers in the DNS to
- unambiguously associate domain names with the DHCP clients using
- them. In the interest of clarity, it is preferable for this DHCP
- information to use a distinct RR type. This memo defines a distinct
- RR for this purpose for use by DHCP clients or servers, the "DHCID"
- RR.
-
- In order to obscure potentially sensitive client identifying
- information, the data stored is the result of a one-way SHA-256 hash
- computation. The hash includes information from the DHCP client's
- message as well as the domain name itself, so that the data stored in
- the DHCID RR will be dependent on both the client identification used
- in the DHCP protocol interaction and the domain name. This means
- that the DHCID RDATA will vary if a single client is associated over
- time with more than one name. This makes it difficult to 'track' a
- client as it is associated with various domain names.
-
-
-3. The DHCID RR
-
- The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
- DHCID RR is only defined in the IN class. DHCID RRs cause no
- additional section processing. The DHCID RR is not a singleton type.
-
-3.1. DHCID RDATA format
-
- The RDATA section of a DHCID RR in transmission contains RDLENGTH
- octets of binary data. The format of this data and its
- interpretation by DHCP servers and clients are described below.
-
- DNS software should consider the RDATA section to be opaque. DHCP
- clients or servers use the DHCID RR to associate a DHCP client's
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 3]
-\f
-Internet-Draft The DHCID RR February 2006
-
-
- identity with a DNS name, so that multiple DHCP clients and servers
- may deterministically perform dynamic DNS updates to the same zone.
- From the updater's perspective, the DHCID resource record RDATA
- consists of a 2-octet identifier type, in network byte order,
- followed by a 1-octet digest type, followed by one or more octets
- representing the actual identifier:
-
- < 2 octets > Identifier type code
- < 1 octet > Digest type code
- < n octets > Digest (length depends on digest type)
-
-3.2. DHCID Presentation Format
-
- In DNS master files, the RDATA is represented as a single block in
- base 64 encoding identical to that used for representing binary data
- in RFC 3548 [7]. The data may be divided up into any number of white
- space separated substrings, down to single base 64 digits, which are
- concatenated to form the complete RDATA. These substrings can span
- lines using the standard parentheses.
-
-3.3. The DHCID RR Identifier Type Codes
-
- The DHCID RR Identifier Type Code specifies what data from the DHCP
- client's request was used as input into the hash function. The
- identifier type codes are defined in a registry maintained by IANA,
- as specified in Section 7. The initial list of assigned values for
- the identifier type code is:
-
- 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6].
- 0x0001 = The data octets (i.e., the Type and Client-Identifier
- fields) from a DHCPv4 client's Client Identifier option [9].
- 0x0002 = The client's DUID (i.e., the data octets of a DHCPv6
- client's Client Identifier option [10] or the DUID field from a
- DHCPv4 client's Client Identifier option [12]).
-
- 0x0003 - 0xfffe = Available to be assigned by IANA.
-
- 0xffff = RESERVED
-
-3.4. The DHCID RR Digest Type Code
-
- The DHCID RR Digest Type Code is an identifier for the digest
- algorithm used. The digest is calculated over an identifier and the
- canonical FQDN as described in the next section.
-
- The digest type codes are defined in a registry maintained by IANA,
- as specified in Section 7. The initial list of assigned values for
- the digest type codes is: value 0 is reserved and value 1 is SHA-256.
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 4]
-\f
-Internet-Draft The DHCID RR February 2006
-
-
- Reserving other types requires IETF standards action. Defining new
- values will also require IETF standards action to document how DNS
- updaters are to deal with multiple digest types.
-
-3.5. Computation of the RDATA
-
- The DHCID RDATA is formed by concatenating the 2-octet identifier
- type code with variable-length data.
-
- The RDATA for all type codes other than 0xffff, which is reserved for
- future expansion, is formed by concatenating the 2-octet identifier
- type code, the 1-octet digest type code, and the digest value (32
- octets for SHA-256).
-
- < identifier-type > < digest-type > < digest >
-
- The input to the digest hash function is defined to be:
-
- digest = SHA-256(< identifier > < FQDN >)
-
- The FQDN is represented in the buffer in unambiguous canonical form
- as described in RFC 4034 [8], section 6.1. The identifier type code
- and the identifier are related as specified in Section 3.3: the
- identifier type code describes the source of the identifier.
-
- A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
- option is present in the DHCPv4 messages and it is encoded as
- specified in [12]. Otherwise, the updater uses 0x0001 if a Client
- Identifier option is present and 0x0000 if not.
-
- A DHCPv6 updater always uses the 0x0002 type code.
-
-3.5.1. Using the Client's DUID
-
- When the updater is using the Client's DUID (either from a DHCPv6
- Client Identifier option or from a portion of the DHCPv4 Client
- Identifier option encoded as specified in [12]), the first two octets
- of the DHCID RR MUST be 0x0002, in network byte order. The third
- octet is the digest type code (1 for SHA-256). The rest of the DHCID
- RR MUST contain the results of computing the SHA-256 hash across the
- octets of the DUID followed by the FQDN.
-
-3.5.2. Using the Client Identifier Option
-
- When the updater is using the DHCPv4 Client Identifier option sent by
- the client in its DHCPREQUEST message, the first two octets of the
- DHCID RR MUST be 0x0001, in network byte order. The third octet is
- the digest type code (1 for SHA-256). The rest of the DHCID RR MUST
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 5]
-\f
-Internet-Draft The DHCID RR February 2006
-
-
- contain the results of computing the SHA-256 hash across the data
- octets (i.e., the Type and Client-Identifier fields) of the option,
- followed by the FQDN.
-
-3.5.3. Using the Client's htype and chaddr
-
- When the updater is using the client's link-layer address as the
- identifier, the first two octets of the DHCID RDATA MUST be zero.
- The third octet is the digest type code (1 for SHA-256). To generate
- the rest of the resource record, the updater computes a one-way hash
- using the SHA-256 algorithm across a buffer containing the client's
- network hardware type, link-layer address, and the FQDN data.
- Specifically, the first octet of the buffer contains the network
- hardware type as it appeared in the DHCP 'htype' field of the
- client's DHCPREQUEST message. All of the significant octets of the
- 'chaddr' field in the client's DHCPREQUEST message follow, in the
- same order in which the octets appear in the DHCPREQUEST message.
- The number of significant octets in the 'chaddr' field is specified
- in the 'hlen' field of the DHCPREQUEST message. The FQDN data, as
- specified above, follows.
-
-3.6. Examples
-
-3.6.1. Example 1
-
- A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
- Ethernet MAC address 01:02:03:04:05:06 using domain name
- "client.example.com" uses the client's link-layer address to identify
- the client. The DHCID RDATA is composed by setting the two type
- octets to zero, the 1-octet digest type to 1 for SHA-256, and
- performing an SHA-256 hash computation across a buffer containing the
- Ethernet MAC type octet, 0x01, the six octets of MAC address, and the
- domain name (represented as specified in Section 3.5).
-
- client.example.com. A 10.0.0.1
- client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
- ytcKD//7es/deY= )
-
- If the DHCID RR type is not supported, the RDATA would be encoded
- [13] as:
-
- \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
- fffedeb3f75e6 )
-
-3.6.2. Example 2
-
- A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
- included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 6]
-\f
-Internet-Draft The DHCID RR February 2006
-
-
- in its DHCP request. The server updates the name "chi.example.com"
- on the client's behalf, and uses the DHCP client identifier option
- data as input in forming a DHCID RR. The DHCID RDATA is formed by
- setting the two type octets to the value 0x0001, the 1-octet digest
- type to 1 for SHA-256, and performing a SHA-256 hash computation
- across a buffer containing the seven octets from the client-id option
- and the FQDN (represented as specified in Section 3.5).
-
- chi.example.com. A 10.0.12.99
- chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
- L3b/NaiUDlW2No= )
-
- If the DHCID RR type is not supported, the RDATA would be encoded
- [13] as:
-
- \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
- 6a2503956d8da )
-
-3.6.3. Example 3
-
- A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
- which included the DHCPv6 client-identifier option data 00:01:00:06:
- 41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request. The server
- updates the name "chi6.example.com" on the client's behalf, and uses
- the DHCP client identifier option data as input in forming a DHCID
- RR. The DHCID RDATA is formed by setting the two type octets to the
- value 0x0002, the 1-octet digest type to 1 for SHA-256, and
- performing a SHA-256 hash computation across a buffer containing the
- 14 octets from the client-id option and the FQDN (represented as
- specified in Section 3.5).
-
- chi6.example.com. AAAA 2000::1234:5678
- chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
- OjxfNuVAA2kjEA= )
-
- If the DHCID RR type is not supported, the RDATA would be encoded
- [13] as:
-
- \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
- b95000da48c40 )
-
-
-4. Use of the DHCID RR
-
- This RR MUST NOT be used for any purpose other than that detailed in
- "Resolution of DNS Name Conflicts" [1]. Although this RR contains
- data that is opaque to DNS servers, the data must be consistent
- across all entities that update and interpret this record.
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 7]
-\f
-Internet-Draft The DHCID RR February 2006
-
-
- Therefore, new data formats may only be defined through actions of
- the DHC Working Group, as a result of revising [1].
-
-
-5. Updater Behavior
-
- The data in the DHCID RR allows updaters to determine whether more
- than one DHCP client desires to use a particular FQDN. This allows
- site administrators to establish policy about DNS updates. The DHCID
- RR does not establish any policy itself.
-
- Updaters use data from a DHCP client's request and the domain name
- that the client desires to use to compute a client identity hash, and
- then compare that hash to the data in any DHCID RRs on the name that
- they wish to associate with the client's IP address. If an updater
- discovers DHCID RRs whose RDATA does not match the client identity
- that they have computed, the updater SHOULD conclude that a different
- client is currently associated with the name in question. The
- updater SHOULD then proceed according to the site's administrative
- policy. That policy might dictate that a different name be selected,
- or it might permit the updater to continue.
-
-
-6. Security Considerations
-
- The DHCID record as such does not introduce any new security problems
- into the DNS. In order to obscure the client's identity information,
- a one-way hash is used. And, in order to make it difficult to
- 'track' a client by examining the names associated with a particular
- hash value, the FQDN is included in the hash computation. Thus, the
- RDATA is dependent on both the DHCP client identification data and on
- each FQDN associated with the client.
-
- However, it should be noted that an attacker that has some knowledge,
- such as of MAC addresses commonly used in DHCP client identification
- data, may be able to discover the client's DHCP identify by using a
- brute-force attack. Even without any additional knowledge, the
- number of unknown bits used in computing the hash is typically only
- 48 to 80.
-
- Administrators should be wary of permitting unsecured DNS updates to
- zones, whether or not they are exposed to the global Internet. Both
- DHCP clients and servers SHOULD use some form of update
- authentication (e.g., TSIG [11]) when performing DNS updates.
-
-
-7. IANA Considerations
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 8]
-\f
-Internet-Draft The DHCID RR February 2006
-
-
- IANA is requested to allocate a DNS RR type number for the DHCID
- record type.
-
- This specification defines a new number-space for the 2-octet
- identifier type codes associated with the DHCID RR. IANA is
- requested to establish a registry of the values for this number-
- space. Three initial values are assigned in Section 3.3, and the
- value 0xFFFF is reserved for future use. New DHCID RR identifier
- type codes are assigned through Standards Action, as defined in RFC
- 2434 [5].
-
- This specification defines a new number-space for the 1-octet digest
- type codes associated with the DHCID RR. IANA is requested to
- establish a registry of the values for this number-space. Two
- initial values are assigned in Section 3.4. New DHCID RR digest type
- codes are assigned through Standards Action, as defined in RFC 2434
- [5].
-
-
-8. Acknowledgements
-
- Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
- Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
- Volz for their review and suggestions.
-
-
-9. References
-
-9.1. Normative References
-
- [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
- DHCP Clients (draft-ietf-dhc-dns-resolution-*)", February 2006.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [3] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [4] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-
-
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 9]
-\f
-Internet-Draft The DHCID RR February 2006
-
-
-9.2. Informative References
-
- [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
- [7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
- RFC 3548, July 2003.
-
- [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
- Extensions", RFC 2132, March 1997.
-
- [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
- Carney, "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
- [11] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [12] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
- for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
- RFC 4361, February 2006.
-
- [13] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
- Types", RFC 3597, September 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 10]
-\f
-Internet-Draft The DHCID RR February 2006
-
-
-Authors' Addresses
-
- Mark Stapp
- Cisco Systems, Inc.
- 1414 Massachusetts Ave.
- Boxborough, MA 01719
- USA
-
- Phone: 978.936.1535
- Email: mjs@cisco.com
-
-
- Ted Lemon
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- USA
-
- Email: mellon@nominum.com
-
-
- Andreas Gustafsson
- Araneus Information Systems Oy
- Ulappakatu 1
- 02320 Espoo
- Finland
-
- Email: gson@araneus.fi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 11]
-\f
-Internet-Draft The DHCID RR February 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 12]
-\f
-
+++ /dev/null
-
-
-
-Network Working Group S. Weiler
-Internet-Draft SPARTA, Inc
-Updates: 4034, 4035 (if approved) May 23, 2005
-Expires: November 24, 2005
-
-
- Clarifications and Implementation Notes for DNSSECbis
- draft-ietf-dnsext-dnssec-bis-updates-01
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on November 24, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This document is a collection of minor technical clarifications to
- the DNSSECbis document set. It is meant to serve as a resource to
- implementors as well as an interim repository of possible DNSSECbis
- errata.
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 1]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-Proposed additions in future versions
-
- An index sorted by the section of DNSSECbis being clarified.
-
- A list of proposed protocol changes being made in other documents,
- such as NSEC3 and Epsilon. This document would not make those
- changes, merely provide an index into the documents that are making
- changes.
-
-Changes between -00 and -01
-
- Document significantly restructured.
-
- Added section on QTYPE=ANY.
-
-Changes between personal submission and first WG draft
-
- Added Section 2.1 based on namedroppers discussions from March 9-10,
- 2005.
-
- Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
-
- Added the DNSSECbis RFC numbers.
-
- Figured out the confusion in Section 4.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 2]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-Table of Contents
-
- 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
- 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4
- 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4
- 2.1 Clarifications on Non-Existence Proofs . . . . . . . . . . 4
- 2.2 Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5
- 2.3 Validating Responses to an ANY Query . . . . . . . . . . . 5
- 3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
- 3.1 Unknown DS Message Digest Algorithms . . . . . . . . . . . 5
- 3.2 Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
- 3.3 Caution About Local Policy and Multiple RRSIGs . . . . . . 6
- 3.4 Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
- 4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7
- 4.1 Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7
- 4.2 Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7
- 4.3 Errors in Examples . . . . . . . . . . . . . . . . . . . . 8
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8
- 7.2 Informative References . . . . . . . . . . . . . . . . . . 9
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
- A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
- Intellectual Property and Copyright Statements . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 3]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-1. Introduction and Terminology
-
- This document lists some minor clarifications and corrections to
- DNSSECbis, as described in [1], [2], and [3].
-
- It is intended to serve as a resource for implementors and as a
- repository of items that need to be addressed when advancing the
- DNSSECbis documents from Proposed Standard to Draft Standard.
-
- In this version (-01 of the WG document), feedback is particularly
- solicited on the structure of the document and whether the text in
- the recently added sections is correct and sufficient.
-
- Proposed substantive additions to this document should be sent to the
- namedroppers mailing list as well as to the editor of this document.
- The editor would greatly prefer text suitable for direct inclusion in
- this document.
-
-1.1 Structure of this Document
-
- The clarifications to DNSSECbis are sorted according to the editor's
- impression of their importance, starting with ones which could, if
- ignored, lead to security and stability problems and progressing down
- to clarifications that are likely to have little operational impact.
- Mere typos and awkward phrasings are not addressed unless they could
- lead to misinterpretation of the DNSSECbis documents.
-
-1.2 Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [4].
-
-2. Significant Concerns
-
- This section provides clarifications that, if overlooked, could lead
- to security issues or major interoperability problems.
-
-2.1 Clarifications on Non-Existence Proofs
-
- RFC4035 Section 5.4 slightly underspecifies the algorithm for
- checking non-existence proofs. In particular, the algorithm there
- might incorrectly allow the NSEC from the parent side of a zone cut
- to prove the non-existence of either other RRs at that name in the
- child zone or other names in the child zone. It might also allow a
- NSEC at the same name as a DNAME to prove the non-existence of names
- beneath that DNAME.
-
-
-
-
-Weiler Expires November 24, 2005 [Page 4]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- A parent-side delegation NSEC (one with the NS bit set, but no SOA
- bit set, and with a singer field that's shorter than the owner name)
- must not be used to assume non-existence of any RRs below that zone
- cut (both RRs at that ownername and at ownernames with more leading
- labels, no matter their content). Similarly, an NSEC with the DNAME
- bit set must not be used to assume the non-existence of any
- descendant of that NSEC's owner name.
-
-2.2 Empty Non-Terminal Proofs
-
- To be written, based on Roy Arends' May 11th message to namedroppers.
-
-2.3 Validating Responses to an ANY Query
-
- RFC4035 does not address now to validate responses when QTYPE=*. As
- described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
- may include a subset of the RRsets at a given name -- it is not
- necessary to include all RRsets at the QNAME in the response.
-
- When validating a response to QTYPE=*, validate all received RRsets
- that match QNAME and QCLASS. If any of those RRsets fail validation,
- treat the answer as Bogus. If there are no RRsets matching QNAME and
- QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
- clarified in this document). To be clear, a validator must not
- insist on receiving all records at the QNAME in response to QTYPE=*.
-
-3. Interoperability Concerns
-
-3.1 Unknown DS Message Digest Algorithms
-
- Section 5.2 of RFC4035 includes rules for how to handle delegations
- to zones that are signed with entirely unsupported algorithms, as
- indicated by the algorithms shown in those zone's DS RRsets. It does
- not explicitly address how to handle DS records that use unsupported
- message digest algorithms. In brief, DS records using unknown or
- unsupported message digest algorithms MUST be treated the same way as
- DS records referring to DNSKEY RRs of unknown or unsupported
- algorithms.
-
- The existing text says:
-
- If the validator does not support any of the algorithms listed
- in an authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
-
-
-
-Weiler Expires November 24, 2005 [Page 5]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- To paraphrase the above, when determining the security status of a
- zone, a validator discards (for this purpose only) any DS records
- listing unknown or unsupported algorithms. If none are left, the
- zone is treated as if it were unsigned.
-
- Modified to consider DS message digest algorithms, a validator also
- discards any DS records using unknown or unsupported message digest
- algorithms.
-
-3.2 Private Algorithms
-
- As discussed above, section 5.2 of RFC4035 requires that validators
- make decisions about the security status of zones based on the public
- key algorithms shown in the DS records for those zones. In the case
- of private algorithms, as described in RFC4034 Appendix A.1.1, the
- eight-bit algorithm field in the DS RR is not conclusive about what
- algorithm(s) is actually in use.
-
- If no private algorithms appear in the DS set or if any supported
- algorithm appears in the DS set, no special processing will be
- needed. In the remaining cases, the security status of the zone
- depends on whether or not the resolver supports any of the private
- algorithms in use (provided that these DS records use supported hash
- functions, as discussed in Section 3.1). In these cases, the
- resolver MUST retrieve the corresponding DNSKEY for each private
- algorithm DS record and examine the public key field to determine the
- algorithm in use. The security-aware resolver MUST ensure that the
- hash of the DNSKEY RR's owner name and RDATA matches the digest in
- the DS RR. If they do not match, and no other DS establishes that
- the zone is secure, the referral should be considered BAD data, as
- discussed in RFC4035.
-
- This clarification facilitates the broader use of private algorithms,
- as suggested by [5].
-
-3.3 Caution About Local Policy and Multiple RRSIGs
-
- When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
- suggests that "the local resolver security policy determines whether
- the resolver also has to test these RRSIG RRs and how to resolve
- conflicts if these RRSIG RRs lead to differing results." In most
- cases, a resolver would be well advised to accept any valid RRSIG as
- sufficient. If the first RRSIG tested fails validation, a resolver
- would be well advised to try others, giving a successful validation
- result if any can be validated and giving a failure only if all
- RRSIGs fail validation.
-
- If a resolver adopts a more restrictive policy, there's a danger that
-
-
-
-Weiler Expires November 24, 2005 [Page 6]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- properly-signed data might unnecessarily fail validation, perhaps
- because of cache timing issues. Furthermore, certain zone management
- techniques, like the Double Signature Zone-signing Key Rollover
- method described in section 4.2.1.2 of [6] might not work reliably.
-
-3.4 Key Tag Calculation
-
- RFC4034 Appendix B.1 incorrectly defines the Key Tag field
- calculation for algorithm 1. It correctly says that the Key Tag is
- the most significant 16 of the least significant 24 bits of the
- public key modulus. However, RFC4034 then goes on to incorrectly say
- that this is 4th to last and 3rd to last octets of the public key
- modulus. It is, in fact, the 3rd to last and 2nd to last octets.
-
-4. Minor Corrections and Clarifications
-
-4.1 Finding Zone Cuts
-
- Appendix C.8 of RFC4035 discusses sending DS queries to the servers
- for a parent zone. To do that, a resolver may first need to apply
- special rules to discover what those servers are.
-
- As explained in Section 3.1.4.1 of RFC4035, security-aware name
- servers need to apply special processing rules to handle the DS RR,
- and in some situations the resolver may also need to apply special
- rules to locate the name servers for the parent zone if the resolver
- does not already have the parent's NS RRset. Section 4.2 of RFC4035
- specifies a mechanism for doing that.
-
-4.2 Clarifications on DNSKEY Usage
-
- Questions of the form "can I use a different DNSKEY for signing the
- X" have occasionally arisen.
-
- The short answer is "yes, absolutely". You can even use a different
- DNSKEY for each RRset in a zone, subject only to practical limits on
- the size of the DNSKEY RRset. However, be aware that there is no way
- to tell resolvers what a particularly DNSKEY is supposed to be used
- for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
- authenticate any RRset in the zone. For example, if a weaker or less
- trusted DNSKEY is being used to authenticate NSEC RRsets or all
- dynamically updated records, that same DNSKEY can also be used to
- sign any other RRsets from the zone.
-
- Furthermore, note that the SEP bit setting has no effect on how a
- DNSKEY may be used -- the validation process is specifically
- prohibited from using that bit by RFC4034 section 2.1.2. It possible
- to use a DNSKEY without the SEP bit set as the sole secure entry
-
-
-
-Weiler Expires November 24, 2005 [Page 7]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- point to the zone, yet use a DNSKEY with the SEP bit set to sign all
- RRsets in the zone (other than the DNSKEY RRset). It's also possible
- to use a single DNSKEY, with or without the SEP bit set, to sign the
- entire zone, including the DNSKEY RRset itself.
-
-4.3 Errors in Examples
-
- The text in RFC4035 Section C.1 refers to the examples in B.1 as
- "x.w.example.com" while B.1 uses "x.w.example". This is painfully
- obvious in the second paragraph where it states that the RRSIG labels
- field value of 3 indicates that the answer was not the result of
- wildcard expansion. This is true for "x.w.example" but not for
- "x.w.example.com", which of course has a label count of 4
- (antithetically, a label count of 3 would imply the answer was the
- result of a wildcard expansion).
-
- The first paragraph of RFC4035 Section C.6 also has a minor error:
- the reference to "a.z.w.w.example" should instead be "a.z.w.example",
- as in the previous line.
-
-5. IANA Considerations
-
- This document specifies no IANA Actions.
-
-6. Security Considerations
-
- This document does not make fundamental changes to the DNSSEC
- protocol, as it was generally understood when DNSSECbis was
- published. It does, however, address some ambiguities and omissions
- in those documents that, if not recognized and addressed in
- implementations, could lead to security failures. In particular, the
- validation algorithm clarifications in Section 2 are critical for
- preserving the security properties DNSSEC offers. Furthermore,
- failure to address some of the interoperability concerns in Section 3
- could limit the ability to later change or expand DNSSEC, including
- by adding new algorithms.
-
-7. References
-
-7.1 Normative References
-
- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Weiler Expires November 24, 2005 [Page 8]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-7.2 Informative References
-
- [5] Blacka, D., "DNSSEC Experiments",
- draft-blacka-dnssec-experiments-00 (work in progress),
- December 2004.
-
- [6] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
- draft-ietf-dnsop-dnssec-operational-practices-04 (work in
- progress), May 2005.
-
-
-Author's Address
-
- Samuel Weiler
- SPARTA, Inc
- 7075 Samuel Morse Drive
- Columbia, Maryland 21046
- US
-
- Email: weiler@tislabs.com
-
-Appendix A. Acknowledgments
-
- The editor is extremely grateful to those who, in addition to finding
- errors and omissions in the DNSSECbis document set, have provided
- text suitable for inclusion in this document.
-
- The lack of specificity about handling private algorithms, as
- described in Section 3.2, and the lack of specificity in handling ANY
- queries, as described in Section 2.3, were discovered by David
- Blacka.
-
- The error in algorithm 1 key tag calculation, as described in
- Section 3.4, was found by Abhijit Hayatnagarkar. Donald Eastlake
- contributed text for Section 3.4.
-
- The bug relating to delegation NSEC RR's in Section 2.1 was found by
- Roy Badami. Roy Arends found the related problem with DNAME.
-
- The errors in the RFC4035 examples were found by Roy Arends, who also
- contributed text for Section 4.3 of this document.
-
-
-
-Weiler Expires November 24, 2005 [Page 9]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- The editor would like to thank Olafur Gudmundsson and Scott Rose for
- their substantive comments on the text of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 10]
-\f
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Weiler Expires November 24, 2005 [Page 11]
-\f
+++ /dev/null
-
-
-
-DNSEXT D. Blacka
-Internet-Draft Verisign, Inc.
-Expires: January 19, 2006 July 18, 2005
-
-
- DNSSEC Experiments
- draft-ietf-dnsext-dnssec-experiments-01
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on January 19, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- In the long history of the development of the DNS security extensions
- [1] (DNSSEC), a number of alternate methodologies and modifications
- have been proposed and rejected for practical, rather than strictly
- technical, reasons. There is a desire to be able to experiment with
- these alternate methods in the public DNS. This document describes a
- methodology for deploying alternate, non-backwards-compatible, DNSSEC
- methodologies in an experimental fashion without disrupting the
- deployment of standard DNSSEC.
-
-
-
-
-Blacka Expires January 19, 2006 [Page 1]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-Table of Contents
-
- 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8
- 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9
- 7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10
- 8. Security Considerations . . . . . . . . . . . . . . . . . . 11
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 10.1 Normative References . . . . . . . . . . . . . . . . . . 13
- 10.2 Informative References . . . . . . . . . . . . . . . . . 13
- Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
- Intellectual Property and Copyright Statements . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 2]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-1. Definitions and Terminology
-
- Throughout this document, familiarity with the DNS system (RFC 1035
- [4]) and the DNS security extensions ([1], [2], and [3].
-
- The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 3]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-2. Overview
-
- Historically, experimentation with DNSSEC alternatives has been a
- problematic endeavor. There has typically been a desire to both
- introduce non-backwards-compatible changes to DNSSEC, and to try
- these changes on real zones in the public DNS. This creates a
- problem when the change to DNSSEC would make all or part of the zone
- using those changes appear bogus (bad) or otherwise broken to
- existing DNSSEC-aware resolvers.
-
- This document describes a standard methodology for setting up public
- DNSSEC experiments. This methodology addresses the issue of co-
- existence with standard DNSSEC and DNS by using unknown algorithm
- identifiers to hide the experimental DNSSEC protocol modifications
- from standard DNSSEC-aware resolvers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 4]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-3. Experiments
-
- When discussing DNSSEC experiments, it is necessary to classify these
- experiments into two broad categories:
-
- Backwards-Compatible: describes experimental changes that, while not
- strictly adhering to the DNSSEC standard, are nonetheless
- interoperable with clients and server that do implement the DNSSEC
- standard.
-
- Non-Backwards-Compatible: describes experiments that would cause a
- standard DNSSEC-aware resolver to (incorrectly) determine that all
- or part of a zone is bogus, or to otherwise not interoperable with
- standard DNSSEC clients and servers.
-
- Not included in these terms are experiments with the core DNS
- protocol itself.
-
- The methodology described in this document is not necessary for
- backwards-compatible experiments, although it certainly could be used
- if desired.
-
- Note that, in essence, this metholodolgy would also be used to
- introduce a new DNSSEC algorithm, independently from any DNSSEC
- experimental protocol change.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 5]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-4. Method
-
- The core of the methodology is the use of strictly "unknown"
- algorithms to sign the experimental zone, and more importantly,
- having only unknown algorithm DS records for the delegation to the
- zone at the parent.
-
- This technique works because of the way DNSSEC-compliant validators
- are expected to work in the presence of a DS set with only unknown
- algorithms. From [3], Section 5.2:
-
- If the validator does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
- And further:
-
- If the resolver does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver will not be able to
- verify the authentication path to the child zone. In this case,
- the resolver SHOULD treat the child zone as if it were unsigned.
-
- While this behavior isn't strictly mandatory (as marked by MUST), it
- is unlikely that a validator would not implement the behavior, or,
- more to the point, it will not violate this behavior in an unsafe way
- (see below (Section 6).)
-
- Because we are talking about experiments, it is RECOMMENDED that
- private algorithm numbers be used (see [2], appendix A.1.1. Note
- that secure handling of private algorithms requires special handing
- by the validator logic. See [6] for futher details.) Normally,
- instead of actually inventing new signing algorithms, the recommended
- path is to create alternate algorithm identifiers that are aliases
- for the existing, known algorithms. While, strictly speaking, it is
- only necessary to create an alternate identifier for the mandatory
- algorithms, it is RECOMMENDED that all OPTIONAL defined algorithms be
- aliased as well.
-
- It is RECOMMENDED that for a particular DNSSEC experiment, a
- particular domain name base is chosen for all new algorithms, then
- the algorithm number (or name) is prepended to it. For example, for
- experiment A, the base name of "dnssec-experiment-a.example.com" is
- chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
- defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-
- experiment-a.example.com". However, any unique identifier will
-
-
-
-Blacka Expires January 19, 2006 [Page 6]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
- suffice.
-
- Using this method, resolvers (or, more specificially, DNSSEC
- validators) essentially indicate their ability to understand the
- DNSSEC experiment's semantics by understanding what the new algorithm
- identifiers signify.
-
- This method creates two classes of DNSSEC-aware servers and
- resolvers: servers and resolvers that are aware of the experiment
- (and thus recognize the experiments algorithm identifiers and
- experimental semantics), and servers and resolvers that are unware of
- the experiment.
-
- This method also precludes any zone from being both in an experiment
- and in a classic DNSSEC island of security. That is, a zone is
- either in an experiment and only experimentally validatable, or it
- isn't.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 7]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-5. Defining an Experiment
-
- The DNSSEC experiment must define the particular set of (previously
- unknown) algorithms that identify the experiment, and define what
- each unknown algorithm identifier means. Typically, unless the
- experiment is actually experimenting with a new DNSSEC algorithm,
- this will be a mapping of private algorithm identifiers to existing,
- known algorithms.
-
- Normally the experiment will choose a DNS name as the algorithm
- identifier base. This DNS name SHOULD be under the control of the
- authors of the experiment. Then the experiment will define a mapping
- between known mandatory and optional algorithms into this private
- algorithm identifier space. Alternately, the experiment MAY use the
- OID private algorithm space instead (using algorithm number 254), or
- may choose non-private algorithm numbers, although this would require
- an IANA allocation (see below (Section 9).)
-
- For example, an experiment might specify in its description the DNS
- name "dnssec-experiment-a.example.com" as the base name, and provide
- the mapping of "3.dnssec-experiment-a.example.com" is an alias of
- DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
- an alias of DNSSEC algorithm 5 (RSASHA1).
-
- Resolvers MUST then only recognize the experiment's semantics when
- present in a zone signed by one or more of these private algorithms.
-
- In general, however, resolvers involved in the experiment are
- expected to understand both standard DNSSEC and the defined
- experimental DNSSEC protocol, although this isn't required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 8]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-6. Considerations
-
- There are a number of considerations with using this methodology.
-
- 1. Under some circumstances, it may be that the experiment will not
- be sufficiently masked by this technique and may cause resolution
- problem for resolvers not aware of the experiment. For instance,
- the resolver may look at the not validatable response and
- conclude that the response is bogus, either due to local policy
- or implementation details. This is not expected to be the common
- case, however.
-
- 2. In general, it will not be possible for DNSSEC-aware resolvers
- not aware of the experiment to build a chain of trust through an
- experimental zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 9]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-7. Transitions
-
- If an experiment is successful, there may be a desire to move the
- experiment to a standards-track extension. One way to do so would be
- to move from private algorithm numbers to IANA allocated algorithm
- numbers, with otherwise the same meaning. This would still leave a
- divide between resolvers that understood the extension versus
- resolvers that did not. It would, in essence, create an additional
- version of DNSSEC.
-
- An alternate technique might be to do a typecode rollover, thus
- actually creating a definitive new version of DNSSEC. There may be
- other transition techniques available, as well.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 10]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-8. Security Considerations
-
- Zones using this methodology will be considered insecure by all
- resolvers except those aware of the experiment. It is not generally
- possible to create a secure delegation from an experimental zone that
- will be followed by resolvers unaware of the experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 11]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-9. IANA Considerations
-
- IANA may need to allocate new DNSSEC algorithm numbers if that
- transition approach is taken, or the experiment decides to use
- allocated numbers to begin with. No IANA action is required to
- deploy an experiment using private algorithm identifiers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 12]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-10. References
-
-10.1 Normative References
-
- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
-10.2 Informative References
-
- [4] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [6] Weiler, S., "Clarifications and Implementation Notes for
- DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in
- progress), March 2005.
-
-
-Author's Address
-
- David Blacka
- Verisign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- Email: davidb@verisign.com
- URI: http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 13]
-\f
-Internet-Draft DNSSEC Experiments July 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Blacka Expires January 19, 2006 [Page 14]
-\f
+++ /dev/null
-
-
-
-DNS Extensions working group J. Jansen
-Internet-Draft NLnet Labs
-Expires: July 5, 2006 January 2006
-
-
- Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC
- draft-ietf-dnsext-dnssec-rsasha256-00
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on July 5, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG
- resource records for use in the Domain Name System Security
- Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).
-
-
-
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 1]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3
- 3. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . . . 3
- 4. Implementation Considerations . . . . . . . . . . . . . . . . . 4
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 5
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
- Intellectual Property and Copyright Statements . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 2]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical distributed
- database for Internet Addressing. The DNS has been extended to use
- digital signatures and cryptographic keys for the verification of
- data. RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS
- Security Extensions.
-
- RFC4034 describes how to store DNSKEY and RRSIG resource records, and
- specifies a list of cryptographic algorithms to use. This document
- extends that list with the algorithm RSA/SHA-256, and specifies how
- to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG
- resource records.
-
- Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in
- this document.
-
-
-2. RSA/SHA-256 DNSKEY Resource Records
-
- RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
- resource records (RRs) with the algorithm number [TBA].
-
- The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110
- [6].
-
-
-3. RSA/SHA-256 RRSIG Resource Records
-
- RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
- records (RRs) with algorithm number [TBA].
-
- The value of the signature field in the RRSIG RR is calculated as
- follows. The values for the fields that precede the signature data
- are specified in RFC4034 [2].
-
- hash = SHA-256(data)
-
- signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
- Where SHA-256 is the message digest algorithm as specified in FIPS
- 180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of
- corresponding hexadecimal value, "e" is the private exponent of the
- signing RSA key, and "n" is the public modulus of the signing key.
- The FF octet MUST be repeated the maximum number of times so that the
- total length of the signature equals the length of the modulus of the
- signer's public key ("n"). "data" is the data of the resource record
- set that is signed, as specified in RFC4034 [2].
-
-
-
-Jansen Expires July 5, 2006 [Page 3]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
- The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as
- specified in PKCS 2.1 [4]:
-
- hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
-
- This prefix should make the use of standard cryptographic libraries
- easier. These specifications are taken directly from PKCS #1 v2.1
- section 9.2 [4].
-
-
-4. Implementation Considerations
-
- DNSSEC aware implementations MUST be able to support RRSIG resource
- records with the RSA/SHA-256 algorithm.
-
- If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are
- available for a certain rrset, with a secure path to their keys, the
- validator SHOULD ignore the SHA-1 signature. If the RSA/SHA-256
- signature does not verify the data, and the RSA/SHA-1 does, the
- validator SHOULD mark the data with the security status from the RSA/
- SHA-256 signature.
-
-
-5. IANA Considerations
-
- IANA has not yet assigned an algorithm number for RSA/SHA-256.
-
- The algorithm list from RFC4034 Appendix A.1 [2] is extended with the
- following entry:
-
- Zone
- Value Algorithm [Mnemonic] Signing References Status
- ----- ----------- ----------- -------- ---------- ---------
- [tba] RSA/SHA-256 [RSASHA256] y [TBA] MANDATORY
-
-
-6. Security Considerations
-
- Recently, weaknesses have been discovered in the SHA-1 hashing
- algorithm. It is therefore strongly encouraged to deploy SHA-256
- where SHA-1 is used now, as soon as the DNS software supports it.
-
- SHA-256 is considered sufficiently strong for the immediate future,
- but predictions about future development in cryptography and
- cryptanalysis are beyond the scope of this document.
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 4]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-7. Acknowledgments
-
- This document is a minor extension to RFC4034 [2]. Also, we try to
- follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt
- [8] for consistency. The authors of and contributors to these
- documents are gratefully acknowledged for their hard work.
-
- The following people provided additional feedback and text: Jaap
- Akkerhuis, Miek Gieben and Wouter Wijngaards.
-
-
-8. References
-
-8.1. Normative References
-
- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
- (PKCS) #1: RSA Cryptography Specifications Version 2.1",
- RFC 3447, February 2003.
-
- [5] National Institute of Standards and Technology, "Secure Hash
- Standard", FIPS PUB 180-2, August 2002.
-
- [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
- System (DNS)", RFC 3110, May 2001.
-
-8.2. Informative References
-
- [7] Schneier, B., "Applied Cryptography Second Edition: protocols,
- algorithms, and source code in C", Wiley and Sons , ISBN 0-471-
- 11709-9, 1996.
-
- [8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
- Resource Records (RRs)", Work in Progress Feb 2006.
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 5]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-Author's Address
-
- Jelte Jansen
- NLnet Labs
- Kruislaan 419
- Amsterdam 1098VA
- NL
-
- Email: jelte@NLnetLabs.nl
- URI: http://www.nlnetlabs.nl/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 6]
-\f
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Jansen Expires July 5, 2006 [Page 7]
-\f
+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Bernard Aboba
-INTERNET-DRAFT Dave Thaler
-Category: Standards Track Levon Esibov
-<draft-ietf-dnsext-mdns-43.txt> Microsoft Corporation
-29 August 2005
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on March 15, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2005.
-
-Abstract
-
- The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
- name resolution in scenarios in which conventional DNS name
- resolution is not possible. LLMNR supports all current and future
- DNS formats, types and classes, while operating on a separate port
- from DNS, and with a distinct resolver cache. Since LLMNR only
- operates on the local link, it cannot be considered a substitute for
- DNS.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
- 1.2 Terminology ..................................... 4
-2. Name Resolution Using LLMNR ........................... 4
- 2.1 LLMNR Packet Format ............................. 6
- 2.2 Sender Behavior ................................. 9
- 2.3 Responder Behavior .............................. 10
- 2.4 Unicast Queries and Responses ................... 12
- 2.5 Off-link Detection .............................. 13
- 2.6 Responder Responsibilities ...................... 13
- 2.7 Retransmission and Jitter ....................... 14
- 2.8 DNS TTL ......................................... 15
- 2.9 Use of the Authority and Additional Sections .... 15
-3. Usage model ........................................... 16
- 3.1 LLMNR Configuration ............................. 17
-4. Conflict Resolution ................................... 18
- 4.1 Uniqueness Verification ......................... 19
- 4.2 Conflict Detection and Defense .................. 20
- 4.3 Considerations for Multiple Interfaces .......... 21
- 4.4 API issues ...................................... 22
-5. Security Considerations ............................... 22
- 5.1 Denial of Service ............................... 23
- 5.2 Spoofing ...............,........................ 23
- 5.3 Authentication .................................. 24
- 5.4 Cache and Port Separation ....................... 25
-6. IANA considerations ................................... 25
-7. Constants ............................................. 25
-8. References ............................................ 25
- 8.1 Normative References ............................ 25
- 8.2 Informative References .......................... 26
-Acknowledgments .............................................. 27
-Authors' Addresses ........................................... 28
-Intellectual Property Statement .............................. 28
-Disclaimer of Validity ....................................... 29
-Copyright Statement .......................................... 29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-1. Introduction
-
- This document discusses Link Local Multicast Name Resolution (LLMNR),
- which is based on the DNS packet format and supports all current and
- future DNS formats, types and classes. LLMNR operates on a separate
- port from the Domain Name System (DNS), with a distinct resolver
- cache.
-
- The goal of LLMNR is to enable name resolution in scenarios in which
- conventional DNS name resolution is not possible. Usage scenarios
- (discussed in more detail in Section 3.1) include situations in which
- hosts are not configured with the address of a DNS server; where the
- DNS server is unavailable or unreachable; where there is no DNS
- server authoritative for the name of a host, or where the
- authoritative DNS server does not have the desired RRs, as described
- in Section 2.
-
- Since LLMNR only operates on the local link, it cannot be considered
- a substitute for DNS. 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.4.
-
- Propagation of LLMNR packets on the local link is considered
- sufficient to enable name resolution in small networks. In such
- networks, if a network has a gateway, then typically the network is
- able to provide DNS server 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
- occur if LLMNR deployment is successful, the need arises for
- multicast name resolution beyond the link-scope, or multicast routing
- becomes ubiquitous. For example, expanded support for multicast name
- resolution might be required for mobile ad-hoc networks.
-
- Once we have experience in LLMNR deployment in terms of
- administrative issues, usability and impact on the network, it will
- be possible to reevaluate which multicast scopes are appropriate for
- use with multicast name resolution. IPv4 administratively scoped
- multicast usage is specified in "Administratively Scoped IP
- Multicast" [RFC2365].
-
- 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.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-1.1. Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
- and "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-1.2. Terminology
-
- This document assumes familiarity with DNS terminology defined in
- [RFC1035]. Other terminology used in this document includes:
-
-Positively Resolved
- Responses with RCODE set to zero are referred to in this document
- as "positively resolved".
-
-Routable Address
- An address other than a Link-Local address. This includes globally
- routable addresses, as well as private addresses.
-
-Reachable
- An LLMNR responder considers one of its addresses reachable over a
- link if it will respond to an ARP or Neighbor Discovery query for
- that address received on that link.
-
-Responder
- A host that listens to LLMNR queries, and responds to those for
- which it is authoritative.
-
-Sender
- A host that sends an LLMNR query.
-
-UNIQUE
- There are some scenarios when multiple responders may respond to
- the same query. There are other scenarios when only one responder
- may respond to a query. Names for which only a single responder is
- anticipated are referred to as UNIQUE. Name uniqueness is
- configured on the responder, and therefore uniqueness verification
- is the responder's responsibility.
-
-2. Name Resolution Using LLMNR
-
- LLMNR is a peer-to-peer name resolution protocol that is not intended
- as a replacement for DNS. LLMNR queries are sent to and received on
- port 5355. The IPv4 link-scope multicast address a given responder
- listens to, and to which a sender sends queries, is 224.0.0.252. The
- IPv6 link-scope multicast address a given responder listens to, and
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.
-
- 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, if only to verify the 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 interfaces, at all times. Enabling LLMNR for use in situations
- where a DNS server has been configured will result in a change in
- default behavior without a simultaneous update to configuration
- information. Where this is considered undesirable, LLMNR SHOULD NOT
- be enabled by default, so that hosts will neither listen on the link-
- scope multicast address, nor will they send queries to that address.
-
- By default, LLMNR queries MAY be sent only when one of the following
- conditions are met:
-
- [1] No manual or automatic DNS configuration has been performed.
- If DNS server address(es) have been configured, then LLMNR
- SHOULD NOT be used as the primary name resolution mechanism,
- although it MAY be used as a secondary name resolution
- mechanism. A dual stack host SHOULD attempt to reach DNS
- servers overall protocols on which DNS server address(es) are
- configured, prior to sending LLMNR queries. For dual stack
- hosts configured with DNS server address(es) for one protocol
- but not another, this inplies that DNS queries SHOULD be sent
- over the protocol configured with a DNS server, prior to
- sending LLMNR queries.
-
- [2] All attempts to resolve the name via DNS on all interfaces
- have failed after exhausting the searchlist. This can occur
- because DNS servers did not respond, or because they
- responded to DNS queries with RCODE=3 (Authoritative Name
- Error) or RCODE=0, and an empty answer section. Where a
- single resolver call generates DNS queries for A and AAAA RRs,
- an implementation MAY choose not to send LLMNR queries if any
- of the DNS queries is successful. An LLMNR query SHOULD only
- be sent for the originally requested name; a searchlist
- is not used to form additional LLMNR queries.
-
- While these conditions are necessary for sending an LLMNR query, they
- are not sufficient. While an LLMNR sender MAY send a query for any
- name, it also MAY impose additional conditions on sending LLMNR
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- queries. For example, a sender configured with a DNS server MAY send
- LLMNR queries only for unqualified names and for fully qualified
- domain names within configured zones.
-
- A typical sequence of events for LLMNR usage is as follows:
-
- [a] DNS servers are not configured or attempts to resolve the
- name via DNS have failed, after exhausting the searchlist.
- Also, the name to be queried satisfies the restrictions
- imposed by the implementation.
-
- [b] An LLMNR sender sends an LLMNR query to the link-scope
- multicast address(es), unless a unicast query is indicated,
- as specified in Section 2.4.
-
- [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.4.
-
- [d] Upon reception of the response, the sender processes it.
-
- The sections that follow provide further details on sender and
- responder behavior.
-
-2.1. LLMNR Packet Format
-
- LLMNR is based on the DNS packet format defined in [RFC1035] Section
- 4 for both queries and responses. LLMNR implementations SHOULD send
- UDP queries and responses only as large as are known to be
- permissible without causing fragmentation. When in doubt a maximum
- packet size of 512 octets SHOULD be used. LLMNR implementations MUST
- accept UDP queries and responses as large as the smaller of the link
- MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
- octets for the header, VLAN tag and CRC).
-
-2.1.1. LLMNR Header Format
-
- LLMNR queries and responses utilize the DNS header format defined in
- [RFC1035] with exceptions noted below:
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
-ID A 16 bit identifier assigned by the program that generates any kind
- of query. This identifier is copied from the query to the response
- and can be used by the sender to match responses to outstanding
- queries. The ID field in a query SHOULD be set to a pseudo-random
- value. For advice on generation of pseudo-random values, please
- consult [RFC1750].
-
-QR Query/Response. A one bit field, which if set indicates that the
- message is an LLMNR response; if clear then the message is an LLMNR
- query.
-
-OPCODE
- A four bit field that specifies the kind of query in this message.
- This value is set by the originator of a query and copied into the
- response. This specification defines the behavior of standard
- queries and responses (opcode value of zero). Future
- specifications may define the use of other opcodes with LLMNR.
- LLMNR senders and responders MUST support standard queries (opcode
- value of zero). LLMNR queries with unsupported OPCODE values MUST
- be silently discarded by responders.
-
-C Conflict. When set within a request, the 'C'onflict bit indicates
- that a sender has received multiple LLMNR responses to this query.
- In an LLMNR response, if the name is considered UNIQUE, then the
- 'C' bit is clear, otherwise it is set. LLMNR senders do not
- retransmit queries with the 'C' bit set. Responders MUST NOT
- respond to LLMNR queries with the 'C' bit set, but may start the
- uniqueness verification process, as described in Section 4.2.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-TC TrunCation - specifies that this message was truncated due to
- length greater than that permitted on the transmission channel.
- The TC bit MUST NOT be set in an LLMNR query and if set is ignored
- by an LLMNR responder. If the TC bit is set in an LLMNR response,
- then the sender SHOULD discard the response and resend the LLMNR
- query over TCP using the unicast address of the responder as the
- destination address. See [RFC2181] and Section 2.4 of this
- specification for further discussion of the TC bit.
-
-T Tentative. The 'T'entative bit is set in a response if the
- responder is authoritative for the name, but has not yet verified
- the uniqueness of the name. A responder MUST ignore the 'T' bit in
- a query, if set. A response with the 'T' bit set is silently
- discarded by the sender, except if it is a uniqueness query, in
- which case a conflict has been detected and a responder MUST
- resolve the conflict as described in Section 4.1.
-
-Z Reserved for future use. Implementations of this specification
- MUST set these bits to zero in both queries and responses. If
- these bits are set in a LLMNR query or response, implementations of
- this specification MUST ignore them. Since reserved bits could
- conceivably be used for different purposes than in DNS,
- implementors are advised not to enable processing of these bits in
- an LLMNR implementation starting from a DNS code base.
-
-RCODE
- Response code -- this 4 bit field is set as part of LLMNR
- responses. In an LLMNR query, the sender MUST set RCODE to zero;
- the responder ignores the RCODE and assumes it to be zero. The
- response to a multicast LLMNR query MUST have RCODE set to zero. A
- sender MUST silently discard an LLMNR response with a non-zero
- RCODE sent in response to a multicast query.
-
- If an LLMNR responder is authoritative for the name in a multicast
- query, but an error is encountered, the responder SHOULD send an
- LLMNR response with an RCODE of zero, no RRs in the answer section,
- and the TC bit set. This will cause the query to be resent using
- TCP, and allow the inclusion of a non-zero RCODE in the response to
- the TCP query. Responding with the TC bit set is preferable to not
- sending a response, since it enables errors to be diagnosed.
- Errors include those defined in [RFC2845], such as BADSIG(16),
- BADKEY(17) and BADTIME(18).
-
- Since LLMNR responders only respond to LLMNR queries for names for
- which they are authoritative, LLMNR responders MUST NOT respond
- with an RCODE of 3; instead, they should not respond at all.
-
- LLMNR implementations MUST support EDNS0 [RFC2671] and extended
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- RCODE values.
-
-QDCOUNT
- An unsigned 16 bit integer specifying the number of entries in the
- question section. A sender MUST place only one question into the
- question section of an LLMNR query. LLMNR responders MUST silently
- discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
- MUST silently discard LLMNR responses with QDCOUNT not equal to
- one.
-
-ANCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the answer section. LLMNR responders MUST silently
- discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
- An unsigned 16 bit integer specifying the number of name server
- resource records in the authority records section. Authority
- record section processing is described in Section 2.9. LLMNR
- responders MUST silently discard LLMNR queries with NSCOUNT not
- equal to zero.
-
-ARCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the additional records section. Additional record
- section processing is described in Section 2.9.
-
-2.2. Sender Behavior
-
- A sender MAY send an LLMNR query for any legal resource record type
- (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
- As described in Section 2.4, a sender MAY also send a unicast query.
-
- The sender MUST anticipate receiving no replies to some LLMNR
- queries, in the event that no responders are available within the
- link-scope. If no response is received, a resolver treats it as a
- response that the name does not exist (RCODE=3 is returned). A
- sender can handle duplicate responses by discarding responses with a
- source IP address and ID field that duplicate a response already
- received.
-
- When multiple valid LLMNR responses are received with the 'C' bit
- set, they SHOULD be concatenated and treated in the same manner that
- multiple RRs received from the same DNS server would be. However,
- responses with the 'C' bit set SHOULD NOT be concatenated with
- responses with the 'C' bit clear; instead, only the responses with
- the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
- received along with error response(s), then the error responses are
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- silently discarded.
-
- If error responses are received from both DNS and LLMNR, then the
- lowest RCODE value should be returned. For example, if either DNS or
- LLMNR receives a response with RCODE=0, then this should returned to
- the caller.
-
- 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.
-
-2.3. Responder Behavior
-
- An LLMNR 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. An SOA RR is synthesized only when a
- responder has another RR in addition to the SOA RR; 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.
-
- For example, a host configured to have computer name "host1" and to
- be a member of the "example.com" domain, and with IPv4 address
- 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
- authoritative for the following records:
-
- host1. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- host1.example.com. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- 1.2.0.192.in-addr.arpa. IN PTR host1.
- IN PTR host1.example.com.
-
- 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
- ip6.arpa IN PTR host1. (line split for formatting reasons)
- IN PTR host1.example.com.
-
- An LLMNR responder might be further manually configured with the name
- of a local mail server with an MX RR included in the "host1." and
- "host1.example.com." records.
-
- In responding to queries:
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
- address(es) defined in Section 2, and on UDP and TCP port 5355 on
- the unicast address(es) that could be set as the source address(es)
- when the responder responds to the LLMNR query.
-
-[b] Responders MUST direct responses to the port from which the query
- was sent. When queries are received via TCP this is an inherent
- part of the transport protocol. For queries received by UDP the
- responder MUST take note of the source port and use that as the
- destination port in the response. Responses MUST always be sent
- from the port to which they were directed.
-
-[c] Responders MUST respond to LLMNR queries for names and addresses
- they are authoritative for. This applies to both forward and
- reverse lookups, with the exception of queries with the 'C' bit
- set, which do not elicit a response.
-
-[d] Responders MUST NOT respond to LLMNR queries for names they are not
- authoritative for.
-
-[e] Responders MUST NOT respond using data from the LLMNR or DNS
- resolver cache.
-
-[f] 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.
-
-[g] If a responder is authoritative for a name, it MUST respond with
- RCODE=0 and an empty answer section, if the type of query does not
- match a RR that the responder has.
-
- 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 apex except
- for the branches delegated into separate zones. Contrary to
- conventional DNS terminology, an LLMNR responder is authoritative
- only for the zone apex.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- For example the host "foo.example.com." is not authoritative for the
- name "child.foo.example.com." unless the host is configured with
- multiple names, including "foo.example.com." and
- "child.foo.example.com.". As a result, "foo.example.com." cannot
- reply to an LLMNR query for "child.foo.example.com." with RCODE=3
- (authoritative name error). The purpose of limiting the name
- authority scope of a responder is to prevent complications that could
- be caused by coexistence of two or more hosts with the names
- representing child and parent (or grandparent) nodes in the DNS tree,
- for example, "foo.example.com." and "child.foo.example.com.".
-
- Without the restriction on authority an LLMNR query for an A resource
- record for the name "child.foo.example.com." would result in two
- authoritative responses: RCODE=3 (authoritative name error) received
- from "foo.example.com.", and a requested A record - from
- "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
- hosts could perform a dynamic update of the parent (or grandparent)
- zone with a delegation to a child zone; for example a host
- "child.foo.example.com." could send a dynamic update for the NS and
- glue A record to "foo.example.com.". However, this approach
- significantly complicates implementation of LLMNR and would not be
- acceptable for lightweight hosts.
-
-2.4. Unicast Queries and Responses
-
- 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
-
- [b] The sender queries for a PTR RR of a fully formed IP address
- within the "in-addr.arpa" or "ip6.arpa" zones.
-
- Unicast LLMNR queries MUST be done using TCP and the responses MUST
- be sent using the same TCP connection as the query. Senders MUST
- support sending TCP queries, and responders MUST support listening
- for TCP queries. 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 MUST be silently discarded.
-
- If TCP connection setup cannot be completed in order to send a
- unicast TCP query, this is treated 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).
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-2.5. "Off link" Detection
-
- A sender MUST select a source address for LLMNR queries that is
- assigned on the interface on which the query is sent. The
- destination address of an LLMNR query MUST be a link-scope multicast
- address or a unicast address.
-
- A responder MUST select a source address for responses that is
- assigned on the interface on which the query was received. The
- destination address of an LLMNR response MUST be a 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
- discarded.
-
- Section 2.4 discusses use of TCP for LLMNR queries and responses. In
- composing an LLMNR query using TCP, the sender MUST set the Hop Limit
- field in the IPv6 header and the TTL field in the IPv4 header of the
- response to one (1). 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.
-
- For UDP queries and responses, the Hop Limit field in the IPv6 header
- and the TTL field in the IPV4 header MAY be set to any value.
- However, it is RECOMMENDED that the value 255 be used for
- compatibility with Apple Bonjour [Bonjour].
-
- Implementation note:
-
- In the sockets API for IPv4 [POSIX], the IP_TTL and
- IP_MULTICAST_TTL socket options are used to set the TTL of
- outgoing unicast and multicast packets. The IP_RECVTTL socket
- option is available on some platforms to retrieve the IPv4 TTL of
- received packets with recvmsg(). [RFC2292] specifies similar
- options for setting and retrieving the IPv6 Hop Limit.
-
-2.6. 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.
- IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local
- addresses are defined in [RFC2373]. In particular:
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- [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.
-
- Where multiple addresses represent valid responses to a query, the
- order in which the addresses are returned is as follows:
-
- [d] If the source address of the query is a link-scope address,
- then the responder SHOULD include a link-scope address first
- in the response, if available.
-
- [e] If the source address of the query is a routable address,
- then the responder MUST include a routable address first
- in the response, if available.
-
-2.7. Retransmission and Jitter
-
- An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
- when to retransmit an LLMNR query. An LLMNR sender SHOULD either
- estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
- high initial timeout. Suggested constants are described in Section
- 7.
-
- If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
- then a sender SHOULD repeat the transmission of the query in order to
- assure that it was received by a host capable of responding to it,
- while increasing the value of LLMNR_TIMEOUT exponentially. An LLMNR
- query SHOULD NOT be sent more than three times.
-
- Where LLMNR queries are sent using TCP, retransmission is handled by
- the transport layer. Queries with the 'C' bit set MUST be sent using
- multicast UDP and MUST NOT be retransmitted.
-
- An LLMNR sender cannot know in advance if a query sent using
- multicast will receive no response, one response, or more than one
- response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
- has been received, or if it is necessary to collect all potential
- responses, such as if a uniqueness verification query is being made.
- Otherwise an LLMNR sender SHOULD consider a multicast query answered
- after the first response is received, if that response has the 'C'
- bit clear.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- However, if the first response has the 'C' bit set, then the sender
- SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
- responses. When multiple valid answers are received, they may first
- be concatenated, and then treated in the same manner that multiple
- RRs received from the same DNS server would. A unicast query sender
- considers the query answered after the first response is received, so
- that it only waits for LLMNR_TIMEOUT if no response has been
- received.
-
- Since it is possible for a response with the 'C' bit clear to be
- followed by a response with the 'C' bit set, an LLMNR sender SHOULD
- be prepared to process additional responses for the purposes of
- conflict detection and LLMNR_TIMEOUT estimation, even after it has
- considered a query answered.
-
- In order to avoid synchronization, the transmission of each LLMNR
- query and response SHOULD delayed by a time randomly selected from
- the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
- responders responding with names which they have previously
- determined to be UNIQUE (see Section 4 for details).
-
-2.8. DNS TTL
-
- The responder should insert a pre-configured TTL value in the records
- returned in an LLMNR 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.9. 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 TTL of this record is set from the minimum of the
- MINIMUM field of the SOA record and the TTL of the SOA itself, and
- indicates how long a resolver may cache the negative answer. The
- owner name of the SOA record (MNAME) MUST be set to the query name.
- The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- by senders. Negative responses without SOA records SHOULD NOT be
- cached.
-
- In LLMNR, the additional section is primarily intended for use by
- EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set,
- senders MAY only include pseudo RR-types in the additional section of
- a query; unless the 'C' bit is set, responders MUST ignore the
- additional section of queries containing other RR types.
-
- In queries where the 'C' bit is set, the sender SHOULD include the
- conflicting RRs in the additional section. Since conflict
- notifications are advisory, responders SHOULD log information from
- the additional section, but otherwise MUST ignore the additional
- section.
-
- 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.
-
-3. Usage Model
-
- Since LLMNR is a secondary name resolution mechanism, its usage is in
- part determined by the behavior of DNS implementations. This
- document does not specify any changes to DNS resolver behavior, such
- as searchlist processing or retransmission/failover policy. However,
- robust DNS resolver implementations are more likely to avoid
- unnecessary LLMNR queries.
-
- As noted in [DNSPerf], even when DNS servers are configured, a
- significant fraction of DNS queries do not receive a response, or
- result in negative responses due to missing inverse mappings or NS
- records that point to nonexistent or inappropriate hosts. This has
- the potential to result in a large number of unnecessary LLMNR
- queries.
-
- [RFC1536] describes common DNS implementation errors and fixes. If
- the proposed fixes are implemented, unnecessary LLMNR queries will be
- reduced substantially, and so implementation of [RFC1536] is
- recommended.
-
- For example, [RFC1536] Section 1 describes issues with retransmission
- and recommends implementation of a retransmission policy based on
- round trip estimates, with exponential backoff. [RFC1536] Section 4
- describes 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
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- 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. 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
- DNS server over IPv4, while remaining unconfigured with a DNS server
- suitable for use over IPv6.
-
- In these situations, a dual stack host will send AAAA queries to the
- configured DNS server over IPv4. However, an IPv6-only host
- unconfigured with a DNS server suitable for use over IPv6 will be
- unable to resolve names using DNS. Automatic IPv6 DNS configuration
- mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
- deployed, and not all DNS servers support IPv6. Therefore lack of
- IPv6 DNS configuration may be a common problem in the short term, and
- LLMNR may prove useful in enabling link-local name resolution over
- IPv6.
-
- Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
- IPv6-only hosts may not be configured with a DNS server. Where there
- is no DNS server authoritative for the name of a host or the
- authoritative DNS server does not support dynamic client update over
- IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
- be able to do DNS dynamic update, and other hosts will not be able to
- resolve its name.
-
- For example, if the configured DNS server responds to a AAAA RR query
- sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
- RCODE=0 and an empty answer section, then a AAAA RR query sent using
- LLMNR over IPv6 may be successful in resolving the name of an
- IPv6-only host on the local link.
-
- Similarly, if a DHCPv4 server is available providing DNS server
- configuration, and DNS server(s) exist which are authoritative for
- the A RRs of local hosts and support either dynamic client update
- over IPv4 or 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
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- 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 using the Name Service Search Option (NSSO) for DHCP
- [RFC2937], using the LLMNR Enable Option code carried in the NSSO
- data.
-
- It is possible that DNS configuration mechanisms will go in and out
- of service. In these circumstances, it is possible for hosts within
- an administrative domain to be inconsistent in their DNS
- configuration.
-
- For example, where DHCP is used for configuring DNS servers, one or
- more DHCP servers can fail. As a result, hosts configured prior to
- the outage will be configured with a DNS server, while hosts
- configured after the outage will not. Alternatively, it is possible
- for the DNS configuration mechanism to continue functioning while
- configured DNS servers fail.
-
- An outage in the DNS configuration mechanism may result in hosts
- continuing to use LLMNR even once the outage is repaired. Since
- LLMNR only enables linklocal name resolution, this represents a
- degradation in capabilities. As a result, hosts without a configured
- DNS server may wish to periodically attempt to obtain DNS
- configuration if permitted by the configuration mechanism in use. In
- the absence of other guidance, a default retry interval of one (1)
- minute is RECOMMENDED.
-
-4. Conflict Resolution
-
- By default, a responder SHOULD be configured to behave as though its
- name is UNIQUE on each interface on which LLMNR is enabled. However,
- it is also possible to configure multiple responders to be
- authoritative for the same name. For example, multiple responders
- MAY respond to a query for an A or AAAA type record for a cluster
- name (assigned to multiple hosts in the cluster).
-
- To detect duplicate use of a name, an administrator can use a name
- resolution 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.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-4.1. Uniqueness Verification
-
- Prior to sending an LLMNR response with the 'T' bit clear, a
- responder configured with a UNIQUE name MUST verify that there is no
- other host within the scope of LLMNR query propagation that is
- authoritative for the same name on that interface.
-
- Once a responder has verified that its name is UNIQUE, if it receives
- an LLMNR query for that name, with the 'C' bit clear, it MUST
- respond, with the 'T' bit clear. Prior to verifying that its name is
- UNIQUE, a responder MUST set the 'T' bit in responses.
-
- Uniqueness verification is carried out when the host:
-
- - starts up or is rebooted
- - wakes from sleep (if the network interface was inactive
- during sleep)
- - is configured to respond to LLMNR queries on an interface
- enabled for transmission and reception of IP traffic
- - is configured to respond to LLMNR queries using additional
- UNIQUE resource records
- - verifies the acquisition of a new IP address and configuration
- on an interface
-
- To verify uniqueness, a responder MUST send an LLMNR query with the
- 'C' bit clear, over all protocols on which it responds to LLMNR
- queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
- uniqueness of a name by sending a query for the name with type='ANY'.
-
- If no response is received, the sender retransmits the query, as
- specified in Section 2.7. If a response is received, the sender MUST
- check if the source address matches the address of any of its
- interfaces; if so, then the response is not considered a conflict,
- since it originates from the sender. To avoid triggering conflict
- detection, a responder that detects that it is connected to the same
- link on multiple interfaces SHOULD set the 'C' bit in responses.
-
- If a response is received with the 'T' bit clear, the responder MUST
- NOT use the name in response to LLMNR queries received over any
- protocol (IPv4 or IPv6). If a response is received with the 'T' bit
- set, the responder MUST check if the source IP address in the
- response, interpreted as an unsigned integer, is less than the source
- IP address in the query. If so, the responder MUST NOT use the name
- in response to LLMNR queries received over any protocol (IPv4 or
- IPv6). For the purpose of uniqueness verification, the contents of
- the answer section in a response is irrelevant.
-
- Periodically carrying out uniqueness verification in an attempt to
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- detect name conflicts is not necessary, wastes network bandwidth, and
- may actually be detrimental. For example, if network links are
- joined only briefly, and are separated again before any new
- communication is initiated, temporary conflicts are benign and no
- forced reconfiguration is required. LLMNR responders SHOULD NOT
- periodically attempt uniqueness verification.
-
-4.2. Conflict Detection and Defense
-
- Hosts on disjoint network links may configure the same name for use
- with LLMNR. If these separate network links are later joined or
- bridged together, then there may be multiple hosts which are now on
- the same link, trying to use the same name.
-
- In order to enable ongoing detection of name conflicts, when an LLMNR
- sender receives multiple LLMNR responses to a query, it MUST check if
- the 'C' bit is clear in any of the responses. If so, the sender
- SHOULD send another query for the same name, type and class, this
- time with the 'C' bit set, with the potentially conflicting resource
- records included in the additional section.
-
- Queries with the 'C' bit set are considered advisory and responders
- MUST verify the existence of a conflict before acting on it. A
- responder receiving a query with the 'C' bit set MUST NOT respond.
-
- If the query is for a UNIQUE name, then the responder MUST send its
- own query for the same name, type and class, with the 'C' bit clear.
- If a response is received, the sender MUST check if the source
- address matches the address of any of its interfaces; if so, then the
- response is not considered a conflict, since it originates from the
- sender. To avoid triggering conflict detection, a responder that
- detects that it is connected to the same link on multiple interfaces
- SHOULD set the 'C' bit in responses.
-
- An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
- log them. Upon detecting a conflict, an LLMNR responder MUST
- immediately stop using the conflicting name in response to LLMNR
- queries received over any supported protocol, if the source IP
- address in the response, interpreted as an unsigned integer, is less
- than the source IP address in the uniqueness verification query.
-
- After stopping the use of a name, the responder MAY elect to
- configure a new name. However, since name reconfiguration may be
- disruptive, this is not required, and a responder may have been
- configured to respond to multiple names so that alternative names may
- already be available. A host that has stopped the use of a name may
- attempt uniqueness verification again after the expiration of the TTL
- of the conflicting response.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-4.3. Considerations for Multiple Interfaces
-
- A multi-homed host may elect to configure LLMNR on only one of its
- active interfaces. In many situations this will be adequate.
- However, should a host need to configure LLMNR on more than one of
- its active interfaces, there are some additional precautions it MUST
- take. Implementers who are not planning to support LLMNR on multiple
- interfaces simultaneously may skip this section.
-
- Where a host is configured to issue LLMNR queries on more than one
- interface, each interface maintains its own independent LLMNR
- resolver cache, containing the responses to LLMNR queries.
-
- A multi-homed host checks the uniqueness of UNIQUE records as
- described in Section 4. The situation is illustrated in figure 1.
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. Link-scope name conflict
-
- In this situation, the multi-homed myhost will probe for, and defend,
- its host name on both interfaces. A conflict will be detected on one
- interface, but not the other. The multi-homed myhost will not be
- able to respond with a host RR for "myhost" on the interface on the
- right (see Figure 1). The multi-homed host may, however, be
- configured to use the "myhost" name on the interface on the left.
-
- Since names are only unique per-link, hosts on different links could
- be using the same name. If an LLMNR client sends requests over
- multiple interfaces, and receives replies from more than one, the
- result returned to the client is defined by the implementation. The
- situation is illustrated in figure 2.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
- If host myhost is configured to use LLMNR on both interfaces, it will
- send LLMNR queries on both interfaces. When host myhost sends a
- query for the host RR for name "A" it will receive a response from
- hosts on both interfaces.
-
- Host myhost cannot distinguish between the situation shown in Figure
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- 2, and that shown in Figure 3 where no conflict exists.
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
- This illustrates that the proposed name conflict resolution mechanism
- does not support detection or resolution of conflicts between hosts
- on different links. This problem can also occur with DNS when a
- multi-homed host is connected to two different networks with
- separated name spaces. It is not the intent of this document to
- address the issue of uniqueness of names within DNS.
-
-4.4. API Issues
-
- [RFC2553] provides an API which can partially solve the name
- ambiguity problem for applications written to use this API, since the
- sockaddr_in6 structure exposes the scope within which each scoped
- address exists, and this structure can be used for both IPv4 (using
- v4-mapped IPv6 addresses) and IPv6 addresses.
-
- Following the example in Figure 2, an application on 'myhost' issues
- the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
- ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
- interfaces and the resolver library will return a list containing
- multiple addrinfo structures, each with an associated sockaddr_in6
- structure. This list will thus contain the IPv4 and IPv6 addresses
- of both hosts responding to the name 'A'. Link-local addresses will
- have a sin6_scope_id value that disambiguates which interface is used
- to reach the address. Of course, to the application, Figures 2 and 3
- are still indistinguishable, but this API allows the application to
- communicate successfully with any address in the list.
-
-5. Security Considerations
-
- LLMNR is a peer-to-peer name resolution protocol designed for use on
- the local link. While LLMNR limits the vulnerability of responders
- to off-link senders, it is possible for an off-link responder to
- reach a sender.
-
- In scenarios such as public "hotspots" attackers can be present on
- the same link. These threats are most serious in wireless networks
- such as 802.11, since attackers on a wired network will require
- physical access to the network, while wireless attackers may mount
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- attacks from a distance. Link-layer security such as [IEEE-802.11i]
- can be of assistance against these threats if it is available.
-
- This section details security measures available to mitigate threats
- from on and off-link attackers.
-
-5.1. Denial of Service
-
- Attackers may take advantage of LLMNR conflict detection by
- allocating the same name, denying service to other LLMNR responders
- and possibly allowing an attacker to receive packets destined for
- other hosts. By logging conflicts, LLMNR responders can provide
- forensic evidence of these attacks.
-
- An attacker may spoof LLMNR queries from a victim's address in order
- to mount a denial of service attack. Responders setting the IPv6 Hop
- Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
- response may be able to reach the victim across the Internet.
-
- While LLMNR responders only respond to queries for which they are
- authoritative and LLMNR does not provide wildcard query support, an
- LLMNR response may be larger than the query, and an attacker can
- generate multiple responses to a query for a name used by multiple
- responders. A sender may protect itself against unsolicited
- responses by silently discarding them as rapidly as possible.
-
-5.2. Spoofing
-
- LLMNR is designed to prevent reception of queries sent by an off-link
- attacker. LLMNR requires that responders receiving UDP queries check
- that they are sent to a link-scope multicast address. However, it is
- possible that some routers may not properly implement link-scope
- multicast, or that link-scope multicast addresses may leak into the
- multicast routing system. To prevent successful setup of TCP
- connections by an off-link sender, responders receiving a TCP SYN
- reply with a TCP SYN-ACK with TTL set to one (1).
-
- While it is difficult for an off-link attacker to send an LLMNR query
- to a responder, it is possible for an off-link attacker to spoof a
- response to a query (such as an A or AAAA query for a popular
- Internet host), and by using a TTL or Hop Limit field larger than one
- (1), for the forged response to reach the LLMNR sender. Since the
- forged response will only be accepted if it contains a matching ID
- field, choosing a pseudo-random ID field within queries provides some
- protection against off-link responders.
-
- Since LLMNR queries can be sent when DNS server(s) do not respond, an
- attacker can execute a denial of service attack on the DNS server(s)
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- and then poison the LLMNR cache by responding to an LLMNR query with
- incorrect information. As noted in "Threat Analysis of the Domain
- Name System (DNS)" [RFC3833] these threats also exist with DNS, since
- DNS response spoofing tools are available that can allow an attacker
- to respond to a query more quickly than a distant DNS server.
- However, while switched networks or link layer security may make it
- difficult for an on-link attacker to snoop unicast DNS queries,
- multicast LLMNR queries are propagated to all hosts on the link,
- making it possible for an on-link attacker to spoof LLMNR responses
- without having to guess the value of the ID field in the query.
-
- Since LLMNR queries are sent and responded to on the local-link, an
- attacker will need to respond more quickly to provide its own
- response prior to arrival of the response from a legitimate
- responder. If an LLMNR query is sent for an off-link host, spoofing
- a response in a timely way is not difficult, since a legitimate
- response will never be received.
-
- Limiting the situations in which LLMNR queries are sent, as described
- in Section 2, is the best protection against these attacks. If LLMNR
- is given higher priority than DNS among the enabled name resolution
- mechanisms, a denial of service attack on the DNS server would not be
- necessary in order to poison the LLMNR cache, since LLMNR queries
- would be sent even when the DNS server is available. In addition,
- the LLMNR cache, once poisoned, would take precedence over the DNS
- cache, eliminating the benefits of cache separation. As a result,
- LLMNR is only used as a name resolution mechanism of last resort.
-
-5.3. Authentication
-
- LLMNR is a peer-to-peer name resolution protocol, and as a result,
- it is often deployed in situations where no trust model can be
- assumed. This makes it difficult to apply existing DNS security
- mechanisms to LLMNR.
-
- LLMNR does not support "delegated trust" (CD or AD bits). As a
- result, unless LLMNR senders are DNSSEC aware, it is not feasible to
- use DNSSEC [RFC4033] with LLMNR.
-
- If authentication is desired, and a pre-arranged security
- configuration is possible, then the following security mechanisms may
- be used:
-
-[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
- [RFC2931] security mechanisms. "DNS Name Service based on Secure
- Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
- the use of TSIG to secure LLMNR responses, based on group keys.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[b] IPsec ESP with a null-transform MAY be used to authenticate unicast
- LLMNR queries and responses or LLMNR responses to multicast
- queries. In a small network without a certificate authority, this
- can be most easily accomplished through configuration of a group
- pre-shared key for trusted hosts.
-
- Where these mechanisms cannot be supported, responses to LLMNR
- queries may be unauthenticated.
-
-5.4. Cache and Port Separation
-
- In order to prevent responses to LLMNR queries from polluting the DNS
- cache, LLMNR implementations MUST use a distinct, isolated cache for
- LLMNR on each interface. The use of separate caches is most
- effective when LLMNR is used as a name resolution mechanism of last
- resort, since this minimizes the opportunities for poisoning the
- LLMNR cache, and decreases reliance on it.
-
- LLMNR operates on a separate port from DNS, reducing the likelihood
- that a DNS server will unintentionally respond to an LLMNR query.
-
-6. IANA Considerations
-
- This specification creates one new name space: the reserved bits in
- the LLMNR header. These are allocated by IETF Consensus, in
- accordance with BCP 26 [RFC2434].
-
- LLMNR requires allocation of port 5355 for both TCP and UDP.
-
- LLMNR requires allocation of link-scope multicast IPv4 address
- 224.0.0.252, as well as link-scope multicast IPv6 address
- FF02:0:0:0:0:0:1:3.
-
-7. Constants
-
- The following timing constants are used in this protocol; they are
- not intended to be user configurable.
-
- JITTER_INTERVAL 100 ms
- LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
- 100 ms (IEEE 802 media, including IEEE 802.11)
-
-8. References
-
-8.1. Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 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.
-
-[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.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
-[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
-8.2. Informative References
-
-[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
- (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
- June 2005.
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
- Caching", IEEE/ACM Transactions on Networking, Volume 10,
- Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers",
- Internet draft (work in progress), draft-ietf-ipv6-dns-
- discovery-07.txt, October 2002.
-
-[IEEE-802.11i]
- Institute of Electrical and Electronics Engineers, "Supplement
- to Standard for Telecommunications and Information Exchange
- Between Systems - LAN/MAN Specific Requirements - Part 11:
- Wireless LAN Medium Access Control (MAC) and Physical Layer
- (PHY) Specifications: Specification for Enhanced Security",
- IEEE 802.11i, July 2004.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 26]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[LLMNREnable]
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
- Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
- Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
- 2004, Phoenix Park, Korea, February 9-11, 2004.
-
-[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
- Portable Operating System Interface (POSIX). Open Group
- Technical Standard: Base Specifications, Issue 6, December
- 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
- Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
- Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
- 2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
- System (DNS)", RFC 3833, August 2004.
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "DNS Security Introduction and Requirement", RFC 4033, March
- 2005.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 27]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-Acknowledgments
-
- This work builds upon original work done on multicast DNS by Bill
- Manning and Bill Woodcock. Bill Manning's work was funded under
- DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
- their contribution to the current specification. Constructive input
- has also been received from Mark Andrews, Rob Austein, Randy Bush,
- Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
- Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
- Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
- Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
- St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
- Bernard Aboba
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 706 6605
- EMail: bernarda@microsoft.com
-
- Dave Thaler
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 703 8835
- EMail: dthaler@microsoft.com
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 28]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-Open Issues
-
- Open issues with this specification are tracked on the following web
- site:
-
- http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 29]
-
-
+++ /dev/null
-
-
-
-Network Working Group B. Laurie
-Internet-Draft G. Sisson
-Expires: August 5, 2006 R. Arends
- Nominet
- February 2006
-
-
- DNSSEC Hash Authenticated Denial of Existence
- draft-ietf-dnsext-nsec3-04
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 5, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- The DNS Security Extensions introduces the NSEC resource record for
- authenticated denial of existence. This document introduces a new
- resource record as an alternative to NSEC that provides measures
- against zone enumeration and allows for gradual expansion of
- delegation-centric zones.
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 1]
-\f
-Internet-Draft nsec3 February 2006
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. NSEC versus NSEC3 . . . . . . . . . . . . . . . . . . . . . . 5
- 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5
- 3.1. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 6
- 3.1.1. The Hash Function Field . . . . . . . . . . . . . . . 6
- 3.1.2. The Opt-In Flag Field . . . . . . . . . . . . . . . . 7
- 3.1.3. The Iterations Field . . . . . . . . . . . . . . . . . 8
- 3.1.4. The Salt Length Field . . . . . . . . . . . . . . . . 8
- 3.1.5. The Salt Field . . . . . . . . . . . . . . . . . . . . 8
- 3.1.6. The Next Hashed Ownername Field . . . . . . . . . . . 9
- 3.1.7. The Type Bit Maps Field . . . . . . . . . . . . . . . 9
- 3.2. The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10
- 4. Creating Additional NSEC3 RRs for Empty Non-Terminals . . . . 11
- 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 11
- 6. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 11
- 7. Responding to NSEC3 Queries . . . . . . . . . . . . . . . . . 12
- 8. Special Considerations . . . . . . . . . . . . . . . . . . . . 13
- 8.1. Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13
- 8.2. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 8.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15
- 8.4. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16
- 8.4.1. Avoiding Hash Collisions during generation . . . . . . 16
- 8.4.2. Second Preimage Requirement Analysis . . . . . . . . . 16
- 8.4.3. Possible Hash Value Truncation Method . . . . . . . . 17
- 8.4.4. Server Response to a Run-time Collision . . . . . . . 17
- 8.4.5. Parameters that Cover the Zone . . . . . . . . . . . . 18
- 9. Performance Considerations . . . . . . . . . . . . . . . . . . 18
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
- 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
- 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
- 12.2. Informative References . . . . . . . . . . . . . . . . . . 22
- Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
- Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 22
- Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 27
- B.1. answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27
- B.1.1. Authenticating the Example DNSKEY RRset . . . . . . . 29
- B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30
- B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . . 32
- B.3.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 33
- B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . . 34
- B.5. Referral to Unsigned Zone using the Opt-In Flag . . . . . 35
- B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 2]
-\f
-Internet-Draft nsec3 February 2006
-
-
- B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38
- B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . . 39
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
- Intellectual Property and Copyright Statements . . . . . . . . . . 42
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 3]
-\f
-Internet-Draft nsec3 February 2006
-
-
-1. Introduction
-
-1.1. Rationale
-
- The DNS Security Extensions included the NSEC RR to provide
- authenticated denial of existence. Though the NSEC RR meets the
- requirements for authenticated denial of existence, it introduced a
- side-effect in that the contents of a zone can be enumerated. This
- property introduces undesired policy issues.
-
- An enumerated zone can be used either directly as a source of
- probable e-mail addresses for spam, or indirectly as a key for
- multiple WHOIS queries to reveal registrant data which many
- registries may be under strict legal obligations to protect. Many
- registries therefore prohibit copying of their zone file; however the
- use of NSEC RRs renders these policies unenforceable.
-
- A second problem was the requirement that the existence of all record
- types in a zone - including unsigned delegation points - must be
- accounted for, despite the fact that unsigned delegation point
- records are not signed. This requirement has a side-effect that the
- overhead of signed zones is not related to the increase in security
- of subzones. This requirement does not allow the zones' size to grow
- in relation to the growth of signed subzones.
-
- In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been
- proposed as a measure against these side effects but at the time were
- regarded as secondary over the need to have a stable DNSSEC
- specification. With (draft-vixie-dnssec-ter) [14] a graceful
- transition path to future enhancements is introduced, while current
- DNSSEC deployment can continue. This document presents the NSEC3
- Resource Record which mitigates these issues with the NSEC RR.
-
- The reader is assumed to be familiar with the basic DNS and DNSSEC
- concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC
- 4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136
- [6], RFC2181 [7] and RFC2308 [8].
-
-1.2. Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [9].
-
-1.3. Terminology
-
- The practice of discovering the contents of a zone, i.e. enumerating
- the domains within a zone, is known as "zone enumeration". Zone
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 4]
-\f
-Internet-Draft nsec3 February 2006
-
-
- enumeration was not practical prior to the introduction of DNSSEC.
-
- In this document the term "original ownername" refers to a standard
- ownername. Because this proposal uses the result of a hash function
- over the original (unmodified) ownername, this result is referred to
- as "hashed ownername".
-
- "Hash order" means the order in which hashed ownernames are arranged
- according to their numerical value, treating the leftmost (lowest
- numbered) octet as the most significant octet. Note that this is the
- same as the canonical ordering specified in RFC 4034 [4].
-
- An "empty non-terminal" is a domain name that owns no resource
- records but has subdomains that do.
-
- The "closest encloser" of a (nonexistent) domain name is the longest
- domain name, including empty non-terminals, that matches the
- rightmost part of the nonexistent domain name.
-
- "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as
- specified in RFC 3548bis [15].
-
-
-2. NSEC versus NSEC3
-
- This document does NOT obsolete the NSEC record, but gives an
- alternative for authenticated denial of existence. NSEC and NSEC3
- RRs can not co-exist in a zone. See draft-vixie-dnssec-ter [14] for
- a signaling mechanism to allow for graceful transition towards NSEC3.
-
-
-3. The NSEC3 Resource Record
-
- The NSEC3 RR provides Authenticated Denial of Existence for DNS
- Resource Record Sets.
-
- The NSEC3 Resource Record (RR) lists RR types present at the NSEC3
- RR's original ownername. It includes the next hashed ownername in
- the hash order of the zone. The complete set of NSEC3 RRs in a zone
- indicates which RRsets exist for the original ownername of the RRset
- and form a chain of hashed ownernames in the zone. This information
- is used to provide authenticated denial of existence for DNS data, as
- described in RFC 4035 [5]. To provide protection against zone
- enumeration, the ownernames used in the NSEC3 RR are cryptographic
- hashes of the original ownername prepended to the name of the zone.
- The NSEC3 RR indicates which hash function is used to construct the
- hash, which salt is used, and how many iterations of the hash
- function are performed over the original ownername. The hashing
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 5]
-\f
-Internet-Draft nsec3 February 2006
-
-
- technique is described fully in Section 5.
-
- Hashed ownernames of unsigned delegations may be excluded from the
- chain. An NSEC3 record which span covers the hash of an unsigned
- delegation's ownername is referred to as an Opt-In NSEC3 record and
- is indicated by the presence of a flag.
-
- The ownername for the NSEC3 RR is the base32 encoding of the hashed
- ownername prepended to the name of the zone..
-
- The type value for the NSEC3 RR is XX.
-
- The NSEC3 RR RDATA format is class independent and is described
- below.
-
- The class MUST be the same as the original ownername's class.
-
- The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
- field. This is in the spirit of negative caching [8].
-
-3.1. NSEC3 RDATA Wire Format
-
- The RDATA of the NSEC3 RR is as shown below:
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Hash Function |O| Iterations |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Salt Length | Salt /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Next Hashed Ownername /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Type Bit Maps /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- "O" is the Opt-In Flag field.
-
-3.1.1. The Hash Function Field
-
- The Hash Function field identifies the cryptographic hash function
- used to construct the hash-value.
-
- The values are as defined for the DS record (see RFC 3658 [10]).
-
- On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash
- function value.
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 6]
-\f
-Internet-Draft nsec3 February 2006
-
-
-3.1.2. The Opt-In Flag Field
-
- The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned
- delegations.
-
- In DNSSEC, NS RRsets at delegation points are not signed, and may be
- accompanied by a DS record. The security status of the subzone is
- determined by the presence or absence of the DS RRset,
- cryptographically proven by the NSEC record or the signed DS RRset.
- The presence of the Opt-In flag expands this definition by allowing
- insecure delegations to exist within an otherwise signed zone without
- the corresponding NSEC3 record at the delegation's (hashed) owner
- name. These delegations are proven insecure by using a covering
- NSEC3 record.
-
- Resolvers must be able to distinguish between NSEC3 records and
- Opt-In NSEC3 records. This is accomplished by setting the Opt-In
- flag of the NSEC3 records that cover (or potentially cover) insecure
- delegation nodes.
-
- An Opt-In NSEC3 record does not assert the existence or non-existence
- of the insecure delegations that it covers. This allows for the
- addition or removal of these delegations without recalculating or
- resigning records in the NSEC3 chain. However, Opt-In NSEC3 records
- do assert the (non)existence of other, authoritative RRsets.
-
- An Opt-In NSEC3 record MAY have the same original owner name as an
- insecure delegation. In this case, the delegation is proven insecure
- by the lack of a DS bit in type map and the signed NSEC3 record does
- assert the existence of the delegation.
-
- Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and
- non-Opt-In NSEC3 records. If an NSEC3 record is not Opt-In, there
- MUST NOT be any hashed ownernames of insecure delegations (nor any
- other records) between it and the RRsets indicated by the 'Next
- Hashed Ownername' in the NSEC3 RDATA. If it is Opt-In, there MUST
- only be hashed ownernames of insecure delegations between it and the
- next node indicated by the 'Next Hashed Ownername' in the NSEC3
- RDATA.
-
- In summary,
- o An Opt-In NSEC3 type is identified by an Opt-In Flag field value
- of 1.
- o A non Opt-In NSEC3 type is identified by an Opt-In Flag field
- value of 0.
- and,
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 7]
-\f
-Internet-Draft nsec3 February 2006
-
-
- o An Opt-In NSEC3 record does not assert the non-existence of a hash
- ownername between its ownername and next hashed ownername,
- although it does assert that any hashed name in this span MUST be
- of an insecure delegation.
- o An Opt-In NSEC3 record does assert the (non)existence of RRsets
- with the same hashed owner name.
-
-3.1.3. The Iterations Field
-
- The Iterations field defines the number of times the hash has been
- iterated. More iterations results in greater resiliency of the hash
- value against dictionary attacks, but at a higher cost for both the
- server and resolver. See Section 5 for details of this field's use.
-
- Iterations make an attack more costly by making the hash computation
- more computationally intensive, e.g. by iterating the hash function a
- number of times.
-
- When generating a few hashes this performance loss will not be a
- problem, as a validator can handle a delay of a few milliseconds.
- But when doing a dictionary attack it will also multiply the attack
- workload by a factor, which is a problem for the attacker.
-
-3.1.4. The Salt Length Field
-
- The salt length field defines the length of the salt in octets.
-
-3.1.5. The Salt Field
-
- The Salt field is not present when the Salt Length Field has a value
- of 0.
-
- The Salt field is appended to the original ownername before hashing
- in order to defend against precalculated dictionary attacks. See
- Section 5 for details on how the salt is used.
-
- Salt is used to make dictionary attacks using precomputation more
- costly. A dictionary can only be computed after the attacker has the
- salt, hence a new salt means that the dictionary has to be
- regenerated with the new salt.
-
- There MUST be a complete set of NSEC3 records covering the entire
- zone that use the same salt value. The requirement exists so that,
- given any qname within a zone, at least one covering NSEC3 RRset may
- be found. While it may be theoretically possible to produce a set of
- NSEC3s that use different salts that cover the entire zone, it is
- computationally infeasible to generate such a set. See Section 8.2
- for further discussion.
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 8]
-\f
-Internet-Draft nsec3 February 2006
-
-
- The salt value SHOULD be changed from time to time - this is to
- prevent the use of a precomputed dictionary to reduce the cost of
- enumeration.
-
-3.1.6. The Next Hashed Ownername Field
-
- The Next Hashed Ownername field contains the next hashed ownername in
- hash order. That is, given the set of all hashed owernames, the Next
- Hashed Ownername contains the hash value that immediately follows the
- owner hash value for the given NSEC3 record. The value of the Next
- Hashed Ownername Field in the last NSEC3 record in the zone is the
- same as the ownername of the first NSEC3 RR in the zone in hash
- order.
-
- Hashed ownernames of glue RRsets MUST NOT be listed in the Next
- Hashed Ownername unless at least one authoritative RRset exists at
- the same ownername. Hashed ownernames of delegation NS RRsets MUST
- be listed if the Opt-In bit is clear.
-
- Note that the Next Hashed Ownername field is not encoded, unlike the
- NSEC3 RR's ownername. It is the unmodified binary hash value. It
- does not include the name of the containing zone.
-
- The length of this field is the length of the hash value produced by
- the hash function selected by the Hash Function field.
-
-3.1.7. The Type Bit Maps Field
-
- The Type Bit Maps field identifies the RRset types which exist at the
- NSEC3 RR's original ownername.
-
- The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
- generation, and MUST be ignored during processing.
-
- 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 NSEC3 RR RDATA in increasing numerical
- order.
-
- "|" denotes concatenation
-
- Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 9]
-\f
-Internet-Draft nsec3 February 2006
-
-
- 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 NSEC3
- RR's ownername. If a bit is set to 0, it indicates that no RRset of
- that type is present for the NSEC3 RR's ownername.
-
- Since bit 0 in window block 0 refers to the non-existing RR type 0,
- it MUST be set to 0. After verification, the validator MUST ignore
- the value of bit 0 in window block 0.
-
- Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11]
- (section 3.1) or within the range reserved for assignment only to
- QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
- zone data. If encountered, they must be ignored upon reading.
-
- Blocks with no types present MUST NOT be included. Trailing zero
- octets in the bitmap MUST be omitted. The length of 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
- NSEC3 RR's actual ownername. Trailing zero octets not specified MUST
- be interpreted as zero octets.
-
-3.2. The NSEC3 RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Opt-In Flag Field is represented as an unsigned decimal integer.
- The value is either 0 or 1.
-
- The Hash field is presented as a mnemonic of the hash or as an
- unsigned decimal integer. The value has a maximum of 127.
-
- The Iterations field is presented as an unsigned decimal integer.
-
- The Salt Length field is not presented.
-
- The Salt field is represented as a sequence of case-insensitive
- hexadecimal digits. Whitespace is not allowed within the sequence.
- The Salt Field is represented as "-" (without the quotes) when the
- Salt Length field has value 0.
-
- The Next Hashed Ownername field is represented as a sequence of case-
- insensitive base32 digits, without whitespace.
-
- The Type Bit Maps Field is represented as a sequence of RR type
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 10]
-\f
-Internet-Draft nsec3 February 2006
-
-
- mnemonics. When the mnemonic is not known, the TYPE representation
- as described in RFC 3597 [12] (section 5) MUST be used.
-
-
-4. Creating Additional NSEC3 RRs for Empty Non-Terminals
-
- In order to prove the non-existence of a record that might be covered
- by a wildcard, it is necessary to prove the existence of its closest
- encloser. A closest encloser might be an empty non-terminal.
-
- Additional NSEC3 RRs are generated for empty non-terminals. These
- additional NSEC3 RRs are identical in format to NSEC3 RRs that cover
- existing RRs in the zone except that their type-maps only indicated
- the existence of an NSEC3 RRset and an RRSIG RRset.
-
- This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs
- not appear at names that did not exist before the zone was signed.
- [Comment.1]
-
-
-5. Calculation of the Hash
-
- Define H(x) to be the hash of x using the hash function selected by
- the NSEC3 record and || to indicate concatenation. Then define:
-
- IH(salt,x,0)=H(x || salt)
-
- IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
-
- Then the calculated hash of an ownername is
- IH(salt,ownername,iterations-1), where the ownername is the canonical
- form.
-
- The canonical form of the ownername is the wire format of the
- ownername where:
- 1. The ownername is fully expanded (no DNS name compression) and
- fully qualified;
- 2. All uppercase US-ASCII letters are replaced by the corresponding
- lowercase US-ASCII letters;
- 3. If the ownername is a wildcard name, the ownername is in its
- original unexpanded form, including the "*" label (no wildcard
- substitution);
- This form is as defined in section 6.2 of RFC 4034 ([4]).
-
-
-6. Including NSEC3 RRs in a Zone
-
- Each ownername within the zone that owns authoritative RRsets MUST
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 11]
-\f
-Internet-Draft nsec3 February 2006
-
-
- have a corresponding NSEC3 RR. Ownernames that correspond to
- unsigned delegations MAY have a corresponding NSEC3 RR, however, if
- there is not, there MUST be a covering NSEC3 RR with the Opt-In flag
- set to 1. Other non-authoritative RRs are not included in the set of
- NSEC3 RRs.
-
- Each empty non-terminal MUST have an NSEC3 record.
-
- The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
- value field in the zone SOA RR.
-
- The type bitmap of every NSEC3 resource record in a signed zone MUST
- indicate the presence of both the NSEC3 RR type itself and its
- corresponding RRSIG RR type.
-
- The following steps describe the proper construction of NSEC3
- records. [Comment.2]
- 1. For each unique original ownername in the zone, add an NSEC3
- RRset. If Opt-In is being used, ownernames of unsigned
- delegations may be excluded, but must be considered for empty-
- non-terminals. The ownername of the NSEC3 RR is the hashed
- equivalent of the original owner name, prepended to the zone
- name. The Next Hashed Ownername field is left blank for the
- moment. If Opt-In is being used, set the Opt-In bit to one.
- 2. For each RRset at the original owner name, set the corresponding
- bit in the type bit map.
- 3. If the difference in number of labels between the apex and the
- original ownername is greater then 1, additional NSEC3s need to
- be added for every empty non-terminal between the apex and the
- original ownername. This process may generate NSEC3 RRs with
- duplicate hashed ownernames.
- 4. Sort the set of NSEC3 RRs into hash order. Hash order is the
- ascending numerical order of the non-encoded hash values.
- 5. Combine NSEC3 RRs with identical hashed ownernames by replacing
- with a single NSEC3 RR with the type map consisting of the union
- of the types represented by the set of NSEC3 RRs.
- 6. In each NSEC3 RR, insert the Next Hashed Ownername by using the
- value of the next NSEC3 RR in hash order. The Next Hashed
- Ownername of the last NSEC3 in the zone contains the value of the
- hashed ownername of the first NSEC3 in the hash order.
-
-
-7. Responding to NSEC3 Queries
-
- Since NSEC3 ownernames are not represented in the NSEC3 chain like
- other zone ownernames, direct queries for NSEC3 ownernames present a
- special case.
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 12]
-\f
-Internet-Draft nsec3 February 2006
-
-
- The special case arises when the following are all true:
- o The QNAME equals an existing NSEC3 ownername, and
- o There are no other record types that exist at QNAME, and
- o The QTYPE does not equal NSEC3.
- These conditions describe a particular case: the answer should be a
- NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to
- include in the authority section.
-
- However, the NSEC3 RRset with ownername equal to QNAME is able to
- prove its own existence. Thus, when answering this query, the
- authoritative server MUST include the NSEC3 RRset whose ownername
- equals QNAME. This RRset proves that QNAME is an existing name with
- types NSEC3 and RRSIG. The authoritative server MUST also include
- the NSEC3 RRset that covers the hash of QNAME. This RRset proves
- that no other types exist.
-
- When validating a NOERROR/NODATA response, validators MUST check for
- a NSEC3 RRset with ownername equals to QNAME, and MUST accept that
- (validated) NSEC3 RRset as proof that QNAME exists. The validator
- MUST also check for an NSEC3 RRset that covers the hash of QNAME as
- proof that QTYPE doesn't exist.
-
- Other cases where the QNAME equals an existing NSEC3 ownername may be
- answered normally.
-
-
-8. Special Considerations
-
- The following paragraphs clarify specific behaviour explain special
- considerations for implementations.
-
-8.1. Proving Nonexistence
-
- If a wildcard resource record appears in a zone, its asterisk label
- is treated as a literal symbol and is treated in the same way as any
- other ownername for purposes of generating NSEC3 RRs. RFC 4035 [5]
- describes the impact of wildcards on authenticated denial of
- existence.
-
- In order to prove there exist no RRs for a domain, as well as no
- source of synthesis, an RR must be shown for the closest encloser,
- and non-existence must be shown for all closer labels and for the
- wildcard at the closest encloser.
-
- This can be done as follows. If the QNAME in the query is
- omega.alfa.beta.example, and the closest encloser is beta.example
- (the nearest ancestor to omega.alfa.beta.example), then the server
- should return an NSEC3 that demonstrates the nonexistence of
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 13]
-\f
-Internet-Draft nsec3 February 2006
-
-
- alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
- *.beta.example, and an NSEC3 that demonstrates the existence of
- beta.example. This takes between one and three NSEC3 records, since
- a single record can, by chance, prove more than one of these facts.
-
- When a verifier checks this response, then the existence of
- beta.example together with the non-existence of alfa.beta.example
- proves that the closest encloser is indeed beta.example. The non-
- existence of *.beta.example shows that there is no wildcard at the
- closest encloser, and so no source of synthesis for
- omega.alfa.beta.example. These two facts are sufficient to satisfy
- the resolver that the QNAME cannot be resolved.
-
- In practice, since the NSEC3 owner and next names are hashed, if the
- server responds with an NSEC3 for beta.example, the resolver will
- have to try successively longer names, starting with example, moving
- to beta.example, alfa.beta.example, and so on, until one of them
- hashes to a value that matches the interval (but not the ownername
- nor next owner name) of one of the returned NSEC3s (this name will be
- alfa.beta.example). Once it has done this, it knows the closest
- encloser (i.e. beta.example), and can then easily check the other two
- required proofs.
-
- Note that it is not possible for one of the shorter names tried by
- the resolver to be denied by one of the returned NSEC3s, since, by
- definition, all these names exist and so cannot appear within the
- range covered by an NSEC3. Note, however, that the first name that
- the resolver tries MUST be the apex of the zone, since names above
- the apex could be denied by one of the returned NSEC3s.
-
-8.2. Salting
-
- Augmenting original ownernames with salt before hashing increases the
- cost of a dictionary of pre-generated hash-values. For every bit of
- salt, the cost of a precomputed dictionary doubles (because there
- must be an entry for each word combined with each possible salt
- value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
- salt, multiplying the cost by 2^2040. This means that an attacker
- must, in practice, recompute the dictionary each time the salt is
- changed.
-
- There MUST be at least one complete set of NSEC3s for the zone using
- the same salt value.
-
- The salt SHOULD be changed periodically to prevent precomputation
- using a single salt. It is RECOMMENDED that the salt be changed for
- every resigning.
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 14]
-\f
-Internet-Draft nsec3 February 2006
-
-
- Note that this could cause a resolver to see records with different
- salt values for the same zone. This is harmless, since each record
- stands alone (that is, it denies the set of ownernames whose hashes,
- using the salt in the NSEC3 record, fall between the two hashes in
- the NSEC3 record) - it is only the server that needs a complete set
- of NSEC3 records with the same salt in order to be able to answer
- every possible query.
-
- There is no prohibition with having NSEC3 with different salts within
- the same zone. However, in order for authoritative servers to be
- able to consistently find covering NSEC3 RRs, the authoritative
- server MUST choose a single set of parameters (algorithm, salt, and
- iterations) to use when selecting NSEC3s. In the absence of any
- other metadata, the server does this by using the parameters from the
- zone apex NSEC3, recognizable by the presence of the SOA bit in the
- type map. If there is more than one NSEC3 record that meets this
- description, then the server may arbitrarily choose one. Because of
- this, if there is a zone apex NSEC3 RR within a zone, it MUST be part
- of a complete NSEC3 set. Conversely, if there exists an incomplete
- set of NSEC3 RRs using the same parameters within a zone, there MUST
- NOT be an NSEC3 RR using those parameters with the SOA bit set.
-
-8.3. Iterations
-
- Setting the number of iterations used allows the zone owner to choose
- the cost of computing a hash, and so the cost of generating a
- dictionary. Note that this is distinct from the effect of salt,
- which prevents the use of a single precomputed dictionary for all
- time.
-
- Obviously the number of iterations also affects the zone owner's cost
- of signing the zone as well as the verifiers cost of verifying the
- zone. We therefore impose an upper limit on the number of
- iterations. We base this on the number of iterations that
- approximately doubles the cost of signing the zone.
-
- A zone owner MUST NOT use a value higher than shown in the table
- below for iterations. A resolver MAY treat a response with a higher
- value as bogus.
-
- +--------------+------------+
- | RSA Key Size | Iterations |
- +--------------+------------+
- | 1024 | 3,000 |
- | 2048 | 20,000 |
- | 4096 | 150,000 |
- +--------------+------------+
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 15]
-\f
-Internet-Draft nsec3 February 2006
-
-
- +--------------+------------+
- | DSA Key Size | Iterations |
- +--------------+------------+
- | 1024 | 1,500 |
- | 2048 | 5,000 |
- +--------------+------------+
-
- This table is based on 150,000 SHA-1's per second, 50 RSA signs per
- second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1
- sign per second for 4096 bit keys, 100 DSA signs per second for 1024
- bit keys and 30 signs per second for 2048 bit keys.
-
- Note that since RSA verifications are 10-100 times faster than
- signatures (depending on key size), in the case of RSA the legal
- values of iterations can substantially increase the cost of
- verification.
-
-8.4. Hash Collision
-
- Hash collisions occur when different messages have the same hash
- value. The expected number of domain names needed to give a 1 in 2
- chance of a single collision is about 2^(n/2) for a hash of length n
- bits (i.e. 2^80 for SHA-1). Though this probability is extremely
- low, the following paragraphs deal with avoiding collisions and
- assessing possible damage in the event of an attack using hash
- collisions.
-
-8.4.1. Avoiding Hash Collisions during generation
-
- During generation of NSEC3 RRs, hash values are supposedly unique.
- In the (academic) case of a collision occurring, an alternative salt
- MUST be chosen and all hash values MUST be regenerated.
-
-8.4.2. Second Preimage Requirement Analysis
-
- A cryptographic hash function has a second-preimage resistance
- property. The second-preimage resistance property means that it is
- computationally infeasible to find another message with the same hash
- value as a given message, i.e. given preimage X, to find a second
- preimage X' != X such that hash(X) = hash(X'). The work factor for
- finding a second preimage is of the order of 2^160 for SHA-1. To
- mount an attack using an existing NSEC3 RR, an adversary needs to
- find a second preimage.
-
- Assuming an adversary is capable of mounting such an extreme attack,
- the actual damage is that a response message can be generated which
- claims that a certain QNAME (i.e. the second pre-image) does exist,
- while in reality QNAME does not exist (a false positive), which will
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 16]
-\f
-Internet-Draft nsec3 February 2006
-
-
- either cause a security aware resolver to re-query for the non-
- existent name, or to fail the initial query. Note that the adversary
- can't mount this attack on an existing name but only on a name that
- the adversary can't choose and does not yet exist.
-
-8.4.3. Possible Hash Value Truncation Method
-
- The previous sections outlined the low probability and low impact of
- a second-preimage attack. When impact and probability are low, while
- space in a DNS message is costly, truncation is tempting. Truncation
- might be considered to allow for shorter ownernames and rdata for
- hashed labels. In general, if a cryptographic hash is truncated to n
- bits, then the expected number of domains required to give a 1 in 2
- probability of a single collision is approximately 2^(n/2) and the
- work factor to produce a second preimage is 2^n.
-
- An extreme hash value truncation would be truncating to the shortest
- possible unique label value. This would be unwise, since the work
- factor to produce second preimages would then approximate the size of
- the zone (sketch of proof: if the zone has k entries, then the length
- of the names when truncated down to uniqueness should be proportional
- to log_2(k). Since the work factor to produce a second pre-image is
- 2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where
- C is some constant), i.e. C'k - a work factor of k).
-
- Though the mentioned truncation can be maximized to a certain
- extreme, the probability of collision increases exponentially for
- every truncated bit. Given the low impact of hash value collisions
- and limited space in DNS messages, the balance between truncation
- profit and collision damage may be determined by local policy. Of
- course, the size of the corresponding RRSIG RR is not reduced, so
- truncation is of limited benefit.
-
- Truncation could be signaled simply by reducing the length of the
- first label in the ownername. Note that there would have to be a
- corresponding reduction in the length of the Next Hashed Ownername
- field.
-
-8.4.4. Server Response to a Run-time Collision
-
- In the astronomically unlikely event that a server is unable to prove
- nonexistence because the hash of the name that does not exist
- collides with a name that does exist, the server is obviously broken,
- and should, therefore, return a response with an RCODE of 2 (server
- failure).
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 17]
-\f
-Internet-Draft nsec3 February 2006
-
-
-8.4.5. Parameters that Cover the Zone
-
- Secondary servers (and perhaps other entities) need to reliably
- determine which NSEC3 parameters (that is, hash, salt and iterations)
- are present at every hashed ownername, in order to be able to choose
- an appropriate set of NSEC3 records for negative responses. This is
- indicated by the parameters at the apex: any set of parameters that
- is used in an NSEC3 record whose original ownername is the apex of
- the zone MUST be present throughout the zone.
-
- A method to determine which NSEC3 in a complete chain corresponds to
- the apex is to look for a NSEC3 RRset which has the SOA bit set in
- the RDATA bit type maps field.
-
-
-9. Performance Considerations
-
- Iterated hashes impose a performance penalty on both authoritative
- servers and resolvers. Therefore, the number of iterations should be
- carefully chosen. In particular it should be noted that a high value
- for iterations gives an attacker a very good denial of service
- attack, since the attacker need not bother to verify the results of
- their queries, and hence has no performance penalty of his own.
-
- On the other hand, nameservers with low query rates and limited
- bandwidth are already subject to a bandwidth based denial of service
- attack, since responses are typically an order of magnitude larger
- than queries, and hence these servers may choose a high value of
- iterations in order to increase the difficulty of offline attempts to
- enumerate their namespace without significantly increasing their
- vulnerability to denial of service attacks.
-
-
-10. IANA Considerations
-
- IANA needs to allocate a RR type code for NSEC3 from the standard RR
- type space (type XXX requested). IANA needs to open a new registry
- for the NSEC3 Hash Functions. The range for this registry is 0-127.
- Defined types are:
-
- 0 is reserved.
- 1 is SHA-1 ([13]).
- 127 is experimental.
-
-
-11. Security Considerations
-
- The NSEC3 records are still susceptible to dictionary attacks (i.e.
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 18]
-\f
-Internet-Draft nsec3 February 2006
-
-
- the attacker retrieves all the NSEC3 records, then calculates the
- hashes of all likely domain names, comparing against the hashes found
- in the NSEC3 records, and thus enumerating the zone). These are
- substantially more expensive than enumerating the original NSEC
- records would have been, and in any case, such an attack could also
- be used directly against the name server itself by performing queries
- for all likely names, though this would obviously be more detectable.
- The expense of this off-line attack can be chosen by setting the
- number of iterations in the NSEC3 RR.
-
- Domains are also susceptible to a precalculated dictionary attack -
- that is, a list of hashes for all likely names is computed once, then
- NSEC3 is scanned periodically and compared against the precomputed
- hashes. This attack is prevented by changing the salt on a regular
- basis.
-
- Walking the NSEC3 RRs will reveal the total number of records in the
- zone, and also what types they are. This could be mitigated by
- adding dummy entries, but certainly an upper limit can always be
- found.
-
- Hash collisions may occur. If they do, it will be impossible to
- prove the non-existence of the colliding domain - however, this is
- fantastically unlikely, and, in any case, DNSSEC already relies on
- SHA-1 to not collide.
-
- Responses to queries where QNAME equals an NSEC3 ownername that has
- no other types may be undetectably changed from a NOERROR/NODATA
- response to a NAME ERROR response.
-
- The Opt-In Flag (O) allows for unsigned names, in the form of
- delegations to unsigned subzones, to exist within an otherwise signed
- zone. All unsigned names are, by definition, insecure, and their
- validity or existence cannot by cryptographically proven.
-
- In general:
- Records with unsigned names (whether existing or not) suffer from
- the same vulnerabilities as records in an unsigned zone. These
- vulnerabilities are described in more detail in [16] (note in
- particular sections 2.3, "Name Games" and 2.6, "Authenticated
- Denial").
- Records with signed names have the same security whether or not
- Opt-In is used.
-
- Note that with or without Opt-In, an insecure delegation may be
- undetectably altered by an attacker. Because of this, the primary
- difference in security when using Opt-In is the loss of the ability
- to prove the existence or nonexistence of an insecure delegation
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 19]
-\f
-Internet-Draft nsec3 February 2006
-
-
- within the span of an Opt-In NSEC3 record.
-
- In particular, this means that a malicious entity may be able to
- insert or delete records with unsigned names. These records are
- normally NS records, but this also includes signed wildcard
- expansions (while the wildcard record itself is signed, its expanded
- name is an unsigned name).
-
- For example, if a resolver received the following response from the
- example zone above:
-
- Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
-
- RCODE=NOERROR
-
- Answer Section:
-
- Authority Section:
- DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
- EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \
- RRSIG DNSKEY
- abcd... RRSIG NSEC3 ...
-
- Additional Section:
-
- The resolver would have no choice but to accept that the referral to
- NS.FORGED. is valid. If a wildcard existed that would have been
- expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
- have undetectably removed it and replaced it with the forged
- delegation.
-
- Note that being able to add a delegation is functionally equivalent
- to being able to add any record type: an attacker merely has to forge
- a delegation to nameserver under his/her control and place whatever
- records needed at the subzone apex.
-
- While in particular cases, this issue may not present a significant
- security problem, in general it should not be lightly dismissed.
- Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
- In particular, zone signing tools SHOULD NOT default to using Opt-In,
- and MAY choose to not support Opt-In at all.
-
-
-12. References
-
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 20]
-\f
-Internet-Draft nsec3 February 2006
-
-
-12.1. Normative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
- [7] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
- [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [10] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
- RFC 3658, December 2003.
-
- [11] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain
- Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
- September 2000.
-
- [12] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
- Types", RFC 3597, September 2003.
-
- [13] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
- RFC 3174, September 2001.
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 21]
-\f
-Internet-Draft nsec3 February 2006
-
-
-12.2. Informative References
-
- [14] Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)",
- draft-vixie-dnssec-ter-01 (work in progress), June 2004.
-
- [15] Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data
- Encodings.", draft-josefsson-rfc3548bis-00 (work in progress),
- October 2005.
-
- [16] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
- System (DNS)", RFC 3833, August 2004.
-
-Editorial Comments
-
- [Comment.1] Although, strictly speaking, the names *did* exist.
-
- [Comment.2] Note that this method makes it impossible to detect
- (extremely unlikely) hash collisions.
-
-
-Appendix A. Example Zone
-
- This is a zone showing its NSEC3 records. They can also be used as
- test vectors for the hash algorithm.
-
- The data in the example zone is currently broken, as it uses a
- different base32 alphabet. This shall be fixed in the next release.
-
-
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600 )
- 3600 RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- 3600 NS ns1.example.
- 3600 NS ns2.example.
- 3600 RRSIG NS 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
- m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
- 1SH5r/wfjuCg+g== )
- 3600 MX 1 xx.example.
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 22]
-\f
-Internet-Draft nsec3 February 2006
-
-
- 3600 RRSIG MX 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
- NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
- S/o/g5C8VM6ftQ== )
- 3600 DNSKEY 257 3 5 (
- AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
- cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
- zsYKWJ7BvR2894hX
- ) ; Key ID = 21960
- 3600 DNSKEY 256 3 5 (
- AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
- 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
- ExXT48OGGdbfIme5
- ) ; Key ID = 62699
- 3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
- xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
- mTkunTYzqWJrmQ== )
- 3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
- 20050612112304 21960 example.
- SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
- ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
- 3w7ZY2UWyYIvpw== )
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2
- NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
- Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
- sb7KfbaUo/vzAg== )
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
- MX NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
- ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
- MEFQmc/gEuxojA== )
- a.example. 3600 IN NS ns1.a.example.
- 3600 IN NS ns2.a.example.
- 3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B
- 766A6A4837206C )
- 3600 RRSIG DS 5 2 3600 20050712112304 (
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 23]
-\f
-Internet-Draft nsec3 February 2006
-
-
- 20050612112304 62699 example.
- QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
- cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
- 0kx7rGKTc3RQDA== )
- ns1.a.example. 3600 IN A 192.0.2.5
- ns2.a.example. 3600 IN A 192.0.2.6
- ai.example. 3600 IN A 192.0.2.9
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
- 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
- ZXW5S+1VjMZYzQ== )
- 3600 HINFO "KLH-10" "ITS"
- 3600 RRSIG HINFO 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
- tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
- VGNmbgPnqDVPiA== )
- 3600 AAAA 2001:db8:0:0:0:0:f00:baa9
- 3600 RRSIG AAAA 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
- ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
- l5/UqLCJJ9BDMg== )
- b.example. 3600 IN NS ns1.b.example.
- 3600 IN NS ns2.b.example.
- ns1.b.example. 3600 IN A 192.0.2.7
- ns2.b.example. 3600 IN A 192.0.2.8
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- gmnfcccja7wkax3iv26bs75myptje3qk
- MX DNSKEY NS SOA NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
- C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
- MOiKMSHozVebqw== )
- gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
- DS NS NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
- ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
- OwQBGbOegrW/Zw== )
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 (
- deadbeaf
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 24]
-\f
-Internet-Draft nsec3 February 2006
-
-
- kcll7fqfnisuhfekckeeqnmbbd4maanu
- NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
- IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
- 94Zbq3k8lgdpZA== )
- kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 (
- deadbeaf
- n42hbhnjj333xdxeybycax5ufvntux5d
- MX NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
- IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
- TOLtc5jPrkL4zQ== )
- n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- nimwfwcnbeoodmsc6npv3vuaagaevxxu
- A NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
- 91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
- xFPFGRIW3wKnrA== )
- nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- vhgwr2qgykdkf4m6iv6vkagbxozphazr
- HINFO A AAAA NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
- z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
- jL33Wm1p07TBdw== )
- ns1.example. 3600 A 192.0.2.1
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
- BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
- nWWLepz1PjjShQ== )
- ns2.example. 3600 A 192.0.2.2
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
- P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
- AkeTJu3J3auUiA== )
- vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 (
- deadbeaf
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 25]
-\f
-Internet-Draft nsec3 February 2006
-
-
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw
- HINFO A AAAA NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
- kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
- 5SNSHIyfpfsi6A== )
- *.w.example. 3600 MX 1 ai.example.
- 3600 RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
- xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
- gQlgxEwhvQDEaQ== )
- x.w.example. 3600 MX 1 xx.example.
- 3600 RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
- lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
- U9VazOa1KEIq1w== )
- x.y.w.example. 3600 MX 1 xx.example.
- 3600 RRSIG MX 5 4 3600 20050712112304 (
- 20050612112304 62699 example.
- aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
- uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
- 9VrQvJjwbllAfA== )
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
- A NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
- ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
- oorBv4xkb0flXw== )
- xx.example. 3600 A 192.0.2.10
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
- tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
- cxwCXWj82GVGdw== )
- 3600 HINFO "KLH-10" "TOPS-20"
- 3600 RRSIG HINFO 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
- OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
- KMf4DgNBDj+dIQ== )
- 3600 AAAA 2001:db8:0:0:0:0:f00:baaa
- 3600 RRSIG AAAA 5 2 3600 20050712112304 (
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 26]
-\f
-Internet-Draft nsec3 February 2006
-
-
- 20050612112304 62699 example.
- rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
- w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
- rzKKwb8J04/ILw== )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
- MX NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
- 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
- OcFlrPGPMm48/A== )
-
-
-Appendix B. Example Responses
-
- The examples in this section show response messages using the signed
- zone example in Appendix A.
-
-B.1. answer
-
- A successful query to an authoritative server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 27]
-\f
-Internet-Draft nsec3 February 2006
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- x.w.example. IN MX
-
- ;; Answer
- x.w.example. 3600 IN MX 1 xx.example.
- x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
- lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
- U9VazOa1KEIq1w== )
-
- ;; Authority
- example. 3600 IN NS ns1.example.
- example. 3600 IN NS ns2.example.
- example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
- m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
- 1SH5r/wfjuCg+g== )
-
- ;; Additional
- xx.example. 3600 IN A 192.0.2.10
- xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
- tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
- cxwCXWj82GVGdw== )
- xx.example. 3600 IN AAAA 2001:db8::f00:baaa
- xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
- w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
- rzKKwb8J04/ILw== )
- ns1.example. 3600 IN A 192.0.2.1
- ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
- BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
- nWWLepz1PjjShQ== )
- ns2.example. 3600 IN A 192.0.2.2
- ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
- P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
- AkeTJu3J3auUiA== )
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 28]
-\f
-Internet-Draft nsec3 February 2006
-
-
- The query returned an MX RRset for "x.w.example". The corresponding
- RRSIG RR indicates that the MX RRset was signed by an "example"
- DNSKEY with algorithm 5 and key tag 62699. The resolver needs the
- corresponding DNSKEY RR in order to authenticate this answer. The
- discussion below describes how a resolver might obtain this DNSKEY
- RR.
-
- The RRSIG RR indicates the original TTL of the MX RRset was 3600,
- and, for the purpose of authentication, the current TTL is replaced
- by 3600. The RRSIG RR's labels field value of 3 indicates that the
- answer was not the result of wildcard expansion. The "x.w.example"
- MX RRset is placed in canonical form, and, assuming the current time
- falls between the signature inception and expiration dates, the
- signature is authenticated.
-
-B.1.1. Authenticating the Example DNSKEY RRset
-
- This example shows the logical authentication process that starts
- from a configured root DNSKEY RRset (or DS RRset) and moves down the
- tree to authenticate the desired "example" DNSKEY RRset. Note that
- the logical order is presented for clarity. An implementation may
- choose to construct the authentication as referrals are received or
- to construct the authentication chain only after all RRsets have been
- obtained, or in any other combination it sees fit. The example here
- demonstrates only the logical process and does not dictate any
- implementation rules.
-
- We assume the resolver starts with a configured DNSKEY RRset for the
- root zone (or a configured DS RRset for the root zone). The resolver
- checks whether this configured DNSKEY RRset is present in the root
- DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
- RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
- root DNSKEY RRset, and whether the signature lifetime is valid. If
- all these conditions are met, all keys in the DNSKEY RRset are
- considered authenticated. The resolver then uses one (or more) of
- the root DNSKEY RRs to authenticate the "example" DS RRset. Note
- that the resolver may have to query the root zone to obtain the root
- DNSKEY RRset or "example" DS RRset.
-
- Once the DS RRset has been authenticated using the root DNSKEY, the
- resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
- RR that matches one of the authenticated "example" DS RRs. If such a
- matching "example" DNSKEY is found, the resolver checks whether this
- DNSKEY RR has signed the "example" DNSKEY RRset and the signature
- lifetime is valid. If these conditions are met, all keys in the
- "example" DNSKEY RRset are considered authenticated.
-
- Finally, the resolver checks that some DNSKEY RR in the "example"
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 29]
-\f
-Internet-Draft nsec3 February 2006
-
-
- DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This
- DNSKEY is used to authenticate the RRSIG included in the response.
- If multiple "example" DNSKEY RRs match this algorithm and key tag,
- then each DNSKEY RR is tried, and the answer is authenticated if any
- of the matching DNSKEY RRs validate the signature as described above.
-
-B.2. Name Error
-
- An authoritative name error. The NSEC3 RRs prove that the name does
- not exist and that no covering wildcard exists.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 30]
-\f
-Internet-Draft nsec3 February 2006
-
-
- ;; Header: QR AA DO RCODE=3
- ;;
- ;; Question
- a.c.x.w.example. IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
- MX NSEC3 RRSIG )
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
- ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
- MEFQmc/gEuxojA== )
- nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- vhgwr2qgykdkf4m6iv6vkagbxozphazr
- HINFO A AAAA NSEC3 RRSIG )
- nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
- z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
- jL33Wm1p07TBdw== )
- ;; Additional
- ;; (empty)
-
- The query returned two NSEC3 RRs that prove that the requested data
- does not exist and no wildcard applies. The negative reply is
- authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are
- authenticated in a manner identical to that of the MX RRset discussed
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 31]
-\f
-Internet-Draft nsec3 February 2006
-
-
- above. At least one of the owner names of the NSEC3 RRs will match
- the closest encloser. At least one of the NSEC3 RRs prove that there
- exists no longer name. At least one of the NSEC3 RRs prove that
- there exists no wildcard RRsets that should have been expanded. The
- closest encloser can be found by hashing the apex ownername (The SOA
- RR's ownername, or the ownername of the DNSKEY RRset referred by an
- RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
- if that fails, continue by adding labels. In other words, the
- resolver first hashes example, checks for a matching NSEC3 ownername,
- then hashes w.example, checks, and finally hashes w.x.example and
- checks.
-
- In the above example, the name 'x.w.example' hashes to
- '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might
- be the closest encloser. To prove that 'c.x.w.example' and
- '*.x.w.example' do not exists, these names are hashed to respectively
- 'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
- 'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that
- these hashed ownernames do not exists, since the names are within the
- given intervals.
-
-B.3. No Data Error
-
- A "no data" response. The NSEC3 RR proves that the name exists and
- that the requested RR type does not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 32]
-\f
-Internet-Draft nsec3 February 2006
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- ns1.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
- A NSEC3 RRSIG )
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
- ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
- oorBv4xkb0flXw== )
- ;; Additional
- ;; (empty)
-
- The query returned an NSEC3 RR that proves that the requested name
- exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
- but the requested RR type does not exist (type MX is absent in the
- type code list of the NSEC RR). The negative reply is authenticated
- by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
- identical to that of the MX RRset discussed above.
-
-B.3.1. No Data Error, Empty Non-Terminal
-
- A "no data" response because of an empty non-terminal. The NSEC3 RR
- proves that the name exists and that the requested RR type does not.
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 33]
-\f
-Internet-Draft nsec3 February 2006
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- y.w.example. IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- kcll7fqfnisuhfekckeeqnmbbd4maanu
- NSEC3 RRSIG )
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
- IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
- 94Zbq3k8lgdpZA== )
-
- The query returned an NSEC3 RR that proves that the requested name
- exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
- but the requested RR type does not exist (Type A is absent in the
- type-bit-maps of the NSEC3 RR). The negative reply is authenticated
- by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
- identical to that of the MX RRset discussed above. Note that, unlike
- generic empty non terminal proof using NSECs, this is identical to
- proving a No Data Error. This example is solely mentioned to be
- complete.
-
-B.4. Referral to Signed Zone
-
- Referral to a signed zone. The DS RR contains the data which the
- resolver will need to validate the corresponding DNSKEY RR in the
- child zone's apex.
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 34]
-\f
-Internet-Draft nsec3 February 2006
-
-
- ;; Header: QR DO RCODE=0
- ;;
-
- ;; Question
- mc.a.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- a.example. 3600 IN NS ns1.a.example.
- a.example. 3600 IN NS ns2.a.example.
- a.example. 3600 IN DS 58470 5 1 (
- 3079F1593EBAD6DC121E202A8B766A6A4837
- 206C )
- a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
- cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
- 0kx7rGKTc3RQDA== )
-
- ;; Additional
- ns1.a.example. 3600 IN A 192.0.2.5
- ns2.a.example. 3600 IN A 192.0.2.6
-
- The query returned a referral to the signed "a.example." zone. The
- DS RR is authenticated in a manner identical to that of the MX RRset
- discussed above. This DS RR is used to authenticate the "a.example"
- DNSKEY RRset.
-
- Once the "a.example" DS RRset has been authenticated using the
- "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
- for some "a.example" DNSKEY RR that matches the DS RR. If such a
- matching "a.example" DNSKEY is found, the resolver checks whether
- this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
- the signature lifetime is valid. If all these conditions are met,
- all keys in the "a.example" DNSKEY RRset are considered
- authenticated.
-
-B.5. Referral to Unsigned Zone using the Opt-In Flag
-
- The NSEC3 RR proves that nothing for this delegation was signed in
- the parent zone. There is no proof that the delegation exists
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 35]
-\f
-Internet-Draft nsec3 February 2006
-
-
- ;; Header: QR DO RCODE=0
- ;;
- ;; Question
- mc.b.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- b.example. 3600 IN NS ns1.b.example.
- b.example. 3600 IN NS ns2.b.example.
- kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 (
- deadbeaf
- n42hbhnjj333xdxeybycax5ufvntux5d
- MX NSEC3 RRSIG )
- kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
- IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
- TOLtc5jPrkL4zQ== )
-
- ;; Additional
- ns1.b.example. 3600 IN A 192.0.2.7
- ns2.b.example. 3600 IN A 192.0.2.8
-
- The query returned a referral to the unsigned "b.example." zone. The
- NSEC3 proves that no authentication leads from "example" to
- "b.example", since the hash of "b.example"
- ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
- the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a
- manner identical to that of the MX RRset discussed above.
-
-B.6. Wildcard Expansion
-
- A successful query that was answered via wildcard expansion. The
- label count in the answer's RRSIG RR indicates that a wildcard RRset
- was expanded to produce this response, and the NSEC3 RR proves that
- no closer match exists in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 36]
-\f
-Internet-Draft nsec3 February 2006
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN MX
-
- ;; Answer
- a.z.w.example. 3600 IN MX 1 ai.example.
- a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
- xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
- gQlgxEwhvQDEaQ== )
- ;; Authority
- example. 3600 NS ns1.example.
- example. 3600 NS ns2.example.
- example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
- m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
- 1SH5r/wfjuCg+g== )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
- MX NSEC3 RRSIG )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
- 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
- OcFlrPGPMm48/A== )
- ;; Additional
- ai.example. 3600 IN A 192.0.2.9
- ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
- 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
- ZXW5S+1VjMZYzQ== )
- ai.example. 3600 AAAA 2001:db8::f00:baa9
- ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
- ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
- l5/UqLCJJ9BDMg== )
-
- The query returned an answer that was produced as a result of
- wildcard expansion. The answer section contains a wildcard RRset
- expanded as it would be in a traditional DNS response, and the
- corresponding RRSIG indicates that the expanded wildcard MX RRset was
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 37]
-\f
-Internet-Draft nsec3 February 2006
-
-
- signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
- The RRSIG indicates that the original TTL of the MX RRset was 3600,
- and, for the purpose of authentication, the current TTL is replaced
- by 3600. The RRSIG labels field value of 2 indicates that the answer
- is the result of wildcard expansion, as the "a.z.w.example" name
- contains 4 labels. The name "a.z.w.example" is replaced by
- "*.w.example", the MX RRset is placed in canonical form, and,
- assuming that the current time falls between the signature inception
- and expiration dates, the signature is authenticated.
-
- The NSEC3 proves that no closer match (exact or closer wildcard)
- could have been used to answer this query, and the NSEC3 RR must also
- be authenticated before the answer is considered valid.
-
-B.7. Wildcard No Data Error
-
- A "no data" response for a name covered by a wildcard. The NSEC3 RRs
- prove that the matching wildcard name does not have any RRs of the
- requested type and that no closer match exists in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 38]
-\f
-Internet-Draft nsec3 February 2006
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN AAAA
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
- MX NSEC3 RRSIG )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
- 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
- OcFlrPGPMm48/A== )
- ;; Additional
- ;; (empty)
-
- The query returned NSEC3 RRs that prove that the requested data does
- not exist and no wildcard applies. The negative reply is
- authenticated by verifying both NSEC3 RRs.
-
-B.8. DS Child Zone No Data Error
-
- A "no data" response for a QTYPE=DS query that was mistakenly sent to
- a name server for the child zone.
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 39]
-\f
-Internet-Draft nsec3 February 2006
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- example. IN DS
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- gmnfcccja7wkax3iv26bs75myptje3qk
- MX DNSKEY NS SOA NSEC3 RRSIG )
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
- C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
- MOiKMSHozVebqw== )
-
- ;; Additional
- ;; (empty)
-
- The query returned NSEC RRs that shows the requested was answered by
- a child server ("example" server). The NSEC RR indicates the
- presence of an SOA RR, showing that the answer is from the child .
- Queries for the "example" DS RRset should be sent to the parent
- servers ("root" servers).
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 40]
-\f
-Internet-Draft nsec3 February 2006
-
-
-Authors' Addresses
-
- Ben Laurie
- Nominet
- 17 Perryn Road
- London W3 7LR
- England
-
- Phone: +44 (20) 8735 0686
- Email: ben@algroup.co.uk
-
-
- Geoffrey Sisson
- Nominet
-
-
- Roy Arends
- Nominet
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 41]
-\f
-Internet-Draft nsec3 February 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 42]
-\f
+++ /dev/null
-
-INTERNET-DRAFT DSA Information in the DNS
-OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: January 2006 July 2005
-
-
- DSA Keying and Signature Information in the DNS
- --- ------ --- --------- ----------- -- --- ---
- <draft-ietf-dnsext-rfc2536bis-dsa-06.txt>
- Donald E. Eastlake 3rd
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method of encoding US Government Digital Signature
- Algorithm keying and signature information for use in the Domain Name
- System is specified.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2005. All Rights Reserved.
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. DSA Keying Information..................................3
- 3. DSA Signature Information...............................4
- 4. Performance Considerations..............................4
- 5. Security Considerations.................................5
- 6. IANA Considerations.....................................5
- Copyright and Disclaimer...................................5
-
- Normative References.......................................7
- Informative References.....................................7
-
- Authors Address............................................8
- Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additional work is underway which would
- require the storage of keying and signature information in the DNS.
-
- This document describes how to encode US Government Digital Signature
- Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
- US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA Keying Information
-
- When DSA public keys are stored in the DNS, the structure of the
- relevant part of the RDATA part of the RR being used is the fields
- listed below in the order given.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- Field Size
- ----- ----
- T 1 octet
- Q 20 octets
- P 64 + T*8 octets
- G 64 + T*8 octets
- Y 64 + T*8 octets
-
- As described in [FIPS 186-2] and [Schneier], T is a key size
- parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
- is greater than 8 is reserved and the remainder of the data may have
- a different format in that case.) Q is a prime number selected at
- key generation time such that 2**159 < Q < 2**160. Thus Q is always
- 20 octets long and, as with all other fields, is stored in "big-
- endian" network order. P, G, and Y are calculated as directed by the
- [FIPS 186-2] key generation algorithm [Schneier]. P is in the range
- 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
- and Y are quantities modulo P and so can be up to the same length as
- P and are allocated fixed size fields with the same number of octets
- as P.
-
- During the key generation process, a random number X must be
- generated such that 1 <= X <= Q-1. X is the private key and is used
- in the final step of public key generation where Y is computed as
-
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Y = G**X mod P
-
-
-
-3. DSA Signature Information
-
- The portion of the RDATA area used for US Digital Signature Algorithm
- signature information is shown below with fields in the order they
- are listed and the contents of each multi-octet field in "big-endian"
- network order.
-
- Field Size
- ----- ----
- T 1 octet
- R 20 octets
- S 20 octets
-
- First, the data signed must be determined. Then the following steps
- are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
- specified in the public key [Schneier]:
-
- hash = SHA-1 ( data )
-
- Generate a random K such that 0 < K < Q.
-
- R = ( G**K mod P ) mod Q
-
- S = ( K**(-1) * (hash + X*R) ) mod Q
-
- For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
- 3174].
-
- Since Q is 160 bits long, R and S can not be larger than 20 octets,
- which is the space allocated.
-
- T is copied from the public key. It is not logically necessary in
- the SIG but is present so that values of T > 8 can more conveniently
- be used as an escape for extended versions of DSA or other algorithms
- as later standardized.
-
-
-
-4. Performance Considerations
-
- General signature generation speeds are roughly the same for RSA [RFC
- 3110] and DSA. With sufficient pre-computation, signature generation
- with DSA is faster than RSA. Key generation is also faster for DSA.
- However, signature verification is an order of magnitude slower than
- RSA when the RSA public exponent is chosen to be small, as is
- recommended for some applications.
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient, it
- is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying and/or signature
- inforamtion consistent with adequate security.
-
-
-
-5. Security Considerations
-
- Keys retrieved from the DNS should not be trusted unless (1) they
- have been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is essential and
- dependent on local policy.
-
- The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
- current DSA standard may limit the security of DSA. For particular
- applications, implementors are encouraged to consider the range of
- available algorithms and key sizes.
-
- DSA assumes the ability to frequently generate high quality random
- numbers. See [random] for guidance. DSA is designed so that if
- biased rather than random numbers are used, high bandwidth covert
- channels are possible. See [Schneier] and more recent research. The
- leakage of an entire DSA private key in only two DSA signatures has
- been demonstrated. DSA provides security only if trusted
- implementations, including trusted random number generation, are
- used.
-
-
-
-6. IANA Considerations
-
- Allocation of meaning to values of the T parameter that are not
- defined herein (i.e., > 8 ) requires an IETF standards actions. It
- is intended that values unallocated herein be used to cover future
- extensions of the DSS standard.
-
-
-
-Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2005). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Normative References
-
- [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
- Signature Standard, 27 January 2000.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative References
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, 11/01/1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, 11/01/1987.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
- (DNS)", D. Eastlake 3rd. May 2001.
-
- [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
- Jones, September 2001.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
-
- [Schneier] - "Applied Cryptography Second Edition: protocols,
- algorithms, and source code in C" (second edition), Bruce Schneier,
- 1996, John Wiley and Sons, ISBN 0-471-11709-9.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Authors Address
-
- Donald E. Eastlake 3rd
- Motorola Labortories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554(w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in January 2006.
-
- Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
+++ /dev/null
-
-
-
-Network Working Group S. Josefsson
-Internet-Draft August 30, 2005
-Expires: March 3, 2006
-
-
- Storing Certificates in the Domain Name System (DNS)
- draft-ietf-dnsext-rfc2538bis-04
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on March 3, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- Cryptographic public keys are frequently published and their
- authenticity demonstrated by certificates. A CERT resource record
- (RR) is defined so that such certificates and related certificate
- revocation lists can be stored in the Domain Name System (DNS).
-
- This document obsoletes RFC 2538.
-
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 1]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3
- 2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4
- 2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5
- 2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6
- 3.1. Content-based X.509 CERT RR Names . . . . . . . . . . . . 7
- 3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8
- 3.3. Content-based OpenPGP CERT RR Names . . . . . . . . . . . 9
- 3.4. Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9
- 3.5. Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9
- 4. Performance Considerations . . . . . . . . . . . . . . . . . . 10
- 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
- 9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
- Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 12
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 2]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-1. Introduction
-
- Public keys are frequently published in the form of a certificate and
- their authenticity is commonly demonstrated by certificates and
- related certificate revocation lists (CRLs). A certificate is a
- binding, through a cryptographic digital signature, of a public key,
- a validity interval and/or conditions, and identity, authorization,
- or other information. A certificate revocation list is a list of
- certificates that are revoked, and incidental information, all signed
- by the signer (issuer) of the revoked certificates. Examples are
- X.509 certificates/CRLs in the X.500 directory system or OpenPGP
- certificates/revocations used by OpenPGP software.
-
- Section 2 below specifies a CERT resource record (RR) for the storage
- of certificates in the Domain Name System [1] [2].
-
- Section 3 discusses appropriate owner names for CERT RRs.
-
- Sections 4, 5, and 6 below cover performance, IANA, and security
- considerations, respectively.
-
- 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 [3].
-
-
-2. The CERT Resource Record
-
- The CERT resource record (RR) has the structure given below. Its RR
- type code is 37.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | type | key tag |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | algorithm | /
- +---------------+ certificate or CRL /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
- The type field is the certificate type as defined in section 2.1
- below.
-
- The key tag field is the 16 bit value computed for the key embedded
- in the certificate, using the RRSIG Key Tag algorithm described in
- Appendix B of [10]. This field is used as an efficiency measure to
- pick which CERT RRs may be applicable to a particular key. The key
-
-
-
-Josefsson Expires March 3, 2006 [Page 3]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- tag can be calculated for the key in question and then only CERT RRs
- with the same key tag need be examined. However, the key must always
- be transformed to the format it would have as the public key portion
- of a DNSKEY RR before the key tag is computed. This is only possible
- if the key is applicable to an algorithm (and limits such as key size
- limits) defined for DNS security. If it is not, the algorithm field
- MUST BE zero and the tag field is meaningless and SHOULD BE zero.
-
- The algorithm field has the same meaning as the algorithm field in
- DNSKEY and RRSIG RRs [10], except that a zero algorithm field
- indicates the algorithm is unknown to a secure DNS, which may simply
- be the result of the algorithm not having been standardized for
- DNSSEC.
-
-2.1. Certificate Type Values
-
- The following values are defined or reserved:
-
- Value Mnemonic Certificate Type
- ----- -------- ----------------
- 0 reserved
- 1 PKIX X.509 as per PKIX
- 2 SPKI SPKI certificate
- 3 PGP OpenPGP packet
- 4 IPKIX The URL of an X.509 data object
- 5 ISPKI The URL of an SPKI certificate
- 6 IPGP The URL of an OpenPGP packet
- 7-252 available for IANA assignment
- 253 URI URI private
- 254 OID OID private
- 255-65534 available for IANA assignment
- 65535 reserved
-
- The PKIX type is reserved to indicate an X.509 certificate conforming
- to the profile being defined by the IETF PKIX working group. The
- certificate section will start with a one-byte unsigned OID length
- and then an X.500 OID indicating the nature of the remainder of the
- certificate section (see 2.3 below). (NOTE: X.509 certificates do
- not include their X.500 directory type designating OID as a prefix.)
-
- The SPKI type is reserved to indicate the SPKI certificate format
- [13], for use when the SPKI documents are moved from experimental
- status.
-
- The PGP type indicates an OpenPGP packet as described in [6] and its
- extensions and successors. Two uses are to transfer public key
- material and revocation signatures. The data is binary, and MUST NOT
- be encoded into an ASCII armor. An implementation SHOULD process
-
-
-
-Josefsson Expires March 3, 2006 [Page 4]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- transferable public keys as described in section 10.1 of [6], but it
- MAY handle additional OpenPGP packets.
-
- The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
- content that would have been in the "certificate, CRL or URL" field
- of the corresponding (PKIX, SPKI or PGP) packet types. These types
- are known as "indirect". These packet types MUST be used when the
- content is too large to fit in the CERT RR, and MAY be used at the
- implementer's discretion. They SHOULD NOT be used where the entire
- UDP packet would have fit in 512 bytes.
-
- The URI private type indicates a certificate format defined by an
- absolute URI. The certificate portion of the CERT RR MUST begin with
- a null terminated URI [5] and the data after the null is the private
- format certificate itself. The URI SHOULD be such that a retrieval
- from it will lead to documentation on the format of the certificate.
- Recognition of private certificate types need not be based on URI
- equality but can use various forms of pattern matching so that, for
- example, subtype or version information can also be encoded into the
- URI.
-
- The OID private type indicates a private format certificate specified
- by an ISO OID prefix. The certificate section will start with a one-
- byte unsigned OID length and then a BER encoded OID indicating the
- nature of the remainder of the certificate section. This can be an
- X.509 certificate format or some other format. X.509 certificates
- that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
- type, not the OID private type. Recognition of private certificate
- types need not be based on OID equality but can use various forms of
- pattern matching such as OID prefix.
-
-2.2. Text Representation of CERT RRs
-
- The RDATA portion of a CERT RR has the type field as an unsigned
- decimal integer or as a mnemonic symbol as listed in section 2.1
- above.
-
- The key tag field is represented as an unsigned decimal integer.
-
- The algorithm field is represented as an unsigned decimal integer or
- a mnemonic symbol as listed in [10].
-
- The certificate / CRL portion is represented in base 64 [14] and may
- be divided up into any number of white space separated substrings,
- down to single base 64 digits, which are concatenated to obtain the
- full signature. These substrings can span lines using the standard
- parenthesis.
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 5]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- Note that the certificate / CRL portion may have internal sub-fields,
- but these do not appear in the master file representation. For
- example, with type 254, there will be an OID size, an OID, and then
- the certificate / CRL proper. But only a single logical base 64
- string will appear in the text representation.
-
-2.3. X.509 OIDs
-
- OIDs have been defined in connection with the X.500 directory for
- user certificates, certification authority certificates, revocations
- of certification authority, and revocations of user certificates.
- The following table lists the OIDs, their BER encoding, and their
- length-prefixed hex format for use in CERT RRs:
-
- id-at-userCertificate
- = { joint-iso-ccitt(2) ds(5) at(4) 36 }
- == 0x 03 55 04 24
- id-at-cACertificate
- = { joint-iso-ccitt(2) ds(5) at(4) 37 }
- == 0x 03 55 04 25
- id-at-authorityRevocationList
- = { joint-iso-ccitt(2) ds(5) at(4) 38 }
- == 0x 03 55 04 26
- id-at-certificateRevocationList
- = { joint-iso-ccitt(2) ds(5) at(4) 39 }
- == 0x 03 55 04 27
-
-
-3. Appropriate Owner Names for CERT RRs
-
- It is recommended that certificate CERT RRs be stored under a domain
- name related to their subject, i.e., the name of the entity intended
- to control the private key corresponding to the public key being
- certified. It is recommended that certificate revocation list CERT
- RRs be stored under a domain name related to their issuer.
-
- Following some of the guidelines below may result in the use in DNS
- names of characters that require DNS quoting which is to use a
- backslash followed by the octal representation of the ASCII code for
- the character (e.g., \000 for NULL).
-
- The choice of name under which CERT RRs are stored is important to
- clients that perform CERT queries. In some situations, the clients
- may not know all information about the CERT RR object it wishes to
- retrieve. For example, a client may not know the subject name of an
- X.509 certificate, or the e-mail address of the owner of an OpenPGP
- key. Further, the client might only know the hostname of a service
- that uses X.509 certificates or the Key ID of an OpenPGP key.
-
-
-
-Josefsson Expires March 3, 2006 [Page 6]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- Therefore, two owner name guidelines are defined: content-based owner
- names and purpose-based owner names. A content-based owner name is
- derived from the content of the CERT RR data; for example, the
- Subject field in an X.509 certificate or the User ID field in OpenPGP
- keys. A purpose-based owner name is a name that a client retrieving
- CERT RRs MUST already know; for example, the host name of an X.509
- protected service or the Key ID of an OpenPGP key. The content-based
- and purpose-based owner name MAY be the same; for example, when a
- client looks up a key based on the From: address of an incoming
- e-mail.
-
- Implementations SHOULD use the purpose-based owner name guidelines
- described in this document, and MAY use CNAMEs of content-based owner
- names (or other names), pointing to the purpose-based owner name.
-
-3.1. Content-based X.509 CERT RR Names
-
- Some X.509 versions permit multiple names to be associated with
- subjects and issuers under "Subject Alternate Name" and "Issuer
- Alternate Name". For example, X.509v3 has such Alternate Names with
- an ASN.1 specification as follows:
-
- GeneralName ::= CHOICE {
- otherName [0] INSTANCE OF OTHER-NAME,
- rfc822Name [1] IA5String,
- dNSName [2] IA5String,
- x400Address [3] EXPLICIT OR-ADDRESS.&Type,
- directoryName [4] EXPLICIT Name,
- ediPartyName [5] EDIPartyName,
- uniformResourceIdentifier [6] IA5String,
- iPAddress [7] OCTET STRING,
- registeredID [8] OBJECT IDENTIFIER
- }
-
- The recommended locations of CERT storage are as follows, in priority
- order:
- 1. If a domain name is included in the identification in the
- certificate or CRL, that should be used.
- 2. If a domain name is not included but an IP address is included,
- then the translation of that IP address into the appropriate
- inverse domain name should be used.
- 3. If neither of the above is used, but a URI containing a domain
- name is present, that domain name should be used.
- 4. If none of the above is included but a character string name is
- included, then it should be treated as described for OpenPGP
- names below.
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 7]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- 5. If none of the above apply, then the distinguished name (DN)
- should be mapped into a domain name as specified in [4].
-
- Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
- DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
- string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
- uri <https://www.secure.john-doe.com:8080/>. The storage locations
- recommended, in priority order, would be
- 1. john-doe.com,
- 2. www.secure.john-doe.com, and
- 3. Doe.com.xy.
-
- Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
- L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
- domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
- (c) string "James Hacker <hacker@mail.widget.foo.example>". The
- storage locations recommended, in priority order, would be
- 1. widget.foo.example,
- 2. 201.13.251.10.in-addr.arpa, and
- 3. hacker.mail.widget.foo.example.
-
-3.2. Purpose-based X.509 CERT RR Names
-
- Due to the difficulty for clients that do not already possess a
- certificate to reconstruct the content-based owner name, purpose-
- based owner names are recommended in this section. Recommendations
- for purpose-based owner names vary per scenario. The following table
- summarizes the purpose-based X.509 CERT RR owner name guidelines for
- use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:
-
- Scenario Owner name
- ------------------ ----------------------------------------------
- S/MIME Certificate Standard translation of an RFC 2822 email
- address. Example: An S/MIME certificate for
- "postmaster@example.org" will use a standard
- hostname translation of the owner name,
- "postmaster.example.org".
-
- TLS Certificate Hostname of the TLS server.
-
- IPSEC Certificate Hostname of the IPSEC machine and/or, for IPv4
- or IPv6 addresses, the fully qualified domain
- name in the appropriate reverse domain.
-
- An alternate approach for IPSEC is to store raw public keys [15].
-
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 8]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-3.3. Content-based OpenPGP CERT RR Names
-
- OpenPGP signed keys (certificates) use a general character string
- User ID [6]. However, it is recommended by OpenPGP that such names
- include the RFC 2822 [8] email address of the party, as in "Leslie
- Example <Leslie@host.example>". If such a format is used, the CERT
- should be under the standard translation of the email address into a
- domain name, which would be leslie.host.example in this case. If no
- RFC 2822 name can be extracted from the string name, no specific
- domain name is recommended.
-
- If a user has more than one email address, the CNAME type can be used
- to reduce the amount of data stored in the DNS. Example:
-
- $ORIGIN example.org.
- smith IN CERT PGP 0 0 <OpenPGP binary>
- john.smith IN CNAME smith
- js IN CNAME smith
-
-3.4. Purpose-based OpenPGP CERT RR Names
-
- Applications that receive an OpenPGP packet containing encrypted or
- signed data but do not know the email address of the sender will have
- difficulties constructing the correct owner name and cannot use the
- content-based owner name guidelines. However, these clients commonly
- know the key fingerprint or the Key ID. The key ID is found in
- OpenPGP packets, and the key fingerprint is commonly found in
- auxilliary data that may be available. In this case, use of an owner
- name identical to the key fingerprint and the key ID expressed in
- hexadecimal [14] is recommended. Example:
-
- $ORIGIN example.org.
- 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
- F835EDA21E94B565716F IN CERT PGP ...
- B565716F IN CERT PGP ...
-
- If the same key material is stored for several owner names, the use
- of CNAME may be used to avoid data duplication. Note that CNAME is
- not always applicable, because it maps one owner name to the other
- for all purposes, which may be sub-optimal when two keys with the
- same Key ID are stored.
-
-3.5. Owner names for IPKIX, ISPKI, and IPGP
-
- These types are stored under the same owner names, both purpose- and
- content-based, as the PKIX, SPKI and PGP types.
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 9]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-4. Performance Considerations
-
- Current Domain Name System (DNS) implementations are optimized for
- small transfers, typically not more than 512 bytes including
- overhead. While larger transfers will perform correctly and work is
- underway to make larger transfers more efficient, it is still
- advisable at this time to make every reasonable effort to minimize
- the size of certificates stored within the DNS. Steps that can be
- taken may include using the fewest possible optional or extension
- fields and using short field values for necessary variable length
- fields.
-
- The RDATA field in the DNS protocol may only hold data of size 65535
- octets (64kb) or less. This means that each CERT RR MUST NOT contain
- more than 64kb of payload, even if the corresponding certificate or
- certificate revocation list is larger. This document addresses this
- by defining "indirect" data types for each normal type.
-
-
-5. Contributors
-
- The majority of this document is copied verbatim from RFC 2538, by
- Donald Eastlake 3rd and Olafur Gudmundsson.
-
-
-6. Acknowledgements
-
- Thanks to David Shaw and Michael Graff for their contributions to
- earlier works that motivated, and served as inspiration for, this
- document.
-
- This document was improved by suggestions and comments from Olivier
- Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
- Sloderbeck, Samuel Weiler, and Florian Weimer. No doubt the list is
- incomplete. We apologize to anyone we left out.
-
-
-7. Security Considerations
-
- By definition, certificates contain their own authenticating
- signature. Thus, it is reasonable to store certificates in non-
- secure DNS zones or to retrieve certificates from DNS with DNS
- security checking not implemented or deferred for efficiency. The
- results MAY be trusted if the certificate chain is verified back to a
- known trusted key and this conforms with the user's security policy.
-
- Alternatively, if certificates are retrieved from a secure DNS zone
- with DNS security checking enabled and are verified by DNS security,
-
-
-
-Josefsson Expires March 3, 2006 [Page 10]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- the key within the retrieved certificate MAY be trusted without
- verifying the certificate chain if this conforms with the user's
- security policy.
-
- If an organization chooses to issue certificates for it's employees,
- placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
- is in use, it is possible for someone to enumerate all employees of
- the organization. This is usually not considered desirable, for the
- same reason enterprise phone listings are not often publicly
- published and are even mark confidential.
-
- When the URI type is used, it should be understood that it introduces
- an additional indirection that may allow for a new attack vector.
- One method to secure that indirection is to include a hash of the
- certificate in the URI itself.
-
- CERT RRs are not used by DNSSEC [9], so there are no security
- considerations related to CERT RRs and securing the DNS itself.
-
- If DNSSEC is used, then the non-existence of a CERT RR and,
- consequently, certificates or revocation lists can be securely
- asserted. Without DNSSEC, this is not possible.
-
-
-8. IANA Considerations
-
- Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
- only be assigned by an IETF standards action [7]. This document
- assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate
- types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
- based on RFC documentation of the certificate type. The availability
- of private types under 0x00FD and 0x00FE should satisfy most
- requirements for proprietary or private types.
-
- The CERT RR reuses the DNS Security Algorithm Numbers registry. In
- particular, the CERT RR requires that algorithm number 0 remain
- reserved, as described in Section 2. The IANA is directed to
- reference the CERT RR as a user of this registry and value 0, in
- particular.
-
-
-9. Changes since RFC 2538
-
- 1. Editorial changes to conform with new document requirements,
- including splitting reference section into two parts and
- updating the references to point at latest versions, and to add
- some additional references.
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 11]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- 2. Improve terminology. For example replace "PGP" with "OpenPGP",
- to align with RFC 2440.
- 3. In section 2.1, clarify that OpenPGP public key data are binary,
- not the ASCII armored format, and reference 10.1 in RFC 2440 on
- how to deal with OpenPGP keys, and acknowledge that
- implementations may handle additional packet types.
- 4. Clarify that integers in the representation format are decimal.
- 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
- terminology. Improve reference for Key Tag Algorithm
- calculations.
- 6. Add examples that suggest use of CNAME to reduce bandwidth.
- 7. In section 3, appended the last paragraphs that discuss
- "content-based" vs "purpose-based" owner names. Add section 3.2
- for purpose-based X.509 CERT owner names, and section 3.4 for
- purpose-based OpenPGP CERT owner names.
- 8. Added size considerations.
- 9. The SPKI types has been reserved, until RFC 2692/2693 is moved
- from the experimental status.
- 10. Added indirect types IPKIX, ISPKI, and IPGP.
-
-
-Appendix A. Copying conditions
-
- Regarding the portion of this document that was written by Simon
- Josefsson ("the author", for the remainder of this section), the
- author makes no guarantees and is not responsible for any damage
- resulting from its use. The author grants irrevocable permission to
- anyone to use, modify, and distribute it in any way that does not
- diminish the rights of anyone else to use, modify, and distribute it,
- provided that redistributed derivative works do not contain
- misleading author or version information. Derivative works need not
- be licensed under similar terms.
-
-
-10. References
-
-10.1. Normative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
-
-
-
-Josefsson Expires March 3, 2006 [Page 12]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
- "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
- January 1998.
-
- [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifiers (URI): Generic Syntax", RFC 2396,
- August 1998.
-
- [6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
- "OpenPGP Message Format", RFC 2440, November 1998.
-
- [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
- [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-10.2. Informative References
-
- [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
- RFC 2246, January 1999.
-
- [12] Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
- [13] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
- and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
- September 1999.
-
- [14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
- RFC 3548, July 2003.
-
- [15] Richardson, M., "A Method for Storing IPsec Keying Material in
- DNS", RFC 4025, March 2005.
-
- [16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
- (S/MIME) Version 3.1 Message Specification", RFC 3851,
- July 2004.
-
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 13]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-Author's Address
-
- Simon Josefsson
-
- Email: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 14]
-\f
-Internet-Draft Storing Certificates in the DNS August 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Josefsson Expires March 3, 2006 [Page 15]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: January 2006 July 2005
-
-
-
-
- Storage of Diffie-Hellman Keying Information in the DNS
- ------- -- -------------- ------ ----------- -- --- ---
- <draft-ietf-dnsext-rfc2539bis-dhk-06.txt>
-
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method for encoding Diffie-Hellman keys in the Domain
- Name System is specified.
-
-
-
-Copyright
-
- Copyright (C) The Internet Society 2005.
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Acknowledgements
-
- Part of the format for Diffie-Hellman keys and the description
- thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
- and Hemma Prafullchandra. In addition, the following persons
- provided useful comments that were incorporated into the predecessor
- of this document: Ran Atkinson, Thomas Narten.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright..................................................1
-
- Acknowledgements...........................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 1.1 About This Document....................................3
- 1.2 About Diffie-Hellman...................................3
- 2. Encoding Diffie-Hellman Keying Information..............4
- 3. Performance Considerations..............................5
- 4. IANA Considerations.....................................5
- 5. Security Considerations.................................5
- Copyright and Disclaimer...................................5
-
- Normative References.......................................7
- Informative Refences.......................................7
-
- Author Address.............................................8
- Expiration and File Name...................................8
-
- Appendix A: Well known prime/generator pairs...............9
- A.1. Well-Known Group 1: A 768 bit prime..................9
- A.2. Well-Known Group 2: A 1024 bit prime.................9
- A.3. Well-Known Group 3: A 1536 bit prime................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- similar information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additonal work is underway which would use
- the storage of keying information in the DNS.
-
-
-
-1.1 About This Document
-
- This document describes how to store Diffie-Hellman keys in the DNS.
- Familiarity with the Diffie-Hellman key exchange algorithm is assumed
- [Schneier, RFC 2631].
-
-
-
-1.2 About Diffie-Hellman
-
- Diffie-Hellman requires two parties to interact to derive keying
- information which can then be used for authentication. Thus Diffie-
- Hellman is inherently a key agreement algorithm. As a result, no
- format is defined for Diffie-Hellman "signature information". For
- example, assume that two parties have local secrets "i" and "j".
- Assume they each respectively calculate X and Y as follows:
-
- X = g**i ( mod p )
-
- Y = g**j ( mod p )
-
- They exchange these quantities and then each calculates a Z as
- follows:
-
- Zi = Y**i ( mod p )
-
- Zj = X**j ( mod p )
-
- Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
- secret between the two parties that an adversary who does not know i
- or j will not be able to learn from the exchanged messages (unless
- the adversary can derive i or j by performing a discrete logarithm
- mod p which is hard for strong p and g).
-
- The private key for each party is their secret i (or j). The public
- key is the pair p and g, which must be the same for the parties, and
- their individual X (or Y).
-
- For further information about Diffie-Hellman and precautions to take
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
- When Diffie-Hellman keys appear within the RDATA portion of a RR,
- they are encoded as shown below.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | KEY flags | protocol | algorithm=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | prime length (or flag) | prime (p) (or special) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / prime (p) (variable length) | generator length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | generator (g) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | public value length | public value (variable length)/
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / public value (g^i mod p) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Prime length is the length of the Diffie-Hellman prime (p) in bytes
- if it is 16 or greater. Prime contains the binary representation of
- the Diffie-Hellman prime with most significant byte first (i.e., in
- network order). If "prime length" field is 1 or 2, then the "prime"
- field is actually an unsigned index into a table of 65,536
- prime/generator pairs and the generator length SHOULD be zero. See
- Appedix A for defined table entries and Section 4 for information on
- allocating additional table entries. The meaning of a zero or 3
- through 15 value for "prime length" is reserved.
-
- Generator length is the length of the generator (g) in bytes.
- Generator is the binary representation of generator with most
- significant byte first. PublicValueLen is the Length of the Public
- Value (g**i (mod p)) in bytes. PublicValue is the binary
- representation of the DH public value with most significant byte
- first.
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-3. Performance Considerations
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient. But
- it is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying information consistent
- with adequate security.
-
-
-
-4. IANA Considerations
-
- Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
- an IETF consensus as defined in [RFC 2434].
-
- Well known prime/generator pairs number 0x0000 through 0x07FF can
- only be assigned by an IETF standards action. [RFC 2539], the
- Proposed Standard predecessor of this document, assigned 0x0001
- through 0x0002. This document additionally assigns 0x0003. Pairs
- number 0s0800 through 0xBFFF can be assigned based on RFC
- documentation. Pairs number 0xC000 through 0xFFFF are available for
- private use and are not centrally coordinated. Use of such private
- pairs outside of a closed environment may result in conflicts and/or
- security failures.
-
-
-
-5. Security Considerations
-
- Keying information retrieved from the DNS should not be trusted
- unless (1) it has been securely obtained from a secure resolver or
- independently verified by the user and (2) this secure resolver and
- secure obtainment or independent verification conform to security
- policies acceptable to the user. As with all cryptographic
- algorithms, evaluating the necessary strength of the key is important
- and dependent on security policy.
-
- In addition, the usual Diffie-Hellman key strength considerations
- apply. (p-1)/2 should also be prime, g should be primitive mod p, p
- should be "large", etc. See [RFC 2631, Schneier].
-
-
-
-Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2005). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Normative References
-
- [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
- 1999.
-
- [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
- in RFCs", T. Narten, H. Alvestrand, October 1998.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative Refences
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, November 1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, November 1987.
-
- [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
- System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
- and Sons.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Author Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in January 2006.
-
- Its file name is draft-ietf-dnsext-rfc2539bis-dhk-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
- These numbers are copied from the IPSEC effort where the derivation of
- these values is more fully explained and additional information is
- available.
- Richard Schroeppel performed all the mathematical and computational
- work for this appendix.
-
-
-
-A.1. Well-Known Group 1: A 768 bit prime
-
- The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
- decimal value is
- 155251809230070893513091813125848175563133404943451431320235
- 119490296623994910210725866945387659164244291000768028886422
- 915080371891804634263272761303128298374438082089019628850917
- 0691316593175367469551763119843371637221007210577919
-
- Prime modulus: Length (32 bit words): 24, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2: A 1024 bit prime
-
- The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
- Its decimal value is
- 179769313486231590770839156793787453197860296048756011706444
- 423684197180216158519368947833795864925541502180565485980503
- 646440548199239100050792877003355816639229553136239076508735
- 759914822574862575007425302077447712589550957937778424442426
- 617334727629299387668709205606050270810842907692932019128194
- 467627007
-
- Prime modulus: Length (32 bit words): 32, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
- FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-A.3. Well-Known Group 3: A 1536 bit prime
-
- The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
- Its decimal value is
- 241031242692103258855207602219756607485695054850245994265411
- 694195810883168261222889009385826134161467322714147790401219
- 650364895705058263194273070680500922306273474534107340669624
- 601458936165977404102716924945320037872943417032584377865919
- 814376319377685986952408894019557734611984354530154704374720
- 774996976375008430892633929555996888245787241299381012913029
- 459299994792636526405928464720973038494721168143446471443848
- 8520940127459844288859336526896320919633919
-
- Prime modulus Length (32 bit words): 48, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
- C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
- 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
- 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-\f
+++ /dev/null
-
-
-
-
-Network Working Group M. StJohns
-Internet-Draft Nominum, Inc.
-Expires: July 14, 2006 January 10, 2006
-
-
- Automated Updates of DNSSEC Trust Anchors
- draft-ietf-dnsext-trustupdate-timers-02
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on July 14, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes a means for automated, authenticated and
- authorized updating of DNSSEC "trust anchors". The method provides
- protection against single key compromise of a key in the trust point
- key set. Based on the trust established by the presence of a current
- anchor, other anchors may be added at the same place in the
- hierarchy, and, ultimately, supplant the existing anchor.
-
- This mechanism, if adopted, will require changes to resolver
- management behavior (but not resolver resolution behavior), and the
-
-
-
-StJohns Expires July 14, 2006 [Page 1]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
- addition of a single flag bit to the DNSKEY record.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
- 1.2. Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
- 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
- 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
- 2.3. Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
- 2.4. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
- 2.5. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
- 2.5.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
- 2.5.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
- 2.5.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6
- 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
- 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4.3. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 8
- 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5.1. Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 9
- 5.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
- 5.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
- 5.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 9
- 5.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 7.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
- 7.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
- 7.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
- 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
- Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
- Intellectual Property and Copyright Statements . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires July 14, 2006 [Page 2]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
-1. Introduction
-
- As part of the reality of fielding DNSSEC (Domain Name System
- Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
- community has come to the realization that there will not be one
- signed name space, but rather islands of signed name space each
- originating from specific points (i.e. 'trust points') in the DNS
- tree. Each of those islands will be identified by the trust point
- name, and validated by at least one associated public key. For the
- purpose of this document we'll call the association of that name and
- a particular key a 'trust anchor'. A particular trust point can have
- more than one key designated as a trust anchor.
-
- For a DNSSEC-aware resolver to validate information in a DNSSEC
- protected branch of the hierarchy, it must have knowledge of a trust
- anchor applicable to that branch. It may also have more than one
- trust anchor for any given trust point. Under current rules, a chain
- of trust for DNSSEC-protected data that chains its way back to ANY
- known trust anchor is considered 'secure'.
-
- Because of the probable balkanization of the DNSSEC tree due to
- signing voids at key locations, a resolver may need to know literally
- thousands of trust anchors to perform its duties. (e.g. Consider an
- unsigned ".COM".) Requiring the owner of the resolver to manually
- manage this many relationships is problematic. It's even more
- problematic when considering the eventual requirement for key
- replacement/update for a given trust anchor. The mechanism described
- herein won't help with the initial configuration of the trust anchors
- in the resolvers, but should make trust point key replacement/
- rollover more viable.
-
- As mentioned above, this document describes a mechanism whereby a
- resolver can update the trust anchors for a given trust point, mainly
- without human intervention at the resolver. There are some corner
- cases discussed (e.g. multiple key compromise) that may require
- manual intervention, but they should be few and far between. This
- document DOES NOT discuss the general problem of the initial
- configuration of trust anchors for the resolver.
-
-1.1. Compliance Nomenclature
-
- 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 BCP 14, [RFC2119].
-
-1.2. Changes since -00
-
- Added the concept of timer triggered resolver queries to refresh the
-
-
-
-StJohns Expires July 14, 2006 [Page 3]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
- resolvers view of the trust anchor key RRSet.
-
- Re-submitted expired draft as -01. Updated DNSSEC RFC References.
-
- Draft -02. Added the IANA Considerations section. Added text to
- describe what happens if all trust anchors at a trust point are
- deleted.
-
-
-2. Theory of Operation
-
- The general concept of this mechanism is that existing trust anchors
- can be used to authenticate new trust anchors at the same point in
- the DNS hierarchy. When a new SEP key is added to a trust point
- DNSKEY RRSet, and when that RRSet is validated by an existing trust
- anchor, then the new key can be added to the set of trust anchors.
-
- There are some issues with this approach which need to be mitigated.
- For example, a compromise of one of the existing keys could allow an
- attacker to add their own 'valid' data. This implies a need for a
- method to revoke an existing key regardless of whether or not that
- key is compromised. As another example assuming a single key
- compromise, an attacker could add a new key and revoke all the other
- old keys.
-
-2.1. Revocation
-
- Assume two trust anchor keys A and B. Assume that B has been
- compromised. Without a specific revocation bit, B could invalidate A
- simply by sending out a signed trust point key set which didn't
- contain A. To fix this, we add a mechanism which requires knowledge
- of the private key of a DNSKEY to revoke that DNSKEY.
-
- A key is considered revoked when the resolver sees the key in a self-
- signed RRSet and the key has the REVOKE bit (see Section 6 below) set
- to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this
- key as a trust anchor or for any other purposes except validating the
- RRSIG over the DNSKEY RRSet specifically for the purpose of
- validating the revocation. Unlike the 'Add' operation below,
- revocation is immediate and permanent upon receipt of a valid
- revocation at the resolver.
-
- N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
- than one without the bit set. This affects the matching of a DNSKEY
- to DS records in the parent, or the fingerprint stored at a resolver
- used to configure a trust point. [msj3]
-
- In the given example, the attacker could revoke B because it has
-
-
-
-StJohns Expires July 14, 2006 [Page 4]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
- knowledge of B's private key, but could not revoke A.
-
-2.2. Add Hold-Down
-
- Assume two trust point keys A and B. Assume that B has been
- compromised. An attacker could generate and add a new trust anchor
- key - C (by adding C to the DNSKEY RRSet and signing it with B), and
- then invalidate the compromised key. This would result in the both
- the attacker and owner being able to sign data in the zone and have
- it accepted as valid by resolvers.
-
- To mitigate, but not completely solve, this problem, we add a hold-
- down time to the addition of the trust anchor. When the resolver
- sees a new SEP key in a validated trust point DNSKEY RRSet, the
- resolver starts an acceptance timer, and remembers all the keys that
- validated the RRSet. If the resolver ever sees the DNSKEY RRSet
- without the new key but validly signed, it stops the acceptance
- process and resets the acceptance timer. If all of the keys which
- were originally used to validate this key are revoked prior to the
- timer expiring, the resolver stops the acceptance process and resets
- the timer.
-
- Once the timer expires, the new key will be added as a trust anchor
- the next time the validated RRSet with the new key is seen at the
- resolver. The resolver MUST NOT treat the new key as a trust anchor
- until the hold down time expires AND it has retrieved and validated a
- DNSKEY RRSet after the hold down time which contains the new key.
-
- N.B.: Once the resolver has accepted a key as a trust anchor, the key
- MUST be considered a valid trust anchor by that resolver until
- explictly revoked as described above.
-
- In the given example, the zone owner can recover from a compromise by
- revoking B and adding a new key D and signing the DNSKEY RRSet with
- both A and B.
-
- The reason this does not completely solve the problem has to do with
- the distributed nature of DNS. The resolver only knows what it sees.
- A determined attacker who holds one compromised key could keep a
- single resolver from realizing that key had been compromised by
- intercepting 'real' data from the originating zone and substituting
- their own (e.g. using the example, signed only by B). This is no
- worse than the current situation assuming a compromised key.
-
-2.3. Remove Hold-down
-
- A new key which has been seen by the resolver, but hasn't reached
- it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
-
-
-
-StJohns Expires July 14, 2006 [Page 5]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
- zone owner. If the resolver sees a validated DNSKEY RRSet without
- this key, it waits for the remove hold-down time and then, if the key
- hasn't reappeared, SHOULD discard any information about the key.
-
-2.4. Active Refresh
-
- A resolver which has been configured for automatic update of keys
- from a particular trust point MUST query that trust point (e.g. do a
- lookup for the DNSKEY RRSet and related RRSIG records) no less often
- than the lesser of 15 days or half the original TTL for the DNSKEY
- RRSet or half the RRSIG expiration interval. The expiration interval
- is the amount of time from when the RRSIG was last retrieved until
- the expiration time in the RRSIG.
-
- If the query fails, the resolver MUST repeat the query until
- satisfied no more often than once an hour and no less often than the
- lesser of 1 day or 10% of the original TTL or 10% of the original
- expiration interval.
-
-2.5. Resolver Parameters
-
-2.5.1. Add Hold-Down Time
-
- The add hold-down time is 30 days or the expiration time of the TTL
- of the first trust point DNSKEY RRSet which contained the key,
- whichever is greater. This ensures that at least two validated
- DNSKEY RRSets which contain the new key MUST be seen by the resolver
- prior to the key's acceptance.
-
-2.5.2. Remove Hold-Down Time
-
- The remove hold-down time is 30 days.
-
-2.5.3. Minimum Trust Anchors per Trust Point
-
- A compliant resolver MUST be able to manage at least five SEP keys
- per trust point.
-
-
-3. Changes to DNSKEY RDATA Wire Format
-
- Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
- flag. If this bit is set to '1', AND the resolver sees an
- RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
- consider this key permanently invalid for all purposes except for
- validing the revocation.
-
-
-
-
-
-StJohns Expires July 14, 2006 [Page 6]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
-4. State Table
-
- The most important thing to understand is the resolver's view of any
- key at a trust point. The following state table describes that view
- at various points in the key's lifetime. The table is a normative
- part of this specification. The initial state of the key is 'Start'.
- The resolver's view of the state of the key changes as various events
- occur.
-
- [msj1] This is the state of a trust point key as seen from the
- resolver. The column on the left indicates the current state. The
- header at the top shows the next state. The intersection of the two
- shows the event that will cause the state to transition from the
- current state to the next.
-
- NEXT STATE
- --------------------------------------------------
- FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
- ----------------------------------------------------------
- Start | |NewKey | | | | |
- ----------------------------------------------------------
- AddPend |KeyRem | |AddTime| | |
- ----------------------------------------------------------
- Valid | | | |KeyRem |Revbit | |
- ----------------------------------------------------------
- Missing | | |KeyPres| |Revbit | |
- ----------------------------------------------------------
- Revoked | | | | | |RemTime|
- ----------------------------------------------------------
- Removed | | | | | | |
- ----------------------------------------------------------
-
-4.1. Events
- NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
- That key will become a new trust anchor for the named trust point
- after its been present in the RRSet for at least 'add time'.
- KeyPres The key has returned to the valid DNSKEY RRSet.
- KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
- this key.
- AddTime The key has been in every valid DNSKEY RRSet seen for at
- least the 'add time'.
- RemTime A revoked key has been missing from the trust point DNSKEY
- RRSet for sufficient time to be removed from the trust set.
- RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
- "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
- signed by this key.
-
-
-
-
-
-StJohns Expires July 14, 2006 [Page 7]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
-4.2. States
- Start The key doesn't yet exist as a trust anchor at the resolver.
- It may or may not exist at the zone server, but hasn't yet been
- seen at the resolver.
- AddPend The key has been seen at the resolver, has its 'SEP' bit set,
- and has been included in a validated DNSKEY RRSet. There is a
- hold-down time for the key before it can be used as a trust
- anchor.
- Valid The key has been seen at the resolver and has been included in
- all validated DNSKEY RRSets from the time it was first seen up
- through the hold-down time. It is now valid for verifying RRSets
- that arrive after the hold down time. Clarification: The DNSKEY
- RRSet does not need to be continuously present at the resolver
- (e.g. its TTL might expire). If the RRSet is seen, and is
- validated (i.e. verifies against an existing trust anchor), this
- key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
- Missing This is an abnormal state. The key remains as a valid trust
- point key, but was not seen at the resolver in the last validated
- DNSKEY RRSet. This is an abnormal state because the zone operator
- should be using the REVOKE bit prior to removal. [Discussion
- item: Should a missing key be considered revoked after some period
- of time?]
- Revoked This is the state a key moves to once the resolver sees an
- RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
- this key with its REVOKE bit set to '1'. Once in this state, this
- key MUST permanently be considered invalid as a trust anchor.
- Removed After a fairly long hold-down time, information about this
- key may be purged from the resolver. A key in the removed state
- MUST NOT be considered a valid trust anchor.
-
-4.3. Trust Point Deletion
-
- A trust point which has all of its trust anchors revoked is
- considered deleted and is treated as if the trust point was never
- configured. If there are no superior trust points, data at and below
- the deleted trust point are considered insecure. If there there ARE
- superior trust points, data at and below the deleted trust point are
- evaluated with respect to the superior trust point.
-
-
-5. Scenarios
-
- The suggested model for operation is to have one active key and one
- stand-by key at each trust point. The active key will be used to
- sign the DNSKEY RRSet. The stand-by key will not normally sign this
- RRSet, but the resolver will accept it as a trust anchor if/when it
- sees the signature on the trust point DNSKEY RRSet.
-
-
-
-
-StJohns Expires July 14, 2006 [Page 8]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
- Since the stand-by key is not in active signing use, the associated
- private key may (and SHOULD) be provided with additional protections
- not normally available to a key that must be used frequently. E.g.
- locked in a safe, split among many parties, etc. Notionally, the
- stand-by key should be less subject to compromise than an active key,
- but that will be dependent on operational concerns not addressed
- here.
-
-5.1. Adding A Trust Anchor
-
- Assume an existing trust anchor key 'A'.
- 1. Generate a new key pair.
- 2. Create a DNSKEY record from the key pair and set the SEP and Zone
- Key bits.
- 3. Add the DNSKEY to the RRSet.
- 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
- 'A'.
- 5. Wait a while.
-
-5.2. Deleting a Trust Anchor
-
- Assume existing trust anchors 'A' and 'B' and that you want to revoke
- and delete 'A'.
- 1. Set the revolcation bit on key 'A'.
- 2. Sign the DNSKEY RRSet with both 'A' and 'B'.
- 'A' is now revoked. The operator SHOULD include the revoked 'A' in
- the RRSet for at least the remove hold-down time, but then may remove
- it from the DNSKEY RRSet.
-
-5.3. Key Roll-Over
-
- Assume existing keys A and B. 'A' is actively in use (i.e. has been
- signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been
- in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
- used to sign the RRSet.)
- 1. Generate a new key pair 'C'.
- 2. Add 'C' to the DNSKEY RRSet.
- 3. Set the revocation bit on key 'A'.
- 4. Sign the RRSet with 'A' and 'B'.
- 'A' is now revoked, 'B' is now the active key, and 'C' will be the
- stand-by key once the hold-down expires. The operator SHOULD include
- the revoked 'A' in the RRSet for at least the remove hold-down time,
- but may then remove it from the DNSKEY RRSet.
-
-5.4. Active Key Compromised
-
- This is the same as the mechanism for Key Roll-Over (Section 5.3)
- above assuming 'A' is the active key.
-
-
-
-StJohns Expires July 14, 2006 [Page 9]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
-5.5. Stand-by Key Compromised
-
- Using the same assumptions and naming conventions as Key Roll-Over
- (Section 5.3) above:
- 1. Generate a new key pair 'C'.
- 2. Add 'C' to the DNSKEY RRSet.
- 3. Set the revocation bit on key 'B'.
- 4. Sign the RRSet with 'A' and 'B'.
- 'B' is now revoked, 'A' remains the active key, and 'C' will be the
- stand-by key once the hold-down expires. 'B' SHOULD continue to be
- included in the RRSet for the remove hold-down time.
-
-
-6. IANA Considerations
-
- The IANA will need to assign a bit in the DNSKEY flags field (see
- section 4.3 of [RFC3755]) for the REVOKE bit. There are no other
- IANA actions required.
-
-
-7. Security Considerations
-
-7.1. Key Ownership vs Acceptance Policy
-
- The reader should note that, while the zone owner is responsible
- creating and distributing keys, it's wholly the decision of the
- resolver owner as to whether to accept such keys for the
- authentication of the zone information. This implies the decision
- update trust anchor keys based on trust for a current trust anchor
- key is also the resolver owner's decision.
-
- The resolver owner (and resolver implementers) MAY choose to permit
- or prevent key status updates based on this mechanism for specific
- trust points. If they choose to prevent the automated updates, they
- will need to establish a mechanism for manual or other out-of-band
- updates outside the scope of this document.
-
-7.2. Multiple Key Compromise
-
- This scheme permits recovery as long as at least one valid trust
- anchor key remains uncompromised. E.g. if there are three keys, you
- can recover if two of them are compromised. The zone owner should
- determine their own level of comfort with respect to the number of
- active valid trust anchors in a zone and should be prepared to
- implement recovery procedures once they detect a compromise. A
- manual or other out-of-band update of all resolvers will be required
- if all trust anchor keys at a trust point are compromised.
-
-
-
-
-StJohns Expires July 14, 2006 [Page 10]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
-7.3. Dynamic Updates
-
- Allowing a resolver to update its trust anchor set based in-band key
- information is potentially less secure than a manual process.
- However, given the nature of the DNS, the number of resolvers that
- would require update if a trust anchor key were compromised, and the
- lack of a standard management framework for DNS, this approach is no
- worse than the existing situation.
-
-8. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer (DS)", RFC 3755, May 2004.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
-Editorial Comments
-
- [msj1] msj: N.B. This table is preliminary and will be revised to
- match implementation experience. For example, should there
- be a state for "Add hold-down expired, but haven't seen the
- new RRSet"?
-
- [msj2] msj: To be assigned.
-
- [msj3] msj: For discussion: What's the implementation guidance for
- resolvers currently with respect to the non-assigned flag
- bits? If they consider the flag bit when doing key matching
- at the trust anchor, they won't be able to match.
-
-
-
-
-
-
-StJohns Expires July 14, 2006 [Page 11]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
-Author's Address
-
- Michael StJohns
- Nominum, Inc.
- 2385 Bay Road
- Redwood City, CA 94063
- USA
-
- Phone: +1-301-528-4729
- Email: Mike.StJohns@nominum.com
- URI: www.nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires July 14, 2006 [Page 12]
-\f
-Internet-Draft trustanchor-update January 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-StJohns Expires July 14, 2006 [Page 13]
-\f
-
+++ /dev/null
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-UPDATES RFC 2845 Motorola Laboratories
-Expires: July 2006 January 2006
-
- HMAC SHA TSIG Algorithm Identifiers
- ---- --- ---- --------- -----------
- <draft-ietf-dnsext-tsig-sha-06.txt>
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- Use of the Domain Name System TSIG resource record requires
- specification of a cryptographic message authentication code.
- Currently identifiers have been specified only for the HMAC MD5
- (Message Digest) and GSS (Generic Security Service) TSIG algorithms.
- This document standardizes identifiers and implementation
- requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG
- algorithms and standardizes how to specify and handle the truncation
- of HMAC values in TSIG.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
-
- 2. Algorithms and Identifiers..............................4
-
- 3. Specifying Truncation...................................5
- 3.1 Truncation Specification...............................5
-
- 4. TSIG Truncation Policy and Error Provisions.............6
-
- 5. IANA Considerations.....................................7
- 6. Security Considerations.................................7
- 7. Copyright and Disclaimer................................7
-
- 8. Normative References....................................8
- 9. Informative References..................................8
-
- Author's Address...........................................9
- Additional IPR Provisions..................................9
- Expiration and File Name...................................9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-1. Introduction
-
- [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
- authenticate DNS (Domain Name System [STD 13]) queries and responses.
- This RR contains a domain name syntax data item which names the
- authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG-
- ALG.REG.INT name for authentication codes using the HMAC [RFC 2104]
- algorithm with the MD5 [RFC 1321] hash algorithm. IANA has also
- registered "gss-tsig" as an identifier for TSIG authentication where
- the cryptographic operations are delegated to the Generic Security
- Service (GSS) [RFC 3645].
-
- It should be noted that use of TSIG presumes prior agreement, between
- the resolver and server involved, as to the algorithm and key to be
- used.
-
- In Section 2, this document specifies additional names for TSIG
- authentication algorithms based on US NIST SHA (United States,
- National Institute of Science and Technology, Secure Hash Algorithm)
- algorithms and HMAC and specifies the implementation requirements for
- those algorithms.
-
- In Section 3, this document specifies the effect of inequality
- between the normal output size of the specified hash function and the
- length of MAC (message authentication code) data given in the TSIG
- RR. In particular, it specifies that a shorter length field value
- specifies truncation and a longer length field is an error.
-
- In Section 4, policy restrictions and implications related to
- truncation and a new error code to indicate truncation shorter than
- permitted by policy are described and specified.
-
- The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
- defined in [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-2. Algorithms and Identifiers
-
- TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
- queries and responses. They are intended to be efficient symmetric
- authentication codes based on a shared secret. (Asymmetric signatures
- can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
- can be used for transaction signatures.) Used with a strong hash
- function, HMAC [RFC 2104] provides a way to calculate such symmetric
- authentication codes. The only specified HMAC based TSIG algorithm
- identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
-
- The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
- compared with the 128 bits for MD5, and additional hash algorithms in
- the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
- and 512 bits, may be preferred in some cases particularly since
- increasingly successful cryptanalytic attacks are being made on the
- shorter hashes.
-
- Use of TSIG between a DNS resolver and server is by mutual agreement.
- That agreement can include the support of additional algorithms and
- criteria as to which algorithms and truncations are acceptable,
- subject to the restriction and guidelines in Section 3 and 4 below.
- Key agreement can be by the TKEY mechanism [RFC 2930] or other
- mutually agreeable method.
-
- The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
- included in the table below for convenience. Implementations which
- support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
- implement gss-tsig and the other algorithms listed below.
-
- Mandatory HMAC-MD5.SIG-ALG.REG.INT
- Optional gss-tsig
- Mandatory hmac-sha1
- Optional hmac-sha224
- Mandatory hmac-sha256
- Optional hamc-sha384
- Optional hmac-sha512
-
- SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
- When space is at a premium and the strength of the full length of an
- HMAC is not needed, it is reasonable to truncate the HMAC output and
- use the truncated value for authentication. HMAC SHA-1 truncated to
- 96 bits is an option available in several IETF protocols including
- IPSEC and TLS.
-
- The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
- size of the MAC field in octets. But [RFC 2845] does not specify what
- to do if this MAC size differs from the length of the output of HMAC
- for a particular hash function. Truncation is indicated by a MAC size
- less than the HMAC size as specified below.
-
-
-
-3.1 Truncation Specification
-
- The specification for TSIG handling is changed as follows:
-
- 1. If "MAC size" field is greater than HMAC output length:
- This case MUST NOT be generated and if received MUST cause the
- packet to be dropped and RCODE 1 (FORMERR) to be returned.
-
- 2. If "MAC size" field equals HMAC output length:
- Operation is as described in [RFC 2845] with the entire output
- HMAC output present.
-
- 3. "MAC size" field is less than HMAC output length but greater than
- that specified in case 4 below:
- This is sent when the signer has truncated the HMAC output to
- an allowable length, as described in RFC 2104, taking initial
- octets and discarding trailing octets. TSIG truncation can only be
- to an integral number of octets. On receipt of a packet with
- truncation thus indicated, the locally calculated MAC is similarly
- truncated and only the truncated values compared for
- authentication. The request MAC used when calculating the TSIG MAC
- for a reply is the truncated request MAC.
-
- 4. "MAC size" field is less than the larger of 10 (octets) and half
- the length of the hash function in use:
- With the exception of certain TSIG error messages described in
- RFC 2845 section 3.2 where it is permitted that the MAC size be
- zero, this case MUST NOT be generated and if received MUST cause
- the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
- size limit for this case can also, for the hash functions
- mentioned in this document, be stated as less than half the hash
- function length for hash functions other than MD5 and less than 10
- octets for MD5.
-
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-4. TSIG Truncation Policy and Error Provisions
-
- Use of TSIG is by mutual agreement between a resolver and server.
- Implicit in such "agreement" are criterion as to acceptable keys and
- algorithms and, with the extensions in this document, truncations.
- Note that it is common for implementations to bind the TSIG secret
- key or keys that may be in place at a resolver and server to
- particular algorithms. Thus such implementations only permit the use
- of an algorithm if there is an associated key in place. Receipt of an
- unknown, unimplemented, or disabled algorithm typically results in a
- BADKEY error.
-
- Local policies MAY require the rejection of TSIGs even though they
- use an algorithm for which implementation is mandatory.
-
- When a local policy permits acceptance of a TSIG with a particular
- algorithm and a particular non-zero amount of truncation it SHOULD
- also permit the use of that algorithm with lesser truncation (a
- longer MAC) up to the full HMAC output.
-
- Regardless of a lower acceptable truncated MAC length specified by
- local policy, a reply SHOULD be sent with a MAC at least as long as
- that in the corresponding request unless the request specified a MAC
- length longer than the HMAC output.
-
- Implementations permitting multiple acceptable algorithms and/or
- truncations SHOULD permit this list to be ordered by presumed
- strength and SHOULD allow different truncations for the same
- algorithm to be treated as separate entities in this list. When so
- implemented, policies SHOULD accept a presumed stronger algorithm and
- truncation than the minimum strength required by the policy.
-
- If a TSIG is received with truncation which is permitted under
- Section 3 above but the MAC is too short for the local policy in
- force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-5. IANA Considerations
-
- This document, on approval for publication as a standards track RFC,
- (1) registers the new TSIG algorithm identifiers listed in Section 2
- with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
- Section 4. [RFC 2845]
-
-
-
-6. Security Considerations
-
- For all of the message authentication code algorithms listed herein,
- those producing longer values are believed to be stronger; however,
- while there have been some arguments that mild truncation can
- strengthen a MAC by reducing the information available to an
- attacker, excessive truncation clearly weakens authentication by
- reducing the number of bits an attacker has to try to break the
- authentication by brute force [RFC 2104].
-
- Significant progress has been made recently in cryptanalysis of hash
- function of the type used herein, all of which ultimately derive from
- the design of MD4. While the results so far should not effect HMAC,
- the stronger SHA-1 and SHA-256 algorithms are being made mandatory
- due to caution.
-
- See the Security Considerations section of [RFC 2845]. See also the
- Security Considerations section of [RFC 2104] from which the limits
- on truncation in this RFC were taken.
-
-
-
-7. Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-8. Normative References
-
- [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
- Federal Information Processing Standard, with Change Notice 1,
- February 2004.
-
- [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
- 1321, April 1992.
-
- [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication", RFC 2104, February 1997.
-
- [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
- 1 (SHA1)", RFC 3174, September 2001.
-
- [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
- September 2004,
-
- [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
- (SHA)", draft-eastlake-sha2-*.txt, work in progress.
-
- [STD 13]
- Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
-
-
-9. Informative References.
-
- [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS
- (TKEY RR)", RFC 2930, September 2000.
-
- [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
- Signatures ( SIG(0)s )", RFC 2931, September 2000.
-
- [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
- J., and R. Hall, "Generic Security Service Algorithm for Secret Key
- Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
- 2003.
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554 (w)
-
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Additional IPR Provisions
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed
- to pertain to the implementation or use of the technology
- described in this document or the extent to which any license
- under such rights might or might not be available; nor does it
- represent that it has made any independent effort to identify any
- such rights. Information on the procedures with respect to
- rights in RFC documents can be found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use
- of such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository
- at http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention
- any copyrights, patents or patent applications, or other
- proprietary rights that may cover technology that may be required
- to implement this standard. Please address the information to the
- IETF at ietf-ipr@ietf.org.
-
-
-
-Expiration and File Name
-
- This draft expires in July 2006.
-
- Its file name is draft-ietf-dnsext-tsig-sha-06.txt
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
+++ /dev/null
-
-
-
-DNSOP O. Kolkman
-Internet-Draft R. Gieben
-Obsoletes: 2541 (if approved) NLnet Labs
-Expires: September 7, 2006 March 6, 2006
-
-
- DNSSEC Operational Practices
- draft-ietf-dnsop-dnssec-operational-practices-08.txt
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on September 7, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes a set of practices for operating the DNS with
- security extensions (DNSSEC). The target audience is zone
- administrators deploying DNSSEC.
-
- The document discusses operational aspects of using keys and
- signatures in the DNS. It discusses issues as key generation, key
- storage, signature generation, key rollover and related policies.
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 1]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- This document obsoletes RFC 2541, as it covers more operational
- ground and gives more up to date requirements with respect to key
- sizes and the new DNSSEC specification.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. The Use of the Term 'key' . . . . . . . . . . . . . . . . 4
- 1.2. Time Definitions . . . . . . . . . . . . . . . . . . . . . 5
- 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5
- 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6
- 3.1. Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6
- 3.1.1. Motivations for the KSK and ZSK Separation . . . . . . 7
- 3.1.2. KSKs for High Level Zones . . . . . . . . . . . . . . 8
- 3.2. Key Generation . . . . . . . . . . . . . . . . . . . . . . 8
- 3.3. Key Effectivity Period . . . . . . . . . . . . . . . . . . 9
- 3.4. Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9
- 3.5. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 10
- 3.6. Private Key Storage . . . . . . . . . . . . . . . . . . . 12
- 4. Signature generation, Key Rollover and Related Policies . . . 12
- 4.1. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12
- 4.1.1. Time Considerations . . . . . . . . . . . . . . . . . 13
- 4.2. Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 14
- 4.2.1. Zone Signing Key Rollovers . . . . . . . . . . . . . . 15
- 4.2.2. Key Signing Key Rollovers . . . . . . . . . . . . . . 19
- 4.2.3. Difference Between ZSK and KSK Rollovers . . . . . . . 20
- 4.2.4. Automated Key Rollovers . . . . . . . . . . . . . . . 21
- 4.3. Planning for Emergency Key Rollover . . . . . . . . . . . 22
- 4.3.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 22
- 4.3.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 24
- 4.3.3. Compromises of Keys Anchored in Resolvers . . . . . . 24
- 4.4. Parental Policies . . . . . . . . . . . . . . . . . . . . 24
- 4.4.1. Initial Key Exchanges and Parental Policies
- Considerations . . . . . . . . . . . . . . . . . . . . 24
- 4.4.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 25
- 4.4.3. Security Lameness . . . . . . . . . . . . . . . . . . 25
- 4.4.4. DS Signature Validity Period . . . . . . . . . . . . . 26
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 28
- Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 29
- Appendix B. Zone Signing Key Rollover Howto . . . . . . . . . . . 30
- Appendix C. Typographic Conventions . . . . . . . . . . . . . . . 31
- Appendix D. Document Details and Changes . . . . . . . . . . . . 33
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 2]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- D.1. draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 33
- D.2. draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 33
- D.3. draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 33
- D.4. draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 33
- D.5. draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 34
- D.6. draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 34
- D.7. draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 34
- D.8. draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 34
- D.9. draft-ietf-dnsop-dnssec-operational-practices-08 . . . . . 34
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
- Intellectual Property and Copyright Statements . . . . . . . . . . 36
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 3]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
-1. Introduction
-
- This document describes how to run a DNSSEC (DNS SECure) enabled
- environment. It is intended for operators who have knowledge of the
- DNS (see RFC 1034 [1] and RFC 1035 [2]) and want deploy DNSSEC. See
- RFC 4033 [4] for an introduction into DNSSEC and RFC 4034 [5] for the
- newly introduced Resource Records and finally RFC 4035 [6] for the
- protocol changes.
-
- During workshops and early operational deployment tests, operators
- and system administrators have gained experience about operating the
- DNS with security extensions (DNSSEC). This document translates
- these experiences into a set of practices for zone administrators.
- At the time of writing, there exists very little experience with
- DNSSEC in production environments; this document should therefore
- explicitly not be seen as representing 'Best Current Practices'.
-
- The procedures herein are focused on the maintenance of signed zones
- (i.e. signing and publishing zones on authoritative servers). It is
- intended that maintenance of zones such as re-signing or key
- rollovers be transparent to any verifying clients on the Internet.
-
- The structure of this document is as follows. In Section 2 we
- discuss the importance of keeping the "chain of trust" intact.
- Aspects of key generation and storage of private keys are discussed
- in Section 3; the focus in this section is mainly on the private part
- of the key(s). Section 4 describes considerations concerning the
- public part of the keys. Since these public keys appear in the DNS
- one has to take into account all kinds of timing issues, which are
- discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the
- rollover, or supercession, of keys. Finally Section 4.4 discusses
- considerations on how parents deal with their children's public keys
- in order to maintain chains of trust.
-
- The typographic conventions used in this document are explained in
- Appendix C.
-
- Since this is a document with operational suggestions and there are
- no protocol specifications, the RFC 2119 [9] language does not apply.
-
- This document obsoletes RFC 2541 [12].
-
-1.1. The Use of the Term 'key'
-
- It is assumed that the reader is familiar with the concept of
- asymmetric keys on which DNSSEC is based (Public Key Cryptography
- [18]). Therefore, this document will use the term 'key' rather
- loosely. Where it is written that 'a key is used to sign data' it is
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 4]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- assumed that the reader understands that it is the private part of
- the key pair that is used for signing. It is also assumed that the
- reader understands that the public part of the key pair is published
- in the DNSKEY resource record and that it is the public part that is
- used in key exchanges.
-
-1.2. Time Definitions
-
- In this document we will be using a number of time related terms.
- The following definitions apply:
- o "Signature validity period"
- The period that a signature is valid. It starts at the time
- specified in the signature inception field of the RRSIG RR and
- ends at the time specified in the expiration field of the RRSIG
- RR.
- o "Signature publication period"
- Time after which a signature (made with a specific key) is
- replaced with a new signature (made with the same key). This
- replacement takes place by publishing the relevant RRSIG in the
- master zone file.
- After one stops publishing an RRSIG in a zone it may take a
- while before the RRSIG has expired from caches and has actually
- been removed from the DNS.
- o "Key effectivity period"
- The period during which a key pair is expected to be effective.
- This period is defined as the time between the first inception
- time stamp and the last expiration date of any signature made
- with this key, regardless of any discontinuity in the use of
- the key.
- The key effectivity period can span multiple signature validity
- periods.
- o "Maximum/Minimum Zone Time to Live (TTL)"
- The maximum or minimum value of the TTLs from the complete set
- of RRs in a zone. Note that the minimum TTL is not the same as
- the MINIMUM field in the SOA RR. See [11] for more
- information.
-
-
-2. Keeping the Chain of Trust Intact
-
- Maintaining a valid chain of trust is important because broken chains
- of trust will result in data being marked as Bogus (as defined in [4]
- section 5), which may cause entire (sub)domains to become invisible
- to verifying clients. The administrators of secured zones have to
- realize that their zone is, to verifying clients, part of a chain of
- trust.
-
- As mentioned in the introduction, the procedures herein are intended
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 5]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- to ensure that maintenance of zones, such as re-signing or key
- rollovers, will be transparent to the verifying clients on the
- Internet.
-
- Administrators of secured zones will have to keep in mind that data
- published on an authoritative primary server will not be immediately
- seen by verifying clients; it may take some time for the data to be
- transferred to other secondary authoritative nameservers and clients
- may be fetching data from caching non-authoritative servers. In this
- light it is good to note that the time for a zone transfer from
- master to slave is negligible when using NOTIFY [8] and IXFR [7],
- increasing by reliance on AXFR, and more if you rely on the SOA
- timing parameters for zone refresh.
-
- For the verifying clients it is important that data from secured
- zones can be used to build chains of trust regardless of whether the
- data came directly from an authoritative server, a caching nameserver
- or some middle box. Only by carefully using the available timing
- parameters can a zone administrator assure that the data necessary
- for verification can be obtained.
-
- The responsibility for maintaining the chain of trust is shared by
- administrators of secured zones in the chain of trust. This is most
- obvious in the case of a 'key compromise' when a trade off between
- maintaining a valid chain of trust and replacing the compromised keys
- as soon as possible must be made. Then zone administrators will have
- to make a trade off, between keeping the chain of trust intact -
- thereby allowing for attacks with the compromised key - or to
- deliberately break the chain of trust and making secured sub domains
- invisible to security aware resolvers. Also see Section 4.3.
-
-
-3. Keys Generation and Storage
-
- This section describes a number of considerations with respect to the
- security of keys. It deals with the generation, effectivity period,
- size and storage of private keys.
-
-3.1. Zone and Key Signing Keys
-
- The DNSSEC validation protocol does not distinguish between different
- types of DNSKEYs. All DNSKEYs can be used during the validation. In
- practice operators use Key Signing and Zone Signing Keys and use the
- so-called (Secure Entry Point) SEP [3] flag to distinguish between
- them during operations. The dynamics and considerations are
- discussed below.
-
- To make zone re-signing and key rollover procedures easier to
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 6]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- implement, it is possible to use one or more keys as Key Signing Keys
- (KSK). These keys will only sign the apex DNSKEY RRSet in a zone.
- Other keys can be used to sign all the RRSets in a zone and are
- referred to as Zone Signing Keys (ZSK). In this document we assume
- that KSKs are the subset of keys that are used for key exchanges with
- the parent and potentially for configuration as trusted anchors - the
- SEP keys. In this document we assume a one-to-one mapping between
- KSK and SEP keys and we assume the SEP flag to be set on all KSKs.
-
-3.1.1. Motivations for the KSK and ZSK Separation
-
- Differentiating between the KSK and ZSK functions has several
- advantages:
-
- o No parent/child interaction is required when ZSKs are updated.
- o The KSK can be made stronger (i.e. using more bits in the key
- material). This has little operational impact since it is only
- used to sign a small fraction of the zone data. Also the KSK is
- only used to verify the zone's key set, not for other RRSets in
- the zone.
- o As the KSK is only used to sign a key set, which is most probably
- updated less frequently than other data in the zone, it can be
- stored separately from and in a safer location than the ZSK.
- o A KSK can have a longer key effectivity period.
-
- For almost any method of key management and zone signing the KSK is
- used less frequently than the ZSK. Once a key set is signed with the
- KSK all the keys in the key set can be used as ZSK. If a ZSK is
- compromised, it can be simply dropped from the key set. The new key
- set is then re-signed with the KSK.
-
- Given the assumption that for KSKs the SEP flag is set, the KSK can
- be distinguished from a ZSK by examining the flag field in the DNSKEY
- RR. If the flag field is an odd number it is a KSK. If it is an
- even number it is a ZSK.
-
- The zone signing key can be used to sign all the data in a zone on a
- regular basis. When a zone signing key is to be rolled, no
- interaction with the parent is needed. This allows for "Signature
- Validity Periods" on the order of days.
-
- The key signing key is only to be used to sign the DNSKEY RRs in a
- zone. If a key signing key is to be rolled over, there will be
- interactions with parties other than the zone administrator. These
- can include the registry of the parent zone or administrators of
- verifying resolvers that have the particular key configured as secure
- entry points. Hence, the key effectivity period of these keys can
- and should be made much longer. Although, given a long enough key,
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 7]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- the Key Effectivity Period can be on the order of years we suggest
- planning for a key effectivity of the order of a few months so that a
- key rollover remains an operational routine.
-
-3.1.2. KSKs for High Level Zones
-
- Higher level zones are generally more sensitive than lower level
- zones. Anyone controlling or breaking the security of a zone thereby
- obtains authority over all of its sub domains (except in the case of
- resolvers that have locally configured the public key of a sub
- domain, in which case this, and only this, sub domain wouldn't be
- affected by the compromise of the parent zone). Therefore, extra
- care should be taken with high level zones and strong keys should
- used.
-
- The root zone is the most critical of all zones. Someone controlling
- or compromising the security of the root zone would control the
- entire DNS name space of all resolvers using that root zone (except
- in the case of resolvers that have locally configured the public key
- of a sub domain). Therefore, the utmost care must be taken in the
- securing of the root zone. The strongest and most carefully handled
- keys should be used. The root zone private key should always be kept
- off line.
-
- Many resolvers will start at a root server for their access to and
- authentication of DNS data. Securely updating the trust anchors in
- an enormous population of resolvers around the world will be
- extremely difficult.
-
-3.2. Key Generation
-
- Careful generation of all keys is a sometimes overlooked but
- absolutely essential element in any cryptographically secure system.
- The strongest algorithms used with the longest keys are still of no
- use if an adversary can guess enough to lower the size of the likely
- key space so that it can be exhaustively searched. Technical
- suggestions for the generation of random keys will be found in RFC
- 4086 [15]. One should carefully assess if the random number
- generator used during key generation adheres to these suggestions.
-
- Keys with a long effectivity period are particularly sensitive as
- they will represent a more valuable target and be subject to attack
- for a longer time than short period keys. It is strongly recommended
- that long term key generation occur off-line in a manner isolated
- from the network via an air gap or, at a minimum, high level secure
- hardware.
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 8]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
-3.3. Key Effectivity Period
-
- For various reasons keys in DNSSEC need to be changed once in a
- while. The longer a key is in use, the greater the probability that
- it will have been compromised through carelessness, accident,
- espionage, or cryptanalysis. Furthermore when key rollovers are too
- rare an event, they will not become part of the operational habit and
- there is risk that nobody on-site will remember the procedure for
- rollover when the need is there.
-
- From a purely operational perspective a reasonable key effectivity
- period for Key Signing Keys is 13 months, with the intent to replace
- them after 12 months. An intended key effectivity period of a month
- is reasonable for Zone Signing Keys.
-
- For key sizes that matches these effectivity periods see Section 3.5.
-
- As argued in Section 3.1.2 securely updating trust anchors will be
- extremely difficult. On the other hand the "operational habit"
- argument does also apply to trust anchor reconfiguration. If a short
- key-effectivity period is used and the trust anchor configuration has
- to be revisited on a regular basis the odds that the configuration
- tends to be forgotten is smaller. The trade-off is against a system
- that is so dynamic that administrators of the validating clients will
- not be able to follow the modifications.
-
- Key effectivity periods can be made very short, as in the order of a
- few minutes. But when replacing keys one has to take the
- considerations from Section 4.1 and Section 4.2 into account.
-
-3.4. Key Algorithm
-
- There are currently three different types of algorithms that can be
- used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter
- is fairly new and has yet to be standardized for usage in DNSSEC.
-
- RSA has been developed in an open and transparent manner. As the
- patent on RSA expired in 2000, its use is now also free.
-
- DSA has been developed by NIST. The creation of signatures takes
- roughly the same time as with RSA, but is 10 to 40 times as slow for
- verification [18].
-
- We suggest the use of RSA/SHA-1 as the preferred algorithm for the
- key. The current known attacks on RSA can be defeated by making your
- key longer. As the MD5 hashing algorithm is showing (theoretical)
- cracks, we recommend the usage of SHA-1.
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 9]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- At the time of publication it is known that the SHA-1 hash has
- cryptanalysis issues. There is work in progress on addressing these
- issues. We recommend the use of public key algorithms based on
- hashes stronger than SHA-1, e.g. SHA-256, as soon as these
- algorithms are available in protocol specifications (See [20] and
- [21] ) and implementations.
-
-3.5. Key Sizes
-
- When choosing key sizes, zone administrators will need to take into
- account how long a key will be used, how much data will be signed
- during the key publication period (See Section 8.10 of [18]) and,
- optionally, how large the key size of the parent is. As the chain of
- trust really is "a chain", there is not much sense in making one of
- the keys in the chain several times larger then the others. As
- always, it's the weakest link that defines the strength of the entire
- chain. Also see Section 3.1.1 for a discussion of how keys serving
- different roles (ZSK v. KSK) may need different key sizes.
-
- Generating a key of the correct size is a difficult problem, RFC 3766
- [14] tries to deal with that problem. The first part of the
- selection procedure in Section 1 of the RFC states:
-
- 1. Determine the attack resistance necessary to satisfy the
- security requirements of the application. Do this by
- estimating the minimum number of computer operations that
- the attacker will be forced to do in order to compromise
- the security of the system and then take the logarithm base
- two of that number. Call that logarithm value "n".
-
- A 1996 report recommended 90 bits as a good all-around choice
- for system security. The 90 bit number should be increased
- by about 2/3 bit/year, or about 96 bits in 2005.
-
- [14] goes on to explain how this number "n" can be used to calculate
- the key sizes in public key cryptography. This culminated in the
- table given below (slightly modified for our purpose):
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 10]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- +-------------+-----------+--------------+
- | System | | |
- | requirement | Symmetric | RSA or DSA |
- | for attack | key size | modulus size |
- | resistance | (bits) | (bits) |
- | (bits) | | |
- +-------------+-----------+--------------+
- | 70 | 70 | 947 |
- | 80 | 80 | 1228 |
- | 90 | 90 | 1553 |
- | 100 | 100 | 1926 |
- | 150 | 150 | 4575 |
- | 200 | 200 | 8719 |
- | 250 | 250 | 14596 |
- +-------------+-----------+--------------+
-
- The key sizes given are rather large. This is because these keys are
- resilient against a trillionaire attacker. Assuming this rich
- attacker will not attack your key and that the key is rolled over
- once a year, we come to the following recommendations about KSK
- sizes; 1024 bits low value domains, 1300 for medium value and 2048
- for the high value domains.
-
- Whether a domain is of low, medium, high value depends solely on the
- views of the zone owner. One could for instance view leaf nodes in
- the DNS as of low value and TLDs or the root zone of high value. The
- suggested key sizes should be safe for the next 5 years.
-
- As ZSKs can be rolled over more easily (and thus more often) the key
- sizes can be made smaller. But as said in the introduction of this
- paragraph, making the ZSKs' key sizes too small (in relation to the
- KSKs' sizes) doesn't make much sense. Try to limit the difference in
- size to about 100 bits.
-
- Note that nobody can see into the future, and that these key sizes
- are only provided here as a guide. Further information can be found
- in [17] and Section 7.5 of [18]. It should be noted though that [17]
- is already considered overly optimistic about what key sizes are
- considered safe.
-
- One final note concerning key sizes. Larger keys will increase the
- sizes of the RRSIG and DNSKEY records and will therefore increase the
- chance of DNS UDP packet overflow. Also the time it takes to
- validate and create RRSIGs increases with larger keys, so don't
- needlessly double your key sizes.
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 11]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
-3.6. Private Key Storage
-
- It is recommended that, where possible, zone private keys and the
- zone file master copy that is to be signed, be kept and used in off-
- line, non-network connected, physically secure machines only.
- Periodically an application can be run to add authentication to a
- zone by adding RRSIG and NSEC RRs. Then the augmented file can be
- transferred.
-
- When relying on dynamic update to manage a signed zone [10], be aware
- that at least one private key of the zone will have to reside on the
- master server. This key is only as secure as the amount of exposure
- the server receives to unknown clients and the security of the host.
- Although not mandatory one could administer the DNS in the following
- way. The master that processes the dynamic updates is unavailable
- from generic hosts on the Internet, it is not listed in the NS RR
- set, although its name appears in the SOA RRs MNAME field. The
- nameservers in the NS RR set are able to receive zone updates through
- NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism. This
- approach is known as the "hidden master" setup.
-
- The ideal situation is to have a one way information flow to the
- network to avoid the possibility of tampering from the network.
- Keeping the zone master file on-line on the network and simply
- cycling it through an off-line signer does not do this. The on-line
- version could still be tampered with if the host it resides on is
- compromised. For maximum security, the master copy of the zone file
- should be off net and should not be updated based on an unsecured
- network mediated communication.
-
- In general keeping a zone-file off-line will not be practical and the
- machines on which zone files are maintained will be connected to a
- network. Operators are advised to take security measures to shield
- unauthorized access to the master copy.
-
- For dynamically updated secured zones [10] both the master copy and
- the private key that is used to update signatures on updated RRs will
- need to be on-line.
-
-
-4. Signature generation, Key Rollover and Related Policies
-
-4.1. Time in DNSSEC
-
- Without DNSSEC all times in DNS are relative. The SOA fields
- REFRESH, RETRY and EXPIRATION are timers used to determine the time
- elapsed after a slave server synchronized with a master server. The
- Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 12]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- are used to determine how long a forwarder should cache data after it
- has been fetched from an authoritative server. By using a signature
- validity period, DNSSEC introduces the notion of an absolute time in
- the DNS. Signatures in DNSSEC have an expiration date after which
- the signature is marked as invalid and the signed data is to be
- considered Bogus.
-
-4.1.1. Time Considerations
-
- Because of the expiration of signatures, one should consider the
- following:
- o We suggest the Maximum Zone TTL of your zone data to be a fraction
- of your signature validity period.
- If the TTL would be of similar order as the signature validity
- period, then all RRSets fetched during the validity period
- would be cached until the signature expiration time. Section
- 7.1 of [4] suggests that "the resolver may use the time
- remaining before expiration of the signature validity period of
- a signed RRSet as an upper bound for the TTL". As a result
- query load on authoritative servers would peak at signature
- expiration time, as this is also the time at which records
- simultaneously expire from caches.
- To avoid query load peaks we suggest the TTL on all the RRs in
- your zone to be at least a few times smaller than your
- signature validity period.
- o We suggest the Signature Publication Period to end at least one
- Maximum Zone TTL duration before the end of the Signature Validity
- Period.
- Re-signing a zone shortly before the end of the signature
- validity period may cause simultaneous expiration of data from
- caches. This in turn may lead to peaks in the load on
- authoritative servers.
- o We suggest the minimum zone TTL to be long enough to both fetch
- and verify all the RRs in the trust chain. In workshop
- environments it has been demonstrated [19] that a low TTL (under 5
- to 10 minutes) caused disruptions because of the following two
- problems:
- 1. During validation, some data may expire before the
- validation is complete. The validator should be able to keep
- all data, until is completed. This applies to all RRs needed
- to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the
- final answers i.e. the RRSet that is returned for the initial
- query.
- 2. Frequent verification causes load on recursive nameservers.
- Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from
- caching. The TTL on those should be relatively long.
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 13]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- o Slave servers will need to be able to fetch newly signed zones
- well before the RRSIGs in the zone served by the slave server pass
- their signature expiration time.
- When a slave server is out of sync with its master and data in
- a zone is signed by expired signatures it may be better for the
- slave server not to give out any answer.
- Normally a slave server that is not able to contact a master
- server for an extended period will expire a zone. When that
- happens the server will respond differently to queries for that
- zone. Some servers issue SERVFAIL while others turn off the
- 'AA' bit in the answers. The time of expiration is set in the
- SOA record and is relative to the last successful refresh
- between the master and the slave server. There exists no
- coupling between the signature expiration of RRSIGs in the zone
- and the expire parameter in the SOA.
- If the server serves a DNSSEC zone then it may well happen that
- the signatures expire well before the SOA expiration timer
- counts down to zero. It is not possible to completely prevent
- this from happening by tweaking the SOA parameters.
- However, the effects can be minimized where the SOA expiration
- time is equal or shorter than the signature validity period.
- The consequence of an authoritative server not being able to
- update a zone, whilst that zone includes expired signatures, is
- that non-secure resolvers will continue to be able to resolve
- data served by the particular slave servers while security
- aware resolvers will experience problems because of answers
- being marked as Bogus.
- We suggest the SOA expiration timer being approximately one
- third or one fourth of the signature validity period. It will
- allow problems with transfers from the master server to be
- noticed before the actual signature times out.
- We also suggest that operators of nameservers that supply
- secondary services develop 'watch dogs' to spot upcoming
- signature expirations in zones they slave, and take appropriate
- action.
- When determining the value for the expiration parameter one has
- to take the following into account: What are the chances that
- all my secondaries expire the zone; How quickly can I reach an
- administrator of secondary servers to load a valid zone? All
- these arguments are not DNSSEC specific but may influence the
- choice of your signature validity intervals.
-
-4.2. Key Rollovers
-
- A DNSSEC key cannot be used forever (see Section 3.3). So key
- rollovers -- or supercessions, as they are sometimes called -- are a
- fact of life when using DNSSEC. Zone administrators who are in the
- process of rolling their keys have to take into account that data
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 14]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- published in previous versions of their zone still lives in caches.
- When deploying DNSSEC, this becomes an important consideration;
- ignoring data that may be in caches may lead to loss of service for
- clients.
-
- The most pressing example of this occurs when zone material signed
- with an old key is being validated by a resolver which does not have
- the old zone key cached. If the old key is no longer present in the
- current zone, this validation fails, marking the data Bogus.
- Alternatively, an attempt could be made to validate data which is
- signed with a new key against an old key that lives in a local cache,
- also resulting in data being marked Bogus.
-
-4.2.1. Zone Signing Key Rollovers
-
- For zone signing key rollovers there are two ways to make sure that
- during the rollover data still cached can be verified with the new
- key sets or newly generated signatures can be verified with the keys
- still in caches. One schema, described in Section 4.2.1.2, uses
- double signatures; the other uses key pre-publication
- (Section 4.2.1.1). The pros, cons and recommendations are described
- in Section 4.2.1.3.
-
-4.2.1.1. Pre-publish Key Rollover
-
- This section shows how to perform a ZSK rollover without the need to
- sign all the data in a zone twice - the so-called "pre-publish
- rollover".This method has advantages in the case of a key compromise.
- If the old key is compromised, the new key has already been
- distributed in the DNS. The zone administrator is then able to
- quickly switch to the new key and remove the compromised key from the
- zone. Another major advantage is that the zone size does not double,
- as is the case with the double signature ZSK rollover. A small
- "HOWTO" for this kind of rollover can be found in Appendix B.
-
- Pre-publish Key Rollover involves four stages as follows:
-
- initial new DNSKEY new RRSIGs DNSKEY removal
-
- SOA0 SOA1 SOA2 SOA3
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
-
- DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11 DNSKEY11
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 15]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- initial: Initial version of the zone: DNSKEY 1 is the key signing
- key. DNSKEY 10 is used to sign all the data of the zone, the zone
- signing key.
- new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no
- signatures are generated with this key yet, but this does not
- secure against brute force attacks on the public key. The minimum
- duration of this pre-roll phase is the time it takes for the data
- to propagate to the authoritative servers plus TTL value of the
- key set.
- new RRSIGs: At the "new RRSIGs" stage (SOA serial 2) DNSKEY 11 is
- used to sign the data in the zone exclusively (i.e. all the
- signatures from DNSKEY 10 are removed from the zone). DNSKEY 10
- remains published in the key set. This way data that was loaded
- into caches from version 1 of the zone can still be verified with
- key sets fetched from version 2 of the zone.
- The minimum time that the key set including DNSKEY 10 is to be
- published is the time that it takes for zone data from the
- previous version of the zone to expire from old caches i.e. the
- time it takes for this zone to propagate to all authoritative
- servers plus the Maximum Zone TTL value of any of the data in the
- previous version of the zone.
- DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now
- only containing DNSKEY 1 and DNSKEY 11 is re-signed with the
- DNSKEY 1.
-
- The above scheme can be simplified by always publishing the "future"
- key immediately after the rollover. The scheme would look as follows
- (we show two rollovers); the future key is introduced in "new DNSKEY"
- as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
- (II)":
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 16]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- initial new RRSIGs new DNSKEY
-
- SOA0 SOA1 SOA2
- RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2)
-
- DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11 DNSKEY11 DNSKEY12
- RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-
-
- new RRSIGs (II) new DNSKEY (II)
-
- SOA3 SOA4
- RRSIG12(SOA3) RRSIG12(SOA4)
-
- DNSKEY1 DNSKEY1
- DNSKEY11 DNSKEY12
- DNSKEY12 DNSKEY13
- RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG12(DNSKEY) RRSIG12(DNSKEY)
-
-
- Pre-Publish Key Rollover, showing two rollovers.
-
- Note that the key introduced in the "new DNSKEY" phase is not used
- for production yet; the private key can thus be stored in a
- physically secure manner and does not need to be 'fetched' every time
- a zone needs to be signed.
-
-4.2.1.2. Double Signature Zone Signing Key Rollover
-
- This section shows how to perform a ZSK key rollover using the double
- zone data signature scheme, aptly named "double sig rollover".
-
- During the "new DNSKEY" stage the new version of the zone file will
- need to propagate to all authoritative servers and the data that
- exists in (distant) caches will need to expire, requiring at least
- the maximum Zone TTL.
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 17]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- Double Signature Zone Signing Key Rollover involves three stages as
- follows:
-
- initial new DNSKEY DNSKEY removal
-
- SOA0 SOA1 SOA2
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
- RRSIG11(SOA1)
-
- DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11
- RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
- RRSIG11(DNSKEY)
-
- initial: Initial Version of the zone: DNSKEY 1 is the key signing
- key. DNSKEY 10 is used to sign all the data of the zone, the zone
- signing key.
- new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
- introduced into the key set and all the data in the zone is signed
- with DNSKEY 10 and DNSKEY 11. The rollover period will need to
- continue until all data from version 0 of the zone has expired
- from remote caches. This will take at least the maximum Zone TTL
- of version 0 of the zone.
- DNSKEY removal: DNSKEY 10 is removed from the zone. All the
- signatures from DNSKEY 10 are removed from the zone. The key set,
- now only containing DNSKEY 11, is re-signed with DNSKEY 1.
-
- At every instance, RRSIGs from the previous version of the zone can
- be verified with the DNSKEY RRSet from the current version and the
- other way around. The data from the current version can be verified
- with the data from the previous version of the zone. The duration of
- the "new DNSKEY" phase and the period between rollovers should be at
- least the Maximum Zone TTL.
-
- Making sure that the "new DNSKEY" phase lasts until the signature
- expiration time of the data in initial version of the zone is
- recommended. This way all caches are cleared of the old signatures.
- However, this duration could be considerably longer than the Maximum
- Zone TTL, making the rollover a lengthy procedure.
-
- Note that in this example we assumed that the zone was not modified
- during the rollover. New data can be introduced in the zone as long
- as it is signed with both keys.
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 18]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
-4.2.1.3. Pros and Cons of the Schemes
-
- Pre-publish Key Rollover: This rollover does not involve signing the
- zone data twice. Instead, before the actual rollover, the new key
- is published in the key set and thus available for cryptanalysis
- attacks. A small disadvantage is that this process requires four
- steps. Also the pre-publish scheme involves more parental work
- when used for KSK rollovers as explained in Section 4.2.3.
- Double Signature Zone-signing Key Rollover: The drawback of this
- signing scheme is that during the rollover the number of
- signatures in your zone doubles, this may be prohibitive if you
- have very big zones. An advantage is that it only requires three
- steps.
-
-4.2.2. Key Signing Key Rollovers
-
- For the rollover of a key signing key the same considerations as for
- the rollover of a zone signing key apply. However we can use a
- double signature scheme to guarantee that old data (only the apex key
- set) in caches can be verified with a new key set and vice versa.
- Since only the key set is signed with a KSK, zone size considerations
- do not apply.
-
-
- initial new DNSKEY DS change DNSKEY removal
- Parent:
- SOA0 --------> SOA1 -------->
- RRSIGpar(SOA0) --------> RRSIGpar(SOA1) -------->
- DS1 --------> DS2 -------->
- RRSIGpar(DS) --------> RRSIGpar(DS) -------->
-
-
- Child:
- SOA0 SOA1 --------> SOA2
- RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2)
- -------->
- DNSKEY1 DNSKEY1 --------> DNSKEY2
- DNSKEY2 -------->
- DNSKEY10 DNSKEY10 --------> DNSKEY10
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY)
- RRSIG2 (DNSKEY) -------->
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY)
-
- Stages of Deployment for Key Signing Key Rollover.
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 19]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- initial: Initial version of the zone. The parental DS points to
- DNSKEY1. Before the rollover starts the child will have to verify
- what the TTL is of the DS RR that points to DNSKEY1 - it is needed
- during the rollover and we refer to the value as TTL_DS.
- new DNSKEY: During the "new DNSKEY" phase the zone administrator
- generates a second KSK, DNSKEY2. The key is provided to the
- parent and the child will have to wait until a new DS RR has been
- generated that points to DNSKEY2. After that DS RR has been
- published on all servers authoritative for the parent's zone, the
- zone administrator has to wait at least TTL_DS to make sure that
- the old DS RR has expired from caches.
- DS change: The parent replaces DS1 with DS2.
- DNSKEY removal: DNSKEY1 has been removed.
-
- The scenario above puts the responsibility for maintaining a valid
- chain of trust with the child. It also is based on the premises that
- the parent only has one DS RR (per algorithm) per zone. An
- alternative mechanism has been considered. Using an established
- trust relation, the interaction can be performed in-band, and the
- removal of the keys by the child can possibly be signaled by the
- parent. In this mechanism there are periods where there are two DS
- RRs at the parent. Since at the moment of writing the protocol for
- this interaction has not been developed, further discussion is out of
- scope for this document.
-
-4.2.3. Difference Between ZSK and KSK Rollovers
-
- Note that KSK rollovers and ZSK rollovers are different in the sense
- that a KSK rollover requires interaction with the parent (and
- possibly replacing of trust anchors) and the ensuing delay while
- waiting for it.
-
- A zone key rollover can be handled in two different ways: pre-publish
- (Section Section 4.2.1.1) and double signature (Section
- Section 4.2.1.2).
-
- As the KSK is used to validate the key set and because the KSK is not
- changed during a ZSK rollover, a cache is able to validate the new
- key set of the zone. The pre-publish method would also work for a
- KSK rollover. The records that are to be pre-published are the
- parental DS RRs. The pre-publish method has some drawbacks for KSKs.
- We first describe the rollover scheme and then indicate these
- drawbacks.
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 20]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- initial new DS new DNSKEY DS/DNSKEY removal
- Parent:
- SOA0 SOA1 --------> SOA2
- RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2)
- DS1 DS1 --------> DS2
- DS2 -------->
- RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS)
-
-
-
- Child:
- SOA0 --------> SOA1 SOA1
- RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1)
- -------->
- DNSKEY1 --------> DNSKEY2 DNSKEY2
- -------->
- DNSKEY10 --------> DNSKEY10 DNSKEY10
- RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY)
- RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-
- Stages of Deployment for a Pre-publish Key Signing Key rollover.
-
- When the child zone wants to roll it notifies the parent during the
- "new DS" phase and submits the new key (or the corresponding DS) to
- the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1
- and DNSKEY2 respectively. During the rollover ("new DNSKEY" phase),
- which can take place as soon as the new DS set propagated through the
- DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that
- ("DS/DNSKEY removal" phase) it can notify the parent that the old DS
- record can be deleted.
-
- The drawbacks of this scheme are that during the "new DS" phase the
- parent cannot verify the match between the DS2 RR and DNSKEY2 using
- the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a
- "security lame" key (See Section 4.4.3). Finally the child-parent
- interaction consists of two steps. The "double signature" method
- only needs one interaction.
-
-4.2.4. Automated Key Rollovers
-
- As keys must be renewed periodically, there is some motivation to
- automate the rollover process. Consider that:
-
- o ZSK rollovers are easy to automate as only the child zone is
- involved.
- o A KSK rollover needs interaction between parent and child. Data
- exchange is needed to provide the new keys to the parent,
- consequently, this data must be authenticated and integrity must
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 21]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- be guaranteed in order to avoid attacks on the rollover.
-
-4.3. Planning for Emergency Key Rollover
-
- This section deals with preparation for a possible key compromise.
- Our advice is to have a documented procedure ready for when a key
- compromise is suspected or confirmed.
-
- When the private material of one of your keys is compromised it can
- be used for as long as a valid trust chain exists. A trust chain
- remains intact for:
- o as long as a signature over the compromised key in the trust chain
- is valid,
- o as long as a parental DS RR (and signature) points to the
- compromised key,
- o as long as the key is anchored in a resolver and is used as a
- starting point for validation (this is generally the hardest to
- update).
-
- While a trust chain to your compromised key exists, your name-space
- is vulnerable to abuse by anyone who has obtained illegitimate
- possession of the key. Zone operators have to make a trade off if
- the abuse of the compromised key is worse than having data in caches
- that cannot be validated. If the zone operator chooses to break the
- trust chain to the compromised key, data in caches signed with this
- key cannot be validated. However, if the zone administrator chooses
- to take the path of a regular roll-over, the malicious key holder can
- spoof data so that it appears to be valid.
-
-4.3.1. KSK Compromise
-
- A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
- as long as the compromised KSK is configured as trust anchor or a
- parental DS points to it.
-
- A compromised KSK can be used to sign the key set of an attacker's
- zone. That zone could be used to poison the DNS.
-
- Therefore when the KSK has been compromised, the trust anchor or the
- parental DS, should be replaced as soon as possible. It is local
- policy whether to break the trust chain during the emergency
- rollover. The trust chain would be broken when the compromised KSK
- is removed from the child's zone while the parent still has a DS
- pointing to the compromised KSK (the assumption is that there is only
- one DS at the parent. If there are multiple DSs this does not apply
- -- however the chain of trust of this particular key is broken).
-
- Note that an attacker's zone still uses the compromised KSK and the
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 22]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- presence of a parental DS would cause the data in this zone to appear
- as valid. Removing the compromised key would cause the attacker's
- zone to appear as valid and the child's zone as Bogus. Therefore we
- advise not to remove the KSK before the parent has a DS to a new KSK
- in place.
-
-4.3.1.1. Keeping the Chain of Trust Intact
-
- If we follow this advice the timing of the replacement of the KSK is
- somewhat critical. The goal is to remove the compromised KSK as soon
- as the new DS RR is available at the parent. And also make sure that
- the signature made with a new KSK over the key set with the
- compromised KSK in it expires just after the new DS appears at the
- parent. Thus removing the old cruft in one swoop.
-
- The procedure is as follows:
- 1. Introduce a new KSK into the key set, keep the compromised KSK in
- the key set.
- 2. Sign the key set, with a short validity period. The validity
- period should expire shortly after the DS is expected to appear
- in the parent and the old DSs have expired from caches.
- 3. Upload the DS for this new key to the parent.
- 4. Follow the procedure of the regular KSK rollover: Wait for the DS
- to appear in the authoritative servers and then wait as long as
- the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet
- and modify/extend the expiration time.
- 5. Remove the compromised DNSKEY RR from the zone and re-sign the
- key set using your "normal" validity interval.
-
- An additional danger of a key compromise is that the compromised key
- could be used to facilitate a legitimate DNSKEY/DS rollover and/or
- nameserver changes at the parent. When that happens the domain may
- be in dispute. An authenticated out-of-band and secure notify
- mechanism to contact a parent is needed in this case.
-
- Note that this is only a problem when the DNSKEY and or DS records
- are used for authentication at the parent.
-
-4.3.1.2. Breaking the Chain of Trust
-
- There are two methods to break the chain of trust. The first method
- causes the child zone to appear as 'Bogus' to validating resolvers.
- The other causes the the child zone to appear as 'insecure'. These
- are described below.
-
- In the method that causes the child zone to appear as 'Bogus' to
- validating resolvers, the child zone replaces the current KSK with a
- new one and resigns the key set. Next it sends the DS of the new key
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 23]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- to the parent. Only after the parent has placed the new DS in the
- zone, the child's chain of trust is repaired.
-
- An alternative method of breaking the chain of trust is by removing
- the DS RRs from the parent zone altogether. As a result the child
- zone would become insecure.
-
-4.3.2. ZSK Compromise
-
- Primarily because there is no parental interaction required when a
- ZSK is compromised, the situation is less severe than with a KSK
- compromise. The zone must still be re-signed with a new ZSK as soon
- as possible. As this is a local operation and requires no
- communication between the parent and child this can be achieved
- fairly quickly. However, one has to take into account that just as
- with a normal rollover the immediate disappearance of the old
- compromised key may lead to verification problems. Also note that as
- long as the RRSIG over the compromised ZSK is not expired the zone
- may be still at risk.
-
-4.3.3. Compromises of Keys Anchored in Resolvers
-
- A key can also be pre-configured in resolvers. For instance, if
- DNSSEC is successfully deployed the root key may be pre-configured in
- most security aware resolvers.
-
- If trust-anchor keys are compromised, the resolvers using these keys
- should be notified of this fact. Zone administrators may consider
- setting up a mailing list to communicate the fact that a SEP key is
- about to be rolled over. This communication will of course need to
- be authenticated e.g. by using digital signatures.
-
- End-users faced with the task of updating an anchored key should
- always validate the new key. New keys should be authenticated out-
- of-band, for example, looking them up on an SSL secured announcement
- website.
-
-4.4. Parental Policies
-
-4.4.1. Initial Key Exchanges and Parental Policies Considerations
-
- The initial key exchange is always subject to the policies set by the
- parent. When designing a key exchange policy one should take into
- account that the authentication and authorization mechanisms used
- during a key exchange should be as strong as the authentication and
- authorization mechanisms used for the exchange of delegation
- information between parent and child. I.e. there is no implicit need
- in DNSSEC to make the authentication process stronger than it was in
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 24]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- DNS.
-
- Using the DNS itself as the source for the actual DNSKEY material,
- with an out-of-band check on the validity of the DNSKEY, has the
- benefit that it reduces the chances of user error. A DNSKEY query
- tool can make use of the SEP bit [3] to select the proper key from a
- DNSSEC key set; thereby reducing the chance that the wrong DNSKEY is
- sent. It can validate the self-signature over a key; thereby
- verifying the ownership of the private key material. Fetching the
- DNSKEY from the DNS ensures that the chain of trust remains intact
- once the parent publishes the DS RR indicating the child is secure.
-
- Note: the out-of-band verification is still needed when the key-
- material is fetched via the DNS. The parent can never be sure
- whether the DNSKEY RRs have been spoofed or not.
-
-4.4.2. Storing Keys or Hashes?
-
- When designing a registry system one should consider which of the
- DNSKEYs and/or the corresponding DSs to store. Since a child zone
- might wish to have a DS published using a message digest algorithm
- not yet understood by the registry, the registry can't count on being
- able to generate the DS record from a raw DNSKEY. Thus, we recommend
- that registry systems at least support storing DS records.
-
- It may also be useful to store DNSKEYs, since having them may help
- during troubleshooting and, as long as the child's chosen message
- digest is supported, the overhead of generating DS records from them
- is minimal. Having an out-of-band mechanism, such as a registry
- directory (e.g. Whois), to find out which keys are used to generate
- DS Resource Records for specific owners and/or zones may also help
- with troubleshooting.
-
- The storage considerations also relate to the design of the customer
- interface and the method by which data is transferred between
- registrant and registry; Will the child zone administrator be able to
- upload DS RRs with unknown hash algorithms or does the interface only
- allow DNSKEYs? In the registry-registrar model one can use the
- DNSSEC EPP protocol extension [16] which allows transfer of DS RRs
- and optionally DNSKEY RRs.
-
-4.4.3. Security Lameness
-
- Security Lameness is defined as what happens when a parent has a DS
- RR pointing to a non-existing DNSKEY RR. When this happens the
- child's zone may be marked as "Bogus" by verifying DNS clients.
-
- As part of a comprehensive delegation check the parent could, at key
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 25]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- exchange time, verify that the child's key is actually configured in
- the DNS. However if a parent does not understand the hashing
- algorithm used by child the parental checks are limited to only
- comparing the key id.
-
- Child zones should be very careful removing DNSKEY material,
- specifically SEP keys, for which a DS RR exists.
-
- Once a zone is "security lame", a fix (e.g. removing a DS RR) will
- take time to propagate through the DNS.
-
-4.4.4. DS Signature Validity Period
-
- Since the DS can be replayed as long as it has a valid signature, a
- short signature validity period over the DS minimizes the time a
- child is vulnerable in the case of a compromise of the child's
- KSK(s). A signature validity period that is too short introduces the
- possibility that a zone is marked Bogus in case of a configuration
- error in the signer. There may not be enough time to fix the
- problems before signatures expire. Something as mundane as operator
- unavailability during weekends shows the need for DS signature
- validity periods longer than 2 days. We recommend an absolute
- minimum for a DS signature validity period of a few days.
-
- The maximum signature validity period of the DS record depends on how
- long child zones are willing to be vulnerable after a key compromise.
- On the other hand shortening the DS signature validity interval
- increases the operational risk for the parent. Therefore the parent
- may have policy to use a signature validity interval that is
- considerably longer than the child would hope for.
-
- A compromise between the operational constraints of the parent and
- minimizing damage for the child may result in a DS signature validity
- period somewhere between the order of a week to order of months.
-
- In addition to the signature validity period, which sets a lower
- bound on the number of times the zone owner will need to sign the
- zone data and which sets an upper bound to the time a child is
- vulnerable after key compromise, there is the TTL value on the DS
- RRs. Shortening the TTL means that the authoritative servers will
- see more queries. But on the other hand, a short TTL lowers the
- persistence of DS RRSets in caches thereby increases the speed with
- which updated DS RRSets propagate through the DNS.
-
-
-5. IANA Considerations
-
- This overview document introduces no new IANA considerations.
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 26]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
-6. Security Considerations
-
- DNSSEC adds data integrity to the DNS. This document tries to assess
- the operational considerations to maintain a stable and secure DNSSEC
- service. Not taking into account the 'data propagation' properties
- in the DNS will cause validation failures and may make secured zones
- unavailable to security aware resolvers.
-
-
-7. Acknowledgments
-
- Most of the ideas in this draft were the result of collective efforts
- during workshops, discussions and try outs.
-
- At the risk of forgetting individuals who were the original
- contributors of the ideas we would like to acknowledge people who
- were actively involved in the compilation of this document. In
- random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
- Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
- Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
- Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch.
-
- Some material in this document has been copied from RFC 2541 [12].
-
- Mike StJohns designed the key exchange between parent and child
- mentioned in the last paragraph of Section 4.2.2
-
- Section 4.2.4 was supplied by G. Guette and O. Courtay.
-
- Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of
- the spelling and style issues.
-
- Kolkman and Gieben take the blame for introducing all miscakes(SIC).
-
- Kolkman was employed by the RIPE NCC while working on this document.
-
-
-8. References
-
-8.1. Normative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 27]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
- RFC 3757, May 2004.
-
- [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
-8.2. Informative References
-
- [7] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
- August 1996.
-
- [8] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
- (DNS NOTIFY)", RFC 1996, August 1996.
-
- [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [10] Eastlake, D., "Secure Domain Name System Dynamic Update",
- RFC 2137, April 1997.
-
- [11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
- [12] Eastlake, D., "DNS Security Operational Considerations",
- RFC 2541, March 1999.
-
- [13] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
- RFC 3658, December 2003.
-
- [14] Orman, H. and P. Hoffman, "Determining Strengths For Public
- Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
- April 2004.
-
- [15] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
- Requirements for Security", BCP 106, RFC 4086, June 2005.
-
- [16] Hollenbeck, S., "Domain Name System (DNS) Security Extensions
- Mapping for the Extensible Provisioning Protocol (EPP)",
- RFC 4310, December 2005.
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 28]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- [17] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
- Sizes", The Journal of Cryptology 14 (255-293), 2001.
-
- [18] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
- Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
- (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
- 1996.
-
- [19] Rose, S., "NIST DNSSEC workshop notes", June 2001.
-
- [20] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
- Records in DNSSEC", draft-ietf-dnsext-dnssec-rsasha256-00.txt
- (work in progress), January 2006.
-
- [21] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
- Resource Records (RRs)", draft-ietf-dnsext-ds-sha256-04.txt
- (work in progress), January 2006.
-
-
-Appendix A. Terminology
-
- In this document there is some jargon used that is defined in other
- documents. In most cases we have not copied the text from the
- documents defining the terms but given a more elaborate explanation
- of the meaning. Note that these explanations should not be seen as
- authoritative.
-
- Anchored Key: A DNSKEY configured in resolvers around the globe.
- This key is hard to update, hence the term anchored.
- Bogus: Also see Section 5 of [4]. An RRSet in DNSSEC is marked
- "Bogus" when a signature of a RRSet does not validate against a
- DNSKEY.
- Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
- exclusively for signing the apex key set. The fact that a key is
- a KSK is only relevant to the signing tool.
- Key size: The term 'key size' can be substituted by 'modulus size'
- throughout the document. It is mathematically more correct to use
- modulus size, but as this is a document directed at operators we
- feel more at ease with the term key size.
- Private and Public Keys: DNSSEC secures the DNS through the use of
- public key cryptography. Public key cryptography is based on the
- existence of two (mathematically related) keys, a public key and a
- private key. The public keys are published in the DNS by use of
- the DNSKEY Resource Record (DNSKEY RR). Private keys should
- remain private.
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 29]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- Key Rollover: A key rollover (also called key supercession in some
- environments) is the act of replacing one key pair by another at
- the end of a key effectivity period.
- Secure Entry Point key or SEP Key: A KSK that has a parental DS
- record pointing to it or is configured as a trust anchor.
- Although not required by the protocol we recommend that the SEP
- flag [3] is set on these keys.
- Self-signature: This is only applies to signatures over DNSKEYs; a
- signature made with DNSKEY x, over DNSKEY x is called a self-
- signature. Note: without further information self-signatures
- convey no trust, they are useful to check the authenticity of the
- DNSKEY, i.e. they can be used as a hash.
- Singing the Zone File: The term used for the event where an
- administrator joyfully signs its zone file while producing melodic
- sound patterns.
- Signer: The system that has access to the private key material and
- signs the Resource Record sets in a zone. A signer may be
- configured to sign only parts of the zone e.g. only those RRSets
- for which existing signatures are about to expire.
- Zone Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is
- used for signing all data in a zone. The fact that a key is a ZSK
- is only relevant to the signing tool.
- Zone Administrator: The 'role' that is responsible for signing a zone
- and publishing it on the primary authoritative server.
-
-
-Appendix B. Zone Signing Key Rollover Howto
-
- Using the pre-published signature scheme and the most conservative
- method to assure oneself that data does not live in caches, here
- follows the "HOWTO".
- Step 0: The preparation: Create two keys and publish both in your key
- set. Mark one of the keys as "active" and the other as
- "published". Use the "active" key for signing your zone data.
- Store the private part of the "published" key, preferably off-
- line.
- The protocol does not provide for attributes to mark a key as
- active or published. This is something you have to do on your
- own, through the use of a notebook or key management tool.
- Step 1: Determine expiration: At the beginning of the rollover make a
- note of the highest expiration time of signatures in your zone
- file created with the current key marked as "active".
- Wait until the expiration time marked in Step 1 has passed
- Step 2: Then start using the key that was marked as "published" to
- sign your data i.e. mark it as "active". Stop using the key that
- was marked as "active", mark it as "rolled".
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 30]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- Step 3: It is safe to engage in a new rollover (Step 1) after at
- least one "signature validity period".
-
-
-Appendix C. Typographic Conventions
-
- The following typographic conventions are used in this document:
- Key notation: A key is denoted by DNSKEYx, where x is a number or an
- identifier, x could be thought of as the key id.
- RRSet notations: RRs are only denoted by the type. All other
- information - owner, class, rdata and TTL - is left out. Thus:
- "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a
- list of RRs. A example of this would be: "A1, A2", specifying the
- RRSet containing two "A" records. This could again be abbreviated
- to just "A".
- Signature notation: Signatures are denoted as RRSIGx(RRSet), which
- means that RRSet is signed with DNSKEYx.
- Zone representation: Using the above notation we have simplified the
- representation of a signed zone by leaving out all unnecessary
- details such as the names and by representing all data by "SOAx"
- SOA representation: SOAs are represented as SOAx, where x is the
- serial number.
- Using this notation the following signed zone:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 31]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- example.net. 86400 IN SOA ns.example.net. bert.example.net. (
- 2006022100 ; serial
- 86400 ; refresh ( 24 hours)
- 7200 ; retry ( 2 hours)
- 3600000 ; expire (1000 hours)
- 28800 ) ; minimum ( 8 hours)
- 86400 RRSIG SOA 5 2 86400 20130522213204 (
- 20130422213204 14 example.net.
- cmL62SI6iAX46xGNQAdQ... )
- 86400 NS a.iana-servers.net.
- 86400 NS b.iana-servers.net.
- 86400 RRSIG NS 5 2 86400 20130507213204 (
- 20130407213204 14 example.net.
- SO5epiJei19AjXoUpFnQ ... )
- 86400 DNSKEY 256 3 5 (
- EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
- 86400 DNSKEY 257 3 5 (
- gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
- 86400 RRSIG DNSKEY 5 2 86400 20130522213204 (
- 20130422213204 14 example.net.
- J4zCe8QX4tXVGjV4e1r9... )
- 86400 RRSIG DNSKEY 5 2 86400 20130522213204 (
- 20130422213204 15 example.net.
- keVDCOpsSeDReyV6O... )
- 86400 RRSIG NSEC 5 2 86400 20130507213204 (
- 20130407213204 14 example.net.
- obj3HEp1GjnmhRjX... )
- a.example.net. 86400 IN TXT "A label"
- 86400 RRSIG TXT 5 3 86400 20130507213204 (
- 20130407213204 14 example.net.
- IkDMlRdYLmXH7QJnuF3v... )
- 86400 NSEC b.example.com. TXT RRSIG NSEC
- 86400 RRSIG NSEC 5 3 86400 20130507213204 (
- 20130407213204 14 example.net.
- bZMjoZ3bHjnEz0nIsPMM... )
- ...
-
- is reduced to the following representation:
-
- SOA2006022100
- RRSIG14(SOA2006022100)
- DNSKEY14
- DNSKEY15
-
- RRSIG14(KEY)
- RRSIG15(KEY)
-
- The rest of the zone data has the same signature as the SOA record,
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 32]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- i.e a RRSIG created with DNSKEY 14.
-
-
-Appendix D. Document Details and Changes
-
- This section is to be removed by the RFC editor if and when the
- document is published.
-
- $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14
- 2005/03/21 15:51:41 dnssec Exp $
-
-D.1. draft-ietf-dnsop-dnssec-operational-practices-00
-
- Submission as working group document. This document is a modified
- and updated version of draft-kolkman-dnssec-operational-practices-00.
-
-D.2. draft-ietf-dnsop-dnssec-operational-practices-01
-
- changed the definition of "Bogus" to reflect the one in the protocol
- draft.
-
- Bad to Bogus
-
- Style and spelling corrections
-
- KSK - SEP mapping made explicit.
-
- Updates from Sam Weiler added
-
-D.3. draft-ietf-dnsop-dnssec-operational-practices-02
-
- Style and errors corrected.
-
- Added Automatic rollover requirements from I-D.ietf-dnsop-key-
- rollover-requirements.
-
-D.4. draft-ietf-dnsop-dnssec-operational-practices-03
-
- Added the definition of Key effectivity period and used that term
- instead of Key validity period.
-
- Modified the order of the sections, based on a suggestion by Rip
- Loomis.
-
- Included parts from RFC 2541 [12]. Most of its ground was already
- covered. This document obsoletes RFC 2541 [12]. Section 3.1.2
- deserves some review as it in contrast to RFC 2541 does _not_ give
- recomendations about root-zone keys.
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 33]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
- added a paragraph to Section 4.4.4
-
-D.5. draft-ietf-dnsop-dnssec-operational-practices-04
-
- Somewhat more details added about the pre-publish KSK rollover. Also
- moved that subsection down a bit.
-
- Editorial and content nits that came in during wg last call were
- fixed.
-
-D.6. draft-ietf-dnsop-dnssec-operational-practices-05
-
- Applied some another set of comments that came in _after_ the the
- WGLC.
-
- Applied comments from Hilarie Orman and made a referece to RFC 3766.
- Deleted of a lot of key length discussion and took over the
- recommendations from RFC 3766.
-
- Reworked all the heading of the rollover figures
-
-D.7. draft-ietf-dnsop-dnssec-operational-practices-06
-
- One comment from Scott Rose applied.
-
- Marcos Sanz gave a lots of editorial nits. Almost all are
- incorporated.
-
-D.8. draft-ietf-dnsop-dnssec-operational-practices-07
-
- Peter Koch's comments applied.
-
- SHA-1/SHA-256 remarks added
-
-D.9. draft-ietf-dnsop-dnssec-operational-practices-08
-
- IESG comments applied. Added headers and some captions to the tables
- and applied all the nits.
-
- IESG DISCUSS comments applied
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 34]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
-Authors' Addresses
-
- Olaf M. Kolkman
- NLnet Labs
- Kruislaan 419
- Amsterdam 1098 VA
- The Netherlands
-
- Email: olaf@nlnetlabs.nl
- URI: http://www.nlnetlabs.nl
-
-
- Miek Gieben
- NLnet Labs
- Kruislaan 419
- Amsterdam 1098 VA
- The Netherlands
-
- Email: miek@nlnetlabs.nl
- URI: http://www.nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 35]
-\f
-Internet-Draft DNSSEC Operational Practices March 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Kolkman & Gieben Expires September 7, 2006 [Page 36]
-\f
+++ /dev/null
-
-
-
-
-
-
- DNSOP Working Group Paul Vixie, ISC
- INTERNET-DRAFT Akira Kato, WIDE
- <draft-ietf-dnsop-respsize-02.txt> July 2005
-
- DNS Response Size Issues
-
- Status of this Memo
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-
-
-
- Abstract
-
- With a mandated default minimum maximum message size of 512 octets,
- the DNS protocol presents some special problems for zones wishing to
- expose a moderate or high number of authority servers (NS RRs). This
- document explains the operational issues caused by, or related to
- this response size limit.
-
-
-
-
-
-
- Expires December 2005 [Page 1]
-\f
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- 1 - Introduction and Overview
-
- 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
- octets. Even though this limitation was due to the required minimum UDP
- reassembly limit for IPv4, it is a hard DNS protocol limit and is not
- implicitly relaxed by changes in transport, for example to IPv6.
-
- 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
- responses by mutual agreement of the requestor and responder. However,
- deployment of EDNS0 cannot be expected to reach every Internet resolver
- in the short or medium term. The 512 octet message size limit remains
- in practical effect at this time.
-
- 1.3. Since DNS responses include a copy of the request, the space
- available for response data is somewhat less than the full 512 octets.
- For negative responses, there is rarely a space constraint. For
- positive and delegation responses, though, every octet must be carefully
- and sparingly allocated. This document specifically addresses
- delegation response sizes.
-
- 2 - Delegation Details
-
- 2.1. A delegation response will include the following elements:
-
- Header Section: fixed length (12 octets)
- Question Section: original query (name, class, type)
- Answer Section: (empty)
- Authority Section: NS RRset (nameserver names)
- Additional Section: A and AAAA RRsets (nameserver addresses)
-
- 2.2. If the total response size would exceed 512 octets, and if the data
- that would not fit belonged in the question, answer, or authority
- section, then the TC bit will be set (indicating truncation) which may
- cause the requestor to retry using TCP, depending on what information
- was desired and what information was omitted. If a retry using TCP is
- needed, the total cost of the transaction is much higher. (See [RFC1123
- 6.1.3.2] for details on the protocol requirement that UDP be attempted
- before falling back to TCP.)
-
- 2.3. RRsets are never sent partially unless truncation occurs, in which
- case the final apparent RRset in the final nonempty section must be
- considered "possibly damaged". With or without truncation, the glue
- present in the additional data section should be considered "possibly
- incomplete", and requestors should be prepared to re-query for any
- damaged or missing RRsets. For multi-transport name or mail services,
-
-
-
- Expires December 2005 [Page 2]
-\f
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- this can mean querying for an IPv6 (AAAA) RRset even when an IPv4 (A)
- RRset is present.
-
- 2.4. DNS label compression allows a domain name to be instantiated only
- once per DNS message, and then referenced with a two-octet "pointer"
- from other locations in that same DNS message. If all nameserver names
- in a message are similar (for example, all ending in ".ROOT-
- SERVERS.NET"), then more space will be available for uncompressable data
- (such as nameserver addresses).
-
- 2.5. The query name can be as long as 255 characters of presentation
- data, which can be up to 256 octets of network data. In this worst case
- scenario, the question section will be 260 octets in size, which would
- leave only 240 octets for the authority and additional sections (after
- deducting 12 octets for the fixed length header.)
-
- 2.6. Average and maximum question section sizes can be predicted by the
- zone owner, since they will know what names actually exist, and can
- measure which ones are queried for most often. For cost and performance
- reasons, the majority of requests should be satisfied without truncation
- or TCP retry.
-
- 2.7. Requestors who deliberately send large queries to force truncation
- are only increasing their own costs, and cannot effectively attack the
- resources of an authority server since the requestor would have to retry
- using TCP to complete the attack. An attack that always used TCP would
- have a lower cost.
-
- 2.8. The minimum useful number of address records is two, since with
- only one address, the probability that it would refer to an unreachable
- server is too high. Truncation which occurs after two address records
- have been added to the additional data section is therefore less
- operationally significant than truncation which occurs earlier.
-
- 2.9. The best case is no truncation. This is because many requestors
- will retry using TCP by reflex, or will automatically re-query for
- RRsets that are "possibly truncated", without considering whether the
- omitted data was actually necessary.
-
- 2.10. Each added NS RR for a zone will add a minimum of between 16 and
- 44 octets to every untruncated referral or negative response from the
- zone's authority servers (16 octets for an NS RR, 16 octets for an A RR,
- and 28 octets for an AAAA RR), in addition to whatever space is taken by
- the nameserver name (NS NSDNAME and A/AAAA owner name).
-
-
-
-
- Expires December 2005 [Page 3]
-\f
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- 3 - Analysis
-
- 3.1. An instrumented protocol trace of a best case delegation response
- follows. Note that 13 servers are named, and 13 addresses are given.
- This query was artificially designed to exactly reach the 512 octet
- limit.
-
- ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
- ;; QUERY SECTION:
- ;; [23456789.123456789.123456789.\
- 123456789.123456789.123456789.com A IN] ;; @80
-
- ;; AUTHORITY SECTION:
- com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
- com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
- com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
- com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
- com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
- com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
- com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
- com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
- com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
- com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
- com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
- com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
- com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
-
- ;; ADDITIONAL SECTION:
- A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
- B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
- C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
- D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
- E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
- F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
- G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
- H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
- I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
- J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
- K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
- L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
- M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
-
- ;; MSG SIZE sent: 80 rcvd: 512
-
-
-
-
-
- Expires December 2005 [Page 4]
-\f
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- 3.2. For longer query names, the number of address records supplied will
- be lower. Furthermore, it is only by using a common parent name (which
- is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
- fit. The following output from a response simulator demonstrates these
- properties:
-
- % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
- a.dns.br requires 10 bytes
- b.dns.br requires 4 bytes
- c.dns.br requires 4 bytes
- d.dns.br requires 4 bytes
- # of NS: 4
- For maximum size query (255 byte):
- if only A is considered: # of A is 4 (green)
- if A and AAAA are condered: # of A+AAAA is 3 (yellow)
- if prefer_glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
- For average size query (64 byte):
- if only A is considered: # of A is 4 (green)
- if A and AAAA are condered: # of A+AAAA is 4 (green)
- if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
- % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
- ns-ext.isc.org requires 16 bytes
- ns.psg.com requires 12 bytes
- ns.ripe.net requires 13 bytes
- ns.eu.int requires 11 bytes
- # of NS: 4
- For maximum size query (255 byte):
- if only A is considered: # of A is 4 (green)
- if A and AAAA are condered: # of A+AAAA is 3 (yellow)
- if prefer_glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
- For average size query (64 byte):
- if only A is considered: # of A is 4 (green)
- if A and AAAA are condered: # of A+AAAA is 4 (green)
- if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
- (Note: The response simulator program is shown in Section 5.)
-
- Here we use the term "green" if all address records could fit, or
- "orange" if two or more could fit, or "red" if fewer than two could fit.
- It's clear that without a common parent for nameserver names, much space
- would be lost. For these examples we use an average/common name size of
- 15 octets, befitting our assumption of GTLD-SERVERS.NET as our common
- parent name.
-
-
-
-
- Expires December 2005 [Page 5]
-\f
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- We're assuming an average query name size of 64 since that is the
- typical average maximum size seen in trace data at the time of this
- writing. If Internationalized Domain Name (IDN) or any other technology
- which results in larger query names be deployed significantly in advance
- of EDNS, then new measurements and new estimates will have to be made.
-
- 4 - Conclusions
-
- 4.1. The current practice of giving all nameserver names a common parent
- (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
- responses and allows for more nameservers to be enumerated than would
- otherwise be possible. (Note that in this case it is wise to serve the
- common parent domain's zone from the same servers that are named within
- it, in order to limit external dependencies when all your eggs are in a
- single basket.)
-
- 4.2. Thirteen (13) seems to be the effective maximum number of
- nameserver names usable traditional (non-extended) DNS, assuming a
- common parent domain name, and given that response truncation is
- undesirable as an average case, and assuming mostly IPv4-only
- reachability (only A RRs exist, not AAAA RRs).
-
- 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
- prototypical delegation that currently contains thirteen (13) IPv4
- nameserver addresses (A RRs) for thirteen (13) nameserver names under a
- common parent, would not have a significant negative operational impact
- on the domain name system.
-
- 5 - Source Code
-
- #!/usr/bin/perl
- #
- # SYNOPSIS
- # repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
- # if all queries are assumed to have zone suffux, such as "jp" in
- # JP TLD servers, specify it in -z option
- #
- use strict;
- use Getopt::Std;
- my ($sz_msg) = (512);
- my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
- my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
- my (%namedb, $name, $nssect, %opts, $optz);
- my $n_ns = 0;
-
-
-
-
- Expires December 2005 [Page 6]
-\f
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- getopt('z', opts);
- if (defined($opts{'z'})) {
- server_name_len($opts{'z'}); # just register it
- }
-
- foreach $name (@ARGV) {
- my $len;
- $n_ns++;
- $len = server_name_len($name);
- print "$name requires $len bytes\n";
- $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl + $sz_rdlen + $len;
- }
- print "# of NS: $n_ns\n";
- arsect(255, $nssect, $n_ns, "maximum");
- arsect(64, $nssect, $n_ns, "average");
-
- sub server_name_len {
- my ($name) = @_;
- my (@labels, $len, $n, $suffix);
-
- $name =~ tr/A-Z/a-z/;
- @labels = split(/./, $name);
- $len = length(join('.', @labels)) + 2;
- for ($n = 0; $#labels >= 0; $n++, shift @labels) {
- $suffix = join('.', @labels);
- return length($name) - length($suffix) + $sz_ptr
- if (defined($namedb{$suffix}));
- $namedb{$suffix} = 1;
- }
- return $len;
- }
-
- sub arsect {
- my ($sz_query, $nssect, $n_ns, $cond) = @_;
- my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
- $ansect = $sz_query + 1 + $sz_type + $sz_class;
- $space = $sz_msg - $sz_header - $ansect - $nssect;
- $n_a = atmost(int($space / $sz_rr_a), $n_ns);
- $n_a_aaaa = atmost(int($space / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
- $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) / $sz_rr_aaaa), $n_ns);
- printf "For %s size query (%d byte):\n", $cond, $sz_query;
- printf "if only A is considered: ";
- printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
- printf "if A and AAAA are condered: ";
- printf "# of A+AAAA is %d (%s)\n", $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
-
-
-
- Expires December 2005 [Page 7]
-\f
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- printf "if prefer_glue A is assumed: ";
- printf "# of A is %d, # of AAAA is %d (%s)\n",
- $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
- }
-
- sub judge {
- my ($n, $n_ns) = @_;
- return "green" if ($n >= $n_ns);
- return "yellow" if ($n >= 2);
- return "orange" if ($n == 1);
- return "red";
- }
-
- sub atmost {
- my ($a, $b) = @_;
- return 0 if ($a < 0);
- return $b if ($a > $b);
- return $a;
- }
-
- Security Considerations
-
- The recommendations contained in this document have no known security
- implications.
-
- IANA Considerations
-
- This document does not call for changes or additions to any IANA
- registry.
-
- IPR Statement
-
- Copyright (C) The Internet Society (2005). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except as
- set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
- IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
- Expires December 2005 [Page 8]
-\f
- INTERNET-DRAFT July 2005 RESPSIZE
-
-
- Authors' Addresses
-
- Paul Vixie
- 950 Charter Street
- Redwood City, CA 94063
- +1 650 423 1301
- vixie@isc.org
-
- Akira Kato
- University of Tokyo, Information Technology Center
- 2-11-16 Yayoi Bunkyo
- Tokyo 113-8658, JAPAN
- +81 3 5841 2750
- kato@wide.ad.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires December 2005 [Page 9]
-\f
\ No newline at end of file
projects / thirdparty / bind9.git / commitdiff
