Delegating in reverse lookup zones

Simon Dodd

unread,

Dec 15, 2009, 1:52:50 PM12/15/09

to bind-...@lists.isc.org

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.

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@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. 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.

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. 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?

-Simon

Kevin Darcy

unread,

Dec 15, 2009, 2:32:16 PM12/15/09

to bind-...@lists.isc.org

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@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

> ;; 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

> ;; 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

Chris Buxton

unread,

Dec 15, 2009, 2:32:20 PM12/15/09

to Simon Dodd, bind-...@lists.isc.org

It's not a valid delegation unless you control the parent zone.

ARIN is delegating the /24 reverse zone to you. You therefore have four options that give control of the PTR records to the midwestfirst.com servers.

Option 1: Ask ARIN to change the delegation. This is the most "correct" option, and the easiest.

Option 2: Configure your two servers as slaves of the zone. That is, on dauth1.joink.com, change your zone statement from type master to type slave, adding a masters statement:

zone "188.134.63.in-addr.arpa." {
type slave;
masters { 65.113.74.3; 65.113.74.4; };
file "188.134.63.in-addr.arpa";
};

Update your zone statement on dauth2 to match (changing the masters line only).

The disadvantage of this approach is that midwestfirst.com's name servers need to permit zone transfers to your name servers. Technically, this is a simple issue; however, when dealing with customers, it can often be hard to explain.

Option 3: Rename the PTR records into a zone that is controlled by the two intended servers. This way, you still have a master zone named "188.134.63.in-addr.arpa.", and the contents of that zone look something like this:

$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.
IN DNAME 188.134.63.rev.midwestfirst.com.

Then tell midwestfirst.com that their reverse zone's name is "188.134.63.rev.midwestfirst.com.", not "188.134.63.in-addr.arpa.". The contents of the zone are otherwise unchanged. (You can also achieve this effect with a destination zone named something like "mw.188.134.63.in-addr.arpa.", but in that case, you must use a $GENERATE statement instead of a DNAME record.)

The disadvantage of this approach is that you have to convince your customer that their zone name is changed from what is normal. This, again, is a simple technical issue that can be difficult to get through to a customer.

Option 4: Use your zone as you had written it, with one minor correction:

$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-254 $ IN NS ns1.midwestfirst.com.
$GENERATE 1-254 $ IN NS ns2.midwestfirst.com.

Note that I've added a "$" after the range in the $GENERATE statements. The disadvantage here is that the customer needs to create separate reverse zones for each IP address. If they try to create one large reverse zone containing all of these records, named "188.134.63.in-addr.arpa.", bad things will happen - it'll work some of the time, but not all of the time, even when the same caching server is involved. Inconsistency makes you look bad.

And of course trying to convince a customer to create 254 reverse zones, for individual IP's, is not a task I would relish.

Chris Buxton
Professional Services
Men & Mice

On Dec 15, 2009, at 10:52 AM, 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.

>
>
> 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@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. 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.
>

> 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. 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?
>

> -Simon
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Joseph S D Yao

unread,

Dec 15, 2009, 2:37:06 PM12/15/09

to Simon Dodd, bind-...@lists.isc.org

On Tue, Dec 15, 2009 at 01:52:50PM -0500, 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:

...

Mr. Dodd,

When you created "joink.com", you had to list the name servers in the
zone file for that zone, but you also had to register with the ".com"
domain and have them put the SAME IDENTICAL name server information in
the ".com" zone files.

If you create a new zone "east.joink.com", you would have to list the
name servers in the zone file for that zone, but you would also have to
put the SAME IDENTICAL name server information in the "joink.com" zone
files.

Reverse DNS is exactly the same as forward DNS, but with numbers. When
you create a zone 188.134.63.in-addr.arpa, you must contact the owners
of the 134.63.in-addr.arpa zone and ask them to put the SAME IDENTICAL
name server information in the "134.63.in-addr.arpa" zone files.

I stress SAME IDENTICAL name server information because the next part is
so often overlooked. If you ever change the name server information for
188.134.63.in-addr.arpa, or joink.com, or the hypothetical subdomain
east.joink.com, you MUST MUST MUST notify the owners of the parent zone
so that they can change the information in the parent zone files to once
again be the SAME IDENTICAL name server information as in your newly
revised zone files.

I hope that this helps!

--
/*********************************************************************\
**
** Joe Yao js...@tux.org - Joseph S. D. Yao
**
\*********************************************************************/

Barry Margolin

unread,

Dec 15, 2009, 2:42:37 PM12/15/09

to comp-protoc...@isc.org

In article <mailman.1304.1260905...@lists.isc.org>,
Chris Buxton <cbu...@menandmice.com> wrote:

> It's not a valid delegation unless you control the parent zone.
>
> ARIN is delegating the /24 reverse zone to you. You therefore have four
> options that give control of the PTR records to the midwestfirst.com servers.

A fifth option is to use RFC 2317-style classless delegation for all 256
entries in the reverse domain:

