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

From: bert hubert <[email-masked]>
Date: Tue, 11 Feb 2003 09:23:55 +0100

On Mon, Feb 10, 2003 at 11:59:42AM -0500, The IESG wrote:

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

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

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 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: [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 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 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: 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: 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: "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.