Subject: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

From: Tim Wicinski <[email-masked]>
Date: Mon, 11 Jul 2016 18:33:14 -0400

This starts an official Call for Adoption for
	 draft-song-dns-wireformat-http

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

Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

We wanted this Call to coincide with the Berlin meeting so if there is 
opinions that needed to be voiced, they can do so.

This call for adoption ends: 25 July 2016

Thanks,
tim wicinski
DNSOP co-chair

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2016 23:50:05 -0000

>by DNSOP, and comments to the list, clearly stating your view.

Yes, we should adopt it.  It needs some work, but what draft doesn't.

>Please also indicate if you are willing to contribute text, review, etc.

Yes.

My main suggestion is to lose the Proxy-DNS-Transport header and
always have the request and response in TCP format.  If the server
doing the http-to-DNS proxy wants to microoptimize and try the query
as UDP and see if it works, that's fine, but I'm guessing that the
proxy will usually be close to the cache it's using so the penalty for
TCP will be low.

I'd also want to change some of the motivation text.  To me, by far
the most likely scenario here is javascript applications that want to
do DNS queries, e.g. for SRV, but can't because javascript doesn't let
you do that.  Now the server that provided the javascript blob can
also be the DNS proxy.  The javascript can't query random other DNS
proxies due to cross-site scripting rules.

R's,
John

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 12 Jul 2016 00:13:57 +0000

One thing I think has always been bugging me about DNS over HTTP is the 
appalling performance we will likely see in a lot of cases.  Even small 
latencies in normal DNS lookups cause major impact on page load times on 
complex pages with resources from many servers, and adding HTTP overhead 
to this will slow things further.

So I suggest some thought should be given to reducing round-trips by 
allowing for multiple DNS request payloads in a single HTTP request 
message, and multiple DNS response payloads in an HTTP response message.

E.g. sending requests as base64 encoded blob values in key-value pairs 
as post data, so that a response can be linked back to the request.

At this stage of the game this should be quite easy, but will become 
more and more difficult as time goes by if the single request/response 
model is rolled out.

Regards

Adrien

------ Original Message ------
From: "Tim Wicinski" <[email-masked]>
To: "dnsop" <[email-masked]>
Sent: 12/07/2016 10:33:14 a.m.
Subject: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

>Please review this draft to see if you think it is suitable for 
>adoption by DNSOP, and comments to the list, clearly stating your view.
>
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

---

From: "John Levine" <[email-masked]>
Date: 12 Jul 2016 03:06:24 -0000

>message, and multiple DNS response payloads in an HTTP response message.

Don't you get this automatically if it's treated as a TCP DNS
connection?  You stuff a bunch of requests down the pipe, and you get
back a bunch of responses.

See RFC 7766.

R's
John

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 12 Jul 2016 03:25:43 +0000

I guess presuming that the back end will use TCP for DNS you could do 
this, but I would imagine that's not always the case?

As an on-the-wire format goes there are worse ones, so if DNS over TCP 
is used, which supports this, then I guess some mention in this proposal 
could be useful to get people thinking about this.  Even if something 
else is used on the back end (e.g. http server is a DNS server with 
cache, so may answer queries from cache or its own authoritative 
database) it can still use this format.

Regards

Adrien

---

From: Marek Vavruša <[email-masked]>
Date: Mon, 11 Jul 2016 22:26:00 -0500

> back a bunch of responses.

You get queueing for free, but not pipelining and out-of-order
responses, that has to be defined.
The draft mentions this, but I think at this point it should just
depend on HTTP/2,
as it's the only way to get decent performance from resolvers but high
variance in response time,
and request semantics in both is different and needs to be defined,
i.e. what happens when client cancels
in-flight query, what happens when server resolver pushes response.

Marek

---

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2016 23:32:51 -0400

> responses, that has to be defined.

RFC 7766 says you should get pipelining and out-of-order responses on TCP 
DNS.  Take a look.

