IETF Logo Mail Archive

Re: [Doh] WG Review: DNS Over HTTPS (doh)

Patrick McManus <pmcmanus@mozilla.com> Fri, 22 September 2017 16:37 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86406134531; Fri, 22 Sep 2017 09:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Level:
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, 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 WXvC7VnUiUm2; Fri, 22 Sep 2017 09:37:03 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1B658132E24; Fri, 22 Sep 2017 09:37:03 -0700 (PDT)
Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id 4546A3A0B6; Fri, 22 Sep 2017 12:37:01 -0400 (EDT)
Received: by mail-lf0-f49.google.com with SMTP id a18so1653938lfl.13; Fri, 22 Sep 2017 09:37:01 -0700 (PDT)
X-Gm-Message-State: AHPjjUh5LZBNZ4oXUIF3rL868MwoN2lS8ecNdbIhV7oTc1V5MyGhrcd9 x2WZZBeWK0O8qP9Q4+dg+V6TbvKQrVng0LZLMBY=
X-Google-Smtp-Source: AOwi7QD7qxNi3qestqIsLZA+xRM1hL+0fl59iVzOTxN6VCoMBPDUoTwno3+IRkp0FxSZX73+ZNgURTUF0NZWyJ6OUbg=
X-Received: by 10.25.22.106 with SMTP id m103mr2284504lfi.168.1506098219922; Fri, 22 Sep 2017 09:36:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.92.200 with HTTP; Fri, 22 Sep 2017 09:36:58 -0700 (PDT)
In-Reply-To: <CAHw9_i+0AKRQnnUkagB1XqoiiNVvcYu5psaHPrqzCetbudEu0w@mail.gmail.com>
References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <eaadc24d-6150-2396-64b6-708266de1c69@nostrum.com> <c06bfd5a-743a-aa9f-68b4-4a60badc8bed@cisco.com> <a34c98e2-7129-1d1a-947b-20cafa236119@nostrum.com> <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> <CA+9kkMBD3qntDXGa3tWpcGRUWN4g4ivbMWMZrWRP-BBeJFOWVQ@mail.gmail.com> <alpine.DEB.2.11.1709221301470.2486@grey.csi.cam.ac.uk> <CAHw9_i+0AKRQnnUkagB1XqoiiNVvcYu5psaHPrqzCetbudEu0w@mail.gmail.com>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Fri, 22 Sep 2017 12:36:58 -0400
X-Gmail-Original-Message-ID: <CAOdDvNqxx1O6cjdS8ONO4iCdhkj-bf_6foCe6pFZaDQoovXARg@mail.gmail.com>
Message-ID: <CAOdDvNqxx1O6cjdS8ONO4iCdhkj-bf_6foCe6pFZaDQoovXARg@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: Tony Finch <dot@dotat.at>, Ted Hardie <ted.ietf@gmail.com>, doh@ietf.org, IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a11407d24653b710559c9d1e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/4PI8ozwIA8xixQ5aKJJSvuz98Gs>
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Sep 2017 16:37:05 -0000

On Fri, Sep 22, 2017 at 12:24 PM, Warren Kumari <warren@kumari.net> wrote:

>
> Yup -- RFC7766, S6.2.1.1 says you should do this, as does RFC7858
> ("Specification for DNS over Transport Layer Security (TLS)").
>
> double yup. https >=h2 offers a couple, really minor in the grand scheme
of things, similar advantages beyond that too. One is a rather seamless (no
additional specification necessary) upgrade to httpOverQuic when that
happens which will help with the tcp level in-order suboptimality.. the
other is multiplexing within any partial response (as opposed to just
reordering whole responses) that is blocking the wire (slow to generate
additional records, or big things like axfr..). They're just nice to haves
but they should help with the tail cases.


>
> DPRIVE solves much of this, but one weakness is that it is still
> clearly DNS traffic.


yep.

v2.23.0 | Report a Bug | By Email