On Aug 11, 2018, at 3:56 PM, Patrick McManus <pmcmanus@xxxxxxxxxxx> wrote: > * Page 16: > > A DoH server is allowed to answer queries with any valid DNS > > response. For example, a valid DNS response might have the TC > > (truncation) bit set in the DNS header to indicate that the server > > was not able to retrieve a full answer for the query but is providing > > the best answer it could get. A DoH server can reply to queries with > > an HTTP error for queries that it cannot fulfill. > > Why should this happen? Why not encode this information in the encoded DNS > response (in wire format)' There was a lot of discussion in the WG about this. The result was similar to what Star replied: let the semantics of the inner protocol (DNS) retain their exact meanings, and let the semantics of the outer layer (HTTP) retain their exact meaning. A DoH client is expected to understand DNS errors *and* be a real HTTP client that can deal with normal HTTP semantics. On Aug 11, 2018, at 4:19 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote: > What I had in mind when making this comment is this: There seem to be > anycast resolvers implementing DoH (e.g., CLoudflare's and others, if I > understand correctly). Giving them the responsibility for DNSsec > validation would seem to me as giving them way too much power (i.e., > what if they were compromised and/or went evil?) DoH clients are no different in this regard than normal DNS (port 53) or DNS-over-TLS clients. Any of the three types of DNS client can do its own DNS validation by asking for the supporting DNS records; DoH by design doesn't change this at all. But to be clear, the ratio of end clients that do their own validation is still incredibly small. >> * Page 15 (Security Considerations): >> >> DoH essentialy switches from a connection-less transport (UDP) to a >> connection-oriented one (TCP). >> >> I disagree a bit. It adds a third TCP based DNS based approach to the >> DNS over TCP and DNS over TLS approaches already standardized so it is >> not breaking new ground in that sense. > > To put it in a different way: > > * What would be the impact if an attacker were to DoS TCP-based > resolution in the traditional case? (i.e., while UDP-based resolution > still works) > > * What would be the impact if an attacker were to DoS (HTTPS/)TCP-based > resolution in the DoH case? > > If the impact were the same, then just say that, and no need to worry. > But my understanding is that in current deployments you normally only > fall back to TCP when the UDP response was truncated, whereas with DoH, > you rely 100% on TCP. DoH servers do not need to reside on the same hosts as DNS/UDP or DNS/TCP servers. Cloudflare happens to do so, possibly due to address cuteness, but there is nothing in the protocol that says they should. The impact on DoH server on attacks is identical to the impact on attacks on normal TLS-based web services. > I don't mean you need to elaborate on how to defend it. JUst noted that > if you completely get rid of UDP-base resolution, then the TCP one (in > this case DoH) becomes even more critical, and the impact of a DoS > against TCP-based resolution is higher. And defending a stateful > protocol like TCP against resource exhaustion attacks is non-trivial. DoH is never expected to "get rid of UDP-based resolution". The use cases for DoH are very much a subset of the use cases for general DNS resolution, and that will be UDP-based for the foreseeable future. > Maybe I'm a bit confused. If, on the same connection, I send a request > to resolve "A" and subsequently a request to resolve "B", the result of > the later might come before than the result of the former? (I'm trying > to understand what the "ordering guarantees" that are not provided with > DoH). Yep! This is why the DoH WG has been such a good learning experience for DNS folks about the modern HTTP world, and for HTTP folks for the modern DNS world. We're not all holding hands and singing kumbaya yet, but at least we understand better the weirdnesses that the others take for granted. --Paul Hoffman
