[ppml] Comments on ARIN's reverse DNS mapping policy

As an "arin mainland policy expert" with a lot of experience in 
lameness and DNS...

ARIN lame delegation proposals: 2002-1 and 2005-3.  2002-1 was 
ratified by the BoT on 17 November 2002 and 2005-3 was ratified on 16 
June 2005 and has an implementation date of 22 August 2007.  (From 
the ARIN web site.  BTW, the link from 2002-1's archive to the ARIN 
IX minuted is broken [404].)  In 2003 an update on this was presented 
to NANOG (http://www.nanog.org/mtg-0306/lewis.html).

The term "lame" in the context of DNS is defined by the IETF in RFC 
1612, 1713, 1912, and 3658.  The word lame is defined more narrowly 
than is used in practice.  Lameness is in the eye of the client and 
applies only when the client *receives a response* indicating that 
the server does not *know* the answer.  In practice, situations when 
a response does not arrive at the client has been called lame, even 
if the reason for the failure is due to an underlying network layer 
event (like packets being filtered at a firewall).

Why did ARIN pass 2002-1?  Because a widely popular implementation of 
DNS (back in the day) would be sent into a loop when it received a 
DNS referral message pointing back "up" the tree.  This made the 
presence of lame delegations an operational issue.  This 
implementation has apparently faded from general use, the operational 
impact diminished, and the topic of correcting lame delegations has 
taken a back seat to other work.

As far as general DNS reverse mapping policy, there has been an 
ongoing discussion within the IETF to produce a document on this. 
Here is the URL for a DNS Operations Working Group document in 
progress:
http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reverse-mapping-considerations/

To give an idea of how much trouble specifying operational 
requirements for reverse mapping is, the topic first appears in the 
IETF Meeting archives at
http://www3.ietf.org/proceedings/00dec/I-D/draft-ietf-dnsop-inaddr-required-00.txt 
in the report of the December 2000 meeting of the DNSOP WG.  (I have 
a personal recollection of the topic being raised at the meeting a 
few months earlier, in August 2000.)  Given the date of the cited 
document, it's been over seven years for the IETF to generate any 
statement on the topic.

What would happen if a policy were to be introduced into ARIN on this?

First an argument over the nature of reverse mapping would happen. 
As you could imagine, if the IETF takes seven plus years to come to 
consensus on this, it'll take ARIN about as long.  (Neither 
organization is smarter than the other.)  Even is there is an IETF 
RFC, I would bet that there will still be at least a small debate 
held here.

Second, the policy would really have to make a statement on what ARIN 
does regarding reverse mapping.  ARIN already offers to make 
delegations.  If the delegations are lame ARIN will cull them (per 
2005-3).  There has been talk of using the threat of culling 
delegations as a carrot/stick to make legacy holders sign agreements 
with ARIN - I say this only as an example of ARIN's action be to stop 
delegations, not because I agree with that.

I could imagine a policy proposal that says "operate reverse mapping 
DNS or lose your allocation" as being the one way to force reverse 
mapping to happen.  But I  also imagine that any such proposal would 
"go down in flames."

I'll conclude by saying that the anal-retentive DNS-wonk engineer in 
me really wants to see a fully populated reverse map zone.  But 
observing the behavior of humans who make decisions, reverse mapping 
is something that isn't going to become mandatory.  I would be 
willing to help any policy that encourages population of the reverse 
map, but given what I've witnessed I think the effort is Quixotic.

ARIN could institute a service of offering free slave service to all 
allocations to encourage reverse map population.  However there are 
problems with this.  One, such an offering is not a topic for a 
policy proposal (see proposals 2007-1,2,3 for what I mean).  Two, 
this would conflict with commercial efforts to provide slave service. 
(A unit of my employer is in that market.)  I raise this because RIPE 
has historically provided slave service but requests have been made 
to cease the free service.

(See: http://ripe.net/ripe/maillists/archives/dns-wg/2006/msg00173.html
    51.3 Lars-Johan Liman -- NCC Secondary Service Policy
         Lars commented that the RIPE NCC has announced it will limit
         involvement in provision of slave servers for TLDs. Lars suggested
         this be closed for now and marked as overtaken by events.
         The working group agreed.
         [[Done, pending mailing list approval]]
)

PS - In digging up references I came across these other links to 
related topics:

These refer to 2003 discussions about lame delegations within RIPE:
http://ripe.net/ripe/maillists/archives/dns-wg/2003/msg00069.html
http://ripe.net/ripe/maillists/archives/dns-wg/2003/msg00088.html

This is an APNIC meeting that covered lame delegations and a general 
reverse map tool, as well as a report of an operational failure 
incident:
http://www.apnic.net/meetings/21/programme/sigs/dns.html

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.arin.net/pipermail/ppml/attachments/20070911/fb05dea4/attachment.html