Measuring and Reporting on Reverse Tree DNS Lameness in the RIPE NCC Service Region

Abstract

A survey carried out in March 2006 revealed that around 11-13% of the nameservers listed in delegations from IANA to the RIPE NCC are 'lame', meaning they are not responding correctly. This document provides more information on the subject.

Table of Contents

1. Background
2. Definition of Lameness
3. Lameness Checking and Reporting
4. Interaction with ns.ripe.net
5. Email to Maintainers

1. Background

The Internet Assigned Numbers Authority (IANA) has delegated the following zones to the RIPE NCC:

• List of delegations was correct at publication date.
• This table includes those parts of Early Registration Transfer (ERX) space that are under the control of the RIPE NCC.
• ERX was a project to take IP allocations made before the RIR System started and move them into management by Regional Internet Registries.

2. Definition of Lameness

There are several definitions of lameness available. However, within the context of this document and these checks, a server will be regarded as lame if it does not satisfy the following test:

• 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 result in an authoritative response, sent from the same address the queries were targeted at with a single SOA RR for the QNAME in the answer section.
• This testing will be network layer protocol independent.

If a server fails this test it will be retried five times over a period of ten days (at varying times of day). After this time, it will be classed as lame.

• In the case of multihomed servers with multiple A (or AAAA) records, repeated failure of any of the designated A records will result in the server being classed as lame.
• In the case of anycasted servers, only the server visible from the RIPE NCC premises in Amsterdam will be tested. If this project is successful, we may expand this test to cover different areas.

3. Lameness Checking and Reporting

The RIPE NCC will run a lameness check once each month against all DNS servers listed as delegation points within the RIPE NCC delegated zones.

• Lameness will be checked over both IPv4 and IPv6, but reported separately.
• Following the completion of this check, we will send an email (via SOA RNAME) to all operators with servers reported as lame.
• We will send an email to the maintainer listed for the domain object in the RIPE Database.
• We will send just one email for each lame server.
• We will publish details and statistics of lameness levels on www.ripe.net.
• We will periodically assess the effectiveness of these efforts by reviewing the published statistics.

4. Interaction with ns.ripe.net

• As the server ns.ripe.net is a delegation target for all /16 IPv4 reverse delegations, we will check all of its zones automatically.
• We will further investigate all zones reported as lame on this server to determine why and resolve the problem as soon as is possible, although this may also involve contact with third parties.

5. Email to Maintainers

The sample text of the alert email that we will send to operators with servers reported as lame:

Dear administrator of [server name]

According to checks made on [date], your server, [server name], was lame for the following zone(s):

[zonelist]

For information about the checks that we made on your zone(s), please see:
http://www.ripe.net/ripe/docs/ripe-400.html