[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/28/09 6:32 PM, Mark Andrews wrote:
In message<4AE8E8E5.4030403@gmail.com>, Doug Otis writes:
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.
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.
Perhaps the _most_ important setting a customer should make would be to
change the _default_ password and ensure external access is disabled. A
large number of CPE devices have been 0wned as a result of password
guessing and various firmware faults.
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?
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.
Providers offering DNS also benefit from the reliance upon UDP. UDP
requires fewer servers and is less prone to being DDoSed.
-Doug