[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          R. Bellis
Internet-Draft                                                Nominet UK
Intended status: Standards Track                                A. Bligh
Expires: April 18, 2010                       Silverscale Associates Ltd
                                                           W. Wijngaards
                                                              NLnet Labs
                                                        October 15, 2009


       DNS Proxy Bypass by Recursive DNS Discovery and LOCAL.ARPA
                draft-bellis-dns-recursive-discovery-00

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 April 18, 2010.

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, et al.           Expires April 18, 2010                 [Page 1]


Internet-Draft              DNS Proxy Bypass                October 2009


Abstract

   This document describes a method for a DNS client resolver to
   discover the IP addresses of the upstream recursive DNS resolvers and
   hence bypass the local DNS proxy.  It also directs IANA to reserve
   the "LOCAL.ARPA" domain name and to create a registry for well known
   sub-domains of that domain name, such sub-domains being reserved for
   use within any network's administrative boundary.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3

   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4

   3.  LOCAL.ARPA  . . . . . . . . . . . . . . . . . . . . . . . . . . 4

   4.  DOMAIN.LOCAL.ARPA - Server behaviour  . . . . . . . . . . . . . 4

   5.  DOMAIN.LOCAL.ARPA - Client Behaviour  . . . . . . . . . . . . . 5

   6.  LOCAL.ARPA - Proxy behaviour  . . . . . . . . . . . . . . . . . 6

   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7

   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7

   9.  IAB Considerations  . . . . . . . . . . . . . . . . . . . . . . 8

   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 8
     10.2.  Informative References . . . . . . . . . . . . . . . . . . 8

   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . . . 8

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9














Bellis, et al.           Expires April 18, 2010                 [Page 2]


Internet-Draft              DNS Proxy Bypass                October 2009


1.  Introduction

   Client DNS resolvers [RFC1035] usually must send their queries to a
   recursive resolver which performs the iterative lookups on the
   client's behalf and returns the complete result, often from a local
   cache.

   However, particularly in consumer and small office networks, the
   client resolver often does not talk directly to a recursive resolver.
   A very common configuration is that the client talks to a 'proxy'
   embedded in their local internet access gateway which acts as a
   simple intermediary between the client and the recursive servers.
   The term 'proxy' is used within this document to indicate any device
   to which the queries generated by the client resolver are addressed
   at an IP level; as such they may include devices such as NAT devices,
   firewalls, and DSL gateways.

   This configuration is a side-effect of the need for the DHCP server
   embedded in such gateways to issue DNS server addresses before those
   addresses have been learnt from the upstream network (see Section 5.3
   of [RFC5625]).

   These proxies have however been found to be generally deficient in
   their implementation of the DNS protocols (see [SAC035], [RFC5625]),
   to the extent that modern DNS extensions may fail to work correctly.
   Common problems include failure to deal properly with large DNS
   packets (including poor support for EDNS0 (ref), poor support for IP
   fragments, and truncation due to apparent buffer size limitations),
   and failure to deal with unknown RR types.

   Thus, whilst the devices may appear to be functional for standard DNS
   protocols, they may fail to properly process all queries, in
   particular DNSSEC [RFC4033] queries, which use RR types that the
   device concerned may not understand, and typically have larger
   responses.  Field tests indicate that such devices are in general far
   more competent at passing through DNS queries addressed directly to
   the recursive resolvers (and the replies to such queries) than they
   are at processing queries addressed directly to them.

   This document therefore proposes a method whereby a client resolver
   may discover the IP addresses of the intended recursive resolvers
   such that subsequent queries may be sent directly to those resolvers
   without passing through the gateway's DNS proxy.

   To support this method IANA are directed to reserve a new domain name
   ("LOCAL.ARPA") which is not present in the .ARPA zone file but exists
   only on the recursive DNS servers local to the client stub resolver
   concerned.  IANA are also redirected to create a registry of well



Bellis, et al.           Expires April 18, 2010                 [Page 3]


Internet-Draft              DNS Proxy Bypass                October 2009


   known sub-domains of "LOCAL.ARPA", and this document further directs
   IANA to record "DOMAIN.LOCAL.ARPA" in that registry.


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.  LOCAL.ARPA

   This document reserves "LOCAL.ARPA" for infrastructure use within the
   administrative boundaries of a local network.  A local network for
   these purposes means, in respect of a given recursive DNS server, all
   those hosts which are permitted to use that server to make recursive
   queries.  The exact boundaries of a local network are implementation
   dependent;.  It could be a corporate network, but it could also be an
   ISP access network including all of the customer networks connected
   to it.

   This domain name serves as an anchor point for the discovery of well
   known services within a network.  Whilst other technologies have been
   described for the discovery of services belonging to a specific
   domain (TODO: DNS-SD ref), the intent of "LOCAL.ARPA" is to support
   discovery of services on the current local network (dependent on
   which recursive nameserver it queries), regardless of the local
   domain name(s).

   Note that like "SINK.ARPA" (see [I-D.jabley-sink-arpa], this domain
   name MUST NOT actually appear in the IANA maintained zone file for
   .ARPA.  Queries for this domain name (and by extension any sub-domain
   thereof) which leak beyond the local network onto the global internet
   MUST receive an NXDOMAIN (RCODE == 3) response.


4.  DOMAIN.LOCAL.ARPA - Server behaviour

   A recursive server implementing this standard, in response to an A or
   AAAA query for the QNAME "DOMAIN.LOCAL.ARPA" MUST do exactly one of
   the following (subject to the normal situations where the server is
   permitted to return an error):

   (a) return a response containing a list of one or more A or AAAA
   records for the QNAME each of which is an IP address for a recursive
   name server that is configured to support recursive DNS lookups by
   the client which sent the initial query.  The server MAY



Bellis, et al.           Expires April 18, 2010                 [Page 4]


Internet-Draft              DNS Proxy Bypass                October 2009


   algorithmically generate such records; for instance, it may return
   one or more of its own IP addresses, for instance the destination IP
   address of the query packet it received or (after appropriate
   sanitisation to ensure the client can query them) a list of IP
   addresses of its own interfaces

   (b) return a CNAME record which, if followed, will yield a list as
   set out in (a) above.  The server MAY algorithmically generate the
   CNAME record, for instance to encode the querying IP address within
   it in an implementation dependent manner.  OR

   (c) return NXDOMAIN, without performing a query to the .ARPA
   nameservers.

   A recursive server not implementing this standard will normally
   recursively query the .ARPA nameservers, which will result in an
   NXDOMAIN, which will be cached for future queries.

   An example of how a network operator running the Unbound recursive
   resolver might configure this is as follows:

         local-zone: "local.arpa."  static
         local-data: "domain.local.arpa. 3600 IN A 192.0.2.1"
         local-data: "domain.local.arpa. 3600 IN A 192.0.2.2"
         local-data: "domain.local.arpa. 3600 IN AAAA 2001:db8::1"

   indicating (for the IPv4 case) that recursive resolvers may be found
   at 192.0.2.1 and 192.0.2.2.


5.  DOMAIN.LOCAL.ARPA - Client Behaviour

   Typically when the DNS client is first started it will use DNS
   settings obtained via a DHCP lease which contains the IP address of
   the local internet access gateway in the Domain Name Server Option
   (6).

   The DNS client resolver bootstrapped (whether as above using DHCP or
   otherwise) would send the query via its local DNS proxy, and receive
   a new list of DNS servers.

   Queries for A or AAAA records will as set out above either return
   NXDOMAIN (in the case where the recursive server does not support
   this standard, or where support is present but not configured), or an
   error code, or a list of A records or a CNAME which when followed
   will yield a list of A records.  The list of A records however
   obtained will contain one or more IP addresses corresponding to
   recursive name servers that are configured to support recursive DNS



Bellis, et al.           Expires April 18, 2010                 [Page 5]


Internet-Draft              DNS Proxy Bypass                October 2009


   lookups by the client which sent the initial query.

   Client resolvers supporting this standard MUST be capable of
   following CNAMEs and MUST follow any CNAME returned in response to a
   query for "DOMAIN.LOCAL.ARPA".

   If the client receives an NXDOMAIN, this indicates that the recursive
   server concerned does not support or is not configured to support
   this standard.  The client MAY continue to use its currently
   configured DNS server IP addresses.  It MAY repeat the query, but it
   MUST NOT issue such a repeat query for "DOMAIN.LOCAL.ARPA" for [60
   seconds].

   If the client receives an error or no response, this may be because
   the proxy does not have internet connectivity.  The client MAY repeat
   the query, but it MUST NOT issue such a repeat query for
   "DOMAIN.LOCAL.ARPA" for [1 second]

   If the client receives a list of one or more A or AAAA records, the
   client MAY then use these IP addresses as the destination for
   subsequent recursive DNS lookup queries in preference to those issued
   by the local DHCP server or otherwise configured.

   If the A or AAAA records have a non-zero TTL, the client SHOULD treat
   the records as invalid after the TTL has expired.  The client MAY
   make repeat queries but SHOULD NOT make such repeat queries until
   half the TTL returned has expired.


6.  LOCAL.ARPA - Proxy behaviour

   Proxies MUST NOT intercept queries to "LOCAL.ARPA" or its subdomains.
   In particular, proxies MUST NOT return NXDOMAIN or A, AAAA or CNAME
   records for queries to "LOCAL.ARPA" or its subdomains unless such a
   response is sent to the proxy by a recursive nameserver.  A proxy for
   this purpose does not include a device which performs a full
   recursive caching nameservice which is compliant with EDNS0
   [RFC2671], DNSSEC, TCP support and is fully capable of handling
   maximum size UDP packets whether fragmented on not.

   A proxy MAY return SERVFAIL if it is aware it has no connectivity to
   a recursive nameserver without attempting to forward the packet
   concerned.  For instance if the proxy device is a DSL access gateway
   and the DSL line by which it would reach the recursive server is
   down.

   A proxy MUST pass UDP and TCP requests (and their responses) to
   recursive servers transparently and unmolested.  This means that



Bellis, et al.           Expires April 18, 2010                 [Page 6]


Internet-Draft              DNS Proxy Bypass                October 2009


   proxies MUST reassemble UDP fragments.  As the proxy may find it hard
   to detect which packets are addressed to or from the recursive
   nameserver, this might be achieved by applying similar considerations
   to all packets.

   It is recognised that proxies which assiduously follow this section
   are unlikely to be the proxies which gave rise to the need for this
   standard.


7.  Security Considerations

   TODO


8.  IANA Considerations

   This document directs the IANA to add the following record to the
   ARPA Reserved Names Registry [I-D.jabley-sink-arpa]:

   +------------+----------------------+---------+---------------------+
   | Name       | Purpose              | RRTypes | Reference           |
   +------------+----------------------+---------+---------------------+
   | LOCAL.ARPA | Locally administered | NONE    | This document       |
   |            | infrastructure       |         | (RFCXXXX)  S. 3     |
   +------------+----------------------+---------+---------------------+

   This document further directs the IANA to create a new registry as
   follows:

   +-------------------------+-----------------------------------------+
   | Parameter               | Value                                   |
   +-------------------------+-----------------------------------------+
   | Registry Name           | ARPA Reserved Local Names               |
   |                         |                                         |
   | Reference               | This document (RFCXXXX) Section 3       |
   |                         |                                         |
   | Registration Procedures | IETF Standards Action                   |
   +-------------------------+-----------------------------------------+

   with initial contents as follows:

   +------------+---------------------+----------+---------------------+
   | Name       | Purpose             | RRTypes  | Reference           |
   +------------+---------------------+----------+---------------------+
   | DOMAIN     | Recursive DNS       | A / AAAA | This document       |
   |            | Discovery           |          | (RFCXXXX)  S. 4     |
   +------------+---------------------+----------+---------------------+



Bellis, et al.           Expires April 18, 2010                 [Page 7]


Internet-Draft              DNS Proxy Bypass                October 2009


9.  IAB Considerations

   The addition of "LOCAL.ARPA" to the ARPA Reserved Names Registry
   requires IAB approval.

   Note that addition of sub-domains of "LOCAL.ARPA" to the ARPA
   Reserved Local Names Registry only requires IETF Standards Action.


10.  References

10.1.  Normative References

   [I-D.jabley-sink-arpa]
              Abley, J. and O. Gudmundsson, "The Eternal Non-Existence
              of SINK.ARPA (and other stories)",
              draft-jabley-sink-arpa-00 (work in progress), May 2009.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
              BCP 152, RFC 5625, August 2009.

10.2.  Informative References

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [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>.


Appendix A.  Change Log

   NB: to be removed by the RFC Editor before publication.

   draft-bellis-dns-recursive-discovery-00





Bellis, et al.           Expires April 18, 2010                 [Page 8]


Internet-Draft              DNS Proxy Bypass                October 2009


      Initial draft


Authors' Addresses

   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/


   Alex Bligh
   Silverscale Associates Ltd
   15 Elsynge Road
   London  SW18 2HW
   United Kingdom

   Phone: +44 20 8812 3300
   Email: alex@alex.org.uk


   Wouter Wijngaards
   NLnet Labs
   Science Park 140
   Amsterdam  1098 XG
   The Netherlands

   Email: wouter@nlnetlabs.nl


















Bellis, et al.           Expires April 18, 2010                 [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/