FAQ: DNS

Q: What is the purpose of DNS?

The primary purpose of DNS is to convert names to IP addresses

There are many other purposes, however. For example, mail routing (MX records), converting IP addresses to names (PTR records), finding services (SRV records), getting the supposed email of the responsible person for a domain (SOA record), etc.

Q: What’s the difference between a domain, a zone, a hostname, and a fully-qualified domain name (FQDN)?

Zone and domain are usually used interchangeably. A zone can be a subdomain. For example, take a server called apple.newyork.example.com: the top-level domain is com, the zone below that that is example.com, and the zone below that is newyork.example.com. The hostname (sometimes called short hostname) is apple, and the FQDN is apple.newyork.example.com. The period at the end removes any ambiguity. For example, if my default search domain was thenicestword.com, and I run: ping pc1.example.com, that could mean that I want to ping pc1.example.com.thenicestword.com or pc1.example.com. But if I type ping pc1.example.com. with a period at the end, it removes that ambiguity.

Q: What characters are allowed in a DNS record?

• Short hostnames allow a-z (case insensitive), 0-9, and - (hyphen). They must not begin or end with a - and must be less than 64 characters long. Even internationalized domain names are actually encoded into Punycode, so they still technically fit this character requirement. Some operating systems and DNS servers allow you to have other characters (e.g., underscores), but doing so can cause incompatibilities, so avoid doing it.
• Other records have different allowances and requirements. Some examples are that SRV records will definitely have underscores, but hostnames must not, and TXT records can have just about anything.

Q: What’s the deal with DNS “propagation?”

Warning: This is a long answer. It leads to further questions: What are TTLs and how do they work? and how does adding a new domain or record work?

The idea of “propagation” is often thrown around in DNS conversations, and is generally used to indicate, “At some point in the near future, you’ll see the DNS additions or changes you just made or requested show up in the real world. But we can’t really say exactly when.” There are generally a few things that you have to wait for, and they may take a long time or a short time:

1. The record to actually be put into the relevant DNS servers. Examples:
   • If I register a new domain name of thenicestword.com, it will take a certain period of time for my registrar to tell the servers responsible for the “.com” top-level-domain that there is a new domain to add to its database. Once that system has been notified, it may be part of a batch job to add it.
   • If I create a new hostname (for example, an A record) to my existing domain, thenicestword.com, and I call it hifi.thenicestword.com, it takes a certain period of time for my DNS provider (e.g., DNS Made Easy) to create that record in all of its authoritative DNS servers (including anycast servers).
2. The other thing has to do with a TTL (time to live) associated with every record. The TTL tells caching servers how long to retain the record before passing the query up to the authoritative servers again. Regarding setting the TTLs, the default TTL for a domain can be defined in its SOA record, and all records that don’t have a specific TTL will inherit the SOA’s TTL. Let’s cover three different things you might do to a DNS record and indicate how TTL affects when each one is seen by clients:
   • You add a record. In addition to what was mentioned above about adding a record, there is a concept in DNS called NXDOMAIN (Non-eXistent Domain). If I query a record before it exists at all, the server will respond with an NXDOMAIN, and that NXDOMAIN will have a TTL associated with it. Until that TTL expires, the caching server won’t bother to ask the authoritative servers again.
   • You change a record. If a record exists already (say you have monkey.example.com A 192.0.2.50) and you change it to 198.18.19.20. If it had a TTL of 3600 (1 hour) and some caching server requested monkey.example.com 2200 seconds ago, you’d have to wait 1400 seconds before it would “notice” the new address, as 3600-2200=1400.
   • You delete a record. You delete hippo.example.com, which had a TTL of 1800 (30 minutes). But a caching server requested hippo.example.com 1200 seconds ago, it wouldn’t “notice” it was deleted for another 600 seconds, as 1800-1200=600.

Q: What’s a zone transfer and do we care anymore?

• Zone transfers are the “standards-based” way of getting data from a primary DNS server to a secondary server (formerly called master-slave, but changed to reflect the insensitivity that those words have attached to them). There is an AXFR (complete zone transfer), which is initiated by the secondary servers at a configured interval. There is also an IXFR (incremental zone transfer), which is usually requested as a result of a NOTIFY (a primary server initiates a connection to the secondary servers and says, “I have some changes for you, ask me what they are”).
• The reason we might not care as much anymore is that most DNS server software has its own mechanism for synchronizing between primary and secondary servers. Even the concept of primary and secondary servers may not apply in the same way as originally envisioned. For example, in a Microsoft Active Directory (AD) environment, you can make a DNS change on any domain controller running DNS server services, and that change is pushed to other domain controllers using an AD synchronization mechanism (not AXFR or IXFR). When disparate server types are used (for example, a secondary server is running BIND and the primary server is running NSD), the standards-based AXFR and IXFR can be used. Or perhaps your primary DNS is using NameCheap and your secondary is using GoDaddy, that would be a use for AXFR/IXFR.

Q: What are some DNS security standards?

• DNSSEC – Too complicated to even start tackling here. DNSSEC Mastery is a great book on the subject.
• DoH (DNS over HTTPS) and DoT (DNS over TLS) both provide TLS encryption for queries, but take different transports and approaches:
  • DOH! DNS over HTTPS explained | APNIC Blog (2018)
  • DoH uses https (HTTP/TLS) on port 443
    If you have a new enough version of dig:
    dig @8.8.8.8 +https thenicestword.com.
  • DoT uses TLS “natively” on port 853
    If you have a new enough version of dig:
    dig @8.8.8.8 +tls-ca thenicestword.com.

Q: Can you detect DoH or DoT?

• You may be able to figure out when a DoH exchange has taken place, but you cannot see what the query or the responses were. See Fingerprinting DNS over HTTPS (DoH) by John Choi.
• Capturing on DoT packets is much easier with a tshark/pcap display filter (let’s say you want to capture on interface eth0):
  tshark -ni eth0 -Y 'tls.handshake.extensions_alpn_str == "dot"'
• You may be able to figure out when a DoT exchange has taken place, but you cannot see what the query or the responses were, as that’s the whole point of it being encrypted…