Frequently Asked Questions
Common questions about DNS configuration, email authentication, DNSSEC, and security — answered clearly for administrators and learners alike.
DNS Basics
What is DNS and why does it matter?
DNS — the Domain Name System — translates human-readable domain names like thedns.guru into IP addresses like 203.0.113.42 that computers use to communicate. Without DNS, you would need to memorize numeric addresses for every service you use. It underpins virtually every internet-connected action: web browsing, email, API calls, and more.
How long does DNS propagation take?
DNS changes propagate based on the TTL (Time to Live) of the record being changed. If your A record has a TTL of 3600 seconds (1 hour), resolvers that cached the old record will serve it for up to 1 hour before re-querying. To speed propagation before a planned change, lower the TTL to 300 seconds (5 minutes) 24–48 hours in advance, make the change, then restore the TTL afterward.
What is a TTL and what should I set it to?
TTL (Time to Live) is the number of seconds resolvers are allowed to cache a DNS record. Lower TTLs mean changes propagate faster but generate more queries to your nameservers. Higher TTLs reduce query load but slow propagation. A good default is 3600 (1 hour) for stable records. Lower to 300 for records you change frequently or before a planned migration.
What is the difference between a domain registrar and a DNS host?
A domain registrar is where you purchase and renew your domain name. A DNS host (also called an authoritative DNS provider) is where your zone file and DNS records actually live. They are often the same company, but do not have to be. You can buy a domain at one registrar and point the NS records to a separate DNS provider like Cloudflare, AWS Route 53, or your own nameservers.
What does "NXDOMAIN" mean?
NXDOMAIN (Non-Existent Domain) is the DNS response code returned when the queried name does not exist in DNS at all. It is different from NOERROR with an empty answer, which means the name exists but has no records of the requested type. NXDOMAIN is commonly seen when a domain has expired, a record has been deleted, or there is a typo in the hostname.
DNS Records
Can I have multiple A records for the same hostname?
Yes. Multiple A records for the same name is called round-robin DNS and is a basic form of load balancing. Resolvers return all records and clients typically try them in order or pick randomly. It is not a substitute for a proper load balancer — there is no health checking — but it is simple and effective for distributing traffic across multiple servers.
Why can't I use a CNAME at my domain apex (@)?
RFC 1034 prohibits CNAME records from coexisting with other record types at the same name. Since the zone apex must have SOA and NS records, a CNAME there would violate the spec. Many DNS providers offer a workaround called ALIAS, ANAME, or CNAME flattening that resolves the target at query time and returns A/AAAA records directly — giving you CNAME-like behavior at the apex.
What is a PTR record and who controls it?
A PTR record maps an IP address back to a hostname (reverse DNS). PTR records live in the in-addr.arpa zone (for IPv4) or ip6.arpa zone (for IPv6) and are controlled by whoever owns the IP address block — not the domain owner. For shared hosting, your hosting provider controls the PTR. For dedicated IPs, you can usually set the PTR through your server provider's control panel.
How do I verify a DNS record has been published?
Use the dig command: dig example.com A +short for a quick answer, or dig @8.8.8.8 example.com TXT to query a specific resolver. Online tools like MXToolbox, whatsmydns.net, and the Google Admin Toolbox also let you check records from multiple global vantage points simultaneously.
Email & Authentication
What are SPF, DKIM, and DMARC — and do I need all three?
SPF (Sender Policy Framework) lists which mail servers are authorized to send email for your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages so receivers can verify they were not tampered with. DMARC ties them together with a policy (none/quarantine/reject) and reports on alignment failures. You need all three for comprehensive email authentication — SPF and DKIM alone leave gaps that DMARC closes.
My SPF record is failing — what is the most common cause?
The most common SPF failure is exceeding the 10 DNS lookup limit defined in RFC 7208. Each include:, a:, mx:, and redirect= mechanism that requires a DNS lookup counts toward the limit. Third-party senders (marketing platforms, CRMs, ticketing systems) each add includes, and the count adds up quickly. Use an SPF flattening tool or a managed SPF service to stay under the limit.
What is DMARC alignment and why does it matter?
DMARC alignment requires that the domain in the email's From: header matches the domain used for SPF or DKIM authentication. A message can pass SPF (sent from an authorized server) but fail DMARC alignment if the SPF domain does not match the From: domain. This prevents attackers from routing mail through a legitimate server while spoofing a different From: address.
What DMARC policy should I start with?
Start with p=none to collect aggregate reports without affecting mail delivery. Review the reports (via a service like Demarcly, DMARC Analyzer, or Mailhardener) to identify all legitimate sending sources. Once you are confident all authorized senders pass SPF or DKIM alignment, move to p=quarantine, then p=reject. Jumping straight to p=reject before auditing your senders will block legitimate mail.
Why is my email going to spam even though SPF, DKIM, and DMARC all pass?
Authentication (SPF/DKIM/DMARC) proves the mail is from who it claims to be, but it does not determine whether the mail is wanted. Spam filters also consider sender IP reputation, domain age, content signals, engagement rates, and blacklist status. Check your sending IP and domain against Spamhaus and other blocklists, review your email content for spam triggers, and ensure you're following list hygiene best practices.
DNSSEC
What does DNSSEC actually protect against?
DNSSEC protects against cache poisoning and DNS spoofing attacks where an attacker injects false DNS responses to redirect traffic to a malicious server. It does this by digitally signing DNS records so resolvers can verify the response came from the legitimate zone operator and has not been modified in transit. DNSSEC does not encrypt DNS traffic — it only provides authentication and integrity.
Should I enable DNSSEC on my domain?
Yes, if your registrar and DNS provider both support it. DNSSEC provides meaningful protection against cache poisoning. The main risk is misconfiguration — if your DNSSEC signatures expire or the DS record at the parent zone becomes mismatched, your domain will go completely dark for resolvers that validate DNSSEC. Use a DNS provider that automates key rotation and monitor with DNSViz.
What is the difference between DNSKEY and DS records?
DNSKEY holds the public key used to verify signatures in your zone. DS (Delegation Signer) is a hash of your DNSKEY that lives in the parent zone (e.g., the .com TLD zone) and links the parent's trust to your zone. The chain of trust works as follows: root zone signs TLD DS → TLD zone signs your DS → your DS validates your DNSKEY → your DNSKEY validates your zone records.
DNS Security & Threats
What is DNS cache poisoning?
Cache poisoning is an attack where a malicious actor injects forged DNS records into a resolver's cache. Once poisoned, the resolver serves the false record to all clients — silently redirecting them to attacker-controlled servers. DNSSEC prevents cache poisoning by allowing resolvers to verify record signatures. Source port randomization and 0x20 encoding are additional mitigations.
What is DNS tunneling?
DNS tunneling encodes arbitrary data — often command-and-control traffic or exfiltrated data — inside DNS queries and responses. Because DNS is rarely blocked at firewalls, it can be used to bypass network controls. Attackers use unusually long subdomains or high query volumes to exfiltrate data. Detection relies on monitoring query rate, entropy of subdomains, and unusual record types (TXT, NULL).
What is the difference between DNS over HTTPS (DoH) and DNS over TLS (DoT)?
Both encrypt DNS queries to prevent eavesdropping and tampering in transit. DoT (RFC 7858) uses TLS on a dedicated port (853) — easy to identify and monitor on networks. DoH (RFC 8484) sends encrypted DNS inside standard HTTPS on port 443 — indistinguishable from web traffic, making it harder for network operators to intercept but also harder to inspect. Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 (9.9.9.9) all support both.
Still have questions?
Explore the in-depth guides or reach out through the contact page.