upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-06-15 00:40:01 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

This commit was manufactured by cvs2git to create branch 'v9_6'.

Browse source
This commit is contained in:
cvs2git 2009-04-29 04:10:42 +00:00
commit b0e0a30968
4 changed files with 3167 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -0,0 +1,370 @@
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 ]

1058
doc/draft/draft-ietf-dnsext-axfr-clarify-11.txt Normal file
View file

File diff suppressed because it is too large Load diff

728
doc/draft/draft-ietf-dnsext-dnsproxy-05.txt Normal file
View file

@ -0,0 +1,728 @@
DNSEXT R. Bellis
Internet-Draft Nominet UK
Intended status: BCP April 23, 2009
Expires: October 25, 2009
DNS Proxy Implementation Guidelines
draft-ietf-dnsext-dnsproxy-05
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 October 25, 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 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]
Internet-Draft DNS Proxy Implementation Guidelines April 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
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.
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.
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.
That notwithstanding, this document describes the incompatibilities
that have been discovered and offers guidelines to implementors on
how to provide better interoperability in those cases where the
client must use the broadband gateway's DNS proxy.
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
all current and future DNS features.
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
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
recursive resolvers.
The role of the proxy should therefore be no more and no less than to
receive DNS requests from clients on the LAN side, forward those
verbatim to one of the known upstream recursive resolvers on the WAN
side, and ensure that the whole response is returned verbatim to the
original client.
It is RECOMMENDED that proxies should be as transparent as possible,
such that any "hop-by-hop" mechanisms or newly introduced protocol
extensions operate as if the proxy were not there.
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
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
The Transparency Principle above, when combined with Postel's
Robustness Principle [RFC0793], suggests that DNS proxies should not
arbitrarily reject or otherwise drop requests or responses based on
perceived non-compliance with standards.
For example, some proxies have been observed to drop any packet
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
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.
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.
4.3. Unknown Resource Record Types
[RFC3597] requires that resolvers MUST handle Resource Records (RRs)
of unknown type transparently.
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
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
"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.
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.
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.
Since UDP packets larger than 512 octets are now expected in normal
operation, proxies SHOULD NOT truncate UDP packets that exceed that
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
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
6.1.3.2 of [RFC1123].
DNS proxies SHOULD 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
"smart" proxies have been observed to first forward any request
received over TCP to an upstream resolver over UDP, only for the
response to be truncated, causing the proxy to retry over TCP. Such
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
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
additional request and response flags.
A client may send an OPT Resource Record (OPT RR) in the Additional
Section of a request to indicate that it supports a specific receive
buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used
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
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.
4.4.3. IP Fragmentation
Support for UDP packet sizes exceeding the WAN MTU depends on the
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
Bellis Expires October 25, 2009 [Page 6]
Internet-Draft DNS Proxy Implementation Guidelines April 2009
Method 1 above will cause compatibility problems with EDNS0 unless
the DNS client is configured to advertise an EDNS0 buffer size
limited to the WAN MTU less the size of the IP header. Note that RFC
2671 does recommend that the path MTU should be taken into account
when using EDNS0.
Also, whilst the EDNS0 specification allows for a buffer size of up
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)
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
smaller than the WAN MTU, although the author has not observed such a
configuration in use on any residential broadband service.
4.5. Secret Key Transaction Authentication for DNS (TSIG)
[RFC2845] defines TSIG, which is a mechanism for authenticating DNS
requests and responses at the packet level.
Any modifications made to the DNS portions of a TSIG-signed query or
response packet (with the exception of the Query ID) will cause a
TSIG authentication failure.
DNS proxies MUST implement Section 4.7 of [RFC2845] and either
forward packets unchanged (as recommended above) or fully implement
TSIG.
As per Section 4.3, DNS proxies MUST be capable of proxying packets
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
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.
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
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.
Most gateways learn their own DNS settings via values supplied by an
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.
This may be acceptable for a desktop system but it is inappropriate
for mobile devices which 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
administrator configuration of values for the "Domain Name Server"
DHCP option.
5.2. Domain Name (DHCP Option 15)
A significant amount of traffic to the DNS Root Name Servers is for
invalid top-level domain names, and some of that traffic can be
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
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
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.
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.
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.
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
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
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
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.
6.1. Forgery Resilience
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.
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.
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
been observed picking sequential Query IDs for successive requests.
It is strongly RECOMMENDED that DNS proxies follow the relevant
recommendations in [RFC5452], particularly those in Section 9.2
relating to randomisation of Query IDs and source ports. This also
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
recommendations in Section 10 of [RFC5452] concerning how long DNS
state is kept.
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
reflector attacks as described in [RFC5358].
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.
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:
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
Additional Sections (although care should be taken where
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.
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
The author would particularly like to acknowledge the assistance of
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
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[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.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358,
October 2008.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452, January 2009.
10.2. Informative References
[DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
Routers", February 2008,
<http://www.iis.se/docs/Routertester_en.pdf>.
[SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
Broadband Routers and Firewalls", September 2008,
<http://www.icann.org/committees/security/sac035.pdf>.
Author's Address
Ray Bellis
Nominet UK
Edmund Halley Road
Oxford OX4 4DQ
United Kingdom
Phone: +44 1865 332211
Email: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/
Bellis Expires October 25, 2009 [Page 13]

1011
doc/rfc/rfc5507.txt Normal file
View file

File diff suppressed because it is too large Load diff