Subject: RFC2136 question

From: [email-masked]
Date: Tue, 9 Nov 1999 13:53:32 -0500

Hi,

Recently I learned that (Lucent) QIP port of BIND 8.1 implemented DNS Update
"execution" in cached zone on the slave server. This fits into their larger
DNS management scheme, where the sender of DNS Update packets knows about
all nameservers authoritative for the domain and sends update packet to each
of them, removing the need for NOTIFY (and subsequent IXFR) traffic.

RFC 2136 doesn't really discuss such a case, but doesn't seem to explicitely
prohibit it either. Below is the closest statement to the issue I found:

3.1.1. The Zone Section is checked to see that there is exactly one
   RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
   requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
   so named is one of this server's authority zones, else signal NOTAUTH
   to the requestor.  If the server is a zone slave, the request will be
   forwarded toward the primary master.

It seems to be "compatible" as long as the slave keeps forwarding the update
message to the master and sends response to the update packet only after
receiving the response from the master. There is a question of SOA serial
number - QIP slave server doesn't increase the serial number after executing
the update locally - this makes the whole thing a bit non-transparent, but
doesn't break anything.

QIP primary master behaves normally.

Does it mean the server is RFC non-compliant ?

Honza Jirousek

---

From: Robert Elz <[email-masked]>
Date: Wed, 10 Nov 1999 17:44:29 +1100

Date:        Tue, 9 Nov 1999 13:53:32 -0500
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 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: Paul A Vixie <[email-masked]>
Date: Thu, 11 Nov 1999 08:43:11 -0800

> of them, removing the need for NOTIFY (and subsequent IXFR) traffic.

this will lead to incoherence among so-called "authority" servers, and is bad.
(a client may not be able to reach all servers, and may not be able to back out
changes committed on one server after failing to reach one of the others.)

> the update locally - this makes the whole thing a bit non-transparent, but

since the slave doesn't know whether the master actually will honour the update
(for reasons of reliability, or policy change), the update can NOT be applied
locally.

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

yes.

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 11 Nov 1999 09:34:57 -0800

> processing it so it can answer with the updated data sooner), ...

this is unacceptable.  updated slave data can come only from the master.
a slave has no idea whether a master has already received conflicting
updates which havn't been propagated yet, or whether the master will
refuse this update for policy reasons, or whether the master is even alive.

> updates independantly, they're also going to need to arrange to sequence them

this whole design assumes that there are no non-QIP servers in the mix.

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 11 Nov 1999 16:24:25 -0800

> No provision for updates when the master is down?  *That* is unacceptable.

i don't disagree.  but doing it in a proprietary fashion which is not
interoperable with other vendors' implementations and which fails in
a catastrophic way (by default, as in the QIP case, since full RFC
compliance is "an option") is absolutely the wrong approach.

multi-master DNS is not an impossible dream.  we can have it.  we talked
about it somewhat during the discussions which led to RFC 2136.  it's not
an unsolvable problem, but it was seen as a different problem than 2136.

let's start working on it.  there are a million details to iron out.

but shipping code that does the wrong thing by default with RFC 2136 messages
is just not on the menu.

---

From: "M. T. Hollinger" <[email-masked]>
Date: Thu, 11 Nov 1999 18:51:23 -0500

>refuse this update for policy reasons, or whether the master is even alive.

Paul, don't you agree that the main reason for having slave servers is to
provide redundancy during periods when the master is down?  If my master
server is down for a day due to a disk failure, the slave server will pick
up the slack.  Eventually, the disk will be restored (though probably with
an older zone database than the last one the slave successfully
transferred), and the master will return.

On the day that my master server is down, as I wait for the disk to be
replaced and its contents restored from backup tape, users will want to keep
performing dynamic updates.  If dynamic updates are to be useful, there must
be some mechanism for them to take effect while the master is down (and
preferably for the updates to then be forwarded to the master upon its
return).

            - Mark

---

From: Paul A Vixie <[email-masked]>
Date: Fri, 12 Nov 1999 00:06:10 -0800

> I think I can still write a simple draft with RFC 1995 based update
> ignoring RFC 2136, if you so wish.

i do not so wish, and i did not so wish on either of the previous two
occasions when you volunteered to do this.

> Or, do you volunteer to iron out the million or trillion details?

i have not counted them and i'm disinclined to accept your estimate,
since your numbers are too round.

i'm definitely not ready to rehash the history of this, though.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Nov 99 15:42:07 JST

Paul;

You seems to have forgotten the history.

> let's start working on it.  there are a million details to iron out.

It was solvable.

For the solutions, we need clarification based real world theories
used for simultaneous update of real world database.

And, I actually showed you in the ML the clarification on how
prerequisites sections are unnecessary based on update of IXFR format.

However, you insisted on having prerequisites and not having explicite
SOA.

That is, RFC2136 might have made it unsolvable to generate a trillion
(or infinite) detals to iron out.

							Masataka Ohta

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Fri, 12 Nov 1999 05:54:59 -0500

If it is really important for the master to be up, then you eningeer a
hot stand by, etc...

From:  "M. T. Hollinger" <[email-masked]>
Message-ID:  <[email-masked]>
To:  "Robert Elz" <[email-masked]>, "Paul A Vixie" <[email-masked]>
Cc:  <[email-masked]>, "namedroppers" <[email-masked]>
References:  <[email-masked]>
Date:  Thu, 11 Nov 1999 18:51:23 -0500