Subject: draft-ietf-dnsext-axfr-clarify-05.txt

From: Randy Bush <[email-masked]>
Date: Wed, 04 Dec 2002 08:48:12 -0800

</chair>
<uncloak> 

<surprise>
confession, other than djb, i have been the other wg member not in
consensus on this document.

as i said in yokohama, i was the one personally uncomfortable with
the axfr document mandating the zone content being maintained
exactly as served by the primary.  i did not see why it was
*necessary* for this to be done, and was hesitant as djb claimed
his implementation would be adversely affected.
</surprise>

yes dan, i was the one holding up progress of this document.

i have recently become convinced that the primary's zone content on
axfrs needs to be preserved purely so that subsequent ixfrs may be
applied.

randy

--
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]
Date: Thu, 05 Dec 2002 11:24:26 +1100

> axfrs needs to be preserved purely so that subsequent ixfrs may be

	Randy, while I'm glad that you agree that the zone contents
	need to be preserved, this sounds like you discount the
	need to fix the operational problems caused as the result
	replacing data in the zone with that from another source.

	This is *not* just a IXFR problem.  It causes problems with
	servers that don't support IXFR.  I would hate to see a
	implementor say "I don't need to do this because I don't
	support IXFR".

	See <[email-masked]> for
	a detailed example of a non IXFR related problem that is
	fixed by preserving the zones contents.
 
	Mark

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Dec 2002 02:12:21 +0000

> 	fixed by preserving the zones contents.

Forgetting for a moment about whether we can find a problem with it,
there's a standards track RFC (#2136) with something to say on the
matter of zone identity and zone ownership:

   7.10. ... Visible (to DNS clients) SOA SERIALs need
   to differ if the zone differs. ...

   7.18. Previously existing names which are occluded by a new zone cut
   are still considered part of the parent zone, for the purposes of
   zone transfers, even though queries for such names will be referred
   to the new subzone's servers.  If a zone cut is removed, all parent
   zone names that were occluded by it will again become visible to
   queries.  (This is a clarification of [RFC1034].)

   7.19. If a server is authoritative for both a zone and its child,
   then queries for names at the zone cut between them will be answered
   authoritatively using only data from the child zone.  (This is a
   clarification of [RFC1034].)

So, whether a server can implicitly edit the data at the zone cut is not
a matter of operational necessity or of personal taste.  It's a matter of
definitional correctness.  A zone's identity is what the primary master
says it is.  Implementations such as BIND4, BIND8, and (apparently) DJBDNS
who implicitly edit a zone's apex because they are also authoritative for
the parent zone, are wrong.  axfr-clarify is not what makes them wrong.
They are just plain wrong.  The fix to BIND4 or BIND8 is "upgrade to BIND9."

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Dec 2002 05:11:52 -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. ]

> yes dan, i was the one holding up progress of this document.

It's always interesting to see a glimpse into the mind of Bush:

   * Bush can make these decisions singlehandedly. After all, Bush is
     more important than anyone else!

   * Consensus is, by definition, whatever Bush is thinking. Remember,
     Bush is more important than anyone else!

   * Bush doesn't need to actually _defend_ his opinions; he can simply
     state them. Remember, Bush is more important than anyone else!

Most importantly, all of this is The Way Things Ought To Be, because
there's nothing in the IETF procedures prohibiting it.

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

---

From: Greg Black <[email-masked]>
Date: Thu, 05 Dec 2002 17:37:50 +1000

"D. J. Bernstein" wrote:

| [ post by non-subscriber. [...]

Perhaps that should be "post by deliberately stupid subscriber".

| It's always interesting to see a glimpse into the mind of Bush:

Perhaps.  But it's certainly become utterly uninteresting to see
any more into the mind of Bernstein.  For years I have said that
one should not make decisions about the software one deploys
based on one's perceptions of the personality of its author; and
I have said that it's good to have multiple implementations of
important infrastructure software.  And, as part of putting my
metaphorical money where my mouth is, I have used Bernstein's
qmail and djbdns utilities.

This latest sorry saga of bullying, name-calling, arrogance and
bloody-mindedness on the namedroppers list has caused me to have
another think about this.  I really don't want to get caught up
in some backwater with Bernstein's software because he can't get
his head around the simple process of co-operative development
of standards.  I've never liked BIND, and I still don't like it,
but I'm going to learn how to set it up (it's changed quite a
lot from v4, which is what was current when I last used it); and
I will probably learn how to install postfix in place of qmail
(although that will also mean that I'll have to move all my
mailing lists away from Bernstein's ezmlm, which will take some
time and effort).

The upside is that I will now be able to filter all Bernstein's
messages from my mailbox so that I never again will need to see
his ranting.  And I'll then be able to stomach this list.  So
it's not all bad.  In fact, what would be really nice would be
to see everybody just stop responding to Bernstein, so that
those of us who filter him out won't have to see the responses
to him either ...

Greg

---

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

Paul Vixie writes:
> A zone's identity is what the primary master says it is.

Nonsense. For example, I've seen a zone that was set up with

   * a European server that returns some European addresses and
   * a United States server that returns some United States addresses

in an effort to reduce delays for users. (Of course, as I discussed in a
previous message, clients are under no obligation to keep track of this
difference.) There is no ``primary master'' for this zone. Your notion
of ``zone identity'' is simply confused.

As for your comments about the BIND 9-specific model of DNS being
``right'' while everybody else is ``wrong'': Do you seriously believe
that this religious nonsense justifies imposing massive redeployment
costs upon innocent users? If you want a new protocol, deploy a new
protocol; there is absolutely no reason to break compatibility.

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 10 Dec 2002 11:22:06 +0100 (CET)

> of ``zone identity'' is simply confused.

Thats simply a different point of view for the clients, thus modifying the
statement (to deal with non-orthodox configurations as above) to:

	``A zone's identity is what the primary master for that particular
	  view says it is.''

For most zones, there is a single view (global), and thus a single primary
master.  For other zones, there would be multiple 'primary' masters, quite
likely based on network topology.

( Although it seems that implementations of topology-based DNS tricks use
  something akin to the BIND 'views' facility to have every nameserver for
  that zone return the 'nearest' results for a given client.  Such are
  outside the general scope of transferring zones )

> protocol; there is absolutely no reason to break compatibility.

Which specific 'massive' deployment costs?  After all, someone who works
for the BIND Company (as you put it) has explicitly stated that pre and
post clarification servers will be able to interoperate, ie:

In [email-masked], Mark Andrews states:

:        Note there are no *forced* upgrades happening here.  The pre-clarify
:        servers will interoperate with the post-clarify servers.  However
:        the post-clarify servers can be used in configurations where most
:        of the pre-clarify servers (those that merge data) can't.

I daresay that your axfr client (unpatched) will be able to successfully
retrieve zones from a post-clarify server, and that a post-clarify client
will be able to successfully retrieve zones from your axfr master (patched
for returning the appropriate rcode and id).

( I'm taking the above two from http://cr.yp.to/djbdns/axfr-clarify.html,
  which only gives detailed comments up to revision -02 of the draft )

--==--
Bruce.