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. There are 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, ...