Problem with reverse lookup in CIDR delegated domain [file details]

[Kevin Darcy]

Jim wrote:

>On Thu, 04 Mar 2004 20:13:52 -0500, Kevin Darcy wrote:
>
>  
>
>>Jim wrote:
>>    
>>
>[snip]
>  
>
>>>zone "184.182.116.67.in-addr.arpa" {
>>>       type master;
>>>       file "m/named.67.116.182.184";
>>>       notify yes;
>>>};
>>>
>>>
>>>      
>>>
>>Are you going to put a PTR record in that zone sometime?
>>    
>>
>
>There are 2 PTR records in there since the beginning.
>
%dig -x 67.116.182.184 axfr @dragon.jms-corp.net.

; <<>> DiG 9.2.2rc1 <<>> 184.182.116.67.in-addr.arpa. axfr 
@dragon.jms-corp.net.
;; global options:  printcmd
184.182.116.67.in-addr.arpa. 86400 IN   SOA     dragon.jms-corp.net. 
root.jms-corp.net. 13 28800 600 3600000 86400
184.182.116.67.in-addr.arpa. 86400 IN   NS      ns1.pbi.net.
184.182.116.67.in-addr.arpa. 86400 IN   NS      ns2.pbi.net.
184.182.116.67.in-addr.arpa. 86400 IN   NS      dragon.jms-corp.net.
186.184.182.116.67.in-addr.arpa. 86400 IN PTR   dragon.jms-corp.net.
184.182.116.67.in-addr.arpa. 86400 IN   SOA     dragon.jms-corp.net. 
root.jms-corp.net. 13 28800 600 3600000 86400
;; Query time: 110 msec
;; SERVER: 67.116.182.186#53(dragon.jms-corp.net.)
;; WHEN: Fri Mar  5 17:35:29 2004
;; XFR size: 7 records

Well, you're half right: there is exactly 1 PTR record in the zone, but 
not where anyone would expect to find it (unless they were doing a 
reverse lookup of an address with 5 octets, i.e. 67.116.182.184.186). So 
I'm not sure what the point of this zone is...

>[snip]
>  
>
>>>named[4364]: transfer of '182.116.67.in-addr.arpa/IN' from 206.13.28.11#53: \
>>>            failed while receiving responses: REFUSED 
>>>named[4364]: transfer of '182.116.67.in-addr.arpa/IN' from 206.13.29.11#53: \
>>>            failed while receiving responses: REFUSED
>>>
>>> 
>>>
>>>      
>>>
>>Looks like they're not permitting zone transfers of that zone from your 
>>source address. Perhaps you should ask them to do so.
>>    
>>
>
>Wasn't sure if it was my configuring or their configuration. Now that
>I know, I'll ask them.
> 
>  
>
>>>========================
>>>      
>>>
>[snip]
>  
>
>>I think you're imputing some magic to the slash notation that simply 
>>isn't there. The ns1.pbi.net and ns2.pbi.net servers don't know about 
>>any "184/29.182.116.67.in-addr.arpa" zone, so there's no point in trying 
>>to be a slave of that zone from them.
>>
>>                                                                         
>>                                                - Kevin
>>    
>>
>
>Not that it's magic. Simply it's the first time I've done this sort
>of DNS config and every document I've been able to find via google
>uses this slash notation, even RFC2317 recommends it. So I ask to
>learn the answers and the reasons.
>
Well, you're not actually following RFC 2317 at all. RFC 2317 describes 
"classless delegation" via the use of CNAMEs. You're instead delegating 
the reverse for a single address (i.e. 184.182. 116.67.in-addr.arpa) 
from your ISP's nameserver to yours. At least, that's what it appears 
you are trying to do...

If you want to follow RFC 2317, you and your ISP need to come to some 
agreement over the name of a container zone (which doesn't even need to 
be under in-addr.arpa, by the way -- even RFC 2317 says as much -- it 
just needs to be a zone which you control, which could even a "forward" 
zone like jms-corp.net or some descendant zone thereof), and then your 
ISP needs to populate their in-addr.arpa zone file with CNAMEs pointing 
to names in that container zone.

I think it would be confusing, at best, for you to continue to use the 
184.182. 116.67.in-addr.arpa zone as your container zone for any reverse 
record other than the one for the 67.116.182.184 address. To do so is to 
generate 5-octet-looking monstrosities like the one earlier mentioned.

                                                                         
                                       - Kevin