12. How to Deploy and configure DNS 2016 – (Part5)

How to Deploy and configure DNS 2016 – (Part5)

In our last 3 parts (Part 5, Part6 and Part7) of How to Deploy and configure DNS 2016 series we will focus on advanced DNS options.

Aging and Scavenging (Most often forgotten configuration for a new DNS server)

DNS aging and scavenging is a mechanism to essentially get rid of records that have been stale. As you can imagine, when you’ve got machines that are moving around, you’ve got laptops that are coming on and off the network, well, that laptop, when it leaves the network, sometimes doesn’t get the same IP address when it comes back on. The user ends up being gone for a week or two, well, that laptop could probably get the next IP address that your DHCP server can give to it. And so, with aging and scavenging, the first half is aging where a dynamically updated DNS record is added to your DNS zone and is added also with a time stamp. This time stamp is used to essentially put a time bomb on that record so that the record can be removed after a certain period of time. The time stamp then, the time bomb value, is reset anytime the record is created, when it’s modified or when that record happens to be refreshed. And Windows hosts will refresh their records during three events:

• When they’re booted so at startup
• Anytime there’s a DHCP lease renewal.
• Every 24 hours.

and so what this does is it gives the records and the machines on the network the abilities to keep that same DHCP address and that same DNS resolution as long as they’re continually attached to your network. The machine has to be able to talk your DNS server to go about refreshing the record. Now, when machines go off the network for extended periods of time, we have to have some way to remove the record as well and that’s the second half, the scavenging part of DNS aging and scavenging.
The scavenging actually is what removes the records, the stale records from your DNS database and it uses two different intervals that are really important to understand so that you know why these records are ending up disappearing out of DNS at what can seem to be random periods of time.
The refresh interval is a period that if the client does not refresh it’s record by the end of that period, the scavenging process removes the record. Now, the refresh interval by default is seven days. So, at the end of seven days, if there’s no client around to refresh it’s record or if the client’s powered off for that period of time, well, then the scavenging process is going to realize that that client doesn’t exist and remove the record out of DNS. We, however, have to be careful about this removal of records because we don’t want to go about removing records too quickly.
And so, there is also a no-refresh interval which is a period of time before the refresh interval also about seven days by default where any client refreshes or simply ignored by the server. So, every 24 hours, if that client happens to be online, the server will ignore the refresh. This is done in order to reduce the amount of replication of DNS replication that has to happen between different servers in the environment.
Picture 1
If the Non-Refresh Interval and the Refresh Interval are 7 days then a resource record is considered as stale if not refreshed after 14 days.

Picture 2
If the Non-Refresh Interval and the Refresh Interval are 7 days then a resource record can be refreshed after 7 days starting from the last refresh. Once done, a new Non-Refresh Interval period will start.

DNS aging uses the resource record timestamp to identify if it is stale or not.
We can distinguish between two types of resource records:

• Resource records having a timestamp equal to zero (0): These are static records and they never become stale

• Resource records having a timestamp not equal to zero (0): These are dynamic records and the time stamp represents the date and time of the last update done on the record (For the time, it represents the hour of the last refresh / update)

Let’s see how we can configure this.
First we need to configure refresh interval for our dns server. Right-Click on your DNS server and select Properties

Select Advanced Tab and tick the Enable automatic scavenging of stale records box. Click Apply and OK.

This is the first of the three settings that we need to take a look at.
With AD-Integrated DNS Zones, a single DNS server with DNS scavenging enabled on it is enough to have the DNS scavenging properly done. 
Next we need to do is to right click on zone and select properties and make the configuration again.

On the General tab, click Aging

Here we can set the further aging and scavenging properties. Tick the Scavenge stale resource records box and adjust the settings if you need to. Click OK 2 times.

You need to do this on all the different zones that you want to configure aging and scavenging on.
If you right-click on DNS server you will see the option to set the Aging and Scavenging for all zones. You might be kind of careful with this one if only because sometimes you end up with zones that you might not necessarily want aging and scavenging turned on, as I said, aging and scavenging are designed for zones where there’s a lot of dynamic stuff going on, clients that are coming in and out of the network, laptops and devices and so on.

Manually Scavenge stale records
There is an option to manually scavenge stale records and to do it you would need to right-click on dns server and select Scavenge Stale Resource Records