Even if the underlying DNS server that the proxy is using can't do it, any 
newly written proxy should provide TCP DNS the way 7766 says it should.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2016 23:34:11 -0400

> I guess presuming that the back end will use TCP for DNS you could do this, 
> but I would imagine that's not always the case?

If it doesn't, there's a lot of queries that will fail, particularly with 
DNSSEC included.  See RFC 7766.

R's,
John

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 12 Jul 2016 03:35:02 +0000

for a web to DNS proxy to decide to send a reply back, it would need to 
consider it complete?

Or are you proposing that the http server would start streaming back the 
payload as it received the (possibly out of order) replies?

Maybe instead should use WebSockets

------ Original Message ------
From: "John R Levine" <[email-masked]>
To: "Marek Vavruša" <[email-masked]>
Cc: "dnsop" <[email-masked]>
Sent: 12/07/2016 3:32:51 p.m.
Subject: Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

>RFC 7766 says you should get pipelining and out-of-order responses on 
>TCP DNS.  Take a look.
>
>Even if the underlying DNS server that the proxy is using can't do it, 
>any newly written proxy should provide TCP DNS the way 7766 says it 
>should.
>
>Regards,

---

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2016 23:39:55 -0400

> payload as it received the (possibly out of order) replies?

I was thinking that the proxy would get all the queries from the DNS 
request, deal with them however it wants, maybe stuff them to a nearby DNS 
cache with TCP if it pipelines properly, or split them up into separate 
requests if it doesn't, then collect the responses and send them back when 
it has them, which I guess would constitute streaming.  RFC 7766 says that 
out-of-order is fine.

I suppose with http/2 we get two-way streaming more or less for free.

R's,
John

---

From: Marek Vavruša <[email-masked]>
Date: Mon, 11 Jul 2016 23:05:56 -0500

RFC 7766 is about DNS/TCP not about DNS/HTTP, the order of processing
has to be determined by the wrapping protocol. You would get it for
free if this draft was about TCP over HTTP or HTTP over DNS/TCP, but
it's not.

Marek

---

From: Marek Vavruša <[email-masked]>
Date: Mon, 11 Jul 2016 23:30:25 -0500

> it has them, which I guess would constitute streaming.  RFC 7766 says that

