Hacker News Reader

Comment by cracker_jacks | Hacker News Reader

I think you're arguing against the wrong thing here. You want decentralization of DNS. I don't see DoH really impacting this issue in any clear direction.

On one hand, you have centralized DNS (based on your ISP). DoH gives you some choice over that now through your browser. On the other, you have only a handful of DNS providers to choose from. DoH is just a technology, there's nothing preventing ISPs from still providing their DNS services over HTTPS.

View on HN

> I don't see DoH really impacting this issue in any clear direction.

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

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.

(sorry for the late response!)

> 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!

[1] RFC 882, page 13, "NAME SERVERS" https://tools.ietf.org/html/rfc882#page-13

[2] RFC 882, page 14, "Authority and administrative control of domains" https://tools.ietf.org/html/rfc882#page-14

[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."

Reply on news.ycombinator.com