Subject: Last Call: DNS Zone Transfer Protocol Clarifications to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 10 Feb 2003 11:59:42 -0500

The IESG has received a request from the DNS Extensions Working Group
to consider DNS Zone Transfer Protocol Clarifications
<draft-ietf-dnsext-axfr-clarify-05.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2003-2-24.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-05.txt

--
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: bert hubert <[email-masked]>
Date: Tue, 11 Feb 2003 09:23:55 +0100

> [email-masked] or [email-masked] mailing lists by 2003-2-24.

This version of the draft looks just fine. I have no real issues with any of
the content as far as I can see after reading it for an hour or so.

Bert Hubert
PowerDNS

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting

---

From: "D. J. Bernstein" <[email-masked]>
Date: 14 Feb 2003 10:32:28 -0000

This ``clarification'' document prohibits several perfectly legitimate,
very widely deployed, AXFR implementation techniques. See my web page
http://cr.yp.to/djbdns/axfr-clarify.html for details. In particular,
this document violates RFC 2119, section 6, in five separate ways.

At least seven people have gone on record as objecting to axfr-clarify:

   Dean Anderson,
   Len Budney,
   Felix von Leitner,
   Kenji Rikitake,
   Aaron Swartz,
   Sam Trenholme (MaraDNS implementor), and
   me (djbdns implementor).

Furthermore, the Yokohama minutes report a WG decision that axfr-clarify
is ``too bind specific''---too specific to BIND 9, to be precise.

Despite this decision and these extensive objections, the WG chairs
declared ``consensus'' for axfr-clarify and sent it to the IESG. Those
claims of consensus were clearly fraudulent: there was no WG discussion
of axfr-clarify in the interim! Subsequent discussions did not resolve
any of the objections.

A review of all of the axfr-clarify discussions in the WG list archive
shows that this document is being pushed primarily by people who have
been paid for BIND work: Mark Andrews, Roy Arends, David Conrad, Danny
Mayer, Jim Reid, Paul Vixie, Brian Wellington, document author Andreas
Gustafsson, and WG chair Gudmundsson.

There are non-BIND people who support the document, notably PowerDNS
implementor Bert Hubert, but my understanding is that Hubert's support
is based entirely on the hope that this document will prevent future
interoperability problems, without regard to the huge redeployment costs
that this document is imposing on the users of existing implementations.

Note that the users attacked by this document include BIND 8 users---who
are no longer represented in the WG by implementors, now that the BIND
implementors are pushing BIND 9. The document's proponents admit that
their ``clarification'' imposes rules disobeyed by BIND 8. My survey
http://cr.yp.to/surveys/dns1.html two months ago showed that 45% of all
.com names were served by BIND 8, while only 23% were served by BIND 9.

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

P.S. You know what really amazes me about this? In another forum, a few
people, including a former IESG member, are objecting to an incredibly
valuable requirement that software support a universal encoding (UTF-8)
of a universal character set (Unicode). Why? Because this requirement
would force some existing software to change---and these people claim
that the IETF _never_ demands changes from deployed software that
complies with the previous standards.

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Feb 2003 18:38:22 +0700

Date:        14 Feb 2003 10:32:28 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | This ``clarification'' document prohibits several perfectly legitimate,
  | very widely deployed, AXFR implementation techniques.

It prohibits some odd-ball techniques that risk future enhancements
(and generally clarifies the almost non-existant specification).

  | In particular,
  | this document violates RFC 2119, section 6, in five separate ways.

2119 is a list of words with definitions to save other RFCs from having
to define them over and over again.   It has some recommendations about
where the words should be used - but it is always up to the document in
question (the WG for a WG document) to decide which of those words should
be used in what circumstances (or to ignore 2119 completely if so inclined).
"Violating" 2119 is a nonsense concept.

  | Furthermore, the Yokohama minutes report a WG decision that axfr-clarify
  | is ``too bind specific''---too specific to BIND 9, to be precise.

That related to some of the language in the draft I believe (I was there,
and I think was one of those who supported this position).   Some of that
I still believe could be cleaned up to be nicer.   It doesn't relate to
any of the substance though, nor particularly to BIND 9, but rather to use
of terms like "slave" and "master" which are (recent) BIND inventions to
refer to what the DNS (1034/1035) has always used the words "secondary"
and "primary" for.   There's a bit more like that I think as well.  None
of it really matters, though the doc would be better if it was all fixed.

  | Despite this decision and these extensive objections, the WG chairs
  | declared ``consensus'' for axfr-clarify and sent it to the IESG.

I believe rough consensus exists on this one (it is rough, but there's
certainly much more support than opposition).

  | A review of all of the axfr-clarify discussions in the WG list archive
  | shows that this document is being pushed primarily by people who have
  | been paid for BIND work:

Even if this were true (and I don't believe it is - I have never been
paid for any BIND work) it is irrelevant.   It is not at all unusual
for a group of related people (sometimes all actually currently employed
by one organisation) to push a proposal.

  | Note that the users attacked by this document include BIND 8 users---who
  | are no longer represented in the WG by implementors, now that the BIND
  | implementors are pushing BIND 9. The document's proponents admit that
  | their ``clarification'' imposes rules disobeyed by BIND 8. My survey
  | http://cr.yp.to/surveys/dns1.html two months ago showed that 45% of all
  | .com names were served by BIND 8, while only 23% were served by BIND 9.

What has this to do with anything?   All that is being done here is to
tighten up the specification for how AXFR is supposed to be done.   That
old BIND code has bugs can hardly be news (even older BIND code had
millions of bugs).   Nothing proposed is going to cause failures of
any existing implementations, nor any current implementations to fail to
interoperate with any new implementations that follow this clarification.

The scare mongering about "huge redeployment costs" is utter nonsense,
no-one is being asked to redeploy anything.

All this document seeks to do is to get future AXFR implementations to
be a little tighter in what they do, so that some possible (even worse)
implementations bugs would have less bad effects than they might otherwise
have done.

The effect upon your implementation would be, that unless you alter
your implementation, you wouldn't be able to claim that it is conformant
with this new RFC (once it is issued of course).   That's it.   As you
seem to dislike AXFR as a zone transfer mechanism anyway (which is just
fine, it has never been required) I'm not sure why you'd care.

kre

---

From: bert hubert <[email-masked]>
Date: Fri, 14 Feb 2003 14:51:55 +0100

> this document violates RFC 2119, section 6, in five separate ways.

See me not care. Almost all RFCs are mutually contradictory. This is not
math, and even there we have Goedel. Some observations. 

Does this clarify things
------------------------

Well, yes. It also specifies new behaviour. The name is therefore
wrong. I'd move to just call this RFC the 'New AXFR RFC' and be done with
it. It should then also specify that nameservers should have configuration
options to deal with older servers.

Otherwise, I'd be more than happy with a non-semantics changing version of
this draft, one that just documents how to start an AXFR and how to finish
it.

The Zone
--------
Your software does not know about zones, it appears. Much of your criticism
boils down to the fact that you do not have a zone concept and do not want
to have one, where 1034 and 1035 simply ooze with zone definitions and they
are clearly part of the DNS philosophy.

Could you perhaps separate your criticism into the parts that are truly
stupid and the parts that just don't fit in with your architecture? 

At a very early point, PowerDNS also did not have zones but it turns out to
be hard to do proper interoperation without them.

  "Therefore, in a zone transfer the master MUST send exactly those
   records that are associated with the zone, whether or not their owner
   names would be considered to be "in" the zone for purposes of
   resolution, and whether or not they would be eligible for use as glue
   in responses"

I don't really get this one on second or third reading. Does this condone
weird data in a zone, data that does not end on the zone name? Like the
examples you mention?

>    Dean Anderson, Len Budney, Felix von Leitner, Kenji Rikitake, Aaron
>    Swartz, Sam Trenholme (MaraDNS implementor), and me (djbdns
>    implementor).

I object to the naming, this goes beyond clarification. Calling BIND9
behaviour 'existing practice' is bad politics. I hate this part:

"and slaves MUST ignore any duplicate RRs received.". I know this is about
robustness but it makes an incoming AXFR a O(N^2) operation which sucks.
Yes, you could build sophisticated hashes & stuff but why not put the burden
on the server supplying the zone. It has had to load the zone at least once
anyhow.

> that this document is imposing on the users of existing implementations.

Stuff changes anyhow. Otherwise we'd still be running NCP and HOSTS.TXT. I
do like to have the ability to add TSIGs to an AXFR in the additional
section, even if that potentially breaks older remotes.

Regards,

bert

---

From: Peter Koch <[email-masked]>
Date: Fri, 14 Feb 2003 15:34:55 +0100

{trimmed To: list}

> on the server supplying the zone. It has had to load the zone at least once

Depends on how actively you'd like duplicates to be ignored. I'd read it
in a way that prohibits rejecting the incoming zone upon receipt of a
duplicate RR but also prohibits handing out these duplicate RRs (which
is in RFC 2181, section5, already) in responses. Also, it allows the slave,
if also acting as a master (*), to hand out the zone without those duplicates,
whereas the general philosophy is that the zone not be touched while being
handed through.

(*) kre: this is why primary/secondary are not sufficient terms in the
    context of this document

-Peter

---

From: [email-masked]
Date: Fri, 14 Feb 2003 11:00:54 -0600

On Fri, Feb 14, 2003 at 02:51:55PM +0100, bert hubert wrote:
> math, and even there we have Goedel. 

You certainly did not mean to refer to Godel in this context.  But
even if you did not, the above one and and a half lines are for the
books: how to lucidly express a healthy ignorance in math and,
simultaneously, come out of the closet and expose your opinion that
logic has no place in evaluating RFCs.

> Your software does not know about zones, it appears. 

It appears as in "it appears by running, and testing it on my box in
the last few months", or as in "it appears in my mind right now so
that I can go on with the rant that follows" ?

But seriously: are you serious?  Could you at least try to be by
avoiding soap opera words like "hate" and "stupid" and search for more
grown up versions?

Thx,

---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis

---

From: bert hubert <[email-masked]>
Date: Fri, 14 Feb 2003 18:40:56 +0100

> logic has no place in evaluating RFCs.

Complaining that RFCs are internally inconsistent should not stand in the
way of progress. 

Regards,

bert

---

From: Dean Anderson <[email-masked]>
Date: Fri, 14 Feb 2003 13:48:09 -0500 (EST)

> (and generally clarifies the almost non-existant specification).

I don't think they can be dismissed so easilly. Indeed, I think the
proposed changes are rather "oddball", and are actually unncessary in
order to implement IXFR (which was the original claimed justification).

Indeed, the proposed changes are only necessary to justify BINDs' oddball
IXFR changes. They are only necessary to make BIND 9 compliant with the
RFC's.

It seems quite odd that a "clarification" would put 77% of the existing
servers out of compliance, and only brings into compliance a currently
non-compliant implementation.  I think it is unprecedented in the history
of any standards organization, not just the IETF.  Such a significant
change is clearly a completely new version.  Thus the widespread
complaints about fraudulent labeling and discription of the proposal.

** 45% Bind 8
** 23% Bind 9
** 77% are not bind 9, and will not be compliant after this
"clarification"

This is not the way to run a railroad. (or rather, it is a railroading of
the changes through the process...)

> certainly much more support than opposition).

Consensus on the part of Bind proponents, yes. Consensus when the wider
community is counted, no.

> by one organisation) to push a proposal.

Of course not. It happens frequently in consortia.  However, a "bloc"
behind a single vendor is usually counted as such.  Its not unheard of for
a vendor to try to create an appearance of widespread support using
subcontactors, when in fact there is none.  When that happens, people cry
"foul". We are crying "foul" now.

> interoperate with any new implementations that follow this clarification.

We have hashed this through many, many times, I fail to see how you can
still make this claim with a straight face.  It certainly will cause
failures: It will cause all non-bind 9implementations to be non-compliant
(or 77% of the servers).

> no-one is being asked to redeploy anything.

Asked? No. It is demanded.  This is a change to a standard, and to be
compliant demands conformance to the standard, and thus change, and
redeployment.

Perhaps unfortunately, the IETF has no branding program. However, we still
have interoperability testing to determine compliance with the standard.

> implementations bugs would have less bad effects than they might otherwise

Clarification is a worthy goal. No one is opposed to clarification.
However, the changes proposed go in the wrong direction, and are motivated
purely by a crufty IXFR implementation in Bind 9.  Many people have
indicated that the correct approch to clarification is to look at what
Bind8 and _OTHER IMPLEMENTATIONS_ did.

Since BIND9 is described in an Oreily book, this could be a difficult for
them. However, they should have thought about that before publishing a
book describing non-conforming implmentation as though it was standards
compliant. They created their own mess, and now want 77% of the world to
fix it for them. Talk about the shifting of costs to someone else...

The Bind9 people claim the changes are necessary to support IXFR. Of
course these changes aren't necessary. IXFR is in principle no different
than database transaction log processing. It has no bearing whatsoever on
AXFR any more than Oracle incremental replication has bearing on the
Oracle query protocol.  They made changes to AXFR to make their crufty
IXFR implementation work, because they are bad engineers. They exercised
even worse judgement by publishing a book on their implementation prior to
standardization. Now they want the 77% of the world to jump through hoops
to make their oddball, badly engineered work "standard".

I'm not buying it.

> fine, it has never been required) I'm not sure why you'd care.

That's huge.  And its not _only_ djbdns.

		--Dean

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 14 Feb 2003 11:38:46 -0800 (PST)

> this document violates RFC 2119, section 6, in five separate ways.

Your objections are certainly well known by now, and I have repeatedly
responded to them.

> At least seven people have gone on record as objecting to axfr-clarify:

Can you please show us that record?  I cannot find any messages from
Felix von Leitner in my namedroppers archive.

>    Kenji Rikitake,

Kenji Rikitake withdrew his objection.

>    Aaron Swartz,

Aaron Swartz' objections appear to be based on his belief that BIND 8
and UltraDNS violate section 3 of the draft.  I have not seen any
further objections from him after I pointed out that they don't.

> is ``too bind specific''---too specific to BIND 9, to be precise.

My impression (based entirely on a private e-mail discussion with
Randy Bush, since I was not present at the Yokohama meeting) is that
this was not a decision that axfr-clarify is too BIND specific in the
view of the WG, but rather a decision to give the draft more time for
discussion due to *your* claim that it is too BIND specific.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 14 Feb 2003 12:24:46 -0800 (PST)

> order to implement IXFR (which was the original claimed justification).

This is not a "change".  There are no existing standards which mandate
or even explicitly allow mixing of data between zones.  On the
contrary, RFC1035 specifically suggests using separate data structures
that ensure that no such mixing occurs:

   6.1.2. Database

   While name server implementations are free to use any internal data
   structures they choose, the suggested structure consists of three major
   parts:

      - A "catalog" data structure which lists the zones available to
	this server, and a "pointer" to the zone data structure.  The
	main purpose of this structure is to find the nearest ancestor
	zone, if any, for arriving standard queries.

      - Separate data structures for each of the zones held by the
	name server.

      - A data structure for cached data. (or perhaps separate caches
	for different classes)

Which one is more "oddball", a server which follows this suggestion or
one which does not?

> IXFR changes. They are only necessary to make BIND 9 compliant with the

BIND 9 is compliant with the existing AXFR standard even without
axfr-clarify.  It's not hard to comply since the existing the
specification is almost nonexistent.

> servers out of compliance,

77% of the existing servers do not reliably interoperate in IXFR (even
with one another), and sometimes serve data inconsistent between the
authoritative servers of a zone.  They *should* be declared out of
compliance.

> and only brings into compliance a currently
> non-compliant implementation.

Again, BIND 9 is currently compliant.

> community is counted, no.

I am not a BIND proponent.  Although I wrote the draft while working
on BIND 9, I encountered the interoperability problems caused by the
current lack of specification and saw the need for clarification years
before I received my first BIND-related paycheck.  I currently work on
products that directly compete with BIND, and I have no financial
incentive to see BIND succeed.

I have been reluctant to bring up this issue because because it should
make no difference whatsoever - the draft should be judged solely on
its technical merits, not based on the affiliations of its proponents,
but the groundless accusations of misconduct and conspiracy theories
by you and Dr. Bernstein have gone too far.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 14 Feb 2003 12:52:52 -0800 (PST)

Robert Elz writes:
> and I think was one of those who supported this position).

Hmm, this seems a bit different from Randy's recollection.  But anyway...

> Some of that
> and "primary" for.

These terms were defined in RFC1996 and are also used in RFC2136, and
they seem clearer than "primary" and "secondary" when describing
topologies where a slave server is itself acting as a master for other
slaves.  If you like, I could add a reference like "This document uses
the terms master and slave as defined in RFC1996".

> There's a bit more like that I think as well.  None

