Re: [Doh] A question on the mix of DNS and HTTP semantics

Ted Hardie <ted.ietf@gmail.com> Mon, 19 March 2018 09:50 UTC

Return-Path: <ted.ietf@gmail.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 17FD71270B4 for <doh@ietfa.amsl.com>; Mon, 19 Mar 2018 02:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tZj0rxRbz3zF for <doh@ietfa.amsl.com>; Mon, 19 Mar 2018 02:50:11 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B9C127010 for <doh@ietf.org>; Mon, 19 Mar 2018 02:50:11 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id y27so9572759oix.10 for <doh@ietf.org>; Mon, 19 Mar 2018 02:50:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KxGQ1K/OX6bpO3SVl8O6gszTklB/msQ81R6N65CU+iY=; b=HWGHRk8vy9pRF4HAvvjrVt4UrLgqON7sGd+t91E5LhpLoQ59UMx+oj3ZcxqDg8hmlU WhSK0ACdwfMGmPYfvQpt9UmfwjqdrUuGns3QWV4p6GAtwWpD4rocy6HWcab/cGVo80My 1k/a/66H/1Yv9JafMXdDThqMBABlaLACllEfVG0in9IWGRZ+VeMiSXsLmC2zFN782YsT lgahYGgh7yNRbeQU9fopPZwy+FfXDdWkbAbJCrSEapx1gKTZXaE35RGkYCEtfV2sjONa uVqnjVZ6d4/ntNknK2US1Gynt6r0GzsFw/muDK1pkzgg/AjReZi23ZlUJNujo7K64VQG t6zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KxGQ1K/OX6bpO3SVl8O6gszTklB/msQ81R6N65CU+iY=; b=UEN9uymfEmkqzEutvzi3ByBySbGJT4A5+gRQ2r6rtduDTCG3MJ8wJTwCETZ563zST+ bft9r5y0Aj6edilVz34BxJ//+18vFzlb30JCDsuEg2CHR8uiX5fMhk6YdnbcDHslvTLH 0t5z5S+SbcfNHadawTMlQQgdLino2v/YG2Dr9pnlSuWAqYJOGc6iIFln6CTp51FD2qV7 JbP9fArSThfMZvKwJotGPy8md5EfhZ5Ni9DTHjfEIaO67U32PVDVWwOeOVKk4Yu+pa2D qN93+XVNuaqINjrl+oPkM4I1GVFrEWKfBPRIRSlTM86jFTVHWSRwfM9AEgUB3aWlhip7 FrAw==
X-Gm-Message-State: AElRT7HdxKoiubaKZ28fkWBJSRslNwNgRNOfHUERew0rFy5UEW21+uWc aHW7j3VmUcvMoxWszyItN/Y3C7zEF/EWddhPRfc=
X-Google-Smtp-Source: AG47ELuB54wp/dyufORnldt5KGFuJtAu3P7fK5wbrKK3JsN4yIzG2+nb+WUsz53GgI82Gkl2wzDzYCMQchdcY46PZsQ=
X-Received: by 10.202.190.70 with SMTP id o67mr3876648oif.103.1521453010816; Mon, 19 Mar 2018 02:50:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.7.27 with HTTP; Mon, 19 Mar 2018 02:49:40 -0700 (PDT)
In-Reply-To: <CAOdDvNr1GstB+g3pYi4w0bXuQ=Nz8HqgTRfWUX9TGu9YAYiz0w@mail.gmail.com>
References: <CA+9kkMB7awRfW9jUmY9Q-1p+w3VLtpG5DxhF3s7Q58nEMZeX3w@mail.gmail.com> <20180318164307.GB6724@laperouse.bortzmeyer.org> <CAOdDvNr1GstB+g3pYi4w0bXuQ=Nz8HqgTRfWUX9TGu9YAYiz0w@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 19 Mar 2018 02:49:40 -0700
Message-ID: <CA+9kkMA733q3BPRbnN++0vwKrmOOCN8SBgknYwFaeEf2cvYikw@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="001a113dd2804091a50567c0e284"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/TjGeujcs78sdaA7CWwEvsiF7CBI>
Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics
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: Mon, 19 Mar 2018 09:50:13 -0000

In-line

On Sun, Mar 18, 2018 at 11:18 AM, Patrick McManus <pmcmanus@mozilla.com>;
wrote:

>
>
> On Sun, Mar 18, 2018 at 4:43 PM, Stephane Bortzmeyer <bortzmeyer@nic.fr>;
> wrote:
>
>> On Sat, Mar 17, 2018 at 10:42:08AM -0700,
>>  Ted Hardie <ted.ietf@gmail.com>; wrote
>>  a message of 182 lines which said:
>>
>> > Similarly, it was not clear to me whether a response like 451 could
>> > contain a UDP wireformat body and, if so, what it would be.  If it
>> > contains no body, the DNS implementation might continue attempting
>> > to query for the information.  If it contains a REFUSED RCODE, in
>> > contrast, it would see a policy-based error.
>>
>> That's an interesting example. If a DoH server replies 451, does it
>> mean that access to this DoH service is blocked, for policy reasons,
>> or that access to this specific DNS data is blocked, for policy
>> reasons? In other words, can a HTTP response from a DoH server depend
>> on the QNAME? (Or on the tuple {QCLASS, QTYPE, QNAME}?)
>>
>>
> Unfortunately I don't think HTTP is going to clarify for you why HTTP is
> giving the 451 - all you know is that the response body is not the answer
> to your DoH request. The 451 could be based on anything in the HTTP request
> - which includes the query params and the message body as well as the path
> and origin. So you don't know what was wrong with the request in
> particular. So it could imo be as general as the hostname or as specific as
> a qtype.
>
> But I can say concretely that the message body of the 451 isn't going to
> clear that up in anything other than a human readable way.
>
>
The message body may not be able to answer this question completely, but it
can clarify at the DNS level that this was REFUSED.  The semantics of that
are much closer to 451's meaning than producing no DNS-level response at
all (which maps to "query did not complete" if I understand it correctly).

Ted



> -P
>
>
>