Subject: Re: in support of axfr-clarify

From: [email-masked]
Date: Sun, 01 Dec 2002 09:17:28 +1100

Dan stop demanding that we don't specify what is required
	to make AXFR work reliably rather than being like a child's
	game of "... whispers".  "... whispers" is a fun game at
	childrens parties but not appropriate for transfering
	zones around.

	AXFR is quite capable of transfering a zone across a AXFR
	transfer graph provided the servers in the middle don't
	alter the contents.

	What comes out the other end of a AXFR graph should be
	independent of what other zones are being served by the
	servers involved.

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

--
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: Danny Mayer <[email-masked]>
Date: Sun, 01 Dec 2002 17:40:08 -0500

At 11:27 PM 11/29/02, D. J. Bernstein wrote:
>Mayer claimed ``You can't clarify without breaking something.'' Is there
>anyone else here who doesn't understand how ridiculous that claim is?

It's not ridiculous. In this case, whatever you do will result in someone
being in nonconformance with the proposed spec.

>BIND company consultant Danny Mayer writes:
> > I am not and never have been an employee of either ISC or Nominum.
>
>I apologize for the error. The fact remains that you're not disclosing
>your financial interests in BIND.

I have no financial interests in BIND, though I see no need to discuss
my financial interests in anything, least of all to you. If I make use of
BIND in the course of my employment or in pursuance of new
employment, do you consider that a financial interest?

> > Since it's ambiguous, people have made different interpretations of
> > the spec resulting in compatibility problems.
>
>A typical implementation difference---whether or not it is caused by
>different interpretations of the spec---does _not_ cause any failures.

If you would read that sentence again, I didn't say anything about
failures. What you get as a result is that two authorative servers
for the same zone which use AXFR to transfer zones from one to the
other can give you answers if the zone transfer is done where each
server has a different implementation of the protocol based on different
interpretation of the spec.

>For example, some AXFR servers insert glue records everywhere they're
>used, while some AXFR servers insert each glue record exactly once.
>AXFR clients can handle either approach. There are no failures here.

Noone said anything about failures. The discussion is about consistency.
The AXFR clients, as you call them, don't get to pick and choose, it's
the server that is making all of the decisions here.

>Explaining that servers can repeat records, and requiring clients to
>handle repetitions, would be a clarification of the protocol. It would
>not cause any failures. It would save time for future implementors, and
>reduce the chance of careless implementors screwing up.

I'm not even sure why you are arguing about this since your idea of zone
transfers use rsync, etc. Why should this even bother you? Why are
you so terrified by this proposal?

Danny

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 2 Dec 2002 12:29:10 -0800 (PST)

> anyone else here who doesn't understand how ridiculous that claim is?

For the record, I also find Mayer's claim ridiculous.

The axfr-clarify specification does not "break" anything - it
maintains full compatibility with existing implementations.  While
some existing implementations don't _conform_ to the specification,
all known existing implementations do _interoperate_ with conforming
implementations.

> handle repetitions, would be a clarification of the protocol.

That's what the draft says:

   The transmission order of all other RRs in the zone is undefined.
   Each of them SHOULD be transmitted only once, and slaves MUST ignore
   any duplicate RRs received.

-- 
Andreas Gustafsson, [email-masked]

---

From: Danny Mayer <[email-masked]>
Date: Mon, 02 Dec 2002 22:06:44 -0500

>all known existing implementations do _interoperate_ with conforming

To clarify myself, I phrased this badly. I should have said that a server
that previously conformed to RFC's based on their being multiple
possible interpretations of those RFC's may be non-compliant with
this draft and would need to be changed in order to be compliant.
Breaking was a badly chosen word.

The other part of this question is this: If you have two servers, one a
master and the other the slave for a specific zone and the slave uses
AXFR to transfer the zone from the master, can the slave ever give
different answers to queries than what the master would respond as
a result of the received zone? If the answer is yes, something is wrong
since you should get the same answer no matter which authorative
server you ask. That's what I meant by broken. Does that make more
sense?

Danny

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Dec 2002 08:13:11 -0000

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

Danny Mayer writes:
> If you have two servers, one a master and the other the slave for a
> specific zone and the slave uses AXFR to transfer the zone from the
> master, can the slave ever give different answers to queries than what
> the master would respond as a result of the received zone?

Yes, of course. Suppose the server is also a slave for a child zone from
another master. If there's an inconsistency between the two masters,
it's obviously impossible to simultaneously (1) match what the parent
zone master says and (2) match what the child zone master says.

It's possible to match both for AXFR requests, as axfr-clarify demands,
but it's simply impossible to match both for normal queries, because
queries don't name zones. Matching is not part of the DNS protocol.

(See my message <[email-masked]> for an analysis of
what the protocol says about these inconsistencies.)

