Subject: Re: in support of axfr-clarify

From: bert hubert <[email-masked]>
Date: Wed, 27 Nov 2002 11:38:14 +0100

On Wed, Nov 27, 2002 at 04:58:02AM +0000, Paul Vixie wrote:
> axfr-clarify should go forward, for two reasons.
> 
> first, bind has done wrong.  early versions were only barely within rfc1035,
> forcing other implementors (notably microsoft) to bend to match field
> behaviour.  bind9 is entirely within rfc1035 regarding axfr, and current
> bind8 is reasonably close.  we need to clarify the spec so that all future
> implementations can know what the right thing is.

Indeed. PowerDNS had a very hard time implementing AXFR reasonably correctly
until we stumbled on the axfr-clarify draft. Without it, there basically is
*no* specification. RFC1035 has two paragraphs on it on flowery language
which try to pass themselves off as a specification. So 'being within
rfc1035' strikes me as a statement more like 'we spent heaps of time
interpreting the meaning of 1035 and we think we are within it'.

In any case, we need a clarification. On a related note, for interop
interest, PowerDNS just went open source, initial drop is on
http://ds9a.nl/pdns

> second, i've seen comments here to the effect that a name node's ownership
> was zone-independent, and that's just plain wrong.  again, early bind got
> this horribly wrong and caused a lot of pain and confusion, and we need to
> retain what's been learned (which is foundational to rfc2181 and rfc2308),
> which is that a delegation point is owned by the child zone and the parent

How is this related to a proposed RFC about zone transfers? 

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

--
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: "D. J. Bernstein" <[email-masked]>
Date: 27 Nov 2002 17:41:04 -0000

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  your subscription address is
  [email-masked], please post from it or
  fix subscription your subscription address! ]

Paul Vixie writes:
> bind has done wrong.

Interoperability is more important than your notions of what's ``right''
and ``wrong''---never mind the question of whether your notions are
actually supported by the Full Standard DNS specifications.

The ``axfr-clarify'' document claims to codify existing practice. The
problem is that what it actually codifies is BIND 9 practice. You admit
that this ``clarification'' imposes rules that are disobeyed by BIND 8,
for example, and by djbdns.

My web pages have said for three years that the DNS specifications are
horribly inadequate. This doesn't mean that I will support a dishonest,
clearly biased document that tries to force me to imitate BIND 9's silly
implementation decisions at the expense of my users.

You say that your optional IXFR extension doesn't work correctly unless
every DNS server on the planet works the way that BIND 9 does. You leap
to the conclusion that everybody else should change their software for
IXFR's benefit. Has it ever occurred to you to fix IXFR instead?

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

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 27 Nov 2002 15:22:28 -0500

> implementation decisions at the expense of my users.

Dan,
        Interoperability is fine and dandy, but should not stand in the way
of writing new specifications to do The Right Thing. This new specification
makes AXFR error reporting and behavior more intuitive, and it puts data in
the proper parts of the AXFR response (vis-a-vis Answer, Authority and
Additional) in order to allow for future extensions. These two points --
error/reporting behavior and allocation of records among sections -- seem to
be your (and your minions') major objections to the new specification,
because you've been bending the _de_facto_ rules in these regards (e.g.
"section agnosticism" or whatever you call it). If your users have any
"expense" due to the new specification, it is because you chose to _ad_lib_
in the absence of a clear specification, instead of proceeding in a
conservative and/or cautious fashion. C'est la vie...

For the record, I support the draft.

- Kevin

---

From: Dean Anderson <[email-masked]>
Date: Wed, 27 Nov 2002 16:32:04 -0500 (EST)

I would note that the "de facto rules" are defined by the "de
facto" implementations, which is not Bind 9.

While there could be reasons to change something, that isn't what
"clarify" means.  "Clarify" is where you document what was _done_ when the
specifications were vague.

It seems highly inappropriate to make seemingly gratiutous changes in a
particular commercial product, begin distributing those changes to users,
and then attempt to change the standards to reflect the changes, and
describing those changes as a "clarification".

This seems more like behind the scenes dirty tricks.

		--Dean

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Nov 2002 00:25:26 -0000

Kevin Darcy writes:
> you've been bending the _de_facto_ rules in these regards (e.g.
> "section agnosticism" or whatever you call it)

How is it possible for people to be so fundamentally confused about such
a simple issue?

RFC 1034 says that the AXFR server sends ``messages'' that ``carry'' all
the records. This is ambiguous: does ``carry'' refer to all sections of
the message, or is it restricted to the answer section?

