Enterprise Hosting provides DNSSEC services for .com, .biz, .gov, .net, .us, .info and many other domain extensions. DNSSEC Services are provided as low as $50 per year per domain. Contact us for further details.
What is DNSSEC?
DNS is one of the foundations of the World Wide Web. Like many early Internet standards, it was designed before security had become a concern. It was simple, fast, and reliable – but not secure. Since then, attackers have found reasons to spoof DNS responses.
Phishing scams or other attacks may want to redirect users to a fake site, and by sending a fake DNS response they can send users to their server instead of yours.
DNSSEC adds a layer of security, and allows you (and your customers) to verify:
1. The server that responded is who they say they are
2. The response has not been tampered with
What do I need to implement DNSSEC?
DNSSEC requires four items:
– Your DNS provider’s servers must support it
– The local resolver (usually your ISP) must support it
– The zone (domain) must be signed
– The root of the zone (.com, .org, .gov, etc.) must know that it has been signed
How does DNSSEC work?
DNSSEC uses a pair of encryption keys to sign each zone using something called public key encryption. One key (the private key) is used to encrypt a signature for each record, and the other (the public key) is used to decrypt it. The public key is published by the DNS server as a DNSKEY record. It cannot be used to derive the private key, which is kept secret by the authoritative nameserver.
Whenever DNSSEC aone is created or updated, an RRSIG record is created for each resource record (A, AAAA, MX, etc.). The RRSIG is created by encrypting a digest (or hash) of the record. When the server receives a DNS query, it sends back both the requested record and the RRSIG. When the resolving server receives them, it then requests the public key to decrypt the signature and makes its own hash of the resource record. Finally, when it has the public key, it decrypts the signature and both digests to make sure they match.
Since an attacker could spoof a keypair along with the rest of the response, one more step is used to establish a “chain of trust”. When the zone is first signed, another type of record called DS records are sent to the zone root, which publishes that information. This is published along with the authoritative nameservers information as part of the whois information for the domain.
When you or your ISP set up a secure resolver, the setup includes signatures for the root servers. Because they are not changed by the running resolver, they are considered secure and used as a “Trust Anchor”. When the resolver queries the root servers for a domain’s authoritative nameservers, it uses these keys to validate the response, which includes information on whether or not the domain is signed. If it is, then the server will only accept signed responses for the domain – unsigned responses from any DNS server for that domain will be ignored. It also receives the hashed key for the next server in the chain. It uses this signature to verify the responses it receives from each server in the chain that leads to the authoritative servers.
As an example, let’s see what would happen if we were looking up www.example.com. The resolver would query the root servers for the addresses of the .com nameservers. The root server sends back a signed response with the address of the .com server and a hash of the .com key.
Next, the resolver checks the .com servers for the list of authoritative nameservers for example.com. The servers might send back a response that ns1.enterprisehostinginc.com is authoritative, along with the hash of the example.com key.
Last, the resolver queries ns1.enterprisehostinginc.com for the www.example.com record. The response is validated against the key sent by the .com servers.
Since the keys are verified at every step, the resolver knows that the final response has been sent by a trusted server. The hash of the record proves that the response has not been tampered with, and the user can be sure that they are being sent to the site or host they requested.
“Domain Name System SECurity protocol” (DNSSEC) is an extension that provides an added security layer to the DNS protocol.
The “Zone Signing Key” (ZSK) is stored on the authoritative nameserver and used to sign resource records (A, AAAA, MX, etc.). Because this key must be kept short for fast responses, it should be changed frequently. We update keys for our Managed DNS customers on a monthly basis.
The “Key Signing Key” (KSK) is also stored on the authoritative nameserver. It is a longer, more secure key which is used to sign the Zone Signing Keys. This allows the Zone Signing Keys to be changed frequently without updating the zone root.
The “Delegation Signer” (DS) key is stored by the zone root, and used to validate responses from the authoritative nameservers for a zone.
The “Resource Record Signature” (RRSIG) record includes such things as the type of resource record being signed, the encryption algorithm used, the signature itself, and expiration information. They are returned along with the record being signed.
The “Next Secure” (NSEC) record is a signed record that is returned to specify domains that do NOT exist. It specifies a range of domain names that are invalid. It is returned at the end of each RR set.
I’m very pleased with Enterprise Hosting’s high availability environment and responsiveness. No matter what time I call, day or night, I can get a response in mere minutes for my urgent issues. That’s invaluable to my business.
As a provider of online training content, we needed a hosting provider with a robust cloud infrastructure, zero down time and a support team that is knowledgeable and responsive. Enterprise Hosting has exceeded our expectations.