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

From: Alfred Hönes <[email-masked]>
Date: Tue, 26 Oct 2010 02:04:31 +0200 (MESZ)

Folks,
just in time ...   :-)

This is the work I had offered in Maastricht to carry out together
with Ondrej Sury.  My sincere apologies for needing "a bit" more
time than promised in the 1st DNSEXT session at IETF there.

The I-D represents a major rehashing of the IXFR spec from RFC 1995
in the style of, and making heavy direct and indirect use of, the new
AXFR specification, RFC 5936, thus emphasizing the commonalities of
both methods and avoiding replication.  It also incorporates as an
integral part the IXFR-ONLY proposal that Ondrej and Shane had
originally submitted in July 2009 (and updated in February 2010).

The draft is now "complete" from my PoV, and we are awaiting feedback.
Please look for possible omissions and inconsistencies.
We are particularly interested in feedback from implementers regarding
the detailed specs of procedures and on-the-wire format rules put into
the draft that were not described in similar detail in RFC 1995.

Further, since this is kind of "ordered work" matching previous
and future goals in the Charter, we'd like the chairs to poll
the WG for adoption of the draft as a work item of DNSEXT,
as soon as enough people have looked at the draft.

Kind regards,
  Alfred.

----- Forwarded message from IETF I-D Submission Tool -----

> From: IETF I-D Submission Tool <[email-masked]>
> To: ah@.TR-Sys.de
> Cc: [email-masked]
> Message-Id: <[email-masked]>
> Date: Mon, 25 Oct 2010 16:23:36 -0700 (PDT)
> Subject: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-01

A new version of I-D, draft-ah-dnsext-rfc1995bis-ixfr-01.txt
has been successfully submitted by Alfred Hoenes and posted
to the IETF repository.

Filename:        draft-ah-dnsext-rfc1995bis-ixfr
Revision:        01
Title:           DNS Incremental Zone Transfer Protocol (IXFR)
Creation_date:   2010-10-26
WG ID:           Independent Submission
Number_of_pages: 26

Abstract:
The standard means within the Domain Name System protocol for
maintaining coherence among a zone's authoritative name servers
consists of three mechanisms.  Incremental Zone Transfer (IXFR) is
one of the mechanisms and originally was defined in RFC 1995.

This document aims to provide a more detailed and up-to-date
specification of the IXFR mechanism and to align it with the current
specification of the primary zone transfer mechanism, AXFR, given in
RFC 5936.  Further, based on operational experience, this document
juxtaposes to the original IXFR query a new query type, IXFR-ONLY,
that will likely be preferred over IXFR in specific deployments.

This document obsoletes and replaces RFC 1995.

Discussion

This draft targets adoption by the DNSEXT working group.  Comments
should be sent to the authors and/or the namedroppers mailing list.

The IETF Secretariat.

----- End of forwarded message from IETF I-D Submission Tool -----

---

From: Shane Kerr <[email-masked]>
Date: Wed, 27 Oct 2010 15:22:53 +0200

Alfred,

Thanks for this!

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.

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.

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?

--
Shane

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 27 Oct 2010 16:47:29 +0200 (MESZ)

Shane,
thanks for the quick feedback.

> expect. I don't think it offers much improvement, so best to leave it

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.

> 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.

> 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!)

Best regards,
  Alfred.