DEV Community: VickkyKruz NetSec

Why the Web Centralised: The Protocol Gaps That Platforms Filled

VickkyKruz NetSec — Sat, 18 Jul 2026 15:37:29 +0000

Five posts in, this series has been circling one idea from five different angles.

ARPANET connected four trusted institutions and needed no security, because everyone on it was known. Packets travel with their addresses exposed, like postcards, because routing demands it. The OSI layers each trust the layer beneath them to have done its job honestly. IP addresses locate a machine but say nothing about who is operating it. And DNS, the internet's phone book, cannot verify that its own answers are genuine.

Every post lands in the same place: the foundational protocols were built for connection, not control. They answered "how do we make these machines talk to each other" brilliantly, and left almost everything else to someone else.

This interlude is about that "someone else."

Because here is the thing I want to argue, and I think the evidence for it is strong: the web did not centralise despite its open, decentralised design. It centralised because of it. Every gap the original protocols left open was eventually filled by a company. And every company that filled a gap became a chokepoint.

That is not a betrayal of the web's architecture. It is the market completing an unfinished protocol.

The Gaps Were Real, and They Were Deliberate

Let us be precise about what the early web actually shipped, because the story only works if we are honest about the technical facts.

Tim Berners-Lee's web gave us three things: a way to name resources (URLs), a way to request them (HTTP), and a way to structure them (HTML). That combination was extraordinarily powerful and extraordinarily minimal. It let any machine serve a document and any machine request one, with no permission needed from anybody. That openness is why it won.

But look at what it did not include.

It did not include a way to know who you were talking to. As we established in Post 4, IP addressing tells you the address of a machine, not the identity of the person, organisation, or thing responsible for that machine. The protocol stack was built to locate endpoints, not to authenticate the humans behind them. The internet was built without any native way of knowing who and what we are connecting to, and because of that, everyone offering a service has had to cobble together their own workaround. That patchwork is why the average business user today juggles something like 191 passwords. Every site had to invent its own identity system, because the web never provided one.

It did not include a way to pay for anything. This one is my favourite, because the evidence is sitting in the specification itself, in plain sight, and has been for over thirty years. HTTP status code 402 is called "Payment Required." It has been in the HTTP specification since the early 1990s. And its official definition has always been, essentially, reserved for future use. The people who designed the web knew a payment layer would be needed. They left a placeholder for it. And then it sat dormant for three decades, because the web was never given a native payment primitive, and the core architecture of the internet has no way to send money the way it transmits information.

Think about what that means. There is a status code in every HTTP implementation on earth, waiting for a payment system that the protocol never delivered.

It did not include a way to establish trust. HTTP will faithfully fetch you a document from a stranger's server. It has no opinion whatsoever about whether that stranger is honest, whether the goods they are selling exist, or whether they will take your money and vanish. Trust was simply not in scope.

It did not include a way to find anything. The web gave us links, but no directory, no index, no search. If you did not already know a URL, or know someone who did, the resource was effectively invisible to you.

And it did not include a way to store state. HTTP is stateless by design. Each request stands alone, knowing nothing of the last. Elegant, scalable, and completely incapable of remembering that you are logged in, what is in your basket, or who you are.

None of these were oversights by careless engineers. They were the deliberate minimalism that made the web deployable. A protocol that had tried to standardise identity, payment, trust, discovery, and state in 1991 would have been so complex, so contentious, and so slow to agree that it would very likely never have shipped at all. The web won because it was small enough to adopt without asking anyone's permission.

But an unfinished protocol does not stay unfinished. The gaps get filled. The only question is by whom.

Every Gap Became a Company

Here is the pattern, and once you see it, the entire shape of the modern web snaps into focus.

The identity gap became login providers. Because there was no protocol-level way to prove who you are, every website built its own account system. That was miserable for users and miserable for developers, so a solution emerged: let one big platform handle identity for everyone. "Sign in with Google." "Log in with Facebook." Facebook's identity system was explicitly marketed to app developers as a generalised web identity system, and it genuinely improved usability, but at the cost of ceding developer and consumer control to the platform. A missing protocol layer became a product, and the company that provided it now sits between you and thousands of services, watching you arrive at each one.

The payment gap became payment processors. HTTP 402 stayed dormant, so commerce needed rails the protocol did not offer. Card networks, then PayPal, then Stripe stepped into that void. They did it well. But it means that value on the web does not flow peer to peer the way information does. It flows through gateways, each of which can charge a fee, set terms, and decide who is allowed to transact at all. The web transmits data without asking permission and money only with it.

The trust gap became platforms. This is the subtlest and most powerful one. Because HTTP could not tell you whether a stranger was trustworthy, buying from a random website was genuinely risky. The solution that emerged was to not trust the stranger at all, and trust an intermediary instead. You do not trust the seller on Amazon; you trust Amazon. You do not trust the driver; you trust Uber. You do not trust the host; you trust Airbnb. Each of these companies is, at its core, a trust layer that the protocol never provided, monetised. And notice what happens once a company becomes the trust layer for a market: it can set the rules of that market, take a cut of every transaction, and remove any participant it chooses. That is not a business model bolted onto the web. It is a missing protocol layer, privatised.

The discovery gap became search. With no directory in the protocol, finding anything required an index, and building a good index was hard and expensive. Google built the best one, and in doing so became the front door to the web. A gap in the protocol turned into the most valuable position on the internet: the entity that decides what is findable.

The state gap became cookies, then tracking. HTTP's statelessness had to be worked around for anything interactive to function, so we got cookies. Cookies solved a genuine engineering problem, and then, because they let a party recognise you across visits, they became the foundation of the entire surveillance advertising economy. A patch for a protocol limitation became the infrastructure of tracking.

Look at the pattern in aggregate. Identity, payment, trust, discovery, state. Five gaps. Five industries. And in every single case, the entity that filled the gap acquired enormous power, not by conquering the web, but by supplying something the web needed and had never provided.

This is why I think the standard story of centralisation is wrong. It is usually told as a moral tale: the open web was hijacked by greedy corporations. But the mechanism was simpler and more structural than that. The protocols left holes. Holes in essential infrastructure get filled. Whoever fills a hole that everyone depends on becomes a chokepoint, and chokepoints accumulate power automatically, regardless of anyone's intentions.

If this argument sounds familiar, it should. It is the same one I made in my post on AI infrastructure: control concentrates in the layers underneath, and it cascades upward. The web is that argument told over thirty years.

Web3: The Right Diagnosis, and What Actually Happened

This is where Web3 enters, and I want to handle it carefully, because it is a topic where most writing is either evangelism or contempt, and neither is useful.

Give Web3 its due: the diagnosis was correct. Its central claim was that the web's centralisation was caused by missing protocol layers, particularly trust and identity and payment, and that if you could provide those at the protocol level instead of the platform level, you would remove the need for the intermediaries entirely. That is a genuinely serious argument, and it is the same argument I have just spent this post making. Web3 read the problem correctly.

The bet was that cryptography and distributed consensus could supply the missing layers. A blockchain could provide trust without a trusted intermediary. A wallet could provide identity without an identity provider. A token could provide payment without a payment processor. Fill the protocol gaps, and the platforms that grew inside them become unnecessary.

So what happened? The honest answer is that it has largely not worked at the scale it promised, and the infrastructure lens explains why better than either the hype or the mockery does.

It re-centralised at the layer below. This is the most instructive failure, and it is exactly what this series would predict. In November 2020, an Infura outage disrupted Ethereum wallets, DeFi platforms, and exchanges. MetaMask users could not access their funds. But the blockchain itself was fine, still processing blocks normally. The problem was the access layer: too many applications depended on a single infrastructure provider to reach the chain. The lesson the ecosystem drew was blunt, and it is the thesis of this entire post: even a decentralised blockchain can rely heavily on centralised gateways.

It happened again, larger. When a major AWS outage hit in October 2025, it exposed how heavily Web3 depends on centralised infrastructure. Coinbase went down. Its Base layer-2 network went down. Infura was degraded. MetaMask front-ends faltered. An ecosystem built explicitly to eliminate central points of failure was taken offline by a central point of failure, because someone still has to run the servers, and it turned out to be the same handful of companies as everyone else.

That is the pattern this series keeps finding. You can decentralise a protocol, but the protocol runs on infrastructure, and infrastructure has economics. Whoever pays for the servers, the bandwidth, and the reliability tends to end up in control, no matter what the protocol above them says.

It fought network effects and lost. The centralised incumbents were not just holding a technical position. They were holding a network effect. A decentralised alternative that is technically superior but has a tenth of the users is not, for most people, superior at all. This is the same wall I discussed in a recent comment about DNS: you cannot flag-day the internet. IPv6 is technically better than IPv4 and, decades in, still runs alongside it rather than replacing it. Better does not win. Better-plus-deployable wins.

And the incentives pulled it off course. Much of the energy that could have gone into building the missing layers went into speculation instead. Serious critical scholarship has questioned whether Web3 genuinely distributes power or merely shifts influence to a new tech-savvy elite, and a fair reading of the last few years makes that question hard to dismiss. Meanwhile the practical gateways people actually used, the exchanges, the wallet providers, the RPC endpoints, consolidated into exactly the kind of intermediaries the movement set out to abolish.

