For more primers like this, subscribe to get notifications about them as they are released.
Domain Name System (DNS) makes the Internet usable to humans by providing a naming structure for online resources and mapping those names to the addresses where the resources reside. Without it, websites would be accessible only by entering long strings of numbers, such as: “184.108.40.2065”.
Humans aren’t good at retaining such things but remember, “npr.org” is manageable. Enter the DNS.
Paul Mockapetris created the DNS at UC Irvine in 1983. Before then, people were mapping names to addresses by sharing a big text file called
hosts.txt. This is why most operating systems have a host file even today.
Let’s look at how the DNS works.
As we said in the intro, the DNS system finds resources for you by name. You ask where a character is, and it returns you an IP address. This is done through a distributed database system whereby requests for names are handed off to various tiers of servers delineated by the dot (.) in the word you’re looking for. It uses the client-server model.
The structure is hierarchical and moves from right to left like so:
Clients, like your laptop or desktop, are usually configured with a DNS server that it uses to get names resolved. Clients typically make recursive queries, meaning they want the final answer—leaving the DNS server to walk the tree.
Name resolution for a typical client follows the steps described below:
The name resolution process is different for recursive vs. iterative queries. See that section for more detail.
The DNS protocol is relatively light (see the image above) and thus sits on top of UDP, so queries can happen quickly and without much overhead. Questions over 512 bytes, and certain heavier operations such as Zone Transfers, however, switch to TCP so that delivery will not become an issue. A recent addition is DoH or DNS over HTTPS, to add support for SSL and other security enhancements lacking in native DNS.
The protocol has the following fields:
One of the most significant points of confusion regarding DNS comes from the difference between DNS caches, DNS servers, and DNS resolvers.
A DNS cache can mean a couple of different things, which is why it isn’t apparent.
So when someone says they need to clear their DNS cache, they’re probably talking about their local cache. So if they’re talking about setting up a DNS Cache, they’re probably talking about a DNS server that makes DNS queries faster for the network.
A DNS server is software that serves DNS requests for clients. It can be a cache (see above) that doesn’t have any names of its own and performs recursive queries (and caching), or it can be a “real” server, meaning that it does hold the authoritative answers for specific resources.
DNS resolvers are just DNS clients and can make two main types of queries: iterative and recursive. See that section below.
As mentioned above, recursive queries are queries where the client asks the server to do all the work for it. For example, it sends the RECURSION DESIRED flag in its query, and the DNS server will either honor that or not.
Iterative queries are the opposite of recursive queries. When they’re used, the server doesn’t find the answer for the client (unless it’s on the first question and response) but instead tells the client where to look next. So if the client asks for chat.google.com, it tells the client to check with the .com servers and considers its work done.
Authoritative responses come directly from a nameserver that has authority over the record in question. Non-authoritative answers come second-hand (or more), i.e., from another server or through a cache.
Reverse queries reverse the direction of DNS lookups, i.e., going from IP to name instead of name to IP. Forward queries are another name for regular name-to-IP queries.
Zone Transfers are how slave servers pull records from controller servers for backup and redundancy purposes. They occur over TCP because the transferred data is usually substantial (most likely over 512 bytes). During the operation, the client sends a query type of IXFR instead of AXFR.
Zone Transfers are sensitive from a security standpoint because when someone knows what and where your resources are, it helps them plan an attack against you. For example, zone Transfers should only be allowed by approved systems.
When you perform a zone transfer, you want to define two things:
You can perform the actual transfer using several tools.
# host -la $DOMAIN
Remember that there are two pieces to doing a Zone Transfer: defining the server you’re asking for and representing the zone you’re trying to pull. With
host, you need to define the first piece by using your
resolv.conf file, i.e., by setting your DNS server to be the target.
dig command you can do it in one step…
# dig @server $DOMAIN axfr
You can also use
nslookup to perform a Zone Transfer, it’s an elaborate process and, therefore, silly. Use
Performing a Zone Transfer against a domain without permission may be considered “hacking” by some. You should either have permission or be prepared to face the consequences.
Anycast is a brilliant protocol that allows the same IP to be served from multiple locations. The network then decides intelligently which location to route a given user request based on distance, latency, network health conditions, etc.
Anycast DNS does this for DNS, making it almost like a CDN for your DNS. However, if you have a site accessed from many parts of the world and where speed is a consideration, you should consider using a DNS provider with an Anycast option.
This site uses Anycast DNS (through DYN) as part of its /stack.
Wildcard DNS is a type of DNS record responding to non-existent subdomains/hosts within a zone. So if you have a wildcard for
*.ctrltilde.com, then someone is going to
.ctrltilde.com will be directed to wherever I point that wildcard record to.
Dynamic DNS allows clients with changing DHCP addresses to update a DNS server with their latest IP so that it can be found by name at its current location.
There are several things to think about from a security perspective regarding DNS. First among these is that if someone controls where you are sent when you ask for a given name, they control something quite powerful.
Modifying DNS servers for clients is often a primary objective of an attacker after gaining control of a system or network. This means changing the DNS resolution so that specific sensitive names (like bankofamerica.com, for example), or even all words, are redirected to a server the attacker controls.
This enables an attacker to present a login form that looks similar to (or even identical to) the real thing. If the user signs into the fake site, the attacker has stolen their credentials.
It’s critical, therefore, that the nameserver responding to client requests in your environment is legitimate and is not compromised.
By default, DNS is pretty easy to spoof because it’s based on UDP. In many cases, You can send a response to a client, and it will assume that you made a previous request and update the record in the cache.
DNSSEC is a set of security-oriented DNS extensions designed to address several issues with DNS. It is primarily concerned with helping resolvers (clients) ensure that DNS data comes from an authorized origin.
DNSSEC works by digitally signing responses using public-key cryptography and uses several new resource records, shown below.
When DNSSEC is used, each answer to a DNS lookup contains an RRSIG DNS record in addition to the requested record type. The RRSIG record is a digital signature of the answer DNS resource record set. The digital signature is verified by locating the correct public key in a DNSKEY record.