Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Windows Server 2012 : Implementing DNSSEC (part 2) - How DNSSEC works,Deploying DNSSEC

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
5/2/2014 2:53:06 AM

How DNSSEC works

DNSSEC works by combining public key infrastructure (PKI) cryptography with DNS to use digital signatures and cryptographic keys to sign DNS zones and validate that DNS responses are authentic. Figure 1 shows the steps involved in the name-resolution process when DNSSEC has been implemented in a Windows Server–based network. The basic steps involved are as follows:

  1. A client such as a Windows 8 computer issues a DNS query to its local DNS server.

  2. The client’s local DNS server has DNSSEC enabled but is not authoritative for the zone being queried, so it issues a recursive query to the authoritative server for the zone to request an authoritative response.

  3. The authoritative server has DNSSEC enabled and is the authoritative server for the zone being queried. This means that the zone has been digitally signed on this server. When the authoritative server receives the recursive query, it returns an authoritative response to the client’s local server. This response includes one or more DNSSEC resource records, which can include the following types:

    • Resource Record Signature (RRSIG) These resource records contain digital signatures for all records in a zone.

    • DNS Public Key (DNSKEY) These resource records contain the public keys for a particular zone.

    • Delegation Signer (DS) These resource records indicate the public key for a child zone.

    • Next Secure (NSEC or NSEC3) These resource records allow the validation of a negative response.

  4. The local server uses the public key of the signed zone on the authoritative server to validate the response it received from the authoritative server.

  5. The local server returns the requested response to the client that issued the query. The client can now access the network resource represented by the name it was querying for.

How DNSSEC works.
Figure 1. How DNSSEC works.

Deploying DNSSEC

