Dynamic DNS records
Dynamic DNS (DDNS) allows dynamic creation and
updates to DNS records. By allowing DDNS, hosts can automatically update
their own records within the DNS zone. Using DDNS raises some obvious
security questions. For this reason, it is best practice not to enable
DDNS for any zones that are facing the public Internet. You should also
consider using Secure Dynamic Updates on your LAN when the DNS zones are
AD integrated.
DNS and Active Directory
We have primarily covered
traditional DNS systems using primary and secondary DNS zones. When
using DNS in an AD environment, you have the option to integrate zones
into AD instead of using the primary/secondary model. There are some
inherit benefits of using AD integrated zones.
Securing DNS
Due
to the critical nature of DNS services, it is important that you make
sure your DNS Servers are as secure as possible. This is especially true
for DNS Servers that are connected to the Internet. Consider
implementing some of the following to secure your DNS Servers:
- Open only necessary firewall ports required to perform name resolution (53 TCP/UDP).
- Restrict log-on to DNS Servers to DNS admins.
- Turn
off recursive lookups if the DNS Servers will be used only for
responding to queries for zones they host. If you plan to allow clients
to use the DNS Servers for name resolution, you will need to leave this
on.
- Do not allow DDNS Updates for non-AD-based zones. Be sure to use only Secure Dynamic Updates for AD-integrated zones.
- Ensure that zone transfers can occur only to authorized secondary servers.
Taking the preceding steps and following other
security best practices can help ensure that your DNS Servers remain
secure and reliable.
Monitoring and troubleshooting DNS
To ensure that you have reliable DNS services, you
need to monitor your DNS Servers and ensure that they perform name
resolution properly. In this section, we will take a look at some of the
tools provided in Windows to monitor DNS and troubleshoot problems.
Event log and debug logging
You will want to review the DNS event log on a
regular basis to ensure that services are online and available. Search
the event log for any error events and correct any issues that appear in
the event log. You should also keep an eye on warning events. These can
point to configuration issues that may not currently be causing an
outage, but could do so at a future time.
Debug logging can really help you home in on the root cause of DNS problems (see Figure 17)
where the solution may not be apparent using other monitoring methods
and event logs. You will not want to leave debug logging enabled all the
time. Turn it on when you need details on DNS packets sent and received
from and to the server. After resolving the problem, be sure to disable
debug logging to prevent the hard drive from filling up. The debug log
settings can be found in the properties of the DNS Server.
DNS Monitoring tab
You can test basic query functionality of the DNS Server by going to the server properties and selecting the Monitoring tab. Here you can manually run both simple and recursive queries against the DNS Server manually and on a scheduled basis.
NSLookup and DNScmd
NSLookup and DNScmd are two very important command
line tools that can assist in troubleshooting DNS problems. You should
have both of these tools as part of your admin toolkit. Luckily, they
are already installed on the server as a part of the operating system.
NSLookup is a tool
used to test queries against DNS Servers. You can run this command line
tool from your workstation and point it to a DNS Server that you wish to
test. You can then run various queries against the server to see
detailed information on the data returned.
DNScmd
is a tool now included as a part of the Windows operating system.
DNScmd includes an array of options that allow you to perform DNS
administrative actions from the command line. These actions include
creating/deleting DNS zones, adding and deleting records, and managing
the DNS windows services. Table 1 lists some commonly used DNScmd commands.
Table 1. Common DNScmd Commands
| Command | Description | Example |
|---|
| DNScmd/zoneadd zonename/primary | Create a new primary DNS zone | DNScmd/zoneadd syngress.com/primary |
| DNScmd/zoneadd zonename/secondary IP Address of Primary | Create a new secondary DNS zone | DNScmd/zoneadd syngress.com/secondary 10.1.3.4 |
| DNScmd/zonedelete zonename | Delete a DNS zone | DNScmd/zonedelete syngress.com |
| DNScmd/enumzones | List DNS zones on a server | DNScmd/enumzones |
| DNScmd/zoneprint zonename | List all the DNS records in a zone | DNScmd/zoneprint syngress.com |
| DNScmd/recordadd zonename hostname A IP Address | Create a new host (A) record | DNScmd/recordadd syngress.com www A 10.1.3.3 |
| DNScmd/recordadd zonename @ MX priority FQDN of mail server | Create a new mail exchanger (MX) record | DNScmd/recordadd syngress.com @ MX 100 mail.syngress.com |
Viewing cache
If your DNS Server does recursive queries against
other DNS Servers, it will begin building a cache of lookups it has
performed. The next time the same lookup is requested, the DNS Server
simply pulls the query result from the cache. You can view the cache by
going to the DNS Server, and then going to the View menu and selecting the Advanced
option. You will see the cache folder appear in the management console.
You can open the zone to review records or right click and the option Clear Cache to delete all cached copies of the records.
Aging and scavenging
The
aging and scavenging process allows DNS to perform basic automated
administration by deleting old DNS records that are no longer in use.
This feature will be more important for AD-integrated zones but can also
be helpful for standard primary/secondary DNS zones.
The aging and scavenging process can be set up on the
server level, zone level, or both. Server level settings apply to all
the zones on the server. Zone-level settings can be set on individual
zones to override the server-level settings. Aging and scavenging are
set up either in the server properties or in the zone properties (see Figure 18).
After providing your preferred scavenging settings,
you have to enable a DNS Server to actually run the scavenge process. To
do this, open the server properties window, and then select the Advanced tab. Click the option Enable automatic scavenging of stale records (see Figure 19).
Using the default settings, the scavenge process will
run every seven days and will purge records that have not been updated
in fourteen days.
Overview of WINS
The
WINS provides name resolution services for NETBIOS names on Windows
networks. WINS was originally developed to provide NETBIOS name
resolution before Windows networks relied so heavily on DNS. WINS works
much like DNS in the sense that DNS maps FQDNs to IP addresses while
WINS maps NETBIOS names to IP addresses.
You should probably try to avoid using WINS if you
are building a new network. Microsoft is deemphasizing WINS in current
operating systems and may decide to remove support in future Windows
versions. With that being said, it is possible that at some point you
may end up needing to administer an existing network that still uses
WINS for legacy applications or operating systems. You should understand
how WINS works prior to taking ownership of that network.
|
WINS and IPv6
WINS is considered as a legacy name resolution
service; thus it does not support IPv6 addresses. You need to keep this
in mind if you have WINS deployed and plan on moving to IPv6. You may
want to consider GNZs in DNS instead of WINS.
|
WINS is deemphasized to the point that it is not
considered a role in Windows Server 2008 R2. To set up a WINS server,
you will need to install the service from the Features node in Server
Manager (see Figure 20).
Once the WINS feature is
installed, it can be used immediately. You can configure clients and
servers to register with the WINS server, and they will begin creating
records within the WINS database.
When planning for WINS, you may want to consider
placing a WINS server on larger network segments to limit the amount of
traffic being sent over WAN links. Like DNS, you can place multiple WINS
servers on your network that replicate with each other. WINS servers
can be set up for push replication, pull replication, or both. During
push replication, the server “pushes” changes out to replication
partner. During pull replication, a WINS server “pulls” changes from a
replication partner.
If mission-critical applications rely on
WINS, you should also consider deploying multiple WINS servers for
redundancy. Clients can then be pointed to multiple WINS servers for
failover in the event that the primary server fails.
