On Tue, May 07, 2013 at 09:52:16AM -0700, Michael Varre wrote: > Thanks Justin, I've been testing with dig and that's how I got the failed > results posted previously. My digs lead me to believe their zones are named > the same as mine, with -'s instead of /'s. > > dig -x 1.1.1.90 +trace > ----snipped---- > ;; Received 180 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 89 ms > > 1.1.1.in-addr.arpa. 86400 IN NS NS1.myisp.COM. > 1.1.1.in-addr.arpa. 86400 IN NS NS2.myisp.COM. > ;; Received 89 bytes from 199.180.180.63#53(r.arin.net) in 55 ms > > 90.1.1.1.in-addr.arpa. 3600 IN NS dns1.myns.com. > ;; Received 75 bytes from 13.13.13.13#53(NS1.myisp.COM) in 84 ms > > ;; Received 44 bytes from 1.1.1.90#53(dns1.myns.com) in 80 ms > <end> > > I've requested they confirm their setup, but I don't know how forthcoming > they'll be.
I don't see any "-" (or "/") in your dig output, which indicates that the ISP delegation isn't using RFC2317-style delegation with CNAMES. It appears they may have manually added NS records for each of 64 IPs. That's messy and inelegant for them, and doesn't work right either. The ISP is responding with NS for 90.1.1.1, which means that the next query must ask a quesion *below* that: something.90.1.1.1. That's why a CNAME is needed, with an additional, "artificial" subzone, allowing proper delegation. Otherwise, it's a so-called "horizontal" referal. In the past, when I've requested RFC2317/sub-24 delegation of rev dns, I've included/suggested BIND syntax (but it's still sometimes taken multiple attempts to be correctly implemented). $ORIGIN 196.185.205.in-addr.arpa. 32-47 NS ns.norchemlab.com. 32-47 NS ns1.norchemlab.com. $GENERATE 32-47 $ CNAME $.32-47 Justin _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
