This is a strange definition of decentralization. I suppose it gives you redundancy. But aren't you broadcasting information about your request to multiple parties if you're doing recursive resolution from different providers?
But I agree that this should be a choice on the client-side.
> This is a strange definition of decentralization.
DNS is - by definition[1] - a distributed database.
Name servers store a distributed database consisting of the
structure of the domain name space, the resource sets associated
with domain names, [...]
> I suppose it gives you redundancy.
The distributed database is about administrative boundaries[2].
Authority is vested in name servers. A name server has
authority over all of its domain until it delegates authority
for a subdomain to some other name server.
Redundancy in the DNS system is provided by a requirement that at least two authoritative nameservers must be listed when delegating authority to a subdomain.
> But aren't you broadcasting information about your request to multiple parties
Recursive resolution only involves multiple parties when the authoritative nameserver for a DNS zone[3] isn't known and again when the TTL (time-to-live) for the zone's NS record expires. Once the NS records are cached locally, queries only involve one party. DNS is a very flexible system that is designed to allow queries at any level and easy caching.
Also, consider that TTL for different record types is often very different. The only record that necessarily must be requested from the 2nd-level domain (".com") or other central server (like 8.8.8.8) are the NS records for a zone. Using the IETF's rfc server in [1] as an example, to lookup the A record for "tools.ietf.org", we first (unfortunately) leak information to .org (or 8.8.8.8, etc) to discover the domain's authoritative servers:
;; SERVER: 8.8.8.8#53
;; QUESTION SECTION:
;tools.ietf.org. IN NS
;; ANSWER SECTION:
tools.ietf.org. 1209600 IN NS heroldrebe.levkowetz.com.
tools.ietf.org. 1209600 IN NS zinfandel.levkowetz.com.
tools.ietf.org. 1209600 IN NS dechaunac.levkowetz.com.
tools.ietf.org. 1209600 IN NS dunkelfelder.levkowetz.com.
tools.ietf.org. 1209600 IN NS durif.levkowetz.com.
We then cache that locally for 1209600 seconds (14 days!). While this does leak the fact that you asked about something in the ".ietf.org" zone to a central server, two (apx)
of these requests per month* doesn't reveal much about your pattern-of-life.
The TTLs of A (and AAAA) records tend to be much shorter, sometimes unnecessarily short for better surveillance resolution. In this case, IETF is using a fairly standard 10 minutes:
;; SERVER: 4.31.198.61#53 (durif.levkowetz.com)
;; QUESTION SECTION:
;tools.ietf.org. IN A
;; ANSWER SECTION:
tools.ietf.org. 600 IN A 4.31.198.61
tools.ietf.org. 600 IN A 4.31.198.62
tools.ietf.org. 600 IN A 64.170.98.42
For comparison, the A record for graph.facebook.com (their big "analytics"/spyware ingress server) seems to have a random TTL between ~5 and 59 seconds. Thy are effectively forcing a DNS query on every analytics event. That's insane, but my point is that doing the recursive resolution locally means that almost all of those DNS queries are sent to dns.facebook.com only. The upstream DNS at the ISP or 8.8.8.8 only gets ~two UDP packets per month. With DoH, all of that still happens, but it has to be routed though Cloudflare first!
[3] From [1], "In general, a name server will be an authority for all or part of a particular domain. The region covered by this authority is called a zone."
See my other posts[1][2] about why DoH explicitly requires centralization.
> you have centralized DNS (based on your ISP)
You might, I don't, because DNS doesn't require that the client delegate recursive resolution to an upstream server.
[1] https://news.ycombinator.com/item?id=21110296
[2] https://news.ycombinator.com/item?id=21309811