Every time you open your bank's site you type a name —bank.com—, never a row
of numbers. But machines don't connect by name; they connect by IP address. Somewhere
between your keyboard and the server, someone translates that name into the right
address. That translator is DNS, and it's so invisible that you only
notice it when it fails —or when it hands you the wrong address—.
What DNS is
DNS solves a human problem before a technical one: remembering names is easy, remembering
numeric addresses is not. Without it, to reach your bank you'd have to memorize something
like 203.0.113.42 instead of bank.com.
DNS (Domain Name System) is the system that translates human-readable names —bank.com— into the numeric IP addresses machines use to connect. It is, literally, the address book of the internet.
Nobody types the IP: you type the name and DNS does the translation underneath. And it isn't one giant server, but a hierarchical, distributed system spread across the whole world.
How a name gets resolved
When you type a name, the translation isn't done by your browser alone: it delegates to a chain of servers that hand the question along until they find the authoritative answer.
- Your browser asks a resolver —your internet provider's, or a public one like
8.8.8.8—: "what's the IP forbank.com?". - The resolver queries the hierarchy: first the root servers, which send it to the TLD servers (the ones for
.com), and those to the domain's authoritative server. - The authoritative server —the one in charge of
bank.com— returns the definitive IP. - The resolver hands that IP to your browser and, along the way, caches it so it doesn't repeat the whole walk next time.
The key point: DNS is hierarchical and distributed. No single server knows all of the internet; each level only knows who to ask at the next one. That's how the system scales to billions of names without a central point that knows everything.
Cache and TTL
Repeating that full walk on every visit would be slow and expensive. That's why every DNS answer carries a TTL (Time To Live): a number of seconds during which the answer is considered valid and can be reused.
That value is cached in several layers at once: in the resolver, in your machine's operating system, and in the browser. As long as the TTL hasn't expired, all those layers answer with the stored value without asking again.
That's why a DNS change "takes time to propagate". Nothing actually propagates: what happens is that the existing cache has to expire before the new value gets queried. A short TTL speeds up changes; a long one eases the load but lengthens the wait.
Record types
A domain doesn't store just one thing: it stores different records, each with a purpose. The ones you'll see most:
- A / AAAA — map a name to an IP address.
Apoints to an IPv4;AAAA, to an IPv6. They're the basic name → address translation. - CNAME — an alias: it says "this name is actually another name". Handy so
www.bank.compoints tobank.comwithout repeating the IP. - MX — tells where the mail goes for the domain: which servers receive messages addressed to
@bank.com. - TXT — free text used for verifications and mail policies like SPF and DKIM, which help prevent sender spoofing.
Common mistakes and when DNS "lies"
Almost every DNS problem isn't a failure of the system, but a misunderstanding of how the cache works or of what DNS doesn't protect.
"I changed the DNS and it still doesn't show up, it's broken." It's almost never broken. What you're seeing is the cache answering with the old value until its TTL expires. There's nothing to fix: you have to wait for the cache to lapse (or flush it where you can).
Beyond the cache, there are two uncomfortable truths about DNS worth being clear on:
- Traditional DNS travels unencrypted. Anyone on your network —a public Wi-Fi, a tampered router— can see which domains you query and even alter the response. DoH (DNS over HTTPS) and DoT (DNS over TLS) encrypt those queries to close that window.
- DNS is a single point of failure. "The servers are alive but the site won't load" is often DNS down: if nobody can resolve the name, it doesn't matter that the service behind it is perfectly healthy. Nobody reaches it.
And here's the "lies" from the title: if an attacker manages to slip in a false answer —cache poisoning—, DNS will hand you the address of their server believing it's your bank's. Against that there's DNSSEC, which we'll see next.
The banking angle
In banking, name resolution stops being an infrastructure detail and becomes a critical service. Three pieces explain why:
- Internal DNS / split-horizon. Many names resolve only inside the corporate network: core systems, admin consoles, internal services that shouldn't exist for the outside world. The same name can return an internal IP to an employee and nothing to someone outside.
- Reliable resolution as a critical service. If DNS goes down, everything goes down —even if every system is healthy—, because nothing can find anything. That's why corporate DNS is designed with redundancy and monitoring, just like the database or the network.
- DNSSEC. It cryptographically signs the answers so the client can verify they come from the real authoritative server and weren't altered. It's the direct defense against cache poisoning and the spoofing of a banking domain.
DNS is invisible until it fails: nobody thinks about the address book until it returns the wrong address or stops answering. That's why, in serious environments, it isn't treated as a minor service: it's designed with redundancy, encrypted and signed. The translation has to always be there, and it has to be the right one.
