Subject: [DNSOP] The DNSOP WG has placed draft-song-dns-wireformat-http in state "Candidate for WG Adoption"

From: IETF Secretariat <[email-masked]>
Date: Fri, 01 Jul 2016 00:51:46 -0700

The DNSOP WG has placed draft-song-dns-wireformat-http in state 
Candidate for WG Adoption (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/

---

From: Bob Harold <[email-masked]>
Date: Tue, 5 Jul 2016 13:17:03 -0400

On Fri, Jul 1, 2016 at 3:51 AM, IETF Secretariat <
[email-masked]> wrote:

> I support adoption and will review.

Is there a need to mention a third scenario?

Scenario 1:
stub resolver <--- dns or http(s) ---> DNS resolver

Scenario 2:
stub resolver <--- dns ---> proxy DNS to HTTP(S) <--- http(s) ---> DNS
resolver

Scenario 3:
stub resolver <--- http(s) ---> proxy HTTP(S) to DNS <--- dns ---> DNS
resolver

Or is the third a subset of another or implied or not useful?
Some comment on this scenario might be helpful.

-- 
Bob Harold

---

From: Davey Song <[email-masked]>
Date: Thu, 7 Jul 2016 17:31:49 +0800

Hi Bob,

inline

>> I support adoption and will review.
Thanks

> stub resolver <--- dns or http(s) ---> DNS resolver
 Yes. There may be one  piece missing is that if http(s) connection is
failed (may happen.), the stub resolver should fall back to normal dns
without the benefit of this protocol.

> stub resolver <--- dns ---> proxy DNS to HTTP(S) <--- http(s) ---> DNS
Actually the Scenario 2 is :
stub resolver <--- dns ---> proxy client <----  dns over http(s) --->proxy
server <--- dns --->DNS resolver

The proxy client and proxy server in this case are separated severs. There
is a note following that proxy client can be implemented in the stub
resolver in another process listen to , and the proxy server can be
implemented in the DNS resolver in this way.

Scenario 3:
> Actually there is a txt saying after the second scenarios which I think
includes your proposed case :

   "It is possible that these scenarios are mixed. The server may speak
   DNS over HTTP directly and the client use a proxy, or the other way
   around."

> Some comment on this scenario might be helpful.
Useful but it is treated as a mixed scenarios 1 and 2. One expected
audience of this document is the software developer. Scenario 1 requires
coder to implement the this protocol in DNS software. The proxy approach is
not.

> Davey