$GENERATE 0-255 $ IN CNAME $.0/24
0/24 IN NS ns1.midwestfirst.com.
0/24 IN NS ns2.midwestfirst.com.

Then have the customer change the name of their reverse zone to
0/24.188.134.63.in-addr.arpa.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Joseph S D Yao

unread,

Dec 15, 2009, 2:56:22 PM12/15/09

to Simon Dodd, bind-...@lists.isc.org

On Tue, Dec 15, 2009 at 01:52:50PM -0500, Simon Dodd wrote:

...

> 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:

...

I'm sorry! I read that too quickly the first time.

The simpler answer is, instead of delegating to YOU, have the owner of
134.63.in-addr.arpa delegate to MidwestFirst.

If you do not wish to do this, then DON'T have a zone file at all.
Instead of the zone being "type master;" have it be "type forward;".
And list "forwarders { 65.113.74.3; 65.113.74.4; };" [that being the IP
addresses of the two name servers with the actual information]. Then
you will be proxying their domains back to people who query you.

The problem is, of course, that if they list their own name servers as
the domain's name servers, then the information will be inconsistent
between parent and child. For consistency, they should list your name
servers. If they are sufficiently enlightened or security-conscious as
to have separate resolving name servers and authoritative name servers,
then their resolving name servers can have the same "forward" zone
declaration as your name servers.

Joseph S D Yao

unread,

Dec 15, 2009, 3:00:38 PM12/15/09

to Barry Margolin, comp-protoc...@isc.org

On Tue, Dec 15, 2009 at 02:42:37PM -0500, Barry Margolin wrote:
...

> A fifth option is to use RFC 2317-style classless delegation for all 256
> entries in the reverse domain:
>
> $GENERATE 0-255 $ IN CNAME $.0/24
> 0/24 IN NS ns1.midwestfirst.com.
> 0/24 IN NS ns2.midwestfirst.com.
>
> Then have the customer change the name of their reverse zone to
> 0/24.188.134.63.in-addr.arpa.

...

My first reaction was that RFC 2317 was not intended for /24's. But
darned if it wouldn't work, and would solve the parent/child consistency
problem I mentioned in my last response. The problem it raises, of
course, is that not everybody understands what they're seeing when they
look at RFC-2317 configurations. But if those who need to, do, this is
not a problem.

Chris Thompson

unread,

Dec 15, 2009, 3:18:30 PM12/15/09

to Simon Dodd, bind-...@lists.isc.org

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.

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...

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: ce...@cam.ac.uk

Simon Dodd

unread,

Dec 15, 2009, 3:33:43 PM12/15/09

to bind-...@lists.isc.org

Thanks for the replies, everyone; I think the consensus is that having ARIN redelegate is the correct solution, and that's fine by me. (As mentioned, my marching orders were to do this without redelegating, but if that's the correct way to do it, I can make that case.)

-Simon

--
Regards,

Simon Dodd
Systems engineer
Joink Internet // www.joink.com

e: simon...@joinkllc.com
t: 812.2345100 ext. 116
f: 812.2342144

"In critical and baffling situations, it is always best to return to first principle and simple action" - Sir Winston Churchill

Doug Barton

unread,

Dec 15, 2009, 3:49:04 PM12/15/09

to Simon Dodd, bind-...@lists.isc.org

Simon Dodd wrote:
> Thanks for the replies, everyone; I think the consensus is that having
> ARIN redelegate is the correct solution, and that's fine by me. (As
> mentioned, my marching orders were to do this without redelegating, but
> if that's the correct way to do it, I can make that case.)

It IS the correct and simplest way to do it, yes.

You CAN handle the whole zone like an RFC 2317 delegation if you want
to, but that's kind of silly.

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

Chris Buxton

unread,

Dec 15, 2009, 4:28:25 PM12/15/09

to Barry Margolin, comp-protoc...@isc.org

On Dec 15, 2009, at 11:42 AM, Barry Margolin wrote:

> In article <mailman.1304.1260905...@lists.isc.org>,
> Chris Buxton <cbu...@menandmice.com> wrote:
>

>> It's not a valid delegation unless you control the parent zone.
>>
>> ARIN is delegating the /24 reverse zone to you. You therefore have four
>> options that give control of the PTR records to the midwestfirst.com servers.
>

> A fifth option is to use RFC 2317-style classless delegation for all 256
> entries in the reverse domain:
>
> $GENERATE 0-255 $ IN CNAME $.0/24
> 0/24 IN NS ns1.midwestfirst.com.
> 0/24 IN NS ns2.midwestfirst.com.
>
> Then have the customer change the name of their reverse zone to
> 0/24.188.134.63.in-addr.arpa.

That approach was included with my option 3. I prefer the DNAME approach (instead of individual CNAME's) in this case, but that's just my opinion.

I would never recommend following that RFC's pattern of addr/mask (i.e. 0/24 in this case). Use something else, like "mw", as the artificially-added label.