reverse ip zone delegation

[Kevin Darcy]

J.P. wrote:

>I've contacted att and had them set our reverse ip zone to be delegated
>by our nameservers. I've done a trace with dig and it stops on att's
>dns server and I don't understand why. Shouldn't it proceed to query
>our nameservers and retrieve the ptr record? I could be totally off
>since I am new to this. There is also one other bit of information that
>bothers me with the CNAME att has setup. It contains a / as you will
>see in the output below. I didn't think this was a valid character, but
>again, I am new to this and I could be totally off.
>
>Just as a side note, if I query out nameservers directly (local or
>remote) using @ns... I get the expected information back.
>
>Thanks,
>J.P.
>
>---
>
>; <<>> DiG 9.2.4 <<>> +trace -x 12.96.12.250
>;; global options:  printcmd
>.                       517958  IN      NS      M.ROOT-SERVERS.NET.
>.                       517958  IN      NS      A.ROOT-SERVERS.NET.
>.                       517958  IN      NS      B.ROOT-SERVERS.NET.
>.                       517958  IN      NS      C.ROOT-SERVERS.NET.
>.                       517958  IN      NS      D.ROOT-SERVERS.NET.
>.                       517958  IN      NS      E.ROOT-SERVERS.NET.
>.                       517958  IN      NS      F.ROOT-SERVERS.NET.
>.                       517958  IN      NS      G.ROOT-SERVERS.NET.
>.                       517958  IN      NS      H.ROOT-SERVERS.NET.
>.                       517958  IN      NS      I.ROOT-SERVERS.NET.
>.                       517958  IN      NS      J.ROOT-SERVERS.NET.
>.                       517958  IN      NS      K.ROOT-SERVERS.NET.
>.                       517958  IN      NS      L.ROOT-SERVERS.NET.
>;; Received 276 bytes from 64.29.16.113#53(64.29.16.113) in 32 ms
>
>12.in-addr.arpa.        86400   IN      NS
>CBRU.BR.NS.ELS-GMS.ATT.NET.
>12.in-addr.arpa.        86400   IN      NS
>CMTU.MT.NS.ELS-GMS.ATT.NET.
>12.in-addr.arpa.        86400   IN      NS
>DBRU.BR.NS.ELS-GMS.ATT.NET.
>12.in-addr.arpa.        86400   IN      NS
>DMTU.MT.NS.ELS-GMS.ATT.NET.
>;; Received 143 bytes from 202.12.27.33#53(M.ROOT-SERVERS.NET) in 147
>ms
>
>250.12.96.12.in-addr.arpa. 172800 IN    CNAME
>250.248/29.12.96.12.in-addr.arpa.
>248/29.12.96.12.in-addr.arpa. 172800 IN NS      ns1.judelawfirm.com.
>248/29.12.96.12.in-addr.arpa. 172800 IN NS      ns2.judelawfirm.com.
>;; Received 140 bytes from
>199.191.128.105#53(CBRU.BR.NS.ELS-GMS.ATT.NET) in 18 ms
>

The +trace mechanism only follows referrals I believe, not CNAMEs, and 
stops when it gets an answer of any kind. So when it got the CNAME as an 
"answer" it stopped. If you wanted to trace further, then, you'd need to 
manually "restart" the query with the CNAME value 
250.248/29.12.96.12.in-addr.arpa.

Having queried your PTR "normally" (i.e. without +trace) and 
successfully, however, I am curious why the TTL on your PTR would be 3 
days (= 259200 seconds), given that the glue for your nameservers 
themselves (the ns1.judelawfirm.com and ns2.judelawfirm.com A records) 
is set to only 8 hours (= 28800 seconds). Seems a little out-of-whack...

                                                                         
      - Kevin