[ppml] Comments on ARIN's reverse DNS mapping policy
Ed.Lewis at neustar.biz
Tue Sep 11 08:47:34 EDT 2007
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 .) 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
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
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
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.
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
These refer to 2003 discussions about lame delegations within RIPE:
This is an APNIC meeting that covered lame delegations and a general
reverse map tool, as well as a report of an operational failure
Edward Lewis +1-571-434-5468
Think glocally. Act confused.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML