1: What is DNSSEC?

The Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) used in IP networks.

DNSSEC is a set of extensions to DNS which provide DNS clients (resolvers) with source authentication, data integrity and authenticated denial of existence. DNSSEC utilizes a series of public/private key combinations to sign information resources, and provide a mechanism for the end user to verify the integrity of the DNS response.

In more basic terms, DNSSEC secures the DNS process. It protects from cache poisoning and other malicious DNS attacks. It works by providing a public key that allow the user’s resolver to check to see if the DNS answer provided, matches the cryptographic version of the answer. The user’s resolver will run the DNS answer through the public key (crypto) and see if there is a match between the original DNS answer and the results of decoding the signature file. There are other features, which are discussed in this FAQ.

Does Neustar UltraDNS support DNSSEC?

Yes, UltraDNS provides DNSSEC at no additional cost for UltraDNS customers. Neustar UltraDNS DNSSEC features auto-key signing and rotation. Neustar can also assist customers in converting or creating DNSSEC signed domains or zones. Neustar will also alert DNSSEC UltraDNS customers when a manual update is required, as there are a few customer responsibilities.

Does Neustar UltraDNS meet compliance requirements?

Yes, UltraDNS DNSSEC generally meets or exceeds DNSSEC compliance requirements. Neustar has security compliance consulting staff members who can assist with compliance related issues.

Note: Certain US Government Federal Agencies have DNSSEC compliance mandates such as:

Office of Management and Budget (M-08-23)

What if I’m using DNSSEC for my website; will non-DNSSEC users be able to reach it?

Yes, DNSSEC is backward compatible with non-DNSSEC resolvers, so DNS will still function and users will still be able to reach websites and other signed zones, only without the protection of DNSSEC.

What problem does DNSSEC solve?

DNSSEC solves several problems, including:

  • Cache Poisoning - or “man in the middle” attacks. Attackers can flood a DNS resolver with phony information with bogus DNS results. Sometimes these attacks get a match by the law of large numbers and plant a bogus result into the cache of the DNS resolver. The DNS resolver will provide this erroneous or malicious web address to anyone seeking that website for a period of time (TTL). This sends web users to malicious websites or website that are “evil twins,” looking like a legitimate website with the goal of stealing personal information or money from the unsuspecting user.
  • False zones – DNSSEC also protects from malicious DNS attacks that seek to exploit the DNS system and provide phony results for zones that don’t even exist, essentially exploiting the gaps in between zones. DNSSEC secures the entire zone and provides mechanisms to prevent the exploitation of gaps in unsigned zones. This is also known as authenticated denial of existence.

What is a “signed” zone?

First, let’s define a zone. A zone can be a variety of DNS records. One common example would be an A record for a website. The A Record contains a routable IP address. The user is directed to the website according to the IP address.

A “signed zone” is a DNSSEC secured version of the zone, such as the A record for a website. After the zone is fully created, it is run through a crypto-algorithm which creates an alpha-numeric signature that is unique for the contents of the zone, exactly the way it exists. This alpha-numeric hash is what is referred to as a ‘signature’ and the zone has been ‘signed’. Any change to the zone requires a new ‘signature’ to be created, as it will change with even the slightest modification to the original unsigned zone. Neustar UltraDNS provides a single click “resign” zone button.

How many organizations are currently using DNSSEC?

DNSSEC adoption has been slow, yet an ever growing number of organizations are using DNSSEC, mainly in the financial and government industries. Current adoption is less than 1%. (Jan 2012)

Certain US Government agencies are mandated to support DNSSEC.

What is required in order to run DNSSEC?

All components of the DNS resolving system must be DNSSEC “signed” or capable in order to receive a DNSSEC authenticated DNS response. These elements include:

  • The Top Level Domain (TLD) such as “.com” must be DNSSEC signed or compatible.
  • The Second Level Domain (SLD) such as “example” in example.com must be DNSSEC signed.
  • The end user’s DNS resolver must be DNSSEC capable.

All these elements must be in place, and working properly, in order to receive a DNSSEC authenticated response from the DNS system.

What is unique about Neustar’s DNSSEC offering?

Neustar has several unique features to offer DNSSEC customers including: automated DNS “signing” when adding or changing a DNSSEC record or adding a DNSSEC domain. Neustar also uses advanced crypto-algorithms with SALT added to provide an even higher level of protection from brute force crypto-decomposition techniques. (see definitions below for specifics)

What crypto algorithm does Neustar support?

Neustar uses RSA-SHA256 for the DNSSEC keys. For the key signing key (KSK), Neustar uses 2048 bit keys. For the zone signing key, Neustar uses 1024 bit keys. UltraDNS generates DS resource keys using both SHA1 and SHA256.

Will DNSSEC change the number of resource records in a domain?

