[ppml] Policy Proposal: Modification to Reverse Mapping Policy

Overall I like the idea, but to give an idea of how much of a pain it 
is to cover this in policy, here is my first pass for nits.  (Keep in 
mind I've written lame delegation test code before and have seen all 
of the "weird" cases.)

I would rather take what we (=community that came to consensus on 
proposals) have, request a review of the tools ARIN (=staff) is using 
to implement 2002-1 and 2003-5 and see where the tools are deemed to 
be insufficient by the community.

>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.

Not all of the delegations from ARIN published zones are to 
"customers" of ARIN.  Because of the Early Registration Transfers 
about 5 years ago, some of the delegations are for registrants of 
APNIC, RIPE, et.al.  We will have to keep this in mind when it comes 
to trying to contact the registrant to report a detected problem.

>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.

A delegation in DNS terminology is the subsetting of the name space 
and yielding it to another authority and is indicated by the set of 
name servers where the subsetted name space can be found.  In the 
field of DNS, we have never grouped all of the NS records with common 
"RHS (right hand sides)" to make a set of zones delegated to the RHS, 
and from this declare the "delegation" to be lame.

For a network with 4 zones, using one implementation of DNS, and only 
configuring 3 zones, if you ask the name server in the NS record for 
the SOA of the 3 working zones, you get good answers.  For the fourth 
you will get no response, making it appear that there was a network 
error.  It would not be proper to call the delegation to the name 
server "lame" (sic).

The mapping is "network"->"zone"->"domain name"->"IP address".  A 
network (e.g., a /19) will beget 32 /24 zones.  Each of the 32 zones 
will inherit the, say, 3 name servers registered to the network. 
Those 3 name servers may each have multiple addresses - IPv4 and/or 
IPv6 - so there may be 4 IP addresses to try.  Further, if there is 
anycast there could be many name servers to test for a given network. 
What if the only server for a network is one that is anycasting 
locally to the site from which testing is done?  (I'm pointing this 
out to give a taste of how much you see from the trenches.)

Requesting an SOA and failing to receive and answer is a very 
inaccurate characterization of lameness (sic).  (Please, don't 
redefine terms, in the DNS context, lame already has a, ok a few, 
IETF documented definitions.)  I'll lay aside the call to use a 
different term for "broken."

The following would also be "broken" - non-recursive query for T=SOA 
and getting back anything other than the appropriate SOA alone in the 
Answer Section (ANCOUNT=1) with the Authoritative Answer (aa) bit set 
to 1.  That covers the use of recursive servers to look like they 
slave the zone.

>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.

There will be many cases where for a network, one server will be 
broken at any moment in time.  But this is an inaccurate 
characterization of the problem.

>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).

I would rephrase this as something like this: ARIN will actively 
monitor DNS delegations from it's DNS servers to ARIN registrants and 
inform registrants of malfunctioning servers .  (Insert time and 
retry parameters here).  If a registered name server for a network 
object is found to be unsuitably operating, it will be removed from 
the network object's definition in the database.

The important point is to make the policy specify an action ARIN can 
easily take - that is the removal of the name server.  (Hey, it 
wasn't working anyway!)  But note "suitably" because it could be the 
case that the name server answers to it's selected population of 
clients and the ARIN tester but to no one else in the Internet, 
thanks to ACLs.

>7.4 References
>
>(Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
>reference/lame_delegations.html


>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

I don't want ARIN to make judgements about "reputation."

>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.

I have a hard time following the rest of the rationale.  What I can 
buy is asking ARIN to suspend/remove a name server if it's inclusion 
in the DNS causes sustained negative operational consequences.  This 
is limited to the zone involved (not the network), as that is the 
extent of the DNS "damage."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.