Subject: axfr-clarify's fraudulent claims of consensus

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

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

---

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)

Dean Anderson writes:
> 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).

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?

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

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.

> It seems quite odd that a "clarification" would put 77% of the existing
> 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.

> Consensus on the part of Bind proponents, yes. Consensus when the wider
> 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 13:48:09 -0500 (EST)

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

> 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]
Date: Fri, 14 Feb 2003 17:34:24 -0500

> complaints about fraudulent labeling and discription of the proposal.

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: "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

> 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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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: [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: 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: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 18 Feb 2003 10:19:19 +0100

--On fredag, februar 14, 2003 17:57:45 -0500 Dean Anderson <[email-masked]> 
wrote:

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

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: [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: "D. J. Bernstein" <[email-masked]>
Date: 19 Feb 2003 05:44:54 -0000

Kevin Darcy writes:
> RFC 1034 requires matching NS record sets in the parent 
> 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: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: 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: Joe Baptista <[email-masked]>
Date: Wed, 19 Feb 2003 09:52:10 -0500 (EST)

> lying; why are you condoning dishonest behavior?

maybe it's because the bind company is a vixie thingy.  and we all know a
good portion of the i$ociety owe saint vixie.

regards
joe baptista

---

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: "Tomson Eric \(Yahoo.fr\)" <[email-masked]>
Date: Wed, 19 Feb 2003 19:05:09 +0100

Just three questions :

1/does the IETF support or contest the "Inclusive Name Space" (the one
operated by NewRoot instead of the ICANN)?

2/is this list reserved for all IETF-supporting people only, or is it
also open to IETF opponents/challengers?

3/knowing that the Internet Society is the only official body amongst
all the Internet-related structures (IETF, IAB, IESG, etc.), created to
host all of them, is it decent and acceptable to dispute/oppose/mock it,
here in this list?

Just asking...

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 19 Feb 2003 19:47:53 +0100

> operated by NewRoot instead of the ICANN)?

See RFC 2826; the IAB thinks that one root is enough.

> also open to IETF opponents/challengers?

You have adressed three lists.

[email-masked] exists as an open forum to further the work of the IETF.
  Its charter can be found on http://www.ietf.org/maillist.html
[email-masked] exists to communicate with the Internet Engineering Steering
  Group (IESG).
[email-masked] exists as an open forum to further the work
  of the DNSEXT IETF working group, described in
  http://www2.ietf.org/html.charters/dnsext-charter.html

None of the lists restrict who can post to it (apart from spam control).
On both of the open lists, repeated posting of material irrelevant to the 
purpose of the list can lead to your posting privilleges being restricted.

This has nothing to do with what you think, or say, and everything to do 
with the forum in which you choose to say it.

> host all of them, is it decent and acceptable to dispute/oppose/mock it,

Since the IETF list ([email-masked]) is intended as a forum to disucss the 
policies of the IETF (among other things), reasoned opinions about the 
relationship between the IETF and ISOC is a valid subject for this list, no 
matter whether the person stating that opinion thinks that the relationship 
is a good thing or a bad thing.

However, it would be inappropriate to the purpose of the namedroppers list.

Mockery is not generally considered a reasoned form of opinion.

Did this answer your question?

                    Harald Alvestrand

---

From: shogunx <[email-masked]>
Date: Wed, 19 Feb 2003 01:28:15 -0500 (EST)

> operated by NewRoot instead of the ICANN)?

Dont forget the opennic www.opennic.unrated.net the pacificroot
pacificroot.org or the open root server consortium www.open-rsc.org when
addressing the topic of alternative root servers.  Notwithstanding, the
IETF is made up of individuals, each with their own perspectives and
opinions.

> also open to IETF opponents/challengers?

Without this list, and the IETF, you would not be able to send the email I
am responding to.

> host all of them, is it decent and acceptable to dispute/oppose/mock it,

Dispute all you want, if the topic is valid.  Oppose whatever you choose.
It is never a wise idea, however, to mock on of the most intelligent
collections of individuals on the planet.  Just a word to the wise.

Scott

> Just asking...

sleekfreak pirate broadcast
world tour 2002-3
live from daytona beach
http://sleekfreak.ath.cx

