Subject: Re: review of draft-ietf-dnsext-axfr-clarify-08

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Jun 2008 12:50:23 -0400

Before committing the recommendations, here are some responses to the 
discussion points.

At 21:10 +0200 6/11/08, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
>Below are my findings during another attempt to closely read
>the latest revision of the AXFR-clarify draft,
>     draft-ietf-dnsext-axfr-clarify-08.
>
>The items below mostly follow a linear walk-through of the draft,
>and they are interspersed with DISCUSS items that came into my
>mind during preparing of this review.
>
>
>(0)  General
>
>As already discussed, after a few revision cycles, the draft
>now should warrant transformation to the usual I-D format.
>
>NOTE:
>   Below, to visually better distinguish running text from excerpts
>   from the draft, the latter have been indented by 3 columns and
>   re-adjusted to 72 columns according to the common I-D formating
>   guidelines.

I don't understand this comment.  The draft as submitted was clipped 
to 72 characters.  I have never seen any requirement for indenting by 
3 columns.  The only id-nit noted was that I don't have pagination in 
there.  (And that waits until the text is down to word and spelling 
problems.)

>(3)  Section 2.1.5

>FOR DISCUSSION:
>   Which AXFR features can reasonably be expected from deployed
>   AXFR server implementations also supporting EDNS0 ?

A twist on the question.  Does anyone use EDNS0 over TCP?  EDNS0 is 
more than just a means to extend the permitted message length, so I 
would think that EDNS0   is in play.  For AXFR, maybe not in current 
form but in the future it is possible that an option might be 
directed at AXFR responses.  So I think it is prudent to anticipate 
that it might be there.

>(4b)   3rd paragraph + subsequent 'editorial note'
>
>[ question mark missing after that note ? ]
>
>Near the end of the paragraph, please   s/in to/into/ .
>
>I support the "MAY" you have solicited comments on, and I recommend
>an additional note that doing so (repeating the query in subsequent
>response messages) is bandwidth inefficient.
>
>FOR DISCUSSION:
>   If the AXFR server consistently echoes the ID from the query in
>   all of its response messages, the AXFR client can easily correlate
>   all these response messages with the original query, and the copy
>   of the Query Section into subsequent response messages seems to
>   have no benefit, even in the case the server admits interleaving
>   of the ongoing AXFR transaction with other transactions on the
>   same TCP connection.
>
>   Therefore, as a follow-up to the above DISCUSS:
>   Can we sensibly specify now than an EDNS0 capable AXFR server
>   servicing an EDNS0 client (i.e. after having sent an EDNS OPT RR
>   in the Additional Section of its first AXFR response message),
>   SHOULD refrain from repeating the Query Section from the AXFR
>   query in its subsequent response messages, if it consistently
>   echoes the query ID in all response messages ?

Something I'd like to hear from those with implementation experience 
- is it worth the parsing time to save the bandwidth?  Would this be 
an over-optimization?

>(4c)  4th + 5th paragraph
>
>The draft seems to be ambiguous in its provisions for error
>responses.  It is reasonable to allow an AXFR server to 'abort'
>a multi-message response at any time with a response message
>containing a non-zero RCODE.  Apparently, other parts of the
>draft seem to support this position, but the text here doesn't
>fully:
>
>    An AXFR response that is indicating an error MUST consist of a
>    single DNS message with the return code set to the appropriate
>    value for the condition encountered - once the error condition is
>    detected.  Such a message MUST copy the AXFR query Query Section
>    into its Query Section.
>
>With regard of the 1st paragraph of 2.2 stating ...
>
>    The AXFR response will consist of 0 or more messages.
>
>.... the above text might be understood as nor supporting this
>'late error' scenario.  I guess that has not been intended, and
>the subsequent (5th) paragraph strongly supports this interpretation.
>
>To rectify the issue, I propose to perform a slight amandment to the
>3rd paragraph, rephrasing ...
>
>      [...].  In such a series, the first message MUST begin with the SOA
>    resource record of the zone, the last message MUST conclude with the
>    same SOA resource record.  [...]
>
>.... to state:
>
>      [...].  In such a series, the first message MUST begin with the SOA
>    resource record of the zone, the last message MUST conclude with the
>    same SOA resource record, unless the response is prematurely aborted
>    by the server with an error message; see the discussion below.
>    [...]
>
>.... and to modify the 4th paragraph to say:
>
>    An AXFR response that is indicating an error SHOULD consist of a
>    single DNS message with the return code set to the appropriate
>    value for the condition encountered.  Under exceptional conditions,
>    e.g., a resource bottleneck or administrative intervention, a server
>    MAY prematurely abort a multi-message AXFR response in progress by
>    sending a response message with a non-zero RCODE.  Any such error
>    message MUST copy the original AXFR query Query Section into its
>    Query Section.

I don't think that that is acceptable, not from what I've heard in 
comments.  First, the points are that a positive transfer begins and 
ends with SOA's.  A transfer that encounters an error will send a 
single error response and terminate.  Finally, although it is not a 
blessed action, it is possible that a server may decide not to 
respond at all for some reason.  Even if such a server is considered 
to be non-compliant, a compliant client has to be prepared for such a 
possibility.

