A DNS Primer
For more primers like this, check out my tutorial series.
What is the DNS?
The 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: “22.214.171.1245”.
Humans aren’t good at retaining such things, but remembering “npr.org” is fairly manageable. Enter the DNS.
The DNS was created by Paul Mockapetris 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 hosts file even today.
Let’s look at how the DNS works.
For those who prefer a walkthrough approach, the video above describes DNS resolution visually.
As we said in the intro, the DNS is a system that finds resources for you by name. You ask where a name 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 which are delineated by the dot (.) in the name you’re looking for. It uses the client-server model.
The structure is hierarchical, and moves from right to left like so:
The root domain (dot)
The top-level domain (TLD)
The second-level domain
The host/resource name
Clients, like your laptop or desktop, are usually configured with a DNS server that it uses to get names resolved. Clients usually make recursive queries, meaning that they just want the final answer—leaving the DNS server to do the work of walking the tree.
Name resolution for a typical client follows the steps described below:
A DNS server is configured with an initial cache (so called hints) of the known addresses of the root name servers. The hint file is updated periodically in a trusted, authoritative way.
When a client makes a (recursive) request of that server, it services that request either through its cache (if it already had the answer from a previous lookup) or by performing the following steps on the client’s behalf.
A query is made to one of the root servers to find the server authoritative for the top-level domain being requested.
An answer is received that points to the nameserver for that resource.
The server “walks the tree” from right to left, going from nameserver to nameserver, until the final step which returns the IP address of the host in question.
The IP address of the resource is then given to the client.
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 that queries can happen quickly and without much overhead. Queries over 512 bytes, and certain heavier operations such as Zone Transfers, however, switch to using TCP so that delivery will not become an issue.
The protocol has the following fields:
The Identifier: a 16-bit ID field that matches requests and responses.
The Query/Rsponse Flag: a 4-bit field that designates whether the packet is a request or a response.
Opcode: Specifies the type of message being carried. Options include: 0 for standard query, 1 for an inverse query (obsolete), 2 for server status, 3 is reserved and unused, 4 is notify message, and 5 is an update (used for Dynamic DNS).
AA: This is a 1-bit field indicating an authoritative answer. The bit is set to 1 if it’s authoritative, meaning that the server who gave the answer is authoritative for the domain in question. If it’s set to 0 it’s a non-authoritative answer.
TC: A 1-bit field for truncation, yes or no. Usually indicates it was sent via UDP but was longer than 512 byes.
RD: A 1-bit field called “Recursion Desired”, meaning that the client is asking the server to walk the tree on the client’s behalf and just return the answer as opposed to telling it where to look next.
RA: A 1-bit field called “Recursion Available”, in which a DNS server tells a client that it support recursion or not.
Z: Three reserved bits that are always set to zeroes.
RCode: A 4-bit field that’s set to zero in queries (because they’re not responses) with the following options: 0 is no error, 1 is format error, 2 is server failure, 3 is name error, 4 is not implemented, 5 is refused, 6 the name exists but it shouldn’t, 7 a resource record exists that shouldn’t, a resource record that should exist doesn’t, 9 the response is not authoritative, 10 the name in the response is not within the zone specified.
QDCount: How many questions in the question section.
ANCount: How many answers in the answer section.
NSCount: How many resource records in the authority section.
ARCount: How many resource records in the additional section.
One of the biggest 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’s confusing.
The list of names and IPs that you’ve resolved recently, which are “cached” such that if you ask the question again you’ll get the same answer without generating network traffic.
A DNS server that doesn’t have any authoritative names itself, but just performs recursive queries and caching (saving those answers for future requests within a certain amount of time).
So when someone says they need to clear their DNS cache, they’re probably talking about their local cache. If they’re talking about setting up a DNS Cache, they’re probably talking about a DNS server that just 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) which doesn’t have any names of its own and just performs recursive queries (and caching), or it can be a “real” server, meaning that it does hold the authoritative answers for certain resources.
DNS resolvers are just DNS clients. They 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. It sends in its query the RECURSION DESIRED flag, 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 go find the answer for the client (unless it’s on the first question and response), but rather 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 are responses that 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 simply reverse the direction of DNS lookups, i.e. going from IP to name instead of name to IP. Forward queries are another name for normal name-to-IP queries.
Zone Transfers are the means by which slave servers pull records from master servers for backup and redundancy purposes. They take place over TCP because the data being transfered is usually substantial (and mostly 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. Zone Transfers should only be allowed by approved systems.
Performing a Zone Transfer
When you perform a zone transfer you basically want to define two things:
The server you’re asking
The domain you’re trying to pull
You can perform the actual transfer using a number of tools.
Using the host command
# host -la $DOMAIN
Keep in mind that there are two pieces to doing a Zone Transfer: defining the server you’re asking, and defining 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.
Using the dig command you can do it in one step…
# dig @server $DOMAIN axfr
You can also use nslookup to perform a Zone Transfer, but it’s an elaborate process and therefore silly. Use host or dig.
Performing a Zone Transfer against a domain without permission may be considered “hacking” to some. You should either have permission or be prepared to face 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 to, based on distance, latency, network health conditions, etc.
Anycast DNS does this for DNS, making it almost like a CDN for your DNS. If you have a site that is accessed from many parts of the world, and where speed is a consideration, you should consider using a DNS provider that has an Anycast option.
This site uses Anycast DNS (through DYN) as part of its /stack.
Wildcard DNS is a type of DNS record that will respond to non-existent subdomains/hosts within a zone. So if you have a wildcard for “*.danielmiessler.com”, then someone going to “aargghhh.danielmiessler.com” will be directed to wherever I point that wildcard record to.
*.danielmiessler.com. 3600 TXT "This is a wildcard."
Unsupervised Learning — Security, Tech, and AI in 10 minutes…
Get a weekly breakdown of what's happening in security and tech—and why it matters.
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 a number of things to think about from a security perspective when it comes to DNS. First among these is the fact that if someone controls where you are sent when you ask for a given name, they control something quite powerful.
Spoofing a legitimate site
Modifying DNS servers for clients is often a primary objective of an attacker after gaining control to a system or network. This means changing the DNS resolution so that certain sensitive names (like bankofamerica.com, for example), or even all names, are redirected to a server that 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 it means the attacker now 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 fairly easy to spoof because it’s based on UDP. In many cases You can simply 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 a number of issues with DNS. It is primarily concerned with helping resolvers (clients) ensure that DNS data in fact came from an authorized origin.
DNSSEC works by digitally signing responses using public-key cryptography and uses several new resource records, shown below.
RRSIG – contains the DNSSEC signature for a record set. DNS resolvers verify the signature with a public key, stored in a DNSKEY-record.
DNSKEY – contains the public key that a DNS resolver uses to verify DNSSEC signatures in RRSIG-records.
DS – holds the name of a delegated zone. You place the DS record in the parent zone along with the delegating NS-records. references a DNSKEY-record in the sub-delegated zone.
NSEC – Contains a link to the next record name in the zone and lists the record types that exist for the record’s name. DNS Resolvers use NSEC records to verify the non-existence of a record name and type as part of DNSSEC validation.
NSEC3 – Contains links to the next record name in the zone (in hashed name sorting order) and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 -record’s own name.These records can be used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation. NSEC3 records are similar to NSEC records, but NSEC3 uses cryptographically hashed record names to avoid the enumeration of the record names in a zone.
NSEC3PARAM – Authoritative DNS servers use this record to calculate and determine which NSEC3-records to include in responses to DNSSEC requests for non-existing names/types.
When DNSSEC is used, each answer to a DNS lookup contains an RRSIG DNS record, in addition to the record type that was requested. 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 found in a DNSKEY record.
There are number of attack types associated with DNS. We’ll cover just a few of them.
Changing Your DNS Server: An attacker who can change your DNS server can control where you are taken when you request sensitive resources, like your bank, etc.
Distributed Denial of Service: Because DNS uses UDP, you can request from thousands, or millions, of DNS servers the address for a given name, but do so with the spoofed source address of your victim. This results in that victim being melted by all the response traffic. Many tools exist for doing this.
The Kaminsky Attack: The Kaminsky attack was an issue with predictable DNS IDs that allowed attackers to flood a given system with responses that would then be written and passed onto clients.For more on this attack, see this excellent resource.
The primary players in DNS software are:
Bind: Ubiquitous, powers most of the Internet.
DJBDNS: Focused on security, less used
A number of DNS providers exist that provide various benefits.
DYN: DYN is a DNS provider that allows you to do registration and host your zones. It also provides Anycast and other advanced services.
DNSMadeEasy: DNSMadeEasy is another big name in DNS that provides a number of related services.
GoDaddy: Godaddy is a rather popular DNS service that has a number of services in the space.
OpenDNS: OpenDNS is an interesting service that provides content and security filtering based on monitoring and blocking DNS requests. You configure your hosts or network to use OpenDNS’s DNS servers, and it will block requests for certain categories of site and/or for malware before your browser even starts going there.
This author has always used DYN, but any of the top tier services are likely good options. The key to remember when choosing a provider is that if your DNS is compromised for a site that is sensitive, you will likely experience similar negative effects to having your site compromised. Choose wisely.
There are a few DNS tricks and tools that you always want to have available to you.
dig: dig is supremely valuable for performing all manner of DNS tasks. I’ll be doing a primer on it soon.
nslookup: nslookup is my least favorite DNS tool because I dislike the syntax, but it is on most systems and thus should be learned to some degree.
Here are a couple things you’ll want to be able to do on any computer related to DNS.
Change Your DNS Server
Sometimes you need to be able to change your DNS server.
Windows Go to your network configuration and change your DNS server(s) and apply/exit.
OSX: Open your Network Preferences and click the Advanced button for the connection you’re on.
Linux: Modify your /etc/resolv.conf file.
Clear Your DNS Cache
There are times when you have previously resolved a name for a resource, which has now changed, and you need to get the entry updated in your cache. This is how to do it for the three main operating systems.
OSX: sudo killall -HUP mDNSResponder
Linux: sudo /etc/init.d/nscd restart
Q: What port does DNS work over?A: 53
Q: What protocol does DNS work over?A: UDP
Q: Does DNS always work over UDP?A: No, it switches to TCP if the content is greater than 512 bytes.
Q: What’s the primary role of DNSSEC?A: To assure clients that the answers received came from the authorized server.
Q: What’s an example of a security problem related to DNS?A: Having someone change your DNS server to a malicious one, having someone send you malicious DNS replies that get accepted as legitimate, using DNS to DDoS someone.
Resolution actually starts at the far right dot (.), not at the TLD, but this is a minor technical detail.
The Wikipedia article on DNS.
Definitely check out my friend Steve’s phenomenal description of the Kaminsky DNS Attack: http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html.