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

[Mark Andrews <marka@isc.org>]

In message <4AEA2907.5010501@mail-abuse.org>, Douglas Otis writes:
> On 10/29/09 3:41 PM, Mark Andrews wrote:
> > In message<4AE9C4B1.4050306@mail-abuse.org>, Douglas Otis writes:
> >> On 10/28/09 6:32 PM, Mark Andrews wrote:
> >>
> >> A status page often displays information obtained from the
> >> provider. A user might copy information over to their DHCP
> >> settings section, or perhaps explore their provider's support page.
> >> For this effort, they could find themselves without DNS service
> >> whenever these settings change.
> >
> > Which leads us back to the CPE vendor doing a proper job.  Either
> > correctly copying data from upstream or fully implementing DNS.
> > Customers shouldn't have to manually configure this information.
> 
> Customers should still change default passwords, but few do.

Again you make a irrelevent comment.  If the vendor wanted to they
could set a default password which is different for every box.  This
is not hard and some vendors do exactly that.

> There are
> also features based upon DNS interception, such as parental controls
> et al.  UDP makes these implementations easier.

Doing this with TCP is not significantly harder than with UDP.

> >> Sure, it could be done.  Unlike UDP, TCP requires more receive,
> >> transmit, and state buffers related to negotiations between two
> >> end points. Received buffers deal with message framing when
> >> products offer DNS related features, and transmit buffers for
> >> packet recovery. Moore's law helps, but dealing with more traffic
> >> offsets density improvements, where power and cooling also impose
> >> limits.
> >
> > LOL.  You think the HTTP server doesn't require these resources.
> 
> The web access feature is however limited to a single session.  This
> would not be the case for DNS over TCP, especially when manipulation
> might be involved.  However, even the simple single session web access
> feature commonly contains security flaws.

But multiple TCP connections.
 
> > One could even just translate both source and destination addresses
> > and NAT the TCP/DNS connection.  This does have the obvious problem
> > in that it reduces the redunancy but if you track which nameservers
> > are responding over UDP it should be reasonably robust.  You could
> > even send the SYN to all the DNS servers and just let the first to
> > respond with a SYS/ACK continue.  This gives you back the reduancy.
> >
> > It is not hard to provide DNS/TCP.  The CPE vendors that don't are
> > just plain lazy.
> 
> This still depends upon available resources.  Rather than lazy, perhaps
> it could be described as vendors avoiding support for more than what is
> absolutely necessary.  An opportunity for non-lazy programmers to offer
> alternative reference implementations for common CPE chip-sets?

They exist.

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