DNS for Solo Builders: What You Actually Need to Know

Most developers interact with DNS the way most drivers interact with their engine: they know it exists, they know it matters, and when something goes wrong they open the hood and stare at it hoping the problem will announce itself. It rarely does.

DNS is the infrastructure layer most solo builders cargo-cult. You copy settings from a tutorial, toggle some switches in Cloudflare, and move on. It works until it doesn't, and when it doesn't, you have no mental model for debugging it. That's fixable in about ten minutes of actual understanding.

Five Record Types. That's the Whole List.

DNS has dozens of record types. You need to know five. Maybe six if you get into DKIM, but that's email territory and a separate conversation.

• A record: Maps a domain name to an IPv4 address. When someone types example.com into a browser, the A record is what tells the internet "that name lives at 203.0.113.42." One domain can have multiple A records for load balancing, but as a solo builder you'll almost always have one.
• AAAA record: Same thing, but for IPv6 addresses. The name is not a joke about how long IPv6 addresses are, though it works as one. If your server has an IPv6 address, add one. If you're behind Cloudflare's proxy, they handle this for you.
• CNAME record: An alias. Instead of pointing to an IP address, it points to another domain name. www.example.com might be a CNAME pointing to example.com. Your hosting provider will often give you a CNAME target like your-app.railway.app instead of a raw IP, because their infrastructure might change IPs and a CNAME follows the target automatically. One constraint: you cannot put a CNAME on the root domain (example.com itself) in standard DNS. Cloudflare gets around this with a feature they call CNAME flattening, which is why their instructions sometimes work when other providers' don't.
• MX record: Mail exchange. Tells sending mail servers where to deliver email for your domain. If you use a service like Fastmail, Proton Mail, or Google Workspace for email, you'll point your MX records at their servers. The priority number matters when you have multiple MX records: lower numbers get tried first.
• TXT record: A plain text string attached to your domain. Used for verification ("prove you own this domain by adding this specific TXT record") and for email authentication (SPF, DKIM, DMARC). You'll accumulate these over time as services ask you to prove ownership. They're harmless and don't affect how your site works.

That's it. A records for IP addresses, CNAMEs for aliases, MX for email, TXT for verification. If someone mentions SRV or NAPTR records, you can safely ignore them until you're running a SIP phone system or something equally niche.

Cloudflare and the Orange Cloud

Most solo builders end up on Cloudflare for DNS. Not because they evaluated alternatives, but because someone told them to use it and the free tier is generous. That's fine. It's a reasonable default. But there's a specific thing about Cloudflare that trips people up if they don't understand what it's doing.

Every DNS record in Cloudflare's dashboard has a toggle: an orange cloud (proxied) or a gray cloud (DNS only). This is more important than most of the other settings on the page.

When the cloud is gray, Cloudflare acts as a pure DNS server. Someone asks "where is example.com?" and Cloudflare answers with your server's actual IP address. The connection goes directly from the visitor to your machine. Cloudflare is just the phone book.

When the cloud is orange, Cloudflare inserts itself as a reverse proxy. The visitor connects to Cloudflare's servers, and Cloudflare connects to yours on their behalf. Your server's real IP address never appears in DNS lookups. This gives you DDoS protection, SSL termination, caching, and some security features. It also means Cloudflare is decrypting and re-encrypting all your traffic, which matters if you care about end-to-end encryption to the client.

The practical consequence: if you're running a web server, orange cloud is usually what you want. If you're running something that isn't HTTP — a mail server, a game server, an SSH endpoint — the orange cloud will break it. Cloudflare's proxy only understands HTTP and HTTPS on standard ports. Everything else needs the gray cloud.

# Check what IP address your domain actually resolves to
dig +short example.com

# If proxied through Cloudflare, you'll see Cloudflare IPs (104.x.x.x or 172.x.x.x)
# If DNS-only, you'll see your actual server IP

One more detail that catches people: Cloudflare Tunnel. If you're using cloudflared to expose a local service without a public IP (common with CGNAT on home internet), you don't set A records at all. The tunnel creates a CNAME record automatically that points to Cloudflare's tunnel infrastructure. The orange cloud is mandatory in this setup. Trying to gray-cloud a tunnel record will break the connection.

TTL and the Propagation Myth

TTL stands for time to live, measured in seconds. It tells DNS resolvers how long they're allowed to cache the answer before asking again. Set a TTL of 3600 and resolvers will cache your record for one hour. Set it to 300 and they'll cache for five minutes.

When you hear someone say "DNS propagation takes 24-48 hours," they're repeating a myth that was approximately true in 2005 and hasn't been accurate for a long time. Here's what actually happens.