I don't recall seeing any specific suggestions for changes, and I did
not attend the Yokohama meeting.  Could you please them to me or
namedroppers?
-- 
Andreas Gustafsson, [email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Fri, 14 Feb 2003 17:25:40 -0500 (EST)

> that ensure that no such mixing occurs:

The key word is "suggests", which has the meaning...

> Which one is more "oddball", a server which follows this suggestion or

Neither. It doesn't matter what the implementation is. What matters is the
protocol. Despite the "suggestion", all implementations prior to Bind 9
made different (but ultimately identical) assumptions. I don't think the
section you quote is so compelling.

The "oddball" part is requiring a change to a irrelevant part of a
protocol.  This is nothing less than bad or lazy engineering.** As I
mentioned previously, IXFR is in principle no different from an Oracle
incremental replication. Clearly, one does not need to alter SQL to have
replicated databases.  One _could_ alter SQL, but it would be a "bad
idea".  The concepts of replicated databases, and different kinds of
replication is well researched, and well documented.  There isn't any
rocket science to IXFR, nor are there any theoretical papers to be written
on the subject. The AXFR protocol does not _need_ to be changed for IXFR.
IXFR can be made to work with AXFR the way it stands.

** a collection of good engineering principles:

A "good" engineer avoids making gratiutous changes.

A "good" engineer, thinking a significant change to a standard of
interoperability needs to be made, will seek consensus from the standards
body on the change before distributing it.

A "good" engineer, upon finding a language ambiguity or vagueness, would
investigate how others analyzed the language, what assumptions they made
about the ambiguity and follow accordingly, or discuss and resolve the
ambiguity if there are no concrete implementations.

A "good" engineer, realizing an incompatible change has to be made to a
standard of interoperabilty, would consult the standards body prior to
publishing a (non-interoperable) book on the subject.

A "good" manager, would ensure that engineers are making "good"
engineering decisions.

Pretty clearly, the Bind 9 group didn't exercise "good" engineering
principles, nor "good" engineering management.  Quite obviously, they made
a mistake altering and distributing AXFR prior to standardization, or by
exploiting the vagueness in the specification. Clearly, they knew about
the incompatibility issue.  One must wonder if anyone could be so arrogant
as to assume that they could push anything they pleased through the
standardization process.  We probably can't know the answer. I don't know
anything about their intentions and can only fairly judge the results of
their actions. However, there is much to criticize about the actions.  I
do not think I am being unfair in that criticism. I also realize that Bind
9 was a group effort, and there is blame to spread among many.

However, I do not want to pay for that mistake. Nor do others.

> specification is almost nonexistent.

No. This isn't true either.  If we clarify AXFR to standardize the
_assumptions_ identically and concretely made by many implementors over a
long period of time, then BIND 9 will not be compliant**.  Bind 9 is
"compliant" only with the vague AXFR spec by invirtue of its vagueness.
AXFR should be clarified. I (and others) think it should be clarified to
follow the concrete assumptions made by many implementors over many years.
This will only make BIND 9 non-compliant.

Then 23% of the servers will have to change. 77% will be unaffected.
**Actually, it might not even be this bad, as I think there are some
"backwards compatibility" functionality that current Bind 9 users can
utilize. So perhaps no servers need changing if we standardize AXFR as I
propose. Except that Bind 9 will have to withdraw IXFR support until it
fixes it to work with AXFR as clarified, or make it synonomous with AXFR.

> authoritative servers of a zone.  They *should* be declared out of

No, because IXFR support is essentially optional. An IXFR server can
return the whole zone (AXFR) if it doesn't support IXFR.  A server can be
compliant with RFC 1995 just by making IXFR a synonym for AXFR. That's
probably a one line change for most if not all implementations. Further,
most people are not using IXFR.

AXFR is not optional. Most people are using AXFR.

> Again, BIND 9 is currently compliant.

Bind 9 won't be compliant (modulo its "backward compatibilty") after
clarification of AXFR to specify the commonly assumed and commonly
implemented behavior for AXFR.

> by you and Dr. Bernstein have gone too far.

I have made no allegations. My position on the issue of "conspiracy and
misconduct" is that allegations made against Dr. Bernstein need to be
investigated, and the allegations made by Dr.  Bernstein also need to
investigated.  I think the allegations made by both sides are sufficiently
specific that a determination can be made as to their truth.

There are many on the djbdiscuss list who seem to think the issue deserves
investigation. (I will try to get back to that matter next week, and work
with others to come to a conclusion about which accusations were credible
and which accusations weren't.)  Clearly, some of the allegations made go
way too far.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 14 Feb 2003 17:57:45 -0500 (EST)

As you note, they didn't conform to a BCP. There is no requirement (or
implication even) that one should conform to a Best Common Practice.
These serve to distribute helpful advice to the community and document
practices that have worked for others, in situations that may be
different.

The AXFR issue is compliance with a required standard, and its definition.
Much more serious concerns and issues are at stake.

		--Dean

On Fri, 14 Feb 2003 [email-masked] wrote:

> On Fri, 14 Feb 2003 13:48:09 EST, Dean Anderson said:
>
> Granted, it's only a BCP, but see RFC2505.  A large percentage of
> implementations were non-conforming to THAT too - but the situation has
> improved dramatically since then.  And note that there are more servers
> for *THAT* protocol, from more vendors, than for DNS.
>
>
> --
> 				Valdis Kletnieks
> 				Computer Systems Senior Engineer
> 				Virginia Tech
>
>

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 14 Feb 2003 18:38:51 -0500

> IXFR can be made to work with AXFR the way it stands.

"Can be made to work"? You mean, through some protocol clarification? If
clarifying *either* standard can effect interoperability, why give preference to
clarifying IXFR over clarifying AXFR? AXFR/IXFR interoperability issues aside,
AXFR was so poorly specified in the first place it seems to me a far better
candidate for clarification.

> long period of time, then BIND 9 will not be compliant

Funny, I thought the job of the IETF was to *lead* the development and
establishment of Internet standards. You seem to see their job as merely that of
a historian/archivist of whatever _de_facto_ standards implementors throw out
there, no matter how inefficient/convoluted/non-interoperable those _de_facto_
standards happen to be.

> AXFR is not optional. Most people are using AXFR.

Speaking as the architect of a large DNS infrastructure, AXFR is becoming less
and less feasible for us as time goes by, because of scaling issues. We need
IXFR ASAP, but we also need good interoperability between AXFR and IXFR because
it's not like we can migrate from one to the other overnight. IXFR may
technically be "optional" to implement, but in the real world, IXFR or something
like it, is quickly becoming a practical necessity. This is because of the
increasing size of zones and the frequency with which those zones are being
updated.

Dean, if you're willing to pony up the thousands of dollars we waste every year
because of inefficient zone transfers, then fine, we'll stick with AXFR
indefinitely. I can give you the address to which to mail the checks. But I'll
be damned if we continue to throw money down the toilet just because you and djb
and a handful of others want to maintain compatibility with some nebulous
_de_facto_ standard for AXFR.

- Kevin

---

From: [email-masked]
Date: Fri, 14 Feb 2003 17:34:24 -0500

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

---

From: Rob Austein <[email-masked]>
Date: Fri, 14 Feb 2003 19:11:40 -0500

> section you quote is so compelling.

Sorry, wrong.  Both JEEVES and CHIVES had very strict notions of zone
boundaries, and both enforced those boundaries during zone operations.

In CHIVES's case the implementation exactly matched the suggestion
that Andreas quoted from RFC 1035 6.1.2.  I no longer remember the
precise implementation details in JEEVES's case, but since JEEVES was
written by the author of RFC 1035, I would be rather surprised if the
author had not followed his own suggestion.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 14 Feb 2003 20:12:20 -0500 (EST)

On Fri, 14 Feb 2003, Kevin Darcy wrote:

> "Can be made to work"? You mean, through some protocol clarification?

No, I mean that AXFR can be clarified to reflect current implementations
except for Bind 9.  The IXFR specification doesn't need to be changed.
IXFR implementations can work with the "current" (non-bind9) AXFR.

> there, no matter how inefficient/convoluted/non-interoperable those _de_facto_

Not at all. However, in the present case, we are dealing with a standard
that was made many years ago, and there are now multiple, interoperable
implementations of it.  In this case, the role of the standards body
(IETF) is to mediate the dispute on the ambiguous language that was
written a long time ago.

The "defacto" standards are in fact interoperable. I and others would like
to keep it that way. The "convoluted/non-interoperable" part is Bind 9.

It is also the role of the standards body to suppress gratuitous changes,
which harm stability and interoperability.

> increasing size of zones and the frequency with which those zones are being

You don't need to change AXFR to implement IXFR any more than it was
necessary to change SQL to implement incremental replication in Oracle, or
Sybase, or DB2, or even the proprietary wire protocols (all different, but
equivalent) used by these engines.

Either version of AXFR is equivalent for the purpose of IXFR. In both
cases, a server gets the contents of the zone from another server. IXFR
just needs to make incremental modifications to the zone database. Oracle
does this. It requires no changes--its just PL/SQL scripts--though the
script language needs access to its own transaction log, and the ability
to make remote updates to the other DB. Did I mention that it didn't need
changes to Net 8 or SQL. This isn't rocket science. DNS servers have
equivalent capabilities through IXFR.  Thus, from a turing machine POV,
they can execute the same operations. Q.E.D.

> _de_facto_ standard for AXFR.

You can implement IXFR. No one is stopping you from doing that. You just
can't change AXFR. Nor do you need to change AXFR from how is implemented
in everything else except Bind 9.

If people are so dull that they can't figure how to implement IXFR, well,
perhaps they should use Ultradns or some other DNS server with a DB
backend and hire an oracle, sybase, or db2, etc consultant as preferred to
setup replication and forget about zone transfers altogether.  Any
commercial Database Engine (and some non-commercial, I think) will happily
do incremental update for you, using a plethora of proprietary but
equivalent wire protocols.

If bandwidth is such a concern (hard to imagine at $50/meg at high
levels)... But if you want to pay me, I'll redo the AXFR and IXFR
protocols using ASN.1. (I'm close to releasing a free ASN.1 compiler that
implements most of the TMF C++ API standard and the ASN1 ITU standards.).
Perhaps we can use unaligned PER, which will use a fraction of the
bandwidth (practically all bits are used). We'll even compress the PDUs.
Everyone has zlib, right? I'd guess we can reduce bandwidth to about 30%.
We'll call it AXFR/2 and IXFR/2.

Then we could update the resolvers to use aligned PER (not as efficient
but easier to encode and decode), we could probably save even more
bandwidth worldwide.

Not that I'm seriously proposing this--It would save some bandwidth, but
the deployment costs would outweigh any savings. ASN1 has advantages and
disadvantages, but we are now committed to protocols for DNS specified
years ago, and can't run off changing them gratuitously because we have a
new widget.

Of course, we certainly won't call an ASN1 proposal a "clarification".
Maybe "alternate protocol for AXFR and IXFR"

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 14 Feb 2003 20:34:22 -0500 (EST)

I think you misunderstood my message.  I meant to stress the fact that the
implementation details don't matter, but only the protocols matter. I'm
talking about modern implementations, such as Bind8, UltraDNS, etc. They
worked out interoperable assumptions on the meaning of AXFR that were
differnent than Bind 9.

		--Dean

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 14 Feb 2003 17:57:33 -0800 (PST)

Dean Anderson writes:
> Despite the "suggestion", all implementations prior to Bind 9
> made different (but ultimately identical) assumptions.

Rob Austein already pointed out JEEVES and CHIVES as counterexamples,
and before I worked on BIND, I wrote an authoritative-only server
which also used separate data structures for each zone.  When I
started working on BIND 9, the BIND 9 team had already independently
made the same design decision.  To both me and the BIND 9 team, it was
the obvious design, and the BIND 8 behavior was an obvious
implementation bug.

> This is nothing less than bad or lazy engineering.** As I
> idea".

If a version of Oracle had a bug that caused tuples to "leak" between
tables under certain conditions and the bug was only noticed when it
broke incremental replication, would you fix the bug or try to
redesign the replication protocol around the bug?  Would you do
differently if 77% of deployed Oracle servers had the bug?

> [more gratuitous insults that I'm not going to respond to]

> So perhaps no servers need changing if we standardize AXFR as I
> propose.

No servers will need changing if we standardize AXFR as I propose,
either.  There is no AXFR interoperability issue either way.  The
only difference (other than IXFR working better) is that a different
set of servers is declared non-compliant.
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Sat, 15 Feb 2003 02:51:56 +0000

> ... made the same design decision.  To both me and the BIND 9 team, it
> was the obvious design, and the BIND 8 behavior was an obvious
> implementation bug.

i just want to say, bind8's treatment of zone boundaries is terrible,
even though it's better in a dozen small ways than bind4's from which
it came.  my advice is, if you use bind, upgrade to bind9.

> set of servers is declared non-compliant.

agreed.  i am in strong support of the gustafsson axfr-clarify draft.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Feb 2003 03:22:36 -0000

It has become clear that the BIND company's ``AXFR clarifications'' are
never going to turn into an honest description of the AXFR protocol.

Consequently, for the sake of interoperability, I sat down after my last
message and wrote a web page saying how AXFR actually works:

   http://cr.yp.to/djbdns/axfr-notes.html

Comments are welcome from anyone who wants to help future implementors.
Comments are not welcome from people who are demanding (for commercial
reasons or for religious reasons) that most of the DNS servers on the
Internet be changed to imitate BIND 9.

---

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

Robert Elz writes:
> It prohibits some odd-ball techniques

You are talking about a draft disobeyed by MOST DNS SERVERS ON THE NET.
Please drop the loaded terminology.

> "Violating" 2119 is a nonsense concept.

RFC 2119, section 6: ``Imperatives of the type defined in this memo must
be used with care and sparingly.  In particular, they MUST only be used
where it is actually required for interoperation or to limit behavior
which has potential for causing harm (e.g., limiting retransmisssions)
For example, they must not be used to try to impose a particular method
on implementors where the method is not required for interoperability.''

Contrary to your claims, these are not mere ``recommendations.'' This
draft claims to be following RFC 2119, but blatantly violates RFC 2119,
by trying to impose BIND 9's private decisions on everyone else.

---

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

Andreas Gustafsson writes:
> To both me and the BIND 9 team, it was the obvious design, and the
> BIND 8 behavior was an obvious implementation bug.

To me, the djbdns cache structure is the obvious design, and BIND's
continuing tree-related cache performance problems---all of which are
visible to clients on the wire---are obvious implementation bugs.

Do you think I should write drafts specifying my cache structure,
falsely label those drafts as ``clarifications,'' and pay a bunch of
people to push those drafts through the IETF standardization process?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Feb 2003 04:29:44 -0000

bert hubert writes:
> Much of your criticism boils down to the fact that you do not have a
> zone concept and do not want to have one, where 1034 and 1035 simply
> ooze with zone definitions and they are clearly part of the DNS philosophy.

It's amazing how many errors you can pack into one paragraph. Facts:

   * My software has zones. It simplifies them for the user, by taking
     advantage of the RFC 1034 database-consistency requirements.

   * The relevant difference between my software and BIND 9 is that,
     when my software sees some of the RFC-1034-violating zones allowed
     by BIND 9, it boils them down to the RFC-1034-compliant parts.

   * BIND 8 does this to some extent too. It would sound pretty stupid
     of you to claim that BIND 8 doesn't ``have a zone concept,'' don't
     you think?

   * The BIND company's ``AXFR clarifications'' try to eliminate the
     RFC 1034 database-consistency requirements, allowing data for the
     same class+name+type to vary across zones, contrary to RFC 1034,
     sections 4.2.1 and 4.2.2.

Furthermore, this zone mismanagement is only one of many problems with
axfr-clarify.

If you decided to imitate BIND 9's database format in your software,
feel free---but stop trying to force me to do the same thing. It isn't
what my users want, and it's not necessary for interoperability.

  [ removing duplicates ]
> Yes, you could build sophisticated hashes & stuff

Learn to program: ``sort -u''.

As for your suggestion to shift this programming burden to the server:
You aren't thinking straight. There will be BIND 8 servers for the
foreseeable future, so you'll have to continue removing duplicates for
the foreseeable future. You'll be imposing a burden on servers without
removing it from clients. Silly.

> I do like to have the ability to add TSIGs to an AXFR in the additional

Again, you aren't thinking straight. Servers don't randomly use TSIG;
they use it _upon request_. Random use of TSIG has no benefits; it's a
pointless incompatibility, and there's no reason to allow it. (Besides,
IPSEC does a better job than TSIG.)

---

From: [email-masked]
Date: Sat, 15 Feb 2003 17:10:46 +1100

>      advantage of the RFC 1034 database-consistency requirements.

	Your software (and BIND 8) causes operational problems by not
	preserving zone contents.

	By incorrectly merging data from child zones you can prevent
	a master from sending correct data.  You can also prevent slaves
	from sending the correct information.  You require administators
	to worry about silly timing issues.  You require administators to
	detect when the timing was wrong and update the serial numbers
	on zones just to get it retransfered with the original information
	because the server couldn't keep the zone contents seperate.

	Senario 1.

	Server 1 master for example.com and slave for division.example.com.
	division.example.com has been updated on it master to have
	new delegation information, the zone has not yet refreshed
	on server 1 for some reason.  You receive email with the
	new delegation information.  You update example.com adjusting
	its serial.  You reload example.com.  You expect the new
	delegation to be advertised in the outgoing zone transfer.
	This doesn't happen because the server messed with the zone
	contents.

	Senario 2.

	Server 1 master example.com
	Server 2 master division.example.com
	Server 3 slave example.com and division.example.com
	Server 4 slave example.com using server 3 as a master.

	Server 2 the delgation infomation for division.example.com is
	update and the parent zone is informed.   Server 1 is updated
	to contain the new delegation information.  Server 3 receives
	the updated parent zone before the updated child zone and
	notifies Server 4 which transfers example.com WITH THE OLD
	DELEGATION INFORMATION.  Both masters were updated to have
	the new delegation information but it doesn't get distributed
	to all the servers.

	You want the IETF to believe that this is *correct* AXFR
	behaviour.  This doesn't pass the giggle test.
	
	This is a common implemention error caused by trying to
	stuff all zones into a common database.  BIND 4 got it
	wrong.  BIND 8 got it wrong.

	You want us all to keep repeating this mistake.

	All that is being asked is that the data in AXFR is preserved
	so that it can be used as the data source of another AXFR and
	as a dataset to which IXFR deltas can be applied.  If you want
	to merge the zones for non AXFR requests go ahead.

	In otherwords what is entered as the zone data is what is
	transmitted as the zone data.

	I was very much aware of this issue when I was working as
	a systems administrator for CSIRO years before I started
	working for ISC.  We had to make regular sweeps of the the
	CSIRO.AU heirarchy to detect and clean up the errors caused
	by nameservers incorrectly merging zone contents.  I got
	very tired of having to explain to all of the different
	system admins what the problem was and how to "fix it" by
	incrementing the serial number and getting the zone
	re-transfered.

	Mark

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

---

From: Doug Barton <[email-masked]>
Date: Fri, 14 Feb 2003 23:32:12 -0800 (PST)

> Complaining that RFCs are internally inconsistent should not stand in the

Isn't that why they need to be clarified? :)

-- 

    "The last time France wanted more evidence, it rolled right
        through Paris with a German flag." - David Letterman

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Feb 2003 14:55:33 +0700

Date:        Fri, 14 Feb 2003 15:34:55 +0100
    From:        Peter Koch <[email-masked]>
    Message-ID:  <[email-masked]>

  | Depends on how actively you'd like duplicates to be ignored. I'd read it
  | in a way that prohibits rejecting the incoming zone upon receipt of a
  | duplicate RR but also prohibits handing out these duplicate RRs (which
  | is in RFC 2181, section5, already) in responses.

This is what it has to mean - what matters is the external behaviour
of the server, not its internal implementation details.   How the server
chooses to go about ignoring the duplicates, if it receives any, is
entirely up to it - the effect when viewed from outside has to be that
the server gives the same responses whether it received an AXFR
containing duplicate RRs or whether those had been pruned by the server.

  | Also, it allows the slave, if also acting as a master (*),
  | (*) kre: this is why primary/secondary are not sufficient terms in the
  |     context of this document

No ... you could write that as

	Also, it allows the secondary, if also acting as a primary, ...

The problem here has always been that people's perception has always
been that a server simply *is* a primary or a secondary for a zone
(largely related to bind4's use of "primary" or "secondary" in its
named.boot file).

But that's nonsense - the terms make sense only when applied to a
particular AXFR (and now IXFR) transaction, and only ever did.

BIND8 (and  9) use the words "master" and "slave" in their named.conf
files in exactly the way BIND4 used "primary" and "secondary", so
it is likely that people (if not educated otherwise) will start to
regard a server as a "master" for a zone, or as a "slave" for a zone,
which would also be wrong.

The BIND config file would probablyt be better if it were using terms
like "load from file" or "load via AXFR" (or "load preferring IXFR")
to describe what it has traditionally used the terms primary/master or
secondary/slave to accomplish - what it is indicating is how this server
should fetch the zone, which relates to its role in at most one AXFR.
Unless prohibited by access controls, any server can be a primary for
an AXFR request, however it fetched the zone file.

Andreas Gustafsson <[email-masked]> said
in <[email-masked]>:

  | Robert Elz writes: 
  | > That related to some of the language in the draft I believe (I
  | > was there, and I think was one of those who supported this
  | > position).

  | Hmm, this seems a bit different from Randy's recollection.  But anyway... 

It is always hard in a brief WG discussion, especially one that takes
only minutes (if that), and relates to a comment from the floor, to
really be sure what was intended is the way it was interpreted.   All I
can say for sure is that I thought that the point related to this
(essentially bind inspired) use of master/slave (etc) (if you read 1034/5
you won't find the term "slave" anywhere - and "master" is mostly used
to refer to the file format, though there are a couple of what I regard
as "slips of the pen" ...)

It is entirely possible that Randy interpreted the comment differently.

  | These terms were defined in RFC1996 and are also used in RFC2136 [...]

Yes, I know.   If you query Paul about this, I'm sure he'll confirm that
he and I have been having a running battle about this ever since that time
(not frequently -- just whenever the topic arises).   When he first proposed
this new terminology I hadn't really thought through the arguments, and
it sounded like a good idea.   That didn't last very long...

  | I don't recall seeing any specific suggestions for changes, and I did
  | not attend the Yokohama meeting.  Could you please them to me or
  | namedroppers?

There were no specific changes requested.   This isn't important enough to
bother with.   As you point out, this new terminology exists in (a few)
other RFCs now, so it is no longer possible to be consistent with everything
out there (though I'd much prefer 1034/5 terminology be used than 1996).

If there's one thing I'd most like changed in this area, it would be that
you expunge all use of the term "primary master" which is utter nonsense.

The definition in 1996 is gibberish, it claims "There is by definition only
one primary master server per zone", while actually defining it to mean
"master server at the root of the zone transfer dependency graph" of which
there can easily be many (there can be several independent zone transfer
dependency graphs for the same zone - the master file can be created
independently at different servers, and transferred from them).   Doing
things this way makes Dynamic Update difficult (or impossible perhaps) but
dynamic update isn't required, it is an option that zones can choose not to
use.   Nothing in 1996 nor in axfr-clarify depends upon there being one
unique magic server for a zone.   (The SOA.MNAME field does of course, but
aside from the use imposed upon it by dynamic update, that's a useless
field, and there doesn't need to be a term (aside from SOA.MNAME) to
refer to the domain name it references).

But I'm not about to request even a delay in the processing of this doc
in order to worry about meaningless differences of opinion about irrelevant
terminology.   If there were to be a reason for you to send in a new
draft for other purposes, then by all means, fix this too if you feel
inclined.   Otherwise, it really doesn't matter - I'll try again with the
next draft that uses this terminology...

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Feb 2003 15:20:46 +0700

Date:        Fri, 14 Feb 2003 17:25:40 -0500 (EST)
    From:        Dean Anderson <[email-masked]>
    Message-ID:  <[email-masked]>

  | 
  | On Fri, 14 Feb 2003, Andreas Gustafsson wrote:
  | > RFC1035 specifically suggests using separate data structures
  | > that ensure that no such mixing occurs:
  | 
  | The key word is "suggests", which has the meaning...

exactly what you think it does - but note, the suggestion relates to
an implementation technique, which certainly isn't going to be required.
Implementors are free to implement however they desire, as long as they
achieve the objective.

Now ask yourself why 1035 would bother even suggesting an implementation
technique.

Don't you think it entirely possible that it is because the requirement
(that which was to be implemented) is so fundamental to the design of
the DNS, that some kind of suggestion of how to actually comply with the
design was worth making?

Implementation methods are often "suggested" in circumstances like that.
That is, when it seems plausible that implementors might miss an important
point and just do it the "easy way", it is common for the spec to indicate
how the implementation can achieve the desired result - this way implementors
either just blindly copy the suggestion, or at least should think about
why they're doing it a different way, and ask themselves if their results
will be the same as the suggested method.

  | No. This isn't true either.  If we clarify AXFR to standardize the
  | _assumptions_ identically and concretely made by many implementors over a
  | long period of time,

I can absolutely guarantee to you that that will never happen.  No-one is
going to standardise a protocol that essentially says "send whatever data
you feel like sending, and believe whatever the other end sends you
without question" which is exactly what the early implementations did.

When we standardise something, we want to first be as sure as we can be
that the protocol is correct for its purpose.  We aren't always very good
at that, but that should certainly be a major aim - documenting something
that doesn't work is a waste of everyone's time.   AXFR as it has been
commonly implemented simply doesn't work reliably.

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Feb 2003 15:38:45 +0700

Date:        15 Feb 2003 04:29:44 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  |    * The BIND company's ``AXFR clarifications'' try to eliminate the
  |      RFC 1034 database-consistency requirements, allowing data for the
  |      same class+name+type to vary across zones, contrary to RFC 1034,
  |      sections 4.2.1 and 4.2.2.

Most of your arguments aren't worth replying to.   This one looks like
it has merit on first glance.   But when examined closely it doesn't.

The database consistency requirements in 1034 *have* to be requirements
imposed upon the operators of the DNS, not the software, as there is
no mechanism in existence which allows the software to ensure this
consistency.

The issue here is "glue" records copied into a parent zone from a child.

If the parent and child are in the same server, the software is able to
ensure that the glue records in the parent are identical to what is in
the child zone - that's what early BIND software did, and I am guessing
that is what your server does.   From a naïve point of view, this looks
to be a good thing.

On the other hand, if the parent and child are operating in different
servers then there's nothing that causes the glue in the parent to be
the same as the records in the child - I have long wished that there
could be (by having the parent actually go query the child, repeatedly)
but for scaling and other reasons, it simply wouldn't work.

Now for your average query this turns out to not matter (which is how
BIND got away with being broken for so long) - a query to a server that
holds both zones will receive its answer using the data that is the child
zone (the zone that actually holds the record in question, or the nearest
parent of that) and so will (assuming the query requests it, one way or
another) get the data (which is glue in the parent) from the child zone.
A query addressed to a parent which doesn't also hold the child zone will
get the glue as added in the parent zone, unaffected by whatever might be
in the child.

Well - most of the time.   And this is where the problems arise, and why
AXFR is relevant to all of this.   If the server for only the parent
did a zone transfer from the server that is also a server for the child
zone, then (using the zone smashing style of earlier BIND) the transfer
it gets contains the records from the child zone, instead of what was
actually configured into the parent zone.

On the other hand, a different server for the parent zone alone, which
did its AXFR from a server that was configured with the parent zone data
and had never seen the child zone (or is a server configured manually
itself, with only the parent zone), would have only the configured glue.

Now we have two servers for the parent only, giving out different answers,
from the same zone, with the same serial number.   That's simply
unacceptable, and wrong, and always has been.   Early BIND had even worse
problems in this area, but they're not relevant here - except that I
certainly hope that no-one is going to come out of the woodwork and
say that because (10 years ago) 99% of the nameservers were running BIND4
that the DNS specs must be "clarified" to document the way that BIND4
worked ... which is the logical conclusion of some of the arguments that
are being made here.

Even ignoring any issues with doing incremental zone transfers, it is
important that a resolver be able to pick any of several different servers
for a zone, with confidence that it will receive the same answer (if it
receives an answer at all).  If the server selected also happens to be a
server for a child zone that would eventually need to be queried anyway,
that's fine, just avoids an extra query getting from parent to child.

But with incremental zone transfer it is essential that there is a well
defined version of what is the content of the zone, so that the clients
of those protocols can sanely apply updates - most particularly when the
server for the (incremental) transfer isn't one fixed system, but can
be any of several others.

That is, DNS database consistency is important, but (unless we were to ever
create some other method of ensuring it) it is the operators who have to 
make it happen - DNS software, at least using the DNS protocols as defined,
simply cannot, and more, must not, attempt to achieve this on the user's
behalf - doing so causes worse problems that not.

Tools to ensure that the parent domain has the correct glue, where glue
is needed, and to keep that correctly up to date when the child zone
makes changes would be a very worthwhile thing to create and make
available.    But they're not related to AXFR, which transfers one zone
from one server to another, and must do that without causing the zone
to change (perhaps as it is transferred along a chain of many servers).

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Feb 2003 11:09:46 -0000

> Server 1 master for example.com and slave for division.example.com.
  [ and division.example.com decides to change its NS records: ]
> You receive email with the new delegation information. You update
> example.com

Your hypothetical scenario breaks down here, for two reasons:

   (1) That configuration violates RFC 1034.
   (2) My software doesn't allow that configuration.

Consequently, your claims of failure have no connection to reality. The
situation simply doesn't occur. (What actually happens is that the NS
record is updated when the child zone is transferred, as it should be.)

In more detail:

   (1) RFC 1034, sections 4.2.1 and 4.2.2, make crystal clear that the
       NS record for division.example.com is supposed to be exactly the
       same in the example.com zone and the division.example.com zone.

   (2) When my software is handling both zones, it enforces the RFC 1034
       requirement, by unifying the data for the two zones. There isn't
       a division.example.com NS record in the example.com zone separate
       from the same NS record in the division.example.com zone.

I realize that, in BIND, there are two independent disk files with the
two zones, so it's possible to separately change the NS record in the
division.com zone. But that violates RFC 1034, and my software simply
doesn't allow it.

You're going to have to learn that the protocol is not defined by BIND's
implementation decisions. If you persist in viewing everything through
the language of BIND's configuration files, you're going to keep making
false claims about the behavior of other DNS software. I strongly
recommend that you read the specifications of the standard DNS protocol,
specifically RFC 1034 and RFC 1035, before you comment further.

---

From: [email-masked]
Date: Sat, 15 Feb 2003 23:39:12 +1100

>    (1) That configuration violates RFC 1034.

	It does not.

>    (2) My software doesn't allow that configuration.

	Well as we keep pointing out your software is BROKEN.
 
>        same in the example.com zone and the division.example.com zone.

	But the parent version *IS* a exact copy in both of the
	senarios given.  Just because it is not what is in the *old*
	copy of the child zone doesn't make it not a exact copy.

>        from the same NS record in the division.example.com zone.

	Which is a problem in your software as it is a problem in BIND4
	and BIND 8.

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 17 Feb 2003 13:48:23 +0000 (GMT)

> 	Well as we keep pointing out your software is BROKEN.

Saying it's broken implies the act of breakage.

At what point was the software NOT broken?

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 17 Feb 2003 13:02:05 -0500

>At what point was the software NOT broken?
"Broken" is a jargon term. In the context of software design, it denotes 
failure to conform to the relevant specifications.

                                            - Kevin

---

From: [email-masked]
Date: Tue, 18 Feb 2003 07:16:04 +1100

> At what point was the software NOT broken?

	In the original design specs.  RFC 1034 and RFC 1035.  If
	they had been followed then we wouldn't be havin this
	discussion.
 
	Mark

---

From: [email-masked]
Date: Mon, 17 Feb 2003 14:28:33 -0600

> 	preserving zone contents.
[...]
> 	Senario 1.

In order to understand your claim about the operational problems while
using djbdns, could you tell us how Scenario 1 is accomplished with
tinydns/axfrdns? Could you give us a URL pointing at a webpage that
contains the output of your experiments?

> 	You update example.com adjusting
> 	its serial.  

In particular, could you tell us what is the relevance of the serial
number to tinydns's update procedures?

> 	Senario 2.

[...]

> 	You want us all to keep repeating this mistake.

But I thought djbdns did _not_ get it wrong.  Or if you think it did,
could you show us the experiment that verifies the claim, that is, it
accomplishes Scenario 2 with tinydns/axfrdns servers?

Mate

---

From: [email-masked]
Date: Mon, 17 Feb 2003 14:43:52 -0600

> 	Well as we keep pointing out your software is BROKEN.

The problem is that I see this claim over and over, but I have not
seen an actual experiment showing the broken behavior.  Why is that?

> 	Which is a problem in your software as it is a problem in BIND4

Here is how the above sounds 

--- Software S enforces a certain rfc 1034 behavior.

--- Then the software has a problem.

Is this logic intentional?

---

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 17 Feb 2003 16:40:07 -0500

>Is this logic intentional?
False syllogism. RFC 1034 requires matching NS record sets in the parent 
and the child, but this cannot be *guaranteed* (even if administrators 
were perfect, there can be propagation delays when the record sets are 
changed). BIND 9 recognizes the possibility of a mismatch and deals with 
it reasonably (IMO) by respecting the disparity between the record sets. 
djbdns's approach, on the other hand, is to shut its eyes, put its 
fingers in its ears, and scream "la! la! la! this can't be happening! 
la! la! la!" and generate problematic zone transfers.

Behold what happens when protocol implementation is left in the hands of 
mathematicians...

The appropriate pseudo-syllogism, if any, is:

Software D assumes that a particular RFC 1034 requirement R is always met

R is sometimes not met

=> Software D's assumption is sometimes false

Corollary: as is often the case, when an algorithm makes a false 
assumption, it generates incorrect results. Such is the case with 
Software D in those instances when its assumption about requirement R 
does not hold true.

                                        - Kevin

---

From: [email-masked]
Date: Mon, 17 Feb 2003 17:32:58 -0600

On Mon, Feb 17, 2003 at 04:40:07PM -0500, Kevin Darcy wrote:
> False syllogism. 

I do not get it: DJB says, his software meets some RFC 1034
requirement, and MA says then DJB's software has a problem.  How can
you read the above conversation differently?  How can you read more
into what Mark is saying, when it is not there?

The fundamental problem is that I see all these claims, and no actual
verifications.  I start to think that none of the people criticizing
djbdns ever run its servers and/or used its clients.

In case you think this is irrelevant: people keep dismissing proposals
and criticisms by saying it is just relevant to the single broken
implementation by a mathematician.  How can this be acceptable when it
comes to creating rfc's?  Is this done in the users' future and
present best interest?  Is this done in the interest of objectivity
and coherence?

> RFC 1034 requires matching NS record sets in the parent 

Again, could you show me the actual experiment when either of Mark's
two Scenarios happen with djbdns?  This cannot be too difficult given
the enormous brokenness of the software.

Mate
---

---

From: Aaron Swartz <[email-masked]>
Date: Mon, 17 Feb 2003 17:31:51 -0600

Kevin Darcy wrote:
> the thousands of dollars we waste every year because of inefficient 
> zone transfers

If you're serious, then you should switch to gzipped rsync immediately. 
I bet you'll save far more than you will with IXFR. I'm sure you can 
find someone who will set it up for you in return for thousands of 
dollars.

-- 
Aaron Swartz [http://www.aaronsw.com/]

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 17 Feb 2003 19:03:31 -0500

Aaron Swartz wrote:

> If you're serious, then you should switch to gzipped rsync 
> immediately. I bet you'll save far more than you will with IXFR. I'm 
> sure you can find someone who will set it up for you in return for 
> thousands of dollars. 

If I were the conspiratorial sort, I'd probably start raving at this 
point about how "the DJB company" was forcing me to use gzip and/or 
rsync by making AXFR and IXFR incompatible with each other...

But, fortunately, I'm _not_ the conspiratorial sort.

I just want AXFR and IXFR to be compatible. And I don't think DJB's poor 
design decisions should stand in the way of that.

                                                - Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 17 Feb 2003 19:25:14 -0500

>into what Mark is saying, when it is not there?
There's a big difference between a piece of software meeting a 
data-structure requirement, and a piece of software assuming that 
*every* administrator in the world *always* meets a particular 
*operational* requirement, and that all replication is instantaneous. 
Remember "liberal in what you accept, conservative in what you generate".

It's like the difference between publishing a bus schedule, on the one 
hand, and, on the other, staking your life on the presence of a bus at a 
particular bus stop at a particular time. The former might be reasonable 
(if it's based on real-world data about how buses proceed through the 
relevant routes); the latter is totally foolish.

>djbdns ever run its servers and/or used its clients.
Well, I think that's mainly because the aberrant behavior of djbdns has 
been hashed out here many times previously, and most folks are sick and 
tired of hearing djb's convoluted rationalizations for it.

>comes to creating rfc's?  
The *proposal* is to clarify AXFR, and it is DJB that is "dismissing" 
it, mostly on the basis that he doesn't want to have to change his 
software to conform to the newly-clarified spec.

As for my comment about mathematicians, sorry if you were offended, but 
the incredibly idealistic assumption embedded in djbdns struck me as 
being singularly representative of the "assume a perfect world" 
stereotype that mathematicians get plastered with regularly.

I'll note that the "E" in IETF stands for "Engineering". Engineers have 
a slightly better reputation for dealing with real-world challenges.

>Is this done in the users' future and
>present best interest?  
>
Yes. Thanks for asking.

>Is this done in the interest of objectivity
>and coherence?
>
Yes. Thanks for asking.

                    - Kevin

---

From: [email-masked]
Date: Tue, 18 Feb 2003 13:27:28 +1100

> Mate Wierdl | Dept. of Math. Sciences | University of Memphis  

	It's easy enough to demonstate.  The master server is 10.53.0.2.
	10.53.0.1 is dbj's software.   I used the FreeBSD port system to
	install it.

djbdns-1.05_2       A collection of secure and reliable DNS tools

tcpclient 10.53.0.2 53 axfr-get child.example.net zone.child.example.net zone.child.example.net.tmp
tcpclient 10.53.0.2 53 axfr-get example.net zone.example.net zone.example.net.tmp
sort -u zone.* > data
make

	You will note that it actually *merges* the records.
	ns2.child.example.net doesn't exist due to a typo in
	child.example.net.  I was taking Dan's word that it
	took the child data.

	Merges are just as bad as taking data just from the child
	zone.  In both cases slaves off 10.53.0.1 will be left with
	data that was not in the original master files.

	I presume for a real world server that you would need to
	call tcpclient periodically and remake data if the zone
	files have changed.   It looks like they axfr-get is
	designed to be called independently of the database make.

	I suspect no-one would run tinydns in the senarios described.
	It's designed for a collection of servers that all serve a
	identical set of zones from a single master.  Trying to use
	it in any other configuration is just cumbersome.  There
	really is no incoming zone maintanence.  You have to roll
	your own from what I can see.  axfr-get will check the
	serial but that is far short of full zone maintenance.
	axfr-get get need to be called with the right periodicity.

	Mark

; <<>> DiG 9.3.0s20021115 <<>> axfr child.example.net @10.53.0.2
;; global options:  printcmd
child.example.net.	10	IN	SOA	. . 1 3600 1200 360000 10
child.example.net.	10	IN	NS	ns1.child.example.net.
child.example.net.	10	IN	NS	ns2.child.example.net.
ns1.child.example.net.	10	IN	A	10.53.0.1
ns1.child.example.net.	10	IN	A	10.53.0.2
child.example.net.	10	IN	SOA	. . 1 3600 1200 360000 10
;; Query time: 43 msec
;; SERVER: 10.53.0.2#53(10.53.0.2)
;; WHEN: Tue Feb 18 11:50:46 2003
;; XFR size: 7 records (messages 1)

; <<>> DiG 9.3.0s20021115 <<>> axfr child.example.net @10.53.0.1
;; global options:  printcmd
child.example.net.	10	IN	SOA	. . 1 3600 1200 360000 10
child.example.net.	10	IN	NS	ns1.child.example.net.
child.example.net.	10	IN	NS	ns2.child.example.net.
ns1.child.example.net.	10	IN	A	10.53.0.1
ns1.child.example.net.	10	IN	A	10.53.0.2
ns2.child.example.net.	10	IN	A	10.53.0.2
child.example.net.	10	IN	SOA	. . 1 3600 1200 360000 10
;; Query time: 5 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Feb 18 11:51:02 2003
;; XFR size: 8 records (messages 7)

; <<>> DiG 9.3.0s20021115 <<>> axfr example.net @10.53.0.2
;; global options:  printcmd
example.net.		10	IN	SOA	. . 1 3600 1200 360000 10
example.net.		10	IN	NS	ns1.example.net.
example.net.		10	IN	NS	ns2.example.net.
child.example.net.	10	IN	NS	ns1.child.example.net.
child.example.net.	10	IN	NS	ns2.child.example.net.
ns1.child.example.net.	10	IN	A	10.53.0.1
ns2.child.example.net.	10	IN	A	10.53.0.2
ns1.example.net.	10	IN	A	10.53.0.1
ns2.example.net.	10	IN	A	10.53.0.2
example.net.		10	IN	SOA	. . 1 3600 1200 360000 10
;; Query time: 3 msec
;; SERVER: 10.53.0.2#53(10.53.0.2)
;; WHEN: Tue Feb 18 11:52:04 2003
;; XFR size: 11 records (messages 1)

; <<>> DiG 9.3.0s20021115 <<>> axfr example.net @10.53.0.1
;; global options:  printcmd
example.net.		10	IN	SOA	. . 1 3600 1200 360000 10
child.example.net.	10	IN	NS	ns1.child.example.net.
child.example.net.	10	IN	NS	ns2.child.example.net.
example.net.		10	IN	NS	ns1.example.net.
example.net.		10	IN	NS	ns2.example.net.
ns1.child.example.net.	10	IN	A	10.53.0.1
ns1.child.example.net.	10	IN	A	10.53.0.2
ns1.example.net.	10	IN	A	10.53.0.1
ns2.child.example.net.	10	IN	A	10.53.0.2
ns2.example.net.	10	IN	A	10.53.0.2
example.net.		10	IN	SOA	. . 1 3600 1200 360000 10
;; Query time: 5 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Feb 18 11:51:30 2003
;; XFR size: 12 records (messages 11)

; <<>> DiG 9.3.0s20021115 <<>> ns child.example.net @10.53.0.1
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56624
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;child.example.net.		IN	NS

;; ANSWER SECTION:
child.example.net.	10	IN	NS	ns1.child.example.net.
child.example.net.	10	IN	NS	ns2.child.example.net.

;; ADDITIONAL SECTION:
ns1.child.example.net.	10	IN	A	10.53.0.1
ns1.child.example.net.	10	IN	A	10.53.0.2
ns2.child.example.net.	10	IN	A	10.53.0.2

;; Query time: 1 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Feb 18 12:11:45 2003
;; MSG SIZE  rcvd: 119

; <<>> DiG 9.3.0s20021115 <<>> ns child.example.net @10.53.0.2
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12751
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;child.example.net.		IN	NS

;; ANSWER SECTION:
child.example.net.	10	IN	NS	ns2.child.example.net.
child.example.net.	10	IN	NS	ns1.child.example.net.

;; ADDITIONAL SECTION:
ns1.child.example.net.	10	IN	A	10.53.0.1
ns1.child.example.net.	10	IN	A	10.53.0.2

;; Query time: 1 msec
;; SERVER: 10.53.0.2#53(10.53.0.2)
;; WHEN: Tue Feb 18 12:12:02 2003
;; MSG SIZE  rcvd: 103

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 18 Feb 2003 10:19:19 +0100

> Much more serious concerns and issues are at stake.

Note: The IETF has never made *any* standard that the IETF required people 
to conform to, unless they wanted to truthfully claim conformance to that 
standard.
At one point in time it made sense to say that "to be an Internet device, 
you have to conform to this set of standards"; currently, the ways in which 
IETF standards depend on each other are complex enough that this doesn't 
make much sense any more.

As a result, the distinction between "Elective", "Recommended" and 
"Required" protocols has largely fallen into disuse; RFC 2400 was the last 
version of the Official Protocol Standards document that even bothered to 
list them - the current version is RFC 3300.

At the time of RFC 2400, the set of Required standards were:

--------   Internet Official Protocol Standards      Req      2400   1
--------   Assigned Numbers                          Req      1700   2
--------   Host Requirements - Communications        Req      1122   3
--------   Host Requirements - Applications          Req      1123   3
IP         Internet Protocol                         Req       791   5
--------     IP Subnet Extension                     Req       950   5
--------     IP Broadcast Datagrams                  Req       919   5
--------     IP Broadcast Datagrams with Subnets     Req       922   5
ICMP       Internet Control Message Protocol         Req       792   5

Here is the status of the DNS standards in that document:

DOMAIN     Domain Name System                        Rec 1034,1035  13
DNS-MX     Mail Routing and the Domain System        Rec       974  14

axfr-clarify will have to enter the process as a Proposed Standard.
Both Proposed Standards and BCPs are encouraging people to do things a 
certain way; if anything, I consider a BCP slightly more forceful.

                  Harald Alvestrand

---

From: Alexis Yushin <[email-masked]>
Date: Tue, 18 Feb 2003 10:48:36 +0100 (CET)

>djbdns ever run its servers and/or used its clients.

Why would they even try after seeing his posts? I certainly wouldn't
as the author comes across as unprofessional, biased and difficult
(next to impossible) to deal with.

Alexis

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 17 Feb 2003 20:36:29 +0000 (GMT)

> 	they had been followed then we wouldn't be havin this

original design specs != "your software".

Are you claiming that djb's djbdns software was incorrectly
implemented? Please be clear, for Dan "we're all suffering because of
a few inconsiderate people" Bernstein's benefit -- and ultimately our
benefit, too.

L.

---

From: Josh Littlefield <[email-masked]>
Date: Tue, 18 Feb 2003 17:07:46 -0500

I'd like to make clear my support for draft-ietf-dnsext-axfr-clarify-05. 
With the exception of a single subtle enhancement (the specification of 
returning NOTAUTH to an AXFR request about a zone for which the server is 
not authoritative), I find that the specification correctly matches my own 
interpretation of RFC1034 and RFC1035 and first-hand interoperability 
experience.

Regarding zone integrity, I find the specification supports the clear 
requirements for the independence of zone data described in RFC1034 
(sections 4.1 and 4.2), along with the practical need to ensure that all 
authoritative servers for a zone will have an accurate copy of the data for 
that zone for a given serial number (RFC1034, Sect. 4.3.5).

As for the requirement to carry zone transfer RRs in the answer section, 
this is a completely obvious application of the rules governing all 
responses to requests with opcode QUERY (0).  RFC1034 clearly states that 
the answer section "carries RRs which directly answer the query."  I don't 
see how anyone could conclude that AXFR clients should look for zone RRs 
anywhere else.

I implemented AXFR in 1997 on a server architected to clearly differentiate 
each zone's data, as specified (according to my reading) in RFC1034.  The 
axfr-clarify draft is consistent with that implementation, whose basic 
architecture has not changed.  This made the implementation of RFC1995 
relatively trivial, because the consistency of the baseline AXFR allows the 
unambiguous communication of incremental changes to that baseline, even if 
the AXFR has been retrieved from one authority, and the IXFR from another, 
and regardless of what other zones those servers may know about.

Regards,
  Josh Littlefield
-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                                      250 Apollo Drive
tel: 978-497-8378  fax: same               Chelmsford, MA  01824-3627

---

From: Dean Anderson <[email-masked]>
Date: Tue, 18 Feb 2003 18:10:36 -0500 (EST)

> design decisions should stand in the way of that.

DJB's decisions don't stand in the way of that. Just the opposite.

Bind 9 broke AXFR, due to bad programming, bad management, and lazy
engineering.  Now, instead of admitting the mistakes, they want to change
AXFR, and are trying (lamely, I might add) to say that AXFR MUST be
changed to support IXFR.

AXFR has NOTHING WHATSOEVER to do with IXFR.  This is a simple proof, the
outlines of which I have already given.

		--Dean

---

From: [email-masked]
Date: Tue, 18 Feb 2003 13:32:27 -0500

> At what point was the software NOT broken?

It's quite conceivable the software was BAD (Broken As Designed).

It's pretty clear to me that either djbdns or BIND was BAD. I'm just not
sure which.. :)

http://www.catb.org/~esr/jargon/html/entry/BAD.html

---

From: Dean Anderson <[email-masked]>
Date: Tue, 18 Feb 2003 18:46:19 -0500 (EST)

Good. You found a bug in an implementation. I thought such things were
off-topic for this list.  This bug doesn't mean that AXFR is broken.
Bind 8 did not have this bug, yet it has the common understanding of AXFR.

Let me summarize the discussion:

Everyone agrees that AXFR specification in RFC 1034 is ambiguous.

Some people, many associated with Bind 9 development, assert that it is
necessary to change AXFR to support IXFR.  This assertion has been refuted
on the grounds that incremental database update does not depend on AXFR,
since incremental database update does not depend on the underlying wire
protocol used to create the remote database which is to be modified by
IXFR. Conceivably, it is unnecessary to use AXFR at all, yet one could
still use IXFR, so, AXFR is independent of IXFR.

Some people, many associated with Bind 9 development, assert that AXFR as
commonly implemented by many implementors over many years, is broken, and
can't transfer domains correctly.  This claim has been refuted by
demonstration by interoperability between Bind 8 and other nameserver
implementations over the years, and 77% of the internet that currently
does not use Bind 9, yet still does AXFR.

There being no other arguments raised for the Bind 9 AXFR
clarify/modification proposal, it seems that this proposal is gratuitous
and unnecessary, and should be rejected.

However, we still have the issue of AXFR ambiguity to deal with, and we
still need to clarify those ambiguities.  I would therefore like to
organize a small group of people using implementations other than Bind 9,
which we declare to be broken, to document the common implementation
assumptions made, and submit that as a clarification to RFC 1034

To prevent confusion between the two proposals, I would like to rename the
first proposal "Bind 9 AXFR Modification", and the second proposal "AXFR
Clarification". The term "axfr-clarify" will not be used.

		--Dean

---

From: [email-masked]
Date: Wed, 19 Feb 2003 11:54:30 +1100

> still use IXFR, so, AXFR is independent of IXFR.

	Nobody is saying that preserving zone content is a *wire*
	issue.  It is a server behaviour issue.

> does not use Bind 9, yet still does AXFR.

	All this shows is that these nameservers are not used in
	situations where the breakage is demonstrated or the
	administators have learn to work around the breakage or
	choose to live with it or are unaware of it.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 18 Feb 2003 20:58:55 -0500 (EST)

> 	issue.  It is a server behaviour issue.

Zone definition and content is not an AXFR issue.  Server administrators
provide the definition of zone boundaries. (RFC 1034 Section 2.3 and
elsewhere)  AXFR merely gives the contents of the zone as has been defined
according to the boundaries and content specified by the administrator.
The contents could be given to the secondary by FTP or other method.  If
you mean to change the definition of zone contents, then I would say this
proposal is hugely mis-labeled.

All the IXFR server needs to do is determine (by some implementation
dependent, administrator maintained method) what has changed between one
zone version and another. How it does this is nobody's business but the
administrator and the implementor. There are infinite possibilities, here.
One could, for example, store differences in a series of files. The
administrator could even make the differnce files by hand--this is an
_implementation detail_. The IXFR server just sends a series or sequences
consisting of a list of deleted RRs and a list of added RRs to an IXFR
client. There is nothing more to it. (notwithstanding the optional
condensation.)

The IXFR client must simply make the changes (again, by some
implementation dependent, administrator maintained method) to the zone by
deleting RRs and adding RR's in each sequence. The original version of the
zone might have been obtained by FTP (or quantum interference, or the
psychic network) for all we know.

This isn't rocket science, and doesn't require any AXFR changes. Nor does
it require that the zone boundaries be defined only in some certain way,
beyond the definition of zone boundaries given by the system
administrator.

> 	choose to live with it or are unaware of it.

"administrators have learn[ed] to work around [it,...] live with it [,] or
are unaware of it".  Agreed.  Having done so, we don't want to stir the
pot.

Essentially, you are putting more (unnecessary) constraints on
implementations, and thus on the administrators, who are supposed to be
pretty free to define the zone boundaries.  Of course, the specifics of an
implementation puts some constraints on the adminstrator, but the
administrator can choose a different implementation more to her liking.

These unnecessary constraints are a "bad thing".

> > Clarification". The term "axfr-clarify" will not be used.

I presume agreement on the name change?

		--Dean

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 18 Feb 2003 18:51:58 -0800 (PST)

> according to the boundaries and content specified by the administrator.

This is exactly what the draft says, so what are you disagreeing with?

The issue with BIND 8 is that it does *not* give the contents of the
zone according to the boundaries and content specified by the zone
administrator, but instead a mixture of data from different zones as
specified by their different administrators.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Wed, 19 Feb 2003 14:42:22 +1100

> according to the boundaries and content specified by the administrator.

	Well BIND 9 does this.  CISCO's server does this according
	to John.  BIND 8 doesn't always.  BIND 4 doesn't always.
	DJBDNS doesn't always.  This is independent of the method
	used to transfer the zone to these servers or enter the
	zone contents on these servers.

> proposal is hugely mis-labeled.

	It's not changing the definition.  It is preserving the
	definition.

	It's not mis-labeled.  It is stating the implict assumption
	that AXFR transfers what is entered as the zones contents.
	Nothing more, nothing less.

> client. There is nothing more to it. (notwithstanding the optional

	All of which is irrelevent to this issue.

> psychic network) for all we know.

	Well the problem is that you have to get the *original* version,
	not a corrupted version.  AXFR implementations are not returning
	the data originally entered.
 
> beyond the definition of zone boundaries given by the system

	It does however require that for a given serial number that all
	sources of the zone have supplied identical contents.  You should
	be able to apply a IXFR delta to a copy derived from any source
	and have it apply without error.
 
> are unaware of it".  Agreed.  Having done so, we don't want to stir the

	LOL.
 
> administrator can choose a different implementation more to her liking.

	The constaint was already there and it is necessary for reliable
	operation of the DNS.
 
> I presume agreement on the name change?

	No.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Feb 2003 05:44:54 -0000

Kevin Darcy writes:
> and the child, but this cannot be *guaranteed*

In the situation under discussion, one server has both zones, so that
server _can_ guarantee RFC 1034 consistency---and my server _does_.
(BIND 8 also does, to some extent. BIND 9 doesn't.)

Andrews says that this RFC 1034 enforcement causes problems for a system
administrator who tries to violate RFC 1034. Well, that's too damn bad!
The system administrator shouldn't be trying to violate RFC 1034.

If the BIND company wants the RFC 1034 rule changed, they can propose
that, and we'll discuss the costs and benefits. Instead they're trying
to slip the change past us as a ``clarification.'' You know they're
lying; why are you condoning dishonest behavior?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Feb 2003 06:30:22 -0000

> ; <<>> DiG 9.3.0s20021115 <<>> axfr child.example.net @10.53.0.2
  [ claims that ns2.child.example.net doesn't exist, as compared to: ]
> ns2.child.example.net.	10	IN	A	10.53.0.2

Once again: That configuration violates RFC 1034. Specifically, sections
4.2.1 and 4.2.2 of RFC 1034 make crystal clear that the ns2 glue in the
parent zone is supposed to match the data in the child zone.

My software enforces the RFC 1034 requirement in this situation. If it
had been running on 10.53.0.2 then you wouldn't have been able to screw
up the configuration in the first place.

What you're complaining about is my software's perfectly straightforward
enforcement of the RFC 1034 requirement on the client side after you set
up an RFC-1034-violating configuration with your server. Is it really so
difficult to understand that it's your fault for violating RFC 1034?

  [ complaining about zone transfers in tinydns ]
> You have to roll your own from what I can see.

No, you don't. Have you ever heard of ``third parties''? How about
``interchangeable parts''? Monolithic design is good for a company
trying to achieve lock-in, but modular design leads to faster evolution
and, in the end, better software for the users.

If you're trying to say that I haven't bothered to write up the existing
AXFR tools on my web pages, you're right. These tools have an extremely
limited audience; I have better things to do. The vast majority of users
are much happier with rsync+ssh than they would ever be with anything
based on AXFR. See http://cr.yp.to/djbdns/tcp.html#intro-axfr.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Feb 2003 06:58:22 -0000

Josh Littlefield writes:
> RFC1034 clearly states that the answer section "carries RRs which
> directly answer the query."  I don't see how anyone could conclude
> that AXFR clients should look for zone RRs anywhere else.

There is overwhelming consensus that (in the absence of extended
behavior requested by the client) the AXFR _server_ must leave the
additional section and authority section empty. It must put the data
into the answer section. All existing servers work this way---and must
do so for interoperability.

There are several perfectly valid parsing strategies for the client.
In particular, my software uses the simple strategy

   while there are records left
      read a record

while BIND 9 uses the slightly more complicated strategy

   while there are records left in the answer section
      read a record

Both strategies work, since servers put all records into the answer
section. Neither strategy creates any interoperability problems.

There is certainly _not_ consensus on telling the _client_ to use the
BIND 9 strategy. Furthermore, any such statement (whether ``MUST'' or
``SHOULD'') would blatantly violate RFC 2119, section 6.

This is about the tenth time that I have had to point out the blazingly
obvious fact that constraining _server_ behavior is not the same as
constraining _client_ behavior.

---

From: Kandra Nygårds <[email-masked]>
Date: Wed, 19 Feb 2003 08:13:35 +0100

> parent zone is supposed to match the data in the child zone.

Excellent point. Now for a real-world example: Many ccTLDs (and RIRs, such
as RIPE) require automated or manual checks before a delegation [change] is
approved by the TLD Registry. Prior to requesting a change of delegation,
the zone administrator changes the zone data. This of course violates RFC
1034, specifically sections 4.2.1 and 4.2.2.

Please tell me, how is one to accomplish this without breaking RFC1034
sections 4.2.1 and 4.2.2?

Or perhaps there are places where some (temporary) RFC1034 breakage is not
only warranted but to be expected from time to time?

> up the configuration in the first place.

If it prevents me from breaking my zones without breaking anything else,
that's a good thing. Unfortunately, it also changes the content of the
zones, which does break something else. This is an interoperability issue,
and a potentially problematic one.

> difficult to understand that it's your fault for violating RFC 1034?

The reason for violating RFC1034 could be as simple as propragation delay.
If timing issues interfere with routine zone updates, it's an implementation
bug. The reason could also be a temporary intentional change. If your
software breaks intentional changes, it's an implementation bug.

Face it, you do not live in a perfect world, where you (as a single
administrator) can control everything. Delays - human or machine - in
propragating information is a reality. If your software can't cope with
that, it's an implementation bug. And, it's no good to claim that it
wouldn't have broken if everyone had just used YOUR software. If it breaks,
it's a bug.

> based on AXFR. See http://cr.yp.to/djbdns/tcp.html#intro-axfr.

...and, if your software can't interoperate with other software properly,
it's an [   insert here   ] bug?

Best regards,
Kandra Nygards

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Feb 2003 16:42:23 +0700

Date:        19 Feb 2003 05:44:54 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | In the situation under discussion, one server has both zones, so that
  | server _can_ guarantee RFC 1034 consistency---and my server _does_.
  | (BIND 8 also does, to some extent. BIND 9 doesn't.)

There are two requirements (in this general area) on servers in the DNS.
One is that two servers for the same zone give the same answers to the
same questions (except in the interval between an update to one server
and its being made known to the other, during which time the SOA serial
numbers will differ).   (AXFR is one such possible question).

Second, glue records should be copied from the authoritative zone to the
parent, so they are the same in both zones.   Again, there is necessarily
going to sometimes be a delay between when the child zone is updated and
when the parent is updated.

Your reading of the requirements means that in order to shorten the
delay in the second case, in some circumstances, you're willing to generate
cases where the first incompatibility (servers for the same zone returning
different answers) will exist, without the serial numbers differing (and
with no defined method of reconciling the issue - that is, there is no
way of knowing which answer is the "correct" one).

In the parent/child case, if there is a difference, the child's answers are
correct by definition.   In the "different zones after an update" case, the
server with the higher serial number is correct, the lower is out of date.
In the case we have been discussing, the answers differ, both servers are
serving the same zone, the serial numbers are the same, which answer should
be used?   How can anyone guess?

Just about everyone here seems to be convinced that the (negligible) gain
to be gained from forcing the parent and child to contain the same records
in the cases where that is feasible is not worth the kind of problems this
can cause to the first requirement (which in hard cases can actually be
difficult to fix without manual intervention - it won't always just "fix
itself" though normal correct operation of the servers).   The requirements
you're insisting upon enforcing in your servers trivially fix themselves
when the parent zone is updated (remember you assume that if the human
doesn't do that, any problems are of their own making...)

If you have a proposal for some method to actually cause the parent/child
delegation to *always* be compatible (glue in parent matches records in child,
always), then please don't keep it a secret, I'd really like to see it.

Until then, assuming that this will always be true, and writing off all
other cases as "configuration error, anything is allowed to happen" is
inappropriate.

kre

---

From: [email-masked]
Date: Thu, 20 Feb 2003 00:38:12 +1100

>    while there are records left

	Which can only be found by adding up the three fields in
	the header (number of answer  records (which bind uses),
	number of records in the authority section and number of
	records in the additional section).  You can't use the DNS
	message length as too many implementations get it wrong and
	leave a couple of bytes between the end of the messages as
	discovered by processing the records and the end of the
	data that is read.  You have discovered this havn't you?
 
> while BIND 9 uses the slightly more complicated strategy

	BIND has always used the simple strategy of reading the
	number from the header then processing that number of
	records after skipping any questions, again read from
	the header.
 
>    while there are records left in the answer section

	Let me see if I have your logic right,
	
	Simple:
	Read the number of questions then skip them. Read three
	numbers, add them up, then read this number of records.
	
	Complicated:
	Read the number of questions then skip them. Read one
	number then read this number of records.

	I think you have the labels the wrong way around.

> section. Neither strategy creates any interoperability problems.

	There is different behaviour.  That is enough reason in and
	of itself to clarify the issue.

	I don't think anyone envisioned someone that would process
	records outside of the answer section as answers.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Feb 2003 17:50:37 -0000

[email-masked] writes:
> You can't use the DNS message length as too many implementations get
> it wrong and leave a couple of bytes between the end of the messages
> as discovered by processing the records and the end of the data that
> is read.

False. The Microsoft AXFR _client_ puts two extra bytes after its AXFR
requests to indicate its support for multiple records per DNS packet,
but the Microsoft AXFR _server_ does nothing of the sort. My AXFR client
can and does use the packet length, in full compliance with RFC 1035.
There are no interoperability problems here.

(By the way, my DNS software is more widely deployed than Microsoft's,
and much more stable, so if there were an interoperability problem then
the lowest-cost solution would be to redeploy Microsoft's software. But
these problems are a figment of your imagination.)

> of itself to clarify the issue.

False premise, bad logic, false conclusion. These software differences
don't affect interoperability, so they are none of the IETF's business.
See RFC 2119, section 6.

> records outside of the answer section as answers.

Read the full DNS standards, RFC 1034 and RFC 1035. Example: To save
time, the additional section of an MX response usually contains A
records that are reported as answers to subsequent queries. This is
perfectly standard behavior not only in theory but also in practice.

(To the extent that proposed standard RFC 2181 suggests otherwise, RFC
2181 is out of whack with reality, and RFC 2181 will have to be fixed.)

You can't seriously promote a ``never treat additional records as
answers'' religion when every major DNS cache---including BIND 9---
blatantly violates that religion. If you start adding qualifiers such as
``except in MX queries'' then your religion starts to sound really dumb.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Feb 2003 19:01:24 -0000

Robert Elz writes:
> delegation to *always* be compatible (glue in parent matches records in
> child, always), then please don't keep it a secret

Read about timestamps in http://cr.yp.to/djbdns/tinydns-data.html. It's
not my fault that BIND can't handle this trivial synchronization.

If you're trying to say that the RFC 1034 requirement should be loosened
to allow semi-synchronized changes (parent zone is changed after all the
child servers have changed), go ahead and make that proposal in DNSEXT,
and we'll discuss it. But don't try to sneak it past us as part of an
``AXFR clarification.''

---

From: Kandra Nygårds <[email-masked]>
Date: Wed, 19 Feb 2003 21:14:49 +0100

> perfectly standard behavior not only in theory but also in practice.

The query is for MX. The answer section contains MX, which is correct. The
response usually contains one or more A records in the additional section,
which are NOT part of the answer but served as additional data as a
convinience.

A query for AXFR would similarily contain the response to the query in the
answer section. As a convenience, servers might add additional data in the
additional section, but those are NOT part of the answer and should not be
treated as such.

Easy enough for you to understand?

- Kandra

---

From: Peter Koch <[email-masked]>
Date: Wed, 19 Feb 2003 21:48:16 +0100

> additional section, but those are NOT part of the answer and should not be

the draft explicitly forbids this ``might add'' in section 4 and this is
OK and consistent with the general idea of producing identical copies of
the zone data. Please note that the draft introduces a concept of names
being ``associated'' with a zone regardless of their logical relation to
the zone's content. I.e. if I add an A RR for this.is.invalid to my zone
the draft expects this RR - although operationally useless - to be copied
for the sake of consistency. On the other hand the draft wont allow handing
out this RR in any case, so there's no operational harm caused by this,
but it makes AXFR as reliable (as in: producing predictable results) as
ftp, scp or pony express.

Since all the data has to be evaluated for eligibility at the slave ("client")
side anyway and the master has no choice in sending or not sending additional
data, there's no point in sending the AXFR response in anything else but the
answer section.

-Peter

---

From: [email-masked]
Date: Thu, 20 Feb 2003 08:28:38 +1100

> There are no interoperability problems here.

	Well you havn't struck the servers that get this calculation
	wrong yet.  However I don't find that suprising as your server
	really isn't designed to with AXFR in mind.
 
> these problems are a figment of your imagination.)

	I never said that Microsoft was the responible vendor.  I've
	never bothered to find the name of the vendor.
 
> don't affect interoperability, so they are none of the IETF's business.

	But it does affect interopability with servers that get
	things slightly wrong.

	You can't trust the UDP length and you can't trust the TCP
	message size to find the end of reply received.  There are
	servers that get these calculations wrong.
 
> perfectly standard behavior not only in theory but also in practice.

	The additional section does NOT contain the answer.  It
	contains other data that may be related however it is not
	part of the answer to the question an is not treated as
	such.

> ``except in MX queries'' then your religion starts to sound really dumb.

	We selectively cache the contents of the additional section.
	We also reject what shouldn't be there or what we don't
	trust the current server to give us.

	Mark

---

From: Dean Anderson <[email-masked]>
Date: Wed, 19 Feb 2003 16:20:03 -0500 (EST)

> This is exactly what the draft says, so what are you disagreeing with?

Uhh, no. Draft 05 says quite a bit more.  It subtly changes a number of
things that shouldn't be, and don't need to be changed. In fact, looking
at my copy, it doesn't say anything like the above at all.  (But assuming
it did, it would be redundant and could be deleted). Perhaps we don't have
the same copy of the file. My copy was printed from
www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-05.txt.

I disagree with everything in the draft that deviates from the common
assumptions made by implementations besides Bind 9.

Specifically, (and I'll try to be complete, but this is just off the cuff
for this message)

The second paragraph of Section 2 should be deleted.  Specific
implementations are not to be mentioned in RFC's.

In section 3, where it says "MUST" it should say "MAY", and where it says
"MAY", it should say "MUST".

Section 3.1 seems like a good idea, however, it is a modification to AXFR,
and should have a new request code. I suggest calling it MAXFR and giving
it code 253.  Support for this request code should be optional, and a
server may respond using the original (one record per message) AXFR
method. Upon discovering non-implemenation, clients should fall back to
AXFR or fail as determined by implementation or configuration.

Section 3.3 should be deleted. This is up to the administator and/or the
implementation.  SIG processing is not addressed, neither by when the
server should put them in, nor by what the client should do with them if
present.

Section 3.4 should be deleted.

Section 3.5 and 3.6 should be deleted. Data can come in either authority
or additional sections.  There are no transaction signatures, except for
id, question, and serial number.

Section 4 should be deleted.  Clearly, glue records need to be merged in.

Section 5 paragraph 3 should be deleted except for the first sentence.
In the forth paragraph, where it says "MUST", should say "MAY".
Clearly, duplicate records may indicate a misconfiguration, and their
presence in a zone can indicate a problem. Or not. It is up to the
administrators to determine how they configure there servers, and to
configure those servers consistently.

Section 6 should be deleted.  The status of these other RFCs is not to be
altered except by appropriate standardization process.  This is an
inappropriate end-run around that process.

Whether zone data is public is an administrative decision not limited by
RFC. Administrators are free to place or implement whatever restrictions
they wish on domain name records, and such administrative restrictions are
not limited to only zone transfer restriction. They can, for example, be
limited by node or record type, or any other way that can be invented and
found useful.

> specified by their different administrators.

Perhaps. Perhaps not. However, that would be an implementation issue, not
relevant to AXFR, or to the protocol.

Section 4.2 of 1034 says "it would be possible to partition the name space
so that each domain name was in a separate zone... In some cases, such
divisions are made purely to make database maintenance more convenient."

There is a huge amount of latitude on the administration of zone
boundaries.  Clearly, one has to be able to merge in glue records.  These
records are specified by the administrator, and so merging is appropriate.
If the administrator specifies them inconsistently, they may be
inconsistent.  No surprise there.  That is the ultimately the
administrator's fault.  It may not be possible for a secondary to detect
such misconfiguration in the master.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 19 Feb 2003 16:32:01 -0500 (EST)

> 	All of which is irrelevent to this issue.

THAT's what I have been saying. You were the one who said we needed to do
this to support IXFR. I've been saying that claim was wrong. Thanks for
FINALLY coming round to that.

> 	the data originally entered.

They sure have been.

> 	and have it apply without error.

None of this is relevant. All that is necessary is to delete the RRs, and
insert the RRs in the sequence.

If the zones are inconsistent through administrative mistake, then it
won't matter what the IXFR does.

> > are unaware of it".  Agreed.  Having done so, we don't want to stir the

Strange, that was my reaction, too. I'm just trying to be polite.  77%
work just fine. We don't want to break 77% of the servers out there.

> 	The constaint was already there and it is necessary for reliable

No, you ware not being honest about the contents of the Draft. See my last
message to Andreas.

> > I presume agreement on the name change?

Then the entire draft should be rejected since it is misleading.  Please
resubmit a proposal that isn't misleading the community about its purpose,
impact, and contents.

		--Dean

---

From: [email-masked]
Date: Thu, 20 Feb 2003 10:21:09 +1100

> and we'll discuss it. But don't try to sneak it past us as part of an

	Semi-synchronized changes have always been part of the DNS.
	Anyone who believes otherwise is deluding themselves.

	Mark

---

From: [email-masked]
Date: Thu, 20 Feb 2003 10:56:45 +1100

> > 	the data originally entered.

	Not always.
 
> won't matter what the IXFR does.

	Who said anything administrative mistakes?  The content is being
	unilaterally changed by the servers.
 
> work just fine. We don't want to break 77% of the servers out there.

	You really think that it will break those servers?  LOL.
 
> No, you ware not being honest about the contents of the Draft. See my last

	The abstract say:

				    This memo clarifies, updates, and
   adds missing detail to the original AXFR protocol specification in
   RFC1034.

	I fail to see how the contents can be deemed misleading when
	it states up front what it does.  Woops we missed warning you
	up front that it contains a warning.
 
> > > > > To prevent confusion between the two proposals, I would like to renam
> e th
> > > e

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Feb 2003 00:07:52 -0000

> 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.

---

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

> 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

---

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.

---

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: Dean Anderson <[email-masked]>
Date: Thu, 20 Feb 2003 11:32:38 -0500 (EST)

> > > 	the data originally entered.

You haven't shown any proof of that.  The "proof" you showed, was the
result of a misconfiguration.

> 	unilaterally changed by the servers.

It is reasonable and necessary to merge in glue. When you misconfigure the
glue, strange things may happen. That is all that you have shown.  I'm
sure that many software programs will exhibit even stranger behavior, and
may even fail to operate as a result of misconfiguration.

> 	You really think that it will break those servers?  LOL.

They will not be compliant, and thus will need to be changed. Thus, they
would be broken by definition of not being compliant.

Your failure to comprehend the consequences of the changes does not lessen
the effect.  We now agree that these changes aren't necessary to support
IXFR. You were part of the bad engineering that led to the unnecessary
creation of these changes in Bind 9.  You were also part of the bad
decision making that led to the distribution of these changes to Bind 9
users prior to standardization, and quite possibly you were part of the
bad decision making that resulted in publishing a book on the subject,
prior to acceptance of your modifications to standards. In short, you have
shown bad judgement.

Trying to "belittle" the effects with the "LOL", as opposed to offering
anything substantive, simply suggests that you have no appreciation of the
seriousness of the changes.  Perhaps you should take this more seriously.

> 	up front that it contains a warning.

I've no doubt that you fail to see it. We seem to be focusing a lot on
your failures. I have to question whether someone who went to MIT could
really fail so often. Perhaps it has changes since I was there. Or perhaps
you aren't really taking this very seriously. Let me explain it:

1) It doesn't say that it adds a completely new, incompatible zone
transfer protocol.  New protocols should be made through a different
process, which includes experimentation. I'm not against experimenting
with a new protocol. Indeed, I think this idea has some merit. However, it
can't be "end-run standardized" by a "clarification". There is a process.

2) It doesn't say that it changes AXFR with respect to SIG

3) It doesn't say that it changes the status of other RFC's (RFC 2845, and
possibly others.) without going through the appropriate standards process.

4) It doesn't say that it changes the definition of zone data to be
public. Zone data is absolutely not "public by definition". It could very
well be useful to tag certain RRs as non-public, and exclude them from
zone transfers to public servers. This "clarification" precludes that.
This is really 2 changes.

