Because
DNS does not offer any form of security natively, it is vulnerable to
spoofing, man-in-the-middle, and cache poisoning attacks. For this
reason, it has become critical to develop a means for securing DNS.
DNSSEC was developed to do just that.
There are a series of IETF RFCs that specify the DNSSEC extensions to DNS. These include the following:
RFC 4033— DNS Security Introduction and Requirements
RFC 4034— Resource Records for the DNS Security Extensions
RFC 4035— Protocol Modifications for the DNS Security Extensions
There
are also several other supporting IETF RFCs. Together, these RFCs
modify and extend the DNS protocol. The DNSSEC extensions provide the
following:
In a nutshell, DNSSEC allows
clients to know that the DNS information is coming from a valid server,
wasn’t changed, and that a given host exists or doesn’t exist.
Windows Server 2008 R2 and Windows 7 fully support the latest DNSSEC RFCs 4033 through 4035.
Note
Interestingly, Windows Server
2003 and Windows Server 2008 do not support the latest RFCs, as their
implementation of DNSSEC was based on the now obsolete RFC 2535. That
RFC required secondary zones and, thus, they cannot interoperate with
the Windows Server 2008 R2 DNSSEC.
DNSSEC Components
The DNSSEC relies on signed
zones, which is a zone whose records are signed as defined by RFC 4035. A
signed zone contains one or more of the new DNSEC record types, which
are DNSKEY, NSEC, RRSIG, and DS records. These records allow DNS data to
be validated by resolvers.
Zone Signing Key (ZSK) is
the encryption key used to sign the zone, essentially a public and
private key combination stored in a certificate. The Key Signing Key
(KSK) is the key used to sign the ZSK to validate it, essentially a
public and private key combination as well.
The DNSKEY record is a DNSSEC
record type used to store a public key. The KSK and the ZSK public keys
are stored in the DNSKEY records to allow the zone signatures to be
validated.
Next Secure (NSEC) record is a
DNSSEC record type used to prove non-existence of a DNS name. This
allows DNS clients to be sure that if a record is not retrieved in a DNS
lookup, the record does not exist in the DNSSEC zone.
The Resource Record Signature
(RRSIG) record is used to hold the signature for a DNS record. For each
A record, there will be a corresponding RRSIG record. For each NSEC
record, there will also be a corresponding RRSIG record.
The Delegation Signer (DS)
record is used to secure delegations to other DNS servers and confirm
their validity. This prevents man-in-the-middle DNS servers from
breaking the security chain during recursive lookups.
A nonvalidating
security-aware stub resolver is a security-aware stub resolver that
trusts one or more security-aware DNS servers to perform DNSSEC
validation on its behalf. All Windows DNS clients are nonvalidating
security-aware stub resolvers, meaning they do not actually do the
DNSSEC validation.
The
Windows DNS client is nonvalidating, meaning that the Windows DNS
client does not check to see if the DNS records are secured but instead
implicitly trusts the DNS server. The Windows DNS client flags the DNS
request based on the NRPT table and expects the DNS server to perform
the check for it. The DNS server returns the results regardless and
indicates if the check for DNSSEC was successful or not. If the check
was successful, the Windows DNS client passes the results to the
application requesting the DNS lookup.
Note
To really ensure the
security of the DNS requests, the DNS client must be able to validate
the DNS server. The method of doing this for Windows systems is to use
IPSec. To really, really secure DNS, IPSec must be deployed as well.
Requirements
In the Windows Server
2008 R2 implementation of DNSSEC, the zones are signed offline—that is,
the zone file for the DNS zone is signed and then loaded into the DNS
server. Thus, you cannot have dynamic zones with Windows Server 2008.
They must be static.
The signed zones can be Active
Directory-integrated zones but must be file backed up. The records are
all text based, so Active Directory integrated zones do not pose a
problem.
To request DNSSEC security
for a lookup, the DNS client must have a Name Resolution Policy Table
(NRPT) entry. This then forces the DNS client to flag the request as a
secure request, which causes the DNS server to check the security of the
lookup and return the records with the secure flag set. If the client
does not request security, the DNS server simply returns the records.
Finally, to fully secure the DNS lookups, IPSec should be deployed.
Configuring a DNSSEC Zone
In this scenario, the zone
secure.companyabc.com will be encrypted. The zone is unsecured to start
and contains several records, shown in Figure 1.
The zone is a file-based zone, with the DNS zone stored in the default
directory c:\windows\system32\dns\ in a file named
secure.companyabc.com.dns.
The DNSSEC configuration and management is done using the dnscmd.exe utility.
The first step is to
generate the signing certificates for the secured zone; that is,
generate the ZSK and KSK certificates. The steps to generate the KSK and
ZSK certificates are the following:
1. | On the DNS server, select Start, Command Prompt, and Run As Administrator.
|
2. | Type the command cd \windows\system32\dns.
|
3. | To generate the KSK, run the command dnscmd
/OfflineSign /GenKey /Alg rsasha1 /Flags KSK /Length 1024 /Zone
secure.companyabc.com /SSCert /FriendlyName KSK-secure.companyabc.com.
|
4. | To generate the ZSK, run the command dnscmd
/OfflineSign /GenKey /Alg rsasha1 /Length 1024 /Zone
secure.companyabc.com /SSCert /FriendlyName ZSK-secure.companyabc.com.
|
The keys are stored in
the Local Computer certificate store of the DNS server in the MSDNSSEC
folder. The certificates are shown in Figure 2
from the MMC certificates snap-in for the Local Computer. The validity
period of the signing certificates is five years by default.
The next step is to sign the zone file and the records. This takes the existing zone file (secure.companyabc.com.dns), signs the zone and records, and saves it to another zone file (signed.secure.companyabc.com.dns). The certificates generated in the previous steps will be used for the signing. The steps to sign the zone are the following:
1. | On the DNS server, launch Server Manager.
|
2. | Expand Roles, DNS Server, DNS, DC1, Forward Lookup Zones, and select secure.companyabc.com.
|
3. | Right-click
on secure.companyabc.com and select Update Server Data File. This
ensures that the latest updates are saved in the file.
|
4. | Select Start, Command Prompt, and Run As Administrator.
|
5. | Type the command cd \windows\system32\dns.
|
6. | To sign the zone file, run the command DnsCmd
/OfflineSign /SignZone /input secure.companyabc.com.dns /output
signed.secure.companyabc.com.dns /zone secure.companyabc.com /signkey
/cert /friendlyname KSK-secure.companyabc.com /signkey /cert
/friendlyname ZSK-secure.companyabc.com.
|
The signed zone file is now ready to be loaded into the DNS server.
The last step in signing the
zone is to reload the zone file into the DNS server. The unsigned zone
must be deleted first; then the signed zone file (signed.secure.companyabc.com.dns) is loaded. The steps to reload the zone are the following:
1. | On the DNS server, select Start, Command Prompt, and Run As Administrator.
|
2. | Type the command cd \windows\system32\dns.
|
3. | Type dnscmd /ZoneDelete secure.companyabc.com /f. This deletes the zone from the DNS server.
|
4. | Type dnscmd /ZoneAdd secure.companyabc.com /primary /file signed.secure.companyabc.com /load. This loads the signed zone file.
|
The zone secure.companyabc.com is now encrypted. Also, if saved, the zone file will save to the new signed.secure.companyabc.com.dns if updates are made. Figure 3 shows the zone records after encryption.
Note
The records show an
inception date of 10/26/2009 and an expiration date of 11/25/2009. The
default validity date is 30 days from the date of the signing of the
zone. This means that the zone file will need to be resigned within 30
days. If a longer validity period is needed, the optional /ValidFrom and
/ValidTo parameters can be specified on the dnscmd.exe command when
signing the zone file.
There are four records for each previous entry now, which are the following:
Standard A Record
RR Signature (RRSIG) Record for the Standard Record
Next Secure (NSEC) Record
RR Signature (RRSIG) Record for the Next Secure Record
Without any additional
configuration, the DNS clients blissfully ignore the DNSSEC for the
zone. To have the clients use the DNSSEC properties of the DNS zone,
they must be configured to request secure DNS entries. This is done by
configuring a Name Resolution Policy Table (NRPT) policy for clients.
The NRPT policy can be
configured through group policy. The steps to create a NRPT group policy
for the secure.companyabc.com zone are the following:
1. | On the domain controller DC1, launch Server Manager.
|
2. | Expand Features, Group Policy Management, Forest: companyabc.com, Domains, and select companyabc.com.
|
3. | Right-click on companyabc.com and select Create a GPO in This Domain, and Link It Here.
|
4. | Enter NRPT Group Policy Object and click OK.
|
5. | Right-click the NRPT Group Policy Object link and select Edit.
|
6. | Expand Policies, Windows Settings, and select Name Resolution Policy.
|
7. | In the field “To which part of the namespace does this rule apply?” select Suffix and enter secure.companyabc.com.
|
8. | In the DNSSEC tab, check the Enable DNSSEC in This Rule.
|
9. | Check the Validation box Require DNS Clients to Check That Name and Address Data Has Been Validated.
Note
The wording of this option
is precise. The Windows DNS client will check that the DNS server has
validated the data, but will NOT do the validation itself.
|
10. | Click the Create button to create the record in the Name Resolution Policy Table at the bottom of the screen. Figure 4 shows how the record should look.
|
11. | Close the GPMC editor to save the changes.
|
Now, all domain DNS
clients will request that DNS servers check the validity of the lookups
for domain secure.companyabc.com using DNSSEC.
Additional steps that might be needed to maintain the secured DNS zone include the following:
Back up the KSK and ZSK certificates.
Back up the secured and unsecured zone files.
Establish a maintenance schedule to refresh the zone signatures.
