In message <fekfdkyxljtjbbkmdqnubalwwxbg.zhanghai...@cnnic.cn>, "=?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 <p...@nohats.ca> > >Reply-To: > >To: "zhanghai...@cnnic.cn" <zhanghai...@cnnic.cn> > >Cc: dnsop <dnsop@ietf.org> > >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
