Let's see DNS

Attentive reader will find on this picture IPv6

People are often puzzled by domains. Why is my site not working? Why this crap is broken, nothing helps, I just want it to work! Usually, the questioner either does not know about the DNS, or does not understand the fundamental ideas. For many, DNS is a terrible and incomprehensible thing. This article is an attempt to dispel such fear. DNS is easy if you understand a few basic concepts.

What is DNS?

DNS stands for Domain Name System . This is a global distributed storage of keys and values. Servers around the world can provide you with a key value, and if they do not know the key, they will ask for help from another server.

That's all. True. You or your browser requests the value for the www.example.com key, and receives 1.2.3.4 in response.

Basic stuff

A big plus of DNS is that it is a public service, and you can poke at the server if you want to figure it out. Let's try. I have a domain petekeen.net , which is hosted on the machine web01.bugsplat.info . The commands used below can be run from the command line OS X ( oh, i.e. macOS, - approx. Lane ).

Let's take a look at the mapping between the name and the address:

 $ dig web01.bugsplat.info 

The dig command is such a Swiss army knife for DNS queries. Cool, multi-tool. Here is the first part of the answer:

 ; <<>> DiG 9.7.6-P1 <<>> web01.bugsplat.info ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51539 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 

There is only one interesting detail: information about the request itself. It is said that we requested a recording and received exactly one answer. Here is:

 ;; QUESTION SECTION: ;web01.bugsplat.info. IN A 

dig defaults to querying A records. A is an address , and this is one of the fundamental types of DNS records. A contains one IPv4 address. There is an equivalent for IPv6 addresses - AAAA . Let's take a look at the answer:

 ;; ANSWER SECTION: web01.bugsplat.info. 300 IN A 192.241.250.244 

It says that the host is web01.bugsplat.info. there is one address A : 192.241.250.244 . The number 300 is TTL , or time to live (lifetime). So many seconds, you can keep the value in the cache until re-check. The word IN means Internet . Historically, it is necessary to separate the types of networks. Read more about this in the IANA's DNS Parameters document.

The rest of the answer describes the answer itself:

 ;; Query time: 20 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:01:16 2013 ;; MSG SIZE rcvd: 56 

In particular, it says how long the server responded, what the server’s IP address was ( 192.168.1.1 ), what port the dig knocking at ( 53 , the default DNS port), when the request was completed and how many bytes were in the response.

As you can see, with a normal DNS query, a lot of things happen. Every time you open a web page, the browser makes dozens of such requests, including to download all external resources such as images and scripts. Each resource is responsible for at least one new DNS query, and if DNS were not designed for strong caching, then a lot of traffic would be generated.

But in this example it is not visible that the DNS server 192.168.1.1 contacted a bunch of other servers to answer the simple question: “where does web01.bugsplat.info address web01.bugsplat.info ?”. Let's run the trace to find out about the whole possible chain that dig would have had if the information had not been cached:

 $ dig +trace web01.bugsplat.info ; <<>> DiG 9.7.6-P1 <<>> +trace web01.bugsplat.info ;; global options: +cmd . 137375 IN NS l.root-servers.net. . 137375 IN NS m.root-servers.net. . 137375 IN NS a.root-servers.net. . 137375 IN NS b.root-servers.net. . 137375 IN NS c.root-servers.net. . 137375 IN NS d.root-servers.net. . 137375 IN NS e.root-servers.net. . 137375 IN NS f.root-servers.net. . 137375 IN NS g.root-servers.net. . 137375 IN NS h.root-servers.net. . 137375 IN NS i.root-servers.net. . 137375 IN NS j.root-servers.net. . 137375 IN NS k.root-servers.net. ;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms info. 172800 IN NS c0.info.afilias-nst.info. info. 172800 IN NS a2.info.afilias-nst.info. info. 172800 IN NS d0.info.afilias-nst.org. info. 172800 IN NS b2.info.afilias-nst.org. info. 172800 IN NS b0.info.afilias-nst.org. info. 172800 IN NS a0.info.afilias-nst.info. ;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms bugsplat.info. 86400 IN NS ns-1356.awsdns-41.org. bugsplat.info. 86400 IN NS ns-212.awsdns-26.com. bugsplat.info. 86400 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 86400 IN NS ns-911.awsdns-49.net. ;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms web01.bugsplat.info. 300 IN A 192.241.250.244 bugsplat.info. 172800 IN NS ns-1356.awsdns-41.org. bugsplat.info. 172800 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 172800 IN NS ns-212.awsdns-26.com. bugsplat.info. 172800 IN NS ns-911.awsdns-49.net. ;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms 

Information is displayed in a hierarchical sequence. Remember how dig inserted a point . after the host, web01.bugsplat.info ? So, the point . this is an important detail, and it means the root of the hierarchy.

Root DNS servers are served by various companies and nations around the world. Initially, they were few, but the Internet was growing, and now there are 13 of them. But each of the servers has dozens or hundreds of physical machines that hide behind a single IP.

So, at the very top of the trace are the root servers, each defined using an NS- record. NS record links the domain name (in this case, the root domain) to the DNS server. When you register a domain name with a registrar like Namecheap or Godaddy, they create NS records for you.

In the next block, you can see how dig chose a random root server, and requested from it an A record for web01.bugsplat.info . Only the IP address of the root server is 192.5.5.241 ( 192.5.5.241 ). So what exactly was the root server? Let's find out!

 $ dig -x 192.5.5.241 ; <<>> DiG 9.8.3-P1 <<>> -x 192.5.5.241 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2862 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;241.5.5.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 241.5.5.192.in-addr.arpa. 3261 IN PTR f.root-servers.net. 

