On 20 and 21 April 2017, the RIPE NCC organized a DNS Measurements Hackathon in Amsterdam. I thought I would be the only one curious about reverse DNS delegations, so, to avoid being disappointed, I convinced myself that the best I could expect was to work on something I could recycle later and use to measure my lovely reverse DNS delegations.
To my surprise, after mentioning my idea for a project, it turned out that two guys wanted to work with me. Yay!
Anand Buddhdev and Max Stucchi were my lovely teammates during the two-day hackathon. The fact that they also work for an RIR (the RIPE NCC in their case) explains why they were also interested in reverse DNS delegations. Anand is a Senior Engineer within the Global Information Infrastructure department and is responsible for all the internal and external services that this department provides, including reverse DNS operation; Max is a trainer with expertise in DNS/DNSSEC.
Could I have asked for better teammates?
Metrics of interest
Anand and Max used their experience and knowledge to get and process all the data we needed: data about allocations and assignments of IP prefixes made by the RIPE NCC and data about reverse DNS delegations present in the RIPE Database. I developed scripts to generate some metrics from all this data, also using some services of the RIPEstat API to get information about the status of the reverse DNS delegations being analyzed.
An invaluable contribution from Anand and Max was the definition of the metrics that could be of interest. After some discussion, we agreed on generating the following metrics:
- Per prefix metrics (generated for each prefix allocated/assigned by the RIPE NCC):
- Latency for reverse delegation of IP prefixes: Number of days that elapse since the day the prefix was allocated/assigned until the day the corresponding reverse delegation was created.
- Percentage of space covered by reverse delegations: Percentage of the total IP space covered by the prefix that is covered by domain objects present in the RIPE Database.
- Percentage of space covered by reverse delegations that present issues: For each domain object present in the RIPE Database, periodic checks are performed verifying the status of the name servers, the consistency of the delegation, the SOA (start of authority), the connectivity, and the presence of DNSSEC data for the domain. If a domain fails for any of these checks, it is marked as having issues.
- Percentage of space covered by reverse delegations that have DNSSEC data: Percentage of space that has a DS record.
- Popularity of issues: We counted how many times each type of issue appeared (when a specific check failed) to determine the most popular issues.
- Popularity of name servers: We counted the number of domains sharing each name server and the space covered by each name server (in units of /24 blocks for IPv4 and of /64 blocks for IPv6) to determine the most popular name servers.
Apart from taking back home lots of useful lines of code, I took with me some valuable new knowledge: I learned how powerful AWK can be, how important it is to use sessions from Python’s requests library when fetching web content, and how better the performance of scripts that deal with IP prefixes can be when using Python’s netaddr library.
So, thanks a lot for this, Anand and Max!
We would have loved to have presented full results at the end of the hackathon, but the number of prefixes allocated/assigned by the RIPE NCC is too high and the first version of our code was not optimized, so we just presented results for a subset of 100 prefixes.
I spent the week after the hackathon optimizing the code: I used the netaddr library to create sets of IP prefixes present in the delegated file and sets of IP prefixes for which there are reverse DNS delegations in the domains database, so that I could then intersect them and just loop through those prefixes that have reverse DNS delegations.
I also replaced the urllib2 library with the requests library so that HTTP connections were not dropped and we could get the DNS checks statuses for all the prefixes of interest.
We currently have the script running on a server and are looking forward to some interesting results. Stay tuned if you’re interested in discovering how long it takes for an organization that receives a prefix to set up the corresponding reverse DNS delegations, what proportion of IP space with reverse DNS delegations presents issues, or what the most popular issues and name servers used are.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Very interested in latency results! when do you expect to publish?
Hi Mc Tim! Good to hear from you 🙂 This is still work in progress and we do not have an estimated date for results yet.
Interesting work! (a) Could you please explain what you mean by “consistency of delegation?”, and (b) Could you also explain “Percentage of space covered by reverse delegations that have DNSSEC data?” I interpreted it to simply mean what fraction of domains that have reverse DNS names are also secured by means of DNSSEC. What does this have to do with the DS record? Couldn’t you simply have checked for the existence of KSK or ZSK?
Hi! Thank you for your comment. Let me try to answer your questions:
a) “consistency of delegation” refers to the information we get from calling the RIPEstat API service reverse-dns-consistency (https://stat.ripe.net/docs/data_api#ReverseDnsConsistency)
b) With “have DNSSEC data” we mean there is RDATA in the ‘ds-rdata’ attribute for the domain object.
From https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns#2–creating-domain–objects-for-reverse-dns:
In DNSSEC, the Delegation Signer (DS) resource record is created from a DNSKEY resource record by comparing it with the public key. The parent publishes the DS resource record. The “ds-rdata:” attribute contains the RDATA of the DS resource records related to the domain, as shown in the “domain:” attribute.
I hope this information is useful.
Cheers!