Subject: Re: axfr-clarify breaking RFC 1034

From: [email-masked]
Date: Thu, 20 Feb 2003 13:25:51 +1100

> [email-masked] writes:
> > Semi-synchronized changes have always been part of the DNS.
> 
> If there's an honest proposal to modify the DNS specifications to allow
> semi-synchronized changes (once again: parent zone being changed after
> all the child servers have changed), perhaps the discussion will reveal
> that those changes work with BIND 4, BIND 8, djbdns, etc.; that those
> changes are useful; and that nobody objects to this modification.
>
> On the other hand, if there's an honest proposal to modify the DNS
> specifications to allow _unsychronized_ changes (such as your asinine
> configuration examples), the discussion will reveal that those changes
> do _not_ work with the majority of DNS servers on the Internet, that
> those changes are _not_ useful, and that the modification is a bad idea.
>
> What we have here is much worse: a thoroughly dishonest attempt to slip
> the latter modification past us as part of an ``AXFR clarification.''
> Anyone with a shred of integrity should be opposing this fraud.

	If you want synchronized changes in the parent and child
	zones you need to write up a draft to explain how to do it.
	The current DNS does not have this capability.

	I would suggest that you will need to add inception and
	expiration times as meta data for each RR.

	I will be happy to review the draft when you make it available.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Feb 2003 03:41:48 -0000

Here's a chart summarizing the situation:

   Timing of         |Useful in|RFC 1034 |BIND 8 |BIND 9 |tinydns
   data change       |practice |compliant|support|support|support
   ------------------+---------+---------+-------+-------+-------
   Synchronized      |Yes      |Yes      |No     |No     |Yes
   Semi-synchronized |Yes      |No       |Yes    |Yes    |Yes
   Unsynchronized    |No       |No       |No     |Yes    |No

The BIND company observes that

   * synchronized changes are hard to do with BIND, even though they're
     required by RFC 1034; and
   * unsynchronized changes can fail miserably with BIND 8 et al., which
     account for the majority of DNS servers.

The obvious solution is semi-synchronized changes, which work with the
entire installed base. I wouldn't object to modifying RFC 1034 to allow
semi-synchronized changes.

(To repeat the relevant definitions: A synchronized change happens at
the same time in all the parent servers and all the child servers. A
semi-synchronized change happens in the parent zone---specifically, the
parent serial is changed---after it happens in all the child servers.)

I certainly _do_ object to allowing unsynchronized changes. They don't
work correctly with the installed base, and they have no advantages over
semi-synchronized changes. It's insane to demand massive redeployment of
DNS servers for the sake of a useless protocol modification.

[email-masked] writes:
> you need to write up a draft

_I_ don't need to write anything. I am not the one trying to change the
requirements in RFC 1034. My software follows the spec.

_Your_ company is trying to impose requirements that aren't in RFC 1034.
You are claiming that most DNS server installations on the Internet have
to be changed. You are demanding that we tolerate configurations that
violate RFC 1034.

Even worse, instead of honestly proposing this protocol change, you are
trying to sneak it past us as part of an ``AXFR clarification''; and
someone who has been paid for BIND work is abusing his position as WG
chair by fraudulently claiming ``consensus.'' This is a sham.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: [email-masked]
Date: Thu, 20 Feb 2003 17:14:57 +1100

>    data change       |practice |compliant|support|support|support

	This is not a accurate summary.
 
>      required by RFC 1034; and

	RFC 1034 requires the *administators* to keep the glue in sync.

Section 4.2.2. Administrative considerations

As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.

	This is a administrative action.

	If you can automate administrative actions well and good.  Using
	a single file for all your PRIMARY zones is actually a useful
	way to partially achieve this.  It will keep all PRIMARY zones
	on the server in sync.

	If you wish you can copy the contents of a SECONDARY into a 
	PRIMARY provided you also change the SERIAL of the PRIMARY to
	reflect the change.  I wouldn't encorage this as a default
	action however.

	However changing the contents of SECONDARY zones is not allowed.
	That action needs to be performed through the PRIMARY server for
	the zone.  UPDATE could be used to facilitate this.  Again I would
	not encourage this as a default action.

	A server ceases to be a SECONDARY if it changes the zones contents.

>      account for the majority of DNS servers.

	Which is why we fixed our server.
 
