Network Working Group                                            P. Koch
Internet-Draft                                                  DENIC eG
Intended status: Informational                         November 12, 2013
Expires: May 16, 2014

    Confidentiality Aspects of DNS Data, Publication, and Resolution


   This document describes aspects of DNS data confidentiality in the
   light of recent IETF discussions on pervasive monitoring.  It focuses
   on potential information leaks rather than prescribing methods of

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

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

   This Internet-Draft will expire on May 16, 2014.

Copyright Notice

   Copyright (c) 2013 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.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Koch                      Expires May 16, 2014                  [Page 1]

Internet-Draft             DNS Confidentiality             November 2013

1.  Introduction

   The Domain Name System (DNS) [RFC1034] [RFC1035] is the Internet's
   primary name lookup system.  It consists of a publication aspect,
   represented by authoritative name servers providing access to DNS
   data covering parts of the DNS tree in units of zones, and a
   resolution aspect.  The latter consists of applications that initite
   DNS requests, DNS stub resolvers and DNS full resolvers (sometimes
   also called recursive resolvers or recursive name servers).
   Resolvers might be chained using a forwarding mechanism.  In today's
   reality, there is a variety of intercepting DNS proxies and other
   middle boxes which are currently out of scope but may be addressed in
   future versions of this memo.

   Threats to the DNS are described in [RFC3833] and have been addressed
   by DNSSEC [RFC4033] [RFC4034] [RFC4035], both to the extent that data
   origin authentication is concerned.  Confidentiality was not a DNSSEC
   design goal, although in subsequent discussion that eventually led to
   the specification and deployment of NSEC3 [RFC5155], confidentiality
   of zone content was a major issue.