Deploying DNSSEC using Windows Server 2012 into an existing Active Directory environment involves performing the following steps:

  1. Begin by introducing Windows Server 2012 domain controllers into your environment. These domain controllers should also have the DNS Server role and be configured to use Active Directory–integrated zones.

  2. DNSSEC is implemented by signing zones on your DNS servers. After deciding which DNS zone to implement DNSSEC on, sign the zone by opening the DNS Manager console, selecting the DNS server, right-clicking on the zone, and selecting DNSSEC, followed by Sign The Zone:

    image with no caption
  3. Follow the prompts of the Zone Signing Wizard to complete the process of signing the zone. The simplest approach is to use the default settings to sign the zone:

    image with no caption

    For example, selecting this option when signing the corp.contoso.com zone on your first Windows Server 2012 domain controller DC-1.corp.contoso.com would have the following results:

    • The domain controller becomes the key master for the corp.contoso.com zone. The key master is the DNS server that generates and manages signing keys for a zone that is protected with DNSSE

    • A key signing key (KSK) with a length of 2048 bits is generated using the RSA/SHA-256 cryptographic algorithm. The KSK is an authentication key that signs all of the DNSKEY records at the root of the zone, and it is part of the chain of trust. By default, the KSK has a rollover frequency of 755 days, and any DNSKEY records signed using the key have a signature validity of 168 hours. Key rollover and signature refresh are enabled by default on Windows Server 2012 DNS servers.

    • A zone signing key (ZSK) with a length of 1024 bits is generated using the RSA/SHA-256 algorithm. The ZSK is used to sign zone data, such as the SOA, NS, and A resource records found in a typical zone. By default, the ZSK has a rollover frequency of 90 days, and any zone resource records signed using the key have a signature validity of 240 hours. Key rollover and signature refresh are enabled by default on Windows Server 2012 DNS servers.

    • NSEC3 is used by default for providing authenticated denial of existence. The NSEC3 hash algorithm used is RSA/SHA-1 with 50 iterations and a salt length of 8.

    • Trust anchors are not distributed. A trust anchor is a preconfigured public key associated with a specific zone. The trust anchor enables DNS servers to validate DNSKEY resource records for the corresponding zone and establish a chain of trust to child zones, if any exist. Validating DNS servers must be configured with one or more trust anchors in order to perform DNSSEC validation. If the DNS server is running on a domain controller, trust anchors are stored in the forest directory partition in Active Directory.

  4. If the zone you signed is an Active Directory–integrated zone, private zone-signing keys now replicate automatically to all domain controllers hosting the zone through Active Directory replication. Each zone owner signs its own copy of the zone when it receives the key, as long as the zone owner is a domain controller running Windows Server 2012.

    Most of the key-management process is automated for DNSSEC in Windows Server 201. After the key rollover frequency has been configured for a zone using the Zone Signing Wizard, the key master automatically generates new keys and replicates via Active Directory. The zone owner rolls over keys and re-signs the zone, and secure delegations from the parent are also automatically updated within the same forest.

  5. At this point, the zone has been signed and contains the necessary RRSIG, DNSKEY, DS, and NSEC3 resource records to support DNSSEC validation:

    image with no caption
  6. When zone data is updated by a client sending a DNS dynamic update to an authoritative DNS server, that DNS server updates its own copy of the zone and generates the required signatures. The unsigned update is then securely replicated to all other authoritative servers, and each DNS server adds the update to its copy of the zone and generates the required signatures.

  7. Trust anchors must then be distributed to the DNS servers in your environment to enable the DNSSEC validation process to be performed by nonauthoritative (recursive or caching) DNS servers. If the DNS servers are running on domain controllers, trust anchors are stored in the forest directory partition in Active Directory and are replicated to all domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named TrustAnchors.dns and can be manually imported to these servers using the DNS Manager console or Windows PowerShell.

    For example, the standalone DNS server running Windows Server 2012 shown next displays its configured trust anchors in the DNS Manager console tree in the Trust Points container. Note that two DNSKEY trust points are displayed: one for the active key and one for the standby key.

    image with no caption
  8. Trust Anchor updates are then automatically replicated via Active Directory to all servers in the forest, and automated Trust Anchor rollover is used to keep trust anchors up to date.

  9. The final step in deploying DNSSEC is to ensure security between the nonvalidating DNS client (which can be computers running Windows 7, Windows 8, Windows Server 2008 R2, or Windows Server 2012) and their local DNS servers. The recommended way to do this is to use IPsec to protect the last mile between the client and its local DNS server. The DNS clients must also be configured to check that responses have been validated by their local DNS server, and this is done by configuring the Name Resolution Policy Table (NRPT) on the clients. The NRPT is a table that contains rules you can configure to specify DNS settings or special behavior for names or namespaces. The NRPT can be configured by using either Group Policy or Windows PowerShell.

Other -----------------
- Windows Server 2012 : Ensuring DHCP availability (part 3) - Managing DHCP failover
- Windows Server 2012 : Ensuring DHCP availability (part 2) - Implementing DHCP failover
- Windows Server 2012 : Ensuring DHCP availability (part 1) - Previous approaches to implementing DHCP availability
- Sharepoint 2013 : Managing Security - See Who Is a Member of a SharePoint Group
- Sharepoint 2013 : Managing Security - Grant Permissions to a File or List Item
- Sharepoint 2013 : Managing Security - See What Permissions Are Set (part 2) - Read the Permissions Page, Check the Permissions for a Specific User or Group
- Sharepoint 2013 : Managing Security - See What Permissions Are Set (part 1) - Check Permissions on Files and List Items
- Microsoft Exchange Server 2010 : Creating and Managing Accepted Domains (part 3) - Changing the Accepted Domain Type and Identifier , Removing Accepted Domains
- Microsoft Exchange Server 2010 : Creating and Managing Accepted Domains (part 2) - Creating Accepted Domains
- Microsoft Exchange Server 2010 : Creating and Managing Accepted Domains (part 1) - Viewing Accepted Domains
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
 
programming4us
Natural Miscarriage
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Game Trailer