DNS Proxy Implementation Guidelines

Research has found (, ) 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.

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 .

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: broadband gateways usually have limited hardware resources firmware upgrade cycles are long, and many users do not routinely apply upgrades when they become available no-one knows what those future DNS features will be, nor how they might be implemented 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. 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 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. 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.

The Transparency Principle above, when combined with Postel's Robustness Principle, 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. This may be because 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.

Compression of labels as per Section 4.1.4 of is optional. Proxies MUST forward packets regardless of the presence or absence of compressed labels therein.

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.

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 and ) 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 naïve 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 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.

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 . 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.

The Extension Mechanism for DNS 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 proxies SHOULD NOT refuse to proxy such packets.

Support for UDP packet sizes exceeding the WAN MTU depends on the gateway's algorithm for handling fragmented IP packets. Several methods are possible: fragments are dropped fragments are forwarded individually as they're received 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 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.

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 and either forward packets unchanged (as recommended above) or fully implement TSIG. As per , DNS proxies MUST be capable of proxying packets containing TKEY 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.

Whilst this document is primarily about DNS proxies, most consumers rely on DHCP 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 configuration.

Most gateways default to supplying their own IP address in the DHCP "Domain Name Server" option. 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 , 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.

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.

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. 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.

This document introduces no new protocols. However there are some security related recommendations for vendors that are listed here.

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 been observed picking sequential Query IDs for successive requests. It is strongly RECOMMENDED that DNS proxies follow the relevant recommendations in , 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 then it SHOULD also follow the recommendations in Section 10 of concerning how long DNS state is kept.

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 . The DNS proxy in a gateway SHOULD NOT by default be accessible from the WAN interfaces of the device.

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: invalid compression pointers (i.e. those that point outside of the current packet, or which might cause a parsing loop). 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.

This document requests no IANA actions.

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) Extra text about proxy bypass (Nicholas W.) draft-bellis-dnsproxy-00 Initial draft

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.