Delegating in reverse lookup zones
Chris Buxton
cbuxton at menandmice.com
Tue Dec 15 19:32:20 UTC 2009
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 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.
> . 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-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
More information about the bind-users
mailing list