5) It doesn't say that it changes the security constraints on a zone
transfer to be limited to deny or accept only.

The list is longer, but that should be enough.

---

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: Keith Moore <[email-masked]>
Date: Thu, 20 Feb 2003 15:07:52 -0500

> RFC 2119, section 6: ``Imperatives of the type defined in this memo
> must be used with care and sparingly.  In particular, they MUST only
> be used where it is actually required for interoperation or to limit
> behavior which has potential for causing harm (e.g., limiting
> retransmisssions) For example, they must not be used to try to impose
> a particular method on implementors where the method is not required
> for interoperability.''

fwiw, this only applies to documents that cite RFC 2119 for
definitions of those terms. other documents have used other
definitions.

---

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

Keith Moore writes:
  [ RFC 2119 section 6 ]
> only applies to documents that cite RFC 2119 for definitions of those terms.

That's exactly what axfr-clarify does in section 1: ``The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC 2119].''

The author will, presumably, try to weasel out of RFC 2119 section 6 by
dropping the reference to RFC 2119. Why is this tolerated? Why would any
legitimate standards organization _want_ to violate the basic principles
stated in RFC 2119? The IETF shouldn't be sticking its nose into private
implementation decisions that don't cause interoperability problems.

---

From: [email-masked]
Date: Fri, 21 Feb 2003 09:33:24 +1100

