AFRINIC has implemented the Lame Delegation policy proposal in its entirety; specifically fulfilling the requirements of Section 10.7 of the CPM.
The planned go-live date is 29 April 2021.
Definition of ‘lame’
An authoritative DNS name server is considered lame when it does not adequately respond to queries for a domain for which it is the designated Start of Authority (SOA).
For the purpose of this policy implementation, a DNS nameserver that, if queried using a standard DNS client or library, does not respond with an authoritative answer for the specific domain is considered lame.
No differentiation is made here between the following behaviours of a DNS server:
- 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.
All the above variations result in a ‘lame’ delegation.
What does this implementation entail?
DNS lameness tests will be run on a monthly basis on all nameservers registered as “nserver” records within “domain” objects in the AFRINIC WHOIS database.
These checks will be running from at least three different geographical locations and a single successful recorded authoritative answer from a single test location is sufficient to not consider a nameserver as “lame”.
Once a given ‘nserver’ record 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 will be added to the domain object in the database recording this.
In the event that all nameserver records are lame for a given domain, the domain object will be removed in its entirety.
The complete “lameness” checking approach is as follows:
| Time | Status | Action |
|---|---|---|
| Day 0 | Lame delegation is first detected | Lame delegation recorded, nameserver to be re-tested for lameness every day |
| Day 3 | If delegation is still lame | Initial notification is sent to the registered admin-c, zone-c and tech-c contacts |
| Day 10 | If delegation is still lame | First reminder sent to the registered admin-c, zone-c and tech-c contacts |
| Day 11 | If lame delegation is still detected | A remark is added in the domain object identifying the lame nameserver(s) |
| Day 17 | If delegation is still lame | Second reminder sent to the admin-c, zone-c and tech-c contacts |
| Day 24 | If delegation is still lame | Last and final reminder sent to the admin-c, zone-c and tech-c contacts |
| Day 30 | If reverse DNS delegation is still lame | The “nserver” record will be removed from the domain object(s) for which it is lame. Any “domain” object that thus has zero “nserver” records will be removed from the WHOIS database. |
The lameness checks will continue to run on a daily basis and where a nameserver is no longer detected as lame, the corresponding remark will be removed.
What is the impact on members whose domains have lame delegations?
The negative impact of reverse DNS lame delegations will affect the users of the network in question as well as any third parties relying on DNS records from the affected domain.
DNS lookups for deleted domains will be answered by an NXDOMAIN response, meaning this domain is not listed in any AFRINIC DNS zone.
What can a member do to resolve a lame delegation?
AFRINIC highly recommends that the necessary steps be taken to correct the DNS lameness issue before deletion takes place; this could be either by making the nameservers authoritative for the relevant zones, or by editing the list of nameservers in the “nserver” attributes of the relevant “domain” objects.
Objects with lame delegations can be updated by logging in to MyAFRINIC:
- Go to the “Resources” tab
- Select “Reverse Delegation” in the drop-down list
- Click the expand icon adjacent to the IP prefix
- Select the edit icon
You may also do it through the WHOIS web interface or through e-mail, where the domain objects can be submitted to auto-dbm@afrinic.net.
The implementation is designed to minimise the possibility of false positives and we recommend that members make use of the lameness checker to verify against false positives as well as to validate any updates made or any new reverse domain delegation registered.
Statistics regarding lame DNS delegations are available at stats.afrinic.net/lamerdns.
For any inquiries, you can contact hostmaster@afrinic.net.
Further reference
- Consolidated Policy Manual, section 10.7
- How to resolve a lame delegation (Support & FAQs, WHOIS DB)
- DNS troubleshooting best practices are recommended in RFC 1912