mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 05:57:52 +00:00
Code Issues Releases Wiki Activity

cleanup

Browse Source
This commit is contained in:
Mark Andrews 2009-11-19 05:03:52 +00:00
parent f95bdcf65d
commit f7e3edb15a
21 changed files with 2954 additions and 10479 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

336
doc/draft/draft-baba-dnsext-acl-reqts-01.txt
View File

@ -1,336 +0,0 @@
Internet-Draft T. Baba
Expires: March 11, 2004 NTT Data
September 11, 2003
Requirements for Access Control in Domain Name Systems
draft-baba-dnsext-acl-reqts-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
This Internet-Draft will expire on March 11, 2004.
Abstract
This document describes the requirements for access control
mechanisms in the Domain Name System (DNS), which authenticate
clients and then allow or deny access to resource records in the
zone according to the access control list (ACL).
1. Introduction
The Domain Name System (DNS) is a hierarchical, distributed, highly
available database used for bi-directional mapping between domain
names and IP addresses, for email routing, and for other information
[RFC1034, 1035]. DNS security extensions (DNSSEC) have been defined
to authenticate the data in DNS and provide key distribution services
using SIG, KEY, and NXT resource records (RRs) [RFC2535].
Baba Expires March 11, 2004 [Page 1]
Internet-Draft DNS Access Control Requirements September 2003
At the 28th IETF Meeting in Houston in 1993, DNS security design team
started a discussion about DNSSEC and agreed to accept the assumption
that "DNS data is public". Accordingly, confidentiality for queries
or responses is not provided by DNSSEC, nor are any sort of access
control lists or other means to differentiate inquirers. However,
about ten years has passed, access control in DNS has been more
important than before. Currently, new RRs are proposed to add new
functionality to DNS such as ENUM [RFC2916]. Such new RRs may
contain private information. Thus, DNS access control will be
needed.
Furthermore, with DNS access control mechanism, access from
unauthorized clients can be blocked when they perform DNS name
resolution. Thus, for example, Denial of Service (DoS) attacks
against a server used by a closed user group can be prevented using
this mechanism if IP address of the server is not revealed by other
sources.
This document describes the requirements for access control
mechanisms in DNS.
2. Terminology
AC-aware client
This is the client that understands the DNS access control
extensions. This client may be an end host which has a stub
resolver, or a cashing/recursive name server which has a
full-service resolver.
AC-aware server
This is the authoritative name server that understands the DNS
access control extensions.
ACE
An Access Control Entry. This is the smallest unit of access
control policy. It grants or denies a given set of access
rights to a set of principals. An ACE is a component of an ACL,
which is associated with a resource.
ACL
An Access Control List. This contains all of the access control
policies which are directly associated with a particular
resource. These policies are expressed as ACEs.
Client
A program or host which issues DNS requests and accepts its
responses. A client may be an end host or a cashing/recursive name
server.
Baba Expires March 11, 2004 [Page 2]
Internet-Draft DNS Access Control Requirements September 2003
RRset
All resource records (RRs) having the same NAME, CLASS and TYPE
are called a Resource Record Set (RRset).
3. Requirements
This section describes the requirements for access control in DNS.
3.1 Authentication
3.1.1 Client Authentication Mechanism
The AC-aware server must identify AC-aware clients based on IP
address and/or domain name (user ID or host name), and must
authenticate them using strong authentication mechanism such as
digital signature or message authentication code (MAC).
SIG(0) RR [RFC2931] contains a domain name associated with sender's
public key in its signer's name field, and TSIG RR [RFC2845] also
contains a domain name associated with shared secret key in its key
name field. Each of these domain names can be a host name or a user
name, and can be used as a sender's identifier for access control.
Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
message authentication. These mechanisms can be used to authenticate
AC-aware clients.
Server authentication may be also provided.
3.1.2 End-to-End Authentication
In current DNS model, caching/recursive name servers are deployed
between end hosts and authoritative name servers. Although
authoritative servers can authenticate caching/recursive name servers
using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
For end-to-end authentication, the mechanism for an end host to
discover the target authoritative name server and directly access to
it bypassing caching/recursive name servers is needed. For example,
an end host can get the IP addresses of the authoritative name
servers by retrieving NS RRs for the zone via local caching/recursive
name server.
In many enterprise networks, however, there are firewalls that block
all DNS packets other than those going to/from the particular
caching/recursive servers. To deal with this problem, one can
implement packet forwarding function on the caching/recursive servers
and enable end-to-end authentication via the caching/recursive
servers.
Baba Expires March 11, 2004 [Page 3]
Internet-Draft DNS Access Control Requirements September 2003
3.1.3 Authentication Key Retrieval
Keys which are used to authenticate clients should be able to be
automatically retrieved. The KEY RR is used to store a public key
for a zone or a host that is associated with a domain name. SIG(0)
RR uses a public key in KEY RR for verifying the signature. If
DNSSEC is available, the KEY RR would be protected by the SIG RR.
KEY RR or newly defined RR can be used to automatic key retrieval.
3.2 Confidentiality
3.2.1 Data Encryption
To avoid disclosure to eavesdroppers, the response containing the
RRsets which are restricted to access from particular users should be
encrypted. Currently, no encryption mechanism is specified in DNS.
Therefore, new RRs should be defined for DNS message encryption.
Instead, IPsec [RFC2401] can be used to provide confidentiality if
name server and resolver can set up security associations dynamically
using IPsec API [IPSECAPI] when encryption is required.
In case encryption is applied, entire DNS message including DNS
header should be encrypted to hide information including error code.
Query encryption may be also provided for hiding query information.
3.2.2 Key Exchange
If DNS message encryption is provided, automatic key exchange
mechanism should be also provided. [RFC2930] specifies a TKEY RR
that can be used to establish and delete shared secret keys used by
TSIG between a client and a server. With minor extensions, TKEY can
be used to establish shared secret keys used for message encryption.
3.2.3 Caching
The RRset that is restricted to access from particular users must not
be cached. To avoid caching, the TTL of the RR that is restricted to
access should be set to zero during transit.
3.3 Access Control
3.3.1 Granularity of Access Control
Control of access on a per-user/per-host granularity must be
supported. Control of access to individual RRset (not just the
entire zone) must be also supported. However, SOA, NS, SIG, NXT,
KEY, and DS RRs must be publicly accessible to avoid unexpected
results.
Baba Expires March 11, 2004 [Page 4]
Internet-Draft DNS Access Control Requirements September 2003
3.3.2 ACL Representation
Access Control List (ACL) format must be standardized so that both
the primary and secondary AC-aware servers can recognize the same
ACL. Although ACL may appear in or out of zone data, it must be
transferred to the secondary AC-aware server with associated zone
data. It is a good idea to contain ACL in zone data, because ACL can
be transferred with zone data using existing zone transfer mechanisms
automatically. However, ACL must not be published except for
authorized secondary master servers.
In zone data master files, ACL should be specified using TXT RRs or
newly defined RRs. In each access control entry (ACE), authorized
entities (host or user) must be described using domain name (host
name, user name, or IP address in in-addr.arpa/ip6.arpa format).
There may be other access control attributes such as access time.
It must be possible to create publicly readable entries, which may be
read even by unauthenticated clients.
3.3.3 Zone/ACL Transfer
As mentioned above, ACL should be transferred from a primary AC-aware
server to a secondary AC-aware server with associated zone data.
When an AC-aware server receives a zone/ACL transfer request, the
server must authenticate the client, and should encrypt the zone
data and associated ACL during transfer.
3.4 Backward/co-existence Compatibility
Any new protocols to be defined for access control in DNS must be
backward compatible with existing DNS protocol. AC-aware servers
must be able to process normal DNS query without authentication, and
must respond if retrieving RRset is publicly accessible.
Modifications to root/gTLD/ccTLD name servers are not allowed.
4. Security Considerations
This document discusses the requirements for access control
mechanisms in DNS.
5. Acknowledgements
This work is funded by the Telecommunications Advancement
Organization of Japan (TAO).
The author would like to thank the members of the NTT DATA network
security team for their important contribution to this work.
Baba Expires March 11, 2004 [Page 5]
Internet-Draft DNS Access Control Requirements September 2003
6. References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
September 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
RFC 2930, September 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s)", RFC 2931, September 2000.
[IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
Progress.
Author's Address
Tatsuya Baba
NTT Data Corporation
Research and Development Headquarters
Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
Tokyo 104-0033, Japan
Tel: +81 3 3523 8081
Fax: +81 3 3523 8090
Email: babatt@nttdata.co.jp
Baba Expires March 11, 2004 [Page 6]

1232
doc/draft/draft-daigle-napstr-04.txt
View File

File diff suppressed because it is too large Load Diff

1960
doc/draft/draft-danisch-dns-rr-smtp-03.txt
View File

File diff suppressed because it is too large Load Diff

241
doc/draft/draft-dnsext-opcode-discover-02.txt
View File

@ -1,241 +0,0 @@
IETF DNSEXT WG Bill Manning
draft-dnsext-opcode-discover-02.txt ep.net
Paul Vixie
ISC
13 Oct 2003
The DISCOVER opcode
This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026.
Comments may be submitted to the group mailing list at "mdns@zocalo.net"
or the authors.
Distribution of this memo is unlimited.
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.
The capitalized keywords "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
0. Abstract:
The QUERY opcode in the DNS is designed for unicast. With the
development of multicast capabilities in the DNS, it is desireable
to have a more robust opcode for server interactions since a single
request may generate replies from multiple responders. So DISCOVER
is defined to deal with replies from multiple responders.
As such, this document extends the core DNS specifications to allow
clients to have a method for coping with replies from multiple
responders. Use of this new opcode may facilitate DNS operations in
modern networking topologies. A prototype of the DISCOVER opcode
was developed during the TBDS project (1999-2000), funded under DARPA
grant F30602-99-1-0523.
1. Introduction:
This document describes an experimental extension to the DNS to receive
multiple responses which is the likely result when using DNS that has
enabled multicast queries. This approach was developed as part of the
TBDS research project, funded under DARPA grant F30602-99-1-0523. The
full processing rules used by TBDS are documented here for possible
incorporation in a future revision of the DNS specification."
2. Method:
DISCOVER works like QUERY except:
1. it can be sent to a broadcast or multicast destination. QUERY
isn't defined for non-unicast, and arguably shouldn't be.
2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
tuples. TBDS tried to augment this structure as follows:
<QNAME=service,QTYPE=SRV>. While this worked for our purposes in
TBDS, it is cleaner to place the SRV question in a separate pass.
3. if QDCOUNT equals 0 then only servers willing to do recursion should
answer. Other servers must silently discard the DISCOVER request.
4. if QDCOUNT is not equal to 0 then only servers who are authoritative
for the zones named by some QNAME should answer.
5. responses may echo the request's Question section or leave it blank,
just like QUERY.
6. responses have standard Answer, Authority, and Additional sections.
e.g. the response is the same as that to a QUERY. It is desireable
that zero content answers not be sent to avoid badly formed or
unfulfilled requests. Responses should be sent to the unicast
address of the requester and the source address should reflect
the unicast address of the responder.
Example usage for gethostby{name,addr}-style requestors:
Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
ip6.arpa domain.
DISCOVER whether anyone in-scope is authoritative for this zone.
If so, query these authoritative servers for local
in-addr/ip6 names.
If not, DISCOVER whether there are recursive servers available.
If so, query these recursive servers for local
in-addr/ip6 names.
So, a node will issue a multicast request with the DISCOVER opcode at
some particular multicast scope. Then determine, from the replies,
whether there are any DNS servers which are authoritative (or support
recursion) for the zone. Replies to DISCOVER requests MUST set the
Recursion Available (RA) flag in the DNS message header.
It is important to recognize that a requester must be prepared to
receive multiple replies from multiple responders. We expect that
there will be a single response per responder.
Once one learns a host's FQDN by the above means, repeat the process
for discovering the closest enclosing authoritative server of such
local name.
Cache all NS and A data learned in this process, respecting TTL's.
TBDS usage for SRV requestors:
Do the gethostbyaddr() and gethostbyname() on one's own link-local
address, using the above process.
Assume that the closest enclosing zone for which an authority server
answers an in-scope DISCOVER packet is "this host's parent domain".
Compute the SRV name as _service._transport.*.parentdomain.
This is a change to the definition as defined in RFC 1034.
A wildcard label ("*") in the QNAME used in a DNS message with
opcode DISCOVER SHOULD be evaluated with special rules. The
wildcard matches any label for which the DNS server data is
authoritative. For example 'x.*.example.com.' would match
'x.y.example.com.' and 'x.yy.example.com.' provided that the
server was authoritative for 'example.com.' In this particular
case, we suggest the follwing considerations be made:
getservbyname() can be satisfied by issuing a request with
this computed SRV name. This structure can be
populated by values returned from a request as follows:
s_name The name of the service, "_service" without the
preceding underscore.
s_aliases The names returned in the SRV RRs in replies
to the query.
s_port The port number in the SRV RRs replies to the
query. If these port numbers disagree - one
of the port numbers is chosen, and only those
names which correspond are returned.
s_proto The transport protocol from named by the
"_transport" label, without the preceding
underscore.
Send SRV query for this name to discovered local authoritative servers.
Usage for disconnected networks with no authoritative servers:
Hosts should run a "stub server" which acts as though its FQDN is a
zone name. Computed SOA gives the host's FQDN as MNAME, "." as the
ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
and the other timers. Compute NS as the host's FQDN. Compute the
glue as the host's link-local address. Or Hosts may run a
"DNS stub server" which acts as though its FQDN is a zone name. The
rules governing the behavior of this stub server are given elsewhere
[1] [2].
Such stub servers should answer DISCOVER packets for its zone, and
will be found by the iterative "discover closest enclosing authority
server" by DISCOVER clients, either in the gethostbyname() or SRV
cases described above. Note that stub servers only answer with
zone names which exactly match QNAME's, not with zone names which
are owned by QNAME's.
The main deviation from the DNS[3][4] model is that a host (like, say, a
printer offering LPD services) has a DNS server which answers authoritatively
for something which hasn't been delegated to it. However, the only way that
such DNS servers can be discovered is with a new opcode, DISCOVER, which
is explicitly defined to discover undelegated zones for tightly scoped
purposes. Therefore this isn't officially a violation of DNS's coherency
principles. In some cases a responder to DISCOVER may not be traditional
DNS software, it could be special purpose software.
3. IANA Considerations
As a new opcode, the IANA will need to assign a numeric value
for the memnonic. The last OPCODE assigned was "5", for UPDATE.
Test implementations have used OPCODE "6".
4. Security Considerations
No new security considerations are known to be introduced with any new
opcode, however using multicast for service discovery has the potential
for denial of service, primarly from flooding attacks. It may also be
possible to enable deliberate misconfiguration of clients simply by
running a malicious DNS resolver that claims to be authoritative for
things that it is not. One possible way to mitigate this effect is by
use of credentials, such as CERT resource records within an RR set.
The TBDS project took this approach.
5. Attribution:
This material was generated in discussions on the mdns mailing list
hosted by Zocalo in March 2000. Updated by discussion in September/October
2003. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock,
Erik Guttman, Bill Manning and Paul Vixie were active contributors.
6. Author's Address
Bill Manning
PO 12317
Marina del Rey, CA. 90295
+1.310.322.8102
bmanning@karoshi.com
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<vixie@isc.org>
7. References
Informational References:
[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
draft-manning-dnsext-mdns-00.txt, August 2000. Expired.
Normative References:
[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
RFC 1035, November 1987
----------------------------EOL-----------------------

370
doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt
View File

@ -1,370 +0,0 @@
DNS Extensions working group V.Dolmatov, Ed.
Internet-Draft Cryptocom Ltd.
Intended status: Standards Track April 8, 2009
Expires: December 31, 2009
Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
for DNSSEC
draft-dolmatov-dnsext-dnssec-gost-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 31 December 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes how to produce GOST signature and hash algorithms
DNSKEY and RRSIG resource records for use in the Domain Name System
Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . .
2.1. Using a public key with existing cryptographic libraries. .
2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . .
3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . .
4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . .
5. NSEC3 Resource Records . . . . . . . . . . . . . . . . . . . .
6. Deployment Considerations . . . . . . . . . . . . . . . . . . .
6.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . .
6.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . .
7. Implementation Considerations . . . . . . . . . . . . . . . . .
7.1. Support for GOST signatures . . . . . . . . . . . . . . . .
7.2. Support for NSEC3 Denial of Existence . . . . . . . . . . .
7.2.1. NSEC3 in Authoritative servers . . . . . . . . . . . .
7.2.2. NSEC3 in Validators . . . . . . . . . . . . . . . . . .
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .
10. References . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1. Normative References . . . . . . . . . . . . . . . . . . .
10.2. Informative References . . . . . . . . . . . . . . . . . .
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .
1. Introduction
The Domain Name System (DNS) is the global hierarchical distributed
database for Internet Naming. The DNS has been extended to use
cryptographic keys and digital signatures for the verification of the
authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034
[RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
Extensions, called DNSSEC.
RFC 4034 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 signature and hash algorithms
GOST [GOST3410, GOST3411],
and specifies how to store DNSKEY data and how to produce
RRSIG resource records with these hash algorithms.
Familiarity with DNSSEC and GOST signature and hash
algorithms is assumed in this document.
The term "GOST" is not officially defined, but is usually used to
refer to the collection of the Russian cryptographic algorithms
GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. Since GOST 28147-89
is not used in DNSSEC, GOST will only refer to GOST R 34.10-2001
(signatire algorithm) and GOST R 34.11-94 (hash algorithm) in this
document.
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].
2. DNSKEY Resource Records
The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
GOST R 34.10-2001 public keys are stored with the algorithm number {TBA1}.
The public key parameters are those identified by
id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357].
The digest parameters for signature are those identified by
id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
The wire format of the public key is compatible with RFC 4491 [RFC4491]:
According to [GOSTR341001], a public key is a point on the elliptic
curve Q = (x,y).
The wire representation of a public key MUST contain 64 octets, where the
first 32 octets contain the little-endian representation of x and the
second 32 octets contain the little-endian representation of y. This
corresponds to the binary representation of (<y>256||<x>256) from
[GOSTR341001], ch. 5.3.
2.1. Using a public key with existing cryptographic libraries
Existing GOST-aware cryptographic libraries at time of this document
writing are capable to read GOST public keys via generic X509 API if the
key is encoded according to RFC 4491 [RFC4491], section 2.3.2.
To make this encoding from the wire format of a GOST public key, prepend
a key data with the following 37-byte sequence:
0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 0x12
0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a 0x85 0x03
0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
2.2. GOST DNSKEY RR Example
The following DNSKEY RR stores a DNS zone key for example.com
example.com. 86400 IN DNSKEY 256 3 {TBA1} ( RamuUwTG1r4RUqsgXu/xF6B+Y
tJLzZEykiZ4C2Fa1gV1pI/8GA
el2Wm69Cz5h1T9eYAQKFAGwzW
m4Lke0E26aw== )
3. RRSIG Resource Records
The value of the signature field in the RRSIG RR follows the RFC 4490
[RFC4490] and is calculated as follows. The values for the RDATA fields
that precede the signature data are specified in RFC 4034 [RFC4034].
hash = GOSTR3411(data)
where "data" is the wire format data of the resource record set that is
signed, as specified in RFC 4034 [RFC4034]. Hash MUST be calculated with
GOST R 34.11-94 parameters identified by
id-GostR3411-94-CryptoProParamSet [RFC4357].
Signature is calculated from the hash according to the GOST R 34.10-2001
standard and its wire format is compatible with RFC 4490 [RFC4490].
Quoting RFC 4490:
"The signature algorithm GOST R 34.10-2001 generates a digital
signature in the form of two 256-bit numbers, r and s. Its octet
string representation consists of 64 octets, where the first 32
octets contain the big-endian representation of s and the second 32
octets contain the big-endian representation of r."
4. DS Resource Records
GOST R 34.11-94 digest algorithm is denoted in DS RR by the digest type
{TBA2}. The wire format of a digest value is compatible with RFC 4490
[RFC4490]. Quoting RFC 4490:
"A 32-byte digest in little-endian representation."
The digest MUST always be calculated with GOST R 34.11-94 parameters
identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
5. NSEC3 Resource Records
GOST R 34.11-94 digest algorithm is denoted in NSEC3 RR by the digest type
{TBA2}. The wire format of a digest value is compatible with RFC 4490
[RFC4490]. Quoting RFC 4490:
"A 32-byte digest in little-endian representation."
The digest MUST always be calculated with GOST R 34.11-94 parameters
identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
6. Deployment Considerations
6.1. Key Sizes
According to RFC4357 [RFC4357] key size of GOST public keys MUST
be 512 bits.
6.2. Signature Sizes
According to GOST signature algorithm [GOST3410] size of GOST signature
is 512 bit.
6.3. Digest Sizes
According to GOST R 34.11-94 [GOST3411] size of GOST digest is 256 bit.
7. Implementation Considerations
7.1. Support for GOST signatures
DNSSEC aware implementations SHOULD be able to support RRSIG and
DNSKEY resource records created with the GOST algorithms as
defined in this document.
7.2. Support for NSEC3 Denial of Existence
RFC5155 [RFC5155] defines new algorithm identifiers for existing
signing algorithms, to indicate that zones signed with these
algorithm identifiers use NSEC3 instead of NSEC records to provide
denial of existence. That mechanism was chosen to protect
implementations predating RFC5155 from encountering resource records
they could not know about. This document does not define such
algorithm aliases, and support for NSEC3 denial of existence is
implicitly signaled with support for one of the algorithms defined in
this document.
7.2.1. NSEC3 in Authoritative servers
An authoritative server that does not implement NSEC3 MAY still serve
zones that use GOST with NSEC denial of existence.
7.2.2. NSEC3 in Validators
A DNSSEC validator that implements GOST MUST be able to handle
both NSEC and NSEC3 [RFC5155] negative answers. If this is not the
case, the validator MUST treat a zone signed with GOST
as signed with an unknown algorithm, and thus as insecure.
8. IANA Considerations
This document updates the IANA registry "DNS SECURITY ALGORITHM
NUMBERS -- per [RFC4035] "
(http://www.iana.org/assignments/dns-sec-alg-numbers). The following
entries are added to the registry:
Zone Trans.
Value Algorithm Mnemonic Signing Sec. References Status
{TBA1} GOST R 34.10-2001 GOST Y * (this memo) OPTIONAL
This document updates the RFC 4034 [RFC4034] Digest Types assignment
(RFC 4034, section A.2):
Value Algorithm Status
{TBA2} GOST R 34.11-94 OPTIONAL
9. Acknowledgments
This document is a minor extension to RFC 4034 [RFC4034]. Also, we
try to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509]
and RFC 4357 [RFC4357] 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: Dmitry
Burkov, Jaap Akkerhuis, Jelte Jansen and Wouter Wijngaards.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001.
[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.
[GOST3410] "Information technology. Cryptographic data security.
Signature and verification processes of [electronic]
digital signature.", GOST R 34.10-2001, Gosudarstvennyi
Standard of Russian Federation, Government Committee of
the Russia for Standards, 2001. (In Russian)
[GOST3411] "Information technology. Cryptographic Data Security.
Hashing function.", GOST R 34.11-94, Gosudarstvennyi
Standard of Russian Federation, Government Committee of
the Russia for Standards, 1994. (In Russian)
[RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional
Cryptographic Algorithms for Use with GOST 28147-89,
GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
Algorithms", RFC 4357, January 2006.
[RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89,
GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001
Algorithms with Cryptographic Message Syntax (CMS)",
RFC 4490, May 2006.
[RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST
R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
Algorithms with the Internet X.509 Public Key
Infrastructure Certificate and CRL Profile", RFC 4491,
May 2006.
10.2. Informative References
[NIST800-57]
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
"Recommendations for Key Management", NIST SP 800-57,
March 2007.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
Authors' Addresses
Vasily Dolmatov, Ed.
Cryptocom Ltd.
Bolotnikovskaya, 23
Moscow, 117303, Russian Federation
EMail: dol@cryptocom.ru
Artem Chuprina
Cryptocom Ltd.
Bolotnikovskaya, 23
Moscow, 117303, Russian Federation
EMail: ran@cryptocom.ru
Igor Ustinov
Cryptocom Ltd.
Bolotnikovskaya, 23
Moscow, 117303, Russian Federation
EMail: igus@cryptocom.ru
Expires December 31, 2009 [Page ]

240
doc/draft/draft-durand-dnsop-dynreverse-00.txt
View File

@ -1,240 +0,0 @@
Internet Engineering Task Force Alain Durand
INTERNET-DRAFT SUN Microsystems
Feb 21, 2003
Expires Aug 2, 2003
Dynamic reverse DNS for IPv6
<draft-durand-dnsop-dynreverse-00.txt>
Status of this memo
This memo provides information to the Internet community. It does
not specify an Internet standard of any kind. This memo is in full
conformance with all provisions of Section 10 of RFC2026 [RFC2026].
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
This document describes a method to dynamically generate PTR records
and corresponding A or AAAA records when the reverse path DNS tree is
not populated.
A special domain dynrev.arpa. is reserved for that purpose.
1. Introduction
In IPv4, the reverse path tree of the DNS under in-addr.arpa.
although not perfectly maintained, is still mostly usable and its
existence is important for a number of applications that relies on
its existence and decent status. Some applications performs some
(very) weak security checks based on it. Mail relays relies on it for
some anti-spams checks an some FTP server will not let you in unless
your IP address resolve properly with a PTR record.
IPv6 addresses being much longer (and cumbersome) than IPv4
addresses, it is to fear that the reverse path tree under ip6.arpa.
would not be as well maintained. Also, tools like 6to4, Isatap and
others have made creative use of the 128 bits of an IPv6 address to
automatically embed an IPv4 address to enable seamless connection to
the IPv6 Internet. However, no provision has been made to make sure
the reverse path tree gets automatically updated as well for those
new IPv6 addresses. One step furter, RFC3041 describes a mechanism
to basically use random bits in the bottom part of an IPv6 address to
preserver anonymity. If those addresses are to resolve in the reverse
path tree, it obviously has to be with anonymous data as well.
Another point to note is that home customer ISPs in IPv4 have a
current practice to pre-populate the reverse path tree with names
automatically derived from the IP addresses. This practice is no
longer possible in IPv6, where IP address allocation is not dense as
it is the case in IPv4. The mere size of typical customer allocation
(2^48 according to the recommendation of RFC3177) makes it
impossible.
Applications that check the existence of PTR records usually follow
this by checking if the name pointed by the PTR resolve in a A (or
AAAA for IPv6) that match the original IP address. Thus the forward
path tree must also include the corresponding data.
One simple approach of this problem is to simply declare the usage of
the reverse path DNS as described above obsolete. The author believe
this is too strong an approach for now.
Similarly, a completely different approach would be to deprecate the
usage of DNS for the reverse tree altogether and replace it by
something inspired from ICMP name-info messages. The author believes
that this approached is an important departure from the current
practise and thus not very realistic. Also, there are some concerns
about the the security implications of this method as any node could
easily impersonate any name. This approach would fundamentally change
the underlying assumption of "I trust what has been put in the DNS by
the local administrators" to "I trust what has been configured on
each machine I query directly".
2. Dynamic record generation
If static pre-population of the tree is not possible anymore and data
still need to be returned to applications using getnameinfo(), the
alternative is dynamic record generation. This can be done is two
places: in the DNS servers responsible for the allocated space (/64
or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the
sub resolver library or the recursive DNS server).
2.1. On the resolver side.
The resolver, either in the recursive DNS server or in the stub
library could theoretically generate this data.
In case DNSsec is in place, the recursive DNS server would have to
pretend these records are authentic.
If the synthesis is done in the stub-resolver library, no record
needs to be actually generated, only the right information needs to
be passed to getnameinfo() and getaddrinfo(). If the synthesis is
done in the recursive DNS server, no modification is required to
existing stub resolvers.
2.2. On the server side.
PTR records could be generated automatically by the server
responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
prefixes or basically anything in between) when static data is not
available.
There could be impact on DNSsec as the zone or some parts of the zone
may need to be resigned each time a DNS query is made for an
unpopulated address. This can be seen as a DOS attack on a DNSsec
zone, so server side synthesis is not recommended if DNSsec is
deployed.
3. Synthesis
The algorithm is simple: Do the normal queries. If the query returns
No such domain, replace this answer by the synthetized one if
possible.
3.1. PTR synthesis
The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
where [X] is any valid DNS name.
The fact that the synthetized PTR points to the dynrev.arpa. domain
is an indication to the applications that this record has been
dynamically generated.
3.2. A synthesis
If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
record for the string [X].dynrev.arpa. which value is d.c.b.a. with
a,b,c & d being integer [0..255]
3.3. AAAA synthesis
If [X] is in the form
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
addr.arpa, one can synthetized a AAAA record for the string
[X].dynrev.arpa. which value is
FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
3.4. Server side synthesis
If synthesis is done on the server side, PTR could be set not to use
the dynrev.arpa domain but the local domain name instead. It culd be
for instance dynrev.mydomain.com.
Note also that server side synthesis is not incompatible with
resolver side synthesis.
4. IANA considerations
The dynrev.arpa. domain is reserved for the purpose of this document.
5. Security considerations
Section 2. discusses the the interactions with DNSsec.
6. Authors addresses
Alain Durand
SUN Microsystems, Inc
17, Network Circle
UMPK17-202
Menlo Park, CA 94025
USA
Mail: Alain.Durand@sun.com

928
doc/draft/draft-ietf-dnsext-2929bis-01.txt
View File

@ -1,928 +0,0 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories
Expires: February 2006 August 2005
Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
<draft-ietf-dnsext-2929bis-01.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 draft is unlimited. It is intended to become
the new BCP 42 obsoleting RFC 2929. Comments should be sent to the
DNS 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
Internet Assigned Number Authority (IANA) parameter assignment
considerations are given for the allocation of Domain Name System
(DNS) classes, RR types, operation codes, error codes, RR header
bits, and AFSDB subtypes.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DNS IANA Considerations August 2005
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. DNS Query/Response Headers..............................3
2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................4
2.3 RCODE Assignment.......................................5
3. DNS Resource Records....................................6
3.1 RR TYPE IANA Considerations............................7
3.1.1 DNS TYPE Allocation Policy...........................8
3.1.2 Special Note on the OPT RR...........................9
3.1.3 The AFSDB RR Subtype Field...........................9
3.2 RR CLASS IANA Considerations...........................9
3.3 RR NAME Considerations................................11
4. Security Considerations................................11
Appendix: Changes from RFC 2929...........................12
Copyright and Disclaimer..................................13
Normative References......................................13
Informative References....................................14
Authors Addresses.........................................16
Expiration and File Name..................................16
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DNS IANA Considerations August 2005
1. Introduction
The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchically store "resource records"
(RRs) under domain names. DNS data is structured into CLASSes and
zones which can be independently maintained. See [RFC 1034, 1035,
2136, 2181, 4033] familiarity with which is assumed.
This document provides, either directly or by reference, general IANA
parameter assignment considerations applying across DNS query and
response headers and all RRs. There may be additional IANA
considerations that apply to only a particular RR type or
query/response opcode. See the specific RFC defining that RR type or
query/response opcode for such considerations if they have been
defined, except for AFSDB RR considerations [RFC 1183] which are
included herein. This RFC obsoletes [RFC 2929].
IANA currently maintains a web page of DNS parameters. See
<http://www.iana.org/numbers.htm>.
"IETF Standards Action", "IETF Consensus", "Specification Required",
and "Private Use" are as defined in [RFC 2434].
2. DNS Query/Response Headers
The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136, 2929]:
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 |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so
they can be matched.
The QR bit indicates whether the header is for a query or a response.
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS IANA Considerations August 2005
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous given existing
implementation. Such meanings may only be assigned by an IETF
Standards Action.
The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
authority count (NSCOUNT), and additional information count (ARCOUNT)
express the number of records in each section for all opcodes except
Update. These fields have the same structure and data type for
Update but are instead the counts for the zone (ZOCOUNT),
prerequisite (PRCOUNT), update (UPCOUNT), and additional information
(ARCOUNT) sections.
2.1 One Spare Bit?
There have been ancient DNS implementations for which the Z bit being
on in a query meant that only a response from the primary server for
a zone is acceptable. It is believed that current DNS
implementations ignore this bit.
Assigning a meaning to the Z bit requires an IETF Standards Action.
2.2 Opcode Assignment
Currently DNS OpCodes are assigned as follows:
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query, Obsolete) [RFC 3425]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
New OpCode assignments require an IETF Standards Action as modified
by [RFC 4020].
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DNS IANA Considerations August 2005
2.3 RCODE Assignment
It would appear from the DNS header above that only four bits of
RCODE, or response/error code are available. However, RCODEs can
appear not only at the top level of a DNS response but also inside
OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
The OPT RR provides an eight bit extension resulting in a 12 bit
RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
Error codes appearing in the DNS header and in these three RR types
all refer to the same error code space with the single exception of
error code 16 which has a different meaning in the OPT RR from its
meaning in other contexts. See table below.
RCODE Name Description Reference
Decimal
Hexadecimal
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11 - 15 Available for assignment
16 BADVERS Bad OPT Version [RFC 2671]
16 BADSIG TSIG Signature Failure [RFC 2845]
17 BADKEY Key not recognized [RFC 2845]
18 BADTIME Signature out of time window [RFC 2845]
19 BADMODE Bad TKEY Mode [RPC 2930]
20 BADNAME Duplicate key name [RPF 2930]
21 BADALG Algorithm not supported [RPF 2930]
22 - 3,840
0x0016 - 0x0F00 Available for assignment
3,841 - 4,095
0x0F01 - 0x0FFF Private Use
4,096 - 65,534
0x1000 - 0xFFFE Available for assignment
65,535
0xFFFF Reserved, can only be allocated by an IETF
Standards Action.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS IANA Considerations August 2005
Since it is important that RCODEs be understood for interoperability,
assignment of new RCODE listed above as "available for assignment"
requires an IETF Consensus.
3. DNS Resource Records
All RRs have the same top level format shown in the figure below
taken from [RFC 1035]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this
resource record pertains. NAMEs are specific to a CLASS as described
in section 3.2. NAMEs consist of an ordered sequence of one or more
labels each of which has a label type [RFC 1035, 2671].
TYPE is a two octet unsigned integer containing one of the RR TYPE
codes. See section 3.1.
CLASS is a two octet unsigned integer containing one of the RR CLASS
codes. See section 3.2.
TTL is a four octet (32 bit) bit unsigned integer that specifies the
number of seconds that the resource record may be cached before the
source of the information should again be consulted. Zero is
interpreted to mean that the RR can only be used for the transaction
in progress.
RDLENGTH is an unsigned 16 bit integer that specifies the length in
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS IANA Considerations August 2005
octets of the RDATA field.
RDATA is a variable length string of octets that constitutes the
resource. The format of this information varies according to the TYPE
and in some cases the CLASS of the resource record.
3.1 RR TYPE IANA Considerations
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
and MetaTYPEs.
Data TYPEs are the primary means of storing data. QTYPES can only be
used in queries. Meta-TYPEs designate transient data associated with
an particular DNS message and in some cases can also be used in
queries. Thus far, data TYPEs have been assigned from 1 upwards plus
the block from 100 through 103 while Q and Meta Types have been
assigned from 255 downwards except for the OPT Meta-RR which is
assigned TYPE 41. There have been DNS implementations which made
caching decisions based on the top bit of the bottom byte of the RR
TYPE.
There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
[RFC 2845], and TKEY [RFC 2930].
There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
AXFR, and IXFR.
Considerations for the allocation of new RR TYPEs are as follows:
Decimal
Hexadecimal
0
0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
2535] and in other circumstances and must never be allocated
for ordinary use.
1 - 127
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
TYPEs by the DNS TYPE Allocation Policy as specified in
section 3.1.1.
128 - 255
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs by the DNS TYPE Allocation Policy as specified in
section 3.1.1.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DNS IANA Considerations August 2005
256 - 32,767
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
TYPE Allocation Policy as specified in section 3.1.1.
32,768 - 65,279
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
65,280 - 65534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
3.1.1 DNS TYPE Allocation Policy
Parameter values specified above as assigned based on DNS TYPE
Allocation Policy. That is, Expert Review with the additional
requirement that the review be based on a complete template as
specified below which has been posted for three weeks to the
namedroppers@ops.ietf.org mailing list.
Partial or draft templates may be posted with the intend of
soliciting feedback.
DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
Date:
Name and email of originator:
Pointer to internet-draft or other document giving a detailed
description of the protocol use of the new RR Type:
What need is the new RR TYPE intended to fix?
What existing RR TYPE(s) come closest to filling that need and why are
they unsatisfactory?
Does the proposed RR TYPR require special handling within the DNS
different from an Unknown RR TYPE?
Comments:
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT DNS IANA Considerations August 2005
3.1.2 Special Note on the OPT RR
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
primary purpose is to extend the effective field size of various DNS
fields including RCODE, label type, OpCode, flag bits, and RDATA
size. In particular, for resolvers and servers that recognize it, it
extends the RCODE field from 4 to 12 bits.
3.1.3 The AFSDB RR Subtype Field
The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
RDATA field structure as the MX RR but the 16 bit unsigned integer
field at the beginning of the RDATA is interpreted as a subtype as
follows:
Decimal
Hexadecimal
0
0x0000 - Allocation requires IETF Standards Action.
1
0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
2
0x0002 - DCE/NCA root cell directory node [RFC 1183].
3 - 65,279
0x0003 - 0xFEFF - Allocation by IETF Consensus.
65,280 - 65,534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, allocation requires IETF Standards Action.
3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the name space or root servers for one CLASS and
those for another CLASS. The same name can have completely different
meanings in different CLASSes; however, the label types are the same
and the null label is usable only as root in every CLASS. However,
as global networking and DNS have evolved, the IN, or Internet, CLASS
has dominated DNS use.
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT DNS IANA Considerations August 2005
There are two subcategories of DNS CLASSes: normal data containing
classes and QCLASSes that are only meaningful in queries or updates.
The current CLASS assignments and considerations for future
assignments are as follows:
Decimal
Hexadecimal
0
0x0000 - Reserved, assignment requires an IETF Standards Action.
1
0x0001 - Internet (IN).
2
0x0002 - Available for assignment by IETF Consensus as a data CLASS.
3
0x0003 - Chaos (CH) [Moon 1981].
4
0x0004 - Hesiod (HS) [Dyer 1987].
5 - 127
0x0005 - 0x007F - available for assignment by IETF Consensus for data
CLASSes only.
128 - 253
0x0080 - 0x00FD - available for assignment by IETF Consensus for
QCLASSes only.
254
0x00FE - QCLASS None [RFC 2136].
255
0x00FF - QCLASS Any [RFC 1035].
256 - 32,767
0x0100 - 0x7FFF - Assigned by IETF Consensus.
32,768 - 65,279
0x8000 - 0xFEFF - Assigned based on Specification Required as defined
in [RFC 2434].
65,280 - 65,534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
D. Eastlake 3rd [Page 10]
INTERNET-DRAFT DNS IANA Considerations August 2005
3.3 RR NAME Considerations
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
NAME is "ROOT" which is the zero length label. By definition, the
null or ROOT label can not be used for any other NAME purpose.
At the present time, there are two categories of label types, data
labels and compression labels. Compression labels are pointers to
data labels elsewhere within an RR or DNS message and are intended to
shorten the wire encoding of NAMEs. The two existing data label
types are sometimes referred to as Text and Binary. Text labels can,
in fact, include any octet value including zero value octets but most
current uses involve only [US-ASCII]. For retrieval, Text labels are
defined to treat ASCII upper and lower case letter codes as matching
[insensitive]. Binary labels are bit sequences [RFC 2673]. The
Binary label type is Experimental [RFC 3363].
IANA considerations for label types are given in [RFC 2671].
NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
1981] CLASSes are essentially for local use. The IN or Internet
CLASS is thus the only DNS CLASS in global use on the Internet at
this time.
A somewhat out-of-date description of name allocation in the IN Class
is given in [RFC 1591]. Some information on reserved top level
domain names is in BCP 32 [RFC 2606].
4. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 4033, 4034, 4035] for
secure DNS considerations.
D. Eastlake 3rd [Page 11]
INTERNET-DRAFT DNS IANA Considerations August 2005
Appendix: Changes from RFC 2929
RFC Editor: This Appendix should be deleted for publication.
Changes from RFC 2929 to this draft:
1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
Allocation Policy" and add the specification of that policy. Change
some remaining "IETF Standards Action" allocation requirements to say
"as modified by [RFC 4020]".
2. Updated various RFC references.
3. Mentioned that the Binary label type is now Experimental and
IQuery is Obsolete.
4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
IETF Standards Action required.
5. Add an IANA allocation policy for the AFSDB RR Subtype field.
6. Addition of reference to case insensitive draft.
D. Eastlake 3rd [Page 12]
INTERNET-DRAFT DNS IANA Considerations August 2005
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.
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.
Normative References
[RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
[RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
D. Eastlake 3rd [Page 13]
INTERNET-DRAFT DNS IANA Considerations August 2005
[RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", September 2000.
[RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
2002.
[RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York, 1968.
Informative References
[Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
Technical Plan - Name Service, April 1987,
[Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June
1981.
[RFC 1591] - Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
September 2000.
[RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", RFC 2606, June 1999.
[insensitive] - Eastlake, D., "Domain Name System (DNS) Case
D. Eastlake 3rd [Page 14]
INTERNET-DRAFT DNS IANA Considerations August 2005
Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
work in progress.
D. Eastlake 3rd [Page 15]
INTERNET-DRAFT DNS IANA Considerations August 2005
Authors Addresses
Donald E. Eastlake 3rd
Motorola Laboratories
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 February 2006.
Its file name is draft-ietf-dnsext-2929bis-01.txt.
D. Eastlake 3rd [Page 16]

442
doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
View File

@ -1,442 +0,0 @@
INTERNET-DRAFT Samuel Weiler
Expires: June 2004 December 15, 2003
Updates: RFC 2535, [DS]
Legacy Resolver Compatibility for Delegation Signer
draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
Status of this Memo
This document is an Internet-Draft and is subject to 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Comments should be sent to the author or to the DNSEXT WG mailing
list: namedroppers@ops.ietf.org
Abstract
As the DNS Security (DNSSEC) specifications have evolved, the
syntax and semantics of the DNSSEC resource records (RRs) have
changed. Many deployed nameservers understand variants of these
semantics. Dangerous interactions can occur when a resolver that
understands an earlier version of these semantics queries an
authoritative server that understands the new delegation signer
semantics, including at least one failure scenario that will cause
an unsecured zone to be unresolvable. This document changes the
type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
avoid those interactions.
Changes between 05 and 06:
Signifigantly reworked the IANA section -- went back to one
algorithm registry.
Removed Diffie-Hellman from the list of zone-signing algorithms
(leaving only DSA, RSA/SHA-1, and private algorithms).
Added a DNSKEY flags field registry.
Changes between 04 and 05:
IESG approved publication.
Cleaned up an internal reference in the acknowledgements section.
Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference.
Changed the names of both new registries. Added algorithm
mnemonics to the new zone signing algorithm registry. Minor
rewording in the IANA section for clarity.
Cleaned up formatting of references. Replaced unknown-rr draft
references with RFC3597. Bumped DS version number.
Changes between 03 and 04:
Clarified that RRSIG(0) may be defined by standards action.
Created a new algorithm registry and renamed the old algorithm
registry for SIG(0) only. Added references to the appropriate
crypto algorithm and format specifications.
Several minor rephrasings.
Changes between 02 and 03:
KEY (as well as SIG) retained for SIG(0) use only.
Changes between 01 and 02:
SIG(0) still uses SIG, not RRSIG. Added 2931 reference.
Domain names embedded in NSECs and RRSIGs are not compressible and
are not downcased. Added unknown-rrs reference (as informative).
Simplified the last paragraph of section 3 (NSEC doesn't always
signal a negative answer).
Changed the suggested type code assignments.
Added 2119 reference.
Added definitions of "unsecure delegation" and "unsecure referral",
since they're not clearly defined elsewhere.
Moved 2065 to informative references, not normative.
1. Introduction
The DNSSEC protocol has been through many iterations whose syntax
and semantics are not completely compatible. This has occurred as
part of the ordinary process of proposing a protocol, implementing
it, testing it in the increasingly complex and diverse environment
of the Internet, and refining the definitions of the initial
Proposed Standard. In the case of DNSSEC, the process has been
complicated by DNS's criticality and wide deployment and the need
to add security while minimizing daily operational complexity.
A weak area for previous DNS specifications has been lack of detail
in specifying resolver behavior, leaving implementors largely on
their own to determine many details of resolver function. This,
combined with the number of iterations the DNSSEC spec has been
through, has resulted in fielded code with a wide variety of
behaviors. This variety makes it difficult to predict how a
protocol change will be handled by all deployed resolvers. The
risk that a change will cause unacceptable or even catastrophic
failures makes it difficult to design and deploy a protocol change.
One strategy for managing that risk is to structure protocol
changes so that existing resolvers can completely ignore input that
might confuse them or trigger undesirable failure modes.
This document addresses a specific problem caused by Delegation
Signer's [DS] introduction of new semantics for the NXT RR that are
incompatible with the semantics in RFC 2535 [RFC2535]. Answers
provided by DS-aware servers can trigger an unacceptable failure
mode in some resolvers that implement RFC 2535, which provides a
great disincentive to sign zones with DS. The changes defined in
this document allow for the incremental deployment of DS.
1.1 Terminology
In this document, the term "unsecure delegation" means any
delegation for which no DS record appears at the parent. An
"unsecure referral" is an answer from the parent containing an NS
RRset and a proof that no DS record exists for that name.
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 The Problem
Delegation Signer introduces new semantics for the NXT RR that are
incompatible with the semantics in RFC 2535. In RFC 2535, NXT
records were only required to be returned as part of a
non-existence proof. With DS, an unsecure referral returns, in
addition to the NS, a proof of non-existence of a DS RR in the form
of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was
to interpret a response with both an NS and an NXT in the authority
section, RCODE=0, and AA=0. Some widely deployed 2535-aware
resolvers interpret any answer with an NXT as a proof of
non-existence of the requested record. This results in unsecure
delegations being invisible to 2535-aware resolvers and violates
the basic architectural principle that DNSSEC must do no harm --
the signing of zones must not prevent the resolution of unsecured
delegations.
2. Possible Solutions
This section presents several solutions that were considered.
Section 3 describes the one selected.
2.1. Change SIG, KEY, and NXT type codes
To avoid the problem described above, legacy (RFC2535-aware)
resolvers need to be kept from seeing unsecure referrals that
include NXT records in the authority section. The simplest way to
do that is to change the type codes for SIG, KEY, and NXT.
The obvious drawback to this is that new resolvers will not be able
to validate zones signed with the old RRs. This problem already
exists, however, because of the changes made by DS, and resolvers
that understand the old RRs (and have compatibility issues with DS)
are far more prevalent than 2535-signed zones.
2.2. Change a subset of type codes
The observed problem with unsecure referrals could be addressed by
changing only the NXT type code or another subset of the type codes
that includes NXT. This has the virtue of apparent simplicity, but
it risks introducing new problems or not going far enough. It's
quite possible that more incompatibilities exist between DS and
earlier semantics. Legacy resolvers may also be confused by seeing
records they recognize (SIG and KEY) while being unable to find
NXTs. Although it may seem unnecessary to fix that which is not
obviously broken, it's far cleaner to change all of the type codes
at once. This will leave legacy resolvers and tools completely
blinded to DNSSEC -- they will see only unknown RRs.
2.3. Replace the DO bit
Another way to keep legacy resolvers from ever seeing DNSSEC
records with DS semantics is to have authoritative servers only
send that data to DS-aware resolvers. It's been proposed that
assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
called "DA"), and having authoritative servers send DNSSEC data
only in response to queries with the DA bit set, would accomplish
this. This bit would presumably supplant the DO bit described in
RFC 3225.
This solution is sufficient only if all 2535-aware resolvers zero
out EDNS0 flags that they don't understand. If one passed through
the DA bit unchanged, it would still see the new semantics, and it
would probably fail to see unsecure delegations. Since it's
impractical to know how every DNS implementation handles unknown
EDNS0 flags, this is not a universal solution. It could, though,
be considered in addition to changing the RR type codes.
2.4. Increment the EDNS version
Another possible solution is to increment the EDNS version number
as defined in RFC 2671 [RFC2671], on the assumption that all
existing implementations will reject higher versions than they
support, and retain the DO bit as the signal for DNSSEC awareness.
This approach has not been tested.
2.5. Do nothing
There is a large deployed base of DNS resolvers that understand
DNSSEC as defined by the standards track RFC 2535 and RFC 2065
and, due to under specification in those documents, interpret any
answer with an NXT as a non-existence proof. So long as that is
the case, zone owners will have a strong incentive to not sign any
zones that contain unsecure delegations, lest those delegations be
invisible to such a large installed base. This will dramatically
slow DNSSEC adoption.
Unfortunately, without signed zones there's no clear incentive for
operators of resolvers to upgrade their software to support the new
version of DNSSEC, as defined in [DS]. Historical data suggests
that resolvers are rarely upgraded, and that old nameserver code
never dies.
Rather than wait years for resolvers to be upgraded through natural
processes before signing zones with unsecure delegations,
addressing this problem with a protocol change will immediately
remove the disincentive for signing zones and allow widespread
deployment of DNSSEC.
3. Protocol changes
This document changes the type codes of SIG, KEY, and NXT. This
approach is the cleanest and safest of those discussed above,
largely because the behavior of resolvers that receive unknown type
codes is well understood. This approach has also received the most
testing.
To avoid operational confusion, it's also necessary to change the
mnemonics for these RRs. DNSKEY will be the replacement for KEY,
with the mnemonic indicating that these keys are not for
application use, per [RFC3445]. RRSIG (Resource Record SIGnature)
will replace SIG, and NSEC (Next SECure) will replace NXT. These
new types completely replace the old types, except that SIG(0)
[RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
The new types will have exactly the same syntax and semantics as
specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
the following:
1) Consistent with [RFC3597], domain names embedded in
RRSIG and NSEC RRs MUST NOT be compressed,
2) Embedded domain names in RRSIG and NSEC RRs are not downcased
for purposes of DNSSEC canonical form and ordering nor for
equality comparison, and
3) An RRSIG with a type-covered field of zero has undefined
semantics. The meaning of such a resource record may only be
defined by IETF Standards Action.
If a resolver receives the old types, it SHOULD treat them as
unknown RRs and SHOULD NOT assign any special meaning to them or
give them any special treatment. It MUST NOT use them for DNSSEC
validations or other DNS operational decision making. For example,
a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone,
they MUST NOT receive special treatment. As an example, if a SIG
is included in a signed zone, there MUST be an RRSIG for it.
Authoritative servers may wish to give error messages when loading
zones containing SIG or NXT records (KEY records may be included
for SIG(0) or TKEY).
As a clarification to previous documents, some positive responses,
particularly wildcard proofs and unsecure referrals, will contain
NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as
negative answers merely because they contain an NSEC.
4. IANA Considerations
4.1 DNS Resource Record Types
This document updates the IANA registry for DNS Resource Record
Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
DNSKEY RRs, respectively.
Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
TKEY [RFC2930] use only.
Type 30 (NXT) should be marked as Obsolete.
4.2 DNS Security Algorithm Numbers
To allow zone signing (DNSSEC) and transaction security mechanisms
(SIG(0) and TKEY) to use different sets of algorithms, the existing
"DNS Security Algorithm Numbers" registry is modified to include
the applicability of each algorithm. Specifically, two new columns
are added to the registry, showing whether each algorithm may be
used for zone signing, transaction security mechanisms, or both.
Only algorithms usable for zone signing may be used in DNSKEY,
RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG
may be used in SIG and KEY RRs.
All currently defined algorithms remain usable for transaction
security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private
algorithms (types 253 and 254) may be used for zone signing. Note
that the registry does not contain the requirement level of each
algorithm, only whether or not an algorithm may be used for the
given purposes. For example, RSA/MD5, while allowed for
transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
Additionally, the presentation format algorithm mnemonics from
RFC2535 Section 7 are added to the registry. This document assigns
RSA/SHA-1 the mnemonic RSASHA1.
As before, assignment of new algorithms in this registry requires
IETF Standards Action. Additionally, modification of algorithm
mnemonics or applicability requires IETF Standards Action.
Documents defining a new algorithm must address the applicability
of the algorithm and should assign a presentation mnemonic to the
algorithm.
4.3 DNSKEY Flags
Like the KEY resource record, DNSKEY contains a 16-bit flags field.
This document creates a new registry for the DNSKEY flags field.
Initially, this registry only contains an assignment for bit 7 (the
ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF
Standards Action.
4.4 DNSKEY Protocol Octet
Like the KEY resource record, DNSKEY contains an eight bit protocol
field. The only defined value for this field is 3 (DNSSEC). No
other values are allowed, hence no IANA registry is needed for this
field.
5. Security Considerations
The changes introduced here do not materially affect security.
The implications of trying to use both new and legacy types
together are not well understood, and attempts to do so would
probably lead to unintended and dangerous results.
Changing type codes will leave code paths in legacy resolvers that
are never exercised. Unexercised code paths are a frequent source
of security holes, largely because those code paths do not get
frequent scrutiny.
Doing nothing, as described in section 2.5, will slow DNSSEC
deployment. While this does not decrease security, it also fails
to increase it.
6. Normative references
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[DS] Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-15.txt, work in
progress, June 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s)", RFC 2931, September 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
System (DNS)", RFC 2436, March 1999.
[RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
Domain Name System (DNS)", RFC 3110, May 2001.
7. Informative References
[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001.
[RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42,
RFC 2929, September 2000.
[RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
Record (RR) Types", RFC 3597, September 2003.
8. Acknowledgments
The changes introduced here and the analysis of alternatives had
many contributors. With apologies to anyone overlooked, those
include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
Lewis, Bill Manning, and Suzanne Woolf.
Thanks to Jakob Schlyter and Mark Andrews for identifying the
incompatibility described in section 1.2.
In addition to the above, the author would like to thank Scott
Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
comments.
9. Author's Address
Samuel Weiler
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
USA
weiler@tislabs.com

616
doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
View File

@ -1,616 +0,0 @@
Network Working Group S. Weiler
Internet-Draft SPARTA, Inc
Updates: 4034, 4035 (if approved) J. Ihren
Expires: July 24, 2006 Autonomica AB
January 20, 2006
Minimally Covering NSEC Records and DNSSEC On-line Signing
draft-ietf-dnsext-dnssec-online-signing-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 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes how to construct DNSSEC NSEC resource records
that cover a smaller range of names than called for by RFC4034. By
generating and signing these records on demand, authoritative name
servers can effectively stop the disclosure of zone contents
otherwise made possible by walking the chain of NSEC records in a
signed zone.
Weiler & Ihren Expires July 24, 2006 [Page 1]
Internet-Draft NSEC Epsilon January 2006
Changes from ietf-01 to ietf-02
Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
and NSEC bits set, to be consistent with DNSSECbis -- previous text
said SHOULD.
Made the applicability statement a little less oppressive.
Changes from ietf-00 to ietf-01
Added an applicability statement, making reference to ongoing work on
NSEC3.
Added the phrase "epsilon functions", which has been commonly used to
describe the technique and already appeared in the header of each
page, in place of "increment and decrement functions". Also added an
explanatory sentence.
Corrected references from 4034 section 6.2 to section 6.1.
Fixed an out-of-date reference to [-bis] and other typos.
Replaced IANA Considerations text.
Escaped close parentheses in examples.
Added some more acknowledgements.
Changes from weiler-01 to ietf-00
Inserted RFC numbers for 4033, 4034, and 4035.
Specified contents of bitmap field in synthesized NSEC RR's, pointing
out that this relaxes a constraint in 4035. Added 4035 to the
Updates header.
Changes from weiler-00 to weiler-01
Clarified that this updates RFC4034 by relaxing requirements on the
next name field.
Added examples covering wildcard names.
In the 'better functions' section, reiterated that perfect functions
aren't needed.
Added a reference to RFC 2119.
Weiler & Ihren Expires July 24, 2006 [Page 2]
Internet-Draft NSEC Epsilon January 2006
Table of Contents
1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
2. Applicability of This Technique . . . . . . . . . . . . . . . 4
3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5
4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Weiler & Ihren Expires July 24, 2006 [Page 3]
Internet-Draft NSEC Epsilon January 2006
1. Introduction and Terminology
With DNSSEC [1], an NSEC record lists the next instantiated name in
its zone, proving that no names exist in the "span" between the
NSEC's owner name and the name in the "next name" field. In this
document, an NSEC record is said to "cover" the names between its
owner name and next name.
Through repeated queries that return NSEC records, it is possible to
retrieve all of the names in the zone, a process commonly called
"walking" the zone. Some zone owners have policies forbidding zone
transfers by arbitrary clients; this side-effect of the NSEC
architecture subverts those policies.
This document presents a way to prevent zone walking by constructing
NSEC records that cover fewer names. These records can make zone
walking take approximately as many queries as simply asking for all
possible names in a zone, making zone walking impractical. Some of
these records must be created and signed on demand, which requires
on-line private keys. Anyone contemplating use of this technique is
strongly encouraged to review the discussion of the risks of on-line
signing in Section 6.
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. Applicability of This Technique
The technique presented here may be useful to a zone owner that wants
to use DNSSEC, is concerned about exposure of its zone contents via
zone walking, and is willing to bear the costs of on-line signing.
As discussed in Section 6, on-line signing has several security
risks, including an increased likelihood of private keys being
disclosed and an increased risk of denial of service attack. Anyone
contemplating use of this technique is strongly encouraged to review
the discussion of the risks of on-line signing in Section 6.
Furthermore, at the time this document was published, the DNSEXT
working group was actively working on a mechanism to prevent zone
walking that does not require on-line signing (tentatively called
NSEC3). The new mechanism is likely to expose slightly more
information about the zone than this technique (e.g. the number of
instantiated names), but it may be preferable to this technique.
Weiler & Ihren Expires July 24, 2006 [Page 4]
Internet-Draft NSEC Epsilon January 2006
3. Minimally Covering NSEC Records
This mechanism involves changes to NSEC records for instantiated
names, which can still be generated and signed in advance, as well as
the on-demand generation and signing of new NSEC records whenever a
name must be proven not to exist.
In the 'next name' field of instantiated names' NSEC records, rather
than list the next instantiated name in the zone, list any name that
falls lexically after the NSEC's owner name and before the next
instantiated name in the zone, according to the ordering function in
RFC4034 [2] section 6.1. This relaxes the requirement in section
4.1.1 of RFC4034 that the 'next name' field contains the next owner
name in the zone. This change is expected to be fully compatible
with all existing DNSSEC validators. These NSEC records are returned
whenever proving something specifically about the owner name (e.g.
that no resource records of a given type appear at that name).
Whenever an NSEC record is needed to prove the non-existence of a
name, a new NSEC record is dynamically produced and signed. The new
NSEC record has an owner name lexically before the QNAME but
lexically following any existing name and a 'next name' lexically
following the QNAME but before any existing name.
The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
bits set and SHOULD NOT have any other bits set. 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.
The functions to generate the lexically following and proceeding
names need not be perfect nor consistent, but the generated NSEC
records must not cover any existing names. Furthermore, this
technique works best when the generated NSEC records cover as few
names as possible. In this document, the functions that generate the
nearby names are called 'epsilon' functions, a reference to the
mathematical convention of using the greek letter epsilon to
represent small deviations.
An NSEC record denying the existence of a wildcard may be generated
in the same way. Since the NSEC record covering a non-existent
wildcard is likely to be used in response to many queries,
authoritative name servers using the techniques described here may
want to pregenerate or cache that record and its corresponding RRSIG.
For example, a query for an A record at the non-instantiated name
example.com might produce the following two NSEC records, the first
denying the existence of the name example.com and the second denying
the existence of a wildcard:
Weiler & Ihren Expires July 24, 2006 [Page 5]
Internet-Draft NSEC Epsilon January 2006
exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
\).com 3600 IN NSEC +.com ( RRSIG NSEC )
Before answering a query with these records, an authoritative server
must test for the existence of names between these endpoints. If the
generated NSEC would cover existing names (e.g. exampldd.com or
*bizarre.example.com), a better epsilon function may be used or the
covered name closest to the QNAME could be used as the NSEC owner
name or next name, as appropriate. If an existing name is used as
the NSEC owner name, that name's real NSEC record MUST be returned.
Using the same example, assuming an exampldd.com delegation exists,
this record might be returned from the parent:
exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
Like every authoritative record in the zone, each generated NSEC
record MUST have corresponding RRSIGs generated using each algorithm
(but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
described in RFC4035 [3] section 2.2. To minimize the number of
signatures that must be generated, a zone may wish to limit the
number of algorithms in its DNSKEY RRset.
4. Better Epsilon Functions
Section 6.1 of RFC4034 defines a strict ordering of DNS names.
Working backwards from that definition, it should be possible to
define epsilon functions that generate the immediately following and
preceding names, respectively. This document does not define such
functions. Instead, this section presents functions that come
reasonably close to the perfect ones. As described above, an
authoritative server should still ensure than no generated NSEC
covers any existing name.
To increment a name, add a leading label with a single null (zero-
value) octet.
To decrement a name, decrement the last character of the leftmost
label, then fill that label to a length of 63 octets with octets of
value 255. To decrement a null (zero-value) octet, remove the octet
-- if an empty label is left, remove the label. Defining this
function numerically: fill the left-most label to its maximum length
with zeros (numeric, not ASCII zeros) and subtract one.
In response to a query for the non-existent name foo.example.com,
these functions produce NSEC records of:
Weiler & Ihren Expires July 24, 2006 [Page 6]
Internet-Draft NSEC Epsilon January 2006
fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
\)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
The first of these NSEC RRs proves that no exact match for
foo.example.com exists, and the second proves that there is no
wildcard in example.com.
Both of these functions are imperfect: they don't take into account
constraints on number of labels in a name nor total length of a name.
As noted in the previous section, though, this technique does not
depend on the use of perfect epsilon functions: it is sufficient to
test whether any instantiated names fall into the span covered by the
generated NSEC and, if so, substitute those instantiated owner names
for the NSEC owner name or next name, as appropriate.
5. IANA Considerations
This document specifies no IANA Actions.
6. Security Considerations
This approach requires on-demand generation of RRSIG records. This
creates several new vulnerabilities.
First, on-demand signing requires that a zone's authoritative servers
have access to its private keys. Storing private keys on well-known
internet-accessible servers may make them more vulnerable to
unintended disclosure.
Second, since generation of digital signatures tends to be
computationally demanding, the requirement for on-demand signing
makes authoritative servers vulnerable to a denial of service attack.
Lastly, if the epsilon functions are predictable, on-demand signing
may enable a chosen-plaintext attack on a zone's private keys. Zones
using this approach should attempt to use cryptographic algorithms
that are resistant to chosen-plaintext attacks. It's worth noting
Weiler & Ihren Expires July 24, 2006 [Page 7]
Internet-Draft NSEC Epsilon January 2006
that while DNSSEC has a "mandatory to implement" algorithm, that is a
requirement on resolvers and validators -- there is no requirement
that a zone be signed with any given algorithm.
The success of using minimally covering NSEC record to prevent zone
walking depends greatly on the quality of the epsilon functions
chosen. An increment function that chooses a name obviously derived
from the next instantiated name may be easily reverse engineered,
destroying the value of this technique. An increment function that
always returns a name close to the next instantiated name is likewise
a poor choice. Good choices of epsilon functions are the ones that
produce the immediately following and preceding names, respectively,
though zone administrators may wish to use less perfect functions
that return more human-friendly names than the functions described in
Section 4 above.
Another obvious but misguided concern is the danger from synthesized
NSEC records being replayed. It's possible for an attacker to replay
an old but still validly signed NSEC record after a new name has been
added in the span covered by that NSEC, incorrectly proving that
there is no record at that name. This danger exists with DNSSEC as
defined in [3]. The techniques described here actually decrease the
danger, since the span covered by any NSEC record is smaller than
before. Choosing better epsilon functions will further reduce this
danger.
7. 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Appendix A. Acknowledgments
Many individuals contributed to this design. They include, in
addition to the authors of this document, Olaf Kolkman, Ed Lewis,
Weiler & Ihren Expires July 24, 2006 [Page 8]
Internet-Draft NSEC Epsilon January 2006
Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
Jakob Schlyter, Bill Manning, and Joao Damas.
In addition, the editors would like to thank Ed Lewis, Scott Rose,
and David Blacka for their careful review of the document.
Weiler & Ihren Expires July 24, 2006 [Page 9]
Internet-Draft NSEC Epsilon January 2006
Authors' Addresses
Samuel Weiler
SPARTA, Inc
7075 Samuel Morse Drive
Columbia, Maryland 21046
US
Email: weiler@tislabs.com
Johan Ihren
Autonomica AB
Bellmansgatan 30
Stockholm SE-118 47
Sweden
Email: johani@autonomica.se
Weiler & Ihren Expires July 24, 2006 [Page 10]
Internet-Draft NSEC Epsilon 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.
Weiler & Ihren Expires July 24, 2006 [Page 11]

839
doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
View File

@ -1,839 +0,0 @@
DNS Extensions Working Group R. Arends
Internet-Draft Telematica Instituut
Expires: August 25, 2005 P. Koch
DENIC eG
J. Schlyter
NIC-SE
February 21, 2005
Evaluating DNSSEC Transition Mechanisms
draft-ietf-dnsext-dnssec-trans-02.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document collects and summarizes different proposals for
alternative and additional strategies for authenticated denial in DNS
responses, evaluates these proposals and gives a recommendation for a
Arends, et al. Expires August 25, 2005 [Page 1]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
way forward.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3
2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4
2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4
2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5
2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6
2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6
2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7
2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8
2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9
2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9
2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10
2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11
2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Normative References . . . . . . . . . . . . . . . . . . . 13
5.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Arends, et al. Expires August 25, 2005 [Page 2]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
1. Introduction
This report shall document the process of dealing with the NSEC
walking problem late in the Last Call for
[I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion
that took place in the DNSEXT WG during the first half of June 2004
as well as some additional ideas that came up subsequently.
This is an edited excerpt of the chairs' mail to the WG:
The working group consents on not including NSEC-alt in the
DNSSEC-bis documents. The working group considers to take up
"prevention of zone enumeration" as a work item.
There may be multiple mechanisms to allow for co-existence with
DNSSEC-bis. The chairs allow the working group a little over a
week (up to June 12, 2004) to come to consensus on a possible
modification to the document to enable gentle rollover. If that
consensus cannot be reached the DNSSEC-bis documents will go out
as-is.
To ease the process of getting consensus, a summary of the proposed
solutions and analysis of the pros and cons were written during the
weekend.
This summary includes:
An inventory of the proposed mechanisms to make a transition to
future work on authenticated denial of existence.
List the known Pros and Cons, possibly provide new arguments, and
possible security considerations of these mechanisms.
Provide a recommendation on a way forward that is least disruptive
to the DNSSEC-bis specifications as they stand and keep an open
path to other methods for authenticated denial of existence.
The descriptions of the proposals in this document are coarse and do
not cover every detail necessary for implementation. In any case,
documentation and further study is needed before implementaion and/or
deployment, including those which seem to be solely operational in
nature.
2. Transition Mechanisms
In the light of recent discussions and past proposals, we have found
several ways to allow for transition to future expansion of
authenticated denial. We tried to illuminate the paths and pitfalls
in these ways forward. Some proposals lead to a versioning of
DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
proposals are 'clean' but may cause delay, while again others may be
Arends, et al. Expires August 25, 2005 [Page 3]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
plain hacks.
Some paths do not introduce versioning, and might require the current
DNSSEC-bis documents to be fully updated to allow for extensions to
authenticated denial mechanisms. Other paths introduce versioning
and do not (or minimally) require DNSSEC-bis documents to be updated,
allowing DNSSEC-bis to be deployed, while future versions can be
drafted independent from or partially depending on DNSSEC-bis.
2.1 Mechanisms With Need of Updating DNSSEC-bis
Mechanisms in this category demand updates to the DNSSEC-bis document
set.
2.1.1 Dynamic NSEC Synthesis
This proposal assumes that NSEC RRs and the authenticating RRSIG will
be generated dynamically to just cover the (non existent) query name.
The owner name is (the) one preceding the name queried for, the Next
Owner Name Field has the value of the Query Name Field + 1 (first
successor in canonical ordering). A separate key (the normal ZSK or
a separate ZSK per authoritative server) would be used for RRSIGs on
NSEC RRs. This is a defense against enumeration, though it has the
presumption of online signing.
2.1.1.1 Coexistence and Migration
There is no change in interpretation other then that the next owner
name might or might not exist.
2.1.1.2 Limitations
This introduces an unbalanced cost between query and response
generation due to dynamic generation of signatures.
2.1.1.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents might need to be updated to indicate
that the next owner name might not be an existing name in the zone.
This is not a real change to the spec since implementers have been
warned not to synthesize with previously cached NSEC records. A
specific bit to identify the dynamic signature generating key might
be useful as well, to prevent it from being used to fake positive
data.
2.1.1.4 Cons
Unbalanced cost is a ground for DDoS. Though this protects against
Arends, et al. Expires August 25, 2005 [Page 4]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
enumeration, it is not really a path for versioning.
2.1.1.5 Pros
Hardly any amendments to DNSSEC-bis.
2.1.2 Add Versioning/Subtyping to Current NSEC
This proposal introduces versioning for the NSEC RR type (a.k.a.
subtyping) by adding a (one octet) version field to the NSEC RDATA.
Version number 0 is assigned to the current (DNSSEC-bis) meaning,
making this an 'Must Be Zero' (MBZ) for the to be published docset.
2.1.2.1 Coexistence and Migration
Since the versioning is done inside the NSEC RR, different versions
may coexist. However, depending on future methods, that may or may
not be useful inside a single zone. Resolvers cannot ask for
specific NSEC versions but may be able to indicate version support by
means of a to be defined EDNS option bit.
2.1.2.2 Limitations
There are no technical limitations, though it will cause delay to
allow testing of the (currently unknown) new NSEC interpretation.
Since the versioning and signaling is done inside the NSEC RR, future
methods will likely be restricted to a single RR type authenticated
denial (as opposed to e.g. NSEC-alt, which currently proposes three
RR types).
2.1.2.3 Amendments to DNSSEC-bis
Full Update of the current DNSSEC-bis documents to provide for new
fields in NSEC, while specifying behavior in case of unknown field
values.
2.1.2.4 Cons
Though this is a clean and clear path without versioning DNSSEC, it
takes some time to design, gain consensus, update the current
dnssec-bis document, test and implement a new authenticated denial
record.
2.1.2.5 Pros
Does not introduce an iteration to DNSSEC while providing a clear and
clean migration strategy.
Arends, et al. Expires August 25, 2005 [Page 5]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.3 Type Bit Map NSEC Indicator
Bits in the type-bit-map are reused or allocated to signify the
interpretation of NSEC.
This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of
the RDATA or introduce an alternative denial mechanism, invoked by
the specific type-bit-map-bits.
2.1.3.1 Coexistence and migration
Old and new NSEC meaning could coexist, depending how the signaling
would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR
types are available as well as those covering meta/query types or
types to be specifically allocated.
2.1.3.2 Limitations
This mechanism uses an NSEC field that was not designed for that
purpose. Similar methods were discussed during the Opt-In discussion
and the Silly-State discussion.
2.1.3.3 Amendments to DNSSEC-bis
The specific type-bit-map-bits must be allocated and they need to be
specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
interpretation. Also, behaviour of the resolver and validator must
be documented in case unknown values are encountered for the MBZ
field. Currently the protocol document specifies that the validator
MUST ignore the setting of the NSEC and the RRSIG bits, while other
bits are only used for the specific purpose of the type-bit-map field
2.1.3.4 Cons
The type-bit-map was not designed for this purpose. It is a
straightforward hack. Text in protocol section 5.4 was put in
specially to defend against this usage.
2.1.3.5 Pros
No change needed to the on-the-wire protocol as specified in the
current docset.
2.1.4 New Apex Type
This introduces a new Apex type (parallel to the zone's SOA)
indicating the DNSSEC version (or authenticated denial) used in or
Arends, et al. Expires August 25, 2005 [Page 6]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
for this zone.
2.1.4.1 Coexistence and Migration
Depending on the design of this new RR type multiple denial
mechanisms may coexist in a zone. Old validators will not understand
and thus ignore the new type, so interpretation of the new NSEC
scheme may fail, negative responses may appear 'bogus'.
2.1.4.2 Limitations
A record of this kind is likely to carry additional
feature/versioning indications unrelated to the current question of
authenticated denial.
2.1.4.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that
the absence of this type indicates dnssec-bis, and that the (mere)
presence of this type indicated unknown versions.
2.1.4.4 Cons
The only other 'zone' or 'apex' record is the SOA record. Though
this proposal is not new, it is yet unknown how it might fulfill
authenticated denial extensions. This new RR type would only provide
for a generalized signaling mechanism, not the new authenticated
denial scheme. Since it is likely to be general in nature, due to
this generality consensus is not to be reached soon.
2.1.4.5 Pros
This approach would allow for a lot of other per zone information to
be transported or signaled to both (slave) servers and resolvers.
2.1.5 NSEC White Lies
This proposal disables one part of NSEC (the pointer part) by means
of a special target (root, apex, owner, ...), leaving intact only the
ability to authenticate denial of existence of RR sets, not denial of
existence of domain names (NXDOMAIN). It may be necessary to have
one working NSEC to prove the absence of a wildcard.
2.1.5.1 Coexistence and Migration
The NSEC target can be specified per RR, so standard NSEC and 'white
lie' NSEC can coexist in a zone. There is no need for migration
because no versioning is introduced or intended.
Arends, et al. Expires August 25, 2005 [Page 7]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.5.2 Limitations
This proposal breaks the protocol and is applicable to certain types
of zones only (no wildcard, no deep names, delegation only). Most of
the burden is put on the resolver side and operational consequences
are yet to be studied.
2.1.5.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that
the NXDOMAIN responses may be insecure.
2.1.5.4 Cons
Strictly speaking this breaks the protocol and doesn't fully fulfill
the requirements for authenticated denial of existence. Security
implications need to be carefully documented: search path problems
(forged denial of existence may lead to wrong expansion of non-FQDNs
[RFC1535]) and replay attacks to deny existence of records.
2.1.5.5 Pros
Hardly any amendments to DNSSEC-bis. Operational "trick" that is
available anyway.
2.1.6 NSEC Optional via DNSSKEY Flag
A new DNSKEY may be defined to declare NSEC optional per zone.
2.1.6.1 Coexistence and Migration
Current resolvers/validators will not understand the Flag bit and
will have to treat negative responses as bogus. Otherwise, no
migration path is needed since NSEC is simply turned off.
2.1.6.2 Limitations
NSEC can only be made completely optional at the cost of being unable
to prove unsecure delegations (absence of a DS RR [RFC3658]). A next
to this approach would just disable authenticated denial for
non-existence of nodes.
2.1.6.3 Amendments to DNSSEC-bis
New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to
be specified in the light of absence of authenticated denial.
Arends, et al. Expires August 25, 2005 [Page 8]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.6.4 Cons
Doesn't fully meet requirements. Operational consequences to be
studied.
2.1.6.5 Pros
Official version of the "trick" presented in (8). Operational
problems can be addressed during future work on validators.
2.1.7 New Answer Pseudo RR Type
A new pseudo RR type may be defined that will be dynamically created
(and signed) by the responding authoritative server. The RR in the
response will cover the QNAME, QCLASS and QTYPE and will authenticate
both denial of existence of name (NXDOMAIN) or RRset.
2.1.7.1 Coexistence and Migration
Current resolvers/validators will not understand the pseudo RR and
will thus not be able to process negative responses so testified. A
signaling or solicitation method would have to be specified.
2.1.7.2 Limitations
This method can only be used with online keys and online signing
capacity.
2.1.7.3 Amendments to DNSSEC-bis
Signaling method needs to be defined.
2.1.7.4 Cons
Keys have to be held and processed online with all security
implications. An additional flag for those keys identifying them as
online or negative answer only keys should be considered.
2.1.7.5 Pros
Expands DNSSEC authentication to the RCODE.
2.1.8 SIG(0) Based Authenticated Denial
2.1.8.1 Coexistence and Migration
Arends, et al. Expires August 25, 2005 [Page 9]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.8.2 Limitations
2.1.8.3 Amendments to DNSSEC-bis
2.1.8.4 Cons
2.1.8.5 Pros
2.2 Mechanisms Without Need of Updating DNSSEC-bis
2.2.1 Partial Type-code and Signal Rollover
Carefully crafted type code/signal rollover to define a new
authenticated denial space that extends/replaces DNSSEC-bis
authenticated denial space. This particular path is illuminated by
Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
posted to <namedroppers@ops.ietf.org> 2004-06-02.
2.2.1.1 Coexistence and Migration
To protect the current resolver for future versions, a new DNSSEC-OK
bit must be allocated to make clear it does or does not understand
the future version. Also, a new DS type needs to be allocated to
allow differentiation between a current signed delegation and a
'future' signed delegation. Also, current NSEC needs to be rolled
into a new authenticated denial type.
2.2.1.2 Limitations
None.
2.2.1.3 Amendments to DNSSEC-bis
None.
2.2.1.4 Cons
It is cumbersome to carefully craft an TCR that 'just fits'. The
DNSSEC-bis protocol has many 'borderline' cases that needs special
consideration. It might be easier to do a full TCR, since a few of
the types and signals need upgrading anyway.
Arends, et al. Expires August 25, 2005 [Page 10]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.2.1.5 Pros
Graceful adoption of future versions of NSEC, while there are no
amendments to DNSSEC-bis.
2.2.2 A Complete Type-code and Signal Rollover
A new DNSSEC space is defined which can exist independent of current
DNSSEC-bis space.
This proposal assumes that all current DNSSEC type-codes
(RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
future versions of DNSSEC. Any future version of DNSSEC has its own
types to allow for keys, signatures, authenticated denial, etcetera.
2.2.2.1 Coexistence and Migration
Both spaces can co-exist. They can be made completely orthogonal.
2.2.2.2 Limitations
None.
2.2.2.3 Amendments to DNSSEC-bis
None.
2.2.2.4 Cons
With this path we abandon the current DNSSEC-bis. Though it is easy
to role specific well-known and well-tested parts into the re-write,
once deployment has started this path is very expensive for
implementers, registries, registrars and registrants as well as
resolvers/users. A TCR is not to be expected to occur frequently, so
while a next generation authenticated denial may be enabled by a TCR,
it is likely that that TCR will only be agreed upon if it serves a
whole basket of changes or additions. A quick introduction of
NSEC-ng should not be expected from this path.
2.2.2.5 Pros
No amendments/changes to current DNSSEC-bis docset needed. It is
always there as last resort.
2.2.3 Unknown Algorithm in RRSIG
This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of
Arends, et al. Expires August 25, 2005 [Page 11]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
the RDATA or introduce an alternative denial mechanism, invoked by
the specific unknown signing algorithm. The different interpretation
would be signaled by use of different signature algorithms in the
RRSIG records covering the NSEC RRs.
When an entire zone is signed with a single unknown algorithm, it
will cause implementations that follow current dnssec-bis documents
to treat individual RRsets as unsigned.
2.2.3.1 Coexistence and migration
Old and new NSEC RDATA interpretation or known and unknown Signatures
can NOT coexist in a zone since signatures cover complete (NSEC)
RRSets.
2.2.3.2 Limitations
Validating resolvers agnostic of new interpretation will treat the
NSEC RRset as "not signed". This affects wildcard and non-existence
proof, as well as proof for (un)secured delegations. Also, all
positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
insecure/bogus to an old validator.
The algorithm version space is split for each future version of
DNSSEC. Violation of the 'modular components' concept. We use the
'validator' to protect the 'resolver' from unknown interpretations.
2.2.3.3 Amendments to DNSSEC-bis
None.
2.2.3.4 Cons
The algorithm field was not designed for this purpose. This is a
straightforward hack.
2.2.3.5 Pros
No amendments/changes to current DNSSEC-bis docset needed.
3. Recommendation
The authors recommend that the working group commits to and starts
work on a partial TCR, allowing graceful transition towards a future
version of NSEC. Meanwhile, to accomodate the need for an
immediately, temporary, solution against zone-traversal, we recommend
On-Demand NSEC synthesis.
Arends, et al. Expires August 25, 2005 [Page 12]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
This approach does not require any mandatory changes to DNSSEC-bis,
does not violate the protocol and fulfills the requirements. As a
side effect, it moves the cost of implementation and deployment to
the users (zone owners) of this mechanism.
4. Acknowledgements
The authors would like to thank Sam Weiler and Mark Andrews for their
input and constructive comments.
5. References
5.1 Normative References
[I-D.ietf-dnsext-dnssec-intro]
Arends, R., Austein, R., Massey, D., Larson, M. and S.
Rose, "DNS Security Introduction and Requirements",
Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
2004.
[I-D.ietf-dnsext-dnssec-protocol]
Arends, R., "Protocol Modifications for the DNS Security
Extensions",
Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
October 2004.
[I-D.ietf-dnsext-dnssec-records]
Arends, R., "Resource Records for the DNS Security
Extensions",
Internet-Draft draft-ietf-dnsext-dnssec-records-11,
October 2004.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
5.2 Informative References
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535, October
1993.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
Arends, et al. Expires August 25, 2005 [Page 13]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
RFC 2535, March 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
Authors' Addresses
Roy Arends
Telematica Instituut
Brouwerijstraat 1
Enschede 7523 XC
The Netherlands
Phone: +31 53 4850485
Email: roy.arends@telin.nl
Peter Koch
DENIC eG
Wiesenh"uttenplatz 26
Frankfurt 60329
Germany
Phone: +49 69 27235 0
Email: pk@DENIC.DE
Jakob Schlyter
NIC-SE
Box 5774
Stockholm SE-114 87
Sweden
Email: jakob@nic.se
URI: http://www.nic.se/
Arends, et al. Expires August 25, 2005 [Page 14]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 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.
Arends, et al. Expires August 25, 2005 [Page 15]

504
doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
View File

@ -1,504 +0,0 @@
Network Working Group W. Hardaker
Internet-Draft Sparta
Expires: August 25, 2006 February 21, 2006
Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
draft-ietf-dnsext-ds-sha256-05.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 August 25, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies how to use the SHA-256 digest type in DNS
Delegation Signer (DS) Resource Records (RRs). DS records, when
stored in a parent zone, point to key signing DNSKEY key(s) in a
child zone.
Hardaker Expires August 25, 2006 [Page 1]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Implementing the SHA-256 algorithm for DS record support . . . 3
2.1. DS record field values . . . . . . . . . . . . . . . . . . 3
2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3
2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Hardaker Expires August 25, 2006 [Page 2]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
1. Introduction
The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
zones to distribute a cryptographic digest of a child's Key Signing
Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the
parent zone's private zone data signing keys for each algorithm in
use by the parent. Each signature is published in an RRSIG resource
record, owned by the same domain as the DS RRset and with a type
covered of DS.
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].
2. Implementing the SHA-256 algorithm for DS record support
This document specifies that the digest type code [XXX: To be
assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
[SHA256CODE] for use within DS records. The results of the digest
algorithm MUST NOT be truncated and the entire 32 byte digest result
is to be published in the DS record.
2.1. DS record field values
Using the SHA-256 digest algorithm within a DS record will make use
of the following DS-record fields:
Digest type: [XXX: To be assigned by IANA; likely 2]
Digest: A SHA-256 bit digest value calculated by using the following
formula ("|" denotes concatenation). The resulting value is not
truncated and the entire 32 byte result is to used in the
resulting DS record and related calculations.
digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
where DNSKEY RDATA is defined by [RFC4034] as:
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
The Key Tag field and Algorithm fields remain unchanged by this
document and are specified in the [RFC4034] specification.
2.2. DS Record with SHA-256 Wire Format
The resulting on-the-wire format for the resulting DS record will be
[XXX: IANA assignment should replace the 2 below]:
Hardaker Expires August 25, 2006 [Page 3]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
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 Tag | Algorithm | DigestType=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest (length for SHA-256 is 32 bytes) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
2.3. Example DS Record Using SHA-256
The following is an example DNSKEY and matching DS record. This
DNSKEY record comes from the example DNSKEY/DS records found in
section 5.4 of [RFC4034].
The DNSKEY record:
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
fwJr1AYtsmx3TGkJaNXVbfi/
2pHm822aJ5iI9BMzNXxeYCmZ
DRD99WYwYqUSdjMmmAphXdvx
egXd/M5+X7OrzKBaMbCVdFLU
Uh6DhweJBjEVv5f2wwjM9Xzc
nOf+EPbtG9DMBmADjFDc2w/r
ljwvFw==
) ; key id = 60485
The resulting DS record covering the above DNSKEY record using a SHA-
256 digest: [RFC Editor: please replace XXX with the assigned digest
type (likely 2):]
dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
CEB1E3E0614B93C4F9E99B83
83F6A1E4469DA50A )
3. Implementation Requirements
Implementations MUST support the use of the SHA-256 algorithm in DS
RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1
digests if DS RRs with SHA-256 digests are present in the DS RRset.
4. Deployment Considerations
If a validator does not support the SHA-256 digest type and no other
DS RR exists in a zone's DS RRset with a supported digest type, then
Hardaker Expires August 25, 2006 [Page 4]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
the validator 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 in [RFC4035], section 5.2.
Because zone administrators can not control the deployment speed of
support for SHA-256 in validators that may be referencing any of
their zones, zone operators should consider deploying both SHA-1 and
SHA-256 based DS records. This should be done for every DNSKEY for
which DS records are being generated. Whether to make use of both
digest types and for how long is a policy decision that extends
beyond the scope of this document.
5. IANA Considerations
Only one IANA action is required by this document:
The Digest Type to be used for supporting SHA-256 within DS records
needs to be assigned by IANA. This document requests that the Digest
Type value of 2 be assigned to the SHA-256 digest algorithm.
At the time of this writing, the current digest types assigned for
use in DS records are as follows:
VALUE Digest Type Status
0 Reserved -
1 SHA-1 MANDATORY
2 SHA-256 MANDATORY
3-255 Unassigned -
6. Security Considerations
6.1. Potential Digest Type Downgrade Attacks
A downgrade attack from a stronger digest type to a weaker one is
possible if all of the following are true:
o A zone includes multiple DS records for a given child's DNSKEY,
each of which use a different digest type.
o A validator accepts a weaker digest even if a stronger one is
present but invalid.
For example, if the following conditions are all true:
Hardaker Expires August 25, 2006 [Page 5]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
o Both SHA-1 and SHA-256 based digests are published in DS records
within a parent zone for a given child zone's DNSKEY.
o The DS record with the SHA-1 digest matches the digest computed
using the child zone's DNSKEY.
o The DS record with the SHA-256 digest fails to match the digest
computed using the child zone's DNSKEY.
Then if the validator accepts the above situation as secure then this
can be used as a downgrade attack since the stronger SHA-256 digest
is ignored.
6.2. SHA-1 vs SHA-256 Considerations for DS Records
Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
implementations allow for it. SHA-256 is widely believed to be more
resilient to attack than SHA-1, and confidence in SHA-1's strength is
being eroded by recently-announced attacks. Regardless of whether or
not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
time of this writing) that SHA-256 is the better choice for use in DS
records.
At the time of this publication, the SHA-256 digest algorithm is
considered sufficiently strong for the immediate future. It is also
considered sufficient for use in DNSSEC DS RRs for the immediate
future. However, future published attacks may weaken the usability
of this algorithm within the DS RRs. It is beyond the scope of this
document to speculate extensively on the cryptographic strength of
the SHA-256 digest algorithm.
Likewise, it is also beyond the scope of this document to specify
whether or for how long SHA-1 based DS records should be
simultaneously published alongside SHA-256 based DS records.
7. Acknowledgments
This document is a minor extension to the existing DNSSEC documents
and those authors are gratefully appreciated for the hard work that
went into the base documents.
The following people contributed to portions of this document in some
fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
Weiler.
Hardaker Expires August 25, 2006 [Page 6]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[SHA256] National Institute of Standards and Technology, "Secure
Hash Algorithm. NIST FIPS 180-2", August 2002.
8.2. Informative References
[SHA256CODE]
Eastlake, D., "US Secure Hash Algorithms (SHA)",
June 2005.
Hardaker Expires August 25, 2006 [Page 7]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
Author's Address
Wes Hardaker
Sparta
P.O. Box 382
Davis, CA 95617
US
Email: hardaker@tislabs.com
Hardaker Expires August 25, 2006 [Page 8]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs 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.
Hardaker Expires August 25, 2006 [Page 9]

17
doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt
View File

@ -1,17 +0,0 @@
This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted
from the Internet-Drafts directory. An Internet-Draft expires 185 days from
the date that it is posted unless it is replaced by an updated version, or the
Secretariat has been notified that the document is under official review by the
IESG or has been passed to the RFC Editor for review and/or publication as an
RFC. This Internet-Draft was not published as an RFC.
Internet-Drafts are not archival documents, and copies of Internet-Drafts that have
been deleted from the directory are not available. The Secretariat does not have
any information regarding the future plans of the author(s) or working group, if
applicable, with respect to this deleted Internet-Draft. For more information, or
to request a copy of the document, please contact the author(s) directly.
Draft Author(s):
Remco van Mook <remco@virtu.nl>,
Bert Hubert <bert.hubert@netherlabs.nl>

560
doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
View File

@ -1,560 +0,0 @@
DNS Extensions O. Kolkman
Internet-Draft RIPE NCC
Expires: June 17, 2004 J. Schlyter
E. Lewis
ARIN
December 18, 2003
DNSKEY RR Secure Entry Point Flag
draft-ietf-dnsext-keyrr-key-signing-flag-12
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.
This Internet-Draft will expire on June 17, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
With the Delegation Signer (DS) resource record the concept of a
public key acting as a secure entry point has been introduced. During
exchanges of public keys with the parent there is a need to
differentiate secure entry point keys from other public keys in the
DNSKEY resource record (RR) set. A flag bit in the DNSKEY RR is
defined to indicate that DNSKEY is to be used as a secure entry
point. The flag bit is intended to assist in operational procedures
to correctly generate DS resource records, or to indicate what
DNSKEYs are intended for static configuration. The flag bit is not to
Kolkman, et al. Expires June 17, 2004 [Page 1]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
be used in the DNS verification protocol. This document updates RFC
2535 and RFC 3445.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . . 4
3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 5
4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Internationalization Considerations . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
Normative References . . . . . . . . . . . . . . . . . . . . . . 7
Informative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . 9
Kolkman, et al. Expires June 17, 2004 [Page 2]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
1. Introduction
"All keys are equal but some keys are more equal than others" [6]
With the definition of the Delegation Signer Resource Record (DS RR)
[5] it has become important to differentiate between the keys in the
DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
other keys in the DNSKEY RR set. We refer to these public keys as
Secure Entry Point (SEP) keys. A SEP key either used to generate a
DS RR or is distributed to resolvers that use the key as the root of
a trusted subtree[3].
In early deployment tests, the use of two (kinds of) key pairs for
each zone has been prevalent. For one kind of key pair the private
key is used to sign just the zone's DNSKEY resource record (RR) set.
Its public key is intended to be referenced by a DS RR at the parent
or configured statically in a resolver. The private key of the other
kind of key pair is used to sign the rest of the zone's data sets.
The former key pair is called a key-signing key (KSK) and the latter
is called a zone-signing key (ZSK). In practice there have been
usually one of each kind of key pair, but there will be multiples of
each at times.
It should be noted that division of keys pairs into KSK's and ZSK's
is not mandatory in any definition of DNSSEC, not even with the
introduction of the DS RR. But, in testing, this distinction has
been helpful when designing key roll over (key super-cession)
schemes. Given that the distinction has proven helpful, the labels
KSK and ZSK have begun to stick.
There is a need to differentiate the public keys for the key pairs
that are used for key signing from keys that are not used key signing
(KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
be sent for generating DS RRs, which DNSKEYs are to be distributed to
resolvers, and which keys are fed to the signer application at the
appropriate time.
In other words, the SEP bit provides an in-band method to communicate
a DNSKEY RR's intended use to third parties. As an example we present
3 use cases in which the bit is useful:
The parent is a registry, the parent and the child use secured DNS
queries and responses, with a preexisting trust-relation, or plain
DNS over a secured channel to exchange the child's DNSKEY RR
sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset
the SEP bit can be used to isolate the DNSKEYs for which a DS RR
needs to be created.
Kolkman, et al. Expires June 17, 2004 [Page 3]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
An administrator has configured a DNSKEY as root for a trusted
subtree into security aware resolver. Using a special purpose tool
that queries for the KEY RRs from that domain's apex, the
administrator will be able to notice the roll over of the trusted
anchor by a change of the subset of KEY RRs with the DS flag set.
A signer might use the SEP bit on the public key to determine
which private key to use to exclusively sign the DNSKEY RRset and
which private key to use to sign the other RRsets in the zone.
As demonstrated in the above examples it is important to be able to
differentiate the SEP keys from the other keys in a DNSKEY RR set in
the flow between signer and (parental) key-collector and in the flow
between the signer and the resolver configuration. The SEP flag is to
be of no interest to the flow between the verifier and the
authoritative data store.
The reason for the term "SEP" is a result of the observation that the
distinction between KSK and ZSK key pairs is made by the signer, a
key pair could be used as both a KSK and a ZSK at the same time. To
be clear, the term SEP was coined to lessen the confusion caused by
the overlap. ( Once this label was applied, it had the side effect of
removing the temptation to have both a KSK flag bit and a ZSK flag
bit.)
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
interpreted as described in RFC2119 [1].
2. The Secure Entry Point (SEP) Flag
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |S| protocol | algorithm |
| |E| | |
| |P| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DNSKEY RR Format
Kolkman, et al. Expires June 17, 2004 [Page 4]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
This document assigns the 15'th bit in the flags field as the secure
entry point (SEP) bit. If the the bit is set to 1 the key is
intended to be used as secure entry point key. One SHOULD NOT assign
special meaning to the key if the bit is set to 0. Operators can
recognize the secure entry point key by the even or odd-ness of the
decimal representation of the flag field.
3. DNSSEC Protocol Changes
The bit MUST NOT be used during the resolving and verification
process. The SEP flag is only used to provide a hint about the
different administrative properties of the key and therefore the use
of the SEP flag does not change the DNS resolution protocol or the
resolution process.
4. Operational Guidelines
The SEP bit is set by the key-pair-generator and MAY be used by the
zone signer to decide whether the public part of the key pair is to
be prepared for input to a DS RR generation function. The SEP bit is
recommended to be set (to 1) whenever the public key of the key pair
will be distributed to the parent zone to build the authentication
chain or if the public key is to be distributed for static
configuration in verifiers.
When a key pair is created, the operator needs to indicate whether
the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within
the data that is used to compute the 'key tag field' in the SIG RR,
changing the SEP bit will change the identity of the key within DNS.
In other words, once a key is used to generate signatures, the
setting of the SEP bit is to remain constant. If not, a verifier will
not be able to find the relevant KEY RR.
When signing a zone, it is intended that the key(s) with the SEP bit
set (if such keys exist) are used to sign the KEY RR set of the zone.
The same key can be used to sign the rest of the zone data too. It
is conceivable that not all keys with a SEP bit set will sign the
DNSKEY RR set, such keys might be pending retirement or not yet in
use.
When verifying a RR set, the SEP bit is not intended to play a role.
How the key is used by the verifier is not intended to be a
consideration at key creation time.
Although the SEP flag provides a hint on which public key is to be
used as trusted root, administrators can choose to ignore the fact
that a DNSKEY has its SEP bit set or not when configuring a trusted
root for their resolvers.
Kolkman, et al. Expires June 17, 2004 [Page 5]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
Using the SEP flag a key roll over can be automated. The parent can
use an existing trust relation to verify DNSKEY RR sets in which a
new DNSKEY RR with the SEP flag appears.
5. Security Considerations
As stated in Section 3 the flag is not to be used in the resolution
protocol or to determine the security status of a key. The flag is to
be used for administrative purposes only.
No trust in a key should be inferred from this flag - trust MUST be
inferred from an existing chain of trust or an out-of-band exchange.
Since this flag might be used for automating public key exchanges, we
think the following consideration is in place.
Automated mechanisms for roll over of the DS RR might be vulnerable
to a class of replay attacks. This might happen after a public key
exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
SEP flag set, is sent to the parent. The parent verifies the DNSKEY
RR set with the existing trust relation and creates the new DS RR
from the DNSKEY RR that the current DS RR is not pointing to. This
key exchange might be replayed. Parents are encouraged to implement a
replay defense. A simple defense can be based on a registry of keys
that have been used to generate DS RRs during the most recent roll
over. These same considerations apply to entities that configure keys
in resolvers.
6. IANA Considerations
The flag bits in the DNSKEY RR are assigned by IETF consensus and
registered in the DNSKEY Flags registry (created by [4]). This
document assigns the 15th bit in the DNSKEY RR as the Secure Entry
Point (SEP) bit.
7. Internationalization Considerations
Although SEP is a popular acronym in many different languages, there
are no internationalization considerations.
8. Acknowledgments
The ideas documented in this document are inspired by communications
we had with numerous people and ideas published by other folk. Among
others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
have contributed ideas and provided feedback.
Kolkman, et al. Expires June 17, 2004 [Page 6]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
This document saw the light during a workshop on DNSSEC operations
hosted by USC/ISI in August 2002.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[3] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
[4] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
in progress), October 2003.
Informative References
[5] Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-15 (work in progress), June
2003.
[6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
Story", ISBN 0151002177 (50th anniversary edition), April 1996.
Authors' Addresses
Olaf M. Kolkman
RIPE NCC
Singel 256
Amsterdam 1016 AB
NL
Phone: +31 20 535 4444
EMail: olaf@ripe.net
URI: http://www.ripe.net/
Jakob Schlyter
Karl Gustavsgatan 15
Goteborg SE-411 25
Sweden
EMail: jakob@schlyter.se
Kolkman, et al. Expires June 17, 2004 [Page 7]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
Edward P. Lewis
ARIN
3635 Concorde Parkway Suite 200
Chantilly, VA 20151
US
Phone: +1 703 227 9854
EMail: edlewis@arin.net
URI: http://www.arin.net/
Kolkman, et al. Expires June 17, 2004 [Page 8]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 implementation 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 assignees.
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
Kolkman, et al. Expires June 17, 2004 [Page 9]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kolkman, et al. Expires June 17, 2004 [Page 10]

8
doc/rfc/index
View File

@ -92,6 +92,7 @@
Secret Key Transaction Authentication for DNS (GSS-TSIG)
3655: Redefinition of DNS Authenticated Data (AD) bit
3658: Delegation Signer (DS) Resource Record (RR)
3755: Legacy Resolver Compatibility for Delegation Signer (DS)
3757: Domain Name System KEY (DNSKEY) Resource Record (RR)
Secure Entry Point (SEP) Flag
3833: Threat Analysis of the Domain Name System (DNS)
@ -112,6 +113,7 @@
4408: Sender Policy Framework (SPF) for Authorizing Use of Domains
in E-Mail, Version 1
4470: Minimally Covering NSEC Records and DNSSEC On-line Signing
4471: Derivation of DNS Name Predecessor and Successor
4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
4634: US Secure Hash Algorithms (SHA and HMAC-SHA)
4635: HMAC SHA TSIG Algorithm Identifiers
@ -120,9 +122,15 @@
4701: A DNS Resource Record (RR) for Encoding
Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
4892: Requirements for a Mechanism Identifying a Name Server Instance
4955: DNS Security (DNSSEC) Experiments
4956: DNS Security (DNSSEC) Opt-In
5001: DNS Name Server Identifier (NSID) Option
5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors
5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extension
5395: Domain Name System (DNS) IANA Considerations
5452: Measures for Making DNS More Resilient against Forged Answers
5507: Design Choices When Expanding the DNS
5625: DNS Proxy Implementation Guidelines
5702: Use of SHA-2 Algorithms with RSA in
DNSKEY and RRSIG Resource Records for DNSSEC

507
doc/rfc/rfc3755.txt Normal file
View File

@ -0,0 +1,507 @@
Network Working Group S. Weiler
Request for Comments: 3755 SPARTA, Inc.
Updates: 3658, 2535 May 2004
Category: Standards Track
Legacy Resolver Compatibility for Delegation Signer (DS)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
As the DNS Security (DNSSEC) specifications have evolved, the syntax
and semantics of the DNSSEC resource records (RRs) have changed.
Many deployed nameservers understand variants of these semantics.
Dangerous interactions can occur when a resolver that understands an
earlier version of these semantics queries an authoritative server
that understands the new delegation signer semantics, including at
least one failure scenario that will cause an unsecured zone to be
unresolvable. This document changes the type codes and mnemonics of
the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions.
1. Introduction
The DNSSEC protocol has been through many iterations whose syntax and
semantics are not completely compatible. This has occurred as part
of the ordinary process of proposing a protocol, implementing it,
testing it in the increasingly complex and diverse environment of the
Internet, and refining the definitions of the initial Proposed
Standard. In the case of DNSSEC, the process has been complicated by
DNS's criticality and wide deployment and the need to add security
while minimizing daily operational complexity.
A weak area for previous DNS specifications has been lack of detail
in specifying resolver behavior, leaving implementors largely on
their own to determine many details of resolver function. This,
combined with the number of iterations the DNSSEC specifications have
been through, has resulted in fielded code with a wide variety of
Weiler Standards Track [Page 1]
RFC 3755 Legacy Resolver Compatibility for DS May 2004
behaviors. This variety makes it difficult to predict how a protocol
change will be handled by all deployed resolvers. The risk that a
change will cause unacceptable or even catastrophic failures makes it
difficult to design and deploy a protocol change. One strategy for
managing that risk is to structure protocol changes so that existing
resolvers can completely ignore input that might confuse them or
trigger undesirable failure modes.
This document addresses a specific problem caused by Delegation
Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR
that are incompatible with the semantics in [RFC2535]. Answers
provided by DS-aware servers can trigger an unacceptable failure mode
in some resolvers that implement RFC 2535, which provides a great
disincentive to sign zones with DS. The changes defined in this
document allow for the incremental deployment of DS.
1.1. Terminology
In this document, the term "unsecure delegation" means any delegation
for which no DS record appears at the parent. An "unsecure referral"
is an answer from the parent containing an NS RRset and a proof that
no DS record exists for that name.
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. The Problem
Delegation Signer (DS) introduces new semantics for the NXT RR that
are incompatible with the semantics in RFC 2535. In RFC 2535, NXT
records were only required to be returned as part of a non-existence
proof. With DS, an unsecure referral returns, in addition to the NS,
a proof of non-existence of a DS RR in the form of an NXT and
SIG(NXT). RFC 2535 didn't specify how a resolver was to interpret a
response with RCODE=0, AA=0, and both an NS and an NXT in the
authority section. Some widely deployed 2535-aware resolvers
interpret any answer with an NXT as a proof of non-existence of the
requested record. This results in unsecure delegations being
invisible to 2535-aware resolvers and violates the basic
architectural principle that DNSSEC must do no harm -- the signing of
zones must not prevent the resolution of unsecured delegations.
2. Possible Solutions
This section presents several solutions that were considered.
Section 3 describes the one selected.
Weiler Standards Track [Page 2]
RFC 3755 Legacy Resolver Compatibility for DS May 2004
2.1. Change SIG, KEY, and NXT type codes
To avoid the problem described above, legacy (RFC2535-aware)
resolvers need to be kept from seeing unsecure referrals that include
NXT records in the authority section. The simplest way to do that is
to change the type codes for SIG, KEY, and NXT.
The obvious drawback to this is that new resolvers will not be able
to validate zones signed with the old RRs. This problem already
exists, however, because of the changes made by DS, and resolvers
that understand the old RRs (and have compatibility issues with DS)
are far more prevalent than 2535-signed zones.
2.2. Change a subset of type codes
The observed problem with unsecure referrals could be addressed by
changing only the NXT type code or another subset of the type codes
that includes NXT. This has the virtue of apparent simplicity, but
it risks introducing new problems or not going far enough. It's
quite possible that more incompatibilities exist between DS and
earlier semantics. Legacy resolvers may also be confused by seeing
records they recognize (SIG and KEY) while being unable to find NXTs.
Although it may seem unnecessary to fix that which is not obviously
broken, it's far cleaner to change all of the type codes at once.
This will leave legacy resolvers and tools completely blinded to
DNSSEC -- they will see only unknown RRs.
2.3. Replace the DO bit
Another way to keep legacy resolvers from ever seeing DNSSEC records
with DS semantics is to have authoritative servers only send that
data to DS-aware resolvers. It's been proposed that assigning a new
EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), and
having authoritative servers send DNSSEC data only in response to
queries with the DA bit set, would accomplish this. This bit would
presumably supplant the DO bit described in [RFC3225].
This solution is sufficient only if all 2535-aware resolvers zero out
EDNS0 flags that they don't understand. If one passed through the DA
bit unchanged, it would still see the new semantics, and it would
probably fail to see unsecure delegations. Since it's impractical to
know how every DNS implementation handles unknown EDNS0 flags, this
is not a universal solution. It could, though, be considered in
addition to changing the RR type codes.
Weiler Standards Track [Page 3]
RFC 3755 Legacy Resolver Compatibility for DS May 2004
2.4. Increment the EDNS version
Another possible solution is to increment the EDNS version number as
defined in [RFC2671], on the assumption that all existing
implementations will reject higher versions than they support, and
retain the DO bit as the signal for DNSSEC awareness. This approach
has not been tested.
2.5. Do nothing
There is a large deployed base of DNS resolvers that understand
DNSSEC as defined by the standards track RFC 2535 and [RFC2065] and,
due to under specification in those documents, interpret any answer
with an NXT as a non-existence proof. So long as that is the case,
zone owners will have a strong incentive to not sign any zones that
contain unsecure delegations, lest those delegations be invisible to
such a large installed base. This will dramatically slow DNSSEC
adoption.
Unfortunately, without signed zones there's no clear incentive for
operators of resolvers to upgrade their software to support the new
version of DNSSEC, as defined in RFC 3658. Historical data suggests
that resolvers are rarely upgraded, and that old nameserver code
never dies.
Rather than wait years for resolvers to be upgraded through natural
processes before signing zones with unsecure delegations, addressing
this problem with a protocol change will immediately remove the
disincentive for signing zones and allow widespread deployment of
DNSSEC.
3. Protocol changes
This document changes the type codes of SIG, KEY, and NXT. This
approach is the cleanest and safest of those discussed above, largely
because the behavior of resolvers that receive unknown type codes is
well understood. This approach has also received the most testing.
To avoid operational confusion, it's also necessary to change the
mnemonics for these RRs. DNSKEY will be the replacement for KEY,
with the mnemonic indicating that these keys are not for application
use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace
SIG, and NSEC (Next SECure) will replace NXT. These new types
completely replace the old types, except that SIG(0) [RFC2931] and
TKEY [RFC2930] will continue to use SIG and KEY.
Weiler Standards Track [Page 4]
RFC 3755 Legacy Resolver Compatibility for DS May 2004
The new types will have exactly the same syntax and semantics as
specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for
the following:
1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC
RRs MUST NOT be compressed,
2) Embedded domain names in RRSIG and NSEC RRs are not downcased for
purposes of DNSSEC canonical form and ordering nor for equality
comparison, and
3) An RRSIG with a type-covered field of zero has undefined
semantics. The meaning of such a resource record may only be
defined by IETF Standards Action.
If a resolver receives the old types, it SHOULD treat them as unknown
RRs and SHOULD NOT assign any special meaning to them or give them
any special treatment. It MUST NOT use them for DNSSEC validations
or other DNS operational decision making. For example, a resolver
MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs.
If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive
special treatment. As an example, if a SIG is included in a signed
zone, there MUST be an RRSIG for it. Authoritative servers may wish
to give error messages when loading zones containing SIG or NXT
records (KEY records may be included for SIG(0) or TKEY).
As a clarification to previous documents, some positive responses,
particularly wildcard proofs and unsecure referrals, will contain
NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as negative
answers merely because they contain an NSEC.
4. IANA Considerations
4.1. DNS Resource Record Types
This document updates the IANA registry for DNS Resource Record Types
by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs,
respectively.
Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
TKEY [RFC2930] use only.
Type 30 (NXT) should be marked as Obsolete.
Weiler Standards Track [Page 5]
RFC 3755 Legacy Resolver Compatibility for DS May 2004
4.2. DNS Security Algorithm Numbers
To allow zone signing (DNSSEC) and transaction security mechanisms
(SIG(0) and TKEY) to use different sets of algorithms, the existing
"DNS Security Algorithm Numbers" registry is modified to include the
applicability of each algorithm. Specifically, two new columns are
added to the registry, showing whether each algorithm may be used for
zone signing, transaction security mechanisms, or both. Only
algorithms usable for zone signing may be used in DNSKEY, RRSIG, and
DS RRs. Only algorithms usable for SIG(0) and/or TSIG may be used in
SIG and KEY RRs.
All currently defined algorithms except for Indirect (algorithm 252)
remain usable for transaction security mechanisms. Only RSA/SHA-1
[RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and
254) may be used for zone signing. Note that the registry does not
contain the requirement level of each algorithm, only whether or not
an algorithm may be used for the given purposes. For example,
RSA/MD5, while allowed for transaction security mechanisms, is NOT
RECOMMENDED, per [RFC3110].
Additionally, the presentation format algorithm mnemonics from
[RFC2535] Section 7 are added to the registry. This document assigns
RSA/SHA-1 the mnemonic RSASHA1.
As before, assignment of new algorithms in this registry requires
IETF Standards Action. Additionally, modification of algorithm
mnemonics or applicability requires IETF Standards Action. Documents
defining a new algorithm must address the applicability of the
algorithm and should assign a presentation mnemonic to the algorithm.
4.3. DNSKEY Flags
Like the KEY resource record, DNSKEY contains a 16-bit flags field.
This document creates a new registry for the DNSKEY flags field.
Initially, this registry only contains an assignment for bit 7 (the
ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF
Standards Action.
4.4. DNSKEY Protocol Octet
Like the KEY resource record, DNSKEY contains an eight bit protocol
field. The only defined value for this field is 3 (DNSSEC). No
other values are allowed, hence no IANA registry is needed for this
field.
Weiler Standards Track [Page 6]
RFC 3755 Legacy Resolver Compatibility for DS May 2004
5. Security Considerations
The changes introduced here do not materially affect security. The
implications of trying to use both new and legacy types together are
not well understood, and attempts to do so would probably lead to
unintended and dangerous results.
Changing type codes will leave code paths in legacy resolvers that
are never exercised. Unexercised code paths are a frequent source of
security holes, largely because those code paths do not get frequent
scrutiny.
Doing nothing, as described in section 2.5, will slow DNSSEC
deployment. While this does not decrease security, it also fails to
increase it.
6. References
6.1. 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.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
RFC 2930, September 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s)", RFC 2931, September 2000.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
Weiler Standards Track [Page 7]
RFC 3755 Legacy Resolver Compatibility for DS May 2004
6.2. Informative References
[RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
Security Extensions", RFC 2065, January 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001.
[RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
7. Acknowledgments
The changes introduced here and the analysis of alternatives had many
contributors. With apologies to anyone overlooked, those include:
Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis,
Bill Manning, Paul Vixie, and Suzanne Woolf.
Thanks to Jakob Schlyter and Mark Andrews for identifying the
incompatibility described in section 1.2.
In addition to the above, the author would like to thank Scott Rose,
Olafur Gudmundsson, and Sandra Murphy for their substantive comments.
8. Author's Address
Samuel Weiler
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
USA
EMail: weiler@tislabs.com
Weiler Standards Track [Page 8]
RFC 3755 Legacy Resolver Compatibility for DS May 2004
9. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weiler Standards Track [Page 9]

876
doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt → doc/rfc/rfc4471.txt
View File

File diff suppressed because it is too large Load Diff

671
doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt → doc/rfc/rfc4955.txt
View File

@ -1,85 +1,48 @@
DNSEXT D. Blacka
Internet-Draft VeriSign, Inc.
Intended status: Standards Track April 7, 2006
Expires: October 9, 2006
DNSSEC Experiments
draft-ietf-dnsext-dnssec-experiments-03
Status of this Memo
Network Working Group D. Blacka
Request for Comments: 4955 VeriSign, Inc.
Category: Standards Track July 2007
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.
DNS Security (DNSSEC) Experiments
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."
Status of This Memo
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 October 9, 2006.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Blacka Expires October 9, 2006 [Page 1]
Internet-Draft DNSSEC Experiments April 2006
Copyright (C) The IETF Trust (2007).
Abstract
This document describes a methodology for deploying alternate, non-
backwards-compatible, DNSSEC methodologies in an experimental fashion
without disrupting the deployment of standard DNSSEC.
backwards-compatible, DNS Security (DNSSEC) methodologies in an
experimental fashion without disrupting the deployment of standard
DNSSEC.
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. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Terminology . . . . . . . . . . . . . . . . . . 2
3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 4
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
@ -92,84 +55,12 @@ Table of Contents
Blacka Expires October 9, 2006 [Page 2]
Blacka Standards Track [Page 1]
Internet-Draft DNSSEC Experiments April 2006
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
1. Definitions and Terminology
Throughout this document, familiarity with the DNS system (RFC 1035
[5]) and the DNS security extensions ([2], [3], and [4] is assumed.
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 [1].
Blacka Expires October 9, 2006 [Page 3]
Internet-Draft DNSSEC Experiments April 2006
2. Overview
1. Overview
Historically, experimentation with DNSSEC alternatives has been a
problematic endeavor. There has typically been a desire to both
@ -180,50 +71,20 @@ Internet-Draft DNSSEC Experiments April 2006
aware resolvers.
This document describes a standard methodology for setting up DNSSEC
experiments. This methodology addresses the issue of co-existence
experiments. This methodology addresses the issue of coexistence
with standard DNSSEC and DNS by using unknown algorithm identifiers
to hide the experimental DNSSEC protocol modifications from standard
security-aware resolvers.
2. Definitions and Terminology
Throughout this document, familiarity with the DNS system (RFC 1035
[5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and
RFC 4035 [4]) is assumed.
Blacka Expires October 9, 2006 [Page 4]
Internet-Draft DNSSEC Experiments April 2006
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 [1].
3. Experiments
@ -250,35 +111,9 @@ Internet-Draft DNSSEC Experiments April 2006
Blacka Expires October 9, 2006 [Page 5]
Blacka Standards Track [Page 2]
Internet-Draft DNSSEC Experiments April 2006
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
4. Method
@ -290,7 +125,7 @@ Internet-Draft DNSSEC Experiments April 2006
This technique works because of the way DNSSEC-compliant validators
are expected to work in the presence of a DS set with only unknown
algorithm identifiers. From [4], Section 5.2:
algorithm identifiers. From RFC 4035 [4], 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
@ -306,21 +141,36 @@ Internet-Draft DNSSEC Experiments April 2006
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 likely that a validator would implement this behavior, or, more to
the point, it would handle this situation in a safe way (see below
(Section 6).)
Although this behavior isn't strictly mandatory (as marked by MUST),
it is unlikely for a validator to implement a substantially different
behavior. Essentially, if the validator does not have a usable chain
of trust to a child zone, then it can only do one of two things:
treat responses from the zone as insecure (the recommended behavior),
or treat the responses as bogus. If the validator chooses the
latter, this will both violate the expectation of the zone owner and
defeat the purpose of the above rule. However, with local policy, it
is within the right of a validator to refuse to trust certain zones
based on any criteria, including the use of unknown signing
algorithms.
Because we are talking about experiments, it is RECOMMENDED that
private algorithm numbers be used (see [3], appendix A.1.1. Note
that secure handling of private algorithms requires special handing
by the validator logic. See [6] for further 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 suggested that all optional defined algorithms be
aliased as well.
private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1.
Note that secure handling of private algorithms requires special
handing by the validator logic. See "Clarifications and
Implementation Notes for DNSSECbis" [6] for further 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 suggested that all optional defined
algorithms be aliased as well.
Blacka Standards Track [Page 3]
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
It is RECOMMENDED that for a particular DNSSEC experiment, a
particular domain name base is chosen for all new algorithms, then
@ -329,14 +179,6 @@ Internet-Draft DNSSEC Experiments April 2006
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
Blacka Expires October 9, 2006 [Page 6]
Internet-Draft DNSSEC Experiments April 2006
will suffice.
Using this method, resolvers (or, more specifically, DNSSEC
@ -352,51 +194,13 @@ Internet-Draft DNSSEC Experiments April 2006
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 is
not.
Blacka Expires October 9, 2006 [Page 7]
Internet-Draft DNSSEC Experiments April 2006
either in an experiment and only possible to validate experimentally,
or it is not.
5. Defining an Experiment
The DNSSEC experiment MUST define the particular set of (previously
unknown) algorithm identifiers that identify the experiment, and
unknown) algorithm identifiers 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
@ -407,9 +211,9 @@ Internet-Draft DNSSEC Experiments April 2006
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.
Object Identifier (OID) private algorithm space instead (using
algorithm number 254), or MAY choose non-private algorithm numbers,
although this would require an IANA allocation.
For example, an experiment might specify in its description the DNS
name "dnssec-experiment-a.example.com" as the base name, and declare
@ -417,6 +221,13 @@ Internet-Draft DNSSEC Experiments April 2006
algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
alias of DNSSEC algorithm 5 (RSASHA1).
Blacka Standards Track [Page 4]
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
Resolvers MUST only recognize the experiment's semantics when present
in a zone signed by one or more of these algorithm identifiers. This
is necessary to isolate the semantics of one experiment from any
@ -426,85 +237,21 @@ Internet-Draft DNSSEC Experiments April 2006
understand both standard DNSSEC and the defined experimental DNSSEC
protocol, although this isn't required.
Blacka Expires October 9, 2006 [Page 8]
Internet-Draft DNSSEC Experiments April 2006
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 a non-validatable response and conclude
that the response is bogus, either due to local policy or
implementation details. This is not expected to be a common
case, however.
1. If an unaware validator does not correctly follow the rules laid
out in RFC 4035 (e.g., the validator interprets a DNSSEC record
prior to validating it), or if the experiment is broader in scope
that just modifying the DNSSEC semantics, the experiment may not
be sufficiently masked by this technique. This may cause
unintended resolution failures.
2. It will not be possible for security-aware resolvers unaware of
the experiment to build a chain of trust through an experimental
zone.
Blacka Expires October 9, 2006 [Page 9]
Internet-Draft DNSSEC Experiments April 2006
7. Use in Non-Experiments
This general methodology MAY be used for non-backwards compatible
@ -519,48 +266,6 @@ Internet-Draft DNSSEC Experiments April 2006
o Resolvers MAY recognize the protocol change in zones not signed
(or not solely signed) using the new algorithm identifiers.
Blacka Expires October 9, 2006 [Page 10]
Internet-Draft DNSSEC Experiments April 2006
8. Security Considerations
Zones using this methodology will be considered insecure by all
@ -568,114 +273,24 @@ Internet-Draft DNSSEC Experiments April 2006
possible to create a secure delegation from an experimental zone that
will be followed by resolvers unaware of the experiment.
Implementers should take into account any security issues that may
result from environments being configured to trust both experimental
and non-experimental zones. If the experimental zone is more
Blacka Expires October 9, 2006 [Page 11]
Blacka Standards Track [Page 5]
Internet-Draft DNSSEC Experiments April 2006
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
9. IANA Considerations
vulnerable to attacks, it could, for example, be used to promote
trust in zones not part of the experiment, possibly under the control
of an attacker.
This document has no IANA actions.
9. References
Blacka Expires October 9, 2006 [Page 12]
Internet-Draft DNSSEC Experiments April 2006
10. References
10.1. Normative References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
@ -692,42 +307,13 @@ Internet-Draft DNSSEC Experiments April 2006
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
10.2. Informative References
9.2. Informative References
[5] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[6] Austein, R. and S. Weiler, "Clarifications and Implementation
Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
(work in progress), January 2006.
Blacka Expires October 9, 2006 [Page 13]
Internet-Draft DNSSEC Experiments April 2006
[6] Weiler, S. and R. Austein, "Clarifications and Implementation
Notes for DNSSECbis", Work in Progress, March 2007.
Author's Address
@ -738,7 +324,7 @@ Author's Address
US
Phone: +1 703 948 3200
Email: davidb@verisign.com
EMail: davidb@verisign.com
URI: http://www.verisignlabs.com
@ -749,45 +335,14 @@ Author's Address
Blacka Expires October 9, 2006 [Page 14]
Blacka Standards Track [Page 6]
Internet-Draft DNSSEC Experiments April 2006
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
Full Copyright Statement
Copyright (C) The Internet Society (2006).
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
@ -795,13 +350,12 @@ Full Copyright Statement
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
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
@ -826,15 +380,16 @@ Intellectual Property
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Funding for the RFC Editor function is currently provided by the
Internet Society.
Blacka Expires October 9, 2006 [Page 15]
Blacka Standards Track [Page 7]

845
doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt → doc/rfc/rfc4956.txt
View File

File diff suppressed because it is too large Load Diff

647
doc/draft/draft-ietf-dnsext-nsid-01.txt → doc/rfc/rfc5001.txt
View File

@ -1,42 +1,27 @@
Network Working Group R. Austein
Internet-Draft ISC
Expires: July 15, 2006 January 11, 2006
Request for Comments: 5001 ISC
Category: Standards Track August 2007
DNS Name Server Identifier Option (NSID)
draft-ietf-dnsext-nsid-01
DNS Name Server Identifier (NSID) Option
Status of this Memo
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 15, 2006.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The IETF Trust (2007).
Abstract
@ -44,74 +29,57 @@ Abstract
mechanisms allowing more than one DNS name server to share a single
IP address, it is sometimes difficult to tell which of a pool of name
servers has answered a particular query. While existing ad-hoc
mechanism allow an operator to send follow-up queries when it is
mechanisms allow an operator to send follow-up queries when it is
necessary to debug such a configuration, the only completely reliable
way to obtain the identity of the name server which responded is to
way to obtain the identity of the name server that responded is to
have the name server include this information in the response itself.
This note defines a protocol extension to support this functionality.
Austein Expires July 15, 2006 [Page 1]
Austein Standards Track [Page 1]
Internet-Draft DNS NSID January 2006
RFC 5001 DNS NSID August 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4
2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4
2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 3
2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 3
2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4
2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6
3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8
3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8
3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Austein Expires July 15, 2006 [Page 2]
Internet-Draft DNS NSID January 2006
2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 4
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 4
3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 7
3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 7
3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
1. Introduction
@ -131,10 +99,22 @@ Internet-Draft DNS NSID January 2006
Given that a DNS query is an idempotent operation with no retained
state, it would appear that the only completely reliable way to
obtain the identity of the name server which responded to a
particular query is to have that name server include identifying
information in the response itself. This note defines a protocol
enhancement to achieve this.
obtain the identity of the name server that responded to a particular
query is to have that name server include identifying information in
the response itself. This note defines a protocol enhancement to
achieve this.
Austein Standards Track [Page 2]
RFC 5001 DNS NSID August 2007
1.1. Reserved Words
@ -142,33 +122,6 @@ Internet-Draft DNS NSID January 2006
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Austein Expires July 15, 2006 [Page 3]
Internet-Draft DNS NSID January 2006
2. Protocol
This note uses an EDNS [RFC2671] option to signal the resolver's
@ -195,10 +148,10 @@ Internet-Draft DNS NSID January 2006
2.2. Name Server Behavior
A name server which understands the NSID option and chooses to honor
a particular NSID request responds by including identifying
information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR
in the response message.
A name server that understands the NSID option and chooses to honor a
particular NSID request responds by including identifying information
in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR in the
response message.
The name server MUST ignore any NSID payload data that might be
present in the query message.
@ -210,29 +163,31 @@ Internet-Draft DNS NSID January 2006
absence of the NSID option in the recursive name server's response to
the original client.
Austein Standards Track [Page 3]
RFC 5001 DNS NSID August 2007
As stated in Section 2.1, this mechanism is not restricted to
authoritative name servers; the semantics are intended to be equally
applicable to recursive name servers.
2.3. The NSID Option
The OPTION-CODE for the NSID option is [TBD].
The OPTION-CODE for the NSID option is 3.
Austein Expires July 15, 2006 [Page 4]
Internet-Draft DNS NSID January 2006
The OPTION-DATA for the NSID option is an opaque byte string the
The OPTION-DATA for the NSID option is an opaque byte string, the
semantics of which are deliberately left outside the protocol. See
Section 3.1 for discussion.
2.4. Presentation Format
User interfaces MUST read and write the content of the NSID option as
a sequence of hexadecimal digits, two digits per payload octet.
User interfaces MUST read and write the contents of the NSID option
as a sequence of hexadecimal digits, two digits per payload octet.
The NSID payload is binary data. Any comparison between NSID
payloads MUST be a comparison of the raw binary data. Copy
@ -243,44 +198,6 @@ Internet-Draft DNS NSID January 2006
See Section 3.3 for discussion.
Austein Expires July 15, 2006 [Page 5]
Internet-Draft DNS NSID January 2006
3. Discussion
This section discusses certain aspects of the protocol and explains
@ -288,11 +205,28 @@ Internet-Draft DNS NSID January 2006
3.1. The NSID Payload
The syntax and semantics of the content of the NSID option is
deliberately left outside the scope of this specification. This
section describe some of the kinds of data that server administrators
might choose to provide as the content of the NSID option, and
explains the reasoning behind choosing a simple opaque byte string.
The syntax and semantics of the content of the NSID option are
deliberately left outside the scope of this specification.
Choosing the NSID content is a prerogative of the server
administrator. The server administrator might choose to encode the
NSID content in such a way that the server operator (or clients
authorized by the server operator) can decode the NSID content to
obtain more information than other clients can. Alternatively, the
server operator might choose unencoded NSID content that is equally
meaningful to any client.
This section describes some of the kinds of data that server
administrators might choose to provide as the content of the NSID
option, and explains the reasoning behind specifying a simple opaque
byte string in Section 2.3.
Austein Standards Track [Page 4]
RFC 5001 DNS NSID August 2007
There are several possibilities for the payload of the NSID option:
@ -306,11 +240,11 @@ Internet-Draft DNS NSID January 2006
predictable fashion somehow using the server's IP address or name
as a seed value.
o It could be some sort of probabilisticly unique identifier
o It could be some sort of probabilistically unique identifier
initially derived from some sort of random number generator then
preserved across reboots of the name server.
o It could be some sort of dynamicly generated identifier so that
o It could be some sort of dynamically generated identifier so that
only the name server operator could tell whether or not any two
queries had been answered by the same server.
@ -329,14 +263,6 @@ Internet-Draft DNS NSID January 2006
o Using the "real" name is simple, but the name server may not have
a "real" name.
Austein Expires July 15, 2006 [Page 6]
Internet-Draft DNS NSID January 2006
o Using the "real" address is also simple, and the name server
almost certainly does have at least one non-anycast IP address for
maintenance operations, but the operator of the name server may
@ -350,6 +276,14 @@ Internet-Draft DNS NSID January 2006
o Using a hash or pseudo-random number can provide a fixed length
value that the resolver can use to tell two name servers apart
Austein Standards Track [Page 5]
RFC 5001 DNS NSID August 2007
without necessarily being able to tell where either one of them
"really" is, but makes debugging more difficult if one happens to
be in a friendly open environment. Furthermore, hashing might not
@ -358,43 +292,59 @@ Internet-Draft DNS NSID January 2006
that operators might have to debug at 4am tend not to be very
random.
o Probabilisticly unique identifiers have similar properties to
o Probabilistically unique identifiers have properties similar to
hashed identifiers, but (given a sufficiently good random number
generator) are immune to the search space issues. However, the
strength of this approach is also its weakness: there is no
algorithmic transformation by which even the server operator can
associate name server instances with identifiers while debugging,
which might be annoying. This approach also requires the name
server instance to preserve the probabilisticly unique identifier
across reboots, but this does not appear to be a serious
restriction, since authoritative nameservers almost always have
some form of nonvolatile storage in any case, and in the rare case
of a name server that does not have any way to store such an
identifier, nothing terrible will happen if the name server just
server instance to preserve the probabilistically unique
identifier across reboots, but this does not appear to be a
serious restriction, since authoritative nameservers almost always
have some form of non-volatile storage. In the rare case of a
name server that does not have any way to store such an
identifier, nothing terrible will happen if the name server
generates a new identifier every time it reboots.
o Using an arbitrary octet string gives name server operators yet
another thing to configure, or mis-configure, or forget to
another setting to configure, or mis-configure, or forget to
configure. Having all the nodes in an anycast name server
constellation identify themselves as "My Name Server" would not be
particularly useful.
o A signed blob is not particularly useful as an NSID payload unless
the signed data is dynamic and includes some kind of replay
protection, such as a timestamp or some kind of data identifying
the requestor. Signed blobs that meet these criteria could
conceivably be useful in some situations but would require
detailed security analysis beyond the scope of this document.
o A static encrypted blob would not be particularly useful, as it
would be subject to replay attacks and would, in effect, just be a
random number to any party that does not possess the decryption
key. Dynamic encrypted blobs could conceivably be useful in some
situations but, as with signed blobs, dynamic encrypted blobs
would require detailed security analysis beyond the scope of this
document.
Given all of the issues listed above, there does not appear to be a
single solution that will meet all needs. Section 2.3 therefore
defines the NSID payload to be an opaque byte string and leaves the
choice up to the implementor and name server operator. The following
guidelines may be useful to implementors and server operators:
choice of payload up to the implementor and name server operator.
Austein Expires July 15, 2006 [Page 7]
Austein Standards Track [Page 6]
Internet-Draft DNS NSID January 2006
RFC 5001 DNS NSID August 2007
The following guidelines may be useful to implementors and server
operators:
o Operators for whom divulging the unicast address is an issue could
use the raw binary representation of a probabilisticly unique
use the raw binary representation of a probabilistically unique
random number. This should probably be the default implementation
behavior.
@ -438,17 +388,17 @@ Internet-Draft DNS NSID January 2006
Given the range of possible payload contents described in
Section 3.1, it is not possible to define a single presentation
format for the NSID payload that is efficient, convenient,
Austein Standards Track [Page 7]
RFC 5001 DNS NSID August 2007
unambiguous, and aesthetically pleasing. In particular, while it is
tempting to use a presentation format that uses some form of textual
strings, attempting to support this would significantly complicate
Austein Expires July 15, 2006 [Page 8]
Internet-Draft DNS NSID January 2006
what's intended to be a very simple debugging mechanism.
In some cases the content of the NSID payload may be binary data
@ -468,7 +418,7 @@ Internet-Draft DNS NSID January 2006
It is much more important for the NSID payload data to be passed
unambiguously from server administrator to user and back again than
it is for the payload data data to be pretty while in transit. In
it is for the payload data to be pretty while in transit. In
particular, it's critical that it be straightforward for a user to
cut and paste an exact copy of the NSID payload output by a debugging
tool into other formats such as email messages or web forms without
@ -490,82 +440,23 @@ Internet-Draft DNS NSID January 2006
"sender's UDP payload size" field of the OPT pseudo-RR to signal a
receive buffer size large enough to make truncation unlikely.
Austein Expires July 15, 2006 [Page 9]
Internet-Draft DNS NSID January 2006
4. IANA Considerations
This mechanism requires allocation of one ENDS option code for the
NSID option (Section 2.3).
IANA has allocated EDNS option code 3 for the NSID option
(Section 2.3).
Austein Expires July 15, 2006 [Page 10]
Austein Standards Track [Page 8]
Internet-Draft DNS NSID January 2006
RFC 5001 DNS NSID August 2007
5. Security Considerations
This document describes a channel signaling mechanism, intended
This document describes a channel signaling mechanism intended
primarily for debugging. Channel signaling mechanisms are outside
the scope of DNSSEC per se. Applications that require integrity
the scope of DNSSEC, per se. Applications that require integrity
protection for the data being signaled will need to use a channel
security mechanism such as TSIG [RFC2845].
@ -576,102 +467,26 @@ Internet-Draft DNS NSID January 2006
leaves the syntax and semantics of the NSID option content up to the
implementation and the name server operator.
Austein Expires July 15, 2006 [Page 11]
Internet-Draft DNS NSID January 2006
Two of the possible kinds of payload data discussed in Section 3.1
involve a digital signature and encryption, respectively. While this
specification discusses some of the pitfalls that might lurk for
careless users of these kinds of payload data, full analysis of the
issues that would be involved in these kinds of payload data would
require knowledge of the content to be signed or encrypted,
algorithms to be used, and so forth, which is beyond the scope of
this document. Implementors should seek competent advice before
attempting to use these kinds of NSID payloads.
6. Acknowledgements
Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve
Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg,
Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and
Suzanne Woolf. Apologies to anyone inadvertently omitted from the
above list.
Austein Expires July 15, 2006 [Page 12]
Internet-Draft DNS NSID January 2006
Thanks to: Joe Abley, Harald Alvestrand, Dean Anderson, Mark Andrews,
Roy Arends, Steve Bellovin, Alex Bligh, Randy Bush, David Conrad,
John Dickinson, Alfred Hoenes, Johan Ihren, Daniel Karrenberg, Peter
Koch, William Leibzon, Ed Lewis, Thomas Narten, Mike Patton, Geoffrey
Sisson, Andrew Sullivan, Mike StJohns, Tom Taylor, Paul Vixie, Sam
Weiler, and Suzanne Woolf, none of whom are responsible for what the
author did with their comments and suggestions. Apologies to anyone
inadvertently omitted from the above list.
7. References
@ -683,6 +498,16 @@ Internet-Draft DNS NSID January 2006
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
Austein Standards Track [Page 9]
RFC 5001 DNS NSID August 2007
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
@ -692,43 +517,6 @@ Internet-Draft DNS NSID January 2006
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", RFC 2277, BCP 18, January 1998.
Austein Expires July 15, 2006 [Page 13]
Internet-Draft DNS NSID January 2006
Author's Address
Rob Austein
@ -737,7 +525,7 @@ Author's Address
Redwood City, CA 94063
USA
Email: sra@isc.org
EMail: sra@isc.org
@ -771,21 +559,28 @@ Author's Address
Austein Expires July 15, 2006 [Page 14]
Austein Standards Track [Page 10]
Internet-Draft DNS NSID January 2006
RFC 5001 DNS NSID August 2007
Intellectual Property Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
@ -809,26 +604,7 @@ Intellectual Property Statement
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
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
@ -836,5 +612,8 @@ Acknowledgment
Austein Expires July 15, 2006 [Page 15]
Austein Standards Track [Page 11]

1011
doc/rfc/rfc5452.txt Normal file
View File

File diff suppressed because it is too large Load Diff

583
doc/draft/draft-ietf-dnsext-dnsproxy-05.txt → doc/rfc/rfc5625.txt
View File

@ -1,37 +1,28 @@
DNSEXT R. Bellis
Internet-Draft Nominet UK
Intended status: BCP April 23, 2009
Expires: October 25, 2009
Network Working Group R. Bellis
Request for Comments: 5625 Nominet UK
BCP: 152 August 2009
Category: Best Current Practice
DNS Proxy Implementation Guidelines
draft-ietf-dnsext-dnsproxy-05
Status of this Memo
Abstract
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
This document provides guidelines for the implementation of DNS
proxies, as found in broadband gateways and other similar network
devices.
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.
Status of This Memo
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 October 25, 2009.
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
@ -44,89 +35,72 @@ Copyright Notice
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document provides guidelines for the implementation of DNS
proxies, as found in broadband gateways and other similar network
devices.
Bellis Expires October 25, 2009 [Page 1]
Bellis Best Current Practice [Page 1]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
RFC 5625 DNS Proxy Implementation Guidelines August 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3
4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4
4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4
4.2. Label Compression . . . . . . . . . . . . . . . . . . . . 4
4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 5
4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5
4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 6
4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6
4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6
4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7
5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7
5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 8
5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8
5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9
6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 10
6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Bellis Expires October 25, 2009 [Page 2]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
1. Introduction ....................................................2
2. Terminology .....................................................3
3. The Transparency Principle ......................................3
4. Protocol Conformance ............................................4
4.1. Unexpected Flags and Data ..................................4
4.2. Label Compression ..........................................4
4.3. Unknown Resource Record Types ..............................4
4.4. Packet Size Limits .........................................4
4.4.1. TCP Transport .......................................5
4.4.2. Extension Mechanisms for DNS (EDNS0) ................6
4.4.3. IP Fragmentation ....................................6
4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7
5. DHCP's Interaction with DNS .....................................7
5.1. Domain Name Server (DHCP Option 6) .........................7
5.2. Domain Name (DHCP Option 15) ...............................8
5.3. DHCP Leases ................................................8
6. Security Considerations .........................................9
6.1. Forgery Resilience .........................................9
6.2. Interface Binding .........................................10
6.3. Packet Filtering ..........................................10
7. Acknowledgements ...............................................10
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................12
1. Introduction
Research has found ([SAC035], [DOTSE]) that many commonly-used
broadband gateways (and similar devices) contain DNS proxies which
are incompatible in various ways with current DNS standards.
Research has found ([SAC035], [DOTSE]) that many commonly used
broadband gateways (and similar devices) contain DNS proxies that are
incompatible in various ways with current DNS standards.
These proxies are usually simple DNS forwarders, but typically do not
have any caching capabilities. The proxy serves as a convenient
default DNS resolver for clients on the LAN, but relies on an
upstream resolver (e.g. at an ISP) to perform recursive DNS lookups.
upstream resolver (e.g., at an ISP) to perform recursive DNS lookups.
Note that to ensure full DNS protocol interoperability it is
preferred that client stub resolvers should communicate directly with
full-feature upstream recursive resolvers wherever possible.
full-feature, upstream recursive resolvers wherever possible.
That notwithstanding, this document describes the incompatibilities
that have been discovered and offers guidelines to implementors on
@ -134,13 +108,20 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
client must use the broadband gateway's DNS proxy.
Bellis Best Current Practice [Page 2]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
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 [RFC2119].
3. The Transparency Principle
It is not considered practical for a simple DNS proxy to implement
@ -148,30 +129,26 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
There are several reasons why this is the case:
o broadband gateways usually have limited hardware resources
o firmware upgrade cycles are long, and many users do not routinely
apply upgrades when they become available
o no-one knows what those future DNS features will be, nor how they
might be implemented
o it would substantially complicate the configuration UI of the
device
o Broadband gateways usually have limited hardware resources.
Furthermore some modern DNS protocol extensions (see e.g. EDNS0,
o Firmware upgrade cycles are long, and many users do not routinely
apply upgrades when they become available.
o No one knows what those future DNS features will be or how they
might be implemented.
o Doing so would substantially complicate the configuration user
interface (UI) of the device.
Furthermore, some modern DNS protocol extensions (see, e.g., EDNS0
below) are intended to be used as "hop-by-hop" mechanisms. If the
DNS proxy is considered to be such a "hop" in the resolution chain,
then for it to function correctly, it would need to be fully
compliant with all such mechanisms.
Bellis Expires October 25, 2009 [Page 3]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
[SAC035] shows that the more actively a proxy participates in the DNS
protocol then the more likely it is that it will somehow interfere
with the flow of messages between the DNS client and the upstream
protocol, the more likely it is that it will somehow interfere with
the flow of messages between the DNS client and the upstream
recursive resolvers.
The role of the proxy should therefore be no more and no less than to
@ -187,11 +164,18 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
Except when required to enforce an active security or network policy
(such as maintaining a pre-authentication "walled garden"), end-users
SHOULD be able to send their DNS queries to specified upstream
Bellis Best Current Practice [Page 3]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
resolvers, thereby bypassing the proxy altogether. In this case, the
gateway SHOULD NOT modify the DNS request or response packets in any
way.
4. Protocol Conformance
4.1. Unexpected Flags and Data
@ -205,26 +189,18 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
containing either the "Authentic Data" (AD) or "Checking Disabled"
(CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035]
originally specified that these unused "Z" flag bits "MUST" be zero.
However these flag bits were always intended to be reserved for
However, these flag bits were always intended to be reserved for
future use, so refusing to proxy any packet containing these flags
(now that uses for those flags have indeed been defined) is not
appropriate.
Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown
DNS flags and proxy those packets as usual.
Therefore, proxies MUST ignore any unknown DNS flags and proxy those
packets as usual.
4.2. Label Compression
Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
Bellis Expires October 25, 2009 [Page 4]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
Proxies MUST forward packets regardless of the presence or absence of
compressed labels therein.
@ -236,28 +212,36 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
All requests and responses MUST be proxied regardless of the values
of the QTYPE and QCLASS fields.
Similarly all responses MUST be proxied regardless of the values of
Similarly, all responses MUST be proxied regardless of the values of
the TYPE and CLASS fields of any Resource Record therein.
4.4. Packet Size Limits
[RFC1035] specifies that the maximum size of the DNS payload in a UDP
packet is 512 octets. Where the required portions of a response
would not fit inside that limit the DNS server MUST set the
would not fit inside that limit, the DNS server MUST set the
Bellis Best Current Practice [Page 4]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
"TrunCation" (TC) bit in the DNS response header to indicate that
truncation has occurred. There are however two standard mechanisms
(described in Section 4.4.1 and Section 4.4.2) for transporting
responses larger than 512 octets.
(described in Sections 4.4.1 and 4.4.2) for transporting responses
larger than 512 octets.
Many proxies have been observed to truncate all responses at 512
octets, and others at a packet size related to the WAN MTU, in either
case doing so without correctly setting the TC bit.
Other proxies have been observed to remove the TC bit in server
responses which correctly had the TC bit set by the server.
responses that correctly had the TC bit set by the server.
If a DNS response is truncated but the TC bit is not set then client
failures may result. In particular a naive DNS client library might
If a DNS response is truncated but the TC bit is not set, then client
failures may result. In particular, a naive DNS client library might
suffer crashes due to reading beyond the end of the data actually
received.
@ -266,29 +250,22 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
size. See Section 4.4.3 for recommendations for packet sizes
exceeding the WAN MTU.
If a proxy must unilaterally truncate a response then the proxy MUST
If a proxy must unilaterally truncate a response, then the proxy MUST
set the TC bit. Similarly, proxies MUST NOT remove the TC bit from
responses.
Bellis Expires October 25, 2009 [Page 5]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
4.4.1. TCP Transport
Should a UDP query fail because of truncation, the standard fail-over
mechanism is to retry the query using TCP, as described in section
mechanism is to retry the query using TCP, as described in Section
6.1.3.2 of [RFC1123].
DNS proxies SHOULD therefore be prepared to receive and forward
queries over TCP.
Whilst TCP transport is not strictly mandatory, it is supported by
the vast majority of stub resolvers and recursive servers. Lack of
support in the proxy prevents this fail-over mechanism from working.
DNS proxies MUST therefore be prepared to receive and forward queries
over TCP.
Note that it is unlikely that a client would send a request over TCP
unless it had already received a truncated UDP response. Some
@ -298,14 +275,23 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
behaviour increases network traffic and causes delay in DNS
resolution since the initial UDP request is doomed to fail.
Therefore whenever a proxy receives a request over TCP, the proxy
Bellis Best Current Practice [Page 5]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
Therefore, whenever a proxy receives a request over TCP, the proxy
SHOULD forward the query over TCP and SHOULD NOT attempt the same
query over UDP first.
4.4.2. Extension Mechanisms for DNS (EDNS0)
The Extension Mechanism for DNS [RFC2671] was introduced to allow the
transport of larger DNS packets over UDP and also to allow for
The "Extension Mechanism for DNS" [RFC2671] was introduced to allow
the transport of larger DNS packets over UDP and also to allow for
additional request and response flags.
A client may send an OPT Resource Record (OPT RR) in the Additional
@ -314,9 +300,9 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
by DNSSEC to indicate that DNSSEC-related RRs should be returned to
the client.
However some proxies have been observed to either reject (with a
However, some proxies have been observed to either reject (with a
FORMERR response code) or black-hole any packet containing an OPT RR.
As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets.
As per Section 4.1, proxies MUST NOT refuse to proxy such packets.
4.4.3. IP Fragmentation
@ -324,18 +310,12 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
gateway's algorithm for handling fragmented IP packets. Several
methods are possible:
1. fragments are dropped
2. fragments are forwarded individually as they're received
3. complete packets are reassembled on the gateway, and then re-
fragmented (if necessary) as they're forwarded to the client
1. Fragments are dropped.
2. Fragments are forwarded individually as they're received.
Bellis Expires October 25, 2009 [Page 6]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
3. Complete packets are reassembled on the gateway and then re-
fragmented (if necessary) as they're forwarded to the client.
Method 1 above will cause compatibility problems with EDNS0 unless
the DNS client is configured to advertise an EDNS0 buffer size
@ -347,11 +327,20 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
to 65535 octets, most common DNS server implementations do not
support a buffer size above 4096 octets.
Therefore (irrespective of which of the methods above is in use)
Therefore (irrespective of which of the above methods is in use),
proxies SHOULD be capable of forwarding UDP packets up to a payload
size of at least 4096 octets.
NB: in theory IP fragmentation may also occur if the LAN MTU is
Bellis Best Current Practice [Page 6]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
NB: in theory, IP fragmentation may also occur if the LAN MTU is
smaller than the WAN MTU, although the author has not observed such a
configuration in use on any residential broadband service.
@ -372,55 +361,58 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
containing TKEY [RFC2930] Resource Records.
NB: any DNS proxy (such as those commonly found in WiFi hotspot
"walled gardens") which transparently intercepts all DNS queries, and
which returns unsigned responses to signed queries, will also cause
"walled gardens") that transparently intercepts all DNS queries and
that returns unsigned responses to signed queries, will also cause
TSIG authentication failures.
5. DHCP's Interaction with DNS
Whilst this document is primarily about DNS proxies, most consumers
rely on DHCP [RFC2131] to obtain network configuration settings.
Such settings include the client machine's IP address, subnet mask
and default gateway, but also include DNS related settings.
Such settings include the client machine's IP address, subnet mask,
and default gateway, but also include DNS-related settings.
It is therefore appropriate to examine how DHCP affects client DNS
Bellis Expires October 25, 2009 [Page 7]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
configuration.
5.1. Domain Name Server (DHCP Option 6)
Most gateways default to supplying their own IP address in the DHCP
"Domain Name Server" option [RFC2132]. The net result is that
without explicit re-configuration many DNS clients will by default
without explicit re-configuration many DNS clients will, by default,
send queries to the gateway's DNS proxy. This is understandable
behaviour given that the correct upstream settings are not usually
known at boot time.
Bellis Best Current Practice [Page 7]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
Most gateways learn their own DNS settings via values supplied by an
ISP via DHCP or PPP over the WAN interface. However whilst many
ISP via DHCP or PPP over the WAN interface. However, whilst many
gateways do allow the device administrator to override those values,
some gateways only use those supplied values to affect the proxy's
own forwarding function, and do not offer these values via DHCP.
When using such a device the only way to avoid using the DNS proxy is
to hard-code the required values in the client operating system.
When using such a device, the only way to avoid using the DNS proxy
is to hard-code the required values in the client operating system.
This may be acceptable for a desktop system but it is inappropriate
for mobile devices which are regularly used on many different
for mobile devices that are regularly used on many different
networks.
As per Section 3, end-users SHOULD be able to send their DNS queries
directly to specified upstream resolvers, ideally without hard-coding
those settings in their stub resolver.
It is therefore RECOMMENDED that gateways SHOULD support device
It is therefore RECOMMENDED that gateways SHOULD support device-
administrator configuration of values for the "Domain Name Server"
DHCP option.
@ -431,80 +423,72 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
attributed to particular equipment vendors whose firmware defaults
this DHCP option to specific values.
Since no standard exists for a "local" scoped domain name suffix it
Since no standard exists for a "local" scoped domain name suffix, it
is RECOMMENDED that the default value for this option SHOULD be
empty, and that this option MUST NOT be sent to clients when no value
is configured.
5.3. DHCP Leases
It is noted that some DHCP servers in broadband gateways by default
offer their own IP address for the "Domain Name Server" option (as
It is noted that some DHCP servers in broadband gateways offer, by
default, their own IP address for the "Domain Name Server" option (as
described above) but then automatically start offering the upstream
Bellis Expires October 25, 2009 [Page 8]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
servers' addresses once they've been learnt over the WAN interface.
In general this behaviour is highly desirable, but the effect for the
end-user is that the settings used depend on whether the DHCP lease
was obtained before or after the WAN link was established.
In general, this behaviour is highly desirable, but the effect for
the end-user is that the settings used depend on whether the DHCP
lease was obtained before or after the WAN link was established.
If the DHCP lease is obtained whilst the WAN link is down then the
If the DHCP lease is obtained whilst the WAN link is down, then the
DHCP client (and hence the DNS client) will not receive the correct
values until the DHCP lease is renewed.
Bellis Best Current Practice [Page 8]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
Whilst no specific recommendations are given here, vendors may wish
to give consideration to the length of DHCP leases, and whether some
mechanism for forcing a DHCP lease renewal might be appropriate.
to give consideration to the length of DHCP leases and to whether
some mechanism for forcing a DHCP lease renewal might be appropriate.
Another possibility is that the learnt upstream values might be
persisted in non-volatile memory such that on reboot the same values
can be automatically offered via DHCP. However this does run the
can be automatically offered via DHCP. However, this does run the
risk that incorrect values are initially offered if the device is
moved or connected to another ISP.
Alternatively, the DHCP server might only issue very short (i.e. 60
Alternatively, the DHCP server might only issue very short (i.e., 60
second) leases while the WAN link is down, only reverting to more
typical lease lengths once the WAN link is up and the upstream DNS
servers are known. Indeed with such a configuration it may be
servers are known. Indeed, with such a configuration it may be
possible to avoid the need to implement a DNS proxy function in the
broadband gateway at all.
6. Security Considerations
This document introduces no new protocols. However there are some
security related recommendations for vendors that are listed here.
This document introduces no new protocols. However, there are some
security-related recommendations for vendors that are listed here.
6.1. Forgery Resilience
Whilst DNS proxies are not usually full-feature resolvers they
Whilst DNS proxies are not usually full-feature resolvers, they
nevertheless share some characteristics with them.
Notwithstanding the recommendations above about transparency many DNS
proxies are observed to pick a new Query ID for outbound requests to
ensure that responses are directed to the correct client.
Notwithstanding the recommendations above about transparency, many
DNS proxies are observed to pick a new Query ID for outbound requests
to ensure that responses are directed to the correct client.
NB: Changing the Query ID is acceptable and compatible with proxying
NB: changing the Query ID is acceptable and compatible with proxying
TSIG-signed packets since the TSIG signature calculation is based on
the original message ID which is carried in the TSIG RR.
the original message ID, which is carried in the TSIG RR.
It has been standard guidance for many years that each DNS query
should use a randomly generated Query ID. However many proxies have
Bellis Expires October 25, 2009 [Page 9]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
should use a randomly generated Query ID. However, many proxies have
been observed picking sequential Query IDs for successive requests.
It is strongly RECOMMENDED that DNS proxies follow the relevant
@ -513,126 +497,76 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
applies to source port selection within any NAT function.
If a DNS proxy is running on a broadband gateway with NAT that is
compliant with [RFC4787] then it SHOULD also follow the
compliant with [RFC4787], then it SHOULD also follow the
recommendations in Section 10 of [RFC5452] concerning how long DNS
state is kept.
Bellis Best Current Practice [Page 9]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
6.2. Interface Binding
Some gateways have been observed to have their DNS proxy listening on
both internal (LAN) and external (WAN) interfaces. In this
configuration it is possible for the proxy to be used to mount
configuration, it is possible for the proxy to be used to mount
reflector attacks as described in [RFC5358].
The DNS proxy in a gateway SHOULD NOT by default be accessible from
The DNS proxy in a gateway SHOULD NOT, by default, be accessible from
the WAN interfaces of the device.
6.3. Packet Filtering
The Transparency and Robustness Principles are not entirely
compatible with the deep packet inspection features of security
appliances such as firewalls which are intended to protect systems on
the inside of a network from rogue traffic.
compatible with the deep packet-inspection features of security
appliances such as firewalls, which are intended to protect systems
on the inside of a network from rogue traffic.
However a clear distinction may be made between traffic that is
However, a clear distinction may be made between traffic that is
intrinsically malformed and that which merely contains unexpected
data.
Examples of malformed packets which MAY be dropped include:
Examples of malformed packets that MAY be dropped include:
o invalid compression pointers (i.e. those that point outside of the
current packet, or which might cause a parsing loop).
o incorrect counts for the Question, Answer, Authority and
o invalid compression pointers (i.e., those that point outside of
the current packet or that might cause a parsing loop)
o incorrect counts for the Question, Answer, Authority, and
Additional Sections (although care should be taken where
truncation is a possibility).
truncation is a possibility)
Since dropped packets will cause the client to repeatedly retransmit
the original request, it is RECOMMENDED that proxies SHOULD instead
return a suitable DNS error response to the client (i.e. SERVFAIL)
instead of dropping the packet completely.
Dropped packets will cause the client to repeatedly retransmit the
original request, with the client only detecting the error after
several retransmit intervals.
In these circumstances, proxies SHOULD synthesise a suitable DNS
error response to the client (i.e., SERVFAIL) instead of dropping the
packet completely. This will allow the client to detect the error
immediately.
Bellis Expires October 25, 2009 [Page 10]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
7. IANA Considerations
This document requests no IANA actions.
8. Change Log
NB: to be removed by the RFC Editor before publication.
draft-ietf-dnsproxy-05
Removed specific reference to 28 byte IP headers (from Mark
Andrews)
draft-ietf-dnsproxy-04 - post WGLC
Introduction expanded
Section 5.2 - changed SHOULD to MUST
Section 4.5 - changed SHOULD to MUST (Alex Bligh)
Editorial nits (from Andrew Sullivan, Alfred Hones)
Clarificaton on end-user vs device administrator (Alan Barrett,
Paul Selkirk)
draft-ietf-dnsproxy-03
Editorial nits and mention of LAN MTU (from Alex Bligh)
draft-ietf-dnsproxy-02
Changed "router" to "gateway" throughout (David Oran)
Updated forgery resilience reference
Elaboration on bypassability (from Nicholas W.)
Elaboration on NAT source port randomisation (from Nicholas W.)
Mention of using short DHCP leases while the WAN link is down
(from Ralph Droms)
Further clarification on permissibility of altering QID when using
TSIG
draft-ietf-dnsproxy-01
Strengthened recommendations about truncation (from Shane Kerr)
New TSIG text (with help from Olafur)
Additional forgery resilience text (from Olafur)
Compression support (from Olafur)
Correction of text re: QID changes and compatibility with TSIG
draft-ietf-dnsproxy-00
Changed recommended DPI error to SERVFAIL (from Jelte)
Changed example for invalid compression pointers (from Wouter).
Note about TSIG implications of changing Query ID (from Wouter).
Clarified TC-bit text (from Wouter)
Bellis Expires October 25, 2009 [Page 11]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
Extra text about proxy bypass (Nicholas W.)
draft-bellis-dnsproxy-00
Initial draft
9. Acknowledgements
7. Acknowledgements
The author would particularly like to acknowledge the assistance of
Lisa Phifer of Core Competence. In addition the author is grateful
Lisa Phifer of Core Competence. In addition, the author is grateful
for the feedback from the members of the DNSEXT Working Group.
10. References
10.1. Normative References
Bellis Best Current Practice [Page 10]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
8. References
8.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
@ -665,14 +599,6 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
Bellis Expires October 25, 2009 [Page 12]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
@ -685,10 +611,19 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
Nameservers in Reflector Attacks", BCP 140, RFC 5358,
October 2008.
Bellis Best Current Practice [Page 11]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452, January 2009.
10.2. Informative References
8.2. Informative References
[DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
Routers", February 2008,
@ -698,7 +633,6 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009
Broadband Routers and Firewalls", September 2008,
<http://www.icann.org/committees/security/sac035.pdf>.
Author's Address
Ray Bellis
@ -708,7 +642,7 @@ Author's Address
United Kingdom
Phone: +44 1865 332211
Email: ray.bellis@nominet.org.uk
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/
@ -724,5 +658,18 @@ Author's Address
Bellis Expires October 25, 2009 [Page 13]
Bellis Best Current Practice [Page 12]