On 11.4.2017 20:39, Mike Bishop wrote: > Looks great – I’m excited to have another concrete application profile > we can look at. > > > > As a side note, I think 4.4 mischaracterizes any recent draft of > HTTP/QUIC. An HTTP server does explicitly need to listen for > client-initiated streams opening; there’s no announcement of this > happening on Stream 3 as you describe. The main effect of choosing to > have no control stream is that there can be no reliable session-level > application context, since data on any stream can be lost via a stream > reset at the wrong time. > > > > 5.2.2 is an example of this issue – how will the SERVFAIL be reliably > delivered if the stream is reset? You probably need to either define > error codes for DNS/QUIC and replace SERVFAIL with those, or reliably > deliver the SERVFAIL (somehow – by never resetting streams?).
Let me express support for Mike's comment above. Current text is confusing when it comes to SERVFAIL. Ad 6.4. DNS Message IDs: I'm in favor of the two blocks of proposed text: When sending multiple queries over a QUIC connection, clients MUST NOT reuse the DNS Message ID of an in-flight query on that connection in order to avoid Message ID collisions. Clients MUST match outstanding queries using the Message ID and if the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Reasoning: There are various DNS proxies which change transport protocol between UDP/TCP/TLS/HTTP on fly, without client knowing. We do not know how this landscape will evolve so it is IMHO better to specify the same behavior for message IDs and query matching regardless of transport to avoid problems with tricks we do not see today. The same applies to 6.3. Response Sizes. For now I propose to keep the same limitations for response sizes regardless of transport. Thank you for writting this down! Petr Špaček @ CZ.NIC > *From:*QUIC [mailto:[email protected]] *On Behalf Of *Christian Huitema > *Sent:* Monday, April 10, 2017 10:23 AM > *To:* [email protected]; [email protected] > *Subject:* Fwd: Fwd: New Version Notification for > draft-huitema-quic-dnsoquic-00.txt > > > > > > FYI: Just published this draft describing transport of DNS over a > dedicated QUIC connection. > > -- Christian Huitema > > -------- Forwarded Message -------- > > *Subject: * > > > > New Version Notification for draft-huitema-quic-dnsoquic-00.txt > > *Date: * > > > > Mon, 10 Apr 2017 09:45:37 -0700 > > *From: * > > > > [email protected] <mailto:[email protected]> > > *To: * > > > > Melinda Shore <[email protected]> <mailto:[email protected]>, Sara > Dickinson <[email protected]> <mailto:[email protected]>, Christian > Huitema <[email protected]> <mailto:[email protected]>, Allison > Mankin <[email protected]> <mailto:[email protected]>, > Janardhan Iyengar <[email protected]> <mailto:[email protected]>, Jana Iyengar > <[email protected]> <mailto:[email protected]> > > > > A new version of I-D, draft-huitema-quic-dnsoquic-00.txt > > has been successfully submitted by Christian Huitema and posted to the > > IETF repository. > > > > Name: draft-huitema-quic-dnsoquic > > Revision: 00 > > Title: Specification of DNS over QUIC > > Document date: 2017-04-10 > > Group: Individual Submission > > Pages: 18 > > URL: > https://www.ietf.org/internet-drafts/draft-huitema-quic-dnsoquic-00.txt > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-huitema-quic-dnsoquic-00.txt&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C5df00a51bfe64b16ca4b08d480363ab3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274417782332222&sdata=QxDgeYj6NMHseVKcgY%2Fv8pgLqj09avV1PnGaOJv7%2B3c%3D&reserved=0> > > Status: https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/ > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-huitema-quic-dnsoquic%2F&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C5df00a51bfe64b16ca4b08d480363ab3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274417782332222&sdata=c7MuOxq2w3L2jz3MWcwA96gCJq8l3ckGjnCF6fHJfNk%3D&reserved=0> > > Htmlized: https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-00 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-huitema-quic-dnsoquic-00&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C5df00a51bfe64b16ca4b08d480363ab3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274417782332222&sdata=i4nBJms1WZwRo78vAZWFSAlfuH49H8zD2WjQIu2Gqwc%3D&reserved=0> > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-huitema-quic-dnsoquic-00 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-huitema-quic-dnsoquic-00&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C5df00a51bfe64b16ca4b08d480363ab3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274417782332222&sdata=JywZYehy3Axc7sDXskM2mGeW4kdiiPBSMZlbicD1N58%3D&reserved=0> > > > > > > Abstract: > > This document describes the use of QUIC to provide transport privacy > > for DNS. The encryption provided by QUIC has similar properties to > > that provided by TLS, while QUIC transport eliminates the head-of- > > line blocking issues inherent with TCP and provides more efficient > > error corrections than UDP. DNS over QUIC has privacy properties > > similar to DNS over TLS specified in RFC7858, and performance similar > > to classic DNS over UDP. > > > > > > > > > > > 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. > > > > The IETF Secretariat _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
