New DNS features in Windows Server 2012
Articles,  Blog

New DNS features in Windows Server 2012


In this video from ITFreeTraining I will look
at the new features in DNS for Windows Server 2012. There are only 2 new features so let’s
have a look. The first feature is improved PowerShell support.
With Windows Server 2012 in general, PowerShell support has increased across the board. In
DNS, all user interface commands are now support in PowerShell. Whatever you can achieve in
the user interface, you can achieve in PowerShell. You can also add and remove the DNS role from
PowerShell if you need to. The next feature is improved support for DNSSEC.
DNSSEC essentially provides additional security for DNS preventing DNS records and DNS transfers
from being tampered with by an attacker. DNSSEC was available in Windows Server 2008, but
has been improved in Windows Server 2012. I will now have a closer look at the improvements
for DNSSEC, but first a brief introduction to DNSSEC. DNSSEC stands for Domain Name System Security
Extensions. It is essentially an extension to DNS that prevents data from be tampered
with or faked. Traffic between DNS servers and the clients is not encrypted so can be
modified. For example. Consider a Primary DNS server and secondary Server. As changes
happen to the primary zone, these changes need to be sent to the secondary server.
If you have additional security on your network, for example VPN or using IPSec to secure communication,
this will not be too much of a concern. This is because even though the DNS traffic is
not in itself encrypted, it is cased in encryption. If however this is not the case, a hacker
can position themselves between the two DNS servers and change the updated information.
For example, they could have the user directed to their fake web site rather than the original
web site. The user would not even be aware that this is occurring. This is what hackers
want to happen in order to get usernames and password or credit card details.
The next point to consider is when a user performs a DNS query. This query is returned
to the user but the data in not encrypted. Once again a hacker can send their own data
back to the client. The hacker could change the data, they could send their own data,
or they could send a message to the client saying the query could not be resolved and
effectively cause a denial of service attack. So what does DNSSEC do in a nut shell? It
provides a method to check that data has not been changed. Once the client or a server
receives DNS data, the data comes with a signature to allow the client to check that the data
is authentic and has not been changed. This should give you a basic idea of what DNSSEC
is. Now let’s look at the new DNSSEC features in Windows Server 2012. The first new feature in Windows Server 2012
allows trust anchors to be seen in the DNS manager that have been stored in Active Directory.
Trust anchors are not at new feature, but previously you were not able to see a trust
anchor in DNS manager. So what is a trust anchor?
Let’s consider how DNS works. At the top of the hierarchy you have the root hint server.
This is where DNS servers start the resolving process. When DNS names are resolved they
are broken down starting from the right of the address and moving left. Each server in
sequence knows the address of another DNS server that knows the next DNS server to pass
the request onto until finally a DNS server is found that can answer the query.
For this reason it makes sense that the root hint server needs to be trusted. So the root
hint server is what you would call a trust anchor. The root hint server contains a key
that is used to create signatures for DNS data that is passed between servers or to
the client. In the next step of the resolving process,
in this example, is an AU DNS server is contacted. This DNS server supports DNSSEC so it can
use the signature of the root hint server. Basically what is happening is the root hint
server is saying that it trusts the AU server. The problem occurs when something like the
following happens. The next server, a DNS com server does not support DNSSEC.
This becomes a problem because the last DNS server, the DNS server that knows how to resolve
our DNS name, example.com.au, does support DNSSEC. The problem is that the chain of trust,
as it is called, has been broken. There is no way that the DNS server can validated the
data coming from the com DNS server and confirm that it has not been tampered with.
In the real world, there are a lot of DNS servers that do not support DNSSEC. As you
can imagine, DNS servers are located all over the world and it is up to the administrator
in that country to configure the DNS server to support DNSSEC. Some countries may be quicker
to adopt this technology while others are more wary.
When a client performs a DNS query, the client will want to confirm that data is accurate
by checking the signature on the DNS data with root hint server. Since the chain of
trust is broken this is not possible. To get around this a new trust Anchor is created.
If the client trusts the new trust anchor, DNSSEC can be used from that point onwards.
On your network, you may use a domain name that cannot be registered like a .local address.
When this is the case, you will need to create a trust anchor for clients. The point to remember
is, with Windows Server 2012 any trust anchor that you create, you will be able to view
it in DNS manager. In Windows Server 2012 trust anchors are easier
to use because of the last two features. In Windows Server 2012 the keys used in DNSSEC
and their management has improved significantly. We already know that the keys can be stored
in Active Directory. This allows them to be replicated with the other Active Directory
data. With Windows Server 2012, there is support
for automated key rollover. When a key is being used in DNSSEC, it will eventually need
to be changed. Windows Server 2012 can now control this process meaning the administrator
does not need to worry about generating a new key before the old key expired.
The last new feature in Windows Server 2012 is what is called The Key Master. What this
essentially is, is a primary zone that can be configured to manage all the keys associated
with that zone. This takes a lot of the work away from the administrator. The administrator
needs to select a server that is holding a primary zone and configure it to be The Key
Master. Only one Key Master can exist at once, but the administrator is free to move The
Key Master to another server if they require. With The Key Master features, managing DNSSEC
is a lot easier than ever before. Thanks for watching this video from ITFreeTraining.
This is just one of the free videos from the DNS courses and the other courses available
free of charge on YouTube or our web page. Hope you have found this video useful and
hope to see you in the next one.

5 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *