Subject: in support of axfr-clarify

From: Paul Vixie <[email-masked]>
Date: 27 Nov 2002 04:58:02 +0000

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.

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
can at best send delegations, never answers and never authoritative, when
queried for things at a child zone's delegation point.  bind9 does this
correctly.  an apparently common misunderstanding as to the contents of a
zone is that data can be copied from a child without changing the identity
of the parent.  this is just false, and is indicative of other conceptual
errors.

i hereby call for the rapid progression of axfr-clarify along the standards
track.  it will do much good, and right many wrongs.
-- 
Paul Vixie

--
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: bert hubert <[email-masked]>
Date: Wed, 27 Nov 2002 11:38:14 +0100

> 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

> 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

---

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: Greg Hudson <[email-masked]>
Date: 27 Nov 2002 16:48:06 -0500

> describing those changes as a "clarification".

Would it really make any of you happier if the title were changed from
"clarifications" to "revisions" and the introductory text modified
accordingly?  (If so, I'm all for it.)

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 27 Nov 2002 17:21:54 -0500

> facto" implementations, which is not Bind 9.

Well, when I said "_de_facto_ rules" I was referring not only to a mere survey of
what extant AXFR implementations do, but also the rules followed generally for
query/response transactions within DNS. AXFR is, after all, a query/response
transaction, albeit a somewhat "special" kind. The general rules say that data
answering a DNS query goes into the Answer section (along with possibly CNAMEs
and DNSSEC goop), and the Authority and Additional sections are reserved for
specific purposes (e.g. referrals, glue, OPTs, TSIGs etc.), none of which really
apply to "classic" unsigned AXFR responses. The general rules also say that if a
server declines to answer a query for some administratively-defined reason, it
sends back an approriate RCODE, rather than just dropping the connection (as
DJB's server apparently does, because he considers AXFR client/server
transactions to be "local matter[s]" rather than something to be governed by
protocol, go figure).

> specifications were vague.

No, the purpose of clarifying AXFR is not to spread a "big tent" that
accommodates the idiosyncratic behavior of every AXFR implementation out there.
Such a specification, if it is possible at all, would be so watered down it would
be useless. The purpose of clarifying AXFR is to bring it into the mainstream of
DNS as a whole, and to allow future implementations to be based on a common
understanding of how AXFR works, and therefore be able to interoperate with a
minimum of hassle. If this means DJB actually has to touch some of his existing
code to make it conformant to the clarified spec, then them's the breaks. He
shouldn't have taken such liberties in the first place. It is exactly
*because* there was a divergence in AXFR implementations (with older
BIND versions being among the prime offenders) that the clarifications were
deemed necessary. A "clarification" that merely documented the incompatibilities
between different implementations would have been pointless: the IETF is not a
historical society, merely documenting the mistakes of the past; it is supposed
to lead into the future. Also, I'll add that every Tom, Dick and Harriet who
decides to implement a poorly-specified IETF protocol doesn't thereby get veto
power over any future clarification of that protocol, simply by incanting "but it
won't interoperate with my implementation!" as if it were some sort of religious
mantra. That's no way to set forward-looking standards.

> describing those changes as a "clarification".

I dispute that the changes are "gratuitous", that BIND is "a commercial product"
(yes, it is used *in* some commercial products, but that's not the same thing),
and, finally, that the standards are actually being changed here.

> This seems more like behind the scenes dirty tricks.

Yeah, it's all a big conspiracy. Sheesh.

- Kevin

---

From: Dean Anderson <[email-masked]>
Date: Wed, 27 Nov 2002 17:52:11 -0500 (EST)

It would make the standards transaction more intellectually honest.

But I still think the changes are dubious.  I assert that the AXFR
protocol and semantics should not need to be changed in order to do IXFR.
Changes to the AXFR semantics seems to imply changes to RFC1035, and
affects backward compatibility.  I think tampering with AXFR is risky, and
not well understood.

However, I haven't looked into the Bind 9 IXFR modifications enough to
know exactly why AXFR changes are really necessary, or if indeed they are
really necessary or just a convenient hack to make IXFR work in Bind.

I think I would rather change IXFR to make it work without changes to
AXFR.

So I still wouldn't be for it.

		--Dean

---

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

> accommodates the idiosyncratic behavior of every AXFR implementation out there.

I agree with this statement. But we aren't talking about a lot of
idiosyncratic behavior. We are talking about behavior shared by numerous
nameservers, and now significantly changed by Bind 9.  So far as I know,
_only_ Bind 9 has this change.

A clarification should define the common way its done, the way it was
reasonably and commonly understood by readers the original document.

> I dispute that the changes are "gratuitous", that BIND is "a commercial product"

Vixie asserts a trademark on "BIND". Though I'm not convinced its really
valid, since it was in the public domain by UCB.  Trademarks are only
valid if used in commerce. .: Bind is a commercial product.

I guess "gratuitous" is rather vague. I should say that I think IXFR
should be changed instead of AXFR, and that I'm not convinced that any
protocol/semantic changes are really necessary to make this work. Rather
than accept these changes to AXFR, I think the implementors should give it
more thought.

> Yeah, it's all a big conspiracy. Sheesh.

Appearances of impropriety weigh just as heavily as actual impropriety.

		--Dean

---

From: [email-masked]
Date: Thu, 28 Nov 2002 11:30:34 +1100

> So I still wouldn't be for it.

	The rules are required for basic AXFR to work regardless of
	IXFR.

	Take the following senario.

	A is the primary master for example.net.
	B is the primary master for child.example.net.
	C is a server for example.net and child.example.net.
	D is a server for example.net that uses C as a master.

	A and B both change the NS RRset for child.example.net.
	The NOTIFY from B is lost so the update relies on refresh.
	C transfers example.net.  C replaces the NS RRset with that
	from child.example.net.
	C notifies D that it has a new version of example.net.
	D transfers example.net from C.
	C performs a refresh query for child.example.net and transfers it.

	You now have:

	A with the NEW NS RRset for child.example.net.
	B with the NEW NS RRset for child.example.net.
	C with the NEW NS RRset for child.example.net.
	D with the OLD NS RRset for child.example.net.

	This is why you MUST preserve zone contents with AXFR.

	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: 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:13:10 -0800 (PST)

> protocol and semantics should not need to be changed in order to do IXFR.

These are not protocol changes.  The one and only protocol change
specified by the draft is that of marking the end of a transfer by
sending the SOA rather than the apex node, since the former is what
every implementation does.  Everything else in the draft is specifying
things that were previously left unspecified.

> I think tampering with AXFR is risky, and not well understood.

I belive I have a pretty good understanding of AXFR after implementing
it in four different name servers for three different companies and
reapeatedly having to deal with the consequences of the
underspecification in RFC1034/1035.  I find that it is far more risky
to leave the protocol as vague as it is than to specify it in detail.

As for "tampering", you might as well say that this whole IETF thing
is a bad idea - after all, tampering with the Internet is risky and
not well understood.
--
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: [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: Danny Mayer <[email-masked]>
Date: Wed, 27 Nov 2002 22:57:48 -0500

>reasonably and commonly understood by readers the original document.

Right. However, if the original document is unclear then different
implementors will have implemented differently, resulting in interoperatibility
problems. By clarifying you necessarily make some of those implementations
non-compliant. You can't clarify without breaking something.

>valid if used in commerce. .: Bind is a commercial product.

That's an untrue statement. You can trademark anything without it being
a commercial product. I don't know if Paul has made any trademark claim
with repect to BIND, though it would be on behalf of ISC.

>than accept these changes to AXFR, I think the implementors should give it

You can't do IXFR unless AXFR is clear and unambiguous. Incremental
makes no sense without that. Are you going to negotiate the type of data
to be sent based on everyone else's different interpretation of the spec?

Danny

---

From: Jim Reid <[email-masked]>
Date: Thu, 28 Nov 2002 03:28:38 -0800

>>>>> "djb" == D J Bernstein <[email-masked]> writes:

    djb> RFC 1034 says that the AXFR server sends ``messages'' that
    djb> ``carry'' all the records. This is ambiguous

I'm perplexed. You accept RFC1034 is ambiguous on the subject of zone
transfers. Fine. So why are you objecting to a draft which clarifies the
specification and eliminates that ambiguity?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Nov 2002 10:21:07 -0000

> This is why you MUST preserve zone contents with AXFR.

No. If a screwy configuration causes problems with the deployed AXFR
protocol, the solution is to outlaw the configuration, not to demand
that the entire universe deploy new software.

Is interoperability such a difficult concept to grasp? If you want a new
protocol, use a new query type. Using the existing AXFR type is clearly
malicious: you're trying to hurt other implementors and users.

---

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

Kevin Darcy writes:
> incanting "but it won't interoperate with my implementation!" as if
> it were some sort of religious mantra

Interoperability is incredibly important in the real world. You have no
right to go creating interoperability problems where none exist today.

> accommodates the idiosyncratic behavior of every AXFR implementation
> out there.  Such a specification, if it is possible at all, would be
> so watered down it would be useless.

That's absurd. In fact, many future implementors would benefit from an
accurate specification of the existing AXFR protocol. This does _not_
mean screwing up interoperability. It does _not_ mean documenting
irrelevant BIND 9 implementation details as if they were the protocol.

> (as DJB's server apparently does, because he considers AXFR
> client/server transactions to be "local matter[s]" rather than
> something to be governed by protocol, go figure).

When did I ever say that local protocols aren't protocols? What I'm
saying is that unauthorized users like you have no right to demand a
response---or even to try to participate in the protocol in the first
place. The protocol is for authorized users.

> The general rules also say that if a server declines to answer a query
> for some administratively-defined reason, it sends back an approriate
> RCODE

No, the specifications don't say that. Servers can say REFUSED if they
want to, but there's no rule saying that they have to.

> the Authority and Additional sections are reserved for
> specific purposes (e.g. referrals, glue, OPTs, TSIGs etc.)

AXFR responses include glue, remember? A server implementor who doesn't
investigate existing practice could reasonably interpret RFC 1034 as
_requiring_ use of the additional section. That would, in turn, cause
failures with careless clients that don't look at the additional section.

I support requiring the careful server behavior. I object to prohibiting
the careful client behavior.

Analogy that I pointed out last year: RFC 2821 clearly prohibits SMTP
clients from sending non-ASCII header bytes, but clearly allows SMTP
servers to accept those bytes.

---

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

BIND company employee Danny Mayer writes:
> You can't clarify without breaking something.

That's absurd.

Right now, because the specifications are unclear, implementors have to
spend a lot of time investigating how the protocol actually works. Most
of us have been very careful about this; consequently, there have been
very few AXFR interoperability problems. (The ``non-glue records'' bug
introduced in BIND 8.2.3 is an exception.)

We can save tons of time for future implementors, and reduce the chance
of future interoperability problems, by clarifying the existing AXFR
protocol. This need not, and should not, break anything.

If there were a current interoperability problem between two deployed
pieces of software, and if both implementors claimed to be right, then
we'd have to resolve the conflict one way or another, after evaluating
the costs of each approach. But that's not the situation here. You're
wrong when you suggest that all differences between implementations are
interoperability problems.

> can't do IXFR

So fix IXFR. Stop demanding that _my_ users pay to make _your_ silly
protocol extensions work. Compatibility is not rocket science.

> You can trademark anything without it being a commercial product.

An applicant for a trademark must declare that he is using, or intends to
use, the mark in commerce. See 37 C.F.R. 2.33.

---

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: [email-masked]
Date: Fri, 29 Nov 2002 08:22:10 +1100

> that the entire universe deploy new software.

	There is nothing "screwy" about that configuration.  It and
	others like it happen all the time in large organisations.
	Can't you see that any implementation that CHANGES the
	contents of a zone and then transfers it is BROKEN.  The
	purpose of AXFR it to transfer the zone unaltered between
	server.  If the server doesn't maintain the zone it is no
	longer transfering the zone.

	BIND 4 and BIND 8 AXFR implementations have ALWAYS been
	broken as they change the replace parts of the zones contents
	silently.

> malicious: you're trying to hurt other implementors and users.

	The server behaviour was under specified.  Common sense
	says that you have to maintain the zone contents if you are
	going to be part of a zone transfer graph.  Clarifications
	are EXPECTED to correct mis-implementations.  We mis-implemented
	AXFR for years (and still do in BIND 4 and BIND 8).

	Mark

---

From: [email-masked]
Date: Fri, 29 Nov 2002 08:28:03 +1100

> place. The protocol is for authorized users.

	RFC 1034 says to send REFUSED not drop the connection.  Please
	fix your BROKEN implemetation as it is not RFC 1034 compliant.

When the poll shows that the zone has changed, then the secondary server
must request a zone transfer via an AXFR request for the zone.  The AXFR
may cause an error, such as refused, but normally is answered by a
sequence of response messages.  The first and last messages must contain
the data for the top authoritative node of the zone.  Intermediate
messages carry all of the other RRs from the zone, including both
authoritative and non-authoritative RRs.  The stream of messages allows
the secondary to construct a copy of the zone.  Because accuracy is
essential, TCP or some other reliable protocol must be used for AXFR
requests.

---

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

[ quoting RFC 1034 ]
> the secondary server must request a zone transfer via an AXFR request
> for the zone.  The AXFR may cause an error, such as refused, but
> normally is answered

See how this starts by saying that the SECONDARY SERVER does something?
You are not the secondary server. You have no authorization to even ask
for AXFR, let alone demand an answer.

Of course, there's also no support in RFC 1034 for your strange claim
that a closed connection is not ``an error.''

(As an engineering matter, every protocol has to allow connections to be
closed. Even when limiting unauthorized resource use isn't an issue,
hosts can and do crash. Forbidding this would be idiotic.)

---

From: [email-masked]
Date: Fri, 29 Nov 2002 14:15:17 +1100

> for AXFR, let alone demand an answer.

	So.  Do you claim that your server returns REFUSED to a
	server that is *supposed* to be a SECONDARY when the PRIMARY
	is misconfigured?  If it doesn't it would appear to be in
	violation of RFC 1034.
	
> that a closed connection is not ``an error.''

	Closing a connection is not sending back a error message.
	It is just "closing a connection".  The caller has know
	knowledge of why the connection failed.
 
> hosts can and do crash. Forbidding this would be idiotic.)
	
	We are not forbidding it.  RFC 1035 says that the client should
	initiate the closure.  The server should only do it in the face
	of resourse starvation or when the connection has been idle for
	several minutes.

	Having the server close the connection immediately on reciept of
	a AXFR request doesn't meet these conditions.

	Client initiation is better for most IP stacks.  The client can't
	initiate closure unless it is told that it in not going to get
	a AXFR.

	Follow the protocol.  Let the client initiate the closure.

RFC 1035

4.2.2. TCP usage

Messages sent over TCP connections use server port 53 (decimal).  The
message is prefixed with a two byte length field which gives the message
length, excluding the two byte length field.  This length field allows
the low-level processing to assemble a complete message before beginning
to parse it.

Several connection management policies are recommended:

   - The server should not block other activities waiting for TCP
     data.

   - The server should support multiple connections.

   - The server should assume that the client will initiate
     connection closing, and should delay closing its end of the
     connection until all outstanding client requests have been
     satisfied.

   - If the server needs to close a dormant connection to reclaim
     resources, it should wait until the connection has been idle
     for a period on the order of two minutes.  In particular, the
     server should allow the SOA and AXFR request sequence (which
     begins a refresh operation) to be made on a single connection.
     Since the server would be unable to answer queries anyway, a
     unilateral close or reset may be used instead of a graceful
     close.

---

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

[email-masked] writes:
> Do you claim that your server returns REFUSED to a server that is
> *supposed* to be a SECONDARY when the PRIMARY is misconfigured?

RFC 1034 says ``secondary server,'' not ``any clueless twit who _thinks_
he's a secondary server.'' The list of clients authorized to ask a
server for zone transfers is entirely up to the server. (As you know,
this list is generally _not_ the same as the NS list published in DNS.)

> Closing a connection is not sending back a error message.

On the contrary. I agree that FIN is, in this context, not a
particularly _informative_ error message, but REFUSED and SERVFAIL
aren't particularly informative either; they carry only marginally more
information than FIN. Anyone who doesn't understand why his AXFR attempt
was rejected will have to ask the server administrator.

Anyway, as an unauthorized user, you have no right to ask for AXFR in
the first place, let alone demand an answer, let alone demand an
_informative_ answer.

  [ quoting RFC 1035 ]
> Several connection management policies are recommended:
  [ ... ]
> The server should assume that the client will initiate connection
> closing, and should delay closing its end of the connection until all
> outstanding client requests have been satisfied.

This doesn't say that servers should be polite to attackers trying to
grab AXFR results without authorization, or to other clients violating
the protocol. Maybe BIND 9 tries to leave the connection open no matter
what, but that's an implementation decision, not a protocol requirement.
Please stop trying to force everybody else to imitate what BIND 9 does.
(Also, please stop pretending that ``recommended'' means ``required.'')

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Nov 2002 18:39:00 -0000

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: Greg Hudson <[email-masked]>
Date: 29 Nov 2002 14:02:21 -0500

> was rejected will have to ask the server administrator.

If you receive a REFUSED message from the server, there is pretty much
only one explanation: the server doesn't have you configured as an
authorized secondary.

If the connection is closed, there are several explanations: the server
is djbdns and doesn't have you configured as an authorized secondary,
the server process crashed and the kernel closed the connection, the
server is running through a misconfigured inetd or tcpserver.

I don't think a reasonable implementor can construe a TCP FIN as an
error message.

> the first place, let alone demand an answer, let alone demand an

You say this a lot, but you're only considering one possible case: the
requestor is a twit with no legitimate relationship to the primary.  A
more interesting case is when the primary or secondary is accidentally
misconfigured.

Contrary to what you've said before, making it easier to detect common
misconfigurations is an important aspect of interoperability.

---

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 08:55:20 +1100

> this list is generally _not_ the same as the NS list published in DNS.)

	You didn't answer my question.  In this case the ``clueless twit''
	is the administator of the PRIMARY.  I repeat.  "Does your server
	meet RFC 1034 and return REFUSED under these conditions?"
 
> was rejected will have to ask the server administrator.

	They carry a lot more information when you are trying to
	diagnose a problem for someone else.  I suspect that the
	DNS admistators of most ISP curse your stupid decision when
	trying to setup secondary service for one of their customers
	who is using your servers but forgot to adjust the access
	controls.

	Now having that extra infomation really helps them help their
	customer fix their server.
 
> the first place, let alone demand an answer, let alone demand an

	An authorized user does.  The ISP above is authorized to transfer
	the zone.
 
> (Also, please stop pretending that ``recommended'' means ``required.'')

	Asking for a AXFR is not violating the protocol.

---

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

---

From: Paul Vixie <[email-masked]>
Date: Sat, 30 Nov 2002 00:59:22 +0000

>   Paul> ... this is just false, and is indicative of other conceptual errors.
> 

yes.  i've got most of a fix ready to propose.  DS as it stands won't work.

> to the DS problem doesn't violate this principal.

agreed.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Nov 2002 20:28:18 -0000

[email-masked] writes:
> There is nothing "screwy" about that configuration.

You admit that this configuration doesn't work correctly with the
zone-transfer protocol as deployed in most servers. (My current survey
shows far more servers running BIND 8 than running BIND 9.)

You claim without evidence that this configuration is used ``all the
time.'' I'm perfectly willing to accept that some administrators have
tried it, but the suggestion that it's popular is simply wrong---even if
we ignore the fact that it doesn't work correctly with most servers.

Demanding that most DNS server administrators deploy new software, for
the sake of a few people who want to try this configuration, is, from an
economic perspective, downright stupid. (Of course, from the perspective
of a software company trying to squelch competition, it's a good idea.)

I'm not trying to say that you have to ignore those people. On the
contrary. You can define a new protocol that makes their configuration
work. For example:

   * Allocate a new MMAXFR query type.

   * Define an MMAXFR response format with all the constraints you want.
     Note that the response may be from an unextended server that treats
     MMAXFR as a normal type; remember that you created interoperability
     problems for IXFR when you screwed this up in BIND 9.

   * Require master+slave servers that received a zone in MMAXFR format
     to provide exactly the same bytes in response to an MMAXFR request,
     and to reject MMAXFR requests if they received the zone in anything
     other than MMAXFR format. One of the mistakes you made in IXFR was
     allowing an AXFR-then-IXFR chain.

   * To prevent zones from being horribly mangled by transfer bugs (such
     as many of the IXFR implementation bugs), use cryptographic hashes
     to supplement serial numbers. (For example, the SOA MNAME can start
     with an MD5 hash of everything else in the MMAXFR response.)

You can write software supporting this new protocol, and give that
software to the people who care. BUT YOU CANNOT IMPOSE THESE COSTS ON
EVERYBODY ELSE.

> contents of a zone and then transfers it is BROKEN.

``Can't you see that software that doesn't reliably report replication
errors to the zone creator is BROKEN? Can't you see that software that
doesn't transmit client-differentiation information (`views') is BROKEN?
Can't you see that software that doesn't transmit timestamps (records
being created or disappearing at a certain moment) is BROKEN?''

Everybody agrees that the zone-transfer protocol has limitations. That
doesn't give you the right to break compatibility.

In the words of Kernighan and Pike: ``Change the name if you change the
specification.'' You're violating this rule. You're trying to deploy a
new AXFR protocol with the same query type as the existing protocol.
You're threatening completely unnecessary interoperability problems---
telling people that they can use features of your new protocol as AXFR
features, when the existing AXFR protocol says nothing of the sort.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Nov 2002 20:44:39 -0000

> I don't think a reasonable implementor can construe a TCP FIN as an

By exactly the same silly argument, SERVFAIL isn't an error message.
Maybe the server program ran out of memory; maybe the disk died; maybe
the system administrator removed a crucial configuration file; maybe the
operating system ran out of file descriptors; etc.

> misconfigurations is an important aspect of interoperability.

By that argument, anybody using AXFR is violating ``interoperability,''
because my recommended use of rsync-over-ssh does a vastly better job of
detecting and reporting common misconfigurations.

---

From: Greg Hudson <[email-masked]>
Date: 29 Nov 2002 21:27:48 -0500

> operating system ran out of file descriptors; etc.

Those were two unrelated arguments.  The paragraph was not intended to
support the second, merely to argue that REFUSED is much clearer than
FIN.

The reason why I don't think a FIN can reasonably be construed as an
error message is: at the TCP level, it's not an error, and at the DNS
level, it's not a message.  An unexpected FIN is rather analagous to a
Unix seg fault; it's an indication that something went wrong, but it's
not an error message.

> detecting and reporting common misconfigurations.

Sure, the interoperability of AXFR, and DNS in general,suffers from poor
error reporting.  So?  Your original argument was that mandating an
error message for a refused AXFR was not necessary for interoperability
at all.  If that were true, then virtually all IETF protocols would be
violating RFC 2119 by mandating separate error codes for separate
failure conditions.

(Of course, even if rsync-over-ssh of zone files is more interopable in
the area of error reporting, it isn't very interoperable in general; it
won't work between BIND and djbdns servers, for instance.)

---

From: Danny Mayer <[email-masked]>
Date: Fri, 29 Nov 2002 20:05:08 -0500

>BIND company employee Danny Mayer writes:

I am not and never have been an employee of either ISC or Nominum.

> > You can't clarify without breaking something.

No, it's reality.  You wouldn't need to clarify if the RFC weren't ambiguous.
Since it's ambiguous, people have made different interpretations of the
spec resulting in compatibility problems. So the clarification means that
someone's interpretation be noncompliant with the draft. Right now
that means yours will be noncompliant. Maybe others too.

>protocol. This need not, and should not, break anything.

If the spec is unclear there are bound to be people not implementing
the same way as everyone else.

>interoperability problems.

No, the cost is not relevant. What is relevant is doing it right so
there are no future problems and any future extensions will be
implementable in some reasonable fashion.  The only question being
addressed here is what is the meaning of "right"?

>protocol extensions work. Compatibility is not rocket science.

You can't fix IXFR if AXFR is not nailed down.

>use, the mark in commerce. See 37 C.F.R. 2.33.

Your statement does not include the word sell, for profit or otherwise.
There are many non-profits in the US that have trademarks. You also
seem to be restricting yourself to the US. Are you saying that ISC
cannot trademark the name whereever they please?

Danny

---

From: Dean Anderson <[email-masked]>
Date: Sat, 30 Nov 2002 01:34:11 -0500 (EST)

> No, the cost is not relevant.

I think this is absurd, and irresponsible. Cost and effects on
interoperability are always issues to be seriously considered.

> What is relevant is doing it right so

"Right" might not be the same as "Common". But changes from common aren't
"clarifications".  "Right" depends on your point of view.

> You can't fix IXFR if AXFR is not nailed down.

I'm OK with that. However, AXFR should be nailed down in ways that
correspond to how people reasonably interpreted the vague spec. The
clarification should be done so as to minimize the breakage to existing
implementations.

I think that AXFR can be nailed down without severely impacting existing
implementations, and I expect that IXFR can be made to work with the
existing (and clarified) AXFR.

> cannot trademark the name whereever they please?

This says nothing of the sort.

Non-profit is not the same as "non-commercial". The ISC uses names in
commerce: it seeks donations, owns property, hires employees, and (if I
recall, either offers either support or directions to Vixies consulting
operations), and promotes the Bind, Inn, and DCHPD packages.

ISC claims (rightly or wrongly) a trademark on Bind. That indicates that
it intends to use "Bind"  in commerce.  Whether it makes a profit or not
is irrelevant.  Bind is a product of ISC.

Whether that trademark claim is invalid (by prior public domain use by
UCB), is irrelevant.  Once ISC makes a declaration of a trademark, it
can't later say the "product" is not commercial.

		--Dean

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Nov 2002 04:27:03 -0000

Mayer claimed ``You can't clarify without breaking something.'' Is there
anyone else here who doesn't understand how ridiculous that claim is?

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

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

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.

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.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Nov 2002 03:30:01 -0000

Greg Hudson writes:
> at the DNS level, it's not a message

Irrelevant. The word ``message'' doesn't appear in the text we're
discussing. Anyway, the server hasn't authorized you to ask for AXFR in
the first place, so you have no right to demand a response. Go away.

> Your original argument was that mandating an error message for a
> refused AXFR was not necessary for interoperability at all.  If that
> were true, then virtually all IETF protocols would be violating RFC
> 2119 by mandating separate error codes for separate failure conditions.

You are massively confused. There is a huge difference between saying
``you must _not_ send this packet if you are _not_ in this situation''
and saying ``you must send this packet if you are in this situation.''

Trivial example: A 5yz response to SMTP VRFY means that the server won't
accept mail for that address. Facts:

   (1) It is crucial for interoperability that servers _not_ say 5yz if
       they are _not_ in this situation. Otherwise some clients will
       fail to deliver mail to that address.

   (2) There is absolutely no requirement for servers to say 5yz if they
       _are_ in this situation; and, in fact, most servers instead say
       252, deliberately hiding information from the client. This has no
       effect on interoperability.

Do you understand the difference between #1 and #2? Do you understand
why #1 is an interoperability issue and #2 isn't?

---

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: [email-masked]
Date: Sun, 01 Dec 2002 09:17:28 +1100

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

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

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

	Mark

---

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

[email-masked] writes:
> "Does your server meet RFC 1034 and return REFUSED under these conditions?"

Have you stopped beating your wife, Mark?

It is entirely up to the primary to decide who the secondaries are. RFC
1034 imposes no constraints on this decision. A non-secondary asking for
AXFR is violating the protocol (specifically, the text that you quoted),
and has no right to a response.

> I suspect that the DNS admistators of most ISP curse your stupid decision
> when trying to setup secondary service for one of their customers who
> is using your servers but forgot to adjust the access controls.

Funny how nobody has ever complained about that.

Maybe this is because step 3 of my upgrade-from-BIND instructions tells
people to authorize zone transfers from their third-party servers. Or
maybe it's because nobody actually gives a damn whether the AXFR client
prints useless error message #1 or useless error message #2---all the
useful information is on the server side.

Next, I suppose, you're going to demand that everybody have BIND-style
promiscuous defaults, so that users who ``forgot to adjust the access
controls'' don't have to be bothered fixing their configurations.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Nov 2002 19:17:31 -0000

> accordingly?  (If so, I'm all for it.)

Everybody agrees that a clarification would be useful. This document is
fraudulently posing as a clarification, and perhaps fooling some people
into supporting it for that reason.

Example: In his (false) declarations of consensus in March 2001 and June
2001, Gudmundsson claimed that this document ``formalizes the zone
transfer protocol in accordance with the fielded DNS server software.''
Sounds great, doesn't it? The problem is that it simply isn't true.

If you're asking whether dishonesty is acceptable, the answer is no. If
you're asking whether dishonesty is the only problem with axfr-clarify,
the answer is no. See http://cr.yp.to/djbdns/axfr-clarify.html.

---

From: Danny Mayer <[email-masked]>
Date: Sat, 30 Nov 2002 19:28:47 -0500

>interoperability are always issues to be seriously considered.

The cheapest thing would be to do nothing. It is, however, not the right
thing to do. Figure out the right thing first and then you can take a
realistic view of the costs.

>"clarifications".  "Right" depends on your point of view.

It didn't mention the word common. I said right. Right is very rarely objective
anyway, so what's your point?

>existing (and clarified) AXFR.

That's what the document is trying to do. So far nothing that you said
discusses the document, just how "unfair" it is to djbdns.

>can't later say the "product" is not commercial.

Assuming that you are in the US, you know nothing about UCC. I suggest
an introductory course in the Uniform Commercial Code before you discuss
this so knowledgably. Please point me to a site that is selling BIND on
behalf of ISC.

Of course, it is relevant to point out that if BIND were a commercial product
it would cost more, in real money, to have it changed than for djbdns to be
changed. Since djbdns is apparently a non-commercial product and noone
is employed to make changes or fixes to it, it costs nothing to change and
we have therefore chosen the cheapest alternative.

Danny

---

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