I noticed that Quad 9 is not able to respond to the spy.pet query:
$ dig spy.pet @9.9.9.9 +short
;; communications error to 9.9.9.9#53: timed out
But Cloudflare DNS is able to do it:
$ dig spy.pet @1.1.1.1 +short
104.26.0.165
104.26.1.165
172.67.74.73
And to be sure, I checked another domain with the same TLD to rule out the option that Quad9 is unable to handle the .pet TLD, but I received a correct answer…
$ dig hello.pet @9.9.9.9 +short
3.64.163.50
Does Quad9 censor DNS queries?
Making a DNS server not respond to queries for a specific name is trivial for any DNS provider to implement, this is not a situation where they would have to develop months worth of new features to support that if the government asked.
It might not be that easy, you’re thinking about one single server running some kind of DNS server you’re familiar with. When we’re talking about Quad9, Cloudflare etc. were talking about hundreds of servers across the planet, highly distributed solutions that rely on multicast and other non-trivial techniques. If you’ve to change a system like that to add the ability to block something, trust me, it won’t take a few hours.
It would literally be easier to add that capability to your own custom DNS server software. After all it is literally an “if query.name in blocklist then drop connection”. Even replacing results would be simple as long as DNSSEC is not involved. You wouldn’t have to add it though since all major DNS servers already include it because it is so simple and has legitimate uses, such as blocking malware control server names or ad blocking.
Yes, it is likely that most providers running custom generic or custom stacks already have the functionally built in and also yes, adding an “if” is easy but then once you’ve thousands of servers running the same piece of software across the globe deploying updates and features becomes way slower and way harder. You’ve to consider tests, regressions, a way to properly store and sincronize the blocklists across nodes etc…
How much simpler can I make this…
You have a primary ‘master’ server in the pool.
Replica/cache servers periodically ask the master for any updates.
Master gives a new update, which is a sinkhole for a marked malicious domain.
Replica/cache server now resolves malicious domain to the sinkhole address.
This is not a ‘feature’ you have to implement, it’s a basic function of running a redundant DNS system.
DNS is literally distributed by design. It’s how it works. Even if a deployment was done for some reason, it would not take more than a single engineer (an engineer really isn’t even necessary for this, because again, it’s built into DNS).
You know you can setup a single instance of PDNS or other resolver and by default they all work in a non-distributed way. You assuming to much, and again while it is likely that most providers running custom stacks already have the functionally built in, it isn’t a guarantee and once you’ve thousands of servers running the same piece of software across the globe deploying updates and features becomes way slower and way harder.
That is not what they do, though. Just because a non standard configuration is possible doesn’t mean that’s the best thing to use. DNS, by design, uses authoritative nameservers, which is what cloudflare and quad9 host. These authoritative hosts distribute their records to caches (usually just recursive DNS resolvers) to ease and distribute the load. It’s literally in all of their documentation, and explained in pretty plain english on their pages.
https://www.cloudflare.com/learning/dns/what-is-dns/ https://www.quad9.net/about/
When a record is updated in your domain (or cloud) provider, it is distributed via an authoritative nameserver hosted by that company. These get distributed to the root name servers, which then distribute the records to other authoritative nameservers.
I don’t know why you’re arguing over this, when it’s one of the first things you learn in information systems and networking. Sure, there’s a lot of stuff for the infrastructure. But the way DNS works on these hosts is still the same, and blocking a single record is not difficult and does not take extra engineering effort. The authoratative hosts simply change their records and it’s done. DNS takes care of the rest.
There’s an entire wikipedia page on this: https://en.wikipedia.org/wiki/DNS_blocking
The thing is, everything you said is correct. But if you think they can just solve this globally for everyone and everything without delays by just pushing things their root servers or the first line of authoritative ones then what else can I say.
They can, because that’s how DNS works. This is why when you update a record for your domain it’s updated globally in near real time with multiple providers. I don’t know how else to tell you that it already works this way. I work in the cloud, and deal with this stuff on a daily basis.
Depending on the TTL, right ?
Correct!
So, you know that “near real time” is different from actual real time.
You’re clearly going keep nitpicking and changing the subject to things that don’t matter and you’re not willing to learn. Your misunderstanding of the fundamentals of DNS is no longer my issue.