DNS is commonly used by ad servers, content delivery networks and other multi-hosted services to redirect users to the fastest locations, according to the client IP.
It usually works as expected if the DNS resolver you are using is on the same physical network (or close to it) as the one you will be sending other queries from. Namely, if you’re running a local resolver, your router’s resolver or your ISP resolver, you’re likely to get the best possible performance.
Now, what if you are using a third-party resolver?
Well, the server you are going to connect to is likely to be the fastest, if the content was downloaded from this DNS server. Which will never be the case.
This leads to choppy Youtube videos, web sites that are stuck waiting for ads to load, unuseable on-demand streaming, and very slow iTunes content.
Switch back to your ISP’s resolver, and bam, everything is snappy again.
As a workaround, Google, Verisign and Neustar published a draft documenting an EDNS0 extension: draft-vandergaast-edns-client-subnet.
As of today, this draft has only been implemented by Google and OpenDNS.
There have been some talks about possibly implementing it in Unbound, but it’s super low priority and nothing was ever done. There is an open ticket to do that in PowerDNS, but nothing’s done either.
What edns-client-subnet does
An edns-client-subnet enabled DNS resolver tags queries sent to upstream servers with the client IP address. So that these can return entries optimized for this IP address instead of the one they actually received the query from.
So, what upstream resolvers are seeing is not the query you sent. It’s the query, plus your IP address. Usually, if a query for example.com is sent to a Level 3 resolver, example.com authoritative servers are only going to see Level 3 IP address, not your IP.
Now, if you are using Google or OpenDNS, and example.com has been configured by them to receive the edns-client-subnet information, example.com servers are going to see your real network address, in addition to the Google or OpenDNS one.
The current edns-client-subnet situation resembles the situation of root certificates in web browsers. Similarly to root certificates in web browsers, the list of authoritative name servers receiving edns-client-subnet tagged queries is manually and independently maintained by Google and OpenDNS. As a result, only a few companies currently have this privilege. A company willing to receive edns-client-subnet tagged queries needs to ask Google and OpenDNS to be added to their respective server configuration. It can end up being added to the former, but not the later. If an ISP wants to enable edns-client-subnet on its resolvers, it has to manually maintain a list of “trusted” authoritative servers. And service providers have to be aware that this new ISP exists.
This obviously doesn’t scale.
On the other hand, this also mitigates its security and privacy issues.
In order to fix this scalability issue, the current draft recommends probing.
Modern DNS resolvers already keep track of authoritative servers features such as the mean RTT, RTT standard deviation, EDNS support, maximum payload size, DNSSEC support and public keys. These are kept in a dedicated cache with a different eviction policy than the message and records set caches.
Support for edns-client-subnet can be probed the same way as other features, namely by always sending it to unknown servers, remembering these that don’t support it, and reprobe these later on.
DNS leaks
A common belief is that using a 3rd party resolver is a good way to fix “DNS leaks” when using a VPN.
If www.example.com is accessed through a VPN in order to hide the client IP address, the last thing users want is to leak their IP address through DNS queries.
If a resolver that doesn’t support edns-client-subnet is being used, it will actually be the case: the example.com authoritative servers will see DNS queries coming from the resolver IP, and won’t learn anything about the real client IP.
However, when using Google or OpenDNS, a copy of the real client network address will be sent to all authoritative servers configured for edns-client-subnet. And no, dnscrypt doesn’t change anything to that.
Recursive servers implementing probing as described by the edns-client-subnet draft are going to leak the client network to all authoritative servers.
Considering the fact that ISPs usually have networks way larger than a /24, using an edns-client-subnet enabled resolver actually leaks more information than using the regular ISP’s resolver.
In general, using a resolver provided by the VPN service is advisable: CDNs, ad servers and other geographically distributed services are likely to redirect to the fastest servers in this situation.
However, in a split tunnelling VPN scenario, or if the DNS resolver offered by the VPN service doesn’t support needed features like DNSSEC, services supporting edns-client-subnet might not be a good option if leaking information about the real client IP address is a concern.
Cache timing attacks
DNS cache timing attacks are as old as the DNS protocol itself.
If a query for www.example.com is sent to a DNS resolver and this resolver didn’t resolve this name before, queries to authoritative servers will be sent in order to recursively resolve it.
The result will then be kept in a cache for a time-to-live controlled by authoritative servers, which tends to be extremely short.
Once an entry has been invalided from the cache, a new query for a name will require recursively querying authoritative servers again.
A response served from a resolver cache is much faster than when the recursion process is required.
By measuring the time it takes to get a response for www.example.com, it’s trivial to guess whether someone else recently sent a query for the same name.
Content filtering gateways also frequently use the DNS protocol to check if an URL should be blocked, with a deterministic mapping. In addition to domain names, timing can be used in order to guess recently accessed URLs.
Lowering the TTL for these or setting it to zero is not an acceptable workaround. Recursive servers can indeed enforce a minimum TTL in order to mitigate DNS cache poisoning and to reduce network traffic.
Cache timing attacks are seldom an issue for ISP DNS resolvers and for open DNS resolvers that don’t support edns-client-subnet. Considering the fact that they are serving a huge number of clients, one doesn’t learn much from the fact that a name has been recently looked up.
However, when edns-client-subnet is in use, this discloses the fact that someone on the same network looked up that name.
This can raise privacy concerns.
Network scanning
Since the client address that authoritative servers should consider is set by the client itself through the edns-client-subnet mechanism, Google DNS can be abused to retrieve the complete list of IPs used by a distributed service.
This is even documented in the RFC: “reverse engineer the algorithms (or data) used by the Authoritative Nameserver to caclulate the optimized answer”.
But the proposed mitigations techniques actually don’t address this issue.
And authoritative servers can directly answer edns-client-subnet tagged queries no matter what.
For example, the full list of networks used by the Edgecast CDN can be retrieved by sending queries to @72.21.80.6 for www.edgecast.com using different client network addresses through the edns-client-subnet extension. This can be used in a DDoS attack, in order to target every node of an infrastructure.
DNS response rate limiting and amplification
Recursive DNS resolvers must cache queries for (question,/24 network 1) and (question,/24 network 2) independently even if the question is the same.
Therefore, an attacker can send repeated queries with a spoofed source address in order to force a resolver to contact upstream authoritative servers for each query.
Repeated queries can trigger the response rate limiting mechanism.
This mechanism, recently implemented in authoritative servers, replies to repeated UDP queries with a tiny response (shorter than the question) with the TC bit set. This causes resolvers and stub resolvers to retry using the TCP protocol, which is more difficult to spoof. This is an elegant way to mitigate DDoS attacks without taking the risk of ignoring legitimate requests.
If an authoritative server’s RRL mechanism is triggered by a recursive resolver due to different networks send through the edns-client-subnet extension, the resolver will be forced to retry using TCP.
A single question sent as a UDP packet will then trigger a TCP handshake, effectively leading to an amplification of the question.
While edns-client-subnet makes this attack applicable to a wider range of servers, it can also be performed without this extension. Indeed, the maximum useable payload size between a resolver and an upstream server can be lower than the one between a client and this resolver.
Google DNS resolvers mitigate this attack, and other amplifications attacks, by enforcing a maximum payload size of 512 bytes when using UDP, even when the DO bit has been set.
Implementation inconsistencies
What happens when a resolver receives a query with the edns-client-subnet extension differs among implementations.
Google resolvers forward this information to upstream resolvers. Thus, if an intermediary cache sits between the client and Google, the actual client network address will still be received by authoritative servers.
This is likely to get optimal responses from geographically distributed services, even with intermediary caches.
This, however, requires that intermediary caches do not forward edns-client-subnet information for unroutable addresses.
OpenDNS resolvers, on the other hand, don’t read this information at all, and replace it with the network address the packet was received from. This can give suboptimal results if intermediary caches are involved, but the fact that these caches and the final client are on networks close to each other is a reasonable assumption.
On a VPN configuration with split tunneling, this behavior has some drawbacks, though. Namely, it makes it impossible to provide a hint to upstream resolvers as to what client network (the local one or the VPN provider one) should be considered by authoritative services.
A note on network addresses
In order to protect users privacy, the edns-client-subnet draft encourages resolvers to truncate IPv4 addresses to 24 bits.
Google and OpenDNS are currently providing 24 bits of the client IP to authoritative servers.
This might not be large enough, as /24 network can be shared by a limited numbers of people in a company or university.
The draft mentions that “ISPs will often have more detailed knowledge of their own networks. I.e. they will know if all 24-bit prefixes in a /20 are in the same area. In those cases, for optimal cache utilization and improved privacy, the ISP’s Recursive Resolver SHOULD truncate IP addresses in this /20 to just 20 bits, instead of 24 as recommended above.”
This is a reasonable recommendation for ISPs running a DNS resolver, but doesn’t address the case of open resolvers.
As of today, both Google and OpenDNS always truncate the IP address to 24 bits no matter what the source and destination are.
For users willing to protect their privacy, the draft mentions: “Users who wish their full IP address to be hidden can include an edns-client-subnet option specifying the wildcard address 0.0.0.0/0 (i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS)”.
Authoritative servers should consider the resolver IP address for queries received with a NULL IP address through the edns-client-subnet mechanism.
Google resolvers do not strip NULL edns-client-subnet information; they are forwarded as-is to authoritative servers, effectively improving users privacy.
OpenDNS resolvers are currently ignoring this information, and always forward the source network address.
Home routers are typically running a variant of dnsmasq. This includes routers running open firmwares like Tomato Shibby and Advanced Tomato.
dnsmasq forwards edns-client-subnet information without altering it. In particular, unroutable client IP addresses are forwarded to upstream resolvers.
On this topic, the draft mentions that authoritative servers and recursive resolvers “must at least ignore unroutable addresses”.
In practice, these servers must treat these queries as if they had no edns-client-subnet extension, and consider the client IP instead.
Cache pollution
Cache pollution can be a serious concern. As recently reported by a mobile operator, a single application abusing the DNS protocol for its own need can totally trash DNS caches.
Unbound, Bind and PowerDNS have complex strategies to mitigate these issues.
However, supporting the edns-client-subnet extension makes writing a secure implementation even more complex.
The draft suggests limiting the number of networks and answsers kept in cache for each query, as well as limiting the number of total different networks kept in cache.
In addition, resolvers should pay attention to the prefix length returned by authoritative servers and upstream resolvers. Caching should be done according to the shortest prefix length, which can be as short as /8 with some CDNs like Edgecast, and not according to the prefix length supplied by the client.
Still a great leap forward
Supporting the edns-client-subnet mechanism has a lot of implications, including complexity, security and privacy concerns.
A compelling alternative is Namehelp, which intelligently combines remote and local resolvers in order to achieve optimal performance without requiring edns-client-subnet from any of the involved parties.
However, Namehelp needs to be running somewhere on the client network. It has to be installed on laptops and workstations. Or on a router, and the procedure to do so might not be straightforward.
It doesn’t run on iOS or Android yet, and running such a service requires a jailbroken device.
Another major issue in the Namehelp tool is that there is no way to let it pick only resolvers supporting DNSSEC, and no way to perform DNSSEC validation anyways. Please note that this is an issue in the tool itself, not in the technique it uses. So it can eventually be fixed.
In contrast, the edns-client-subnet mechanism doesn’t require any additional software, and can work with any device already supporting the DNS protocol.
However, users should be aware of the privacy issues it involves.