From nobody Tue Nov 6 02:11:27 2018 Return-Path: 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 6ECDF130DF6 for ; Tue, 6 Nov 2018 02:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 brs7KJbFi9fe for ; Tue, 6 Nov 2018 02:11:24 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587C9130E7B for ; Tue, 6 Nov 2018 02:11:24 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id B6F09316CA; Tue, 6 Nov 2018 05:11:22 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23521.26826.725343.973720@gro.dd.org> Date: Tue, 6 Nov 2018 05:11:22 -0500 From: Dave Lawrence To: doh@ietf.org Archived-At: Subject: [Doh] DoH Working Group Status X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 10:11:26 -0000 With the publication of RFC 8484, "DNS Queries over HTTPS (DoH)", we consider the doh working group to have fulfilled its charter. This could signal the closing of the working group, but a temporary stay of execution has been granted. Several interesting areas of follow-on work have been identified. While some this might well be handled by other long-lived working groups (such as dnsop, dprive, or httpbis), for some issues the blended expertise of DNS and HTTP people together could be best. It is not yet clear whether this would be done by rechartering doh, or closing it in favour of an ops-area group, or fitting in to the most relevant existing group. For now the doh working group and its mailing will remain open, at least through the spring meeting in Prague, to consider new work. If you have work that you think should be handled by a doh-focused working group, please make sure it is known. From nobody Tue Nov 6 02:27:49 2018 Return-Path: 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 DFED9130DC4; Tue, 6 Nov 2018 02:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VJ1LQzHp1pLG; Tue, 6 Nov 2018 02:27:39 -0800 (PST) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id C631C1277C8; Tue, 6 Nov 2018 02:27:38 -0800 (PST) Received: from naina (unknown [159.192.243.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 7A9C532C0908; Tue, 6 Nov 2018 10:27:35 +0000 (UTC) Date: Tue, 6 Nov 2018 17:27:31 +0700 From: Mukund Sivaraman To: doh@ietf.org, dnsop@ietf.org Message-ID: <20181106102731.GA5280@naina> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Doh] On today's resolverless DNS meeting X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 10:27:41 -0000 Hi all It seemed that the objective (or an objective) of what is desired is for a webpage to have an and also push an address record for the hostname in the src URL. We talked about DNSSEC and certificate signing and such. If the host serving this webpage to the browser has control over the webpage's content (e.g., the contents of that src attribute), and the webpage's contents are already authenticated by TLS, then why does an address record have to be separately authenticated? Why can't the webpage contain the addresses of the hostname in the URL, in another attribute of that element? Does it have to be separately signed via DNSSEC and certificates? The webpage can tell the browser to fetch the img resource from anyplace it wants to - it can very well specify an IP address instead of the hostname - the webpage controls it. Why can't it, for *that* element, provide the target address in an attribute without any additional signatures, given that the webpage's content itself is authenticated via TLS? Mukund From nobody Tue Nov 6 06:39:38 2018 Return-Path: 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 05543130DFE for ; Tue, 6 Nov 2018 06:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 o4HOoeNdcPo4 for ; Tue, 6 Nov 2018 06:39:34 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 E4E4012426A for ; Tue, 6 Nov 2018 06:39:33 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id v1-v6so5423710ljd.0 for ; Tue, 06 Nov 2018 06:39:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=O7SauoN52L3YghV5k20xzAuF26vf3MkONeyCWUclxC8=; b=efEkpijKUvG+mVWOMnTpAlwaZ8di3rBQcxyuE4xNDkMxfwif9jB82h/weH+3q6BcgD 4Ekj45I9UDx+Q0uRWWM1RnYGRGSqzrpK89hfcm+rTreyaQuhaWqv19SlTSJyMpSRoMC1 1lKtjD+PT8X0n84x7TQAnB8pfrvGVWVFL/x7s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=O7SauoN52L3YghV5k20xzAuF26vf3MkONeyCWUclxC8=; b=EdDlDk1Rp+7hnDkso4KHHmxsnJI/FPvYh71shM1+8cT04FzcmoyXyDOCos7gLh4L4o VpME7Ux0ufviO3qg2GJpDZHpW/j/NUTIAPE03VjS4CaUUFTJkFf83KZUan0tuGluQ4Jh lCBiX+RX1x0DbXQ8h9Kfiha56cTigeUQrXwiQejWI5TN50VddsQHWrZ+bVm5qA9O2q7D cuasFkBNxiDGuwWUftqz+KTfeHBbppVwaiKqLZnHRiTFLKxfQkMDyZeYjW1N2HRyISs5 JcZVlpFbakyMXieZJO/Xp/k8EZKRLhVrJSa+iGI5Zs5euaV1ADTAxEI5+Jk9x9gq8MAC Rz0g== X-Gm-Message-State: AGRZ1gIVKIqR7FBqFQc9QsMVyORq+IyIY6iFORLbpIzUaD/4/3eCJ/QE sKykPJW0VARDFVSzStFSLbAWpKHbzv20LCYABqeRuw== X-Google-Smtp-Source: AJdET5dCOiBEWrh/SULE+HwHSruTDxswqosMU+VDjvOwhBrssK5KqEuFyCzp5hV/4SQVfy65SvuGDKVwnJxf2kE6vGI= X-Received: by 2002:a2e:6d0a:: with SMTP id i10-v6mr18916522ljc.14.1541515171950; Tue, 06 Nov 2018 06:39:31 -0800 (PST) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Nov 2018 06:39:30 -0800 From: Joe Abley Mime-Version: 1.0 (1.0) References: <20181106102731.GA5280@naina> In-Reply-To: <20181106102731.GA5280@naina> Date: Tue, 6 Nov 2018 06:39:30 -0800 Message-ID: To: Mukund Sivaraman Cc: doh@ietf.org, dnsop@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] [DNSOP] On today's resolverless DNS meeting X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 14:39:36 -0000 > On Nov 6, 2018, at 17:27, Mukund Sivaraman wrote: > > We talked about DNSSEC and certificate signing and such. If the host > serving this webpage to the browser has control over the webpage's > content (e.g., the contents of that src attribute), and the webpage's > contents are already authenticated by TLS, then why does an address > record have to be separately authenticated? I think this is an easy one. It doesn't. The names that it is permissible for a server to push information about (and the names that a client should be allowed to accept) must be constrained such that the names supplied for use in one web application can't influence the operation of another. (For example, it would be bad if some generic and otherwise benign web page could feed the browser high-TTL DNS messages for names under online retailer domains that accept credit cards or component APIs used within genuine web apps.) The obvious analogy to me is the logic that controls what cookies a browser should accept. Maybe exactly the same rules are appropriate. I realise that managing those rules using mechanisms like the public suffix list is not without challenges. If we accept that these constraints are necessary, then the presence or absence of DNSSEC signatures doesn't matter. The DoH objects are within the same security perimeter as the URIs that make use of them and don't benefit from additional integrity protection; the transport security for all the other objects being sent from server to client provides the right coverage. Joe From nobody Tue Nov 6 06:45:13 2018 Return-Path: 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 DB426130E6A for ; Tue, 6 Nov 2018 06:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 BNMlWoWavzmp for ; Tue, 6 Nov 2018 06:45:09 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 EAFF0130E48 for ; Tue, 6 Nov 2018 06:45:08 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id n7so4606837uao.7 for ; Tue, 06 Nov 2018 06:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fZ85//HAL1u8tGRSWBYUwISmaevkCKDhlUIFuHg5k+w=; b=aZI0WTuCyXrhMe+52Fg6+iauDJnLaLPu34M7ZyctrGnB218nfxOChq2zRwvVuplatm MnPiHHDBzdS40rVuYER83U6r41iEIf18VMb0ZEFdYeBb7oSpwTQ6pp+gIlAn8BDgBqAO Cd7gxiL14in7qvAPgR7HzujT5/0nTVhv7LFKOOCue2BGj704T10dAnGrelwG3M9t5MRY x9ZxJMkUtWn+DkKWBLyZZmz65yL2cqzFbV5tH6SZTk4/v2wpzpm/Lftq6quqhIOR0ooy xescuAVX0d0Nz3P26Vi59jstnK0ugtUZ90ok9gEzmWUzbfPKk14FStstwxaiIHTSDlxT UAPg== 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=fZ85//HAL1u8tGRSWBYUwISmaevkCKDhlUIFuHg5k+w=; b=r6yoDSPJVJ7qN4/IeCXHkhx2jLmRdp9Xo0l8wntJfahalfWfx1QSuKo15BiApX2CL/ xC+yC39+3cj5oz4XY05r4+oA+hb2DNZMrjsDyGmezkb6ms+3ZThygo+1OJieW+4ixz0H aI1bFF++ixPCPzXfeR7jV1TgdA9PqOwf4Ylxt4/iixeu5U5gGihrKqh3sUEZPVQqQDWq rkGliu4BWhD+Q4D6XIfbqPNANvhppb7AWOmKf+7AV/hjznKy7qApCTxPUHTPpN8n6jfA DOWIl7wdWKf3t6PKEwyhQpp9yWTe8wHS+iERwqVOD+zsYtRRiqMZJS4Yg+af4/nG19kG gzOw== X-Gm-Message-State: AGRZ1gIYfZ8jt0cKkuoW+BvHWgL8M2+dIfPrNXu2QR9aQCUb5Lv2kTFx xx3mccb+R1WlcViE6X6i7tAdQsNgjPQZaAaPjeo8tQ== X-Google-Smtp-Source: AJdET5fr7cyx5bq+p3+fxcFMZ2tJsuWRaF17YcFuwfnFuwqjKzotUVQ0FLqi+ViJSwaxb7uLCev8rTtoX8mwZ+XP5Sg= X-Received: by 2002:ab0:550b:: with SMTP id t11mr509297uaa.31.1541515507533; Tue, 06 Nov 2018 06:45:07 -0800 (PST) MIME-Version: 1.0 References: <20181106102731.GA5280@naina> In-Reply-To: From: Justin Henck Date: Tue, 6 Nov 2018 21:44:55 +0700 Message-ID: To: jabley@hopcount.ca Cc: Mukund Sivaraman , dnsop@ietf.org, doh@ietf.org, resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="0000000000003e71bf057a000cad" Archived-At: Subject: Re: [Doh] [DNSOP] On today's resolverless DNS meeting X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 14:45:12 -0000 --0000000000003e71bf057a000cad Content-Type: text/plain; charset="UTF-8" Briefly jumping in to add resolverless-dns@ietf.org, which was set up after the last meeting for discussion of this specific topic. Direct link: https://www.ietf.org/mailman/listinfo/resolverless-dns I also just sent the notes to that mailing list. Justin Henck Product Manager 212-565-9811 google.com/jigsaw PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B On Tue, Nov 6, 2018 at 9:39 PM Joe Abley wrote: > > On Nov 6, 2018, at 17:27, Mukund Sivaraman wrote: > > > > We talked about DNSSEC and certificate signing and such. If the host > > serving this webpage to the browser has control over the webpage's > > content (e.g., the contents of that src attribute), and the webpage's > > contents are already authenticated by TLS, then why does an address > > record have to be separately authenticated? > > I think this is an easy one. It doesn't. > > The names that it is permissible for a server to push information > about (and the names that a client should be allowed to accept) must > be constrained such that the names supplied for use in one web > application can't influence the operation of another. > > (For example, it would be bad if some generic and otherwise benign web > page could feed the browser high-TTL DNS messages for names under > online retailer domains that accept credit cards or component APIs > used within genuine web apps.) > > The obvious analogy to me is the logic that controls what cookies a > browser should accept. Maybe exactly the same rules are appropriate. I > realise that managing those rules using mechanisms like the public > suffix list is not without challenges. > > If we accept that these constraints are necessary, then the presence > or absence of DNSSEC signatures doesn't matter. The DoH objects are > within the same security perimeter as the URIs that make use of them > and don't benefit from additional integrity protection; the transport > security for all the other objects being sent from server to client > provides the right coverage. > > > Joe > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000003e71bf057a000cad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> On Nov 6, 2018, at 17:27, Mukund Sivaraman <muks@mukund.org> wrote= :
>
> We talked about DNSSEC and certificate signing and such. If the host > serving this webpage to the browser has control over the webpage's=
> content (e.g., the contents of that src attribute), and the webpage= 9;s
> contents are already authenticated by TLS, then why does an address > record have to be separately authenticated?

