Draft: draft-ietf-doh-dns-over-https-latest

Commentary: on list   points out that we do n't mention some pretty key architectural benefits of doh such as authentication , amplification resistance , etc . on list as " changes for draft - ietf - doh - dns - over - https-03 " . is meant to address this 
 Hi , following few impressions on advantageous aspects of doh : For sure , the experience aquired in mitigation against hammering attacks on " HTTP " layer is much more effective and well - ruled than DDoS mitigation(s ) when comparing to UDP DNS , due to persisting amplification attacks . Many different APIs to expire contents are available on a system layer ( Cloudflare , squid , find / rm ) , many HTTP request headers too on a protocl layer , so shall be widely possible to " control " cache validity with non - DNS methods , when system is responsive ( i.e. can take little longer).Compression , modernised with brotli and binary proto . I also sustain the need of a mention to the HEAD method as cache priming or verification method .. Is it desired , interesting , considered any useful by the working group ? ( Stephane brought this up to  as a bug , but me too I was considering it since ever)Leveraging CDN caches ( when atomic , i.e.  , CF - ID ) is another immediate advantage , but as discussed in the CNAME / A thread there might arise issues with ADDITIONAL / AUTHORITY sections ' validity ( my implementation used to squeeze the two in one consistent response , which is doable in DNS terms , for the sake of the service ... or give shortened responses and iterate trough natural granularity of DNS messaging).Preemptive / ALL caching is less interesting to me personally , but I understand the relatively low effort required by infrastructure to take this extra burden of caching+refreshing it ( we now always desire to get the most records at once ... ) . Might state that too , that DNSSEC interactions will require more storage , or more bandwidth , or refer to it . Talking about Auth / Auth , OAuth or all the SSO you can name , are clearly BIG advantages ( i.e. refuse some clients or geo - locate / displace others ) . I was thinking MAC / DAC reasonings were to fall outside of DNS - over - HTTP draft , IMHO ... is not a " native " feature of DNS , as - is ... what is your opinion ? to me is HTTP.OTOH , a more precise Accounting is a native aspect coming straight out of doh ( making accounting easier if ever needed , my old implementation accounted for billing , not a new thing ) . To me , just because some companies do bill on imprecise Netflow stats , accurate tcpdumps on mirror ports , or even weirder things , does n't mean DOH can not state ( mention ) about " billabilty " at the net of SYN , SYN / ACK , ACK , retransmissions and RESETS :) :) Having a line like : " as any other HTTP dialogue , DNS - over - HTTP might offer possibility to have its usage logged and billed " . For some companies it might be a plus , let 's not tell them they could have done it with bind or plugins :) Traceability ? Is a mention to logging needed ? ( or needs to be implied as any HTTP does?).The detail of the query itself might not be available to authorities via such simplified logs anyway , and that has been made clear during the  tables anyway , by  regarding POSTs for example . In my previous exp in law enforcment for telco -started with landlines then switched to web- European ISP and hosting providers were obliged / required to provide HTTP and mail logs by investigating authorities ( at their own cost of maintenance , law enforcment might be a dead budget for smaller companies ) . It was 2006 , 2009 then 2016 things have n't much improved , just the sensibility towards the topic but not the smoothness of process and guarantee of security in personal / sensible data treatment , in medium companies not just . Many product offer since day 1 full auditing features , FGA in Oracle for example , simple or complex as be , is just matter of using them :( But why DNS traces are not always taken in consideration by all authorities , or everything becomes " best - effort " ? The queries / responses might not be traced / traceable , surely not in post - mortem , only some providers can / do . Not sponsoring any point of view on justice or privacy . ... this for doh is an evolution and an involution : the space needed to account for the long - term - storage might be an argument not to spouse doh . Obviously , filtering out is easy ( ct= ) By mentioning such aspect(s ) we can help answering frequent questions before they 're even been asked : +1 : As we are realising , mixing the experts from 2 different worlds of DNS and HTTP is not easy , so the more dialectical the best ? With clear examples for sure . I just think that people need to think what is DOH and what does and what does n't automagically do ( extra certificates , extra logs , " slower " but maybe faster , etc ) so to be able to compare pros / cons comparing to non HTTP / DNS servers / clients . To me is doh is just a transport thing , and I really like it since many years :) sorry for super long post , will copy this to mailing list if you think is useful . 
 I agree with almost everything you say , but I do n't think the  protocol doc is the place to got at all of these things at this length . I 'm just trying to give a flavor of the implications of using the http ecosystem - which you go into in much deeper detail . The document has to focus on how you do that . my suggestion would be you raise the concept of a separate applicability / use - case document if you think this is valuable .. you could raise this as part of the charter discussion for DoH. Or you could just work on a really great blog post :) 
 Thank you I will follow all of your suggestions , just a matter of having some time to say something " useful " and hopefully , possibly correct . I am still willing to follow all of the discussions around the doh topic , I have a lot to learn from all of you , really proud of your consideration . I understand the logic of defining precise specifications and how - to - implement , proper of drafting RFC . I fully support the criteria of " referring to " other standing and specific RFCs by keeping the transversal implications outside of the doc , as it might over - confuse implementors and this is not the goal . Sorry for that , I just wanted to mention some of the possible " arguments " or side - effects ( my first time in participating in such exciting discussions and group ) . My congratulations to all of the working group and supporters , for all the efforts being put into this important draft
Paragraph (version A):
The Internet does not always provide end to end reachability for
native DNS.  On-path network devices may spoof DNS responses, block
DNS requests, or just redirect DNS queries to different DNS servers
that give less-than-honest answers.
Paragraph (version B):
The Internet does not always provide end to end reachability for
native DNS.  On-path network devices may spoof DNS responses, block
DNS requests, or just redirect DNS queries to different DNS servers
that give less-than-honest answers.  These are also sometimes
delivered with poor performance or reduced feature sets.
Paragraph (version A):
The described approach is more than a tunnel over HTTP.  It
establishes default media formatting types for requests and responses
but uses normal HTTP content negotiation mechanisms for selecting
alternatives that endpoints may prefer in anticipation of serving new
use cases.  In addition to this media type negotiation, it aligns
itself with HTTP features such as caching, redirection, proxying, and
compression.
Paragraph (version B):
The described approach is more than a tunnel over HTTP.  It
establishes default media formatting types for requests and responses
but uses normal HTTP content negotiation mechanisms for selecting
alternatives that endpoints may prefer in anticipation of serving new
use cases.  In addition to this media type negotiation, it aligns
itself with HTTP features such as caching, redirection, proxying,
authentication, and compression.
Paragraph (version A):
Running DNS over HTTPS relies on the security of the underlying HTTP
transport.  Implementations utilizing HTTP/2 benefit from the TLS
profile defined in RFC7540 Section 9.2.
Paragraph (version B):
Running DNS over HTTPS relies on the security of the underlying HTTP
transport.  This mitigates classic amplication attacks for UDP-based
DNS.  Implementations utilizing HTTP/2 benefit from the TLS profile
defined in RFC7540 Section 9.2.