>>>>> On Fri, 19 Nov 2004 16:58:05 -0500,
>>>>> Rob Austein <[EMAIL PROTECTED]> said:
> This is a working group last call on the "Observed DNS Resolution
> Misbehavior" draft, draft-ietf-dnsop-bad-dns-res-03.txt, which we
> hope to submit to the IESG for consideration as a BCP document.
> This last call will terminate at 17:00 UTC on 6 December 2004.
> Please clearly state to the mailing list whether you support or oppose
> this draft going to the IESG.
> Please do not express an opinion if you have not read the draft.
> As always, please discuss substantive issues on the WG mailing list.
> Minor editorial comments may be sent directly to the draft authors
> (please CC the WG chairs on any such comments so that we can track
> this).
I think my concern to the previous last call (attached below) is still
there. It's my bad that I've not sent a proposed text to address this
that I promised before, but if you give me some more time, I'll make a
suggestion and send it to the list next week.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- Begin Message ---
(explicitly cc'ing to the authors)
>>>>> On Thu, 24 Jun 2004 13:04:08 -0700,
>>>>> David Meyer <[EMAIL PROTECTED]> 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...
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.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
--- End Message ---
