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
>