Date: Mon, 13 Jan 2003 01:19:07 +0100 From: Brad Knowles <brad.knowles@skynet.be> To: Terry Lambert <tlambert2@mindspring.com> Cc: Brad Knowles <brad.knowles@skynet.be>, Doug Barton <DougB@FreeBSD.org>, freebsd-chat@FreeBSD.org Subject: Re: Need advice on PHP and MySQL books Message-ID: <a05200f01ba47b3610139@[10.0.1.2]> In-Reply-To: <3E21FCA1.C4C63219@mindspring.com> References: <20030110234309.R12065@2-234-22-23.pyvrag.nggov.pbz> <3E1FF12B.5390D978@mindspring.com> <20030111144619.X22424@2-234-22-23.pyvrag.nggov.pbz> <3E20D1D6.E9FC60B1@mindspring.com> <a05200f23ba474c2d8565@[12.27.220.113]> <3E21FCA1.C4C63219@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 3:39 PM -0800 2003/01/12, Terry Lambert wrote:
> Without this, you would be required to extendively modify your
> server software; bere little DNS software, no matter who writes
> it, has the ability to shed load very well.
I disagree. The Caching Name Server (CNS) and Authoritative Name
Server (ANS) software from Nominum looks like it will handle load
very, very well. Rick Jones has done some preliminary benchmarks
that show it capable of handling 50,000+ DNS queries per second, and
I believe that it may well be even faster than this. I'll be shortly
doing some testing of my own, which I will be presenting at RIPE 44
in Amsterdam at the end of January.
Neverthless, the lesson we learned really well at AOL is that if
you get enough ankle-biters together, they can still take down the
biggest elephant in the world.
> The (relatively)
> recent attack on the root servers had no effect only because it
> was not sustained until more than 50% of the TTL had passed, at
> which point the overall degradation would have been exponential;
> as it was, less than 1% of the Internet even knew there was an
> attack in progress.
If they had tried to sustain the attack that long, I think the
perpetrators would have been found and caught, and dealt with very,
very harshly. I think they knew this, which is why they stopped so
soon.
> If you added a really long latency, effectively increasing the
> pool retention time for requests, then you decrease the total
> number of requests you can handle in a given period of time
> before the servers become vulnerable by becomining more limiting
> than the pipe size. At that point, you've introduced a serious
> vulnerability to the system, that hasn't been addressed, and can't
> be addressed merely by throwing more resources at it.
I'm sorry, I don't quite understand how you arrive at this
conclusion. Could you elaborate?
> This is really wrong.
>
> The problem with this model is the communications channel between
> the primaries is vulnerable.
There is no security weakness that did not already exist, because
you forward to them the same update packet that you receive yourself.
At least, this is how I think it would be best to handle the
"multiple primaries" problem.
> As I stated on namedroppers years ago, when DJB first argued this
> approach, and that inter-server synchronization was "left as an
> exercise for the student" (his suggestion was rsync or some other
> protocol for synchronization, over SSH, etc.), the problem is that
> DNS data should always flow over the DNS protocol.
I couldn't agree more. However, there are some cases where you
may have to deal with out-of-band data, such as when you're replacing
the back-end database.
> The main secondary reason is, I think, that you don't want to
> open up a communications channel from an insecure server (the DNS
> server is public-facing) to a secure zone server (the database,
> whatever it is, is vulnerable.
>
> Basically, this argues that data should be pushed from the secure
> area to the insecure area, rather than pulled from the insecure
> area from the secure... unless that pull occurs over an already
> established secure tunnel.
Also agreed. See above regarding the forwarding of the same
update packet as was received.
> Thus my recommendation would be to replicate a DNS server contents
> in the customer-facing server in the insecure area from another,
> non-customer-facing, server in the secure area.
Fair enough.
I can't really argue with the rest. ;-)
--
Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a05200f01ba47b3610139>