The TCP is an optional protocal for DNS query at the auth name server side, and is not mandatory, so not every DNS service will support TCP. so I think we should provide a method to get rid of it by UDP protocal.
thanks for your feedback. haikuo ------------------ origin email ------------------ >From: Paul Wouters <[email protected]> >Reply-To: >To: "[email protected]" <[email protected]> >Cc: dnsop <[email protected]> >Subject: Re: [DNSOP] draft-zhang-dnsop-weak-trust-anchor.txt >Date: Fri, 30 May 2014 14:11:45 -0400 (EDT) > On Fri, 30 May 2014, [email protected] wrote: > Name: draft-zhang-dnsop-weak-trust-anchor > URL:http://www.ietf.org/internet-drafts/draft-zhang-dnsop-weak-trust-anchor-00.txt > Status:https://datatracker.ietf.org/doc/draft-zhang-dnsop-weak-trust-anchor/ > Htmlized:http://tools.ietf.org/html/draft-zhang-dnsop-weak-trust-anchor-00 > > > Abstract: > DNS Security Extensions (DNSSEC) is an effective method to provide > security protection for resolvers and end users in the DNS protocols. > But the DNSSEC is too aggressive for the DNS service in the poor > network infrastructure, because the domain name will be invisible > when large DNSSEC messages were dropped by some other network > equipments, like the routers which have MTU problem or the old > firewalls which do not support ENDS0. This document defines a new > concept weak trust anchor which can be used on a security-aware > resolver to get rid of the above problem. > > > I am looking for feedback for this draft, feel free to comment. A very skeptical person would describe this draft as a protocol backdoor to disable DNSSEC to faciliate DNS spoofing to unwitting victims. The draft claims to address two problems: 1 MTU issues with DNSSEC by misconfigured firewalls dropping large (and/or fragmented?) UDP. 2 old firewalls dropping EDNS0 packets by not recognising these as valid DNS packets. The first issue is not a problem, the DNS software could request smaller UDP packets using EDNS0, or it could fall back to TCP. No protocol modifications are required for this to work. The second issue is about broken software for a standard released in August 1999 (RFC 2671), and assumes that the end hosts will actually timely update by implementing this new 2014 document??? And to accomodate such broken software, it would requires the client to completely disable DNSSEC when the network filters out expected DNSSEC responses to queries it sent, without being able to tell this packet drop was due to "old firewalls" or a MITM attack. If this document is really meant to assist newer endnodes from operating in old broken networks, you should find a way to accomplish this that does not require disabling DNSSEC and does not require any DNS protocol change. Note also that for this problem, there is already a commonly deployed solution at the application level that addresses this situation, such as https://www.nlnetlabs.nl/projects/dnssec-trigger/ which will inform the user the network is severely broken or the user is under attack, and gives the user the option to disable DNSSEC and go "insecure". Contrary to the proposed draft, the user is informed and consent is requested before disabling a security control the user has activated for good reasons on their system. I do not believe your stated problem is one that needs addressing. I do not believe the Security Considerations section of your draft even remotely begins to address the problems of completely disabling DNSSEC transparently without user consent. Paul _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
