Subject: Re: in support of axfr-clarify

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

--
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: [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: [email-masked]
Date: Wed, 04 Dec 2002 09:11:01 +1100

> queries don't name zones. Matching is not part of the DNS protocol.

	We are talking about AXFR (IXFR) not queries other than AXFR (IXFR).
	Queries other than AXFR (IXFR) are already addressed in RFC 2181.
 
> You are fundamentally confused about how DNS works. See above.

	No Don your concept of the DNS is fundementally broken if you
	believe that you should get different results to AXFR queries
	to each of the server for the zone when the zone is in steady
	state.

	So that there is no confusion about what I mean about the same
	answer.  After removal of duplicate records, down casing
	all domainnames in the zone and sorting the resulting data
	should be the same.

	Mark

--
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: 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: [email-masked]
Date: Thu, 05 Dec 2002 10:38:35 +1100

> weigh the implications before choosing that strategy?

	Yes.  The world is changing and zones are getting MUCH bigger.

	Part of the response to that was to support sending multiple
	records in one message so that the transfer could take
	advantage of DNS label compression.  The second response
	was to eliminate the duplicate records.
 
> exaggerating the importance of an absurdly small issue?

	Where do you think the large zone operators get there servers
	from?  They normally don't roll their own.  Large zones are
	just one thing a implementor must think of when designing
	a nameserver.

	Transmission times have been a problem in the past.  They
	currently arn't but DNSSEC is just around the corner and
	with DNSSEC comes a large increase in the volume of data
	that has to be transmitted.
 
	Also as a implementor it is not normally your bandwith (money)
	that is being wasted.

> to use EDNS0? (``DNS servers SHOULD NOT use EDNS0.'')

	Yes. The choice of database backend is important.
	Yes. The choice involved in EDNS are important.
 
> make those decisions---never mind actual costs and benefits?

	No one is forcing you to send each record once.  Just to
	make sure you think about it carefully before you decided
	to send a record multiple times.
 
> it is not succeeding at this goal.

	It's not a minor issue to some zone operators.  It has in
	the past come close to causing the DNS to fail for a large
	portions of the net.
 
	Mark

---

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: David Conrad <[email-masked]>
Date: Thu, 5 Dec 2002 11:47:35 -0800

Yowsa.

Based on the number of private email I've received, it appears the 
Danster is nothing if not consistent about lying.

To forestall additional requests: I will not expand on namedroppers on 
the myriad lies, half-truths, misconceptions, irrelevancies, and down 
right stupidities on Bernstein's web site -- the signal to noise is low 
enough already.

Perhaps a separate mailing list should be set up (maybe 'djblies'?), to 
which observations of Bernstein's deceits could be sent?  Problem is, 
it'd be a high volume list...

Rgds,
-drc

---

From: Dean Anderson <[email-masked]>
Date: Thu, 5 Dec 2002 15:27:55 -0500 (EST)

I'd like to be on that list. I looked at the page Bernstein posted, and I
didn't see anything on it that was false.  I'm on some--but not all--of
the lists he quotes from and remember some of the messages he quotes. I'm
sure they can be found in archives of those lists.  Accusations of lying
are serious in an acedemic/professional setting.  People stake their
credentials on such things. I'd like to investigate these claims offline,
and report back on findings. I think the name of the should be
djb-investigators so as to not appear prejudical.

		--Dean

---

From: Aaron Swartz <[email-masked]>
Date: Thu, 5 Dec 2002 14:29:27 -0600

David Conrad wrote:
> Perhaps a separate mailing list should be set up (maybe 'djblies'?), 
> to which observations of Bernstein's deceits could be sent?

I've set up [email-masked] for discussion of D. J. Bernstein. 
To subscribe, send an empty message to 
[email-masked].

-- 
Aaron Swartz [http://www.aaronsw.com]
I'll be in SanFran for the Creative Commons launch the week of Dec15.

---

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

---

From: Joe Baptista <[email-masked]>
Date: Fri, 6 Dec 2002 04:47:09 -0500 (EST)

> it'd be a high volume list...

I've kept my eye on you over the years.  Your nasty sometimes.

regards
joe baptista

---

From: Dean Anderson <[email-masked]>
Date: Fri, 6 Dec 2002 13:58:27 -0500 (EST)

Bernsteins reaction is a natural response to harrassment, and deceptive
labeling regarding axfr-clarify.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 6 Dec 2002 14:10:45 -0500 (EST)

Has anyone noticed that when DJB posts, the prefix message looks
like this:

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

While other people's look like this:

>   automatically accepted. ]

Does anyone else find it strange that these should be different?

---

From: Danny Mayer <[email-masked]>
Date: Fri, 06 Dec 2002 16:10:23 -0500

>labeling regarding axfr-clarify.

Yes, the natural response of a child who resorts to threads, abuse, 
harrassment,
yells and screams to get their way, rather than a reasoned response. All this
from a professor.

Danny

---

From: Dean Anderson <[email-masked]>
Date: Sat, 7 Dec 2002 11:34:47 -0500 (EST)

None of this is accurate.

He may be yelling, but it is a result of sustained abuse over a long, long
period of time. Frankly, I wouldn't be nearly as patient.

		--Dean

---

From: Danny Mayer <[email-masked]>
Date: Sat, 07 Dec 2002 14:55:02 -0500

Someone who constantly heaps abuse on people even when they're
attempting to discuss issues for which this mailing list is designed
shouldn't expect sympathy from anyone. It's very childish.

Can we please get back to discussing issues?

Danny

---

From: Dean Anderson <[email-masked]>
Date: Sun, 8 Dec 2002 12:42:40 -0500 (EST)

Indeed, you are correct. It is very childish to abuse someone attempting
to discuss real issues.  Can we please stop abusing and maligning Dan
Bernstein?

By contrast, Dan seems to have valid points, while you don't.

		--Dean

---

From: Danny Mayer <[email-masked]>
Date: Mon, 09 Dec 2002 00:08:25 -0500

>By contrast, Dan seems to have valid points, while you don't.

You're confusing me with someone else.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 09 Dec 2002 00:20:16 -0500

I'd like to bring this back on track here.

I'd like to look at what rsync (as recommended by the DJBDNS company)
does and what axfr-clarify says to do.

Let us say we have two servers A and B that are authorative for a zone.
The contents of the zone reside in a file named Z on server A and in a file
named Z' on server B.

An admin adds records to file Z on server A and reloads the server. rsync
notices the change to the file and transfers the delta to server B and merges
the changes into file Z'. If I understand correctly rsync, the contents of 
file Z'
is now identical to that of Z. Server B is now reloaded and can respond to
queries on the new records.

Isn't this exactly what axfr-clarify is trying to accomplish, i.e. the records
in the zone should be transferred unchanged from server A to server B
irrespective of other information that the server may have regarding some
of the records? Why should AXFR be different in this respect from rsync?

Danny

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 9 Dec 2002 11:29:44 +0100 (CET)

Yes.

> Isn't this exactly what axfr-clarify is trying to accomplish, i.e. the records

Nearly.

> of the records? Why should AXFR be different in this respect from rsync?

The main difference between AXFR and rsync-over-ssh is that the latter
produces an exact copy of a given _file_.  The former SHOULD produce a
functionally-identical copy of a given _zone_.

( I say 'SHOULD' because a number of implementations do not produce
  functionally-identical copies, due to confusion about the existing
  definition of AXFR, as has been noted previously. )

This means, since there is no set standard for an actual zone file, that
you can only (reliably) do rsync-over-ssh if you have identical server
software on both servers.

If you have two servers using different zone file formats, that understand
AXFR, you should be able to get working transfers of zones, without having
to mess around with post-converting the zone file from one format to
another, to say nothing of a separate process to detect changes and
trigger a zone or server reload.

Hence, I support the general need for a clarification of AXFR so that
various nameserver implementations can reliably act as both primary or
secondary depending on local configuration.

--==--
Bruce.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 09 Dec 2002 07:21:01 -0500

>software on both servers.

Thank you. I should have said functionally identical. An AXFR transfer
has no defined order in the records transferred except that the first and
last records be the SOA and identical and of course any comments that
may have been in the original source file do not get transferred.

>trigger a zone or server reload.

Yes, the storage of the data can be in any format, including a database.

Danny

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Dec 2002 15:26:54 +0000

this discussion puts me in mind of the following text:

> RFC 1034             Domain Concepts and Facilities        November 1987
> 
> 4.3.5. Zone maintenance and transfers
> 
> Part of the job of a zone administrator is to maintain the zones at all
> of the name servers which are authoritative for the zone.  When the
> inevitable changes are made, they must be distributed to all of the name
> servers.  While this distribution can be accomplished using FTP or some
> other ad hoc procedure, the preferred method is the zone transfer part
> of the DNS protocol.

rsync is thus accounted for.  unless this thread intends to modify 1034's
intent, which i've seen no evidence of, can you please take it to
djbdns-workers@, or to some other implementation-specific forum?

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 09 Dec 2002 21:52:33 +0100

> secondary depending on local configuration.

I also would like to support the clarification of AXFR. The interoperable
method becomes increasingly important as different implementations take new
data storage and backend paradigms in use.[0]

As a side note: While some zones have passed the size where AFXR ceases to
be a practically feasible synchronisation method, these are in absolute
minority -- I believe they can be counted on ones fingers today. 

Those reluctant or unable to promote or use AXFR might want to document
their ideas in another draft, perhaps to DNSOP, as this is strictly a
management issue, not a protocol one. 

- -- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

[0] Out of the 4 or so implementations I've toyed with the last year, only
    one (BIND family) uses the classic file -- the others have switched to 
    databases, most often dbm hashes.

---

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

Danny Mayer writes:
> Isn't this exactly what axfr-clarify is trying to accomplish

No.

My recommended use of rsync is to replicate complete _servers_. This has
a simple meaning: the servers respond identically to every query.

What you're trying to do is replicate separate _zones_. This is a much
more complicated concept. Contrary to your previous claims, it does
_not_ mean that the servers respond identically to every query in the
zone; I explained in a previous message why that can't be true.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Dec 2002 08:31:18 -0000

Okay. Andrews has specifically endorsed the three statements

   * ``DNS servers SHOULD NOT use LDAP'' and
   * ``DNS servers SHOULD NOT use EDNS0'' and
   * ``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy''

because he claims that every DNS server implementor must understand and
carefully weigh the implications (specifically, some minor efficiency
issues) before doing any of these things.

Is this the same Andrews who has been telling everybody to use EDNS0?
``SHOULD NOT use EDNS0,'' but please use it anyway? Does he understand
how stupid he's making himself sound here?

Andrews tries to defend his silly AXFR position by saying that ``zones
are getting MUCH bigger'' and by pointing to DNSSEC. But bigger zones
and DNSSEC make BIND 8's AXFR glue strategy even _less_ of an issue! The
djbdns/BIND 9 strategy saves space _for repeated delegations_, not for
miscellaneous records.

In short, Andrews is making the ludicrous demand that every implementor
worry about the .com zone. This is a transparent attempt to hold back
progress in DNS server software.

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 10 Dec 2002 11:01:05 +0100

> a simple meaning: the servers respond identically to every query.

A cool concept. And a fringe case at best. I am hard pressed to find this
situation in large and/or widespread management domains -- most servers are
by intention or legacy somewhat unique. This also is an operational issue. 

> zone; I explained in a previous message why that can't be true.

So why are you attacking the AXFR concept by proposing something completely
different, that does not fill the same need?

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 10 Dec 2002 15:12:26 +0100 (CET)

> software on both servers.

Hrm.  There is a set standard for zone (MASTER) files in RFC1035 section 5
which I had forgotten about (and keen-eyed Bush immediately noted).  The
above paragraph thus should read:

	This means that you can only (reliably) do rsync-over-ssh if you
	have a common zone file format on both servers (eg the 'MASTER'
	zone format as per RFC1035 5.1).

--==--
Bruce.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Dec 2002 21:26:40 -0000

> A cool concept. And a fringe case at best.

In fact, even though BIND makes it unnecessarily difficult to set up,
this is an extremely popular configuration. AXFR today has two main uses:

   (1) as a clumsy mechanism of replicating servers and
   (2) as a clumsy mechanism of editing zone files remotely.

Except at companies that sell third-party DNS service, there's very
little demand for any type of replication other than server replication.
Yes, we can all point to examples such as arpa-vs.-root-servers.net, but
those examples are the fringe case.

---

From: [email-masked]
Date: Wed, 11 Dec 2002 08:54:44 +1100

>    * ``DNS servers SHOULD NOT use LDAP'' and

	I didn't say that.  And it cannot be paraphrased as that.

>    * ``DNS servers SHOULD NOT use EDNS0'' and

	I didn't say that.  And it cannot be paraphrased as that.

>    * ``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy''

	Yes. That is what ixfr-clarify says.

> how stupid he's making himself sound here?

	Go read what I said again.
 
> progress in DNS server software.

	Do you realise how stupid you sound with these ridiculous
	assertions.   Implementors should always be looking at the
	their clients needs.  If you don't want to serve big zones
	then don't deal with their needs.

	Nothing in axfr-clarify stops you sending a record multiple
	times.  No one is forcing you to only send one record.  The
	only constraint is that the SOA record is sent exactly
	twice.  Once as the first record.  Once as the last record.

	Mark

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Dec 2002 23:16:25 -0000

When normal people replicate servers, they use the same software
everywhere. For example, a normal person setting up replicated HTTP
service uses the same HTTP software on both computers. Similarly, a
normal person setting up replicated DNS service uses the same DNS
software on both computers.

There are certainly advantages to simple, stable configuration-file
formats that can be read by many programs, but these advantages are
practically irrelevant to server replication, and they're often
outweighed by the benefits of better formats.

Bruce Campbell writes:
> There is a set standard for zone (MASTER) files in RFC1035 section 5

Sorry to bother you with the facts, but the BIND company keeps changing
their zone-file format. You're kidding yourself if you think that the
format is stable. Furthermore, zone files are only part of the BIND
configuration; the named.conf format is even less stable.

---

From: Derek Atkins <[email-masked]>
Date: 10 Dec 2002 18:25:54 -0500

Dan,

Now I KNOW you're on crack.  EVERY single DNS server that I've set up
has used AXFR to do zone syncs.  The reason: each server hosts a
different set of zones.  My primary and secondary servers are not
mirrors of each other.  They are not administrated by the same set of
people.  Indeed, the BCP REQUIRES that DNS servers be
network-distributed to protect against single-point-of-failures.

Setting up axfr is simple.  I list my secondaries, and they just say
"master <my-ip-adderess>".  There.  Done.  End of configuration.  How
could setting up a secondary be any easier than that?

I would say that there is a LOT of demand for AXFR.  Everyone out
there than runs their own domain and actually follows the BCP needs
AXFR.  I'm certainly not willing to give my secondaries remote-access
(even for rsync) to my server.  Nor do I think the primaries for the
zones for which I secondary would give me similar access.

Dan, it's been a long time since our PGP V. X.509 discussions on the
bus from Morristown to Picataway (I presume you still remember that
conversation?  I certainly do!).  What I learned from that is the
notion that there are necessarily multiple ways of doing something and
not everyone agrees on the "right way".  So you need to come up with
some basic, minimal, in-band means to do what you want to do, and if
people want to do something different, out of band, you need to allow
them to do so.  In this case, you need to standardize the AXFR (the
simple in-band solution) but allow people to use the out-of-band
(rsync) method if they so choose.

However, since it is out-of-band, that implies it is out-of-scope and
therefore should be taken elsewhere.

Have a nice day,

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Dec 2002 23:57:11 -0000

Andrews claims that every DNS implementor _must_ understand and
carefully weigh the implications---specifically, a minor traffic
increase for some zones---before using BIND 8's AXFR glue strategy.
(``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy.'')

The following analogies show how silly Andrews's argument is:

   * ``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy'' because
     another strategy sometimes generates less traffic.

   * ``DNS servers SHOULD NOT use EDNS0'' because the opposite choice
     usually generates less traffic.

   * ``DNS servers SHOULD NOT use AXFR'' because rsync practically
     always generates less traffic.

   * ``DNS servers SHOULD use bzip2-compressed zone transfers instead of
     gzip-compressed zone transfers'' because bzip2 usually generates
     less traffic than gzip.

   * ``DNS servers SHOULD use gzip-compressed zone transfers instead of
     bzip2-compressed zone transfers'' because gzip usually takes less
     CPU time than bzip2.

   * ``DNS servers SHOULD NOT serve records from an LDAP database''
     because LDAP can be slow.

I could go on like this for a while. Is there anyone other than Andrews
who still doesn't understand why this is a misuse of ``SHOULD NOT''?

In a previous message, I specifically asked Andrews about some of these
examples:

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

His answer: ``Yes. The choice involved in EDNS are important.'' That's a
clear, direct, specific endorsement of ``DNS servers SHOULD NOT use
EDNS0''---but Andrews now claims that he never said that! Flip, flop,
flip, flop.

---

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

> could setting up a secondary be any easier than that?

What do you do when you change named.conf---for example, to add a zone?
You have to copy the changes to the secondary. With server replication,
this is handled automatically.

> each server hosts a different set of zones.  My primary and secondary
> servers are not mirrors of each other.  They are not administrated by
> the same set of people.

That configuration is much less popular than you appear to realize. See
http://cr.yp.to/djbdns/third-party.html for further comments.

> out-of-band (rsync)

Your notion of ``out-of-band'' is religious nonsense. Does it frighten
you that the FTP protocol uses more than one port?

---

From: [email-masked]
Date: Wed, 11 Dec 2002 12:24:55 +1100

> (``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy.'')

	This is perfect example of why the section is there.

	There you go again, not analysing the requirements.  You are
	assuming that there is always a *minor traffic increase*.
	You as a implementor are not in a position to say if a given
	increase in traffic is minor or not as you do not have
	enough details of the conditions underwhich the transmission
	is taking place.

	Mark

---

From: Derek Atkins <[email-masked]>
Date: 10 Dec 2002 20:38:34 -0500

> this is handled automatically.

If I am the primary, I email it to the maintainer of the secondardies
and say "add this section to named.conf".  If I'm the secondary, then
the admin of the primary usually contacts me with similar information.
The configuration of the zones themselves are nearly static; changing
the IP addresses of primary and secondary servers is rare -- certainly
much more rare than changing the zone data.

The point is that each DNS server is autonomous.  There is no
requirement that NS1.FOO.EXAMPLE. and NS5.BAR.EXAMPLE., which both
happen to be authoritative for the QUUX.EXAMPLE zone, be mirrors of
each other.

> you that the FTP protocol uses more than one port?

Religious nonsense, eh?  Dan, are you trying to be intentionally
belligerent or are you just unaware of how your tone comes across in
email?  I don't recall you being this quick to judge, nor do I
remember you trying to be mean or hostile, but then again I was much
younger then.  If your tone is accidental, may I suggest you "tone
down" your messages in the future?  Personally, I'm trying to have a
peaceful conversation here, and honestly I'm not sure how to interpret
your message.  Regardless, I do have to wonder how is it nonsense to
call "use protocol Y to communicate data for protocol X" out-of-band,
when protocol-X has its own way of communicating that very same data?

As for FTP, does it frighten me in what way?  The FTP spec clearly has
the PORT command documented.  It is part of the FTP protocol
specification.  I think it was a poor design choice, but then again I
wasn't there at the time it was created (and besides, that was not the
question).  No, the FTP PORT callback channel is not "out of band",
because it is just a second connection that remains part of the ftp
protocol.

