By sending queries with a spoofed source address to such open resolvers, the resolver will send the answers to that spoofed address. An attacker spoofs the address of his/her target and sends a large number of queries to an open resolver, creating a deluge of large DNS answers towards the target.

As these open resolvers function as a point of reflection (the original source is not visible on the target’s side) and amplification (small queries in, large answers out), they are potent and desirable resources for attackers. More details of these concepts and defence mechanisms are explained in this post on the Akamai blog.

Scanning for open resolvers

Finding these open resolvers is easy for IPv4: simply send a query to every possible IPv4 address and see whether you get a response! Perfectly feasible using commodity hardware and a half-decent home connection.

However, trying all the possible IPv6 addresses would consume your lifetime, and then some more, and then some more after that.

Having said this, there are some potential other ways to do it, as we presented in our 2017 Passive and Active Measurement Conference (PAM) paper and as I’ll describe below.

Assuming that most IPv6-connected hosts still also have IPv4 connectivity, we wondered whether we could find open IPv6 resolvers via IPv4. Upon exploring this hypothesis, the first challenge we had to overcome was the fact that IPv4 addresses and IPv6 addresses are independent of each other, so there is no way to simply ‘translate’ the IPv4 address of an open resolver into its IPv6 address. This meant we needed to go higher!

Traversing using the application layer

We used a higher layer to force the traversal from IPv4 to IPv6 — the way the DNS and DNS resolvers work allows this.

If we think about the process of resolving `labs.ripe.net`, the resolver will:

1. Contact a root server to find the`.net`-zone
2. Query the `.net`-server to find the `.ripe`-zone
3. Asks the `.ripe`-nameserver about the `labs`-subdomain.

Most importantly, the resolver will set up a new IP connection for each part of the original query.

The IP addresses of the nameservers the resolver has to connect to are, naturally, in the DNS as well. And we can configure the DNS or at least some parts of it. This is where things get interesting: what if we delegate a subdomain to a nameserver which is reachable only over IPv6, and query an IPv4 resolver for something in that IPv6-only subdomain?

If the resolver has any form of IPv6 connectivity, it will ‘switch’ from IPv4 to IPv6 and contact the IPv6-only nameserver. So, if we control that IPv6-only nameserver and listen for incoming queries, we can determine whether an IPv4 resolver indeed has IPv6 connectivity, and what its IPv6 address actually is.

Geoff Huston provides a much more elaborate explanation of the DNS in this post.

Did we really find an open resolver?

The freshly obtained IPv6 address does not necessarily function as an open resolver. A simple DNS query towards that address will tell us whether it indeed openly resolves, and can be misused in attacks.

As it turns out, this last query weeds out many of the found IPv6 addresses. We performed a measurement, scanning the entire IPv4 address space for open resolvers and querying them for our IPv6-only zone. This yielded 1.5 million unique pairs of IPv4/IPv6 showing IPv6 connectivity, of which, 80,000 are openly resolving on both IPv4 and IPv6. These pairs contained 1,038 unique IPv6 open resolvers, and 73,000 unique open IPv4 resolvers.

The IPv4 open resolver count is in the order of magnitude of 10 million, so 1,038 does not sound that impressive nor worrisome, does it?

Quality vs. quantity

Let’s take a step back. The idea of our methodology sprouted while we were thinking of dual-stacked open resolvers, a single machine with both IPv4 and IPv6 connectivity. However, the machine contacting our controlled authoritative nameserver is not necessarily the machine we’ve sent the initial query to. Network operators can use a forwarder in front of a multi-machine resolving infrastructure. Naturally, this forwarder is the ‘IPv4 open resolver’, while we see one of many infrastructural machines contacting our IPv6-only nameserver. Two completely different beasts!

What does this mean for the numbers? Based on the collected data — incoming queries at the controlled authoritative nameserver — we cannot determine which of the scenarios we are actually dealing with. With an extra query, though, we are able to gain some insights.

By querying the found IPv6 open resolvers for an IPv4-only zone (that’s right, we are simply reversing the trick) and observing incoming traffic on the authoritative nameserver, we learn whether we are dealing with a dual-stacked, single machine. If the IPv4 address contacting our server is identical to the one we initially queried for the IPv6-only zone, this is likely to be so.

Does this work in every possible scenario? Probably not. But we’re not after a method to classify unknown resolving infrastructures — we just want to find open resolvers.

