Best practices for protecting your domain

As a Fastly customer, you trust us to protect your traffic, and we offer several TLS features to protect traffic coming into Fastly, and from Fastly to your origin. As recently covered by Director of Security Research Jose Nazario, Fastly’s footprint and features can help protect against various types of attacks, and we continuously work on making the edge more secure, developing features you can leverage to protect your applications. However, in order for you to truly benefit from these features, there are steps you should take at the crucial stage where traffic is handed off to the CDN.

This blog provides some best practices for protecting your domain name and DNS resolution while traffic finds its way across the internet to the Fastly CDN.

Protecting your domain registration

A domain name is typically registered with a registry – an organization that operates the top level domain name, for instance, .com. The registration is performed by a registrar, the company where you purchase your domain name. Once the name is registered, you tell your registrar to allocate name servers to the domain in the registry’s database. Those name server operators are then the authoritative sources of information for where your website or application can be located.

You may be surprised to hear this, but it is not uncommon for an attacker to hijack a domain name by abusing one of the organizations involved in operating it.

At any of these organizations, an attacker could leverage social engineering or web application vulnerabilities to compromise an account, and use the privileges of that account to redirect traffic intended for your domain. Domain hijacking has affected many large sites in the last few years, and even some top level domains. For instance, in a widely published registry hijack in October of 2012, many major Irish sites, including Google.ie and Yahoo.ie, were redirected to fraudulent pages.

In order to mitigate this risk at the registry level, many registries have built technologies that harden the process of modifying your domain name. In the case of .com, this technology is called Registry Lock. By enabling it on your domain, an authorized individual at the registrar must personally contact the registry to request the domain to be unlocked prior to a modification taking place. This prevents a fully automated attack, where a single web application vulnerability at the registrar or registry would allow an attacker to make a modification.

For .com, and many more registries which use a similar implementation, you can check if Registry Lock is applied by checking the following flags in the whois output for your domain:

$ whois "=fastly.com"