No, out of band is when some protocol says to "run this _OTHER_
protocol to copy data from A to B".  Note that in this case (for DNS
zone files) I can use email, ssh, ftp, http, or even the US Postal
Service and OCR to transmit zone data.  Indeed, there are LOTS of
"out-of-band" means to transfer the data.  There are, however, two
"in-band" methods defined by the DNS specification, called AXFR and
IXFR.  Let's not confuse apples with kumquats here.  :-)

-derek

---

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

Derek Atkins writes:
> Religious nonsense, eh?

Yes. Instead of rationally evaluating the costs and benefits of two
different protocol extension mechanisms, you declare that one mechanism
(new query types) is ``part of the protocol,'' while the other one (new
ports) is ``out of band'' and therefore not subject to discussion here.
That's religious nonsense.

> happen to be authoritative for the QUUX.EXAMPLE zone, be mirrors of

I didn't say that server replication was required. I said that it's
popular.

---

From: Derek Atkins <[email-masked]>
Date: 10 Dec 2002 21:22:56 -0500

> ports) is ``out of band'' and therefore not subject to discussion here.

Could you answer me how AXFR can be considered a "new query type" or
even a "protcol extension"?  It seems to be defined as far back as
RFC-883, which, if memory serves, is the original DNS definition....
Therefore, it would seem to imply that it is a core DNS element,
having been there from the beginning.  If people have found problems
with the AXFR then that would certainly be within scope of this list.

