<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <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 class="moz-txt-link-freetext" href="https://www.afrinic.net/en/community/policy-development/policy-proposals/2067-lame-delegations-in-afrinic-reverse-dns">https://www.afrinic.net/en/community/policy-development/policy-proposals/2067-lame-delegations-in-afrinic-reverse-dns</a></p>
    <p><br>
    </p>
    <p>===============================================</p>
    <p>Policy Proposal: Lame delegations in AFRINIC reverse DNS</p>
    <p><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 afrinic.net]<br>
      •    A. Phokeer [amreesh at afrinic.net]<br>
      •    N. Goburdhan [nishal at pch.net]<br>
      •    J. Engelbrecht [jaco at jacoengelbrecht.eu]<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>
      .............................................<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>
      .............................................<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 class="moz-txt-link-freetext" href="https://www.rfc-editor.org/rfc/rfc2119.txt">https://www.rfc-editor.org/rfc/rfc2119.txt</a><br>
      [2]    <a class="moz-txt-link-freetext" href="https://www.ietf.org/rfc/rfc1912.txt">https://www.ietf.org/rfc/rfc1912.txt</a><br>
      [3]   
<a class="moz-txt-link-freetext" href="https://www.afrinic.net/library/corporate-documents/216-how-to-request-reverse-delegation-in-afrinic-region">https://www.afrinic.net/library/corporate-documents/216-how-to-request-reverse-delegation-in-afrinic-region</a><br>
      [4]    <a class="moz-txt-link-freetext" href="https://www.arin.net/policy/proposals/2002_1.html">https://www.arin.net/policy/proposals/2002_1.html</a><br>
      [5]    <a class="moz-txt-link-freetext" href="https://www.apnic.net/community/policy/proposals/prop-038/">https://www.apnic.net/community/policy/proposals/prop-038/</a><br>
      [6]    <a class="moz-txt-link-freetext" href="http://www.lacnic.net/en/web/lacnic/manual-6">http://www.lacnic.net/en/web/lacnic/manual-6</a><br>
      [7]   
      <a class="moz-txt-link-freetext" href="http://afrinic.net/blog/165-how-lame-are-our-reverse-delegations">http://afrinic.net/blog/165-how-lame-are-our-reverse-delegations</a><br>
      [8]    <a class="moz-txt-link-freetext" href="http://web.cs.ucla.edu/~lixia/papers/09DNSConfig.pdf">http://web.cs.ucla.edu/~lixia/papers/09DNSConfig.pdf</a><br>
      [9]   
<a class="moz-txt-link-freetext" href="https://raw.githubusercontent.com/techdad/afpub-2017-lame-dns/master/sample-implementation/afpub-2017-lame-dns-sample-ops-manual-draft-00.txt">https://raw.githubusercontent.com/techdad/afpub-2017-lame-dns/master/sample-implementation/afpub-2017-lame-dns-sample-ops-manual-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>
      ===============================================<br>
      <br>
      <br>
      <br>
      <br>
    </p>
  </body>
</html>