Re: New to BIND - Setting up slaveserver
On 5/7/12 5:57 PM, "Barry Margolin" wrote: > In article , > michoski wrote: >> note: keeping replies on-list, so others can also chime in and help... >> On 5/7/12 2:41 PM, "James Sheffer" 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
Re: New to BIND - Setting up slaveserver
In article , michoski wrote: > note: keeping replies on-list, so others can also chime in and help... > > On 5/7/12 2:41 PM, "James Sheffer" 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:
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 , 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
note: keeping replies on-list, so others can also chime in and help...
On 5/7/12 2:41 PM, "James Sheffer" wrote:
> On May 7, 2012, at 3:56 PM, michoski wrote:
>> On 5/7/12 1:02 PM, "James Sheffer" wrote:
>>> 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;
>> };
>
> I guess I thought that the semi-colon was terminating the statement by being
> outside the brackets (a semi colon both inside and outside didn't seem to
> "balance" in my mind!) but I see your point now. I also wondered that if this
> is correct, shouldn't there be a semi colon inside the "allow-notify"
> statement as well (or as you pointed out, all statements?
yes, this syntax is common...for example, you will want:
allow-notify {
10.10.10.10;
10.10.10.20;
// etc...
};
named-checkconf will help you here.
> As for the spacing, I was working remotely and didn't have a way to copy/paste
> between locations, so that is my manual typing, typing typos :-)
>
> 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.
beside the dns & bind book and google references, i suggest getting familiar
with the BIND 9 ARM for your version:
http://www.isc.org/software/bind/documentation
you can see links there such as:
http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.pdf
http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.html
>> 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).
>
> I still need to study "recursion" as I haven't quite grasped it's meaning :-)
recursion is how you run a caching server. so if you have clients that need
to look up "google.com" or other data not hosted explicitly in your zone
files recursion is what you want. however, you want to lock it down to
specific clients (using views, acls and allow-recursion options) so random
bad guys can't do things like poison your cache.
without recursion enabled, your server will only be able to serve
"authoritative" data found in local zone files you configure.
you can read more on this in the ARM. :-)
> Thanks - I've already found the named-checkconf command and am using it to
> make sure everything is the way it should be.
>
> Since the folder "named" is owned by root and I created a folder called
> "slaves" for the zone files within the named folder, I assume that I want the
> "slaves" folder also owned by root with the same privileges, correct?
usually you will run BIND with a flag like "-u named" which says to drop
root privileges after startup, so you will want directories BIND needs to
write to owned by that user or a group the user belongs to.
> Thank you so much for the help and explanations, as well as pointing me to the
> example conf files - the more I can see the better I understand and don't ask
> to many questions that I could have found in a search first :-)
it's good that you take the time to search (we all should), but also don't
feel bad about asking questions...that's why we're here!
--
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
Re: Inline Signing does not update SOA?
In message , "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: New to BIND - Setting up slaveserver
On 5/7/12 1:02 PM, "James Sheffer" 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
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: 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
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: 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: 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: 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" 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?
On 5/7/12 11:32 AM, "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? 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: Inline Signing does not update SOA?
On Mon, May 7, 2012 at 7:31 AM, Spain, Dr. Jeffry A. 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
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?
> 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
Re:
On 5/7/12 8: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). 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:
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 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
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
[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
