3 ms·
In that sense neither would putting a recursive resolver in your OS. DNS can have arbitrarily many levels of caching, because stub resolvers can be caches and
by zrm 7y ago
In that sense neither would putting a recursive resolver in your OS.
DNS can have arbitrarily many levels of caching, because stub resolvers can be caches and can point to other stub resolvers.
For example, you might have a DNS cache in your OS so that if more than one process asks to resolve the same name (or the same process asks more than once because it doesn't have internal caching), only one query has to be made. That resolver may point to a DNS cache on your LAN (deduplicating queries between devices), which in turn may point to a recursive resolver on the internet, which may itself be caching data from the authoritative servers.
If you replace that with DoH between the application and the recursive resolver on the internet, all the intermediary caches are eliminated, even though they might have had significantly lower response times than the resolver on the internet.
- pvg 7y agoI'm not quite following all of this but before I try to sort it out in detail, is the fundamental objection here 'a DOH-using app is not using the OS resolver'?
- zrm 7y agoThat is effectively what causes the issue. The local resolver in the OS or on the LAN may have the name cached (because some other application or device requested it previously) and is thereby able to respond in <1ms, but if the application doesn't use them it has to take a round trip to the internet.
- pvg 7y agoAh I see. I don't find it particularly convincing as a thing leveled at DoH specifically because apps have been doing this for years. Browsers, Electron apps, Unity apps, whatnot. All have lived happy and successful lives without lookup latencies or the internet-as-we-know-it suffering any obvious ill effects. It's not a meaningful critique of DoH because we know the problems the critique warns of haven't really been problems.
- zrm 7y agoYou'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 agoThey 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 agoSure, 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 agoI 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.