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

"Vinny Parla (vparla)" <vparla@cisco.com> Thu, 17 December 2020 20:33 UTC

Return-Path: <vparla@cisco.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 D834A3A0FF8 for <dns-privacy@ietfa.amsl.com>; Thu, 17 Dec 2020 12:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=H5KorkTH; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=AdiFYbD1
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 pnsNxvOkvJoP for <dns-privacy@ietfa.amsl.com>; Thu, 17 Dec 2020 12:33:14 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A30E3A0FF7 for <dns-privacy@ietf.org>; Thu, 17 Dec 2020 12:33:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34521; q=dns/txt; s=iport; t=1608237194; x=1609446794; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/yZvvYPm9tCtBe44rCKF0fh4yus4lG7UXMECSU/A1cs=; b=H5KorkTHZXOgltEywEXJEIQLlR43yC6J7JMXjgYWYKXXC5HjElEbN40c DGH5JC6aUQsb+lLNCBqra61t/FA/sVP2DqU8i7aI42ssdGfXt4x+4swao ycEeO/tlq3JIQe5xsmIYVABp5xCIup5yPM29nNka+Seg9H49M3LkOGOJ4 Q=;
X-Files: smime.p7s : 3980
X-IPAS-Result: =?us-ascii?q?A0CrCgD5vdtf/4UNJK1YCh4BAQsSDIMyLyMuB3UtLi8uh?= =?us-ascii?q?D+DSAONWwOKGo5ygUKBEQNUBAcBAQEKAwEBGAEMCAIEAQGESgKBcwIlOBMCA?= =?us-ascii?q?wEBAQMCAwEBAQEFAQEBAgEGBHGFYQELhXIBAQEEAQEQEQoTAQElBwwPAgEIE?= =?us-ascii?q?AEEAQEWCwcDAgICHwYLFAkIAgQTCAYGBgEHgwWBflcDHw8BDqMTAoE8iGl2g?= =?us-ascii?q?TKDBAEBBYE3AoNwDQuCCQcDBoE4gVOBIoUAgwmCJyYbgUE/gRFDglY+ghtCA?= =?us-ascii?q?QECAYEVGhUaFRYJCYJYM4IsgVgBaA0lOEMOAQEfAjkFJRIbKRYOAy0ICgIeW?= =?us-ascii?q?Y5uK4pKnCw4VwqCdIRcgmiBX4ZzhhmFPqI+lAeLDYJ3jlcchDMCBAIEBQIOA?= =?us-ascii?q?QEFgW0jKoEtcBU7gmlQFwINjiEJGoNOhRSFQwF0AjUCBgEJAQEDCXyLfwEB?=
IronPort-PHdr: =?us-ascii?q?9a23=3ABTe5jB3dEIVgiHYLsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGv6dsgUPHG4LB5KEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK6PFRbXsHkaA6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,428,1599523200"; d="p7s'?scan'208,217";a="611421193"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Dec 2020 20:33:12 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BHKXCRb029087 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <dns-privacy@ietf.org>; Thu, 17 Dec 2020 20:33:12 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 17 Dec 2020 14:33:12 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 17 Dec 2020 14:33:11 -0600
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 17 Dec 2020 14:33:12 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ypj3yFEQFUmBVrm1dXbs4U/PZNfo5KZXmmV7uQK6HP6OO077hQ4h/eOXoLNOFIlRlLDsvo/3+mmCd/lwf8IA3C/TKmkMwr7SGq/3TaWnHs8X2OGdzZS392xuclr/Ls7S3B/3jX8d82KPPcFcUDfSTsE9fyTNZDkIv9U3uKEqE2OiDQMcrkkqi3aWRx/rWdrFRGYIyfFx9XfGv+cC+MFl0a7vBdIao4oE3594IFWbnRnHWwOk5GQxlaNkxbEMYGuOUdJSJSaSsg7C1LGLF2C09EjDoU/Krb5Q977rpqgUF+M9Lvc3f5EcyBRmbGFdr6g6d84Pkv9cbR7xkCxwPsS/qA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cd/SASNjOIyIzDH9jtrOix+EGhH+YgIlFEttc7db6eQ=; b=ETrf2UbMa3HblQy/V87+z7lRBlqce25dQ9TwUP9TXDh62X4hmYHsqoTqAa4bbOXdK98V/FcvTTK+IWUl6bZiKVQHp2S5nn/Pm926AYE5+MSo5pHin9oxGSsylJfbl/DOHrvQcktuWFuvEY/my/4SzVfe1P5Aw8/gcsujJ48k4e3rsRIw9PDwbnvdzNpXVVcniMvbRlgitP/7CGOCiXyJ4tQkjISYQShIUAEc57rQ60u3yQ4NqMv/8d7MpC5c5chczKUeemDX3ClUoImEePt/iCI1OnQjtNTCSQmMJ0B06XfsrZZkvNJVHqjiT5JHwdJudBPMmEFh6FAo3C6uw4TCwA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cd/SASNjOIyIzDH9jtrOix+EGhH+YgIlFEttc7db6eQ=; b=AdiFYbD1wwU+agrU1NYJa7f7DO/fC4vd/VUg1wdgvwewt6uVIvClXbmSFr+hASplaNOWOG+BiVo2NMabM6DBGGXMYnxsLWrGxdLuaSYCgOffmY7T+Fs5PayEJCKvDDg+Ofq4OzXA1KRuAxRPNf1+NqDVGjcc1RRVMRAxtnHlp40=
Received: from MN2PR11MB4760.namprd11.prod.outlook.com (2603:10b6:208:266::22) by MN2PR11MB4566.namprd11.prod.outlook.com (2603:10b6:208:24e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.14; Thu, 17 Dec 2020 20:33:11 +0000
Received: from MN2PR11MB4760.namprd11.prod.outlook.com ([fe80::195e:17a5:40a:46f0]) by MN2PR11MB4760.namprd11.prod.outlook.com ([fe80::195e:17a5:40a:46f0%7]) with mapi id 15.20.3654.021; Thu, 17 Dec 2020 20:33:11 +0000
From: "Vinny Parla (vparla)" <vparla@cisco.com>
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
Thread-Index: AdabLJ2GPjqR+/akTMiZMRHmFMQKNAA94NwAACIy4oAAApqMsAAB5VCAAAG+vIAAAYOVAA356HUw
Date: Thu, 17 Dec 2020 20:33:10 +0000
Message-ID: <MN2PR11MB4760361A9ACF968F1AE6364AD8C40@MN2PR11MB4760.namprd11.prod.outlook.com>
References: <MN2PR11MB47604813E0DC2DDA0E297A36D80C0@MN2PR11MB4760.namprd11.prod.outlook.com> <CAO+dDxn1J2bOz1b8iPKbUnYLTFhSLJRhx9Od5hAHpP3TSkp7yQ@mail.gmail.com> <C276A52C-DCBA-4920-95E1-FAF2D3881D0B@apple.com> <MN2PR11MB476044BA6BD5D47C8088D434D80A0@MN2PR11MB4760.namprd11.prod.outlook.com> <F0B35F84-E3F8-44B2-9A06-FDF2C725229E@apple.com> <cfbaf15f-d3f7-99e6-b609-d07dafbb84f5@huitema.net> <CACJ6M17iU0mRfRT6VNWyHo+FWqp7uST7DittfDZG0RuKq1==ow@mail.gmail.com>
In-Reply-To: <CACJ6M17iU0mRfRT6VNWyHo+FWqp7uST7DittfDZG0RuKq1==ow@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:188:c400:bde0:ac5f:6b8c:24ab:63f4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 972f2deb-07de-43e7-6435-08d8a2caf8a8
x-ms-traffictypediagnostic: MN2PR11MB4566:
x-microsoft-antispam-prvs: <MN2PR11MB456677BFB6667B71E836F1F9D8C40@MN2PR11MB4566.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bLh3JqStJz+pi5ElarAtheNqmsZMMCoq57KqOovxBaI6FlyZFrVrrOGLSaLRXP/1jOAHfiTCP/aclLJcABkiITC2ti1mdFHWF7M2mmoDNyWgaZiAewIYFQSTRME/CEeiyIj9/i0O4IkvW9PV5DBiHyq6v/T5tG8+PIqF2yLDp4K2h1KuqZeR+B3pInP2Um+1cCrObJJqdf4Dxn7jnXGoskRsvlrjZJIpVso8ef8vj2P++UCOn27uyTq2qEuqiH0EWF+w0A0nRMTe4Ohmuz9wM/V2PUEqr/fBvIJgdl6Hb43ZYujVxb5WOg3dwIw2NEvPET0nfILre1MuJUBYbeq65YlU/Mswf3JxJksOv1+eHeEqrN9eHWh7u53L6Hn1K3ChrM09mOdy0OSl70Wf8NxM8g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4760.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(39860400002)(366004)(346002)(376002)(2906002)(8936002)(86362001)(53546011)(33656002)(966005)(71200400001)(8676002)(66574015)(166002)(55016002)(83380400001)(6506007)(6916009)(9686003)(66446008)(66616009)(316002)(66556008)(52536014)(66476007)(76116006)(66946007)(186003)(7696005)(99936003)(64756008)(478600001)(5660300002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?MUdjaVRsaFcya2UvaVFxclJ3V29WUnBlTk5ucWtUOXRoeW1EMUtwLzBhOTdh?= =?utf-8?B?VVhiekREUFlvS1ZteGw2RkhaYkdkTWNXUEhDL2VBQUl0VHpDa1ZnVzNoK1VQ?= =?utf-8?B?TDFFekp5b3FPSmN5U0ZUejBjMHA5NVAzZEVlMW85eFVJc09sSXcwaXJYYUVV?= =?utf-8?B?d1B6NE5SSTc2TFZEbnMyL204a1RWS0NWd3RNenVCUCs0cHcyUjkyZTRIUmRK?= =?utf-8?B?RDlGWXB5RUVGckxQdWlCbkQyUFh2TFIvL2NDT2RyekNZdGdlejZURzZ0R25D?= =?utf-8?B?a0ZObFZML1QvUW1qbkgwc3EwZitleUZrWGkwYWZqQ1BhMHl2bjdiZnhuL2h2?= =?utf-8?B?RERmQ2ExSXdwSGR1MkYzdEdmOUZvUEN6NnhGTXNybmxjVkZKVkV1YUV5NGNz?= =?utf-8?B?aHJJSFhvV3ZlcStkcEFDcXJKSUU0bGhnemc0TnBNYno4R0V6RVBaRi9CLzFm?= =?utf-8?B?bkU5MUpBdm1HSDZXRkVOYWRSSFZaWHRsWkhFOVVpTFV4aHR4NGdJb0pOdzF4?= =?utf-8?B?dWhLUyttem4xQ0ZDNytLbFk5Wlp1VFJrNlNLQXBqSlhyaEpIbCs0STAxV28w?= =?utf-8?B?Z24rYkdtTmY5TktQRjVvcVFUbTZoemswTjlkZWZWQ3VwVDJsWUk2TnQyM2V5?= =?utf-8?B?Y2xUZ0UrcUE2dXRpRDdlbVFtd3VLZXRMTnMxcU5FQm9Rd0kxVmJSRnloTnk4?= =?utf-8?B?amdXdHZtcXdSOFdXcnd4aHlIQkZ0aVJWbjZaMUM4YVdLR3BoMDd2VWZRWE9I?= =?utf-8?B?OGovaTI1QlBRVE81MFhXMVZnVXJzUEtaUUZxakJhMzhZUTluWWRiQnBTTHFS?= =?utf-8?B?Q1FJMU9CQkVub2FyZjVDbkJCQ0NsODE1dGtTNWM0UDVvQUh3SlhoSHpNQ281?= =?utf-8?B?UFBWSU1xdXVHYjNaVmhuQzV6ejh5OGR6MGpFVzUvZE9rVkhicS9kMENMcVdY?= =?utf-8?B?eExTNjhUcVJiODZhcTJjZXBXTHdVYnFWMHVyeCtENXU0czJVcDEyYlVpbktr?= =?utf-8?B?R2xNMzl0YUlTMFlHZXUxSTdOZE41SVRRS1Z3cCtRakRkcklBQ0dZT3BZMGR2?= =?utf-8?B?djRnWDUzSUpXaXp6a2pXR1lZeGRPQXpUbzdyZmRvVkh5YVRuWDNaei9RTGI0?= =?utf-8?B?dGdEQjBvTS9oWDliME03bVVITVhqdFU2bjYxbGxoRzBBaHR1akErcHhOZTk4?= =?utf-8?B?Z1c5U3B3czA0aHVHMkpFbGpuNUptNEpzYitqRWxCV29CNWpuVnB1dmVBeTc3?= =?utf-8?B?YXZ2c3F3SWVSY0t4dkdkSTNLVmU1Zjh4V0lNZDNOMnNrWk9UNkJMdHNEZ3NC?= =?utf-8?B?WkpUaFIzdVNsRmd5dE54clNWYmJyU1VVLzVObVR6Q2N2U1kzbUJLZWtCSWhi?= =?utf-8?Q?VVWkFxz4u1AaiEMalRgUUdlFFgabmEOE=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05DD_01D6D489.EC306150"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4760.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 972f2deb-07de-43e7-6435-08d8a2caf8a8
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2020 20:33:11.0330 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HrAZKFZDjRtReMLHP7cVqIjoMBko/7YnbP6QQhkZQ3Xgyo+95LhxO5iwTswVFx8I9yBC9Doq6aWAvrgszthv3g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4566
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/MH9RuKeeKKZsRf1BjrKGqnMzMxo>
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: Thu, 17 Dec 2020 20:33:17 -0000

Just reviving this thread with the recent news to see what folks think in terms of content and dns multiplexing.

Ad-blocker AdGuard deploys world's first DNS-over-QUIC resolver | ZDNet <https://www.zdnet.com/article/ad-blocker-adguard-deploys-worlds-first-dns-over-quic-resolver/> 

 

From: Chris Box (BT) <chris.box.ietf@gmail.com> 
Sent: Wednesday, October 7, 2020 1:05 PM
To: Vinny Parla (vparla) <vparla@cisco.com>
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

 

Vinny,

 

Christian makes a number of good points. I will just add that your original question assumes that the client wishes to send most or all of its DNS queries directly to the content provider it is talking to. The ADD working group is founded on the concept of needing to discover recursive resolvers, and very often these are not the same endpoints that the web content is served from. This implies that reuse of an existing HTTP/3 connection that was established for retrieving web content, will not be the end goal for DNS queries. Sometimes it'll happen, yes, but certainly not all the time. It is far more likely that DNS will continue to be an independent layer, served by its own set of servers that has only some overlap with the set that serves web content.

 

Chris

 

 

 

On Wed, 7 Oct 2020 at 17:25, Christian Huitema <huitema@huitema.net <mailto:huitema@huitema.net> > wrote:

There is indeed some extra per request overhead for Doh over HTTP3 versus Dns over QUIC, but I don't think that is the deciding factor. I think that the two other decision factors are for the client the privacy risks linked to cookies and other forms of HTTP tracking, and for the server the additional attack surface caused by adding an HTTP server stack to the DNS service. These factors may play out differently in the stub to recursive scenario and in the recursive to authoritative scenario.

In HTTP-3, each DNS request would be carried by as a POST command, which requires a Header Frame to carry the HTTP header parameters and a Data Frame that carries the actual data. Each reply also requires a Header Frame and a Data Frame. In the fairly minimal implementation of HTTP-3 in Picoquic, the HTTP header carries the name of the Request URL, the name of the Http Server, and the content type. The Data Frame header carries the content length. The typical overhead for a request would be 16 to 32 bytes, depending on the length of server name and URL; the overhead per response will be 21 bytes. A full implementation of HTTP-3 would use header compression to reduce the size of the query overhead, but might use an additional set of HTTP header elements, including cookies, so the Header Frames might be larger in both directions, with a range of header size from a few dozen to a few hundred bytes.

Running over HTTP brings to the DNS the privacy issues of HTTP. Cookies and other headers are used to manage content and caches, but also identify the users and enable a variety of surveillance scenarios. If a DoH query is multiplexed inside a regular HTTP session, the query will be associated with all the user information gathered in the session, which creates an important privacy exposure. This is definitely a greater exposure than a regular DNS query, in which the main identifying information is an IP address.

On the server side, running over HTTP implies running on top of an HTTP server engine. This brings in a lot of code, some of it complex. It might be well tested and well maintained code, typically much better tested and maintained than if a server operator attempted to develop a specialized implementation of HTTP, but this is still a very large additional attack surface. Moreover, the HTTP code only remains "well maintained" if the operators regularly apply updates, which adds an operational constraint.

I think that the exposure and overhead issues imply that solutions like DoT or DoQ should be preferred to DoH in recursive to authoritative scenarios. They should also be preferred when the stub resolver is part of the operating system, because operating system resolvers would normally not mix their queries with existing HTTP sessions, and thus don't get any advantage from "integrating to the web" -- unless of course firewall traversal is a big issue.

-- Christian Huitema

 

On 10/7/2020 8:31 AM, Tommy Pauly wrote:

DoH is designed to be multiplexed with other HTTP requests. This is already possible with HTTP/2, and HTTP/3 carries on that ability. In order to take advantage of multiplexing, even with QUIC, you need some application-layer awareness of the content of the streams, which is why this is more practical with DoH than DoQ. 

 

I’m not sure how prevalent the multiplexing is today. For example, in our system implementation on iOS/macOS, DoH connections are made by the system DNS daemon and thus are not easy to multiplex with requests. However, that’s just one model, and there are certainly cases where the application would know it could multiplex a priori (and thus do DoH in the application), or could recognize that DNS results point to the same address as the DoH server, and start multiplexing after the fact.

 

Thanks,

Tommy





On Oct 7, 2020, at 7:39 AM, Vinny Parla (vparla) <vparla=40cisco.com@dmarc.ietf.org <mailto:vparla=40cisco.com@dmarc.ietf.org> > wrote:

 

Hi,

 

What I am driving at in my original question is do we envision mixing Content and DNS together in a multiplexed session or will DNS continue to be an entirely independent channel (whether over HTTP/2 /3 Do53 DoQ DoH).

 

-Vinny

 

From: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org <mailto:tpauly=40apple.com@dmarc.ietf.org> > 
Sent: Wednesday, October 7, 2020 9:23 AM
To: James <james.ietf@gmail.com <mailto:james.ietf@gmail.com> >
Cc: Vinny Parla (vparla) <vparla@cisco.com <mailto:vparla@cisco.com> >; dns-privacy@ietf.org <mailto:dns-privacy@ietf.org> 
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

 

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 <mailto: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

 

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

_______________________________________________
dns-privacy mailing list
 <mailto:dns-privacy@ietf.org> 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

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org <mailto:dns-privacy@ietf.org> 
https://www.ietf.org/mailman/listinfo/dns-privacy