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.