[ppml] Policy Proposal: Modification to Reverse Mapping Policy
Ed.Lewis at neustar.biz
Wed Sep 12 14:52:49 EDT 2007
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
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.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
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.
>(Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
>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
Think glocally. Act confused.
More information about the ARIN-PPML