Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification

From: Dean Anderson <[email-masked]>
Date: Wed, 19 Feb 2003 16:20:03 -0500 (EST)

On Tue, 18 Feb 2003, Andreas Gustafsson wrote:

> Dean Anderson writes:
> > Zone definition and content is not an AXFR issue.  Server administrators
> > provide the definition of zone boundaries. (RFC 1034 Section 2.3 and
> > elsewhere)  AXFR merely gives the contents of the zone as has been defined
> > according to the boundaries and content specified by the administrator.
>
> This is exactly what the draft says, so what are you disagreeing with?

Uhh, no. Draft 05 says quite a bit more.  It subtly changes a number of
things that shouldn't be, and don't need to be changed. In fact, looking
at my copy, it doesn't say anything like the above at all.  (But assuming
it did, it would be redundant and could be deleted). Perhaps we don't have
the same copy of the file. My copy was printed from
www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-05.txt.

I disagree with everything in the draft that deviates from the common
assumptions made by implementations besides Bind 9.

Specifically, (and I'll try to be complete, but this is just off the cuff
for this message)

The second paragraph of Section 2 should be deleted.  Specific
implementations are not to be mentioned in RFC's.

In section 3, where it says "MUST" it should say "MAY", and where it says
"MAY", it should say "MUST".

Section 3.1 seems like a good idea, however, it is a modification to AXFR,
and should have a new request code. I suggest calling it MAXFR and giving
it code 253.  Support for this request code should be optional, and a
server may respond using the original (one record per message) AXFR
method. Upon discovering non-implemenation, clients should fall back to
AXFR or fail as determined by implementation or configuration.

Section 3.3 should be deleted. This is up to the administator and/or the
implementation.  SIG processing is not addressed, neither by when the
server should put them in, nor by what the client should do with them if
present.

Section 3.4 should be deleted.

Section 3.5 and 3.6 should be deleted. Data can come in either authority
or additional sections.  There are no transaction signatures, except for
id, question, and serial number.

Section 4 should be deleted.  Clearly, glue records need to be merged in.

Section 5 paragraph 3 should be deleted except for the first sentence.
In the forth paragraph, where it says "MUST", should say "MAY".
Clearly, duplicate records may indicate a misconfiguration, and their
presence in a zone can indicate a problem. Or not. It is up to the
administrators to determine how they configure there servers, and to
configure those servers consistently.

Section 6 should be deleted.  The status of these other RFCs is not to be
altered except by appropriate standardization process.  This is an
inappropriate end-run around that process.

Whether zone data is public is an administrative decision not limited by
RFC. Administrators are free to place or implement whatever restrictions
they wish on domain name records, and such administrative restrictions are
not limited to only zone transfer restriction. They can, for example, be
limited by node or record type, or any other way that can be invented and
found useful.

> The issue with BIND 8 is that it does *not* give the contents of the
> zone according to the boundaries and content specified by the zone
> administrator, but instead a mixture of data from different zones as
> specified by their different administrators.

Perhaps. Perhaps not. However, that would be an implementation issue, not
relevant to AXFR, or to the protocol.

Section 4.2 of 1034 says "it would be possible to partition the name space
so that each domain name was in a separate zone... In some cases, such
divisions are made purely to make database maintenance more convenient."

There is a huge amount of latitude on the administration of zone
boundaries.  Clearly, one has to be able to merge in glue records.  These
records are specified by the administrator, and so merging is appropriate.
If the administrator specifies them inconsistently, they may be
inconsistent.  No surprise there.  That is the ultimately the
administrator's fault.  It may not be possible for a secondary to detect
such misconfiguration in the master.

		--Dean

--
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: Thu, 20 Feb 2003 15:56:17 -0800 (PST)

Dean Anderson writes:
> it did, it would be redundant and could be deleted).

The draft says many things, and I understand that you are objecting to
several of them, but we were specifically discussing zone boundaries,
the subject of section 4.  Your statement that "server administrators
provide the definition of zone boundaries" is consistent with the
draft's existing wording and inconsistent with the BIND 4 / BIND 8
handling of zone boundaries which you previously claimed to support.

> Section 4 should be deleted.  Clearly, glue records need to be merged in.

Are you saying section 4 should be deleted because you disagree with
it, or because you find it obviously correct and therefore redundant?
Also, which glue records need to be merged into what?
-- 
Andreas Gustafsson, [email-masked]