Subject: Re: RFC2136 question

From: [email-masked]
Date: Wed, 10 Nov 1999 11:10:56 -0500

Thanks for the reply,

I'm aware of at least some of the conceptual problems you talk about. Note
that I'm indeed talking about fairly tightly controlled and "designed" DNS
environment, where all servers run the same (or at least known) versions of
software, the sources of dynamic DNS updates are known and controlled as
well (in fact all DynDNS updates in this setup are sent from a small number
of DNS management servers, who do send the update packets to all servers for
a domain).

Now this QIP "enterprise-wise" port of BIND comes with some features, which
can possibly save load or enhance managebility of dynamic DNS *in such an
environment*. Executing DNS updates on secondaries is one of them. I
wondered whether this feature would comply with real-world DNS scenarios and
standards.

You've got a very good point about a need for SOA check before executing the
change on the slave.

There remains one thing I'm not clear on. Is it a no-no for a DNS server to
present different data at different times with the same SOA serial number ?
e.g.  if I did "dig @slave zone AXFR" at two different times and I would get
different data, but the same SOA serial number.  Or if I did "dig @slave1
zone AXFR" and "dig @slave2 zone AXFR" and I woud get different zone data,
but the same SOA serial. Typically this would be a signal of DNS
misconfiguration, but it doesn't necessarily have to be so (and doesn't have
to break IXFR/AXFR synchronization), if slave server played games with local
DNS changes. I always understood SOA serial number as a mere signal for zone
replication between master and slaves, but it could be also considered as
stricter "zone data version number" with a requirement of data-serial
consistency. Is there any RFC which would presume such meanimg of serial
number ?

The above would apply to the time after the slave updates the cached zone
data (but not SOA serial) but before it does IXFR/AXFR (without NOTIFY that
time period could take up to "refresh" time).

Honza

  | Does it mean the server is RFC non-compliant ?

The only part that looks fundamentally wrong to me is this part of your
description of how things work ...

  | removing the need for NOTIFY (and subsequent IXFR) traffic.

That means that the theory is that all the servers are co-operating and
updating their zones in the same way (including the serial numbers) after
any update.   That's broken.

There is no requirement on a client to send to all the servers (no rule
preventing it either), nor is there any guarantee that all the servers for
a zone will be running the same code.

Hence, whatever a secondary server does with an update it receives (like
processing it so it can answer with the updated data sooner), it still must
forward it to the primary server (which you say it is doing), and then the
primary server must increment the serial number, and the secondary servers
(one way or another - optional NOTIFY, plus one of IXFR or AXFR or whatever)
must copy the updated zone file from the primary.   There may have been
other modifications that the primary server knows about, but which the
secondary does not.

The part of "doing the modification and forwarding" instead of just
forwarding is also dangerous, and would take a very clever server
implementation.   At the very least it would need to check that the zone
has not been modified at the primary since the secondary last synchronised
(ie: a SOA query), otherwise some recent modification at the primary may
cause the update to operate differently (fail when it would have succeeded,
succeed when it would have failed, or simply delete different data, the
order of updates can be important - if different servers are processing
updates independantly, they're also going to need to arrange to sequence them
the same way - somehow).

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 11 Nov 1999 18:41:59 +1100

Date:        Wed, 10 Nov 1999 11:10:56 -0500
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | I'm indeed talking about fairly tightly controlled and "designed" DNS
  | environment,

If you're operating in a private world, you can do what you like.  That the
protocol adopted has some similarities to an IETF standard is pretty much
irrelevant - doesn't matter one way or the other.

  | There remains one thing I'm not clear on. Is it a no-no for a DNS server to
  | present different data at different times with the same SOA serial number ?

Yes - while I am not sure right now that anything actually depends upon
that behaviour (I don't know of anyone doing SOA checks and refreshing
TTLs for example, though it could be done).

  | e.g. if I did "dig @slave zone AXFR" at two different times and I would get
  | different data, but the same SOA serial number.

That would certainly be broken (for the internet environment of course - in a
private world, if you can cope, cope).   2136 is quite clear that the serial
number must be incremented whenever the zone data is changed, and the serial
number is exposed.   That wasn't changing anything in 1034, just emphasising it.

kre

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 17 Nov 1999 10:04:27 -0500

>number is exposed.   That wasn't changing anything in 1034, just 

I've seen a (Microsoft) nameserver present changing data (dynamically 
inserted based on DHCP action) while not incrementing the serial number.
So I could ask for the A record of alden.maxware.no at 2 different times 
and get back 2 different answers, yet the SOA serial number was the same.

However, that one did the additional twist of not including those data in 
the AXFR of the zone at all, which means that a secondary wouldn't see the 
data that was changing - perhaps it didn't consider this to be zone data?

I personally think this is bizarre, but others may think otherwise...

(No, I don't have the serial number, and haven't checked it for the last 6 
months. I could check again if someone cares.)

                          Harald

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 16 Nov 1999 13:51:27 -0800

> You've got a very good point about a need for SOA check before executing the

As I said (separately from what Robert said about checking the SOA), the
slaves can't really know if the master plans to honour the update.  To make
multiple masters work in the current DNS, each "authority" ("zone") server
has to have equal access to an out of band storage and transfer mechanism.
That's how Microsoft describes their LDAP-based ADS, and while I have no
idea whether I'd trust my data to it, it's a consistent model from DNS's
point of view.

> present different data at different times with the same SOA serial number ?

Yes.