DNS lameness technical documentation

This page describes how our software checks zones for lameness. This is to allow recipients of alerts to understand how to check their zones in the way we do.

Software workflow

Lameness checks run on a monthly basis. At the beginning of each month a snapshot is made of all our (reverse DNS) parent zones, and all the delegations in those zones. Each nameserver in each delegation is turned into a job which is then handled as follows:

• All nameservers for every delegation are first resolved into IP address(es). Up to 5 attempts are made to do this. Failure to resolve the nameserver results in an "unable to resolve nameserver address" error condition.
• For each nameserver, contact email addresses are obtained from the RIPE Database, by looking up contact information in the relevant domain objects.
• Each nameserver IP address is queried up five times over the course of the month as described below. If a query is successful, then no more queries are sent during that month.

Details about the queries

Once the IP address(es) and contact information have been gathered the lameness checking software sends a query for the SOA record of the zone. It then expects a response with the following properties:

1. Is there a reponse to the query?
2. Does the response have a header?
3. Does the response have a RCODE other than "NOERROR"?
4. Is the reponse from the same IP address that we queries?
5. Does the answer section contain a SOA record?
6. Does the response contain more than one SOA record?
7. Is the SOA record for the zone we queried?
8. Does the response have the AA (authoritative answer) bit set?

If these checks pass, then the RNAME record parsed and the value extracted is also stored as a contact for the zone.

Summary of what conditions were tested.

As per the definition in document RIPE-400 every delegation must satisfy the following tests:

• The target of an NS RR must resolve into at least one address record RR (A or AAAA RR).
• A standard DNS UDP query with RD=0 for an SOA RR in the IN class, with QNAME=zonename, must:
  1. result in an authoritative response
  2. be sent from the same address the queries were targeted at
  3. have a single SOA RR
  4. for the QNAME in the answer section.

How to manually check a delegation for lameness.

To get started you will need to work through the following checklist. These examples the address space 193.0.1.0/24. Replace this with your own address space.

1. What nameservers does RIPE NCC have in its parent zone?
   

   We delegate your reverse DNS zones to the nameservers that you have listed in the nserver records in your domain object in the RIPE database. To query your domain object you may use the online RIPE database query tool or you can use a command line WHOIS client. In both cases you will need to query for a domain object for your reverse zone, which in this example is: 1.0.193.in-addr.arpa. You will then get back a domain object like this:

   # whois 1.0.193.in-addr.arpa
   
   % Information related to '1.0.193.in-addr.arpa'
   
   domain:         1.0.193.in-addr.arpa
   descr:          RIPE NCC Internal Use
   admin-c:        AMR68-RIPE
   tech-c:         OPS4-RIPE
   zone-c:         OPS4-RIPE
   mnt-by:         RIPE-DNS-MNT
   mnt-lower:      RIPE-NCC-MNT
   source:         RIPE
   changed:        sjoerdoo@ripe.net 20090313
   nserver:        sec1.apnic.net
   nserver:        ns-sec.ripe.net
   nserver:        ns-pri.ripe.net
   nserver:        sec3.apnic.net
   ds-rdata:       35431  5  1  38f2de182341064eac62118c3b92207956df191b
   

   In this case the delegation points to the four nameservers listed in the nserver records: ns-pri.ripe.net, ns-sec.ripe.net, sec1.apnic.net, sec3.apnic.net. If the servers that are listed in your domain object are not correct you can update this by following the instructions in step 4 of the reverse delegation how-to.



2. Resolving each of these nameservers.
   

   Each of the nameservers found in step 1 must resolve into at least one IP address. To resolve names into IP addresses there are many many tools available. On both windows and linux systems you will (most likely) have nslookup, host or dig installed by default. Use one of these tools to resolve all the nameserver names into IP addresses. On linux this will look something like:

   
   # nslookup ns-pri.ripe.net 
   Server:         123.123.123.123
   Address:        123.123.123.123#53
   
   Non-authoritative answer:
   Name:   ns-pri.ripe.net
   Address: 193.0.0.195
   

   Below is an example of a hostname that does not resolve:

   
   # nslookup broken.ripe.net 
   Server:         123.123.123.123
   Address:        123.123.123.123#53
   
   ** server can't find broken.ripe.net: NXDOMAIN
   

   Use the nslookup command or some similar tool to resolve all your nameservers that are listed in your delegation, making sure they all work correctly.



3. Checking the SOA record for your zone on each nameserver.

   Now it's time to make sure each of the nameservers for your delegation are answering correctly for your zone. For this you will need a more advanced DNS query tool such as dig by ISC (comes as part of BIND) or drill by nlnetlabs installed on your system. This example will use dig.
   To query a DNS server for a SOA record you will need to run a command similar to:

   
   # dig +noauthority +noadditional +norec @ns-pri.ripe.net 1.0.193.in-addr.arpa SOA
   
   ; <<>> DiG 9.3.1 <<>> +noauthority +noadditional +norec @ns-pri.ripe.net 1.0.193.in-addr.arpa SOA
   ; (1 server found)
   ;; global options:  printcmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53524
   ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
   
   ;; QUESTION SECTION:
   ;1.0.193.in-addr.arpa.          IN      SOA
   
   ;; ANSWER SECTION:
   1.0.193.in-addr.arpa.   172800  IN      SOA     ns-pri.ripe.net. ops.ripe.net. 2009042200 43200 7200 1209600 7200
   
   ;; Query time: 1 msec
   ;; SERVER: 193.0.0.195#53(193.0.0.195)
   ;; WHEN: Wed Apr 22 12:12:39 2009
   ;; MSG SIZE  rcvd: 172
   

   To analyze this answer you will need to look at the following things (marked in bold in the example):
   1. Is the status of the response NOERROR?
   2. Is the aa flag present in the flags section?
   3. Is there only one answer line in the answer section?
   4. Is the zone name the same as you gave in the command?
   5. Is the answer from the same IP address that you found while resolving nameservers?
   
   You will need to check the SOA records in this manner for each of the nameservers listed in the nserver records you found in step 1. If anything is wrong in the response you received when checking you may be able to find more hints in the lameness FAQ.