Hacker News new | past | comments | ask | show | jobs | submit login

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




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: