Your IP address is 3.233.219.62

Related articles

The Policy Development Process Public Policy Meetings View Current Policies
Policy Manual View recent discussions
(mailing list)
The Policy Development Working Group (PDWG) Meeting Minutes View Policy Proposals
(under discussion)

Participate in the policy discussions (mailing list)

Propose a policy

Filters

Implementation of policy proposal “Lame Delegations in the AFRINIC reverse DNS”

A. Preamble

On 28th March 2018, the AFRINIC Board ratified the policy proposal "Lame Delegations in the AFRINIC reverse DNS".This policy lays out a process to monitor nameserver records responsible for lame delegations, and puts in place a phased approach for removing these records from the DNS. Its aim is to enable AFRINIC to remove lame delegation records from ‘domain’ objects in the AFRINIC database.

 

What is a Lame Delegation

A DNS nameserver is considered lame if, when queried using a standard DNS client or library, the server does not respond with an authoritative answer for the specific domain.

All the following variations will result in 'lame' records when a name server is:

  • Not responding at all.
  • Responding in some way, but not for the specific domain queried.
  • Responding for the correct domain, but without the authority bit set.

Lame delegations are undesirable, and can cause many problems including, but not limited to:

  • Denial of certain services (as well as some delays) caused by DNS malfunctions.
  • Timeouts from unresponsive servers can possibly increase DNS traffic (between caching and authoritative DNS servers) - resulting in possible load on infrastructure and increased operating costs.

Once implemented, this policy will impact AFRINIC operations and membership as follows.

  1. Tests will be run on a monthly basis on all nameservers referenced by "nserver" attributes within "domain" objects in the AFRINIC WHOIS Database. Nameservers are referenced within domain whois database objects as follows:

    domain: 2.0.192.in-addr.arpa

    descr: rDNS for Company A (Pty) Ltd

    admin-c: TEST123-AFRINIC

    tech-c: TEST123-AFRINIC

    zone-c: TEST123-AFRINIC

    nserver: ns1.test.example.com

    nserver: ns1.test.example.com

    mnt-by: TEST999-MNT

    changed: This e-mail address is being protected from spambots. You need JavaScript enabled to view it example.com

    source: AFRINIC

  2. Tests will be performed from multiple vantage points, using all relevant IP addresses for the nameserver. If some tests pass and some fail, then the nameserver will NOT be considered as lame. If all tests show that the nameserver is lame for the specified domain, then AFRINIC will notify the responsible persons, as described in the timeline below.
  3. If a lame server is not corrected, then AFRINIC will remove the nameserver from the domain, and may remove the domain entirely, as described in the timeline below.
  4. General lame delegation reports will be published monthly. 
  5. AFRINIC will put in place a public lameness checker tool and new nameserver entries for domain objects will be systematically checked for lameness prior to data going into the public WHOIS database.

 

B. Implementation

The policy text concerning Lame Delegations appears in article 10.7 of the Consolidated Policy Manual as follows:

10.7 Removal of ‘Lame’ Delegations

Once a given ‘nserver’ attribute has been determined to be lame for a given domain, and reasonable attempts have been made to contact the responsible person(s), the nserver attribute must then be removed from the given domain object. A ‘remarks’ line should be added to the domain object in the database recording this.

In the event all nameserver records are lame for a given delegation, the domain object would be removed in its entirety. Historical information about removed domain objects should be archived for a reasonable amount of time and made available as necessary.

Although the policy text does not explicitly state the time limits within which "nserver" attributes responsible for lame delegations shall be removed from domain whois objects, or actual deletion of the domain whois database object altogether should all listed "servers" be lame, AFRINIC has implemented the following timelines:

Day

Action

1

The delegation is parsed & tested.

3

If the delegation is still lame, a notification is sent by email to the admin-c, tech-c and zone-c contacts.

10

If the delegation is still lame, a first reminder is sent by email to the admin-c, tech-c and zone-c contacts.

11

If the delegation is still lame, a remark is added to the domain object in the WHOIS DB.

17

If the delegation is still lame, a second reminder is sent by email to the admin-c, tech-c and zone-c contacts.

24

If the delegation is still lame, a LAST reminder is sent by email to the admin-c, tech-c and zone-c contacts.

30

If the delegation is still lame, the offending nserver attribute is removed from the domain object. And if the domain object does not have any remaining nserver, it is deleted. A notification is sent by email to the admin-c, tech-c and zone-c contacts.

As of August 2018, approximately 50,000 domain objects in the AFRINIC database have been detected to conatin lame delegation records. These objects will go through the checks and notifications schedule as indicated in the table above as soon as the policy has been implemented.

 

C. "Lameness" Stats & Check Tool

  • Global lame delegation stats will be published at https://www.afrinic.net/en/services/statistics (Under the "Lame Delegations" tab).
  • Members will at a point in future, be able to check and/or see which of their domains have lame delegations from within MyAFRINIC (Under "Resources -> Reverse Delegation).

D. Updating Objects with Lame Delegations

Objects with lame delegations can be corrected or updated using the usual whois database update methods below:

  1. Through MyAFRINIC, under the "Reverse Delegation" tab in the "Resources" Menu.
  2. Via the WHOIS server update section of the AFRINIC website - https://www.afrinic.net/services/whois-query
  3. Through e-mail, where the domain objects can be submitted to  This e-mail address is being protected from spambots. You need JavaScript enabled to view it  for automatic processing.

 

Members can always contact  This e-mail address is being protected from spambots. You need JavaScript enabled to view it  for any additional assistance.

While attempting to troubleshoot any identified lame delegations, members and the community at large are encouraged to adopt best practices recommended in DNS troubleshooting - such as those in RFC 1912 - https://www.ietf.org/rfc/rfc1912.txt

Discussions are taking place on the policy working group mailing list if you want to subscribe to the mailing send your subscription request to rpd-request [at] afrinic.net with 'Subscribe' as subject line


Mailing list archives can be found at https://lists.afrinic.net/pipermail/rpd