DNS namespace

DNS is a distributed hierarchical database composed mainly of computer name and IP address pairs. The entire DNS tree is called the “DNS namespace”.

standard zone VS Active Directory-integrated zone

Standard zone:

A zone that isn’t Active Directory integrated is referred to as a “standard zone”, and the zone store data in a text file. The text file named zone-name.dns in %systemroot%\system32\dns ” folder on the DNS server. The standard zones are used for Internet name resolution.

Type of standard zone:

  1. Primary
  2. Secondary
  3. Stub

AD-integrated zone:

When you are selecting the zone type in the New Zone Wizard, the “store the zone in the Active Directory” option means you want the zone to be stored in an active directory partition.

When you are storing the zone in Active Directory, the valid zone type options are primary and stub zones. If you select a secondary zone, the option to store the zone in Active Directory is disabled.

Recursive and Iterative

1. With a recursive name query , the DNS client requires that the DNS server respond to the client with either the requested resource record or an error message stating that the record or domain name does not exist. The DNS server cannot just refer the DNS client to a different DNS server.

Thus, if a DNS server does not have the requested information when it receives a recursive query, it queries other servers until it gets the information, or until the name query fails.

Recursive name queries are generally made by a DNS client to a DNS server, or by a DNS server that is configured to pass unresolved name queries to another DNS server, in the case of a DNS server configured to use a forwarder.

2. An iterative name query is one in which a DNS client allows the DNS server to return the best answer it can give based on its cache or local zone data. If the queried DNS server does not have an exact match for the queried name, the best possible information it can return is a referral (that is, a pointer to a DNS server authoritative for a lower level of the domain namespace). The DNS client can then query the DNS server for which it obtained a referral. It continues this process until it locates a DNS server that is authoritative for the queried name, or until an error or time-out condition is met.

This process is sometimes referred to as “walking the tree,” and this type of query is typically initiated by a DNS server that attempts to resolve a recursive name query for a DNS client.

Figure bellow shows an example of iterative and recursive queries. This example assumes that none of the servers have the requested information in their caches.

Cc961401.CNCC03(en-us,TechNet.10).gif

 

In the example shown in Figure above a client somewhere on the Internet needs the IP address of noam.reskit.com. The following events take place:

  1. The client contacts NameServer1 with a recursive query for noam.reskit.com. The server must now return either the answer or an error message.
  2. NameServer1 checks its cache and zones for the answer, but does not find it, so it contacts a server authoritative for the Internet (that is, a root server ) with an iterative query for noam.reskit.com.
  3. The server at the root of the Internet does not know the answer, so it responds with a referral to a server authoritative for the .com domain.
  4. NameServer1 contacts a server authoritative for the .com domain with an iterative query for noam.reskit.com.
  5. The server authoritative for the .com domain does not know the exact answer, so it responds with a referral to a server authoritative for the reskit.com domain.
  6. NameServer1 contacts the server authoritative for the reskit.com domain with an iterative query for noam.reskit.com.
  7. The server authoritative for the reskit.com domain does know the answer. It responds with the requested IP address.
  8. NameServer1 responds to the client query with the IP address for noam.reskit.com.
DNSSEC Terminology

DNSSEC is a suite of features and protocols for validating DNS server responses. DNSSEC provides DNS clients with three critical methods to ensure that data they receive from DNS queries is accurate and secure:

  1. Origin authentication of DNS data: verify that the DNS server replying to a query is authentic.
  2. Authenticated denial of existence: allows verifying that a resource record couldn’t be found.
  3. Data integrity: verifies that data hasn’t been tampered within transit.

Note that DNSSEC doesn’t provide confidentiality of data.

DNSSEC can secure zones by using a process called zone signing and uses digital signatures in DNSSEC-related resource records to verify DNS responses.

The DNSSEC-related records includes following:

Resource record type Description
Resource record signature (RRSIG) Signatures that are generated with DNSSEC are contained in RRSIG records. Each RRSIG record is matched to another record in the zone for which it provides a digital signature.

When a resolver issues a query for a name, one or more RRSIG records are returned in the response.

Next Secure (NSEC) An NSEC record is used to prove nonexistence of a DNS name. NSEC records prevent spoofing attacks that are intended to fool a DNS client into believing that a DNS name does not exist.
Next Secure 3 (NSEC3) NSEC3 is a replacement or alternative to NSEC that has the additional benefit of preventing “zone walking” which is the process of repeating NSEC queries in order to retrieve all the names in a zone. A DNS server running Windows Server 2012 or a later operating system supports both NSEC and NSEC3. A zone can be signed with either NSEC or NSEC3, but not both.
Next Secure 3 Parameter (NSEC3PARAM) The NSEC3PARAM record is used to determine which NSEC3 records to include in responses for non-existing DNS names.
DNS Key (DNSKEY) A DNSKEY resource record stores a public cryptographic key that is used to verify a signature. The DNSKEY record is used by a DNS server during the validation process.

DNSKEY records can store public keys for a zone signing key (ZSK) or a key signing key (KSK).

Delegation Signer (DS) A DS record is a DNSSEC record type that is used to secure a delegation. DS records are used to build authentication chains to child zones.

 

Zone signing uses public key cryptography, to secure a zone with a digital signature, a key master must be designed. Two keys must be generated:

  1. Key-signing key: a KSK has a private and public key associated with it. The private key is used to sign all DNSKEY records, and public key is used as a trust anchor for validating DNS responses. A trust anchor is usually the DNSKEY for the zone but can also be a DS key for a delegated zone.
  2. Zone-signing key: A ZSK is a public and private key combination stored in a certificate used to sign the zone. The KSK is used to sign the ZSK to validate it.

 

The DNS Security Extensions(DNSSEC) attach a special kind of information called cryptographic signatures to the queries and responses that let your computer detect false information. DNSSEC prevents the cyber criminal from hijacking your connection and from harvesting your confidential information.

Note, too, that DNSSEC is NOT only for the Web, but also can be used by any other Internet service or protocol. We’re already seeing interesting uses of DNSSEC with email (SMTP), instant messaging and voice-over-IP.

When a DNSSEC-aware recursive or forwarding DNS server receives a query from a DNS client for a DNSSEC-signed zone, it will request that the authoritative DNS server also send DNSSEC records, and then attempt to validate the DNS response using these records. A recursive or forwarding DNS server recognizes that the zone supports DNSSEC if it has a DNSKEY, also called a trust anchor, for that zone.

DNSKEYs are used to compute hash values and decrypt RRSIG records. The figure does not display all validation processes that are performed. Additional validation is also carried out to ensure the DNSKEYs are valid and that DS records are valid, if they exist (not shown above).

Validating DNS responses

When a client requests a resource record from a zone secured with DNSSEC, the following steps take place:

1.  A DNS client sends a query to the local DNS server configured in its network interface settings. If the client is DNSSEC aware, that information is included in the query message.

2. The local DNS server sends a query to a root server and top level domain Server, as necessary. The message contains information indicating that the DNS server is DNSSEC aware.

3. The local DNS server receives a response containing the IP address of a DNS server authoritative for the zone.

4. The local DNS server sends a query to the authoritative DNS server. The message indicates that the DNS server is DNSSEC aware and the server can validate signed resource records.

5. The authoritative DNS server returns the resource record information requested plus the RRSIG records needed to validate the response.

6. The local DNS server returns the response to the DNS client with an indication of whether the response was validated.

Configure DNSSEC
To sign a zone on DC1
  1. In the DNS Manager console tree on DC1, navigate to Forward Lookup Zones > DNS zone.

  2. Right-click DNS zone, point to DNSSEC, and then click Sign the Zone.

  3. In the Zone Signing Wizard, click Next, and then choose Use recommended settings to sign the zone.

    Sign the zone
  4. Click Next twice, confirm that The zone has been successfully signed is displayed, and then click Finish.

  5. Refresh the DNS Manager console and verify that a new icon is displayed for the DNS zone, indicating that it is currently signed with DNSSEC.

  6. Click the DNS zone and review the new resource records that are present, including DNSKEY, RRSIG and NSEC3 records.

More detailed steps to configure DNSSEC:

https://technet.microsoft.com/en-us/library/hh831411(v=ws.11).aspx

Test DNSSEC.

