DNS

DNS is part of Junior2Senior a course to help you grow as software engineers.

In the first article, we describe what is a web/HTTP request. Requests are directed toward a host and a port.

The port is defined by the protocol, HTTP goes to port 80, HTTPS goes to 443. The host is defined by the request as a string.

A possible host is “google.com” another is “facebook.com”.

However, packets are routed over the internet using IP addresses, numbers, while hosts are strings.

Each IP packet must contain its source and its destination to be delivered. And the host of the source address and of the destination address must be encoded as IP addresses.

In order to create the IP packet and to deliver it to the internet, we need to convert the host name “kitty.com” in its IP address 53.125.12.9.

DNS serves have the basic goal of translating the string that represents the host (“google.com”) in a number, the IP address ( 116.98.109.34) so that a valid IP packet can be generated.

Scratching the surface

At its most basic level, DNS are services that take as input a host string and return the IP address of the host.

A simple utility to test DNS is dig. In its most basic invocation, dig takes an input an host and returns its IPv4.

The following examples have different options to provide a more concise output.

$ dig +noall +answer -t A google.com google.com. 275    IN  A   216.58.205.46 
$ dig +noall +answer -t AAAA google.com google.com. 257 IN  AAAA    2a00:1450:4009:81b::200e

In the first line we translate the host “google.com” into an IPv4 address ( 216.58.205.46).

In the second line, for the same host, we retrieve its IPv6 ( 2a00:1450:4009:81b::200e).

DNS record type

DNS can store different kinds of records beside IP addresses. The most common record type is A that stores IPv4 addresses. The AAAA record stores IPv6 addresses.

Another important record type is the CNAME (or ALIAS) record type. It is useful if a single machine, with only one IP address, runs multiple services on different ports.

The TXT record type can contain arbitrary information, it is usually used to verify the ownership of a domain name.

Other record types are available and widely used, but the working principle is the same for all.

Resolve DNS query

DNS works like any other internet service, but with some peculiarity.

First of all, the IP address of the DNSs are widely know, for instance, the one provided by google is 8.8.8.8 and the one by Cloudflare is 1.1.1.1.

Then DNS works mostly over UDP and not over TCP. The use of UDP is mostly for performance.

Performance is the most strict requirement for DNS.

DNS must be fast.

In order to keep communication as concise and fast as possible, almost all packets DNS queries and responses fit into a single UDP packet and are limited to 512 bytes. If the DNS answer is bigger other communications protocols are used.

Need for speed

The use of UDP over TCP is mostly due to performance requirements. Any application needs to make multiple DNS queries, it must be fast.

Even if fast, it is still impractical to make a DNS query for each network request. Moreover, when visiting a website, most requests are against the same host in a short amount of time.

To address the problem DNS is aggressively cached on different layers.

Cached values eventually goes stale and they must be updated. For this reason, DNS records provide also a TTL value, Time To Live.

After the TTL expires, the DNS value is considered outdated and it must be requested again from the authoritative domain.

Server cache

The first level of DNS cache is the server level. DNS servers don’t store all the values of all the domains, but only a small subset.

If a request for an unknown domain comes, they recursively redirect the request to other DNS until they don’t get the answer from the authoritative (main) DNS. The answer is then cached until the TTL expires.

Client cache

While server cached helps a lot in reducing the latency of DNS queries, it cannot be as fast as a local copy.

Hence the first level of cache regarding the name server happens in the local machine.

The OS intercepts DNS requests and returns a cached answer, as long as the TTL is not expired. As soon as the TTL expires a new request to the server is made and the answer cached again.

TTL and propagation time

Caching the result of DNS queries has the huge benefits of making it fast. The downside is that updates to DNS take time.

All the TTL needs to expire before all the users can see the updated values.

It can take up to 2 days for the information to propagate in the DNS servers. For most applications, the delay is much smaller, a few hours at the very maximum in my experience using AWS Route53 or Cloudfront.

Trivial

DNS can store arbitrary information, and eventually all the DNS servers will agree on a specific values. For these reasons DNS are considered the biggest and more widely deployed eventual consistent databases.

DNS console

After you buy a domain name you can set all the DNS values relative to that domain and all its subdomains.

All the DNS interfaces are similar, offering pretty much the same functionality.

Your DNS provider is mostly a matter of taste and convenience.

AWS Route53

I like to use Amazon Route53 service, that allows buying the domain and set the records in the same interface.

I like Amazon Route53 because:

1. DNS is a fundamental service for AWS, it will always work

2. They provide very clear, simple, and cheap pricing

