Two masters for one zone

[Simon Waters]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Herb Martin wrote:
>
> Well of course we agree on this but appreciable inconsistency
> is realistically avoidable -- something no worse than the
> inherent inconsistency from Primary to Secondary is quite
> achievable.
>
> To complain about inherent inconstistancy that is no worse
> than any other solution would be disingenuous.

In database replication, which is the same problem AFAICT, you just have
to figure out a design that converges. This will give you the same
levels of consistency as you get with primary/secondary, and a conflict
resoluion that converges if it is unavoidable and doesn't break DNS
functionality.

Some of the pathological cases in replication may not have corresponding
  meaningful DNS events. i.e. your network would have to be very broke
for DNS updates that cause certain types of conflicts to occur, at which
point it is usually acceptable to bail out and ask for a human to clean
the mess up. i.e. uncoordinated deployment of multiple DHCP servers
serving the same IP ranges and zones.

The SOA serial is easy, it is a monotonicaly increasing number, that
could be replaced with the timestamp (some encoding) of the last update
applied to a zone. Trying to rely on SOA serial between masters is
futile, but such an approach for IXFR or AXFR to secondaries should be fine.

The real problem comes with additions and removals, which may or may not
depend on existing records I suspect, but I haven't tried a detailed
analysis to see if it is an issue, I tried once but it was more academic
interest than practical DNS work (no one was paying ;). Some of these
problems may depend on how many masters you have, for most purposes I
suspect 2 is enough, as the prime interest is presumably to handle
dynamic updates when the primary is down.

Indeed failover rather than multimaster replication is probably
sufficent, but you end up with the "split brain" problem, where when the
WAN is down the fail-over master can't tell that the real master is
still up and changing the data.

Adding subdomains also raised some interesting issues, but I suspect
they are readily solved if you are prepared to accept you will only be
able to add subdomains when all the masters are available, in sync (by
temporarily suspending/queuing updates). Assuming you are doing a zone
by zone approach! It might be possible to devise an "add zone" update
scheme that would work without the need to delay updates till all
masters were synchronised.

Anyone actually tried this in practice other than MS? I suspect the
theoretical problems are far worse than what actually occur in practice,
although I didn't see any "something bad happened" dialogues in the ADS
implementation, so either Microsoft solved it (so a solution exists) or
we can have some fun messing with the bugs.
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/K5VmGFXfHI9FVgYRAvEcAJ9RhaPxAI/kHEo3E9Uq8gTwKqmAlACgoKku
tk+b0gs3Z/pJn3fvoGWwMcA=
=C9+h
-----END PGP SIGNATURE-----