Domain Name: fastly.com
…
Domain Status: clientUpdateProhibited (https://www.icann.org/epp#clientUpdateProhibited)
Domain Status: clientTransferProhibited (https://www.icann.org/epp#clientTransferProhibited)
Domain Status: clientDeleteProhibited (https://www.icann.org/epp#clientDeleteProhibited)
Domain Status: serverUpdateProhibited (https://www.icann.org/epp#serverUpdateProhibited)
Domain Status: serverTransferProhibited (https://www.icann.org/epp#serverTransferProhibited)
Domain Status: serverDeleteProhibited (https://www.icann.org/epp#serverDeleteProhibited)

If you just see the client flags above (meaning, you see no server flags), it means that your name is only locked at the registrar, but not between registrar and registry. While adding registry lock may incur an additional cost, and not every registrar may support it, if your traffic is important to your business, it’s well worth the investment.

Ensuring you have appropriate security controls in place is very important to make sure traffic is directed accurately. Techniques such as two-factor authentication and restricting management access to your corporate IP ranges can help ensure the infrastructure is robustly managed.

Protecting domain name resolution

Availability of your name servers

As part of migrating to Fastly, many customers choose to deploy a CNAME record pointing to a Fastly hostname, enabling an easy integration with our infrastructure. In this case, customers operate their own Domain Name System (DNS) or use a service provider. While most DNS service providers focus on reliability, if you operate your own DNS, there are a few things to keep in mind:

• Distribute your authoritative name servers. Fastly is focused on ensuring that your application remains available, and our global network allows us to do so even if a single network provider fails. However, sometimes we see customers who deploy their name servers within a single network. In order to avoid a single network outage from affecting your availability, ensure that your authoritative name servers are distributed across several network providers. It’s helpful to have multiple name servers (and even mandatory in some top-level domains, such as .org), and standards describe anywhere between three and seven as a good number.  

  DNS service providers often use technologies such as Anycast, which advertises the same IP prefix from many locations, to ensure high availability, low latency, and strong DDoS segmentation of these critical assets.

• Use hidden master name servers. Some organizations choose to deploy a so-called “hidden master” name server, and deploy all publicly visible name servers as secondaries. This enables you to maintain a single, secure authoritative server which only allows limited traffic and does not interact with actual clients. The only hosts on the internet that the authoritative server is allowed to communicate with are its downstream secondary name servers. This limits your exposure to "packet of death" vulnerabilities in DNS server implementations, and prevents your hidden master from being fingerprinted as a DNS server by people (white hats, black hats) who are constantly scanning the internet for DNS servers.

Should all secondaries fail, it is relatively easy to set up additional ones and configure them to refresh from the master, which is not affected by the attack.

Don’t perform recursion for the world

Fastly often sees DDoS attacks, many of which actually involve the illicit use of the DNS protocol. It’s not uncommon to find DNS servers which are misconfigured to perform recursion for public internet addresses. Recursion is a valid name server feature that allows a single name server to provide DNS resolution for a set of clients. However, due to convenience or error, it was historically often enabled on name servers which are in fact intended to be authoritative for a more limited set of domain names.

As most DNS queries are UDP, which is trivially spoofable, an attacker can generate DNS requests to such name servers, claiming to come from a legitimate application. As the DNS query is most commonly smaller than the response, this leads to a so-called “amplification attack,” where even a small amount of attack traffic can generate very large responses to the victim application — a distributed denial of service attack.

This affects both the application owners, who may experience an outage; their network providers, who need to mitigate; and the DNS server owner, who may see some performance impact. Disabling recursion, or limiting it to a restricted set of clients, is the right thing to do for most authoritative name servers.

Luckily, recursion is disabled by default in recent versions of BIND, a very common name server. So making sure you are running up-to-date software, with a secure, well-vetted configuration, is important. There are several organizations that outsource the delivery of DNS choices, and for many users they may be a good choice.

Deciding on an appropriate time to live (TTL)

Setting an appropriate TTL for your domain is as much art and experience as it is science. The TTL, which can be set per DNS resource record, defines how long the result of a query remains valid, until it expires and the client will need to perform a new lookup.

Having a high TTL value typically increases performance, as the client will keep the response cached for a longer amount of time, and visiting the application won’t incur an additional DNS lookup. In addition, it reduces load on the backend name servers. However, when a problem occurs, for instance a server fails or is out of service, a high TTL value limits your ability to change the IP address the record points to. It reduces your flexibility, and if you change the IP address in a rush, users are out of luck while you wait for their cached results to expire.

In principle, if your DNS record is intended to be very robust, for instance a CNAME to its Fastly map, having a higher TTL is acceptable. When you plan to make modifications frequently, or have less confidence in a backend application, it’s recommended to keep a shorter TTL. For fastly.com, we have our TTL set to one hour (3,600 seconds). For customers using a Fastly hostname, you will see that the TTL is set to 30 seconds so that we can react quickly to network outages and load conditions by directing requests to an alternate, nearby data center.

If you’re not currently using a CDN, and you fear that during a DDoS attack you may need to change over to other infrastructure quickly, we’d recommend considering a lower value. When you make that switch, that TTL value is the maximum length of time your application will be served inconsistently while clients reconverge on the new IP address.

Using a managed DNS provider

Using a third party may offer additional security benefits above what can be typically accomplished with one’s own DNS servers. For example, managed DNS providers offer robust global anycast networks with redundant data centers, internet connections, and name server infrastructures. Some managed DNS providers run diverse name server technologies like BIND and NSD to diversify from software bugs. Many DNS providers have extensive DDoS mitigation systems to protect the DNS. Further, like registries, these services offer the protection of two-factor authentication and IP access list controls to management portals.

In a future blog post, we’ll explore some interesting technologies and records you can set to make your organization’s overall internet experience more robust, such as DKIM, SPF, DMARC and CAA, and keep an eye on our security blog for the latest updates.