3. I trust Amazon don’t screw people over a few dollars in the domain registration fee, unlike other vendors.

A domain on AWS cost ~12$ / year plus few cents if your domain is extremely popular or if you need special features.

Beware that other vendors sell your domain at a much higher price BUT they provide a hefty discount for the first year. So it seems like you are buying it for 4$ and the second year they start charging you 50$ / year.

In my opinion, it is just not worth doing business with them.

Trivial

The DNS service of Amazon is called Route53, while Route is quite clear, why not Route 66, much more iconic. Or Route 101? Because 53 is the port used by the DNS protocol.

The console

The console of AWS Route53 looks like this, for each of your domains.

We will focus on the big table. The navigation on the right is for more (advanced) features of AWS Route53.

From the table, we can immediately see the name of the record (first column), the record type ( A, NS, AAAA, CNAME, etc...​) and the value of the record.

The highlighted rows are all A records. It is interesting to note how the root domain manage:

1. The root domain itself, making redbeardlab.com point to the IP address 212.47.232.249

2. The sub-domain, making simplesql.redbeardlab.com point to 212.47.253.152

3. All other sub-domain levels, in this case making telemetrics.redisql.redbeardlab.com point to 51.15.142.13

The AAAA records are very similar to the A record.

In this example we make telemetrics.redisql.redbeardlab.com point to 2001:bc8:4400:2c00::2b:c17.

This does not generate an ambiguity with the A record above. If the client asks for the IPv4 address the server returns 51.15.142.13. While, if the client ask for the IPv6 address the server returns 2001:bc8:4400:2c00::2b:c17. In this particular case, both addresses point to the same machine. But they could point to different servers offering completely different services.

The CNAME record creates an alias.

In the first example, we set the host redisql.redbeardlab.com to point to redbeardlab.github.io. In this way we can serve, under the domain we control, content from Github pages, for free. Quite convenient.

In the second case we redirect all the calls to AWS Cloudfront, a CDN managed by AWS.

When a client finds a CNAME it stops asking for the original host IP address and starts asking for the IP address of the ALIAS. If a client goes to redisql.redbeardlab.com, at first it will try to find the IP address of redisql.redbeardlab.com, however, the DNS server will say that the IP address does not exist, but it exists an alias, redbeardlab.github.io. At this point, the client will start looking for the IP address of redbeardlab.github.io.

The TXT fields were used for verifying the ownership of the domain against Google.

This is the most common use I encounter, but other uses for the TXT field are possible.

Finally, the NS record, declare who manage the DNS entry.

In this case, the DNS is managed by…​ Cloudflare. So all we said above is ignored by a real DNS client that will make its queries not against AWS Route53 but against Cloudflare.

While the TTL (Time To Live) for most records is set to 300 or 600 seconds (5 to 10 minutes) the TTL for the NS is set to a much larger value, 7200 seconds (2 hours).

This is to be expected, you don’t change often the NS value, once you set your DNS provider you tend to stick to it. Moreover, change the NS value is expensive, all the queries need to be directed to a completely different service that needs time to accommodate it.

Note on Name Server configuration in AWS Route53

Unfortunately, in Route53, it is not sufficient to set the Name Server record set, but it is also necessary to set the name servers in another setting.

Under 'Register Domains' > $your_domain and then "Add or edit name servers".

I find a good practice to keep the two values in sync.

Cloudflare

Another very reputable DNS provider is Cloudflare. They don’t sell you domain names directly, but they can manage them for you.

So you will need to buy your domain somewhere else, also an AWS Route53, and then let Cloudflare manage it. This is what I did above.

This is done setting up the authoritative name server to point to Cloudflare. It is as simple as adding a new record (of type NS) to your existing DNS records (modulo the extra setting in AWS Route53). From that moment on, beside propagation delay, all the DNS queries will be redirected toward the new authoritative name server.

The console

The console of Cloudflare is different from the one of Route53, but overall they contain the same information and it is equally simple to use.

We can recognize the same kind of information:

1. the A fields that point to IPv4 addresses

2. the AAAA fields that point to IPv6 addresses

3. the CNAME used for alias

4. the TXT again used for domain ownership verification

5. the MX used for email routing, with a priority

The “Proxy Status” column in the Cloudflare console indicates whenever Cloudflare takes care only of the DNS ( DNS only) or also to cache and manage with their services the request to the domain.

Recap

Hopefully, this article is helpful if you are setting up your DNS or if you are getting started with web services.

If you have any question I would love to expand the article and help you out, feel free to reach over on twitter @pauldigian.

Originally published at https://jr2sr.com on June 7, 2020.