Emile Aben

RIPE Atlas - A Case Study of AAAA Filtering

Emile Aben
Contributors: Philip Homburg

6 min read

0 You have liked this article 0 times.
0

At the recent RIPE Meeting, the question was raised whether Internet users would see significant filtering of AAAA DNS queries or replies. We used RIPE Atlas measurements to provide an answer to this question.


Background

Selective filtering of the DNS AAAA record is one of the tools available to operators to mitigate potential problems end users have with broken IPv6 connectivity. This idea was presented at IETF 77 in 2010 , and there are working implementations of it in major DNS caching resolvers .

At RIPE 65 , Lorenzo Colitti from Google raised the question whether Internet users would see significant filtering of AAAA DNS queries or replies, either by their ISP or by their Customer Premise Equipment (CPE). We used RIPE Atlas to provide an answer to this question.

We scheduled two User Defined Measurements (UDM):

  • One that tries to resolve the IPv4 address for www.ripe.net using the probe's local resolvers (a DNS 'IN A' query) and
  • One that queries the IPv6 address ('IN AAAA').

By comparing the results it is possible to find out which of the RIPE Atlas probes can resolve the IPv4 address but cannot resolve the IPv6 address. Note that at the time of writing, starting a UDM that involves all RIPE Atlas probes is only possible for RIPE NCC staff. We hope to lift this restriction in the near future.

Methodology

We started two UDM on 2012-09-24 22:10 UTC and stopped them on 2012-09-25 06:02 UTC:

  1. UDM with identifier 1004102 was set to perform a DNS 'IN A' query on www.ripe.net every 300 seconds, using all of the probe's local resolvers.
  2. UDM with identifier 1004103 was set to perform a DNS 'IN AAAA' query on www.ripe.net every 300 seconds.

You can download the raw data for both of these measurements from the list of public UDMs if you have a RIPE Access account.

Because we didn't know the exact number of active and avalable RIPE Atlas probes at that point in time, we defined both UDMs such that requests were sent to 2,500 probes , which we knew was more than currently available in the system. The scheduler selected 1,855 probes. During the time of the experiment, each of the 1,855 probes performed approximately 95 measurements. Probes with multiple resolvers tried their resolvers in round robin fashion. That means per UDM, probes sent one DNS query every 300 seconds rotating among the resolvers. While analysing the measurement results, we found a small bug in the round robin implementation that results in the measurements not evenly spreading across multiple resolvers. This bug didn't affect the measurement results, and is going to be fixed in an upcoming release of the probe firmware.

For various reasons a probe may not be performing any measurements or may be broken in other ways, and we decided to select only working probes. If out of all measurements a probe would get a single reply to an 'IN A' query, the probe was assumed to be working correctly. If a working probe gets at least one reply to an 'IN AAAA' query, we count that probe as having working AAAA.

When we did some consistency checks on the results, we found the following: For the 'IN A' query, there were two probes that got results that could not be decoded as valid DNS replies. Surprisingly, both probes got completely valid 'IN AAAA' replies. We did not find any probes that could do 'IN AAAA' but could not do 'IN A'.

Results

Out of 1,810 RIPE Atlas probes which showed results for A queries, only 14 (0.8%)  consistently didn't get responses for the AAAA query, while getting responses on A queries. We tried to determine the AS of the resolvers these 14 probes used. If the probe queried private IPv4 address space (RFC 1918), we assumed that the resolver AS is the AS the probe is located in. This way we found 7 ASes with suspected AAAA filtering. Some characteristics of these ASes are listed below in Table 1. Note that we anonymised the ASes and only show in which country they are located.

AS country no. probes no. probes with suspected AAAA-filtering
(a) FR 12 8
(b) AU 8 1
(c) GR 5 1
(d) AU 3 1
(e) ES 1 1
(f) JP 1 1
(g) JP 1 1

Table 1: Characteristics of ASes where suspected AAAA filtering was detected

As you can see in Table 1, there is only 1 AS, in France, where we see more then one RIPE Atlas probe with suspected AAAA filtering. This same AS also has 4 RIPE Atlas probes that see AAAA records in the test above. This suggests that if AAAA filtering is indeed applied in this AS, it is not applied uniformly across the AS. We didn't find any clear pattern in the resolvers that were in use by the probes in this particular AS. We also couldn't detect any specific country or regions that showed a high number of filtering vs. non-filtering probes.

For the other 6 ASes we only saw single RIPE Atlas probes with detected AAAA filtering.

Conclusion

We don't see evidence of widespread AAAA filtering, at least not in the networks in which RIPE Atlas probes are deployed. In order to detect phenomena like this better, we are constantly looking to improve the RIPE Atlas network by having more RIPE Atlas probes deployed. Please help and apply for one today!

0 You have liked this article 0 times.
0

You may also like

View more

About the author

Emile Aben Based in Amsterdam, NL

I'm a system architect/research coordinator at the RIPE NCC, where I work in the science group. I'm a chemist by training, but have been working since 1998 on Internet related things, as a sysadmin, security consultant, web developer and researcher. I am interested in technology changes (like IPv6 deployment), Internet measurement, data analysis, data visualisation, sustainability and security. I'd like to bring research and operations closer together, ie. do research that is operationally relevant. When I'm not working I like to make music (electric guitar, bass and drums), do sports (swimming, (inline) skating, bouldering, soccer), and try to be a good parent.

Comments 0