3 ms·

A comment on that post: “I’m the original author of this code, though I no longer maintain it. ”Just want to give folks a heads-up that we’ve been in discussi

by fwlr 4y ago

A comment on that post: “I’m the original author of this code, though I no longer maintain it. ”Just want to give folks a heads-up that we’ve been in discussion with various parties about this for some time now, as we agree the negative effects on the root servers are undesirable. So in terms of “do the Chromium folks know/care”; yes, and yes. ”This is a challenging problem to solve, as we’ve repeatedly seen in the past that NXDOMAIN hijacking is pervasive (I can’t speak quantitatively or claim that “exception rather than the norm” is false, but it’s certainly at least very common), and network operators often actively worked around previous attempts to detect it in order to ensure they could hijack without Chromium detecting it. ”We do have some proposed designs to fix; at this point much of the issue is engineering bandwidth. Though I’m sure that if ISPs wanted to cooperate with us on a reliable way to detect NXDOMAIN hijacking, we wouldn’t object. Ideally, we wouldn’t have to frustrate them, nor they us.” A way for DNS root servers and Chromium devs to cooperate that couldn’t be hijacked by domain redirecting ISPs would be nice.

sneak 4y ago
Chrome simply talking DoH to Google (or other trustworthy non-hijacking) servers by default would fix this totally.
- tptacek 4y ago
  Fix what, though? This is an insignificant load on a piece of core infrastructure for which all of the load from all of the users of the world's most popular Internet application is still a rounding error error relative to capacity. This is what those servers are there to do!
  - jeroenhd 4y ago
    Those servers are for looking up real domains, they're not designed to be a detection mechanism for malicious actors. Chrome intentionally fires unresolveable uncacheable domains at the root servers. That's dishonest use of public infrastructure at the very least. I doubt Google would be happy if Microsoft or Apple were to build a network availability tool into their systems that executes random Google queries that won't get you a result to see if searches are being redirected.
    - tptacek 4y ago
      Says who? The RFCs disagree: just look at all the resource record types. The DNS standards people have been saying for years that the DNS should also be a secure object storage system, because that's a capability DNSSEC brings. Unlike that purely hypothetical use case, this is real people using the DNS roots for an actually important day-to-day function. There's nothing dishonest about what Chrome is doing: it's sending unresolveable uncachable names specifically to avoid ISP DNS servers caching them and tricking users into believing that NXDOMAINs are clean. This isn't Google using a competitor's resources. It's Google's users using core Internet infrastructure. It's core infra for a reason. We're not required to use it parsimoniously. I have the impression that most of the concerned comments on this thread believe that Chrome's NXDOMAIN detection is somehow a burden on the Internet roots. It is not. It's prominent on a graph, and that's all. The Internet roots are, by necessity, designed to handle immense amounts of traffic.
jesprenj 4y ago
Chrome simply using DNSSEC and NSEC(3) by default would fix this to a great extent.
- tptacek 4y ago
  It wouldn't fix it even a little bit, because DNSSEC is a server-to-server protocol, and the "threat" in this scenario is your upstream DNS server. It would, on the other hand, create enormous new load on the DNS infrastructure.
  - jesprenj 4y ago
    Chrome could just behave like a resolver. Or operating systems could start behaving like resolvers on ::1. DNS was designed with trusted resolvers in mind (was it?), but we've shifted towards using resolvers of our ISPs and random companies. I can see the appeal of caching across a WAN, but then again, we don't use HTTP proxies anymore, which provide a similar caching feature. Integrity protection should be placed higher in our priority list than caching effectiveness. Maybe the impact on root servers created with selfhosted resolvers would decrease as chromium wouldn't have to query random TLDs -- root could just be cached for days. Actually, thinking about caching root, why don't resolvers already cache root? Chrome wouldn't have such an impact if NSEC from root was remembered by resolvers. DNSSEC solves this problem even nowadays.
    - tptacek 4y ago
      If you're suggesting that DNS was designed with endpoint resolvers, rather than upstream caching resolvers, in mind: no, it's the opposite. The DNS architecture assumes that your browser relies on a caching DNS server somewhere. DNSSEC is hardly deployed at all and doesn't really enter into this story. It doesn't change anything about what Chrome is trying to do, and, were it actually deployed, would dwarf all other causes of increased root server loads by itself.

by fwlr 4y ago

sneak 4y ago

Chrome simply talking DoH to Google (or other trustworthy non-hijacking) servers by default would fix this totally.

tptacek 4y ago
Fix what, though? This is an insignificant load on a piece of core infrastructure for which all of the load from all of the users of the world's most popular Internet application is still a rounding error error relative to capacity. This is what those servers are there to do!
- jeroenhd 4y ago
  Those servers are for looking up real domains, they're not designed to be a detection mechanism for malicious actors. Chrome intentionally fires unresolveable uncacheable domains at the root servers. That's dishonest use of public infrastructure at the very least. I doubt Google would be happy if Microsoft or Apple were to build a network availability tool into their systems that executes random Google queries that won't get you a result to see if searches are being redirected.
  - tptacek 4y ago
    Says who? The RFCs disagree: just look at all the resource record types. The DNS standards people have been saying for years that the DNS should also be a secure object storage system, because that's a capability DNSSEC brings. Unlike that purely hypothetical use case, this is real people using the DNS roots for an actually important day-to-day function. There's nothing dishonest about what Chrome is doing: it's sending unresolveable uncachable names specifically to avoid ISP DNS servers caching them and tricking users into believing that NXDOMAINs are clean. This isn't Google using a competitor's resources. It's Google's users using core Internet infrastructure. It's core infra for a reason. We're not required to use it parsimoniously. I have the impression that most of the concerned comments on this thread believe that Chrome's NXDOMAIN detection is somehow a burden on the Internet roots. It is not. It's prominent on a graph, and that's all. The Internet roots are, by necessity, designed to handle immense amounts of traffic.

jesprenj 4y ago

Chrome simply using DNSSEC and NSEC(3) by default would fix this to a great extent.

tptacek 4y ago
It wouldn't fix it even a little bit, because DNSSEC is a server-to-server protocol, and the "threat" in this scenario is your upstream DNS server. It would, on the other hand, create enormous new load on the DNS infrastructure.
- jesprenj 4y ago
  Chrome could just behave like a resolver. Or operating systems could start behaving like resolvers on ::1. DNS was designed with trusted resolvers in mind (was it?), but we've shifted towards using resolvers of our ISPs and random companies. I can see the appeal of caching across a WAN, but then again, we don't use HTTP proxies anymore, which provide a similar caching feature. Integrity protection should be placed higher in our priority list than caching effectiveness. Maybe the impact on root servers created with selfhosted resolvers would decrease as chromium wouldn't have to query random TLDs -- root could just be cached for days. Actually, thinking about caching root, why don't resolvers already cache root? Chrome wouldn't have such an impact if NSEC from root was remembered by resolvers. DNSSEC solves this problem even nowadays.
  - tptacek 4y ago
    If you're suggesting that DNS was designed with endpoint resolvers, rather than upstream caching resolvers, in mind: no, it's the opposite. The DNS architecture assumes that your browser relies on a caching DNS server somewhere. DNSSEC is hardly deployed at all and doesn't really enter into this story. It doesn't change anything about what Chrome is trying to do, and, were it actually deployed, would dwarf all other causes of increased root server loads by itself.