Slight Increase in DNS Resolvers Doing Priming Queries after .arpa Signing - Why?

Emile Aben — Apr 06, 2010 01:55 PM
Filed under: , , ,
The roll-out of a signed root-zone at K-root on 24 March 2010 was uneventful. But we saw the number of resolvers doing priming queries increase slightly since 18 March 2010 and wanted to find out why.

The roll-out of a signed root-zone at K-root on 24 March 2010 was uneventful. We didn't see anything in the data we collect worth mentioning around that date. What we did see was the number of resolvers doing priming queries  (qclass=IN,qtype=NS,qname='.') increase slightly since 18 March (Figure 1). This may be a natural fluctuation, but it's also right after the deployment of a signed .arpa zones that was rolled out between 2010-03-15 0001 UTC and 2010-03-17 2359 UTC .

Figure 1

If you look at the global K-root nodes, this effect is not seen everywhere (see Figure 2). It is visible on the AMS-IX node and a bit less pronounced on the DENIC and Tokyo nodes. It doesn't seem visible on the NAP node located in Miami, and on the LINX node something happened on 15 - 16 March so there are less IP addresses seen there. K-root uses anycast, so changes in routing can result in the shift of a population of resolvers from one K-root node to the other which could explain some of the differences in Figure 2, but the total population of resolvers that hit K-root (as shown in Figure 1) should be relatively constant.

Figure 2

The most visited local K-root nodes (ie. NO_EXPORT) also show mixed results. The shift around 18 March 2010 is visible at MIX (Milan,Italy) and maybe CERN (Switzerland) but not significant at other nodes (Figure 3).

Figure 3

I'd like to know which resolvers caused this increase, to understand what caused the increase we see. To get a rough feel if this is caused by a specific network or not, I looked into the first octet of IPv4 addresses seen in the week before 18 March versus the week after. For all the /8's that are in frequent use an increase in the number of resolvers is visible between the week before 18 March and the week after (data not shown). Looking at EDNS support (a prereq for DNSSEC) provides more clues and shows that if an increase in number of resolvers doing priming queries is seen this is primarily due to an increase of resolvers without EDNS support. Figure 4a-e show the EDNS support for K-root global nodes as well as the ratio between resolvers that support EDNS and resolvers that don't support EDNS.  The number of EDNS-capable resolvers that hit the AMS-IX, DENIC and Tokyo K-root nodes on a given day stays fairly constant over all of March, where the resolvers that are not EDNS-capable increases after 18 March. This effect is not visible on the NAP and LINX K-root nodes.

Figure 4a Figure 4b
  Figure 4c   Figure 4d
  Figure 4e  

While this is not causing any significant operational strain on K-root, and we don't believe a significant number of clients have problems with DNS resolution, we still want to know what is going on. If you know what could have caused the increase in number of resolvers doing priming queries to K-root around 18 March 2010, please let us know . In the meantime I'll be trying to characterise this some more (look at TTLs), isolate some sources that cause the increase, to try to find out if this is just coincidence or if this is related to the signing of the .arpa zone.


Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Related Items
Visualising Bandwidth Capacity and Network Activity in RIPEstat Using M-Lab Data

As a result of the cooperation between the RIPE NCC and Measurement Lab (M-Lab), you can now ...

RIPEstat 2013 Year in Review

RIPEstat users saw a lot of changes throughout 2013, from support for new query types, such as ...

Internet Disruptions in Sudan

Significant Internet disruptions are happening in Sudan, possibly as a reaction to riots. We use ...

IPv6 RIPEness - Implementing the Fifth Star

In this article we present the first publicly available beta version of the fifth IPv6 RIPEness ...

Using RIPE Atlas: A DENIC Case Study

When we experienced an occasional operational issue with the data returned by one of our name ...

more ...