Network Working Group R. Bellis
Request for Comments: 5625 Nominet UK
BCP: 152 August 2009
Category: Best Current Practice
DNS Proxy Implementation Guidelines
Abstract
This document provides guidelines for the implementation of DNS
proxies, as found in broadband gateways and other similar network
devices.
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
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.
Bellis Best Current Practice [Page 1]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
Table of Contents
1. Introduction ....................................................2
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 ..............................4
4.4. Packet Size Limits .........................................4
4.4.1. TCP Transport .......................................5
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) .........................7
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. Acknowledgements ...............................................10
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................12
1. Introduction
Research has found ([SAC035], [DOTSE]) that many commonly used
broadband gateways (and similar devices) contain DNS proxies that 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.
Bellis Best Current Practice [Page 2]
RFC 5625 DNS Proxy Implementation Guidelines August 2009
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.