Convert Static record to a Dynamic one
If I needed to take a static record and make it dynamic (vice versa), make it part of this aging and scavenging thing that I’ve turned on, the way in which I do that is simply is by coming back here to the static record and selecting the box to delete the record when it becomes stale. If you don’t see this option go to View –> Advanced

CONFIGURE DNSSEC (DNS Security)

When you type your bank’s website into your browser at some point your browser, or your computer, basically, goes off to a DNS server and says, “Here’s my bank’s website. “Give me the IP address of that website.” Your browser then reaches out to that IP address, gets your bank’s website data, pulls it on, and you perform your transactions. But if you think about it, there’s a bit of a problem there. That is that you type in your bank’s website, and then the DNS servers somewhere goes and translates that website into that IP address. How do you know that the IP address that the DNS server’s giving you back is actually your bank’s website?
What if you could come up with a way of having a DNS server lie to you? So, this is sort of what the core idea of DNSSEC is; it’s a way to verify what you get back from a DNS server. In fact, it’s verified using cryptographic techniques, which means that everything that you get back, not only do you get a response, you get assigned a bit of cryptographic code that says, “This is legit.” So, what happens is that when you configure DNSSEC, a DNS server with what’s called a signed zone sends a DNSSEC record to validate the response to the query.
So, what DNSSEC does is it protects against things like package interception. Someone spoofing and sending you a DNS response, and putting DNS data in your cache that’s illegitimate. It stops what’s called a monkey in the middle attack where you’re getting bad data from someone intercepting your traffic. It stops spoofing where someone may have compromised the DNS server that you’re using
Why would you use it?
We need to actually have ways of verifying some of these core bits of infrastructure, and DNSSEC is a way of doing it. It’s a way of making sure that when you query a DNS record, you can trust the result you get back.
There are 4 main components of DNSSEC

• TRUST ANCHOR – it’s a special cryptographic key that’s associated with a zone. And this special key is used to validate resource records. So, think of it as like almost a root CA for a zone. You trust the record because you already trust the trust anchor. So, the trust anchor’s sort of the root of your trust, and that’s why we call it a trust anchor, it’s a top. You trust the trust anchor, and then you’ll trust anything that’s authorized by the trust anchor. A trust anchor can be stored in Active Directory, and it can replicate out to all DNS servers, or DCs in a forest. It can also be imported on any standalone DC.

• KEY MASTER – when you deploy DNSSEC in your environment, what you need is a key master; and, basically, a key master is someone that goes and creates keys. And it’s a special DNS server that generates and manages the signing keys for DNSSEC protected zones. You can have one DNSSEC key master in your organization, and a single DNS server can be the DNSSEC key master for multiple zones. That’s not a problem. Just remember once you go and implement this sort of stuff, you do want to back this up. And this is one of the advantages of running this on an Active Directory domain controller because all of these keys, basically, get backed up to Active Directory automatically.

• KEY SIGNING KEY (KSK) – The KSK is used to sign all DNSKEY records at the zone’s root. And you create the KSK using the DNSSEC key master. So, when you first go and deploy DNSSEC in your environment, you set up a key master and then from that point the key master goes and creates the KSK.

• ZONE SIGNING KEY (ZSK) – The key master also can create the ZSK. ZSK is for signing all zone data, including individual resource records other than the DNSKEY records. And, as I said, you create the ZSK using the DNSSEC key master.