I decided to take the safest possible interpretation:

   * My AXFR _server_ puts all records in the answer section, just in
     case some clients look only at the answer section.

   * My AXFR _client_ reads all sections, just in case some servers use
     other sections.

The accusation that I'm ``bending the rules'' is utterly without merit.
I am doing what any careful implementor would have done, for the sake of
interoperability. My server behavior and client behavior are both fully
compliant with the protocol specifications.

Now, it appears that every other _server_ implementor has made the same
decision to use only the answer section, so no harm would have arisen if
my _client_ had been less careful. But the leap from ``this client can
handle protocol violations that, thankfully, do not occur'' to ``this
client itself violates the protocol'' is utterly absurd.

The BIND company's ``clarification'' does two things:

   * It requires _servers_ to use the careful _server_ strategy. I have
     no objection to this: it's what servers are already doing, it is
     necessary for interoperability with careless clients, and it
     removes a frivolous source of variability in the protocol.

   * It prohibits _clients_ from using the careful _client_ strategy. I
     object to this: it is _not_ consistent with the installed base, and
     it is _not_ necessary for interoperability.

How can anyone confuse a constraint on _servers_ with a constraint on
_clients_? It isn't just Kevin; the same blatant confusion appeared in
the message from the DNSEXT chairs on 13 November.

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 27 Nov 2002 17:55:29 -0800 (PST)

>      it is _not_ necessary for interoperability.

We have been over all this before.  At the risk of repeating myself:

What you say is true, but it is a rather selective view of the truth.
As far as I know, the client behavior specified in the draft is
consistent with the entire installed base with the sole exception of
djbdns.  Although it is not necessary for interoperability of the base
protocol, it is necessary in order to support protocol extensions that
send out-of-band data in sections other than the answer section, such
as TSIG signed transfers.

I also wouldn't use the word "careful" to describe the indiscriminate
conglomeration of data from arbitrary sections of the response, but
I suppose that is a matter of taste.
-- 
Andreas Gustafsson, [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 27 Nov 2002 20:56:20 -0500

> the message, or is it restricted to the answer section?

You're only reinforcing the need for a Clarify draft.

>    * My AXFR _client_ reads all sections, just in case some servers use

Okay, Dan, I appreciate now that you were just trying to be cautious in your
client. But the threat that you protected against never actually
materialized, and at the same time the mechanism you used to protect against
it appears to have made an implicit assumption -- that non-Answer sections
of an AXFR response would never be used productively -- which turned out to
be false because of things like EDNS0 and TSIG.

No-one blames you for having less-than-perfect foresight. But when the
DNS world changes, sometimes old assumptions are invalidated and code which
is based on those assumptions needs to change or become
non-standards-compliant. The proposed AXFR Clarify draft, inasmuch as it
seeks to accommodate relatively recent developments like EDNS0 and TSIG, not
to mention future extensions, with its "must ignore" provisions, seems to be
incompatible with the behavior of your AXFR client. Something has to give
here. The question is: is your codebase the "immovable object" which
prevents AXFR from being clarified in this way, or is AXFR Clarify the
"irresistible force" which requires you to change your code in order to
maintain standards-compliance? As inconvenient as it may be for you and the
users of your DNS package, I think the rough concensus here is for the
latter. The alternative is for AXFR to remain under-specified
*indefinitely*, thus leading to more interoperability problems in future
implementations. Let's move forward here.

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Nov 2002 11:40:55 -0000

> You're only reinforcing the need for a Clarify draft.

I've been saying for years that the DNS specifications are horribly
inadequate. I thought axfr-clarify sounded like a great idea until I
read the document and discovered twelve problems. Two of those problems
have now been fixed; ten more to go.

> an implicit assumption -- that non-Answer sections of an AXFR response
> would never be used productively -- which turned out to be false
> because of things like EDNS0 and TSIG.

These issues have been discussed before. First, contrary to your claim,
there is no evidence of an actual problem. Second, and more importantly,
if an optional protocol extension fails to ensure compatibility with the
previous protocol, that is entirely the extension's fault.

As I wrote when we last discussed this in July 2001, after you asked why
I wasn't changing my code:

   The benefits are nonexistent. The harms include encouraging further
   disregard for compatibility. What stops incompetent implementors from
   demanding another code change every week? Ignore AXFR AR, discard
   TKEY, ignore types 128-255, recognize IXFR, ignore MS garbage. This
   is not a sane way to handle optional protocol extensions.

Is compatibility such a difficult concept to grasp?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Nov 2002 18:39:00 -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. ]

All of this was discussed in detail a long time ago. In any legitimate
standards organization, the results of that discussion would have been
recorded for future reference.

Andreas Gustafsson writes:
> Although it is not necessary for interoperability of the base

