<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap:break-word"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Hi,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Is this not meant to be an operational task of Afrinic Staff maintaining the DNS? Do they need to have a policy to carry out their routine activities?</div> <br> <div id="bloop_sign_1492165298823450112" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br><span style="font-family:'helvetica Neue',helvetica;line-height:normal">Regards,</span><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><span style="font-family:'helvetica Neue',helvetica;line-height:normal">Ademola Osindero</span><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><span style="font-family:'helvetica Neue',helvetica;line-height:normal">CEO/Consulting Director</span><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><span style="font-family:'helvetica Neue',helvetica;line-height:normal">Lopworks Limited</span><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><span style="font-family:'helvetica Neue',helvetica;line-height:normal">29 Ago Palace Way,</span><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><span style="font-family:'helvetica Neue',helvetica;line-height:normal">Okota, Isolo,</span><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><span style="font-family:'helvetica Neue',helvetica;line-height:normal">Lagos, Nigeria</span><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><a href="tel://Mob: +234 8058097820" style="font-family:'helvetica Neue',helvetica;line-height:normal">Mob: +234 8058097820</a><span style="font-family:'helvetica Neue',helvetica;line-height:normal">, </span><font face="helvetica Neue, helvetica"><span style="line-height:normal"><a href="tel://+234">+234</a></span></font><a href="tel://+234 8091291780" style="font-family:'helvetica Neue',helvetica;line-height:normal"> 8091291780</a><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><a href="tel://Tel: +234 1 3422633" style="font-family:'helvetica Neue',helvetica;line-height:normal">Tel: +234 1 3422633</a><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><span style="font-family:'helvetica Neue',helvetica;line-height:normal">Email: </span><a href="mailto:ademola@ng.lopworks.com" class="" style="font-family:'helvetica Neue',helvetica;line-height:normal">ademola@ng.lopworks.com</a><br class="" style="font-family:'helvetica Neue',helvetica;line-height:normal"><span style="font-family:'helvetica Neue',helvetica;line-height:normal">Web: </span><a href="http://www.lopworks.com/" class="" style="font-family:'helvetica Neue',helvetica;line-height:normal">http://www.lopworks.com</a></div></div> <br><p class="airmail_on">On 14 April 2017 at 09:42:02, Barrack Otieno (<a href="mailto:otieno.barrack@gmail.com">otieno.barrack@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<p>Hi all,</p>
<p>I support this proposal.</p>
<p>Regards</p>
<div class="gmail_quote">On Apr 14, 2017 11:17 AM, "Derrick
Harrison" <<a href="mailto:derrick.harrison@sonictelecoms.co.za">derrick.harrison@sonictelecoms.co.za</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="m_8105369077137488238WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
I support this.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
I would also add a DNS check when adding your authoritative server
for the zone. If your DNS server is not configured to be
authoritative for the zone, then it must not be allowed to be
added.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
</span></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
From:</span></b> <span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
Ernest [mailto:<a href="mailto:ernest@afrinic.net" target="_blank">ernest@afrinic.net</a>]<br>
<b>Sent:</b> Thursday, April 13, 2017 11:58 AM<br>
<b>To:</b> AfriNIC Resource Policy Discussion List <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>><br>
<b>Subject:</b> [rpd] New Proposal: Lame delegations in AFRINIC
reverse DNS</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p>A new policy proposal updating Sec 10 of the Consolidated Policy
Manual (Reverse Delegation) has been received as follows, and is
now open for discussions:</p>
<p>URL: <a href="https://www.afrinic.net/en/community/policy-development/policy-proposals/2067-lame-delegations-in-afrinic-reverse-dns" target="_blank">https://www.afrinic.net/en/<wbr>community/policy-development/<wbr>policy-proposals/2067-lame-<wbr>delegations-in-afrinic-<wbr>reverse-dns</a></p>
<p> </p>
<p>==============================<wbr>=================</p>
<p>Policy Proposal: Lame delegations in AFRINIC reverse DNS</p>
<p style="margin-bottom:12.0pt"><br>
ID :AFPUB-2017-DNS-001-DRAFT-01<br>
Submission Date: 11/04/2017<br>
Version: 1.0<br>
Author(s):<br>
• D. Shaw [daniel at <a href="http://afrinic.net" target="_blank">afrinic.net</a>]<br>
• A. Phokeer [amreesh at <a href="http://afrinic.net" target="_blank">afrinic.net</a>]<br>
• N. Goburdhan [nishal at <a href="http://pch.net" target="_blank">pch.net</a>]<br>
• J. Engelbrecht [jaco at <a href="http://jacoengelbrecht.eu" target="_blank">jacoengelbrecht.eu</a>]<br>
<br>
<br>
<br>
1. Summary of the problem being addressed by this proposal<br>
<br>
<br>
1.1. Background: What is "Lame Delegation"?<br>
<br>
In the DNS, a lame delegation is a type of DNS misconfiguration
error that occurs when a nameserver that is designated as an
authoritative server for a domain name, does not return
authoritative data for that name, when queried. For example,
if a nameserver is delegated the responsibility for providing a
name service for a zone (via NS records) and it is not actually
doing it, i.e. the nameserver is neither set up as a primary nor
secondary server, or is unresponsive, then the NS record is
considered to be 'lame'. (RFC1912 [2]).<br>
<br>
1.2. Impact of Lame Delegations in the Global DNS<br>
<br>
In the in-addr.arpa and ip6.arpa zones, as applicable to this
policy, the DNS records considered are NS records (as in the
example above), delegating authority further down the chain of
authority. With such a delegation resulting in lame
responses, the most obvious issue is complete failure for the
specific .ARPA sub-zone that is being delegated to. This is
similar to not having any delegation in place at all: The sub-set
of .ARPA records cannot be found, and so reverse DNS lookups will
fail for that set of IP address resources. With no delegation
in place, the failure is immediate and final. The querying
client for a particular zone will get a negative response from the
parent zone's nameserver, and do no further lookups.<br>
<br>
But comparing to a lame delegation, the client receives a referral
to the lame (and invalid or broken) nameserver(s). It then
has to look them up by name before then querying one or more for
the originally requested record. If the first nameserver in
the set fails, the client may try the remainder, one by one if all
are lame.<br>
<br>
In some cases the lameness is a result of non-authority or missing
records, but in others the lame nameserver is non-existent or
unresponsive. In these cases, the client also has to wait for
the request to time-out before trying the alternate NS, or failing
completely.<br>
<br>
In summary, lame nameserver delegations as compared to no
delegation result in additional DNS traffic and a far greater time
to respond for the client, with the same practical end
outcome. In addition, the higher level parent zones that
contain these useless and effectively invalid NS records are
unnecessarily larger then needed. There is also a potential impact
on any statistical data drawn from the parent zone(s).<br>
<br>
<br>
2. Summary of how this proposal addresses the problem<br>
<br>
<br>
2.1. Summary<br>
<br>
This policy lays out a process to monitor nameserver records
responsible for lame delegations, and a phased approach to removing
these records from the DNS.<br>
<br>
2.2. Scope of the Policy<br>
<br>
This policy is intended to apply only to the DNS zones under
in-addr.arpa and ip6.arpa managed by AFRINIC. Checks should
be done for every single NS record as sourced from "domain" objects
in the AFRINIC WHOIS database.<br>
<br>
More specifically, this policy is only applicable to reverse DNS
delegations managed within the AFRINIC region for AFRINIC majority
RIR IP allocations and assignments.<br>
<br>
This policy should not monitor or consider reverse DNS delegations
for minority RIR IP address resources or legacy IP address
resources.<br>
<br>
<br>
3. Proposal<br>
<br>
<br>
3.1. Process Detail<br>
<br>
The following text will be added into the Consolidated Policy
Manual:<br>
<br>
..............................<wbr>...............<br>
10.7 Process for Lame Delegations<br>
<br>
10.7.1 Monitoring / Checking<br>
<br>
All "domain" objects in the AFRINIC WHOIS database must be
periodically examined, and all "nserver" attributes extracted for
checking. Each "nserver" found must be checked to:<br>
<br>
• Respond to DNS queries.<br>
• Reply with a valid SOA record for the
associated domain with in the WHOIS database.<br>
<br>
This periodic checking should be automated. The checks should
be relatively frequent, but not so frequent as to cause any
operational impact to either AFRINIC systems or the global DNS. If
a nameserver fails a check for the first time, this is initially
just recorded. Only after failing multiple lameness checks,
should a nameserver be flagged for further action.<br>
<br>
10.7.2 Notification<br>
<br>
After one or more nameservers are flagged as lame, a reasonable
attempt must be made to contact the person(s) responsible for the
"domain" object and the DNS delegation.<br>
<br>
All of the "admin-c", "tech-c" and "zone-c" contacts should be
tried in parallel.<br>
<br>
In addition, contact information may be extracted from associated
"org" and/or "mnt-by" attributes when appropriate.<br>
<br>
Unanswered notification communications should also be re-tried more
than once before moving on to further actions.<br>
<br>
The communication frequency, communication method(s) and number of
attempts should be standardised and publicly documented.<br>
<br>
10.7.3 Delegation Removal<br>
<br>
Once a given nameserver had been determined to be lame for a given
DNS "domain", and reasonable attempts have been made to contact a
responsible person, the nameserver must then be removed from the
given DNS "domain".<br>
<br>
The nameserver must not be removed from all WHOIS objects and DNS
zones, as it may not be uniformly lame for other zones it
serves.<br>
<br>
Only those nameservers flagged as lame should be removed from a
given domain. The domain must not have all "nserver"
attributes removed.<br>
<br>
These removals should be automated. An optional "remarks"
line may be added to the "domain" record in the database.<br>
<br>
Should a given domain have all it's nameserver's identified as
lame, and thus removed, it must then also be removed from the
database, due to the "nserver" attribute being mandatory for
"domain" objects.<br>
<br>
Historical information about removed nameservers and domain objects
should be archived for a reasonable amount of time and made
available to the member for informational purpose.<br>
<br>
10.7.4 Re-instatement<br>
<br>
Once nameservers are fixed, or alternate nameservers are available
for a given reverse DNS zone, the responsible person(s) would add
delegation to them in the same way as a new delegation is done for
a new IP assignment or allocation.<br>
..............................<wbr>...............<br>
<br>
<br>
<br>
3.2 Possible Operational Impact(s)<br>
<br>
A DNS delegation of a child-zone by lame NS records in the
parent-zone will result in partial or complete failure of the
child-zone.<br>
<br>
Therefore, removing these lame records at the parent will have no
further adverse effects on the child zone.<br>
<br>
In the case of partial lameness, where not all nameservers are
found to be lame, the impact will be positive: The removal of
failing delegations will result in no DNS failures, rather than
partial.<br>
<br>
<br>
3.3 Sample Implementation Operations Guideline<br>
<br>
The authors are aware that there would be significant work to be
done to implement this policy. They have worked on a
guideline for implementation, should the policy be passed.<br>
<br>
A sample operational manual is available online [9] as a guideline
to AFRINIC staff to use. Input and text, is welcome, but
please note that this is a sample for implementation and not part
of the policy.<br>
<br>
<br>
4. Revision History<br>
<br>
<br>
2017-03-15: First draft<br>
<br>
<br>
5. References<br>
<br>
<br>
5.1 Similar policies in other regions<br>
<br>
• ARIN: Policy 2002-1: Lame Delegations in
IN-ADDR.ARPA [4]<br>
• APNIC: prop-038: Amending APNIC's lame DNS
reverse delegation policy [5]<br>
• LACNIC: Lame Delegation Policy within the
Region Covered by LACNIC [6]<br>
• RIPE NCC: No known policy at this time.<br>
<br>
<br>
5.2 DNS misconfiguration studies<br>
<br>
• Lame delegation in the AFRINIC database: How
lame are our reverse delegations? [7]<br>
• DNS Misconfiguration errors: Impact of
Configuration Errors on DNS Robustness [8]<br>
<br>
<br>
5.3 URI’s<br>
<br>
[1] <a href="https://www.rfc-editor.org/rfc/rfc2119.txt" target="_blank">https://www.rfc-editor.org/<wbr>rfc/rfc2119.txt</a><br>
[2] <a href="https://www.ietf.org/rfc/rfc1912.txt" target="_blank">https://www.ietf.org/rfc/<wbr>rfc1912.txt</a><br>
[3] <a href="https://www.afrinic.net/library/corporate-documents/216-how-to-request-reverse-delegation-in-afrinic-region" target="_blank">https://www.afrinic.net/<wbr>library/corporate-documents/<wbr>216-how-to-request-reverse-<wbr>delegation-in-afrinic-region</a><br>
[4] <a href="https://www.arin.net/policy/proposals/2002_1.html" target="_blank">https://www.arin.net/policy/<wbr>proposals/2002_1.html</a><br>
[5] <a href="https://www.apnic.net/community/policy/proposals/prop-038/" target="_blank">https://www.apnic.net/<wbr>community/policy/proposals/<wbr>prop-038/</a><br>
[6] <a href="http://www.lacnic.net/en/web/lacnic/manual-6" target="_blank">http://www.lacnic.net/en/web/<wbr>lacnic/manual-6</a><br>
[7] <a href="http://afrinic.net/blog/165-how-lame-are-our-reverse-delegations" target="_blank">http://afrinic.net/blog/165-<wbr>how-lame-are-our-reverse-<wbr>delegations</a><br>
[8] <a href="http://web.cs.ucla.edu/~lixia/papers/09DNSConfig.pdf" target="_blank">http://web.cs.ucla.edu/~lixia/<wbr>papers/09DNSConfig.pdf</a><br>
[9] <a href="https://raw.githubusercontent.com/techdad/afpub-2017-lame-dns/master/sample-implementation/afpub-2017-lame-dns-sample-ops-manual-draft-00.txt" target="_blank">https://raw.githubusercontent.<wbr>com/techdad/afpub-2017-lame-<wbr>dns/master/sample-<wbr>implementation/afpub-2017-<wbr>lame-dns-sample-ops-manual-<wbr>draft-00.txt</a><br>
<br>
5.4 Glossary<br>
<br>
• DNS: Domain Name System<br>
• RIR: Regional Internet Registry<br>
• Majority RIR: Holds the parent allocation from
IANA.<br>
• Minority RIR: Administrates space within the
majority allocation.<br>
• Legacy Internet Resources: Internet number
resources obtained prior to or otherwise outside the current
hierarchical Internet registry system.<br>
• SOA record: "Start Of Authority" record, at the
head of every DNS zone.<br>
<br>
==============================<wbr>=================<br>
<br>
<br>
<br></p>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/<wbr>mailman/listinfo/rpd</a><br>
<br></blockquote>
</div>
_______________________________________________
<br>RPD mailing list
<br><a href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<br><a href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
<br></div></div></span></blockquote></body></html>