DNS delegation based on both location and organization

[Brad Knowles]

At 12:34 PM +0200 2005-09-12, martinez_ja5 at tsm.es wrote:

>  That's why I am trying to make DNS as reliable as possible. :)

	But why?  What's your application that requires such reliability 
from an inherently unreliable system?

>  UDP should not pose a problem since plenty of bandwidth is available
>  locally (no need for reliable TCP). Also, load balancing should take care
>  of server availability.

	Actually, switches and load-balancing can make the situation 
worse.  Full duplex switches don't allow the target to intentionally 
create jams to force the sender to back off, and Ethernet technology 
(CSMA/CD) and TCP/IP are both inherently designed with this "back 
pressure" as a critical flow control concept.  Full duplex switches 
remove that capability, and can cause more problems on the local 
high-speed LAN than they resolve.

	Although there is a certain amount of buffering on switches and 
routers, it is possible to generate flows that are high enough that 
the buffering can't keep up, and without "back pressure", there's no 
way to get the sender to slow down.


	A single mis-configured or abusive client could spaz all over the 
servers, and create a denial-of-service for all other clients.

	Moreover, UDP is trivially easy to spoof, and unless you've got 
BCP-38 style source route filtering on each and every segment of your 
network, it's trivially easy for an abusive client to spoof all sorts 
of other internal addresses, including internal addresses of other 
servers, and set them up to spaz all over each other.

	All it takes is one disgruntled employee, or some kid who wants 
to play around and see what happens, or one person who doesn't really 
understand what they're doing, or one person who gets infected with a 
virus/worm/trojan horse on your internal network, and you're toast.

	It's much harder to spoof TCP connections, and if you really want 
to get careful then you can do them over TLS.


	See 
<http://www.ranum.com/security/computer_security/editorials/dumb/>. 
What you're talking about is a form of "turd polishing".  You're 
trying to go for absolute maximum performance and reliability in a 
centralized solution, without any consideration to security, or what 
someone could do to your internal network.

	And you're ignoring the fact that over 90% of all security 
compromises come from the inside -- people who exceed their 
authorized level of access, or who get unauthorized access, but who 
otherwise already work there and are "inside" the system.

>  I know DNS was not intended for critical resolution, but /etc/hosts file
>  really grew too large already and with so many server talking to each other
>  it is becoming quite hard to keep the file updated and small.
>
>  If you know of any other solution, please, let me know because I would love
>  to know about it.

	If you run a local nameserver on each machine, and have them all 
pull secondary from a hidden master, then you never have to worry 
about network latency between your application and the nameserver on 
the same box.  You'll have all the same issues that would otherwise 
have been unavoidable anyway, when it comes to running nameservers at 
all, but there will not be any network latency to worry about.

	Moreover, if the internal nameserver on a given machine is toast, 
then the other applications on that nameserver are probably already 
toast as well, and you would not have saved anything by moving the 
DNS services off the box.

	Since it would be authoritative-only services on the local box, 
those could be done at relatively high rates of speed with moderately 
powerful boxes -- I've seen BIND-9 do 25,000-30,000 DNS queries per 
second on a dual-processor Opteron box, with threading enabled, and 
running the right OS configuration.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.