Subject: Re: [dnsop] comments on draft-fujiwara-dnsop-bad-dns-auth-01

From: [email-masked]
Date: Sat, 05 Feb 2005 07:56:47 +0900 (JST)

Sorry, Too too late response.

> From: Rob Austein <[email-masked]>
> 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

---

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Feb 2005 10:34:33 +1100

>      implementation/specification.

	EDNS is required to get referrals through which contain
	enough glue in a dual stack IPv4/IPv6 world.  DNSSEC will
	just increase the need.  

	TCP is required to get the larger answers application writers
	are requesting from the DNS.

	Both in my opinion are manditory to support in servers and
	interative resolvers.  One an get away w/o EDNS in stub
	resolvers until you require DNSSEC which requires EDNS.  

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: [email-masked]
Date: Wed, 09 Feb 2005 20:21:08 +0900 (JST)

> From: Mark Andrews <[email-masked]>

Agree, but both two have weakpoints each.

EDNS0 weak point is in IP fragmentation. I think EDNS0 can support
4096 or 8192 octet, but 65535 octets is unimaginable.

TCP may not work when BGP route flap occuer or BGP transit network
uses BGP per packet load balancing (which is not allowed in RFC1771
BGP4, but it exists).

How large DNS data can be carried by EDNS0?

     -   512    UDP
513  -  4096    UDP with EDNS0
4097 - 65535    TCP?

> 	resolvers until you require DNSSEC which requires EDNS.  

agree.

Transport between authoritative servers and iterative resolvers and
transport between stub resolvers and caching(resolver) servers should
be considered separately. need to consider...