It’s interesting idea. We have not discuss that before. I’m not sure the impact of bad HTTP proxies to this protocol. Anyway it is not free to register a new head filed. I will discuss with co-author about delivering the TCP/UDP massage via other meta format. Thanks for your interest and comments.
Davey 发件人: DNSOP [mailto:[email protected]] 代表 Adrien de Croy 发送时间: 2016年5月3日 13:25 收件人: Adrien de Croy; Davey Song; [email protected] 主题: Re: [DNSOP] Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt One other thing... there are plenty of http proxies that will rightly or wrongly strip or reject unknown header fields. Since you're proposing the use of POST to send the query, why not also include the Proxy-DNS-Transport value as POST data also. either inside the application/dns-wireformat definition, or some other new meta format, or just base64 encode the message, and include both parts as form data (application/x-www-form-encoded). The same applies to unknown response headers (may be stripped or blocked) Regards Adrien ------ Original Message ------ From: "Adrien de Croy" <[email protected]> To: "Davey Song" <[email protected]>; "[email protected]" <[email protected]> Sent: 3/05/2016 5:14:31 p.m. Subject: Re: [DNSOP] Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt Hi Davey Some general comments: I don't think you can claim that https provides data integrity or privacy any more, since MitM proxies are abundant. I think some thought should be given to how a DNS stub might deal with a captive portal or http proxy authentication. I think also that any HTTP server that receives such a request probably ought to be validating the encapsulated binary data before forwarding it to any DNS server. I wonder why you'd want to keep truncation, as the request should be able to benefit from the fact that fundamentally it's made over TCP to the HTTP agent. I would also suggest looking into how such requests might be best blocked by an http proxy, because this will be a requirement of proxy operators, and it would be good to consider user experience for when this happens, so that a consistent approach can be taken (rather than every different proxy blocking it some other way so that the user experience becomes awful). Cheers Adrien ------ Original Message ------ From: "Davey Song" <[email protected]> To: "[email protected]" <[email protected]> Sent: 27/04/2016 8:43:09 p.m. Subject: [DNSOP] Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt Hi Colleagues, We have update the dns-wireformat draft according to the advice we gained from last IETF meeting, changing the well-known URI from dns-over-http to dns-wireformat according to Paul Hoffman's suggestion. Any further comments ? I would like to ask for WG to adopt it this time. Best regards, Davey ---------- Forwarded message ---------- From: <[email protected]> Date: 27 April 2016 at 16:03 Subject: New Version Notification for draft-song-dns-wireformat-http-03.txt To: "Paul A. Vixie" <[email protected]>, Shane Kerr <[email protected]>, Runxia Wan <[email protected]>, Linjian Song <[email protected]> A new version of I-D, draft-song-dns-wireformat-http-03.txt has been successfully submitted by Linjian Song and posted to the IETF repository. Name: draft-song-dns-wireformat-http Revision: 03 Title: DNS wire-format over HTTP Document date: 2016-04-27 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-song-dns-wireformat-http-03.txt Status: https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/ Htmlized: https://tools.ietf.org/html/draft-song-dns-wireformat-http-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-song-dns-wireformat-http-03 Abstract: This memo introduces a way to tunnel DNS data over HTTP. This may be useful in any situation where DNS is not working properly, such as when there is middlebox misbehavior. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/> . The IETF Secretariat
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
