Zone name conflicts / overlapping

[david klein]

I don't know from Power DNS, but BIND expects to have one master where all
changes are initiated, and all other servers receive replication from the
single master, via incremental zone transfers. This is how conflicts and
race conditions are prevented. You would do better to designate one of the
two boxes as master, migrate all of the zones to that box, and have the
other box only receive replication from the first.

If you want multi-master replication (not recommended, because it introduces
a lot of strange behavior in edge cases), you would need to use something
like DLZ and move your zone management out of the nameserver itself, and
into an application that would feed DLZ. Note, this is nontrivial, and will
add a lot of complexity and processing overhead.

A best design would be to make both of your current servers consume
replication and add a third server, which does not have NS record, and which
is not in SOA, but which is designated the master and provides replication
to the other two. This way you decouple where you make the changes from
where you serve the data to the final consumers, and may be able to put it
in a secure walled-garden, with only connectivity allowed to the DNS servers
(which one presumes would be Internet facing).

HTH,

 -DTK



On Mon, Sep 19, 2011 at 12:45 AM, Ben C. <armondbc at gmail.com> wrote:

> Hello all,
>
> This is my first post to bind-users, so I would like to first of all
> say hello, and thanks to everyone who takes their time to read and
> respond to any mailing list post. =)
>
> I have a fairly complex situation where I have a pDNS server and a ISC
> BIND server, both containing unique zones.  I'm trying to make them
> "sync" to each other so that the end result is they both contain the
> same list of zones, and update the opposite's zone files regularly.  I
> am doing my best in designing it so that it *shouldn't* have the
> possibility of a zone conflict, where server A says something about
> zone "foo.com", and server B contains it's own unique record, so when
> they sync, .. well ...
>
> I noticed with BIND, what I expected happens if the situation occurs:
>
> zone "foo.com" {
>  type master;
>  file "/path/to/some.file";
> };
>
> // .. some stuff
> zone "foo.com" {
>  type master;
>  file "/path/to/some.other.file";
>  // ^^ They can be the same file, too ..
> };
>
> -- BIND simply refuses to start, which is great because it allows me
> to /see/ the error a little easier.
>
> However, the situation got interesting when the following occurs:
>
> zone "ns1.foo.com" {
>  type master;
>  file "/path/to/ns1.foo.com";
> };
>
> zone "foo.com" {
>  type master;
>  file "/path/to/foo.com";
> };
>
> Where ns1.foo.com's zone file would obviously contain an A record for
> itself (ns1.foo.com.) and then foo.com's zone file contains an A
> record for the same zone / hostname, ns1.foo.com.
>
> It appears to me, BIND sees the conflict / overlap but does not care
> about the order they are in, nor cares to exit (or even tell anybody
> about it), but simply use the more "specific" zone file which would be
> "ns1.foo.com".  I'm pretty sure this is intended behavior. Although
> for my specific and very individual circumstance, this is not ideal
> for me, but I'm by no means saying this is a bug, or "bad" behavior.
>
> I'm simply trying to figure out (1) if this is indeed the correct
> assumption, that BIND will always use the more "specific" zone,  ...
> (2) if there are ways to modify the behavior (short of editing the way
> BIND, or even DNS works) ...  (3) if there is a way to at least
> identify this kind of behavior in logs (error/warning message? maybe
> I'm missing it..) .. (4) a link or referral to any kind of relevant
> information would be useful -- documentation, mailing lists, anything
> -- I did a _lot_ of googling and even peeked around on IRC asking
> around, but either I'm not asking the question correctly, or it's not
> a very common thing :)
>
> Thanks for your time,
> Ben
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 

david t. klein

Cisco Certified Network Associate (CSCO11281885)
Linux Professional Institute Certification (LPI000165615)
Redhat Certified Engineer (805009745938860)

Quis custodiet ipsos custodes?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110919/180f48b5/attachment.html>