- Shopping Bag ( 0 items )
DNS on Windows NT is a special edition of the classic DNS and BIND, which Microsoft recommends for Windows NT users and administrators. It discusses one of the Internet's fundamental building blocks: the distributed host information database that's responsible for translating names into addresses, routing mail to its proper destination, and many other services. As the authors write in the preface, if you're using the Internet, you're already using DNS — even if you don't know ...
DNS on Windows NT is a special edition of the classic DNS and BIND, which Microsoft recommends for Windows NT users and administrators. It discusses one of the Internet's fundamental building blocks: the distributed host information database that's responsible for translating names into addresses, routing mail to its proper destination, and many other services. As the authors write in the preface, if you're using the Internet, you're already using DNS — even if you don't know it.
This book covers the DNS server in Windows NT 4.0, as updated with Service Pack 3. In addition to covering general issues, like installing, setting up, and maintaining the server, it covers many issues specific to the Windows environment: integration between DNS and WINS, converting from BIND to the Microsoft DNS server, and registry settings. It pays special attention to security issues, system tuning, caching, and zone change notification. It also pays detailed attention to issues like troubleshooting and planning for growth.
Whether you're an administrator involved with DNS on a daily basis, or a user who wants to be more informed about the Internet and how it works, you'll find that this book is essential reading.
This Windows NT version of the author's classic publication DNS and BIND, Second Edition. Designed for system administrators and network managers, this publication focuses on the Windows NT DNS Server release Service Pack 3. Please be familiar with system administration and the Domain Name System, as DNS theory is only covered in two chapters.
Once you've decided to have children, the next question to ask yourself is, naturally, how many children to have.
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 zone, because there's not much delegation to keep track of. However, you wind up with larger subdomains, which require more memory 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 name space and a single point of administration.
Delegating to many smaller subdomains can be a headache for the administrator of the parent. Keeping delegation data current involves keeping track of which hosts run name servers and which zones they're authoritative for. The data change each time a subdomain adds a new name server, or when 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 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 subdomain 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 name space:
This can lead to problems, though. It's nice to use a relatively consistent naming scheme across your subdomains. It makes it easier for users in one subdomain, or outside your domain entirely, to guess or remember your subdomain names and to figure out in which domain a particular host or user lives.
Leaving the decision to the locals can result in naming chaos. Some will want to use geographical names, and others will insist on organizational names. Some will want to abbreviate; others will want to use full names.
Therefore, it's often best to establish a naming convention before choosing subdomain names. Here are some suggestions from our experience:
|2||How Does DNS Work?||11|
|3||Where Do I Start?||37|
|4||Setting Up the Microsoft DNS Server||58|
|5||DNS and Electronic Mail||97|
|7||Maintaining the Microsoft DNS Server||120|
|8||Growing Your Domain||135|
|10||Advanced Features and Security||183|
|A||DNS Message Format and Resource Records||277|
|B||Installing the DNS Server from CD-ROM||296|
|C||Converting from BIND to the Microsoft DNS Server||297|
|E||Domain Registration Form||305|
|F||In-addr.arpa Registration Form||310|
|G||Microsoft DNS Server Registry Settings||316|