Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt

[Mark Andrews <marka@isc.org>]

In message <4AE8E8E5.4030403@gmail.com>, Doug Otis writes:
> On 10/28/09 4:41 PM, Mark Andrews wrote:
> > In message<4AE8A694.5010801@gmail.com>, Doug Otis writes:
> >> Imposing _any_ TCP mandate represents an expedient that takes DNS in the
> >> wrong direction.  As such, this draft should also include a strong
> >> warning that resources needed to sustain TCP services might be
> >> provisioned for other transports during aberrant demand, and that it is
> >> not recommended to be dependent upon TCP availability.
> >
> > TCP has always been expected to be implemented unless you had GOOD
> > reasons to not implement it and had REALLY thought about the
> > consequences.  Read RFC 1034 and 1123.  TCP was not MAY.  It was
> > SHOULD.
> 
> The concern is about establishing a dependence upon TCP.  While TCP has 
> often been a fall-back for truncated DNS answers, it has never been 
> mandated.  A SHOULD is not a MUST.  TCP being functional for DNS was 
> never assured.  Even ensuring that TCP is enable does not ensure 
> availability of a lower priority service.  In addition, TCP is not 
> enabled by one the roots, and most CPE equipment.  While people can 
> configure their CPE equipment to bypass DNS proxy services lacking 
> proper TCP support, most do not.

And prey tell how are the customers supposed to know that they can
bypass it or even what values to configure?  If the CPE vendor
didn't want to implement a DNS server then they could have returned
the DNS servers learned from upstream or none at all.  Instead these
vendors choose to have their DHCP clients use their box as a DNS
server then failed to deliver on providing that service.

> > Does anyone here really think that any proxy vendor, that doesn't
> > support TCP, could successfully argue that they did that analysis
> > and have the result pass a laugh test?
> 
> What analysis?  Vendors likely considered the resources needed to 
> support the features they offered, and decided against expenditures 
> related to TCP for DNS.  The CPE market decided TCP was not an 
> overriding requirement for DNS, in favor of cost.  This same cost issue 
> with TCP killed RDMA.  Mandating that DNS servers MUST provide TCP when 
> the service can be carried over UDP extended to conservative MTUs of 
> 1280, or IMHO 1476, makes no sense.  This strategy should also help 
> curtail growth of DNS TCP traffic.  After all, TCP is not well suited to 
> efficiently handle DNS, and should be avoided where possible.

You mean the same boxes that implement HTTP servers can't accept a
TCP connection on port 53 and then make a outgoing TCP connection
and then shuffle bits between the two TCP connections?  This is all
that is required of a the TCP component of a DNS proxy.

Again, you want me to believe that they couldn't do something so
simple?  That the cost was too high once they had attracted the DNS
traffic to their box rather than have it go to the upstream boxes
directly?

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org