Home
/ How to Change Dns Servers Using a Group Policy
How to Change Dns Servers Using a Group Policy
Forward Lookup Zone
MCSA/MCSE 70-291: The Windows Server 2003 DNS Server
Deborah Littlejohn Shinder , ... Laura Hunter , in MCSA/MCSE (Exam 70-291) Study Guide, 2003
Installing and Configuring the Windows Server 2003 DNS Server
☑
Forward lookup zones resolve names to IP addresses and Reverse lookup zones resolve IP addresses to names.
☑
Forwarders can be used on your DNS server to forward requests for which your DNS server does not have an authoritative answer. You can also set up your forwarders to conditionally forward requests to different forwarders based on domain names.
☑
Scavenging of stale records must be set up on both the server and the zone to work correctly.
☑
By default, zone transfers are not allowed. Microsoft recommends allowing zone transfers only to specific server IP addresses; best practice is to use Active Directory Integrated zones, which use Active Directory replication to copy zone data.
Derrick Rountree , in Windows 2012 Server Network Security, 2013
Creating Zones
There are two main categories of lookup zones: forward lookup zones and reverse lookup zones. Forward lookup zones are used to map a host name to an IP address. Reverse lookup zones are used to map IP addresses to host names.
Creating Forward Lookup Zones
Forward lookup zones hold name registrations for servers and services. They are the basis of what DNS servers do.
To create a forward lookup zone, perform the following steps:
1.
Right-click on the Forward Lookup Zones folder, select New Zone. This will bring up the New Zone Wizard, as seen in Figure 2.20.
Figure 2.20. New DNS Zone Welcome Screen
2.
On the Welcome screen, click Next.
3.
On the Zone Type screen, as seen in Figure 2.21, you choose what type of zone you are creating. You can choose Primary Zone, Secondary Zone, or Stub Zone. You also have the options to store the zone in Active Directory. Select Primary Zone, and click Next.
Figure 2.21. New DNS Zone Type Screen
4.
Next is the Zone Name screen, as seen in Figure 2.22. Here you must input the domain name for the DNS zone. Enter the name, and click Next.
Figure 2.22. New DNS Zone Name Screen
5.
Next you will see the Zone File screen, as seen in Figure 2.23. Here you can specify to create a new DNS zone file or use an existing one. Since we are creating a new zone, we will choose to create a new zone file and click Next.
Figure 2.23. New DNS Zone File Screen
6.
Next is the Dynamic Update screen, as seen in Figure 2.24. You must choose whether you want to allow dynamic updates. If you do allow dynamic updates, you must choose whether to allow unsecured dynamic updates or just secure dynamic updates. We plan to configure Active Directory later, so we are going to select Allow both nonsecure and secure dynamic updates. Click Next.
Figure 2.24. New DNS Zone Dynamic Update Screen
7.
Finally, you have the final screen, as seen in Figure 2.25. Click Finish.
Tony Piltzecker , Brien Posey , in The Best Damn Windows Server 2008 Book Period (Second Edition), 2008
Creating a Standard Primary Forward Lookup Zone
Follow these steps to create a primary, forward lookup zone:
1
Open DNS Manager by clicking Start | Administrative Tools | DNS
2
In the left pane, expand the node representing the server you want to configure, right-click Forward Lookup Zones, and click New Zone…
3
Read the welcome page of the New Zone Wizard dialog box and click Next
4
On the Zone Type wizard page, leave the default selection of Primary zone and click Next. See Figure 5.11.
Figure 5.11. The Zone Type Wizard Page
5
On the Zone Name wizard page, enter the name of your domain in the Zone name: text box and click Next. See Figure 5.12.
Figure 5.12. The Zone Name Wizard Page
6
On the Zone File wizard page, you can select one of the following options (see Figure 5.13):
▪
Create a new file with this file name. This option, which is filled in with a recommended setting by default, is used when you need to create a zone file.
▪
Use this existing file. If you have a preexisting zone file that is configured and ready to use, select this option. The file must be located in the %systemroot%\System32\dns directory.
Figure 5.13. The Zone File Wizard Page
7
Click Next
8
On the Dynamic Update wizard page, you can select from the following options (see Figure 5.14):
▪
Allow both secure and non-secure dynamic updates. The DNS Server role in Windows Server 2008 supports dynamic DNS (DDNS). If this option is selected, computers can communicate with the DNS server to create and manage their own records. If the zone is AD integrated, a third option with enhanced security is available. A standard primary zone has reduced security when using DDNS that make it easy for attackers to specify faulty DNS record information when this option is enabled. Microsoft does not recommend enabling this option.
▪
Do not allow dynamic updates. This option prevents the use of dynamic DDNS. Records for this primary zone will need to be managed manually if it is selected. This is the default option.
Figure 5.14. The Dynamic Update Wizard Page
9
Click Next
10
On the Completing the New Zone Wizard page, review the information provided and click Finish
11
In the left pane under Forward Lookup Zones a new node representing the zone you created should appear. Click that zone.
12
In the right pane, you should see that at least two records have been created automatically (SOA and NS). See Figure 5.15.
Figure 5.15. DNS Manager Utility with the Created Forward Primary Zone
MCSE 70-293: Planning, Implementing, and Maintaining a Name Resolution Strategy
Martin Grasdal , ... Dr. Thomas W. Shinder , in MCSE (Exam 70-293) Study Guide, 2003
DnsUpdateProxy Group
Any objects that are created by members of the DnsUpdateProxy group have no security and are ownerless. Consequently, the first authenticated computer that updates the record is able to take ownership of the object. Therefore, if you enable secure dynamic updates only, you should place all DHCP servers in this group before they start registering names.
The DnsUpdateProxy group can create a security risk, however, if the DHCP server is installed on a domain controller. If the DHCP server that is a member of the DnsUpdateProxy group is installed on a domain controller, all the SRV, the A records for domain controller on which DHCP is installed and other critical records created by the domain controller for AD functionality will be ownerless, allowing the first authenticated user who tries to update them to become the owner. For this reason, you should not install a DHCP server on a domain controller if you are using the DnsUpdateProxy group.
If, for whatever reason you do need to install DHCP on a domain controller, or if DHCP is updating A records for clients in forward lookup zones, you should configure your DHCP server(s) to use DNS dynamic update credentials. To do this, you configure a security principal (a user account in this case) for use by all your DHCP servers when they update a DNS zone. You then configure your DHCP servers to use this account for dynamic updates. (This is a new feature of Windows Server 2003 and is not available on Windows 2000.) This obviates the problems arising from ownerless records created by DHCP servers in the DnsUpdateProxy group. In particular, enabling this configuration prevents a DHCP server from using the elevated permissions it inherits by virtue of its being installed on a domain controller. Figure 6.13 shows the Advanced tab on the D HCP server property page where you configure credentials for dynamic updates.
Figure 6.13. Configuring Credentials for DHCP Updates to Dynamic Zones
Head of the Class…
Generic Security Service TSIG (GSS-TSIG) and Dynamic Updates
Microsoft uses a dialect of transaction signatures (TSIG) as the underlying mechanism for secure dynamic updates, as specified in RFC 2485. This dialect, Generic Security Service TSIG (GSS-TSIG), is not spoken by other implementations of DNS. A version of BIND 9.x is supposed to provide this support in the future, but as of this writing, BIND 9.2 (the most current version) does not provide this support. This lack of interoperability can cause issues if you are trying to integrate BIND into your Windows environment. For example if you want a BIND server to handle all your dynamic updates, which makes the zone become a much more complex administrative challenge, as well as if you want a BIND DNS client to be able to update records using secure dynamic update.
In BIND 9, TSIG is used primarily for secure server-to-server communications (for example, zone transfer, notify, and recursive query messages). However, TSIG can be used in a BIND environment for secure dynamic updates.
MCSA/MCSE 70–294: Working with Forests and Domains
Michael Cross , ... Thomas W. Shinder Dr. , in MCSE (Exam 70-294) Study Guide, 2004
Preparing DNS
Any time a client requires access to Active Directory, it activates an internal mechanism called the DC locator for locating DCs through DNS. It uses SRV records for this. If no SRV records are found in DNS, the access fails. To prevent this failure, before renaming an Active Directory domain you need to be sure that the appropriate zones exist for the forest and for each domain.
After you create the DNS zones for the new domain name, your DCs will populate each zone through dynamic update. This is one of the reasons for the reboot after the execution of the renaming script. Configure the zones to allow secure dynamic updates as a good security practice. Repeat the zone creation for each domain you plan to rename.
Everything needed to support your existing Active Directory domain must be recreated to support the domain after renaming. Usually, this is accomplished by mirroring your current DNS infrastructure. As an example, say you want to rename an existing domain called Labs.dog.com to Retrievers.dog.com. If the zone containing your current SRV resource records is called Labs.dog.com, you will need to create a new DNS zone called Retrievers, dog. com.
To analyze and prepare DNS zones for domain rename, first compile a list of DNS zones that you need to create. Second, create the forward lookup zones using the DNS tool and configure them to allow dynamic updates. The section Configuring DNS Servers for Use with Active Directory gives more detailed information.
Head of the Class…
What Happens to My Distributed File System When I Rename My Domain?
First, those of you who are not using DFS should think seriously about it. DFS allows you to redirect specific folders like My Documents out to a high-availability network location where each user's files can be backed up and protected. Folder redirection is a Group Policy extension that allows you to identify a connection between network servers or DFS roots and the local folders that you want to redirect.
What happens to DFS when you rename a domain ail depends on how you have it configured. Think about it, If you use a domain-based DFS path like \\domainName\DFSRoot, then when the domainName goes away, what happens to the path?
It goes dead, and everyone's documents disappear, or become inaccessible. As far as the users know, all of their data is gone. Your telephone will ring by 5 a.m. the next day—guaranteed. What does it depend on, and how can you keep your telephone from ringing? If your Folder Redirection policy specifies the NetBIOS name of the domain in your domain-based DFS path, and you keep the NetBIOS name of your domain the same instead of changing it along with the DNS name, then you're okay.
What if you want to change your NetBIOS name along with your DNS name? You could push out a new group policy and move the files to another location. Temporarily, you could point your folder redirection to a stand-alone DFS path, or even to a simple server-based share. You should do that a couple of days before the rename just to be sure it works before shaking things up again—you'll be too busy renaming to worry about DFS at that point. Since \\hostName\DFSRoot stays rock solid through a domain rename, your documents should still be available the next morning. When things settle down, restore the user files back to your domain- based DFS root and push out the old DFS policy again. That isn't without risk, but it keeps things working.
What about home directories and roaming profiles? Same thing. Look at the pathname you specify in your policy to determine whether they'll break when you rename the domain. Make sure to fix those beforehand.
In The Best Damn Exchange, SQL and IIS Book Period, 2007
Enabling Name Resolution Lookups between the Edge Transport and Hub Transport Servers Suffix
It's important that the edge transport server and any hub transport servers in your Exchange 2007 organization are able to see each other using name resolution. To accomplish this goal, you can create the necessary host record in a forward lookup zone on the internal DNS server used by the edge transport and hub transport servers.
Note
Since any Exchange 2007 hub transport server in your Exchange organization needs to be added to the Active Directory, before you can install this role only the host name of the edge transport server needs to be manually added to the respective forward lookup zone.
You do so by performing the following steps:
1.
Log onto the internal DNS server used by the edge transport and hub transport servers.
2.
Click Start | Administrative Tools and then click DNS.
3.
In the DNS Management snap-in, expand the Server node and then Forward Lookup Zones (see Figure 7.4).
Figure 7.4. DNS Management MMC Snap-in
4.
Now right-click the respective Forward Lookup Zone and select New Host (A) in the context menu.
5.
Enter the hostname and IP address of the edge transport server and click Add Host (see Figure 7.5).
Figure 7.5. Creating a New Host (A) Record
6.
Close the DNS Management snap-in and log off the internal DNS server.
You may also choose to simply add the hostname and IP address of the edge transport server to the local hosts file on each hub transport server, and the hostname and IP address of any hub transport server to the local hosts file on the edge transport server in your Exchange organization. Although this is a perfectly supported solution, we don't recommend you use it unless you're dealing with a small shop that has maybe one edge transport server and one or perhaps two hub transport servers. If you're a messaging administrator/consultant in a large Exchange organization that contains multiple edge transport servers as well as several hub transport servers, it's far better to keep the name resolution centralized on an internal DNS server.
You add the hostname and IP address to the local hosts file on the server by performing the following steps:
1.
Log onto the edge transport or hub transport server.
2.
Click Start | Run and type C:\windows\system32\drivers\etc and press Enter.
3.
Now open the hosts file in Notepad.
4.
Type the IP address and hostname of the server (see Figure 7.6).
Figure 7.6. Entering the IP Address in the Hosts File
5.
Save the changes and close Notepad.
6.
Now open a Command Prompt Window by clicking Start | Run and then typing CMD.EXE.
7.
You now need to purge and reload the remote cache name table, which is done by typing NBTSTAT –R followed by pressing Enter (see Figure 7.7).
Figure 7.7. Purging and Preloading NBT Remote Cache Name Table
8.
Verify that you can ping the respective servers using the fully qualified domain name, and make sure it's the correct IP address that's resolved (see Figure 7.8).
Figure 7.8. Pinging the Edge Transport Server
Note
You need to perform Steps 1 through 8 on each edge transport and hub transport server in your Exchange organization.
Configuring DNS Settings
If you choose to run the edge transport server in a multihomed setup where you have a network adapter connected to the internal network and one to the external network (perimeter network), you need to pay special attention in configuring DNS. Since the external network adapter doesn't have access to the DNS server in your Active Directory on the internal network, you should configure this network adapter to use a public DNS server (or a DNS server located in your perimeter network), so that the edge transport server can perform name resolutions, required to resolve SMTP domain names to MX or Mail Exchange records as well as route mail to the respective SMTP servers on the Internet.
The internal network adapter should be configured to use a DNS server located in the perimeter network or, alternatively, to use a hosts file. As you saw in the section of this chapter titled "Enabling Name Resolution Lookups between the Edge Transport and Hub Transport Servers," the edge transport and hub transport servers must be able to locate each other using name resolution.
As was also the case with Exchange Server 2000 and 2003, you can configure the edge transport server to use a DNS server (typically an external DNS server) for routing mail other than the DNS server specified on the external network adapter. In Exchange 2000 and 2003, this was done by taking the Properties of the default SMTP virtual server in the System Manager and then clicking the Delivery tab and finally the Advanced button. On an edge transport server, you configure the DNS servers by taking Properties for the Edge Transport server object in the Result pane. On the Properties page, click the External DNS Lookups tab and specify the DNS server that should be used for routing mail to other SMTP servers on the Internet (see Figure 7.9).
Dustin Hannifin , ... Joey Alpern , in Microsoft Windows Server 2008 R2, 2010
DNS zones
DNS Servers host zones which in turn host records that resolve a name to an IP address. The zone is the authoritative source for information about the domain name managed by that zone. A DNS zone is typically the same as the domain name being hosted on the DNS Server. For example, if the DNS Server will be hosting the domain syngress.com, then the zone syngress.com must be created on the DNS Server. There are two Primary zone types that can be set up on a DNS Server—Forward Lookup Zones and Reverse Lookup Zones.
▪
Forward Lookup Zones—Forward Lookup Zones allow the DNS Server to resolve queries where the client sends a name to the DNS Server to request the IP address of the requested host.
▪
Reverse Lookup Zones—Reverse DNS zones perform the opposite task as Forward Lookup Zones. They return the fully qualified domain name (FQDN) of a given IP address. For example, a client could send the IP address of 69.163.177.2 to a DNS Server. If the server hosted a reverse zone that included that IP address, it would return the FQDN for that address, such as www.syngress.com.
In addition to the standard zone types, DNS zones can be further broken down into the following zone types:
▪
Primary zone (stored in AD)—These zones are stored in AD and replicated via normal AD replication. This provides an optimized way to replicate the zones within your corporate network. Primary zones stored in AD follow the same multimaster rules as other AD services. This means that you can perform updates on any AD Domain Controller and they will replicate to the other Domain Controllers.
▪
Primary zone (standard)—Standard Primary zones are stored in a flat file on the DNS Server. The Primary zone is considered the master copy of the zone database file. All updates to the zone must be performed on the Primary zone server.
▪
Secondary zone—Secondary zones are read-only copies of the Primary zones. Secondary zones replicate a copy of the zone from the Primary zone server to provide redundancy. Any updates to the zone must be performed on the Primary zone server.
▪
Stub zone—Stub zones are similar to Secondary zones in that they are read-only copies of the zone database file. Stub zones, however, contain only the Name Server (NS), Start of Authority (SOA), and host (A) records for the Name Servers.
Best practices
Create Reverse Lookup Zones
Some applications require the ability to perform Reverse DNS Lookups. As a best practice, you should set up Reverse Lookup Zones for IP subnets on your network.
Global Naming Zones
Before Windows networks relied so heavily on DNS, they used the Windows Internet Naming Service (WINS) to provide name resolution. WINS provides the ability to resolve a NETBIOS name to an IP address. If you support legacy applications that rely on NETBIOS names, it is highly possible that you are still supporting WINS on your network. To help organizations move away from WINS, Microsoft developed Global Naming Zones (GNZs). GNZs, in Windows Server 2008 R2, allow companies to decommission WINS while still supporting NETBIOS names. GNZs require that your domain controllers be at Windows Server 2008 or later. Windows Server 2003 DCs do not support GNZs.
ISA 2004 Client Types and Automating Client Provisioning
Dr. Thomas W. Shinder , Debra Littlejohn Shinder , in Dr. Tom Shinder's Configuring ISA Server 2004, 2005
Configuring DNS Servers to Support Web Proxy and Firewall Client Autodiscovery
Another method you can use in deliver autodiscovery information to Web Proxy and Firewall clients is DNS. You can create a wpad alias entry in DNS and allow browser clients to use this information to automatically configure themselves. This is in contrast to the situation we saw with the DHCP method, where the logged-on user needed to be a member of a specific group in the Windows operating system.
Name resolution is a pivotal component in making this method of Web Proxy and Firewall client autodiscovery work. In this case, the client operating system must be able to correctly fully qualify the name wpad. The reason for this is that the Web Proxy and Firewall client only knows that it needs to resolve the name wpad; it does not know what specific domain name it should append to the query to resolve the name wpad. We will cover this issue in detail later.
NOTE
In contrast to the DHCP method of assigning autodiscovery information to Web Proxy and Firewall clients, you do not have the option to use a custom port number to publish autodiscovery information when using the DNS method. You must publish autodiscovery information on TCP 80 when using the DNS method.
We will detail the following steps to enable DNS to provide autodiscovery information to Web Proxy and Firewall clients:
▪
Creating the wpad entry in DNS
▪
Configuring the client to use the fully-qualified wpad alias
▪
Configuring the client browser to use autodiscovery
▪
Making the connection
Creating the wpad Entry in DNS
The first step is to create a wpad alias entry in DNS. This alias points to a Host (A) record for the ISA 2004 firewall, which resolves the name of the ISA 2004 firewall to the Internal IP address of the firewall. This Host (A) record must be created before you create the CNAME alias entry. If you enable automatic registration in DNS, the ISA 2004 firewall's entry will already be entered into DNS. If you have not enabled automatic registration, you will need to create the Host (A) record for the ISA 2004 firewall manually. In the following example, the ISA 2004 firewall has automatically registered itself with DNS.
WARNING
You should turn off DNS autoregistration on all network interfaces attached to the ISA 2004 fireall. This includes autoregistration for any demand-dial interfaces configured on the ISA 2004 firewall. If the ISA 2004 firewall has already autoregistered information in the DNS, you should remove all the autoregistered entries from the DNS after disabling autoregistration on each of the ISA 2004 firewall's adapters, and then re-enter the addresses. This will prevent problems with Internet connectivity when VPN clients connect to the ISA 2004 firewall's VPN server.
Do the following on the DNS server of the domain controller on the Internal network:
1.
Click Start and select Administrative Tools. Click the DNS entry. In the DNS management console shown in Figure 5.39, right-click on the forward lookup zone for your domain, and click the New Alias (CNAME) command.
Figure 5.39. Selecting the New Alias (CNAME) Command
2.
In the New Resource Record dialog box (Figure 5.40), enter wpad in the Alias name (uses parent domain if left blank) text box. Click the Browse button.
Figure 5.40. The New Resource Record Dialog Box
3.
In the Browse dialog box, double-click on your server name in the Records list.
4.
In the Browse dialog box, double-click on the Forward Lookup Zone entry in the Records frame.
5.
In the Browse dialog box, double-click on the name of your forward lookup zone in the Records frame.
6.
In the Browse dialog box, select the name of the ISA 2004 firewall in the Records frame. Click OK.
Figure 5.41. New Resource Dialog Box
7.
Click OK in the New Resource Record dialog box.
8.
The CNAME (alias) entry appears in the right pane of the DNS management console.
Figure 5.42. Viewing the DNS WPAD Alias
9.
Close the DNS Management console.
Configure the Client to Use the Fully-Qualified wpad Alias
Web Proxy and Firewall clients need to be able to correctly resolve the name wpad. The Web Proxy and Firewall client configurations are not aware of the domain containing the wpad alias. The Web Proxy and Firewall client operating system must be able to provide this information to the Web Proxy and Firewall client software.
DNS queries must be fully qualified before the query is sent to the DNS server. A fully-qualified request contains a host name and a domain name. The Web Proxy and Firewall clients only know the host name portion, which in this case is Wpad. Web Proxy and Firewall client operating system must be able to provide the correct domain name, which it appends to the wpad host name, before it can send a DNS query to the DNS server.
There are a number of methods you can use to provide a domain name that is appended to the wpad name before the query is sent to the client's DNS server. Two popular methods for doing this are:
▪
Using DHCP to assign a primary domain name
▪
Configuring a primary domain name in the client operating system's network identification dialog box.
We will detail these two methods in the following steps:
1.
Right-click My Computer on the desktop, and click the Properties command.
2.
In the System Properties dialog box, click the Network Identification tab. Click the Properties button.
3.
In the Identification Changes dialog box (see Figure 5.43), click More.
Figure 5.43. The Identification Changes Dialog Box
4.
In the DNS Suffix and NetBIOS Computer Name dialog box shown in Figure 5.44, enter the domain name that contains your wpad entry in the Primary DNS suffix of this computer text box. This is the domain name that the operating system will append to the wpad name before sending the DNS query to the DNS server. By default, the primary domain name is the same as the domain name to which the machine belongs. If the machine is not a member of a domain, this text box will be empty. Note Change primary DNS suffix when domain membership changes is enabled by default. In the current example, the machine is not a member of a domain. Cancel out of each of the dialog boxes so that you do not configure a primary domain name at this time.
Figure 5.44. The DNS Suffix and NetBIOS Computer Name Dialog Box
5.
Another way to assign a machine a primary domain name is to use DHCP. A DHCP server can be configured to supply DHCP clients a primary domain name by configuring a DHCP scope option. We did this earlier when we created a scope on the DHCP server using the DHCP scope wizard. In the current example, the DNS Domain Name scope option was set to deliver the domain name msfirewall.org to DHCP clients. This option (shown in Figure 5.45) has the same effect as manually setting the primary domain name. DHCP clients will append this name to unqualified DNS queries (such as those for wpad) before sending the DNS query to a DNS server.
Figure 5.45. Viewing Scope Options
6.
Go to the DHCP client system and open a command prompt. At the command prompt, enter ipconfig /all and press ENTER. Notice that the machine has been assigned a Connection-specific DNS Suffix of msfirewall.org.
DHCP is the most efficient way to assign a primary DNS suffix to clients on your network, as seen in Figure 5.46. This feature allows you to automatically configure a DNS suffix on DHCP clients that connect to your network, which are not members of your Active Directory domain. These clients can still correctly resolve the wpad name based on your current DNS infrastructure without requiring them to join the domain or manually configuring them.
Figure 5.46. DHCP client configuration
Note that if you have multiple domains and clients on your Internal network that belong to multiple domains, you will need to create wpad CNAME alias entries for each of the domains. In addition, DNS support for WPAD entries can be a bit problematic when you have a single Internal network domain that spans WAN links. You can only enter a single WPAD entry per domain, and all hosts that fully qualify the WPAD entry with that domain name will receive the same server address. This can lead to Branch office hosts attempting to access the Internet via an ISA 2004 located at the Main office. The best solution to this problem is to create subdomains in the DNS that support Branch office clients.
Configure the client browser to use autodiscovery
The next step is to configure the browser to use autodiscovery. If you have not already done so, configure the Web browser to use autodiscovery to automatically configure itself to use the ISA 2004 firewall's Web Proxy:
1.
Right-click on the Internet Explorer icon on the desktop, and click Properties.
2.
In the Internet Properties dialog box, click the Connections tab. Click the LAN Settings button.
3.
In the Local Area Network (LAN) Settings dialog box, put a checkmark in the Automatically detect settings check box. Click OK.
4.
Click Apply, and then click OK in the Internet Properties dialog box.
The next step is to configure the ISA 2004 firewall Publish Autodiscovery Information for autodiscovery Web Proxy and Firewall clients.
MCSA/MCSE 70-291: NetBIOS Name Resolution and WINS
Deborah Littlejohn Shinder , ... Laura Hunter , in MCSA/MCSE (Exam 70-291) Study Guide, 2003
In this exercise, we will show you how you can set up your DNS zones to query your WINS database on behalf of your DNS clients for requests not found in DNS. This is useful if the majority of your server names are NetBIOS names stored in WINS, but you wish to use DNS to resolve these names.
1.
Click Start | Administrative Tools | DNS to open your DNS MMC snap in.
2.
Click the "…." to expand your Forward Lookup Zones container.
3.
Highlight the zone you want to configure, then right-click it and select Properties.
4.
In your zone names Properties dialog window, select the WINS tab as shown in Figure 4.73.
5.
Click on the option checkbox Use WINS forward lookup.
6.
Type the IP address of your WINS server and click the Add button as displayed in Figure 4.73. Repeat this step for each server to which you want to forward lookups for name resolution.
Note
Check the option checkbox, Do not replicate this record, if you do not want WINS related entries replicated, or transferred, to your other DNS servers during normal zone transfer operations. This option is useful when you want to avoid zone update failures and loading errors when you have a mixed DNS environment consisting of Microsoft and non-Microsoft DNS servers that may not understand your WINS data records. By default this is not checked when enabling WINS lookup and thus all WINS-related records are slated to be replicated via zone transfers.
7.
Click the Advanced button to configure both Cache Time-outs and Lookup Time-outs as shown in Figure 4.74. The two advanced configuration options include the following:
■
Cache time-out TTL value that determines how long other DNS servers are allowed to cache WINS related entries returned through the use of WINS lookup integration. The default value is 15 minutes.
■
Lookup time-out An interval that determines the amount of time a DNS server will wait to get a successful response from its configured WINS forward lookup server before returning a name not found error. The default value is 2 seconds.
Deborah Littlejohn Shinder , ... Laura Hunter , in MCSA/MCSE (Exam 70-291) Study Guide, 2003
Exam Objectives Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the Exam Objectives presented in this chapter, and to assist you with real-life implementation of these concepts. You will also gain access to thousands of other FAQs at ITFAQnet.com.
Q: Aren't host names and NetBIOS names the same thing in Windows Server 2003?
A: By default, the host name assigned to the computer is used as the NetBIOS name in Windows Server 2003. However, an alternate NetBIOS name can be assigned to the computer, if desired. Even if the host name and NetBIOS name are the same, their functions and the methods by which they are resolved is different.
Q: On the exam, am I going to be expected to know all the different top level domains?
A: No. It's important that you understand what the top level domain designations are and how they're used on the Internet. However, questions on the exam will focus on applying knowledge about top level domains to scenarios. In those cases, you'll need to understand that the root is unnamed and is designated with the dot (.).You'll also need to understand that top level domains as well as the second level domains are managed so that each combination is guaranteed to be unique worldwide.
Q: What's the relationship between recursive and iterative queries and forward and reverse lookups?
A: Recursive and iterative queries specify what results are acceptable. A recursive query requires that either the information or an error be returned. An iterative query requires that either the information or a pointer be returned. When a DNS server is attempting to resolve a query, whether recursive or iterative, it will query its own cache and zone fries first. There might be forward and reverse lookup defined. Forward lookup zones provide information needed to resolve names within the domain and reverse lookup zones provide information on reverse lookups, resolving an IP address to a name.
Q: What exactly is a stub zone?
A: A stub zone is a copy of a zone that contains only three resource records: SOA, NS, and glue A for the delegated zone. The stub zone typically is used to keep a parent zone aware of the authoritative DNS servers for child zones to maintain DNS name resolution efficiency. Just as a secondary zone is a copy of the primary zone, a stub zone is a copy as well, but it does not contain all the RRs, just those used to define authoritative DNS servers for child zones.
Q: Will I be expected to understand BIND for the exam?
A: Microsoft exams focus on Microsoft technologies and, in particular, what's new in the technology. In that regard, you would not expect to see questions about BIND. However, Microsoft technologies often are used in conjunction with non-Microsoft technologies. Where these two overlap or interact, you'll be expected to have a basic knowledge. What's important to understand about the BIND format is that although Microsoft does not use it, UNIX and Linux DNS servers do. If you are importing files, you'll need to understand how these interact and relate to the Microsoft convention.
Q: How much do I need to know about the types of resource records supported in Windows Server 2003?
A: It's important to understand the standard zone RRs such as A, PTR, CNAME, SOA, NS, MX, and SRV. Table 5.5 lists the more commonly used RRs. Understanding what each of these does and what information is contained in them will help you not only on the exam but on the job as well. You might be called upon to add manual RRs and you'll need to understand what effect they will have. The DNS Management Console provides the parameters for each RRs type, so you won't need to memorize that data. You'll need to be able to recognize and understand the standard RRs used in Windows Server 2003.
Q: Do I need to know much about Internet Protocol version 6 for this exam?
A: Internet Protocol version 6 (IPv6) is the latest IP protocol version that provides support for 128-bit IP addresses, so you'll need to understand this protocol and how it's implemented in Windows Server 2003. That subject is outside the scope of this chapter. Within the scope, you'll need to know the RR types used to support IPv6 and also how IPv6 addresses are resolved (using either AAAA for name lookups or IP6.ARPA for reverse lookups). For more information about IPv6, you can visit the IETF Web site for information about the IPv6 standards or visit the Microsoft Windows Server 2003 Web site for information about IPv6 and how to install and route IPv6.