Without HTTP/2 each request, clients would need to start a separate
connection to get parallel processing, which means TCP handshake and
potentially a TLS and more bookkeeping code. So client makes requests
to proxy over HTTP/2 to mitigate the costs (here 7766 doesn't apply).
Then proxy translates incoming HTTP/2 multiplexed requests into either
DNS/TCP queries to origins (here 7766 helps)  or plain old DNS
(additional costs and bookkeeping). Server sends back DNS responses to
proxy, which in turn translates them to DNS/HTTP answers. So both
DNS/TCP out-of-order processing and DNS/HTTP out-of-order processing
is desirable here.

> I suppose with http/2 we get two-way streaming more or less for free.

Yep, the proxy can also push DNS answers to client ahead of time,
which is interesting and something DNS servers can't do right now. On
another note - this proposal kind of competes with DNS over HTTP
encoded in JSON. While that one doesn't transport exact byte-by-byte
DNS messages, it's much more consumer-friendly and elegant than
piggybacking binary data. I wonder why that one is not getting more
attention.

Marek

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Jul 2016 11:47:14 +0100

John Levine <[email-masked]> wrote:
> always have the request and response in TCP format.

The HTTP payload should always be unframed (like DNS over UDP) regardless
of the upstream DNS transport, since HTTP already provides content-length
framing so there's no need to repeat the message length. Like TCP, the
EDNS0 UDP buffer size is irrelevant for HTTP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Northeast Viking, North Utsire: Westerly veering northerly later, 3 or 4,
occasionally 5 in south. Slight or moderate. Occasional rain, fog patches.
Moderate or good, occasionally very poor.

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Jul 2016 11:49:53 +0100

Adrien de Croy <[email-masked]> wrote:
>
> So I suggest some thought should be given to reducing round-trips by allowing
> for multiple DNS request payloads in a single HTTP request message, and
> multiple DNS response payloads in an HTTP response message.

Why not just specify that pipelined HTTP should be used where possible?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fair Isle: Northwest 5 or 6, decreasing 4 at times. Moderate. Rain or showers,
fog patches in north. Moderate or good, occasionally very poor in north.

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Jul 2016 11:52:21 +0100

> but I would imagine that's not always the case?

In a good implementation the back-end DNS framing should be independent of
the HTTP framing.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Fitzroy: Northerly 4 or 5, increasing 6 or 7 in east. Moderate,
occasionally rough later in southeast. Fair. Good.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Jul 2016 07:00:17 -0400 (EDT)

On Mon, 11 Jul 2016, Tim Wicinski wrote:

> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP, and comments to the list, clearly stating your view.

I am very hesitant to accept any protocol-over-http wrapper, as it just
moves the problem around and generate a new set of middleware boxes that
mess with the data.

I think RFC 7858 is fine for mistakenly broken networks. The only
advantage of this method is to work around administrative blocks. And
that's a rat-race with middle boxes.

There is also a bootstrap issue. if you can use the local DNS to get to
the webserver for DNS-over-HTTP then the local DNS can prevent you from
resolving it. If you hardcode the IP they can blacklist known servers.
And they can transparent proxy your requests to prevent you from using
it anyway. So it's not even that good to work around administrative
blocks.

So I am not convinced of the use case compared to RFC 7858.

Paul

---

From: Ray Bellis <[email-masked]>
Date: Tue, 12 Jul 2016 12:04:37 +0100

> moves the problem around and generate a new set of middleware boxes that

+lots

Ray

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2016 09:45:31 -0400

> EDNS0 UDP buffer size is irrelevant for HTTP.

The reason to use TCP framing is so that you can send multiple DNS 
requests in a single http request and get back multiple answers.  Recent 
messages here suggest that's of considerable interest, and if you're only 
sending one request, the two bytes of TCP length are tiny compared to the 
http headers.

It occurs to me that this crock is not inherently much slower than regular 
TCP over DNS.  In both cases the client opens a connection and sends out 
the request, and the server sends back the answer.  In both DNS and most 
versions of http you can leave the connection open and reuse it, probably 
more important in http since you're likely reusing the TLS negotiation 
too.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2016 09:47:58 -0400

> free if this draft was about TCP over HTTP or HTTP over DNS/TCP, but

It's hard to believe we're reading the same draft.  The one I'm reading is 
about wrapping DNS wire format requests in http, with a header saying 
whether it's wrapping UDP format or TCP format.  (My preference is to lose 
the UDP and only wrap TCP, but that's a nit.)

So it's DNS in TCP in http.  Since DNS in TCP handles multiple requests 
and out of order responses, so does this.

Regards,

---

From: Marek Vavruša <[email-masked]>
Date: Tue, 12 Jul 2016 10:00:15 -0500

On Tue, Jul 12, 2016 at 8:45 AM, John R Levine <[email-masked]> wrote:
> The reason to use TCP framing is so that you can send multiple DNS requests
> in a single http request and get back multiple answers.  Recent messages
> here suggest that's of considerable interest, and if you're only sending one
> request, the two bytes of TCP length are tiny compared to the http headers.

Maybe I'm still missing something - so you pack multiple DNS requests
in single HTTP request,
answer#1 takes 5s, answer#2 timeouts, the rest is answered from cache.
How do you send back
the fast answers first without blocking when you have just a single
HTTP request outstanding?

> TCP over DNS.  In both cases the client opens a connection and sends out the
> request, and the server sends back the answer.  In both DNS and most
> more important in http since you're likely reusing the TLS negotiation too.
>
> Regards,

---

From: Shane Kerr <[email-masked]>
Date: Tue, 12 Jul 2016 17:06:24 +0200

Paul,

At 2016-07-12 07:00:17 -0400

> that's a rat-race with middle boxes.

This is indeed the main use case of the draft - getting around
administrative blocks. Widespread adoption would indeed result in a
sort of arm's race with developers adding blocks, although the main
advantage of DNS over HTTP is that HTTP is difficult to block in
general, whereas DNS is easy to block in general.

One can of course use RFC 7858 over port 443. My guess is that
traffic analysis will quickly reveal this to be DNS traffic (although
EDNS0 padding may combat this). The advantage of DNS over HTTP beyond
this is that you can run DNS over HTTP on an HTTP server which is
serving other HTTP content. (The DNS over HTTP draft mentions this,
IIRC.) This makes DNS over HTTP indistinguishable from "normal" HTTP
traffic, because it is running on the same server as "normal" HTTP
traffic.

> it anyway. So it's not even that good to work around administrative

There is indeed a bootstrap issue. In our code you can either use the
IP directly or use another resolver (like the normal DHCP-supplied
resolver) to lookup the IP of the HTTP over DNS server. Perhaps we
should address this in the draft?

The impact of blocking on this will vary depending on the scenario.
Yes, China will surely maintain a blacklist, just like they do for VPN.
Hopefully this will be mitigated a little bit by sharing the DNS over
HTTP with web pages, but maybe not. It's still useful for people who
are stuck behind less comprehensive blocks.

> So I am not convinced of the use case compared to RFC 7858.

That's fine.

One thing that I have mentioned several times in the past is that the
IETF has a culture of stopping things because people don't like
proposals for various reasons. This is especially true in the DNS
community, for some reason.

I'm hoping even though you and Ray and surely others don't find this a
useful technique, that the document can proceed anyway. You don't have
to use it, and can discourage use by others. But maybe having an extra
potential tool is okay.

Cheers,

--
Shane

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2016 12:03:11 -0400

> Maybe I'm still missing something - so you pack multiple DNS requests in 
> single HTTP request, answer#1 takes 5s, answer#2 timeouts, the rest is 
> answered from cache. How do you send back the fast answers first without 
> blocking when you have just a single HTTP request outstanding?

The obvious way would be to send chunked http responses as the answers 
come back.  See section 4 of RFC 7230.  The DNS responses don't have to be 
in order.

I don't think anyone sees DNS over http as a general replacement for 
ordinary DNS.  I see two plausible scenarios:

* The most likely is javascript apps that want to look up SRV or NAPTR or 
something, but can only make http/s requests back to the place the js 
files came from.

* The other is an application that wants to make it hord to observce its 
DNS queries, so it uses https to a trusted proxy.

This should be fine for both of those.

R's,
John

---

From: Marek Vavruša <[email-masked]>
Date: Tue, 12 Jul 2016 11:21:50 -0500

On Tue, Jul 12, 2016 at 11:03 AM, John R Levine <[email-masked]> wrote:
>>> requests
> The obvious way would be to send chunked http responses as the answers come
> back.  See section 4 of RFC 7230.  The DNS responses don't have to be in
> order.

Great, so you get a couple of queries from DNS/TCP stream and batch
them into HTTP request,
now you get additional query but your HTTP connection is already
blocked and you have to start a new one
or wait. After all this is just an optimisation game, perhaps I'm
foolish to pursue it, but (for me) it's important to define the
requirements before we end up with a long tail of weak
implementations.

> something, but can only make http/s requests back to the place the js files
> came from.
>
> * The other is an application that wants to make it hord to observce its DNS
> queries, so it uses https to a trusted proxy.
>

I hope these would be the cases, I thought about search engine results
page pushing resolved addresses (secured) for search results ahead of
time, but using packed DNS wire format for this is not terribly great.
It looks like the motivation is to get around DNS firewalls and
filters, which implies deploying a scattered
set of "open" resolvers similar to dnscrypt to get around IP blocking.
Performance should matter in this case.

Marek

---

From: Shane Kerr <[email-masked]>
Date: Tue, 12 Jul 2016 20:51:23 +0200

Marek,

At 2016-07-11 22:26:00 -0500
> in-flight query, what happens when server resolver pushes response.

There is another option, which is what HTTP developers have done for
years, which is keep multiple HTTP connections open. Not ideal, but
better than blocking all lookups on a slow resolution. :)

I recognize that HTTP/2 is definitely a better option because of
out-of-order replies, but I worry about requiring it. It's still quite
new and language support may be spotty. But I guess given it's
popularity this shouldn't be a huge problem, so maybe that is a
reasonable recommendation.

I'm also not sure if we need to define all of the semantics in full.
Rather, I am worried about over-specifying semantics. Perhaps we can do
that as "suggested semantics"?

Cheers,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Tue, 12 Jul 2016 21:08:30 +0200

John,

At 2016-07-11 23:50:05 -0000

> proxy will usually be close to the cache it's using so the penalty for

Remember, we want DNS-over-HTTP to be able to handle existing DNS stub
resolvers. The motivation for UDP is to keep the client side of the DNS
over HTTP proxy simple.

----

If you always send TCP, then the client side may receive a response
which will not fit into either the 512 byte or EDNS buffer size. The
client side then has to remove RRset from the response to try to get it
to fit into the right size, possibly setting the truncation bit (TC=1).
This requires that the client side actually know quite a bit about DNS,
and be able to process DNS packets.

You cannot do this on the server side of the DNS-over-HTTP because the
server would not have any way to distinguish between a UDP packet
without a EDNS buffer size and a TCP message. So it would not know if
it had to assume a 512 byte maximum or a 65535 byte maximum. Even if it
could, it would still have to have all of the same logic needed to
reduce DNS message size by removing RRset.

