Re: [Doh] No truncation for DNS over HTTPS

Davey Song <songlinjian@gmail.com> Thu, 22 March 2018 14:51 UTC

Return-Path: <songlinjian@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 DF4C012D87E for <doh@ietfa.amsl.com>; Thu, 22 Mar 2018 07:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_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 H03naJF7kIqV for <doh@ietfa.amsl.com>; Thu, 22 Mar 2018 07:51:17 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 E195912D86E for <doh@ietf.org>; Thu, 22 Mar 2018 07:51:16 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id f6so5739003ual.0 for <doh@ietf.org>; Thu, 22 Mar 2018 07:51:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kBsVoGWBPr54AcGgrNF/8jpKX/AxKYDjkEO3GdBcTIg=; b=R83LcvUg1uvT7hmDZjm5WIo6Pu81LC9TGE2FxtBw+NjzBuKfeMii000yyCs29q/ny9 FdjrrabxOPPv0LrEJsCVtt7CivFG1CBEzsqRXYsySqLedorTs8t2iQdpBctwSV79hYiw R2ZWVkRfqxVD5JNl2GCtkXJZ/JSWoJvRRlrFbMaIYwT9k808GgOTV9hc6uCZ8m1SxJw4 M7/pUFWyakdDQJW83l7bOE31DCFKHclJ2HlEIu1dVijgD4QtqGMogwYrJ1sYerybuhNZ n8iAXIb4DlRxs2KsU0t3ecXqfrQ2ObMvt1YQjXTF9tewubekGv5ZvhBL9Pfy9uaDrv86 58vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kBsVoGWBPr54AcGgrNF/8jpKX/AxKYDjkEO3GdBcTIg=; b=R7PSgrfu2GnsoEBs28MSQEuUcUfazFZVockbLUaMJjzk+3LNyU6Bdf3l/ADLQ2hQij /mvMpRJNWls6Kudr9fe5+JTUqTwCbwx2haVZoMn6Y670gTmt5iARpSsFJc8NSNdamjLn tq5XDJICUQRZAD823fKluru2PkftVPwgMFwYE6nB78mEfvkkTGV2EZF06zbm7P6ytwHt 2jHeoazyFJ1zWQtWsAQYMNMRdksgw9dQPfeBt46dkcmS1LogpULyF8pcroqDymCOQGNY n9PQIEPD055KaKNKaf8Z37SHFQqxsnmc+X5IRNaCnlpU1AN+gSnepIJcK4CCsZM6omF6 gvbQ==
X-Gm-Message-State: AElRT7G10yFxm1YULCW6E2HyOnWyKtQg3SHLceovAnzggXtTk0cs0Rf8 rvzWnqmBZh0bdT0o6Nyf3jx7WQRSvJ/j5Tdg3wI=
X-Google-Smtp-Source: AG47ELvuivRN2tM8dZVCrWNTIiGzR5BnNaeSEUEhwu5Oo49bMvCqUgx2dY2otmczO3ga5BMxSnG2ALK+8qWFTEb1O/k=
X-Received: by 10.176.85.199 with SMTP id w7mr14477217uaa.145.1521730275854; Thu, 22 Mar 2018 07:51:15 -0700 (PDT)
MIME-Version: 1.0
References: <CAAObRXJDV5Oa_d_S12HT2jqBuO=-AHOuMH8eKrac3BZ2bDxixw@mail.gmail.com> <a8949b7b-5717-6d63-af70-984894e6a571@bellis.me.uk>
In-Reply-To: <a8949b7b-5717-6d63-af70-984894e6a571@bellis.me.uk>
From: Davey Song <songlinjian@gmail.com>
Date: Thu, 22 Mar 2018 14:51:04 +0000
Message-ID: <CAAObRXKTpo=xt_C=C1xhkeOFAV=B7_fq7r7nU24VE-7RpVqbBA@mail.gmail.com>
To: Ray Bellis <ray@bellis.me.uk>
Cc: doh@ietf.org
Content-Type: multipart/alternative; boundary="f403045e343489501f056801705a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/NvkdUGehvrzGZau3B1sOpD7dWBU>
Subject: Re: [Doh] No truncation for DNS over HTTPS
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: Thu, 22 Mar 2018 14:51:19 -0000

Sorry. We are talking about two different things. One is about DOH as a dns
transport protocol. One is about the proxy use case.

I'm told by the author that the doh draft is to define HTTPS as DNS native
transport, just as DNS UDP and DNS TCP, that's why I'm asking more
clarification on truncation.  There is nothing to do with proxy use case.

If the DNS API server is deployed as a proxy, it is introduced as a doh use
case in another draft in dnsop:
https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-02

In the doh proxy draft, it keeps the transparent principle which is
proposed in rfc5625 as well as full support on TCP proposed in s4.4.1 of
rfc5625. So the "WAN interface" speaking normal UDP must recognize TC bit
and be able to fall back to TCP. But the "LAN interface" speaking DOH
should not do truncation. The process of truncation for stub-resolver
should be done in the"LAN interface" of DNS API client, If I understand
correctly.

I will add your suggestion on doh proxy draft. It is recommended in rfc5625
though.

Davey


Ray Bellis <ray@bellis.me.uk> 于 2018年3月22日周四 18:24写道:

> On 22/03/2018 09:20, Davey Song wrote:
>
> > Although the dns-udpwireformat MIME type was defined, the dns wireformat
> > data should not be treated as a datagram encapsulted in a HTTPs header
> > but a new byte stream over HTTPs (similar with DNS TCP usage). No
> > truncation loop is needed. Peopole may take it for granted, but It
> > should be explicitely mentioned in this draft.
>
> If the DNS API Server is proxying between DOH and a real UDP DNS server
> then the UDP DNS server might still set the TC bit and the proxy could
> return that, so the client may still have to cope with +TC.
>
> The alternative is that the proxy has to have sufficient smarts to
> recognise the returned +TC and re-issue the request over TCP to the
> backend DNS server.
>
> Ray
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>