Credit: The original article is published here.
Cloudflare’s 1.1.1.1 DNS resolver service fell victim to a simultaneous BGP hijack and route leak event, causing massive internet outages and degradation worldwide. Pakistan caused the most famous BGP outage. The government tried to block access to YouTube within the country. Their misconfiguration caused a worldwide YouTube outage.
Most organizations are targets of attacks 7.5 times a year. And while most are resolved quickly, these are examples of public infrastructure failures that are beyond your control.
What other technology do you rely on every day that was invented in the 1980s? Not your smartphone. Not your car. Not your TV. And definitely not your work tools. Yet, every time you send an email, connect to a website, or deploy a cloud service, you’re relying on core internet protocols that predate the web itself.
The Fragile Foundation
The Border Gateway Protocol (BGP) was designed in 1989, an era when the “internet” was barely a concept and security was an afterthought. Back then:
– Home users connected via dial-up modems.
– Businesses considered themselves cutting-edge if they had a T1 line.
– Network reliability was a hope, not an expectation.
BGP’s original purpose was simple: keep the nascent internet stitched together. It provided large institutions with a means to announce which IP address blocks they controlled and to learn about others. The protocol allowed routers across autonomous systems (ASes) to share route announcements and dynamically discover paths to distant networks.
BGP was designed for resilience, not determinism. For openness, not security.
Speed, uptime, and security
Today, we demand speed, uptime, and security that BGP was never built to deliver. Multi-gigabit fiber reaches homes. Enterprises span multiple clouds across continents. Workloads like real-time video, financial transactions, and machine learning require low-latency, high-throughput data paths.
However, BGP still routes traffic based on trust and reachability, rather than performance or identity. It can’t enforce policies. It can’t prevent hijacks. And it certainly can’t guarantee who’s on the other end.
Despite multiple security incidents and efforts, such as RPKI and BGPsec, the internet still routes traffic based on a chain of trust that can be exploited by anyone with a few malicious route announcements. Most fixes require coordination that doesn’t exist and IT infrastructure upgrades that move at glacial speed.
The result? The modern internet rides on a protocol that thinks it’s still 1992.
Public by Default
Another artifact of that era is the Domain Name System (DNS). Created to make numeric IP addresses human-readable, DNS transformed how people accessed websites. Instead of memorizing strings of numbers, you could simply type in a name.
The problem? DNS is public by design.
Every query, every resolution, and every domain is visible and discoverable. Attackers can enumerate subdomains, discover shadow IT resources, and probe for vulnerabilities – all by posing as legitimate users.
We’ve seen this pattern before. Consider phone numbers. In the 1990s, receiving a call or piece of mail felt like an event. Now? Most calls are spam, and most email is junk. People don’t pick up unless they recognize the number. Our relationship with public identifiers has undergone a fundamental shift.
The same evolution is happening with network services. Public IP addresses and DNS names are easily scraped, scanned, and attacked. In an age of automation and AI-assisted hacking, exposing your infrastructure by default amounts to sending an invitation.
Yet we continue treating server addresses like phone numbers in a white pages directory – a model that no longer works for the threats we face.
Obsolete Assumptions
Both BGP and DNS reflect assumptions that simply don’t hold up anymore:
– Assumption: Networks are trusted.
— Reality: Most attacks now originate from within or via compromised peers.
– Assumption: Routes are stable.
— Reality: Internet routes change unpredictably due to performance tuning, outages, and misconfigurations.
– Assumption: Identities don’t matter.
— Reality: Zero-trust architecture has become the standard for secure design.
– Assumption: Services are few and fixed.
— Reality: Modern architectures dynamically spin up and down thousands of services.
The more we scale and automate, the more these assumptions crumble.
Time for a Rethink
The internet’s early architecture was undeniably brilliant for its time. But that time has passed.
Today’s needs are different. We need:
– Deterministic data paths that can be trusted end-to-end.
– Secure naming systems that are private by default.
– Policy-aware routing that aligns with business, performance, and compliance requirements.
– A model where services announce themselves securely to authorized peers, not to the entire internet.
These aren’t enhancements; they’re necessities.
The irony is striking: everything else in tech has evolved dramatically. Compute became elastic. Storage turned redundant and distributed. Deployment went fully automated. But networking? It’s still largely manual, primarily public, and built mainly on 40-year-old concepts.
This should be our wake-up call. We can’t keep patching internet security with duct tape and hoping for the best. It’s time to challenge the status quo and ask a hard question: are the foundational protocols we depend on every day actually fit for purpose anymore?
Security and privacy can’t remain afterthoughts we layer onto a crumbling foundation. They need to be built from the ground up. That means completely reimagining how the internet connects, routes, and identifies everything.
Think about it: what other critical system in your life still runs on ideas from the 1980s?
LINK!
This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro
