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

Keith Medcalf kmedcalf at dessus.com
Tue Sep 11 21:09:39 EDT 2007


> Identical issues to what I am experiencing. If people look 
> deeply enough, I am confident there are many Org's who 
> operate AS's with no in-addr.arpa SOA on there DNS servers.

You remember that once upon a time in a land far far away the lack of functioning in-addr.arpa. DNS would act to actually prohibit those addresses for being useful for anything other than crawling the dirtpath though CIX and accessing advertizing gophers and the "Commercial internet".

As I recall when I signed the AUP for NSFNet access and transit, working DNS closure was a requirement for access to almost any resource subject those and similar AUP's in common use at that time.

Then along came the clueless johhny-come-lately ISPs (mostly telco's and cableco's) and people stopped checking in-addr.arpa DNS because the sheer volume of the clueless created massive operational issues.

For example, even merit's ftp servers (and uu's also) *required* not only non-lame in-addr.arpa delegations, but also closure of the forward and reverse mapping.

After a while (measured in years) many of the telco/cableco's managed to *buy* a clue.  Many even have proper closure of the forward and reverse zones.

Despite this fact many more recent arrivals (some of them really really big software companies, like Microsoft) still haven't managed to either find or buy a clue.  Perhaps because the clue-store is sold out or all clues are on back-order :)

There is a reason why in-addr.arpa and forward DNS closure is a good thing:  often the operators of each DNS zone are different (or at least those in control of the delegations are different) and therefore proper closure demonstrates that the end-ip is authorized to operate by both the "network" (in-addr.arpa) operator *and* the forward "domain" operator.

If attempting resolution though both domains does not result in closure it is reasonable to assume that the ip/netblock in question is not "authentic" -- and thus any service requiring bare minimum of authenticity verification shoulod be denied to those unable to demonstrate such closure.







More information about the ARIN-PPML mailing list