3 ms·

You're naming some things that have notoriously bad performance. Being slow doesn't guarantee failure but it sure isn't a feature. And the problem isn't the pr

by zrm 7y ago

You're naming some things that have notoriously bad performance. Being slow doesn't guarantee failure but it sure isn't a feature. And the problem isn't the protocol here, it's the choice of resolver. If the resolver on your LAN made queries using DoH instead of the application itself then your ISP still couldn't read them, but you would regain the benefits of local caching.

pvg 7y ago
They don't have 'notoriously bad performance' because of DNS or lack of some sort of global DNS caching. That just isn't the case. Firefox also didn't honour systemwide proxy settings for a decade+, nobody really cared because it fundamentally didn't matter. If the DNS thing was that important, somebody would have complained about it before. Nobody (statistically) ever did, any more than they did about the proxy thing.
- zrm 7y ago
  Sure, they had notoriously bad performance for a plurality of reasons. Which also explains the lack of specific complaints. People can tell you that it's slow, that doesn't mean they can tell you every reason why. Firefox historically being slower than Chrome was for a long time one of main reasons cited by people who switched from Firefox to Chrome. DNS/proxy defaults were certainly not the only reason it was slower but all the little things add up. And we shouldn't need to use user complaints to gauge performance impact when we can do so directly by measuring page load times etc.
  - pvg 7y ago
    I mean, we started with 'does DoH break caching' to which the answer I think is quite clearly 'no' and we're now on to 'do apps doing their own resolving break anything materially important' to which the answer I think is also 'no' and yours is a pretty unspecific 'maybe'. I don't think these are bad or unwarranted questions (a lot of the anti-DoH arguments are significantly worse) but I'm fairly confident they have a straightforward, empirically-supported negative answer.
    - zrm 7y ago
      We started with "does running your own recursive resolver break caching" to which the answer is yes, because it removes intermediary caches that can really improve query latency. It doesn't have to remove 100% of all caches to make caching much less effective. But having the browser bypass local caches and query directly to the internet (entirely regardless of DoH or not) does much the same. The last level cache on the local network is particularly significant because it should have the best hit rate of any cache before the query latency gets multiplied by a factor of 50 or more by going out to the internet. Caching or not should never "break anything" unless you've seriously screwed up. It's always a matter of the performance impact. Which users will regularly gripe about without being able to articulate what's causing it. The practical impact of this depends on the context. If your browser is running in a data center across the street from the DoH server with a 3ms round trip latency and you're making a single query, it'll be imperceptible. When your internet link has a 50+ms latency and you're making multiple queries (which may have serial dependencies), it quickly adds up to hundreds of milliseconds. And some people are on satellite links with 500+ms latencies where this matters a lot.

by zrm 7y ago

pvg 7y ago

They don't have 'notoriously bad performance' because of DNS or lack of some sort of global DNS caching. That just isn't the case. Firefox also didn't honour systemwide proxy settings for a decade+, nobody really cared because it fundamentally didn't matter. If the DNS thing was that important, somebody would have complained about it before. Nobody (statistically) ever did, any more than they did about the proxy thing.

zrm 7y ago
Sure, they had notoriously bad performance for a plurality of reasons. Which also explains the lack of specific complaints. People can tell you that it's slow, that doesn't mean they can tell you every reason why. Firefox historically being slower than Chrome was for a long time one of main reasons cited by people who switched from Firefox to Chrome. DNS/proxy defaults were certainly not the only reason it was slower but all the little things add up. And we shouldn't need to use user complaints to gauge performance impact when we can do so directly by measuring page load times etc.
- pvg 7y ago
  I mean, we started with 'does DoH break caching' to which the answer I think is quite clearly 'no' and we're now on to 'do apps doing their own resolving break anything materially important' to which the answer I think is also 'no' and yours is a pretty unspecific 'maybe'. I don't think these are bad or unwarranted questions (a lot of the anti-DoH arguments are significantly worse) but I'm fairly confident they have a straightforward, empirically-supported negative answer.
  - zrm 7y ago
    We started with "does running your own recursive resolver break caching" to which the answer is yes, because it removes intermediary caches that can really improve query latency. It doesn't have to remove 100% of all caches to make caching much less effective. But having the browser bypass local caches and query directly to the internet (entirely regardless of DoH or not) does much the same. The last level cache on the local network is particularly significant because it should have the best hit rate of any cache before the query latency gets multiplied by a factor of 50 or more by going out to the internet. Caching or not should never "break anything" unless you've seriously screwed up. It's always a matter of the performance impact. Which users will regularly gripe about without being able to articulate what's causing it. The practical impact of this depends on the context. If your browser is running in a data center across the street from the DoH server with a 3ms round trip latency and you're making a single query, it'll be imperceptible. When your internet link has a 50+ms latency and you're making multiple queries (which may have serial dependencies), it quickly adds up to hundreds of milliseconds. And some people are on satellite links with 500+ms latencies where this matters a lot.