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

Kevin Darcy kcd at daimlerchrysler.com
Fri Mar 5 01:13:52 UTC 2004


Jim wrote:

>On Fri, 05 Mar 2004 08:23:41 +1100, Mark Andrews wrote:
>
>  
>
>>>On Thu, 04 Mar 2004 00:40:14 -0500, Barry Margolin wrote:
>>>      
>>>
>>>>In article <c25oe6$1pg$1 at sf1.isc.org>, Jim <me at privacy.net> wrote:
>>>>        
>>>>
>>>>>Didn't add this record as I'm connected 242 x 7 static IP
>>>>>          
>>>>>
>>>>And it never fails?
>>>>        
>>>>
>>>Yes, it does. I posted twice in response to Mark's second post on
>>>the subject. First to apologise for not following advise I'd asked
>>>for. Second to ask what I put in the file for the slave zone.
>>>Neither post has made it back to my news server yet. Might be
>>>lost in the bit bucket.
>>>
>>>Jim
>>>      
>>>
>>	You don't put anything in the file.  Named will transfer
>>	the zone contents from the servers listed in the masters
>>	clause.
>>
>>	Mark
>>    
>>
>
>I corrected /etc/named.conf and have this in it:
> 
>zone "182.116.67.in-addr.arpa" {
>        type slave;
>        file "s/named.67.116.182";
>        masters { 206.13.28.11; 206.13.29.11; };
>        notify no;
>};
> 
>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?

>Restarted named and here is the syslog:
>
>named[4364]: starting BIND 9.2.2-P3
>named[4364]: using 1 CPU
>named[4364]: loading configuration from '/etc/named.conf'
>named[4364]: no IPv6 interfaces found
>named[4364]: listening on IPv4 interface lo, 127.0.0.1#53
>named[4364]: listening on IPv4 interface eth0, 67.116.182.186#53
>named[4364]: command channel listening on 127.0.0.1#953
>named[4364]: zone 0.0.127.in-addr.arpa/IN: loaded serial 13
>named[4364]: zone 184.182.116.67.in-addr.arpa/IN: loaded serial 13
>named[4364]: zone jms-corp.net/IN: loaded serial 13
>named[4364]: running
>named[4364]: zone jms-corp.net/IN: sending notifies (serial 13)
>named[4364]: zone 184.182.116.67.in-addr.arpa/IN: sending notifies (serial 13)
>named[4364]: transfer of '182.116.67.in-addr.arpa/IN' from 206.13.28.11#53: end
>of transfer
>named[4364]: transfer of '182.116.67.in-addr.arpa/IN' from 206.13.29.11#53: end
>of transfer
>
>*****************
>ERRORS
>*****************
>
>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.

>========================
>
>Did some googling and found this URL:
>
>http://www.csh.rit.edu/~jon/text/papers/classless/
>
>The example shown for the entry in named.conf is:
>
>zone "64/27.7.126.206.in-addr.arpa" {
>     type slave;
>     file "64-27.7.126.206.rev";
>     masters { 206.126.7.65; };
>};
>
>So should my slave zone be in this style syntax to only transfer
>the records delegated to me? Like this?
>
>zone "184/29.182.116.67.in-addr.arpa" {
>     type slave;
>     file "184-29.182.116.67.rev";
>     masters { 206.13.28.11; 206.13.29.11; };
>     notify no;
>};
>  
>
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




More information about the bind-users mailing list