لطفا منتظر باشید ...
10.2 How Many Children?
Of course, you won't
simply say, "I want to create four
subdomains." Deciding how many subdomains to
implement is really choosing the organizational affiliations of those
subdomains. For example, if your company has four branch offices, you
might decide to create four subdomains, each of which corresponds to
a branch office.Should you create subdomains for each site, for each division, or
even for each department? You have a lot of latitude in your choice
because of DNS's scalability. You can create a few
large subdomains or many small subdomains. You face trade-offs
whichever you choose,
though.Delegating to a few large subdomains
isn't much work for the parent because
there's not much delegation to keep track of.
However, you wind up with larger subdomains, which require more
memory to load and faster name servers, and administration
isn't as distributed. If you implement site-level
subdomains, for example, you may force autonomous or unrelated groups
at a site to share a single namespace and a single point of
administration.Delegating to many smaller subdomains can be a headache for the
parent's administrator. Keeping delegation data
current involves keeping track of which hosts run name servers and
which zones they're authoritative for. The data
changes each time a subdomain adds a new name server or the address
of a name server for the subdomain changes. If the subdomains are all
administered by different people, that means more administrators to
train, more relationships for the parent's
administrator to maintain, and more overhead for the organization
overall. On the other hand, the subdomains are smaller and easier to
manage, and the administration is more widely distributed, allowing
closer management of zone data.Given the advantages and disadvantages of either alternative, it may
seem difficult to make a choice. Actually, there's
probably a natural division in your organization. Some companies
manage computers and networks at the site level; others have
decentralized, relatively autonomous workgroups that manage
everything themselves. Here are a few basic rules to help you find
the right way to carve up your namespace:Don't shoehorn your organization into a weird or
uncomfortable domain structure. Trying to fit 50 independent,
unrelated U.S. divisions into four regional subdomains may save you
work (as the administrator of the parent zone), but it
won't help your reputation. Decentralized,
autonomous operations demand different
zonesthat's the raison
d'être of the Domain Name
System.The structure of your domain should mirror the structure of your
organization, especially your organization's support
structure. If departments run networks, assign IP addresses, and
manage hosts, they should also manage the subdomains.If you're not sure or can't agree
about how the namespace should be organized, try to come up with
guidelines for when a group within your organization can carve off
its own subdomain (for example, how many hosts are needed to create a
new subdomain and what level of support the group must provide) and
grow the namespace organically, only as needed.