On a client machine, open Powershell, use cmdlet:

nslookup does not support DNSSEC.

resolve-dnsname FQDN -dnssecok

DNS Socket Pool

Normally DNS server use port UDP 53 to issue queries response. DNS socket pool is a pool of port number used by a DNS server for DNS queries. Each time a client issues a query, the DNS server randomize the source port, along with a random transaction ID.

Only windows server 2008 R2 or higher version support socket pool. The pool size is 2500 by default, you can increase the value to 10,000.

Use dnscmd to change the size:

dnscmd /config /socketpoolsize 5000

configure exclusive range:

dnscmd /config /socketpoolexcludedportranges start_number-end_number

DNS cache locking

Cache locking prevents any updates to a cached record until the TTL expires. So an attacker can not falsify update information.

cache locking is configured as a percentage of the TTL, if you configure the value to 60%, the cache can only be overwritten after 60% of TTL. If you set to 100%, the cache can never be overwritten.

Syntax: dnscmd /config /cachelockingpercent number

dnscmd /config /cachelockingpercent 60

Advanced DNS options

 

Recursion

For a iterative queries, DNS queries to a root server first, then to a TLD server, and finally to an authoritative server for the domain name being resolved.

For a recursive query, might involve a forwarder instead. Then the forwarder resolves the query and responds to the DNS server or performs a recursive query starting with a root server.

Two ways to change the recursion:

  1. Server node, right click  the server name and choose properties , open Forwarders tab, then tick “Use root hints if no forwarder are available”, so the recursion is enabled.
  2. Server node, right click  the server name and choose properties , open Advanced tab, then tick “Disable recursion (also disables forwarders)”, so the recursion is disabled.
Netmask ordering

Round-robin DNS returns a list of IP addresses in a different order for each query.

Netmask ordering is a DNS feature that causes the DNS server to order the list of addresses so that addresses with a closer match to the client making the query are returned at the top of the list. The closer match is based on the IP address of the DNS server, the servers with IP address in the same network with the client take precedence.

Windows bases netmask ordering on the first three octets of the client by default.

To verify this you can use command:

dnscmd /info /localnetprioritynetmask

If the Dword: is 255 (000000FF), the system is still using default setting. You can change this setting by following command.

use the Dnscmd /Config /LocalNetPriorityNetMask 0x0000FFFF command to use class B ( or 16 bit) for netmask ordering.

The following table lists other netmask ordering settings:

Netmask LocalPriorityNet
255.255.255.0 0x000000ff
255.255.0.0 0x0000ffff
255.0.0.0 0x00ffffff

Enable / Disable Netmask ordering:

The Netmask ordering is enabled by default. You can disable it by clearing the check box in the Advanced tab in DNS server’s properties dialog box or command line:

dnscmd /config /localnetpriority 0

Analyzing DNS zone level statistics

New feature in Windows Server 2012 R2. The Zone level statistics provides a detailed look at how a DNS server is used.

The following types of statistics are available for each authoritative zone on a DNS server:

  • Zone queries – show queries received and responded to successfully as well as failures.
  • Zone transfers – show zone transfers between primary and secondary zone servers. If a zone is AD integrated, no information is show.
  • Zone updates – show how many dynamic updates the server received and rejected.

Syntax: get-DnsServerStatistics -ZoneName FQDN

Example:

$zonestatistics = get-DnsServerStatistics -ZoneName frankfu.com

$zonestatistics.ZoneQueryStatistics    //show the query statistics on screen

$zonestatistics.zoneTransferStatistics   //show zone transfer statistics on screen

$zonestatistics.ZoneUpdateStatistics    //show zone update statistics on screen

Delegate administration

To give staff permission only on DNS related operation, the DnsAdmins group can be the choice.

The built in DnsAdmins group has read, write, create all child objects, and delete all child objects permission on the DNS server and DNS zones; has read and write permission on DNS resource records.

Best practice:

The DnsAdmin group is the security local group. So create a global group, add user accounts to it, and add the global group to the DnsAdmins group.

Reference

For  more info, check this page:https://technet.microsoft.com/en-us/library/jj200221.

https://technet.microsoft.com/en-us/library/hh831411(v=ws.11).aspx