- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Much has changed in the New DNS implementation for Windows 2000.
By now, you've all heard of Win2k's reliance on DNS. Many of you have studied DNS to a point that you would consider yourselves 'experts' at DNS. Those of you that do, keep reading, I might just teach you a thing or two in this short article. Likewise, if you're a DNS newbie, this article should be rather informative.
By now, you've all heard of Win2k's reliance on DNS. Many of you have studied DNS to a point that you would consider yourselves "experts" at DNS. Those of you that do, keep reading, I might just teach you a thing or two in this short article. Likewise, if you're a DNS newbie, this article should be rather informative.
We can start out by talking about what DNS is, and how it's different from our old friend WINS. DNS is a distributed, hierarchical system for resolving names to IP addresses. DNS dates back to the good ol' ARPANET, which was the internet way back in the days of its creation. You see, they had to find a way to remember the addresses of all these different computers connected to the ARPANET. So, they devised this method of naming all of the servers on the ARPANET, and creating a small table on each computer that defined the name of each machine, and it's IP address. This was the hosts file. Well, as you can imagine, maintaining these tables became a full time job, with new computers being added all of the time. So, some people got together, and devised a way to maintain a hierarchical database of each computer on the ARPANET, with each administrator being responsible for maintaining the tables for the computers he managed. We call this system DNS. If you want more history on the internet, you can click this link: http://www.isoc.org/internet/history/.
When you type "ping www.swynk.com" at the command prompt, you get a message that says "Pinging www.swynk.com [184.108.40.206] with 32 bytes of data:" Then your response would be something like "Reply from 220.127.116.11: bytes=32 time<10ms TTL=128" Which would indicate that you have resolved www.swynk.com to 18.104.22.168, using DNS. There is a process that is followed, and generally acts like follows
1. Someone types the command "ping www.swynk.com" from the command line
2. Client sends request to its primary DNS server
3. Primary DNS server checks its cache, if found, it replies to the client with the IP
4. If not found, it forwards a recursive query to the . domain, the query is looking for a root nameserver for the .com domain
5. The root nameserver, for the . domain, replies to the DNS server with the address of a nameserver for the .com domain
6. The DNS server queries the nameserver for the .com domain, looking for the address of a DNS server for swynk.com
7. The DNS server for the .com domain sends the address for the primary nameserver for swynk.com to the client's DNS server
8. The client's DNS server queries the primary nameserver for swynk.com looking for a host record of "www"
9. The primary nameserver for swynk.com replies to the client's DNS server with the IP address associated with the "www" record
DNS differs from WINS in that the process you see above is hierarchical. WINS (which Windows computers have been using forever) is a flat namespace, that has absolutely no heirarchy at all. When WINS makes a query, the client queries the local WINS server, which doesn't have the ability to perform any more queries on the client's behalf. If your local WINS server doesn't have the name of another computer in it's local database, your out of luck. WINS does have the ability to replicate it's database with another WINS server, but that is almost a flat merge of the 2 databases. Some of the most common problems with WINS today include extremely poor provisions for replication, database problems in relation to the Jet database that the WINS engine uses, and the fact that the flat namespace does not allow you to reuse any common name for a server across the enterprise. You cannot have a server called www in Chicago, and one called www in Portland with WINS. This would cause a name conflict, you could however have this naming scheme with DNS, the names might look like www.chicago.company.com, and www.portland.company.com. You would have 2 machines named www, but since they reside in different DNS zones, (chicago.company.com, and portland.company.com) you don't have a naming conflict, because their absolute names aren't the same. the inability to scale to large enterprises is partly contributed to the inability to split the database into multiple partitions, which DNS also allows you to do. All these features give you more flexibility with DNS. WINS is a system which contains a NETBIOS name, plus a 2 character code, which delineates what kind of record each entry is. For example, a domain controller in WINS is differentiated by a 1C entry. You might have a domain controller named DC1, this would look like <1C>-DC1 in WINS. Microsoft added support for SRV resource records with the DNS server in Windows 2000, so now the ability to find a host that offers a particular service isn't exclusive to WINS networks only. For those of you that don't know what a SRV resource record is, it's a service type record, an example is an MX record. MX stands for "Mail Exchanger", when you need to send email to firstname.lastname@example.org, your SMTP server performs a DNS query against the primary nameserver for that domain, looking for an MX, SRV resource record, and to the host that it points at. The SMTP server then knows which computer to connect to, on port 25, and start the mail transfer process. This is probably one of the simplist examples of SRV resource records. These are some of the reasons that WINS is out, and DNS is in. As I'll show you below, Microsoft also added an abundant array of features to the DNS server in Windows 2000, which allow it to support Windows clients with robustness, efficiency, and stability.
Dynamic Updates- The old school method of updating DNS is the same way we all pump gas into our SUV's in the morning. By Hand. We all know it would be a nightmare to maintain the DNS records that need to exist for Windows 2000 and Active Directory to function properly. This would mean maintaining records for all hosts on your network, and extra records for Domain Controllers, Global Catalog Servers, DNS servers, and the like. It would be even harder to maintain when some of us use that "new fangled DHCP protocol." Dynamic Update protocol can make all of this work together like a dream. Instead of the administrator manually adding entries for all hosts on the network, or changing it when the client/server receives a new IP address from the server, Dynamic Update protocol does all of this for you. Dynamic Update protocol allows a Windows 2000 client to send a message to a DNS server that supports it, telling the server it's hostname, the services it offers, and it's IP address. If you still have Windows NT 4, and Windows 9x clients on your network, then you can even enable an option within the Microsoft DHCP server that will update DNS for you, so you can take advantage of DNS with NT4 and 9x clients. There's even a function of Dynamic Update protocol that allows for secure updates between the client and the server using a symmetric key exchange between the client and DNS server. For more information regarding the secure update, see RFC 2078
Incremental Zone Transfer Support (IFXR)- RFC's 1995, and 1996 contain exhaustive details about what makes the incremental zone transfer work. The basic idea is that instead of transferring the entire zone database every time that we have a zone transfer to secondary servers, we only transfer the changes that have been made to that zone. This is supported in primary, secondary, and active directory integrated zones. This is superceded by replication of AD when a zone is AD integrated, as there are only delta updates as part of the AD replication.
Unicode Character Support.- As according to the original specs for the protocol, DNS only supported a standard character set of 0-9, a-z, and -. NETBIOS names for Windows based computers support a much larger characters set. RFC 2181 added Unicode character support to DNS. This means that if you are using non standard characters in your computername field in NT4 or Win 9x, you don't have to rename your computers or domain controllers as you migrate to Windows 2000. You can enable the support for Unicode characters on the DNS server, and viola` you have UTF-8 support in your DNS server.
Active Directory Integrated Zones.- Active Directory Integrated zones give you to the ability to eliminate the single master model for DNS replication. Active Directory allows you to integrate a DNS zone into your AD database, and replicate it with the AD, giving you the ability to perform replication automatically with all AD servers. This also eliminates the problem of having a single master DNS server, which would be the only server where changes to the DNS zone could be made. AD integration allows you to make changes to the DNS zone on any AD Domain Controller, with changes replicating with the AD during the AD replication process. This feature kills 2 birds with one stone, you can elimate having to design a separate DNS infrastructure to support the AD, and you can eliminate the problems of having 1 single master DNS server, where all changes have to be made.
As you can see, Microsoft put much work into making the DNS server included with Windows 2000 full-featured, and robust. With the addition of support for open standards based technology, and the ability to integrate with the Active Directory, I think we have a DNS server that's ready for Primetime.