> That's religious nonsense.

Well, I'm very sorry you feel that way.  This _IS_ the namedroppers
list after all, for discussion of the DNS protocol (of which AXFR is
clearly part).  I am certainly open to the concept of using alternate
methods (outside the DNS protocol) to transmit DNS information, but it
is quite frankly out of scope for the DNS protocol discussion list.

Such discussion _may_ be appropriate for a DNS operations mailing
list, but last I checked this was not such a list.

-derek

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Dec 2002 03:45:18 -0000

Derek Atkins writes:
> even a "protcol extension"?

You said ``AXFR and IXFR.'' If you're going to start drawing some
religious line between protocol options defined many years ago and
protocol options defined more recently, you'll have to put IXFR on the
same side of the line as rsync.

> I am certainly open to the concept of using alternate methods
> (outside the DNS protocol) to transmit DNS information, but it is
> quite frankly out of scope for the DNS protocol discussion list.

What exactly do you mean by ``the DNS protocol''? 

Please try to avoid knee-jerk religious answers. For example, if you
define ``the DNS protocol'' as ``whatever runs on port 53,'' then you're
making the absurd claim that it's ``out of scope'' to discuss Larson's
proposal to put DNSSEC on another port.

---

From: Derek Atkins <[email-masked]>
Date: 10 Dec 2002 23:44:49 -0500

