--- /dev/null
+
+
+
+DNSEXT R. Bellis
+Internet-Draft Nominet UK
+Intended status: BCP April 23, 2009
+Expires: October 25, 2009
+
+
+ DNS Proxy Implementation Guidelines
+ draft-ietf-dnsext-dnsproxy-05
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on October 25, 2009.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+Abstract
+
+ This document provides guidelines for the implementation of DNS
+ proxies, as found in broadband gateways and other similar network
+ devices.
+
+
+
+Bellis Expires October 25, 2009 [Page 1]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+
+ 3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3
+
+ 4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4
+ 4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4
+ 4.2. Label Compression . . . . . . . . . . . . . . . . . . . . 4
+ 4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 5
+ 4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5
+ 4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 6
+ 4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6
+ 4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6
+ 4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7
+
+ 5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7
+ 5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 8
+ 5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8
+ 5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8
+
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9
+ 6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 10
+ 6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10
+
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
+
+ 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis Expires October 25, 2009 [Page 2]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+1. Introduction
+
+ Research has found ([SAC035], [DOTSE]) 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.
+
+
+2. Terminology
+
+ 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 [RFC2119].
+
+
+3. The Transparency Principle
+
+ 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:
+
+ o broadband gateways usually have limited hardware resources
+ o firmware upgrade cycles are long, and many users do not routinely
+ apply upgrades when they become available
+ o no-one knows what those future DNS features will be, nor how they
+ might be implemented
+ o 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.
+
+
+
+Bellis Expires October 25, 2009 [Page 3]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+ [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.
+
+ 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.
+
+ 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.
+
+
+4. Protocol Conformance
+
+4.1. Unexpected Flags and Data
+
+ The Transparency Principle above, when combined with Postel's
+ Robustness Principle [RFC0793], 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 [RFC4035]. This may be because [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.
+
+ Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown
+ DNS flags and proxy those packets as usual.
+
+4.2. Label Compression
+
+ Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
+
+
+
+
+Bellis Expires October 25, 2009 [Page 4]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+ Proxies MUST forward packets regardless of the presence or absence of
+ compressed labels therein.
+
+4.3. Unknown Resource Record Types
+
+ [RFC3597] 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.
+
+4.4. Packet Size Limits
+
+ [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 Section 4.4.1 and Section 4.4.2) 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 naive 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 Section 4.4.3 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.
+
+
+
+
+
+
+
+Bellis Expires October 25, 2009 [Page 5]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+4.4.1. TCP Transport
+
+ 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 [RFC1123].
+
+ 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.
+
+4.4.2. Extension Mechanisms for DNS (EDNS0)
+
+ The Extension Mechanism for DNS [RFC2671] 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 Section 4.1 proxies SHOULD NOT refuse to proxy such packets.
+
+4.4.3. IP Fragmentation
+
+ Support for UDP packet sizes exceeding the WAN MTU depends on the
+ gateway's algorithm for handling fragmented IP packets. Several
+ methods are possible:
+
+ 1. fragments are dropped
+ 2. fragments are forwarded individually as they're received
+ 3. complete packets are reassembled on the gateway, and then re-
+ fragmented (if necessary) as they're forwarded to the client
+
+
+
+
+Bellis Expires October 25, 2009 [Page 6]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+ 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.
+
+4.5. Secret Key Transaction Authentication for DNS (TSIG)
+
+ [RFC2845] 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 [RFC2845] and either
+ forward packets unchanged (as recommended above) or fully implement
+ TSIG.
+
+ As per Section 4.3, DNS proxies MUST be capable of proxying packets
+ containing TKEY [RFC2930] 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.
+
+
+5. DHCP's Interaction with DNS
+
+ Whilst this document is primarily about DNS proxies, most consumers
+ rely on DHCP [RFC2131] 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
+
+
+
+Bellis Expires October 25, 2009 [Page 7]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+ configuration.
+
+5.1. Domain Name Server (DHCP Option 6)
+
+ Most gateways default to supplying their own IP address in the DHCP
+ "Domain Name Server" option [RFC2132]. 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 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.
+
+ It is therefore RECOMMENDED that gateways SHOULD support device
+ administrator configuration of values for the "Domain Name Server"
+ DHCP option.
+
+5.2. Domain Name (DHCP Option 15)
+
+ 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.
+
+5.3. DHCP Leases
+
+ 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
+
+
+
+Bellis Expires October 25, 2009 [Page 8]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+ 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.
+
+
+6. Security Considerations
+
+ This document introduces no new protocols. However there are some
+ security related recommendations for vendors that are listed here.
+
+6.1. Forgery Resilience
+
+ 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
+
+
+
+Bellis Expires October 25, 2009 [Page 9]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+ been observed picking sequential Query IDs for successive requests.
+
+ 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.
+
+ 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.
+
+6.2. Interface Binding
+
+ 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 [RFC5358].
+
+ The DNS proxy in a gateway SHOULD NOT by default be accessible from
+ the WAN interfaces of the device.
+
+6.3. Packet Filtering
+
+ 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:
+
+ o invalid compression pointers (i.e. those that point outside of the
+ current packet, or which might cause a parsing loop).
+ o 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.
+
+
+
+
+
+
+Bellis Expires October 25, 2009 [Page 10]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+7. IANA Considerations
+
+ This document requests no IANA actions.
+
+
+8. Change Log
+
+ 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)
+
+
+
+
+
+Bellis Expires October 25, 2009 [Page 11]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+ Extra text about proxy bypass (Nicholas W.)
+
+ draft-bellis-dnsproxy-00
+ Initial draft
+
+
+9. Acknowledgements
+
+ 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.
+
+
+10. References
+
+10.1. Normative References
+
+ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, September 1981.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
+ and Support", STD 3, RFC 1123, October 1989.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
+ RFC 2131, March 1997.
+
+ [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+ Extensions", RFC 2132, March 1997.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+ RFC 2671, August 1999.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", RFC 2845, May 2000.
+
+ [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
+ RR)", RFC 2930, September 2000.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+
+
+
+Bellis Expires October 25, 2009 [Page 12]
+\f
+Internet-Draft DNS Proxy Implementation Guidelines April 2009
+
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
+ (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+ RFC 4787, January 2007.
+
+ [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
+ Nameservers in Reflector Attacks", BCP 140, RFC 5358,
+ October 2008.
+
+ [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
+ Resilient against Forged Answers", RFC 5452, January 2009.
+
+10.2. Informative References
+
+ [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
+ Routers", February 2008,
+ <http://www.iis.se/docs/Routertester_en.pdf>.
+
+ [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
+ Broadband Routers and Firewalls", September 2008,
+ <http://www.icann.org/committees/security/sac035.pdf>.
+
+
+Author's Address
+
+ Ray Bellis
+ Nominet UK
+ Edmund Halley Road
+ Oxford OX4 4DQ
+ United Kingdom
+
+ Phone: +44 1865 332211
+ Email: ray.bellis@nominet.org.uk
+ URI: http://www.nominet.org.uk/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis Expires October 25, 2009 [Page 13]
+\f
projects / thirdparty / bind9.git / commitdiff
