This post is part of my Web Application Security learning journey. On Day 1, I focused on understanding how DNS actually works under the hood — and why it's such a critical attack surface.
The Domain Name System, or DNS, sits at the heart of how the internet works. It takes simple website names like www.github.com and turns them into IP addresses — basically, the language computers use to talk to each other. So, when you type a web address in your browser, DNS jumps into action, searching through its network of servers to track down the right IP address. That's how your browser knows where to go. DNS isn't just helpful; it's essential. Since it determines where all internet traffic goes, it also ends up being a hot target for hackers and security threats.
Full DNS lookup process: an explanation
Because computers on the internet communicate using IP addresses rather than human-readable names, your browser must first convert the domain name into an IP address when you type www.medium.com. The request is sent to a recursive DNS resolver, typically offered by your internet service provider or a public DNS service, if the IP address cannot be located locally.
1.The resolver then starts the DNS hierarchy lookup by contacting a root name server.
2. This server provides the addresses of the.com TLD name servers since it is aware of which servers are in charge of top-level domains but does not know the IP address of medium.com.
3.In order to find out where medium.com is managed, the resolver then gets in touch with a.com TLD name server. This server does not know the final IP address either, but it does reply with the address of Medium's authoritative DNS server, which is in charge of maintaining the domain's actual DNS records.
4. Lastly, the IP address linked to www.medium.com is returned by the resolver's query to Medium's authoritative DNS server.
The resolver then sends this IP address back to the browser, often caching it for future requests, and the browser uses the IP to establish a connection with Medium's web server and load the website.
What happens after DNS lookup is complete?
The browser initiates the connection and data transfer process once the DNS lookup is finished and it has the website's IP address. It starts by connecting to the server's IP address on the relevant port, which is typically port 80 for HTTP or port 443 for HTTPS. The next step, if the website is HTTPS, is a TLS handshake, in which the browser and server agree on encryption techniques, the server displays its SSL/TLS certificate, and the browser confirms that the certificate is legitimate and issued by a reliable Certificate Authority. The browser sends an HTTP request (such as a GET request) requesting a particular resource, like the homepage, after a secure connection has been established.
DNS, or Domain Name System, works in a few different ways, depending on how you look at it. You can break it down by what the servers actually do, the kind of info they hold, or how you ask them for answers. All of that matters, especially if you care about how the internet works or worry about security.
Let's start with the server roles — there are four big ones.
1.First up, the recursive DNS resolver. That's the one your phone or laptop talks to first, usually from your internet provider or a big service like Google or Cloudflare. Think of it as your helper that goes out and finds the answer for you. The resolver then checks in with a root name server, which is basically the top boss in the DNS world. It doesn't know the exact IP addresses for websites, but it knows where to send your helper next.
2. From there, the resolver heads over to the TLD name servers — the ones that handle big domains like .com, .org, or .in. These servers tell your resolver, "Hey, for that domain, talk to this specific authoritative server."
3. And that's the last stop: the authoritative DNS server. This one actually has the real records for the domain, including the IP address you need. The resolver grabs that info and finally gives you the answer, so your browser can load the right website.
Let's break down DNS a bit more. First, you can sort DNS by record types, which basically tells you what kind of info gets stored.
An A record links a domain name to an IPv4 address. If you're using IPv6, that's where the AAAA record comes in — it maps the domain to an IPv6 address instead. CNAME records are for aliases; they point one domain name to another. MX records decide which mail servers handle your email, and NS records show which name servers are in charge of a domain. Then there are TXT records. They hold plain text but play a big role in things like SPF and DKIM for email security or proving you own a domain, so they really matter for security. PTR records work the other way around — they map an IP address back to a domain name, which is called a reverse DNS lookup.
What attacks that can happen at this stage?
DNS spoofing — sometimes called DNS cache poisoning — is a classic DNS attack where an attacker tricks a DNS resolver into saving a fake IP address for a legit domain. Most of the time, the fake site looks just like the real one.
Another one you'll see a lot is the Man-in-the-Middle (MITM) attack during DNS lookups. Regular DNS traffic isn't encrypted; it just flies around in plain text over UDP on port 53. If you're on public Wi-Fi at a coffee shop or airport, attackers on the same network can jump in, mess with DNS responses, and quietly send you to the wrong website.
There's also the rogue DNS resolver attack, where someone changes your device's DNS settings or hacks your router, so everything points to a malicious DNS server. Now, every single domain your device looks up can be hijacked.
DNS hijacking at the network level is a whole other beast. Attackers go after the big stuff — ISP infrastructure, router firmware, or major DNS services.
Then there's DNS downgrade or blocking. Attackers can block real DNS responses or mess up the resolution process, which forces systems to use less secure DNS resolvers or even fall back to old-fashioned, unencrypted HTTP connections.