DNS setup mistakes can erase rankings, break email delivery, and expose domains to security risks. This guide walks through the configuration errors that actually matter—propagation misunderstandings, missing or duplicate records, TTL misjudgments, and subdomain oversights—with the decision logic and checks that prevent them.
DNS records interpret values differently based on whether they end with a dot. A CNAME pointing to 'cdn.example.com' (no trailing dot) is treated as relative to your zone—if you're configuring 'yoursite.ca', the resolver appends that and looks for 'cdn.example.com.yoursite.ca', which doesn't exist. The correct entry is 'cdn.example.com.' with the trailing dot, signaling an absolute FQDN. This trips up teams migrating between DNS providers because some interfaces auto-append the dot, others require it manually. MX records have the same behaviour: 'mail.protonmail.ch' without the dot becomes a subdomain query under your own zone. The fix is simple but non-obvious—always confirm whether your provider's UI treats entries as absolute or relative, and when in doubt, include the trailing dot for any external hostname. Missing this breaks CDN delivery, email routing, and third-party integrations silently until someone notices the bounce logs.
The '24-48 hour propagation' advice is a legacy holdover that obscures how DNS actually updates. Propagation is governed by Time To Live values, not a fixed global clock. If your A record has a TTL of 3600 seconds and you change the IP, recursive resolvers that cached the old value will serve it for up to one more hour, then fetch the new one. The 48-hour myth comes from old defaults (86400 seconds) and assumes every resolver cached your record at the worst possible moment. The practical mistake is leaving TTLs high during a migration or provider switch—if you need to roll back, you're stuck waiting out the cache window. Best practice: 48 hours before any planned change, lower relevant TTLs to 300 or 600 seconds, make the change, confirm it works, then raise TTL back to reduce query load. For stable records, 3600-7200 is reasonable. For records tied to CDN failover or active-active setups, keep TTL low permanently to enable fast traffic steering.
A hostname can have multiple A records (the resolver picks one, usually round-robin) or a single CNAME, but never both simultaneously. Attempting to set both creates undefined behaviour—some resolvers ignore the CNAME, others discard the A records, most just break. This happens when a subdomain is CNAMEd to a CDN, then someone adds an A record for the same name thinking it will 'also' point traffic somewhere. It won't—it invalidates the CNAME. The same host can't point to two places using different record types. Another variant: multiple A records for a primary domain where the application expects session stickiness. DNS round-robin sends requests to different IPs with no awareness of sessions, so users hit different origin servers mid-session unless there's a load balancer or shared session store. If you need geographic distribution or failover, use a traffic management service (Route 53, Cloudflare Load Balancing, NS1) rather than stacking raw A records and hoping DNS handles logic it wasn't designed for.
SPF, DKIM, and DMARC are TXT records that prove your domain authorizes specific mail servers and tell receivers what to do with forgeries. Missing them entirely is common for new domains or teams who assume their email provider 'handles it'—providers handle DKIM signing, but you must publish the corresponding public key in DNS. An SPF record like 'v=spf1 include:_spf.google.com ~all' permits Google Workspace to send mail on your behalf; without it, cold emails to prospects land in spam or get rejected outright. The '~all' softfail vs. '-all' hardfail decision matters—softfail during initial setup lets legitimate edge cases through, hardfail after confirming all senders are covered prevents spoofing. DMARC ('v=DMARC1; p=none; rua=mailto:reports@yourdomain.ca') starts in monitor mode, sending aggregate reports so you can see who's sending as you before enforcing 'p=quarantine' or 'p=reject'. Skipping these records doesn't just hurt deliverability—it leaves your domain open to exact-match phishing, and certain enterprise spam filters automatically downrank domains without DMARC.
A wildcard DNS entry ('*.yourdomain.ca') resolves any subdomain that doesn't have an explicit record—useful for SaaS multi-tenancy or dynamic subdomain generation, risky everywhere else. The mistake is setting a wildcard A or CNAME without auditing what subdomains actually exist or might be guessable. If 'staging.yourdomain.ca' or 'dev.yourdomain.ca' has no explicit record, the wildcard catches it and points traffic to your production server or CDN, potentially exposing non-public environments. Worse, wildcard records interfere with Let's Encrypt DNS-01 challenges if you later want a wildcard certificate—LE creates a TXT record at '_acme-challenge.yourdomain.ca', but if a wildcard CNAME points everything elsewhere, the validation lookup fails. The safe approach: define explicit records for every subdomain you actually use, and only deploy a wildcard if your application architecture specifically requires catch-all behaviour. If you do use one, pair it with firewall rules or application-layer authentication so unknown subdomains don't serve content.
When you delegate a subdomain to another nameserver (common for third-party platforms or regional microsites), you create NS records at the parent zone pointing to the child's authoritative servers. The mistake is creating both an NS delegation and an A or CNAME for the same name—the NS takes precedence, so the A/CNAME is ignored, and if the delegated nameservers don't have the expected record, resolution fails. Example: 'shop.yourdomain.ca' has NS records pointing to Shopify's nameservers, but you also set an A record at your primary DNS provider thinking it will 'override'—it won't. Another error is delegating without confirming the target nameservers are actually configured. You set NS records pointing to 'ns1.platform.com', but the platform hasn't yet created the zone on their side, so queries return SERVFAIL. Always verify the delegation target is live before updating the parent NS records. For subdomain handoffs, coordinate TTL reduction on both sides, update NS records, confirm resolution with 'dig @8.8.8.8 subdomain.yourdomain.ca NS', then let the old TTL expire before changing anything else.
CAA (Certification Authority Authorization) records specify which CAs are allowed to issue certificates for your domain. If you publish 'yourdomain.ca. CAA 0 issue "letsencrypt.org"', only Let's Encrypt can issue certs—requests to DigiCert, Sectigo, or any other CA will be refused. The mistake is setting a CAA record for one use case (locking a production domain to a specific CA for security) and forgetting it when a different team tries to provision a cert elsewhere. This breaks silently—the cert order just fails with a CAA violation error that non-DNS-aware teams don't recognize. Another variant: setting CAA at the root but not considering subdomains. CAA is inherited unless overridden, so if your root allows only Let's Encrypt but a subdomain is delegated to a platform that uses a different CA, issuance fails. If you use CAA, document it clearly in runbooks and set up monitoring (some CAs send email warnings). If you don't need the security constraint, don't set CAA at all—absence means any CA can issue, which is the default and expected state for most domains.
Propagation time equals the TTL (Time To Live) of the record you changed. If the old record had a TTL of 3600 seconds, resolvers that cached it will serve the old value for up to one more hour after your change, then fetch the new one. There's no fixed 24-48 hour window—that advice assumes worst-case caching of old default TTLs. Lower TTL before planned changes to reduce the window.
You can create multiple A records for the same hostname, and DNS will return all of them (or rotate them), but this is round-robin, not intelligent failover. If one IP is down, DNS still returns it—clients try it, wait for timeout, then retry. For actual redundancy, use a load balancer at a single IP or a managed DNS service with health-check-based failover like Route 53 or Cloudflare.
DNS distinguishes absolute FQDNs (which end in a dot, meaning 'don't append anything') from relative names (no dot, so the zone name is appended). Some DNS provider UIs auto-append the trailing dot behind the scenes, treating all entries as absolute. Others require you to type it manually. If your CNAME or MX value doesn't resolve, check whether the interface expects the dot or adds it for you.
DNS doesn't allow a hostname to have both—CNAME means 'this name is an alias, go look up that other name instead,' so any other record type at the same name is invalid. Most authoritative servers will reject the configuration or ignore one of the records unpredictably. Remove the A record if you want the CNAME, or remove the CNAME if you want direct A records.
Yes, even if you send nothing, because absence of these records lets spammers forge your domain in phishing emails with no authentication failure. Receivers can't tell the difference between your silence and a spoofed message. At minimum, publish SPF with '-all' (hardfail, no one is authorized) and DMARC with 'p=reject' to explicitly disavow all mail and protect your domain's reputation.
If those subdomains don't have explicit records, yes—the wildcard catches them and resolves to whatever target you specified. Anyone guessing 'staging.yourdomain.ca' or 'dev.yourdomain.ca' will reach your wildcard destination. Either create explicit records for known subdomains (even if they point to 127.0.0.1 or return NXDOMAIN) or secure wildcard endpoints with authentication at the application layer.