Getting to Know DNS

What DNS is

DNS stands for Domain Name System (Sistema de Nomes e Domínios in Portuguese), responsible for converting website domain names people type into web browsers into IP numbers.
DNS operates mainly through two functions: examining and updating databases, and resolving domain names into network addresses.

The domain name distribution system began in 1984, making it possible for host names residing in a database to be distributed among multiple servers, thus reducing the load on any one server.
DNS is based on hierarchical names and allows various typed data to be registered in addition to the host name and IP (Internet Protocol).

Because the database is distributed, its size is practically unlimited and performance does not drop when new servers join.

The DNS server translates names into IP addresses and vice versa. And the classic division between primary (where the zone is edited) and secondary (which receives a copy through zone transfer) still applies — registro.br, for example, requires at least two servers answering for your domain.

What is Reverse DNS?

Reverse DNS resolves an IP address by looking up the domain name associated with the host. In other words, when we have a host’s IP address and do not know its domain address (the name given to a machine or other device accessing a network), we try to resolve the IP address through reverse DNS, which looks for the domain name associated with that address. Servers using reverse DNS can verify address authenticity by checking whether the current IP address matches the IP address reported by the DNS server. This prevents someone from using a domain they do not own to send spam, for example.

Basic concept

Reverse DNS turns 66.249.71.47 into dominio.com.br — an IP address into a name. The classic resolution path is: DNS resolver ➜ root servers ➜ ARIN (North American IP registry) ➜ Local ISP ➜ Acme Inc. DNS servers.

Whoever supplies your IP addresses must either add your entries to their DNS servers or delegate authority for your reverse entries to your DNS servers. Reverse DNS entries use a hostname with a reversed IP address and “.in-addr.arpa” appended to it. For example, “124.168.184.200.in-addr.arpa”.

Standard DNS uses entries of type “A Records,” while reverse DNS uses “PTR records” that look like “124.168.184.200.in-addr.arpa. PTR host.example.com” (whereas standard DNS would be something like “host.example.com. A 66.249.71.47”).

How standard DNS works

Many people only know “standard” DNS for resolving a hostname into an IP address, which would turn dominio.com.br into 66.249.71.47. This process starts with registering a domain. In Brazil, registro.br is one of the entities (registrars) where we can create new domains; there are hundreds of registrars worldwide.

When creating a domain, you must specify the DNS servers responsible for pointing the new domain to an IP address. In turn, registro.br sends that information to the root servers (technically, the parent server for your TLD). This way, anyone in the world can access your domains, and you can send them any IP address you want. You have full control over your domains and can even send IP addresses you do not own — in that case, you would need permission from the actual owner of the IP your DNS servers return as a resolution result.

The record types you will use

A DNS zone is a list of records, each with a type. These are the ones you encounter day to day:

If you administer email, three of these determine whether your message arrives or goes to spam: MX, the PTR of the outgoing IP, and the TXT for SPF, DKIM, and DMARC. The subject is detailed in The history of Postfix.

Queries in practice: dig

All the theory above can be checked with one command. dig comes in the package dnsutils (Debian/Ubuntu) or bind-utils (Fedora/RHEL):

# o básico: qual o IP deste nome?
dig +short exemplo.com.br

# um tipo específico
dig exemplo.com.br MX +short
dig exemplo.com.br TXT +short
dig exemplo.com.br NS +short

# DNS reverso
dig -x 203.0.113.10 +short

# perguntando a um resolvedor específico, ignorando o seu
dig @1.1.1.1 exemplo.com.br
dig @8.8.8.8 exemplo.com.br

# perguntando direto ao servidor autoritativo, sem cache no meio
dig @ns1.provedor.com.br exemplo.com.br

# a resolução inteira, passo a passo: raiz → TLD → autoritativo
dig +trace exemplo.com.br

The +trace is the command that truly teaches DNS — it shows on screen the same chain of questions described in this post, one line per step.

For daily use, two shortcuts:

host exemplo.com.br          # resposta curta e legível
resolvectl query exemplo.com.br   # o que o systemd-resolved está usando
resolvectl status            # quais servidores a sua máquina consulta
resolvectl flush-caches      # limpar o cache local

TTL: why changes take time to “take effect”

Every record carries a TTL — the time, in seconds, that resolvers around the world may cache that answer. It explains the most common question from someone changing servers: “I changed the IP and the site still opens on the old one”.

# ver o TTL restante (sem o +short)
dig exemplo.com.br | grep -A1 "ANSWER SECTION"

The golden rule for migration: lower the TTL to 300 seconds at least 24 hours in advance, make the change, confirm everything is right, and only then raise the TTL back to 3600 or more. Anyone who forgets this step lives with an entire day of traffic split between old and new servers.

What changed since 2017: DNSSEC and encrypted DNS

DNS was designed in 1983 without any concern for security — the response arrives in plain text and unsigned. Two layers were created to plug different holes, and they are often confused:

• DNSSEC handles authenticity: it cryptographically signs records so the resolver can detect whether someone tampered with the response along the way. It hides nothing — it only proves the response came from the right source. For .br it has been supported since 2009 and is enabled in registro.br’s panel.
• DoT (DNS over TLS, port 853) and DoH (DNS over HTTPS, port 443) handle privacy: they encrypt queries so your Internet provider and anyone in between cannot see which sites you look up. They say nothing about whether the response is correct.

One complements the other. In systemd-resolved, enable DoT like this:

sudo tee /etc/systemd/resolved.conf.d/dot.conf >/dev/null <<'EOF'
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
DNSOverTLS=yes
DNSSEC=allow-downgrade
EOF

sudo systemctl restart systemd-resolved
resolvectl status | grep -E "DNSOverTLS|DNSSEC|Current DNS"

# conferir se um domínio está assinado com DNSSEC
dig exemplo.com.br +dnssec | grep -E "RRSIG|flags:"
# a flag "ad" (authenticated data) na resposta indica validação bem-sucedida

When something does not resolve

Diagnostic checklist, from most to least likely:

1. Is it the cache? resolvectl flush-caches and test again. Compare with dig @1.1.1.1, which bypasses your resolver.
2. Does the authoritative server respond? dig @ns1.provedor.com.br o-dominio. If the authoritative server does not respond, the problem is not on your end.
3. Is the delegation correct? dig o-dominio NS +trace — check whether the NS records published by the registrar match those in the zone.
4. Is the old TTL still valid? If you just made the change, wait for the previous TTL to expire.
5. Broken DNSSEC? An expired signature takes the entire domain down for validating resolvers. dig +cd disables validation: if it works with +cd and fails without it, you found the culprit.
6. Is it your machine? resolvectl status shows which server is actually being used — often it is not the one you configured.

How the Internet works

A series made by Nic.br about how the Internet works. If you are creating or administering a mail, web, or DNS server, pause and watch these 4 videos from Nic.br.

• Part 1: The IP protocol
• Part 2: Autonomous Systems, BGP, Internet exchange points
• Part 3: DNS
• Part 4: Internet governance
• The importance of DNS in networks

Links

• registro.br — where you register domains .br and configure DNSSEC
• root-servers.org — the live map of root server instances
• DNSViz — visualizes a domain’s DNSSEC chain and identifies where it broke

Here on the blog: The history of Postfix explains why MX, PTR, and SPF determine your email’s delivery; About the hosts file shows the shortcut that existed before DNS — and is still consulted first; and the Linux Servers Series puts all of this into practice.