[sig-dns]Revised Policy Proposal: Lame DNS
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.
