Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02

[Brian Dickson <[e-mail]>]

On Thu, Jun 16, 2011 at 3:22 PM, Edward Lewis <[e-mail]> wrote:

> 2. For the first time I have thought abotu IXFR-only and I don't get it at
> all.  The reason is I don't accept that "If this is not possible, in the
> case of bare IXFR, the server falls back to AXFR, i.e. it provides the full
> zone content."
>
[snip]
>
> RFC 1995 never specifies that a failed IXFR will cause an AXFR to happen.

Actually, it does, right at the beginning of section 4. Quoting the text:

4. Response Format


   If incremental zone transfer is not available, the entire zone is
   returned.  The first and the last RR of the response is the SOA
   record of the zone.  I.e. the behavior is the same as an AXFR
   response except the query type is IXFR.


> Thinking in another vein, if a client chooses not to ever use AXFR, then
> what happens when IXFR requests can't be satisfied?  Let the zone EXPIRE?
>  Is a dead server better than a server that is taking time to sync up?
>  (This calls out the motivation for IXFR-only.)

Those fall under the scope of operator, rather than implementer, issues.
Presumably the operator will act sensibly, trying all available
sources for IXFR-ONLY,
before giving up and doing an explicit AXFR.

The need for IXFR-ONLY is the desire to have interoperable implementations.

Suggesting that non-interoperable implementations of IXFR, to support IXFR-ONLY,
goes against common sense.

It is reasonable to expect zone administrators to operate multiple
authority servers for their zones.
It is reasonable to expect that zone administrators will want to have
zones instances be identical.
It is reasonable to expect that zone administrators may want to
operate servers from multiple vendors.

When you combine "multiple vendors" with "zone instances identical",
and add in "efficient transport",
you get the requirement for inter-vendor, interoperable IXFR, quite
possibly with IXFR-ONLY as a desired
capability.

The problem is, there is no current work-around, and adding this
without -bis standardization, isn't
necessarily interoperable. Better to update the standard. It's a no-brainer.

(End of flogging of the deceased quadroped.)

Brian