What Is Needed to Perform Secure Dynamic Updates?

Secure Dynamic DNS

By virtue of information technology being dynamic, Dynamic DNS (DDNS) is designed for ease of administration. Clients register themselves and update their records whenever they receive an IP address from Windows Server 2003 DHCP. If yous are the administrator of a DNS zone, the last thing yous want is to take a agglomeration of unauthorized clients polluting the zone with unwanted resource records. This situation volition add to your frustration levels, not to mention your workload, for cleaning out these DNS infidels. Fortunately, Windows Server 2003 DNS and its Windows 2000 Server predecessor have the "Scavenge Old Records" utility so that resource records of a sure age can be eliminated with a single click. This is great for old records, simply what tin be washed before these records have reached their expiration date? Windows Server 2003 DNS has the answer: Secure DDNS.

Secure Dynamic Update is available only for Active Directory-integrated zones. If the target DNS zone is not Active Directory integrated and yous desire to implement this characteristic, you must modify the zone type to Active Directory-integrated before attempting to run whatever of the procedures described later. Secure Dynamic Update is non available for servers running Windows Server 2003, Web Edition.

The trouble arises when unauthorized clients register with DDNS. If a large number of these clients are registered with a given zone, the zone database increases in size and the speed for DNS queries decreases. Secure DDNS avoids

Continued this by requiring an update of the DNS record by an authorized DHCP server. When the Windows Server 2003 DHCP Server service is authorized in an Active Directory-integrated zone, information technology has total control of all DNS zones and records. As a event, the DHCP Server service can update or delete any DNS tape that is registered in a secure Active Directory-integrated zone. When an unauthorized client attempts to register itself through DDNS, the DHCP Server tin can simply overwrite that record in DNS. Only clients joined to the domain and with a valid Kerberos ticket can perform Secure DDNS updates. If a DHCP server is to perform this task, it must be a fellow member of the DNS Proxy group.

To configure Secure Dynamic Updates from the DNS Snap-In in MMC:

1. Open the DNS snap-In in MMC.

2. In the console tree, correct-click the target DNS zone and click Properties.

iii. On the Full general tab, ensure that the zone type is Active Directory-integrated.

four. In the Dynamic Updates section, click Secure only, as shown in Effigy v.five.

Figure five.5 Configuring Secure Dynamic Updates

Figure 5.5 Configuring Secure Dynamic Updates

To configure Secure Dynamic Updates from the command line:

1. Open a Command Prompt window.

2. Blazon 'dnscmd [ServerName] /Config {[ZoneName] -or-[..AllZones]} /AllowUpdate 2', for example "dnscmd nameserverl /Config{vanc.nru.corp} /AllowUpdate ii"

Continued

All elements of this string are required. 'dnscmd' is the name of the command-line program. This is followed by ServerName (the host name or the IP address of the target DNS server), or a dot (.) if you are running dnscmd locally on the target DNS server. The /Config switch specifies that the command will alter the configuration of the server. At this point, you tin enter the ZoneName that you want to secure or you can type '..AllZones' to secure all Active Directory-integrated zones hosted on the target DNS server. The fully qualified domain name (FQDN) of the target zone must be entered as the ZoneName. /AllowUpdate ii triggers the re-configuration of the target DNS server to let Secure Dynamic Update. If the '2' is omitted, the target DNS zone will exist set to perform standard dynamic updates only.

In Windows Server 2003, Microsoft has taken the concept of dynamic DNS updates a step further. When a DNS zone is integrated with Agile Directory, information technology has the added reward of potentially utilizing secure dynamic updates. When DNS is configured to employ secure dynamic updates, but computers that take been authenticated to the Active Directory domain can perform dynamic updates. In Windows Server 2003, dynamic DNS updates are disabled past default when standard zones are used. Nevertheless, when a zone becomes an Agile Directory-integrated zone, secure dynamic DNS updates are turned on past default. If you lot want to allow clients to be able to apply non-secure DNS updates on a Windows Server 2003 DNS server (using either standard or Agile Directory-integrated zones), you need to enable this selection manually using the 'Nonsecure and secure' setting (come across Figure 5.five).

Note_

Call up that dynamic updates can be configured merely equally 'secure only' for Active Directory-integrated zones.

The DNS Security Extensions Protocol

The last topic that we hash out in this section is Microsoft's support for the DNS Security Extensions (DNSSEC) protocol. DNSSEC is a set up of extensions to DNS that adds the capability to authenticate resources records and was designed to protect the Net from certain attacks. DNSSEC uses public key cryptography with digital signatures to provide a process for a requestor of resources information to authenticate the source of the information. DNSSEC offers reliability that a query response can exist traced back to a trusted source, either straight or through a bureaucracy that can extend all the style to the parent DNS server.

In DNSSEC, a DNS zone has its ain public and private key pair that is used to encrypt and decrypt digital signatures. DNSSEC works by adding three additional record types into DNS—NXT, KEY and SIG—that will be used for authentication:

■ The NXT fundamental is used for creating a chain of certificate owners and for listing the resource records that non be for a particular zone.

■ The Primal record stores the public key information for a host or zone.

