Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification

From: Dean Anderson <[email-masked]>
Date: Tue, 18 Feb 2003 20:58:55 -0500 (EST)

On Wed, 19 Feb 2003 [email-masked] wrote:

> > Good. You found a bug in an implementation. I thought such things were
> > off-topic for this list.  This bug doesn't mean that AXFR is broken.
> > Bind 8 did not have this bug, yet it has the common understanding of AXFR.
> >
> > Let me summarize the discussion:
> >
> > Everyone agrees that AXFR specification in RFC 1034 is ambiguous.
> >
> > Some people, many associated with Bind 9 development, assert that it is
> > necessary to change AXFR to support IXFR.  This assertion has been refuted
> > on the grounds that incremental database update does not depend on AXFR,
> > since incremental database update does not depend on the underlying wire
> > protocol used to create the remote database which is to be modified by
> > IXFR. Conceivably, it is unnecessary to use AXFR at all, yet one could
> > still use IXFR, so, AXFR is independent of IXFR.
>
> 	Nobody is saying that preserving zone content is a *wire*
> 	issue.  It is a server behaviour issue.

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.
The contents could be given to the secondary by FTP or other method.  If
you mean to change the definition of zone contents, then I would say this
proposal is hugely mis-labeled.

All the IXFR server needs to do is determine (by some implementation
dependent, administrator maintained method) what has changed between one
zone version and another. How it does this is nobody's business but the
administrator and the implementor. There are infinite possibilities, here.
One could, for example, store differences in a series of files. The
administrator could even make the differnce files by hand--this is an
_implementation detail_. The IXFR server just sends a series or sequences
consisting of a list of deleted RRs and a list of added RRs to an IXFR
client. There is nothing more to it. (notwithstanding the optional
condensation.)

The IXFR client must simply make the changes (again, by some
implementation dependent, administrator maintained method) to the zone by
deleting RRs and adding RR's in each sequence. The original version of the
zone might have been obtained by FTP (or quantum interference, or the
psychic network) for all we know.

This isn't rocket science, and doesn't require any AXFR changes. Nor does
it require that the zone boundaries be defined only in some certain way,
beyond the definition of zone boundaries given by the system
administrator.

> > Some people, many associated with Bind 9 development, assert that AXFR as
> > commonly implemented by many implementors over many years, is broken, and
> > can't transfer domains correctly.  This claim has been refuted by
> > demonstration by interoperability between Bind 8 and other nameserver
> > implementations over the years, and 77% of the internet that currently
> > does not use Bind 9, yet still does AXFR.
>
> 	All this shows is that these nameservers are not used in
> 	situations where the breakage is demonstrated or the
> 	administators have learn to work around the breakage or
> 	choose to live with it or are unaware of it.

"administrators have learn[ed] to work around [it,...] live with it [,] or
are unaware of it".  Agreed.  Having done so, we don't want to stir the
pot.

Essentially, you are putting more (unnecessary) constraints on
implementations, and thus on the administrators, who are supposed to be
pretty free to define the zone boundaries.  Of course, the specifics of an
implementation puts some constraints on the adminstrator, but the
administrator can choose a different implementation more to her liking.

These unnecessary constraints are a "bad thing".

> > To prevent confusion between the two proposals, I would like to rename the
> > first proposal "Bind 9 AXFR Modification", and the second proposal "AXFR
> > Clarification". The term "axfr-clarify" will not be used.

I presume agreement on the name change?

		--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: Tue, 18 Feb 2003 18:51:58 -0800 (PST)

> according to the boundaries and content specified by the administrator.

This is exactly what the draft says, so what are you disagreeing with?

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.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Wed, 19 Feb 2003 14:42:22 +1100

> according to the boundaries and content specified by the administrator.

	Well BIND 9 does this.  CISCO's server does this according
	to John.  BIND 8 doesn't always.  BIND 4 doesn't always.
	DJBDNS doesn't always.  This is independent of the method
	used to transfer the zone to these servers or enter the
	zone contents on these servers.

> proposal is hugely mis-labeled.

	It's not changing the definition.  It is preserving the
	definition.

	It's not mis-labeled.  It is stating the implict assumption
	that AXFR transfers what is entered as the zones contents.
	Nothing more, nothing less.

> client. There is nothing more to it. (notwithstanding the optional

	All of which is irrelevent to this issue.

> psychic network) for all we know.

	Well the problem is that you have to get the *original* version,
	not a corrupted version.  AXFR implementations are not returning
	the data originally entered.
 
> beyond the definition of zone boundaries given by the system

	It does however require that for a given serial number that all
	sources of the zone have supplied identical contents.  You should
	be able to apply a IXFR delta to a copy derived from any source
	and have it apply without error.
 
> are unaware of it".  Agreed.  Having done so, we don't want to stir the

	LOL.
 
> administrator can choose a different implementation more to her liking.

	The constaint was already there and it is necessary for reliable
	operation of the DNS.
 
> I presume agreement on the name change?

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