> > > > > deleting RRs and adding RR's in each sequence. The original version o
> f th
> > > e

	No.  It is the result of operational reality.  Whenever you
	have a parent and child zones under different administrative
	controls it is impossible to change both zones simultaniously.
	It is also impossible using AXFR or any other mechanism
	which transfers *individual* zones to transfer them to a
	secondary and guarantee that they will arrive simultaniously.

	Having parent and child zone under different administrative control
	is the norm not the execption.

> may even fail to operate as a result of misconfiguration.

	No.  It is neither reasonable nor necessary.  Any temporary
	inconsistancies will be corrected when all the zone transfers
	complete.  By changing the zones contents you create
	situations where these temporary inconsistancies won't be
	corrected.  When handing out non axfr/ixfr responses you
	use the best source of data you have.

	Nothing in RFC 1033 / 1034 / 1035 says that a server is permitted
	to alter the content of a zone.  The responability for maintaining
	consistancy between zones is a administrative function.
 
> would be broken by definition of not being compliant.

	So.  Just because they will not be compliant doesn't mean
	that that they need to be replaced immediately.  That
	non-compliance doesn't hurt most of them.  For those where
	it does have a negative impact it will mean that they should
	be able to request a fix from their vendor.

> prior to acceptance of your modifications to standards. In short, you have

	I never said that they we not necessary for IXFR.  I said that
	that your descripition of how to generate the differences was
	irrelevent to this discussion.

	It was bad engineering to merge the data sets together in the
	first place.  It was not required by RFC 1033/ 1034 / 1035.
	It had negative consequences.  It was good engineering to
	correct this.  It was also good engineering to report a
	common error to the community so that other vendors could
	fix their mistakes.
 
	Good engineers learn from their mistakes and try hard not
	to repeat them.  They also learn from the mistakes of others.
	That's why bridge designs are wind tunnel tested these days.

