Re: [Doh] assorted things

Patrick McManus <pmcmanus@mozilla.com> Tue, 05 June 2018 14:46 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 6C16913103F for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 07:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Level:
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 U8DgCo2w1iuc for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 07:46:53 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9C720131002 for <doh@ietf.org>; Tue, 5 Jun 2018 07:46:53 -0700 (PDT)
Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) by linode64.ducksong.com (Postfix) with ESMTPSA id C5B4C3A04F for <doh@ietf.org>; Tue, 5 Jun 2018 10:46:52 -0400 (EDT)
Received: by mail-ot0-f175.google.com with SMTP id n3-v6so3128307ota.5 for <doh@ietf.org>; Tue, 05 Jun 2018 07:46:52 -0700 (PDT)
X-Gm-Message-State: ALKqPwc1O2buTxU3ryhUPjCjYrDvyDancXEAWzO9glV5NHNH4Vg2xPYi KHamvJuJVsemMQHaBtJUWWsHtRGOPUboR0ijoRo=
X-Google-Smtp-Source: ADUXVKKOGEqIj831Ih50rXNsvN7ck+Zz0+v4gWxLYm8KeQ6PCgJEexetCE1ZA5MiwL3gjPC91yZdNZrbEitTtBeikgQ=
X-Received: by 2002:a9d:513b:: with SMTP id c56-v6mr16673035oth.397.1528210012017; Tue, 05 Jun 2018 07:46:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 07:46:51 -0700 (PDT)
In-Reply-To: <20180605123541.GB29047@server.ds9a.nl>
References: <20180605123541.GB29047@server.ds9a.nl>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 5 Jun 2018 16:46:51 +0200
X-Gmail-Original-Message-ID: <CAOdDvNohjh75idC=A0gsMmHb1dv-dqwazaLTPzYzymaNbiVY9A@mail.gmail.com>
Message-ID: <CAOdDvNohjh75idC=A0gsMmHb1dv-dqwazaLTPzYzymaNbiVY9A@mail.gmail.com>
To: bert hubert <bert.hubert@powerdns.com>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e89a64056de61e8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/DDSW-22khjs7CzxjjIP1VCERdTg>
Subject: Re: [Doh] assorted things
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 05 Jun 2018 14:46:56 -0000

Hey Bert,

On Tue, Jun 5, 2018 at 2:35 PM, bert hubert <bert.hubert@powerdns.com>;
wrote:

>
> Does this say "don't just use any URI"?  What are 'DNS resolution
> privileges'


every DoH exchange has a URI - if the URI isn't one your client is cool
with - don't use it. e.g. when a DoH exchange arrives via push, check the
URI as your first filter.


> ? Is this about disallowing javascript to send out random DNS
> queries?
>
> no

 >. Naive implementations may decide to not

> follow 3xx codes. I would recommend making this explicit with a MUST. Also,
> it may be worth it to explicitly say if authentication is in our out of
> scope
>

That non-normative text is just there to remind the reader, who may not be
that familiar with http, about the way http works. Specifically the group
wanted to emphasize that DNS errors are only carried in successful HTTP
responses, non-successful responses have HTTP semantics. This is a further
reminder that we say non-successful rather than failed because some codes
(like 3xx) can still be worked out successfully if the HTTP client wants to
try harder with another request.. but that's all governed by HTTP, not DoH
in particular. (And there are lots of these cases - so enumerating them
rather than just relying on HTTP semantics is probably not the right
thing.. a DoH implementation needs a full HTTP implementation - likely via
library or other tool).



> In 6.3 "Server Push":
>    For HTTP server push ([RFC7540] Section 8.2) extra care must be taken to
>    ensure that the pushed URI is one that the client would have directed
> the
>    same query to if the client had initiated the request.
>
> This means an API server is free to send responses to DNS queries we
> haven't
> seen yet?  And should a client do something with that?  Or can it ignore
> the
> pushed records?
>
>
it can ignore them if it likes. It can cache them if it likes. In practice
it can even configure HTTP/2 to prevent or flow control them if it likes
(its an http feature, and we don't enumerate every knob http provides or
may evolve - we just stick to the semantics it provides).