Lecture 3 – DNS
DNS (Domain Name System)
Belongs to the application-layer protocol: hosts, DNS servers communicate to resolve names (address/name
translation).
note: core Internet function, the DNS is applied as an application-layer protocol
complexity at network’s “edge”; it's used by servers that sit at the network edge rather than at routers and
switches inside the network.
Is a distributed db implemented in hierarchy of many name servers.
Ex: People have many identifiers: SSN, name, passport #, etc.
The Internet hosts and routers also have two identifiers:
the IP address (32 bit) - used for addressing datagrams
“name”, i.e., cs.umass.edu -used by humans
DNS: services, structure
DNS services provide:
hostname-to-IP-address translation
host aliasing (translating from externally facing names, like mail.cs.ums.edu, to some internal host name
that's much more complicated than that)
canonical, alias names
mail server aliasing
load distribution
replicated Web servers: many IP addresses correspond to one name
Why DNS shouldn’t be centralized
single point of failure A centralized approach represents a single point of failure, and we've seen that the DNS
traffic volume is critical infrastructure. Given the loads on the DNS, a centralized approach would create
distant centralized db a tremendous concentration of traffic. Given how important performances, remember
maintenance milliseconds count when resolving a DNS query, placing it at one location would
necessarily mean long RTT delays to some places on the planet. This is all to say that a
centralized approach simply doesn't scale.
With trillions of queries a day, Akamai alone handles more than a trillion (2.2 T) DNS requests a day; comcast DNS
servers alone 600B DNS queries/day
Thinking about the DNS
- It can be thought of as a highly distributed, high-scale, high-performance distributed db (with nearly billions
of records, each simple).
- It needs to also be able to handle literally trillions of requests, mostly reads that come in every day, and it has
to do so with really high performance.
there are many more reads than writes
the performance matters: almost every Internet transaction interacts with DNS - msecs count!
- Then organizationally, it's also highly decentralized. There are literally hundreds of thousands of organizations
that are going to be responsible for their pieces, their records within this distributed db.
- Is “bulletproof” , reliable and secure.
DNS: a distributed, hierarchical db
The root of this tree, we have the root DNS servers.
The next layer, we have the DNS servers that are responsible for all of the.com or.edu or.net domain names. These are
known as the top-level domain or TLD servers.
And then we have the authoritative name servers. These are the servers that have the ultimate responsibility for
resolving names in their domain. For example, for all of umass.edu, all of nyu.edu, or all of pbs.org.
Now, if a client wants to resolve an address, say for www.amazon.com, here's the basic approach.
The client could first contact a root DNS server to get the name of the TLD server for all of the dot coms.
The client then contacts the TLD server to get the name of the authoritative name server for Amazon.com.
Then finally, the client contacts the authoritative name server for Amazon.com to get the IP address of
www.amazon.com.
DNS: root name servers (4 colors in the second photo: 0, 1-10, 11-20, 21+ servers (4 color classes)
Starting at the top of the DNS hierarchy and that's with the root servers, the root servers are a place to go when a
server is not actually able to resolve a name.
You can think of it almost like a contact of last resort, and in fact, it's not really a contact of last resort because it's not
going to actually provide that translation service, but it's a place to go to get translation started.
This is obviously an incredibly important function for the Internet, almost like the central nervous system of the
Internet. And as such, security is going to be very important.
Now, the root servers and much of the infrastructure tied to them is the responsibility of ICANN, the Internet
Corporation for Assigned Names and Numbers.
There are 13 logical root servers around the world, but each of these logical root servers are themselves actually
replicated. So, corresponding to these 13 logical servers, there are actually close to a thousand physical servers around
the world.
Top Level Domain (TLD) and Authoritative Servers
There are more than 200 physical root servers in the U.S. Moving down a level from the root domain, we find the TLD,
the top-level domain. Each of the addresses that have an ending like.com,.edu,.net, or.org. The organizations that are
responsible for managing these TLD domains are internet registries. These registries are also the place that you'd go if
you want to register a new.com,.edu, or .net name.
Local DNS name servers
- When a host makes DNS query, it is sent to its local DNS server.
Local DNS server returns reply, answering:
from its local cache of recent name-to-address translation pairs (possibly out of date!)
by forwarding request into DNS hierarchy for resolution
Each ISP has a local DNS name server; to find the host name of your local DNS server Caching DNS Information, apply
these shortcuts to:
MacOS: % scutil –dns Windows: >ipconfig /all
DNS name resolution: iterated query
DNS name resolution: recursive query
Caching DNS Information
Once (any) name server learns mapping, it caches it, and immediately returns a cached that maps response to a query.
caching improves response time
cache entries timeout (disappear) after some time (TTL)
TLD servers are typically cached in the local name servers
Cached entries may be out-of-date.
if the named host changes IP address, it may not be known Internet-wide until all TTLs expire
best-effort name-to-address translation
DNS records
- RR (resource records) are stored there; the RR format is (name, value, type, ttl).
- There are 4 types of DNS records:
DNS protocol messages
Getting Information into the DNS
1. Registering a Domain
- When establishing a new startup, such as "Network Utopia," the first step is to register a domain name (e.g.,
networkutopia.com) with a DNS registrar like Network Solutions.
- The registrar collects information, including the names and IP addresses of authoritative name servers (primary and
secondary) for the domain.
2. Inserting Records into TLD Server
- The registrar inserts relevant records into the Top-Level Domain (TLD) server for .com.
Examples of records inserted:
(networkutopia.com, dns1.networkutopia.com, NS) - Indicating the authoritative name server for networkutopia.com.
(dns1.networkutopia.com, 212.212.212.1, A) - Associating the IP address with the authoritative name server.
3. Local Authoritative Server:
The startup sets up a local authoritative server with the specified IP address (e.g., 212.212.212.1).
Additional records are created:
Type A record for www.networkutopia.com.
Type MX record for networkutopia.com, specifying mail exchange servers.
DNS Security
DDoS Attacks
1) Bombarding Root Servers
- Attempting to fill root DNS servers with a massive volume of traffic.
- Mitigation strategies include traffic filtering and the caching of TLD server IPs by local DNS servers, reducing
reliance on root servers.
2) Bombarding TLD Servers:
- A potentially more dangerous DDoS attack targeting Top-Level Domain servers.
- Requires robust security measures to prevent disruptions.
Spoofing Attacks
Intercepting DNS Queries
- Malicious actors intercept legitimate DNS queries and return falsified (bogus) replies.
- Can lead to users being redirected to malicious websites.
Ex: DNS Cache Poisoning, RFC 4033: DNSSEC:
- DNS Security Extensions (DNSSEC) is a suite of extensions to DNS that adds an additional layer of
authentication.
- It helps in preventing cache poisoning and ensures the integrity and authenticity of DNS data.
