In the previous blog on DNS privacy, we covered how the current DNS does not provide for any confidentiality of queries or responses.\u00a0 Pervasive Monitoring (PM) of clear-text DNS messages can reveal a great deal about a client.\u00a0 With a heightened awareness of Pervasive Monitoring, there is a sincere desire to preserve user\u2019s personal privacy when using DNS over the Internet.\u00a0 In this blog we will cover the work being done within the IETF to help mitigate the DNS privacy issues.<\/p>\n
The IETF is actively working on DNS privacy and confidentiality solutions.\u00a0 The IETF has formed a\u00a0DNS PRIVate Exchange<\/a>\u00a0(dprive) working group.\u00a0 DNS privacy topics are also covered by the\u00a0DNS Operations<\/a>\u00a0(dnsop) working group.\u00a0 There is also an\u00a0IETF mailing list<\/a>\u00a0specifically for discussions about DNS Privacy (dns-privacy@ietf.org<\/a>).\u00a0 You can subscribe to the mailing list\u00a0here<\/a>.\u00a0 The archives for this mailing list can be found\u00a0here<\/a>.<\/p>\n One of the primary IETF RFCs on this topic is DNS Privacy Considerations (RFC 7626<\/a>).\u00a0 This RFC originally started as a\u00a0draft<\/a>\u00a0authored by St\u00e9phane Bortzmeyer (AFNIC) which came out of the dnsop working group (but then it changed into a\u00a0problem statement<\/a>,\u00a0which then became an RFC).\u00a0 This DNS Privacy RFC offers a good overview of the issues at hand and hints at some of the possible solutions.\u00a0 Another draft, albeit expired, that covered some of these same topics of monitoring DNS traffic is titled \u201cConfidentiality Aspects of DNS Data, Publication, and Resolution<\/a>\u201d.<\/p>\n Most DNS queries use UDP,\u00a0but sometimes TCP<\/a>\u00a0can be used, when the query response is large for example.\u00a0 This choice is also influenced by the availability of\u00a0EDNS0<\/a>.\u00a0 Thus, another IETF draft germane to the discussion about DNS privacy is \u201cClient Subnet in DNS Queries<\/a>\u201d.\u00a0 This draft proposal intends to include a masked IP address of the originating DNS client within the DNS query and place it into the EDNS0 OPT resource record.\u00a0 When a client uses a public recursive DNS server, a GSLB system may incorrectly assume that they are near each other.\u00a0 The aim of this technique is that it helps aid the resolution based on network topology geographical proximity information.\u00a0 The DNS servers will more precisely know about the client\u2019s location and be able to return resolutions that direct the connection to the nearest content to reduce latency and maximize end-user experience.\u00a0 The disadvantage of this technique is that it reveals information about the client\u2019s network location that could be pervasively monitored by recursive DNS servers or authoritative name servers.<\/p>\n In recent years, we have witnessed an increase in DNS message amplification\u00a0attacks due to open DNS servers<\/a>.\u00a0 The attacker will send spoofed queries to a set of DNS servers that do not restrict queries.\u00a0 The DNS servers respond to those spoofed queries\u2019 fake source addresses with a large amount of response data.\u00a0 The result is a high-volume stream of DNS response packets destined for the spoofed IP address which leads to the victim\u2019s network.\u00a0 One proposed method to help thwart these types of attacks is to use DNS cookies.\u00a0 This draft proposes creation of a cookie OPT resource record (EDNS0 RFC 6891<\/a>) response data for either a client cookie or a server cookie to provide a lightweight DNS transaction security measure.\u00a0\u00a0This paper<\/a>\u00a0also further explains how DNS cookies would work between the client and the recursive name server and between the recursive name server and other DNS servers.\u00a0 This DNS cookie technique has been implemented by\u00a0ISC<\/a>\u00a0in BIND 9.10.0b1 as the\u00a0Source Identity Token<\/a>\u00a0(SIT) feature.\u00a0 The benefit of this technique is that DNS cookies would provide a method of protecting against DNS packet amplification attacks.\u00a0 Unfortunately, this technique does not provide any privacy protection.<\/p>\n A central issue in DNS privacy is that DNS queries contain the full Query Name (QNAME) on each recursive query.\u00a0 Therefore, each DNS server queried along the tree traversal would know the full question being asked by the client.\u00a0 This can contain more information than is required.\u00a0 For example, queries to TLD or root name servers should only be a query for a Name Server (NS) record for the authoritative DNS server for that queried domain.\u00a0 The concept is similar to only asking the specific question required at the moment without giving away the complete intent of the questioner.\u00a0 In this way, the answer is not provided too much information and provides for a \u201cseparation of duties<\/a>\u201d security measure.<\/p>\n The IETF dnsop working group has created a draft, again authored by St\u00e9phane Bortzmeyer (AFNIC), titled \u201cDNS query name minimisation to improve privacy<\/a>\u201d.\u00a0 With this solution, the queries to the root name servers only contain a query for the Top Level Domain (TLD) that contains the domain name being looked up.\u00a0 The query to the TLD name server only contains a query for the NS record for the next-level down the zone tree structure for the organization\u2019s authoritative DNS server.\u00a0 Each subsequent query contains more specific information and only the authoritative name server observes the complete QNAME query.<\/p>\n Other solutions to solving the DNS privacy conundrum involves performing encryption of the DNS packets to prevent traffic inspection and protecting against eavesdropping.\u00a0 At the 2014 IETF 89 meeting in London there was an \u201cEncryption of DNS requests for confidentiality<\/a>\u201d (DNSE) Birds of a Feather (BOF) session where several options were discussed.<\/p>\n One draft proposal is titled \u201cConfidential DNS<\/a>\u201d.\u00a0 This proposal defines the creation of a new ENCRYPT resource record type (RRType).\u00a0 The DNS server publishes encryption keys and the ENCRYPT RRType is used for each segment of the DNS query path.<\/p>\n Transport Layer Security (TLS) (and its predecessor Secure Sockets Layer (SSL)) is a popular technique for providing confidentiality to many types of communications applications.\u00a0 TLS is best known as the secure form of HTTP that uses public key cryptography to validate the authenticity of the site (but then uses symmetric cryptography for the encryption of the transmitted data).\u00a0 TLS can also be applied for collaboration applications and it is also possible to use TLS over TCP to provide security for DNS queries.<\/p>\n There are several benefits to using TCP for DNS queries.\u00a0 UDP DNS queries are often spoofed and used for large-scale\u00a0DDoS attacks<\/a>.\u00a0 TCP avoids the problems of DDoS attacks using open recursive DNS servers and allows for TLS encryption.\u00a0 These are all great benefits, but most DNS queries use UDP and so this TLS method of encryption with TCP may not apply to all DNS queries.\u00a0 Besides, TCP can end up being used anyway for larger DNS responses such as those containing more data (e.g.\u00a0DNSSEC<\/a>,\u00a0DANE<\/a>,\u00a0TLSA<\/a>, etc.).<\/p>\n This IETF draft proposal titled \u201cTLS for DNS: Initiation and Performance Considerations<\/a>\u201d describes how TLS can be applied to protect the confidentially of DNS query payload data.<\/p>\n Since most DNS queries utilize UDP, then using TLS for encryption may not be the best applicable for all situations.\u00a0 Thankfully, there may be an option of adding encryption to the typical UDP DNS queries.\u00a0 The Datagram Transport Layer Security (DTLS) protocol is a method of encrypting application payload data transported over UDP.<\/p>\n The IETF draft proposal titled \u201cDNS over DTLS (DNSoD)<\/a>\u201d describes how this might work.\u00a0 You might recognize the name Dan Wing, one of the authors of this draft.\u00a0 Dan Wing (along with Andrew Yourtchenko, both with Cisco) is an author of the Happy Eyeballs RFC (RFC 6555) that describes a technique to improve end-user experience for dual-protocol communications.<\/p>\n Judging from the activity in the area of DNS privacy, this will likely be a popular topic of discussion and action in 2016.\u00a0 There are many different solutions, some competing with each other.\u00a0 Many of these solutions are just early IETF drafts of concepts but a few of these ideas may make their way into the Internet Systems Consortium\u2019s (ISCs)\u00a0BIND software<\/a>\u00a0and appear on their\u00a0list of features<\/a>.\u00a0 In the meantime, we should consider how monitoring of our DNS traffic can leave us vulnerable to a loss of privacy.<\/p>\n","protected":false},"excerpt":{"rendered":" In the previous blog on DNS privacy, we covered how the current DNS does not provide for any confidentiality of queries or responses.\u00a0 Pervasive Monitoring (PM) of clear-text DNS messages can reveal a great deal about a client.\u00a0 With a heightened awareness of Pervasive Monitoring, there is a sincere desire to preserve user\u2019s personal privacy […]<\/p>\n","protected":false},"author":321,"featured_media":2577,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[17],"tags":[108,30,15,48],"class_list":{"0":"post-2842","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ipv6-coe","8":"tag-bind","9":"tag-dns","10":"tag-security","11":"tag-threat","12":"entry"},"acf":[],"yoast_head":"\nClient Subnet in DNS Queries<\/h2>\n
DNS Cookies<\/h2>\n
DNS Minimization<\/h2>\n
Encryption of DNS Requests<\/h2>\n
Confidential DNS<\/h3>\n
TLS for DNS<\/h3>\n
DNS over DTLS<\/h3>\n
More DNS Privacy Activity Expected in 2016<\/h2>\n