3 ms·
> DoH does not help you at at all if your browser is going to go to an IP that is on a watchlist. That is the author's (and Paul Vixie's point). If that's the
by karasu 7y ago
> DoH does not help you at at all if your browser is going to go to an IP that is on a watchlist. That is the author's (and Paul Vixie's point).
If that's the aim then I have to concur that DoH does nothing here. This is why I dislike the way Mozilla touts DoH as a privacy feature, because that's not what it (primarily) should be about, as far as I'm concerned.
> Technically speaking, if you're not getting DNSSEC signed results back, you're also trusting your DoH provider to not manipulate records. ;)
Agreed. But that's exactly why you can pick a trusted resolver, right? One that you trust to correctly validate DNSSEC for you, so you simply trust the AD bit in the response instead of doing all this on each and every client. And one that you trust not to mess with answers in general. Without either DoT or DoH, you are basically forced to validate DNSSEC on every Client, which seems like a waste.
- throw0101a 7y ago> Without either DoT or DoH, you are basically forced to validate DNSSEC on every Client, which seems like a waste. Part of Vixie's talk was about the changing nature/position of the recursive resolver: when he started DNS stuff in 1988, it was often the case that there was a resolver right on the subnet that you were on, often living on the default gateway. As time has gone on, it started moving "up" closer to the cloud (as we now call it): to being building-wide, then to the campus, and now generally the ISP. (Though local CPE routers have a caching resolver nowadays, they often go to the ISP's service.) Now we're talking about having DNS 'in the cloud' (i.e., Internet) from some distant provider, often close (network/latency-wise) to the service that we will eventually connecting to once we get the look-up from.