Bind99 and a slave named server

Alan Clegg alan at clegg.com
Wed Aug 21 12:39:34 UTC 2013


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

> On 20 Aug 2013, at 20:42 , Alan Clegg <alan at clegg.com> wrote:
>> If it's down that long and very often, you may want to consider putting your DNS on a reliable server/circuit/data center.
> 
> Well, often is somewhat more than... 5? times in the last 18 years... so, perhaps *often* isn't the right word.
> 
> Belts and suspenders?
> 
> manually digging every domain against the slave to get the info and reconstructing a file for bind sounds like something that will take considerable time. Or am I missing a trick?

You never answer the questions that I ask, so I'm not going to be able to do much more in this thread.

Why do you feel the need to switch from master to slave when the master is down?  I can't imagine a scenario that my master would be down for any reason beyond the data center physically burning down that I can't fix within a relatively short length of time and my data centers are on opposite ends of the United States.

And even if I had a catastrophic event, writing a script that is along the lines of:

           "grep ^zone | awk print $2 | dig $result > $result_file"

wouldn't be all that hard (or, probably better, at that point, prepare new hardware, set it up as a slave of all of the zones, set THAT server to "masterfile-format text", transfer the zones, convert it to master and be done with it.

Now, to guess at the answer to the original question, since we've not seen any useful log messages, nor a configuration file, I'm guessing that you have a "complex" configuration with multiple IP addresses bound to interfaces on the machine(s) and that the notifies for updates are coming from incorrect addresses (ones that don't match the NS records) so somewhere in the log files, you'll see "notify from non-master", or something similar.  Or what Mark guessed at and there's some type of firewall thing going on.

But that's just a guess.

Going one step farther, since you don't block zone transfers of kreme.com from either of the two listed NS servers (but as a note, you do block DNS completely from the master listed in the SOA record) I configured one of my servers as a slave of your zone:

zone "kreme.com" {
	type slave;
	masters { 75.148.117.90; 75.148.117.93; };
	file "slave/kreme.com";
};

And I got the zone with no problems at all:

21-Aug-2013 08:32:47.977 general: info: zone kreme.com/IN: Transfer started.
21-Aug-2013 08:32:48.278 general: info: zone kreme.com/IN: transferred serial 2013053002
21-Aug-2013 08:32:48.279 notify: info: zone kreme.com/IN: sending notifies (serial 2013053002)

I'm now going to remove this from my configuration.

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/20130821/a77c3bb2/attachment.bin>


More information about the bind-users mailing list