■ The SIG tape stores a digital signature associated with each set of records.

When a resource record in a zone is signed using a private cardinal, DNSSEC-aware resolvers containing the secured zone'due south public key can determine whether resource information received from the zone is authentic. If a resolver receives an unsigned record fix when information technology expects a signed one, information technology determines that there is a trouble and therefore volition not accept the information that has been retrieved. A typical DNSSEC-enabled query occurs as follows:

1. Offset, the resolver must query the root server using the root server'due south public fundamental (which is well known) to find out the DNS server that is authoritative for a particular zone as well as the public key for that zone.

2. The resolver and so sends a DNS query to the authoritative server for the zone for which it had requested the public primal in Step 1.

3. The DNS server receives the query and responds to the resolver with the requested information also equally the SIG record that corresponds to the DNS zone.

4. The resolver receives the resource record as well every bit the SIG tape and authenticates the resource record using the known public cardinal (which was obtained in Step 1).

5. If the resolver can cosign the resource tape and SIG, it will accept the resource record data. If information technology cannot cosign the information, information technology will discard it.

You might be asking yourself what happens if a DNS server does not take a resource record for a particular query in its database. For this purpose, a third type of record has been added to DNS as office of the DNSSEC implementation: the NXT (next) tape. When a DNS server responds to a query that it does non accept a matching tape for, the DNS server sends a NXT record. The NXT record contains the proper noun of the side by side DNS entity that exists in the zone too equally a list of the types of records (NS, SOA, MX, and others) nowadays for the current name. The purpose of the NXT record is to non but inform the requestor that a particular resources record does not be, but it besides prevents the DNS server from becoming a victim of a replay attack. In a replay assault, a third party that is sitting between the two replays data to the second party that it has previously received from ane of the parties.

NXT records thwart replay attacks by verifying the guild in which certificates were signed. The NXT record contains the name of the side by side tape that exists inside a zone. From our example, the following records exist in the vanc.nru.corp domain:

■ omega.vanc.nru.corp

■ zeta.vanc.nru.corp

Frank, who is a very unhappy instructor at Name Resolution Academy, is familiar with the concept of a DNS replay attack. Frank makes a request to a DNSSEC-enabled DNS server for the resource record of kappa.vanc.nru.corp. Since this host does not exist in our table, Frank is sent an NXT record for delta.vanc.nru.corp, since information technology is the record simply prior to where kappa would exist. This NXT record contains the name of the side by side existing server in the zone, which is omega.vanc.nru.corp.

Frank decides that he wants to cause a little havoc in the Phoenix office. He performs a replay attack on a fellow teacher, Karen. Karen sends a query to the same DNS server for the IP address of alpha.vanc.nru.corp. Earlier the DNS server can answer to Karen's query, Frank sends his stored NXT tape to Karen. Since the NXT record was signed by the DNS server, Karen's estimator verifies the record as authentic. However, when Karen'south computer views the NXT record, it sees that the NXT record is that of delta.vanc.nru.corp, and since alpha does non autumn between delta and omega, Karen'southward reckoner can assume that the record is invalid and discard information technology.

To acquire more about DNSSEC, visit www.dns.net/dnsrd/rfc/rfc2535.html, which is the original RFC on DNSSEC.Yous might also want to check out www.dnssec.cyberspace, which is a great portal for Spider web sites related to DNSSEC.

Using DNSSEC

Equally far as Windows Server 2003 support for DNSSEC, we have some good news and some bad news. Beginning, the bad news: it does not support all the features listed in RFC 2535.The skillful news is that information technology does encompass "basic support" for DNSSEC every bit described in RFC 2535.The basic support functionality as described in the RFC states that a DNS server must possess the capability to store and call up SIG, Central, and NXT resource records. Any secondary or caching server for a secure zone must have at to the lowest degree these basic compliance features.

Server Support

Considering Windows Server 2003 meets only the basic back up functionality for DNSSEC, it can be configured to operate but as a secondary DNSSEC-enabled DNS server. This means that a Windows Server 2003 DNS server cannot perform such functions as signing zones or resource records, or validating SIG resource records. When a Windows Server 2003 DNS server receives a zone transfer from a DNSSEC-enabled DNS server that has resources records, it writes these records to the zone storage as well as the standard DNS resources records. When the Windows Server 2003 DNS server receives a request for a DNSSEC resource record, it does not verify the digital signatures; rather, it caches the response from the primary server and uses it for future queries.

Customer Support

In Windows Server 2003 (and Windows XP Professional), the DNS client cannot read or store a cardinal for a trusted zone, nor can information technology perform authentication or verification. When a

Windows 20003/XP client initiates a DNS query and the response contains DNSSEC resource records, the DNS client returns these records and caches them in the same fashion equally whatever other resource records. All the same, at the time of this writing, this is the maximum corporeality of support that Windows Server 2003 and Windows XP clients have for DNSSEC.

Continue reading here: DNS Servers

Was this article helpful?

edsonloiced.blogspot.com

Source: https://www.serverbrain.org/designing-infrastructure-2003/secure-dynamic-dns.html

Share this post