> same side of the line as rsync.

No, because IXFR works within the DNS framework and rsync does not.
It's sort of like comparing DNSSec and PGP.  They are completely
separate ideas, even if they can solve the same sorts of problems.

-derek

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Dec 2002 05:17:09 -0000

Derek Atkins writes:
> IXFR works within the DNS framework and rsync does not.

More religious nonsense. You still haven't defined ``the DNS protocol'';
if I ask you to define ``the DNS framework,'' are you going to dodge
that too, and start babbling about ``the DNS approach''?

> separate ideas, even if they can solve the same sorts of problems.

In fact, there would be quite a few advantages to using PGP signatures
inside DNS: software is already widely available for key generation,
signature generation, and signature verification. Are your religious
views blinding you to this possibility?

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 11 Dec 2002 10:33:49 +0100

> that too, and start babbling about ``the DNS approach''?

Please, Dan. 

The point we (at least I am) are trying to make is that "Hey, it is fine to
use whatever [server|zone] replication mechanism, but we believe that only
AXFR and other methods that use DNS messages like IXFR are on-topic for
this forum." It is not a judgement -- I for one am using ftp for one of the
zones I slave -- but more of a stay-on-topic requirement. 

The dnsop wg has a mailing list, which probably is the better IETF forum
for this, but I do believe that the topic of "how to replicate DNS data out
of band" is best at home in a systems administration forum, of which there
are a multitude. 

