Missing Reverse DNS Parent Zones

[Mark Andrews]

In message <4A43CABC.5090804 at chrysler.com>, Kevin Darcy writes:
> Raymond Popowich wrote:
> > Hello,
> >
> > One of the reverse DNS zones that I am responsible for is 
> > 95.69.in-addr.arpa. I have never created parent zones for any of them. 
> > I create individual zones for each /24 within them. For example, I 
> > don't have a 95.69.in-addr.arpa, but I do have 1.95.69.in-addr.arpa 
> > 2.95.69.in-addr.arpa, 3.95.69.in-addr.arpa etc. Is this a problem? 
> > I've never had an issue until a client recently mentioned that they 
> > believe it's a problem. After some googling I'm still left wondering 
> > if it really matters one way or the other. I can get them created, but 
> > does it matter? Thanks!
> >
> I checked a few subdomains at random; it seems you have a zone defined 
> for *every* possible legal numeric subdomain, from 0.95.69.in-addr.arpa 
> through 255.95.69.in-addr.arpa. Is that correct?
> 
> If that's true, then this is a case of "it works, but it's not really 
> the right thing to do". The fact that you have all of those subdomains 
> set up as zones, means that all reverse lookups of addresses in that 
> range will work as expected. But 96.69.in-addr.arpa *is* delegated to 
> you, you should have a zone for it. It's the proper thing to do.
> 
> Also, the way you're set up, degenerate queries under 96.69.in-addr.arpa 
> don't generate the responses they should:
> 
> $ dig aslkfj.95.69.in-addr.arpa
> 
> ; <<>> DiG 9.3.0 <<>> aslkfj.95.69.in-addr.arpa
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1461
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;aslkfj.95.69.in-addr.arpa.     IN      A
> 
> ;; Query time: 55 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Jun 25 14:52:15 2009
> ;; MSG SIZE  rcvd: 43
> 
> While there's no practical reason for anyone to query 
> slkfj.95.69.in-addr.arpa, it's also true that they shouldn't get a 
> SERVFAIL response. Permanent SERVFAIL is never justified -- the only 
> time anything under your control should return SERVFAIL is if you're 
> having some sort of _bona_fide_ outage, and should only be temporary.
> 
> 95.69.in-addr.arpa itself also returns SERVFAIL, and that's much more 
> likely to be a query target, for debugging or for someone trying to 
> verify whether the address range allocated to your organization is 
> actually in use.
> 
>                                                                          
>                                  - Kevin

	Also things like DNSSEC depend on having all the layers in
	place as the validator has to check each linkage in the
	delegation chain.  Zone test tools also depend on it being
	there.  If ARIN ever start checking delegations like they
	are supposed to do these checks will break and the delegation
	may be pulled.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org