Enabling DNS on the network
Enabling DNS on the network
To enable DNS on the network, you need to configure DNS clients and servers. When you configure DNS clients, you tell the clients the IP addresses of DNS servers on the network. By using these addresses, clients can communicate with DNS servers anywhere on the network, even if the servers are on different subnets.
NOTE Configuring a DNS client is explained in Chapter 7, “Managing TCP/IP networking.” Configuring a DNS server is explained in the next section of this chapter.
The DNS client built into computers running Windows 7 and later, in addition to Windows Server 2008 R2 or later, supports DNS traffic over Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). By default, IPv6 automatically configures the site-local address of DNS servers. To add the IPv6 addresses of your DNS servers, use the properties of the Internet Protocol Version 6 (TCP/IPv6) component in Network Connections or the following command:
netsh interface IPV6 ADD DNSSERVERS
In Windows PowerShell, you can use Get-NetIPInterface to list the available interfaces and then use Set-DNSClientServerAddress to set the IPv6 address on a specified interface.
DNS servers running Windows Server 2008 R2 or later support IPv6 addresses as fully as they support IPv4 addresses. In the DNS Manager console, host addresses are displayed as IPv4 or IPv6 addresses. The Dnscmd command-line tool also accepts addresses in either format. Additionally, DNS servers can now send recursive queries to IPv6-only servers, and the server forwarder list can contain both IPv4 and IPv6 addresses. Finally, DNS servers now support the ip6.arpa domain namespace for reverse lookups.
When the network uses DHCP, you should configure DHCP to work with DNS. DHCP clients can register IPv6 addresses along with or instead of IPv4 addresses. To ensure proper integration of DHCP and DNS, you need to set the DHCP scope options as specified in “Setting scope options” in Chapter 8, “Running DHCP clients and servers.” For IPv4, you should set the 006 DNS Servers and 015 DNS Domain Name scope options. For IPv6, you should set the 00023 DNS Recursive Name Server IPV6 Address List and 00024 Domain Search List scope options. Additionally, if computers on the network need to be accessible from other Active Directory domains, you need to create records for them in DNS. DNS records are organized into zones, where a zone is an area within a domain.
DNS client computers running Windows 7 or later, in addition to Windows Server 2008 R2 or later, can use Link-Local Multicast Name Resolution (LLMNR) to resolve names on a local network segment when a DNS server is not available. They also periodically search for a domain controller in the domain to which they belong. This functionality helps avoid performance problems that might occur if a network or server failure causes a DNS client to create an association with a distant domain controller located on a slow link rather than a local domain controller. Previously, this association continued until the client was forced to seek a new domain controller, such as when the client computer was disconnected from the network for a long period of time. By periodically renewing its association with a domain controller, a DNS client can reduce the probability that it will be associated with an inappropriate domain controller.
The DNS client service for Windows 8 and later has several interoperability and security enhancements specific to LLMNR and NetBIOS. To improve security for mobile networking, the service
? Does not send outbound LLMNR queries over mobile broadband or VPN interfaces.
? Does not send outbound NetBIOS queries over mobile broadband.
For better compatibility with devices in power-saving mode, the LLMNR query timeout is set to 410 milliseconds (msec) for the first retry and 410 msec for the second retry, making the total timeout value 820 msec. To improve response times for all queries, the DNS client service does the following:
? Issues LLMNR and NetBIOS queries in parallel, and optimizes for IPv4 and IPv6
? Divides interfaces into networks to send parallel DNS queries
? Uses asynchronous DNS cache with an optimized response timing
NOTE You can configure a DNS client computer running Windows 7 or later, in addition to Windows Server 2008 R2 or later, to locate the nearest domain controller instead of searching randomly. This can improve performance in networks containing domains that exist across slow links. However, because of the network traffic this process generates, locating the nearest domain controller can have a negative impact on network performance.
Windows Server 2008 and later support read-only primary zones and the GlobalNames zone. To support read-only domain controllers (RODCs), the primary readonly zone is created automatically. When a computer becomes an RODC, it replicates a full read-only copy of all the application directory partitions that DNS uses, including the domain partition, ForestDNSZones, and DomainDNSZones. This ensures that the DNS server running on the RODC has a full read-only copy of any DNS zones. As an administrator of an RODC, you can view the contents of a primary read-only zone. You cannot, however, change the contents of a zone on the RODC. You can change the contents of the zone only on a standard domain controller.
To support all DNS environments and single-label name resolution, you can create a zone named GlobalNames . For optimal performance and cross-forest support, you should integrate this zone with AD DS and configure each authoritative DNS server with a local copy. When you use Service Location (SRV) resource records to publish the location of the GlobalNames zone, this zone provides unique, single-label computer names across the forest. Unlike WINS, the GlobalNames zone is intended to provide single-label name resolution for a subset of host names-typically, the CNAME resource records for your corporate servers. The GlobalNames zone is not intended to be used for peer-to-peer name resolution, such as name resolution for workstations. This is what LLMNR is for.
When the GlobalNames zone is configured appropriately, single-label name resolution works as follows:
1. The client’s primary DNS suffix is appended to the single-label name that the client is looking up, and the query is submitted to the DNS server.
2. If that computer’s full name is not resolved, the client requests resolution by using its DNS suffix search lists, if any.
3. If none of those names can be resolved, the client requests resolution by using the single-label name.
4. If the single-label name appears in the GlobalNames zone, the DNS server hosting the zone resolves the name. Otherwise, the query fails over to WINS.
The GlobalNames zone provides single-label name resolution only when all authoritative DNS servers are running Windows Server 2008 R2 and later. However, other DNS servers that are not authoritative for any zone can be running other operating systems. Dynamic updates in the GlobalNames zone are not supported.