IF you believe that AXFR is so broken that it needs to be replaced with
something completely different, then find out a method, write a draft and
make it so good that we all see that this is the future. THAT would be
on-topic. 

Regards,

---

From: Greg Hudson <[email-masked]>
Date: Wed, 11 Dec 2002 11:33:42 -0500

Ideally, an RFC uses SHOULD when the working group feels that an
analysis of a tradeoff should generally go in one direction, but that
an implementor could reasonably choose the other direction after
thinking about it carefully.

>     another strategy sometimes generates less traffic.

The tradeoff here is between code simplicity and traffic savings.
Since you believe that code simplicity is important and that the
traffic savings never reach the level of significance, you side with
simplicity.  That's fine, but if working group consensus is against
you on that point (which is not my call), then the use of SHOULD NOT
is still appropriate.

If you said that IETF RFCs tended to erroneously choose complex
algorithms over simple ones for minor benefit, I might agree.  But
instead, you've attempted a bizarre reductio ad absurdum.

>      usually generates less traffic.

The tradeoff here is between extended functionality and traffic
savings.  So it's not a very good analogy.

>      always generates less traffic.

But rsync accomplishes different goals, as you've pointed out--server
replication versus zone replication.  (If, as you assert, zone
replication is not commonly desired, then perhaps AXFR should bite the
dust, but I think the working group remains unconvinced on that
point.)  Certainly, people should generally use the software which
most closely matches their needs.

