Additional DNS-over-QUIC draft with a different use case

["Paul Hoffman" <[e-mail]>]

Related to Christian's recent announcement of 
draft-huitema-quic-dnsoquic, here a different draft that also are of 
interest to the QUIC WG. The drafts have different use cases. The 
solutions spaces for the use cases are different (reusing an existing 
connection instead of starting a new one). We think that both might be 
of interest to the IETF given that both should help make DNS traffic 
private.

I also created a parallel draft about DNS in existing HTTP/2 streams, 
but will send that to the HTTPBIS WG.

--Paul Hoffman

Name:		draft-hoffman-dns-in-existing-quic
Revision:	00
Title:		Running DNS in Existing QUIC Connections
Document date:	2017-04-10
Group:		Individual Submission
Pages:		6
URL:            
https://www.ietf.org/internet-drafts/draft-hoffman-dns-in-existing-quic-00.txt
Status:         
https://datatracker.ietf.org/doc/draft-hoffman-dns-in-existing-quic/
Htmlized:       
https://tools.ietf.org/html/draft-hoffman-dns-in-existing-quic-00
Htmlized:       
https://datatracker.ietf.org/doc/html/draft-hoffman-dns-in-existing-quic-00


Abstract:
   Intermediaries such as governments and ISPs spoof DNS responses, and
   block DNS requests to particular recursive resolvers, for a variety
   of reasons.  They spoof by capturing traffic on port 53, or by
   redirecting port 853 traffic in the hopes that the client is using
   opportunistic encryption.  They block if they know the address of a
   resolver that they don't like, such as public resolvers that give
   honest answers.

   This document describes how to run DNS service over existing QUIC
   connections, such as those being used for HTTP for basic web service.
   This design prevents intermediaries from spoofing DNS responses, and
   makes it impossible for intermediaries to block the use of those
   recursive resolvers without blocking the desired HTTP connections.
   It also prevents intermediaries or passive observers from seeing the
   DNS traffic.  This design is meant for communication between a DNS
   stub resolver and a DNS recursive resolver.