So the fair summary is this: Web3 identified the right problem and demonstrated, at real expense, that fixing a protocol gap with cryptography alone does not fix the centralisation, because centralisation is not only a protocol phenomenon. It is an infrastructure and economics phenomenon. That is a genuinely valuable finding, even though it is not the one anyone wanted.

And it is worth noting the quieter, more interesting sequel. HTTP 402 is finally being activated, thirty years on, through efforts to build a real payment primitive into HTTP, driven largely by the needs of AI agents that cannot click through a checkout page. Whether that succeeds is genuinely unsettled, and I would not bet either way. But it is the clearest possible demonstration of the thesis: the gap was real, it was left in the specification on purpose, and the pressure to fill it never went away.

What This Means for Anything Being Built Now

The reason this matters beyond history is that the pattern is not finished. It is running right now, on the next layer.

Every emerging technology arrives with its own set of protocol gaps, and the same race to fill them. AI systems have no native identity layer, no native payment layer, no native trust layer. Right now, those gaps are being filled, and the entities filling them are becoming the chokepoints of the next era, exactly as Google, Facebook, Amazon, and Stripe did for the web. The specific technologies change. The structure does not.

So the useful question, whenever you look at any new system, is not "is this decentralised?" It is: what does this protocol not provide, and who is going to provide it instead? That question tells you where the power will accumulate, usually years before it becomes obvious.

If you want to feel this rather than just read it, a few small projects make the gaps tangible, and I would suggest them as things to try rather than tutorials to follow:

Run your own service end to end, on your own VPS with your own domain, as I covered in a recent standalone guide. Doing it once teaches you exactly how much the platforms are actually doing for you, and where you are still dependent no matter how self-hosted you feel.

Build a small site that handles its own authentication instead of using "Sign in with Google," and notice how much work the identity gap really represents, and why almost everyone hands it to a platform.

Try to accept a payment without a processor, and watch how quickly you discover that the web has no native way to move money.

Serve something over a peer-to-peer protocol like IPFS and then ask yourself, honestly, who is pinning the data and who is running the gateway you are reaching it through.

Each of these is small. Each one teaches the same lesson from a different side: the gaps are real, filling them is hard, and that difficulty is precisely why the companies that filled them became so powerful.

What You Now Understand

We took a detour from the plumbing, but it was not really a detour.

You now know that the web's foundational protocols were deliberately minimal: they specified naming, requesting, and structuring documents, and left out identity, payment, trust, discovery, and state. That minimalism is why the web was deployable at all, so it is not a design flaw. It is the reason the web exists.

You know that those gaps did not stay empty. Each one was filled by a company, and each company that filled one became a chokepoint: login providers for identity, processors for payment, platforms for trust, search for discovery, cookies and tracking for state. Centralisation was not a hijacking. It was the market finishing an unfinished protocol, and collecting rent on the parts it completed.

You know that Web3 diagnosed this correctly and still largely failed to fix it, and you know why: it re-centralised at the infrastructure layer beneath the protocol, it fought network effects without a deployment path, and its incentives pulled it toward speculation. That is not a moral judgement, it is a structural one, and it is the same lesson the whole series teaches. Control lives in the layers underneath.

And most usefully, you have a question you can now apply to anything: what does this system not provide, and who will provide it instead? That is where the power goes.

In the next post we return to the plumbing, and to a question this interlude has quietly raised. We have talked a lot about how data finds its destination. Post 6 is about the choice every application makes once it gets there: reliability or speed. TCP and UDP, the three-way handshake, and the tradeoff that shapes everything from your bank transfer to your video call.

This was an interlude in the Networking Foundations series, sitting between Post 5 on DNS and Post 6 on TCP and UDP. If it gave you a new way to read the web's history, share it with someone who thinks centralisation was just greed. New here? The series starts with Post 1, on what a network actually is, and this interlude leans on everything from Posts 1 to 5. Subscribe to our newsletter to get each new post as it publishes.

Connecting a Domain to a VPS From a Different Company: The Guide Nobody Gives You

VickkyKruz NetSec — Sun, 12 Jul 2026 13:32:47 +0000

Almost everyone who has ever deployed something hits this exact wall.

You rent a VPS from one provider, maybe Hetzner, DigitalOcean, Contabo, or a Namecheap VPS. It gives you a public IP address, a string like 203.0.113.45. Separately, you bought a domain name from somewhere else entirely, maybe GoDaddy, Namecheap, or Cloudflare, because that is where it was cheapest or where you already had an account. So now you have two things bought from two different companies that have no relationship with each other: a server with an IP address, and a domain with a name.

And between them sits a gap that nobody explains. The VPS provider assumes you will sort out the domain. The domain registrar assumes you know where you want to point it. Neither walks you through the bit in the middle. You are left with a working server that nobody can reach by name, and a domain that leads nowhere.

This guide closes that gap. First the concept, because the reason people get stuck is almost never the clicking, it is not understanding what the clicks are actually doing. Then the walkthrough, covering both of the main methods, so you know not just how but which one to choose. And finally the part most guides skip entirely: getting HTTPS working, because a site reachable only over plain HTTP in 2026 is a site browsers actively warn people away from.

The Concept: Two Separate Decisions People Wrongly Merge Into One

Here is the single most important idea in this entire guide, and the thing that, once understood, makes everything else obvious.

Connecting a domain to a server involves two completely separate decisions, and almost everyone who gets stuck is stuck because they have merged them into one confused blob in their head. Separate them, and the confusion evaporates.