----

If we can instead pass the stub DNS packet through exactly as it came
to the client DNS-over-HTTP proxy then the DNS server will be able to
remove RRset to make sure the response is small enough. The DNS server
already has to be able to do this, so no additional code is needed.
Neither the DNS-over-HTTP client or server has to actually understand
DNS messages. :)

Cheers,

--
Shane

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 12 Jul 2016 12:22:15 -0700

Folks, this is a call for WG adoption, not a design exercise. If the WG 
adopts the document, we will have plenty of opportunity to fine-tune or 
make major changes. Such as:

> reasonable recommendation.

If this WG adopts the document and then says "but we want to use an 
older version of the HTTP protocol", we should expect a fair amount of 
push-back during IETF Last Call.

--Paul Hoffman

---

From: Shane Kerr <[email-masked]>
Date: Tue, 12 Jul 2016 22:10:41 +0200

John,

> proxies due to cross-site scripting rules.

As I think that I mentioned before, the current draft of DNS-over-HTTP
is poorly suited for JavaScript. Building and parsing DNS binary
messages in JavaScript seems like a really hard way to get at the few
tidbits of information that you actually want.

OTOH, I am (obviously) not a web developer, so perhaps I overestimate
the difficulty in working with DNS binary-format. Maybe it's a
relatively compact set of JavaScript functions that can be used?

Maybe I just found a project for the IETF Hackathon? Hm... :)

Cheers,

--
Shane

---

From: "John Levine" <[email-masked]>
Date: 12 Jul 2016 20:13:39 -0000

>> always have the request and response in TCP format. ...

>resolvers. The motivation for UDP is to keep the client side of the DNS

Oh, OK, but that gets us back to the question of what the real purpose
of this thing is.

If it's to let javascript apps do DNS requests, who cares, it's all
going to be in js libraries anyway.

If it's to tunnel through hostile firewalls for general DNS service,
then your model makes sense, but I have to ask how likely it is that
many people will really use it that way.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 12 Jul 2016 20:17:29 -0000

