As a workaround, Google, Verisign and Neustar published a draftdocumenting 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 anopen 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 toupstream servers with the client IP address. So that these can returnentries optimized for this IP address instead of the one they actuallyreceived the query from.

So, what upstream resolvers are seeing is not the query you sent. It’sthe query, plus your IP address. Usually, if a query for example.com issent to a Level 3 resolver, example.com authoritative servers are onlygoing to see Level 3 IP address, not your IP.

Now, if you are using Google or OpenDNS, and example.com has beenconfigured by them to receive the edns-client-subnet information,example.com servers are going to see your real network address, inaddition to the Google or OpenDNS one.

The current edns-client-subnet situation resembles the situation ofroot certificates in web browsers.Similarly to root certificates in web browsers, the list ofauthoritative name servers receiving edns-client-subnet tagged queriesis 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 needsto ask Google and OpenDNS to be added to their respective serverconfiguration. It can end up being added to the former, but not thelater.If an ISP wants to enable edns-client-subnet on its resolvers, it hasto manually maintain a list of “trusted” authoritative servers. Andservice 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 serversfeatures such as the mean RTT, RTT standard deviation, EDNS support, maximumpayload size, DNSSEC support and public keys. These are kept in adedicated cache with a different eviction policy than the message and recordsset caches.

Support for edns-client-subnet can be probed the same way as otherfeatures, namely by always sending it to unknown servers, rememberingthese 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 tofix “DNS leaks” when using a VPN.

If www.example.com is accessed through a VPN in order to hide theclient IP address, the last thing users want is to leak their IPaddress 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 serverswill see DNS queries coming from the resolver IP, and won’t learnanything about the real client IP.

However, when using Google or OpenDNS, a copy of the real clientnetwork address will be sent to all authoritative servers configured foredns-client-subnet. And no, dnscrypt doesn’t change anything to that.

Recursive servers implementing probing as described by theedns-client-subnet draft are going to leak the client network to allauthoritative servers.

Considering the fact that ISPs usually have networks way larger than a/24, using an edns-client-subnet enabled resolver actually leaks moreinformation 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 arelikely to redirect to the fastest servers in this situation.

However, in a split tunnelling VPN scenario, or if the DNS resolver offeredby the VPN service doesn’t support needed features like DNSSEC,services supporting edns-client-subnet might not be a good option ifleaking 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 thisresolver didn’t resolve this name before, queries to authoritativeservers will be sent in order to recursively resolve it.

The result will then be kept in a cache for a time-to-live controlledby authoritative servers, which tends to beextremelyshort.

Once an entry has been invalided from the cache, a new query for aname will require recursively querying authoritative servers again.

A response served from a resolver cache is much faster than when therecursion 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 forthe same name.

Content filtering gateways also frequently use the DNS protocol tocheck if an URL should be blocked, with a deterministic mapping.In addition to domain names, timing can be used in order to guessrecently accessed URLs.

Lowering the TTL for these or setting it to zero is not an acceptableworkaround. Recursive servers can indeed enforce a minimum TTL inorder to mitigate DNS cache poisoning and to reduce network traffic.

Cache timing attacks are seldom an issue for ISP DNS resolvers and foropen DNS resolvers that don’t support edns-client-subnet. Consideringthe fact that they are serving a huge number of clients, one doesn’tlearn much from the fact that a name has been recently looked up.

However, when edns-client-subnet is in use, this discloses the factthat 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 isset by the client itself through the edns-client-subnet mechanism,Google DNS can be abused to retrieve the complete list of IPs used bya distributed service.

This is even documented in the RFC: “reverse engineer the algorithms(or data) used by the Authoritative Nameserver to caclulate the optimizedanswer”.

But the proposed mitigations techniques actually don’t address thisissue.

And authoritative servers can directly answer edns-client-subnet taggedqueries no matter what.

For example, the full list of networks used by the Edgecast CDN can beretrieved by sending queries to @72.21.80.6 for www.edgecast.com usingdifferent client network addresses through the edns-client-subnetextension. This can be used in a DDoS attack, in order to target everynode of an infrastructure.

DNS response rate limiting and amplification

Recursive DNS resolvers must cache queries for (question,/24network 1) and (question,/24 network 2) independently even if thequestion is the same.

Therefore, an attacker can send repeated queries with a spoofed sourceaddress in order to force a resolver to contact upstream authoritativeservers for each query.

