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
_______________________________________________
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