> seriousness of the changes.  Perhaps you should take this more seriously.

	I'm quite aware of what the change requires.  I'm also aware
	that most of the nameserver are used in situations where
	the zone contents is already preserved because they are not
	serving zones with parent / child relationships.

	Anyone saying that all the nameservers need to be replaced
	immediately is spreading FUD.  LOL the the correct reponse
	to FUD.
 
	Using a server that perserves zone contents under all
	conditions doesn't break anything.

> > > > > pretty free to define the zone boundaries.  Of course, the specifics 
> of a
> > > n

	It isn't new.  All it is saying is that the contents tramitted
	out MUST be that transmitted in.  This occurs most of the time
	already.  Note BIND is not the only implementation that does
	this.  We have already had reports of 3 other implementations
	doing this.  Even the implementations that don't guarentee the
	contents do this most of the time.  It has no negative effects.

> 2) It doesn't say that it changes AXFR with respect to SIG

	It doesn't change anything wrt to SIG.  Go read RFC 2535 which
	also says that SIG records in the answer section are part of the
	zone contents and don't need special processing.
 
> possibly others.) without going through the appropriate standards process.

	It doen't change the status of RFC 2845.
 
> This is really 2 changes.

	Nowhere in RFC 1033 / 1034 / 1035 does it say that zone transfers
	are restricted to secondaries.  Nowhere in RFC 1033 / 1034 / 1035
	does it say that you should restrict zone tranfers.
 
	There is a REFUSED rcode so the possibility of refusing a zone
	transfer is allowed for but the conditions underwhich this will
	be done are not specified.  This draft does not change this.

> transfer to be limited to deny or accept only.

	Effective it does.  If you transmit the zone then you MUST
	transmit its full contents unmodified (accept).  It also
	says that you are allowed to refuse zone transfers (deny).

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 20 Feb 2003 15:56:17 -0800 (PST)

Dean Anderson writes:
> it did, it would be redundant and could be deleted).

The draft says many things, and I understand that you are objecting to
several of them, but we were specifically discussing zone boundaries,
the subject of section 4.  Your statement that "server administrators
provide the definition of zone boundaries" is consistent with the
draft's existing wording and inconsistent with the BIND 4 / BIND 8
handling of zone boundaries which you previously claimed to support.

> Section 4 should be deleted.  Clearly, glue records need to be merged in.

Are you saying section 4 should be deleted because you disagree with
it, or because you find it obviously correct and therefore redundant?
Also, which glue records need to be merged into what?
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Fri, 21 Feb 2003 11:14:17 +1100

> Andrews admits that his configuration violates RFC 1034 section 4.2.2.

	It's a necessary and unavoidable reality to temporarily
	violate it.

	The only way to meet this all the times and at all levels
	of the DNS is to have the all the zones administered on a
	single machine *and* to have a multizone transfer protocol.

	Lets go back to HOSTS.TXT, that meets this criteria.

> parts of his configuration. (BIND 9 doesn't; djbdns does; BIND 8 does to

	No.  I agree that server can be configured to correct PRIMARY
	zones if they detect a inconsistancy and if they do so they
	have to update the serial number.
 
> data for the parent zone through AXFR rather than directly from an

	It is not the servers job to correct inconsistancies in SECONDARY
	zones.

	RFC 1034 states that a ACURATE copy of the zone is ESSENTIAL.

					"The stream of messages allows
the secondary to construct a copy of the zone.  Because accuracy is
essential, TCP or some other reliable protocol must be used for AXFR
requests."
 
	A modified zone is NOT a ACURATE copy.  It's not even
	a copy.  It is a derived work.

	BIND 4 and BIND 8 violate this section of RFC 1034.
	BIND 9 does not.

>        for most of the Internet's DNS servers to be non-compliant!

	The installed base is broken.  It doesn't matter if it is 1%,
	77% or 100%.
 
>    (3) Sane conclusion: The configuration is broken. Stop using it.

	No.  The sane conclusion is to deal with physical and
	administative realities.  To stop fighting the speed of
	light and correct the implementations.
 
> modified to allow semi-synchronized configurations.

	It is good to see that you agree that Section 4.2.2 cannot
	be met all the time.  It is good to see that you agree that
	enforcing agreement between zones causes problem.  The
	logical conclusion is to stop enforcing agreement between
	zones where it causes problems.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 20 Feb 2003 14:08:27 -0800

D. J. Bernstein wrote:
> The IETF shouldn't be sticking its nose into private

But Rob Elz made a clear point in seemingly the only message you 
*didn't* respond to that your implementation could cause 
interoperability problems by potentially allowing for different contents 
of the same zone with the same serial number.  I won't regurgitate the 
rest of his message, but it's in the archives.

If he's right (and it seems to me that he is), that's an indication for 
either a standards clarification or a bug fix to your code, and maybe 
both (indicated, IMHO).

Eliot

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Feb 2003 21:07:49 -0500 (EST)

> 	is the norm not the execption.

Actually, a parent always has some control over the child. It exercises
this control through the glue records.  When the glue records are in the
child zone, they need to be merged. If a zone transfer happens while they
are inconsistent, it is possible for some strange results to happen.
Ordinarilly, zone transfers don't happen when they are inconsistent, since
the inconsistency is usually short.

Any zone transfers made during the inconsistent window are corrected so
long as the child zone is updated with correct information after the
parent is updated.

Frequently the parent and child zone are under different administrative
control, and are frequently on different servers. In such a case, the
contents of the parent zone aren't merged with the child in the child's
server, and no evidence of the inconsistency is seen through zone
transfers. However, the inconsistency still exists and may still be
visible by resolvers and nameservers that lookup the glue records.

You have obtained no benefits by these constraints.

> 	use the best source of data you have.

It is necessary, since the parent has glue records in the child zone.
The parent therefore has (always) a part of the child zone. If that server
also loads the child zone (or perhaps generates part of it dynamically),
it quite reasonable to merge the records as though the zone includes
multiple files, which in theory, it does.

The child zone contents will only be correct when the administrators of
both zones agree on the contents of the glue records, and update their
parts of the child zone accordingly. It will not be correct until then,
regardless of how many zone transfers take place.

> 	consistancy between zones is a administrative function.

This is a loaded statement. The part of the server NOT involved in
responding to queries and zone transfers is part of the administrative
function. So, as part of that administrative function, it has to be able
to modify the RR and zones accordingly.  Your proposed changes exclude a
huge part of the potential for intelligence in name servers. And do so
with no benefits.

> 	be able to request a fix from their vendor.

You seem to make a case that in general, non-compliance doesn't hurt
anything. This is false, for both technical and commercial reasons.
Technically, it hurts interoperability, which has some many obvious harms
I won't go into them. Commercially, implementations make and advertise
compatibility and standards compliance claims. This retroactively makes
those claims false, which harms the business and reputation of those other
vendors.

77% will need a fix from the vendor, if we were to accept these changes.

The vendor that made false claims of compatibility and standards
compliance is Bind 9. It should suffer the commercial damage to its
business and reputation, as a result.

> 	irrelevent to this discussion.

Ok, you are half way there. They are irrelevant because IXFR is
irrelevant. These changes are not necessary to IXFR, as I explained that
IXFR can work with the current AXFR, or even without AXFR.

> 	common error to the community so that other vendors could

Actually, since the parent has the glue in the child zone, it has part of
the child zone as well as the master zone.  Merging them together is not
prohibited, and in the case where child and parent have the same
adminstrator, as might be the case where most of the child is simply
automatically generated by the nameserver, can make things much easier.

Your constraints preclude this unnecessarilly.

Since I can think of cases where it is useful to merge records together,
it is bad engineering to remove that flexibility and obtain no benefits in
return.

> 	serving zones with parent / child relationships.

Apparently, you aren't even aware that your changes will make all non-bind
9 servers non-compliant.  Had you been aware of that, it seems you would
have brought this proposal forward something like 3 years ago, before
releasing Bind 9, and before publishing a book on the subject.

> 	immediately is spreading FUD.  LOL the the correct reponse

Making 77% of the servers non-compliant is a fact of your proposed
changes.  It is another fact, as explained, that non-compliant servers
will need to be replaced.  Will they suddenly stop working? It depends on
whether other implementations want to implement a "backwards
compatibility" mode. If they don't implement this mode, then the answer is
yes, they will stop working as soon as these updates are deployed by other
vendors. Of course, this is a bad result.

> 	conditions doesn't break anything.

Your constraints break useful services, and offer no value in return.

> 	contents do this most of the time.  It has no negative effects.

No, Section 3.1 is a whole new derivative of AXFR. That is new.

> 	zone contents and don't need special processing.

Oh. Then section 3.3 can be deleted in entirety without objection.

> 	It doen't change the status of RFC 2845.

The IEFT index indicates that RFC 2845 is "Proposed Standard", with no
applicability statement that I could find.  This changes it to
"RECOMMENDED" requirement level.  I think an applicability statement is
premature until RFC 2845 is moved along, and then by the appropriate
standards body decision-making process. It is inappropriate to hide
something like this deep in an irrelevant "clarification".

> 	does it say that you should restrict zone tranfers.

I don't think you understood my statement. I'm talking about the
definition of zone data. Nowhere does 1034 etc say that zone data is
public.  It may well have been thought to be public, originally, but since
I can easily see a useful purpose in withholding some private RRs, there
isn't any reason to preclude that behavior.

Your constraints harm a useful purpose, and provide no benefits.

> 	be done are not specified.  This draft does not change this.

Your modifications put additional and unnecessary restrictions on a zone
transfer. Again, these restrictions have no useful purpose.

> 	says that you are allowed to refuse zone transfers (deny).

This was addressed in the previous comments.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Feb 2003 21:19:51 -0500 (EST)

> handling of zone boundaries which you previously claimed to support.

Actually, I am quoting RFC 1034 directly. Section 2.3.

I believe you are misquoting the draft, since its section 4 doesn't say
anything like this.

Bind 8 will merge glue from child and parent zones. This merging is the
reason for the warning not to mix slave and master servers, since the
order of this merging is undetermined and the slave can overwrite the glue
originally supplied from the parent zone file.

> Also, which glue records need to be merged into what?

I disagree with it.  I gave several reasons in more detail in my last
message to Mark Andrews:

1) It makes it impossible to dynamically generate zones
2) It makes it impossible to give some data to public secondaries and
other data to private/trusted secondaries.
3) It offers no benefits.

