[sig-dns]Revised Policy Proposal: Lame DNS

[Anne Lord <anne@apnic.net>]

Dear DNS Ops chair and colleagues,

Below is a revised text proposal for the DNS Ops SIG at the forthcoming
APNIC Open Policy Meeting in Korea.  

An activity is proposed for identifying, testing and disabling lame 
DNS delegations.   This was previously presented at APNIC15 and 
the revised proposal incorporates feedback received.

Your comments and feedback on this proposal are much appreciated.

Regards,
Anne
----------------------------------------------------------------------
See you at APNIC 16
Seoul, Korea, 19-22 August 2003          http://www.apnic.net/meetings
----------------------------------------------------------------------

A proposal for sweeping lame DNS reverse delegations 

Proposed by: APNIC
Version: 1.1
Date: 22 July 2003

1	Summary

This is a proposal to authorise the APNIC Secretariat to test for, and 
disable, lame DNS reverse delegations. 

The process would consist of the following steps:

"	Identify potential lameness;
"	Test the DNS reverse delegation (15 day test period); 
"	Attempt to notify the domain holder (45 day notice period); 
"	Disable lame DNS reverse delegation.

During the notice period, the APNIC Secretariat will try to contact the 
domain-holder by all reasonable means, using all contact information in 
the registered domain objects.

Disabled reverse delegations will be identified in the whois database with 
special entries in the remarks field. While a reverse DNS domain is disabled, 
the domain-holder will be emailed monthly reminders. Domain holders will be 
able to re-enable their reverse delegations at any time.

The APNIC Secretariat will report regularly to the DNS SIG on activities 
under this proposal, and will manage the process with community consultation.

2	Background and problem statement

DNS reverse delegations are considered lame if some or all of the registered 
DNS nameservers are unreachable or badly configured. APNIC research has 
shown that a significant proportion (between 10 and 15 percent) of reverse 
delegations in the APNIC Whois database are currently lame.

Lame DNS reverse delegations can cause several problems across the Internet, 
such as:

* Delays in service binding for clients using affected address ranges. These 
  delays come from timeouts in reverse-address lookup when the receiving 
  party tries to resolve the calling source address. 

* Refusal of service due to failures during DNS processing.

* Increased DNS traffic between caching DNS nameservers and the listed 
  authorities down from the root, processing requests which can only fail 
  after timeout. This represents a measurable load on critical infrastructure 
  which the RIRs have been requested to investigate and reduce.

Lame DNS reverse delegations can affect both the users of the network in 
question and unrelated third parties. End users cannot resolve this problem 
themselves because of the hierarchical nature of authoritative delegation. 
If the network administrators do not correct errors in their DNS 
configurations, the only other mechanism to reduce its impact is for the 
RIR to resume control of the delegated domain and disable the listing of the 
misconfigured servers so a valid NXDOMAIN DNS response can be sent.

The Internet community is still discussing definitions of "lameness DNS". 
However, for the purposes of this proposal, the following four types of 
problems are relevant:

Problem					
A listed DNS server is not reachable.   

Policy implication
This should be considered as lame DNS.

However, it is important to try to reach the DNS server from at least 
two geographically separate locations. If one or more locations are able 
to reach the server then it is not considered lame.

Problem
A listed DNS server is reachable, but does not respond on port 53.

Policy implication
This should be considered as lame DNS.

Problem
A listed DNS server is reachable and responds on port 53, but it is not 
able to answer for the domain.
	
This problem could arise in the following circumstances:
* The server is a secondary and has been unable to re-load the zone 
  from a master/authoritative source, with no local copy of the zone held 
  at restart time.

* An error in the runtime configuration of the zone has caused it to be 
  skipped when the server was started.

Policy implication
This should be considered as lame DNS.

Problem
A listed DNS server is reachable and responds on port 53, but serves 
incorrect data for the domain. 

Incorrect data could take one of two forms:
* Zone serial is not in synchronization with the listed master/authoritative 
  source.

* Zone serial is in synchronization, but authority bit is not set.

Policy implication
This should not be considered as lame DNS.

Although this may be considered lame under a strict definition, this problem 
does not have a significant impact on global DNS root nameservers. 

3	Other RIRs

3.1	ARIN
ARIN has a policy of managing lame reverse DNS delegations under a 30 
day notice process, which is documented at:

