This is an excerpt from an opinion article originally posted on APNIC Labs. Read the entire article here.
The DNS Operations, Analysis and Research Centre holds a two day workshop twice a year. This is a collation of the presentations I found most stimulating at the Fall 2015 workshop, held at the start of October in Montreal. The full set of presentations can be found here.
At the outset I note that there was less of an emphasis on the coopting of the DNS into an attack vector, and while there were some presentations on DDOS mitigation techniques for resolvers, other topics also were aired at the workshop. One of the new themes is the consideration of the amount of information leakage in the DNS, and there were some presentations on efforts to improve the privacy of the DNS, principally concerning efforts relating to the shifting of DNS queries and responses from the current open UDP transactions to ones that are conducted through secure transport sessions, using either TCP or a transport protocol that extensively borrows from TCP.
1. DNS Privacy – Alison Mankin
Interestingly, RFC 4033 (The DNSSEC Requirements specification) has no confidentiality requirement. The NSEC3 activity considered zone confidentiality but it went no further. The DNSCurve and DNSCrypt tools offer confidentiality, but were not taken up by IETF DNS mainstream at the time. Since then the pervasive security theme has taken root in the IETF and the focus is back on confidentiality and protection of personal privacy at the protocol level (RFC7258). The IETF’s DPRIV WG has pushed out RFC7626 as its first document (the problem statement for the Working Group). This covers various points in the DNS where DNS data could be compromised, inspected by unauthorized third parties or otherwise misused.
The two major initiatives being considered are DNS-over-TLS, and qname minimisation. There is interest in the draft draft-ietf-dprive-dns-over-tls, which assumes DNS queries and responses over TCP, using models of an opportunistic channel security profile and pre-configured security profile to be applied against a specific DNS server. It was noted that implementations of the approach are appearing The Qname Minimisation draft has completed WG Last Call, and will be sent for IESG review anytime soon.
Further possible areas of exposure: NSEC3 is vulnerable to hash attacks by a well-resourced adversary. TLS uses cleartext domain names it its handshake. DHCP is similarly accessible. SNI exposes the domain name of the client, and as a response a reader should look at “domain fronting” in www.icir.org/vern/meek-PETS-2015.pdf. More parameters in the RTLS handshake are being protected in this manner.
2. TLS in DNS – Sara Dickinson
A number of possible approaches are being considered.
- STARTTLS uses port 53. Its a known technique with incremental deployment. But there is the potential for middlebox confusion when encountering encrypted port 53 traffic, and its also susceptible to a downgrade MITM attack.
- TLS using a new port will not interfere with port 53, but there is no firewall support and this may be an impediment.
- DTLS, which is basically DNS over TLS over UDP. There is the issue of UDP fragmentation and truncation, with a fallback to clear text or TLS. No running code as yet.
At the base here is DNS-over-TCP, used traditionally as a fallback in response to a TC=1 query response (RFC5966). A USC/ISI 2014 paper, “Connection-oriented TCP,” shows that TCP/TLS performance is feasible for DNS. The work documented in draft-ietf-dnsop-5966bis contemplates re-use of the TCP TLS session, as you want to amortize the cost of session setup to spam multiple queries (edns-tcp-keepalive for long-lived DNS-over-TCP sessions). This allows a model of conventional query response sequencing or query pipelining with queries in parallel. TCP fast open (RFC7413) uses cookie exchange and data in the first SYN. TLS session resumption (RFC5077) allows abbreviated handshake using a session ticket. There are the usual caveats about system tuning under intense TCP load (including TCP connection state explosion).
The unbound resolver has added TLS in 1.4.14 as a last chance connection attempt, and LDS and NSD have TLS patcheds. The getdns resolver is heading in the same direction, using TLS port 1021, and options for strict TLS, opportunistic TLS and conventional TCP/UDP fallback, with pipelining, out of order processing and a configurable idle session timer.
RFC7525 – BCP for TLS and DTLS, specifies TLS 1.2 as supported and preferred, with recommended cipher suites. There is work on TLS 1.3, which is anticipated to obsolete TLS 1.2
3. Neutering ANY Queries – Olafur Gudmundsson
This is a presentation on the ANY query and its treatment by Cloudflare. I have always been impressed by the ability of the folk at Cloudflare to innovate in the DNS and provide efficient scalable solutions to serving signed DNS records in novel ways, and this was no exception. ANY is an unreliable meta-type. Is ANY meant to be “all?” Or “Some?” Or “Many?” Or even just “A & AAAA” please? In Cloudflare’s case they find ANY is an expensive question to answer if ANY is the same as “all”, as not all the various components of a name are available all of the time at the point when the DNS response is being assembled.
Cloudflare initially responded by saying NOTIMP (“not implemented” response code) as a response to ANY. However NOTIMP was perhaps an over-reaction, as ANY is used as a query type. For example Firefox used ANY as a shorthand for “A and AAAA.” Qmail used ANY as a means of potential optimization, and it would fall back to explicit A and AAAA queries. In trying to optimize the approach to responding to ANY queries, an option here is to answer with what’s convenient. They have observed that ANY answers do not pre-populate caches with specific RR types that may have been included in the ANY response, but only populate the cache with the ANY lookup query type. The problem is the open resolver zombies without a cache (the open resolver problem). They have no cache and there are users behind them.
So the approach taken was a readable cacheable response that can be readily synthesized as it contains mo domain-specific data of any form. They opted for a fixed HINFO response as a response to ANY. This can be generated on the fly, and signed on the fly with their ECC signer. There was a comment in the room agreeing with this approach, noting that HINFO is already so compromised that it has no serious purpose any more, so why not throw HINFO under the bus, and just use that as the ANY response.
There was a question about using DNSSEC OPTOUT to even stop signing HINFO!
4. Canadian Content Hosting – Jim Cowie
Once upon a time we boasted that the Internet blurred geography. We boasted that a web site located in Oodnadatta could be seen by an entire world of Internet users, and an Internet user could browse every part of a world without borders. There were no “long distance charges” any more – it was one big flat Internet. Somewhere between the stunningly inappropriate mid-twentieth century models of content distribution that tries to insist that everyone has a binding obligation not to pass their precious content across these somewhat invisible national borders, and a world that is increasingly driven by a variety of nationalistic paranoia bought about through the rampant enthusiasm for broad scale surveillance, we apparently now want to erect political boundaries in the network, and place border controls on the flows of data. Do Swedish users communicate with other Swedish users along conduits and through servers only located on Swedish soil? Even 10 years ago it’s a question that would’ve elicited more or less polite laughter in response, but these days it’s asked seriously, and the answers pondered with equal gravitas. So when this presentation asks what proportion of the most popular content sites used by users in Canada are hosted inside Canada, it’s a question, and an answer, that some would like to take seriously. Maybe its part of this post-Snowden world that there are such levels of concern about where the national political boundaries really exist in the Internet. So when this presentation observes that some 78% of domain names in the .CA top level domain are hosted by enterprises located in the US are we to congratulate the canny Canadians for finding a good deal, and equally congratulate these entrepreneurial US enterprises for their zeal in servicing international export markets, or are we to deplore this situation as major threat to the integrity of citizens’ online data?
I am not sure what to conclude from this presentation!
5. Atlas and F-Root Anycast Selection – Ray Bellis
These days anycast drives the expansion of the root zone, and most (but not all) of the 13 root servers are in fact a constellation of synchronised servers that are intended to respond identically. But from the inside there is an interesting couple of questions: how effective is an existing root server constellation? If the anycast constellation were to be expanded, then where would additional anycast servers make sense? Both of these are difficult questions, and one suspects that the current anycast placement processes are more about “pins in a map” than a deep understanding of DNS query flows.
Ray has looked at RIPE measurement 10304: every root server, every 240s “hostname.bind CH TXT” query. He is mapping with the Atlas geo data to visualise the “client constellation” of each F Root anycast instance, and, in particular, identify those locations that are seeing DNS query response delays in excess of 200ms. Obvious anomalies are visible in this approach, such as French users using the Atlanta F root instance.
However the “what if” question is extremely difficult to answer from this approach. You can tell what is sub-optimal, but that’s not quite the same as an optimal placement of a further element in the anycast constellation.
But this leads to the next question: Is anycast an eloquent expression of failure?
This gets back to the question of what is the problem that we are wanting to solve, and is this the problem we appear to be solving. One can’t help but wonder if faster NXDOMAIN responses really matters. It appears that the actual benefit is not faster NXDOMAIN, but attack minimization. There were times when single instance root servers were DDOS’ed off the net, and large anycast constellations certainly help in minimizing the effectiveness of attack, even if the attack is a widely distributed attack.
But at this stage the thought process heads into ways to leverage DNSSEC to alter the entire root zone distribution architecture and see if we can eliminate even these 13 anycast constellations as critical points. But that is heading way beyond Ray’s presentation.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.