Microsoft DNS and Bind
Aladdin
These DNS servers have somewhere in about 20 AD integrated zones. Both
DCs are with Sp3. Also there are Bind servers on unix configured to pull
all zones from ONE Microsoft DNS server. So the problem is that from
time to time bind servers complain that serial number of some dns ad
zones have decremented. And bind servers refuse to transfer zones. So
Question is: why Microsoft DNS decrements dns zones serial numbers from
time to time?:/ I think that is not so pleasant bug:( Any other
thoughts? Thanks.
William Stacey [MVP]
the serial numbers. AD zones, for some reason, do strange things with the
serial number for internal replication but don't have details on the logic
tree. Maybe someone else knows?
--
William Stacey, DNS MVP
"Aladdin" <ala...@remove-this.antakalnis.lt> wrote in message
news:3EDD9AE2...@remove-this.antakalnis.lt...
Aladdin
any patch regarding this?
Jonathan de Boyne Pollard
A> that serial number of some dns ad zones have decremented.
Most of the contents of the "SOA" resource record are specific to one
particular DNS database replication mechanism: "zone transfer". The serial
number is updated by Active Directory database replication, but that's just a
sop for the benefit of things that expect serial numbers to change. (Active
Directory database replication doesn't _use_ the serial number field of "SOA"
resource records any more than it uses the "primary master name", "refresh",
or "retry" fields. The serial number could be a fixed constant, and Active
Directory database replication would still work.) The problem is that whilst
a single, sequenced, incrementing, counter matches the paradigm of the "zone
transfer" replication mechanism; it doesn't match a multi-master database
replication paradigm at all. It's impossible to have an exact mapping between
the two. Active Directory is constructing the best simulacrum that it can,
using a complex set of rules for when a serial number is and is not updated;
to make it look as if there is a single sequenced counter there (mostly) for
the benefit of humans that write and use diagnostic tools that expect it. But
it can only ever be an approximation of what is actually going on.
The upshot of this is a very simple maxim that should apply unless you are
very careful and know _exactly_ what you are doing: Don't mix and match
different types of DNS database replication within a single set of peer
content DNS servers. If you are going to use "zone transfer", use it on _all_
servers and have a single primary master. If you are going to have multiple
masters use Active Directory on _all_ servers. Treat the contents of the
"SOA" resource record as private to each particular replication mechanism, and
don't expect different DNS database replication mechanisms to use all of the
fields in the same way, or in a way that is compatible with one another, or
even to use them at all.
Kenneth Porter
news:3EDF3E33...@tesco.net:
> Active Directory is constructing the best simulacrum that it can,
> using a complex set of rules for when a serial number is and is not
> updated; to make it look as if there is a single sequenced counter
> there (mostly) for the benefit of humans that write and use diagnostic
> tools that expect it. But it can only ever be an approximation of
> what is actually going on.
Interesting. Any idea what that algorithm is? (Just curious.)
> The upshot of this is a very simple maxim that should apply unless you
> are very careful and know _exactly_ what you are doing: Don't mix and
> match different types of DNS database replication within a single set
> of peer content DNS servers.
I'd tighten this slightly to say don't mix within a domain of authority
(ie. over the control of one SOA record). Two domains with different SOA's
on the same server can use different replication systems.
--
Kenneth Porter
http://www.sewingwitch.com/ken/
William Stacey [MVP]
zone really changes, either via dynamic update on one PM or other, they
should stay in sync and only go up. That allows standard secondaries to
observe proper behavior.
--
William Stacey, DNS MVP
"Jonathan de Boyne Pollard" <J.deBoyn...@tesco.net> wrote in message
news:3EDF3E33...@tesco.net...
Ace Fekay [MVP]
William Stacey [MVP] <sta...@mvps.org> posted his concerns then I replied
down below:
> All that said, they should still only increment and not decrement.
> When the zone really changes, either via dynamic update on one PM or
> other, they should stay in sync and only go up. That allows standard
> secondaries to observe proper behavior.
>
> --
> William Stacey, DNS MVP
>
This is true, but what's happening, the way I see it and what Jonathan said,
since there are mutliple "masters" at any given time, a change made on one
of them does not necessarily replicate at that time sequence before say
another "master" has a change and that is replicated. It's not that the zone
serial is being decreased, but rather that the latest replication cycle
replicated the zone from another DC that just happened to have a lower
serial number and since AD replication doesn't care about zone serial
numbers, it just blatantly overwrites the previous copy, since it believes
that the AD database on that particular server has a newer version than on
the one that it's replicating to rather than paying attention to zone serial
numbers.
I also think rather just use Primary/Secondaries to eliminate this
"behavior"
Cheers!
--
Regards,
Ace
Please direct all replies to the newsgroup so all can benefit.
Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
--
=================================
William Stacey [MVP]
number decremented. I assume this means on the primary master his secondary
points to. So it still should not matter how what the two primaries do, the
one "he" points to should stay the same or *increase, if a change was made
on the other primary. If the change was made on "his" primary, it should
still increase and that will be reflected on the other when they sync. So
either way, they should still always go up and not down relative to any
point in time. I imagin there could be an issue when you promote a new
standard primary to ad-integrated with a low serial number. Then that SOA
may overwrite the others as it has the "newest" data - not sure. Anyone
have the logic flow chart on that?
--
William Stacey, DNS MVP
"Ace Fekay [MVP]" <PleaseSubstituteMyFirstName&LastNa...@hotmail.com>
wrote in message news:%23qP%23mV6K...@TK2MSFTNGP10.phx.gbl...
Aladdin
OF THE MANY Microsoft's own implementations of RFCs. Microsoft says that, lets
say, DNS server works as described in RFC but it in not true, it works in
general as Microsoft wants it to work:( Because of that we have various problems
when we try to use third party products with Microsoft products. As regarding
SOA, IT SHOULD ALWAYS increment. I don't care about replications, I only want
DNS servers to work correctly. Because for now I simply cant use Bind servers as
ordinary secondaries with Microsoft DNS:( But maybe it is Microsoft intention to
make it impossible to achieve:(
William Stacey [MVP]
> ordinary secondaries with Microsoft DNS:( But maybe it is Microsoft
intention to
> make it impossible to achieve:(
I don't think they did it on purpose. To be fair, multi-master primaries is
a great invention from MS. While everyone else was thinking about it - MS
did it. That is not an RFC (AFAIK) but there is probably a draft or will
one soon. However, I still agree with you, the serial numbers should only
increase as this behavior obviously breaks standard XFR/IXFR.
--wjs
Jonathan de Boyne Pollard
Yes. It's documented in Microsoft KnowledgeBase article Q282826.
KB> I'd tighten this slightly to say don't mix within a domain of
KB> authority (ie. over the control of one SOA record). Two
KB> domains with different SOA's on the same server can use
KB> different replication systems.
Indeed. Clarifying the maxim, therefore: Don't mix and match different types
of DNS database replication when replicating the DNS data for a given "zone"
across the single set of peer content DNS servers that publish those data.
Jonathan de Boyne Pollard
WSM> decrement.
I'd like to see some evidence that they actually _did_ decrement. You are
taking it purely on trust that they actually did. The published algorithm
certainly makes no mention of ever decrementing serial numbers. I strongly
suspect that they _didn't_ actually decrement at all, and what actually
happened is that the BIND servers are configured to be slaves of more than one
master.
In such a scenario, it is possible for the slave to see serial numbers lower
on one master than on the master that it previously looked at, given the way
that Active Directory replicates data. (The Microsoft KnowledgeBase article
even mentions this.) What is happening is _not_ that the serial numbers are
decrementing; but that the serial numbers _on two separate servers_ are not
the same as each other and the BIND slave sees first one and then the other
because it talks to two different masters, and complains because the second
serial number seen is lower than the first.
WSM> When the zone really changes, either via dynamic update on
WSM> one PM or other, they should stay in sync and only go up.
As I've said once already, a single, sequenced, incrementing, counter doesn't
match a multi-master database replication paradigm at all. It's impossible to
have an exact mapping between the two. You are requiring the impossible.
Jonathan de Boyne Pollard
WSM> He said the serial number decremented.
No. He said that the BIND servers _complained_ that the serial number
decremented. That's not the same thing.
WSM> I assume this means on the primary master his
WSM> secondary points to.
You're also taking him at his word that his BIND servers are slaves to a
single master. The Microsoft KnowledgeBase article and I have covered how the
case where a BIND server is a slave to _multiple_ masters can cause such a
complaint _without_ the serial number decrementing. So it seems likely, given
that he's seen the exact behaviour that can occur in such situations, that,
despite what he says, as a result of accident or oversight in actual fact his
BIND servers _are_ slaves of multiple masters.
As I said, I'd like to see the evidence that the serial numbers really did
decrement. I'd like to see the log entries showing that the BIND server
really _was_ querying the same master both times; and I'd like to see the
actual serial number values involved.
Jonathan de Boyne Pollard
A> DNS servers to work correctly.
You, as a DNS administrator, _should_ care about replication. You should make
the effort to understand what the softwares under your control are actually
doing, what mechanisms they are employing, and (in particular) how you have
arranged those mechanisms to act in concert.
A> Because for now I simply cant use Bind servers as ordinary
A> secondaries with Microsoft DNS:(
Wrong. You haven't been paying attention. You cannot (or, rather, should
not) use BIND servers as slaves of Microsoft DNS servers _when_ those
Microsoft DNS servers are not using "zone transfer" database replication
amongst themselves and a single master.
A> But maybe it is Microsoft intention to
A> make it impossible to achieve:(
It's not malicious intent on Microsoft's part. Indeed, similar problems can
occur when one mixes and matches other DNS database replication mechanisms.
One doesn't even have to have any Microsoft software involved at all to
experience problems such as this. It's a problem inherent in the mixing and
matching of database replication mechanisms. As I implied before, different
DNS database replication mechanisms do not use all of the fields of "SOA"
resource records in the same way, or in ways that are compatible with one
another, or even at all.
Ironically, the real problem here is your decision (expressed above) not to
care about replication, such that you aren't making the effort to consider the
actual mechanisms involved and what their various parts are for. You are
taking a rule that _only_ applies to the case where the "zone transfer"
replication mechanism is used, and taking it to apply universally to all
replication mechanisms. (Read RFC 1034 again. Serial number increment is
only discussed where it deals _specifically_ with the "zone transfer" database
replication mechanism. There's no implication that it applies to other
replication mechanisms.) Then you are berating Microsoft for not exactly
adhering to that rule in a completely different database replication, even
though (by the RFC) it doesn't apply, even though it is impossible to do so
(given the nature of the mechanism), and even though Microsoft has done its
best to provide a compatibility facility anyway (despite the fact that it need
not have done, and could have just fixed the serial numbers at a given
constant value).
William Stacey [MVP]
--
William Stacey, DNS MVP
"Jonathan de Boyne Pollard" <J.deBoyn...@tesco.net> wrote in message
news:3EE08DEB...@tesco.net...
William Stacey [MVP]
> not) use BIND servers as slaves of Microsoft DNS servers _when_ those
> Microsoft DNS servers are not using "zone transfer" database replication
> amongst themselves and a single master.
That article does not say that. IMO, regardless of what/how MS does
multi-master replication in the back-end, any standard secondaries should
expect to see them act as a normal standard primary. AFAICT, this is how
they designed it and how it should act.
> It's not malicious intent on Microsoft's part. Indeed, similar problems
can
> occur when one mixes and matches other DNS database replication
mechanisms.
> One doesn't even have to have any Microsoft software involved at all to
> experience problems such as this. It's a problem inherent in the mixing
and
> matching of database replication mechanisms.
However, there implementation should be transparent.
> replication mechanisms. (Read RFC 1034 again. Serial number increment is
> only discussed where it deals _specifically_ with the "zone transfer"
database
> replication mechanism. There's no implication that it applies to other
Also on Update 2136 - maybe others.
> replication mechanisms.) Then you are berating Microsoft for not exactly
> adhering to that rule in a completely different database replication, even
> though (by the RFC) it doesn't apply, even though it is impossible to do
so
> (given the nature of the mechanism), and even though Microsoft has done
its
The RFCs do not dictate an implementaion method on handling many backend
tasks. This is a good thing. MS can implement the backend anyway they wish
as they did with multi-master replication. However, they do need (IMO) to
adhere to the RFCs on the protocol, structures and expected behavior as
dictated in the RFCs. For all we care or know, they could use a SQL
database to implement the zone file backing store and do syncs with SQL
updates (and they will eventually) - that does not matter. They still need
to do the correct thing for RFC clients interacting with the server. I
agree we don't know that serial is decrementing on one primary, but if it
is, that would be an error/bug.
Ace Fekay [MVP]
> serial number decremented. I assume this means on the primary master
> his secondary points to. So it still should not matter how what the
> two primaries do, the one "he" points to should stay the same or
> *increase, if a change was made on the other primary. If the change
> was made on "his" primary, it should still increase and that will be
> reflected on the other when they sync. So either way, they should
> still always go up and not down relative to any point in time. I
> imagin there could be an issue when you promote a new standard
> primary to ad-integrated with a low serial number. Then that SOA may
> overwrite the others as it has the "newest" data - not sure. Anyone
> have the logic flow chart on that?
>
> --
> William Stacey, DNS MVP
>
I agree, it should always increased and never decrement. So this is an
interesting issue. I would be interested in seeing a logic flow on this too.
Aladdin
> I don't think they did it on purpose. To be fair, multi-master primaries is
> a great invention from MS. While everyone else was thinking about it - MS
> did it.
Yes, I agree with that. But don't forget to add - it's great invention and
works in most cases well only in PURE Microsoft environment:( If we don't have
the one...:)
As for now my boss (linux fan :) ) wants to kill me because of this shitty
behaviour:( And I can't blame on him:(
>
Aladdin
> replication mechanisms.) Then you are berating Microsoft for not exactly
> adhering to that rule in a completely different database replication, even
> though (by the RFC) it doesn't apply, even though it is impossible to do so
> (given the nature of the mechanism), and even though Microsoft has done its
> best to provide a compatibility facility anyway (despite the fact that it need
> not have done, and could have just fixed the serial numbers at a given
> constant value).
Nice long reply, ufff:) In some cases you're right and I don't argue with
that. BUT, don't you thing that SOA serial number must only increment and not
decrement? Answer me only that and not abour, replications, implementations and so
on. Because from your reply I can see only one way, if I'm using DC with AD
integrated zones I can use only these DCs without any additional bind or microsoft
servers configured as ordinary secondaries, because of that serian number
behaviour. And you can tell me anything, I still think that this is not normal:(
P.S. Microsoft found on bug allready. This bug - dns decrements serial during
shutdown and restart. Do you still think that this is normal behaviour?:)
Ace Fekay [MVP]
Aladdin <ala...@remove-this.antakalnis.lt> posted his concerns then I
replied down below:
> Nice long reply, ufff:) In some cases you're right and I don't
> argue with that. BUT, don't you thing that SOA serial number must
> only increment and not decrement? Answer me only that and not abour,
> replications, implementations and so on. Because from your reply I
> can see only one way, if I'm using DC with AD integrated zones I can
> use only these DCs without any additional bind or microsoft servers
> configured as ordinary secondaries, because of that serian number
> behaviour. And you can tell me anything, I still think that this is
> not normal:(
>
> P.S. Microsoft found on bug allready. This bug - dns decrements
> serial during shutdown and restart. Do you still think that this is
> normal behaviour?:)
Here's an interesting article, which *may* be causing part of the problem:
304653 - The Serial Number Is Decremented in DNS When You Reboot the
Computer:
http://support.microsoft.com/?id=304653
Aladdin
> WSM> All that said, they should still only increment and not
> WSM> decrement.
>
> I'd like to see some evidence that they actually _did_ decrement. You are
> taking it purely on trust that they actually did. The published algorithm
> certainly makes no mention of ever decrementing serial numbers. I strongly
> suspect that they _didn't_ actually decrement at all, and what actually
> happened is that the BIND servers are configured to be slaves of more than one
> master.
NO. Bind servers are configured to pull zones ONLY FROM ONE OF THE TWO
Microsoft DNS servers, believe me.
Our Bind servers run on AIX and my unix admin showed plenty of the following
entries:
May 19 15:24:45 fobas2 Message forwarded from fobas: named[5680]: Zone
"32.168.192.in-addr.arpa" (IN) SOA serial# (17) rcvd from [10.17.0.80] is < ours
(18)
This zone is even not configured for the automatic updates.
As I said Bind servers are configured to pull zones only from 10.17.0.80.
And I actually saw when serial decremented when I restarted one of my DC. But
this is known bug. I suspect that there are some left unseen:(
> In such a scenario, it is possible for the slave to see serial numbers lower
> on one master than on the master that it previously looked at, given the way
> that Active Directory replicates data. (The Microsoft KnowledgeBase article
> even mentions this.) What is happening is _not_ that the serial numbers are
> decrementing; but that the serial numbers _on two separate servers_ are not
> the same as each other and the BIND slave sees first one and then the other
> because it talks to two different masters, and complains because the second
> serial number seen is lower than the first.
I repeat, BIND servers are configured to pull zones only from one master.
> WSM> When the zone really changes, either via dynamic update on
> WSM> one PM or other, they should stay in sync and only go up.
>
> As I've said once already, a single, sequenced, incrementing, counter doesn't
> match a multi-master database replication paradigm at all. It's impossible to
> have an exact mapping between the two. You are requiring the impossible.
In other words Microsoft implemented DNS in AD with its replication and made
DNS servers not to work as they must. Because of that it is impossible to use
third party products with Microsoft products. In DNS case it is possible, but with
not so pleasant problems:(
Aladdin
> > serial during shutdown and restart. Do you still think that this is
> > normal behaviour?:)
>
> Here's an interesting article, which *may* be causing part of the problem:
>
> 304653 - The Serial Number Is Decremented in DNS When You Reboot the
> Computer:
> http://support.microsoft.com/?id=304653
>
Yes, and I actually saw when serial number decrements during server
restart:) And I was able to see that many times. And yes again - it is part of
the problem:) Will try to apply patch in a few days:)
William Stacey [MVP]
--
William Stacey, DNS MVP
"Aladdin" <ala...@remove-this.antakalnis.lt> wrote in message
news:3EE483F6...@remove-this.antakalnis.lt...
Ace Fekay [MVP]
Jonathan de Boyne Pollard
JdeBP> can, using a complex set of rules for when a serial number
JdeBP> is and is not updated; to make it look as if there is a
JdeBP> single sequenced counter there (mostly) for the benefit
JdeBP> of humans that write and use diagnostic tools that expect
JdeBP> it. But it can only ever be an approximation of what is
JdeBP> actually going on.
KP> Interesting. Any idea what that algorithm is? (Just curious.)
JdeBP> Yes. It's documented in Microsoft KnowledgeBase article
JdeBP> Q282826.
WSM> That article does not say this from what I read.
Yes, it does. Are you reading the same Q282826 as the rest of
us are ? It's entitled "Active Directory-Integrated DNS Zone
Serial Number Behavior" and it describes how and when the
counter is incremented.