> If the answer is yes, something is wrong since you should get the same
> answer no matter which authorative server you ask. That's what I meant
> by broken.

You are fundamentally confused about how DNS works. See above.

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Dec 2002 19:38:12 -0000

Danny ``I am not and never have been an employee of ... Nominum'' Mayer,
who in other forums has identified himself as a Senior Software Engineer
> Noone said anything about failures. The discussion is about consistency.

So you're demanding that an implementation decision be prohibited simply
because it's different from a decision in your implementation---even
though you admit that it interoperates just fine.

Even if you don't understand how ridiculous this demand is, surely you
can understand that it violates section 6 of RFC 2119.

> whatever you do will result in someone being in nonconformance with
> the proposed spec.

That's blatantly incorrect. I already gave you an obvious example of a
useful clarification that wouldn't declare current practice to be
non-compliant. The only reason for a clarification to make such a
declaration is when there's an interoperability problem---a conflict
between implementations that has to be fixed by one side or the other.

> I have no financial interests in BIND

Liar. Is your pretense of independence part of the BIND company's
strategy for packing this standards committee, or have other BIND
company people been quietly warning you that you should fess up?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Dec 2002 20:14:00 -0000

Andreas Gustafsson writes:
> Each of them SHOULD be transmitted only once

That blatantly violates RFC 2119, section 6.

> That's what the draft says

And I have no objection to the draft saying that. What I object to in
this area is the draft saying more---this ludicrous BIND-8-violating
``clarification'' that records ``SHOULD be transmitted only once.''
According to RFC 2119, this means that

   there may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course

which nobody claims is true in this case.

I shouldn't have to say these things even once. The fact that I have to
keep saying them---Gustafsson simply waits a few months and tries again;
nothing is officially recorded in a usable form; nothing is learned---
reflects a serious deficiency in the IETF procedures.

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 03 Dec 2002 17:44:52 -0500

> That blatantly violates RFC 2119, section 6.

No it doesn't. The "no repeat" provision of the draft merely restates RFC 2181,
Section 5.5, which is not limited in applicability to only
"ordinary" DNS replies. Feel free to argue that RFC 2181 is incompatible with
RFC 2119, Section 6, but I think it's a little late for that...

- Kevin

---

From: David Conrad <[email-masked]>
Date: Tue, 03 Dec 2002 15:23:55 -0800

Bernstein,

I've put up with quite a bit of your libel on this thread, but I've had
enough.

