[ppml] Policy Proposal 2005-3: Lame Delegations

[Paul Vixie]

> >> ... If someone's got their in-addr.arpa stuff broken, it's not
> >> really hurting anyone but themselves.

> > i don't agree.  bad or missing in-addr.arpa or ip6.arpa data hurts
> > us all.

> While I do not necessarily disagree, can you expand on why you believe
> lack of reverse information hurts us?

first and foremost, negative caching in dns is weak on its best day and
it has very few good days.  there is no way to express in a dns response
that a nonterminal ancestor of a qname does not exist, so if someone asks:
	1.187.152.204.IN-ADDR.ARPA
and the thing that doesn't exist is:
	187.152.204.IN-ADDR.ARPA
then there is no way to signal this ancestral nonexistence, and the client
can only cache the nonexistence of the qname itself.  but of course a lot
of dns implementors don't cache anything, or don't cache negatives, or don't
cache lameness.  the result is, a lot of queries hitting the dns root servers
and the IN-ADDR.ARPA servers and the .ARPA servers whenever someone's inaddr
is lame or nonexistent.

(since folks all over the internet *will* query for these names, the lack
of support for them by any given network owner is socially irresponsible.)

more to the point, the data is useful when present, and normally when it's
absent it's by error or omission rather than by policy.  someone whose
policy is to not support inaddr lookups about their network can just put
an empty zone in place.  but everyone ought to have to think about their
intentions, and put some kind of zone in place, and keep it from being lame,
since the vast majority of people who need to do that, have no policy of
secrecy.  thus the net impact of arin's policy will be that more useful
data is available about the internet's infrastructure.

for both reasons, this is an appropriate use of arin's resources.