A Look at DNS Priming Queries to K-root

In this article we take a look at DNS priming queries arriving during the deployment of a DNSSEC signed zone at the DNS root servers. We are specifically looking for potential problems as a result of this deployment. In this analysis we did not find any signs of problems occurring after the first three dates when  a signed zone was deployed at the root. This is reassuring in the light of deployment of a signed zone at K-root (operated by the RIPE NCC) on 24 March 2010.

Introduction

As part of our efforts to monitor the deployment of a signed zone at the DNS root servers, we collect traffic traces of the specific DNS queries to k-root nodes that are associated with so called DNS priming. DNS priming is part of the bootstrap of a caching DNS resolver, and in this process the caching DNS resolver asks for the name servers for the root zone ( NS IN . ). As part of a (re)start, a caching DNS resolver normally performs this query to one of the 13 root servers. Restarting a caching DNS resolver is a common first troubleshooting step when operators suspect something is not functioning properly. So if the pattern of DNS priming queries to the root server system changes, it can be an indication of problems on the side of the caching DNS resolver.

The signed zone at the root is being deployed in phases. Between January and May 2010, the 13 root servers will start serving a signed, but unverifiable, root zone. For more information, please see: http://www.root-dnssec.org/ . In this article we analyse the queries received by K-root that are associated with the priming of caching DNS resolvers in the weeks before and during the signed zone roll out to the first four root-servers on three deployment dates.

Analysis

The data this analysis is based on are traffic traces of DNS clients that query K-root nodes for the nameservers for the root zone (qtype=NS , qname='.', qclass=IN). While we expect that most of this traffic is associated with priming of caching DNS resolvers, this traffic can also have other causes, for instance manual troubleshooting, (D)DoS, or monitoring DNS connectivity. For the remainder of this article we'll label all of the (qtype=NS, qname='.', qclass=IN)-type traffic as 'ns-for-dot' traffic.

One problem with analysing DNS priming data is that DNS priming was never standardised, although an effort is underway to do this: http://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-02 . One ambiguous aspect is the exact mechanism of selecting what root-server a caching resolver targets to do a priming query. The common method of doing this is randomly selecting a target from a hints-configuration file. However, anecdotal evidence suggests some DNS resolver implementations use different selection strategies, or even send a priming query to all targets they can find. A second non-standardised aspect is the mechanics by which caching DNS resolvers issue re-priming queries, i.e. refreshing the information that was retrieved by an earlier priming query. The IETF draft suggests not to issue a priming query more then once a day and to honour the Time To Live (TTL) of the NS records in the answer to the priming query. This TTL is currently six days (518400 seconds). The re-priming queries are not distinguisable from the priming queries that are done when a caching DNS resolver restarts, so this will create a background signal that can't be filtered out easily.

A look at query rates of 'ns-for-dot' queries to K-root shows that this rate varies a lot and may not be that useful in detecting a change in the pattern of DNS priming queries to K-root. Closer inspection of the data reveals the variety is mainly caused by a small amount of sources sending a lot of 'ns-for-dot' queries to K-root nodes. While most sources send at most a single 'ns-for-dot' query per day to the K-root system, there are sources that send up to 1.46 million queries in a single day. This is on the low side to be a sustained DDoS attack, but far too high to be the result of manual restarts of caching DNS resolvers. The top two source addresses of these queries only hit the Tokyo K-root node and originated from AS10429 and AS28573 ( Do you have an idea of what causes these 'ns-for-dot' storms? ).

Figure 1: Source IP addresses seen doing 'ns-for-dot' queries to K-root

Next we decided to look at the number of IP source addresses from which we received 'ns-for-dot' traffic. In Figure 1 the total number of source addresses is plotted per day (green plusses). In the same figure these source addresses are split out based on the number of 'ns-for-dot' seen from that source address on a given day. On weekdays roughly 220k unique source IP addresses perform 'ns-for-dot' queries to K-root nodes. Of these 220k, around 180k unique source IP addresses perform exactly one 'ns-for-dot' query. If a significant number of caching DNS resolvers would be restarted once or multiple times during troubleshooting, this would result in one or at most a small number of queries to K-root nodes per restarted resolver. If caching resolvers randomly select the target for their priming query, the chance of hitting K-root nodes is 1 in 13 for each query they do. It is interesting to note that during weekends the number of unique source IP addresses seen performing 'ns-for-dot' queries drops under 200k, and on Friday the number of unique sources is slightly less then on other weekdays. The weekday-weekend pattern could be caused by less systems administration activity in weekends, although this weekday-weekend pattern is also visible in the total query rate (!= number of IP sources) to the K-root system ( http://k.root-servers.org/statistics/GLOBAL/monthly/ ). The 'Friday'-pattern could be the result of a freeze in network configuration changes that some organisations have in place on Fridays. Figure 1 shows that with the three deployments of a signed root (vertical lines) this pattern did not change. So at the macroscopic level there was no significant increase or decrease in the number of source IP addresses performing 'ns-for-dot' queries to K-root.

To see how the population of sources issuing 'ns-for-dot' queries changes from the days before, the set of source IP addresses issuing these queries was compared to the set of IP addresses from the day before (Figure 2) and six days before (Figure 3). One would expect that in the case of increased reboots of populations of caching resolvers the number of IP addresses seen on a given day would go up, but not on the day before. In figure 2 we can see that there is no significant change in IP addresses seen on a given day, but not on the day before and after the signed zone deployment days (green plusses). In figure 2 we can see that about 75k-80k unique sources are seen on consecutive days (purple stars), and the weekend-weekday pattern is visible again.

Figure 2: Unique IP addresses issuing 'ns-for-dot' compared to the day before

Figure 3 shows the number of IP addresses that are unique or recurring for a given day compared to six days before, this is to see if there is an effect due to re-priming queries due to TTL expiry of the NS records; this TTL is currently six days. The number of IP addresses seen on a given day as well as six days before that day (purple stars) drops as compared to the number of recurring IP addresses for 1 day before (Figure 2), so re-priming due to TTL expiry isn't visible in this data. The number of IP addresses seen on a given day, but not six days earlier (green plusses) is too noisy to be used as an indicator of increased resolver restarts.

Figure 3: Unique IP addresses issuing 'ns-for-dot' queries compared to six days before

Conclusion

Based on the data and analysis for the first three deployment dates presented here, there is little evidence of increased restarting of caching DNS resolvers due to the roll out of a signed zone at the root servers. On 24 March 2010, K-root will start serving a signed root-zone, as part of the next batch of three root servers that are going to start serving a signed root zone. We will continue our monitoring activities during the signed zone roll out at the root and update the community if we find significant anomalies. If there are specific aspects  you think we should look at, please let us know by leaving a comment in the forum below or by sending a mail to labs@ripe.net .