Just quoting the article, can anyone weigh in on the costs/complexity of a public DNS resolver implementing geo-fencing?
I was a small part of the original team that built OpenDNS. I also operate a less well known public resolver now.
DNS is extremely latency sensitive. You have basically a 20ms budget to work with, which includes the time the request and response traverse the internet. It is also extremely high volume, a large public service like Quad9 could easily see single digit millions of requests per second.
There is nothing that technically prevents you from doing geofencing. Cisco has the money to absorb the costs of the additional overhead - but I could not. My first stab at the problem would be to simply shut down my servers in France to try to get out of the legal jurisdiction. I don't know if that would be sufficient without paying for a lawyer.
Quad9 absolutely has a valid argument here and it pushes more of our public infrastructure into the centralized hands of a small number of players because people like me can't afford to just run free shit on the internet anymore.
I don't know what is unique about Quad9 that they couldn't do this, but it's possible they have some technical limitation
Have you implemented something at that scale to say this is no big deal for them to do? And what about when 180 countries want their own list and maybe even states, providences, etc do as well?
Also keep in mind we’re talking about Cisco here and not some Ruby on Rails shop.
Anyway, I’m a big fan of the “fuck country $x” approach
Assuming this is total blocks for all of Quad9 globally? Spread this over 4 nameservers in a region (assuming anycast), with let's say 4 global regions (to be conservative)? That would be 1.985Mbps per server. That's (max!) 484 DNS requests per second, with 1/500th the bandwidth.
DNS is probably the fastest protocol on the internet other than ICMP. You can handle a ton of traffic with minimal hardware. Bump up the CPU to handle more interrupts/iptables rules. Buy a NIC with packet offload for even less CPU use (thus handling more requests). And eBPF & XDP would be much faster than netfilter.
If you were already gonna accept the request, process it, and send back a reply, dropping the packet doesn't cost you anything. It actually saves bandwidth, tx interrupts, and possibly CPU cycles.
Netfilter is plenty fast, when configured sensibly. You'd probably want script to populate a "hash:net" ipset instead, and have just one iptables rule:
-A INPUT \
-m set --match-set geoblock \
-j DROP
Do you even know what Quad9 does or why it's a thing?
Are you honestly suggesting they just need to add a couple CPUs and some different NICs?