Sorry, Too too late response.
> From: Rob Austein <[EMAIL PROTECTED]>
> Date: Fri, 19 Nov 2004 16:41:50 -0500
> I had a couple of comments on Fujiwara-san's presentation at the DNSOP
> meeting at IETF61, and promised that I would send them to the list.
>
> 1) Regarding the reported problem with the five minute timeout on RFC
> 2308 SERVFAIL caching and the suggestion to fix this problem by
> increasing the cache timeout to several hours: it might be better
> to treat this as a polling problem. That is, leave the five minute
> timer in place, and when the five minute timer expires, it's time
> to consider the possibility that the server has recovered, so one
> should send it a packet or three to see what it does, while
> continuing to answer queries as if the server were still known to
> be bad until results from the poll become available. This is
> similar in concept to the way that TCP zero-window probes work.
Agree.
Indeed, this problem occured on old BIND-8 caching server.
Newer caching server (BIND 9) was not influenced .
There are some solutions for this problem.
I and other authors will add this point to -02.
I think I should drop protocol changes.
> 2) The recommendation that name servers MUST support EDNS0 if they're
> going to send back response messages larger than 512 octets seems
> reasonable. The need for name servers to support TCP as well if
> the message size exceeds 1200 octets is less obvious: it seems to
> me that EDNS0 is enough.
I also think EDNS0 is enough if the message size exceeds 1200 octets.
It should be noted that EDNS0 uses IP fragmentation affirmatively
which IPv6 specification discuorages.
> Part of the reason why the TCP requirement concerns me is that I
> suspect that such a requirement would simply be ignored, so if TCP
> support really is a requirement, we're going to have to make a very
> compelling case for why TCP is the only solution. Since I'm pretty
> sure that EDNS0 is enough, I suspect that we cannot make that
> strong a case for TCP.
So, I will write new I-D for future dns transport till next monday (as
much as possible).
1. EDNS0 is enough for everything
OK for DNS anycasting.
But may be larger than 4096 octets
especially in DNSSEC
And There are some misconfigurations which contains 10k octets PTR RRs.
-> I think it is not resolved, but it costs much!!! for resolvers.
2. anycast vs TCP
There are bad cases and good cases. I think we need protection
mechanism or protection specification in cache server
implementation/specification.
3. Future DNS service
Root, TLD case
Major site's case
(DNSSEC case)
resolver server
--
Fujiwara, Kazunori JPRS
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
