reveal // how dns works

dns is just a phonebook nobody reads until something breaks

every time you type a domain into a browser, something has to translate that human-friendly name into an ip address a computer actually understands. that translation layer is dns, and it's quietly running in the background of literally everything you do online. today we're pulling back the curtain with one command so you can see it happen yourself.

dig +short example.com

run that on your own machine right now. you'll get back an ip address, maybe two. that's it. that's the whole trick. you asked "hey, what's the address for example.com" and dns answered.

breaking down the command

dig stands for "domain information groper" (yes, really) and it's the standard tool for querying dns servers. it's built into most linux and mac systems, and available on windows through wsl or a quick install.

+short tells dig to skip the verbose output and just give you the answer. without it, you'd get a wall of technical metadata about the query, the server that answered, timing info, and more. that full output is useful when you're troubleshooting, but for a quick lookup, +short keeps it clean.

example.com is just the domain you're asking about. swap it for your own site, your work domain, whatever you want to check.

why this matters for defenders

dns feels invisible until it's the reason something is broken or exposed. as someone protecting your own systems, this lookup is one of the fastest sanity checks you have. a few real reasons to run it regularly on domains you own:

catching stale records. moved your website to a new host? migrated servers? if dig still shows the old ip, visitors (and you) might be hitting a server you no longer control or one that's about to get decommissioned.

spotting unauthorized changes. if someone gets into your domain registrar or dns provider account, one of the first things they'll do is repoint your records somewhere else, often to intercept traffic or redirect visitors to a phishing page. running dig +short periodically and comparing it against what you expect is a dead simple tripwire.

verifying your own infrastructure. if you're managing servers, checking dns propagation, or confirming a cname or a record change actually took effect, this is the fastest way to check without opening a browser and dealing with cached pages.

going one level deeper

dig can query more than just the main "a" record. here are a few variations worth knowing for your own defensive checks:

dig +short MX example.com
dig +short TXT example.com
dig +short NS example.com

MX records show you where mail for that domain gets routed, useful for confirming your email provider hasn't been silently changed. TXT records often hold spf, dkim, and dmarc info, the stuff that helps prevent people from spoofing emails using your domain. NS records show which nameservers are authoritative for the domain, meaning who actually controls where that domain points. if you don't recognize the nameservers listed for your own domain, that's worth investigating immediately.

the flip side: what dns lookups can't tell you

running dig on your own domain is completely fine and normal, it's public information anyone can query. but understand what it is and isn't. it tells you where a domain points, not what's running on that server, not whether it's secure, and it's not a scanning or exploitation tool. if you're checking someone else's domain out of curiosity, fine, that's public data. the moment you start poking at ports, services, or systems that aren't yours, you've crossed from "checking a phonebook" into territory that needs explicit permission. keep your curiosity pointed at your own infrastructure.

the takeaway

dns is the internet's phonebook, and dig +short is how you flip to the right page without wading through the whole book. as a defender, make it a habit: check your domain's records after any hosting change, keep an eye on who your nameservers actually are, and set a calendar reminder to glance at your dns config every few months. it takes ten seconds and it's one of the cheapest ways to catch a hijacked domain or a misconfiguration before it turns into a real incident. run the command, know your own answers, and you'll notice fast when something doesn't match.