I think this is an easy one. It doesn't.

The names that it is permissible for a server to push information
about (and the names that a client should be allowed to accept) must
be constrained such that the names supplied for use in one web
application can't influence the operation of another.

(For example, it would be bad if some generic and otherwise benign web
page could feed the browser high-TTL DNS messages for names under
online retailer domains that accept credit cards or component APIs
used within genuine web apps.)

The obvious analogy to me is the logic that controls what cookies a
browser should accept. Maybe exactly the same rules are appropriate. I
realise that managing those rules using mechanisms like the public
suffix list is not without challenges.

If we accept that these constraints are necessary, then the presence
or absence of DNSSEC signatures doesn't matter. The DoH objects are
within the same security perimeter as the URIs that make use of them
and don't benefit from additional integrity protection; the transport security for all the other objects being sent from server to client
provides the right coverage.


Joe

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000003e71bf057a000cad-- From nobody Tue Nov 6 10:59:58 2018 Return-Path: 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 1D81F130DEF for ; Tue, 6 Nov 2018 10:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 IHMEgCCkOx7F for ; Tue, 6 Nov 2018 10:58:46 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 5F88012F1A5 for ; Tue, 6 Nov 2018 10:58:46 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id t189-v6so11135001itf.1 for ; Tue, 06 Nov 2018 10:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FDBhR2oAIZpqJCjMOW+pZ28Y9JSmuSpBSJtJGLP0ZQc=; b=qORuKIUL3J9CEuF1BYI5IjwH9/6uT1PMPOQpkBOID3WCaRcfzyM/9bNQfqu25LL1lU nG83w99Dcc6PRFriF2MjYKgd+hpOzbWoDRy+bKemjeDWH/T1QrzqlxE1HsKEYrJ8uH7Q xiYk9vxL4oiH6VY6V1FmxcCDNhHP3Yghuhc8CDTuwJehUdXo534NCP7otDPtd7Nteivr tZEwlWBfDeyvYt81yelK4lMAyX4YkviApK+2+7+3ujqwS5st3Iic3HUN8OSN02c2qjjm +fQtg740IAqcINqg5U6iBcIf/fgbsOB1VTzXbWckw4ZAWIEylInsSqLiNN81JK8RAlCD +K9g== 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=FDBhR2oAIZpqJCjMOW+pZ28Y9JSmuSpBSJtJGLP0ZQc=; b=T8r4ExCRPD9PwFVpn/RV1nBwW3/Yjo8rQCZALmrhHYmznGlSV67+Uk02qS9PYbnKZy D1zToA96sZuQki4EiHx4Bbdf3EqtKFKYC2GeNgdiL5jUy+iVzao41BjGuoC5NUfFXaOD a8ZGf7210jnF6ehJWt8ZZtInMrwKp7dFG2NDpMSyi9njfY6dkxoh5pYfUHYc63ygvvTW Fyh5XjkYoN1lJQwh6uS81ue+QWcO9zFli6ltmetOkHil12P0WA4jJc+y8GRzYptOeBN6 xGgltE3h69KckqAiHMBMMWjXRbPzrFcYXBx8k1WgzSeYmk7dqScCVk8+qUUub0PyvrWm 5fvA== X-Gm-Message-State: AGRZ1gLVhlgWpWUA8qqvjPTHlsvEs7U/sWrTMq8SwtdYVWwGhHMnJp0E IMnfPHEabv6Lopf3NBqVfVV2bZM8mnYRar6z+d13Sa32AMSjyw== X-Google-Smtp-Source: AJdET5ctDt1YsOSY2CqQ/B6y3oxcDUr0+Gefz2JwNLTKuEJgwR0b2HyuhiCl7kG3qkBeD0jXFpqofLy8vCGqiaT/lJ8= X-Received: by 2002:a24:5c05:: with SMTP id q5-v6mr3054194itb.70.1541530725322; Tue, 06 Nov 2018 10:58:45 -0800 (PST) MIME-Version: 1.0 References: <20181106102731.GA5280@naina> In-Reply-To: From: Ben Schwartz Date: Tue, 6 Nov 2018 13:58:33 -0500 Message-ID: To: henck=40google.com@dmarc.ietf.org Cc: jabley@hopcount.ca, resolverless-dns@ietf.org, muks@mukund.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000054359e057a0397a0" Archived-At: X-Mailman-Approved-At: Tue, 06 Nov 2018 10:59:57 -0800 Subject: Re: [Doh] [DNSOP] On today's resolverless DNS meeting X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 18:58:50 -0000 --00000000000054359e057a0397a0 Content-Type: multipart/alternative; boundary="0000000000004b77f5057a0397f8" --0000000000004b77f5057a0397f8 Content-Type: text/plain; charset="UTF-8" DOH and dnsop to bcc. On Tue, Nov 6, 2018 at 9:45 AM Justin Henck wrote: > Briefly jumping in to add resolverless-dns@ietf.org, which was set up > after the last meeting for discussion of this specific topic. Direct link: > https://www.ietf.org/mailman/listinfo/resolverless-dns > > I also just sent the notes to that mailing list. > > Justin Henck > Product Manager > 212-565-9811 > google.com/jigsaw > > PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B > > > On Tue, Nov 6, 2018 at 9:39 PM Joe Abley wrote: > >> > On Nov 6, 2018, at 17:27, Mukund Sivaraman wrote: >> > >> > We talked about DNSSEC and certificate signing and such. If the host >> > serving this webpage to the browser has control over the webpage's >> > content (e.g., the contents of that src attribute), and the webpage's >> > contents are already authenticated by TLS, then why does an address >> > record have to be separately authenticated? >> >> I think this is an easy one. It doesn't. >> >> The names that it is permissible for a server to push information >> about (and the names that a client should be allowed to accept) must >> be constrained such that the names supplied for use in one web >> application can't influence the operation of another. >> > I don't see any way to do this in the web security model. For example, if two web applications both use subresources from the same origin, then cookies loaded for that origin from one application will be included in requests to the other. Similarly, subresource cache entries populated by one application will be reused by other applications. Web security is scoped to the domain of each request, not the domain of the page. Additionally, most browsers perform connection coalescing for resources on the same origin, even if the requests are from different tabs. I'm very interested in finding a solution here, but I don't think it will be so simple. For example, there may be a nontrivial interaction with the iframe "sandbox" attribute. Some of these problems become easier if we imagine an https-only world. However, many browser engineers believe that DNS integrity acts as an important barrier to utilization of stolen WebPKI private keys. If you accept this threat model, using unsigned DNS records from untrusted parties could enable more stolen-key attacks. There is a complex intersection of web and DNS problems, and IMHO too speculative for dnsop (and out of scope for doh's current charter), so I would encourage interested parties to join the resolverless-dns list. (For example, it would be bad if some generic and otherwise benign web >> page could feed the browser high-TTL DNS messages for names under >> online retailer domains that accept credit cards or component APIs >> used within genuine web apps.) >> >> The obvious analogy to me is the logic that controls what cookies a >> browser should accept. Maybe exactly the same rules are appropriate. I >> realise that managing those rules using mechanisms like the public >> suffix list is not without challenges. >> >> If we accept that these constraints are necessary, then the presence >> or absence of DNSSEC signatures doesn't matter. The DoH objects are >> within the same security perimeter as the URIs that make use of them >> and don't benefit from additional integrity protection; the transport >> security for all the other objects being sent from server to client >> provides the right coverage. >> >> >> Joe >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000004b77f5057a0397f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
DOH and dnsop to bcc.

On Tue, Nov 6, 2018 at 9:45 AM Justin Henck <henck=3D40google.com@dmarc.ietf.org&= gt; wrote:
Briefly jumping in to add resolverless-dns@ietf.org, whi= ch was set up after the last meeting for discussion of this specific topic.= =C2=A0 Direct link: https://www.ietf.org/mailman/listinfo/resolve= rless-dns

I also just sent the notes to that mailing list.

Jus= tin Henck=C2=A0
Product Manager=C2=A0
212-565-9811=C2=A0
google.com/jigsaw

PGP: EA8E 8C27 2D75 974D B357= 482B 1039 9F2D 869A 117B
=


On Tue, Nov 6, 2018 at 9:39 PM Joe = Abley <jabley@ho= pcount.ca> wrote:
> On = Nov 6, 2018, at 17:27, Mukund Sivaraman <muks@mukund.org> wrote:
>
> We talked about DNSSEC and certificate signing and such. If the host > serving this webpage to the browser has control over the webpage's=
> content (e.g., the contents of that src attribute), and the webpage= 9;s
> contents are already authenticated by TLS, then why does an address > record have to be separately authenticated?

I think this is an easy one. It doesn't.

The names that it is permissible for a server to push information
about (and the names that a client should be allowed to accept) must
be constrained such that the names supplied for use in one web
application can't influence the operation of another.
<= /div>

I don't see any way to do this in= the web security model.=C2=A0 For example, if two web applications both us= e subresources from the same origin, then cookies loaded for that origin fr= om one application will be included in requests to the other.=C2=A0 Similar= ly, subresource cache entries populated by one application will be reused b= y other applications.=C2=A0 Web security is scoped to the domain of each re= quest, not the domain of the page.=C2=A0 Additionally, most browsers perfor= m connection coalescing for resources on the same origin, even if the reque= sts are from different tabs.

I'm very interest= ed in finding a solution here, but I don't think it will be so simple.= =C2=A0 For example, there may be a nontrivial interaction with the iframe &= quot;sandbox" attribute.

Some of these proble= ms become easier if we imagine an https-only world.=C2=A0 However, many bro= wser engineers believe that DNS integrity acts as an important barrier to u= tilization of stolen WebPKI private keys.=C2=A0 If you accept this threat m= odel, using unsigned DNS records from untrusted parties could enable more s= tolen-key attacks.

