Re: [dnsop] Re: WGLC for draft-ietf-dnsop-bad-dns-res-02.txt

["Larson, Matt" <[e-mail]>]

On Mon, 26 Jul 2004, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> Hmm, the revision number does not seem to be incremented from the
> previous one:
> [...]
> But there appear to be differences between the two documents
> (non-trivial ones such as the issue date).

I'm not sure what happened.  I definitely submitted -03 to
[e-mail], but it showed up as -02.

> And from a quick glance,
> the new version does not seem to address my comments on the previous
> one:
>   http://darkwing.uoregon.edu/~llynch/dnsop/msg02958.html
> 
> If this simply means the author decided to reject the comments, then
> it's okay (though I'll be sad then).  But at least I've not seen any
> responses to the comments, either positive or negative, so I'm making
> an explicit note just in case.

I did see your comments and I thank you for sending them.  I apologize
for not responding to them until now.  Please see below for my
response.

On Tue, 29 Jun 2004, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> (explicitly cc'ing to the authors)
> 
> >>>>> On Thu, 24 Jun 2004 13:04:08 -0700, 
> >>>>> David Meyer <[e-mail]> said:
> 
> > 	The WGLC on this one was scheduled to end today at 1500
> > 	PDT (GMT/UTC-7). However, there have been several
> > 	comments that need to be resolved before we can go
> > 	forward. We will revisit this one after the authors have
> > 	revised the document.
> 
> In section 2.2.1, the draft says:
> 
>    [...]
>    Implementations that perform lame server caching MUST refrain from
>    sending queries to known lame servers based on a time interval from
>    when the server is discovered to be lame.  [...]
> 
> In general, I agree on this recommendation.  But it might cause a
> rather undesirable result when all authoritative servers seem to be
> lame, since some authoritative server implementations can be lame for
> particular resource record types.  (See Section 4.4 of
> draft-ietf-dnsop-misbehavior-against-aaaa-01.txt for more details)
> 
> Of course, what is wrong here is "lame" authoritative servers.  But
> sometimes we need to explore workaround to deal with real-world's
> problems...

This is true and I overlooked this comment during the revision.
You're right that a sentence or two explaining the unfortunate "lame
by domain name" behavior would be helpful.

> Meanwhile, I'm not sure if the recommendation also applies to the case
> where *all* authoritative servers seem to lame.  In the beginning of
> Section 2.2, the draft says as follows:
> 
>    A more common occurrence is a subset of a zone's name servers being
>    unavailable or misconfigured.
> 
> But I could not be sure if this section (including the recommendation)
> only concentrates on the case where a subset of the servers behave
> badly or it also considers the case where all of them are bad.
> 
> If the intention is the former, then please make it clear throughout
> the section, particularly in Section 2.2.1.
> 
> If the intention is the latter, I hope the document also notes that
> the recommended behavior may sometimes cause undesirable result while
> the behavior generally makes sense.

The section is intended to apply on a per-server basis, i.e., what to
do when a given server is discovered to be lame for a particular zone.
I confess that I re-read the section several times and thought it was
clear.  I could not figure out a way to make it more clear.  Could you
please suggest specific changes?

Matt

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html