Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

Martin Thomson <martin.thomson@gmail.com> Tue, 03 April 2018 09:58 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C510012E87F; Tue, 3 Apr 2018 02:58:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 GFz5hNbbBK1u; Tue, 3 Apr 2018 02:58:48 -0700 (PDT)
Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 EED57120726; Tue, 3 Apr 2018 02:58:47 -0700 (PDT)
Received: by mail-ot0-x229.google.com with SMTP id m7-v6so18746388otd.1; Tue, 03 Apr 2018 02:58:47 -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=IoYOKlpl7a3fKG+i8tkp91ymgyq8USnZaWhkoO/Lvuc=; b=IEY22VYYys4dy5TSN7CIVC75Mk+WT5yYhJQzjwzOkERsybvwfTMixa8uXg0J0B0y8h 7WRTduMYem9guxekAoLMJnhJYY2MPuJTb4impK+KjJ7e8Do3u5/EZNBvUphiasD2Q8Fn qWO9Wldv+fyDZw+7mmWzzfHvg6pWCJ1vACg7U0ggIBpdywuzUan1KHiKsMtT4fOF38Cv N+2cFtqxJ+M8Da74nQTTiqNudq3rcjQ/dYHWkFQHi6b+ZqBxzvkWxsUAwqun9lxi7aN0 qNryfEacU3qXPuYVaylURabV0sIb4suQ/6S3pfhx75a1vzH0Geu5Ah6ubfhwH4qWB4Ck QxfQ==
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=IoYOKlpl7a3fKG+i8tkp91ymgyq8USnZaWhkoO/Lvuc=; b=a+YuaftSGz+ms9xcZCJkB6JNmkzwY1Bc67ZtV1pX04xsF44C7fUSi3AwGHeKhWSLrY LbZcwXdBUAQ+EZucftaicvE5Bh6cDGbaO7U98DGNnIwVBdo6ucu2Eig3sjCeU4PFgRuJ jNyQ9UzDRoDdpwJm1aBmURAdIFlxEcjAAAVY3T7MWemn85KkWPyyCK+4bs2kvgHCGw9a E8HaEVshw9dAqbiGvNJbVZxl6vHh89sgR9ymlpzkwnLJ6Dza+fJY18kcJgBOmjS/D2MS 8HFdCU3nc647gbIReupoo4xRxy8X0qMS8ug1kLQkqr8P53Pk6W73EtqjyG3su02DWSkG Ib1A==
X-Gm-Message-State: ALQs6tDd0XiAQitvUuDoMokfsPb38pb/HIculBMAJthgvEB7zrTlJwRP h/cjpN0UQa4HZVpb6/5/HrgzK38jqOWYvPqjjrI=
X-Google-Smtp-Source: AIpwx49g6Jp9kkzJn1hE2qViKyyjTrj7yIs0aD1zavgjOTeiPImmayJeU6vr6GdQp2P4qtFQuWqz5V0vEJ5o7FYVCZI=
X-Received: by 2002:a9d:4c81:: with SMTP id m1-v6mr2890785otf.396.1522749527188; Tue, 03 Apr 2018 02:58:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 3 Apr 2018 02:58:46 -0700 (PDT)
In-Reply-To: <CAAObRXKHhk51DxNt5uiYB0gunJ=DNde2j9FJSU=Ky2m4Q1UkhQ@mail.gmail.com>
References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <CAAObRXLm3c-p9rZkn6H6tcEoh3-UT5JW06NXQ_FMyyr2NFMmyw@mail.gmail.com> <23219.33838.166003.614689@gro.dd.org> <CAAObRX+xF5SwVd3x3iXSWd-A0Kpr_ubbOJzn0yTrSk8pc+tm6Q@mail.gmail.com> <23219.56569.2064.711002@gro.dd.org> <CA+nkc8ANQh2wAr6==eNuM82mbD+E2ELzHGizdqF_sGdY-kkOqg@mail.gmail.com> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <CABkgnnX2jGY_JpVbqJuQdDVUyVzsuM_2CDg4nppfqQHZQm0F+w@mail.gmail.com> <CAAObRXKHhk51DxNt5uiYB0gunJ=DNde2j9FJSU=Ky2m4Q1UkhQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 03 Apr 2018 19:58:46 +1000
Message-ID: <CABkgnnVL0XaUDS-WzDGaN9-kLx9p3x1+UVuWhvx=Zyo5oRos+w@mail.gmail.com>
To: Davey Song <songlinjian@gmail.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>, DoH WG <doh@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5nq5L2_V24EzkkiBou9CtR8c2ow>
Subject: Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2018 09:58:50 -0000

If I understand your response (not sure that I do), that seems pretty
academic and not at all persuasive.  For instance, if a client cared
about testing TCP capabilities, it can always do its own resolution.

On Tue, Apr 3, 2018 at 7:44 PM, Davey Song <songlinjian@gmail.com> wrote:
>
>
> On 3 April 2018 at 15:33, Martin Thomson <martin.thomson@gmail.com> wrote:
>>
>> This is intended to do what?  Indicate where the response came from?
>> Why does the client care?
>
> To keep the proxy (API client and server) transparent and bypass the
> middlebox along the path. Without the indicate, the API server has no clue
> what transport the client use (or would like to use. because there maybe
> cases that client would like to test TCP capablity of the far end resolver,
> I don't know). If no such indicate, It is either always using UDP or TCP by
> default (or by local configuration). It can be done as an choice for
> software implementation, but for protocol design IMHO, a indicate should be
> introduced to provide that information.
>
>>
>> I assume that it doesn't apply to requests,
>> or that would get into draft-bellis-dnsop-xpf territory.
>
> That's is the quesion whether the indicate should be carried in HTTP layer
> or DNS layer. If we use HTTP as a tranparent tunnel without any modification
> on upper layer message, I would prefer to use a HTTP indicate.
>
>>
>> BTW, you really need to drop UDP from the media type name now.
>> application/dns-udpwireformat;original_transport=tcp is a bit of a
>> contradiction.
>
>
> I agree.  I find no harm defining a media type "application/dns-wireformat"
> for DOH.
>
> Davey
>