In the situation where zone replication is desired--and particularly
when software independence is required--the tradeoff here is between a
better functionality match and traffic savings.  Still not a very good
analogy.

>      bzip2-compressed zone transfers'' because gzip usually takes less

Either of these statements might be reasonable for an RFC to make--if
the working group genuinely felt one way or another about the
bandwidth vs. time tradeoff, which seems unlikely--but obviously not
both.

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 11 Dec 2002 12:05:22 -0500

>this is handled automatically.
Well, perhaps this is as good a time as any to raise the fact that I've 
been working on an "auto-slaving" mechanism. The basic idea is that upon 
receipt of a signed NOTIFY from a particular entity, a slave can, if 
configured to do so, automatically configure itself as a slave for the 
zone being NOTIFY'ed. I've already started implementing this in the BIND 
9 codebase, but the general concept is not implementation-specific and 
could conceivably be supported by any implementation that handles signed 
NOTIFYs.

I bring this up not only to provide a middle-ground alternative between 
the two extremes presented thusfar, i.e. manually set up AXFR/IXFR 
slaves versus handling everything automatically through server 
replication, but also to elicit opinions as to whether this (perhaps 
unforeseen) use of NOTIFY requires any protocol standards action (Jim 
Reid has already weighed in with his opinion that it *does* require 
protocol standards action, but I disagree).

Other opinions?

                                    - Kevin

P.S. Mark (Andrews), have you seen my BIND 9 patch for this?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Dec 2002 17:43:12 +0000

i'd like to register my somewhat passive opposition to in-band autoslaving
as a defined function of the protocol.  out of band methods, like putting
a list of zones into a "meta-zone" and transferring/postprocessing that,
work fine.  if we do it in-band, we'll need a way to not just add slaves
but also move and replace and delete them.  i'm perfectly happy just keeping
an out of band list of who i want slaving what.  far less complexity inside
the dns implementation itself that way.  "cron" is my friend.

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 11 Dec 2002 14:02:44 -0500

>the dns implementation itself that way.  "cron" is my friend.
I don't see that the mechanism I have outlined, when limited in scope to 
slave "adds", complicates the protocol _per_se_. After all, the master 
is going to send initial NOTIFYs to all of its configured slaves anyway, 
regardless of whether they are already configured to be slaves or not, 
and it is going to sign those NOTIFYs if it is configured to do so. How 
is there any more protocol complexity if the slave takes the receipt of 
that signed NOTIFY as a trigger to perform more-work-than-usual behind 
the scenes?

As for auto-UN-slaving, I see no reason why slave "adds" and slave 
"deletes" necessarily need to use the same mechanism. If I were to 
automate auto-UN-slaving at all, I'd probably base it on whether the 
putative master starts responding non-authoritatively to refresh checks. 
Perhaps there could be a configurable threshold, e.g. "x successive 
nonauth refresh-check responses and the zone gets deleted" in order to 
bridge temporary configuration errors on the master. On the other hand, 
one of the beauties of having an automatic NOTIFY-based autoslaving 
("add") mechanism is that if a slave were to accidentally -- or perhaps 
as a result of being hacked -- stop being a slave for a zone, it 
automatically heals itself the next time the zone changes and another 
NOTIFY gets sent out for it.

I'm not sure what you mean by "mov[ing] and replac[ing]" slave zones. In 
my conceptualization of autoslaving, a given nameserver is either slave 
for a zone or not slave for it. So there are only "adds" and "deletes" 
to the list of zones that a given nameserver slaves from some other 
given nameserver. I view the details of how those slave zones are 
configured within the slave (e.g. what servers down the delegation graph 
should get NOTIFYs, who can query the zone, update-forwarding 
configuration, etc.) to be out-of-scope of the autoslaving mechanism 
_per_se_.

