Dean,
The following message pretty clearly illustrates the frivolous nature of
John Brown's "dispute", as he is quite well aware that DNSSEC requires TCP
queries of the root servers, and in fact has been //advocating// for it.
And he is also aware of other upcoming technologies and developments that
will both increase the size of the packets and hence increase the number
of TCP connections made on the root servers.
Nothing in the messages quoted below says anything about DNSSEC requiring TCP.
Nothing in the protocol specs says anything about DNSSEC requiring TCP.
In fact if you take a look at the actual protocol you'll notice that it is not even possible to have DNSSEC information returned unless you utilize EDNS(0). With EDNS(0) you'll also get the ability to advertise a larger UDP reassembly buffer capability than 512 bytes which more or less takes care of your DNSSEC worries.
Can we please stop the DNSSEC red hering now?
Johan
It is completely frivolous to claim that 'DNS queries are "mostly UDP",
and that we need not worry about TCP queries'. We already know that at
present and historically that UDP is the common case. Taking cheap shots
in frivolous disputes is no way to work on problems.
--Dean
---------- Forwarded message ---------- Date: Mon, 14 Oct 2002 23:57:00 -0600 From: John M. Brown <john@xxxxxxxxxxx> To: 'Masataka Ohta' <mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx>, "'Loomis, Rip'" <GILBERT.R.LOOMIS@xxxxxxxx> Cc: dnsop@xxxxxxxx Subject: RE: Interim signing of the root zone.
anycast root opens the root system up to more capture, even if its localized capture, its still capture.
Who decides on who can "anycast" the zone and how do we know its the right zone ?
signing the root, by whatever means is decided upon, helps assure that the data is in fact "the original stuff".
If the country of Futuro (make believe) decides to run its own "root" via an anycast system, and they change the NS RR set for .JP, how are users going to know that?
maybe I'm just naive.....
john brown
-----Original Message----- From: owner-dnsop@xxxxxxxx [mailto:owner-dnsop@xxxxxxxx] On Behalf Of Masataka Ohta Sent: Monday, October 14, 2002 10:31 PM To: Loomis, Rip Cc: 'dnsop@xxxxxxxx' Subject: Re: Interim signing of the root zone.
Rip
as dnssec is finally approaching deployment, it seems imprudent to rush into a not obviously critical anycast deployment when a little patience would seem harmless.
DNSSEC, or any CA-based security, is not really secure and is undeployable for any practical security.
With all due respect, you've made such claims/statements on the list before,
And the only counter argument was:
My teacher taught me differently, I think.
Please feel free to back up that opinion with fact, or don't waste peoples' time with it.
If security is compromized, who pays how much?
Have you ever checked the reality of terms and conditions of CAs?
Better yet, if you think things are slightly broken then propose a fix. If you think things are *very* broken then propose a workable alternative and explain why things are so broken.
The current DNS is working well with weak security replying on ISPs.
Those who need additional security should share a secret end to end without introducing intellignet intermediate entities of CAs.
So, I don't think I have to propose a workable alternative.
Nonetheless, I proposed anycast root, which improves security against spoofed route.
On the other hand, DNSSEC is unworkable as evidenced by the failed deployment attempt for so many years.
Observing the failure, I gave an explanation why it is hopeless.
Masataka Ohta #------------------------------------------------------------- --------- # To unsubscripbe, send a message to <dnsop-request@xxxxxxxx>.
#---------------------------------------------------------------------- # To unsubscripbe, send a message to <dnsop-request@xxxxxxxx>.
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf