Subject: Re: axfr-clarify's fraudulent claims of consensus

From: Dean Anderson <[email-masked]>
Date: Fri, 14 Feb 2003 20:12:20 -0500 (EST)

On Fri, 14 Feb 2003, Kevin Darcy wrote:

> "Can be made to work"? You mean, through some protocol clarification?

No, I mean that AXFR can be clarified to reflect current implementations
except for Bind 9.  The IXFR specification doesn't need to be changed.
IXFR implementations can work with the "current" (non-bind9) AXFR.

> > No. This isn't true either.  If we clarify AXFR to standardize the
> > _assumptions_ identically and concretely made by many implementors over a
> > long period of time, then BIND 9 will not be compliant
>
> Funny, I thought the job of the IETF was to *lead* the development and
> establishment of Internet standards. You seem to see their job as merely that of
> a historian/archivist of whatever _de_facto_ standards implementors throw out
> there, no matter how inefficient/convoluted/non-interoperable those _de_facto_
> standards happen to be.

Not at all. However, in the present case, we are dealing with a standard
that was made many years ago, and there are now multiple, interoperable
implementations of it.  In this case, the role of the standards body
(IETF) is to mediate the dispute on the ambiguous language that was
written a long time ago.

The "defacto" standards are in fact interoperable. I and others would like
to keep it that way. The "convoluted/non-interoperable" part is Bind 9.

It is also the role of the standards body to suppress gratuitous changes,
which harm stability and interoperability.

> Speaking as the architect of a large DNS infrastructure, AXFR is becoming less
> and less feasible for us as time goes by, because of scaling issues. We need
> IXFR ASAP, but we also need good interoperability between AXFR and IXFR because
> it's not like we can migrate from one to the other overnight. IXFR may
> technically be "optional" to implement, but in the real world, IXFR or something
> like it, is quickly becoming a practical necessity. This is because of the
> increasing size of zones and the frequency with which those zones are being
> updated.

You don't need to change AXFR to implement IXFR any more than it was
necessary to change SQL to implement incremental replication in Oracle, or
Sybase, or DB2, or even the proprietary wire protocols (all different, but
equivalent) used by these engines.

Either version of AXFR is equivalent for the purpose of IXFR. In both
cases, a server gets the contents of the zone from another server. IXFR
just needs to make incremental modifications to the zone database. Oracle
does this. It requires no changes--its just PL/SQL scripts--though the
script language needs access to its own transaction log, and the ability
to make remote updates to the other DB. Did I mention that it didn't need
changes to Net 8 or SQL. This isn't rocket science. DNS servers have
equivalent capabilities through IXFR.  Thus, from a turing machine POV,
they can execute the same operations. Q.E.D.

> Dean, if you're willing to pony up the thousands of dollars we waste every year
> because of inefficient zone transfers, then fine, we'll stick with AXFR
> indefinitely. I can give you the address to which to mail the checks. But I'll
> be damned if we continue to throw money down the toilet just because you and djb
> and a handful of others want to maintain compatibility with some nebulous
> _de_facto_ standard for AXFR.

You can implement IXFR. No one is stopping you from doing that. You just
can't change AXFR. Nor do you need to change AXFR from how is implemented
in everything else except Bind 9.

If people are so dull that they can't figure how to implement IXFR, well,
perhaps they should use Ultradns or some other DNS server with a DB
backend and hire an oracle, sybase, or db2, etc consultant as preferred to
setup replication and forget about zone transfers altogether.  Any
commercial Database Engine (and some non-commercial, I think) will happily
do incremental update for you, using a plethora of proprietary but
equivalent wire protocols.

If bandwidth is such a concern (hard to imagine at $50/meg at high
levels)... But if you want to pay me, I'll redo the AXFR and IXFR
protocols using ASN.1. (I'm close to releasing a free ASN.1 compiler that
implements most of the TMF C++ API standard and the ASN1 ITU standards.).
Perhaps we can use unaligned PER, which will use a fraction of the
bandwidth (practically all bits are used). We'll even compress the PDUs.
Everyone has zlib, right? I'd guess we can reduce bandwidth to about 30%.
We'll call it AXFR/2 and IXFR/2.

Then we could update the resolvers to use aligned PER (not as efficient
but easier to encode and decode), we could probably save even more
bandwidth worldwide.

Not that I'm seriously proposing this--It would save some bandwidth, but
the deployment costs would outweigh any savings. ASN1 has advantages and
disadvantages, but we are now committed to protocols for DNS specified
years ago, and can't run off changing them gratuitously because we have a
new widget.

Of course, we certainly won't call an ASN1 proposal a "clarification".
Maybe "alternate protocol for AXFR and IXFR"

		--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: Aaron Swartz <[email-masked]>
Date: Mon, 17 Feb 2003 17:31:51 -0600

Kevin Darcy wrote:
> the thousands of dollars we waste every year because of inefficient 
> zone transfers

If you're serious, then you should switch to gzipped rsync immediately. 
I bet you'll save far more than you will with IXFR. I'm sure you can 
find someone who will set it up for you in return for thousands of 
dollars.

-- 
Aaron Swartz [http://www.aaronsw.com/]