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

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 10 Apr 2017 11:03:32 -0700

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.

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 11 Apr 2017 08:52:44 +0000

Hi Paul,

Interesting read thanks. 

I wonder how common the scenario is where a h2 or QUIC endpoint can also service DNS. Do you have any concrete examples?

In the context of h2, how do you think this proposal compares to say performing DNS-over-HTTP? My gut feel is that the proposed DNS frame is a semantic change because it changes the stream life cycle i.e. stream open and close are controlled by sending/receiving DNS frames. Such semantic changes require negotiation, for example by exchanging SETTINGS frames. This could be done on connection initiation and may solve your service discovery in a different way. 

In the context of QUIC, I'm not aware of any text (yet) that specifies how to extend the transport. Is the use of the DNS frame restricted to only HTTP/QUIC connections or could it be used on all types, e.g. DNS/QUIC. It seems a bit strange to be able to express DNS in two different formats on the same connection.

Regards
Lucas

________________________________________
From: QUIC [[email-masked]] on behalf of Paul Hoffman [[email-masked]]
Sent: 10 April 2017 19:03
To: [email-masked]
Subject: Additional DNS-over-QUIC draft with a different use case

--Paul Hoffman

Abstract:

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 11 Apr 2017 07:54:48 -0700

On 11 Apr 2017, at 1:52, Lucas Pardue wrote:

> Interesting read thanks.
>
> I wonder how common the scenario is where a h2 or QUIC endpoint can 
> also service DNS. Do you have any concrete examples?

Any h2 or QUIC endpoint "can" service DNS. Of course, none of them do so 
today because there is no protocol support for it.

Having said that, we know that the operators of some large web sites 
also want to give their customers the best DNS they can because doing so 
protects their customers and because the cost of doing so is small in 
terms of bandwidth and CPU. Google and Yandex are current examples of 
these.

> In the context of h2, how do you think this proposal compares to say 
> performing DNS-over-HTTP?

Much cleaner, if done correctly.

> My gut feel is that the proposed DNS frame is a semantic change 
> because it changes the stream life cycle i.e. stream open and close 
> are controlled by sending/receiving DNS frames.

The draft doesn't suggest closing the stream after the response frame, 
at least not intentionally.

> Such semantic changes require negotiation, for example by exchanging 
> SETTINGS frames. This could be done on connection initiation and may 
> solve your service discovery in a different way.

Or, a better solution for DNS-over-h2 could be made. This was just a 
stake in the ground with a first guess. Other folks have suggested 
reserving stream numbers for DNS, for example; that might be better than 
DNS frames.

> In the context of QUIC, I'm not aware of any text (yet) that specifies 
> how to extend the transport. Is the use of the DNS frame restricted to 
> only HTTP/QUIC connections or could it be used on all types, e.g. 
> DNS/QUIC. It seems a bit strange to be able to express DNS in two 
> different formats on the same connection.

Agree. If there is a clean way to do DNS-over-h2, and that can then be 
done directly in QUIC, there is no reason to have two mechanisms.

--Paul Hoffman

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 11 Apr 2017 16:01:47 +0000

Paul Hoffman wrote:
 
> The draft doesn't suggest closing the stream after the response frame, at
> least not intentionally.

My language was a bit unclear. From the I-D, the definition of DNS frame is stated as using the END_STREAM flag identically to the DATA frame. So, reception of the DNS frame with the flag set (for either request or response) could cause the stream to enter half-closed or closed. 

On further thought, since END_STREAM is being reused, the semantic change would come from defining a mechanism to transition a stream from idle to open state. One way around this is to reserve a stream(s) as you've mentioned. However, I'd argue that this is also a semantic change, since endpoints expect stream ID usage to follow RFC 7540.

QUIC usage could be simpler I think, if this is pitched as a HTTP extension, which possibly avoids the topic of QUIC extensions. If streams are reserved, the DNS request/response could be carried as a QUIC STREAM frame (in a similar way to how HTTP/QUIC DATA frames are). If the DNS frame concept is to remain, it would itself be carried inside the QUIC STREAM frame.

> Or, a better solution for DNS-over-h2 could be made. This was just a stake in
> the ground with a first guess. Other folks have suggested reserving stream
> numbers for DNS, for example; that might be better than DNS frames.
> 

Stakes in the ground are helpful, so thanks for taking the time to write up your ideas.

Here's a stupid idea, how about hanging the DNS-inside-HTTP interactions off of a well-known URI? This solves some of the problems around stream initiation (using existing h2 semantics for lifecycle management or reservation). The DNS requests/responses are then carried as application payload in DATA frames. Apologies if this echoes other ideas thrown about for DNS-over-HTTP that I am unfamiliar with.

Regards
Lucas