1.1.  The alleged public nature of DNS data

   It has long been claimed that "the data in the DNS is public".  While
   this sentence makes sense for an Internet wide lookup system, there
   are multiple facets to data and meta data that deserve a more
   detailed look.  First, access control lists and private name spaces
   nonwithstanding, the DNS operates under the assumption that public
   facing authoritative name servers will respond to "usual" DNS queries
   for any zone they are authoritative for without further
   authentication or authorization of the client (resolver).  A DNS
   query consists of QNAME, QCLASS and QTYPE.  Due to the lack of search
   capabilities, only a given QNAME will reveal the resource records
   associated with that name (or that name's non existence).  In other
   words: one needs to know what to ask for to receive a response.  The
   zone transfer QTYPE [RFC5936] is often blocked or restricted to
   authenticated/authorized access to enforce this difference (and maybe
   for other, more dubious reasons).

   Another differentiation to be applied is between the DNS data as
   mentioned above and a particular transaction, most prominently but
   not limited to a DNS name lookup.  The fact that the results of a DNS
   query are public within the boundaries described in the previous
   paragraph and therefore might have no confidentiality requirements
   does not imply the same for a single or a sequence of transactions.
   Any transaction has meta data associated with the query data, e.g., a
   source address and a timestamp.

Koch                      Expires May 16, 2014                  [Page 2]

Internet-Draft             DNS Confidentiality             November 2013

1.2.  Disclaimer

   The practices listed in this document appear only to support an
   informed discussion.  Their presence (or absence) does not imply any
   form of support, engagement, applicability, appropriateness, fitness,
   or stance on legal status.

2.  DNS Element walk through

   This section will address the specific confidentiality issues of
   verious elements of the DNS ecosystem.  We will start at the
   authoritative servers, leaving the provisioning side out of scope,
   cover the resolution and recursive resolvers and finally address DNS
   queries at large and packet capturing.

2.1.  Authoritative Name Servers

   DNS zone data is published by authoritative name servers.  Starting
   at the primary master, zone data is transfered in full (AXFR) or
   increments (IXFR) to secondary servers along the XFR dependency
   graph.  The zone data thereby is inevitably revealed to any of the
   authoritative servers.  Some zones, including the DNS root zone, are
   deliberatly published by methods other than DNS AXFR.

   While client as well as server authentication and data integrity are
   usually achieved by TSIG [RFC2845], there is no DNS protocol feature
   that provides zone transfer confidentiality.  However, VPNs or other
   private arrangements are occasionally used.  [RFC2182] is the most
   recent IETF document potentially dealing with this issue.

2.2.  DNS Name Resolution

   Since the communication between an application and the local resolver
   or between the local (stub) resolver and a full recursive resolver is
   rarely authenticated, DNS queries can and hve been redirected.  This
   has mostly been done with the malicius intent to inject forged
   responses, but could also be used as a man-in-the-middle (MITM)
   attack to learn a particular system's DNS queries and the response

   The same queries (and responses) could be captured on the wire, even
   on the way to (and from) the correct, intended full resolver.
   Usually it has been assumed that the DNS resolution would not add
   additional intelligence given that subsequent communication would
   most likely reveal more than the DNS lookup.  However, with recent
   suggestions to encrypt, say, web (HTTP) and mail (SMTP) connections,
   the DNS information could be of increased interest, disclosing
   otherwise unavailable information.

Koch                      Expires May 16, 2014                  [Page 3]

Internet-Draft             DNS Confidentiality             November 2013

   Operators of recursive resolvers could collect and examine queries
   directed to their systems.

   The content of resolvers can reveal data about the clients using it.
   This information can sometimes be examined by sending DNS queries
   with RD=0 to inspect cache content, particularly looking at the DNS
   TTLs.  Since this also is a reconnaissance technique for subsequent
   cache poisoning attacks, some counter measures have already been
   developed and deployed.

2.3.  DNS Queries

   DNS queries are initiated by an application handed over to a stub
   resolver, sometimes involving a host dependent name caching mechanism
   that is out of scope of this document.  They consist of a QNAME,
   QCLASS and QTYPE, a DNS query ID and other parameters at the IP or
   transport layer.  Among those are an IP source address, an IP ID and
   a source port number [RFC5452].  While some of these parameters have
   received increased attention due to their significance for DNS
   response spoofing mitigation, they do not contribute to
   confidentiality and may in fact deliver additional intelligence by
   supportig correlation of multiple queries from one system or even a
   single process or application at the same source.  This is sometimes
   used in resolver software fingerprinting or behavioural analysis.

   The source address in a DNS query is necessary to direct the
   response, but it may help to identify the requesting entity, be that
   a system, a process or an end user.  For recursive resolvers it is
   sometimes argued that the size of the population 'behind' that
   resolver contributes to the noise.  However, a private extension
   [I-D.vandergaast-edns-client-subnet] exists that will disclose the
   source address, or some prefix of the source address to the receiver,
   usually an authoritative name server.

   The QNAME itself will be an existing or a non existing domain name.
   With reference to the earlier discussion of the public (or not)
   nature of DNS data, the response may reveal information.  More
   importantly, due to the use of search paths [RFC1535] the QNAME may
   also disclose information relative to the querying entity:

Koch                      Expires May 16, 2014                  [Page 4]

Internet-Draft             DNS Confidentiality             November 2013

   For parts of the domain name tree that more deeply enjoy the
   hierarchic nature of the DNS, like the IPv6 reverse delegation
   [RFC3596] or ENUM [RFC6116], the query name itself, asked for at a
   particular time, may disclose related, either ongoing or subsequent
   communication.  This is partly due to the fact that the DNS treats
   the QNAME in full all the time.

   Attempts have been made to encrypt the resource record RDATA

2.4.  DNS Packet Capturing

   Both ephemeral and long term DNS captures have become DNS operational
   practice [DITL1] [DITL2].  Taking these packet traces usually occurs
   close to the authoritative servers, packets being captuered on the
   wire, but under the control of the endpoint operator.

   Initially designed to reconstruct DNS zone content from query
   response data, passive DNS [FW2005] has evolved into a widely used
   tool.  These traces are usually sourced by on the wire traffic
   between recursive resolver and authoritative server.

3.  Security Considerations

   This document does not define a new protocol.  It deals with
   confidentiality issues of the current DNS protocol and operations.

4.  IANA Considerations

   This document does not propose any new IANA registry nor does it ask
   for any allocation from an existing IANA registry.

5.  Acknowledgements

   This document was inspired by discussion with Wouter Wijngaards and
   Alexander Mayrhofer.  Stephane Bortzmeyer and Nathalie Boulvard
   raised the issue of packet captures at a CENTR workshop.  Jonathan
   Spring triggered some thoughts on the same topic.

6.  References

6.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

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

Koch                      Expires May 16, 2014                  [Page 5]

Internet-Draft             DNS Confidentiality             November 2013

   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
              July 1997.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.

   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
              Name System (DNS)", RFC 3833, August 2004.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, March 2008.

   [RFC5936]  Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, June 2010.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973, July

6.2.  Informative References

   [DITL1]    CAIDA, "A Day in the Life of the Internet (DITL)", 2011.

   [DITL2]    DNS-OARC, "DITL Traces and Analysis", 2013.

   [FW2005]   Weimer, F., "Passive DNS Replication", FIRST 17, April

              Timms, B., Reid, J., and J. Schlyter, "IANA Registration
              for Encrypted ENUM", draft-timms-encrypt-naptr-01 (work in
              progress), July 2008.

              Contavalli, C., Gaast, W., Leach, S., and E. Lewis,
              "Client Subnet in DNS Requests", draft-vandergaast-edns-
              client-subnet-02 (work in progress), July 2013.

   [RFC1535]  Gavron, E., "A Security Problem and Proposed Correction
              With Widely Deployed DNS Software", RFC 1535, October

Koch                      Expires May 16, 2014                  [Page 6]

Internet-Draft             DNS Confidentiality             November 2013

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", RFC 3596,
              October 2003.

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

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
              Resilient against Forged Answers", RFC 5452, January 2009.

   [RFC6116]  Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
              Uniform Resource Identifiers (URI) Dynamic Delegation
              Discovery System (DDDS) Application (ENUM)", RFC 6116,
              March 2011.

Appendix A.  Document Revision History

   This section is to be removed should the draft be published.

   $Id: draft-koch-perpass-dns-confidentiality.xml,v 1.1 2013/11/12
   09:29:48 pk Exp $

A.1.  Initial Document

   First draft

Author's Address

   Peter Koch
   Kaiserstrasse 75-77
   Frankfurt  60329

   Phone: +49 69 27235 0
   Email: pk@DENIC.DE

Koch                      Expires May 16, 2014                  [Page 7]