Internet DRAFT - draft-koch-perpass-dns-confidentiality
draft-koch-perpass-dns-confidentiality
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
draft-koch-perpass-dns-confidentiality-00
Abstract
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
mitigation.
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 http://datatracker.ietf.org/drafts/current/.
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
(http://trustee.ietf.org/license-info) 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
content.
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:
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.
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
[I-D.timms-encrypt-naptr].
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
2013.
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
2005.
[I-D.timms-encrypt-naptr]
Timms, B., Reid, J., and J. Schlyter, "IANA Registration
for Encrypted ENUM", draft-timms-encrypt-naptr-01 (work in
progress), July 2008.
[I-D.vandergaast-edns-client-subnet]
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
1993.
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
DENIC eG
Kaiserstrasse 75-77
Frankfurt 60329
DE
Phone: +49 69 27235 0
Email: pk@DENIC.DE
Koch Expires May 16, 2014 [Page 7]
