[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.  There are
also features based upon DNS interception, such as parental controls
et al.  UDP makes these implementations easier.


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.


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?

-Doug