APNIC operational response to lame DNS reverse delegations
About this document
This document represents the current APNIC operational response to lame DNS reverse delegations.
This document should be read in conjunction with other APNIC documents, particularly those dealing with reverse DNS delegations. A selection of FAQs relating to lame DNS is available at:
Introduction
DNS reverse delegations are considered lame if some or all of the registered DNS nameservers are unreachable or badly configured. 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, and the hierarchical nature of authoritative delegation means that end users cannot resolve the problem themselves. If the network administrators do not correct errors in their DNS configurations, the only other way to reduce the impact of those errors is for the RIR to resume control of the delegated domain and disable the listing of the misconfigured servers so that a valid NXDOMAIN DNS response can be sent.
Action on lame DNS reverse delegations
In the interests of maintaining accurate reverse DNS delegation data, and limiting the problems caused by faulty data, APNIC applies procedures to repair or remove persistently lame DNS delegations. The process consists of a number of steps, listed below:
Step 1 – Identify potential lameness
There are a number of specific circumstances which APNIC considers when determining whether a reverse delegation is "lame".
Problem |
Policy implication |
A listed DNS server is not reachable. |
APNIC considers this to be 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. |
A listed DNS server is reachable, but does not respond on port 53. |
APNIC considers this to be lame DNS. |
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.
|
APNIC considers this to be lame DNS. |
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.
|
APNIC does not consider this to be lame DNS.
Although some may describe this as lame under a strict definition, this problem does not have a significant impact on global DNS root nameservers. |
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, APNIC will regularly test the delegation for lameness. APNIC will perform this testing 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 APNIC will consider the DNS delegation to be 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. It will also list 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.
Reporting
Because DNS lameness is globally visible, the APNIC Secretariat will publish details of the current status of all domains under test on 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.
Top | Resource services
|
