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

Thu Apr 13 14:59:34 UTC 2017

I support this.

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.

*From:* Ernest [mailto:ernest at afrinic.net]
*Sent:* Thursday, April 13, 2017 11:58 AM
*To:* AfriNIC Resource Policy Discussion List <rpd at afrinic.net>
*Subject:* [rpd] New Proposal: Lame delegations in AFRINIC reverse DNS

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.

===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20170413/768350eb/attachment-0001.html>