The parent zone has glue records belonging to the child zone. It is quite
reasonable (perhaps not absolutely necessary) for those records to be
merged in as though the zone were spread across multiple files.

This is an administrative function of the server, on behalf of the human
adminstrator.

		--Dean

---

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.)

---

From: [email-masked]
Date: Fri, 21 Feb 2003 14:57:53 +1100

> child zone, they need to be merged.

	Which is it.  Does the parent control the contents of its zone
	or does the child?

> If a zone transfer happens while they

	It doesn't matter if they normally happen while they are
	consistant.  You have to get correct behaviour while they
	are inconsistant.  Changing zone content on SECONDARY servers
	is not correct behaviour.
 
> long as the child zone is updated with correct information after the

	This is a incorrect statement.
 
> visible by resolvers and nameservers that lookup the glue records.

	Nobody is claiming that inconsistancies don't occur all the
	time.  What we are claiming is that those inconsistancies
	need to be preserved in SECONDARY servers for the correct
	operation of the DNS.  That they can only be corrected by
	modifying the PRIMARY source of the zones.
 
> You have obtained no benefits by these constraints.

	There are clear benefits in preserving zone contents on
	SECONDARY servers.
 
> multiple files, which in theory, it does.

	No it isn't.  Changes need to come from the PRIMARY source not
	from intermediate sources.
 
> regardless of how many zone transfers take place.

	Which is what I've been saying all along.  It doesn't require
	a server to "correct" the content at a intermediate point.  Such
	"corrections" actually cause problems.
 
> huge part of the potential for intelligence in name servers. And do so

	The benefits are correct operation of the DNS regardless of the
	propogation timings involved.  If servers don't modify slave zone
	content then which the master servers are brought into sync all
	the servers will be brought into sync.

	This is not guarenteed if the zone content is modified by a
	secondary server.
 
> those claims false, which harms the business and reputation of those other

	They will be harmed much more if they don't correct a common
	error now that it has been pointed out.

	The claims were made in good faith and will be accepted as
	such.
	
> business and reputation, as a result.

	BIND 9 conforms to RFC 1034.  Nothing in RFC 1034 says to
	merge zone content.  If fact 1034 says that this a administrative
	responsability.
 
> IXFR can work with the current AXFR, or even without AXFR.

	IXFR cannot work through SECONDARY servers that change zone
	content regardless of whether the content was learnt via
	AXFR or IXFR.

> Your constraints preclude this unnecessarilly.

	The constraint in on the SECONDARY server.
 
> releasing Bind 9, and before publishing a book on the subject.

	Well you obviously have not been reading.  ISC is not the
	only vendor to come to the same conclusion about preserving
	zone content.  I suspect that they are just bored with
	arguing with you and Dan.
 
> vendors. Of course, this is a bad result.

	Well they havn't stopped working in the last two years that
	this code has been out there.  Nothing in this drafts stops
	a server implementing it taking to any other server.

	There is one backwards compatiblity switch which is only
	requires if you decide to send multiple records in a single
	messages.  A server is not required to send multiple records
	in a single message.

> Your constraints break useful services, and offer no value in return.

	What's useful about modifing the contents of a slave zone?  All
	I can see is harm.
 
> No, Section 3.1 is a whole new derivative of AXFR. That is new.

	Actually it's always been allowed by RFC 1034.  Just because
	it wasn't implement initially doesn't mean that it was not
	allowed.
 
> isn't any reason to preclude that behavior.

	Does this address your concerns?

   "The zone transfer protocol allows read-only access to the complete
   zone data.  When the data being served to the public it is
   generally acceptable to allow unrestricted access to it via AXFR.
   Sites that wish to avoid disclosing their full zone data MAY
   restrict zone transfer access to authorized slaves."

	If you have part of a zone to which you would normally
	return REFUSED to I suggest that you also return REFUSED
	to AXFR.

	If you want to be able to return partial zones then I suggest
	that a new TYPE be defined so that receipients can know
	that the results will be incomplete.

---

From: David Conrad <[email-masked]>
Date: Thu, 20 Feb 2003 20:04:32 -0800

Dean,

It would probably be helpful if you desist from ad hominem attacks.

Rgds,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Fri, 21 Feb 2003 04:20:38 +0000

this is all just fantasy, and not about dns at all (yet).  the protocol
as specified has zone boundaries and the parent's zone bottom is 
unauthoritative glue.  any implementation which mixes data from the
child apex into the parent zone-bottom is incorrect.

this discussion is significantly off course.  let's talk about clarifying
axfr.

> X-Original-To: [email-masked]
> Subject: Re: axfr-clarify breaking RFC 1034
> From: Greg Hudson <[email-masked]>
> To: [email-masked]
> X-Mailer: Ximian Evolution 1.0.5 
> Date: 20 Feb 2003 21:36:31 -0500
> Sender: [email-masked]
>

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Feb 2003 23:32:58 -0500 (EST)

I presume you mean this:

> > engineering.  Now, instead of admitting the mistakes, they want to
> > change AXFR, and are trying (lamely, I might add) to say that AXFR
> > MUST be changed to support IXFR.

This is a true and fair criticism. If it is embarrasing to someone or to
some group of people, that isn't my problem, nor is it an ad hominem,
which means an attack on some person's personal traits, like calling
someone fat or something.  Making a fair criticism isn't an ad hominem.

		--Dean

---

From: David Conrad <[email-masked]>
Date: Thu, 20 Feb 2003 20:51:07 -0800

> This is a true and fair criticism.

No.  It is a subjective and erroneous evaluation based on incomplete 
and incorrect information.  Instead of expressing specific concerns 
about the protocol in a constructive way you are attacking the 
programming, management, and engineering of the people who wrote BINDv9.

Rgds,
-drc

---

From: Dean Anderson <[email-masked]>
Date: Fri, 21 Feb 2003 00:25:56 -0500 (EST)

> 	Which is it.  Does the parent control the contents of its zone

You seem not to understand the subtlety of the issue. The parent (like
real parents) ultimately controls the child, but the child (like real
children) has limited autonomy.

> 	is not correct behaviour.

Sure it is. Unless you can arrange to conduct both updates simultaneosly.
While it would be possible to coordinate such changes on the phone,
relativity could come into play someday.  It has nothing to do with zone
transfers. Its part of the state of the system. Zone transfers is only one
way to learn about the state of the system.

> 	This is a incorrect statement.

Could you elaborate?

> 	modifying the PRIMARY source of the zones.

???  I can't parse this with respect to your previous statements. Could
you rephrase it?

During the period in which the zone is inconsistent, there is no guarantee
the zone will work.  Depending on the nature of the change, wrong
information may be given in queries as well. Suppose the parent is
removing control from the child, and has updated the glue to remove
referals to the child nameservers. For some time (the TTL, at least), the
original child servers will be queried.

On the other hand, the child zone may not even exist yet on the childs
nameservers.  Referals to the zone fail.

To make a concrete example, Osama registers alquaeda.com, and begins
coordinating his evil deeds. The registrar delegates the alquaeda.com as a
child of .com. Eventually, the government intervenes, and .com replaces
Osamas nameserver glue with new glue pointing to government servers. For a
time, this zone will be inconsistent. Note that in this case, the zone
transfers will not indicate the inconsistency.  However, for a short time,
Osama will be able to put up a message warning his followers not to go to
the government run site. This can't be avoided, no matter what gyrations
you put AXFR through.

It makes no difference that the inconsistency _could_, _in_some_cases_, be
seen at the secondaries.

> 	There are clear benefits in preserving zone contents on

Such as?

Your term "preserving zone contents" is misleading. The zone contents are
not corrupted. The glue is inconsistent.  What is the benefit of
preventing any trace of inconsistency in the secondary?

It has nothing to do with IXFR. It has nothing to do with anything.

> 	from intermediate sources.

The intermediate sources aren't making changes. They are, at worst,
propogating old information mixed with new information. However, this is
visible in other ways besides zone transfers.

> 	"corrections" actually cause problems.

Good. Then you agree that Bind 8 behavior is correct.

> 	the servers will be brought into sync.

We already have correct operation of DNS. The zone contents are
inconsistent until both adminstrators come to agreement. The child zone
should be updated last. After the child zone is brought into agreement
with the parent glue, zone transfers will be made which are correct. Only
then will zone transfers will be correct.  Zone transfers made while the
administrators are not in agreement will not be correct, even if there is
no apparent evidence in the zone data from the child (such as a mixture of
new and old glue) they are still incorrect. NS Queries against the parent
and child servers will return different results.

> 	error now that it has been pointed out.

Except, there are no errors, beyond a window of inconsistency that cannot
be avoided, and in fact, that window isn't fixed. Nor do you fix the
"error". They are _still_ inconsistent for a period. And the child will
_still_ have to be updated last.

> 	The claims were made in good faith and will be accepted as

I'm not convinced.  If they were, we would have argued this before Bind 9
was released, and before a book was sent out. Probably about 3 years ago.
Someone knew years ago when they wrote the "backward compatibility" mode,
that they had a protocol issue that would have to come before
namedroppers.  That they delayed for so long doesn't indicate good faith
to me.

> 	merge zone content.  If fact 1034 says that this a administrative

It does right now, due to a knowingly reckless exploitation of ambiguity
in the AXFR. Once AXFR is clarified, Bind 9 will have to use its 'backward
compatibility' mode to be compliant.

It is "knowingly reckless" because the Bind 9 implementers _KNEW_ they
needed to provide a "backward compatibility". That means they knew what
they were doing was incompatible with any (all actually) reasonable
interpretation (however ambiguous) of 1034.

> 	content regardless of whether the content was learnt via

Sure it can.  It doesn't need AXFR at all.  And the secondary's aren't
making arbitrary changes at all.

> 	The constraint in on the SECONDARY server.

So? It is still unnecesary.

> 	arguing with you and Dan.

I think they just haven't really read the proposal's, and have taken some
misleading assurances at face value.

> 	a server implementing it taking to any other server.

Uhh, wrong. The drafts make the current AXFR non-compliant. There is
nothing that would require a server to implement the old AXFR and provide
a "backwards compatibility" mode such as Bind 9 has.

So servers running today, won't be able to talk to strictly compliant
servers that don't have a backwards compatibility mode.

> 	messages.  A server is not required to send multiple records

But is allowed to, and a server that can't receive such messages won't be
able to get the zone.

> 	it wasn't implement initially doesn't mean that it was not

Uhh, wrong, except in an unreasonably broad technical exception due to the
vagueness of 1034.

> 	Does this address your concerns?

No. Because it might be reasonable not to give complete zone data.

> 	that the results will be incomplete.

So far as the secondary is concerned, the zone is complete.  If you do
this, you don't want to tell people that you have some data that isn't
public.  Nor would you ever need to.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 21 Feb 2003 00:41:19 -0500 (EST)

I'm not attacking them. I'm criticizing them, fairly, I might add.

As I wrote in another mail, when they put in a "backward compatibility"
mode, they knew (years ago) that they had a protocol issue that would have
to come before namedroppers and the ietf.  They delayed. Instead, they
released code to users, and wrote a book. Those were clearly a bad
decisions. (note the plural) They justly deserve criticism for that.

Further, they wrongly concluded that these changes were necessary to
implement IXFR. Even if we assume that was an honest mistake, then it was
still a _MISTAKE_, for which they justly deserve criticism.

---

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: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2003 06:37:25 -0000

[email-masked] writes:
> Whenever you have a parent and child zones under different administrative

False.

Set the clocks correctly, and schedule the change on all the servers for
a particular time, using (for example) the tinydns timestamp feature
described in http://cr.yp.to/djbdns/tinydns-data.html. When that time
rolls around, all the servers will change their data simultaneously, as
RFC 1034 requires.

Yes, this is difficult to achieve with BIND, AXFR, etc. But it's easy to
achieve with better software, better replication protocols, etc. You're
making a fool of yourself when you call it ``impossible.''

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2003 07:03:17 -0000

[email-masked] writes:
  [ about RFC 1034's database-consistency requirement ]
> single machine *and* to have a multizone transfer protocol.

False; and, more importantly, irrelevant.

RFC 1034 clearly prohibits your broken configurations. You admit this.
It's now obvious to everybody that you're talking about real protocol
changes, not ``clarifications.''

You want to change the protocol. Okay. Make an honest proposal in the
DNSEXT WG, and we'll discuss it. Don't try to slip it past us as part
of an ``AXFR clarification.''

---

From: [email-masked]
Date: Fri, 21 Feb 2003 18:23:53 +1100

> children) has limited autonomy.

It is a subtle issue.  You can only apply changes to the PRIMARY source
of the data.  Applying changes at any other point has the potential to
cause servers to serve incorrect content.
 
> way to learn about the state of the system.

Changing the content of zones in SECONDARY servers prevents other SECONARY
servers using the first SECONDARY server learning the correct state of the
system.
 
> > 	This is a incorrect statement.

	Server A master to parent.
	Server B master to child.
	Server C slave to parent and child.
	Server D slave to parent using C as master.

	All servers with NS RRset N of child zone.

	Server B updates NS RRset to N'.
	Server A updates NS RRset to N'.
	Server C transfers parent from A.
	Server D transfers parent zone from C.
	Server C transfers child zone from B.

	End state with modification (BIND 8/tinydns).
	Server A N', Server B N', Server C N', Server D N.

	End state without modificatin (BIND 9).
	Server A N', Server B N', Server C N', Server D N'.

	You will notice that the last transfer above was the transfer of
	the child zone.
 
	Now lets update the child last.

	Server A updates NS RRset to N'.
	Server B updates NS RRset to N'.
	Server C transfers parent from A.
	Server D transfers parent zone from C.
	Server C transfers child zone from B.
	
	End state with modification (BIND 8/tinydns).
	Server A N', Server B N', Server C N', Server D N.

	End state without modificatin (BIND 9).
	Server A N', Server B N', Server C N', Server D N'.
	
	You will notice that the last transfer above was the transfer of
	the child zone.

	Lets wait for the parent zone to propogate to all servers
	before updating the child zone.

	Server A updates NS RRset to N'.
	Server C transfers parent from A.
	Server D transfers parent zone from C.
	Server B updates NS RRset to N'.
	Server C transfers child zone from B.

	End state with modification (BIND 8/tinydns).
	Server A N', Server B N', Server C N', Server D N.

	End state without modificatin (BIND 9).
	Server A N', Server B N', Server C N', Server D N'.

	Now if you force everyone to wait until the child zone
	has progated.

	Server B updates NS RRset to N'.
	Server C transfers child zone from B.
	Server A updates NS RRset to N'.
	Server C transfers parent from A.
	Server D transfers parent zone from C.
	
	End state with modification (BIND 8/tinydns).
	Server A N', Server B N', Server C N', Server D N'.

	End state without modificatin (BIND 9).
	Server A N', Server B N', Server C N', Server D N'.

	You will notice that in all examples BIND 9 ends in the correct
	state.  The same cannot be said for BIND 8 or tinydns.

	Modification of SECONDARY zone content is NOT required or desirable
	for the correct operation of the DNS.

> ???  I can't parse this with respect to your previous statements. Could

	You make changes at the PRIMARY server for the zone.
	You do not make changes to zones anywhere else.

> original child servers will be queried.

	What does this have to do with this draft?
 
> nameservers.  Referals to the zone fail.

	What does that have to do with this draft?
 
> the government run site. This can't be avoided, no matter what gyrations

	What has this got to do with this draft?
 
> It makes no difference that the inconsistency _could_, _in_some_cases_, be

	It does make a difference as demonstated above.
 
> preventing any trace of inconsistency in the secondary?

	It may be inconsistant but which version is correct?  The copy
	in the child may be out of date.
 
> It has nothing to do with IXFR. It has nothing to do with anything.

	IXFR still requires the content to only be changed in response
	to IXFR deltas.
 
> visible in other ways besides zone transfers.

	You are changing the contents if you mix data from different zones.
 
> Good. Then you agree that Bind 8 behavior is correct.

	BIND 8 "corrects" data at intermediate points.  BIND 9 doesn't.
	BIND 8's behaviour is wrong.
 
> and child servers will return different results.

	What have you been smoking?
 
> > > > > > > Strange, that was my reaction, too. I'm just trying to be polite.
>   77
> > > %

	You obviously don't understand the problem
 
> namedroppers.  That they delayed for so long doesn't indicate good faith

	We having been saying for years before BIND 9 was released that
	that BIND 8 had this wrong.  BIND 9 conforms to RFC 1034.

	Axfr-clarify arose because it was pointed out that IXFR depended
	upon the definition of AXFR and that AXFR was not well specified.

> compatibility' mode to be compliant.

	What "reckless" exploitation? 
 
> interpretation (however ambiguous) of 1034.

	The only thing that requires a backward compatability switch
	is sending multiple records in a message.

	BIND 4 accepted these back in 1996.  Other vendors started
	accepting these back in 1996.  BIND 8 has always accepted
	them and could be configured to send them.  BIND 9 defaults
	to sending them and can be configured not to.

	At the same time as this was happening other vendors also
	started sending them.  We all knew that there was interoprability
	issues that were a result of oversites in the implementation.
	One vendor even made use of the fact that named (and I
	presume other servers) didn't barf on a oversized query to
	signal to it servers that they could send a multi-record
	respones.
 
> > > > > Your failure to comprehend the consequences of the changes does not l
> esse
> > > n
> > > > > prior to acceptance of your modifications to standards. In short, you
>  hav
> > > e
> > > > > shown bad judgement.
> > > >

	If servers wern't making arbitary changes we would not be having
	this discussion.

> So? It is still unnecesary.

	Next you will tell me that the grass is blue and the sky is green.

	If you can't see the need for the constraint stop blocking those
	that do.

> > > > > anything substantive, simply suggests that you have no appreciation o
> f th
> > > e

	So you want

   "Slaves MUST accept messages containing any number of answer RRs.  For
   compatibility with old slaves, masters that support sending multiple
   answers per message SHOULD be configurable to revert to the
   historical mode of one answer per message, and the configuration
   SHOULD be settable on a per-slave basis."

	replaced with

   "Slaves MUST accept messages containing any number of answer RRs.  For
   compatibility with old slaves, masters that support sending multiple
   answers per message MUST be configurable to revert to the
   historical mode of one answer per message, and the configuration
   SHOULD be settable on a per-slave basis."

> > > > > with a new protocol. Indeed, I think this idea has some merit. Howeve
> r, i
> > > t

	Multiple records in the answer section have always been part
	of the standard.
 
> public.  Nor would you ever need to.

	Well if you don't want to tell them that you have private
	part then you won't be answering with REFUSED. You effectively
	have two zones that just have a lot in common.  Treat them
	as such.

	Mark

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2003 07:30:55 -0000

Eliot Lear writes:
> your implementation

And others, notably BIND 8. We're talking about MOST of the Internet's
DNS servers here. (See http://cr.yp.to/surveys/dns1.html; I'm assuming
that *.com is representative.) This is not a small issue.

> could cause interoperability problems by potentially allowing for
> different contents of the same zone with the same serial number.

No. The _administrator_ can create problems by violating RFC 1034.
(Andrews has admitted that his broken configurations violate RFC 1034.)

If the administrator follows RFC 1034's consistency requirements, no
problems occur. In fact, if the administrator violates RFC 1034 but
still follows the easy semi-synchronization rule, no problems occur.

Andrews is finally coming out of the closet and arguing that the RFC
1034 rule should be changed (because, with his software, the rule is
hard for administrators to follow). But he can't reasonably argue
against the semi-synchronization rule. People normally follow that rule
anyway; there's no reason to break it; and it guarantees that problems
don't occur.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 09:25:36 +0100 (CET)

> releasing Bind 9, and before publishing a book on the subject.

A data point.

http://www.ietf.org/proceedings/00jul/I-D/dnsext-axfr-clarify-00.txt
INTERNET-DRAFT                                      Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-00.txt                     Nominum Inc.
                                                            March 2000
