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