What I did for our reverse zones due to the AT&T way of delegating was
create two entries like this:
# Special notation required for internet delegation (e.g. dig -x ...)
#
zone "49-62.65.210.63.IN-ADDR.ARPA" {
type master;
file "arpa.63.210.65";
allow-query { any; };
};
# Standard notation required for direct lookups (e.g. dig @dswands1 -x
...)
#
zone "65.210.63.IN-ADDR.ARPA" {
type master;
file "arpa.63.210.65";
allow-query { any; };
};
Notice the file name is the same and the entry on the slave would have
slave related entries instead of "type master;" but is pretty much the
same.
Since the file transfer with the second zone which is "standard" name
for arpa zone it doesn't matter that the first one shows error as it
will look at the same file transferred by the other entry.
-----Original Message-----
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Steve Brown
Sent: Friday, July 31, 2009 12:34 PM
To: bind-users@lists.isc.org
Subject: Can't transfer RFC2317 reverse zone
I'm trying to setup a new server as a slave to our master DNS server.
I am able to transfer several zones just fine, but when will not
transfer. AT&T uses RFC2317-style zones for reverse delegation, so
I've been delegated 0/27.146.68.12.in-addr.arpa. However, when I
fired up BIND and tried to transfer the zone from the master, I get
this in the logs:
30-Jul-2009 13:18:37.094 zone
0/27.146.68.12.in-addr.arpa/IN/com.apple.ServerAdmin.DNS.public:
Transfer started.
30-Jul-2009 13:18:37.096 transfer of
'0/27.146.68.12.in-addr.arpa/IN/com.apple.ServerAdmin.DNS.public' from
12.68.146.1#53: connected using 206.123.100.18#52732
30-Jul-2009 13:18:37.100 dumping master file: bak.0/tmp-Yj75Mq2ImU:
open: file not found
30-Jul-2009 13:18:37.100 transfer of
'0/27.146.68.12.in-addr.arpa/IN/com.apple.ServerAdmin.DNS.public' from
12.68.146.1#53: failed while receiving responses: file not found
30-Jul-2009 13:18:37.100 transfer of
'0/27.146.68.12.in-addr.arpa/IN/com.apple.ServerAdmin.DNS.public' from
12.68.146.1#53: end of transfer
>From what I have seen on this list, BIND typically spits out this
error when it doesn't have write permission on its working directory.
However, I know this is not the case because it transferred a dozen
other zones just fine. Its only barfing on this one reverse zone. I'm
guessing that it has something to do with how BIND names the temp
files it creates for writing slave zones, combined with the fact that
there is a "/" (forward slash) in the name it would like to write?
I've been searching for a way to specify the name of the temp file
BIND uses, but I've had no luck finding that.
Any thoughts or ideas on how I can get this slave zone to transfer
correctly?
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
----------------------------------
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
