DNS delegation based on both location and organization
martinez_ja5 at tsm.es
martinez_ja5 at tsm.es
Thu Sep 8 13:15:07 UTC 2005
Thanks a lot.
I understand it better now (at least my headache dissappeared) :)
I'll go with the centralized stealth primary and two secondary servers =
per
city load balanced (actually I think load balancing should be used beca=
use
it avoids timeout retries when first dns on list is down).
Centralized should not lower my avavailability since it is just a
management server and the database is stored inside a huge highy redund=
ant
oracle db. Just take care that secondaries do not get flushed too soon =
and
problem solved. :)
I do not have to annouce which are my NS for my zones so I'll just put =
two
per city (those local for the domain). That is, madrid 1 & 1 as
authoritative for madrid.*.corp.com.
Again, thank you very much.
Jose Angel
=
=20
=
=20
Brad Knowles Para: ma=
rtinez_ja5 at tsm.es =20
<brad at stop.mail-abuse cc: bi=
nd-users at isc.org =20
.org> Asunto: Re=
: DNS delegation based on both location and organization =20
=
=20
=
=20
=
=20
=
=20
08/09/2005 13:22 =
=20
=
=20
=
=20
=
=20
Telef=F3nica M=F3viles Espa=F1a, S.A. =
=20
=
=20
At 12:08 PM +0200 2005-09-08, martinez_ja5 at tsm.es wrote:
> I am not sure if I understood the diferences on server types, but I
think
> I want all DNS servers to have full DNS records for the quickest
response
> (plenty of RAM available).
A full-mesh network is one way to make sure that you have
maximum
availability and speed of resolution, but it is not necessarily
always the best solution.
> From that I understand DNS servers at Ma=
drid
> office should be both primary servers of all Madrid local zones
> (madrid.finance.corp.com, madrid.sales.corp.com, ...) and all other
> servers (those in Barcelona, Valencia, etc) should be secondary
> (non-authoritative) for Madrid zones.
Secondary !=3D non-authoritative.
If a server is secondary for a zone, then it is fully
authoritative for that zone.
> Of course, the same architect=
ure
> would be applied for all other cities, two local primary servers and=
> 4x2 secondary remote secondary servers.
Generally speaking, you usually want only one primary serv=
er
for
a zone, and a set of secondaries. All changes to the zone are made
only on the primary, and then when you reload the zone on the
primary, that information will automatically be distributed to the
secondaries.
If you need two nameservers for each city, make one of the=
m
primary and the other secondary. Keep in mind that you can have as
many secondaries as you want for a zone, but you don't necessarily
have to list them all as official authoritative servers within the
zone content itself. The extras would be "stealth" secondaries --
they get a copy of the data, they answer authoritatively for anyone
who asks them, but since they're not advertised they should get
relatively few queries for that zone.
> To centralize management also I thought I would add another server
> primary for all zones, hidden and behind a firewall to be a master
> of everything, safe repository of data and source of all changes to
> sync into all other servers. (This would be VitalQIP+oracle manageme=
nt).
This isn't the way primaries work. Primaries don't share =
out
data to other primaries, they instead share out data to secondaries.
You could do your own out-of-band communication method to share data
between primaries, but that would be outside the scope of DNS and
BIND.
You can have a stealth primary and have all other servers =
be
secondary to that primary, and all advertised servers within the zone
are actually secondaries and not primary. Since either primary or
secondary would answer authoritatively, the clients don't care.
If you want to make all your changes in a centralized
location,
that's fine. But you're getting confused on the terminology between
primary and secondary.
> It looks like a little overkill but:
> - I do not want to use cache servers because cache misses get too
> long to get resolved.
I don't think that this would really be too much of an iss=
ue,
but
I'm willing to take this as a given.
> - I need centralized Oracle based management.
No problem. The primary can be whatever you want, and use=
whatever back-end technology you want. The secondaries don't care,
since they'll get their data via zone transfers and then store that
content locally in the format of their choice. You just have to make
sure that the primaries support zone transfers, and you're fine.
> - I need local resolution and redundancy (I even need load balancers=
> for the quickest response time and highest availability)
Load-balancing switches are definitely a good idea for HA,=
but
they generally don't contribute much of anything on the performance
side of the equation unless you're doing tens to hundreds of
thousands of DNS queries per second. I built what was the world's
largest caching nameserver farm at AOL, and that whole cluster of
machines was capable of handling at least 32,000 DNS queries per
second (our testing tools weren't able to push the system hard enough
to find out what the real top-end was), but now you can get
reasonably low-cost individual boxes that can provide performance
approaching or even exceeding those levels.
> - Second and third domain levels would be hardly adjustable to my ne=
eds
> for simpler DNS
>
> Does this architecture look fine or is just a nerd mess? Aren't ther=
e
too
> many primary servers? Would make any difference if I set them all to=
> secondary but the centralized one?
Having all of them be secondaries to the single central
primary
would definitely be the way to make the system easier to manage, but
you will have to keep in mind that you will have to push out
/etc/named.conf changes to each of those machines if you add or
delete any zones that they should be secondaries for. Zone content
changes will be no problem -- that will be handled automatically.
Of course, this does give you a Single Point of Failure
(SPOF),
which will hurt your overall system availability percentage, due to
the single central management system. However, since this is a
stealth primary, and it wouldn't be advertised anywhere within any of
the zones it serves, this would only prevent updates to the zone
contents -- the existing zone contents would continue to be served by
the secondaries.
The bigger issue for you is going to be determining which
machines at each site need to be advertised as authoritative for the
zones, and which ones can be stealth secondaries. That choice is
entirely up to you.
But keep in mind that you don't want to list too many
authoritative servers (typically no more than four or five), because
you don't want to cause the responses you hand out to exceed the
512-byte limitation of typical DNS responses via the UDP protocol.
Trust me, you do *not* want to know what kind of weirdness tends to
manifest itself when you start causing truncation, which results in
DNS queries having to be re-tried with TCP, etc....
--
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