Generalising the two scenarios (dual-stack vs. infrastructural), and distinguishing between them, allows us to consider how serious we should take the obtained numbers. Nobody will lose sleep over 1,038 dual-stacked residential routers with a 2 Mbps uplink.

However, everybody should lose sleep over 1,038 high-available infrastructural resolvers with a 1 or 10 GbE uplink —  a handful of the latter would be a potent attack resource.

Time to lose sleep

Based on this second query, we identified 745 (72%) of the found IPv6 resolvers to be indeed infrastructural. Analysis of the Interface Identifiers (IID), the last 64 bits of these addresses, emphasises the likeliness of these machines being explicitly configured to resolve by humans: of the 1,038 addresses, 622 featured all zeroes but the last two bytes, like this: `2001:db8:2:3::53` (short for `2001:db8:2:3:0:0:0:53`).

Moreover, 570 of these 622 addresses show only decimal characters in the last two bytes, no hexadecimals.

Compare this with an automatically configured stateless address (SLAAC), filled with hexadecimal characters, and most people will agree the shorter, ‘decimal’ one is preferable to work with.

Of the 1,038 addresses, only 225 have any hexadecimal character: 83 of these are SLAAC addresses, based on the embedded `ff:fe` part.

Conclusion: We don’t have exact numbers on how many of the found IPv6 open resolvers are definitely infrastructural, but we have multiple reasons to believe it’s a significant share.

Caching behaviour

Even if we are dealing with a high-bandwidth, well-connected infrastructural resolver, it does not automatically mean it is effective as a reflection and amplification point.

With most authoritative nameservers having implemented Request Rate Limiting (RRL), an attack will be limited in case the open resolver has to contact an authoritative for every single query. However, if the open resolver caches the answers, there is no need to repeatedly set up connections to that authoritative, making it a far more effective open resolver in terms of possible misuse.

922 out of the 1,038 IPv6 resolvers cache. That’s 89%.

Where are these open resolvers?

A brief look into where these open resolvers are located tells us two things.

First, network-wise, the 1,038 resolvers are spread over 216 Autonomous Systems (ASes). This means the problem (by now we agree that we are dealing with ‘a problem’, right?) is not caused by just one or two shady or misconfigured networks. That said, the top 10 ASes containing most open resolvers account for a little over 50% of all.

Geographically, we find a slight bias towards Western Europe and Asia. This might be explained by the adoption and deployment numbers of IPv6 being higher as well. With only 1,038 data points, it’s hard to make any statistically correct claims. The main takeaway here is that all operators should be aware of possible open resolvers in their IPv6 networks.

Ethical considerations

This kind of research is definitely a lot of fun, both to carry out and to see the results coming from it. It does, however, quickly enter a grey area, ethically speaking, in terms of using a method of finding misused machines and causing more noise on the Internet by scanning the entire IPv4 space.

For obvious reasons, we do not simply publish the list of found open resolvers. Publishing the way to find them, however, might still raise eyebrows.

As for the scans, it would be great if we could reuse large-scale scans from other researchers, network operators and/or enthusiasts so as not to introduce more noise on the Internet than there already is. But, because of some technical requirements from our side (basically, excepting far more DNS responses than only completely sane and valid ones), existing datasets did not suffice. The machine performing our scans hosted a simple website, explaining our doings and provided an email address for operators to request blacklisting of their networks. This study should help operators, not annoy them by tickling their detection systems.

The steps we’ve presented are all based on existing, standardised technology, available to anyone. This means we are probably not the first to think of this.

So there you have it

A fistful of open resolvers on IPv6. Leveraging the facts that we can scan the entire IPv4 address space, and traverse from IPv4 to IPv6 via the AAAA-only nameserver configuration, finding them is feasible.

Our approach does not find all the open resolvers with IPv6 connectivity out there. IPv6-only resolvers, for example, will never be found, because of the first IPv4-based step in our method. We hope to enhance this or find new approaches in the near future.

We also want to make our results useful for operators. Efforts of merging our approach in existing ‘open resolver’-services are ongoing, but for any questions about either the method or the results, please contact us.

This blog post is based on the paper we published about this subject at the Passive and Active Measurement Conference (PAM) in Sydney, 2017. For more details, please read the pre-print version of that paper, titled On the potential of IPv6 open resolvers for DDoS attacks [PDF 308 KB].