> semi-synchronized changes.

	You have to be kidding.  Even if we were to go down that
	path (which I don't believe we should) it still leaves
	servers with the underlying problem in that they are not
	serving the zone contents as entered.
 
> DNS servers for the sake of a useless protocol modification.

	Nobody is demanding a massive redeployment.  None of the changes
	require a massive redeployment.
 
	Mark

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Feb 2003 18:16:26 -0000

Andrews admits that his configuration violates RFC 1034 section 4.2.2.
He also agrees that DNS servers are allowed to discard the inconsistent
parts of his configuration. (BIND 9 doesn't; djbdns does; BIND 8 does to
some extent.)

However, because the _title_ of section 4.2.2 is ``Administrative
considerations,'' Andrews concludes that DNS servers aren't allowed to
discard the inconsistent parts of his configuration _if_ they obtained
data for the parent zone through AXFR rather than directly from an
``administrator.''

It would be easy to shred the details of that argument. I could point
out again that the configuration also violates section 4.2.1; the title
of section 4.2.1 is ``Technical considerations''; no ``administrators''
here. There are many other obvious mistakes in what Andrews says.

But there's a much larger problem here. Look at the overall structure of
Andrews's argument:

   (1) Observation: This configuration, which is prohibited by RFC 1034,
       doesn't work correctly with 77% of the installed base.

   (2) Insane conclusion: 77% of the installed base is broken! We have
       to change all of it to make this configuration work correctly!
       Let's ignore all the objections, and declare the software used
       for most of the Internet's DNS servers to be non-compliant!

Anyone who cares about interoperability will draw a very different
conclusion:

   (3) Sane conclusion: The configuration is broken. Stop using it.

Andrews is trying to shift blame from the broken configuration to the
installed base. He's fighting against both RFC 1034 and the real world;
that's why he's resorted almost entirely to religious arguments about
proper implementation techniques for servers.

There is one spot where Andrews returns to reality. He points out that
his software (unlike mine) has never supported the synchronization
required by RFC 1034. Obeying RFC 1034 would mean, among other things,
changing all the BIND installations, which would be very difficult.

Does this mean that we need the broken configurations? No! There's a
middle ground between the synchronized configurations required by RFC
1034 and the broken configurations: namely, semi-synchronized
configurations (parent serial changing after all the child servers have
changed), which work with the entire installed base. RFC 1034 can be
modified to allow semi-synchronized configurations.

[email-masked] writes:
> Even if we were to go down that path (which I don't believe we should)

Let me get this straight, Mark. You're screaming that the RFC 1034
requirement is too restrictive---because it requires synchronization
that your software can't handle---but you don't believe that it should
be changed to allow configurations that work with all existing software?

You know, Mark, this discussion would have been a lot easier if your
company had started by making an honest proposal to change the protocol,
instead of trying to sneak changes past us as ``clarifications.''

---

From: Greg Hudson <[email-masked]>
Date: 20 Feb 2003 21:36:31 -0500

> parent serial is changed---after it happens in all the child servers.)

Does this mean there can't be unrelated changes in the parent zone while
the child servers are still being updated?  (Or, more realistically,
after the child servers have been updated but before the administrators
of the parent zone have processed the change request for the glue
records.)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2003 06:27:51 -0000

Greg Hudson writes:
> the child servers are still being updated?

No. You can make as many other changes, and corresponding serial-number
updates, as you want. Semi-synchronization refers to the timing of the
parent serial-number update corresponding to a child-zone change.

Presumably you're accustomed to the following zone update procedure for
glue data:

   (1) Change the data in the child zone on the child master.
   (2) Change the child serial number. This must be done after #1.
       (I mean >=, not >, when I say ``after''; you probably do #1 and
       #2 at the same time.)
   (3) Copy the new data to all the child slaves. 
   (4) Change the data in the parent zone on the parent master.
   (5) Change the parent serial number. This must be done after #4.
   (6) Copy the new data to all the parent slaves.

The definition of a semi-synchronized change is simply that #5 is done
after #3; you don't finish the parent update until all the child servers
have been updated. (The definition of a synchronized change is that #1,
#2, #3, #4, #5, #6 happen at the same time.) Mark's problems can't occur
unless he changes the parent serial number too early.

It's fine for other updates to be happening at the same time. In fact,
Mark's problems can't occur for active zones, even if he does screw up
the timing of #5 for one update; the next update wipes out all of the
inconsistencies that he created by screwing up the configuration.

---

From: Robert Elz <[email-masked]>
Date: Fri, 21 Feb 2003 19:34:02 +0700

Date:        21 Feb 2003 06:27:51 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Presumably you're accustomed to the following zone update procedure for
  | glue data:
  | 
  |    (1) Change the data in the child zone on the child master.
  |    (2) Change the child serial number. This must be done after #1.
  |        (I mean >=, not >, when I say ``after''; you probably do #1 and
  |        #2 at the same time.)

To be correct, it should not be "probably" (as viewed from the outside
world anyway).  When the data in the zone changes, the serial number must
also change (simultaneously).   This, of course, doesn't impact upon your
argument at all (I am just pointing it out so anyone who reads this doesn't
get the impression that they're allowed to make changes to a zone, and then
sometime later, update the serial number).

  |    (3) Copy the new data to all the child slaves. 
  |    (4) Change the data in the parent zone on the parent master.
  |    (5) Change the parent serial number. This must be done after #4.
  |    (6) Copy the new data to all the parent slaves.
  | 
  | The definition of a semi-synchronized change is simply that #5 is done
  | after #3; you don't finish the parent update until all the child servers
  | have been updated.

That's fine, that's how things should work in most cases.

  | (The definition of a synchronized change is that #1,
  | #2, #3, #4, #5, #6 happen at the same time.)

That's essentially impossible to do in general, though obviously can be
done in some special cases.    Inventing a new protocol to make it happen
could be done - but there is no such thing in the DNS, and the DNS is what
we're concerned with here.

  | Mark's problems can't occur
  | unless he changes the parent serial number too early.

I didn't bother to read Mark's description of the problem, as I know
what the problem is, and didn't need to be educated about it.  So, it
is possible that he didn't describe the issue, or that you didn't
understand it - in any case I'm not in a position to say whether or
not Mark's particular problems can or can't occur.

But problems certainly occur following your "semi-synchronized" model,
having the parent update later doesn't help - which should be obvious,
as the only fix for the problem that is consistent with your view are
your synchronized updates, which require the parent to update sooner
(ie: with a delay of 0 after the first possible instant when it can
properly update).

Any delay larger than 0 opens a window during which problems can
occur.   Since in the practical universe, rather than some imaginary
one, the delay is very often going to be (much) longer than 0 (dealing
with ccTLDs it can be months...) we need to find what method causes
least problems to deal with the unavoidable discrepancies that do
occur.

Note that the DNS design assumes that there will be differences - it
has timers that limit how out of date data are allowed to become.
The RR TTL controls caches, the SOA timers control secondary servers.
There's no protocol control over parent zone updates, just the
administrative ones.  All this is expected (and the users of the DNS
are expected to plan their changes to allow for this).  The timers
can all be adjusted as needed to assist limit the period during which
these occur.   When operating the way it was designed, the DNS will
always fix itself (and yes, the way it was designed includes the parent
updating glue to match what is in the child zones).

The way that you want the DNS to operate however, it can get into a
state where it will not self-heal, it can stay inconsistent forever.
That's not how it was designed to work.  That it is possible to reach
this state under your reading of how things are supposed to work should
be regarded as pretty good evidence that your reading is incorrect.

Of course, that you're able to read it this way, and other are able to
read it differently, is conclusive evidence that clarification is needed.

And, of course, when we do that, some readers of the original spec are
bound to conclude that what has happened in the "clarification" isn't
clarification at all, but change.   Others see it as "well, that's what
it always said, why do we need this at all?"   Both of those groups
are mistaken.

When we have something that is sometimes read one way, and sometimes
read a different way, we don't decide which is correct by counting the
number of readers who formed one interpretation, and counting the number
who formed a different one - much less do we do so by counting the
number of deployed copies of implementations based upon each reading.
What we do is look at what the spec should say, to work correctly.

  | It's fine for other updates to be happening at the same time. In fact,
  | Mark's problems can't occur for active zones, even if he does screw up
  | the timing of #5 for one update; the next update wipes out all of the
  | inconsistencies that he created by screwing up the configuration.

Yes, this is correct - assuming that the same problem doesn't occur again.
But that's a big assumption, given that the problem is caused by the
normal operation of the servers, there's no reason to expect that anything
different will happen from one update to the next.   If the servers smash
zones together on the first update, they're going to do it on every
subsequent update.   Which actual data is inconsistent may vary from one
update to another, but having some inconsistent data, continually, is
quite likely.

And, of course, you're also assuming that there is a "next update" within
some practical time frame.

Some zones are updated relatively frequently (daily, or more often), others
can go for years without any changes at all.  The DNS should correct its
inconsistencies without requiring updates that aren't otherwise required.
Operating as designed, it does.   Operating as you would define it, it
doesn't.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2003 18:59:25 -0000

Robert Elz writes:
> the serial number must also change (simultaneously)

That's certainly part of the RFC 1034 requirement. But Andrews is
complaining that the RFC 1034 requirement is too hard to follow. (For
example, you're violating this part if you change your data but forget
to update the serial number until later.)

I'm pointing out the minimum set of timing constraints that guarantee
consistent data at the end. From this perspective, it's fine for the
serial number to be updated as a separate step.

> state where it will not self-heal, it can stay inconsistent forever.

False. After step #6 of a semi-synchronized update, all the servers
have the updated data---whether the servers are running BIND 4, BIND 8,
BIND 9, or djbdns. All of Andrews's problems occur because he's updating
the parent serial number too early.

---

From: [email-masked]
Date: Fri, 21 Feb 2003 17:16:38 -0600

On Fri, Feb 21, 2003 at 06:59:25PM -0000, D. J. Bernstein wrote:
> All of Andrews's problems occur because he's updating

This is hard to watch: people cannot believe it is possible to have
perfect synchronization, you keep asserting it is possible. I think if
you tell tell them how djbdns does it, the pingpong will be over.
Some might even install djbdns just to see for themselves.

Mate