Yes. For typical domains, DNSSEC users can estimate about three times (3X) the normal resource record count compared to an unprotected, unsigned version of the zone. For each resource record set (RRSET) with a unique hostname and RRYTPE, there will be one additional RRSIG resource record. For each RRSET of the same hostname there will be an additional NSEC3 record. If a domain has delegated subdomains that are secured with DNSSEC, there will be one or more DS resource records for each delegation, and RRSIG and NSEC3. All of these additional records add up to roughly 3X the normal record count.

Will DNSSEC increase my DNS query count?

Perhaps. For typical domains, it should be a negligible increase. For most domains, the querying nameserver will get secure validation information in the same response packet that it would without DNSSEC. However, there are additional concerns with DNSSEC that may change this behavior.

  • First, DNSSEC will increase the size of DNS responses. In some cases, the response packet may exceed the maximum transmission unit (MTU) of a device in the network path between the server and validating resolver. This may trigger the querying server to request an Answer again (for example, with a smaller EDNS0 buffer size or over TCP).
  • Second, low resource record TTL values mean that validation information is not cached, and must therefore be queried more frequently. This is the same effect of lowering a TTL record on a non-secure DNS record, but has a greater impact because validation data may be requested.
  • Finally, a domain with multiple delegated subdomains may be subjected to increase query load due to remote resolvers looking for validation information of the subdomains through the chain of trust.

What TTLs are recommended for use in a DNSSEC deployment?

ANSWER: This is a complicated question as it involves tradeoffs. The IETF recommendations can be found here:

http://www.ietf.org/rfc/rfc4641.txt

= excerpt =
Kolkman & Gieben             Informational                     [Page 12]

RFC 4641              DNSSEC Operational Practices        September 2006


	Re-signing a zone shortly before the end of the signature
	validity period may cause simultaneous expiration of data from
	caches.  This in turn may lead to peaks in the load on
	authoritative servers.

	o  We suggest the Minimum Zone TTL to be long enough to both fetch
	and verify all the RRs in the trust chain.  In workshop
	environments, it has been demonstrated that a low TTL (under
	5 to 10 minutes) caused disruptions because of the following two
	problems:

		1.  During validation, some data may expire before the
		validation is complete.  The validator should be able to
		keep all data until it is completed.  This applies to all
		RRs needed to complete the chain of trust: DSes, DNSKEYs,
		RRSIGs, and the final Answers, i.e., the RRSet that is
		returned for the initial query.

		2.  Frequent verification causes load on recursive nameservers.
		Data at delegation points, DSes, DNSKEYs, and RRSIGs
		benefit from caching.  The TTL on those should be
		relatively long.

What is an RRSIG record?

RRSIG is a resource record signature, a unique hash that is associated with every resource record or sets of like resource records. It is used to verify that the actual Resource is legitimate and has not been changed. The private key/public key system verifies that the RRSIG is legitimate and thereby validates the underlying resource record.

What is an NSEC record?

Next secure – this is a record used to secure the “gaps” or spaces between valid DNS information. The basic purpose of the next secure or NSEC record is to define which records/answers are NOT present in the DNS zone, so that the querying server can validate that an answer should not exist. It protects against a malicious response to a question which does not have a valid answer in the DNS zone. It specifies the next record and the owner of that record, thereby preventing gaps in the zone from being exploited. An NSEC record appears at the end of each RR set. Neustar supports NSEC3, which provides the same security as NSEC, with the addition of hashes of the domain names so that it is difficult to enumerate every host within a domain.

Does DNSSEC encrypt the DNS responses?

No, DNSSEC does not encrypt the DNS response; it only adds an encrypted signature that is verified by use of the unique public key/private key system. This provides assurance that the Answer is valid and not spoofed by a malicious 3rd party.

What are the secure key rollover periods?

Zone signing keys (ZSK) are automatically rolled every 90 days by UltraDNS without user intervention.

Key-signing keys (KSK) are scheduled to roll annually, and UltraDNS will alert the user that a manual key rollover is recommended. UltraDNS schedules a KSK rollover, notifies the customer when the schedule has arrived and provides the steps necessary to complete the process. However, the system will not take any action without customer approval.

RRSIGs are regenerated automatically every 30 days by UltraDNS, without customer intervention.

What are DS resource records?

Delegation Signer or DS resource records are hashed versions of the public key (KSK) that are passed up the “chain of trust.” Normally, after a DNSSEC DNS zone has been signed, the DS RRs are sent to the registrar. They are used to verify that the public key is legitimate.

What is a hash?

A hash (sometimes called a digest) is an alphanumeric representation of a larger message, such as a public key or a resource record. Hashes have important properties that prevent them from being deciphered or reverse engineered. If the original message is changed in any manner, it will deliver a totally different hash. Hashes are used in DNSSEC as a way to verify that the original message or key has not been altered.

Note: Neustar uses the SHA1 algorithm to create hashes.

What is SALT?

SALT is a method of purposefully adding characters to a hash or other key, to make it more difficult for someone to spoof the originating key by brute force or otherwise. Neustar uses system generated SALT to protect its key and hash systems.

