On Dec 15 2009, Simon Dodd wrote:
I'm having a problem configuring a delegation. We have various /24s for
which we provide PTR records. If I create a zone file for
188.134.63.in-addr.arpa and add PTR records, they resolve just fine. In
other words, if this is my zone, I can resolve 63.134.188.13:
$TTL 6h
@ 345600 IN SOA dauth1.joink.com. noc.joink.com. (
2009121524 ; Serial number
86400 ; Refresh
3600 ; Retry
777600 ; Expire
3600 ) ; Minimum TTL
IN NS dauth1.joink.com.
IN NS dauth2.joink.com.
13 IN PTR midwest1st.com.
But that isn't what we want to do for this particular zone. We want to
delegate all queries concerning 188.134.63.in-addr.arpa to
ns1.midwestfirst.com and ns2.midwestfirst.com. Albitz & Liu 4th says that's
fair game, so here's how I configured the zone:
$TTL 6h
@ 345600 IN SOA dauth1.joink.com. noc.joink.com. (
2009121524 ; Serial number
86400 ; Refresh
3600 ; Retry
777600 ; Expire
3600 ) ; Minimum TTL
IN NS ns1.midwestfirst.com.
IN NS ns2.midwestfirst.com.
You can't "delegate" the *whole* of a zone like that. You are claiming
to have an authoritative version of the zone, which contains no PTR
records ... and incidentally, that the official servers are those in
at ns*.midwestern.com. So you are in fact claiming to be something
like a "stealth slave" for the zone, but you are still authoritative,
and the rest of the world is going to believe your responses saying
that the PTR records don't exist.
Mutatis mutandis, that's the configuration that Albitz & Liu show for
delegating forward lookup zones (p. 232). It isn't quite how they show
reverse lookup zones (more on this in a moment), and unfortunately, it
doesn't work:
[r...@linux1 joink-domains]# dig -x 63.134.188.13 +trace
; <<>> DiG 9.2.1 <<>> -x 63.134.188.13 +trace
;; global options: printcmd
. 3600000 IN NS B.ROOT-SERVERS.NET.
. 3600000 IN NS M.ROOT-SERVERS.NET.
. 3600000 IN NS K.ROOT-SERVERS.NET.
. 3600000 IN NS E.ROOT-SERVERS.NET.
. 3600000 IN NS L.ROOT-SERVERS.NET.
. 3600000 IN NS A.ROOT-SERVERS.NET.
. 3600000 IN NS J.ROOT-SERVERS.NET.
. 3600000 IN NS G.ROOT-SERVERS.NET.
. 3600000 IN NS C.ROOT-SERVERS.NET.
. 3600000 IN NS F.ROOT-SERVERS.NET.
. 3600000 IN NS H.ROOT-SERVERS.NET.
. 3600000 IN NS I.ROOT-SERVERS.NET.
. 3600000 IN NS D.ROOT-SERVERS.NET.
;; Received 272 bytes from 12.109.94.5#53(12.109.94.5) in 1 ms
63.in-addr.arpa. 86400 IN NS DILL.ARIN.NET.
63.in-addr.arpa. 86400 IN NS Y.ARIN.NET.
63.in-addr.arpa. 86400 IN NS INDIGO.ARIN.NET.
63.in-addr.arpa. 86400 IN NS Z.ARIN.NET.
63.in-addr.arpa. 86400 IN NS BASIL.ARIN.NET.
63.in-addr.arpa. 86400 IN NS HENNA.ARIN.NET.
63.in-addr.arpa. 86400 IN NS X.ARIN.NET.
;; Received 180 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 76 ms
188.134.63.in-addr.arpa. 86400 IN NS DAUTH1.JOINK.COM.
188.134.63.in-addr.arpa. 86400 IN NS DAUTH2.JOINK.COM.
;; Received 95 bytes from 192.35.51.32#53(DILL.ARIN.NET) in 75 ms
188.134.63.in-addr.arpa. 3600 IN SOA dauth1.joink.com.
noc.joink.com.
200
9121525 86400 3600 777600 3600
;; Received 100 bytes from 63.134.128.150#53(DAUTH1.JOINK.COM) in 0 ms
As I said, this isn't quite how Albitz & Liu show delegation for reverse
lookup zones. Nevertheless, the only difference that I see between what I
have configured and what they show is that I'm working with
188.134.63.in-addr.arpa, while they're working one level higher, at the
equivalent of 134.63.in-addr.arpa.
Big difference. Big BIG difference. NS records only indicate a delegation
when they are *not* at the zone apex.
Accordingly, they have to specify name
servers for 188 within the zone, whereas I can (I had thought) inhereit that
data from the zone. Maybe not, though, since it isn't working!
I even tried adding the "generate" command that they propose:
$TTL 6h
@ 345600 IN SOA dauth1.joink.com. noc.joink.com. (
2009121526 ; Serial number
86400 ; Refresh
3600 ; Retry
777600 ; Expire
3600 ) ; Minimum TTL
IN NS ns1.midwestfirst.com.
IN NS ns2.midwestfirst.com.
$GENERATE 1-255 IN NS ns1.midwestfirst.com.
$GENERATE 1-255 IN NS ns2.midwestfirst.com.
That looks like a syntax error. If you had
$GENERATE 0-255 $ IN NS ns1.widwestern.com.
$GENERATE 0-255 $ IN NS ns2.midwestern.com.
that would be a correct delegation of 256 different sub-zones, each
of which would presumably contain just one PTR record, and you would
have to configure the ns*.midwestern.com servers accordingly. Which
would work, but I'm fairly sure you would come to regret doing it
like that...
But no dice:
; <<>> DiG 9.2.1 <<>> -x 63.134.188.13 +trace
;; global options: printcmd
. 3600000 IN NS I.ROOT-SERVERS.NET.
. 3600000 IN NS A.ROOT-SERVERS.NET.
. 3600000 IN NS E.ROOT-SERVERS.NET.
. 3600000 IN NS G.ROOT-SERVERS.NET.
. 3600000 IN NS M.ROOT-SERVERS.NET.
. 3600000 IN NS L.ROOT-SERVERS.NET.
. 3600000 IN NS D.ROOT-SERVERS.NET.
. 3600000 IN NS B.ROOT-SERVERS.NET.
. 3600000 IN NS F.ROOT-SERVERS.NET.
. 3600000 IN NS H.ROOT-SERVERS.NET.
. 3600000 IN NS J.ROOT-SERVERS.NET.
. 3600000 IN NS K.ROOT-SERVERS.NET.
. 3600000 IN NS C.ROOT-SERVERS.NET.
;; Received 228 bytes from 12.109.94.5#53(12.109.94.5) in 1 ms
63.in-addr.arpa. 86400 IN NS HENNA.ARIN.NET.
63.in-addr.arpa. 86400 IN NS BASIL.ARIN.NET.
63.in-addr.arpa. 86400 IN NS DILL.ARIN.NET.
63.in-addr.arpa. 86400 IN NS X.ARIN.NET.
63.in-addr.arpa. 86400 IN NS INDIGO.ARIN.NET.
63.in-addr.arpa. 86400 IN NS Z.ARIN.NET.
63.in-addr.arpa. 86400 IN NS Y.ARIN.NET.
;; Received 180 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in 65 ms
188.134.63.in-addr.arpa. 86400 IN NS DAUTH2.JOINK.COM.
188.134.63.in-addr.arpa. 86400 IN NS DAUTH1.JOINK.COM.
;; Received 95 bytes from 192.26.92.32#53(HENNA.ARIN.NET) in 35 ms
188.134.63.in-addr.arpa. 3600 IN SOA dauth1.joink.com.
noc.joink.com. 2009121523 86400 3600 777600 3600
;; Received 100 bytes from 63.134.128.151#53(DAUTH2.JOINK.COM) in 0 ms
What really baffles me is that this worked for several hours yesterday, and
apparently quit overnight.
Probably because when the delegation NS records for 188.134.63.in-addr.arpa
disagree with the in-zone ones, different caching servers may be remembering
and using either set.
One option is just to change the delegation at
ARIN, but we want to avoid that
Why? You will have to bite the bullet eventually.
There are more elaborate things you could do to transfer the PTR records
to the ns*.midwestern.com servers, e.g. use CNAMEs or DNAMEs a la RFC2317,
but as long as the delegation points to dauth*.joink.com those servers
are involved in getting to the data. And ...
$ dig +norec +short txt chaos version.bind @dauth1.joink.com
"8.3.3-REL-NOESW"
$ dig +norec +short txt chaos version.bind @dauth2.joink.com
"8.3.3-REL-NOESW"
... if that's right you truely, truely want to turn them off REAL SOON NOW
(or upgrade). BIND 8 is passed on, has ceased to be, is expired and gone
to meet its maker, etc. etc. It is an ex-BIND.
and in any event I'd like to know what the
issue is. Any ideas on what I'm doing wrong?
Did the above help?
--
Chris Thompson
Email: c...@cam.ac.uk
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
