Enabling DNS Secure Only Updates
Prerequisites / Suggestions
This article is aimed to help start us on the right track to enabling DNS security in our organization in a way to best support all our users while protecting our resources. As with any network change, it is aimed at impacting users and services as little as possible. This is best accomplished when other best practices have been followed in the network configuration. These include but are not limited to:
– Active Directory Intergraded DNS Zones
– Whenever possible, intergrating your DNS into AD is very helpful to the stability of your DNS design. The benefits are numerous, but a few are the multi-master updates and replication. In normal DNS only one server can be the owner of the zone and have a writable copy, in multi-master any primary server can write to the database spreading the load and often bringing a master copy of DNS closer to the end user.
– Static IP addresses assigned to your servers / DHCP for clients
– DNS updates are handled differently between static and dynamic allocations. These differences are to the advantage of the statically assigned servers. This is even truer when implementing secured DNS zones.
– Proper DNS Scavenging
– DNS Scavenging is not a critical service, but it can help make administration easier and improve server performance. It does this by trimming the fat from the DNS database. If you do not yet have scavenging enabled on you DNS zones I would suggest planning and enacting that change before streamlining your DNS zones.
– Some rules to follow for enabling are (these are not all-inclusive):
– When designing a DNS scavenging solution, the most important thing to remember is that DNS is a critical service, and scavenging, while helpful, is not critical. You are more concerned that DNS can correctly answer all the questions it is asked, than that DNS has too many answers. Proper DNS scavenging can help in this, while aggressive strategies can put us at risk.
– The scavenging service (done at the server level in the DNS management console) should only be done for one server that owns the DNS zone to avoid premature removal from the DNS database.
– DNS is tied tightly to IP addressing methods. Be aware of how your services, that use DNS, update their records in the database. Statically assigned Microsoft clients update their DNS records daily (every 24 hours). If the DHCP service is performing DNS updates for its clients then it updates the client records when the client renews its IP at half the DHCP lease. If the DHCP clients are updating their own records they follow the 24 hour standard interval (You may find contradiction for this in some articles, see the network capture below taken on an XP machine, validated on 2003-Win 7). Contrary to many articles (including those by Microsoft) that state that the Netlogon service that runs on Domain Controllers updates records every hour, this update actually takes place every 24 hours – up until Windows 2008. Starting with 2008 SP1 (the first relase of 2008), this interval has been lowered to 1 hour.
See http://www.cbfive.com/blog/post/Netlogon-DNS-SRV-Resource-Record-Registration.aspx
– Scavenging works well with the default DHCP lease time (8 days) and the default update intervals. If you have not changed the DHCP lease times, it is wise to leave the DNS Refresh and No-Refresh intervals to the default 7 days each.
Microsoft DNS Security
An ongoing security concern in the technical field is DNS. DNS is at the core of our technical infrastructures, but has some security drawbacks to it. One is that, in a DNS zone that does not have security turned on; any record can be overwritten (or duplicated) by any source. This leaves critical records such as DC locator and other service records vulnerable to highjacking and DOS attacks. Here we will discuss how to mitigate this, and some other specific caveats to securing DNS.
Securing DNS
In Microsoft DNS, to secure against this, we have the ability to set the DNS zone to “Secure only” updates. This means that when the DNS record is created or updated in the directory a KRB token corresponding to the domain account from which the DNS update came is added to the record as a security ACL. In the default scenario the security account used in the Secure DNS update is the computer account. This means that only that computer account or a DNS admin will be able to update that record in the future.
DNS Security for Down Level Clients
Many networks include legacy windows clients (such as Windows 98 and Windows NT) or some 3rd party clients such as MAC or Linux that are unable to secure their DNS records by default. These clients would be unable to register in DNS securely since they would not have the intelligence to create the secure update or to gather the key material needed to do so.
Using a Microsoft DHCP server to facilitate these updates can help to mitigate this issue, as well as providing a consistent method for updating DHCP client records.
DHCP’s Role in DNS Security
DHCP gives us a way to provide consistent DNS security to all of our client records. DHCP has the ability to update both A and PTR records for our DHCP clients. What this means is that the DNS secure update will now be done with the DHCP server’s account, instead of the end client. Thus, for those clients that cannot update their records, DHCP can update DNS for them.
There are some fringe benefits to having DHCP update our records in DNS. One is that since servers are typically statically given an IP address (recommended because of update intervals and consistency), they will not be DHCP clients. They will then update their own records in DNS with their own account as the DNS record owner. The DHCP Service account will not be able to overwrite this record and so server DNS records will be better segmented and secured.
Problem with Multiple DHCP servers
One reason for concern when DHCP does all the DNS updates is that in large networks we may use methods such as DCHP split scopes to provide redundancy. This means that two different DHCP servers could serve the same set of clients. Even in smaller environments, mobile users may travel between networks and DHCP servers frequently. So, since the first DHCP server used its computer account to update the record in DNS, the second DHCP server will not be able to change this DNS record.
Problem with DHCP on a DC
Domain Controller computer accounts have special rights to the DNS database when it is stored in Active Directory. Since typical DHCP updates use the computer account, co-location of DHCP and the DC can mean that the DNS update, done by DHCP with the computer account can cross unwanted boundaries. Fortunately, there are ways to mitigate this.
Fix to Multiple DHCP servers or DHCP on a DC
In order to fix these issues we use a single DHCP account for DNS updates. This DHCP-DNS update account does not need any special rights other than being a domain user. This way it cannot over write any other DNS records but those which it creates. You do not change the account which the service runs under. You simply open the DHCP management console and right click on the server and go to “properties”. From there go to the “Advanced” tab then “Credentials” and add the user account here for every DHCP server. Do this on all your DHCP servers with the same DHCP-DNS update account, then all DNS updates from your DHCP servers will be ACL-ed with the same account, so DHCP will all be able to update each record created by any DHCP server.
VPN devices and DNS security
Another area of concern when implementing DNS security is VPN devices. These devices are rarely domain members. VPN devices handle DHCP and DNS a myriad of ways that we need to be aware of. There are too many ways to provide fixes for all, but the first step in any of these is to identify what the VPN concentrators do for IP address assignment and DNS updates.
VPN Device and DHCP
Here are some of the DHCP methods VPN devices will use; DNS may be separate from these:
– Local IP address Pool
– This will not allow the DHCP servers to do the DNS update and may result in a record that cannot be updated.
– DHCP Proxy
– This is typically a request to gather a pool of addresses from a DHCP server. This sometimes means that a hostname is not given, so a DNS update cannot be added.
– DHCP Forwarding
– This may allow the DHCP servers to operate normally if the hostname value is correctly passed through.
VPN Device and DNS
Here are some of the DNS methods VPN devices will use; DHCP may be separate from these:
– Local DNS Service
– This may mean that VPN concentrator maintains DNS itself with a completely separate system, forwarding to the central infrastructure.
– DNS Proxy
– This means that the VPN concentrator receives the DNS update from the client (or through the DHCP settings) and sends the update along to the internal DNS servers.
– DNS Forwarding
– This may allow the DNS clients to pass their updates directly to the DNS servers.
Non-Secure to Secure Zone Migration
Changing a DNS zone to “Secure-only” updates through DHCP that has not had security already enabled is pretty strait forward. No special permissions are needed for the DHCP DNS update account; this is because there are no security identifiers on the current records in the DNS database. We should still be concerned that all our clients are making these secured updates, and we will talk about how to check for this later.
Moving to a secure Zone with DHCP DNS Updates
Changing a secure DNS zone to use DHCP to do the clients update requires first that the DHCP DNS update account have rights to each of the DNS records. These records were originally created by the clients themselves so the DNS records were secured by the clients KRB token. This means that the DHCP-DNS update account cannot overwrite or update these records in DNS. To overcome this we temporarily add the DHCP-DNS update account to the “DnsUpdateProxy” group in Active Directory. This gives the DHCP-DNS update account administrative rights to the zone, and so this is only a temporary change (this could introduce the risk of being able to overwrite critical DNS records, even though the chance is slim). The length of time that the DHCP-DNS update account should live in this group should be twice the scavenging interval (the sum of no-refresh, refresh and scavenging). If you do not have DNS Scavenging enabled, and do not plan to, this can be set to twice the longest DHCP lease time, but you will also need to check the DHCP server often for errors in updating its client’s DNS records as there may be some lingering DNS records that were not overwritten or updated during the time that DHCP-DNS update account had the elevated rights.
Making sure it works
Before making any change to DNS it is a good idea to take a snapshot of the current DNS database. There are a few ways to do this.
One way is to set up a secondary DNS zone on another member server, no users will use this server for DNS so the impact is minimal. This is a good idea in any DNS environment. The DNS database stored in AD is not easily restored without taking down a Domain Controller since the DNS database is stored in the directory. Alternatively, secondary DNS servers store the DNS database in a text file. This text file can be backed up while the DNS service is running so that we can backup this data at anytime.
If the first option is not viable for you, another method is to export the list of records in the DNS management console. Simply open the zone(s) and right click in the right pane and select “Export list”. This will allow you to create a text file of all the information displayed. This is in no way a backup of the records, but it can give you a list of what is there. This may also be a painful exercise in large namespaces or environments, as you will have to do this for every level of hierarchy in the DNS zone. This can be scripted with DNSCMD.
Once you have this backup of what was originally in place, implement your design. After a sufficient time has passed (such as twice the scavenging interval), look at the delta between the current DNS database and what it was before your changes. If this is too large there may be reason for concern.
Another place to look will be the event logs and DHCP management console of the DHCP server(s) (in the management console you will typically see an icon of a pencil and eraser next to the lease or a blue triangle w/ an exclaimation mark in the middle). This will tell you if the DHCP server is having any problems updating the records. You should not wait any time to begin looking at this, but make it a regular effort to review these logs for errors.
Reference(s):