DNS Proxy RFC http://tools.ietf.org/html/rfc5625
Should
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
way.
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
size.
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.
Must:
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
responses.
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
TSIG.
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
http://tools.ietf.org/html/rfc2119 :
1. MUST
This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
2. SHOULD
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.
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
way.
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
size.
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.
Must:
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
responses.
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
TSIG.
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
http://tools.ietf.org/html/rfc2119 :
1. MUST
This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
2. SHOULD
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.