http://www.arin.net/policy/2002_1.html

ARIN only disables non-authoritative servers. It does not currently disable 
lame DNS for unreachable nameservers. ARIN has a year of experience with 
this policy and reports on lame DNS status at ARIN meetings.

For the purposes of the ARIN policy, DNS reverse delegations are considered 
lame if:

* AA bit is not set in response header, the zone is not marked as 
  authoritative.
* AA bit is set in response header, but there is nothing in the answer 
  section.
* AA bit is set in response header, but the answer is not an SOA record.

3.2	LACNIC
LACNIC performs DNS checks and updates whois records on a regular cycle. 
The check is based on a statistical measurement and marks lame DNS daily, 
restoring non-lame status on a weekly cycle. A proposal to formalise this 
process and de-list lame delegations may be presented at future LACNIC 
member meetings.

3.3	RIPE NCC
At this time, RIPE NCC measures the extent of lame DNS for informational 
purposes only. As is the case in other RIRs, RIPE NCC requires the listed 
authoritative nameservers to be functional at the time the reverse domain is 
first delegated. Details of the RIPE lame measurement process are available 
at:

	http://www.ripe.net/ripencc/pub-services/stats/revdns/

4	Proposal

4.1	Details of proposed procedure
It is proposed that APNIC should adopt procedures to repair or remove 
persistently lame DNS delegations. The details of the proposed procedures 
are as follows:

Step 1 - Identify potential lameness

* APNIC currently runs regular administrative tests on DNS delegations, 
for statistical purposes. It is proposed to extend the scope of these tests 
by specifically identifying potentially lame DNS delegations.

Step 2 - Test the DNS reverse delegation (15 day test period)

* When a DNS delegation is identified as potentially lame, a "lame DNS timer" 
will start.

* While the timer is running, the delegation will be regularly tested for 
lameness. The testing will be performed from at least two geographically 
separate locations.

* If the DNS delegation successfully resolves DNS during the testing period, 
then the timer will be reset. This allows for temporary problems to be fixed 
before any action is required from APNIC.

* If the timer runs for 15 days without being reset, then the DNS 
delegation will be considered as persistently lame.

Step 3 - Attempt to notify the domain holder (45 day notice period)

* Once a DNS delegation is considered persistently lame, the 45 day notice 
period will start.

* APNIC will email each admin-c and tech-c registered in the domain to 
inform them of the problem in their delegation. If the problem is not fixed, 
this email will be repeated weekly.

* If APNIC receives no reply from the emails, it will try to contact the 
domain holders using any other contact information available (such as phone, 
fax, or postal mail). APNIC may also seek contact through parent records in 
the database, upstream ISPs, and any other relevant contact details that 
may be available.

Step 4 - Disable lame DNS delegation

* If the DNS delegation is still lame at the end of the 45 day notice period, 
APNIC will insert a special marker in the remarks field of the relevant 
domain object. This marker will identify the DNS delegation as 
"administratively blocked" and will cause the delegation to be withdrawn. 

* The special marker may be removed by the domain holders at any time, using 
normal whois database procedures. 

* The special marker will contain text noting that APNIC is overriding the 
listed "nserver" records, timestamp information, and a URL to instructions for 
re-enabling the delegation.

* While the delegation remains blocked, APNIC will send monthly email 
remainders to each admin-c and tech-c.

4.2	Scope of proposed procedure
This procedure will apply to each nserver entry listed in domain objects. 
Therefore, if all nserver entries in a particular domain object are disabled 
for persistent lameness, the entire domain will be withdrawn from the DNS. In 
these cases, reverse DNS lookup will terminate in the APNIC nameservers with 
an NXDOMAIN response.

4.3	Reporting
Because DNS lameness is globally visible, details of the current status of 
all domains under test will be posted to the APNIC website. 

At each APNIC Open Policy Meeting, the DNS SIG agenda will include a report 
by the APNIC Secretariat on activities relating to DNS lameness.  Reports will 
also be sent to the DNS SIG mailing list. The reports will include the 
status of domain objects, the rate of administrative disabling and 
re-enabling, and related activities.

The APNIC Secretariat may also make additional reports to other bodies, such 
as IEPG and NANOG.

5	Implementation
This proposal will be implemented three months after it has been accepted by 
the APNIC community.