[ppml] Policy Proposal: Modification to Reverse Mapping Policy

[Dean Anderson]

This proposal is misguided since it decides lameness on a per-nameserver 
basis rather than a per zone basis.

A DNS zone is working if even one nameserver responds to queries for
that zone.

It doesn't matter if a nameserver serves multiple zones, some of which
it actually is configured to serve, and thus is not lame for some zones.  
Nor does it matter if a nameserver serves multiple zones, and does not
respond for any of those zones.

The current policy properly identifies lameness by zone, and removes
delegation records when the _zone_ is lame. A zone is only lame when
_no_ nameservers respond to queries for that zone.  In that case, ARIN
can, after appropriate steps, remove delegation records.  The current
policy is proper so that ARIN nameservers can give out NXDomain
responses (which are also cached) for those zones that won't be
supported anyway.

However, if even one nameserver responds for a zone, there is no reason
for ARIN to take any steps at all: The zone is not lame.  It is not
ARIN's responibility to monitor the uptime of all delegated namesevers,
or otherwise ensure that all nameservers are working for a zone, or for
any group of zones.  There is no harm to ARIN if the zone is not lame,
but some of the nameservers for that zone are not working.

If some other group wants to monitor nameservers and report failures,
that is up to them. But monitoring nameservers isn't a task that belongs
to ARIN, beyond the issue of zone lameness.

Therefore, this policy should not be accepted.


Dean Anderson 
Av8 Internet, Inc 
(a longtime DNSEXT WG and DNSOP WG participant, and discoverer of
various DNS-related scams.)


On Wed, 12 Sep 2007, Member Services wrote:
> 
> Policy Proposal Name: Modification to Reverse Mapping Policy
> 
> Author: John Von Essen
> 
> Proposal Version: 1.0
> 
> Submission Date: September 11, 2007
> 
> Proposal type: modify
> 
> Policy term: permanent
> 
> Policy statement:
> 
> I am proposing a modification to section 7 of the IPv4 policy such that
> a more precise definition and overview of lameness is described.
> Below is how I think section 7 should be re-written.
> 
> START NEW Section
> 
> 7. Reverse Mapping
> 
> 7.1. Maintaining IN-ADDRs
> 
> All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
> from ARIN will be responsible for maintaining all IN- ADDR.ARPA domain
> records for their respective customers. For blocks smaller than /16, and
> for the segment of larger blocks which start or end with a CIDR prefix
> longer than /16, ARIN can maintain IN-ADDRs through the use of the SWIP
> (Reallocate and Reassign) templates or the Netmod template for /24 and
> shorter prefixes.
> 
> 7.2 Definitions
> 
> 7.2.1 Lame Delegation
> 
> A delegation is defined as being lame if all of the in-addr.arpa zones
> for a given name server of a specific network registration are lame. An
> in- addr.arpa zone is defined as lame when ARIN requests the SOA record
> from the name server registered in whois, but does not receive an answer.
> 
> 7.2.2 Partially Lame Delegation
> 
> A delegation is defined as being partially lame if at least one in-
> addr.arpa zone for a given name server of a specific network
> registration is lame. An in- addr.arpa zone is defined as lame when ARIN
> requests the SOA record from the name server registered in whois, but
> does not receive an answer.
> 
> 7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA
> 
> ARIN will actively identify lame and partially lame DNS name server
> (s) for reverse address delegations associated with address blocks
> allocated, assigned or administered by ARIN. Upon identification of a
> lame or partially lame delegation, ARIN shall attempt to contact the POC
> for that resource and resolve the issue. If, following due diligence,
> ARIN is unable to resolve the lame or partially lame delegation, ARIN
> will update the WHOIS database records resulting in the removal of lame
> or partially lame DNS servers. ARIN's actions in resolving lame and
> partially lame delegations is governed by the procedures set forth in
> (Lame-Ref).
> 
> 7.4 References
> 
> (Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
> reference/lame_delegations.html
> 
> 
> STOP NEW Section
> 
> 
> Rationale:
> 
> Current policy only considers an Org's delegation being deemed lame if
> all of in-addr.arpa zones for a given name server of a specific network
> registration are lame. Lame is defined when ARIN tests an in-addr.arpa
> zone by requesting the SOA record from the name server registered in
> whois, but does not receive an answer. If deemed lame, ARIN has an
> appropriate procedure for contacting the Org and handling the issue as
> per "http://www.arin.net/ reference/lame_delegations.html".
> 
> Unfortunately, the policy does not cover the situation of a so-called
> partially lame delegation. That is, some of the in-addr.arpa zones
> belonging to the network registration return a valid SOA upon testing,
> and some do not. Even if only one /24 in-addr.arpa reverse tests comes
> back as lame, it is my opinion that this still taints the reputation of
> entire network registration. IPs belonging to that lame in-addr.arpa
> zone will cause query timeouts to 3rd party dns resolvers, both public
> and private. These excessive timeouts in my opinion can harm the overall
> well-being of reverse dns functionality throughout the internet. The
> only way to prevent such harm is for ARIN to not delegate reverse
> authority to the so-called partially lame dns server as registered in
> whois. That is the purpose of this policy proposal, to consider partial
> lameness with the same prejudice as traditionally defined lameness.
> Org's who are partially lame should be contacted by ARIN and lame
> in-addr.arpa zones should be resolved as the procedures per
> "http://www.arin.net/reference/ lame_delegations.html" dictate.
> 
> Timetable for implementation: June 1, 2008
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000