Re: Can't transfer RFC2317 reverse zone
> With the "file" statement in the zone declaration for that zone.
>
> Zone "0/27.146.68.12.in-addr.arpa" {
> ...
> file "blah-blah";
> # or file "0.27.146.68.12.in-addr.arpa"; as I believe Mark Andrews
> suggested
> ...
> };
>
> (See also Jeff Lightner's example earlier in this thread.)
Whoops, sorry missed those. Thanks!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Can't transfer RFC2317 reverse zone
With the "file" statement in the zone declaration for that zone.
Zone "0/27.146.68.12.in-addr.arpa" {
...
file "blah-blah";
# orfile "0.27.146.68.12.in-addr.arpa"; as I believe Mark Andrews suggested
...
};
(See also Jeff Lightner's example earlier in this thread.)
> -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 1:22 PM
> To: bind-users@lists.isc.org
> Subject: Re: Can't transfer RFC2317 reverse zone
>
> >> Nope, no such file exists. I've got bak.* for all my other zones,
> >> but not that one.
> >
> > The filename you use to *save* the zone file as is
> arbitrary, try blah-blah
>
> How do I specify that?
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't transfer RFC2317 reverse zone
>> Nope, no such file exists. I've got bak.* for all my other zones, but >> not that one. > > The filename you use to *save* the zone file as is arbitrary, try > blah-blah How do I specify that? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't transfer RFC2317 reverse zone
On Fri, Jul 31, 2009 at 1:16 PM, Steve Brown wrote: >> I suspect you have 'file "bak.0/27.146.68.12.in-addr.arpa";' >> in your zone declaration. You can't alway use the zone name >> as a file name as a zone name may contain "/" which is a > Nope, no such file exists. I've got bak.* for all my other zones, but > not that one. The filename you use to *save* the zone file as is arbitrary, try blah-blah -- aRDy Music and Rick Dicaire present: http://www.ardynet.com http://www.ardynet.com:9000/ardymusic.ogg.m3u ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't transfer RFC2317 reverse zone
>> 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. > > No. Read the error message. It says "file not found" in > this case the file not found was the directory "bak.0". > >> 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. > > I suspect you have 'file "bak.0/27.146.68.12.in-addr.arpa";' > in your zone declaration. You can't alway use the zone name > as a file name as a zone name may contain "/" which is a > directory seperator in a file name. Now you could use > 'file "bak.0.27.146.68.12.in-addr.arpa";' or you could > create the directory "bak.0". I would choose the former. Nope, no such file exists. I've got bak.* for all my other zones, but not that one. Believe me, I would love to be able to switch that slash to a hyphen, but thats how it was delegated to me. How would I go about changing it? Since the zone I am delegated contains the slash, would I have to CNAME the zone on my end? Wouldn't I still have the same problem with the CNAME'd zone? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Can't transfer RFC2317 reverse zone
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
Re: Can't transfer RFC2317 reverse zone
In message <1f4ef0970907310934p2916336fy1f91485f8c17a...@mail.gmail.com>, Steve Brown writes: > 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. No. Read the error message. It says "file not found" in this case the file not found was the directory "bak.0". > 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. I suspect you have 'file "bak.0/27.146.68.12.in-addr.arpa";' in your zone declaration. You can't alway use the zone name as a file name as a zone name may contain "/" which is a directory seperator in a file name. Now you could use 'file "bak.0.27.146.68.12.in-addr.arpa";' or you could create the directory "bak.0". I would choose the former. Mark > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
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
