Subject: [dnsext] A few notes on the IXFR-ONLY draft

From: Alfred Hönes <[email-masked]>
Date: Fri, 30 Oct 2009 15:16:29 +0100 (MEZ)

An interesting proposal has been made in draft-kerr-ixfr-only-00,
but I did not find the time to take a closer look at it until now.

(Unfortunately a draft file name has been chosen that does not
allow automatic linking of the I-D as a "dnsext related" draft
to the DNSEXT WG page at http://tools.ietf.org/wg/dnsext/.
This has happened and cannot be changed any more, but it should
serve as a reminder to '-00' draft authors to profit by the IETF
tools for 'marketing' of their work.)

The major deficiency of the document currently is the non-use
of established precise terminology, making it somehow difficult
to quickly understand the intention.

The objective of the draft is to define a new QTYPE (see RFC 5395,
section 3.1, for the most recent exposition of the RRTYPE currently
defined categories).  However, the draft very imprecisely always
simply talks about an (unspecified) "type" -- not even "RR type"!
Please improve the precision of the text.

Similarly, I'd wish the draft to talk about "authoritative servers"
-- primary and secondary servers, not simply "master" and "slave",
or else state a definition of the shorthand terms.
Please note that the problem you want to address most likely will
occur in situations where the authoritative servers for a zone
are not structured in a strict master-slave relationship, but more
like (more or less fuuly-meshed) peers, making the general terms
"master" and "slave" particularly inappropriate.  RFC 1995 already
talks about primary and secondary servers, and has introduced the
terms "IXFR client" and "IXFR server", so this draft should
preferably use similar terminology.

Experience has shown that much confusion around the DNS has been
caused by non-use of precise terms for the roles of DNS entities,
and we should do better than other folks and attempt to use
exemplary terminology in a consistent manner.

So you will aks for better text.
Ok.
To give a starting point, here's my proposal for an improved Abstract:

OLD:

|  Presents IXFR-ONLY, a way for a DNS slave to prevent a DNS master
|  from falling back from IXFR to AXFR.

NEW:

|  This documents proposes a new QTYPE (Query pseudo RRtype) for the
|  Domain Name System (DNS).  IXFR-ONLY is a variant of IXFR (RFC 1995)
|  that allows an authoritative server to incrementally update zone
|  content from another (primary) server without falling back from IXFR
|  to AXFR in case of an SOA Serial mismatch.  This way, alternate peers
|  can be contacted more quickly and convergence of zone content may be
|  achieved much faster in important, resilient operational scenarios.

At this time, I refrain from mentioning editorial nits since
reworking of the text according to the principles suggested above
will perhaps allow to uncover and correct these, or they will get
moot anyway.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Joe Abley <[email-masked]>
Date: Sat, 31 Oct 2009 16:49:52 +0000

> |  achieved much faster in important, resilient operational scenarios.

Your text misses slightly here since you misrepresent the effect of an  
"SOA serial mismatch". The generation of an AXFR response to an  
inbound IXFR happens for server-specific reasons (most often, you  
would expect, because the specific delta requested by the IXFR client  
cannot be isolated by the server).

An SOA mismatch is expected for any kind of transfer; if the SOA of  
the zone concerned was identical on both servers then no transfer of  
any kind would normally be attempted at all.

Joe