There is a complex intersection= of web and DNS problems, and IMHO too speculative for dnsop (and out of sc= ope for doh's current charter), so I would encourage interested parties= to join the resolverless-dns list.

(For example, it would be bad if some generic and otherwise benign web
page could feed the browser high-TTL DNS messages for names under
online retailer domains that accept credit cards or component APIs
used within genuine web apps.)

The obvious analogy to me is the logic that controls what cookies a
browser should accept. Maybe exactly the same rules are appropriate. I
realise that managing those rules using mechanisms like the public
suffix list is not without challenges.

If we accept that these constraints are necessary, then the presence
or absence of DNSSEC signatures doesn't matter. The DoH objects are
within the same security perimeter as the URIs that make use of them
and don't benefit from additional integrity protection; the transport security for all the other objects being sent from server to client
provides the right coverage.


Joe

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000004b77f5057a0397f8-- --00000000000054359e057a0397a0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMYJWDwudxwNjwu8B4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MTAxNDA4MjIxMloXDTE5MDQx MjA4MjIxMlowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCjAFK2jxl2SbwdLgmpNj92zrqk75pYCWjsHhvdBpOYu7YqUel7 tZEj5mGxVhKL8jbTW9bEM/iB1XBfK+JjPXV+WADiV+9+yRRDRugD0oy5iTiEFNVATSd4G5Su+lfw aCM7aa4opbbXPkehb7Gkx3zks54gj2F5KH7dvmvMdAVZuH6Ff4TnUkzolgu/llEzjYArUXHDaAR4 WE02VO3FbyLV97Y68Z3gtHbzsyAOXK6hjLiVwGBTaWaApt9i+d0jR0SDWClPDyK3Vq3QhLVpewN8 bRR1rb72UKt2an3n95SrvbhD639vfyy/cHR09HxDXXlTfyugAk0kYIQiqwS1X74zAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFDPcHr72CmAhHX2sPCeQbgmPbXZWMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQATQwVzUhwG45UvRH44 Ls0IDXKJb9GVoZurKcd19M1EtjywGT6ZfFDW1DenoGaf/gizTDc0dHMLV79yXlj6yLtsDkP6rb7f zOyczFMqHbXRXT9YDJlPcOrtp3E2wA/HHph+nimVhrmfcGMndO5AV2DzTD2oOQe5C/mh9RUT5z6/ CrUQ0dAaBZweRC8agj/PQ4Jnen/kqDBE/TgK0ChQ7Q44MkuENG0dp2bPuHG7ZPKkqZ2V5LGhrba4 c4MtQvK9dyNE8urDPL70ogUS3pwBvfui1H1gbHJwe3npqkBvuqswxS7IvDmW88A1wGeWt/02LLQP ysd6YM+XWMe3rBB1zzJDMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMYJWDwudx wNjwu8B4MA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDUbWXzdb6/wUsxZfq47lNK 1ggSu8aJGAajA+BUw3/kJjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODExMDYxODU4NDVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAWt7SWm2t/BE1b7TeUXuiOyOllnNNrIvtEi2vQdYi 2NLZ6zIzVuZEx2d2iJC69pjwR2sgiN16//hpT/kvv3NyeIDN+JU9RijOtvkea3Qj8/Y0R94x8XdT TELs1IBOvwvXbZQrVk7X9VtU/LLd2hT99lZoNVKLjSGV5t2iaLgQ7+ehZWts97couJxOhLvVoRSK Uubt9yFifKi5/WR8zusQ2patd2/JFTCdFL0Sao3YjxDVDk18z2fPNPanow8TcvyV2zay7qEIGKdP Xs/4LueZ+QJ35dcVTxvKTM8qppqvcPVyFOCKDGpFHyZWLYI+4Zr/QSWmK0ihz0oBzDTbsIaQEA== --00000000000054359e057a0397a0-- From nobody Wed Nov 7 03:49:16 2018 Return-Path: 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 74E1812F295 for ; Wed, 7 Nov 2018 03:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 INbTfUDKZANj for ; Wed, 7 Nov 2018 03:48:59 -0800 (PST) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 01064130DDF for ; Wed, 7 Nov 2018 03:48:58 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:42808) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gKMKP-000mN7-LN (Exim 4.91) for doh@ietf.org (return-path ); Wed, 07 Nov 2018 11:48:57 +0000 Date: Wed, 7 Nov 2018 11:48:57 +0000 From: Tony Finch To: doh@ietf.org Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Doh] notes on CORS and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 11:49:09 -0000 I've amended my `doh101` implementation to support cross-origin requests from browsers. https://github.com/fanf2/doh101/ DoH GET requests count as "simple requests" from the point of view of CORS, so they do not require any special support on the server to be available to any web page. However, because query strings are usually logged by web servers, DoH GET requests have somewhat worse privacy properties than POST requests. So it seemed to be worth implementing CORS, so that POST is available wherever GET is. What I've done is add `Access-Control-Allow-Origin: *` to regular DoH responses, and I added support for OPTIONS requests which reply with: Access-Control-Allow-Origin: * Access-Control-Allow-Methods: OPTIONS, HEAD, GET, POST Access-Control-Allow-Headers: Content-Type Access-Control-Max-Age: 86400 It's roughly in line with what Cloudflare does for https://cloudflare-dns.com/dns-query (Except I'm using a longer method list which matches what I return for 405 method not allowed errors.) I've had a very brief look at some of the DoH servers listed at https://github.com/curl/curl/wiki/DNS-over-HTTPS#doh-tools and CORS support seems to be relatively rare. Tony. -- f.anthony.n.finch http://dotat.at/ Fisher, German Bight: Southeast 5 to 7, veering south or southwest 4 or 5. Moderate or rough. Showers. Good occasionally poor. From nobody Wed Nov 7 04:23:34 2018 Return-Path: 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 7529D12D4F0 for ; Wed, 7 Nov 2018 04:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 SIQnAFXoSqxT for ; Wed, 7 Nov 2018 04:23:30 -0800 (PST) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05olkn0810.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe50::810]) (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 6ACF1130E6A for ; Wed, 7 Nov 2018 04:23:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZDkEs74nC5GPSDmMyt8ZchTxxkqNa3lDlMha0KLvOVc=; b=YBP+N55Mb5zMXnHhyCVeO220KfdxXZmB62kReXWOMbnN5v85Kqf6T1Q8tlJfvxQ+tbmjRG3gFwL32y1/DVzxJXoV2rq6ppupZiDrJSadl1WCH2YFDN45bVMk+aYHhZ+qL+hCPwSunUUvXmgl7Y35tEVzrBaIXYDeDPGrfGHBI+Ohiy3dLPV+w+eY/NKQtU7ueHCv5P6kEwZwX17xDa/AdgDRanrUKTSDpwGbOEDRidCHdAaaE/bdVY3ykZfdcWaubeuCq0wBoIb3p4j/xYyz0Tl+ulY+Ct3xsx5k+uuRMwoIYH8TKlJ7GZnPqgsfVCovzv/b4qAAmg7MeC2Pw7Ymig== Received: from CO1NAM05FT062.eop-nam05.prod.protection.outlook.com (10.152.96.53) by CO1NAM05HT215.eop-nam05.prod.protection.outlook.com (10.152.97.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.3; Wed, 7 Nov 2018 12:23:28 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.96.56) by CO1NAM05FT062.mail.protection.outlook.com (10.152.96.180) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.3 via Frontend Transport; Wed, 7 Nov 2018 12:23:28 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c46c:9463:1bae:42e5]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c46c:9463:1bae:42e5%2]) with mapi id 15.20.1294.034; Wed, 7 Nov 2018 12:23:28 +0000 From: Star Brilliant To: Tony Finch , "doh@ietf.org" Thread-Topic: [Doh] notes on CORS and DoH Thread-Index: AQHUdo/6Seld3kdaBEW71lr6fOzovaVEPAmx Date: Wed, 7 Nov 2018 12:23:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:0352FD9D4C6B0F5DB95F690DD983036DA99C321AAE0C733E10746EF8BCDC17CF; UpperCasedChecksum:206F56651FEABB14D874672E417A4CB78DE4AE1438BC7F257A23C267A7DDAA02; SizeAsReceived:7093; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [8p8e5lwq1O1pbN+wwNB8BZiL6ol25bW3KAACOfisFuvf6jBjKA0d6A==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM05HT215; 6:yTtWVOm+VOP1gzY9xnIE3zj1Ava2MUDNlHHJ4q/UQyPK5/3ywxSpMspR4W/6eKmlFHNboQMgqkXcHLu9LZeKZPSsczVTsr5kKUvs4SsylD72QT7KLl3F0CVs3SoU/trjZvT6dOAWSIZ6AMxf8wlbQQO4Qr+RMsgdcXLIw94gKovl5Psp/wnR23iciooqg5k7isS3XkrxrgJTbgsWmphAXQNg0Yy0m1lBF0NqogS+Pn+OFFTYD1+vCF+bnvJUjmrq8Ix3gF0apCzSHIjVU0SjYp6m5i0TF5iKZfxfB13RaPIo+qZSFPn9ZGeaiICAUIQCVg09jo5VPJPJxsPq8tDWUWk9jKPmh7kVuInzbzt8hMSRxCYQZX6qpOC+8frd+7FLYO5W2hhkKGUfXAnzjAyz2U/GcfszkaFrnZtMZBqTTaGw4I0DpzXY4Ywykk5fq7N5znZFX6b8908TaFCrZl60nA==; 5:wEAFx101BRtk8mj3Mrp5XV0YE3RxizdbKFm4LzReMuLN6PZ6mNNiKWtFfKfpwC/Yn27syefqxOLSQ42b23JMY+HTY7Pb5wQ7py0MOila5Q5CTApUJLKvKUwnWvM5YBsbadYad8Ots4ojEM116qN+IgpBeYI981Z6rtYe7sYHGwM=; 7:UCiP+wbwbjApA+wt7V7zU6+ur3ZFmF8uhKius4fteHt1rzodVKfUIkxg/FvGtleptqRgveVKdKUtEyU7zzbGPIwnCsO0R00y1+ZKU4vEF+zCWN/8TfZjnSETh2JMjqUR9KBKHgIZzitC6xkQqvt1Lw== x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:CO1NAM05HT215; x-ms-traffictypediagnostic: CO1NAM05HT215: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:CO1NAM05HT215; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM05HT215; x-microsoft-antispam-message-info: FBqL0FaThUAckem0IQFfUYFBJbehGBPTtK3sENrshnqFMQeJXkpKRPAbwbsCr5bx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: a4ec6c8a-0253-4803-b2a5-08d644abd28f X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2018 12:23:28.1472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM05HT215 Archived-At: Subject: Re: [Doh] notes on CORS and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 12:23:32 -0000 On Wed, Nov 7, 2018 at 7:49 PM Tony Finch wrote:=0A= >=0A= > I've amended my `doh101` implementation to support cross-origin requests= =0A= > from browsers.=0A= >=0A= > https://github.com/fanf2/doh101/=0A= >=0A= > DoH GET requests count as "simple requests" from the point of view of=0A= > CORS, so they do not require any special support on the server to be=0A= > available to any web page. However, because query strings are usually=0A= > logged by web servers, DoH GET requests have somewhat worse privacy=0A= > properties than POST requests. So it seemed to be worth implementing CORS= ,=0A= > so that POST is available wherever GET is.=0A= >=0A= > What I've done is add `Access-Control-Allow-Origin: *` to regular DoH=0A= > responses, and I added support for OPTIONS requests which reply with:=0A= >=0A= > Access-Control-Allow-Origin: *=0A= > Access-Control-Allow-Methods: OPTIONS, HEAD, GET, POST=0A= > Access-Control-Allow-Headers: Content-Type=0A= > Access-Control-Max-Age: 86400=0A= >=0A= > It's roughly in line with what Cloudflare does for=0A= > https://cloudflare-dns.com/dns-query=0A= > (Except I'm using a longer method list which matches what I return=0A= > for 405 method not allowed errors.)=0A= >=0A= > I've had a very brief look at some of the DoH servers listed at=0A= > https://github.com/curl/curl/wiki/DNS-over-HTTPS#doh-tools=0A= > and CORS support seems to be relatively rare.=0A= >=0A= > Tony.=0A= > --=0A= > f.anthony.n.finch http://dotat.at/=0A= > Fisher, German Bight: Southeast 5 to 7, veering south or southwest 4 or 5= .=0A= > Moderate or rough. Showers. Good occasionally poor.=0A= =0A= =0A= Hello Tony,=0A= =0A= Thank you for your reminder!=0A= =0A= I also amended my implementation [1]. The code is pending to be released be= fore I test it through-out.=0A= =0A= I consider there are no security issues with CORS.=0A= But, does the browser-side cache work for a single URL or a whole site? Wil= l it be a problem if a DoH server shares the same hostname with another web= site?=0A= =0A= Best regards,=0A= StarBrilliant=0A= =0A= [1]: https://github.com/m13253/dns-over-https/commit/4754aa0414840349dc22a1= 1b954d5f2c8243cf00= From nobody Wed Nov 7 05:40:12 2018 Return-Path: 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 09EB7128CF2 for ; Wed, 7 Nov 2018 05:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 K6D43TrYFn_Y for ; Wed, 7 Nov 2018 05:40:08 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 BA4CD1274D0 for ; Wed, 7 Nov 2018 05:40:08 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:59116) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gKO3x-000HVJ-0p (Exim 4.91) (return-path ); Wed, 07 Nov 2018 13:40:05 +0000 Date: Wed, 7 Nov 2018 13:40:05 +0000 From: Tony Finch To: Star Brilliant cc: "doh@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Doh] notes on CORS and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 13:40:12 -0000 Star Brilliant wrote: > But, does the browser-side cache work for a single URL or a whole site? > Will it be a problem if a DoH server shares the same hostname with > another website? Good question: it isn't super clear from the MDN docs. But on further investigation I see the Fetch spec says it's per URL: https://fetch.spec.whatwg.org/#concept-cache [ I was wondering what to set the max-age to, and randomly chose 1 day which happens to be the same as the cap applied by Firefox. Cloudflare set their max-age to 1 week. ] Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: South or southwest 5 to 7, increasing gale 8 at times. Very rough, becoming high. Rain or thundery showers. Poor. From nobody Wed Nov 7 17:20:51 2018 Return-Path: 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 4584D130E76 for ; Wed, 7 Nov 2018 17:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=a2Ig32H/; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=LmaMmH5+ 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 fHoQLeOnhEA9 for ; Wed, 7 Nov 2018 17:20:39 -0800 (PST) Received: from outbound1a.ore.mailhop.org (outbound1a.ore.mailhop.org [54.213.22.21]) (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 0906D130E8D for ; Wed, 7 Nov 2018 17:20:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541640038; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=E9VfC4fDNbJCihd3lmYY7N2eqgYyFQj8UDKghUNm5VkefM71yBSKcWEAh0eY857sFQs4/+Zjc+Esp XTsj7S2bTsh8YLE6dJN+QqU8XvraIExnfekc3Ti56koWyP2MfkTdtnuIjVTQ5TY1iBbUnoICO5PcZd k5kC5Lg8Yq+jlKSun9fSI/iDWTWT6JxTDxNBdPOGaLeqeJ1H8ZgnzMxGdduGhb0OMcL19+OmM7Flq5 UAOnPHFSoEAY1p0cd50wgi/DAZuOLaSsAuJ7a6/V73bBt2rMo+NheCBp2vvNYgxp1pnCEbR+Pb30pr +WA+J6N9UpFyWm5l+iY27IO+iSqjKXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=2/DZ36PjKX6IUBaDt3SraPp7PBKB2C174P/AuyxvWVE=; b=OcKd9QHyZEYWC3ZnA24bv7dF846cfQwCcsAOz6YEmkwKlRCVUuhIK0I4kGn5ADZ/40rOdqWkFEg+v B3pfNS2b6ZqQYIUm65OTa53CiS2wOoubI4qbOjkmUBZYCmwFaTm4D1/GTmW2PRQrYCY0B+zQsEwFNj pGRrnGB5EV/h2Tec7vtLl2r9hwSFh8d4nWB3pSR8PzNlMeGBC2UhTGL2T6NBdutJoQHmYXVzKfrqWX HEFJrj7j6NJU1kOA8uXuGYOHq0+d7QLuZ+3uJwjMPt80rvuaQsSV+Ng5CKCJMOcTUBGCIlXHgmfKZ6 krPuPit8amHbKIutk0VwGGfYXYWcJFA== ARC-Authentication-Results: i=1; outbound1.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.42; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=2/DZ36PjKX6IUBaDt3SraPp7PBKB2C174P/AuyxvWVE=; b=a2Ig32H/SuLNK/VRV2JN+avyPLR/cgaimNvtRHdkpNEN1oZ3qaVIjOTDfCOwULNigFwAIMyfmPeD6 0PNL6Chv8x1EF2uC5OVjlzjSCzwCYXohaBzpk69vtabj3o4bgBnhbd1t8uRjdBsh7BC8arK8lEXv1i uQE0xUxytsXEnlb0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=2/DZ36PjKX6IUBaDt3SraPp7PBKB2C174P/AuyxvWVE=; b=LmaMmH5+NvVDPsuPwpCEO9q7Vq1Dbs5Jo59LWMH02kPAmtZvuvYTB2mKJj67j/U79yDEnUll/DGTy tV+zAvf4lf/mrNB4O8iDS7scoRFBwVe631OtZNMyB8jLK5JGucgwIcEjQAkp5OnTj/lZOE4QZiVZX0 8P40Xu7bfRDEBGS0ZkSl8l9t1irooKIsX+PHrlZ8zXQ3bLYVKmuq579y8wQWTf+U707uSuu7UKw/Os dWqf4TWoV47lSNa1oVZ8aXNwiAOe+PglwOTSmfGe2nyoA9fQe/lYaS83sMeTsgVgs3qrGKUi/nP3i6 99qEQNu5LfJYSBmKtbCHT5UKsufqprQ== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 7f56b5df-e2f4-11e8-a93b-310333596487 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.42 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f42.google.com (unknown [209.85.210.42]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 7f56b5df-e2f4-11e8-a93b-310333596487; Thu, 08 Nov 2018 01:20:37 +0000 (UTC) Received: by mail-ot1-f42.google.com with SMTP id k9so16660728otl.10 for ; Wed, 07 Nov 2018 17:20:37 -0800 (PST) X-Gm-Message-State: AGRZ1gK/1D2opcMKj0w798EcCqaZF8bTyEQ8yi+3kRbNIaP/4Lpl0ukW 3qmVkQvs96O60GMV3bEks4WnT87jyKtmUJAQQ2A= X-Google-Smtp-Source: AJdET5cyZudIGsEzKozL2u9gXq9Napd7oYDIsenm5BCYX/P7N+kvieFwRy8kj7sthwFAlXJ+h57G59E8VIuK8G41kIA= X-Received: by 2002:a9d:7654:: with SMTP id o20mr576814otl.295.1541640036911; Wed, 07 Nov 2018 17:20:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Thu, 8 Nov 2018 08:20:23 +0700 X-Gmail-Original-Message-ID: Message-ID: To: Star Brilliant Cc: Tony Finch , DoH WG Content-Type: multipart/alternative; boundary="000000000000c59080057a1d0afe" Archived-At: Subject: Re: [Doh] notes on CORS and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 01:20:50 -0000 --000000000000c59080057a1d0afe Content-Type: text/plain; charset="UTF-8" > > I consider there are no security issues with CORS. > But, does the browser-side cache work for a single URL or a whole site? cors granularity is a little finer than per url (you salt the url with credentials, method, etc..) > Will it be a problem if a DoH server shares the same hostname with another > website? > not for cors, and generally not at all. There's nothing wrong with multiple doh servers (with multiple resoltuion policies) sharing the same origin. There are a couple things that apply site-wide in http, but very few. (hsts for example.) > > Best regards, > StarBrilliant > > [1]: > https://github.com/m13253/dns-over-https/commit/4754aa0414840349dc22a11b954d5f2c8243cf00 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --000000000000c59080057a1d0afe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


I consider there are no security issues with CORS.
But, does the browser-side cache work for a single URL or a whole site?

cors granularity is a little finer than per ur= l (you salt the url with credentials, method, etc..)
=C2=A0
=
Will it be a problem if a DoH server shares= the same hostname with another website?

not for cors, and generally not at all. There's nothing wrong with mu= ltiple doh servers (with multiple resoltuion policies) sharing the same ori= gin.

There are a couple things that apply site-wid= e in http, but very few. (hsts for example.)
=C2=A0

Best regards,
StarBrilliant

[1]: https:/= /github.com/m13253/dns-over-https/commit/4754aa0414840349dc22a11b954d5f2c82= 43cf00
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

--000000000000c59080057a1d0afe-- From nobody Mon Nov 19 02:10:09 2018 Return-Path: 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 5DB5B129C6B for ; Mon, 19 Nov 2018 02:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 EbgWS-pRU7R2 for ; Mon, 19 Nov 2018 02:10:05 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DA212F1A5 for ; Mon, 19 Nov 2018 02:10:05 -0800 (PST) Received: from server.ds9a.nl (ip565244ed.adsl-surfen.hetnet.nl [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id AE76C9FD6E for ; Mon, 19 Nov 2018 10:09:54 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 81DA8ACA4A1; Mon, 19 Nov 2018 11:09:54 +0100 (CET) Date: Mon, 19 Nov 2018 11:09:54 +0100 From: bert hubert To: doh@ietf.org Message-ID: <20181119100954.GA6704@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Doh] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 10:10:07 -0000 Hi everyone, Now that we are still here, perhaps some work is left for us, but I'm not sure. I've observed that the thousands of users of doh.powerdns.org (I also do not know how this happened) take around 22 packets per DNS query/response. Larger scale adoption of TLSv1.3 might improve this somewhat, but it is a big number. I've also personally observed that a "slightly suboptimal" network absolutely kills browsing performance in Firefox Nightly using DoH. A naive calculation shows that 0.5% packet loss turns into a 5% failure rate per DoH query, which then can cause Head of Line blocking for further queries, which cascades into "blank pages" getting rendered. Of course, once we have HTTP/3, DNS over HTTP/3 would suffer way less from incidental packet loss, and in general there would be a lot less packets too. My question now is, is there any specific work to be done for DoH/3? Are there number, priorities, features you'd want or not want to use to make things work well? In other words, to the sound of a groaning camel, do we need a draft? Or a section in the HTTP/3 I-D? And, perhaps somewhat more provocatively, should we maybe not start pushing DoH/2 if it leaves people with a sub-standard experience, causing them to disable DoH? DoH/3 might be somewhat of a wait but it might prevent that sour taste from developing. I'd love to hear your thoughts! Bert From nobody Mon Nov 19 03:01:08 2018 Return-Path: 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 59F31127133 for ; Mon, 19 Nov 2018 03:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 f_0vPLjf7rBJ for ; Mon, 19 Nov 2018 03:01:05 -0800 (PST) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFD5126CB6 for ; Mon, 19 Nov 2018 03:01:05 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id 9951F5F40AFC; Mon, 19 Nov 2018 12:01:04 +0100 (CET) Received: from [172.19.153.200] (p4FC21989.dip0.t-ipconnect.de [79.194.25.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 9F0085F40310; Mon, 19 Nov 2018 12:01:02 +0100 (CET) From: "Ralf Weber" To: "bert hubert" Cc: doh@ietf.org Date: Mon, 19 Nov 2018 12:01:01 +0100 X-Mailer: MailMate (1.12.1r5552) Message-ID: <2A4EC6B6-4654-4CD2-BAB3-6299E1A65AEB@fl1ger.de> In-Reply-To: <20181119100954.GA6704@server.ds9a.nl> References: <20181119100954.GA6704@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Doh] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 11:01:08 -0000 Moin! On 19 Nov 2018, at 11:09, bert hubert wrote: > I've observed that the thousands of users of doh.powerdns.org (I also > do not > know how this happened) take around 22 packets per DNS query/response. Wow. Good for manufactures of 10GB ethernet cards ;-). > Larger scale adoption of TLSv1.3 might improve this somewhat, but it > is a > big number. > > I've also personally observed that a "slightly suboptimal" network > absolutely kills browsing performance in Firefox Nightly using DoH. A > naive > calculation shows that 0.5% packet loss turns into a 5% failure rate > per DoH > query, which then can cause Head of Line blocking for further queries, > which > cascades into "blank pages" getting rendered. Hmm doh.powerdns.org resolves to one IP address while mozilla.cloudflare-dns.com resolves to two IP addresses. Not sure if that would make a difference as I don’t know what the Mozilla stub does. I also didn’t find anything in the RFC wrt to the failure/failover behaviour other than DoH follows standard HTTP mechanisms, but I have no idea what that means for unresponsive servers, and more important when a server is declared unresponsive. […] > And, perhaps somewhat more provocatively, should we maybe not start > pushing > DoH/2 if it leaves people with a sub-standard experience, causing them > to > disable DoH? DoH/3 might be somewhat of a wait but it might prevent > that > sour taste from developing. Maybe there is a need for dohop (DNS over HTTP Operations) working group. I think there are still a lot of unknowns in the operations of DoH clients and servers, but the same is true for regular DNS and I’ve been working on that for decades now. Maybe a draft or some measurements would also help to get a discussion started. So long -Ralf —-- Ralf Weber From nobody Mon Nov 19 06:12:25 2018 Return-Path: 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 CE615130DC8 for ; Mon, 19 Nov 2018 06:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 klIG4Bgy2ebA for ; Mon, 19 Nov 2018 06:12:22 -0800 (PST) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1111012008A for ; Mon, 19 Nov 2018 06:12:22 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 19 Nov 2018 06:12:20 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Mon, 19 Nov 2018 06:12:19 -0800 From: Paul Hoffman To: bert hubert CC: "doh@ietf.org" Thread-Topic: [Ext] [Doh] DNS over HTTP/3? Thread-Index: AQHUf/AQSCvsgY2gXkOTrPQmqQiX0aVXqf4A Date: Mon, 19 Nov 2018 14:12:18 +0000 Message-ID: <5BE15B68-1C61-4462-AE84-901E2CF0F9F9@icann.org> References: <20181119100954.GA6704@server.ds9a.nl> In-Reply-To: <20181119100954.GA6704@server.ds9a.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_97356FDC-D7A0-4123-AE66-26FF72674864"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 14:12:24 -0000 --Apple-Mail=_97356FDC-D7A0-4123-AE66-26FF72674864 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 19, 2018, at 2:09 AM, bert hubert = wrote: >=20 > Hi everyone, >=20 > Now that we are still here, perhaps some work is left for us, but I'm = not > sure.=20 >=20 > I've observed that the thousands of users of doh.powerdns.org (I also = do not > know how this happened) take around 22 packets per DNS query/response.=20= It would be valuable to know if this is this because your DoH server = kills the entire connection after every DNS query, or because the = clients are doing so. > Larger scale adoption of TLSv1.3 might improve this somewhat, but it = is a > big number. DoH was designed for long-lived connections, so the number would = normally be smaller after the initial connection. > I've also personally observed that a "slightly suboptimal" network > absolutely kills browsing performance in Firefox Nightly using DoH. A = naive > calculation shows that 0.5% packet loss turns into a 5% failure rate = per DoH > query, which then can cause Head of Line blocking for further queries, = which > cascades into "blank pages" getting rendered.=20 When you say "naive calculation", do you mean this is observed in the = clients hitting your DoH server? That would indeed be scary. However, = the Mozilla numbers tell a very different story. It would be good to = know which one is true. > Of course, once we have HTTP/3, DNS over HTTP/3 would suffer way less = from > incidental packet loss, and in general there would be a lot less = packets > too. >=20 > My question now is, is there any specific work to be done for DoH/3? = Are > there number, priorities, features you'd want or not want to use to = make > things work well? DoH is just a specification for how to do a normal HTTP interaction, so = there should be litter or no changes to DoH if the transport under HTTP = changes. We'll know more when HTTP/3 is finished, but probably not = before then. > In other words, to the sound of a groaning camel, do we need a draft? = Or a > section in the HTTP/3 I-D? We might, but we can't tell now. > And, perhaps somewhat more provocatively, should we maybe not start = pushing > DoH/2 if it leaves people with a sub-standard experience, causing them = to > disable DoH? If the implementations on the client or server side make using DoH bad, = those implementations should be fixed. If they don't get fixed, we'll = certainly hear about it. > DoH/3 might be somewhat of a wait but it might prevent that > sour taste from developing. Without sufficient data, it's hard to say if there really is a sour = taste. --Paul Hoffman= --Apple-Mail=_97356FDC-D7A0-4123-AE66-26FF72674864 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTExOTE0MTIxOVowIwYJKoZIhvcNAQkEMRYEFI1/HvrFwIRcGGFGNv/tUpQ27sFiMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQANGhTzKTjMUXpUVcxGLhYLAhPArRYKnoiKVv8Dw5itmNCc7AmFtRJHsW4cb0IWqQJx7BFy chueoQRqNQs8SkE1JSC698fc8KifX0TTWckqzmyYr5S6l5X8w0qTyKH7IVzEholHRbgx9xoEdc4z XRNCwjvae7r5MocYHE70nGjHCmkiIQAXzCCJBta/S9gs+Q4sTF4YxMCP8mpv0tintFoO42CNLZJu wPTa2P2w/hkREW77JhEbspr/Apspw6QiNY5C4BPCMyt13DCuq+mZnIHc5Yb8MhRGv7/xX4NGtcWM zazFoAzFdf3wphHCHcELZglGSJAwHMtv4FMF8LfcvziEAAAAAAAA --Apple-Mail=_97356FDC-D7A0-4123-AE66-26FF72674864-- From nobody Mon Nov 19 07:02:27 2018 Return-Path: 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 1A203130DC9 for ; Mon, 19 Nov 2018 07:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 GjMX_nnWEP4w for ; Mon, 19 Nov 2018 07:02:24 -0800 (PST) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) (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 D50E71286E7 for ; Mon, 19 Nov 2018 07:02:23 -0800 (PST) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id wAJF2Kh1002811 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Nov 2018 16:02:20 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id wAJF2Jlu002804; Mon, 19 Nov 2018 16:02:19 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Mon, 19 Nov 2018 16:02:19 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: bert hubert cc: doh@ietf.org In-Reply-To: <20181119100954.GA6704@server.ds9a.nl> Message-ID: References: <20181119100954.GA6704@server.ds9a.nl> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Doh] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 15:02:26 -0000 On Mon, 19 Nov 2018, bert hubert wrote: > I've also personally observed that a "slightly suboptimal" network > absolutely kills browsing performance in Firefox Nightly using DoH. A naive > calculation shows that 0.5% packet loss turns into a 5% failure rate per DoH > query, which then can cause Head of Line blocking for further queries, which > cascades into "blank pages" getting rendered. Isn't this mostly because it uses (multiplexing over) TCP and TLS? Meaning that DoT will basically see roughly the same degredation? (And regarding "blank pages", that's also a matter of what the browser/user-agnes does or doesn't do when it gets DoH timeouts...) -- / daniel.haxx.se From nobody Mon Nov 19 07:12:23 2018 Return-Path: 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 7EE49130E11 for ; Mon, 19 Nov 2018 07:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 q3m8f6ua806p for ; Mon, 19 Nov 2018 07:12:12 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B371130DE1 for ; Mon, 19 Nov 2018 07:12:11 -0800 (PST) Received: from server.ds9a.nl (ip565244ed.adsl-surfen.hetnet.nl [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id DCE1F9FD6E; Mon, 19 Nov 2018 15:12:09 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 4878AACA4B3; Mon, 19 Nov 2018 16:12:09 +0100 (CET) Date: Mon, 19 Nov 2018 16:12:09 +0100 From: bert hubert To: Paul Hoffman Cc: "doh@ietf.org" Message-ID: <20181119151209.GC11506@server.ds9a.nl> References: <20181119100954.GA6704@server.ds9a.nl> <5BE15B68-1C61-4462-AE84-901E2CF0F9F9@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BE15B68-1C61-4462-AE84-901E2CF0F9F9@icann.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] [Ext] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 15:12:22 -0000 On Mon, Nov 19, 2018 at 02:12:18PM +0000, Paul Hoffman wrote: > > I've observed that the thousands of users of doh.powerdns.org (I also do not > > know how this happened) take around 22 packets per DNS query/response. > > It would be valuable to know if this is this because your DoH server kills > the entire connection after every DNS query, or because the clients are > doing so. It does around 2 DNS queries per HTTPS connection on average dnsdist-doh keeps open an HTTP/2 connection for 10 seconds if it becomes idle. > > Larger scale adoption of TLSv1.3 might improve this somewhat, but it is a > > big number. > > DoH was designed for long-lived connections, so the number would normally be smaller after the initial connection. I can only report what I measure based on several thousands of users. > > I've also personally observed that a "slightly suboptimal" network > > absolutely kills browsing performance in Firefox Nightly using DoH. A naive > > calculation shows that 0.5% packet loss turns into a 5% failure rate per DoH > > query, which then can cause Head of Line blocking for further queries, which > > cascades into "blank pages" getting rendered. > > When you say "naive calculation", do you mean this is observed in the > clients hitting your DoH server? That would indeed be scary. However, > the Mozilla numbers tell a very different story. It would be good to know > which one is true. My personal observation is that on a slightly bad network, turning off DoH speeds up things massively and makes the web useable again. This naively makes sense, DoH uses way more packets and suffers from Head of Line blocking, unlike plain DNS. We have asked Mozilla to provide more details of their measurements, but these have not been forthcoming. Note that the graph published on the blog misses the 95% and 99% bins, https://blog.nightly.mozilla.org/files/2018/08/DNS-over-HTTPS-Performance-Improvement.png and does not include details on timeouts. > > And, perhaps somewhat more provocatively, should we maybe not start pushing > > DoH/2 if it leaves people with a sub-standard experience, causing them to > > disable DoH? > > If the implementations on the client or server side make using DoH bad, > those implementations should be fixed. If they don't get fixed, we'll > certainly hear about it. There is already a Firefox ticket I think, but with Patrick and Daniel gone or gone soon, I am not sure who owns it now > > DoH/3 might be somewhat of a wait but it might prevent that > > sour taste from developing. > > Without sufficient data, it's hard to say if there really is a sour taste. Perhaps Mozilla can clarify further what they measured beyond the 7 milliseconds slowdown. I may do some induced packetloss experiments to see if the "experience" can be reproduced. Bert From nobody Mon Nov 19 07:39:23 2018 Return-Path: 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 0CE62130DD3 for ; Mon, 19 Nov 2018 07:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 M1hSzo3cMhh5 for ; Mon, 19 Nov 2018 07:39:19 -0800 (PST) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F84A130DD8 for ; Mon, 19 Nov 2018 07:39:19 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 19 Nov 2018 07:39:17 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Mon, 19 Nov 2018 07:39:17 -0800 From: Paul Hoffman To: bert hubert CC: "doh@ietf.org" Thread-Topic: [Doh] [Ext] DNS over HTTP/3? Thread-Index: AQHUgBpJDcHiU7C9TEuONF//QgGdoaVXwfYA Date: Mon, 19 Nov 2018 15:39:16 +0000 Message-ID: References: <20181119100954.GA6704@server.ds9a.nl> <5BE15B68-1C61-4462-AE84-901E2CF0F9F9@icann.org> <20181119151209.GC11506@server.ds9a.nl> In-Reply-To: <20181119151209.GC11506@server.ds9a.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_F1A79C9B-90F8-480D-8DF8-28D559885D5B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 15:39:22 -0000 --Apple-Mail=_F1A79C9B-90F8-480D-8DF8-28D559885D5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 19, 2018, at 7:12 AM, bert hubert = wrote: >=20 > On Mon, Nov 19, 2018 at 02:12:18PM +0000, Paul Hoffman wrote: >>> I've observed that the thousands of users of doh.powerdns.org (I = also do not >>> know how this happened) take around 22 packets per DNS = query/response.=20 >>=20 >> It would be valuable to know if this is this because your DoH server = kills >> the entire connection after every DNS query, or because the clients = are >> doing so. >=20 > It does around 2 DNS queries per HTTPS connection on average = dnsdist-doh > keeps open an HTTP/2 connection for 10 seconds if it becomes idle. Thanks, that seems to be your problem. Can the dnsdist DoH server = package be configured to have an idle timeout that is more = representative of typical browser use, such as on the order of minutes? >>> Larger scale adoption of TLSv1.3 might improve this somewhat, but it = is a >>> big number. >>=20 >> DoH was designed for long-lived connections, so the number would = normally be smaller after the initial connection. >=20 > I can only report what I measure based on several thousands of users. >=20 >>> I've also personally observed that a "slightly suboptimal" network >>> absolutely kills browsing performance in Firefox Nightly using DoH. = A naive >>> calculation shows that 0.5% packet loss turns into a 5% failure rate = per DoH >>> query, which then can cause Head of Line blocking for further = queries, which >>> cascades into "blank pages" getting rendered.=20 >>=20 >> When you say "naive calculation", do you mean this is observed in the >> clients hitting your DoH server? That would indeed be scary. = However, >> the Mozilla numbers tell a very different story. It would be good to = know >> which one is true. >=20 > My personal observation is that on a slightly bad network, turning off = DoH > speeds up things massively and makes the web useable again. This = naively > makes sense, DoH uses way more packets and suffers from Head of Line > blocking, unlike plain DNS. Is that still true with a server timeout that is not so short? > We have asked Mozilla to provide more details of their measurements, = but > these have not been forthcoming. Noted. It would be *really* useful to the community if there was better = communication from them. > Note that the graph published on the blog misses the 95% and 99% bins, > = https://blog.nightly.mozilla.org/files/2018/08/DNS-over-HTTPS-Performance-= Improvement.png > and does not include details on timeouts. Yep, and that would be useful too. >>> And, perhaps somewhat more provocatively, should we maybe not start = pushing >>> DoH/2 if it leaves people with a sub-standard experience, causing = them to >>> disable DoH? >>=20 >> If the implementations on the client or server side make using DoH = bad, >> those implementations should be fixed. If they don't get fixed, = we'll >> certainly hear about it. >=20 > There is already a Firefox ticket I think, but with Patrick and Daniel = gone > or gone soon, I am not sure who owns it now. Hopefully he or she will decloak soon. >=20 >>> DoH/3 might be somewhat of a wait but it might prevent that >>> sour taste from developing. >>=20 >> Without sufficient data, it's hard to say if there really is a sour = taste. >=20 > Perhaps Mozilla can clarify further what they measured beyond the 7 > milliseconds slowdown. >=20 > I may do some induced packetloss experiments to see if the = "experience" can > be reproduced. That would be grand, but it would also be good to have such experiments = when the server has a more sensible timeout value. --Paul Hoffman= --Apple-Mail=_F1A79C9B-90F8-480D-8DF8-28D559885D5B Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTExOTE1MzkxN1owIwYJKoZIhvcNAQkEMRYEFDuvJsiHzRO/PHzgIZET+UEzvUYTMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQBhF9LMAJ0h35JVujX1LWdthrv9SHazHvIPhbhDR/kT/kfSTL0twQ+pwcNcp1/Dr11cikqi fnC7ltdA23oATHvEpscQqMKa99+HYQWeHz46Onah5QbXdbC9ag0mN8tA5JGh93JHI6wFpdLE+hkE yIMKrCiB+l7gcXqjNTqt1fX08MfhvWTv5oSxOQph3n0qaFxKL3RldVHlHxgRQ5q/Xi5Ob5HziBsP 2pDhFrQBF57d9TykMR+qpp4B6rAu1DivOENz2tbdGEm1F+PSwvvZczEDvBVy1XJ/fRsR29o/aF7Q 8/zfJBzw2CUcU0BaP37SvVzBURMmAutIzaluxPNZO1UpAAAAAAAA --Apple-Mail=_F1A79C9B-90F8-480D-8DF8-28D559885D5B-- From nobody Mon Nov 19 08:04:29 2018 Return-Path: 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 8C1AC1294D0 for ; Mon, 19 Nov 2018 08:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 Ge_Em1CYqQwg for ; Mon, 19 Nov 2018 08:04:26 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6531286E7 for ; Mon, 19 Nov 2018 08:04:26 -0800 (PST) Received: from server.ds9a.nl (ip565244ed.adsl-surfen.hetnet.nl [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 205EF9FD6E; Mon, 19 Nov 2018 16:04:15 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id E7DBEACA4AF; Mon, 19 Nov 2018 17:04:14 +0100 (CET) Date: Mon, 19 Nov 2018 17:04:14 +0100 From: bert hubert To: Paul Hoffman Cc: "doh@ietf.org" Message-ID: <20181119160414.GA20821@server.ds9a.nl> References: <20181119100954.GA6704@server.ds9a.nl> <5BE15B68-1C61-4462-AE84-901E2CF0F9F9@icann.org> <20181119151209.GC11506@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] [Ext] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 16:04:28 -0000 On Mon, Nov 19, 2018 at 03:39:16PM +0000, Paul Hoffman wrote: > > It does around 2 DNS queries per HTTPS connection on average dnsdist-doh > > keeps open an HTTP/2 connection for 10 seconds if it becomes idle. > > Thanks, that seems to be your problem. Can the dnsdist DoH server package > be configured to have an idle timeout that is more representative of > typical browser use, such as on the order of minutes? I have measured with timeout of 100 seconds and 300 seconds. In both cases, the packets per query ratio drops to 12, from 22. This is still around 6 times more than UDP, and I now carry around hundreds of additional filedescriptors. But ok. > > My personal observation is that on a slightly bad network, turning off DoH > > speeds up things massively and makes the web useable again. This naively > > makes sense, DoH uses way more packets and suffers from Head of Line > > blocking, unlike plain DNS. > > Is that still true with a server timeout that is not so short? I will need to measure again. Linux can inject packet loss, so this should be doable. Bert From nobody Mon Nov 19 11:18:33 2018 Return-Path: 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 6FCF3130DE2 for ; Mon, 19 Nov 2018 11:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Cj3eUesBo0p3 for ; Mon, 19 Nov 2018 11:18:30 -0800 (PST) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2B312785F for ; Mon, 19 Nov 2018 11:18:30 -0800 (PST) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id A6161176075 for ; Mon, 19 Nov 2018 11:18:29 -0800 (PST) Received: (qmail 10796 invoked from network); 19 Nov 2018 19:18:27 -0000 Received: from unknown (HELO ?192.168.2.3?) (ask@mail.dev@104.153.224.166) by smtp.develooper.com with ESMTPA; 19 Nov 2018 19:18:27 -0000 From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= Message-Id: <60383420-A392-493E-9E09-52D649E35E9C@develooper.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AD6D7752-35AD-4B40-92F6-FAF7DFB29482" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 19 Nov 2018 11:17:45 -0800 In-Reply-To: <20181119151209.GC11506@server.ds9a.nl> Cc: Paul Hoffman , "doh@ietf.org" To: bert hubert References: <20181119100954.GA6704@server.ds9a.nl> <5BE15B68-1C61-4462-AE84-901E2CF0F9F9@icann.org> <20181119151209.GC11506@server.ds9a.nl> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Doh] [Ext] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 19:18:31 -0000 --Apple-Mail=_AD6D7752-35AD-4B40-92F6-FAF7DFB29482 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 19, 2018, at 7:12 , bert hubert = wrote: >=20 > My personal observation is that on a slightly bad network, turning off = DoH > speeds up things massively and makes the web useable again. This = naively > makes sense, DoH uses way more packets and suffers from Head of Line > blocking, unlike plain DNS. Wouldn=E2=80=99t comparing to DNS-over-TLS be a more relevant/fair = comparison? DoH makes sense, I believe, if you need a long-lived/persistent = connection because we get to take advantage of improvements in HTTP/3, = etc, without =E2=80=9Cextra DNS work=E2=80=9D. If you don=E2=80=99t need a session (or encryption) or compare with = clients that don=E2=80=99t, that=E2=80=99s never going to look = favorable. Many new DNS features require a session so as those gain adoption DoH = should look more favorable. Ask= --Apple-Mail=_AD6D7752-35AD-4B40-92F6-FAF7DFB29482 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 19, 2018, at 7:12 , bert hubert <bert.hubert@powerdns.com> wrote:

My personal = observation is that on a slightly bad network, turning off DoH
speeds up things massively and makes the web useable again. =  This naively
makes sense, DoH uses way more packets and suffers from Head = of Line
blocking, unlike plain DNS.

Wouldn=E2=80=99t comparing to = DNS-over-TLS be a more relevant/fair comparison?

DoH makes sense, I believe, if you need = a long-lived/persistent connection because we get to take advantage of = improvements in HTTP/3, etc, without =E2=80=9Cextra DNS = work=E2=80=9D.

If you don=E2=80=99t need a session (or encryption) or = compare with clients that don=E2=80=99t, that=E2=80=99s never going to = look favorable.

Many new DNS features require a session so as those gain = adoption DoH should look more favorable.


Ask
= --Apple-Mail=_AD6D7752-35AD-4B40-92F6-FAF7DFB29482-- From nobody Mon Nov 19 12:13:06 2018 Return-Path: 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 B78F5129BBF for ; Mon, 19 Nov 2018 12:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.20150623.gappssmtp.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 dQVQpDVUCaje for ; Mon, 19 Nov 2018 12:13:02 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 4CDD51292F1 for ; Mon, 19 Nov 2018 12:13:02 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id 189so50816017qkj.8 for ; Mon, 19 Nov 2018 12:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fuaATg6hnCGAhlJxmTHlZgb1Io27mC+vM7hvxK8UhTM=; b=0TDjU3RtcZaNrx1A5BSnip0Yo+UzYBkLslfr+bfSWNpfgzRGkr2bPMXVwvEhKSNF1Z soxYGE/FxWUqG/cxcTX4/jMWvbl8HG6by9s5DhpF963yfbPYX0sNV2qoGbWEFzxnwhLN NyrU9NNzLmBvU0PcI4dDd7rLYADgesC4r2VVBEzriyAITAKvsyeErdOXV4z5eEvqN/G5 rW3N+bM28WN+lqZzztnSW9Fj08jf2mobZ4e8F9eJv+d/gmc+fSNbVk2Z6ibSlC3f8Z3C ISmVqSLq0igaF73Tyjbcr9j7pwrGzhOjC56deAqYyrk8L8DiOew66EPB94lLe1LVqj0D tMmg== 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=fuaATg6hnCGAhlJxmTHlZgb1Io27mC+vM7hvxK8UhTM=; b=C7KmyBj+W5ssdUFpLpNv8yRkt1VAwZcdS7ZZZHT6UVC0s6JX0ZiFoVSLPl6HdOiel2 3T0td2FnJItnWrFK3KQvbU8+qylDbD6EM58XBPfc5uHgky5boVDfgEZKKzgzlIMtyc5x nl5OegGkRBqtjQ1DvJpd51b13GWr80LOJItVz0QHXtEUdqVeJxMw3WNcXoPpICGFiRrY bQWCOv1/x9ZNSduJCmtw7TeU5WPcGdAWa01LjyN6nIFrOGTEr2EH14gw8z+TCGuOwBhI fpXAtnmdQ90s8avP38gvX7OturncmoYlzBX79MZ+8pHnLtHDu5Tl/pz864Wyg7B+lIDA avqg== X-Gm-Message-State: AA+aEWYJcg23/F7DltIkqlomeBBaYkFigu0/LcQh4C/LlBr7oJoDM8u+ 7uCL9FqILxEGySWj0hGa26D9lu9iS6SOGN/4d+yN/zvUjiE= X-Google-Smtp-Source: AFSGD/WcU3N7U/nOkLOKefFQg1zIj9/UFc+Nd1f16bXw5e5XTL8yPBvGKem/0V9UICIugmQGKP8R3W81CoXkws+hDr8= X-Received: by 2002:a0c:c348:: with SMTP id j8mr11942006qvi.201.1542658381368; Mon, 19 Nov 2018 12:13:01 -0800 (PST) MIME-Version: 1.0 References: <20181119100954.GA6704@server.ds9a.nl> <5BE15B68-1C61-4462-AE84-901E2CF0F9F9@icann.org> <20181119151209.GC11506@server.ds9a.nl> <60383420-A392-493E-9E09-52D649E35E9C@develooper.com> In-Reply-To: <60383420-A392-493E-9E09-52D649E35E9C@develooper.com> From: Ted Lemon Date: Mon, 19 Nov 2018 15:12:25 -0500 Message-ID: To: ask@develooper.com Cc: bert hubert , Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="000000000000d4ee30057b0a24df" Archived-At: Subject: Re: [Doh] [Ext] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 20:13:05 -0000 --000000000000d4ee30057b0a24df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What new DNS features require a session? On Mon, Nov 19, 2018 at 2:18 PM Ask Bj=C3=B8rn Hansen = wrote: > > > On Nov 19, 2018, at 7:12 , bert hubert wrote: > > My personal observation is that on a slightly bad network, turning off Do= H > speeds up things massively and makes the web useable again. This naively > makes sense, DoH uses way more packets and suffers from Head of Line > blocking, unlike plain DNS. > > > Wouldn=E2=80=99t comparing to DNS-over-TLS be a more relevant/fair compar= ison? > > DoH makes sense, I believe, if you need a long-lived/persistent connectio= n > because we get to take advantage of improvements in HTTP/3, etc, without > =E2=80=9Cextra DNS work=E2=80=9D. > > If you don=E2=80=99t need a session (or encryption) or compare with clien= ts that > don=E2=80=99t, that=E2=80=99s never going to look favorable. > > Many new DNS features require a session so as those gain adoption DoH > should look more favorable. > > > Ask > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000d4ee30057b0a24df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What new DNS features require a session?

On Mon, Nov 19, 2018 at 2:18 PM Ask Bj= =C3=B8rn Hansen <ask@develooper.co= m> wrote:


On Nov 19, 2018, at 7:12 , bert hubert <bert.hubert@powerdns.com&= gt; wrote:

My personal observation is that on a slightly bad network, turning off D= oH
speeds up things massively and makes th= e web useable again.=C2=A0 This naively
ma= kes sense, DoH uses way more packets and suffers from Head of Lineblocking, unlike plain DNS.

Wouldn=E2=80= =99t comparing to DNS-over-TLS be a more relevant/fair comparison?

DoH makes sense, I believe, if you need a long-lived/persi= stent connection because we get to take advantage of improvements in HTTP/3= , etc, without =E2=80=9Cextra DNS work=E2=80=9D.

I= f you don=E2=80=99t need a session (or encryption) or compare with clients = that don=E2=80=99t, that=E2=80=99s never going to look favorable.

Many new DNS features require a session so as those gain ad= option DoH should look more favorable.


<= div>Ask_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000d4ee30057b0a24df-- From nobody Mon Nov 19 12:14:13 2018 Return-Path: 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 B552A130DE2 for ; Mon, 19 Nov 2018 12:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 huUJNbDxYlNw for ; Mon, 19 Nov 2018 12:14:11 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F909129BBF for ; Mon, 19 Nov 2018 12:14:11 -0800 (PST) Received: from server.ds9a.nl (ip565244ed.adsl-surfen.hetnet.nl [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 5F4289FD6E; Mon, 19 Nov 2018 20:14:08 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id E526DACA4C5; Mon, 19 Nov 2018 21:14:07 +0100 (CET) Date: Mon, 19 Nov 2018 21:14:07 +0100 From: bert hubert To: Ask =?iso-8859-1?Q?Bj=F8rn?= Hansen Cc: Paul Hoffman , "doh@ietf.org" Message-ID: <20181119201407.GB20821@server.ds9a.nl> References: <20181119100954.GA6704@server.ds9a.nl> <5BE15B68-1C61-4462-AE84-901E2CF0F9F9@icann.org> <20181119151209.GC11506@server.ds9a.nl> <60383420-A392-493E-9E09-52D649E35E9C@develooper.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <60383420-A392-493E-9E09-52D649E35E9C@develooper.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] [Ext] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 20:14:13 -0000 On Mon, Nov 19, 2018 at 11:17:45AM -0800, Ask Bjørn Hansen wrote: > > My personal observation is that on a slightly bad network, turning off DoH > > speeds up things massively and makes the web useable again. This naively > Wouldn’t comparing to DNS-over-TLS be a more relevant/fair comparison? The reason I compare DoH to 'plain DNS' is that it was proposed as the new default for Firefox. And if it turns out that this new default will in fact cause a performance degradation, it may be worth pondering skipping 'DOH/2' as default and waiting for 'DOH/3'. (note that Mozilla has let the "we'd like to turn on DoH by default" wording stand, but also stated there are currently no plans yet to do so). > If you don’t need a session (or encryption) or compare with clients that don’t, that’s never going to look favorable. DNSCrypt still offers encryption without sessions, and it works well. Perhaps DNSCrypt/DoH is the fairest comparison. Bert From nobody Mon Nov 19 13:34:37 2018 Return-Path: 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 BB373130DF4 for ; Mon, 19 Nov 2018 13:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 h4Xf7zFlJtSF for ; Mon, 19 Nov 2018 13:34:34 -0800 (PST) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) (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 B63FF130DEE for ; Mon, 19 Nov 2018 13:34:33 -0800 (PST) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id wAJLY7JL031815 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Nov 2018 22:34:07 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id wAJLY5Ou031803; Mon, 19 Nov 2018 22:34:06 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Mon, 19 Nov 2018 22:34:05 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: bert hubert cc: Paul Hoffman , "doh@ietf.org" In-Reply-To: <20181119151209.GC11506@server.ds9a.nl> Message-ID: References: <20181119100954.GA6704@server.ds9a.nl> <5BE15B68-1C61-4462-AE84-901E2CF0F9F9@icann.org> <20181119151209.GC11506@server.ds9a.nl> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Doh] [Ext] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 21:34:36 -0000 On Mon, 19 Nov 2018, bert hubert wrote: >> If the implementations on the client or server side make using DoH bad, >> those implementations should be fixed. If they don't get fixed, we'll >> certainly hear about it. > > There is already a Firefox ticket I think, but with Patrick and Daniel gone > or gone soon, I am not sure who owns it now One of my more recent changes to Firefox's DoH code was exactly a system that makes it switch off "TRR" when the DoH server repeatedly fails to respond correctly (in time). But we're digressing, that's really a Firefox/webbrowser issue, not a general DoH issue. -- / daniel.haxx.se From nobody Tue Nov 20 03:31:09 2018 Return-Path: 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 1B715130DFD for ; Tue, 20 Nov 2018 03:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1vPTXieV6_NE for ; Tue, 20 Nov 2018 03:31:03 -0800 (PST) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id E459B130DF1 for ; Tue, 20 Nov 2018 03:31:02 -0800 (PST) Received: from jurassic (unknown [210.18.173.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id F18B032C0F32; Tue, 20 Nov 2018 11:31:00 +0000 (UTC) Date: Tue, 20 Nov 2018 17:00:56 +0530 From: Mukund Sivaraman To: bert hubert Cc: Paul Hoffman , "doh@ietf.org" Message-ID: <20181120113056.GA17221@jurassic> References: <20181119100954.GA6704@server.ds9a.nl> <5BE15B68-1C61-4462-AE84-901E2CF0F9F9@icann.org> <20181119151209.GC11506@server.ds9a.nl> <20181119160414.GA20821@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181119160414.GA20821@server.ds9a.nl> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [Doh] [Ext] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 11:31:07 -0000 On Mon, Nov 19, 2018 at 05:04:14PM +0100, bert hubert wrote: > On Mon, Nov 19, 2018 at 03:39:16PM +0000, Paul Hoffman wrote: > > > It does around 2 DNS queries per HTTPS connection on average dnsdist-doh > > > keeps open an HTTP/2 connection for 10 seconds if it becomes idle. > > > > Thanks, that seems to be your problem. Can the dnsdist DoH server package > > be configured to have an idle timeout that is more representative of > > typical browser use, such as on the order of minutes? > > I have measured with timeout of 100 seconds and 300 seconds. In both cases, > the packets per query ratio drops to 12, from 22. This is still around 6 > times more than UDP, and I now carry around hundreds of additional > filedescriptors. But ok. This is not specifically about DoH, but I don't like the path DNS is taking. I don't like the general push to heavy protocols for DNS and have often commented about it on dprive and dnsop. DNS historically has been mostly a light-weight single-request single-response stateless protocol (TCP is used as a last resort vs. UDP that's used in preference). The addition of a privacy layer could add more weight, but we seem to be uninterested in exploring other stateless or low-state ideas, outside TLS and even QUIC. After the resolver work, the phase-2 introduction for resolver<->auth communications[1] started with TLS which seemed illogical to me. There must be empirical studies of consequences before protocols push through to RFC. People such as Sara Dickinson at Sinodun have been studying the performance and scalability of the privacy layer in DNS implementations which is very commendable. [1] https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01 Some people such as Brian Haberman have taken an initiative to gather requirements for resolver-auth privacy instead of jumping directly to design which is again commendable. dnsop and dprive should study this before pushing drafts to RFCs. What is the worst case on resource utilization, number of round-trips and number of packets to implement these layers? What could happen on average in practice? Large operators who plan ahead ask these questions. Can handle TCP and DNS over TLS and DNS over HTTPS in a future world at rates similar to UDP now? I can picture the overhead for UDP and TCP, but it is a lot more complicated with the extra layers. It's not ok to assume and hand-wave away that optimizations such as TCP fastopen will avoid roundtrips and make up for performance. A TCP client may not have a cookie for the average nameserver case for the SYN except if it is for a "CDN/cloud" concentrated nameserver. I'm afraid these things will encourage more concentration for performance vs. keeping the internet distributed. Facilities such as TCP fastopen are also experimental and we should not rely on them until more time has passed. Server-side support for it is still turned off by default in current versions of popular Linux distributions (a system-level setting that can't be enabled by applications such as a nameserver). Resolvers such as BIND have not yet implemented TCP fastopen for making connections. fastopen also suggests downgrades globally to regular 3-way TCP handshake from fastopen when there is a flood, which is not an attack in the regular sense, but loses the fastopen optimization if DNS relies on it to perform satisfactorily. DNS is not a special protocol, but it is at the head of every internet activity. It has to perform well and scale well. The chairs should encourage studies into stateless methods to do privacy with low roundtrip overhead. Other protocols pay heed to stateless methods, e.g., DNS COOKIE is stateless on the server side. TCP fastopen is also stateless on the server side. There is unexpected advice in RFCs too. When TCP fastopen is available for the DNS over TCP case, it seems better for the TCP connection to be closed than it be kept open because the open connection would revert to slow-start phase after an idle period with typical DNS query traffic patterns (unlike replies to a browser's HTTP requests that are typically much larger and more in sequence) unless it is continually active. In a greedy world, closing idle connections is something that authoritative servers would prefer to do to get rid of state - resolvers can't rely on having long-lived connections. This has become a rant but I'm unhappy about the process that is pushing new DNS features without sufficient evaluation. Modifying the transport of DNS without studies may affect performance and scalability that we may come to regret. Mukund From nobody Thu Nov 22 19:43:47 2018 Return-Path: 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 BB1CB12F1A5 for ; Thu, 22 Nov 2018 19:43:45 -0800 (PST) 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 iN_e-pMoIC-L for ; Thu, 22 Nov 2018 19:43:42 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 5633D130DE0 for ; Thu, 22 Nov 2018 19:43:42 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id f18so7994058otl.11 for ; Thu, 22 Nov 2018 19:43:42 -0800 (PST) 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=O8afrFdSinjbbNZek00NBC9d8ex6kTHXzQyMAnGn//k=; b=HJpe1tOb4zAO4DUEnWGxIGyHy3NCAPHpIzi+x6JO3XqH/K17fRSQ1KhjR7lQdMj7QY AYojR6j0UgPlJXMG6VUD7nFnaU57Rgf8735AP+fNePcAI79SDiz+P4geBrq8QChaj+NU 32pLrH4EKInr8M/FmQhn+X+D3nekCQoUKgI8lvc+ohJnNpxrT9OweQu2qurqdQtJuPIl bZ0e3lhajxiGMVbK1c3QOBM+VfWSVyXzzKgvIBHNoaa1XXyN5GFgb0yr/SORgdVa4ogg Hg6wDLM5TJNNwXO3WGfdhTxlxZy5scVApWMgEQAI4kejmiaJrPtdGqCviO/IT4H3Thxv XuVw== 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=O8afrFdSinjbbNZek00NBC9d8ex6kTHXzQyMAnGn//k=; b=GSo+H3Ri98yShcekY/ydWIwC6xi3i70wBuGaQqQKlqUR2CNulDbPtJrmYsge+oddGX j/MmSARR+Oa7P/sco+oEmWJlSbDhopAhpCB3tQ2gHE0yZG4YFpc99JhzGCSzm4Q49FEV +RvnZI8Agu27SOaOkSG66y5oP34yfcFzI6UkEYfzAJR6ZTNbq6gLnRwTkOztnpf5MOXS WOjiRPqo2eIKUdumi/zQmX1jQvcURYtQli8qoFG8iSOD3Cvh618GpZUt3XKhgmO1DYNc fhyqbbfdMctJbCy+mohiaXCwwhcAABfbFUkjZM3q6skpHRkAHFa1OW/eCzI4CyMO8YoP R+Mg== X-Gm-Message-State: AA+aEWZwqdlHog0nQc3g3Cq7sB63L41wpNkl3O3HHa3SZ5Y2pHD2LJ6I cdaiNDotjDxvKQFGF8CpA341yfl0Yml6CTiOdN4= X-Google-Smtp-Source: AFSGD/VPAW8d6TpEolWq9q4lw7VBak6ifKKdfElC/DaBpjqIN1JV4566r80DzJw67xWv4nL/GDh6Uua+M/pMYhiyjk4= X-Received: by 2002:a9d:6a8e:: with SMTP id l14mr7444959otq.348.1542944621576; Thu, 22 Nov 2018 19:43:41 -0800 (PST) MIME-Version: 1.0 References: <20181119100954.GA6704@server.ds9a.nl> In-Reply-To: <20181119100954.GA6704@server.ds9a.nl> From: Az Mankin Date: Thu, 22 Nov 2018 22:43:30 -0500 Message-ID: To: bert hubert Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="00000000000013c816057b4ccacb" Archived-At: Subject: Re: [Doh] DNS over HTTP/3? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 03:43:46 -0000 --00000000000013c816057b4ccacb Content-Type: text/plain; charset="UTF-8" Bert, >In other words, to the sound of a groaning >camel, do we need a draft? Or a >section in the HTTP/3 I-D? Please take a look at draft-huitema-quic-dnsoquic-05 It was introduced in the QUIC WG and revised as QUIC evolved (and as some prototype stacks by the authors gave results). It needs a refresh now. QUIC made it low priority while working on the HTTP transport. On Mon, Nov 19, 2018 at 5:10 AM bert hubert wrote: > Hi everyone, > > Now that we are still here, perhaps some work is left for us, but I'm not > sure. > > I've observed that the thousands of users of doh.powerdns.org (I also do > not > know how this happened) take around 22 packets per DNS query/response. > > Larger scale adoption of TLSv1.3 might improve this somewhat, but it is a > big number. > > I've also personally observed that a "slightly suboptimal" network > absolutely kills browsing performance in Firefox Nightly using DoH. A > naive > calculation shows that 0.5% packet loss turns into a 5% failure rate per > DoH > query, which then can cause Head of Line blocking for further queries, > which > cascades into "blank pages" getting rendered. > > Of course, once we have HTTP/3, DNS over HTTP/3 would suffer way less from > incidental packet loss, and in general there would be a lot less packets > too. > > My question now is, is there any specific work to be done for DoH/3? Are > there number, priorities, features you'd want or not want to use to make > things work well? > > In other words, to the sound of a groaning camel, do we need a draft? Or a > section in the HTTP/3 I-D? > > And, perhaps somewhat more provocatively, should we maybe not start pushing > DoH/2 if it leaves people with a sub-standard experience, causing them to > disable DoH? DoH/3 might be somewhat of a wait but it might prevent that > sour taste from developing. > > I'd love to hear your thoughts! > > Bert > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --00000000000013c816057b4ccacb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bert,