>tidbits of information that you actually want.

Having written DNS servers and proxies in perl (using the low level
socket library, not Net::DNS), I think you underestimate the gross
stuff that people do in scripting languages.

Sure, you could try to write something that sugared up the queries
that you thought people would use, but I can promise that before the
toner is dry you'll get complaints from people who want use some
arcana you never thought anyone was interested in.  Just give us the
bits; we can deal with them.

R's,
John

---

From: "Allan Liska" <[email-masked]>
Date: Tue, 12 Jul 2016 16:33:00 -0400

On 7/12/2016 at 4:10 PM, "Shane Kerr"  wrote:John,

Maybe I just found a project for the IETF Hackathon? Hm... :)
My first thought (and maybe this says more about me than the project)
is that this seems like the perfect way to make a fully self-contained
piece of malware.  Ransom32 already proved that you can create
ransomware developed entirely in JavaScript, imagine if you combined a
JavaScript DNS library with a JavaScript TLS library
(https://github.com/digitalbazaar/forge) you could create a piece of
malware that is significantly harder to detect because all of the
network indicators would be encrypted or not in places that security
tools normally look.  Now, it would also be somewhat easy to detect
because there are very few legitimate reasons for someone to be
emailing you 25+ Meg .js file.  
I am not saying something shouldn't be done simply because bad guys
might abuse it, otherwise we should have gotten rid of email a long
time ago. What I am asking is are there more legitimate uses for DNS
over JavaScript than there are illegitimate?  I don't know the answer,
but I don't know if the "cool" factor outweighs the potential security
risk.
allan

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Jul 2016 18:47:23 -0400

What's to stop someone from writing that malware today?   Keeping the net
safe by reducing the expressiveness of what is carried over HTTP is already
a lost cause, and would have been a slender reed to rely on for security in
any case.

On Tue, Jul 12, 2016 at 4:33 PM, Allan Liska <[email-masked]> wrote:

> On 7/12/2016 at 4:10 PM, "Shane Kerr" <[email-masked]> wrote:
>
> John,
>
> My first thought (and maybe this says more about me than the project) is
> that this seems like the perfect way to make a fully self-contained piece
> of malware.  Ransom32 already proved that you can create ransomware
> developed entirely in JavaScript, imagine if you combined a JavaScript DNS
> library with a JavaScript TLS library (
> https://github.com/digitalbazaar/forge) you could create a piece of
> malware that is significantly harder to detect because all of the network
> indicators would be encrypted or not in places that security tools normally
> look.  Now, it would also be somewhat easy to detect because there are very
> few legitimate reasons for someone to be emailing you 25+ Meg .js file.
>
> I am not saying something shouldn't be done simply because bad guys might
> abuse it, otherwise we should have gotten rid of email a long time ago.
> What I am asking is are there more legitimate uses for DNS over JavaScript
> than there are illegitimate?  I don't know the answer, but I don't know if
> the "cool" factor outweighs the potential security risk.
>
>
>
> allan
>
>

---

From: "Allan Liska" <[email-masked]>
Date: Tue, 12 Jul 2016 20:20:02 -0400

There is nothing that stops someone from writing malware that uses a
custom-built JavaScript DNS server (or takes advantage of DNS
capabilities built into node.js) today. The difference is that even a
custom built DNS server still relies on port 53 for DNS queries, which
means that existing DNS security safeguards (if they exist in a
network) are still able to detect it.  
A piece of malware that uses DNS over TLS is going to operate outside
of those existing bounds and be more difficult to detect and is not
something that exists today (yes, a malware developer could tunnel DNS
traffic over a JavaScript TLS connection, but that would be cumbersome
and unreliable.  
I am not disagreeing with you, my point is that I can see a lot of bad
things that can be done with this capability and I don't really see a
lot of benefit.  
allan

On 7/12/2016 at 6:48 PM, "Ted Lemon"  wrote:What's to stop someone
from writing that malware today?   Keeping the net safe by reducing
the expressiveness of what is carried over HTTP is already a lost
cause, and would have been a slender reed to rely on for security in
any case.
On Tue, Jul 12, 2016 at 4:33 PM, Allan Liska  wrote:
On 7/12/2016 at 4:10 PM, "Shane Kerr"  wrote:John,

---

From: Davey Song(宋林健) <[email-masked]>
Date: Wed, 13 Jul 2016 10:03:55 +0800

+1, there is enough room for us to improve. 

When I first drafted some idea, I was told that the IETF work is driven by
the community. It's good. As one of the co-authors, I'm fairly open for
suggestions. But for experimental draft, I'm not sure whether we should
stick to the scope of original experiment we have done (hiding the DNS
traffic in web traffic ), or expand it for potential usage. I will ask and
handle it to the WG people if it is adopted by the WG.

As to the question of performance, we once had done some simple test
(http://www.dnsv6lab.net ) . It is not so scary and almost equal to DNS/TCP.
I'm glad to see more comprehensive test result if some guys are interested
on that. 

Davey

-----邮件原件-----
发件人: DNSOP [mailto:[email-masked]] 代表 Paul Hoffman
发送时间: 2016年7月13日 3:22
收件人: dnsop
主题: Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

Folks, this is a call for WG adoption, not a design exercise. If the WG
adopts the document, we will have plenty of opportunity to fine-tune or make
major changes. Such as:

> reasonable recommendation.

If this WG adopts the document and then says "but we want to use an older
version of the HTTP protocol", we should expect a fair amount of push-back
during IETF Last Call.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Wed, 13 Jul 2016 10:59:20 +0100

> relatively compact set of JavaScript functions that can be used?

It wouldn't be completely horrible to parse DNS packets using JavaScript
typed arrays.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames: Variable mainly northwesterly 3 or 4, increasing 5 at times.
Slight, occasionally moderate. Showers. Good.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 13 Jul 2016 13:27:27 +0100

> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays
why all that complexity? if some remote device (iot thingy) wants 'dns over
http' why would it not (as a first order answer) just ask
/cgi-bin/dnslookup for 'srv:foo.com' ? (returned answer in txt, json,
etc...)

why bother with a bunch of javascript tomfoolery?

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2016 10:42:09 -0400

> why bother with a bunch of javascript tomfoolery?

Security in IoT is close to an oxymoron, but my device would like to check 
the signature before trusting what your proxy says.

Also, as I mentioned in another message, unless you plan to carefully 
maintain your proxy to handle and translate every rrtype, we're going to 
want to use rr's that it doesn't handle.  I suppose it might return a json 
blob of TYPE1234, but you might as well just send the binary stuff at that 
point.

Regards,

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 13 Jul 2016 22:27:35 +0100

> the signature before trusting what your proxy says.
ok, I'm sure your device has some agreement with the cooperating http(s)
server though, right? it can get the text / bas64 rrsig content just as
easily as if it were doing udp/dns. (it should probably also check ssl
certificates/etc to make sure traffic did not get wonked in flight)

---

From: "John Levine" <[email-masked]>
Date: 14 Jul 2016 01:53:12 -0000

>certificates/etc to make sure traffic did not get wonked in flight)

I don't understand what problem this solves.  If you're going to
provide all of the DNS results in a gooped up form, why not just
provide them in a native form and let the client deal with it?

R's,
John

---

From: Tomoyuki Sahara <[email-masked]>
Date: Fri, 22 Jul 2016 13:24:46 +0900

> If this WG adopts the document and then says "but we want to use an older version of the HTTP protocol", we should expect a fair amount of push-back during IETF Last Call.

RFC7540 clearly states:

  This specification is an alternative to, but does not obsolete, the
  HTTP/1.1 message syntax.

Thanks,
Tomoyuki