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 29th 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, the server 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 | Send the First reminder 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 | Send the Second reminder to the admin-c,zone-c, and tech-c contacts |
| Day 24 | If delegation is still lame | Send last and final reminder 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 lookup 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 Lame Delegation?
AFRINIC highly recommends that the necessary steps must be taken to correct the DNS lameness issue before deletion takes place; this could either be, 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 https://my.afrinic.net
- 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 on the AFRINIC website https://www.afrinic.net/whois or through e-mail, where the domain objects can be submitted to This email address is being protected from spambots. You need JavaScript enabled to view it..
The implementation is designed to minimize the possibility of false positives and we recommend to members to make use of the lameness checker https://afrinic.net/whois/lame to verify against false positives as well validating any updates made or any new reverse domain delegation registered.
Statistics regarding Lame DNS delegation statistics are available here: https://stats.afrinic.net/lamerdns/
For any inquiries, you can contact This email address is being protected from spambots. You need JavaScript enabled to view it..
Further reference:
Consolidated Policy Manual section 10.7 at https://afrinic.net/policy/manual#lame
How to resolve Lame Delegation? https://afrinic.net/support/whois/resolve-lame-delegation
DNS troubleshooting best practices are recommended in RFC 1912 at https://www.ietf.org/rfc/rfc1912.txt