deploying DNS in large ISP
Brad Knowles
brad.knowles at skynet.be
Wed Jul 4 23:28:25 UTC 2001
At 3:35 PM -0700 7/4/01, Duane Powers wrote:
> Just as a follow-up, currently we are deploying resolvers into each of
> our pops, and using our radius system to assign the ip's to our
> customers.
Right, pretty typical.
> I don't nescessarily disagree with this approach, I just
> wonder if it's a better idea to build a much larger, more fault-tolerant
> load-balancing system, or actually, three, in geographically diverse
> areas, so that should one box be impacted (crash <g>) the services
> continue unimpaired - or at least minimally impaired, rather than having
> one pop substantially impacted.
What is it that you're trying to design for high availability?
Is it the recursive/caching-only nameservers at each POP? If so,
then put two or three at each POP, and have an L4 load-balancing
switch sitting in front of them.
It would be more difficult to build into the RADIUS server the
ability to monitor which nameserver(s) are currently running and
handling queries, and to then tailor the address(es) they hand out to
their clients. And even then, this wouldn't do anything for people
who had already been assigned IP addresses for their nameservers.
Of course, properly configured nameservers very rarely die (at
Skynet, we had much more problems with the RADIUS servers than we did
with the nameservers), so this shouldn't really be that big of an
issue.
But, if you are concerned about this, the critical thing to do is
to make sure that the IP address for your nameserver simply never
goes down, even if one or more of the nameservers behind that IP
address do go down -- if you ever fail over to the second nameserver
on the list, you're dead meat.
And you do this by using L4 load-balancing switches.
> This is, of course, dependent on the
> resilience of the network over which the traffic will travel. I don't
> know that I like the idea of 20-30 ip's for resolvers for an area the
> size of California. just doesn't seem clean to me. What do you guys think?
It depends on how many POPs you have, and if you want to make
each of your POPs self-sustaining and internally resilient to faults,
or if you want to try to use geographical diversity to your advantage
and keep the additional hardware to a minimum.
This would mean you might have just one nameserver at each POP
with an L4 load-balancing switch sitting in front of it and
redirecting queries to both the local nameserver and the other remote
nameservers across your WAN. To do this properly (so that traffic
stays as local as possible), you'd need load-balancing switches that
are intelligent with respect to network topology.
This kind of intelligence is much harder to get right, although
some vendors claim to be able to do it (although they seem to focus
on a much broader across-the-entire-world/Internet perspective, such
as the Cisco GlobalDirector).
Myself, I'd plan on putting up a larger number of smaller
nameservers (two or three per POP), with an L4 load-balancing switch
sitting in front of them. This would allow you to do upgrades and to
scale your client nameservice at each POP as your requirements
dictate, without ever taking that IP address out of service.
Of course, this would just be for your dial-in clients. The
servers should be using nameservers running locally on the same
machine, so that their requirements for nameservice are not lumped in
with the client requirements, and you don't have them fighting for
resources, etc.... This also helps scale your nameservice
requirements better, because as you add more machines (and more
powerful machines) to perform various tasks, they automatically bring
more power to serve their own nameservice requirements.
You then only need to worry about growth in client nameservice
requirements for the recursive/caching-only nameserver machines at
each POP.
--
Brad Knowles, <brad.knowles at skynet.be>
/* efdtt.c Author: Charles M. Hannum <root at ihack.net> */
/* Represented as 1045 digit prime number by Phil Carmody */
/* Prime as DNS cname chain by Roy Arends and Walter Belgers */
/* */
/* Usage is: cat title-key scrambled.vob | efdtt >clear.vob */
/* where title-key = "153 2 8 105 225" or other similar 5-byte key */
dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'
More information about the bind-users
mailing list