Since DNS is a distributed database, there must be a mechanism to ensure that the data remains fresh in the nonauthoritative servers. When a resolver requests a record, it will store that information locally in case it is needed again. However, if it remains in the local cache, the primary, or authoritative, server may have been updated, and the resolver’s data becomes stale. There are timers, often called TTL or time to live, that tell the nonauthoritative servers how long to keep the data before requesting a refresh. For example, if the TTL is set for 1,800 seconds, then the resolver must go back every 30 minutes and request a refresh of the records to keep it from getting stale. The TTL values are sent from the authoritative to nonauthoritative servers when a DNS record is delivered.
Sites that make frequent changes would benefit from a short TTL so the clients receive accurate and updated information. However, if a site seldom changes, then a longer TTL would offer a higher level of performance since the DNS record data would be cached closer to the clients and the DNS servers would not have to take the time to refresh the cached data.
When resolving a DNS query, each DNS server that answers the queries needs a path to every zone in that namespace. Delegations provide this purpose. The delegation is a record stored in the parent zone that lists authoritative name servers at the next level down in the hierarchy. This allows for servers in one zone to direct clients to servers in other zones. For example, the root zones delegate to the .com servers below them, which in turn delegate to the company domain below them, such as tipofthehat.com.
Traditionally the basic Route 53 service did not implement any security and the DNS records traditionally sent data in the clear. This was the case since DNS was first used in 1983 to replace host files with a dynamic database for name resolution. To implement tighter security measures when using DNS, the Domain Name System Security Extension (DNSSEC) specification was developed in 2010 and was added to Route 53 in 2021. The Route 53 DNSSEC implementation can be enabled for all existing and new public hosted zones and for resolver validations to guarantee the authenticity and integrity of the DNS data. Security mandates from FedRAMP and others are adding encryption compliance requirements for DNS. DNSSEC is the tool that enables the security required under these mandates.
DNSSEC enables authentication for data origins and verification for the integrity of the data by using asymmetric digital signatures and the Public Key Cryptography (PKI) infrastructure. The data owner applies the cryptography to the actual DNS data and not the queries and responses.
Route 53 performs the crypto signatures on each record in its hosted zones. The key is managed by Route 53 and can be managed through the Key Management Services (KMS) of AWS. The Route 53 Resolver in each VPC guarantees that the DNS responses have not been tampered with during transmission. When a server does a recursive lookup, it will use the public key of the zone to validate the authenticity of the DNS data. This proves that the data was received from the actual zone where the DNS records are and not a fake or imposter zone. The data integrity part of DNSSEC confirms to the resolver that the data was not changed or tampered with in transit and that it was originally signed by the zone administrator using its private key.
Route 53 DNSSEC uses two types of keys. The first is the key-signing key (KSK), as shown in Figures 2.5 and 2.6. Each KSK is an asymmetric customer-managed public/private key pair that is owned by you and stored in the AWS Key Management Service (KMS) for your account. All KSK operations are your responsibility including rotating and replacing the keys as required. The zone-signing key (ZSK) is managed by AWS and will be transparent to your AWS administrators. The Route 53 hosted zones have a hard-coded TTL value for DNSSEC implementations of one week. Also, be careful with multivendor DNSSEC implementations to check if interoperability is supported with Route 53.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
