Saturday 7 December 2013

RFC 5625 : DNS Proxy Implementation Guidelines

 DNS Proxy RFC


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

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

3)  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

4) DNS proxies should not arbitrarily reject or otherwise drop requests
     or responses based on perceived non-compliance with standards.

5) Since UDP packets larger than 512 octets are now expected in normal
   operation, proxies SHOULD NOT truncate UDP packets that exceed that

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

7) Proxies SHOULD be capable of forwarding UDP packets up to a payload
   size of at least 4096 octets.

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

9)  It is therefore RECOMMENDED that gateways SHOULD support device-
   administrator configuration of values for the "Domain Name Server"
   DHCP option

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

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

12) The DNS proxy in a gateway SHOULD NOT, by default, be accessible from the WAN interfaces of the device.


1)  Proxies MUST ignore any unknown DNS flags and proxy
   packets as usual.

2)  Proxies MUST forward packets regardless of the presence or absence of compressed labels therein. (
   Compression of labels as per Section 4.1.4 of [RFC1035]

3) [RFC3597] requires that resolvers MUST handle Resource Records (RRs)
   of unknown type transparently.

 4)  All requests and responses MUST be proxied regardless of the values
   of the QTYPE and QCLASS fields.

5)  All responses MUST be proxied regardless of the values of the TYPE and CLASS fields of any Resource Record therein.

6)  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

7) DNS proxies MUST therefore be prepared to receive and forward queries
   over TCP.

8) As per Section 4.1, proxies MUST NOT refuse to proxy such packets which contain an OPT RR

9)   DNS proxies MUST implement Section 4.7 of [RFC2845] and either
   forward packets unchanged (as recommended above) or fully implement

10)    As per Section 4.3, DNS proxies MUST be capable of proxying packets
   containing TKEY [RFC2930] Resource Records.

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

Key words for use in RFCs to Indicate Requirement Levels :

 This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

 This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.