<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Dear Community,</div><div class=""><br class=""></div><div class="">AFRINIC carried out an experiment on the WHOIS database and checked for lame delagations on our domain objects. Domain objects are used to register reverse delegation from our members to whom resources have been allocated or assigned. A domain object consists of two main parts: the reverse zone and a set of name servers. </div><div class=""><br class=""></div><div class="">A name server is considered 'lame' if it is found to be either:</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- not responsive</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- not serving the intended zone</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- not authoritative</div><div class=""><br class=""></div><div class="">At the time of the experiment, AFRINIC had 29894 'in-addr.arpa' domain objects with 72341 NS records and 196 'ip6.arpa' domain objects with 550 NS records.</div><div class="">We studied each <domain, NS> tuple. </div><div class=""><br class=""></div><div class="">In total, it was found that 45.5% of <domain, NS> records to be lame for IPv4 zones and 32% for IPv6 zones. The cause of lameness is due to unresponsive DNS servers (23.5%), name servers not serving the intended zone (75.5%) and non-authoritative NS (1%) for both v4 and v6.</div><div class=""><br class=""></div><div class="">Lame delegations can negatively impact Internet performance for example through delayed DNS lookups or simply failed responses. It is therefore important to provide a clean reverse delegation database to improve the robustness of the DNS.</div><div class=""><br class=""></div><div class="">Other RIRs have set stringent operational checks, that remind operators to fix their lame name servers, failing which, reverse delegations are simply removed. LACNIC has a lame delegation policy [1].</div><div class=""><br class=""></div><div class="">Questions to the community:</div><div class="">1. Should AFRINIC implement operational checks that are run periodically and members are informed about the status of their domain objects. After X reminders, if domain object still contain lame NS records, domain object are removed.</div><div class=""><br class=""></div><div class="">2. Should the AFRINIC community enforce lame delegation removal through a policy.</div><div class=""><br class=""></div><div class="">More details of the study can be found here [2].</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">AFRINIC</div><div class=""><br class=""></div><div class="">[1] <a href="http://www.lacnic.net/en/web/lacnic/manual-6" class="">http://www.lacnic.net/en/web/lacnic/manual-6</a></div><div class="">[2] <a href="http://afrinic.net/blog/165-how-lame-are-our-reverse-delegations" class="">http://afrinic.net/blog/165-how-lame-are-our-reverse-delegations</a></div><div class=""><br class=""></div></body></html>