Seems to be 3 years ago.

  Erik

---

From: [email-masked]
Date: Fri, 21 Feb 2003 19:28:06 +1100

> rolls around, all the servers will change their data simultaneously, as

	So now you want to extend the protocol so that each record has
	an inception time and a expiration time.  We could create a
	new transfer protocol to do this and treat this data as meta
	data.

	However you would still have the problem of the meta data
	being inconsitant.  You would still need to ensure that it
	is transmitted in the right order or that servers didn't
	modify it while it was being transmitted or that you ban
	any server but the master server sending copies of the zone.

	The problems are inherent with having different source maintaining
	copies of the same data.
	
	Mark

---

From: [email-masked]
Date: Fri, 21 Feb 2003 19:42:33 +1100

> (Andrews has admitted that his broken configurations violate RFC 1034.)

	The administrator cannot avoid breaking the rule.  All they
	can do is ensure that the time the rule is broken is
	minimised.
 
> still follows the easy semi-synchronization rule, no problems occur.

	You don't live in the real world if you think there won't be
	errors.  The job of computers is to make life easier not
	more complicated.  Having a protocol/implementation that
	doesn't deal with timing mistakes is a bad.
	
> anyway; there's no reason to break it; and it guarantees that problems

	Dan if you want everyone to follow this rule then are you
	going to modify your software to enforce it.  You software
	doesn't currently comply with this rule.

	Mark

---

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: Kandra Nygårds <[email-masked]>
Date: Fri, 21 Feb 2003 15:36:39 +0100

> rolls around, all the servers will change their data simultaneously, as

Excellent idea. Unfortunately, this doesn't address the problem with several
TLD registries requiring a correctly configured zone prior to making a
delegation. In many cases, there are automated checks that prevent you from
even requesting a change of delegation unless you have updated your zone.

Example:

Server A and B are authorative for zone C.
Zone C is a child of zone TLD.
The administrator for zone C wants to add Server D.
The registrar for TLD requires that Zone C is configured according to the
new data before approving a change.

Alternative A:

The administrator for zone C won't violate RFC1034 and is therefore unable
to change his zone data unless TLD is also updated at the same time, which
the TLD doesn't allow.

Alternative B:

The administrator for zone C changes the data in zone C, thereby temporarily
violating RFC1034.
The delegation robot for TLD verifies the data and accepts the delegation,
therefore ensuring that RFC1034 consistency is maintained.

I'm sure that most administrators would pick alternative B in this case. If
you're still maintaining that RFC1034 violations are unacceptable, you might
want to update the following pages:

http://cr.yp.to/djbdns/dot-fr.html
http://cr.yp.to/djbdns/dot-it.html
http://cr.yp.to/djbdns/dot-nl.html
http://cr.yp.to/djbdns/dot-no.html
http://cr.yp.to/djbdns/dot-ru.html
http://cr.yp.to/djbdns/dot-arpa.html

All of these registries require that administrators knowingly change the
data in their child zones before the parent zone is updated, in fact they
all use automated checks to ensure that the data is in fact correct. This
short-term intentional violation of RFC1034 is to ensure that parent and
child gluedata is consistent in the long run.

As I said, we don't live in a perfect world. If your software can't cope
with that, there's an implementation bug.

Best regards,
Kandra Nygards

---

From: David Conrad <[email-masked]>
Date: Fri, 21 Feb 2003 06:58:42 -0800

I remember when people thought OSI protocols took too long to 
standardize... :-)

Rgds,
-drc

On Friday, February 21, 2003, at 12:25  AM, Erik Nordmark wrote:

> _______________________________________________
> This message was passed through [email-masked], 
> which is a sublist of [email-masked]. Not all messages are passed. 
> Decisions on what to pass are made solely by Raffaele D'Albenzio.
>

---

From: Len Budney <[email-masked]>
Date: Fri, 21 Feb 2003 12:31:25 -0500 (EST)

On Fri, 21 Feb 2003 [email-masked] wrote:
> Dan Bernstein wrote:
>> problems occur...
> You don't live in the real world if you think there won't be errors.  
> The job of computers is to make life easier not more complicated.  

Agreed! The way to make life easier is to make the software enforce the
rules, so that the admins don't have to worry about it. Granted, the rules
themselves can be wrong--but in that case, you change the rules and then
start enforcing them.

>> Andrews...can't reasonably argue against the semi-synchronization
>> rule. People normally follow that rule anyway; there's no reason to
>> break it; and it guarantees that problems don't occur.
> 
> Dan if you want everyone to follow this rule then are you going to
> modify your software to enforce it.  You software doesn't currently
> comply with this rule.

You might want to read more carefully: Dan's definition of
"semi-synchronization" was (purposely) designed to include
synchronization as a special case.

--Len.

---

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: Dean Anderson <[email-masked]>
Date: Fri, 21 Feb 2003 14:06:41 -0500 (EST)

> rolls around, all the servers will change their data simultaneously, as

Clever.

> making a fool of yourself when you call it ``impossible.''

This could be done with a slight change to AXFR. Lets include it in the
MAXFR proposal (the axfr mods, taken out of the "clarification".

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2003 19:14:30 -0000

> with that, there's an implementation bug.

Where do you get the idea that my software (or most deployed versions of
BIND) has any trouble here?

Andrews is creating problems for himself by updating the parent serial
number too _early_. You're talking about parents that insist on making
the parent changes _late_. Early and late both violate RFC 1034, but
late doesn't cause problems.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 21 Feb 2003 14:20:57 -0500 (EST)

Interesting. So, they knew that standardization was necessary, the
proposed a standard, the standard wasn't accepted, so they distributed
code to users anyway, and wrote a book anyway.

I find that even more worthy of criticism.

Did they think they would force this through later? Never mind, it doesn't
matter what they thought.

As this "clarify" seems to have been dead for years, we should get on with
the business of clarifying AXFR as it was commonly interpreted. And lets
get on with the MAXFR proposal.

		--Dean

---

From: Kandra Nygårds <[email-masked]>
Date: Fri, 21 Feb 2003 21:11:19 +0100

> BIND) has any trouble here?

You have been consistently claiming that your software enforces strict
RFC1034 compliance and therefore compromizes data integrity.

> late doesn't cause problems.

Both "early" and "late" exist in the real world. Regardless of if it's an
administrative error or an intentional change, there's no excuse for any
software to allow timing issues to affect data integrity.

- Kandra

---

From: Len Budney <[email-masked]>
Date: Fri, 21 Feb 2003 15:52:18 -0500 (EST)

On Fri, 21 Feb 2003, [iso-8859-1] Kandra Nygårds wrote:
> 
> Both "early" and "late" exist in the real world. Regardless of if it's
> an administrative error or an intentional change, there's no excuse
> for any software to allow timing issues to affect data integrity.

Yes--early and late both exist. But errors are not symmetrical! If the
task is to "open the door and walk through", then opening the door "early"
doesn't hurt, but opening the door "late" really hurts a lot.

Dan has proposed allowing "late" but not "early". That's easy to do: just
do one thing before attempting to do the other. Your implied claim that
it's impossible to guarantee a time ordering is ridiculous.

--Len.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2003 21:32:57 -0000

> Regardless of if it's an administrative error or an intentional
> change, there's no excuse for any software to allow timing issues to
> affect data integrity.

Suppose the administrator changes the serial number and _then_ changes
the other data. This timing screwup destroys data integrity with BIND 9.
According to your mindless rhetoric, this is an inexcusable BIND 9 flaw.

Can we please drop the religious nonsense now?

In the real world, when the administrator screws up the timing, we blame
the administrator. Good software can prevent many problems---as tinydns
does with automatic serial numbers, for example---but all remaining
problems are the direct result of an administrator's misconfiguration.

Andrews says that the RFC 1034 rules are too hard for administrators to
follow. He wants to loosen them. I'm pointing out exactly which timing
rules are necessary to guarantee a successful update. You are claiming
that we don't need _any_ rules; that's ludicrous.

---

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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 21 Feb 2003 23:53:58 +0000

why would that matter?  the dns protocol does not have perfect 
synchronization.  microsoft goes out of band ("active directory")
to try to create the illusion of "multiple masters" which is their
marketing equivilent of perfect synchronization.  dbjdns appears
to go out of band ("rsync") for the same reason and with similar
results.

instead of talking about out of band methods used by implementations,
let's talk about the dns protocol (this being "namedroppers").  like
for example, let's clarify exactly what a zone is and how the dns
protocol goes about transfering it ("axfr").

re:

> From: [email-masked]
> Date: Fri, 21 Feb 2003 17:16:38 -0600
> To: Name Droppers <[email-masked]>

---

From: Matt Crawford <[email-masked]>
Date: Fri, 21 Feb 2003 11:31:48 -0600

> rolls around, all the servers will change their data simultaneously, 

My friend Dr. Einstein would like a word with you about your casual
misuse of the word "simultaneously."

__________________________________________________________________
Matt Crawford             [email-masked]                Fermilab

---

From: Matt Crawford <[email-masked]>
Date: Fri, 21 Feb 2003 12:09:08 -0600

> I remember when people thought OSI protocols took too long to 

"$X is a slow-moving parody of itself." -- Peter Honeyman

In the original, $X was bound to "USENET", not "IETF".

---

From: [email-masked]
Date: Sat, 22 Feb 2003 23:08:22 +1100

> that we don't need _any_ rules; that's ludicrous.

	Server A (tinydns) primary parent and child.
	Server B (bind 8) secondary parent and child off A
	Server C secondary parent off B

	Initial state NS RRset for child zone N on all servers

	Server A updates NS RRset to N'
	Server B transfers parent
	Server C transfers parent
	Server B transfers child
	
	Final state
	Server A N', Server B N', Server C N

	Your fix.  Delay the update of the parent.  Tinydns is
	incapable of doing this.

---

From: Kandra Nygårds <[email-masked]>
Date: Sat, 22 Feb 2003 16:12:16 +0100

> the other data. This timing screwup destroys data integrity with BIND 9.

BIND9 transfers the zone as presented by the master server at the time of
the transfer. BIND9 does not destroy or change any data received through
that transfer.

A change in the master zone without the corresponding change of serial is an
administrative error, true, and will result in inconsistent views in master
and slave servers. However, the draft in question is specific to the concept
of AXFR. In this scenario, an AXFR would never take place.

> Can we please drop the religious nonsense now?

I apologize. I strayed off topic.

> problems are the direct result of an administrator's misconfiguration.

I fully agree with you, with the exception that there is a defined problem
here. Under certain circumstances, some software might not preserve data
integrity. Your software might be one of them, as has been claimed by a
number of people.

I agree that good software can prevent many problems, in particular
administrative errors. However, those errors must be corrected at the source
or not at all. Attempting to correct administrative errors at a slave server
will cause data inconsistency in certain circumstances.

> that we don't need _any_ rules; that's ludicrous.

On the contrary, I'm trying to encourage a draft that specifies rules to
protect data integrity.

- Kandra

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Feb 2003 17:24:05 -0000

Andrews gives yet another example of a configuration that (1) violates
the semi-synchronization rule and (2) causes problems.

The solution, of course, is to follow the semi-synchronization rule:
update the parent serial number after the child servers have changed.

[email-masked] writes:
> Tinydns is incapable of doing this.

Where do you get these ridiculous ideas?

With tinydns, you can use manual serial numbers and update them exactly
as you would with BIND. You can also use automatic serial numbers and
update them by simply touching the data file. Both ways work.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Feb 2003 17:43:07 -0000

[ BIND 9 allowing a badly timed serial-number update to destroy data ]
> In this scenario, an AXFR would never take place.

BIND 9 does an AXFR, but does it too early, because the administrator
updated the parent serial number too early. BIND 9 never realizes that
it has to do another AXFR.

This is also what's going wrong in Andrews's tinydns/BIND 8 scenarios.
Andrews updates the parent serial number too early, so the parent slave
doesn't realize that it have to transfer the parent zone. The necessary
final AXFR never takes place.

> Attempting to correct administrative errors at a slave server

No. It will simply copy inconsistencies created by the administrator.

If the administrator changes serial numbers properly, the only effect
of these inconsistencies is that, _during_ the update, clients might
receive old data, and clients might receive new data.

If the administrator screws up the timing of changing serial numbers,
the old data can persist _beyond_ the update. You claimed that this was
``inexcusable'' but have now admitted that it's true for BIND 9 too. The
solution is for the administrator to change serial numbers properly.

---

From: [email-masked]
Date: Sun, 23 Feb 2003 09:49:00 +1100

> update them by simply touching the data file. Both ways work.

	So now you want to update the contents of the parent zone
	without a changing the serial.  You want the administators
	to intentionally introduce inconsistanties within the servers
	of a zone to deal with your misguided attempts to remove
	inconsistanties between zones that will be corrected if
	you left them alone.

	Mark

---

From: [email-masked]
Date: Sun, 23 Feb 2003 10:36:40 +1100

>   [ BIND 9 allowing a badly timed serial-number update to destroy data ]

	Dan, is your intention to intentionally mislead the list?
	The example was for BIND 8.  Saying it was for BIND 9 was
	a lie.

        
        Final state

> it has to do another AXFR.

	Well it was BIND 8 doing the AXFR.
 
> final AXFR never takes place.

	There is not such thing are a "necessary final AXFR".
 
> No. It will simply copy inconsistencies created by the administrator.

	What?
 
> solution is for the administrator to change serial numbers properly.

	Well I didn't claim this.

	If the nameserver screws up the copy of the zone the old
	data can persist _beyond_ the update.

	The simple solution to this is to stop the nameservers
	screwing with the copy the zone.

	Mark

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Feb 2003 00:08:19 -0000

[email-masked] writes:
> without a changing the serial.

I said nothing of the sort.

The entire theme of this discussion is that _you_ are causing problems
by leaving a serial number alone when you should be updating it. Because
of your configuration error, a slave fails to realize that it needs to
do an AXFR.

_I_ am saying that those serial numbers have to be changed at certain
times. My position is supported by both RFC 1034 (which imposes even
more stringent constraints---so stringent that you're trying to change
them) and the reality of what actually works with the installed base.

(The ``I'll update serial numbers too early if I feel like it, and it's
inexcusable for software to fail to correct my mistake'' religion made
a brief appearance in this discussion, and was quickly shredded. It's
obvious that some constraints are required.)

It is, of course, acceptable for serial numbers to be changed at other
times too. Extra AXFRs will not cause the world to collapse.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Feb 2003 00:19:14 -0000

[email-masked] writes:
> The example was for BIND 8.  Saying it was for BIND 9 was a lie.

You are, as usual, completely wrong. I gave a crystal-clear example of
BIND 9 allowing a badly timed serial-number update to destroy data. I
was responding to the ridiculous claim that ``there's no excuse for any
software to allow timing issues to affect data integrity.''

> Tinydns is incapable
  [ of changing serial numbers upon demand ]

Wrong again. You're making a fool of yourself.

---

From: [email-masked]
Date: Sun, 23 Feb 2003 12:00:25 +1100

> of your configuration error, a slave fails to realize that it needs to

	In every case I've presented the PRIMARY changed the serial when
	the parent zone was updated.   This is correct adminstrative
	procedure.
 
> them) and the reality of what actually works with the installed base.

	There is no requirement to change the contents of a secondary
	zone in RFC 1034.  It's all in your imagination.
 
> obvious that some constraints are required.)

	It's your I'll change the contents of a secondary zone that
	is causing all the problems.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Feb 2003 02:29:32 -0000

[email-masked] writes:
> the parent zone was updated.   This is correct adminstrative procedure.

No. Your procedure is insufficient, incomplete, and incorrect.

You're arguing that, because you did _something_ right, your entire
procedure is correct. The premise is okay, but the logic is idiotic.

Here's an extreme example to demonstrate the flaw in the logic. Suppose
you _never_ update the data in the child servers. Then the old data will
persist, producing a long-lasting inconsistency, quite similar to the
inconsistencies in your BIND 8 examples and in my BIND 9 example.

You can scream ``I updated the parent data and serial number'' all you
want. But the problem isn't what you _did_; the problem is what you
_failed_ to do. Now do you understand the flaw in your argument?

Anyway, you've admitted that your procedure (1) violates RFC 1034 and
(2) gives wrong answers with most of the installed base. So you don't
have a leg to stand on when you call it ``correct.''

---

From: Alexis Yushin <[email-masked]>
Date: Sun, 23 Feb 2003 05:26:10 +0100 (CET)

>Wrong again. You're making a fool of yourself.

Are you guys married?

Alexis

---

From: [email-masked]
Date: Sun, 23 Feb 2003 16:07:48 +1100

> No. Your procedure is insufficient, incomplete, and incorrect.

	Changing the serial number when they data in a zone changes is
	correct procedure.

	THAT IS ALL THAT IS REQUIRED WITH NON BROKEN SERVERS.  THAT IS
	ALL THAT IS REQUIRED BY RFC 1034.

	Waiting for data to propogate is a WORKAROUND.

> inconsistencies in your BIND 8 examples and in my BIND 9 example.

	If you never update the child then it is an *administrative*
	error.

> _failed_ to do. Now do you understand the flaw in your argument?
 
	The size of the installed base has absolutely nothing to do
	which what is right or wrong.
	
	If 90% of installed bridges had construction/design flaws what
	would you do.

	A.  Continue to used that the existing construction/design method.
	B.  Stop using the existing construction/design method.

	Mark

---

From: Len Budney <[email-masked]>
Date: Sun, 23 Feb 2003 00:33:58 -0500 (EST)

> If 90% of installed bridges had construction/design flaws what

Redesign and rebuild the bridges, of course. But I wouldn't claim it was
"routine maintenance" and "design clarification", for starters. I'd call
it what it was.

--Len.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Feb 2003 09:15:13 -0000

[email-masked] writes:
> If you never update the child then it is an *administrative* error.

Changing the serial number too early is also an administrative error.
Here's a summary of our three examples of administrative errors:

   1. Failing to update the parent serial number after updating the glue
      in all the child servers. As you keep pointing out, this error can
      cause problems with BIND 8: the data will be inconsistent until
      the serial number is updated.

   2. Failing to update the parent serial number after updating the glue
      in the parent master. This error can cause problems with BIND 9
      (and BIND 8, of course): the data will be inconsistent until the
      serial number is updated.

   3. Failing to update the data in the child master. This error can
      cause problems with BIND 9 (and BIND 8, of course): the data will
      be inconsistent until the child data is updated (and the serial
      numbers handled properly).

In every case, the administrator is violating RFC 1034 (as you have
admitted), and is creating a configuration that does not work properly
with most DNS software deployed in the real world.

You persist in drawing a completely unjustified line between the first
error and the other two errors. You claim that allowable administrative
action is defined by BIND 9---never mind what RFC 1034 says, and never
mind the rest of the installed base. You cycle endlessly between ``BIND
9 is doing the Right Thing'' and ``BIND 9 handles that situation'' and
``that situation is not actually an error,'' attempting to defend each
part of the BIND 9 religion by showing how it fits with the other parts.
The circularity is pathetic.

In situations where there's a difference between the software and the
spec---for example, actions that are prohibited by RFC 1034 even though
they work in the real world, or vice versa---one can reasonably discuss
whether the actions should be considered errors. But the above actions
do _not_ work and are _not_ allowed by the spec. If you want to support
them in BIND 9, fine, but you have no basis for demanding that the rest
of us support them too.

---

From: Kandra Nygårds <[email-masked]>
Date: Sun, 23 Feb 2003 10:59:35 +0100

> solution is for the administrator to change serial numbers properly.

Whoa, back up a moment.

First, I'd like to apologize for not making my argument crystal clear. For
some reason, a few people seem to be under several misconceptions regarding
my intentions.

Let's step back and define a few base parameters:

I'm claiming that some software - now existing or future - might experience
problems due to implementation errors.
These problems may be caused by minor administrative errors, or may be
caused by normal everyday routine operations.

These problems are caused by the following:

Server A updates parent and/or child zones.
Server B reaches its refresh threshold for parent zone, checks for an
updated SOA serial and transfers the zone via AXFR
Server C reaches its refresh threshold for parent zone, checks for an
updated SOA serial and transfers the zone via AXFR
Server B reaches its refresh threshold for child zone, checks for an updated
SOA serial and transfers the zone via AXFR

In the above scenario, all updates are performed according to established
routines:
* Any update of the data in a zone is accompanied by the required update of
the SOA serial.
* The AXFRs are all initiated by a SOA serial query indicating an updated
zone.
* The frequency and timing of the queries are controlled by the SOA refresh
value.

This scenario is for a perfectly ordinary routine operation for real-world
configurations - I've personally witnessed configurations where several
masters (see Server B) receive their data from a hidden master (Server A)
and in turn allow slaves (Server C) to update from them.