Why do the DS Records need to be submitted to the registrar?

The DS Records need to be submitted to the registrar to establish the ‘chain of trust.’

The DS Records allow for the authentication of the public key.

What is the “chain of trust?”

The chain of trust is a cascading series of public key hashes that are used by DNSSEC to verify the validity of the public key. These DS records are passed down through the series of DNS responses starting with the root server, to the TLD to the Authoritative server. In each case a DS record containing a hash of the lower level public key is passed down, hence the name ‘chain of trust.’

What is a “stub resolver?”

A stub resolver is generally a browser such as IE or Firefox that contains its own cached DNS answers. It will always check this cache for a DNS answer, before going to the recursive server with a DNS query.

Do I need a special web browser to use DNSSEC?

No, DNSSEC is not a function of the browser. However if you want your browser to indicate if DNSSEC has been used to connect to a website, then you will generally need to add a ‘plug in’ software patch to add DNSSEC indicators to the browser.

Example: Mozilla Firefox has an available software “plug in” that creates a DNSSEC capable browser.

https://addons.mozilla.org/en-us/firefox/addon/dnssec-validator/

Note: Your ‘Recursive Server’ also needs to be DNSSEC enabled, along with the website you are attempting to reach.

How can I tell if my browser is connected to a website using DNSSEC?

In the case of Firefox, a small “green key” symbol will indicate if DNSSEC has been used to verify the DNS response.

DNSSEC Key Screenshot of browser showing an image of a key before start of url

You can also go to the following website to test if you’re DNSSEC capabilities are working.

http://www.dnssec-failed.org/

This website can tell you if a particular domain is DNSSEC signed.

dnssec-debugger.verisignlabs.com/

What happens if I forget and my keys expire?

Nothing. Keys do not expire, they may be used indefinitely. Typically you will want to change them periodically, but there is no hard requirement.

What are the “best practices” for key management?

IETF documents currently recommend changing the zone signing key several times a year and the key signing key less frequently, but frequent enough to keep operational practice updated. By default, UltraDNS will rotate the ZSK every 90 days and the KSK annually. (see above for more information about ZSK & KSK rollover)

What do I need to prepare to “sign” a zone?

First check to see if your TLD is signed. Most common TLDs and popular ccTLDs are already signed; however, if they are not signed you may have to take different steps to secure your zone with DNSSEC.

Confirm if your domain registrar can support DNSSEC, specifically, do they allow you to give them delegation signer (DS) DNS resource records? (This is an important feature to verify, but one of the last steps in the process of adding DNSSEC to your zone.)

Decide on an approach for DNSSEC appropriate to your organization and governing polices. For example, there may be policies or requirements on how to maintain and secure private keys (e.g. some U.S. federal agencies have internal and govt mandates that may affect policy).

Can Neustar help me “sign” my zones?

Yes, Neustar can work with UltraDNS customers to convert existing zones into DNSSEC signed zones.

How does Neustar allow me to manage my DNSSEC zones?

Neustar offers several approaches to adding DNSSEC to domains. UltraDNS offers support for DNSSEC key management and zone singing through the Neustar customer portal, a web based UI. You can also manage UltraDNS zones (including DNSSEC zones) via a SOAP API.

Neustar also offers UltraDNS as a DNS secondary if you would prefer to manage your own keys and zone signing on your own hardware. Neustar also offers custom solutions if the first two do not meet your requirements.

Note: The UltraDNS mobile apps do not currently support changes to DNSSEC zones.

Can I use UltraDNS advanced features, such as the SiteBacker automatic failover solutions or directional load balancing, with DNSSEC zones ?

Neustar has plans to make advanced features such as SiteBacker, Traffic Controller and Directional DNS available to DNSSEC zones. These updates are coming shortly.

I signed my zone, but made some changes. Now I see a button saying “re-sign” zone. Why is that necessary ?

Any changes to a zone will need to be resigned. Because the underlying resource has changed, the hash or signatures for that resource also need to be updated to reflect that change, as they are all unique. Neustar automatically queues up changes made to DNSSEC zones, so the customer can “resign” them all at once, saving computing cycles and burden on updating DNS systems. Once you have made all your changes, you must hit “resign” to have those changes propagated along with the updated cryptographic signatures.

If I signed a zone using DNSSEC, is there a reason to “un-sign” it?

Generally not, as DNSSEC is a “set and forget” technology. DNSSEC is also backward compatible with non-DNSSEC users, so they should still be able to reach a DNSSEC signed resource (like a www A record) without the protections of DNSSEC. Neustar does provide an “un-sign” option within the UltraDNS Customer Portal.

Acronyms:

  • DNSSEC – Domain Name System Security Extensions
  • DS – Delegation Signer
  • KSK – Key Signing Key
  • NSEC – Next Secure
  • RRSIG – Resource Record Signature
  • ZSK – Zone Signing Key