[rpd] New Proposal: Lame delegations in AFRINIC reverse DNS

Thu Apr 13 19:28:39 UTC 2017

+ 1 Badru

My main worry would be with implementation which I presume will require
development of a tool

Best regards

Honest Ornella GANKPA


2017-04-13 11:50 GMT+01:00 Badru Ntege <badru.ntege at nftconsult.com>:

> I would support this policy in principle
>
> Regards
>
>
>
>
> On 4/13/17, 12:58 PM, "Ernest" <ernest at afrinic.net> wrote:
>
> 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:
>
> URL: https://www.afrinic.net/en/community/policy-development/
> policy-proposals/2067-lame-delegations-in-afrinic-reverse-dns
>
>
> ===============================================
>
> Policy Proposal: Lame delegations in AFRINIC reverse DNS
>
>
> ID :AFPUB-2017-DNS-001-DRAFT-01
> Submission Date: 11/04/2017
> Version: 1.0
> Author(s):
> •    D. Shaw [daniel at afrinic.net]
> •    A. Phokeer [amreesh at afrinic.net]
> •    N. Goburdhan [nishal at pch.net]
> •    J. Engelbrecht [jaco at jacoengelbrecht.eu]
>
>
>
> 1. Summary of the problem being addressed by this proposal
>
>
> 1.1.  Background: What is "Lame Delegation"?
>
> 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]).
>
> 1.2.  Impact of Lame Delegations in the Global DNS
>
> 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.
>
> 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.
>
> 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.
>
> 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).
>
>
> 2. Summary of how this proposal addresses the problem
>
>
> 2.1.  Summary
>
> 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.
>
> 2.2.  Scope of the Policy
>
> 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.
>
> More specifically, this policy is only applicable to reverse DNS
> delegations managed within the AFRINIC region for AFRINIC majority RIR IP
> allocations and assignments.
>
> This policy should not monitor or consider reverse DNS delegations for
> minority RIR IP address resources or legacy IP address resources.
>
>
> 3. Proposal
>
>
> 3.1.  Process Detail
>
> The following text will be added into the Consolidated Policy Manual:
>
> .............................................
> 10.7 Process for Lame Delegations
>
> 10.7.1 Monitoring / Checking
>
> 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:
>
> •    Respond to DNS queries.
> •    Reply with a valid SOA record for the associated domain with in the
> WHOIS database.
>
> 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.
>
> 10.7.2 Notification
>
> 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.
>
> All of the "admin-c", "tech-c" and "zone-c" contacts should be tried in
> parallel.
>
> In addition, contact information may be extracted from associated "org"
> and/or "mnt-by" attributes when appropriate.
>
> Unanswered notification communications should also be re-tried more than
> once before moving on to further actions.
>
> The communication frequency, communication method(s) and number of
> attempts should be standardised and publicly documented.
>
> 10.7.3 Delegation Removal
>
> 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".
>
> 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.
>
> Only those nameservers flagged as lame should be removed from a given
> domain.  The domain must not have all "nserver" attributes removed.
>
> These removals should be automated.  An optional "remarks" line may be
> added to the "domain" record in the database.
>
> 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.
>
> 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.
>
> 10.7.4 Re-instatement
>
> 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.
> .............................................
>
>
>
> 3.2 Possible Operational Impact(s)
>
> 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.
>
> Therefore, removing these lame records at the parent will have no further
> adverse effects on the child zone.
>
> 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.
>
>
> 3.3 Sample Implementation Operations Guideline
>
> 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.
>
> 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.
>
>
> 4. Revision History
>
>
> 2017-03-15: First draft
>
>
> 5. References
>
>
> 5.1 Similar policies in other regions
>
> •    ARIN: Policy 2002-1: Lame Delegations in IN-ADDR.ARPA [4]
> •    APNIC: prop-038: Amending APNIC's lame DNS reverse delegation policy
> [5]
> •    LACNIC: Lame Delegation Policy within the Region Covered by LACNIC [6]
> •    RIPE NCC: No known policy at this time.
>
>
> 5.2 DNS misconfiguration studies
>
> •    Lame delegation in the AFRINIC database: How lame are our reverse
> delegations? [7]
> •    DNS Misconfiguration errors: Impact of Configuration Errors on DNS
> Robustness [8]
>
>
> 5.3 URI’s
>
> [1]    https://www.rfc-editor.org/rfc/rfc2119.txt
> [2]    https://www.ietf.org/rfc/rfc1912.txt
> [3]    https://www.afrinic.net/library/corporate-documents/
> 216-how-to-request-reverse-delegation-in-afrinic-region
> [4]    https://www.arin.net/policy/proposals/2002_1.html
> [5]    https://www.apnic.net/community/policy/proposals/prop-038/
> [6]    http://www.lacnic.net/en/web/lacnic/manual-6
> [7]    http://afrinic.net/blog/165-how-lame-are-our-reverse-delegations
> [8]    http://web.cs.ucla.edu/~lixia/papers/09DNSConfig.pdf
> [9]    https://raw.githubusercontent.com/techdad/afpub-2017-lame-
> dns/master/sample-implementation/afpub-2017-lame-dns-sample-ops-manual-
> draft-00.txt
>
> 5.4 Glossary
>
> •    DNS: Domain Name System
> •    RIR: Regional Internet Registry
> •    Majority RIR: Holds the parent allocation from IANA.
> •    Minority RIR: Administrates space within the majority allocation.
> •    Legacy Internet Resources: Internet number resources obtained prior
> to or otherwise outside the current hierarchical Internet registry system.
> •    SOA record: "Start Of Authority" record, at the head of every DNS
> zone.
>
> ===============================================
>
>
>
>
> _______________________________________________ RPD mailing list
> RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20170413/54adb65d/attachment-0001.html>