The -x flag causes dig to do a reverse lookup by IP address. DNS responds with a PTR record that connects the IP and the host, in this case f.root-servers.net .

Returning to our initial query: the root server F returned another set of NS servers. He is responsible for the top-level domain info . dig requests one of these servers for the A record for web01.bugsplat.info , and receives another set of NS servers in response, and then requests the A record for web01.bugsplat.info. from one of these servers web01.bugsplat.info. . And finally gets an answer!

Phew! Much traffic would have been generated, but almost all of these entries were cached for a long time by each server in the chain. Your computer also caches this data, just like your browser. Most often, DNS queries never reach the root servers, because their IP addresses almost never change ( “Probably, it’s all about a big TTL for records in their database. If the DNS server’s IP address has never changed at all, this does not mean that its base has been forever cached ” (note from rrrav ). Top level domains com , net , org , etc. also usually heavily cached.

Other types

There are several other types that are worth knowing. The first is MX . It connects the domain name with one or more mail servers. Email is so important that it has its own type of DNS record. Here are the MX values ​​for petekeen.net :

 $ dig petekeen.net mx ; <<>> DiG 9.7.6-P1 <<>> petekeen.net mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18765 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;petekeen.net. IN MX ;; ANSWER SECTION: petekeen.net. 86400 IN MX 60 web01.bugsplat.info. ;; Query time: 272 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:33:43 2013 ;; MSG SIZE rcvd: 93 

Notice that the MX record points to the name, not the IP address.

Another type that you probably know is CNAME . Transcribed as Canonical Name (canonical name). He associates one name with another. Let's look at the answer:

 $ dig www.petekeen.net ; <<>> DiG 9.7.6-P1 <<>> www.petekeen.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16785 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.petekeen.net. IN A ;; ANSWER SECTION: www.petekeen.net. 86400 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 300 IN A 192.241.250.244 ;; Query time: 63 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:36:58 2013 ;; MSG SIZE rcvd: 86 

We immediately see that we received two answers. The first one says that www.petekeen.net points to web01.bugsplat.info . The second returns an A record for that server. We can assume that CNAME is a pseudonym (or alias) for another server.

What's wrong with CNAME

CNAME records are very useful, but there is an important point: if there is a CNAME with some name, then you cannot create another record with the same name. Neither MX , nor A , nor NS , nothing.

The reason is that DNS replaces in such a way that all records of the place where CNAME points to are also valid for CNAME . In our example, the entries for www.petekeen.net and web01.bugsplat.info will match.

Therefore, you cannot make CNAME on the root domain like petekeen.net , because usually there are other records needed, for example, MX .

Requests to other servers

Let's imagine that the DNS configuration is corrupted. It seems to you that you have fixed the problem, but do not want to wait until the cache is updated to make sure. With dig you can make a request to a public DNS server instead of your default one, like this:

 $ dig www.petekeen.net @8.8.8.8 

The @ symbol with an IP address or host causes dig send a request to the specified server through the default port. You can use Google’s public DNS server or the almost public Level 3 server at 4.2.2.2 .

Typical situations

Let's look at typical situations familiar to many web developers.

Redirect domain to www

Often you need to redirect the domain iskettlemanstillopen.com to www.iskettlemanstillopen.com . Registrars like Namecheap or DNSimple call this the Redirect URL . Here is an example from the Namecheap admin:

The @ symbol indicates the root domain iskettlemanstillopen.com . Let's look at the A record at this domain:

 $ dig iskettlemanstillopen.com ;; QUESTION SECTION: ;iskettlemanstillopen.com. IN A ;; ANSWER SECTION: iskettlemanstillopen.com. 500 IN A 192.64.119.118 

This IP is owned by Namecheap, and there is a small web server running that simply does a redirect at the HTTP level to http://www.iskettlemanstillopen.com :

 $ curl -I iskettlemanstillopen.com curl -I iskettlemanstillopen.com HTTP/1.1 302 Moved Temporarily Server: nginx Date: Fri, 19 Jul 2013 23:53:21 GMT Content-Type: text/html Connection: keep-alive Content-Length: 154 Location: http://www.iskettlemanstillopen.com/ 

CNAME for Heroku or Github

Take a look at the screenshot above. On the second line there is a CNAME . In this case, www.iskettlemanstillopen.com points to the application running on Heroku.

 $ heroku domains === warm-journey-3906 Domain Names warm-journey-3906.herokuapp.com www.iskettlemanstillopen.com 

There is a similar story with Github, but there you need to create a special file in the root of the repository, and name it CNAME . See the documentation .

Wildcards

Most DNS servers support wildcards. For example, there is a wildcard CNAME for *.web01.bugsplat.info points to web01.bugsplat.info . Then any host on web01 will point to web01.bugsplat.info and there is no need to create new entries:

 $ dig randomapp.web01.bugsplat.info ;; QUESTION SECTION: ;randomapp.web01.bugsplat.info. IN A ;; ANSWER SECTION: randomapp.web01.bugsplat.info. 300 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 15 IN A 192.241.250.244 

Conclusion

Hope you now have a basic understanding of DNS. All standards are described in the documents:

• RFC 1034: Domain Names - Concepts and Facilities
• RFC 1035: Domain Names - Implementation and Specification

There are a couple of interesting RFCs, including 4034 , which describes the DNSSEC standard and 5321 , which describes the relationship between DNS and email. They are interesting to read for common development.