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

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

> [email-masked] writes:
> > 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.

	It does not.

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

	Well as we keep pointing out your software is BROKEN.
 
> 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.

	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.

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

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

> 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.
>
> 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.
>
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> 
> --
> 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: Kevin Darcy <[email-masked]>
Date: Mon, 17 Feb 2003 13:02:05 -0500

Lloyd Wood wrote:

>[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>  and therefore delete posts by non-subscribers.  if you wish to regularly
>  post from an address that is not subscribed to this mailing list, send a
>  message to <listname>[email-masked] and ask to have the alternate
>  address added to the list of addresses from which submissions are
>  automatically accepted. ]
>
>On Sat, 15 Feb 2003 [email-masked] wrote:
>
>  
>
>Saying it's broken implies the act of breakage.
>
>At what point was the software NOT broken?
>
"Broken" is a jargon term. In the context of software design, it denotes 
failure to conform to the relevant specifications.

                                            - Kevin

---

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

> At what point was the software NOT broken?

	In the original design specs.  RFC 1034 and RFC 1035.  If
	they had been followed then we wouldn't be havin this
	discussion.
 
	Mark
> L.
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

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

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

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

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

Here is how the above sounds 

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

--- Then the software has a problem.

Is this logic intentional?

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

---

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

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

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

The appropriate pseudo-syllogism, if any, is:

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

R is sometimes not met

=> Software D's assumption is sometimes false

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

                                        - Kevin

---

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

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

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

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

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

> RFC 1034 requires matching NS record sets in the parent 

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

Mate
---

---

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

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

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

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

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

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

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

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

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

                    - Kevin

---

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

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

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

Alexis

---

From: [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:
> 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: 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: 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 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.''