Bind99 and a slave named server

Alan Clegg alan at clegg.com
Tue Aug 20 23:56:10 UTC 2013


On Aug 20, 2013, at 7:35 PM, LuKreme <kremels at kreme.com> wrote:

>> zone example.com {
>> 	type master;			// I own this.
>> 	file "files/example.com";	// Here's where I read them from
>> };
>> 
>> it will become:
>> 
>> zone example.com {
>> 	type slave;			// Now a slave
>> 	file "files/example.com";	// Must now be writable by BIND
>> 	masters { 192.168.1.1; };	// IP address of master server here
>> };
>> 
>> Bazinga!
> 
> And suddenly, miraculously, the master and slave will communicate with each other and the slave will know when changes occur? Isn't that what allow transfer and notify are for?

Yes, the master and slave will communicate and updates will happen as needed. That's what NS records are for.  And the MNAME in the SOA record.  DNS theory.

>>> 1. RAW versus TEXT
>>> 2. allow transfer
>>> 3. notify
>>> 4. key files<1>
>>> 5. dnssec-enable
>>> 6. managed-keys
>> 
>> 1:  you don't care, as the new slave will xfer over the old data
> 
> I *do* care, honest.

What *ABOUT* raw vs text?  BIND 9.9 slaves (and newer) store and expect the transferred file in raw format on the slave.  All other versions (and BIND 9.9 masters) store (and expect) the zone data in text format.  You don't need to mess with the setting unless you are doing something like looking at the zone data on the slave using a program that expects text format.  You shouldn't be doing that anyway because the data on disk may not match what is in memory.  If you need access to the data on the slave, use "dig".

When you first convert your servers to slaves, remove the existing zone data and it will be xfer'd from the master as soon as the slave is started (this was mentioned in a previous post).

>> 2:  read the documentation, it's not part of master/slave transition, setup good acls
>> 3:  notify just works unless you have odd configuration
> 
> There is no allow-notify setting anymore or it's not needed?

Advanced notification mechanisms are only needed if you do things like (ugh) hidden slaves.  The flooding notify mechanism that BIND uses "just works" if you have NS records that match reality.

If you need more information on this, if you post your entire configuration file, I'm sure that someone will be more than happy to do a configuration review.

>> 4:  you don't want the same key files on more than one server
> 
> See? that's why I asked.

>> 5:  not related to master/slave, just leave it enabled
> 
> Well, leave it disabled I guess as it's commented out in the conf file.

If it's commented out, you are leaving it enabled since that's the default.

>> 6:  that's dnssec-validation related
>> 
>> If you have any specific questions on these items, ask them, otherwise there are a number of classes around (I teach one of them, several other people on the list [that have responded to you, if I remember right] also teach them) and I would recommend either a class or a book (again, several come to mind).
>> 
>> A fantastic (free) resource is:  http://www.zytrax.com/books/dns/
> 
> Yes, something like that, exactly. I shall go read. Sadly, my OR book on bind is very outdated and doesn't cover new-fangled tech like rndc-key and dnssec.

Cricket's book (o'reilly) has rndc in it.  Ron's book (zytrax) covers DNSSEC in great detail and several of the documents that I've prepared cover DNSSEC in detail:

  https://kb.isc.org/article/AA-00820/0/DNSSEC-in-6-minutes.html

>>> and any changes in how root servers are setup since I am pretty sure that has changed since I first setup bind 9.1 many eons ago (2002?).
>> 
>> If you are Internet visible, you don't do anything with configuring anything about the roots, as it "just works" (compiled into bind since 9.3ish).
> 
> I distinctly remember having to go get the root file myself under either 9.0 or 9.1 and sometime since then there was a kerfuffle as one of the root servers changed and, I could be wrong, I had to manually update that change.

Thus "9.3ish".  This entire thread is caused by an upgrade to BIND 9.9 if I remember correctly.

"Don't provide a root hint zone because it's provided for you by BIND"

I'm sorry if I'm coming across as a tired old grump, but I think that we've been trying to answer your questions without doing all of the work for you.

AlanC
-- 
Alan Clegg | +1-919-355-8851 | alan at clegg.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130820/39d31ad3/attachment.bin>


More information about the bind-users mailing list