One document matched: draft-ietf-dnsext-dnsproxy-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc793 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml'>
<!ENTITY rfc1035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc1123 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1123.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2131 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'>
<!ENTITY rfc2132 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'>
<!ENTITY rfc2671 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2671.xml'>
<!ENTITY rfc2845 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2845.xml'>
<!ENTITY rfc2930 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2930.xml'>
<!ENTITY rfc3597 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3597.xml'>
<!ENTITY rfc4035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml'>
<!ENTITY rfc4787 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml'>
<!ENTITY rfc5358 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5358.xml'>
<!ENTITY rfc5452 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5452.xml'>
]>
<rfc category="bcp" ipr="trust200902" docName="draft-ietf-dnsext-dnsproxy-06">
<?rfc toc='yes' ?>
<?rfc tocompact='no' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='yes' ?>
<?rfc sortrefs='yes' ?>
<?rfc symrefs='yes' ?>
<front>
<title>DNS Proxy Implementation Guidelines</title>
<author initials="R.P." surname="Bellis" fullname="Ray Bellis">
<organization>Nominet UK</organization>
<address>
<postal>
<street>Edmund Halley Road</street>
<city>Oxford</city>
<code>OX4 4DQ</code>
<country>United Kingdom</country>
</postal>
<phone>+44 1865 332211</phone>
<email>ray.bellis@nominet.org.uk</email>
<uri>http://www.nominet.org.uk/</uri>
</address>
</author>
<date year="2009"/>
<area>Internet Area</area>
<workgroup>DNSEXT</workgroup>
<keyword>DNS</keyword>
<keyword>Proxy</keyword>
<abstract>
<t> This document provides guidelines for the implementation of DNS proxies, as found in
broadband gateways and other similar network devices.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> Research has found (<xref target="SAC035"/>, <xref target="DOTSE"/>) that many
commonly-used broadband gateways (and similar devices) contain DNS proxies which are
incompatible in various ways with current DNS standards. </t>
<t> 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.</t>
<t> 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.</t>
<t> 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.</t>
</section>
<section title="Terminology">
<t> 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 <xref target="RFC2119"/>.</t>
</section>
<section title="The Transparency Principle" anchor="transparency">
<t> It is not considered practical for a simple DNS proxy to implement all current and
future DNS features.</t>
<t> There are several reasons why this is the case:</t>
<t>
<list style="symbols">
<t> broadband gateways usually have limited hardware resources </t>
<t> firmware upgrade cycles are long, and many users do not routinely apply
upgrades when they become available</t>
<t> no-one knows what those future DNS features will be, nor how they might be
implemented</t>
<t> it would substantially complicate the configuration UI of the device</t>
</list>
</t>
<t> 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.</t>
<t>
<xref target="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.</t>
<t> The rôle 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.</t>
<t> 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.</t>
<t> 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.</t>
</section>
<section title="Protocol Conformance">
<section title="Unexpected Flags and Data" anchor="flags">
<t> The Transparency Principle above, when combined with <xref target="RFC0793"
>Postel's Robustness Principle</xref>, suggests that DNS proxies should not
arbitrarily reject or otherwise drop requests or responses based on perceived
non-compliance with standards.</t>
<t> For example, some proxies have been observed to drop any packet containing
either the "Authentic Data" (AD) or "Checking Disabled" (CD) bits from <xref
target="RFC4035">DNSSEC</xref>. This may be because <xref target="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.</t>
<t> Therefore proxies MUST ignore any unknown DNS flags and proxy those packets as
usual.</t>
</section>
<section title="Label Compression">
<t> Compression of labels as per Section 4.1.4 of <xref target="RFC1035"/> is
optional.</t>
<t> Proxies MUST forward packets regardless of the presence or absence of compressed
labels therein.</t>
</section>
<section title="Unknown Resource Record Types" anchor="unknown">
<t>
<xref target="RFC3597"/> requires that resolvers MUST handle Resource Records
(RRs) of unknown type transparently.</t>
<t> All requests and responses MUST be proxied regardless of the values of the QTYPE
and QCLASS fields.</t>
<t> Similarly all responses MUST be proxied regardless of the values of the TYPE and
CLASS fields of any Resource Record therein.</t>
</section>
<section title="Packet Size Limits">
<t>
<xref target="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 <xref target="tcp"/> and <xref
target="edns0"/>) for transporting responses larger than 512 octets.</t>
<t> 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.</t>
<t> Other proxies have been observed to remove the TC bit in server responses which
correctly had the TC bit set by the server.</t>
<t> If a DNS response is truncated but the TC bit is not set then client failures
may result. In particular a naïve DNS client library might suffer crashes due to
reading beyond the end of the data actually received.</t>
<t>Since UDP packets larger than 512 octets are now expected in normal operation,
proxies SHOULD NOT truncate UDP packets that exceed that size. See <xref
target="ipfrag"/> for recommendations for packet sizes exceeding the WAN
MTU.</t>
<t> 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.</t>
<section title="TCP Transport" anchor="tcp">
<t> 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 <xref target="RFC1123"/>.</t>
<t> 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.</t>
<t> DNS proxies MUST therefore be prepared to receive and forward queries over
TCP.</t>
<t> 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.</t>
<t> 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.</t>
</section>
<section title="Extension Mechanisms for DNS (EDNS0)" anchor="edns0">
<t> The <xref target="RFC2671">Extension Mechanism for DNS</xref> was introduced
to allow the transport of larger DNS packets over UDP and also to allow for
additional request and response flags.</t>
<t> 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.</t>
<t> 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 <xref
target="flags"/> proxies MUST NOT refuse to proxy such packets. </t>
</section>
<section anchor="ipfrag" title="IP Fragmentation">
<t> Support for UDP packet sizes exceeding the WAN MTU depends on the gateway's
algorithm for handling fragmented IP packets. Several methods are possible:</t>
<t>
<list style="numbers">
<t> fragments are dropped</t>
<t> fragments are forwarded individually as they're received </t>
<t> complete packets are reassembled on the gateway, and then
re-fragmented (if necessary) as they're forwarded to the client </t>
</list>
</t>
<t> 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.</t>
<t> 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.</t>
<t> 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.</t>
<t> 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.</t>
</section>
</section>
<section title="Secret Key Transaction Authentication for DNS (TSIG)">
<t>
<xref target="RFC2845"/> defines TSIG, which is a mechanism for authenticating
DNS requests and responses at the packet level.</t>
<t> 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.</t>
<t> DNS proxies MUST implement Section 4.7 of <xref target="RFC2845"/> and either
forward packets unchanged (as recommended above) or fully implement TSIG.</t>
<t> As per <xref target="unknown"/>, DNS proxies MUST be capable of proxying packets
containing <xref target="RFC2930">TKEY</xref> Resource Records.</t>
<t> 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.</t>
</section>
</section>
<section title="DHCP's Interaction with DNS">
<t> Whilst this document is primarily about DNS proxies, most consumers rely on <xref
target="RFC2131">DHCP</xref> 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.</t>
<t> It is therefore appropriate to examine how DHCP affects client DNS configuration.</t>
<section title="Domain Name Server (DHCP Option 6)">
<t> Most gateways default to supplying their own IP address in the DHCP "Domain Name
Server" <xref target="RFC2132">option</xref>. 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. </t>
<t> 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.</t>
<t> 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.</t>
<t> As per <xref target="transparency"/>, 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.</t>
<t> It is therefore RECOMMENDED that gateways SHOULD support device administrator
configuration of values for the "Domain Name Server" DHCP option.</t>
</section>
<section title="Domain Name (DHCP Option 15)">
<t> 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. </t>
<t> 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. </t>
<!-- <t> Where an ISP is sending out pre-configured units to customers they MAY consider
configuring a suitable stub zone (e.g. ".local") on their recursive DNS servers
and using this zone as the configured default. This would mitigate any leakage
of end-users' locally scoped queries to the wider internet.</t> -->
</section>
<section title="DHCP Leases">
<t> 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 servers' addresses once they've been
learnt over the WAN interface.</t>
<t> 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.</t>
<t> 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.</t>
<t> 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.</t>
<t> 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.</t>
<t> 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.</t>
</section>
</section>
<section title="Security Considerations" anchor="security">
<t>This document introduces no new protocols. However there are some security related
recommendations for vendors that are listed here.</t>
<section title="Forgery Resilience">
<t> Whilst DNS proxies are not usually full-feature resolvers they nevertheless
share some characteristics with them.</t>
<t> 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.</t>
<t> 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.</t>
<t> It has been standard guidance for many years that each DNS query should use a
randomly generated Query ID. However many proxies have been observed picking
sequential Query IDs for successive requests.</t>
<t> It is strongly RECOMMENDED that DNS proxies follow the relevant recommendations
in <xref target="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.</t>
<t>If a DNS proxy is running on a broadband gateway with NAT that is compliant with
<xref target="RFC4787"/> then it SHOULD also follow the recommendations in
Section 10 of <xref target="RFC5452"/> concerning how long DNS state is kept.</t>
</section>
<section title="Interface Binding">
<t> 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
<xref target="RFC5358"/>.</t>
<t> The DNS proxy in a gateway SHOULD NOT by default be accessible from the WAN
interfaces of the device.</t>
</section>
<section title="Packet Filtering">
<t> 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.</t>
<t> However a clear distinction may be made between traffic that is intrinsically
malformed and that which merely contains unexpected data.</t>
<t> Examples of malformed packets which MAY be dropped include:</t>
<t>
<list style="symbols">
<t> invalid compression pointers (i.e. those that point outside of the
current packet, or which might cause a parsing loop).</t>
<t> incorrect counts for the Question, Answer, Authority and Additional
Sections (although care should be taken where truncation is a
possibility).</t>
</list>
</t>
<t> Dropped packets will cause the client to repeatedly retransmit the original
request, with the client only detecting the error after several retransmit
intervals.</t>
<t> 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. </t>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document requests no IANA actions.</t>
</section>
<section title="Change Log">
<t>NB: to be removed by the RFC Editor before publication.</t>
<t>draft-ietf-dnsproxy-06pre (from IESG review)<list>
<t>Section 4.1 - cleaned up tautological language and changed SHOULD to MUST
(Adrian Farrel)</t>
<t>Section 4.4.1 - made TCP support mandatory (from Lars Eggert) </t>
<t>Section 4.4.2 - made EDNS0 pass-thru mandatory (from Jari Arkko)</t>
<t>Section 6.3 - clarified rationale for handling errors (from Robert
Sparks)</t>
</list></t>
<t>draft-ietf-dnsproxy-05 <list>
<t>Removed specific reference to 28 byte IP headers (from Mark Andrews)</t>
</list></t>
<t>draft-ietf-dnsproxy-04 - post WGLC<list>
<t>Introduction expanded</t>
<t>Section 5.2 - changed SHOULD to MUST</t>
<t>Section 4.5 - changed SHOULD to MUST (Alex Bligh)</t>
<t>Editorial nits (from Andrew Sullivan, Alfred Hones)</t>
<t>Clarificaton on end-user vs device administrator (Alan Barrett, Paul
Selkirk)</t>
</list></t>
<t>draft-ietf-dnsproxy-03 <list>
<t>Editorial nits and mention of LAN MTU (from Alex Bligh)</t>
</list></t>
<t>draft-ietf-dnsproxy-02 <list>
<t>Changed "router" to "gateway" throughout (David Oran)</t>
<t>Updated forgery resilience reference</t>
<t>Elaboration on bypassability (from Nicholas W.)</t>
<t>Elaboration on NAT source port randomisation (from Nicholas W.)</t>
<t>Mention of using short DHCP leases while the WAN link is down (from Ralph
Droms)</t>
<t>Further clarification on permissibility of altering QID when using TSIG</t>
</list>
</t>
<t>draft-ietf-dnsproxy-01 <list>
<t>Strengthened recommendations about truncation (from Shane Kerr)</t>
<t>New TSIG text (with help from Olafur)</t>
<t>Additional forgery resilience text (from Olafur)</t>
<t>Compression support (from Olafur)</t>
<t>Correction of text re: QID changes and compatibility with TSIG</t>
</list>
</t>
<t>draft-ietf-dnsproxy-00 <list>
<t>Changed recommended DPI error to SERVFAIL (from Jelte)</t>
<t>Changed example for invalid compression pointers (from Wouter).</t>
<t>Note about TSIG implications of changing Query ID (from Wouter).</t>
<t>Clarified TC-bit text (from Wouter)</t>
<t>Extra text about proxy bypass (Nicholas W.)</t>
</list>
</t>
<t>draft-bellis-dnsproxy-00 <list>
<t>Initial draft</t>
</list>
</t>
</section>
<section title="Acknowledgements">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References"> &rfc793; &rfc1035; &rfc1123;
&rfc2119; &rfc4035; &rfc2131; &rfc2132; &rfc2671; &rfc2845;
&rfc2930; &rfc3597; &rfc4787; &rfc5358; &rfc5452; </references>
<references title="Informative References">
<reference anchor="SAC035" target="http://www.icann.org/committees/security/sac035.pdf">
<front>
<title>Test Report: DNSSEC Impact on Broadband Routers and Firewalls</title>
<author fullname="Ray Bellis" initials="R" surname="Bellis">
<organization>Nominet UK</organization>
</author>
<author fullname="Lisa M. Phifer" initials="L.M." surname="Phifer">
<organization>Core Competence</organization>
</author>
<date day="16" month="September" year="2008"/>
</front>
</reference>
<reference anchor="DOTSE" target="http://www.iis.se/docs/Routertester_en.pdf">
<front>
<title>DNSSEC Tests of Consumer Broadband Routers</title>
<author fullname="Joakim Ahlund" surname="Ahlund">
<organization>.SE</organization>
</author>
<author fullname="Patrik Wallstrom" surname="Wallstrom">
<organization>.SE</organization>
</author>
<date day="26" month="February" year="2008"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:37:53 |