Everything DNS (Domain Name System) Domain Name System Translates a human-friendly name such as www.ietf.org into a network address. introduced in ch. 1 holds is a four-field record and everything it says uses one message format. Getting a new name into the system means writing four records in two places.
Words you will meet
- Resource record — one entry in the DNS database, written as four fields.
- TTL — Time To Live: how long a cached record may be kept.
- Type A record — gives the IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 address of a named host.
- Type NS (Name Server) Name Server The DNS record type that names the authoritative server for a domain. introduced in ch. 2 record — names the server that knows the answers for a domain.
- Type CNAME record — says “this nickname really means that official name”.
- Type MX (Mail eXchange) Mail eXchange The DNS record type that names the mail server for a domain. introduced in ch. 2 record — names the mail server for a domain.
- Registrar — a company that sells domain names and puts them into DNS for you.
- DNS poisoning — feeding a DNS server false records so it sends people astray.
Why this matters
Section 2.4.2 showed the shape of the system. This section shows what is actually stored and actually sent, which is the difference between knowing how DNS works and being able to read a packet capture of it.
It also closes the loop. Everything so far has been about reading DNS. The last part of this section is the only place in the chapter that explains how anything gets written into it.
Resource records
The DNS servers that together implement the distributed database store resource records resource record Simple One entry in the DNS database, written as four fields. Precise A four-tuple (Name, Value, Type, TTL) stored by the DNS servers that together implement the DNS distributed database. Each DNS reply message carries one or more resource records. The meaning of Name and Value depends on Type. introduced in ch. 2 — open in glossary ( RR (Resource Record) Resource Record One (Name, Value, Type, TTL) entry in the DNS database. introduced in ch. 2 s), including records that provide hostname-to-IP-address mappings. Each DNS reply message carries one or more of them.
A resource record is a four-tuple:
(Name, Value, Type, TTL)TTL (Time To Live) Time To Live How long a cached DNS record may be kept before it must be fetched again. introduced in ch. 2 dns time to live Simple How long a cached DNS answer may be kept before it must be looked up again. Precise The TTL field of a resource record, which determines when the record should be removed from a cache. introduced in ch. 2 — open in glossary is the time to live of the record: it determines when the record should be removed from a cache. In the examples below it is ignored, as the book ignores it.
Name and Value have no fixed meaning
The meaning of Name and Value depends on Type. That is not a quirk; it is the design. Four record types share two slots, and what those slots hold changes completely from one type to the next.
So the four types have to be learned together. Reading the table below one row at a time will not work.
| Name is… | Value is… | Example | |
|---|---|---|---|
| An NS record names a server by hostname, and you cannot send a packet to a hostname. So it almost always travels with a Type A record giving that server’s address — otherwise resolving the referral would need its own lookup, which would need its own, and so on. | |||
Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.
Sort by Type, or read down the examples. The two middle columns change meaning from row to row — that is the whole idea.
Which records a server actually holds
There is a simple rule, and it explains the shape of every query chain in section 2.4.2.
- If a DNS server is authoritative for a hostname, it holds a Type A record type a record Simple A DNS record giving the IP address of a named host. Precise A resource record in which Name is a hostname and Value is the IP address for that hostname, providing the standard hostname-to-IP-address mapping. For example (relay1.bar.foo.com, 145.37.93.126, A). A server authoritative for a hostname always holds a Type A record for it. introduced in ch. 2 — open in glossary for that hostname. (Even a server that is not authoritative may hold one in its cache.)
- If a server is not authoritative, it holds a Type NS (Name Server) Name Server The DNS record type that names the authoritative server for a domain. introduced in ch. 2 record type ns record Simple A DNS record naming the server that knows the answers for a domain. Precise A resource record in which Name is a domain. Value is the hostname of an authoritative DNS server that knows how to obtain the IP addresses for hosts in that domain. It is used to route DNS queries further along the query chain — for example (foo.com, dns.foo.com, NS). It is normally accompanied by a Type A record giving that server’s address. introduced in ch. 2 — open in glossary for the domain containing the hostname — and also a Type A record giving the IP address of the server named in that NS record.
Worked example — what an edu TLD (Top-Level Domain) Top-Level Domain The last label of a hostname — com, edu, uk — and the DNS servers responsible for it. introduced in ch. 2 server holds
Suppose an edu TLD (Top-Level Domain) Top-Level Domain The last label of a hostname — com, edu, uk — and the DNS servers responsible for it.
introduced in ch. 2 server is not authoritative for
gaia.cs.umass.edu. Then it
contains a record for a domain that includes that host:
(umass.edu, dns.umass.edu, NS)and it also contains a Type A record mapping that server to an address:
(dns.umass.edu, 128.119.40.111, A)Why both? The NS record names a server by hostname, and you cannot send a packet to a hostname. Without the A record beside it, resolving the referral would need its own lookup — which would need its own, and so on. The pair stops the regress.
The other two types implement the aliasing services of section 2.4.1. A Type CNAME (Canonical Name) Canonical Name The DNS record type that maps an alias hostname to the real one. introduced in ch. 2 record type cname record Simple A DNS record saying “this nickname really means that official name”. Precise A resource record in which Value is a canonical hostname for the alias hostname Name. For example (foo.com, relay1.bar.foo.com, CNAME). introduced in ch. 2 — open in glossary gives the canonical hostname behind an alias. A Type MX (Mail eXchange) Mail eXchange The DNS record type that names the mail server for a domain. introduced in ch. 2 record type mx record Simple A DNS record naming the mail server for a domain. Precise A resource record in which Value is the canonical name of a mail server that has the alias hostname Name — for example (foo.com, mail.bar.foo.com, MX). MX records let a company use the same aliased name for its mail server and its Web server. A client queries for MX to reach the mail server, and for CNAME to reach the other. introduced in ch. 2 — open in glossary gives the canonical name of a mail server that has an alias.
DNS messages
There are only two kinds of DNS message — query and reply — and both have the same format.
Click any box to read what that part of the message is for.
Every field, as text
- Identification — 16 bits — A 16-bit number that identifies this query. (example: 0x1a2b)
- Flags — 16 bits — Several one-bit flags. See the expansion below. (example: QR=0, RD=1)
- Number of questions — 16 bits — How many entries the questions section holds. (example: 1)
- Number of answer RRs — 16 bits — How many resource records the answer section holds. (example: 1)
- Number of authority RRs — 16 bits — How many records the authority section holds. (example: 0)
- Number of additional RRs — 16 bits — How many records the additional section holds. (example: 1)
Query and reply are the only two kinds of DNS message, and both use this format. Click any field.
In plain words — what the four counts are for
There is no length field anywhere in a DNS message. Instead the header carries four number-of fields, one per section, and those counts tell the receiver how many entries to expect in each.
It is a small design decision with a large consequence: a receiver can parse the message without knowing its total size in advance.
Click any box to read what that part of the message is for.
Every field, as text
- QR — 1 bits — Query or reply. (example: 0)
- other — 4 bits — Further flag bits the book does not detail.
- AA — 1 bits — Authoritative answer. (example: 1)
- x — 1 bits — A further flag bit the book does not detail.
- RD — 1 bits — Recursion desired. (example: 1)
- RA — 1 bits — Recursion available. (example: 0)
- other flag bits — 7 bits — The remainder of the field, which the book does not detail.
The book names four of these flags in prose without giving their positions. The positions drawn here are from RFC 1035; the four the book names are labelled, and the rest are marked as such rather than invented.
Click any arrow to see what that message says and why it is sent.
The same two messages the §2.4.1 ladder showed, now with their fields filled in. Click either arrow.
Read this diagram as text
- Lin’s laptop sends query — id 0x1a2b, QR=0, RD=1 to Local DNS server. One question, no answers. Recursion desired is set, because a host does want its local server to do the walking.
- Local DNS server sends reply — id 0x1a2b, QR=1, one answer to Lin’s laptop. The identification is copied back unchanged: that is how the laptop knows this reply belongs to that query. The question is echoed, and the answer section carries the record.
Lifelines, left to right: Lin’s laptop (host), Local DNS server (server).
Try it yourself
You can send a DNS query straight from your own machine with the nslookup
program, available on most Windows and UNIX platforms. Type nslookup at a
command prompt, then send a query to any DNS server — root, TLD or authoritative.
nslookup displays the records in the reply in a human-readable format.
If you would rather not run it locally, many websites let you use nslookup remotely.
Where this breaks: nslookup shows you the records, not the bytes. The identification field, the flag bits and the four counts — everything the diagrams above are about — are parsed away before you see anything. The Wireshark lab at the end of this chapter is where you meet the actual message.
Getting records into the database
Everything so far has been about retrieving records. How do they get in?
The first step is to register the domain name with a registrar registrar Simple A company that sells domain names and puts them into the DNS for you. Precise A commercial entity that verifies the uniqueness of a domain name, enters it into the DNS database and collects a fee. Registrars are accredited by ICANN. Registering a domain means giving the registrar the names and IP addresses of your authoritative DNS servers. The registrar then inserts a Type NS and a Type A record into the TLD servers. introduced in ch. 2 — open in glossary . A registrar is a commercial entity that verifies the name is unique, enters it into the DNS database, and collects a small fee. ICANN (Internet Corporation for Assigned Names and Numbers) Internet Corporation for Assigned Names and Numbers Accredits the registrars that sell domain names. introduced in ch. 2 accredits them.
A registrar is a commercial entity that verifies the domain name is unique, enters it into the DNS database, and collects a small fee. Before 1999 a single registrar, Network Solutions, held a monopoly on com, net and org. Today many compete, and ICANN accredits them.
Everything so far has been about reading DNS. This is how anything gets written into it.
Read all steps as text
- 1 — Register the name with a registrar — A registrar is a commercial entity that verifies the domain name is unique, enters it into the DNS database, and collects a small fee. Before 1999 a single registrar, Network Solutions, held a monopoly on com, net and org. Today many compete, and ICANN accredits them.
- 2 — Give it your authoritative servers — You supply the names and IP addresses of your primary and secondary authoritative DNS servers: dns1.networkutopia.com and dns2.networkutopia.com, at 212.212.212.1 and 212.212.212.2.
- 3 — The registrar writes two records into the com TLD servers — For each of your two authoritative servers it inserts an NS record and an A record. The NS record says who is authoritative; the A record gives that server an address, so a querying server can act on the referral without a further lookup.
- 4 — You write your own records into your own servers — Into your authoritative servers you put a Type A record for your web server www.networkutopia.com, and a Type MX record for your mail server mail.networkutopia.com. Until recently these were configured statically from a file written by a system manager; an UPDATE option now allows data to be added and deleted dynamically through DNS messages.
- 5 — Alice in Australia visits your site — Her host queries her local DNS server, which contacts a com TLD server. That server holds the two records the registrar inserted, so it replies with both. Her local server then queries 212.212.212.1 for the Type A record of www.networkutopia.com, gets 212.212.71.4, and passes it back. Her browser opens a TCP connection and sends an HTTP request.
A typo in the book
The book gives your two authoritative servers’ addresses on book page 134 as
212.2.212.1 and 212.212.212.2, then uses 212.212.212.1 on page 136 when it
writes out the record.
212.212.212.1 is the consistent one, and this site uses it throughout. Flagged
because a reader comparing the two pages would otherwise think they had
misunderstood something.
Once all this is done, people can visit your website and send e-mail to your staff. That claim is worth verifying rather than accepting, which is what step 5 above does.
Until recently the contents of each DNS server were configured statically,
from a configuration file written by a system manager. An UPDATE option has
since been added to the DNS protocol, allowing data to be added to or deleted
from the database dynamically through DNS messages.
Focus on security: attacking DNS
DNS is a critical component of the Internet infrastructure, and many important services — the Web and e-mail among them — simply cannot function without it. So it is fair to ask how it can be attacked. Is it a sitting duck?
Flooding the roots, 21 October 2002
The obvious attack is a DDoS (Distributed Denial of Service) Distributed Denial of Service A denial-of-service attack launched from many controlled machines at once. introduced in ch. 1 bandwidth-flooding attack against the DNS servers, and one was attempted. Attackers used a botnet to send enormous numbers of ICMP (Internet Control Message Protocol) Internet Control Message Protocol Carries error and diagnostic messages between hosts and routers. A ping is an ICMP message. Covered in §5.6. introduced in ch. 2 ping messages to each of the 13 root IP addresses.
It caused minimal damage. Two things saved the roots:
- Many of them were protected by packet filters configured to block all ICMP ping messages directed at them. Those servers were spared and worked normally.
- Most local DNS servers cache the addresses of TLD servers, so the query process often bypasses the roots anyway — exactly as section 2.4.2 explained.
Flooding a TLD provider, 21 October 2016
A potentially more effective attack sends a deluge of DNS queries to top-level-domain servers instead. This is harder to defend, for two reasons that mirror the two defences above. DNS queries are harder to filter than ICMP pings, and TLD servers are not so easily bypassed by caching.
Such an attack took place against the TLD service provider Dyn, exactly fourteen years to the day after the attack on the roots. It used a botnet of about one hundred thousand IoT (Internet of Things) Internet of Things Everyday devices with network connections — the Mirai botnet was built from about 100,000 of them. introduced in ch. 2 devices — printers, IP cameras, residential gateways, baby monitors — infected with Mirai malware.
For almost a full day, Amazon, Twitter, Netflix, Github and Spotify were disturbed.
In plain words
Nobody attacked Amazon, Twitter, Netflix, Github or Spotify. Their servers were fine the whole time.
What failed was the ability to turn their names into addresses, and that was enough. This is what section 2.4.1 meant by calling DNS a core network function.
Forging replies
DNS can be attacked in other ways. In a man-in-the-middle attack the attacker intercepts queries from hosts and returns bogus replies. In the DNS poisoning dns poisoning Simple Feeding a DNS server false records, so it sends people to the wrong place. Precise An attack in which the attacker sends bogus replies to a DNS server, tricking it into accepting bogus records into its cache. Together with the man-in-the-middle attack, in which the attacker intercepts queries and returns bogus replies, it could be used to redirect an unsuspecting Web user to the attacker’s Web site. DNSSEC was designed and deployed to protect against such exploits. introduced in ch. 2 — open in glossary attack the attacker sends bogus replies to a DNS server, tricking it into accepting bogus records into its cache.
Either could redirect an unsuspecting user to the attacker’s website.
The DNS Security Extensions ( DNSSEC (DNS Security Extensions) DNS Security Extensions A secured version of DNS, designed against man-in-the-middle and poisoning attacks. introduced in ch. 2 ) have been designed and deployed to protect against such exploits. DNSSEC is a secured version of DNS that addresses many of these attacks, and it is gaining popularity.
DNSSEC does not stop a flood
Notice that the two families of attack need different defences. DNSSEC protects against forged replies — man-in-the-middle and poisoning — by letting a resolver check that a record really came from the right server.
It does nothing whatever against a flood. Signing a reply does not help if the reply never gets sent.
Check yourself
Check yourself
0 of 7 answered1.A resource record is a four-tuple (Name, Value, Type, TTL). Why can you not say what Name and Value mean without looking at Type?
2.An edu TLD server is not authoritative for gaia.cs.umass.edu. Which records does it hold, and why two rather than one?
3.predictLook at the DNS message diagram. The header is 12 bytes. How is that made up?
4.What is the identification field for?
5.A client asks for the MX record of a domain. The answer section names a mail server. What is likely in the additional section, and why is that useful?
6.You register networkutopia.com. Which records does the registrar insert into the com TLD servers?
7.The 2002 attack on the root servers did little damage; the 2016 attack on Dyn disturbed Amazon, Twitter, Netflix, Github and Spotify for almost a full day. What made the difference?
What to remember
- A resource record is
(Name, Value, Type, TTL). What Name and Value mean depends on Type, so the four types must be learned together. - A = hostname → address. NS = domain → authoritative server’s hostname. CNAME = alias → canonical name. MX = alias → mail server’s canonical name.
- The 2002 flood of the roots failed, because of packet filters and caching. The 2016 flood of Dyn worked: DNS queries are harder to filter, and TLD servers are not bypassed by caching. DNSSEC defends against forged replies and does nothing against a flood.