No, it is not necessary. Backwards compatibility is not rocket science.
Servers must not---and, according to you, BIND does not---send TSIG junk
to clients that haven't indicated that they want it. (I have no desire
to support TSIG; IPSEC is a vastly better solution.)

If the TSIG specification fails to impose this basic interoperability
requirement, then that's a bug in the TSIG specification. It is the
responsibility of optional protocol extensions to maintain perfect
compatibility with the unextended protocol. The alternative---forcing
the entire Internet to change its software for every careless protocol
extension that comes along---is insane.

How would you like it if Microsoft wrote an RFC on some incompatible
protocol extension, hid the interoperability problems until the RFC was
published as an elective Proposed Standard, and then demanded that every
BIND installation be ``upgraded'' to deal with the junk produced by that
protocol extension? How do you think your users would like it?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Nov 2002 11:08:19 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Paul" == Paul Vixie <[email-masked]> writes:
    Paul> which is that a delegation point is owned by the child zone and the parent
    Paul> can at best send delegations, never answers and never authoritative, when
    Paul> queried for things at a child zone's delegation point.  bind9 does this
    Paul> correctly.  an apparently common misunderstanding as to the contents of a
    Paul> zone is that data can be copied from a child without changing the identity
    Paul> of the parent.  this is just false, and is indicative of other conceptual
    Paul> errors.

  I agree strongly with you on this - delegations belong to the child.

  What about DS? The problems identified at the workshop stem PRECISELY from
the problems with who is authoritative for the DS record. 

  A hack was proposed, whereby the DS record for example.com would be
actually named as _ds_example.com. This restores the principle that you
outline above. it would be very nice if we could come up with a solution
to the DS problem doesn't violate this principal.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: [email-masked]
Date: Sat, 30 Nov 2002 09:17:39 +1100

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

	No one is trying to force a incompatabile extension on anyone.

	How is saying that the client should enforce what the server
	should be enforcing going to create incompatabilities?

	There is nothing incompatable with saying that servers built
	from this time on MUST NOT treat records in the authority
	and additional sections as part of the results of AXFR.

	We already have servers that enforce this. They have existed
	since basically the begining.  Having servers behave
	differently in the presence of changes to the spec is *bad*.
	Specifing what their behaviour is in advance means that the
	effect of changes can be predicted.

	Now if anyone is going to add extentions they are also going
	to need to add knobs to disable the extention.  It would
	just be nice if those knobs rarely need to be changed.

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Nov 2002 18:24:47 -0000

> No one is trying to force a incompatabile extension on anyone.

You are demanding a rule whose only purpose is to support incompatible
extensions. _You_ are trying to impose costs on _my_ users so that _you_
don't have to bother preserving backwards compatibility in _your_ stupid
protocol extensions. Furthermore, adding insult to injury, you're trying
to sneak this protocol change through as a ``clarification.''

You didn't answer my question: How would you like it if Microsoft wrote
an RFC on some incompatible protocol extension, hid the interoperability
problems until the RFC was published as an elective Proposed Standard,
and then demanded that every BIND installation be ``upgraded'' to deal
with the junk produced by that protocol extension? How do you think your
users would like it?

If you want to break compatibility with a deployed protocol, you have to
admit the massive costs of changing software around the Internet, and
demonstrate benefits that are even more massive. Saying something like

   We'd like to offer people a pointless, clumsy, ad-hoc reinvention of
   IPSEC, and we realize that there's no need to break compatibility to
   do this, and our implementation in fact follows a rule that ensures
   compatibility, but we didn't put this rule into the spec because it's
   against company policy to think through compatibility issues, and now
   instead of fixing the spec we're demanding that other people upgrade
   their software

doesn't cut it.

What's particularly amazing about your ``axfr-clarify'' document is that
you admit that it imposes rules violated by BIND 8. How can you possibly
claim that this is necessary for interoperability?

> and additional sections as part of the results of AXFR.

1. Please stop viewing the entire world through a BIND lens. Don't say
``server'' if you mean ``AXFR client.''

2. When you use a phrase like ``in future implementations,'' you're
admitting that you're violating RFC 2119, section 6. There is no valid
excuse for a protocol to refer to software creation dates. 

3. It's content-free to say that an extra requirement doesn't create a
compatibility problem. What I'm talking about are compatibility problems
created by protocol extensions that don't work correctly with unextended
protocol implementations.

---

From: Danny Mayer <[email-masked]>
Date: Sat, 30 Nov 2002 21:09:34 -0500

>protocol extension? How do you think your users would like it?

They already did that. See the discussion on GSS-TSIG.

Danny