On 12/3/02 11:38 AM, "D. J. Bernstein" <[email-masked]> wrote:
> [ post by non-subscriber.

You really should get this fixed.  Perhaps you should hire a consultant if
you can't figure out how to do it yourself.

> Danny ``I am not and never have been an employee of ... Nominum'' Mayer,

To be clear, Danny did some contract work for Nominum (porting BINDv9 to
Win32) in the past.  He was never an employee and we currently don't have a
contract with him.  Perhaps you could hire him to help you with subscribing
to namedroppers?

> company people been quietly warning you that you should fess up?

Careful of the libelous accusations you throw around Bernstein, particularly
as you yourself are so quick to throw threats of lawsuits around.

Do you have any proof that "the BIND company" (who is this, exactly?) is
"packing this standards committee"?  If so, present it.  Otherwise admit
that you are the liar and send a retraction.

Disgusted,
-drc

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 3 Dec 2002 15:29:56 -0800 (PST)

> which nobody claims is true in this case.

I would certainly want implementers to understand and carefully weigh
the implications of multiple transmission, such as waste of bandwidth
and receiver CPU time.  Are you suggesting they should not?

RFC 2119 section 6 says imperatives (e.g., MUST or SHOULD) "MUST only
be used where it is actually required for interoperation or to to
limit behavior which has potential for causing harm (e.g., limiting
retransmisssions)".  This would be the latter case.  Incidentally, I
found it amusing that the author of RFC2119 specifically chose
limiting retransmissions as the example; although he probably had a
different kind of retransmission in mind than that of transmitting
records multiple times in an AXFR, they both cause similar harm
in the form of wasted bandwidth.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Wed, 04 Dec 2002 10:39:09 +1100

> which nobody claims is true in this case.

	BIND 8 is a legacy implementation and has been for a while
	now.  What I find ludicrous is you ignoring the fact that
	it is a legacy implementation.  There are lots of things
	BIND 8 does that are against some RFC.  We wrote BIND 9 to
	address those issues.

	The full implications are that same record will be transmitted
	multiple times making the transmission process longer.  If
	the zone is stored to disk it without removal of the
	duplicates it will take up more space.  Applications that
	use the result need to be aware that there may be duplicates.
	All existing nameservers cope with this.  All namesevers
	that comform to the clarify draft will cope with this.

	These are NOT NEW implications.  They have existed as long as
	BIND has existed.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 03 Dec 2002 19:29:49 -0500

>company people been quietly warning you that you should fess up?

Fess up to what?  I had enough of your attitude.  The statement I made
is true. Repeating something ad nauseum doesn't make it true.

>Statistics, and Computer Science, University of Illinois at Chicago

For someone who claims to be an assistant professor you are acting
very childishly. There are almost no posts that you have made to this
forum or others on almost any topic that I've seen that could be
described as adult. You've made every opportunity to demean, harass,
admonish, and otherwise belittle anyone who disagrees with your point
of view. Since your field is supposed to be mathematics, you should
know that theorems are supposed to be proven with unassailable logic,
not assaulted with abuse. Q.E.D. has a meaning. Stick to it. It's time
for you to grow up and become an adult.

I have no interest in and will not discuss my employment, financial
interests, or other personal information with you in this forum or
any other.

Danny

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Dec 2002 00:30:04 -0000

> No it doesn't.
  [ ... ]
> merely restates RFC 2181

I can't imagine why you think that this is relevant to my comment. As
I've pointed out before, RFC 2181 blatantly violates RFC 2119 too.

As a broader matter: ``We screwed it up before'' does not justify
``Let's screw it up again.'' The solution to problems in RFC 2181 is to
fix RFC 2181, not to copy the problems into other documents.

Note that BIND 9 clearly fails to comply with RFC 2181 (by, for example,
using an A record cached from the additional section of an MX response
to answer a subsequent A query---this is normal, desirable behavior that
is prohibited by RFC 2181), so please don't spout any religious nonsense
about RFC 2181 being an edict from the heavens.

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 03 Dec 2002 20:11:37 -0500

> about RFC 2181 being an edict from the heavens.

It's not an edict from the heavens, but it is a prevailing DNS standard. Get over
it. The time for gauging "rough concensus" on the "don't repeat records" part of
the DNS protocol specification is long past, and the fact that axfr-clarify
restates the rule doesn't give you another chance to turn back the hand of
progress.

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Dec 2002 01:10:44 -0000

> and receiver CPU time.  Are you suggesting they should not?

Yes or no: Are you claiming that every DNS implementor, before choosing
to use (for example) BIND 8's strategy of sending glue whenever it's
referenced, _must_ understand and carefully weigh the implications?

That's the definition of ``SHOULD'' in RFC 2119. It's a mechanism to
warn implementors about behaviors that are interoperable but dangerous;
see RFC 2119, section 6. It isn't an excuse for you to have your BIND 9
implementation decisions masquerading as protocol requirements.

Are you next going to claim that people ``SHOULD NOT'' put DNS records
into LDAP? Look at all that wasted bandwidth and CPU time!

As another example, you're wasting tons of bandwidth by using zone
transfers (incremental but not compressed) rather than rsync-over-ssh
(incremental _and_ compressed). Have you understood and carefully
weighed the implications of your poor choice of protocols? How would you
like it if someone said that you ``SHOULD NOT'' use zone transfers?

Andreas Gustafsson writes:
> Incidentally, I found it amusing that the author of RFC2119
> specifically chose limiting retransmissions as the example; although
> he probably had a different kind of retransmission in mind than that
> of transmitting records multiple times in an AXFR, they both cause 
> similar harm in the form of wasted bandwidth.

Wow, are you really this ignorant? The retransmission issue has nothing
to do with optimizing bandwidth use. The retransmission issue is that
momentary network overloads can snowball into nearly complete outages.

If people really are misusing ``SHOULD'' for minor efficiency issues
(misinterpreting ``harm'' in section 6 of RFC 2119), we're going to need
a new word to point out real dangers such as over-eager retransmission.

---

From: [email-masked]
Date: Tue, 3 Dec 2002 17:21:13 -0800 (PST)

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

> > Is your pretense of independence part of the BIND company's
> > strategy for packing this standards committee, 
> >  -- sez djb
> 

	More humourous, perhaps, is the delusion that a mailing list 
	is a masquerade for a standards committee.  

	Dun & Bradstreet do not appear to have a listing for any company
	named "BIND" that has DNS software as a product.  Perhaps 
	the "DJBDNS company" representative is playing fast and loose
	with pejoritive statements to attempt to incite non-productive
	dialog?

	I expect that a more productive tactic would be for the "DJBDNS
	company" representative to write an ID to debate/discuss the 
	relative merits of the existing ID under discussion and propose substantive
	alternatives that are more inclusive and advance the state of art
	of the Domain Name System.  Promotion of better ideas works lots 
	better than castigation of ideas that are distastful, for what 
	ever reason. 

	As for me, I want a strong, robust, evolving system that has "genetic"
	diversity in the code base.  

--bill

---

From: "Kandra Nygards" <[email-masked]>
Date: Wed, 4 Dec 2002 12:56:34 +0100 (CET)

> weighed the implications of your poor choice of protocols? How would
> you like it if someone said that you ``SHOULD NOT'' use zone transfers?

Once again...

Rsync and ssh has exactly *WHAT* to do with DNS? As for poor choice of
protocols, I personally feel that DNS is a rather good choice of protocol
for doing things DNS related, but then again, that's just me.

Now, could we please focus here? This discussion is about the axfr-clarify
draft. It's not about proper mailinglist behaviour, it's not about rsync
or ssh, it's not about alternate methods for tranfering zones. It's most
definitely not about Mark's wife, and it's not about Danny's employment.
In fact, believe it or not, it's about the axfr-clarify draft.
Now, Dan, your original objections to the axfr-clarify draft was that it
prohibited the behaviour of your software on a number of points, which you
claimed was in violation of RFC 2119. Those issues have been discussed.
Some people, myself included, feel that they have been resolved. Some
people do not. If you have anything further to say regarding those
specific issues, please feel free to speak up. If you have any other
issues regarding this particular draft that need to be adressed, feel free
to bring THEM up. If not, then could we please focus on the work at hand,
namely to decide if we have a rough consensus on the draft or not and
proceed accordingly.
Also, I would appreciate if we could please limit the namecalling, libel,
insults and flames to a maximum of one email per person per day. That way
it'll be easier for archive readers to find out who's doing what to who's
dog.
My quota for today would therefore be to ask Dan if his DNS-software is
IPv8 compliant yet.

Best regards,
Kandra Nygards

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 4 Dec 2002 10:30:24 -0800 (PST)

> referenced, _must_ understand and carefully weigh the implications?

Yes.

> a new word to point out real dangers such as over-eager retransmission.

We already have one.  It's called MUST.
-- 
Andreas Gustafsson, [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Dec 2002 20:49:41 -0000

> > referenced, _must_ understand and carefully weigh the implications?

Let me get this straight. Because the BIND 4/8 strategy (for the sake of
server simplicity) generates slightly more traffic (for some zones), you
conclude that every DNS implementor _must_ understand and carefully
weigh the implications before choosing that strategy?

After many years of BIND 4/8 working just fine without anybody worrying
about this, why did this suddenly become an issue? Maybe the .com
administrators care, but how does that justify demanding that _every_
implementor worry about this? Are you sure that you aren't wildly
exaggerating the importance of an absurdly small issue?

Do you also conclude that every DNS implementor _must_ understand and
carefully weigh the implications before putting DNS records into LDAP?
(``DNS servers SHOULD NOT use LDAP.'') And that every DNS implementor
_must_ understand and carefully weigh the implications before attempting
to use EDNS0? (``DNS servers SHOULD NOT use EDNS0.'')

If the last two answers are no: What, precisely, is the relevant
difference between these situations and the repeated-glue situation?
Don't you agree that these things generate more traffic? A moment ago
you said how important it was for all implementors to pay attention to
efficiency issues; are you retreating from that principle?

How would you like it if other people tried to force you to imitate
their implementation decisions by declaring that implementations SHOULD
make those decisions---never mind actual costs and benefits?

> We already have one.  It's called MUST.

I'm cc'ing this to Bradner. RFC 2119 is obviously meant to stop people
from pretending that every implementation decision is a protocol issue;
it is not succeeding at this goal.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Dec 2002 07:49:22 -0000

BIND company director David Conrad writes:
> Do you have any proof that "the BIND company" (who is this, exactly?)

See http://cr.yp.to/djbdns/blurb/bindmoney.html.

> is "packing this standards committee"?

The decisions are being made by Gudmundsson, who has been paid for
working on BIND, and Bush, whose biases are obvious from an inspection
of the messages that he has censored. Practically all of the promotion
of axfr-clarify has come from BIND company people. Even worse, some of
those people haven't disclosed their connection to the BIND company.

---

From: David Conrad <[email-masked]>
Date: Thu, 5 Dec 2002 08:41:39 -0800

Bernstein,

You are a liar.  An incompetent one at that.

Rgds,
-drc

On Wednesday, December 4, 2002, at 11:49  PM, liar D. J. Bernstein

---

From: Danny Mayer <[email-masked]>
Date: Thu, 05 Dec 2002 21:20:35 -0500

>Statistics, and Computer Science, University of Illinois at Chicago

Stop acting like a child! If you can't act like an adult and discuss issues
you shouldn't be posting at all. You say that you are a professor of
mathematics yet your postings to this list seems to consist of nothing
but attempts to harras, intimidate and browbeat the people who do not
agree with you. You don't respond to technical questions asked and you
don't support any of your technical arguments with anything but abuse.
In mathematics you prove theorems with sequential logical coherent
steps. That's what Q.E.D. is all about. Maybe you think that as a
professor of mathematics you don't think it's necessary to do that any
more. Start to act like an adult instead of a child and keep to the subjects
for which this forum is designed.

Danny