Repeated queries can trigger the response rate limiting mechanism.

This mechanism, recently implemented in authoritative servers, repliesto repeated UDP queries with a tiny response (shorter than thequestion) with the TC bit set. This causes resolvers and stubresolvers to retry using the TCP protocol, which is more difficult tospoof. This is an elegant way to mitigate DDoS attacks without takingthe risk of ignoring legitimate requests.

If an authoritative server’s RRL mechanism is triggered by a recursiveresolver due to different networks send through the edns-client-subnetextension, the resolver will be forced to retry using TCP.

A single question sent as a UDP packet will then trigger a TCPhandshake, effectively leading to an amplification of the question.

While edns-client-subnet makes this attack applicable to a wider range ofservers, it can also be performed without this extension.Indeed, the maximum useable payload size between a resolver and an upstreamserver can be lower than the one between a client and this resolver.

Google DNS resolvers mitigate this attack, and other amplificationsattacks, by enforcing a maximum payload size of 512 bytes when usingUDP, even when the DO bit has been set.

Implementation inconsistencies

What happens when a resolver receives a query with theedns-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, theactual client network address will still be received by authoritativeservers.

This is likely to get optimal responses from geographically distributedservices, even with intermediary caches.

This, however, requires that intermediary caches do not forwardedns-client-subnet information for unroutable addresses.

OpenDNS resolvers, on the other hand, don’t read this information atall, and replace it with the network address the packet was receivedfrom. This can give suboptimal results if intermediary caches areinvolved, but the fact that these caches and the final client are onnetworks close to each other is a reasonable assumption.

On a VPN configuration with split tunneling, this behavior has somedrawbacks, though. Namely, it makes it impossible to provide a hint toupstream resolvers as to what client network (the local one or the VPNprovider one) should be considered by authoritative services.

A note on network addresses

In order to protect users privacy, the edns-client-subnet draftencourages resolvers to truncate IPv4 addresses to 24 bits.

Google and OpenDNS are currently providing 24 bits of the client IPto authoritative servers.

This might not be large enough, as /24 network can be shared by alimited numbers of people in a company or university.

The draft mentions that “ISPs will often have more detailed knowledgeof their own networks. I.e. they will know if all 24-bit prefixes ina /20 are in the same area. In those cases, for optimal cacheutilization and improved privacy, the ISP’s Recursive Resolver SHOULDtruncate IP addresses in this /20 to just 20 bits, instead of 24as 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 to24 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 anedns-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 forqueries received with a NULL IP address through the edns-client-subnetmechanism.

Google resolvers do not strip NULL edns-client-subnet information;they are forwarded as-is to authoritative servers, effectivelyimproving users privacy.

OpenDNS resolvers are currently ignoring this information, and alwaysforward the source network address.

Home routers are typically running a variant of dnsmasq. This includesrouters 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 toupstream resolvers.

On this topic, the draft mentions that authoritative servers andrecursive resolvers “must at least ignore unroutable addresses”.

In practice, these servers must treat these queries as if they hadno edns-client-subnet extension, and consider the client IP instead.

Cache pollution

Cache pollution can be a serious concern. As recently reported by amobile operator, a single application abusing the DNS protocol for itsown need can totally trash DNS caches.

Unbound, Bind and PowerDNS have complex strategies to mitigate theseissues.

However, supporting the edns-client-subnet extension makes writing asecure implementation even more complex.

The draft suggests limiting the number of networks and answsers keptin cache for each query, as well as limiting the number of totaldifferent networks kept in cache.

In addition, resolvers should pay attention to the prefix lengthreturned by authoritative servers and upstream resolvers. Cachingshould be done according to the shortest prefix length, which can beas short as /8 with some CDNs like Edgecast, and not according to theprefix 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 isNamehelp,which intelligently combines remote and local resolvers in order toachieve optimal performance without requiring edns-client-subnet fromany 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 servicerequires a jailbroken device.

Another major issue in the Namehelp tool is that there is no way tolet it pick only resolvers supporting DNSSEC, and no way to perform DNSSECvalidation anyways. Please note that this is an issue in the toolitself, not in the technique it uses. So it can eventually be fixed.

In contrast, the edns-client-subnet mechanism doesn’t require anyadditional software, and can work with any device already supportingthe DNS protocol.

However, users should be aware of the privacy issues it involves.