<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [ppml] Comments on ARIN's reverse DNS mapping
policy</title></head><body>
<div>As an "arin mainland policy expert" with a lot of
experience in lameness and DNS...</div>
<div><br></div>
<div>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).</div>
<div><br></div>
<div>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).</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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:</div>
<div
>http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reverse-mapping-cons<span
></span>iderations/</div>
<div><br></div>
<div>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</div>
<div
>http://www3.ietf.org/proceedings/00dec/I-D/draft-ietf-dnsop-inaddr-r<span
></span>equired-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.</div>
<div><br></div>
<div>What would happen if a policy were to be introduced into ARIN on
this?</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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."</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>(See:
http://ripe.net/ripe/maillists/archives/dns-wg/2006/msg00173.html</div
>
<div> 51.3 Lars-Johan Liman -- NCC Secondary Service
Policy</div>
<div> Lars commented that
the RIPE NCC has announced it will limit<br>
involvement in provision of
slave servers for TLDs. Lars suggested<br>
this be closed for now and
marked as overtaken by events.<br>
The working group
agreed.<br>
[[Done, pending mailing
list approval]]</div>
<div>)</div>
<div><br></div>
<div>PS - In digging up references I came across these other links to
related topics:</div>
<div><br></div>
<div>These refer to 2003 discussions about lame delegations within
RIPE:</div>
<div>http://ripe.net/ripe/maillists/archives/dns-wg/2003/msg00069.html</div
>
<div>http://ripe.net/ripe/maillists/archives/dns-wg/2003/msg00088.html</div
>
<div><br></div>
<div>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:</div>
<div>http://www.apnic.net/meetings/21/programme/sigs/dns.html</div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span
></span>-=-=-=-<br>
Edward
Lewis <span
></span
> <span
></span
> <span
></span
> <span
></span> +1-571-434-5468<br>
NeuStar<br>
<br>
Think glocally. Act confused.</div>
</body>
</html>