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. <armon...@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@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?
_______________________________________________ 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