Delegating in reverse lookup zones
Kevin Darcy
kcd at chrysler.com
Tue Dec 15 19:32:16 UTC 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
> <http://63.134.188.13>:
>
> $TTL 6h
> @ 345600 IN SOA dauth1.joink.com <http://dauth1.joink.com>.
> noc.joink.com <http://noc.joink.com>. (
> 2009121524 ; Serial number
> 86400 ; Refresh
> 3600 ; Retry
> 777600 ; Expire
> 3600 ) ; Minimum TTL
> IN NS dauth1.joink.com <http://dauth1.joink.com>.
> IN NS dauth2.joink.com <http://dauth2.joink.com>.
> 13 IN PTR midwest1st.com <http://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 <http://ns1.midwestfirst.com> and
> ns2.midwestfirst.com <http://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 <http://dauth1.joink.com>.
> noc.joink.com <http://noc.joink.com>. (
> 2009121524 ; Serial number
> 86400 ; Refresh
> 3600 ; Retry
> 777600 ; Expire
> 3600 ) ; Minimum TTL
> IN NS ns1.midwestfirst.com
> <http://ns1.midwestfirst.com>.
> IN NS ns2.midwestfirst.com
> <http://ns2.midwestfirst.com>.
>
>
> 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:
>
> [root at 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
> <http://B.ROOT-SERVERS.NET>.
> . 3600000 IN NS M.ROOT-SERVERS.NET
> <http://M.ROOT-SERVERS.NET>.
> . 3600000 IN NS K.ROOT-SERVERS.NET
> <http://K.ROOT-SERVERS.NET>.
> . 3600000 IN NS E.ROOT-SERVERS.NET
> <http://E.ROOT-SERVERS.NET>.
> . 3600000 IN NS L.ROOT-SERVERS.NET
> <http://L.ROOT-SERVERS.NET>.
> . 3600000 IN NS A.ROOT-SERVERS.NET
> <http://A.ROOT-SERVERS.NET>.
> . 3600000 IN NS J.ROOT-SERVERS.NET
> <http://J.ROOT-SERVERS.NET>.
> . 3600000 IN NS G.ROOT-SERVERS.NET
> <http://G.ROOT-SERVERS.NET>.
> . 3600000 IN NS C.ROOT-SERVERS.NET
> <http://C.ROOT-SERVERS.NET>.
> . 3600000 IN NS F.ROOT-SERVERS.NET
> <http://F.ROOT-SERVERS.NET>.
> . 3600000 IN NS H.ROOT-SERVERS.NET
> <http://H.ROOT-SERVERS.NET>.
> . 3600000 IN NS I.ROOT-SERVERS.NET
> <http://I.ROOT-SERVERS.NET>.
> . 3600000 IN NS D.ROOT-SERVERS.NET
> <http://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
> <http://DILL.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS Y.ARIN.NET
> <http://Y.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS INDIGO.ARIN.NET
> <http://INDIGO.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS Z.ARIN.NET
> <http://Z.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS BASIL.ARIN.NET
> <http://BASIL.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS HENNA.ARIN.NET
> <http://HENNA.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS X.ARIN.NET
> <http://X.ARIN.NET>.
> ;; Received 180 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET
> <http://B.ROOT-SERVERS.NET>) in 76 ms
>
> 188.134.63.in-addr.arpa. 86400 IN NS DAUTH1.JOINK.COM
> <http://DAUTH1.JOINK.COM>.
> 188.134.63.in-addr.arpa. 86400 IN NS DAUTH2.JOINK.COM
> <http://DAUTH2.JOINK.COM>.
> ;; Received 95 bytes from 192.35.51.32#53(DILL.ARIN.NET
> <http://DILL.ARIN.NET>) in 75 ms
>
> 188.134.63.in-addr.arpa. 3600 IN SOA dauth1.joink.com
> <http://dauth1.joink.com>. noc.joink.com <http://noc.joink.com>.
> 200
> 9121525 86400 3600 777600 3600
> ;; Received 100 bytes from 63.134.128.150#53(DAUTH1.JOINK.COM
> <http://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. 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 <http://dauth1.joink.com>.
> noc.joink.com <http://noc.joink.com>. (
> 2009121526 ; Serial number
> 86400 ; Refresh
> 3600 ; Retry
> 777600 ; Expire
> 3600 ) ; Minimum TTL
> IN NS ns1.midwestfirst.com
> <http://ns1.midwestfirst.com>.
> IN NS ns2.midwestfirst.com
> <http://ns2.midwestfirst.com>.
> $GENERATE 1-255 IN NS ns1.midwestfirst.com
> <http://ns1.midwestfirst.com>.
> $GENERATE 1-255 IN NS ns2.midwestfirst.com
> <http://ns2.midwestfirst.com>.
>
That would only work if the midwestfirst.com nameservers had every PTR
contained in its own zone (with associated NS, SOA records etc.) This
does not appear to be the case:
$ dig -x 63.134.188.57 soa +noquest +noadd +nostats @ns1.midwestfirst.com
; <<>> DiG 9.4.3-P3 <<>> -x 63.134.188.57 soa +noquest +noadd +nostats
@ns1.midwestfirst.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1180
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; AUTHORITY SECTION:
188.134.63.in-addr.arpa. 86400 IN SOA ns1.midwestfirst.com.
joshfell.midwestfirst.com. 2009121401 86400 3600 777600
Note that it is referring upwards to the parent zone
(188.134.63.in-addr.arpa). This implies that it doesn't have
57.188.134.63.in-addr.arpa configured as a zone.
I picked 57 randomly as the last octet, but I'd assume the same was true
for all of the others.
> But no dice:
>
> ; <<>> DiG 9.2.1 <<>> -x 63.134.188.13 +trace
> ;; global options: printcmd
> . 3600000 IN NS I.ROOT-SERVERS.NET
> <http://I.ROOT-SERVERS.NET>.
> . 3600000 IN NS A.ROOT-SERVERS.NET
> <http://A.ROOT-SERVERS.NET>.
> . 3600000 IN NS E.ROOT-SERVERS.NET
> <http://E.ROOT-SERVERS.NET>.
> . 3600000 IN NS G.ROOT-SERVERS.NET
> <http://G.ROOT-SERVERS.NET>.
> . 3600000 IN NS M.ROOT-SERVERS.NET
> <http://M.ROOT-SERVERS.NET>.
> . 3600000 IN NS L.ROOT-SERVERS.NET
> <http://L.ROOT-SERVERS.NET>.
> . 3600000 IN NS D.ROOT-SERVERS.NET
> <http://D.ROOT-SERVERS.NET>.
> . 3600000 IN NS B.ROOT-SERVERS.NET
> <http://B.ROOT-SERVERS.NET>.
> . 3600000 IN NS F.ROOT-SERVERS.NET
> <http://F.ROOT-SERVERS.NET>.
> . 3600000 IN NS H.ROOT-SERVERS.NET
> <http://H.ROOT-SERVERS.NET>.
> . 3600000 IN NS J.ROOT-SERVERS.NET
> <http://J.ROOT-SERVERS.NET>.
> . 3600000 IN NS K.ROOT-SERVERS.NET
> <http://K.ROOT-SERVERS.NET>.
> . 3600000 IN NS C.ROOT-SERVERS.NET
> <http://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
> <http://HENNA.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS BASIL.ARIN.NET
> <http://BASIL.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS DILL.ARIN.NET
> <http://DILL.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS X.ARIN.NET
> <http://X.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS INDIGO.ARIN.NET
> <http://INDIGO.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS Z.ARIN.NET
> <http://Z.ARIN.NET>.
> 63.in-addr.arpa. 86400 IN NS Y.ARIN.NET
> <http://Y.ARIN.NET>.
> ;; Received 180 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET
> <http://I.ROOT-SERVERS.NET>) in 65 ms
>
> 188.134.63.in-addr.arpa. 86400 IN NS DAUTH2.JOINK.COM
> <http://DAUTH2.JOINK.COM>.
> 188.134.63.in-addr.arpa. 86400 IN NS DAUTH1.JOINK.COM
> <http://DAUTH1.JOINK.COM>.
> ;; Received 95 bytes from 192.26.92.32#53(HENNA.ARIN.NET
> <http://HENNA.ARIN.NET>) in 35 ms
>
> 188.134.63.in-addr.arpa. 3600 IN SOA dauth1.joink.com
> <http://dauth1.joink.com>. noc.joink.com <http://noc.joink.com>.
> 2009121523 86400 3600 777600 3600
> ;; Received 100 bytes from 63.134.128.151#53(DAUTH2.JOINK.COM
> <http://DAUTH2.JOINK.COM>) in 0 ms
>
> What really baffles me is that this worked for several hours
> yesterday, and apparently quit overnight. One option is just to change
> the delegation at ARIN, but we want to avoid that and in any event I'd
> like to know what the issue is. Any ideas on what I'm doing wrong?
>
You may have "poisoned" people's caches temporarily with the
midwestfirst.com NS records, but once those entries timed out, the
queries came back to you and you answered with NXDOMAIN, which then
itself was cached for some period of time. So it will work, stop
working, work, stop working, etc. You can't make "sideways delegation"
work reliably. That's just not how delegation is designed.
- Kevin
More information about the bind-users
mailing list