DNS Proxy Implementation Guidelines
RFC 5625
Document | Type |
RFC - Best Current Practice
(August 2009; No errata)
Also known as BCP 152
|
|
---|---|---|---|
Author | Ray Bellis | ||
Last updated | 2015-10-14 | ||
Replaces | draft-bellis-dnsext-dnsproxy | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5625 (Best Current Practice) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ralph Droms | ||
Send notices to | (None) |
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. 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 or how they might be implemented. o Doing so would substantially complicate the configuration user interface (UI) of the device.Show full document text