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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Brian Dickson 
writes:
> 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. =A0The 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 fu=
> ll
> > 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? =A0Let the zone EXPIR=
> E?
> > =A0Is a dead server better than a server that is taking time to sync up?
> > =A0(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
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext

Ed,
    the problem is that in some ixfr implementations there is no
way to turn off, the optional, delta consolidation.  If your then
have a server being fed from two+ intermediate servers (for redundancy)
that are in turn being fed servers that consolidate deltas you get
lots of AXFR style responses when you switch between intermediate
servers.

With this setup the intermediate servers don't have all the changes
that have occurred to the zone so they can't always generate a delta
style response as they don't have the starting point.

This exact senario was warned about in Section 6 of RFC 1995.

   But, this feature may not be so useful if an IXFR client has access
   to two IXFR servers: A and B, with inconsistent condensation results.
   The current version of the IXFR client, received from server A, may
   be unknown to server B. In such a case, server B can not provide
   incremental data from the unknown version and a full zone transfer is
   necessary.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]