Decision one: who hosts your DNS? Remember from the DNS post (DNS: The Internet's Phone Book, and Its Biggest Weakness) that somewhere out there, a set of authoritative nameservers holds the records for your domain and answers the world's questions about it. The question here is: whose nameservers will those be? You have a choice. It can be your registrar's own nameservers, the default, since they run DNS for every domain they sell. Or it can be a third party like Cloudflare, whom you delegate the job to. This decision is about where your domain's DNS records live and who serves them.

Decision two: what do those records say? Wherever your DNS is hosted, it holds records. The one that matters here is the A record, which maps your domain name to an IPv4 address. This decision is about what address your domain actually points to, namely, your VPS's IP.

People get stuck because they conflate these. They think "pointing my domain at my server" is one action, when it is really two: choosing who runs your DNS, and then setting the record that names your server's IP. Once you see them as separate, the two methods below stop being competing mysteries and become simply two answers to decision one, with decision two working the same way in both.

Hold one more idea from the DNS post in mind as we go: propagation. DNS answers are cached all over the world according to their TTL, so when you change where your domain points, the change is not instant. It rolls out as old cached records expire. This is why nothing in this guide takes effect the very second you click save, and why patience is part of the process, not a sign something is broken.

Method One: Keep Your Registrar's DNS, Just Add an A Record

This is the simplest method, and for a great many people it is the right one. You leave your DNS where it already is, at your registrar, and you simply edit one record to point at your VPS.

Here is the whole idea: your registrar is already hosting your domain's DNS by default. You do not need to move anything. You just log in and add or edit the A record so it points at your VPS's IP address.

The steps, in principle, are the same wherever your domain lives, even though every registrar's panel looks slightly different:

Get your VPS's public IP address from your hosting provider's dashboard. It will look like 203.0.113.45.
Log in to your domain registrar and open the DNS management page for your domain.
Find the existing A records. Delete or edit any old A, AAAA, or CNAME records for the root (often shown as @) and for www, so they do not conflict with what you are about to add.
Add an A record for the root domain: host @, value your VPS IP. This makes example.com point at your server.
Add a second record for www. You can make this another A record pointing at the same IP, or a CNAME pointing at your root domain. Either makes www.example.com work.
Save, and wait for propagation, up to around 24 hours, though often much faster. That is it. Your domain now resolves to your server.

When to choose this method: if your VPS has a static IP that will not change, and you do not need extra features like a CDN or DDoS protection, this is the clean, correct choice. There is one honest caveat worth knowing: with the A record method, if your VPS IP ever changes, you must come back and update this record by hand. For a stable server that is a non-issue, but it is the tradeoff to be aware of.

Method Two: Delegate Your DNS to Cloudflare (or Another Provider)

The second method answers decision one differently. Instead of leaving your DNS at your registrar, you hand the job of hosting it to a third party, most commonly Cloudflare, and manage your records there instead.

Why would you do the extra work? Because moving your domain's nameservers to Cloudflare unlocks a set of things the registrar's basic DNS panel simply cannot do: putting your site behind Cloudflare's network for CDN caching and speed, hiding your server's real IP address, DDoS protection, a web application firewall, free SSL termination, easy DNSSEC, and a proper API. For anything you are self-hosting seriously, this is often worth it.

Crucially, and this surprises people, you do not move your domain away from your registrar to do this. Your domain stays registered exactly where it is. The only thing you change at the registrar is which nameservers it points to. Ownership does not move; only the DNS-hosting job does.

The steps:

Create a Cloudflare account and choose "Add a site" (or "Onboard a domain"), then enter your domain.
Cloudflare automatically scans your existing DNS records and imports what it finds. Review this list. In particular, make sure there is an A record pointing your domain at your VPS's IP; add or correct it if needed.
Cloudflare gives you two nameservers to use, something like ada.ns.cloudflare.com and bob.ns.cloudflare.com. Copy them.
Log in to your registrar, find the nameserver setting for your domain, and replace the registrar's default nameservers with the two from Cloudflare.
Wait for the delegation to take effect, up to 24 to 48 hours, though usually faster. Cloudflare emails you and shows the domain as "Active" once it sees the change.
From now on, you manage all your DNS records inside Cloudflare, not at your registrar. One important gotcha, learned the hard way by many. If your domain currently has DNSSEC enabled at your registrar, you must turn DNSSEC off at the registrar before changing the nameservers. Changing nameservers while DNSSEC is still active can make your domain unreachable, because the old cryptographic signatures no longer match the new DNS host. You can re-enable DNSSEC later, from within Cloudflare, once the domain is active. This single step trips up a lot of people, so do not skip it.

The orange cloud versus the grey cloud. Once you are managing records in Cloudflare, each record has a proxy toggle shown as a cloud icon, and understanding it prevents a lot of confusion. An orange cloud (proxied) means traffic goes through Cloudflare's network first: your real server IP is hidden, and you get the CDN, caching, and protection. A grey cloud (DNS only) means Cloudflare just answers the DNS question and the visitor connects straight to your server's real IP, with none of the proxying. For a normal website you want the orange cloud. But one rule to remember: mail records, and any non-web service like SSH, should always be grey cloud, because proxying only works properly for web traffic on the standard HTTP and HTTPS ports. Proxying your mail records will break your email.

When to choose this method: if you want a CDN, DDoS protection, to hide your origin IP, or if your VPS has a changing IP that you would rather manage through an API than by hand, this is the stronger choice. It is a few more steps up front for considerably more capability afterwards.

Which Method Should You Actually Use?

To make the choice concrete rather than abstract:

Choose the registrar A record method if you have a single VPS with a static IP, you want the simplest possible setup, and you do not need a CDN or the extra protection. It is direct and there is nothing wrong with it. Many perfectly good production sites run exactly this way.

Choose the Cloudflare nameserver method if you want performance and protection features, you want to hide your server's real IP from the public, you are running anything that might attract attention or attack, or you simply want a more powerful DNS control panel and API for the future. Given that Cloudflare's basic tier is free, many developers pick this route by default now, even for small projects, because it costs nothing and leaves room to grow.

Neither is wrong. They are answers to the same question at different levels of ambition.

The Step People Forget: Pointing Is Not Serving

Here is a mistake so common it deserves its own section, because it causes hours of confused debugging.

Getting your domain to point at your server is only half the job. It gets a visitor's browser to arrive at your server's front door. But it does nothing to make your server actually answer for that domain once they knock. Those are two separate things, and people constantly do the first and forget the second.

"DNS points to the server" and "the server is configured to serve the site for that domain" are different steps. Your DNS records send the visitor to the right IP. But your web server software on the VPS, whether that is Nginx, Apache, Caddy, or something else, also has to be told to respond to requests for your domain name and serve the right content. If you point your domain correctly but never configure the web server to recognise it, you will get a connection that lands but shows a default page, an error, or nothing useful, and you will wrongly assume the DNS is broken when it is fine.

So the real sequence is: point the domain (DNS), and configure the web server to serve that domain (server config). Only when both are done does typing your domain into a browser actually show your site.

Verifying It Worked, and the Waiting Game

Once you have set your records, you will want to check whether they have taken effect, especially since propagation is not instant. Two commands do almost all the work, both of which the DNS post introduced.

Check what your domain currently resolves to:

dig example.com +short

This should eventually print your VPS's IP address. If it prints nothing, or an old address, propagation has not finished, or a record is wrong. Run it again after a while.

Check that your server actually responds over the domain:

curl -I http://example.com

This makes a request and shows you the response headers. A sensible response here means your domain is not only pointing at the server, but the server is answering for it, both halves of the job done.

If these do not work immediately, resist the urge to change everything in a panic. Propagation genuinely can take up to 24 hours, occasionally a little more, because DNS resolvers around the world are still serving cached older records until their TTL expires. A tool like whatsmydns.net lets you watch propagation happen across different locations globally, which is reassuring when you are wondering whether you broke something or simply need to wait.

The Final Step: Turn On HTTPS

Your domain points at your server, and your server answers for it. But right now it does so over plain, unencrypted HTTP. In 2026, browsers show a visible "Not Secure" warning on HTTP sites, which quietly scares away visitors and undermines trust. And as the DNS and firewall posts in the series argued, unencrypted traffic is a genuine security exposure, not a cosmetic issue. So the last step of any real deployment is enabling HTTPS.

The standard, free way to do this is Let's Encrypt, a free and automated certificate authority, using a tool called Certbot. On a typical Ubuntu server running Nginx, the process is short.

Install Certbot and its Nginx plugin:

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

Then request and install a certificate for your domain:

sudo certbot --nginx -d example.com -d www.example.com

Certbot verifies that you control the domain, obtains a certificate, and automatically edits your Nginx configuration to serve HTTPS. It will offer to redirect all HTTP traffic to HTTPS, which you should accept. The certificate is valid for 90 days and renews itself automatically, so this is genuinely a set-and-forget step.

The crucial ordering gotcha, and why this section comes last. Certbot's standard verification method works by having Let's Encrypt connect to your domain over the public internet, on port 80, to confirm you really control it. This means your domain must already be resolving to your server and reachable before you run Certbot. If DNS has not propagated yet, or your server is not answering on port 80, certificate issuance will fail. This is exactly why HTTPS is the last step: it depends on every previous step already being complete and live. Get the domain pointing and serving first, confirm it with the commands above, and only then run Certbot.

Once done, verify:

curl -I https://example.com

Seeing a secure response here is the finish line. Your domain, bought from one company, now points at your server, bought from another, and serves your site securely over HTTPS. The gap is closed.

The Whole Thing, in Order

Stepping back, here is the complete mental model, which is worth more than any single set of click-by-click steps because panels change but the logic does not:

You have a server with an IP, and a domain with a name, bought from two unrelated companies. To connect them, you first decide who hosts your DNS: your registrar, the simplest option, or a third party like Cloudflare, the more powerful one. Then, wherever that DNS lives, you set an A record pointing your domain at your VPS's IP. You separately configure your web server to actually answer for that domain, because pointing is not serving. You wait for propagation, verify with dig and curl, and finally enable HTTPS with Certbot once the domain is live and reachable.

Every developer hits this gap once. The reason it feels so confusing the first time is that no single company owns the whole journey, your VPS provider, your registrar, and your DNS host are potentially three different parties, and none of them explains the parts owned by the others. But once you hold the concept, that this is two decisions and a couple of verification steps rather than one mysterious action, it stops being intimidating and becomes something you can do confidently in a few minutes, for any domain and any server, for the rest of your career.

This was a standalone practical guide. If you want the theory underneath it, why a name resolves to an address at all, how the lookup actually travels the internet, and why propagation works the way it does, it is covered in Post 5 of my Networking Foundations series, on DNS. And if this saved you the confusion it saves most people, share it with someone about to deploy their first server. Subscribe to my newsletter for more practical, foundations-first guides like this one.

DNS: The Internet's Phone Book, and Its Biggest Weakness

VickkyKruz NetSec — Sat, 11 Jul 2026 13:45:53 +0000

This is Post 5 of my Networking Foundations series, originally published on my blog. Start from Post 1 there if you want the full series in order.

At the end of the last post, you understood how a device is found on a network: by its IP address, the logical location that routing depends on. But then I pointed out something you have probably never stopped to notice. In your entire life online, you have never once typed an IP address to reach a website. You do not open your browser and type 142.250.72.14. You type google.com.

So something, somewhere, is quietly translating the human name you type into the machine address the network needs. That something is DNS, the Domain Name System, and it is one of the largest, oldest, and most essential systems on the entire internet. Every website you visit, every email you send, every app that connects to a server, begins with a DNS lookup. It happens so fast and so invisibly that most people never know it is there.

This post pulls it into the light. What DNS is and why it exists, the surprisingly involved journey that happens in the fraction of a second between typing a name and the page appearing, the different kinds of records DNS holds, and then the part this series always comes back to: how a system built for a trusting world became one of the most abused surfaces on the internet, and what defends it.

What DNS Actually Is

Let us start with the problem DNS solves, because it is a genuinely human one.

Computers locate each other using IP addresses, numbers like 142.250.72.14, or the far longer strings of an IPv6 address. Machines are perfectly happy with these. Humans are not. Nobody wants to memorise a string of digits for every website they visit, and even if you did, those numbers change. A company can move its website to a new server with a new IP address, and if you had memorised the old number, you would be stuck.

DNS is the system that lets humans use names while machines use numbers. The classic description, and it is a good one, is that DNS is the phone book of the internet. In an old telephone directory, you looked up a person's name to find their number, because you remember names, not numbers. DNS does exactly this. You provide a name, google.com, and DNS returns the current number, the IP address, that the network actually needs to route your request.

This layer of translation is quietly one of the most important ideas on the internet, because it decouples the name from the location. The name google.com can stay the same forever, building trust and recognition, while the actual servers behind it can move, multiply, and change addresses freely. DNS is the flexible link between the stable human-facing name and the shifting machine-facing address. Without it, the web as we know it, built on memorable names and links, could not exist.

The Resolution Journey: What Actually Happens

Here is where it gets genuinely interesting. When you type a name and hit enter, the translation is not a single lookup in one big table somewhere. It is a small relay race across a globally distributed hierarchy of servers, each one knowing just enough to point you to the next. This process is called DNS resolution, and understanding its steps is the heart of understanding DNS.

There are four kinds of players in this race. Let us meet them, then watch them run.

The stub resolver is the simple piece of software built into your operating system. It does not do the hard work itself. It just asks a question and waits for an answer. When your browser needs an address, it hands the request to the stub resolver.

The recursive resolver, often called just the resolver or the recursor, is the workhorse. It is usually run by your internet provider, or a public service like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. Its job is to take your question and do whatever it takes to find the answer, then hand it back. It is the middleman that manages the entire search on your behalf.

The root nameservers sit at the very top of the hierarchy. There are 13 of them, known to every recursive resolver on earth. They do not know the address of google.com, but they know where to send you to get closer: to the right top-level domain servers.

The TLD nameservers are responsible for a specific top-level domain, the last part of a name, like .com, .org, or .uk. The .com TLD servers do not know google.com's address either, but they know which servers do: the authoritative nameservers for that specific domain.

The authoritative nameservers are the final source of truth. They hold the actual DNS records for a domain. When the query reaches them, they give the definitive answer.

Now watch the race for www.example.com, assuming nothing is cached yet:

Your browser asks the stub resolver in your OS for the address of www.example.com.
The stub resolver forwards the question to the recursive resolver (say, your ISP's, or 1.1.1.1).
The recursive resolver asks a root nameserver: "where do I find .com addresses?" The root server replies with a referral: "go ask the .com TLD servers, here they are."
The recursive resolver asks a .com TLD nameserver: "where do I find example.com?" The TLD server replies with another referral: "go ask example.com's authoritative servers, here they are."
The recursive resolver asks the authoritative nameserver for example.com: "what is the address of www.example.com?" This server holds the real record and replies with the actual IP address.
The recursive resolver hands that IP address back to your stub resolver, which hands it to your browser.
Your browser, finally holding the IP address, opens a connection to that server and requests the page.

Every one of those steps happened in the time it took the page to start loading, often well under a tenth of a second. A distributed, hierarchical, worldwide system of servers coordinated to answer one question, and you never saw a thing.

Notice the elegant design. No single server holds the whole internet's address book. The knowledge is delegated down a hierarchy: the root knows the TLDs, the TLDs know the domains, the domains know their own records. This is what makes DNS able to scale to billions of names without any one machine being a bottleneck or a single point of total failure.

Caching: Why It Is Not Slow

If DNS did that full seven-step journey every single time, it would be slower and would hammer the root and TLD servers with unimaginable traffic. It does not, because of caching.

At nearly every layer, the answer to a DNS query gets temporarily stored, so it can be reused without repeating the journey. Your browser caches. Your operating system caches. Above all, the recursive resolver caches. When the recursive resolver has recently looked up example.com for someone else, it simply returns the stored answer from its cache, skipping the root, TLD, and authoritative servers entirely. Given how many people share a resolver, most common lookups are answered instantly from cache.

But cached answers cannot live forever, or they would go stale when a domain genuinely changes its address. This is controlled by a value you met back in Post 2: the TTL, or Time to Live. Every DNS record carries a TTL, a number of seconds that says how long this answer may be cached before it must be looked up fresh. A short TTL means changes propagate quickly but caching is less effective. A long TTL means excellent caching but slower propagation when something changes. Every DNS administrator balances these two, and it is why, when you change a website's address, you are often told to wait for the change to propagate. You are waiting for old cached records around the world to hit their TTL and expire.

Keep the security implication of caching in the back of your mind as we move on, because that shared, trusted cache is about to become the target of one of the most important attacks in DNS.

The Records DNS Holds

DNS does not only translate names to IPv4 addresses. A domain's authoritative servers hold several types of records, each serving a different purpose. You do not need to memorise them, but knowing the main ones makes DNS concrete rather than abstract.

The A record is the most fundamental. It maps a name to an IPv4 address. This is the classic phone-book entry: example.com points to 93.184.216.34.

The AAAA record (pronounced "quad-A") does the same job for an IPv6 address. As IPv6 adoption grows, most major domains publish both an A and a AAAA record.

The CNAME record, or Canonical Name, is an alias. It points one name at another name rather than at an address. For example, www.example.com might be a CNAME pointing to example.com, so both resolve to the same place and you only have to maintain the address in one spot.

The MX record, or Mail Exchange, tells the internet where to deliver email for a domain. When you email someone at example.com, the sending mail server does a DNS lookup for example.com's MX record to find the mail server that should receive it.

The NS record, or Nameserver, states which authoritative nameservers are responsible for the domain. It is part of the delegation chain we walked through earlier.

The TXT record holds arbitrary text. It has become the internet's general-purpose noticeboard, used for verifying domain ownership and, importantly, for email security records like SPF, DKIM, and DMARC that help prove an email genuinely came from the domain it claims to.

That last point is worth pausing on. Several of the most important defences against email spoofing and phishing live entirely in DNS TXT records. DNS is not only how you find things, it is increasingly how the internet proves that things are who they say they are, which makes its own trustworthiness all the more critical.

The Security Truth: A System Built to Trust

Here is the thread this whole series keeps pulling, and DNS may be its clearest example yet.

DNS was designed in the early 1980s, for the same small, trusting, academic internet that shaped every other early protocol we have discussed. Its single purpose was to make name resolution work reliably and at scale, and at that it succeeded magnificently. But like the rest of that early internet, it was not built to be secure. The original protocol has no built-in way to verify that a DNS answer is genuine. When a resolver receives a response saying "google.com is at this address," standard DNS has no mechanism to check whether that answer really came from the legitimate authoritative server, or from an attacker who slipped a forged reply in first.

That single missing feature, the inability to verify authenticity, is the root of nearly every DNS attack. Let us look at the main ones.

DNS Spoofing and Cache Poisoning

This is the signature DNS attack, and the caching we just discussed is exactly what makes it so dangerous. In DNS cache poisoning, an attacker tricks a recursive resolver into storing a false record, so that the resolver returns a fraudulent IP address to everyone who asks. Users trying to reach a legitimate site are silently redirected to an attacker-controlled destination, often a convincing fake built to steal credentials, while their browser still shows the correct address in the bar and nothing appears wrong.

The classic technique exploits the trust gap directly: the attacker floods the resolver with forged responses, each guessing at the identifying number that ties a DNS answer to its question, hoping to land a forged reply before the real one arrives. The reason this is so serious is scale. A single poisoned resolver can misdirect thousands or millions of users at once, without touching the target domain's own servers at all. The legitimate site is untouched; the poison is in the directory that points to it.

DNS Hijacking

DNS hijacking is a broader term for any attack that redirects users by corrupting the resolution process itself, rather than poisoning a cache. This can happen several ways. An attacker might compromise the domain's account at its registrar and change its records at the source. They might take over a home or office router and change which resolver it uses, pointing every device on that network at a malicious server. Or malware on a device might alter its local settings so that specific domains resolve to attacker-controlled addresses. In every case, the result is the same: you type a legitimate name, and you are sent somewhere hostile.

DNS as a Smuggling Tunnel

There is a subtler abuse worth knowing about. Because DNS traffic is so essential and so trusted, it is very often allowed straight through firewalls that would block other traffic. Attackers exploit this by using DNS itself as a covert channel, a technique called DNS tunnelling. Data, such as stolen information or commands to malware already inside a network, is smuggled hidden inside DNS queries and responses, slipping past defences that never thought to inspect the humble name lookup. It is a striking example of how a trusted, overlooked protocol becomes an attacker's favourite hiding place.

A Real Incident: The MyEtherWallet Redirect

To make this concrete, consider what happened to users of MyEtherWallet, a popular cryptocurrency wallet service, in 2018. Attackers manipulated internet routing to hijack the traffic headed for the service's DNS infrastructure, so that people typing the correct, legitimate web address were quietly redirected to a malicious copy of the site. The fake site looked right. Users logged in as normal. And in doing so, they handed their credentials straight to the attackers, who drained cryptocurrency from the real accounts. No victim did anything obviously wrong. They typed the correct address. The directory that was supposed to send them to the right place sent them into a trap. That is the essence of why DNS security matters: when the phone book itself is lying, doing everything else right does not save you.

The Defences: Adding Trust to a Trusting System

If the root problem is that DNS cannot verify authenticity, then the defences are all, in one way or another, about adding that missing verification and privacy back on top. There are two main families, and they solve two different problems.

DNSSEC: Proving the Answer Is Genuine

DNSSEC (DNS Security Extensions) addresses the authenticity problem directly. It uses public-key cryptography to digitally sign DNS records, so that a resolver can verify that an answer genuinely came from the legitimate authoritative source and was not forged or tampered with in transit. If a poisoned or spoofed record arrives, its signature will not validate, and a DNSSEC-aware resolver will reject it. This is the primary cryptographic defence against cache poisoning and spoofing.

DNSSEC is powerful, but it is worth being honest about its limits, because this is where many explanations oversell it. First, DNSSEC provides authentication and integrity, proof that the answer is genuine and unaltered, but it does not provide encryption. DNSSEC responses are signed, not secret. Second, its real-world protection is limited by inconsistent deployment. Major top-level domains sign their zones, but signing at the level of individual domains remains patchy, and a signature only helps if both the domain publishes one and the resolver checks it. And third, DNSSEC does not defend against every DNS attack. It does nothing against registrar account compromise, router hijacking, or a malicious entry placed directly in a device's local settings, because in those cases the attacker is not forging a signed record, they are changing the process elsewhere.

DoH and DoT: Encrypting the Conversation

The second family solves a different problem: privacy and tampering in transit. Standard DNS queries travel in plain text, which means anyone positioned along the path, on the same public Wi-Fi, for instance, can see every domain you look up and potentially tamper with the response. This is the postcard problem from Post 2, applied to DNS.

DNS over HTTPS (DoH) and DNS over TLS (DoT) solve this by encrypting the DNS conversation between your device and the resolver. An on-path eavesdropper can no longer read which sites you are looking up, and can no longer secretly modify the answers, because the channel is encrypted and the resolver's identity can be verified. This makes the kind of on-path tampering that public Wi-Fi enables far harder to pull off.

The crucial point, and the honest one, is that these two families are complementary, not interchangeable. DNSSEC proves the answer is genuine but does not hide it. DoH and DoT hide the conversation but do not, by themselves, prove the authoritative answer was genuine. Strong DNS security uses both: encryption to protect the conversation in transit, and signing to prove the answer's authenticity. And because even both together do not cover registrar compromise or router hijacking, real defence also means securing the accounts and devices around DNS, not just the protocol. No single technology closes every path, which is exactly why layered defence is the theme it always comes back to.

Commands to See DNS For Yourself

DNS is one of the most satisfying systems to inspect directly, because every step is visible with the right tool.

The simple lookup, on any system:

nslookup google.com

This asks your configured resolver for the address of google.com and shows you the answer, along with which resolver gave it. Simple and available everywhere.

The detailed lookup, on macOS and Linux:

dig google.com

dig is the tool of choice for anyone serious about DNS. It shows the answer, the record type, and, importantly, the TTL counting down, the caching lifetime we discussed. Run it twice in quick succession and watch the TTL drop, that is the cache at work.

Watch the entire resolution journey happen:

dig +trace google.com

This is the one to try. The +trace option makes dig perform the full walk we described, starting at the root servers, following the referral to the TLD servers, then to the authoritative servers, printing each step. You are watching the relay race in real time, seeing the root hand off to .com, and .com hand off to google.com's own nameservers. Few commands make an abstract concept this tangible.

Look up specific record types:

dig example.com MX      (find the mail servers)
dig example.com TXT     (see the text records, including email security)
dig example.com NS      (see the authoritative nameservers)

Try the MX and TXT lookups on a domain you know. Seeing a real domain's mail configuration and its SPF or DMARC records makes the record types stop being a list and start being real infrastructure you can read.

What You Now Understand

You began with a small mystery, that you navigate the entire internet by name yet the network runs on numbers, and you now understand the system that bridges the two. DNS is the phone book of the internet, the translation layer that lets stable human names point at shifting machine addresses, decoupling the two so each can do its job.

You can trace the resolution journey yourself: the stub resolver in your OS, the recursive resolver doing the legwork, and the hierarchy of root, TLD, and authoritative servers, each knowing just enough to delegate to the next. You understand why this delegated design lets DNS scale to the whole internet, and how caching, governed by TTL, makes it fast. You know the main record types, and the striking fact that DNS is now used not just to find things but to prove identity, through the email-security records living in TXT.

Most importantly, you understand the security truth at the centre of it. DNS was built for a trusting world and cannot, on its own, verify that an answer is genuine. That single gap is the root of spoofing, cache poisoning, and hijacking, made vivid by real incidents where typing the correct address still led users into a trap. And you know the two complementary families of defence: DNSSEC to prove authenticity, DoH and DoT to protect the conversation, with the honest caveat that neither is complete and layered defence is the only real answer.

This is the same lesson the series keeps arriving at from every direction. The foundational systems of the internet were built for connection, not protection, and security has been carefully added on top ever after.

In the next post, we go deeper into how data is actually carried once a name has been resolved and a connection is being made. We will look closely at the two great transport protocols, TCP and UDP, the reliability-versus-speed tradeoff that every application on the internet has to make, and the three-way handshake that quietly opens nearly every connection you use. That is Post 6.

This is Post 5 of the Networking Foundations series. If DNS finally makes sense as more than a vague acronym, share it with someone who has wondered what actually happens when they type a web address. New here? Start with Post 1, and Post 4 on IP addressing leads directly into this one. Subscribe to our newsletter to get each new post as it publishes.

IP Addressing and Subnetting: Every Device Needs an Address

VickkyKruz NetSec — Mon, 06 Jul 2026 21:50:38 +0000

This is Post 4 of my Networking Foundations series, originally published on my blog. Start from Post 1 there if you want the full series in order.

At the end of the last post, we zoomed out to see the whole OSI model, seven layers, each with one job. Then we promised to come back and zoom all the way into one of them: Layer 3, the network layer, the home of the thing that makes global communication possible in the first place.

That thing is the IP address.

Every device that speaks to another device across a network needs one. Your phone has one right now. So does the server hosting this page, the router in your home, and the laptop you might be reading this on. Without addresses, there is no way to say "send this here rather than there," and the entire idea of a network collapses. The IP address is the network layer's answer to a single question: on a planet with billions of connected devices, how does data find the one specific machine it is meant for?

This post answers that question completely. What an address actually is, why we nearly ran out of them, how your home network quietly shares a single public one, how the newer system fixes the shortage, and finally, subnetting: the skill that trips up more networking learners than any other, taught here in the order that actually makes it stick.

What an IP Address Actually Is

Let us start with the concept, before any notation.

An IP address is a numerical label assigned to every device on a network that uses the Internet Protocol. It does two jobs at once: it identifies the device, and it locates that device within the network. Those are subtly different things, and both matter. Identification says "this is who you are." Location says "this is where you are, so traffic can be routed to you."

Here is the important word: an IP address is a logical address, not a physical one. Remember from Post 3 that every device also has a MAC address, burned into its hardware at the data link layer. That MAC address is like a person's fingerprint. It never changes and it is tied to the physical device forever. An IP address is different. It is like a mailing address. It describes where you currently are on the network, and it can change when you move. Connect your laptop to a different network and it gets a different IP address, just as you would have a different postal address if you moved house. The laptop is the same laptop, its fingerprint is unchanged, but its location, its logical address, is now different.

This is the postal analogy we have been building since Post 2, and it holds all the way up. The MAC address is who you are. The IP address is where you live. Routing, the job of getting data across the world, depends entirely on the second one.

IPv4: The Original System, and Why We Ran Out

The version of IP addressing that built the internet is called IPv4, and it has been in use since 1983.

An IPv4 address is a 32-bit number. In practice you never see it as 32 raw bits, because that would be unreadable. Instead it is split into four groups of 8 bits, each group written as a decimal number from 0 to 255, joined by dots. That is why IP addresses look the way they do:

192.168.1.75

Each of those four numbers is called an octet, because it represents 8 bits. Eight bits can hold 2 to the power of 8, which is 256 values, giving the range 0 to 255 that you see in every octet. The same address in binary looks like this:

11000000.10101000.00000001.01001011

That is the exact same address, just shown as the bits the machine actually works with. We will need this binary view later for subnetting, so keep in the back of your mind that every dotted-decimal address is really just 32 ones and zeros wearing a friendlier costume.

Now the problem. If an IPv4 address is 32 bits, then the total number of possible addresses is 2 to the power of 32, which is about 4.3 billion. In 1983, when there were a few hundred computers on the entire network, 4.3 billion seemed limitless. But the internet grew into a world of billions of phones, laptops, servers, cameras, thermostats, cars, and sensors, and 4.3 billion stopped being nearly enough. This is called IPv4 address exhaustion, and it played out over the 2010s exactly as engineers had feared decades earlier.

The industry responded in three ways. Two were stopgaps to stretch IPv4 further: private addressing and NAT, which we will cover next. The third was the real long-term fix: a brand-new addressing system with a vastly larger space, called IPv6. Almost every strange or clever thing about modern addressing traces back to this one root cause, the slow exhaustion of a 4.3 billion address ceiling that was set in 1983.

Public vs Private Addressing, and the Trick That Saved IPv4

Here is a question that reveals how the stopgap works. You might have five, ten, or twenty devices connected to your home network right now. Each one has an IP address. Yet your entire home shows up to the outside internet as a single address. How?

The answer is the split between public and private addressing, joined by a translation trick called NAT.

Three ranges of IPv4 addresses are reserved for private use, meaning they are never routed on the public internet. They are defined in a standard called RFC 1918, and they are:

10.0.0.0        to  10.255.255.255
172.16.0.0      to  172.31.255.255
192.168.0.0     to  192.168.255.255

Anyone can use these ranges inside their own network without asking permission, because they are not globally unique. Millions of home networks around the world use 192.168.0.x at the same time, and that causes no conflict, precisely because these addresses never appear on the public internet. This is why, if you check your laptop's address at home, it very likely starts with 192.168 or 10. That is a private address, visible only inside your own network.

So how does your privately-addressed laptop reach a public website? Through Network Address Translation, or NAT. Your router holds one public address, the one your internet provider assigns you, and it sits at the boundary between your private network and the public internet. When your laptop sends a request out, the router rewrites the packet so that it appears to come from the router's single public address. When the reply comes back, the router remembers which internal device asked, and forwards it to the right place. Every device in your home shares that one public address, taking turns through the router's translation table.

NAT was one of the two great stopgaps that kept IPv4 alive far longer than its address count should have allowed. It also has a quiet security side effect worth naming: because your internal devices are not directly addressable from the public internet, they are somewhat shielded from direct inbound connection. NAT was never designed as a security control, and it should never be relied on as one, but the isolation it creates is a real and useful side effect. We will come back to that idea, deliberate isolation, when we reach the security section, because it is the heart of why subnetting matters.

IPv6: The Real Fix

Stopgaps buy time. IPv6 was built to end the shortage permanently.

Where an IPv4 address is 32 bits, an IPv6 address is 128 bits. That change sounds modest, four times the bits, but because each added bit doubles the space, the result is staggering. IPv4 offers about 4.3 billion addresses. IPv6 offers 2 to the power of 128, which is roughly 340 undecillion, a number so large it is effectively beyond exhaustion. To put it in perspective, the smallest standard IPv6 subnet allocation contains more addresses than the square of the entire IPv4 internet. We are not going to run out of IPv6 addresses.

Because 128 bits would be absurd to write in dotted decimal, IPv6 uses a different notation: eight groups of four hexadecimal digits, separated by colons. A full IPv6 address looks like this:

2001:0db8:0000:0000:0000:8a2e:0370:7334

There are shorthand rules to compress the long runs of zeros, so in practice you often see something much shorter, like 2001:db8::8a2e:370:7334. The double colon stands in for a run of zero groups.

Two honest points about IPv6. First, it is not a distant future thing, it is here and running now, and it has been deploying since the mid-2000s. Second, and just as honestly, IPv4 has not gone away. Both systems run side by side across the internet today, and they will for years to come. This is why a working engineer has to be fluent in both, not one or the other. IPv6 is the destination, IPv4 is the enormous installed base we still live with, and the reality on the ground is both at once.

Subnetting: The Part Everyone Dreads, Done in the Right Order

Now for the section that makes people give up on networking. We are going to make it stick by building the idea first and doing the maths second.

Why divide a network at all?

Imagine a single flat network with thousands of devices on it. Every device can talk directly to every other device. This sounds convenient, but it is a problem for two reasons.

The first is noise and performance. Some network traffic is a broadcast, a message sent to every device at once. On a huge flat network, broadcasts reach thousands of machines, and all that unnecessary chatter clogs the network. The second reason is the one this series cares about most: security. On a flat network, anything that gets in can reach everything. There are no internal walls. An attacker or a piece of malware that compromises one machine can move sideways to every other machine, because they are all on the same undivided space.

Subnetting is the solution to both problems. It is the practice of dividing one large network into smaller, self-contained sub-networks, called subnets. Each subnet is its own contained space. Broadcasts stay inside their own subnet instead of flooding everything, which fixes the performance problem. And traffic between subnets has to pass through a router, where it can be filtered and controlled, which fixes the security problem by creating exactly the kind of internal walls a flat network lacks.

That is the whole idea. Everything below is just how we express it precisely.

The network part and the host part

Every IP address is secretly divided into two sections. The first section identifies the network (or subnet) the device is on. The second section identifies the specific device, called the host, within that network.

Think of the postal analogy one more time. A full address like "12 Baker Street, London" has a part that identifies the area (London, the street) and a part that identifies the specific building (number 12). The network part of an IP address is the area. The host part is the specific building. Devices in the same area, on the same subnet, share the same network part and differ only in their host part.

The question is: where is the dividing line between the two parts? That line is set by something called the subnet mask.

The subnet mask and CIDR notation

A subnet mask is a 32-bit value that marks which bits of an address belong to the network part and which belong to the host part. Every bit set to 1 in the mask means "this bit is network." Every bit set to 0 means "this bit is host." The ones always come first, all together, followed by the zeros.

The most common subnet mask is:

255.255.255.0

In binary that is twenty-four 1s followed by eight 0s. It says the first 24 bits of the address are the network, and the last 8 bits are the host.

Writing out full subnet masks is tedious, so modern networking uses a shorthand called CIDR notation. You simply write the address, a slash, and the number of network bits. So instead of saying "192.168.1.0 with a mask of 255.255.255.0," you write:

192.168.1.0/24

The /24 means "the first 24 bits are the network part." This single number, the prefix length, tells you everything about how the address is divided. A larger number after the slash means more bits given to the network and fewer left for hosts, which means a smaller subnet with fewer devices. A smaller number means a bigger subnet. That inverse relationship trips people up at first, so hold onto it: bigger slash number, smaller network.

The maths, worked step by step

Now we do the actual calculation, and because you understand what you are calculating, it will make sense rather than feel like magic.

For any subnet, there are a few things you want to work out: how many devices it can hold, the network address, and the broadcast address. Here are the rules, then a full worked example.

Counting the hosts. If a subnet has some number of host bits, call it h, then the number of usable device addresses is 2 to the power of h, minus 2. The formula is:

usable hosts = 2^(32 - prefix) - 2

Why minus 2? Because two addresses in every subnet are reserved and cannot be given to a device. The very first address, where all host bits are 0, is the network address, which names the subnet itself. The very last address, where all host bits are 1, is the broadcast address, used to send to every device in the subnet at once. Neither can be assigned to a real device, so we subtract them.

A full worked example: 192.168.1.0/24

The prefix is /24, so 24 bits are network and 32 minus 24, which is 8, are host.

Usable hosts = 2^8 - 2 = 256 - 2 = 254
Network address   = 192.168.1.0     (all 8 host bits = 0)
First usable host = 192.168.1.1
Last usable host  = 192.168.1.254
Broadcast address = 192.168.1.255   (all 8 host bits = 1)

So a /24 gives you 254 usable addresses, from .1 to .254, with .0 and .255 reserved. This is the classic home and small office network.

Now let us actually subnet: splitting that /24 into four smaller networks

Suppose you have that one /24 and you want to divide it into four separate subnets, perhaps one each for staff, guests, servers, and IoT devices, so you can wall them off from one another. This is subnetting in action.

To make four subnets, you need to borrow bits from the host part and give them to the network part. Four subnets is 2 to the power of 2, so you borrow 2 bits. Your prefix grows from /24 to /26.

A /26 means 26 network bits and 6 host bits. Let us work out one subnet fully:

Prefix /26  ->  host bits = 32 - 26 = 6
Addresses per subnet = 2^6 = 64
Usable hosts = 64 - 2 = 62

And the four subnets carve up the original range like this:

192.168.1.0/26    hosts .1   to .62     (broadcast .63)
192.168.1.64/26   hosts .65  to .126    (broadcast .127)
192.168.1.128/26  hosts .129 to .190    (broadcast .191)
192.168.1.192/26  hosts .193 to .254    (broadcast .255)

Look at what happened. The one network that held 254 devices is now four separate networks holding 62 devices each. Each is its own broadcast domain, and traffic moving between them must cross a router, where it can be controlled. You did not add any hardware. You simply moved the dividing line two bits to the right, and in doing so you created internal walls where there were none.

The binary underneath

Here is the binary view that shows why the boundaries land where they do. Take the address 192.168.1.75 and the mask for /24. To find the network address, the router performs a bitwise AND: wherever the mask has a 1, it keeps the address bit; wherever the mask has a 0, it forces the bit to 0.

  11000000.10101000.00000001.01001011   (192.168.1.75, the address)
AND
  11111111.11111111.11111111.00000000   (255.255.255.0, the /24 mask)
= 11000000.10101000.00000001.00000000   (192.168.1.0, the network)

The mask's 1s preserve the network part exactly, and its 0s wipe the host part to zero, leaving the network address. This single operation, done in hardware billions of times a second, is how every router on earth decides which subnet an address belongs to. Every subnetting question you will ever face is, underneath, just this: line up the bits, apply the mask, read off the boundaries.

A note on IPv6 subnetting

IPv6 uses the exact same CIDR slash notation, so everything you just learned about prefixes transfers directly. The main practical difference is that IPv6 subnets are, by strong convention, a /64. That leaves 64 bits for hosts, which is 2 to the power of 64 addresses in a single subnet, about 18 quintillion. Because address space is no longer scarce, IPv6 subnetting is less about squeezing every address out of a tight block and more about clean, consistent structure. The maths is identical. The scarcity mindset is gone.

The Security Payoff: Subnetting Is a Security Control

Everything above was leading here, because subnetting is not only an addressing and performance tool. It is one of the most fundamental security controls in all of networking, and it connects directly to the earlier posts in this series.

Recall the firewall post Behind the Wall: What Firewalls Really See, Block, and Miss, where the real danger was not the attacker getting in, but the attacker moving sideways once inside, from a low-value machine to the crown jewels, across a flat internal network. Subnetting is the structural defence against exactly that. By dividing a network into segments, you limit the attack surface and obstruct lateral movement. If an attacker compromises one machine, they cannot automatically reach the rest, because the other subnets sit behind a router boundary where traffic can be filtered and blocked. A malware infection in one subnet does not spread to another. The internal walls contain it.

This practice, dividing a network into isolated segments to control traffic and contain breaches, is called network segmentation, and subnetting is its foundation. It is why you put IoT devices, those cheap cameras and thermostats with weak security, on their own separate subnet, so that if one is compromised, the attacker is trapped in a segment with nothing valuable, unable to reach your servers or workstations.

There is a second security angle worth understanding, from the attacker's side. When a penetration tester or a real attacker gains a foothold in a network, one of the very first things they do is reconnaissance: mapping the network to find out what else is reachable. They use tools like Nmap to scan address ranges and discover live hosts and open services. The subnet structure is one of the first things this reconnaissance reveals, because the subnet mask tells an attacker how many other devices share the segment and where the boundaries are. A tester can only test what they can reach, and an attacker can only attack what they can reach. Good segmentation directly shrinks the internal attack surface by shrinking what any single compromised position can see. This is the network layer's version of the same lesson the whole series keeps returning to: control, and the lack of it, is structural. It lives in how the system is divided.

Commands to See Your Own Addressing

Everything here is visible on your own machine right now.

See your own IP address, subnet mask, and gateway:

ipconfig            (Windows, look for IPv4 Address and Subnet Mask)
ip a                (modern Linux)
ifconfig            (macOS and older Linux)

Look at the address. If it begins with 192.168 or 10, you are looking at a private RFC 1918 address, and NAT is translating for you every time you reach the internet. Note the subnet mask too, very often 255.255.255.0, your /24.

See the difference between your private and public address:

Your machine knows only its private address. To see the single public address your whole network shares, you can search "what is my IP address" in a browser. Compare the two. The private one is what your laptop calls itself. The public one is what the entire internet sees. The gap between them is NAT at work.

See your route to a destination, and the addresses along the way:

traceroute google.com     (tracert on Windows)

As in Post 2, every hop is a real router with its own address. Now you can read those addresses with understanding, spotting private ranges near your end and public ranges further out.

What You Now Understand

You started this post with a simple truth, that every device needs an address, and you now understand what that address actually is: a logical, changeable location marker at Layer 3, distinct from the fixed physical MAC address, exactly the mailing-address-versus-fingerprint split.

You know why the original IPv4 system, with its 4.3 billion address ceiling set in 1983, ran short, and the three responses that followed: private addressing, NAT, and ultimately IPv6 with its effectively limitless 128-bit space. You understand why your home network shares one public address, and you can now read your own private address and know what it means.

Most importantly, you did the thing most people give up on. You subnetted, in the right order. You understand why we divide networks before you memorised how, and then you did the how anyway: the network and host split, the subnet mask, CIDR notation, the host-counting formula, a full worked division of a /24 into four /26 subnets, and the bitwise AND underneath it all. And you saw that IPv6 uses the very same notation, just without the scarcity.

And you connected it back to the thread of the series: subnetting is not just plumbing, it is a security control. It is the structural foundation of network segmentation, the thing that contains breaches and obstructs the lateral movement that the firewall post warned about. Control lives in how a network is divided.

In the next post, we follow the address one step further. You now know how a device is located by its IP address, but you have never once typed an IP address to visit a website. You type a name, like google.com. The system that translates that human name into a machine address is DNS, the internet's phone book, and it is one of the oldest, most essential, and most quietly abused systems on the network. That is Post 5.

networking #security #beginners #tutorial

The Infrastructure Lens: Why Control of AI Lives in the Layers Underneath

VickkyKruz NetSec — Mon, 22 Jun 2026 23:07:39 +0000

Hi everyone 👋

I want to share a standalone piece I just published. It is a short detour from my Networking Foundations series, but it comes from the same instinct, so it felt worth writing.

Here is the idea.

As an infrastructure engineer, you learn not to start with the application a user sees. You start at the bottom of the stack and work up, because that is where the real constraints live. A website is only as available as the server beneath it. A server is only as reachable as the network beneath that. Control, capability, and failure all originate in the lower layers and cascade upward.

I took that exact instinct and pointed it at artificial intelligence. And through an infrastructure lens rather than a software one, something becomes clear that the louder conversations tend to miss.

AI is not really a software story. It is an infrastructure story.

Underneath every weightless little AI prompt sits a very physical stack: chips, data centres, electricity, cooling, water, land, and grid capacity. And each of those layers has a chokepoint, a place where a small number of actors control something everyone else depends on.

Consider just the energy layer. The single biggest constraint in the AI buildout right now is not chips or capital. It is electricity. In the largest data-centre hub on earth, some new projects have been warned they could wait up to seven years for a full grid connection. A single AI server rack can draw as much continuous power as a small building. The binding limit on AI is becoming physical.

Here is why that matters beyond the engineering. Because the layers are stacked, control of a lower layer cascades upward. Restrict who can buy advanced chips, and you have indirectly decided who can build data centres, which decides who can train models, which decides who can ship applications. You do not need to regulate a thousand applications if you control the one resource they all depend on.

The post also looks at the long history of critical infrastructure, railroads, steel, nuclear, the internet itself, and the consistent pattern of what happens once a technology becomes essential enough that a society cannot function without it.

I kept it deliberately structural rather than political. The point is not who is right or wrong. It is that infrastructure shapes what is possible, and that is an engineering truth, not a partisan one.

It also connects back to something personal. I once wrote about hitting paid usage limits on an AI tool and asking whether the pricing was exploiting how dependent I had become. This post is the structural answer to that frustration: the wall I kept hitting was placed several layers down the stack, in a room I would never see.

📖 Read it here: https://vickkykruzprogramming.dev/blog/the-infrastructure-lens-why-control-of-ai-lives-in-the-layers-underneath

It comes with four original diagrams, including the full five-layer AI infrastructure stack. Subscribe to my newsletter for more analysis that looks underneath the headlines.

AI #Infrastructure #CyberSecurity #DataCenters #CloudComputing #TechAnalysis #Engineering #DevOps

The OSI Model: Demystified, Not Memorised

VickkyKruz NetSec — Mon, 22 Jun 2026 22:35:19 +0000

Hi everyone 👋

Let me say something that might be controversial in tech education circles.

The way the OSI model is normally taught is the reason most people never actually understand it.

You know the drill. Seven layers, memorise them in order, use a mnemonic like "Please Do Not Throw Sausage Pizza Away," answer the exam question, and forget the whole thing within a week. You technically "learned" it, but you could not explain what it actually does or why it exists.

In Post 3 of my Networking Foundations series, I set out to fix that by teaching it the opposite way.

Here is the core idea: if you have followed the series so far, you already understand the hard part. You have already met packets, headers, encapsulation, IP addresses, and MAC addresses. The OSI model is simply the formal name for that structure. It is not new information to memorise. It is a label for something you already understand.

So the post does not ask you to memorise seven names. It teaches you seven jobs.

It covers:

→ Why the OSI model exists at all (the early networking world was a chaos of incompatible systems, and the industry needed a shared reference)
→ All seven layers explained as jobs, not names, each with its real-world protocols, devices, and data unit
→ The honest truth most tutorials skip: the internet does not actually run on OSI. It runs on the simpler four-layer TCP/IP model. The post includes a full side-by-side showing exactly how the two map together.
→ The security payoff that makes the whole model worth knowing

That last point is the one I care about most. When you understand the layers, you understand where in the stack any given attack operates, and therefore what kind of defence can possibly stop it.

A TCP SYN flood is a Layer 4 attack. No web application firewall (Layer 7) will stop it.

ARP poisoning is a Layer 2 attack. It happens below the level a traditional IP firewall even looks.

SQL injection is a Layer 7 attack. Your network firewall passes it happily, because to the network it looks like ordinary web traffic.

Match the defence to the layer, or it does nothing. That single skill, placing an attack on a layer and reasoning about the right defence, is worth more than any mnemonic.

The post includes four original diagrams: the full seven-layer stack, the encapsulation flow, a per-layer attack map, and the OSI vs TCP/IP comparison.

📖 Read Post 3 here: https://vickkykruzprogramming.dev/blog/the-osi-model-demystified-not-memorised

This is part of an ongoing 14-post series taking readers from the basics of networking through to Zero Trust security. Subscribe to our newsletter to get each new post as it publishes. 🔔

Networking #CyberSecurity #OSIModel #CCNA #NetworkSecurity #InfoSec #TechEducation #ITCareer #DevOps #LearnNetworking

How Data Actually Travels: Packets, Protocols, and the Postal Service Analogy

VickkyKruz NetSec — Wed, 17 Jun 2026 10:53:51 +0000

Hi everyone 👋

Here is something that sounds impossible but happens billions of times a second.

The email you sent this morning never travelled as a single message. Neither did this post. Neither did the last video call you were on.

Every one of them was torn into small pieces first.

Those pieces, called packets, were each stamped with an address, sent out individually (often by completely different routes through different cities and even different countries), and then reassembled at the destination into something that looked exactly like the original. All in a fraction of a second. All completely invisibly.

This is the single most important mechanism in all of networking. And once it clicks, almost everything else in the field starts to make sense.

So in Post 2 of my Networking Foundations series, I set out to make it click, using something everyone already understands: the postal service.

Here is the core idea.

Imagine posting a 500-page manuscript. You cannot fit it in one envelope, so you split it into 500 numbered pages, put each in its own envelope, and post them all. They travel by different routes, arrive out of order, and get sorted back into sequence on arrival using their page numbers.

That is exactly how data moves across a network. The manuscript is your email. The envelopes are packets. The sorting offices are routers.

From that one analogy, the post builds up every core concept:

→ What is actually inside a packet (header, payload, and trailer)
→ Encapsulation, the nested-envelope structure that wraps your data in layers
→ How routers move packets without any single one knowing the full route
→ How TTL stops packets from looping around the internet forever
→ How TCP uses sequence numbers and acknowledgements to recover lost packets and reorder them, turning an unreliable system into one that feels perfectly reliable

And then the part that matters most for anyone thinking about security.

A large amount of network traffic does not travel as a sealed letter. It travels as a postcard. The address has to be visible for routing to work, but on a postcard, so is the message. Anyone positioned along the route, on the same Wi-Fi, the same office network, the same coffee shop hotspot, can potentially read it using free, widely available tools.

This is why the difference between http and https is not a technicality. It is the difference between a postcard and a sealed envelope. On public Wi-Fi especially, it is the difference between your data being private and your data being readable by anyone nearby with five minutes and a laptop.

The post includes six original diagrams built specifically for it, including a full breakdown of packet anatomy, the encapsulation layers, and a side-by-side of what a packet sniffer sees with http versus https.

It is written for a mixed audience. Whether you are completely new to networking, a developer filling in the gaps, or someone studying towards a certification, it is built to meet you where you are.

📦 Read Post 2 here: https://vickkykruzprogramming.dev/blog/how-data-actually-travels-packets-protocols-and-the-postal-service-analogy

This is part of an ongoing 14-post series taking readers from the very basics of networking through to Zero Trust security. Subscribe to our newsletter to get each new post delivered as it publishes. 🔔

Networking #CyberSecurity #CCNA #NetworkSecurity #InfoSec #TechEducation #DevOps #ITCareer #LearnNetworking #DataPrivacy

What Is a Network? The Why Before the How

VickkyKruz NetSec — Tue, 12 May 2026 20:05:39 +0000

Hi everyone 👋

Now, before we dive into the nitty-gritty of things such as IP addresses, subnets, firewalls, and protocols, I have one question to start off with you.

What, according to you, was the first-ever message ever communicated through a computer network?

No, not "Hello, world."
And not something deep, either.
Quite simply, it was "LO".

One of the researchers at UCLA was typing the word "LOGIN" to the computer at the Stanford Research Institute, located about 350 miles away. The L arrived. The O arrived. He typed the G, and the system at Stanford crashed.

The message that was sent for the first time through a computer network was a sign of an inevitable failure. The two letters that emerged from that failure, however, have changed the entire history of networking.

That happened on October 29, 1969.

Recently, I have uploaded a premiere post for a new series: Networking Foundations, a 14-post series that covers you from the very first step in computer networking to Zero Trust security, cloud infrastructure, and packet analysis.

Post 1 is called: What is a network? The why before the how. And the "why" is a story most guides skip entirely.

Here’s‍‌‍‍‌ the blog talks about:
🔹 The comprehensive origin tale: from Cold War tensions to the very first four nodes of ARPANET
🔹 What exactly is a network: the proper definition starting from basics
🔹 The four kinds of networks (PAN, LAN, MAN, WAN) and how their security differ
🔹 What goes on when you input a URL: the whole process, each one of the attack surfaces
🔹 The trust issue: how the design of the internet is the main cause of most security problems
🔹 Useful commands: ping, traceroute, ipconfig, check out your network right ‍‌‍‍‌now

This supplement comprises four original diagrams crafted exclusively for the blog post, which include a geographic ARPANET map that depicts the initial four nodes and the first connection.

This is Post 1 of 14. The complete series will take you through topics such as IP addressing, DNS, cloud networking, packet analysis with Wireshark, and Zero Trust architecture, all the while incorporating security at every stage.

If you have ever desired a solid groundwork in networking, not a mere overview of the surface but an insightful, well-connected comprehension, this series has been designed for you.

📖 Read Post 1 here: https://vickkykruzprogramming.dev/blog/what-is-a-network-the-why-before-the-how

Also, get a subscription to our newsletter to have each new installment of the series straight into your inbox right when it gets published. 🔔

Networking #CyberSecurity #CCNA #NetworkingFoundations #InfoSec #TechLearning #ARPANET #ZeroTrust #ITCareer #DevOp

Behind the Wall: What Firewalls Really See, Block, and Miss

VickkyKruz NetSec — Fri, 01 May 2026 21:24:35 +0000

Hi everyone 👋

Just a quick question to you.

You have a firewall, right?

Well, your IT team has probably done the setup. It's gone live. And now you think you're protected.

But when was the last time you actually asked: what are the firewall's limitations?

This is what a majority of security presentations won't disclose:

→ According to statistics, more than 90% of online traffic is encrypted and most of the time firewalls are not able to access it.

→ Firewalls are designed to regulate the flow of data primarily between the internal network and the internet (north-south). So intruders can freely move around within your network (east-west) without being detected.

→ According to research, 95% of the cases where unauthorized access to firewalls take place happen due to errors in the configuration and not because of highly skilled hackers.

→ In the incident of Capital One data breach in 2019, here were more than 100 million customer records compromised due to a single misconfigured rule.

It's not that the firewall failed. The failure was the notion that just installing a firewall will be sufficient.

I've done a comprehensive research starting from the first firewall US prototype (UC Davis, 1988) and leading up to Zero Trust security concept, which fundamentally does away with the idea of a perimeter in security.

📌 Behind the Wall: What Firewalls Really See, Block, and Miss
🔗 Full article: https://vickkykruzprogramming.dev/blog/behind-the-wall-what-firewalls-really-see-block-and-miss

This post will definitely be helpful for those working in IT, security, networking, or generally handling any business infrastructure.

And if this has resulted in you questioning some of your assumptions, then sign up for our newsletter. We regularly publish cybersecurity and networking articles that go in-depth beyond the surface.

CyberSecurity #NetworkSecurity #Firewall #ZeroTrust #InfoSec #ITSecurity #NGFW #DataProtection

Why ‍UK Businesses Choose .co.uk Domain: The Untold ‍ ‌‍ ‍‌Story

VickkyKruz NetSec — Wed, 29 Apr 2026 11:37:36 +0000

Hey everyone 👋

I've got a little secret for you:

UK businesses didn't switch to .co.uk because they liked it over .com. 😊

For almost 30 years, it was the only commercial domain available under the .uk namespace. Businesses didn't pick it, the internet's design handed it to them.

The tale starts in 1985, when the UK was only the second country in the world to get its own domain. It continues with JANET UK's academic-only internet of the 80s the structural decision to designate .co.uk as the commercial-tier, and Nominet's establishment in 1996 that led to commercial registrations opening up.

I just put out the detailed explanation:

📌 Why UK Businesses Choose.co.uk, The Untold Story

Topics it touches on:

→ The full history from 1985 to present day

→ The reason.co.uk still retains 40 years of brand trust

→.com vs.co.uk vs.uk, when to go for each

→ A hands-on guide to all the major domain extensions

→ A 4-question framework to help you choose the right domain for your brand

Be it you are starting a new venture, doing rebranding, or just wondering, this article is a good read.

🔗 Full article: https://vickkykruzprogramming.dev/blog/why-uk-businesses-choose-co-uk-domain-the-untold-story

Do you find it helpful? Pass it on to a founder or business owner who is about to register a domain. Also, subscribe to our newsletter if you want to receive more practical business and digital guides. 🔔

UKBusiness #Domains #DigitalStrategy #StartupUK #SmallBusiness #Branding #WebDevelopment

Why SIM Cloning Isn't Used Anymore, And What Changed It

VickkyKruz NetSec — Fri, 17 Apr 2026 12:41:49 +0000

Hey all 👋

Many people think that hackers make a copy of your SIM card to steal your phone number. Actually? That method is mostly a historical technique from the 1990s.

The thing which superseded it is quite straightforward and even more frightening.

I have recently shared a blog post in which I explain it all:

📌 Why SIM Cloning Is No Longer Used, And What Changed It
Here I explain:

→ The real definition of SIM cloning (and why it is no longer working on today's networks)
→ SIM swapping, the social engineering strike that took over from the original
→ SS7 exploitation, the telecom door that most people are oblivious to
→ 5 easy defensive measures you can take right now

If you are relying on SMS for your 2FA, then this is definitely one for you.

🔗 Complete article: https://vickkykruzprogramming.dev/blog/why-sim-cloning-isn-t-used-anymore-and-what-changed-it

Like‍‌‍‍‌ and follow for more security-related content.
And if you want, you can subscribe to our newsletter to receive breakdowns just like this one directly in your ‍‌‍‍‌mailbox.

CyberSecurity #InfoSec #SIMSwap #DataPrivacy #DigitalSafety

StackSentry Is Now Installable — And We Need You to Break It

VickkyKruz NetSec — Sat, 11 Apr 2026 04:08:12 +0000

Hi everyone 👋

I've spent the last several weeks detailing everything about StackSentry, how it works, what it scans, how it auto-fixes security issues, and what you can expect from it across different stacks. Now it's time for the most important part: I need you to test it and tell me what breaks.

🛡️ StackSentry v1.0.0 is officially live on PyPI.

In one command, it scanned my own VPS, auto-fixed six security issues via SSH, and took the security grade from F (16.7%) to C (72.7%) — with zero attack paths detected after fixes.

pip install stacksentry

I'm looking for testers across all stacks: Flask, Django, PHP, WordPress, shared hosting, VPS. If you have a web app running anywhere, run it, open issues, and tell me what's wrong. Your feedback at this stage is everything.

I've written up the full story, what it does, how it works, and the proof in my latest article. Go through it and share your thoughts: 👉 https://vickkykruzprogramming.dev/blog/stacksentry-is-now-installable-and-we-need-you-to-break-it

Also, the full project README is on GitHub, it can be access here: 👉 https://github.com/vickkykruz/stacksentry

⭐ on GitHub helps it reach more people. Thank you in advance.

DevOps #Security #Python #OpenSource #WebDev