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

Ted Hardie <ted.ietf@gmail.com> Sun, 18 March 2018 13:57 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 376D012711A for <doh@ietfa.amsl.com>; Sun, 18 Mar 2018 06:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 EEThWvIsnU6S for <doh@ietfa.amsl.com>; Sun, 18 Mar 2018 06:57:39 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 54269126C0F for <doh@ietf.org>; Sun, 18 Mar 2018 06:57:39 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id c12so12256738oic.7 for <doh@ietf.org>; Sun, 18 Mar 2018 06:57:39 -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=Negjez1tf0ZUWEWI0aZeTcCcpAAah7U+jELNo1QWXbA=; b=CAtHh7w8VvJQHfy0gFXQfURJr6Xu1EiIpsYmi8z3yUXFjBbTno9FVU4LNPLlK2gi9c nTU3n971vRWf7pBkwyfprDpSQcyKXvQDtUggLFYjunZMzplldbo9l8d2NiYj1xjcfkso BFsVuhwuzkpdz1NLspvUpLf+/T9iWcSa1DvBjDasZWlZefj3uGxi51rZg8ojHwr8l3Z6 EVZoXcQ3TVFKYHUleGH2L9HPwfJSCwvQCAfhWEz5pipR5SktjT/IaCBwvov7QB08VHTT yH6OI+AXz30CipW3UPgbU2inSNeSmgbfPSv8CK7pcCYvQpq94TrAZtsqtbYkOCfMkmYg kvRQ==
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=Negjez1tf0ZUWEWI0aZeTcCcpAAah7U+jELNo1QWXbA=; b=kujT5rzbtMBnzc60dMjAhB7FJyGpk8iNdShtoQJOmS9fEZwFgPQjPKEYlXJENmAgHj Wsd6sMdbND1wxTnICBL7j4fspjfFONGL45KIatZDCcuI/kchs6TmBneFd6dr3q1fapOb v89ERqNmyzqKBwnzFSZHcIgi03DAf4m+ofQidhlJ7nyjZKaU1Y5T86R8bqPQKYdjy0qB XXtxcqQkm4wlZMXl0QZE/SeC8PAZRLj+dmFZJggai/WIB4bOWWF106KcUN6QCA4vukMH AEKSYWxOQMHNcWNx0X6yIgda60sgVr2R9VoRYnk2mLh4QDnqBqNUHhOq+ChPFmUsgOVV tj2g==
X-Gm-Message-State: AElRT7EK4veVMTjTJpefpex/iCtj54Jkl2YuRaF7vj9VuYEXO3TDwTEY S4ysEyCHwWNpah5MmoP9riABhm60M3JF9PzgFo8=
X-Google-Smtp-Source: AG47ELvGCA0DfGWenzklsmPsI84+u0owwe+DCc10m4vGypQj36SSSFdEVxBwbgB3I5OV7lpAo+sbKkndFKPGZLtpxR0=
X-Received: by 10.202.225.67 with SMTP id y64mr5452329oig.122.1521381458342; Sun, 18 Mar 2018 06:57:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.7.27 with HTTP; Sun, 18 Mar 2018 06:57:07 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.20.1803181226570.24786@tvnag.unkk.fr>
References: <CA+9kkMB7awRfW9jUmY9Q-1p+w3VLtpG5DxhF3s7Q58nEMZeX3w@mail.gmail.com> <CAOdDvNpt-d+8epv80q4eofG4X-K83=zJdmFV67Z2z+4GNOQwxw@mail.gmail.com> <CAHbrMsBFE+4XpRbJucXu=zyMfZdmm29gQDn20GfgTrzk-O170A@mail.gmail.com> <CA+9kkMCGzTe+YPoaUZSUzWR4bdLkTZEUNx6j0dp544hVrHB9=Q@mail.gmail.com> <alpine.DEB.2.20.1803181226570.24786@tvnag.unkk.fr>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Sun, 18 Mar 2018 06:57:07 -0700
Message-ID: <CA+9kkMCuLwAcAVcPR2aE3h9Od_mnoYvwgu8FAxh1dJ4bpWj1Rw@mail.gmail.com>
To: Daniel Stenberg <daniel@haxx.se>
Cc: Ben Schwartz <bemasc@google.com>, doh@ietf.org, Patrick McManus <pmcmanus@mozilla.com>
Content-Type: multipart/alternative; boundary="001a113d4d6e647d1b0567b0394d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/H6GQXERp92w_fAk7PcwYwrg4QHc>
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: Sun, 18 Mar 2018 13:57:41 -0000

Howdy,

On Sun, Mar 18, 2018 at 4:43 AM, Daniel Stenberg <daniel@haxx.se>; wrote:

> On Sun, 18 Mar 2018, Ted Hardie wrote:
>
> Saying something in the document like "only 2xx response codes will carry
>> response bodies with DNS UDP wireformat" would be a short and sweet way of
>> saying that in the document, if there is working group consensus that this
>> is true.  Based on my conversations yesterday, I am not sure that there is
>> complete consensus on this point, though there may very well be rough
>> consensus.
>>
>
> I'm firmly in the only-2xx-carry-response-bodies-to-care-about camp. I
> don't even understand how it would work otherwise.
>
> What other HTTP response codes could be used to transmit DNS responses?
>
>
The 4xx ones, might, as I noted below.


> A pure transport failure may result in a retry.  There are some of these
>> responses which strongly indicate that such a retry will result in failures
>> (e.g. 403).  If you do not synthesize some message to the DNS client about
>> the type of failure, and the server does not provide one, what part of the
>> system avoids the retry?
>>
>
> For all 4xx HTTP response codes, the "fault" is in the client side (the
> request) so if you as a client decide to retry the request it doesn't at
> least make any sense to send an identical request again.
>
>
I think you're thinking of a different layering than I am.  If the DNS
client is talking to the HTTP stack as if it were a transport, and it gets
nothing back (transport failure), it may construct and send the query again
(it might do that in the UDP transport case, for example, on the theory
that the network had dropped the response packet).  To avoid that, you
might want to send a DNS message that encodes the information that this
server will not fulfill this request over this transport.

regards,

Ted


> I don't think 4xx strictly avoids retries. It informs the client about the
> fact that the request, as-is, was denied. A retry would then have to change
> something in the request for it to be successful. 401 and 407 are good
> examples of this, for which clients often retry with a modified request
> (with added auth headers).
>
> --
>
>  / daniel.haxx.se
>