ohh,yes. TCP must be implemented in name server in RFC 5966. I think it is the problem which came from UDP protocal. It maybe better if this problem can be handled in UDP protocal, not switch it to TCP protocal. If the TCP traffic is heavy, other problems may come out for DNS service in the future, like performance issue. Of cause, all of problem which I mentioned in the draft can be handled in the TCP protocal. and thanks for your comment.
----------original mail ------------------ >From: Mark Andrews <ma...@isc.org> >Reply-To: >To: 张海阔<zhanghai...@cnnic.cn> >Cc: p...@nohats.ca, dnsop@ietf.org >Subject: Re: [DNSOP] draft-zhang-dnsop-weak-trust-anchor.txt >Date: Sat, 31 May 2014 20:35:27 +1000 > In message , "=?gb2312?B?1cW 6o8Cr?=" writes: > The TCP is an optional protocal for DNS query at the auth name server side, a > nd 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 TCP has never been optional. Optional is MAY. TCP was part of the base spec. RFC 103[45]. RFC 1123 said SHOULD. i.e. you need to have a very good reason to not implement it. TCP has since been made a MUST RFC 5966. As for DNSSEC you would be insane to disable TCP if you are serving a signed zone. Mark > ------------------ origin email ------------------ > >From: Paul Wouters > >Reply-To: > >To: "zhanghai...@cnnic.cn" > >Cc: dnsop > >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, zhanghai...@cnnic.cn 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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
