IETF Logo Mail Archive

Re: [dnsoverhttp] New draft: draft-hoffman-dns-over-http-00.txt

Paul Hoffman <paul.hoffman@icann.org> Tue, 20 September 2016 21:44 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsoverhttp@ietfa.amsl.com
Delivered-To: dnsoverhttp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE7B12B9D2 for <dnsoverhttp@ietfa.amsl.com>; Tue, 20 Sep 2016 14:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.517
X-Spam-Level:
X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, 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 ZncJdcfA965A for <dnsoverhttp@ietfa.amsl.com>; Tue, 20 Sep 2016 14:44:01 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D2812B901 for <dnsoverhttp@ietf.org>; Tue, 20 Sep 2016 14:44:01 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 20 Sep 2016 14:43:59 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 20 Sep 2016 14:43:59 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Ted Hardie <ted.ietf@gmail.com>
Thread-Topic: [dnsoverhttp] New draft: draft-hoffman-dns-over-http-00.txt
Thread-Index: AQHSE07kDK2wJtUwEEi0lLnNJpT1/qCDTRkAgAAR0QA=
Date: Tue, 20 Sep 2016 21:43:59 +0000
Message-ID: <AF616D4B-A22B-4CB7-AD20-29B4E6107276@icann.org>
References: <147438228195.28999.4355943522486567954.idtracker@ietfa.amsl.com> <D1E3CC44-FE5A-4ACE-90A1-EF9B5EE975D7@icann.org> <CA+9kkMATL4RVv=RCmS0nqks2OWB1aQSeNcZ_-zyqHBnv5eYmLg@mail.gmail.com>
In-Reply-To: <CA+9kkMATL4RVv=RCmS0nqks2OWB1aQSeNcZ_-zyqHBnv5eYmLg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DE82455E0E5704409A89B5D22C5F73F1@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsoverhttp/AqmL41TsjyulNMaT2I9kounWrdQ>
Cc: "dnsoverhttp@ietf.org" <dnsoverhttp@ietf.org>
Subject: Re: [dnsoverhttp] New draft: draft-hoffman-dns-over-http-00.txt
X-BeenThere: dnsoverhttp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of DNS over HTTP <dnsoverhttp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsoverhttp/>
List-Post: <mailto:dnsoverhttp@ietf.org>
List-Help: <mailto:dnsoverhttp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Sep 2016 21:44:02 -0000

On Sep 20, 2016, at 1:40 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
> Thanks for the draft.  Reading through it, it seems to posit a mechanism for providing a DNS API server that will serve the same function as a recursive resolver would now. 

We did not mean to limit it to recursive resolvers: it could be any DNS server. In Section 2.4, note the rd parameter can be set to 0. Maybe we should say this explicitly in the Introduction.

> Given that this is basically similar to a recursive resolver putting up a new API, I'm not sure why the complication of a non-standardized prefix is the right trade-off.  Why not standardize it?  If not standardized, why not use the well known URI mechanisms?

If folks prefer a standard prefix, we could certainly go that way. Having said that, if we started off with that instead, I strongly suspect that some would ask why we were forcing a particular URI on servers, and the modern IETF way is to give flexibility through discovery.

> I also note that this seems to be answering a different use case than Patrick and Martin were talking about in regards to server push.  With this, server push might be used for something like additional data, but you wouldn't see this in the same context as "normal" HTTPS connections, so server push from a content server wouldn't apply. Have I got that bit right?

Hopefully not. That is, we certainly want the server push model to work with our proposal.

--Paul Hoffman

v2.8.7 | Report a Bug | By Email