APNIC’s operational response

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 that 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 a 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 a 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 secondary and has been unable to reload 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 a lame DNS.
A listed DNS server is reachable and responds on port 53 but serves incorrect data for the domain.

  • A valid DNS response is sent, but the authority bit is not set.
APNIC considers this to be a lame DNS.

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.
  • If the DNS delegation successfully resolves the 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 test 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 that contains instructions for re-enabling the delegation.
  • While the delegation remains blocked, APNIC will send monthly email remainders to each admin-c and tech-c.