draft-ietf-dnsext-dnsproxy-02.txt   draft-ietf-dnsext-dnsproxy-03.txt 
DNSEXT R. Bellis DNSEXT R. Bellis
Internet-Draft Nominet UK Internet-Draft Nominet UK
Intended status: BCP March 2, 2009 Intended status: BCP March 3, 2009
Expires: September 3, 2009 Expires: September 4, 2009
DNS Proxy Implementation Guidelines DNS Proxy Implementation Guidelines
draft-ietf-dnsext-dnsproxy-02 draft-ietf-dnsext-dnsproxy-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2009. This Internet-Draft will expire on September 4, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 43 skipping to change at page 2, line 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Recent research ([SAC035], [DOTSE]) has found that many commonly-used Recent research ([SAC035], [DOTSE]) has found that many commonly-used
broadband gateways (and similar devices) contain DNS proxies which broadband gateways (and similar devices) contain DNS proxies which
are incompatible in various ways with current DNS standards. are incompatible in various ways with current DNS standards.
These proxies are usual simple DNS forwarders, but do not usually These proxies are usual simple DNS forwarders, but do not usually
have any caching capabilities. The proxy serves as a convenient have any caching capabilities. The proxy serves as a convenient
default DNS resolver for clients on the LAN, but relies on an 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.
This documents describes the incompatibilities that have been This document describes the incompatibilities that have been
discovered and offers guidelines to implementors on how to provide discovered and offers guidelines to implementors on how to provide
maximum interoperability. maximum interoperability.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. The Transparency Principle 3. The Transparency Principle
It is not considered practical for a simple DNS proxy to directly It is not considered practical for a simple DNS proxy to implement
implement all current and future DNS features. all current and future DNS features.
There are several reasons why this is the case: There are several reasons why this is the case:
o broadband gateways usually have limited hardware resources o broadband gateways usually have limited hardware resources
o firmware upgrade cycles are long, and many users do not routinely o firmware upgrade cycles are long, and many users do not routinely
apply upgrades when they become available apply upgrades when they become available
o no-one knows what those future DNS features will be, nor how they o no-one knows what those future DNS features will be, nor how they
might be implemented might be implemented
o it would substantially complicate the configuration UI of the o it would substantially complicate the configuration UI of the
device device
Furthermore some modern DNS protocol extensions (see e.g. EDNS0, Furthermore some modern DNS protocol extensions (see e.g. EDNS0,
below) are intended to be used as "hop-by-hop" mechanisms. If the 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 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 then for it to function correctly, it would need to be fully
with all such mechanisms. compliant with all such mechanisms.
Research [SAC035] has shown that the more actively a proxy Research [SAC035] has shown that the more actively a proxy
participates in the DNS protocol then the more likely it is that it participates in the DNS protocol then the more likely it is that it
will somehow interfere with the flow of messages between the DNS will somehow interfere with the flow of messages between the DNS
client and the upstream recursive resolvers. client and the upstream recursive resolvers.
The role of the proxy should therefore be no more and no less than to 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 receive DNS requests from clients on the LAN side, forward those
verbatim to one of the known upstream recursive resolvers on the WAN verbatim to one of the known upstream recursive resolvers on the WAN
side, and ensure that the whole response is returned verbatim to the side, and ensure that the whole response is returned verbatim to the
original client. original client.
It is RECOMMENDED that proxies should be as transparent as possible, It is RECOMMENDED that proxies should be as transparent as possible,
such that any "hop-by-hop" mechanisms or newly introduced protocol such that any "hop-by-hop" mechanisms or newly introduced protocol
extensions operate as if the proxy were not there. extensions operate as if the proxy were not there.
Except when required to enforce an active security or network policy Except when required to enforce an active security or network policy
(such as maintaining a pre-authentication "walled garden"), end-users (such as maintaining a pre-authentication "walled garden"), end-users
SHOULD be able to send their DNS queries to specified upstream SHOULD be able to send their DNS queries to specified upstream
resolvers. In this case, the proxy SHOULD NOT modify the packets in resolvers, thereby bypassing the proxy altogether. In this case, the
any way except for modifying IP and TCP/UDP headers as required by gateway SHOULD NOT modify the DNS request or response packets in any
NAT. way.
4. Protocol Conformance 4. Protocol Conformance
4.1. Unexpected Flags and Data 4.1. Unexpected Flags and Data
The Transparency Principle above, when combined with Postel's The Transparency Principle above, when combined with Postel's
Robustness Principle [RFC0793], suggests that DNS proxies should not Robustness Principle [RFC0793], suggests that DNS proxies should not
arbitrarily reject or otherwise drop requests or responses based on arbitrarily reject or otherwise drop requests or responses based on
perceived non-compliance with standards. perceived non-compliance with standards.
skipping to change at page 5, line 29 skipping to change at page 5, line 29
packet is 512 octets. Where the required portions of a response 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
"TrunCation" (TC) bit in the DNS response header to indicate that "TrunCation" (TC) bit in the DNS response header to indicate that
truncation has occurred. There are however two standard mechanisms truncation has occurred. There are however two standard mechanisms
(described below) for transporting responses larger than 512 octets. (described below) for transporting responses larger than 512 octets.
Many proxies have been observed to truncate all responses at 512 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 octets, and others at a packet size related to the WAN MTU, in either
case doing so without correctly setting the TC bit. case doing so without correctly setting the TC bit.
Other proxies have been observed to incorrectly remove the TC bit in Other proxies have been observed to remove the TC bit in server
server responses which correctly had the TC bit set by the 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 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 failures may result, in particular a naive DNS client library might
suffer crashes due to reading beyond the end of the data actually suffer crashes due to reading beyond the end of the data actually
received. received.
Since UDP packets larger than 512 octets are now expected in normal Since UDP packets larger than 512 octets are now expected in normal
operation, proxies SHOULD NOT truncate UDP packets that exceed that operation, proxies SHOULD NOT truncate UDP packets that exceed that
size. See Section 4.4.3 for recommendations for packet sizes size. See Section 4.4.3 for recommendations for packet sizes
exceeding the WAN MTU. 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 set the TC bit. Similarly, proxies MUST NOT remove the TC bit from
responses. responses.
4.4.1. TCP Transport 4.4.1. TCP Transport
Should a UDP query fail because of truncation the standard fail-over 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] . 6.1.3.2 of [RFC1123] .
DNS proxies SHOULD therefore be prepared to receive and forward DNS proxies SHOULD therefore be prepared to receive and forward
queries over TCP. queries over TCP.
Note that it is unlikely that a client would send a request 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 unless it had already received a truncated UDP response. Some
"smart" proxies have been observed to first forward a request "smart" proxies have been observed to first forward any request
received over TCP to an upstream resolver over UDP, only for the received over TCP to an upstream resolver over UDP, only for the
response to be truncated, causing the proxy to retry over TCP. Such response to be truncated, causing the proxy to retry over TCP. Such
behaviour increases network traffic and causes delay in DNS behaviour increases network traffic and causes delay in DNS
resolution since the initial UDP request is doomed to fail. resolution since the initial UDP request is doomed to fail.
Therefore whenever a proxy receives a request over TCP, the proxy Therefore whenever a proxy receives a request over TCP, the proxy
SHOULD forward the query over TCP and SHOULD NOT attempt the same SHOULD forward the query over TCP and SHOULD NOT attempt the same
query over UDP first. query over UDP first.
4.4.2. Extension Mechanisms for DNS (EDNS0) 4.4.2. Extension Mechanisms for DNS (EDNS0)
skipping to change at page 7, line 7 skipping to change at page 7, line 7
Option 1 above will cause compatibility problems with EDNS0 unless Option 1 above will cause compatibility problems with EDNS0 unless
the DNS client is configured to advertise an EDNS0 buffer size the DNS client is configured to advertise an EDNS0 buffer size
limited to 28 octets less than the MTU. Note that RFC 2671 does limited to 28 octets less than the MTU. Note that RFC 2671 does
recommend that the path MTU should be taken into account when using recommend that the path MTU should be taken into account when using
EDNS0. EDNS0.
Also, whilst the EDNS0 specification allows for a buffer size of up Also, whilst the EDNS0 specification allows for a buffer size of up
to 65535 octets, most common DNS server implementations do not to 65535 octets, most common DNS server implementations do not
support a buffer size above 4096 octets. support a buffer size above 4096 octets.
Therefore it is RECOMMENDED (whichever of options 2 or 3 above is in Therefore proxies SHOULD (whichever of options 2 or 3 above is in
use) that gateways SHOULD be capable of forwarding UDP packets up to use) be capable of forwarding UDP packets up to a payload size of at
a payload size of at least 4096 octets. 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) 4.5. Secret Key Transaction Authentication for DNS (TSIG)
[RFC2845] defines TSIG, which is a mechanism for authenticating DNS [RFC2845] defines TSIG, which is a mechanism for authenticating DNS
requests and responses at the packet level. requests and responses at the packet level.
Any modifications made to the DNS portions of a TSIG-signed query or 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 response packet (with the exception of the Query ID) will cause a
TSIG authentication failure. TSIG authentication failure.
skipping to change at page 9, line 49 skipping to change at page 10, line 7
should use a randomly generated Query ID. However many proxies have should use a randomly generated Query ID. However many proxies have
been observed picking sequential Query IDs for successive requests. been observed picking sequential Query IDs for successive requests.
It is strongly RECOMMENDED that DNS proxies follow the relevant It is strongly RECOMMENDED that DNS proxies follow the relevant
recommendations in [RFC5452], particularly those in Section 9.2 recommendations in [RFC5452], particularly those in Section 9.2
relating to randomisation of Query IDs and source ports. This also relating to randomisation of Query IDs and source ports. This also
applies to source port selection within any NAT function. applies to source port selection within any NAT function.
If a DNS proxy is running on a broadband gateway with NAT that is 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 for how long DNS state is kept from Section 10 of recommendations in Section 10 of [RFC5452] concerning how long DNS
[RFC5452] state is kept.
6.2. Interface Binding 6.2. Interface Binding
Some gateways have been observed to have their DNS proxy listening on Some gateways have been observed to have their DNS proxy listening on
both internal (LAN) and external (WAN) interfaces. In this 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] 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. the WAN interfaces of the device.
skipping to change at page 10, line 45 skipping to change at page 10, line 50
the original request, it is RECOMMENDED that proxies SHOULD instead the original request, it is RECOMMENDED that proxies SHOULD instead
return a suitable DNS error response to the client (i.e. SERVFAIL) return a suitable DNS error response to the client (i.e. SERVFAIL)
instead of dropping the packet completely. instead of dropping the packet completely.
7. IANA Considerations 7. IANA Considerations
This document requests no IANA actions. This document requests no IANA actions.
8. Change Log 8. Change Log
draft-ietf-dnsproxy-03
Editorial nits and mention of LAN MTU (from Alex Bligh)
draft-ietf-dnsproxy-02 draft-ietf-dnsproxy-02
Changed "router" to "gateway" throughout (David Oran) Changed "router" to "gateway" throughout (David Oran)
Updated forgery resilience reference Updated forgery resilience reference
Elaboration on bypassability (from Nicholas W.) Elaboration on bypassability (from Nicholas W.)
Elaboration on NAT source port randomisation (from Nicholas W.) Elaboration on NAT source port randomisation (from Nicholas W.)
Mention of using short DHCP leases while the WAN link is down Mention of using short DHCP leases while the WAN link is down
(from Ralph Droms) (from Ralph Droms)
Further clarification on permissibility of altering QID when using Further clarification on permissibility of altering QID when using
TSIG TSIG
 End of changes. 14 change blocks. 
23 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/