---

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: [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: [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: "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: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Feb 2003 09:56:34 +0100

Mr. Bernstein,

> Anyone with a shred of integrity should be opposing this fraud.

The charter for the IETF list (RFC 3005, also visible at 
http://www.ietf.org/maillist.html) includes the sentence

>  Inappropriate postings include:
>
>    - Unsolicited bulk e-mail
>    - Discussion of subjects unrelated to IETF policy, meetings,
>      activities, or technical concerns
>    - Unprofessional commentary, regardless of the general subject
>    - Announcements of conferences, events, or activities that are not
>      sponsored or endorsed by the Internet Society or IETF.
>
>   The IETF Chair, the IETF Executive Director, or a sergeant-at-arms
>   appointed by the Chair is empowered to restrict posting by a person,
>   or of a thread, when the content is inappropriate and represents a
>   pattern of abuse.

Accusations of "dishonesty" and "fraud" in a technical discussion are 
normally considered "unprofessional".

I would also want to direct your attention to RFC 3184, "IETF Guidelines 
for Conduct", which states, among other things:

>   2. IETF participants develop and test ideas impartially, without
>      finding fault with the colleague proposing the idea.
>
>      We dispute ideas by using reasoned argument, rather than through
>      intimidation or ad hominem attack.  Or, said in a somewhat more
>      IETF-like way:
>
>            "Reduce the heat and increase the light"

Note to list: The normal procedure when dealing with unprofessional conduct 
on mailing lists includes a private warning. But since mr. Bernstein has 
chosen not to accept mail from me without asking me to engage in some 
arcane ritual of admission, I have chosen to skip this step in this case.

                        Harald Alvestrand

---

From: Joe Baptista <[email-masked]>
Date: Thu, 20 Feb 2003 04:18:24 -0500 (EST)

> normally considered "unprofessional".

Harald - I must agree with the views expressed by Dr. Bernstein.  As you
know Harald I have had the pleasure of watching the i$ociety these past 10
years and the facts clearly show many members of the same use dishonesty
and fraud as their currency of choice.

> >      intimidation or ad hominem attack.  Or, said in a somewhat more

yes - thats one thing thats nice about the ietf.  at least when it works.

love and kisses
joe baptista

Joe Baptista - only at www.baptista.god

          .film domain registration available at http://www.register.film
             another inclusive namespace Top Level Domain

---

From: grenville armitage <[email-masked]>
Date: Fri, 21 Feb 2003 01:01:51 +1100

Harald Tveit Alvestrand wrote:
	[..]
> normally considered "unprofessional".

I'm finding Bernstein's commentary to be robust and colorful (and at times
obtuse, for I'm not a DNS weenie and the relevant details usually elude me).
But not even beginning to get as close to 'unprofessional' as I've seen
on IETF mailing lists over the years.

"Be liberal in what you accept" seems a good philosophy for reading this
list...

cheers,
gja
-- 
Grenville Armitage
http://caia.swin.edu.au

---

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: 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: [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: "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: "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: [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: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 21 Feb 2003 16:32:40 +0100

> "Be liberal in what you accept" seems a good philosophy for reading 

As a very intelligent man told me once - "The good thing about 
'Subject' is that you know what you can delete without reading it".

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 21 Feb 2003 16:32:40 +0100

- kurtis -

_______________________________________________
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: Dean Anderson <[email-masked]>
Date: Fri, 14 Feb 2003 17:57:45 -0500 (EST)

--Dean

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 20 Feb 2003 15:29:12 +0000 (GMT)

> > normally considered "unprofessional".

...when they're unsubstantiated and unproven, certainly. Is that the
case?

> "Be liberal in what you accept" seems a good philosophy for reading this

Cuts both ways.

Anyone attempting to mail bernstein will have discovered that he's not
very liberal in what he accepts.

Anyone attempting to read bernstein will have discovered that he's not
very conservative in what he sends.

I have to keep reminding myself than bernstein is NOT a teenager, and
that I really shouldn't be making allowances for his age.

L.

---

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: John Stracke <[email-masked]>
Date: Wed, 19 Feb 2003 13:24:57 -0500

>operated by NewRoot instead of the ICANN)?
RFC-2826 answers this.

-- 
/===========================================================\
|John Stracke      [email-masked]                    |
|Principal Engineer|http://www.centive.com                  |
|Centive           |My opinions are my own.                 |
|===========================================================|
|A computer without Windows is like a chocolate cake without|
|mustard.                                                   |
\===========================================================/