Re: [Tsv-art] [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13

[Fernando Gont <[e-mail]>]

Hello,

Thanks for the response. Inline....

On 08/12/2018 12:58 AM, Star Brilliant wrote:
>> * Page 15:
>>> It is the choice of a client to either
>>>    perform full DNSSEC validation of answers or to trust the DoH server
>>>    to do DNSSEC validation and inspect the AD (Authentic Data) bit in
>>>    the returned message to determine whether an answer was authentic or
>>>    not.
>>
>> Relying on the DoH server for DNSsec validation does not seem like a good idea.
>> You want DNSsec to be end-to-end.
> 
> We discussed about this paragraph before. The problem depends on how you deploy DoH services.
> 
> 1) For most people's needs, the users grab a list of DoH servers from the Internet and configure their systems to use the DoH servers. These public servers are untrustworthy. So the users need to validate DNSSEC at their end.

This is the scenario I was assuming, for which it seemed a bad idea to
ahve the DOH server do DNSsec validation. Anyway to clarify this so that
others do't fall into the same assumption?



>> * 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)'
> 
> If you are asking about "an HTTP error", here is the explain:
> 
> 1) Some errors indicates a problem happening on HTTP layer, not DNS layer.
> For example, 302 Redirection, 404 Not Found, 401 Unauthorized
> 
> 2) Sometimes it is technically impossible to reply with an encoded DNS response.
> For example, the web server crashed, throwing a default 500-504 error page
> 
> DoH is a double-layered protocol. It is intuitive that each layer may break, resulting with an error that represents that layer. (Additionally, since DoH runs on TCP/IP, a DoH server can even reply with an icmp-port-unreachable error.) Layered error is the nature of Internet protocols.
> 
> If you are asking about the TC bit, this happens in many situations. One cause is broken TCP on the authoritative server, which happens quite frequently with anycast servers.

My understanding of the quoted text above was that DoH might signal via
HTTP error codes some events that could also be signaled via DNS
responses.  -- whereas my expectation was for HTTP response codes to
only signal stuff related to HTTP stransport.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492