Let's not forget the core shakiness and trust-based nature of BGP will be our ultimate safeguard against an AGI takeover.
Lack of authentication, inherent vulnerabilities to route hijacks and leaks, and reliance on mutual trust rather than verification...If AGI tries to assert global dominance, BGP will be the fail-safe 'red button' to prevent an AI apocalypse.
Unfortunately BGP will probably be mostly solid in a few more years. At least solid enough among countries with caring ISPs. Prime for the AGI pickings.
RPKI/ROA does not solve BGP hijacking [1]: "Even with RPKI validation enforced, a BGP actor could still impersonate your origin AS and advertise your BGP route through a malicious router configuration."
It also would not have prevented the bulk of this issue (as the next AS Path was "1031 262504 267613 13335", and would have been accepted by RPKI) so I am confused why Cloudflare claims it to be the solution. Perhaps Cloudflare's own engineers forgot that RPKI is still insecure?
Did 1.0.0.1 not work? Do people not use the backup resolvers that providers offer? I didn't even know that there was an outage. Cloudflare is much faster than quad9, at least for my connection. Talking like sub 10ms response vs 30+ for other providers.
I use Technitium and legacy DNS on my internal network. I have Technitium setup to use DoH to cloudflare for all the requests it makes. Best of both worlds IMO
Considering their 1.1.1.1/32 advertisement was a RTBH (Remotely triggered blackhole), it is likely they advertised the route automatically as a result of DDoS.
It is common for ISPs to blackhole (nullroute) an IP address that is experiencing DDoS to protect the rest of the network. In this case, they were learning this route from a peer (not a customer), and should not RTBH under any circumstance, but that boils down to a misconfiguration.
DJB was right. We should have used Curve 25519 for encryption in DNS itself. Then we wouldn't have needed DoT nor DoH, and we'd still have had a pretty good measure of privacy relative to ISPs and eavesdroppers.
I don't think DNSSEC would help in the common case of non-validating stub resolvers querying a public resolver. My understanding is that the DNS query response from a DNSSEC-validating public recursive resolver doesn't contain the information required for the stub client to validate it, only a single AD bit.
Probably not, I can't remember the last time I looked at 'resolvectl' output and saw anything other than "DNSSEC: no" on any system so I assume it mostly just doesn't exist in practice
Next, get zone files for the TLDs themselves. Not every TLD makes that freely or easily available, but https://github.com/jschauma/tld-zoneinfo is an excellent resource.
The author of the above repo runs https://netmeister.org/tldstats/ which will give you an idea of scale; they're able to get 98.89% of all TLDs.
(Correction: zone files for ccTLDs are mostly unavailable. That 98.89% is only domain count coverage, not zone file coverage.)
1) It's distributed. There's not a single database with all the DNS records in existence. Each zone is responsible for hosting and serving their own records.
2) The TTL for a DNS record can be 0.
Edit:
3) AXFR is blocked on 'most' zones. You would need this to know all the records in a zone.
When Jane Deer creates a new Blog jane-deer.com, your local database would not know which server to contact to resolve it, and nobody is gonna notify the database in your home.
So you would have to contact some other kind of database outside your home to find out how to resolve that domain--which you might have already realized sounds a lot like a (non-local) DNS server...
There are too many reasons to list. But the primary reasons DNS is a hierarchy of DNS services hosted by many distinct groups. And DNS records are queriable publicly, but also consider private. Almost all servers in the world disable AFRX for a variety reasons.
Beyond that DNS servers are not just a "database" of records, they are services that can return different results depending on who queried. And this is quite common with CDNs.
There are many more reasons, but let's talk about what you could do.
You could download a list of all registered domains, and then query all of them for the most common records. It would take hours, not include 99.9 percent all records, and be out of date the second it completes. With this database, you could visit some websites, but many host services on subdomains and you have no way to dynamically get that list when you're populating the database.
The gist is because DNS gets updated. Your computer already has a local cache of all DNS responses it receives and relies on those until that entry expires (as set by the TTL field). If you want to run a local resolver, you can, but it wouldn't solve this problem, because you'll still need to update your cache regularly and guess how you do that? With DNS.
The next question from there might be why do DNS responses change so frequently? I don't have an exact statistic, but most of them don't (I would guess 90%), so you could probably indefinitely cache those. But the ones that do, iirc, it's usually to allow quicker changes (esp. if the site is under active development), load balancing, global distribution, etc.
How would you update that database? Who would you ask for the updates?
IPs change out from under domains constantly. How would knowledge of those changes make their way from the owner of the domain to your local database?
If you'd want a single source of truth to receive and distribute that info, that's a single point of failure and comes with lots of technical challenges. And it's less "you could never get this 1%" and more "you will never need 99.9% of this"
------------------------------------------------
However, that's all entirely unrelated to this Cloudflare incident, which involved no domains at all, only raw IP addresses. This was an incident involving BGP, which is how the various providers of internet backbone know which other provider they connect to is able to answer requests made to a given IP address, and how changes to that information propagate.
Readit News
Lack of authentication, inherent vulnerabilities to route hijacks and leaks, and reliance on mutual trust rather than verification...If AGI tries to assert global dominance, BGP will be the fail-safe 'red button' to prevent an AI apocalypse.
https://radar.cloudflare.com/routing
Unfortunately BGP will probably be mostly solid in a few more years. At least solid enough among countries with caring ISPs. Prime for the AGI pickings.
It also would not have prevented the bulk of this issue (as the next AS Path was "1031 262504 267613 13335", and would have been accepted by RPKI) so I am confused why Cloudflare claims it to be the solution. Perhaps Cloudflare's own engineers forgot that RPKI is still insecure?
[1] https://blog.cloudflare.com/rpki-details
Swapped to Quad9[1], been using them since.
Was debating setting up my own recursive resolver, but the privacy aspect seemed less than ideal. Damed if you do, damed if you don't kinda.
[1]: https://www.quad9.net/
I use Technitium and legacy DNS on my internal network. I have Technitium setup to use DoH to cloudflare for all the requests it makes. Best of both worlds IMO
I run Pi-hole, haven't noticed any significant difference in speed. But good point, will see if I can find that DNS benchmark tool again.
But yeah, it was more that the privacy implications are unclear to me.
It is common for ISPs to blackhole (nullroute) an IP address that is experiencing DDoS to protect the rest of the network. In this case, they were learning this route from a peer (not a customer), and should not RTBH under any circumstance, but that boils down to a misconfiguration.
Edit: Could this have been used to hijack/create TLS certificates?
Protection could be validating DNSSEC (most likely not)
Or using DoH (DNS over HTTPS) or DoT (DNS over TLS)
Not writed in the post, does anyone know?
I don't want a 'you could never get this 1%" because of X straight up. What percentage could I get and why is this not easy?
First, grab the root zone file which points to all the TLD nameservers: https://www.internic.net/domain/root.zone
Next, get zone files for the TLDs themselves. Not every TLD makes that freely or easily available, but https://github.com/jschauma/tld-zoneinfo is an excellent resource.
The author of the above repo runs https://netmeister.org/tldstats/ which will give you an idea of scale; they're able to get 98.89% of all TLDs.
(Correction: zone files for ccTLDs are mostly unavailable. That 98.89% is only domain count coverage, not zone file coverage.)
But mostly it's about how the DNS changes, a lot. Sites move, geo records, etc. Getting those changes to every household would be a lot of traffic.
Before DNS folk were sharing a common /etc/hosts file - and quickly determined there had to be a better way.
So, DNS with a dozen root servers that stay fresh, caching down stream.
2) The TTL for a DNS record can be 0.
Edit:
3) AXFR is blocked on 'most' zones. You would need this to know all the records in a zone.
When Jane Deer creates a new Blog jane-deer.com, your local database would not know which server to contact to resolve it, and nobody is gonna notify the database in your home.
So you would have to contact some other kind of database outside your home to find out how to resolve that domain--which you might have already realized sounds a lot like a (non-local) DNS server...
Beyond that DNS servers are not just a "database" of records, they are services that can return different results depending on who queried. And this is quite common with CDNs.
There are many more reasons, but let's talk about what you could do.
You could download a list of all registered domains, and then query all of them for the most common records. It would take hours, not include 99.9 percent all records, and be out of date the second it completes. With this database, you could visit some websites, but many host services on subdomains and you have no way to dynamically get that list when you're populating the database.
The next question from there might be why do DNS responses change so frequently? I don't have an exact statistic, but most of them don't (I would guess 90%), so you could probably indefinitely cache those. But the ones that do, iirc, it's usually to allow quicker changes (esp. if the site is under active development), load balancing, global distribution, etc.
I hope that's helpful.
IPs change out from under domains constantly. How would knowledge of those changes make their way from the owner of the domain to your local database?
If you'd want a single source of truth to receive and distribute that info, that's a single point of failure and comes with lots of technical challenges. And it's less "you could never get this 1%" and more "you will never need 99.9% of this"
------------------------------------------------
However, that's all entirely unrelated to this Cloudflare incident, which involved no domains at all, only raw IP addresses. This was an incident involving BGP, which is how the various providers of internet backbone know which other provider they connect to is able to answer requests made to a given IP address, and how changes to that information propagate.