Subject: [dnsext] XFR-ng, was New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-01 (fwd)

From: Shane Kerr <[email-masked]>
Date: Mon, 01 Nov 2010 15:59:18 +0100

Alfred,

[ I left a lot of text in here relative to my comments. Apologies but I 
  can't think of a careful way to remove text that doesn't run the risk 
  of me dropping context. ]

On Wed, 2010-10-27 at 16:47 +0200, Alfred Hönes wrote:
> > One concern is this:
> >
> >    If an IXFR server is not able or willing to send the incremental zone
> >    change information to transform the client's version (sn_o) to its
> >    newer version (sn_n), the server SHOULD, in the case of QTYPE=IXFR,
> >    fall back to AXFR (see below); however, it MAY, and in the case of
> >    QTYPE=IXFR-ONLY, it MUST respond with an appropriate error, e.g.,
> >    CannotIXFR (see below) in the case of QTYPE=IXFR-ONLY.
> >
> > I don't know that CannotIXFR should be supported for QTYPE=IXFR. Clients
> > that do not support this RCODE will get different behavior than they
> > expect. I don't think it offers much improvement, so best to leave it
> > out.
> 
> Maybe the language is not clear enough, but I think we agree perfectly:
> The clause,
> 
>              "... it MUST respond with an appropriate error,"
> 
> was intended to indicate a "reasonable" RCODE -- one that the server
> expects being understood by the client -- , and then the particular
> case:
>    "..., e.g., CannotIXFR (see below) in the case of QTYPE=IXFR-ONLY."
> 
> was intended to say that *in case of QTYPE=IXFR-ONLY*, CannotIXFR
> _is_ the appropriate error.
> 
> I hope the second paragraph in 3.2.1 is consistent with that
> interpretation.
> 
> Do you have a text suggestion for improving the above clause?
> 
> BTW, I'm not sure whether existing IXFR implementations ever consider
> responding with an error (the MAY above) or always fall back to AXFR.
> The verbiage was chosen in this manner to allow different behavior of
> server implementations to remain conformant with the new spec, and to
> encourage client implementors to do very robust encoding.

AFAIK, all existing IXFR implementations fall back to AXFR. I think it
would be confusing if some implementations started returning an error.
So I recommend that the specification leaves that "as is" (see below for
more ideas though).

> > Regarding the question of whether CannotIXFR should be an RCODE or an
> > extended RCODE, I think actually that an extended RCODE makes sense. In
> > the case of IXFR we have co-operating servers, so getting EDNS working
> > between them is probably not such a big task in the normal case.
> 
> That was the conclusion I had drawn personally as well, but I wanted
> to be neutral and leave it as an open topic for discussion.
> 
> If we adopt this version, EDNS needs to become mandatory for IXFR-ONLY
> queries, and the text in 3.1.5 and 3.2.5 needs minor tweaks as well to
> reflect this.

Okay, agreed.

> > Finally, some servers will never be used as an IXFR server, and so
> > should always be happy with condensed replies. Some servers will be used
> > as an IXFR server, and as such probably *never* want a condensed reply.
> > (How the server knows which is true is an open question. However a good
> > rule of thumb may be that if no IXFR client are authorized for a given
> > IXFR server that it will be happy with condensed replies.)
> >
> > Perhaps a way for an IXFR client to signal either a desire for condensed
> > replies or not might be useful?
> 
> Splendid observation!
> 
> The signalling could be performed with an EDNS option.
> 
> But ... thinking out loudly ...
> 
> in that case, an alternative method to request IXFR-ONLY would be
> to remain stuck with QCODE=IXFR and steer the IXFR server behavior
> with the value of a more generic, say IXFR-Qualifier EDNS option.
> The value might be an octet encoded as independent flag bits.  This
> would allow to encode nuances of the desired IXFR server behavior.
> 
> This solution seems to have the same, or even better backwards
> compatibility properties: a server that is unaware of IXFR-ONLY
> would ignore the IXFR-Qualifier EDNS option and simply behave
> as before for IXFR.  This is impossible with QCODE=IXFR-ONLY,
> and during a phased upgrade of servers for a zone the alternative
> solution thus would save one round-trip.  However, refusal of an
> unsupported IXFR-ONLY allows to switch to another server ...
> So this will be an engineering compromise to choose.
> 
> In case we'd use such "IXFR-Modifier" EDNS option, I would also want
> to define an "understand IXFR-ONLY" bit in that option, set to 0 by
> the client and set to 1 in the response by an IXFR-ONLY aware server.
> (This would allow the client to distinguish an IXFR-ONLY aware server
> from an IXFR-ONLY unaware server that blindly echoes EDNS options
> received.)
> Maybe it would also make sense then to have the server clear those
> option bits corresponding to behavior variants that the server was not
> able to perform, and let those bits set to 1 that it was able to honor.
> 
> If all that is done, sophisticated IXFR clients could "profile"
> IXFR servers and use this information (maybe subject to some kind
> of aging, to allow for changes in the deployment like software updates
> or config changes to be accommodated seemlessly) to improve their
> server selection strategy.  (All local matter!)

This was among the first ideas that came up when I was discussing this
with Ondřej Surý. However, the problem with this is that if you connect
to a server that does not understand the EDNS options, you will have one
of three possibilities:

     1. The server considers this an error, and returns an error code of
        some description to you.
     2. The server considers this an error, and drops your message on
        the floor, leading to a timeout.
     3. The server ignores the EDNS option, and cannot perform an IXFR
        so starts sending an AXFR-style response.

The first one is fine - that is what you want. However, options #2 and
#3 are both unpleasant.

If we use a separate pseudo-message number, then a server who does not
support IXFR-ONLY will only have the first two options (returning an
error code, or dropping the message). I don't think there is a way to
avoid badly-implemented servers who don't return errors to clients, so
we're stuck with #2. (Credit: it was Ondřej who came up with the idea
use of a separate pseudo-message number to avoid the problems of #3.)

But, thinking about this further... maybe the best thing to do is not to
use IXFR-ONLY as a separate pseudo-message number, but rather to create
a separate pseudo-message. Something like IXFR2, or EXFR (extensible
transfer) perhaps? This could combine the following options:

      * AXFR transfer if IXFR not allowed
      * Compressed IXFR desired, not desired, or don't care
      * zlib compressed AXFR (and IXFR?)

Yes, I just threw in that last one. Once upon a time there was something
called ZXFR which ended up being dropped. The message that references
its death even mentions making it an EDNS option:

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00554.html

In fact a custom DNS compression scheme might give even better results
both in CPU and size than a generic compression algorithm, but zlib is
an reasonable choice I think, because of the number of solid
implementations available.

There may be other possible XFR improvements, although this is all the
ones that I was thinking of. :)

--
Shane