DNS delegation based on both location and organization
Brad Knowles
brad at stop.mail-abuse.org
Mon Sep 12 11:30:09 UTC 2005
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.
More information about the bind-users
mailing list