IETF Logo Mail Archive

Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Tommy Pauly <tpauly@apple.com> Wed, 07 October 2020 13:22 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8988F3A09D7 for <dns-privacy@ietfa.amsl.com>; Wed, 7 Oct 2020 06:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.3
X-Spam-Level:
X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 jsWzEe42xSNs for <dns-privacy@ietfa.amsl.com>; Wed, 7 Oct 2020 06:22:44 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D37853A0962 for <dns-privacy@ietf.org>; Wed, 7 Oct 2020 06:22:43 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 097DIMl5056842; Wed, 7 Oct 2020 06:22:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=R9fMKaVaMWfObMUL5KsPxYAzT4M3jHd3vEEu36jPie0=; b=p9lqZ1orajet4LqZ98ukJmOddF6bd4OH1HNXTzkUu0uR+s+4CSz5/cBtQCqFb3OCaONv 0nzfqfjZT5ymYsoTivJkgOYZ0Didm0VmHkwF7Xrx3pcHx6xRzJ0Vgn6gSSB+EQONTd5O yCLlPyi6ulqxZvuHK5Vl8hjBWf8zDrU5MpcN6XiWlaMzyxLSzQyhNAOIB8ldZGIJ/1jj D2MsWdl9D0YAa837MCg2DRijUAp0AoF/Om6GsLrgF3mFvXGYg+LMfGjf3v7pXDlX6mEs 1cdpBkitXiAwlMDH3PAVfQb7fk+LG6QtThiNM5vG4V2QLbcafRay8ZwFe6VM+DWJ01UA uQ==
Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 33xr9um41r-16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 07 Oct 2020 06:22:41 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QHU00OR22HREPA0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Wed, 07 Oct 2020 06:22:39 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QHU00A002DUZR00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 07 Oct 2020 06:22:39 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 49abafcf888da37f6561236f2cada3a1
X-Va-E-CD: 705702691aedd6670e3687c80c9df5ea
X-Va-R-CD: f7af8795141d8e3099f1341536676977
X-Va-CD: 0
X-Va-ID: d6afb2a1-ab66-4987-a213-7097b96068b3
X-V-A:
X-V-T-CD: 49abafcf888da37f6561236f2cada3a1
X-V-E-CD: 705702691aedd6670e3687c80c9df5ea
X-V-R-CD: f7af8795141d8e3099f1341536676977
X-V-CD: 0
X-V-ID: 31009ac3-fe09-495c-af17-0684093c54ff
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-07_08:2020-10-06, 2020-10-07 signatures=0
Received: from localhost.localdomain (unknown [17.234.7.156]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QHU00XFS2HPRP00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 07 Oct 2020 06:22:38 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <C276A52C-DCBA-4920-95E1-FAF2D3881D0B@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_BE99A3F5-3300-4584-A696-BEC6AE8B2751"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\))
Date: Wed, 07 Oct 2020 06:22:37 -0700
In-reply-to: <CAO+dDxn1J2bOz1b8iPKbUnYLTFhSLJRhx9Od5hAHpP3TSkp7yQ@mail.gmail.com>
Cc: "Vinny Parla (vparla)" <vparla=40cisco.com@dmarc.ietf.org>, dns-privacy@ietf.org
To: James <james.ietf@gmail.com>
References: <MN2PR11MB47604813E0DC2DDA0E297A36D80C0@MN2PR11MB4760.namprd11.prod.outlook.com> <CAO+dDxn1J2bOz1b8iPKbUnYLTFhSLJRhx9Od5hAHpP3TSkp7yQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.0.3.2.26)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-07_08:2020-10-06, 2020-10-07 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/zsMloijZobQdSDAXb91EBO5mlFY>
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2020 13:22:46 -0000

Can you cite this claim about DNS over HTTP/3? The per-query cost once an HTTP/3 connection is established should be minimal. If you’re taking into account all setup overhead for an HTTPS connection as a “per query” cost, that’s not representative of how DoH is reasonably used (and would be a issue with existing DoH).

Thanks,
Tommy

> On Oct 6, 2020, at 2:03 PM, James <james.ietf@gmail.com> wrote:
> 
> My most recent observations of discussions around DNS over QUIC and HTTP/3 was that some folks had attempted DNS over HTTP/3, however the overheads (~14KiB for a query at worst-case) made it impractical and infeasible. With regards to DNS over QUIC, the current dprive working group adopted draft [1] is focusing on stub to recursive, but not necessarily as a multiplex with an existing QUIC connection.
> 
> - J
> 
> 1: https://tools.ietf.org/html/draft-ietf-dprive-dnsoquic-00 <https://tools.ietf.org/html/draft-ietf-dprive-dnsoquic-00>
> On Mon, 5 Oct 2020 at 17:31, Vinny Parla (vparla) <vparla=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org>> wrote:
> Hi,
> 
>  
> 
> It was suggested that I ask this question on the 3 lists:
> 
>  
> 
> Now that QUIC & HTTP/3 is imminent…
> 
>  
> 
> I would like to know what the opinion is of the community on the long term view of DNS.  
> 
> Would DNS remain an independent channel or would it be subsumed in a multiplexed stream via HTTP/3 in some future version?
> 
>  
> 
> For example, would a browser perform DNS queries over a QUIC multiplexed session?
> 
>  (e.g. similar to how today an http proxy can perform DNS queries on behalf of the client using that proxy) 
> 
>  
> 
> Would love to hear from implementors what their long term view is of this in particular.
> 
>  
> 
> Thanks,
> 
>  
> 
> -Vinny
> 
>  
> 
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org <mailto:dns-privacy@ietf.org>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org <mailto:dns-privacy@ietf.org>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>

v2.23.0 | Report a Bug | By Email