Next thing that we need to understand is the DNSSEC Record Types
RRSIG – this is a resource record signature. So, if you have A records, you have quad-A records, MX records etc. Each RRSIG record matches and provides a signature for an existing record in a zone. So, for every record you’ve got in your zone, they’ll be a corresponding resource record signature
NSEC (Technology) – NSEC is a very basic system that provides nonexistence of a record, and it protects against spoofing attacks. Basically, what some people do is they go and create records that don’t actually exist in a zone so that they can never have them checked against anything else. What an NSEC record does is when you go and query the zone, it says, “Actually, this record does not exist.” And that actually does provide useful information in terms of securing DNS
NSEC3 (Technology) – The more recent version, or the upgraded version, is NSEC3. And it’s a replacement that prevents what’s called zone walking, where someone might actually go in and try and fingerprint, or footprint, or get an idea of every record that exists in the zone. Zones can be either signed with NSEC or NSEC3, and you, basically, should use the newer one; but you can’t use both.
NSEC3PARAM –  specify which records will be included in a response from the DNS server for names that don’t exist.
DNSKEY – this stores the public key used to verify a signature. It may store the public KSK and ZSK keys.
DS – that’s a delegation signer record. So, if you’ve got subdomains, this basically is a way of securely signing the delegation. You use it in creating what’s called an authentication chain to a child zone. So, think about your certificate service’s chain where you have a root CA which you trust, and then because you trust the root CA, you’ll trust any subordinate child CAs of that CA. The same thing applies with DS records. If you trust a root zone, or a parent zone, and it’s got a delegation signer record, then you’re going to trust those child zones.
Last thing we need to discuss before demo is Name Resolution Policy Tables (NRPT)
I want to talk about a technology that’s very specific to Active Directory and group policy, and that is the Name Resolution Policy Table. The idea with the Name Resolution Policy Table is that you can enforce through Group Policy that your clients will only accept DNSSEC-signed records from particular zones. So, you’ve got zones that you want to secure, you say, “Right, I’m configuring a policy. “We’re only going to accept DNSSEC-signed records “for hosts in those zones.” Think of it almost like an IPsec policy, where you’re saying that a computer will only communicate with another host if that host communicates using IPsec. If it doesn’t, well, sorry not going to talk to you. So, you configure the Name Resolution Policy Table, obviously, through Group Policy, and it’s in the Windows Settings\Name Resolution Policy area of a Group Policy object. You’ve got a couple of options. You can require DNSSEC for a specific suffix. For example, you can say, “Okay, I want DNSSEC “for everything in the Mehic.se zone.” You can do it for a prefix. You could say, “Okay, every computer that has the prefix, “the first name, or the first bunch of names like SEC, “or essential, or anything like that, “you can do it on a basis of prefix.” I reckon that would probably be a lot harder than doing it on suffix, but whatever floats your boat. You can also do it on the basis of specific Fully Qualified Domain Names. So, that might be that you have a bunch of specifically secure servers in your organizations that you want to make sure that no one’s getting redirected from. So, you put those specific server addresses into your Name Resolution Policy Table, and for those addresses, only DNSSEC records will be accepted.
Let’s see how we can configure this.
Before we configure DNSSEC let’s open powershell and resolve some record. I will type in Resolve-DnsName RDS01.mehic.se -DnssecOk -Server dc01 

And at the moment you can see there that there’s not a whole lot of information around that record.
To configure DNSSEC right-click on the zone –> DNSSEC –< Sign the ZONE

This brings up the DNSSEC Security Extensions wizard. Click Next
On Signing Options page, we get the option to either customize zone signing parameters, sign the zone with the parameters of an existing zone. So, if I, for example, had signed PrimaryZone, I could go and use exactly the same parameters as those used in PrimaryZone for Mehic.se. But as this is the first zone in my DNS infrastructure that I’m configuring DNSSEC for, I’m quite happy with the current parameters. Or I could go and use the default settings, but that’s not going to be very informative to you. It is only next and finish and you will not know what happens under the hood. The reason for you to implement DNSSEC comes from some compliance regulation, and when that regulation has settings that defer from the default settings Windows is going to give you with, well then it comes time to actually customize a few of those settings.
So, choose first option and click Next.

On Key Master page, As you can see up here, any authoritative DNS server that hosts a primary copy of the zone can be the Key Master. So it can be this server, or any other server out there that hosts a primary copy, but there’s only one that you’re going to choose as that Key Master. Click Next

On Key Signing Key page, here it gives me a bit of information, and basically tells me what the Key Signing Key is, saying it’s an authentication key that corresponds to a private key used to sign one or more signing keys. Click Next

Now we need to go and configure our Key Signing Key, When I’m going to go and configure my Key Signing Key, what I need to do is specify a whole lot of information, such as which algorithm am I going to use, which key length am I going to use, which KSP am I going to use, what’s the replication, and so on? So, do to that, I click Add, and on the New Key Signing Key page, I specify whether I’m going to use pre-generated keys.

