Re: [dnsoverhttp] New draft: draft-hoffman-dns-over-http-00.txt
Patrick McManus <pmcmanus@mozilla.com> Wed, 21 September 2016 10:31 UTC
Return-Path: <pmcmanus@mozilla.com>
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 B6DB012B09E
for <dnsoverhttp@ietfa.amsl.com>; Wed, 21 Sep 2016 03:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001,
SPF_SOFTFAIL=0.665] autolearn=no 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 aZTYhBgw5Hxw for <dnsoverhttp@ietfa.amsl.com>;
Wed, 21 Sep 2016 03:31:22 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102])
by ietfa.amsl.com (Postfix) with ESMTP id 1D72D12B1FB
for <dnsoverhttp@ietf.org>; Wed, 21 Sep 2016 03:31:22 -0700 (PDT)
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com
[209.85.223.172])
by linode64.ducksong.com (Postfix) with ESMTPSA id D054F3A05C
for <dnsoverhttp@ietf.org>; Wed, 21 Sep 2016 06:31:11 -0400 (EDT)
Received: by mail-io0-f172.google.com with SMTP id m79so48104279ioo.3
for <dnsoverhttp@ietf.org>; Wed, 21 Sep 2016 03:31:11 -0700 (PDT)
X-Gm-Message-State: AE9vXwPFSyqUyj+pxT/zbC8cLRSf7oVYEAPai/qX3/3TUilAcQEL38uBOU8wRnQhgi6MDitWa9QtuIricC7Mtg==
X-Received: by 10.107.185.3 with SMTP id j3mr49853697iof.3.1474453870138; Wed,
21 Sep 2016 03:31:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.148.50 with HTTP; Wed, 21 Sep 2016 03:31:09 -0700 (PDT)
In-Reply-To: <D1E3CC44-FE5A-4ACE-90A1-EF9B5EE975D7@icann.org>
References: <147438228195.28999.4355943522486567954.idtracker@ietfa.amsl.com>
<D1E3CC44-FE5A-4ACE-90A1-EF9B5EE975D7@icann.org>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 21 Sep 2016 12:31:09 +0200
X-Gmail-Original-Message-ID: <CAOdDvNpWdN=w0R7pOkghbwg0-SwHnD9=AqvpnAM7tQfmRpVGEw@mail.gmail.com>
Message-ID: <CAOdDvNpWdN=w0R7pOkghbwg0-SwHnD9=AqvpnAM7tQfmRpVGEw@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Content-Type: multipart/alternative; boundary=94eb2c071c302ade32053d020bac
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsoverhttp/mvJB7BAuxqXntoR5HcPCIabiDYQ>
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: Wed, 21 Sep 2016 10:31:25 -0000
Paul - thanks for the draft! This is a good contribution - Some thoughts, in no particular order: * I don't have a strong opinion on whether or not the prefix can be discoverable for some use cases, but it seems for h2 push it needs to be in the .wk space in order to give the client enough context to recognize this is dns data. given that, it might make sense to just use .wk everywhere instead of making it discoverable. * you have a todo on how trust works for prefixes based on IP instead of name.. I think that's a little backwards - you want to think of a prefix always using a name (for validation purposes) and in conjunction how to bootstrap an address for it when necessary (i.e. allow optional stapling of some sort) * the discussion of content negotiation (aka Accept:) doesn't really add anything to the existing http definition - i.e. using it might help you get a content type you know how to decode. Perhaps having a MTI type (json?) gives this more pertinence and helps deployability. Might as well get the hard stuff on the table early :) * the observation to set the cache age to the minimum of the included RR TTL is good.. I wonder if you need to go farther in a couple of ways: a] this impacts what you might want to bundle together as additional records etc.. especially when pushing and those could be served as their own pushed responses.. some advice on that would be useful b] I wonder (in the true sense of I don't know) if there is difference in a recursive resolver in just marking this as remaining max-age, or giving the max-age of the fresh TTL and using Age headers to indicate how much of that has passed.. mnot probably has keen insight into that - but it seems to me if the TTL is part of the json or wire format response then this has implications for revalidations and etags * some advice on how to create etags might be helpful.. especially to the extent that it is responding with tags that represent sets, traditional version tracking might be really hard. hashes spring to mind as something to consider - at the very least the issue should be discussed * with respect to dnssec not authenticating everything we want I personally have a bit of a shrug response.. because obviously adding trust to that response just because of the ip address on the reply doesn't really add any significant value either imo. Caching recursive resolvers tend to obscure this stuff anyhow - especially big public ones. If we thought this was a critical concern (I likely don't) then we could define some opt-in bit for the zone owner to sign indicating they were ok with caches handing out their data on their behalf. But I tend to agree with Martin that the http client needs to be conservative about how far to propagate this information - widening the circle as it gains confidence in it. That's what is happening with other pushed data right now anyhow in practice (it gets scoped to the resource that did the pushing, but after it is used successfully it may end up in the general cache) - though feedback has been that this is too conservative. its an interesting discussion. On Tue, Sep 20, 2016 at 4:54 PM, Paul Hoffman <paul.hoffman@icann.org> wrote: > Greetings. As Joe and I presaged on the list last week, here is our draft > on the HTTP parts of DNS over HTTP. We tried to cover all of the issues > that any foo-over-HTTP document should cover, and to be sure that every > normal DNS query (even with extensions) could be specified. If we missed > any, we're happy to update. > > --Paul Hoffman > > > A new version of I-D, draft-hoffman-dns-over-http-00.txt > > has been successfully submitted by Paul Hoffman and posted to the > > IETF repository. > > > > Name: draft-hoffman-dns-over-http > > Revision: 00 > > Title: DNS Queries over HTTPS > > Document date: 2016-09-20 > > Group: Individual Submission > > Pages: 12 > > URL: https://www.ietf.org/internet- > drafts/draft-hoffman-dns-over-http-00.txt > > Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-over- > http/ > > Htmlized: https://tools.ietf.org/html/ > draft-hoffman-dns-over-http-00 > > > > > > Abstract: > > This document describes how to make DNS queries and get DNS responses > > over HTTPS. The main driver for this document is to allow clients > > who want to send DNS queries over HTTP transport to be able to do in > > a secure and interoperable fashion, regardless of the format of the > > responses. > > _______________________________________________ > dnsoverhttp mailing list > dnsoverhttp@ietf.org > https://www.ietf.org/mailman/listinfo/dnsoverhttp >
- [dnsoverhttp] New draft: draft-hoffman-dns-over-h… Paul Hoffman
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Ted Hardie
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Paul Hoffman
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Ted Hardie
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Paul Hoffman
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Ted Hardie
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Martin Thomson
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Martin Thomson
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Patrick McManus
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Paul Hoffman
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Paul Hoffman
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Ted Hardie
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Patrick McManus
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Martin Thomson
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Martin Thomson
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Martin Thomson
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Martin Thomson
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Paul Hoffman
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Martin Thomson
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Paul Hoffman
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Patrick McManus
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Patrick McManus
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Ted Hardie
- Re: [dnsoverhttp] New draft: draft-hoffman-dns-ov… Martin Thomson