4 ms·

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 o

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.

pdkl95 7y ago
> 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 https://news.ycombinator.com/item?id=21110296 [2] https://news.ycombinator.com/item?id=21309811 https://news.ycombinator.com/item?id=21309811
- cracker_jacks 7y ago
  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.
  - pdkl95 7y ago
    (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 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 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."

pdkl95 7y ago

> 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 https://news.ycombinator.com/item?id=21110296 [2] https://news.ycombinator.com/item?id=21309811 https://news.ycombinator.com/item?id=21309811

cracker_jacks 7y ago
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.
- pdkl95 7y ago
  (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 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 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."