Subject: Re: objection to axfr-clarify

From: Aaron Swartz <[email-masked]>
Date: Fri, 14 Feb 2003 14:51:10 -0600

>> The vast majority of implementations do not do it this way (notably 
>> BIND8,
>> djbdns and UltraDNS) and I've only heard reports that one does 
>> (BIND9).
>> How can the actions of only one, recent application be the existing
>> protocol?
>
> You are incorrect regarding both BIND 8 and UltraDNS

Apologies, my testing code was broken.

> [returning an RCODE] is necessary in order to have an interoperable 
> means of indicating the reason for failure.

So? Indicating the reason for failure is not necessary for 
interoperability. The document already says ``slaves MAY interpret an 
immediate graceful close of the TCP connection as equivalent to a 
"Refused" response (RCODE 5).'' Why not require this client strategy 
and remove the requirement against the server strategy? Clients will 
likely have to implement this anyway (when it makes a difference); the 
1.85 million .com's running djbdns won't go away overnight.

>> "the master MUST send exactly those records that are associated with
>> the zone" How am I supposed to calculate which are associated?
> If you received the zone by AXFR, it's what you received in that AXFR
> (as opposed to what you received in AXFRs of other zones).

This would appear to prohibit the behavior of djbdns, which makes no 
distinction between AXFR data for one zone and another. Adding such a 
distinction is not necessary, and would make the software much more 
complicated and harder to use.

There seems to be an implicit assumption of using AXFR to update slave 
servers and being able to receive updates from those servers also. But 
this isn't part of the protocol, nor is it the protocol's only use. If 
you'd like to recommend this use, feel free, but please keep it 
separate from protocol requirements.

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

--
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: David Terrell <[email-masked]>
Date: Sat, 15 Feb 2003 03:15:54 -0600

> complicated and harder to use.

Server A loads a.b.c.test from disk.
Server B loads b.c.test from disk.
Server C axfr slaves a.b.c.test and b.c.test from a and b, respectively.
Server D axfr slaves b.c.test from C.

In your world, server D will have stale versions of *.a.b.c.test
data any time a has been updated more recently than b.

That's an interoperability failure, or in the words of one local
critic, "an AXFR disaster".

-- 
David Terrell          | Step 1: "configure one system using your GUI"
[email-masked]           | Step 2: "now configure 1000 more"
Nebcorp Prime Minister |   - Casper H.S. Dik
http://wwn.nebcorp.com |