I’m going to go with generate a new set of signing keys. Next thing I can is choose my cryptographic algorithm. Rather than go with RSA/SHA-256, I’m going with RSA/SHA-512. I’m going to keep the default key length of 2,048 bits. I’m going to use the Microsoft Software Key Storage Provider, and my DNSKEY RRSET signature validity period will be by default 168 hours, which means a new signature will be required every 168 hours on each resource record authentication record. All of these here are things that may be adjusted if they’re required by your industry, or other compliance regulation. If you have an Active Directory Integrated Zone, you can replicate the private key to other DNS servers who are also authoritative for the zone.
OBS!!! If you’re not using Active Directory Integrated Zones, and you need to make them Active Directory Integrated, you actually have to unsign the zone, change it to the AD Integrated Format, and then resign the zone. So typically your DNSSEC configuration is going to be the last thing that you do, the last major change that you make to any zones that you create. 
Also, your keys will actually roll over after a period of days, by default 755 days. That allows you to just roll over those keys to make sure that you’ve got fresh keys every so many number of years, it looks like here. Click OK and next

On Zone Signing Key page click next

Now I need to do our Zone Signing Key. So, same idea here, I click Add. Here I’m happier to use the default. You can change the defaults or keep them. (most of the decisions that you’ll make here are going to be handed down to you from some other regulation document). When done click OK and Next

On Next Secure (NSEC) page, Here I get the option of using NSEC3, which is the newer version, or NSEC in terms of denial of existence of records. So, I’m going to go with NSEC3 because that’s the newest version. I’m going to generate and use a random salt of length 8, and I’m not worried about using opt-out to cover unsigned delegations because we’re not using unsigned delegations. Click Next

On Trust Anchors (TAs) page, Check the Enable the distribution of trust anchors for this zone box. Trust anchors are going to be required any time you have a non-authoritative server that needs to authenticate against the zone, or resolve against the zone, that server’s going to need to have the trust anchor for it to be able to resolve off of the contents of this zone. So typically, particularly in Active Directory environments, you’re going to check this box when you have Active Directory Integrated Zones. Click Next

On Signing and Polling Parameters page, this is basically the values for DNS signing and polling. So, DS-record generation algorithm, I’ve said use SHA-1 and SHA-256. The DS-record time to live is 3,600 seconds. The DNSKEY record time to live also 3,600 seconds. Secure delegation polling occurs every 12 hours, and signature inception is the offset, so the polling offset is going to be 1 hour, and that means that it’s all not happening at the same time. Click Next and Finish

Now if you right-click on empty space in your DNS Manager and select Refresh  you’ll see all of those new records for the zone! Lots of RR Sig records, lots of DNS KEY records.


So, what I’m going to do is I’m going to run that PowerShell command, again. And we can see now that we’re getting validation that that record has been digitally authenticated.

Let’s go back to DNS Manager Console and expand Trust Point. (Trust Point is trust anchor). Trust anchors must be configured on every non-authoritative DNS server that will attempt to validate DNS data

The last thing we need to do is to configure Name Resolution Policy Tables (NRPT)
Open Group Policy Management. I will edit Default Domain Policy. Right-Click and select EDIT

Navigate to Computer Configuration\Policies\Windows Settings and click on Name Resolution Policy
The suffix is going to be mehic.se. So, anything in that particular zone. I’m going to enable DNSSEC in this rule, and I’m going to require that clients check the name and address data has been validated.

You can configure DNS settings for DirectAccess using the Name Resolution Policy Table.  You can also specify Generic DNS Server settings, which means that this specific DNS server will be used for this particular zone. So, you’re able to actually specify, “Oh, if you’re querying this zone, “go and use this particular DNS server”. And Encoding allows you to specify encoding of the request.
Now scroll down and click on create. It creates the rule. I scroll down. I’m just showing you here that it’s saying perform DNSSEC validation, but don’t perform IPsec validation. Click Apply

Open Powershell/CMD and type in gpupdate /force. (Sometimes you need to reboot). Next command Get-DNSClientNRPTPolicy

Any new records that are created in mehic.se are going to be automatically signed. To verify create a new A record in zone and hit refresh.
That’s it. To avoid very long posts we will continue with advanced dns options in Part 6.
What we covered.

• What is Aging and Scavenging and how to configure it
• What is DNSSEC
• DNSSEC main components
• DNSSEC Record Types
• How to implement DNSSEC