Eventually, it might be useful to take a look at the requirements -- or 
lack of same -- for a "nameserver configuration control" protocol. Given 
the current lay of the land, I could see this being implemented through 
SNMP somehow. The autoslaving mechanism I have proposed and partially 
implemented, is a targeted, short- to medium- solution at best, not a 
first pass at or a first step towards a comprehensive 
configuration-control solution.

In any case, the question on the table here is: does a NOTIFY-based 
autoslaving mechanism require protocol-standards action, given that, on 
the one hand, it doesn't change the wire format at all, but, on the 
other, adds more "baggage" to NOTIFY than was originally intended? The 
question of whether it's a good idea or not is probably better suited to 
another forum.

                            - Kevin

---

From: Peter Koch <[email-masked]>
Date: Wed, 11 Dec 2002 20:31:08 +0100

> slave "adds", complicates the protocol _per_se_. After all, the master 

that dependds on your service model. There is not necessarily a 1:1 relationship
between master and slave, which is why "server replication" is not applicable
in many cases. Then, a slave may depend upon several masters (i.e. may offer
2ndary service to multiple parties). So, you need some notion of ownership
wrt the zones to be slaved. In addition, you need a channel to communicate
back some status information, i.e. addition succeeded/failed for reason x.
We've developed a simple request-response protocol some years ago and did NOT
use DNS as a "transport" mechanism, not only because TSIG wasn't yet around.

> that signed NOTIFY as a trigger to perform more-work-than-usual behind 

Usually you have more information available than just "slave zone exapmle.com
off dns.example.net". There are - yet implementation specific - details which
need to be piggybacked to the slave request. AXFR limits, some people seem
to believe in them, are one example. You could prenegotiate and configure
some of these, but I do not believe DNS is the best or canonical way to
accomplish this task (although, for XFR limits in particular, that could
quite simply be done in band, i.e. within that particular zone).

> bridge temporary configuration errors on the master. On the other hand, 

Also here, a careful design would take into account the current delegation
status of that particular zone.

> NOTIFY gets sent out for it.

Well, a cracker wouldn't have to stop at the DoS level, they'd insert false
information. Anyway, from an operational perspective I do not really like
the idea, because it is already difficult enough to explain to the average
part time DNS zone maintainer that these things do not happen automagically.
If they'd work automagically only *sometimes*, that might be worse.

> for a zone or not slave for it. So there are only "adds" and "deletes" 

It can be slave with different sources (owners) of a zone.

> lack of same -- for a "nameserver configuration control" protocol. Given 

I'd like to discuss this further but I suggest we take this off the list,
because it is not really DNS related. In fact, it looks a bit similar to what
happens at the registry-registrar level.

-Peter

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 11 Dec 2002 15:16:18 -0500

>use DNS as a "transport" mechanism, not only because TSIG wasn't yet around.
I already have a notion of ownership in what I've implemented so far. An 
"autoslave" can have multiple masters for any given zone. As for status 
reporting, the master can always query the zone and see if the putative 
slave answers authoritatively. I don't see the need for a special "channel".

>quite simply be done in band, i.e. within that particular zone).
Right. I'm putting all of that stuff out of scope. The mechanism I'm 
talking about just adds a slave zone. The details of how that slave zone 
is configured is up to the slave, possibly using some out-of-band 
information from the master.

>status of that particular zone.
I don't quite catch your drift. What do you mean by "delegation status"? 
You mean whether the zone is delegated from its parent or not? I'm not 
sure what bearing this has on master/slave replication.

>information. 
The NOTIFY was signed, I'm assuming if that is in place, the zone 
transfers are signed too. Why would someone require NOTIFYs to be signed 
but then accept a zone transfer based on weaker authentication or no 
authentication at all? That seems rather remiss.

>Anyway, from an operational perspective I do not really like
Is it better to have a patchwork of homegrown solutions to the problem? 
Or to force everyone into DJB's server-replication model?
 
It is precisely because I'm sick and tired of my own homegrown solution, 
that I started working on this...

>It can be slave with different sources (owners) of a zone.
Right, slaves and masters for a given zone is potentially a many-to-many 
relationship. But between two given nameservers, either a given zone is 
being replicated between them, or it isn't.

>happens at the registry-registrar level.
Can I count that as implicitly a voice in support of "not a protocol 
change" then? :-)

                                        - Kevin

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 11 Dec 2002 20:36:39 +0100 (CET)

> been working on an "auto-slaving" mechanism. The basic idea is that upon

http://archive.iecc.com/article/spamtools/20010608005

--==--
Bruce.

---

From: Doug Barton <[email-masked]>
Date: Wed, 11 Dec 2002 23:13:01 -0800 (PST)

> those examples are the fringe case.

I have to disagree. I am the DNS administrator for a fairly large
enterprise, and I'm also responsible for the name servers used in our DNS
reselling program. I have roughly 200 name servers, in dozens of
geographic locations all over the world, some authoritative, most
resolvers. I have several different masters, each with a unique subset of
zones it's responsible for. Each of the slaves sucks down some zones from
the various masters, but no single server gets all the zones from any of
the masters.