You change a DNS record. Your DNS provider (Cloudflare, Route 53, whoever) updates its authoritative servers within seconds. From that moment, any resolver that asks for a fresh answer will get the new one. The "propagation" delay is resolvers around the world still serving cached copies of the old answer until their cached TTL expires.

If your old TTL was 86400 (24 hours), then yes, some resolvers might serve stale data for up to 24 hours. If your old TTL was 300 (five minutes), the worst-case wait is five minutes. The trick: if you know you're about to make a change, lower the TTL first. Set it to 300, wait for the old TTL to expire, then make your change. The transition will be nearly instant.

# Check the current TTL of a record
dig example.com +noall +answer

# Output shows TTL in seconds (the number before IN)
# example.com.    300    IN    A    203.0.113.42

Cloudflare proxied records ignore the TTL you set and use their own short TTL (usually 300 seconds). This is another reason the orange cloud is convenient: DNS changes take effect in minutes regardless of what you configured.

The other common "it's not working yet" scenario has nothing to do with DNS at all. You changed the record, DNS resolved correctly, but your browser cached the old page. Hard refresh (Cmd+Shift+R) or incognito window. Check DNS resolution separately from browser behavior. dig tells you what DNS thinks. Your browser has its own opinions.

The Solo Builder DNS Setup

Here's the configuration that covers 90% of solo builder needs. One domain, one server, email through a third-party provider.

# Root domain -> your server
example.com          A       203.0.113.42     (proxied)

# WWW redirect (CNAME to root, Cloudflare handles the redirect)
www.example.com      CNAME   example.com      (proxied)

# Email (example: Fastmail)
example.com          MX      10 in1-smtp.messagingengine.com
example.com          MX      20 in2-smtp.messagingengine.com

# Email authentication
example.com          TXT     "v=spf1 include:spf.messagingengine.com ~all"

# Domain verification (whatever services ask you to add)
example.com          TXT     "google-site-verification=abc123..."

If you're using Cloudflare Tunnel instead of a public IP:

# Tunnel replaces the A record with an auto-generated CNAME
example.com          CNAME   .cfargotunnel.com    (proxied, mandatory)
www.example.com      CNAME   example.com                     (proxied)

The total number of records for a typical solo builder domain is somewhere between 5 and 12. If you have more than 20, something has probably accumulated that should be cleaned up.

Debugging DNS

When something doesn't resolve correctly, the debugging process is straightforward. Three commands cover nearly every case.

# What does the authoritative nameserver say? (bypasses all caches)
dig @ns1.cloudflare.com example.com

# What does Google's public resolver say? (tests if the change has reached public DNS)
dig @8.8.8.8 example.com

# Full trace from root servers down (shows where a resolution breaks)
dig +trace example.com

If the authoritative nameserver has the right answer but Google's resolver doesn't, the old record is still cached. Wait for the TTL to expire. If the authoritative nameserver has the wrong answer, your change didn't save correctly or you're editing DNS in the wrong provider. Check which nameservers your registrar is pointing to. It's common to buy a domain at one registrar, then change nameservers to Cloudflare, and then accidentally edit DNS at the registrar instead of Cloudflare. Both dashboards will happily let you make changes. Only the one your nameservers point to will matter.

The Catch

DNS is simple until it isn't. The five record types above cover standard web infrastructure for a solo builder, but there are edges where it gets genuinely complicated. DNSSEC adds a cryptographic signing layer that most solo builders don't need but some registrars enable by default, causing mysterious failures when you switch DNS providers. Wildcard records (*.example.com) interact with proxied Cloudflare records in ways that aren't always intuitive. And email deliverability — getting SPF, DKIM, and DMARC all configured correctly so your emails don't land in spam — is a deep enough topic to fill its own post.

The other limitation worth naming: if you build your entire infrastructure around Cloudflare's free tier, you have a single point of dependency on a company that can change its terms of service whenever it wants. The free tier has been stable for years. That's not a guarantee it stays that way. Knowing how DNS works at the protocol level means you can move to any provider in an afternoon. Not knowing means you're locked to whichever dashboard you learned to click through.

Understanding Over Memorizing

DNS doesn't reward memorization. It rewards having a mental model. Records map names to values. Resolvers cache those mappings for the TTL duration. Proxies sit between the client and your server. Everything else is details you can look up when you need them.

The solo builders who waste hours on DNS are the ones debugging without a model. They change a record, reload their browser, see no change, change it again, reload again, and spiral into increasingly random modifications until something appears to work for reasons they can't explain. The ones who spend ten minutes understanding how resolution actually works never have that experience. They make a change, verify it with dig, and move on to the work that matters.

Infrastructure knowledge compounds the same way domain expertise does. Learn it once, use it forever, stop guessing at A records.