<= /span>
>In other w= ords, to the sound of a groaning >camel, do we need a draft? Or a=
>section in the HTTP/3 I-D?

Please take a look at=C2=A0

draft-huitema-quic-dnsoquic-05


It was introduced in the QUIC WG and revised as QUIC evolv= ed (and as some prototype stacks by the authors gave results).=C2=A0 It nee= ds a refresh now. QUIC made it low priority while working on the HTTP trans= port.

On = Mon, Nov 19, 2018 at 5:10 AM bert hubert <bert.hubert@powerdns.com> wrote:
Hi everyone,

Now that we are still here, perhaps some work is left for us, but I'm n= ot
sure.

I've observed that the thousands of users of doh.powerdns.org (I also= do not
know how this happened) take around 22 packets per DNS query/response.

Larger scale adoption of TLSv1.3 might improve this somewhat, but it is a big number.

I've also personally observed that a "slightly suboptimal" ne= twork
absolutely kills browsing performance in Firefox Nightly using DoH.=C2=A0 A= naive
calculation shows that 0.5% packet loss turns into a 5% failure rate per Do= H
query, which then can cause Head of Line blocking for further queries, whic= h
cascades into "blank pages" getting rendered.

Of course, once we have HTTP/3, DNS over HTTP/3 would suffer way less from<= br> incidental packet loss, and in general there would be a lot less packets too.

My question now is, is there any specific work to be done for DoH/3? Are there number, priorities, features you'd want or not want to use to mak= e
things work well?

In other words, to the sound of a groaning camel, do we need a draft? Or a<= br> section in the HTTP/3 I-D?

And, perhaps somewhat more provocatively, should we maybe not start pushing=
DoH/2 if it leaves people with a sub-standard experience, causing them to disable DoH?=C2=A0 DoH/3 might be somewhat of a wait but it might prevent t= hat
sour taste from developing.

I'd love to hear your thoughts!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bert

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--00000000000013c816057b4ccacb--