DNS and DNSSEC

6-minute read
AWS • Certification • Basic • DNS • DNSSEC • SA-PRO

What is DNS?

Phone Book

Phone Book

At the base level, DNS is an old-style phone book for the internet. When we want to visit a website like google.com, before our browser can make the request, it needs to know the IP address associated with google.com. To do this, it looks it up in DNS. This lookup is similar to finding a name in an old phone book for those of you who remember those.

In the case of DNS, though, the process is entirely transparent to the user. When you make that request to google.com, your computer looks up the IP address and forwards your request to that website. In the case of google.com, it would look up an A record. You can see this A record using a tool like dig.

➜  ~ dig google.com A

; <<>> DiG 9.10.6 <<>> google.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22473
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		188	IN	A	172.217.0.174

;; Query time: 0 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: Sun Jan 01 15:58:46 CST 2023
;; MSG SIZE  rcvd: 55

Note in the above output that we are looking up an A record, and the answer section returns 172.217.0.174. This response means that when you request google.com, you ask for that IP address.

DNS Terms

  • Zone: Domain containing records
  • ZoneFile: File storing the Zone on a disk
  • Name Server: A DNS server that hosts one or more zone files
  • Authoritative: Indicates the Name Server responding has authority over the Zone and can answer for it definitively.
  • Non-Authorative: Indicates the information returned was from a copy/cache of the zone file.

Architecture or Hierarchy

DNS is made up of a hierarchical network of servers at various levels. This system distributes the workload and provides a way for individual domain owners to manage their DNS records without needing approval or waiting for registrars to make the changes for them.

At the top of the DNS hierarchy is the root servers. On the hardware side, these servers are managed by independent organizations (large businesses). These servers can be reached through thirteen publicized IP addresses (though there are many more physical servers behind the scenes than this). IANA maintains the actual records on the servers at this level.

The records in the root zones contain information on the TLDs (e.g., COM, .NET,.ORG,.US,.WEBSITE,.UK, etc…). IANA delegates the management of the TLDs to registries. An example of this is VeriSign manages the .COM TLD. In the root zone, there are records for each TLD that point to the servers for the TLD zones.

When a buyer registers a domain at a registrar, the registrar informs the registry of the purchase. Then, the domain is placed in the TLD zone with records pointing to the name server for the newly created domain. This record is the NS record. The same happens if you change the NS records - the registrar tells the registry what nameserver to point to for your domain.

Once we have the name server record for the domain, we query it to find the host we are looking for. In this case, the host is just the domain’s root, so the A record is returned for that host.

The reasons for the hierarchical design over a simple database or set of databases are:

  • Security - If we had one master DNS server on the internet, it would be the target of bad actors attempting to change the DNS entries and undermine the security of the internet infrastructure.
  • Scaling & Volume - The DNS system services nearly every request on the internet. It also has hundreds of millions of records, if not more. Trying to handle that kind of load and that volume of data would be too much for any single server. It would put the entire internet at risk.

DNSSEC

DNSSEC provides data origin authentication and data integrity protection. It establishes a chain of trust between the DNS root and the DNS records. It does this using public key cryptography.

DNSSEC is an addon to regular DNS queries - if a client doesn’t want to check the DNSSEC records, they won’t be provided. But if a client wants to ensure that the DNS records have not been tampered with and come from the registrant of the domain, as established through the chain of trust, DNSSEC allows it to do just that.

You use DNSSEC to produce RRSIG records, which sign an RRSET. An RRSET is any DNS record that has the same type and name. Many are a single value, but some might have more than one value associated. The RRSIG stores a digital signature of an RRSET using public and private keys. The RRSIG uses the RRSET data and the private part of the Zone Signing Key to create a signature.

The clients use the public part of the Zone Signing Key to verify the RRSIG. The public keys are in the DNS Key record, which stores the public key for the zone signing key and the keys signing key. You use flags to determine what kind of key is referred to in the DNSKEY record. For example, flag 256 is a zone signing key, and the value of 257 is a key signing key. Validating the RRSIG matches the RRSET using the zone signing key proves the records haven’t been tampered with and are signed by the private zone signing key.

The DNSKEY record also has an RRSIG, but this one is signed with the Key Signing Key. DNSKEY is the only record in the zone signed by the privtate part of the Key Signing Key. Zone Signing Key signs the rest. The private part of the Key Signing Key is held by the registrant and used to create the RRSIG of the DNSKEY, as mentioned. The public part is hashed, and that hash is kept in the parent-level DNS zone. With this, we can verify the integrity of data in the zone. This establishes a chain of trust to the root domain.

Setting up Route 53 hosted zones with DNSSEC and NAME.COM registrar

  1. Navigate to the hosted zone and click on it.
  2. Click on DNSSEC Signing
  3. Enable DNSSEC Sigining
  4. Pick a name for your Key Signing Key - it will be stored in Route 53 not KMS.
  5. Create or choose a Customer Managed Key from KMS. This key will be usd to create the Key Signing Key.
  6. Once this is done you will see a button that says View Information to create DS record - click it.
  7. In another tab go to your Name.com domains and select it
  8. From there click on the Manage Name Servers Link
  9. On that page scroll down to find DNSSEC management sections. Click on DNSSEC Management page.
  10. From there you will find a form with all of the information you need to fill out from the AWS page we just chose.
  11. Congratulations your domain is now working with DNSSEC.

Photo Credit: http://www.recyclethis.co.uk, Link