DNS Proxy Implementation Guidelines
RFC 5625

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

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.