Now, the problems mentioned above can of course also be caused by
administrative errors, but that's beside the point. What I'm trying to point
out here is the need to maintain zone integrity for the purposes of AXFR in
order to ensure that the zones stay consistent between the servers during
normal updates.

- Kandra

---

From: [email-masked]
Date: Mon, 24 Feb 2003 08:28:07 +1100

> them in BIND 9, fine, but you have no basis for demanding that the rest

	Changing the content of SECONDARY zones is outside of the
	actions specified by RFC 1034.  In fact RFC 1034 demands a
	"accurate" copy.  You can't have a "accurate" copy if it
	has been changed.

	There are no timing issues if you have a "accurate" copy.

	There is no such thing as changing the serial "too early".

	It is the errors in BIND 4, BIND 8 and tinydns that introduce
	timing constraints that are not part of RFC 1034 and only
	affect servers that are serving both parent and child zones.

	We have heard from at least three other independent developers
	that they preserve / preserved the copy of the child zone
	based on RFC 1034 requirement.

	Maintaining consistancy between parent and child zones is
	a administrative responsability.  Even with automated
	assistance the changes are required to be applied to the
	PRIMARY not to the SECONDARY.  BIND 4, BIND 8 and tinydns
	violate the maintance model as a result of applying changes
	in the incorrect place directly leading to the situation where
	all the PRIMARY copies of the zones have the correct information
	but some of the SECONDARY "copies" don't.

	There is no technical reason not to preserve the contents of
	the SECONDARY copies of the zone unaltered.  There are no
	negative effects from doing this.  There definitely are negative
	effects caused by changing the contents of SECONDARY copies.

	All your complaints are based on your interpretation of RFC
	1034.  Your interpretation introduces timing issues which
	even your own software cannot meet without violating the
	requirement to change the serial number when you change the
	zone contents.

	In addition to the pure AXFR issues.  IXFR depends upon the
	contents of the zone not being changed unilaterally on the
	SECONDARY.  Failure to preserve the contents will result
	in deltas not applying that should.  This should result in
	fallback to AXFR to get a upto date copy of the zone.  This
	will result in a AXFR style IXFR to done stream servers.

	Mark

---

From: Paul Vixie <[email-masked]>
Date: Sun, 23 Feb 2003 23:01:53 +0000

ok mark, that's it.  no more replies are warranted.  if mr. bernstein
still misunderstands zone coherency, then someone who doesn't work for
ISC will have to take a turn trying to educate him.  we're done. --paul

ps. great answer btw.

re:

> To: "D. J. Bernstein" <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> From: [email-masked]
> Subject: Re: update timing errors 
> Date: Mon, 24 Feb 2003 08:28:07 +1100

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Feb 2003 00:18:09 -0000

[email-masked] writes:
> actions specified by RFC 1034.

Fact: Slaves _must_ discard records in some situations. A detailed
example appears in http://cr.yp.to/djbdns/axfr-notes.html#poison.
(There are many other counterexamples to your ``no reason'' claim.)

Fact: Slaves _do_ discard records in many situations. You claim that
this is ``wrong'' solely because it can break certain configurations.
You have admitted that RFC 1034 clearly prohibits those configurations.

> timing constraints that are not part of RFC 1034

Fact: As you have already admitted, RFC 1034 _does_ impose these timing
constraints. As you have already admitted, RFC 1034 prohibits even the
slightest configuration inconsistency. In previous messages, you were
complaining about how severe the RFC 1034 consistency requirement is!

Fact: As above, your sole basis for calling the widespread BIND-8-etc.
behavior an ``error'' is that it doesn't work with your broken
configurations. Your sole basis for claiming that the configurations
aren't broken is _some_ DNS servers support them.

Fact: These broken configurations are going to continue to fail for the
foreseeable future. (As http://cr.yp.to/surveys/dns1.html shows, BIND 8
is more widely used than BIND 9.) It is essential for interoperability
that these broken configurations continue to be prohibited. Demanding
support for them would impose costs on at least two independent
implementations, without providing any benefits for the users.

Fact: Making the configurations work is a simple matter of updating the
parent---most importantly, the parent serial number---after (or at the
same time as) all the child servers are updated. This rule is easy for
administrators to follow.

> All your complaints are based on your interpretation of RFC 1034.

Fact: There are no relevant disputes about the interpretation of RFC
1034. When I pointed to the sections of RFC 1034 that you are violating,
you admitted your violations.

> change the serial number when you change the zone contents

Fact: That's part of what RFC 1034 requires. However, that's not even
close to a complete description of an RFC-1034-compliant glue-update
procedure. More importantly, it's not a complete description of a
glue-update procedure that works in practice.

> IXFR depends upon

Fact: IXFR is an optional protocol extension. It is entirely IXFR's
responsibility to maintain compatibility with the preexisting,
unextended, protocol. It is not the responsibility of the installed base
to change for the sake of new protocol options.

Fact: When a protocol extension causes failures with most of the
software deployed on the Internet, you can't safely use the extension
without waiting for a massive upgrade. Users are much happier with an
extension that, at comparable cost, avoids the failures and provides
the same benefits immediately. I have explained to you how to do this
in the case of IXFR.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Feb 2003 00:28:24 -0000

> Any update of the data in a zone is accompanied by the required
> update of the SOA serial.

That sentence is, obviously, not a complete statement of a glue-update
procedure.

See my 21 Feb 2003 06:27:51 -0000 message for a complete list of the
things you have to do. Do you have some questions about that procedure?

---

From: [email-masked] (Andreas Gustafsson)
Date: Sun, 23 Feb 2003 18:39:10 -0800 (PST)

D. J. Bernstein writes:
> Fact: Slaves _must_ discard records in some situations.

This claim has no basis in the standards.

> A detailed example appears in http://cr.yp.to/djbdns/axfr-notes.html#poison.

This is an interesting example and worth discussing in its own right;
I have changed the subject line in the hope that this discussion can
be kept somewhat separate from the usual flamage.  Quoting your
example:

> Suppose that an ISP is simultaneously a third-party DNS server for
> .edu and a third-party DNS server for princeton.edu.
> 
> Suppose the ISP pulls the princeton.edu zone from a Princeton AXFR
> server, and receives the data
> 
>      haven.princeton.edu NS serv1.net.yale.edu
>      serv1.net.yale.edu A 128.112.128.15
> 
> from the AXFR server. The point of the following analysis is that the
> ISP must discard the yale.edu information.
> 
> An innocent user's cache has the legitimate record
> 
>      yale.edu NS serv1.net.yale.edu
> 
> saved. The user asks for the address of www.haven.princeton.edu. The
> cache contacts the root server, learns that the ISP is a .edu server,
> contacts the ISP, and receives the same information
> 
>      haven.princeton.edu NS serv1.net.yale.edu
>      serv1.net.yale.edu A 128.112.128.15
> 
> that the ISP obtained from the Princeton server. Because the ISP is a
> .edu server, the cache trusts and saves the serv1.net.yale.edu
> information. The user now asks for the address of www.yale.edu. The
> cache knows yale.edu NS serv1.net.yale.edu and serv1.net.yale.edu A
> 128.112.128.15, so it contacts 128.112.128.15 to obtain the address of
> www.yale.edu. In short, Princeton has been given control over the Yale
> web server.

I agree that this is a real problem that ought to be solved.  However,
there are several ways of solving it, and I do not think your solution
(making slaves discard certain records in zone transfers) is the best
solution.  For one thing, it does not solve the case where the ISP is
the *master* for the domains in case.

It is an unfortunate fact that the existing DNS standards do not
adequately address the issue of cache poisoning.  They do not even
address the simpler cases that can arise even when all domains are
hosted on distinct servers, much less the more subtle case you
describe above.  They do not even recommend, much less mandate, the
simple but effective resolver-side anti-spoofing measures that BIND 8,
BIND 9, and dnscache all currently employ and that you are taking for
granted in your example above when you say "because the ISP is a .edu
server, the cache trusts and saves the serv1.net.yale.edu information.

My own preference would be for solving this problem on the resolver
side, by using more discriminate anti-spoofing rules than the ones
BIND 8/9 and djbdns currently use.  Another possibility is to make the
servers refrain from giving out the glue in responses in situations
like the above even though it is stored and preserved for purposes of
outgoing zone transfers.  In any case, none of the possible solutions
are standardized at this time, and until they are, no one is required
to use any particular solution, and that includes your solution of
"discarding records".

> When I first mentioned this type of attack, the BIND 9 implementors
> claimed that it was safe for the ISP to provide the serv1.net.yale.edu
> information as glue for haven.princeton.edu.

There was a discussion where I said it was safe to provide cross-zone
glue, but in that discussion no mention was made of the server also
being authoritative for "edu", which makes a subtle but important
difference.
-- 
Andreas Gustafsson, [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Feb 2003 04:00:21 -0000

> This claim has no basis in the standards.

Anti-poisoning rules are required for security. I'm not going to bother
addressing the irrelevant question of whether the de-facto standards in
DNS security can be deduced from the de-jure standards.

You have some anti-poisoning rules in BIND 9 (and BIND 8). We all know
that they're necessary: some records have to be discarded. Consequently,
any claim such as ``all records must be preserved'' is obviously wrong.
When religious rhetoric crashes into security, we all know who wins.

Yes or no: Does the specific attack described on my web page work
against BIND 9? I'll give you three days to issue a security release
before I send a message to bugtraq. Or are you using the defense stated
on my web page, discarding records on the client side of an AXFR?

> where the ISP is the *master* for the domains

Different situation, but same solution: discard all records outside the
source's bailiwick. End of problem.

> more discriminate anti-spoofing rules

Namely? Exactly what would you suggest in place of the de-facto-standard
bailiwick rule? (You realize, of course, that deploying a new rule would
take time.)

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 24 Feb 2003 15:40:56 -0800 (PST)

D. J. Bernstein writes:
> against BIND 9?

It does not.  BIND 9 is currently incapable of storing out-of-domain
glue records (i.e., records whose owner name is not a subdomain of the
zone apex), whether it is acting as a primary or a secondary.
Therefore, it will discard such records whether they are loaded from a
master file or received as part of a zone transfer.  This might be
considered either a security feature or a bug depending on your point
of view.

> source's bailiwick. End of problem.

Yes, requiring all authoritative servers (masters and slaves) to
discard out-of-domain glue would solve the problem you described.  If
we do this, slaves to conformant masters will never actually discard
any records because anything that the slave would discard has already
been discarded by the master, and the integrity of the zone will be
preserved as required in axfr-clarify section 4.

> bailiwick rule?

What Masataka Ohta suggested in August 2001:

 Ohta> I have been suggesting that these records be put in a referral-local
 Ohta> cache content of which is not used for usual A query nor glue A of
 Ohta> other referral points.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Feb 2003 00:50:42 -0000

A moment ago we were being told how vitally important it was for AXFR
clients to preserve all records received under all circumstances:

   * ``An ACURATE [sic] copy of the zone is ESSENTIAL'';
   * ``A modified zone is NOT a [sic] ACURATE [sic] copy. It's not
     even a copy. It is a derived work'';
   * ``IXFR depends upon the contents of the zone not being changed
     unilaterally on the SECONDARY'';
   * ``Bernstein still misunderstands zone coherency''; etc.

This rhetoric is supposed to convince you that the majority of AXFR
clients (BIND 8 et al.) are doing something wrong by discarding parent
glue records when they have the authoritative child records.

But now Gustafsson admits that the BIND 9 AXFR client doesn't follow
the ``zone coherency'' religion. It deliberately discards some kinds of
records! It isn't making a perfect copy of the zone! It's breaking IXFR!
Here's the quote: ``BIND 9 ... will discard [these] records whether they
are loaded from a master file or received as part of a zone transfer.''

To summarize: Not only is the BIND company (1) fraudulently labelling
its religion as a ``clarification'' and (2) fraudulently claiming
``consensus'' on the religion over the objections of several people,
but it is also (3) deliberately disobeying its own commandments.

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 24 Feb 2003 20:50:18 -0800 (PST)

> records! It isn't making a perfect copy of the zone! It's breaking IXFR!

BIND 9 is doing what you yourself said it "must" do.

This does not by itself break IXFR.  In theory, IXFR can break when
the zone transfer graph contains both servers that fully support
out-of-zone glue and servers that do not, but in practice no servers
support out-of-zone glue and the problem does not occur.  This is of
course another argument for completely outlawing out-of-zone glue in
both masters and slaves as you already suggested doing for security
reasons.  Mandating support for out-of-zone glue everywhere would also
work, but outlawing it does seem like the more realistic approach.

In practice, IXFR failures are likely to be caused by inconsistencies
in-domain glue, not out-of-domain glue, and the in-domain case is what
section 4 is primarily trying to address.
-- 
Andreas Gustafsson, [email-masked]

---

From: Len Budney <[email-masked]>
Date: Tue, 25 Feb 2003 03:32:52 -0500 (EST)

On Mon, 24 Feb 2003, (Andreas Gustafsson) wrote:
>> the ``zone coherency'' religion. It deliberately discards some kinds
>> of records! It isn't making a perfect copy of the zone! It's breaking
>> IXFR!
> 

True--but it is NOT doing what Mark claimed tinydns and other
BIND 9 competitors "must" do.

--Len.

---

From: "Kandra Nygards" <[email-masked]>
Date: Tue, 25 Feb 2003 12:13:20 +0100 (CET)

> records! It isn't making a perfect copy of the zone! It's breaking
> IXFR! Here's the quote: ``BIND 9 ... will discard [these] records
> whether they are loaded from a master file or received as part of a
> zone transfer.''

Excellent point. You're perfectly right, of course.

According to my understanding of this argument, BIND9 (and tinydns etc)
must preserve any out-of-zone records it receives in an AXFR, for the
purposes of transfering a non-modified zone to other servers via AXFR.
It MAY, of course, discard such records when it loads its data from a
master file or outer source of master configuration, as well as discard
such records for non-AXFR responses to queries.

May I assume that you're supporting the AXFR-clarify draft as long as the
above clarification is made?

Best regards
Kandra Nygards

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 25 Feb 2003 18:52:43 +0100 (CET)

> purposes of transfering a non-modified zone to other servers via AXFR.

Yes, specifically (section 4, paragraph 4 of axfr-clarify-05):

   The slave MUST associate the RRs received in a zone transfer with the
   specific zone being transferred, and maintain that association for
   purposes of acting as a master in outgoing transfers.

> such records for non-AXFR responses to queries.

Yes, specifically section 4, paragraph 3:

   Therefore, in a zone transfer the master MUST send exactly those
   records that are associated with the zone, whether or not their owner
   names would be considered to be "in" the zone for purposes of
   resolution, and whether or not they would be eligible for use as glue
   in responses.

'Exactly' in this instance should imply that case is preserved, as per
1035 2.3.3 , although you'd only get into trouble with not doing this when
tossing IDN zones around.

> above clarification is made?

You seem to be 35 days early.

--==--
Bruce.

---

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

Kandra Nygards writes:
> May I assume that you're supporting the AXFR-clarify draft as long as
> the above clarification is made?

Of course not.

The existing draft is inconsistent with RFC 1034, inconsistent with most
of the installed base, and---as Gustafsson now admits---inconsistent
with BIND 9. Your additional ``clarification'' doesn't change this; it
simply highlights BIND 9's failure to follow the rules.

Furthermore, even if the wacko zone-coherency requirements are dropped,
axfr-clarify will still need to be fixed in several other ways.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 25 Feb 2003 14:29:41 -0500 (EST)

> BIND 9 is doing what you yourself said it "must" do.

Yes. You present this as though it refutes his argument. It does not. Bind
9 does something that contradicts your claims. (you might say, "we thought
so".

> This does not by itself break IXFR.

Of course it doesn't. As we've been saying, IXFR has no relationship to
AXFR at all.  IXFR can work _without_ AXFR.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 25 Feb 2003 14:49:06 -0500 (EST)

Dan, Kanda: Do you support the clarification with these changes:

I'll write up the draft with these changes, if you agree.

++++++++++ repost from last week

++++++++++++++++++++++++++++++++++

		--Dean

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 25 Feb 2003 18:17:50 -0800 (PST)

> tossing IDN zones around.

RFC1035 section 2.3.3 says case should be preserved "when possible",
but also notes that there are cases where it is not possible.  It is
not always possible to preserve case in zone transfers because of
domain name compression in the transfer messages, and I did not mean
to imply that case would be preserved.

IDN must deal with case not being preserved, and as far as I know it
does.  So does IXFR.
-- 
Andreas Gustafsson, [email-masked]

---

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

> I'll write up the draft with these changes, if you agree.

The existing draft was shoved into Last Call with huge problems. I'm
still waiting for it to be withdrawn (or rejected).

There are obviously bigger problems here than clarification of the AXFR
protocol. The discussion has revealed a huge gap between

   * RFC 1034, which simplifies software but demands that administrators
     maintain exact glue consistency, and

   * the ``zone coherency'' cult, which removes some administrative
     requirements (but not all) while demanding that AXFR clients (but
     not other clients) maintain exact copies of zones no matter how
     inconsistent those zones are---a rule that even BIND 9 violates.

The real world is somewhere between these extremes. Perhaps we can have
a rational cost-benefit discussion, now that BIND 9's disobedience of
the cult has been exposed.

Meanwhile, http://cr.yp.to/djbdns/axfr-notes.html covers several issues
that aren't covered in axfr-clarify.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 27 Feb 2003 12:09:06 -0500 (EST)

> still waiting for it to be withdrawn (or rejected).

I agree that the curent version is unacceptable, though, we also (I think)
agree that AXFR does need to be clarified.  We could reject the current
document and resubmit a new one, or we could extensively modify the
current one.  Is there any benefit to doing this one way over the other
way?

> protocol. The discussion has revealed a huge gap between

We should add:

====
It is the responsibility of extended AXFR clients to preserve
compatibility with un-extended AXFR servers.
====

I think the issue with AXFR responses was addressed consistently with the
comments on your page.

Your comment about atomic retrieval of Zone Contents is supported by RFC
1035 Section 6.3 Second Paragraph.  This doesn't seem ambiguous to me.

I had proposed deleting section 3.4 of the clarify draft.  However, it
seems that to support concurrent UDP zone tranfers, either the question
section must be used, or the ID must be supplied by the AXFR server.

I also just noticed that I don't see anywhere that TCP is required for
AXFR. If UDP is to be used (why?), then one needs the ID in all UDP
packets.  Over TCP, unless non-AXFR data is to be intermixed in the TCP
connection, neither the ID nore the question matters. Including the ID in
all packets would permit multiplexing over TCP.  I'm for this, in general,
but it wasn't done previously. It could be the topic of a modified AXFR
proposal.  So, the clarification should also say that TCP is required for
AXFR. The question and ID sections are not required. Presence of the ID
and question sections in the responses should be accepted and ignored by
all AXFR clients. Neither client nor server is not allowed to interleave
questions or responses over the same TCP connection during an AXFR.

Regarding Poison, I think that such records could be discarded, but I
wonder whether it is necessary to require such records be removed.  It
seems to me to be enough to allow administrators and implementations to
remove such records, by removing the proposed requirement that no data
ever be deleted.  So I think that no further clarification is required.
This also addresses the database indexing issue.

Regarding the parent/child descrepancies, I think we have now demonstrated
that IXFR has no bearing on AXFR, and similar to the previous paragraph,
the implementation is free to discard such records.

However, I would like to move on the clarification, to clarify what the
existing AXFR definitely is and definitely is not, the way it was pre-bind
9.

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 28 Feb 2003 16:06:35 -0800 (PST)

On the IETF list, Claus Färber wrote:
> I think the only requirement that's really essential is that the serial
> number changes whenever the data that would be returned by a zone
> transfer changes (even if that breaks database consistency for the SOA
> record's serial number).

It is also essential that two different authoritative servers that
show the same serial number actually serve the same data.

> One strategy to implement this would be to keep an exact copy of a zone
> obtained from other servers for outgoing transfers (so you'll always use
> the original serial number), which is the BIND 9 strategy.
> 
> Another strategy would be to just increment the serial number of a zone
> when it is actually changed by importing glue records from another zone.
> This would solve the synchronisation problem, too: If the parent zone is
> updated too early, the server might throw away the glue record. But it
> will update the parent zone and increase its the serial number when it
> gets an up-to-date copy of the child zone.

In principle, this approach could work on the primary master server
(at least assuming the zone serial number is being maintained by the
server rather than the administrator), but it won't work on a slave.

If a slave "imports" glue into a zone, it can't update the serial
number, and even if it could, that wouldn't make the zone contents
consistent with the master.

Followups to namedroppers, please.
-- 
Andreas Gustafsson, [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 1 Mar 2003 00:43:19 -0000

> show the same serial number actually serve the same data.

That's a wild exaggeration. For example, a pure slave can do anything it
wants with its serial numbers. In fact, unless one slave pulls the zone
from two different masters, serial-number coherency is irrelevant.