Subject: Re: axfr-clarify's fraudulent claims of consensus

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

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

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

		--Dean

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

> On Fri, 14 Feb 2003 13:48:09 EST, Dean Anderson said:
>
> > 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.
>
> 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
>
>

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

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

		--Dean

On Fri, 14 Feb 2003, Rob Austein wrote:

> At Fri, 14 Feb 2003 17:25:40 -0500 (EST), Dean Anderson wrote:
> >
> > 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.
>
> Sorry, wrong.  Both JEEVES and CHIVES had very strict notions of zone
> boundaries, and both enforced those boundaries during zone operations.
>
> In CHIVES's case the implementation exactly matched the suggestion
> that Andreas quoted from RFC 1035 6.1.2.  I no longer remember the
> precise implementation details in JEEVES's case, but since JEEVES was
> written by the author of RFC 1035, I would be rather surprised if the
> author had not followed his own suggestion.
>
> --

---

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

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

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

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

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

No ... you could write that as

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

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

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

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

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

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

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

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

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

It is entirely possible that Randy interpreted the comment differently.

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

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

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

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

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

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

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

kre

---

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

Aaron Swartz wrote:

> Kevin Darcy wrote:
>
>> the thousands of dollars we waste every year because of inefficient 
>> zone transfers
>
>
> If you're serious, then you should switch to gzipped rsync 
> immediately. I bet you'll save far more than you will with IXFR. I'm 
> sure you can find someone who will set it up for you in return for 
> thousands of dollars. 

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

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

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

                                                - Kevin

---

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

> design decisions should stand in the way of that.

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

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

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

		--Dean

---

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

Kandra_Nyg=E5rds <[email-masked]> wrote:

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

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

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

-Peter

---

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

Dean,

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

Rgds,
-drc

---

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

I presume you mean this:

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

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

		--Dean

---

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

> This is a true and fair criticism.

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

Rgds,
-drc

---

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

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

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

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

---

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

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

	The administrator cannot avoid breaking the rule.  All they
	can do is ensure that the time the rule is broken is
	minimised.
 
> 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.

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

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

---

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

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

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

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

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

--Len.