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

Shane Kerr <shane@time-travellers.org> Tue, 12 July 2016 15:29 UTC

Return-Path: <shane@time-travellers.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE86112DADA for <dnsop@ietfa.amsl.com>; Tue, 12 Jul 2016 08:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y8YMzqn0XpX for <dnsop@ietfa.amsl.com>; Tue, 12 Jul 2016 08:29:42 -0700 (PDT)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC9212D974 for <dnsop@ietf.org>; Tue, 12 Jul 2016 08:06:41 -0700 (PDT)
Received: from [2001:470:78c8:2:224:9bff:fe13:3a9c] (helo=pallas.home.time-travellers.org) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1bMzGe-0007YS-Ik; Tue, 12 Jul 2016 15:06:36 +0000
Date: Tue, 12 Jul 2016 17:06:24 +0200
From: Shane Kerr <shane@time-travellers.org>
To: Paul Wouters <paul@nohats.ca>
Message-ID: <20160712170624.75a00ac5@pallas.home.time-travellers.org>
In-Reply-To: <alpine.LRH.2.20.1607120652001.11932@bofh.nohats.ca>
References: <e5c97630-a11f-0c93-8f4b-482764c85f71@gmail.com> <alpine.LRH.2.20.1607120652001.11932@bofh.nohats.ca>
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; boundary="Sig_/WrVuEjb01FDa7S.lgrOeDe6"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UrRAww8ye0fFvYXvwQl7ZEPr0IY>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2016 15:29:44 -0000

Paul,

At 2016-07-12 07:00:17 -0400
Paul Wouters <paul@nohats.ca> wrote:

> On Mon, 11 Jul 2016, Tim Wicinski wrote:
> 
> > 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.  
> 
> 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.

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.

> 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.

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