The problem is that we hear from a wide range of religious views on 
this.  We have folks that take the hard-line view that this is a 
client-server/query-response protocol and all actions deserve a 
reaction.  It is hard to reconcile this against populists that say 
the world is broken and we need to account for not always pairing 
actions and reactions.  The issue for me is that the divide is caused 
by implementers who are external to this process and aren't present 
to help hammer out some compromise by defending the rationale for "0 
message" answers.  The debate is not a head-butting-head situation, 
it's two off-kilter blows as is true in many long running 
sociological debates.

Still, I can try to re-word this topic.  There's not going to be 
anything that will keep all the different fundamentalist niches happy 
through.

Do I sound cynical?

>Once this modification has been adopted, the 5th paragraph can be
>simplified:
>
>    An AXFR client might receive a number of AXFR response messages
>    free of an error condition before the message indicating the error
>    is received.  But once an error is reported, the AXFR client can
>    assume this the reporting message is the last.
>---
>    The AXFR client can savely assume that an error reporting message
>    (with non-zero RCODE) is the last response message for its query.
>
>Otherwise,     s/this the/that this/   in the last line.
>

>(5b)  Note 2.2.1.b
>
>Please improve the language.  ...

I'm sorry, I can't fix "English." ;)  Sorry, couldn't resist.

>(5c)  Note 2.2.1.c, 2nd paragraph

>DISCUSS:  Promote  SHOULD NOT  to  MUST NOT  ?

Or demote "SHOULD NOT" to "ought not"?

>DISCUSS:
>
>   Need to clarify whether SIG(0) / TSIG have to be applied
>   a)  per message (in multi-message responses) or
>   b)  per response (i.e., last message of multi-message responses) ?

Per DNS message, that's what they are defined to cover, right?

Yes, it seems this has been over looked in the TCP session cases. 
But knowing what was discussed back then that did not make it into 
text was the assumption that a response refers to a single message 
and not the session in the TSIG/SIG(0) definitions.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 13 Jun 2008 22:14:21 +0200 (MESZ)

Edward,
thanks for your response to my review.

However, I suspect having been misunderstood a bit
regarding the error response issue.

> At 21:10 +0200 6/11/08, Alfred Hönes wrote:
>> ...
>> 
>> (4)   Section 2.2
>> ...
>> (4c)  4th + 5th paragraph
>> 
>> .... the above text might be understood as not supporting this
>> To rectify the issue, I propose to perform a slight amendment to the

I purposely had avoided to touch the zero-message "response" case.

[ Nevertheless and BTW,
  as you have asked for, here is my opinion on that topic as well:
  Yes, you sound cynical.  But that's ok, because the legitimate
  user more and more suffering under such blackholing behavior
  perceives that as being treated cynically as well.  Such behaviour
  IMHO is one of the most frequent sources of bad and annoying user
  experience.  Applications having to go through long chains of DNS
  timeouts also effectively cause more (retry) traffic to the non-
  responding servers because negative caching is made impossible.
  Fallback to "zero-message response" should only be admitted if
  the server has clear indications of being under attack.
  Furthermore, in the case of TCP, receiving an error response
  allows the client to orderly and quickly close the connection,
  which in turn allows the server to reclaim connection resources
  faster, while still conforming to the TCP RFCs. ]

The starting point, as quoted above, has been the sentence in the
draft:

   detected.  [...]

What if the error condition is detected after sending, say, fifty
response messages?  (E.g. the server being signalled to reload
updated zone data during an already long running AXFR session.)
Literally following the first part of the text above is impossible
then, but the subsequent "once the error condition is detected"
points out just that possible scenario, discussion of which
apparently is continued in subsequent draft text (e.g. the 5th
paragraph of that section - see quote below).

My change proposals have purposely been crafted to always being
conditional on *sending* an error message (at all), to avoid that
sad battle.  The whole discussion in my original notes only were
concerned with the case that the server *does* send a response;
if it doesn't, the circumstances under which to prematurely abort
a running multi-message response will never arise.

Sending the 'trailing' SOA in the abort case, after incomplete
zone data, seems to be a bad idea, since 'old' clients possibly
not expecting such error (and not testing for RCODE) might be
misguided to take that matching SOA as an indication of a
successful, *complete* zone transfer.

>> ...

> Per DNS message, that's what they are defined to cover, right?

Unfortunately, the TSIG/SIG(0) RFCs are ambiguous and disagree, as I
had explained; the latter says 'message', the former says 'response'.

> and not the session in the TSIG/SIG(0) definitions.

This confirms that a clarification is needed -- either in axfr-carify
or in upcoming (?) 'bis' documents for TSIG and SIG(0).

[ BTW: SIG(0) needs a self-contained specification anyway, after SIG /
  RFC 2535 which it is based upon has been obsoleted by DNSSEC-bis ! ]

Since we are doing axfr-clarify now, we should do it there.

Arguably, signing the whole transaction (concatenation of all
messages) is what many other protocols do, and that choice would
reduce the bandwidth needed and offload the server from crypto
processing during a protected AXFR session.

> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| 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: Edward Lewis <[email-masked]>
Date: Mon, 16 Jun 2008 16:02:57 -0400

I'm working my way through edits, reworking a lot of things in some 
places.  Good comments and if I didn't make the specific change I 
made major edits to accommodate the spirit.

But this one I am not inclined to make for two reasons.  One is that 
I purposefully undid your suggestion, whereby I created the list of 
DNSSEC documents in the second paragraph.  The reason was that I 
thought 3 reference links was too long a break for my short attention 
span.  So I decided to just postpone the individual references. 
Also, I have grown tired of documents that do not repeat the full 
title of the RFC because in all of our jargon-filled tirades we 
sometimes lose the real meaning of the documents.

Secondly, the reference to "the implementation" is in the context of 
this being a response field.  Hence the "set to" has to be by the 
server and "upon receipt" is what happens at the client.  Note that 
the distinction is whether the implementation does DNSSEC (hence 
conforms to RFC 4033-4035) or not.

It's not that I disagree with your suggestion, it's that I had made a 
choice to go the other way here.  I think both can work, but from my 
experience with RFCs, I think what's there now might be easier to 
swallow for an implementer.  (Oh, so tempted to make an 
implementer's-reading-ability joke here.)

At 21:10 +0200 6/11/08, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:

>(5e)  Note 2.2.1.e
>
>I suggest to make the references to the DNSSEC specifications less
>verbose.  This *note* is not intended to become an introduction to
>DNSSEC :-)
>Furthermore, the 2nd sentence in 2.2.1.e seems to be too unspecific;
>it does not properly address the possible cases of
>DNSSEC-aware vs. -unaware AXFR cleints/servers.
>
>Here is my attempt to improve the text (further enhancements
>solicited!):
>
>  Note 2.2.1.e If the implementation supports the DNS Security Extensions
>    (see below) then this value MUST be set according to the rules in RFC
>    4035, section 3.1.6, "The AD and CD Bits in an Authoritative Response".
>    If the implementation does not support the DNS Security Extensions,
>    then this value MUST be set to 0 and MUST be ignored upon receipt.
>
>    The DNS Security Extensions (DNSSEC) is defined in these base
>    documents:
>    - "DNS Security Introduction and Requirements" [RFC4033]
>    - "Resource Records for the DNS Security Extensions" [RFC4034]
>    - "Protocol Modifications for the DNS Security Extensions" [RFC4035]
>---
>|Note 2.2.1.e
>|
>|  If the server implementation supports the DNS Security Extensions
>|  [RFC4033] [RFC4034] [RFC4035], then these bits MUST be set according
>|  to the rules in RFC 4035, section 3.1.6, "The AD and CD Bits in an
>|  Authoritative Response".  If the AXFR server implementation does not
>|  support DNSSEC, then these bits MUST be set to 0.  If the AXFR client
>|  does not support DNSSEC, or if it is aware of the fact that the
>|  server does not support DNSSEC (e.g., by configuration, by the lack
>|  of an EDNS0 OPT RR in the Additional Section of the first response
>|  message, or by other out-of-band mechanisms), it MUST ignore these
>|  bits.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Jun 2008 16:52:58 -0400

In the spirit of letting you know why some changes weren't (yet) made...

At 21:10 +0200 6/11/08, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:

>(7)  Section 3.1, 2nd paragraph

>To clarify these exceptional cases, I suggest to amend the second
>sentence of this paragraph, e.g. (for clarity, I recommend
>splittin the paragraph into 3 parts):

I decided to just remove the section - the section should just talk 
about the contents and not the ordering.

>(8)  Section 3.2 ff.
>
>There are a couple of instances where the draft does not use
>'rational quotation' (treating quotes around terms or short phrases
>as text enhancements like the [impossible] underlining, subject to
>evident rules for pairing/nesting).

I'm going to leave this to the RFC Editor.  My learnin' says 
differently, if there was a book on grammar and stuff that convinced 
me I was wrong I'd change my ways.

>(9)  Section 3.2, reason 4) and subsequent 'Editorial Note'
>
>IMO, this discussion is out of scope.  It should be deferred to a
>future IXFR-bis draft.

Still there because I hope the commentor can fill in the blanks I have.

>(10b)  last paragraph
>
>I suggest to improve the wording of the very last sentence:
>
>                [...].  This document leaves AXFR over UDP undefined,
>    with the issue to be discussed and possibly appear in a separate
>|  definition.
>---^^^^^^
>                [...].  This document leaves AXFR over UDP undefined,
>    with the issue to be discussed and possibly appearing in a separate
>|  specification.
>    ^^^^^^^^^                                         ^^^

I was going to not do this, but decide to lop off the last two lines 
completely.  "Possibly appear" vs. "Possibly appearing" - to me the 
former has a subtle hint that this is less likely than the latter. 
As in "if it'll happen it's possibly appear after I retire" versus 
"when it comes out it will be possibly appearing in a document by 
John."  Yeah, maybe the latter grammer is poor, but that's way you 
might hear someone say it (not write it).

In either case, no one has revived a discussion on AXFR/UDP since the 
IETF in, well, where ever, so I'm not going to promote it anymore.