In short, while there are subsets of slaves that all have the same
configurations, there isn't anyplace in my company where the concept of
"server replication" would apply. AXFR is crucial to the success of my
configuration(s). Note, I haven't even touched on the issue of sharing
information with third parties, whether I'm slaving from them, or they are
slaving from me (I have some of each).

Now you can argue whether or not I'm a "typical" user, or whether all the
gymnastics are actually needed. (In fact, the current configuration is
both simpler and more reliable than when I took over, but I digress.)
However, AXFR definitely provides me the flexibility I need to deal with
my situation (as I perceive it).

-- 
   "We have known freedom's price. We have shown freedom's power.
      And in this great conflict, ...  we will see freedom's victory."
	- George W. Bush, President of the United States
          State of the Union, January 28, 2002

         Do YOU Yahoo!?

---

From: Bruce Campbell <[email-masked]>
Date: Thu, 12 Dec 2002 13:14:52 +0100 (CET)

On 10 Dec 2002, D. J. Bernstein wrote:

> format is stable.

Lets see.  I stated that there is a set, implementation non-specific,
standard for zone files.  You replied that a specific implementation, the
'BIND company', keeps changing their zone file format.

Ergo, to use your methods of summarising, you are in support of AXFR
between different nameserver implementations, and possibly different
versions of the one implementation.

( Although to play Devils Advocate, after downloading sample BIND
  distributions and checking the example zones, the synxtax of the zone
  file that BIND will accept has not changed between BIND 4.8 and 9.2.2rc1
)

> Furthermore, zone files are only part of the BIND

Point being?

( as in, we're talking about zone files, not server configuration files )

--==--
Bruce.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Dec 2002 03:18:14 -0000

I've noticed that Randy Bush discarded Len Budney's note on this topic:
http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org

Greg Hudson writes:
> analysis of a tradeoff should generally go in one direction

No. That violates RFC 2119, section 6. These decisions are _not_ up to
the working group. They are up to the implementors and, ultimately, the
users.

When speedups actually make a difference for the users, the users notice
and select implementations accordingly. When a tradeoff is good for some
users and bad for others, implementations end up offering a variety of
options, and users end up choosing options accordingly. The free market
does a good job of matching speedups to the users who benefit from them.

Telling implementors that they ``SHOULD'' choose one option---that they
must carefully consider the consequences before doing anything else---is
naive, misguided, paternalistic, anti-competitive behavior. Even if

   * you think that some users will benefit from the option; or
   * you think that some users _need_ the option; or
   * you think that _most_ users need the option; or, as an extreme,
   * you _know_ that most users need the option;

it is still wrong to discourage implementors from making choices that
are better for the _other_ users. The only legitimate reason for a
protocol specification to make a choice is to prevent actual harm, such
as an interoperability failure.

Example: You may think that there's no good reason for DNS servers to
retrieve data from LDAP databases. You may have performance statistics
showing that thousands of DNS servers can't possibly tolerate the CPU
time or network bandwidth of these LDAP lookups. It's still wrong for
you to tell implementors that they ``SHOULD NOT use LDAP''---that they
must carefully consider the consequences before using LDAP. That's not
your decision to make.

Getting back to the example that started this discussion, namely the
bandwidth consumed by BIND 8's AXFR glue repetitions: It is wrong to
demand that implementors carefully consider the consequences before
using the BIND 8 strategy. This would be true even if there were a bunch
of sites that cared about this absurdly small bandwidth issue and that
insisted on software avoiding the BIND 8 strategy. These decisions don't
belong in protocol specifications.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Dec 2002 03:51:30 -0000

[email-masked] writes:
> You as a implementor are not in a position to say if a given increase
> in traffic is minor or not as you do not have enough details of the
> conditions underwhich the transmission is taking place.

Of course, Andrews thinks that he's an exception to this rule; that he
is in a position to say that BIND 8's AXFR glue repetition is a massive
waste of bandwidth; that it was irresponsible of the BIND company to
ignore this crucial issue for so many years; that all implementors must
carefully consider the consequences before repeating BIND 8's mistake.

I'm looking forward to draft-bindcompany-gzip9-00.txt, which says that
all DNS software distribution through tar.gz format SHOULD use the -9
option to gzip, and draft-bindcompany-logging-00.txt, which says that
all UNIX DNS software SHOULD support logging to files as an efficient
alternative to syslog.

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 16 Dec 2002 11:00:31 -0500

>belong in protocol specifications.
Dan,
        Can you suggest less normative verbiage than "carefully consider 
the consequences"? Carefully considering the consequences is something 
that good implementors should be doing *anyway*, for *all* aspects of 
their implementation. So, on that basis, "carefully considering the 
consequences" isn't even nudging them in a particular direction...

                                                - Kevin