[no subject]
Dear all, I have the following situation in my zone migration for one server (A) to another server (B) The zone is called toto.be and contains the following record: www.toto.be 86400 IN CNAME www.titi.be == the zone titi.be is in the same server (A) but is not transferred to the server (B). If I do a dig @SERVER(A) www.toto.be == I receive the IP corresponding to www.titi.be If I do a dig @SERVER(B) www.toto.be == I do not receive the IP corresponding to www.titi.be - Is this situation due to the fact that dig always and only contacts the server mentionned in the command ? - Does the titi.be and toto.be be on the same server to correctly use CNAMES? Thanks for your feedback, hugo, ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Inline Signing does not update SOA?
Hi, I am testing with BIND 9.9.0 and inline signing. I have run upon something that I cannot figure out. When I update the SOA record of the master zone file, if I reload the zone with rndc reload, the SOA record is updated. If I perform a stop/start of the named executable, the SOA change is not updated. I can even see in the log file where the unsigned zone's serial number is incremented, yet the signed version does not change. Below you can see where I started named, stopped named, made a change in the SOA and incremented the serial number, then started named. After that, I incremented the serial number once more then performed an rndc reload. (Started named) 07-May-2012 08:00:00.664 general: managed-keys-zone: loaded serial 0 07-May-2012 08:00:00.664 general: zone 0.0.127.in-addr.arpa/IN: loaded serial 1 07-May-2012 08:00:00.683 general: zone nasa.gov/IN (unsigned): loaded serial 200804540 07-May-2012 08:00:00.704 general: zone nasa.gov/IN (signed): loaded serial 200804885 (DNSSEC signed) 07-May-2012 08:00:00.705 general: zone localhost/IN: loaded serial 1 07-May-2012 08:00:00.705 general: all zones loaded 07-May-2012 08:00:00.705 general: running 07-May-2012 08:00:00.719 general: zone nasa.gov/IN (signed): receive_secure_serial: unchanged 07-May-2012 08:00:00.719 general: zone nasa.gov/IN (signed): reconfiguring zone keys 07-May-2012 08:00:00.720 general: zone nasa.gov/IN (signed): next key event: 07-May-2012 09:00:00.719 (Stopped named and edited zone file 'nasa.gov') 07-May-2012 08:01:14.057 general: shutting down 07-May-2012 08:01:14.058 general: stopping command channel on 0.0.0.0#953 07-May-2012 08:01:14.064 general: exiting (Started named) 07-May-2012 08:01:49.998 general: managed-keys-zone: loaded serial 0 07-May-2012 08:01:49.999 general: zone 0.0.127.in-addr.arpa/IN: loaded serial 1 07-May-2012 08:01:50.017 general: zone nasa.gov/IN (unsigned): loaded serial 200804541 07-May-2012 08:01:50.039 general: zone nasa.gov/IN (signed): loaded serial 200804885 (DNSSEC signed) 07-May-2012 08:01:50.039 general: zone localhost/IN: loaded serial 1 07-May-2012 08:01:50.040 general: all zones loaded 07-May-2012 08:01:50.040 general: running 07-May-2012 08:01:50.053 general: zone nasa.gov/IN (signed): receive_secure_serial: unchanged 07-May-2012 08:01:50.059 general: zone nasa.gov/IN (signed): reconfiguring zone keys 07-May-2012 08:01:50.060 general: zone nasa.gov/IN (signed): next key event: 07-May-2012 09:01:50.059 (Performed rndc reload) 07-May-2012 08:02:59.553 general: received control channel command 'reload nasa.gov' 07-May-2012 08:02:59.611 general: zone nasa.gov/IN (unsigned): loaded serial 200804542 07-May-2012 08:02:59.612 general: zone nasa.gov/IN (signed): serial 200804886 (unsigned 200804542) Am I doing something wrong? Thank you, Ralph F. Bischof, Jr. NASA Agency IPAM/DNS/DHCP SAIC/NICS 256-544-3982 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re:
On 07/05/2012 15:29, hugo hugoo wrote: Hi Hugo, I have the following situation in my zone migration for one server (A) to another server (B) The zone is called toto.be and contains the following record: www.toto.be 86400 IN CNAME www.titi.be == the zone titi.be is in the same server (A) but is not transferred to the server (B). If I do a dig @SERVER(A) www.toto.be == I receive the IP corresponding to www.titi.be This works, because server A knows about both zones, so it can return the IP address out of zone titi.be. If I do a dig @SERVER(B) www.toto.be == I do not receive the IP corresponding to www.titi.be Server B does not know about titi.be, so it cannot provide the IP address. - Is this situation due to the fact that dig always and only contacts the server mentionned in the command ? When you run dig like this, it sends one query to a server, and shows you the response. The dig command does not do recursive resolution. - Does the titi.be and toto.be be on the same server to correctly use CNAMES? No. A recursive DNS resolver will be able to follow the CNAME chain from server B back to A to look up records in titi.be. Regards, Anand Buddhdev RIPE NCC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re:
If that's an exact copy of your record, I'm going to also assume that the ORIGIN at the time of the record is toto.be. As such, the resulting record becomes: www.toto.be.toto.be. 86400 IN CNAME www.titi.be.toto.be. Note that trailing '.'s are required to prevent the automatic addition of the ORIGIN. e.g.: www.toto.be. 86400 IN CNAME www.titi.be. Dig will only send it's query to the server specified on the command line (when specified). Otherwise, it uses the server listed in the resolver configuration. If this doesn't answer your question, provide better information. i.e. example dig and full response. On 05/07/2012 09:29 AM, hugo hugoo wrote: Dear all, I have the following situation in my zone migration for one server (A) to another server (B) The zone is called toto.be and contains the following record: www.toto.be 86400 IN CNAME www.titi.be == the zone titi.be is in the same server (A) but is not transferred to the server (B). If I do a dig @SERVER(A) www.toto.be == I receive the IP corresponding to www.titi.be If I do a dig @SERVER(B) www.toto.be == I do not receive the IP corresponding to www.titi.be - Is this situation due to the fact that dig always and only contacts the server mentionned in the command ? - Does the titi.be and toto.be be on the same server to correctly use CNAMES? Thanks for your feedback, hugo, ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re:
On 5/7/12 8:29 AM, hugo hugoo hugo...@hotmail.com wrote: Dear all, I have the following situation in my zone migration for one server (A) to another server (B) The zone is called toto.be and contains the following record: www.toto.be 86400 IN CNAME www.titi.be == the zone titi.be is in the same server (A) but is not transferred to the server (B). I am assuming here that server B is not set up for recursion. If I do a dig @SERVER(A) www.toto.be == I receive the IP corresponding to www.titi.be The extra information is provided when it is known. If I do a dig @SERVER(B) www.toto.be == I do not receive the IP corresponding to www.titi.be Since there is no recursion allowed, all SERVER(B) can provide is the information for which it is authoritative. - Is this situation due to the fact that dig always and only contacts the server mentionned in the command ? Yes. Dig id not a complete resolver, it does not chase down incomplete references or glue. - Does the titi.be and toto.be be on the same server to correctly use CNAMES? No. A recursive resolver will determine the information using more than one query. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Inline Signing does not update SOA?
When I update the SOA record of the master zone file, if I reload the zone with rndc reload, the SOA record is updated. If I perform a stop/start of the named executable, the SOA change is not updated. Ralph: There was a lot of discussion about this issue on the bind forum around the first of the year. My recollection is that with inline-signing enabled, stopping named, editing the zone file, and restarting named isn't a supported method of updating zone data. I am aware of two supported options: 1) as you did above, edit the zone file and run 'rndc reload', 2) use 'nsupdate'. Others will probably recall this in more detail and more accurately. Regards, Jeff. Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Why does a non-delegated sub-domain work?
So ... if we have exacttarget.com delegated to ns1 and ns2.exacttarget.com nameservers and ... we manage the s6.exacttarget.com zone file from ns1 and ns2.exacttarget.com but we don't delegate s6 in the exacttarget.com zone file ... forgot to enter it in the zone file ... how is it that s6.exacttarget.com and its contents resolve properly from everywhere? Seems BIND is helping us out behind the scenes somehow. Right? Confused. Thanks, Marty ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline Signing does not update SOA?
On Mon, May 7, 2012 at 7:31 AM, Spain, Dr. Jeffry A. spa...@countryday.net wrote: When I update the SOA record of the master zone file, if I reload the zone with rndc reload, the SOA record is updated. If I perform a stop/start of the named executable, the SOA change is not updated. Ralph: There was a lot of discussion about this issue on the bind forum around the first of the year. My recollection is that with inline-signing enabled, stopping named, editing the zone file, and restarting named isn't a supported method of updating zone data. I am aware of two supported options: 1) as you did above, edit the zone file and run 'rndc reload', 2) use 'nsupdate'. Others will probably recall this in more detail and more accurately. Regards, Jeff. I believe that the official answer is that you need to use rndc to freeze the zone, edit the zone file, and thaw the zone. You really can't edit a zone that is subject to any operation that makes use of journal files (dynamic updates, in-line signing) while the zone may be changing during the edit. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why does a non-delegated sub-domain work?
On 5/7/12 11:32 AM, M. Meadows sun-g...@live.com wrote: So ... if we have exacttarget.com delegated to ns1 and ns2.exacttarget.com nameservers and ... we manage the s6.exacttarget.com zone file from ns1 and ns2.exacttarget.com but we don't delegate s6 in the exacttarget.com zone file ... forgot to enter it in the zone file ... how is it that s6.exacttarget.com and its contents resolve properly from everywhere? Because bind can't distinguish between a query for s6.exacttarget.com from the exacttarget.com zone and a query for s6.exacttarget.com in the s6.exacttarget.com zone, so it employs longest match and returns the appropriate information. Seems BIND is helping us out behind the scenes somehow. Right? Bind is hiding your configuration error, yes. It won't work with DNSSEC and might fail if you have a secondary for s6.exacttarget.com that is not also authoritative for exacttarget.com -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why does a non-delegated sub-domain work?
You are getting lucky that they are on the same server and when asked about anything in the subdomain the server notices it loads it and answers for it. It is however a landmine waiting for someone in thee future. If you move the subdomain to another server without fixing the delegation the subdomain will disappear. -Ben Croswell On May 7, 2012 1:08 PM, M. Meadows sun-g...@live.com wrote: So ... if we have exacttarget.com delegated to ns1 and ns2.exacttarget.com nameservers and ... we manage the s6.exacttarget.com zone file from ns1 and ns2.exacttarget.com but we don't delegate s6 in the exacttarget.com zone file ... forgot to enter it in the zone file ... how is it that s6.exacttarget.com and its contents resolve properly from everywhere? Seems BIND is helping us out behind the scenes somehow. Right? Confused. Thanks, Marty ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why does a non-delegated sub-domain work?
s6 is a subdomain of the parent domain. Unless otherwise specified, subdomains are mastered (NS'd) by the parent (or extended parent domain) containing NS records. As such, because you didn't put any NS records in the zone file for s6, it follows the NS records of the parent which happen to be the same name server as s6. On the other hand, if you had attempted to master s6 on a different name server, it would not have worked. On 05/07/2012 12:32 PM, M. Meadows wrote: So ... if we have exacttarget.com delegated to ns1 and ns2.exacttarget.com nameservers and ... we manage the s6.exacttarget.com zone file from ns1 and ns2.exacttarget.com but we don't delegate s6 in the exacttarget.com zone file ... forgot to enter it in the zone file ... how is it that s6.exacttarget.com and its contents resolve properly from everywhere? Seems BIND is helping us out behind the scenes somehow. Right? Confused. Thanks, Marty ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline Signing does not update SOA?
Ralph: There was a lot of discussion about this issue on the bind forum around the first of the year. My recollection is that with inline-signing enabled, stopping named, editing the zone file, and restarting named isn't a supported method of updating zone data. That was unsupported in the first alpha release of the feature, but it should work now as long as the SOA serial is updated. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Inline Signing does not update SOA?
Hi Evan, -Original Message- From: Evan Hunt [mailto:e...@isc.org] Sent: Monday, May 07, 2012 12:44 PM To: Spain, Dr. Jeffry A. Cc: Bischof, Ralph F. (MSFC-IS40)[NICS]; bind-users@lists.isc.org Subject: Re: Inline Signing does not update SOA? Ralph: There was a lot of discussion about this issue on the bind forum around the first of the year. My recollection is that with inline-signing enabled, stopping named, editing the zone file, and restarting named isn't a supported method of updating zone data. That was unsupported in the first alpha release of the feature, but it should work now as long as the SOA serial is updated. I am using the released version from ISC. I always update the serial number of the unsigned zone (as I show in the original message). Is there something else that I may be doing wrong? The reason this is important to me is that the application that we use for IPAM/DNS/DHCP utilizes BIND and performs a stop/start to load new versions of the zones. Thank you, Ralph F. Bischof, Jr. NASA Agency IPAM/DNS/DHCP SAIC/NICS 256-544-3982 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Why does a non-delegated sub-domain work?
thanks for the feedback! From: sun-g...@live.com To: b...@wingenbach.org Subject: RE: Why does a non-delegated sub-domain work? Date: Mon, 7 May 2012 15:44:38 -0400 Thanks for the feedback John. Date: Mon, 7 May 2012 13:23:30 -0400 From: b...@wingenbach.org To: bind-users@lists.isc.org Subject: Re: Why does a non-delegated sub-domain work? s6 is a subdomain of the parent domain. Unless otherwise specified, subdomains are mastered (NS'd) by the parent (or extended parent domain) containing NS records. As such, because you didn't put any NS records in the zone file for s6, it follows the NS records of the parent which happen to be the same name server as s6. On the other hand, if you had attempted to master s6 on a different name server, it would not have worked. On 05/07/2012 12:32 PM, M. Meadows wrote: So ... if we have exacttarget.com delegated to ns1 and ns2.exacttarget.com nameservers and ... we manage the s6.exacttarget.com zone file from ns1 and ns2.exacttarget.com but we don't delegate s6 in the exacttarget.com zone file ... forgot to enter it in the zone file ... how is it that s6.exacttarget.com and its contents resolve properly from everywhere? Seems BIND is helping us out behind the scenes somehow. Right? Confused. Thanks, Marty ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
New to BIND - Setting up slaveserver
Hi everyone-
Newbe here...
We have been running name servers using QDNS (Mac) for eons but now I want to
change that.
I still have NS1 (Master) set up and running with QDNS. It is also set to be
the master for NS2 so that shouldn't need changing (I hope, although NS1 is
running BIND 4.x and the new NS2 Slave will be running the latest build of
BIND 9).
Having never set up NS records by hand, I'm not sure about what I'm doing, at
least for the Slave (NS2).
I've read up on almost everything I could find, gone through my BIND book (DNS
BIND) and have a pretty good understanding of the basic zone file setups.
What I'm not sure about is setting up my named.conf file for the Slave.
My first question is about my options. For now, I want to receive transfers
from my Master server. I may want to disallow the NS2 from transferring
requests for outside domains (It appears this is a good idea?) but for now
(testing) I don't want to do that. Does this look correct for a basic Slave
server's options?:
PS - I'm not sure on syntax - should the allow-update and allow-transfer
statements be like they are with an extra ; inside the curly brackets (It
feels wrong but I keep seeing it )?
options {
directory /var/named;
allow-notify {74.254.239.53 }; // Master IP Address
// allow-transfer {none ; };
recursion yes;
};
I have zones for the following:
Zone . IN {
type hint;
file named.ca;
}
Zone localhost IN {
type master;
file localhost.zone;
allow-update ( none; };
};
zone 239.254.74.in-addr.arpa IN {
type slave;
file slaves/74.254.239.54.rev; // Slave address
masters {74.254.239.53}; // Master address
};
Then I set up the zones for the websites (about 40):
zone higherpowered.com IN {
type slave;
file slaves/higherpowered.com;
masters {74.254.239.53};
};
etc
Logging ...
--
Next Question:
When setting up new slave zones, is there anything else I have to do other than
adding their zone records here in the named.conf? Do the actual zone
information files get written into the slaves directory according to the name
I call them here, or do I have to include a blank file already named for each?
I apologize for all the questions - I honestly have been looking up as much
information as I could before asking :-)
James Sheffer,
The HigherPowered Team!
supp...@higherpowered.com sa...@higherpowered.com
Web Design Development http://www.higherpowered.com
phone: 469-256-0268
We help businesses succeed on the web!
---
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: New to BIND - Setting up slaveserver
On 5/7/12 1:02 PM, James Sheffer ja...@higherpowered.com wrote:
We have been running name servers using QDNS (Mac) for eons but now I want to
change that.
welcome to bind.
I still have NS1 (Master) set up and running with QDNS. It is also set to
be the master for NS2 so that shouldn't need changing (I hope, although NS1
is running BIND 4.x and the new NS2 Slave will be running the latest build
of BIND 9).
it has been many years since i touched 4.x...it should be fine with newer
bind versions as slaves, but you might end up needing some additional
tweaking to get it all working.
if possible i'd really suggest setting up an ip alias on your existing
master and run bind 9.x on that...then cut-over to the updated bind
infrastructure once you're confident it's working. 4.x is so ancient at
this point i hate to see it actively used!
I've read up on almost everything I could find, gone through my BIND book (DNS
BIND) and have a pretty good understanding of the basic zone file setups.
What I'm not sure about is setting up my named.conf file for the Slave.
i'm probably biased, but i think the example conf here may be useful:
http://www.cymru.com/Documents/secure-bind-template.html
My first question is about my options. For now, I want to receive transfers
from my Master server. I may want to disallow the NS2 from transferring
requests for outside domains (It appears this is a good idea?) but for now
(testing) I don't want to do that. Does this look correct for a basic Slave
server's options?:
PS - I'm not sure on syntax - should the allow-update and allow-transfer
statements be like they are with an extra ; inside the curly brackets (It
feels wrong but I keep seeing it )?
it's not that you have an extra semicolon inside the brackets but rather
each element is terminated with a semicolon... this may help:
whatever-option {
elementA;
elementB;
elementC;
};
options {
directory /var/named;
allow-notify {74.254.239.53 }; // Master IP Address
// allow-transfer {none ; };
recursion yes;
};
I have zones for the following:
Zone . IN {
type hint;
file named.ca;
}
Zone localhost IN {
type master;
file localhost.zone;
allow-update ( none; };
};
zone 239.254.74.in-addr.arpa IN {
type slave;
file slaves/74.254.239.54.rev; // Slave address
masters {74.254.239.53}; // Master address
};
Then I set up the zones for the websites (about 40):
zone higherpowered.com IN {
type slave;
file slaves/higherpowered.com;
masters {74.254.239.53};
};
you may need to clean some spacing... and you likely don't need
allow-notify to the master, since that's where changes will occur (it'll
already know about new data, and notify your slaves).
recursion may be needed for your internal clients, but you generally want it
in a private view or controlled by an acl (see secure template).
When setting up new slave zones, is there anything else I have to do other
than adding their zone records here in the named.conf? Do the actual zone
information files get written into the slaves directory according to the
name I call them here, or do I have to include a blank file already named for
each?
when you add a new domain you'd add a master stanza on your primary server,
then add zone definitions in named.conf of type slave for the secondaries,
which will in turn zone-transfer the data files from the specified
master(s). they will indeed get written to the directory/file name(s) you
specify with file.
once you have a configuration you think is mostly correct, i suggest running
named-checkconf against it for helpful pointers on things that might need
work...as well as named-checkzone on your zone files.
good luck!
--
Men use thought only to justify their wrong doings,
and speech only to conceal their thoughts.
-- Voltaire
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline Signing does not update SOA?
In message a605629600c9a347b5881ffe16f101fb3d82823...@ndmsscc07.ndc.nasa.gov, Bischof, Ralph F. (MSFC-IS40) [NICS] writes: Hi, I am testing with BIND 9.9.0 and inline signing. I have run upon something that I cannot figure out. W hen I update the SOA record of the master zone file, if I reload the zone with rndc reload, the SOA record is updated. If I perform a stop/start of the named executable, the SOA change is not updated. I can even se e in the log file where the unsigned zone's serial number is incremented, yet the signed version does not ch ange. Below you can see where I started named, stopped named, made a change in the SOA and incremented the s erial number, then started named. After that, I incremented the serial number once more then performed an r ndc reload. If you only changed the SOA serial then this is expected behaviour. The unsigned zone's serial is less than the signed zone's serial. Named works out what has changed in the unsigned zone apart from the serial and applies that to the signed zone. That said I can see a bug where changes only to the SOA other than the serial will be ignored. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re:
Please add a Subject next time. Please log a bug report with you Mail User Agent vendor that it is doing unnessecary quoted-printable escaping. Comma does not need to be escaped and as the purpose of quoted-printable is to be readable by humans any unnecessary quoting should be avoided. In message dub109-w1019888953b5631b3dd13c1ac...@phx.gbl, hugo hugoo writes: Dear all, I have the following situation in my zone migration for one server (A) to a= nother server (B) The zone is called toto.be and contains the following record: www.toto.be 86400 IN CNAME www.titi.be == the zone titi.be is in the same server (A) but is not transferred t= o the server (B). If I do a dig @SERVER(A) www.toto.be == I receive the IP correspondi= ng to www.titi.be If I do a dig @SERVER(B) www.toto.be == I do not receive the IP corre= sponding to www.titi.be - Is this situation due to the fact that dig always and only contacts the s= erver mentionned in the command ? Dig only contacts one server when using @server (note it might try multiple addresses). To resolve the target of a CNAME the server needs to be configured to recurse or to have a local copy of the CNAME target. It is not a error for authoritative servers to not return the data for the target of a CNAME as recursive servers will make additional queries. - Does the titi.be and toto.be be on the same server to correctly use CNAME= S? No, recursive servers will perform a second lookup to resolve CNAME targets. Thanks for your feedback, hugo, -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New to BIND - Setting up slaveserver
In article mailman.702.1336433477.63724.bind-us...@lists.isc.org, michoski micho...@cisco.com wrote: note: keeping replies on-list, so others can also chime in and help... On 5/7/12 2:41 PM, James Sheffer ja...@higherpowered.com wrote: My mistake - I thought allow-notify was telling the slave to only accept transfers from the ip address supplied (Master). allow-notify is a list of additional addresses to notify about zone changes other than those listed as NS records in your zone files. Isn't that ALSO-notify? -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New to BIND - Setting up slaveserver
On 5/7/12 5:57 PM, Barry Margolin bar...@alum.mit.edu wrote: In article mailman.702.1336433477.63724.bind-us...@lists.isc.org, michoski micho...@cisco.com wrote: note: keeping replies on-list, so others can also chime in and help... On 5/7/12 2:41 PM, James Sheffer ja...@higherpowered.com wrote: My mistake - I thought allow-notify was telling the slave to only accept transfers from the ip address supplied (Master). allow-notify is a list of additional addresses to notify about zone changes other than those listed as NS records in your zone files. Isn't that ALSO-notify? thanks, precisely why you want to read the arm and keep replies on-list! also good not to reply during business hours while distracted... ;-) that said, looking at his original quote... telling the slave to only accept transfers from the ip address supplied would be neither... that's what allow-transfer is used for. -- By nature, men are nearly alike; by practice, they get to be wide apart. -- Confucius ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
