From nobody Sun Nov 4 18:43:24 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305FA126BED for ; Sun, 4 Nov 2018 18:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.945 X-Spam-Level: X-Spam-Status: No, score=-15.945 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_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 3RL_MToO0N-L for ; Sun, 4 Nov 2018 18:43:21 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 B8603127148 for ; Sun, 4 Nov 2018 18:43:21 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id t17so4218951vsc.8 for ; Sun, 04 Nov 2018 18:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=iCusHWFnZuWnPdTRr0f1gxGT/P/2SyDgHmJ5fNV67Ho=; b=pe5pcg6RxdR0bvD1ckeH62ozomLlJP80dAcPdnjsTHCDKS5BsUHHJkN4jmXIaqlSng W0l1m2x+f4J1BpHXD0MNliX5jelwjdeirbWG+tlHlHqGsn/F8eo8FoFtJ4APl1wr+w9H 8pnyJqeFpKJAv1H+rterJUcoXo1p32DCg0vmyIQk+d+gtmKdMU47BB4PKMoucRvLxwDt 4tO7ZSi/wuJmW5ByDhsdTGeoFLapBU3v5NDKQQyP4F+ylEUylk6+rV2gZnBAYtWEL46Q ohihgIOG3Nf5agmoYiLHdAkBaSD7nByCHHaRW4BumGeYB6mKD7CPBn07np7sKsZEHsbr q34w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=iCusHWFnZuWnPdTRr0f1gxGT/P/2SyDgHmJ5fNV67Ho=; b=LbjXHHZjtlrpdMEkQ7ZQiS441WMlQcyKWONwwk/Zm3yrHNIbcIicFTOLGAdNQuSGw7 5/rPEjjNSnC3F5MpClv+ShwSIRG93HMgpEx+QSla3d3Grsw1y3sUpKLSFz2PYxuo45Ja QCHXkv5ToLajeeR9OK1DGjj/H6c1+kwHIkuJompjZaH2dUFJqhKYV/8xC4oPoK0qjFPs I8NZ/LmU2qTZpGwLMGN38VW8GD3KKVR7lszPBPVJ3gArY4m+RU1FReYk7WmiZUdzfUWN w2Ch2LfGnzSZeRaAmfN6Q8ZVUDPnjPIJh+tr5UANxdBO9W7gBgHg65ws7FpY89lxUN/P t3kw== X-Gm-Message-State: AGRZ1gLvV5VLsbxoLZR7KNxYVIBExsZwVlK51fT7Ljmkbl0S9Mxye2PN vKy5OeJq+lrGiZlkYvXfgUmWPSZiRTzChdFgu5tI5HrLd1iVKw== X-Google-Smtp-Source: AJdET5eN5yqzuHmUhFX8VF3+ToJH5t5wlOrMAMAzjboMIw4J0g8rFJfUKxnLvRCyRkgFpK19Si+S52yYi0jzMWo4K1U= X-Received: by 2002:a67:32c6:: with SMTP id y189mr8611288vsy.105.1541385800217; Sun, 04 Nov 2018 18:43:20 -0800 (PST) MIME-Version: 1.0 From: Justin Henck Date: Mon, 5 Nov 2018 09:43:08 +0700 Message-ID: To: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="00000000000015dc990579e1d9bc" Archived-At: Subject: [Resolverless-dns] Resolverless side-meeting Tuesday (unofficial) X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 02:43:23 -0000 --00000000000015dc990579e1d9bc Content-Type: text/plain; charset="UTF-8" I set up an unofficial Resolverless DNS side meeting for Tuesday 16:00-17:00 in Pagoda (4th Floor) for some in-person discussion. Hopefully this works for people. Justin Justin Henck Product Manager 212-565-9811 google.com/jigsaw PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B --00000000000015dc990579e1d9bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I set up an unofficial Resolverless DNS s= ide meeting for Tuesday 16:00-17:00 in Pagoda (4th Floor) for some in-perso= n discussion.=C2=A0 Hopefully this works for people.
=
Justin


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

PGP: E= A8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B
<= /div>
<= /div> --00000000000015dc990579e1d9bc-- From nobody Tue Nov 6 06:42:19 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A68124BE5 for ; Tue, 6 Nov 2018 06:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.095 X-Spam-Level: X-Spam-Status: No, score=-16.095 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_IMAGE_ONLY_28=1.404, 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, WEIRD_PORT=0.001] autolearn=no 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 VBRFLIed_fhy for ; Tue, 6 Nov 2018 06:42:15 -0800 (PST) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 7EC3E130E39 for ; Tue, 6 Nov 2018 06:42:15 -0800 (PST) Received: by mail-vs1-xe30.google.com with SMTP id t17so7396692vsc.8 for ; Tue, 06 Nov 2018 06:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=a+Y8CuB7uAFou9YObM+NdJFfL56GLzhmskC+vk3wQvM=; b=Iu5J7cX/YoXyZpN11ctrITrC8W8a7FZyCK92rwAFzXq6wnFkOv0Zj3Emz41TTuVdTg eJ4kAdzNoIIdFMnfQzobfBzjwfN5LQh0WW7jxW1fOrAzoKnVsfNQJzdTe+ONg1Qhsrb5 MrwBcEPKn6PWjS9cx1IoTyBjl+B+LEilGZIxx++SliQf1MDCuNIQm6CDsAeFAmhsXRMw IQ0dx5RkCAGwu/+saim72SUFSzu5bgoBngp/7bpnTBEBoNrcZd79KuSPDn//BOZu5Zvv t21HUouMJdMs+zZOJnhVH3DQXrQZuoT6vPuwT/olLaMaTl4wtUb3hDnn1h8W+tdv/+kq Moqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=a+Y8CuB7uAFou9YObM+NdJFfL56GLzhmskC+vk3wQvM=; b=XEzm47SBEbcyK2mXuIGEBezVABp+irp9c53U548v5O+nz3ufzt5QD7M2mlGpF8il+5 f+4CbWpxOWIyoCduhzBoLqWDLVf6GBKnu4XgBWL6tj3i3sl38c2LSMzR09V2KMdN7UUF LF+6Pq9P4hSkxLEdYNoHPCIL0AwOejFdLw7aC/OWFObSd2qYfQBPIhwXQ/9knnItCN4B maY/wjPG/MGRgF9qADlCCu17ZTIUgCehhUEMM0rWE8EJHnfa0AFzhSjXCGsv/wneeY1R EGik0fTQSaaArNRrtJAbjgtR6IKj3b9uH3RY+7HP0WacnNkFLlccxGTJPqCKaAZPBPP+ TyXQ== X-Gm-Message-State: AGRZ1gIJWImycryLBo8rpxnElStgdRGnkDcO0ImPHZHej9wuPNbOcCYV kBUVmQUDR7w8XKv7jt14rNDQP9HqgI3YGmTiPy7Cm4rkhCPlIA== X-Google-Smtp-Source: AJdET5cOkNSk4RaUeCvQ1dLcKsoBXH+GxHlaTrmcszKM0XIQBJup3PFKZrgBC6zif80AgdPkfztfR7PzO/XQkKzyIQE= X-Received: by 2002:a67:ca0e:: with SMTP id z14mr11429231vsk.83.1541515333484; Tue, 06 Nov 2018 06:42:13 -0800 (PST) MIME-Version: 1.0 From: Justin Henck Date: Tue, 6 Nov 2018 21:42:00 +0700 Message-ID: To: resolverless-dns@ietf.org Content-Type: multipart/mixed; boundary="000000000000df0c95057a000118" Archived-At: Subject: [Resolverless-dns] 103 Unofficial Side-meeting Notes X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 14:42:18 -0000 --000000000000df0c95057a000118 Content-Type: multipart/alternative; boundary="000000000000df0c8b057a000116" --000000000000df0c8b057a000116 Content-Type: text/plain; charset="UTF-8" Hi all, Thanks for attending the side-meeting today. Though there are clearly some issues to resolve, there were three specific proposals put forward during and after the meeting for pushing DNS records or similar information. (Listed below in the order they were presented.) Since I'm a newcomer, what seems like a good goal for 104? Proposal 1: DNSSEC-signed: Any outbound link or resource from a site Proposal 2: ??: CDN-local links or resources Proposal 3: Within TLS: Any automatically loaded resource, perhaps in the HTML I've attached the complete notes captured as best I was able. The lack of attribution is more a consequence of the many new faces for me than anything else, so please feel free to edit the etherpad ( http://etherpad.tools.ietf.org:9000/p/notes-ietf-103-unofficial-resolverless) to attribute yourself or your organization and we can send the notes out again later. Justin Henck Product Manager 212-565-9811 google.com/jigsaw PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B --000000000000df0c8b057a000116 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
Thanks for a= ttending the side-meeting today. Though there are clearly some issues to re= solve, there were three specific proposals put forward during and after the= meeting for pushing DNS records or similar information.=C2=A0 (Listed belo= w in the order they were presented.) Since I'm a newcomer, what seems l= ike a good goal for 104?

Proposal 1: DNSSEC-signed= : Any outbound link or resource from a site
Proposal 2: ??: CDN-l= ocal links or resources
Proposal 3: Within TLS: Any automatically= loaded resource, perhaps in the HTML

I've att= ached the complete notes captured as best I was able.=C2=A0 The lack of att= ribution is more a consequence of the many new faces for me than anything e= lse, so please feel free to edit the etherpad (http://etherpa= d.tools.ietf.org:9000/p/notes-ietf-103-unofficial-resolverless) to attr= ibute yourself or your organization and we can send the notes out again lat= er.

Justin 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
--000000000000df0c8b057a000116-- --000000000000df0c95057a000118 Content-Type: text/markdown; charset="US-ASCII"; name="notes-ietf-103-unofficial-resolverless.md" Content-Disposition: attachment; filename="notes-ietf-103-unofficial-resolverless.md" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jo5uecw50 IyBSZXNvbHZlcmxlc3MgRE5TCgpOb3ZlbWJlciA2LCAyMDE4IH4zMCBwZW9wbGUKCgojIyBPdmVy dmlldyBvZiAxMDIKCkFjdGlvbiBpdGVtIHRvIGNvbWUgdXAgd2l0aCBhIG1pbmltdW0gdXNlIGNh c2UgZm9yIHJlc29sdmVybGVzcyBET0gKCgojIyMgVXNlIGNhc2VzCgoqICAgU3BlZWQKICAgICog ICBSZW1vdmluZyBxdWVyeQogICAgKiAgIENvbnNvbGlkYXRpbmcgSVBzCiogICBQcml2YWN5CiAg ICAqICAgUmVkdWNlZCByZXNvbHZlciB0cmFja2luZwogICAgKiAgIFJlZHVjZWQgcmVzb2x2ZXIg cmVzdHJpY3Rpb25zCiogICBOYW1lc3BhY2luZwoKCiMjIyBDb25jZXJucwoKKiAgIFN1cGVyY29v a2llcwoqICAgRERvUwoqICAgVHJhZmZpYyBjYXB0dXJlCgoKIyMgKipTdGFydGluZyBQcm9wb3Nh bCoqCgoqICAgREtHOiBIVFRQLWNsaWVudCByZWNlaXZlcyBETlNTRUMgc2lnbmVkIHJlY29yZCBz ZXQKCgojIyBEaXNjdXNzaW9uCgoqICAgQ29uY2VybjogVGhlIG1lY2hhbmlzbSBmb3IgY29udHJv bGxpbmcgd2hlcmUgdHJhZmZpYyBpcyBkaXJlY3RlZCBpcyBhbHRlcmVkIHdoZW4gcmVjb3JkcyBh cmUgb2J0YWluZWQgdGhyb3VnaCBzZXJ2ZXIgcHVzaCByYXRoZXIgdGhhbiB2aWEgYSB0eXBpY2Fs IGRucyByZXNvbHZlcgogICAgKiAgIEhvdyBkb2VzIEVDUyBmaXQgaW50byB0aGlzPwogICAgKiAg IEEgc2VydmVyIG1pZ2h0IHRyeSB0byByZWRpcmVjdCB1c2VycyB3aG8gYXJyaXZlIGF0IHRoYXQg c2VydmVyIHZpYSBhIHB1c2hlZCByZWNvcmQgYnkgcHVzaGluZyBhbm90aGVyIHJlY29yZCB3aXRo IGEgY2xvc2VyIGlwIHRoYXQgdGhlIHVzZXIgc2hvdWxkIHVzZSBpbiBmdXR1cmUgY29ubmVjdGlv bnMKICAgICogICBXaGF0IGlmIHdlIGFsbG93IGhvc3RuYW1lcyB0byBvcHQtaW4gb3Igb3B0LW91 dCBvZiBoYXZpbmcgcmVjb3JkcyBmb3IgdGhlaXIgaG9zdG5hbWUgcHVzaGVkIGJ5IG90aGVyIHNl cnZpY2VzPwogICAgKiAgIExhcmdlIHdlYnNpdGVzIHdvdWxkbid0IHdhbnQgYnJvd3NlcnMgdG8g aW50ZXJmZXJlIHdpdGggdGhlaXIgbG9hZCBiYWxhbmNpbmcgc2NoZW1lcwoqICAgQ291bGQgd2Ug dXNlIGRpZmZlcmVudCBzdGFuZGFyZHMgb2YgcHJvb2YgZm9yIGFjY2VwdGluZyByZWNvcmRzPyBF LmcuIGlmIGEgd2Vic2l0ZSBoYXMgYSBjZXJ0aWZpY2F0ZSBjb3ZlcmluZyBfKi5kb21haW5fIHRo ZW4gY2FuIHlvdSBhY2NlcHRlZCBwdXNoZWQgX2EuZG9tYWluXyByZWNvcmRzIGZyb20gdGhhdCB3 ZWJzaXRlIHdpdGhvdXQgRE5TU0VDPwogICAgKiAgIEl0IHdvdWxkIHByb2JhYmx5IGJlIGRvbWFp biBzcGVjaWZpYwogICAgKiAgIENyaXRpcXVlOiBXZSdkIGhhdmUgdG8gYmUgd29ycmllZCBhYm91 dCByZXBsYXkgYXR0YWNrcwogICAgKiAgIFdoYXQga2luZCBvZiByZWNvcmQgdHlwZXM/IEEsIEFB QUEsIEVTTkk/CiAgICAqICAgWW91IHdvdWxkIGhhdmUgdG8gc3RlYWwgcHJpdmF0ZSBrZXlzIGlu IG9yZGVyIHRvIHJlZGlyZWN0IHRyYWZmaWMgdnMuIHRoZSBjdXJyZW50IHN0YXRlIG9mIG1hbmlw dWxhdGluZyB0aGUgbmV0d29yayAoZS5nLiBCR1ApCiogICBDb25jZXJuOiBXaGF0IGFib3V0IHNp bWlsYXItbG9va2luZyBkb21haW5zIGFuZCB0aGUgaW50ZXJwbGF5IHdpdGggc29jaWFsIGVuZ2lu ZWVyaW5nIChpLmUuIGEgd2ViIHNlcnZlciBwdXNoaW5nIGEgcmVjb3JkIGZvciBmYWtlYm9vay5j b20gYXMgYSBwaGlzaGluZyBhdHRhY2spPwogICAgKiAgIE1hbHdhcmUtZmlsdGVyaW5nIEROUyB3 b3VsZCBubyBsb25nZXIgY2F0Y2ggdGhlc2UgYXR0YWNrcyBzaW5jZSB0aGUgYnJvd3NlciB3b3Vs ZG4ndCBsb29rIHVwIHRoZSByZWNvcmQKICAgICogICBNYXliZSB3ZSBjb3VsZCBwdXNoIG1hbHdh cmUgZmlsdGVyaW5nIGludG8gdGhlIGJyb3dzZXIsIG9yIHNpbXBseSBpbnN0cnVjdCB1c2VycyBv ZiB0aG9zZSBETlMgc2VydmljZXMgdG8gdHVybiBvZmYgcHVzaAoqICAgV2hhdCdzIHRoZSB1c2Ug Y2FzZT8KICAgICogICBQdXNoaW5nIEROUyByZWNvcmRzIGZvciBsaW5rcyBhbmQgc3VicmVzb3Vy Y2VzIHdpdGhpbiB0aGUgSFRNTAogICAgKiAgIEJldHRlciBwZXJmb3JtYW5jZSBhbmQgcHJpdmFj eQoqICAgQXJlIGNvbXBhbmllcyB3aWxsaW5nIHRvIGltcGxlbWVudCBETlNTRUM/CiAgICAqICAg T25lIGxhcmdlIGNvbXBhbnkgZGlkbid0IHdhbnQgdG8gaW5jbHVkZSBpdCBpbiB0aGUgT1MsIGZv ciB2YXJpb3VzIHJlYXNvbnMgc3VjaCBhcyBETlNTRUMgcmVjb3JkcyBuZXZlciBtYWtpbmcgdGhl aXIgd2F5IHRocm91Z2ggdGhlIG5ldHdvcmsgdG8gdGhlIGNsaWVudCAodGhvdWdoIHRoaXMgY29u Y2VybiBkb2Vzbid0IGFwcGx5IHRvIHB1c2ggRE5TKQogICAgKiAgIEFub3RoZXIgZG9lcyBzb21l IGRvbWFpbiBzaWduaW5nLCBhbmQgZG9lcyB2YWxpZGF0aW9uIG9uIGl0cyBwdWJsaWMgRE5TIHNl cnZpY2UKICAgICogICBXb3VsZCBpbXBsZW1lbnRpbmcgRE5TU0VDIGF0IHRoZSBicm93c2VyIGxl dmVsIGRlLWluY2VudGl2aXplIE9TJ3MgZnJvbSBpbXBsZW1lbnRpbmcgRE5TU0VDPwogICAgKiAg IE9TIGFuZCBicm93c2VyIGNhbiBzaGFyZSBhIHN0YWNrIC0gc2hvdWxkIGJlIHRoYXQgd2F5IGlu IENocm9tZU9TIChhY3R1YWxseSB0aGVyZSBhcmUgNCBzdGFja3MgaW4gQ2hyb21lT1MhKQoqICAg U29tZWJvZHkgc3RpbGwgaGFzIHRvIGRvIHRoZSByZXNvbHZpbmcsIHNvIHRoZSB0ZXJtICJyZXNv bHZlcmxlc3MgRE5TIiBpcyBhIGJpdCBtaXNsZWFkaW5nCiogICBIb3cgd2lsbCBhIGJyb3dzZXIg b2JzZXJ2ZSByb290IGtleSByb3RhdGlvbnM/CiAgICAqICAgVGhleSB3aWxsIGp1c3QgZ2V0IHVw ZGF0ZWQgZHVyaW5nIHRoZWlyIHJlZ3VsYXIgc2NoZWR1bGVzCiogICBDb25jZXJuczogd2hpdGVs aXN0cyArIGJsYWNrbGlzdCBmb3IgRE5TU0VDIC0gdXNlcnMgd29uJ3QgZ2V0IHNvbWUgcmVjb3Jk cwogICAgKiAgIFRoaXMgc2hvdWxkbid0IGJlIGEgZmFpbHVyZSwgYmVjYXVzZSBpZiB5b3UgZG9u J3QgZ2V0IGEgcmVjb3JkLCB5b3UganVzdCBxdWVyeSBETlMKICAgICogICBXZSBzaG91bGRuJ3Qg dHJ1c3QgTlhEb21haW5zCiogICBNYXliZSB3ZSBzaG91bGQgc2VwYXJhdGUgcHJpdmFjeSBjYXNl IGZyb20gcGVyZm9ybWFuY2UgY2FzZSwgYmVjYXVzZSBpZiB5b3UgZmFsbGJhY2sgdGhlbiB5b3Un cmUgc3RpbGwgbWFraW5nIGEgcXVlcnksIGFuZCB0aGlzICJmYWlsIG9wZW4iIGNvdWxkIGhhdmUg bmVnYXRpdmUgcHJpdmFjeSBpbXBsaWNhdGlvbnMKICAgICogICBJdCdzIGFtb3JwaG91cyBidXQg c2hvdWxkIHN0aWxsIGluY3JlYXNlIHByaXZhY3kKICAgICogICBXZSB3b3VsZCBuZWVkIHRvIGNv bnNpZGVyIGlmIHRoZXJlIGlzIGEgcmVhbCBmb3JjZWQgZmFpbHVyZSBhdHRhY2sKKiAgIENvdWxk IHRoaXMgYmUgYW4gb3B0aW1pemF0aW9uIHdpdGggQ0ROcyB0aGF0IGFyZSBjb2hvc3RpbmcKICAg ICogICBZZXMsIGNvdWxkIHdvcmsgd2l0aCBTZWNvbmRhcnkgQ2VydAoqICAgTWF5YmUgd2UgY291 bGQganVzdCBwdXQgb3VyIG93biBuYW1lcyAoaS5lLiBuYW1lcyB1bmRlciB0aGUgc2FtZSBjZXJ0 aWZpY2F0ZSksIHdpdGhvdXQgRE5TU0VDPwogICAgKiAgIFdvdWxkIGhhdmUgdG8gZGVmaW5lIHdo YXQgdGhhdCBtZWFucwoqICAgV2hhdCB3b3VsZCBJIGRvIHdpdGggbXVsdGlwbGUgcmVjb3Jkcz8K ICAgICogICBDb3VsZCBkbyBIYXBweSBFeWViYWxscyBieSByYWNpbmcgY29ubmVjdGlvbnMgdG8g dGhlIHZhcmlvdXMgcmVjb3JkIGlwcwoqICAgQXJlIHBlb3BsZSBPSyB3aXRoIHRoZSBjZXJ0IHBy b3Bvc2FsPyBXaGF0IGFyZSB0aGUgY3JpdGlxdWVzPwogICAgKiAgIFlvdSBtYXkgbm90IGJlIGlu IGJhaWxpd2ljawogICAgKiAgIE5ldHdvcmsgYXR0YWNrIGJlY29tZXMgYSByZW1vdGUgYXR0YWNr IGlmIHRoZSBjZXJ0IGlzIHN0b2xlbgoqICAgV2FybmluZzogREJPVU5EIHdvcmtpbmcgZ3JvdXAg aGFkIHJlbGF0ZWQgb2JqZWN0aXZlcyBhbmQgZmFpbGVkIGFmdGVyIDIgeWVhcnMgb2YgZGlzY3Vz c2lvbgoKCiMjIEVuZGluZyBQcm9wb3NhbHMKClByb3Bvc2FsIDE6IEROU1NFQy1zaWduZWQ6IEFu eSBvdXRib3VuZCBsaW5rIG9yIHJlc291cmNlIGZyb20gYSBzaXRlCgpQcm9wb3NhbCAyOiA/Pzog Q0ROLWxvY2FsIGxpbmtzIG9yIHJlc291cmNlcwoKUHJvcG9zYWwgMzogV2l0aGluIFRMUzogQW55 IGF1dG9tYXRpY2FsbHkgbG9hZGVkIHJlc291cmNlCgo= --000000000000df0c95057a000118-- From nobody Tue Nov 6 06:45:26 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04AB130E48 for ; Tue, 6 Nov 2018 06:45:13 -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=unavailable 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 9DCJKo0mfDlM for ; Tue, 6 Nov 2018 06:45:11 -0800 (PST) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 EBE6F130E5D for ; Tue, 6 Nov 2018 06:45:08 -0800 (PST) Received: by mail-ua1-x92a.google.com with SMTP id x3so4596450ual.12 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=CY9Pno9JVqBwyvZCWS8LpeVGfUvEuHIiGjcIyrqJxQyZ9WiAx5JhWuZQV2zOZOwT4n RYOLSewD8YzrtmV7k1SHxeOqU0+w8P4mI2nqtg2uxuqeiTOd1ri+DCwcn66HTi4ZpBQz /pVxKN2tCuYgF0hNXgopxzpAsRzfKdBsIC/fTEI/YSOlBcAl+vtUes3QQvnyf2xhnthd sR0RUigfR/i5FMEm8rUkZpvEPpVZvh0OiYQv1p0aV/WIOSa1hCOpCUk89ZiogwpEvWLB PUn284hjJHRE02um+Ri98qrlWlN6Lqq9RlXFdHOMmvsiBfXq8w9YIAMuy5T3hFVAJNMA gvWA== X-Gm-Message-State: AGRZ1gJKPmETImNUSJC46kKKmgxPKOJKc+uZGKfEUWHfJxTNMlbkd1Qr jAA4yN4+u76D+gKQxkGTaN4/LEIoQURRNh/K6+oovw== 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: [Resolverless-dns] [Doh] [DNSOP] On today's resolverless DNS meeting X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 14:45:14 -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:58:50 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D02A130E02 for ; Tue, 6 Nov 2018 10:58:49 -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 WfErMqeS7FKM for ; Tue, 6 Nov 2018 10:58:46 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 63AE6130DEF for ; Tue, 6 Nov 2018 10:58:46 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id h13so19431095itl.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=egQKcio2pGYzJpexg+aquAhaAIOdvGePacATRjsd0NI=; b=MyAaZFegrmYc7GhL87MIcU5N6f2sFPu422a25bThOrVb8+BuQzhT3BexKBEo7I9pmQ MAM1oy4ZGezVouF5d7BqPnQkswb0FxKyk8Rlh6430ZVaYRKl4ACPdpJdnRSUqr5Qbqt7 Rhv0xkOYGOgXpTvBoBQX8AIeUWYulOvKTGQxDgrK4Tvf0vBzwgnI9Lf9AbjEdgGPLiz9 SipX0IYozt8bvKaASD/eZMWau7hobIeaj0uTX9r1cSoLIKmeNU+/wjM/Qj/CAwKXU04p 4tyPkxVu/yFhHZEtFZ1ZNlYdOSLhhCwUOPOm2shHOSMQCDVHxS3ytXTkwlXQi7DsWwS3 ffgw== 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=egQKcio2pGYzJpexg+aquAhaAIOdvGePacATRjsd0NI=; b=j7c8y1Hd02ykDqcdBa2dfgvaAOMSJkBKl9ELrN/oCeiv4FnHqpdw8ASUcrAR2Tg4oo WXLxRxDSPcICORWfZlN9Riq3heMJ51oanuNDWEzSQ/U+HUYY6ShVKf+Rt5zULo3E0T+V UCnPBBTtylymojj/gbM0wsF6N5Q/hd+12iFhnAaoF1Q01OZvVBx/nnT+SOctkW6mR9nR OCVPT2YGh5YszQP4Q3YXtliTgaIXXNxozDz/b9v0h/cSV8uFB31QaxsvvGFHz7vj2wVY 48syNQHK/vb8qusxgtqx3O2h1AVPnDrCSWyR+ZbzJxm1L3FsqhFk+XkerG+FFmkGgpXC Th1g== X-Gm-Message-State: AGRZ1gLpajrfWwsvpgidjhdCUFh4lQJgj7qblze95mNWeCzWoT0x2Cio ycIL/7FqypNQB8RfXqtz6eQGgsyfVEg7qzqpKT6zRA== 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="000000000000548547057a0397da" Archived-At: Subject: Re: [Resolverless-dns] [Doh] [DNSOP] On today's resolverless DNS meeting X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 18:58:49 -0000 --000000000000548547057a0397da 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-- --000000000000548547057a0397da 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== --000000000000548547057a0397da-- From nobody Tue Nov 6 12:14:54 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB1F12F1AB for ; Tue, 6 Nov 2018 12:14:53 -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 KH7oLfrKZEXd for ; Tue, 6 Nov 2018 12:14:50 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 1F5B8124408 for ; Tue, 6 Nov 2018 12:14:50 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id n11-v6so10223290iob.6 for ; Tue, 06 Nov 2018 12:14:50 -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=l2ZLNpdiZBn1C0Wv2kzK3s8r572hZSJA6xYTEXc09eg=; b=wPTe8HE9wM2yfQPtIvaX7bZdg7fagsJy4G+ivf//+x3WF+t5YAb8FjrfdSC8qvitnn lbFxDx80FTqbbxhpM8S7jB9Vexb1W7BH5URau8PFrIG6fbNXzs6gOtVvfBZtIouKeB2f kkjM6gvdI/EdBrJADiIre2pUFZutlc+MGSz2nAUPpzGygHAn5K5xV1NUSZSaCGeTv3rM 9JEogStUdOi93V36ltX+0xHq8pgkDAc/MZQwRFKGgyFNrT2k9VUw0v3FKi9m5S1mzfxc VCveYOe3G2ZhTmaA48aTSKJnJflnGjw5jgsBSK+/AVd1PyyIQ92Cc5x5JAcwVuma/sXS jftA== 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=l2ZLNpdiZBn1C0Wv2kzK3s8r572hZSJA6xYTEXc09eg=; b=FJPLnqtXLhMHbaPetLroKsVUPslmRgWwLXHhPkVMnXnawGCRjDCakhllwFwgqqjktc x1bsmC1XBybTs8VnY7W06BDzw3QLPoUh6X2qG9FkZutYM9vw87wS5WoQzySRFS8JWYnx qOE7XIv45IsMHo1TEv/4Ci+dhOJng/9iHv+wAG1LNZYUYMdVcnw+OTKdHjZPjB3AAFi0 ZsvK8KOq8qF2tR8SX1VmCyZ3mN6CsnBIxJf+81I/Ul/7tQGc174qVZXce/h3qXbU/bU8 8lwz4/MOen14MkJl5kZmIxP7ARhF1glysw50TCBSOrjxpUOZa47EUCTaQw7HnLM3UV5N SXVA== X-Gm-Message-State: AGRZ1gKNYca/vgD9ty+fdTtSwUVb6QXUZfefzNRQObxP7qcyTKMI3Pd3 azUXLHFDLxHE4CPcWhvyzPB88pzSZdEigCHS1Uh6H7CzT7p4eQ== X-Google-Smtp-Source: AJdET5fcQo+aD8yAm9m70G+UMwsBOhmoLDHY7y9DGW73GPFmSo2FkQDLyzcLtz7kK8OW7oXmyZJghoVX5fX2tFE+CG4= X-Received: by 2002:a5e:de45:: with SMTP id e5-v6mr20743336ioq.235.1541535288930; Tue, 06 Nov 2018 12:14:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Tue, 6 Nov 2018 15:14:37 -0500 Message-ID: To: henck=40google.com@dmarc.ietf.org Cc: resolverless-dns@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000598404057a04a772" Archived-At: Subject: Re: [Resolverless-dns] 103 Unofficial Side-meeting Notes X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 20:14:53 -0000 --000000000000598404057a04a772 Content-Type: multipart/alternative; boundary="0000000000004f2571057a04a73b" --0000000000004f2571057a04a73b Content-Type: text/plain; charset="UTF-8" Thanks for the notes. Some thoughts: > Proposal 1: DNSSEC-signed: Any outbound link or resource from a site This still seems like the most promising option to me, particularly because it preserves the DNS defense against stolen key attacks. > What if we allow hostnames to opt-in or opt-out of having records for their hostname pushed by other services? I think this is an interesting idea. You could roughly describe it as an "anycast bit", identifying that this RRSET is good for any client, not geotargeted or load-balanced. However, it's not clear to me that it's necessary. The concern here seems to be about degradation and denial of service from html that reaches large numbers of users (e.g. search engines, ad networks). However, if one of these systems were malicious it could already mount a large DDOS attack, e.g. using XHR. Rather than block while we consider this opt-in, I'd rather find a design that allows us to do this in the future if it proves necessary. One way I can see would be to standardize a new HTTP request header, e.g. "Accept-DNS". The header value would indicate the client's policy for accepting pushed records. For example, we could start with a "dnssec" policy (indicating records must be signed), and then define additional policies in the future (e.g. "dnssec-global" for hypothetical anycast-tagged RRSETs, "same-parent" for domains under the same eTLD+1, etc.). A new HTTP request header would also enable experimenting with Resolverless without having to push DNS records to millions of existing clients that will ignore them. > Supercookies Everybody should check out https://dnscookie.com/ for a demo of this. DNSSEC doesn't help; a malicious authoritative could give unique signed records to each user. I think it should be sufficient to make the DNS cache entries cookie-scoped (i.e. profile- or container-scoped, cleared when cookies are cleared). --0000000000004f2571057a04a73b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the notes.=C2= =A0 Some thoughts:

> Proposal 1: DNSSEC-signed: Any o= utbound link or resource from a site

This s= till seems like the most promising option to me, particularly because it pr= eserves the DNS defense against stolen key attacks.

>=C2=A0What if we allow hostna= mes to opt-in or opt-out of having records for their hostname pushed by oth= er services?

I think this is an interesting idea.= =C2=A0 You could roughly describe it as an "anycast bit", identif= ying that this RRSET is good for any client, not geotargeted or load-balanc= ed.=C2=A0 However, it's not clear to me that it's necessary.=C2=A0 = The concern here seems to be about degradation and denial of service from h= tml that reaches large numbers of users (e.g. search engines, ad networks).= =C2=A0 However, if one of these systems were malicious it could already mou= nt a large DDOS attack,=C2=A0e.g. using XHR.

Rathe= r than block while we consider this opt-in, I'd rather find a design th= at allows us to do this in the future if it proves necessary.=C2=A0 One way= I can see would be to standardize a new HTTP request header, e.g. "Ac= cept-DNS".=C2=A0 The header value would indicate the client's poli= cy for accepting pushed records.=C2=A0 For example, we could start with a &= quot;dnssec" policy (indicating records must be signed), and then defi= ne additional policies in the future (e.g. "dnssec-global" for hy= pothetical anycast-tagged RRSETs, "same-parent" for domains under= the same eTLD+1, etc.).

A new HTTP request header= would also enable experimenting with Resolverless without having to push D= NS records to millions of existing clients that will ignore them.

> Supercookies

Everybody should= check out https://dnscookie.com/ fo= r a demo of this.=C2=A0 DNSSEC doesn't help; a malicious authoritative = could give unique signed records to each user.=C2=A0 I think it should be s= ufficient to make the DNS cache entries cookie-scoped (i.e. profile- or con= tainer-scoped, cleared when cookies are cleared).
--0000000000004f2571057a04a73b-- --000000000000598404057a04a772 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 wNjwu8B4MA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAAd6CrjieCiXFTKNCJPOtF PlTb+8a/CmH3HNPxhtM9XTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODExMDYyMDE0NDlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEASNEUExtvpu2AEhyH4oBubMXaX0UicbmPUSGJoP/Q 6gFhlVik45Tta4g9Yfihx7/iXDMFntcnGAidEGfKzaHlmNe96XbLjh5LpWB/TPPBzpNvrHJP5ixr AfWCRBwHx0i+6PAUqgWJe8QAxcyEbSQ/1rMBDSBTr4lbV7ZQdIHV+sX900P2jGwtUubPnsFLTXjg v+0GfzayULqfQGWJ9cGtKPRw6IyDGbElle0mL5nFe+x8+a+6Q7yZ5VnyEY7kwabDR+j5HM5Ctx8D WWHUQrCV3VvVVY88RzJueAKYKzTSFQ0PUE79CXVZ0gyoGtudFjbHRq1/4UhlX02ZLYKgHgRzvg== --000000000000598404057a04a772-- From nobody Wed Nov 7 05:21:22 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2EC12D4EA for ; Wed, 7 Nov 2018 05:21:20 -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 w0fwQqMKf3gt for ; Wed, 7 Nov 2018 05:21:18 -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 6B9301274D0 for ; Wed, 7 Nov 2018 05:21:18 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 348C9323D6; Wed, 7 Nov 2018 08:21:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23522.59085.197570.559585@gro.dd.org> Date: Wed, 7 Nov 2018 08:21:17 -0500 From: Dave Lawrence To: resolverless-dns@ietf.org In-Reply-To: <20181106102731.GA5280@naina> References: <20181106102731.GA5280@naina> Archived-At: Subject: Re: [Resolverless-dns] [DNSOP] On today's resolverless DNS meeting X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 13:21:21 -0000 Redirected from {dnsop,doh}@ietf.org, so the whole message is appended, something I am normally loathe to do. The part I'm focused on is this: > 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. You're right that this can be done, and has been sometimes in the past. It only works in simple cases, though, which means it would fail an awful lot on the modern Internet if that resource is hosted on a machine which needs Host:/SNI to work correctly. Go ahead and try it with whatever you've got open in your browser now. I just did it with https to facebook.com, google.com, and en.wikipedia.org, and got NET::ERR_CERT_COMMON_NAME_INVALID or NET::ERR_CERT_AUTHORITY_INVALID. Plain http to vhosted sites also has problems with identifying the correct objects. Yes you can come up with more ways to make it work, but they're gross too, surely more so than being able to have trustworthy name to address mappings. Mukund Sivaraman writes: > 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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Wed Nov 7 05:51:44 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4612E1274D0 for ; Wed, 7 Nov 2018 05:51:37 -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 n8Z9z2pNTi_A for ; Wed, 7 Nov 2018 05:51:36 -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 DD88112F18C for ; Wed, 7 Nov 2018 05:51:35 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 0BF61323FA; Wed, 7 Nov 2018 08:51:34 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23522.60902.31643.819149@gro.dd.org> Date: Wed, 7 Nov 2018 08:51:34 -0500 From: Dave Lawrence To: resolverless-dns@ietf.org In-Reply-To: References: Archived-At: Subject: Re: [Resolverless-dns] 103 Unofficial Side-meeting Notes X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 13:51:37 -0000 Ben Schwartz writes: > This still seems like the most promising option to me, particularly > because it preserves the DNS defense against stolen key attacks. It also keeps things well within our existing model of understanding delegation of authority for Internet resources without relying on third parties. As a side benefit, maybe this is also another kick in the pants for DNSSEC adoption. > > Supercookies > > Everybody should check out https://dnscookie.com/ for a demo of > this. ERR_CONNECTION_REFUSED From nobody Wed Nov 7 08:01:52 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36C0130DCA for ; Wed, 7 Nov 2018 08:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 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, 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 y9_jRXPMLiZt for ; Wed, 7 Nov 2018 08:01:49 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 1F61A130DC8 for ; Wed, 7 Nov 2018 08:01:49 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id f12-v6so12295961iog.0 for ; Wed, 07 Nov 2018 08:01:49 -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=GI+c3WPj5Lk4POkFBTZYWuRpqWe76N7Tp/G74criB5A=; b=L1PUY9vm53vlVZN9McVtt1ntmD+lbgpY65zqFC4MAHnsPv9eq2Oq8chnx0EWmf4Zg+ S/2ENYzSoRbhrxn+9YC0ib3v4V1MhXyEtwsjRq7GWX4IW/BlKQ+uCEM8ZYXkYacuCNlL miiZTXevUVbwxYopODJhkyTFrQ7f+y5tDcWE4toEo7Twj9T3SdMDBGYVyJFfGGC+HpYQ Je+mFrYLZTqvVb1T2wy7VzKvGZFHuygPbk7v5sKdUaV4R0OlQTVAQBkmDXWrD/18/HDt jW2PqBheQZ19KxNY/Sann4kFIo3vK6ppItnaJIQDb7eHFUJ89THqdgysI4dcdiaTro4W SrhQ== 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=GI+c3WPj5Lk4POkFBTZYWuRpqWe76N7Tp/G74criB5A=; b=mIs8USlZwulAj1QMaixYRzZa6TuNN9ywcWrb67WIpSVfinUmh5p8GSSo8bZPiQCFKp TB6XLfVxkE1JCOTMUxhTov6JbfyX9CO5gGP7S12HaXYX6eUdyAN5BDwQyCt4hYU0vqtK U8E0dd64OocAyDv60nP8ua/Xrza5zy1kQNFrreZYWCGLHhaEBuTABikEzJpphLw+ALd5 mgQMusX695Gyfurrq/0iKZ2n6AQq8htx40CF2eQWoGPq16feGQ0R0Zgo+MO+8nDeRce8 kMnz7UOZZBzbN0EWSOsNoxuxSLT4VGp2xBeQSW1LCZPsdQdK8QGrrTKYqK7gkafRvj3k h73w== X-Gm-Message-State: AGRZ1gKDBE5mcQDuVIqdLUjTYswhA2EJRW65R7XAL8R0zu3OcYQtjGpO /nK5eSPdrQrUfDWfsTALqNTztAjjYXMYtNcW8bAWXIqiRxk= X-Google-Smtp-Source: AJdET5cTvkNrXPPqo54ITn4P2h2V1Io0BwhmSWF0Q2Rv1JJonJWHRfFX4w+aVRI87uT35StsxNedIvZUk5T0gWKqSu8= X-Received: by 2002:a5e:c246:: with SMTP id w6-v6mr651938iop.302.1541606507953; Wed, 07 Nov 2018 08:01:47 -0800 (PST) MIME-Version: 1.0 References: <23522.60902.31643.819149@gro.dd.org> In-Reply-To: <23522.60902.31643.819149@gro.dd.org> From: Ben Schwartz Date: Wed, 7 Nov 2018 11:01:35 -0500 Message-ID: To: David Lawrence Cc: resolverless-dns@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000005455ee057a153c26" Archived-At: Subject: Re: [Resolverless-dns] 103 Unofficial Side-meeting Notes X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 16:01:52 -0000 --0000000000005455ee057a153c26 Content-Type: multipart/alternative; boundary="0000000000004aeb2f057a153c2b" --0000000000004aeb2f057a153c2b Content-Type: text/plain; charset="UTF-8" On Wed, Nov 7, 2018 at 8:51 AM Dave Lawrence wrote: > Ben Schwartz writes: > > This still seems like the most promising option to me, particularly > > because it preserves the DNS defense against stolen key attacks. > > It also keeps things well within our existing model of understanding > delegation of authority for Internet resources without relying on > third parties. As a side benefit, maybe this is also another kick in > the pants for DNSSEC adoption. > > > > Supercookies > > > > Everybody should check out https://dnscookie.com/ for a demo of > > this. > > ERR_CONNECTION_REFUSED > Argh, looks like it's ironically http-only. http://dnscookie.com -- > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns > --0000000000004aeb2f057a153c2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 7,= 2018 at 8:51 AM Dave Lawrence <tale@dd.o= rg> wrote:
Ben Schwartz writ= es:
> This still seems like the most promising option to me, particularly > because it preserves the DNS defense against stolen key attacks.

It also keeps things well within our existing model of understanding
delegation of authority for Internet resources without relying on
third parties.=C2=A0 As a side benefit, maybe this is also another kick in<= br> the pants for DNSSEC adoption.

> > Supercookies
>
> Everybody should check out https://dnscookie.com/ for a demo of
> this.

ERR_CONNECTION_REFUSED

Argh, looks like= it's ironically http-only.=C2=A0 http= ://dnscookie.com

--
Resolverless-dns mailing list
Resolverless= -dns@ietf.org
https://www.ietf.org/mailman/listinfo/resolver= less-dns
--0000000000004aeb2f057a153c2b-- --0000000000005455ee057a153c26 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 wNjwu8B4MA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCD/wN0stVEx1Gi1MFxdKI5b AQQrUvfHPHfE/Bf6Xl9OxjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODExMDcxNjAxNDhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAEruBOfzcBZQ5ZvQb9ylnw0P9jtHP3KLFgotWXqZG DqVtXngZleXZ+mRNEd2WhW20a5D1pUp1cVhwUrr+LFiIzjXYaZldk3WJHTOpzNst0CjfE6vtW4t1 Fm39M9wFl8lz/62Rth1Tda8fArTyIO3y95eTAhgfXF4PS4pjiKK2x9jflVnZcvdYG6nP4OHnkPgp Q9plo07O4tCKBY8dFsnxYXemG2NNWI50SVvlJJDDeSWd7sdRSB+mzDzdaDliYuZcZiH0RW9HGn0P nF+KY4zKTsiKQAUdJD+fvwFIzxUtF19rOXe29KQf3AUW81CfqYagXn07Kd/cF3JyIW4L4aF5eg== --0000000000005455ee057a153c26-- From nobody Wed Nov 7 20:35:29 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E957130E57 for ; Wed, 7 Nov 2018 20:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.945 X-Spam-Level: X-Spam-Status: No, score=-15.945 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_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 tAaETxaetv8L for ; Wed, 7 Nov 2018 20:35:23 -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 D5B06130DD1 for ; Wed, 7 Nov 2018 20:35:22 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id v24so6735605uap.13 for ; Wed, 07 Nov 2018 20:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2pukenmn4nO49iXEPGYF8VnHZU+ltlMS1++bBSFNJYE=; b=u1atTBLzoRsBwPPwpKlE4MN6kBOWsFtNji5yKUl5j4E4h8GV9UbRuE0LLAWS7ZorFI b1P+yxwAS8SuOjKcmM4XR8pBJyzquuWrQ1t4XYmtyGpC12MheQIuNRivSFSID8vlaEh2 Lrm1MGJwlJF20IJ7L+zHS/GifaFCfhjJDSk+i2KGyTdekxxgYZz7EMzJyUUld+zmOWZu Yko6A4da9jM349G0NELqFFKpesUm0RSbaiP3raKmJVj1nZIGe4o5L1LL2Z8vT2PzhIrU 1rb3x/LMhIKmrpmF1GCa8VIcVIz4VFrg2d8CYxzs+hh/1sbkWRLZQOrjCMhVlemJgkYJ c5hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2pukenmn4nO49iXEPGYF8VnHZU+ltlMS1++bBSFNJYE=; b=kA4nnE5li8LL2+n8XfGl/wsJEQ6bE7Uck3etRqiBFRLydH3SCX0I89LENsmtzE79Tm gWm17//YI002aDWIILNkspwuBq8z6zH48pGMXHUAz2ko7jvUFFjvkBrBVF+EsxH+r7q+ fG9Toof9VizjQi6vRMNuxyFN0K4EbyhTWs1aA9mo/zQOo6OkHZKzQzs9YyoCUUPnMepy 5P0NWJuU+IQCJzWcy0BApUFV0xew1sFc16mehm5fZK63kBqvhV94DmiV6YQ91cMtxMyI TxCUzwhC0G9DcD9RxWgIApJ/Ag70G9nt7rZ0mzSaLgP4vH+tqXvAO3gSEBO3Go0YvHii uh7A== X-Gm-Message-State: AGRZ1gJ0OXE4S30LZU5AVPL0BxxkGN8sbSttffFu9Uyi6Vgr0clLIN8X 61+uBSmnX0s0u2tFRfDggWZ2eA8z+t5RqoQnmNF7GmiBgSc= X-Google-Smtp-Source: AJdET5dlJH0AVtV3K39vMmUGUGdgeOlqaIHmxJuK+Yu6LUzu2XjQNFJIGHNNr4hFuP+O9Taf3Ix+KRXU2l9B3d+GynM= X-Received: by 2002:a9f:386c:: with SMTP id q41mr1389349uad.27.1541651721404; Wed, 07 Nov 2018 20:35:21 -0800 (PST) MIME-Version: 1.0 From: Justin Henck Date: Thu, 8 Nov 2018 11:35:09 +0700 Message-ID: To: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="0000000000003942b3057a1fc38d" Archived-At: Subject: [Resolverless-dns] Load-balancing concerns X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 04:35:26 -0000 --0000000000003942b3057a1fc38d Content-Type: text/plain; charset="UTF-8" Hi all, Some people mentioned load-balancing concerns during the meeting. Ben Schwartz pointed out to me that if a potential solution included DNSSEC, then the server would have to push an entire RRSET. If we combine that with random IP selection by clients and AltSvc to solve geographical misdirection, would that alleviate load balancing concerns? Justin Justin Henck Product Manager 212-565-9811 google.com/jigsaw PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B --0000000000003942b3057a1fc38d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Some people mentioned load-balancing = concerns during the meeting.=C2=A0 Ben Schwartz pointed out to me that if a= potential solution included DNSSEC, then the server would have to push an = entire RRSET.=C2=A0 If we combine that with random IP selection by clients = and AltSvc to solve geographical misdirection, would that alleviate load ba= lancing concerns?

Justin
=
=
Justin He= nck=C2=A0
Product Manager=C2=A0
212-565-9811=C2=A0
google.com/jigsaw

PGP: EA8E 8C27 2D75 974D B357 482B 1= 039 9F2D 869A 117B
<= /div>
--0000000000003942b3057a1fc38d-- From nobody Wed Nov 7 22:33:49 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD7A130DE2 for ; Wed, 7 Nov 2018 22:33:49 -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 QoSpq07W6DlZ for ; Wed, 7 Nov 2018 22:33:47 -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 337A012D4ED for ; Wed, 7 Nov 2018 22:33:47 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 87FB332894; Thu, 8 Nov 2018 01:33:45 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23523.55497.532269.465187@gro.dd.org> Date: Thu, 8 Nov 2018 01:33:45 -0500 From: Dave Lawrence To: resolverless-dns@ietf.org In-Reply-To: References: Archived-At: Subject: Re: [Resolverless-dns] Load-balancing concerns X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 06:33:49 -0000 Justin Henck writes: > Some people mentioned load-balancing concerns during the meeting. > Ben Schwartz pointed out to me that if a potential solution included > DNSSEC, then the server would have to push an entire RRSET. If we > combine that with random IP selection by clients and AltSvc to solve > geographical misdirection, would that alleviate load balancing concerns? I'm afraid I don't understand the connection you're making. What does the setup, "would have to push an entire RRSET", have to do with the rest of "If we combine that..."? I'm not clear on how DNSSEC makes any difference at all in this particular problem. My guess is that you are imagining a situation where all possible addresses that clients could receive are put into one A or AAAA RRset. This isn't the way most such systems work though. For example, one CDN puts only the addresses it wants a particular client to use into the answer, with the appropriate signature. If you then learned addresses for another client, with its own signature for the RRSet, there's no way to combine those different answer sets into one and still have it validate. Even if you could combine them, random selection would then largely defeat the way the CDN is trying to direct traffic, but for the occasions where the random guess was right. Of course, a DoH server which has used EDNS Client Subnet (or some other internal mechanism) to know appropriate client-based answers can just use the appropriate RRset and signature and be as true to the load-balancing and geo-redirection intents as if the client had just asked through conventional DNS. If the DoH server can't do ECS or otherwise have mapping information from the authority, any customized answers it gets will be resolver-mapped just like a client talking to any traditional non-ECS resolver. It's really hard to imagine how it could be otherwise without even more significant changes to the way things are done now, far beyond random IP selection. From nobody Wed Nov 7 22:44:32 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B8D130DC8 for ; Wed, 7 Nov 2018 22:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 bIRvhEFuyths for ; Wed, 7 Nov 2018 22:44:29 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 400BA130E04 for ; Wed, 7 Nov 2018 22:44:29 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id k206-v6so161963ite.0 for ; Wed, 07 Nov 2018 22:44:29 -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=YAoysYwL1CpgBshH9vJx8xXdyhSekivEaYBVQjSsSCU=; b=CWBpsFpmXTOBbjsBJmJhkzklzB39dfxmS4P/Ie+roizhm7OooCS5P/JdkRrYhhqwuo ozQwinfIOyu726AtHrNOctlxkAWH3xaODPws+CZLylUuFvMheQ1lLuSUVPohQB74BCMC hUEIctF2h5nSAxb7RBIglDKLRjMGUY3BXA2mlul8MKIxBwtoLTFmKAddAhojbDXpsHGd aKNmNrCpmBFJ9sZ3ZfVOap2LshA6t5dc5wZvaH2CE+M6cYyA9wcqlUM2sQkEQdSdvIoe ngFCvNXvoHaSSO4ch8EdEPlRDO+uJtLWJAMKWIb9syxnCnG9uDfLFj932XV8zkonJtz1 iYng== 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=YAoysYwL1CpgBshH9vJx8xXdyhSekivEaYBVQjSsSCU=; b=Pw/7tO4d837BbBvwLPzmqvGjiJcpgxgd9g1AydREIQ27OdIoTbHWbpge2UO1Y0LlIz f3mB5cmhr9B6fWvXh84JhAE1oZUlIrMC6jORZmDzzxCkI4T/4qojm7OiqELFtj+V5meE /g7/k2ZHDFAxVG5XCKPlXwie3t7CwQj+jyUU5emGf+LNFB9zr83cB1q+OXG5Wth4rb+T poBLvW1CJYd4VCnAERng05ftsmoNa6hI+c3M5ShCmj8AQFxXq8LHgt4fAxyr8GV5q51i UANnV4+EwwbBHzvvw1s9dThSIAh4g6LS8yTgBa/vfahUCpwSlqSPxeyEX+TxE7mPuEmE 4L/Q== X-Gm-Message-State: AGRZ1gJVmIR7D19WWw2h0BsYsA6dhqqfj8K3WnGkzXIDWV4ug1RX3NDZ r1evo5+UemuYl7gC4vmSMccYkWRL4KYtLo3Df6/+pu8X X-Google-Smtp-Source: AJdET5fDhx9yi0HcnqT7bhI9IFX2Q+uKElTCE9q00bS6isB0s512L7ufj7lLBtILGUfsznh7jFYbZodkdPtYyJ294qg= X-Received: by 2002:a02:94d:: with SMTP id f74-v6mr3214869jad.85.1541659468411; Wed, 07 Nov 2018 22:44:28 -0800 (PST) MIME-Version: 1.0 References: <23523.55497.532269.465187@gro.dd.org> In-Reply-To: <23523.55497.532269.465187@gro.dd.org> From: manu tman Date: Thu, 8 Nov 2018 13:44:17 +0700 Message-ID: To: Dave Lawrence Cc: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="000000000000fabaa8057a219064" Archived-At: Subject: Re: [Resolverless-dns] Load-balancing concerns X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 06:44:31 -0000 --000000000000fabaa8057a219064 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 8, 2018 at 1:33 PM Dave Lawrence wrote: > If the DoH server can't do ECS or > otherwise have mapping information from the authority, any customized > answers it gets will be resolver-mapped just like a client talking to > any traditional non-ECS resolver. > Except that it will be based on the IP of the DoH server and not the resolver of the client, which in most cases will be more representative of the actual network location (ISP or subnets of ISP) of the client. The DoH server will most likely be mapped to the =E2=80=9Cbest=E2=80=9D loc= ation for the majority of the clients using the service at the cost of totally bad selection for the ones that don=E2=80=99t fall in the majority bucket and i= ts neighbors. Manu --000000000000fabaa8057a219064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu,= Nov 8, 2018 at 1:33 PM Dave Lawrence <ta= le@dd.org> wrote:
=C2=A0If= the DoH server can't do ECS or
otherwise have mapping information from the authority, any customized
answers it gets will be resolver-mapped just like a client talking to
any traditional non-ECS resolver.

Except that it will be based on = the IP of the DoH server and not the resolver of the client, which in most = cases will be more representative of the actual network location (ISP or su= bnets of ISP) of the client.

The DoH server will most likely be mapped to the =E2=80=9Cbest=E2=80= =9D location for the majority of the clients using the service at the cost = of totally bad selection for the ones that don=E2=80=99t fall in the majori= ty bucket and its neighbors.

Manu
--000000000000fabaa8057a219064-- From nobody Wed Nov 7 23:04:53 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFB7130DC2 for ; Wed, 7 Nov 2018 23:04:52 -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, MARKETING_PARTNERS=0.001, 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 SQDrmjMJMMAe for ; Wed, 7 Nov 2018 23:04:51 -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 6D8981294D7 for ; Wed, 7 Nov 2018 23:04:51 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id EF8A6328A5; Thu, 8 Nov 2018 02:04:48 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23523.57360.956625.553332@gro.dd.org> Date: Thu, 8 Nov 2018 02:04:48 -0500 From: Dave Lawrence To: resolverless-dns@ietf.org In-Reply-To: References: <23523.55497.532269.465187@gro.dd.org> Archived-At: Subject: Re: [Resolverless-dns] Load-balancing concerns X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 07:04:52 -0000 manu tman writes: > Except that it will be based on the IP of the DoH server and not the > resolver of the client, Right, as I said (or thought I said). > which in most cases will be more representative of the actual > network location (ISP or subnets of ISP) of the client. I question the validity of this assertion. It seems to be making a huge assumptive leap about where the server providing the records is and what its network relationship to any given client is, and completely discounting typical resolver locality. "in most cases" will need some data to support it, and it's way too early in the brave new DoH world to have good data on that. Personally I expect DoH to be used in a variety of environments, not just by the biggest providers with worldwide footprints. > The DoH server will most likely be mapped to the best location for > the majority of the clients using the service Who said the DoH server is getting mapped at all, or has any locality to the additional resources it is trying to provide access to? Imagine a pretty reasonable set up where some website which only has a handful of deployments, say a couple in North America and a couple in Europe, wants to point records for one of its partners which actually has a much broader footprint. An Asian client connected to one of the North American data centers and getting American-mapped answers when the partner site would much rather have preferred you be using one of their Asian installations if only you'd asked through normal DNS. That's just the simple case of network-performance mapping anyway, and completely ignores other mapping From nobody Wed Nov 7 23:10:29 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B376E1294D7 for ; Wed, 7 Nov 2018 23:10:27 -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 38LDva7lk0AI for ; Wed, 7 Nov 2018 23:10:26 -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 2DC27130DE2 for ; Wed, 7 Nov 2018 23:10:26 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 3E4EE328AF; Thu, 8 Nov 2018 02:10:25 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23523.57697.230183.472983@gro.dd.org> Date: Thu, 8 Nov 2018 02:10:25 -0500 From: Dave Lawrence To: resolverless-dns@ietf.org In-Reply-To: References: <23522.60902.31643.819149@gro.dd.org> Archived-At: Subject: Re: [Resolverless-dns] 103 Unofficial Side-meeting Notes X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 07:10:28 -0000 Ben Schwartz writes: > http://dnscookie.com This apparently has no relation to RFC 7873, "Domain Name System (DNS) Cookies", correct? Could it be renamed to avoid confusion? From nobody Wed Nov 7 23:35:49 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C0C128DFD for ; Wed, 7 Nov 2018 23:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 8YRN0SfHVSyh for ; Wed, 7 Nov 2018 23:35:46 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 5DC59127332 for ; Wed, 7 Nov 2018 23:35:46 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id k141-v6so297091itk.3 for ; Wed, 07 Nov 2018 23:35:46 -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=TxC2hKGO0bGz2u0mXfAnsQpwNh9aXwk6DPkcTYR2eD0=; b=kUwGJofYy2/RY9KXK8iFRI+QqBUB2ekn3rYIU5VLHzo1242+p807pbca0bErqfUs7h 4wWNki6K+4sA9HT/YO8sUeNESXdbdAZvX5OY7lV53CNx5mDKfQvPho0aViYrK3KSzdNN PgY/MTJpqsXtwVPfSfgoYJIIoToCULklI5JMLJbuqii9PPzs7Xeot9vTvJmVmJKczOCs 2XIKeJ7mSoP4YYuWPuiHtnkYca4Lpj1Uw8llYHu27YjWlcJBqBBHF9szDDeHQc+j2tcE PD6vUFwzKKPdk+q5Mr8q/CdB5vcVXiyqYWoC0OtyiIH/6ifBpVKV7dpsnoMZuB6mFjM1 FGjQ== 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=TxC2hKGO0bGz2u0mXfAnsQpwNh9aXwk6DPkcTYR2eD0=; b=evpnj40sZ3O93gRVgxijfgIHdAyqD3ZDryZK95xe2JdTyCI1m0gNtmX77ylD2yRQPh km7Y9AJelzPJlMdGkUJWiyUqiQxWOzgW2UXBjkbqmDBQaSQs8CZpFtbu+lhjL773Twx9 xCdXDDSTjfFF0HV21Vkcz54Z3+wKJOP/ZoPYhPU3D9MLhF9Tksjz7HtWCoStZ1FJ1X3b dzldsmq5S7qulc8MXXOOL/P9RReRO7yipoZCw6MBTXGNcKfwmfbo0CNX3im2uYQ71cdE V+mWukYR0omblSWjAl53fPYLPSJtkrK2bPnU3xRMxhMsoKfl6fYgI4gCkH+ElISSD666 g9XQ== X-Gm-Message-State: AGRZ1gIjjW62np+WOmQc03f1HUANjyHj/OMV928ZMXHbNxB9pjGTRY4T 15xCyi7AZafnHnMDLBNtsQSulhFfdpx3DqJcb3Ua2EX4 X-Google-Smtp-Source: AJdET5eFkrjqb/CTH11EqL+F90JepFm9NTJvAolS0tCPqtGyjJg/IqWFqlPISVJ1eJubsBJGsz8yECcLWVxHyn6bU8Q= X-Received: by 2002:a24:f982:: with SMTP id l124-v6mr123511ith.115.1541662545601; Wed, 07 Nov 2018 23:35:45 -0800 (PST) MIME-Version: 1.0 References: <23523.55497.532269.465187@gro.dd.org> <23523.57360.956625.553332@gro.dd.org> In-Reply-To: <23523.57360.956625.553332@gro.dd.org> From: manu tman Date: Thu, 8 Nov 2018 14:35:33 +0700 Message-ID: To: Dave Lawrence Cc: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="00000000000064ebfd057a2248b9" Archived-At: Subject: Re: [Resolverless-dns] Load-balancing concerns X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 07:35:48 -0000 --00000000000064ebfd057a2248b9 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 8, 2018 at 2:04 PM Dave Lawrence wrote: > manu tman writes: > > Except that it will be based on the IP of the DoH server and not the > > resolver of the client, > > Right, as I said (or thought I said). > It was not clear to me, you mentioned it would be resolver-based but this resolver is now unrelated to the original resolver. I may have missed the > > > which in most cases will be more representative of the actual > > network location (ISP or subnets of ISP) of the client. > > I question the validity of this assertion. It seems to be making a > huge assumptive leap about where the server providing the records is > and what its network relationship to any given client is, and > completely discounting typical resolver locality. "in most cases" > will need some data to support it, and it's way too early in the brave > new DoH world to have good data on that. > I am referring to the recursive resolver of the original client, not the DoH server that would now return records. Before resolverless, you would return answers based on client recursive resolver IP (which I assume is somewhat "close" to the end user, but don't have data to back this up with), with resolverless dns, it would be based on the IP of the DoH server (or the recursive resolver used by that one). > > Personally I expect DoH to be used in a variety of environments, not > just by the biggest providers with worldwide footprints. > > > The DoH server will most likely be mapped to the best location for > > the majority of the clients using the service > > Who said the DoH server is getting mapped at all, or has any locality > to the additional resources it is trying to provide access to? > > Imagine a pretty reasonable set up where some website which only has a > handful of deployments, say a couple in North America and a couple in > Europe, wants to point records for one of its partners which actually > has a much broader footprint. An Asian client connected to one of the > North American data centers and getting American-mapped answers when > the partner site would much rather have preferred you be using one of > their Asian installations if only you'd asked through normal DNS. > This is what I wanted to say and failed at apparently. I did not mean to contradict your statement, but rather support it. That being said, chances are that if the majority of the users that use the first North American server are actually Asian users, chances are the effect will be that North American users will end up being sent to the Asian servers of the second site instead of the North American one. As you said, this is network performance mapping, not geo locality. > That's just the simple case of network-performance mapping anyway, and > completely ignores other mapping > > -- > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns > --00000000000064ebfd057a2248b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Nov 8, 2018 at 2:04 PM Dave Lawrence <t= ale@dd.org> wrote:
manu tma= n writes:
> Except that it will be based on the IP of the DoH server and not the > resolver of the client,

Right, as I said (or thought I said).

I= t was not clear to me, you mentioned it would be resolver-based but this re= solver is now unrelated to the original resolver. I may have missed the=C2= =A0=C2=A0

> which in most cases will be more representative of the actual
> network location (ISP or subnets of ISP) of the client.

I question the validity of this assertion.=C2=A0 It seems to be making a huge assumptive leap about where the server providing the records is
and what its network relationship to any given client is, and
completely discounting typical resolver locality.=C2=A0 "in most cases= "
will need some data to support it, and it's way too early in the brave<= br> new DoH world to have good data on that.

I am refe= rring to the recursive resolver of the original client, not the DoH server = that would now return records. Before resolverless, you would return answer= s based on client recursive resolver IP (which I assume is somewhat "c= lose" to the end user, but don't have data to back this up with), = with resolverless dns, it would be based on the IP of the DoH server (or th= e recursive resolver used by that one).

Personally I expect DoH to be used in a variety of environments, not
just by the biggest providers with worldwide footprints.

> The DoH server will most likely be mapped to the best location for
> the majority of the clients using the service

Who said the DoH server is getting mapped at all, or has any locality
to the additional resources it is trying to provide access to?

Imagine a pretty reasonable set up where some website which only has a
handful of deployments, say a couple in North America and a couple in
Europe, wants to point records for one of its partners which actually
has a much broader footprint.=C2=A0 An Asian client connected to one of the=
North American data centers and getting American-mapped answers when
the partner site would much rather have preferred you be using one of
their Asian installations if only you'd asked through normal DNS.

This is what I wanted to say and failed at a= pparently. I did not mean to contradict your statement, but rather support = it.
That being said, chances are that if the majority of the users that = use the first North American server are actually Asian users, chances are t= he effect will be that North American users will end up being sent to the A= sian servers of the second site instead of the North American one. As you s= aid, this is network performance mapping, not geo locality.

<= /div>

That's just the simple case of network-performance mapping anyway, and<= br> completely ignores other mapping

--
Resolverless-dns mailing list
Resolverless= -dns@ietf.org
https://www.ietf.org/mailman/listinfo/resolver= less-dns
--00000000000064ebfd057a2248b9-- From nobody Wed Nov 7 23:53:45 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE18130E34 for ; Wed, 7 Nov 2018 23:53:44 -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=unavailable 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 Dzvlz1YxEono for ; Wed, 7 Nov 2018 23:53:41 -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 AB4E6130E10 for ; Wed, 7 Nov 2018 23:53:41 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id DB62A5F40221; Thu, 8 Nov 2018 08:53:40 +0100 (CET) Received: from [172.19.152.185] (dhcp-8a4f.meeting.ietf.org [31.133.138.79]) (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 E09375F40221; Thu, 8 Nov 2018 08:53:37 +0100 (CET) From: "Ralf Weber" To: "Justin Henck" Cc: resolverless-dns@ietf.org Date: Thu, 08 Nov 2018 14:53:33 +0700 X-Mailer: MailMate (1.12.1r5552) Message-ID: <8FADE530-60F2-4105-8F1D-EDAB1159D88F@fl1ger.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Resolverless-dns] 103 Unofficial Side-meeting Notes X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 07:53:44 -0000 Moin! On 6 Nov 2018, at 21:42, Justin Henck wrote: > Hi all, > Thanks for attending the side-meeting today. Though there are clearly > some > issues to resolve, there were three specific proposals put forward > during > and after the meeting for pushing DNS records or similar information. > (Listed below in the order they were presented.) Since I'm a newcomer, > what > seems like a good goal for 104? > > Proposal 1: DNSSEC-signed: Any outbound link or resource from a site This has the problem that the information the http server has might be signed, but still could lead the user to a bad endpoint from a CDN perspective as the DNS query probably was done with the IP of the http server and not the client. Yeah I know there is ECS for this, but most authoritative servers only accept that when you are whitelisted. > Proposal 2: ??: CDN-local links or resources This is the only way that potentially could work, but even then you loose all the security properties your resolver normally provides you and it totally is possible for bad guys to serve traffic over a CDN. > Proposal 3: Within TLS: Any automatically loaded resource, perhaps in > the > HTML Seems similar to 2, maybe a bit wider, but still could be used to attack you. I think we have to recognise the case that an attacker controls the endpoint you connect to and can circumvent security measures you have in a your resolver which might be protection agains DNS rebinding (sneaking in a public name to point to your RFC1918) for homes and enterprises, or might start a phishing attack by sneaking in a IDN near identical name (goᴏgle.com. - look closely if you would have catched this real domain is xn--gogle-n29a.com. ) and then directing you there. In both cases your security properties possibly get worse when using resolver less DNS. So long -Ralf —-- Ralf Weber From nobody Thu Nov 8 00:19:39 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4E1130DD9 for ; Thu, 8 Nov 2018 00:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 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, 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 NSijeO93BURn for ; Thu, 8 Nov 2018 00:19:35 -0800 (PST) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 85B1A1294D0 for ; Thu, 8 Nov 2018 00:19:35 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id d8so6893436ual.2 for ; Thu, 08 Nov 2018 00:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8vG13YZiCyPM7PrDI/XX79C7PYCQswVmEoDvz1gl/HI=; b=Oa8DmPd6DRl89fCN/w1wd8v3kYcG9OUEZ2A638RPr3UsE1lvoPRsqW5vTo4LdWsiOm 72ZNDQSBW7QD0Frq/zVK2CBK85aoN1DtVkqeSswyoSplNX2Zh+Dmp9aKI2C4FzJE1c29 DWwEQQnexsEV9Q0OPj6Z81LH2RhyIRuJcXuHuc97W4yN0U+60ogOgsGgftvSAfwLLVI9 G1ANoC5KlHLyO59ugqg/3MqoK8ACwFiEdtVm9xzb59c3q30+b73LzBh4s8BQHY4rtqdI uitH6tnAAOPbLnB7ZzQO6SVmH5Nocyg550vRZJkIdF0ZPhar91ObA2p+8Doke/7emk2z LjOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8vG13YZiCyPM7PrDI/XX79C7PYCQswVmEoDvz1gl/HI=; b=lv5TfgouBoc/HJk3Bwi2yj9KxdIVUJutrhAA0QUlHaPhNlJIuS0D7j1UQMd5/yJJXf R4qUkv2dm+BaveUTJI3M09JO05i3myU9LOJNHoa+xtMPRz/E/Qf06qkJlUt+dMnRDXJX OMn03x9pGXvHqqrP615aKi+s4llvFf4ospp1HV96Ptna9Qro6L1eplV29PUBhrDV8gpd M6Fnjn24yrBGUAg/sZQdmXD1cwFMtHxNMS+YAyVnQti+2UfM/qBgi5t46HjiQ/AVn2o1 lmeEpATUmDjrNYjbnrsCTMXtdoNOE+SZse5QY6Yjggv396IQuwDFqkUvFVVOkkzlCDH0 a82w== X-Gm-Message-State: AGRZ1gJKKrKn/TSbyvHGsKvytdH5aG5giCi47igmJ0nndstnDXCyTYru urSyTR5cKWQJpzw1WEoiG1CEP9EH0jdSDxLre7yawB5KGwTl6A== X-Google-Smtp-Source: AJdET5dSz21BhYW0iTSV4rNOjxJtahj/q0qgpC6urslBNzYfmN8J/49FTEMQAaAgV4/5LlYjZ8YAlSHG/LP/zJnIAN4= X-Received: by 2002:a9f:2622:: with SMTP id 31mr1663613uag.90.1541665173931; Thu, 08 Nov 2018 00:19:33 -0800 (PST) MIME-Version: 1.0 From: Justin Henck Date: Thu, 8 Nov 2018 15:19:21 +0700 Message-ID: To: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="0000000000000e6834057a22e544" Archived-At: Subject: Re: [Resolverless-dns] Load-balancing concerns X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 08:19:38 -0000 --0000000000000e6834057a22e544 Content-Type: text/plain; charset="UTF-8" > > > I'm afraid I don't understand the connection you're making. What does > the setup, "would have to push an entire RRSET", have to do with the > rest of "If we combine that..."? I'm not clear on how DNSSEC makes > any difference at all in this particular problem. > > My guess is that you are imagining a situation where all possible > addresses that clients could receive are put into one A or AAAA > RRset. This isn't the way most such systems work though. > You'll have to forgive my ignorance - I definitely don't pretend to be an expert in any of these areas. My understanding (please correct me!) was that generally an authoritative will return a single A or AAAA record based on a particular query, but with DNSSEC it will return an entire relevant RRSET. So although there might be multiple such RRSETs you will at least have (perhaps) more than one IP. I was imagining a worst-case scenario (heavily simplified): -----Definitions----- Primary Server - In country "A" Referred Service - Global. Has different sets of servers for different locations/networks Many Users - In country "B" ------Scenario:------ 1. Many Users load page from Primary Server in a short time. 2. Primary Server queries for a record for Referred Service. 3. Primary Server caches a single IP in country "A" for Referred Service 4. Many Users hit single IP for Referred Service which experiences Bad Things The partial alleviation I was hypothesizing about was: ------Scenario:------- 1. Many Users load page from Primary Server in a short time. 2. Primary Server queries for a complete RRSET for Referred Service 3. Primary Server caches country "A" RRSET for Referred Service 4. Many Users' clients pick different IPs for Referred Service and connect to them 5. Many Users' clients receive AltSvc records telling them to use an IP in country "B" for their next connection Pure point of ignorance: To your point about different clients getting different IPs - does that extend beyond the resolver+ECS level? E.g. if 10,000 customers using a mobile carrier in a single city hit their ECS-less resolver for a particular domain, will they get different IPs? Justin Henck Product Manager 212-565-9811 google.com/jigsaw PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B --0000000000000e6834057a22e544 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I= 9;m afraid I don't understand the connection you're making.=C2=A0 W= hat does
the setup, "would have to push an entire RRSET", have= to do with the
rest of "If we combine that..."?=C2=A0 I'm= not clear on how DNSSEC makes
any difference at all in this particular = problem.

My guess is that you are imagining a situation where all po= ssible
addresses that clients could receive are put into one A or AAAARRset.=C2=A0 This isn't the way most such systems work though.

You'll have to forgive my ignorance - I d= efinitely don't pretend to be an expert in any of these areas.=C2=A0 My= understanding (please correct me!) was that generally an authoritative wil= l return a single A or AAAA record based on a particular query, but with DN= SSEC it will return an entire relevant RRSET.=C2=A0 So although there might= be multiple such RRSETs you will at least have (perhaps) more than one IP.= =C2=A0

I was imagining a worst-case scenario (heav= ily simplified):
-----Definitions-----
Primary Server= =C2=A0 - In country "A"
Referred Service - Global. Has = different sets of servers for different locations/networks
Many U= sers - In country "B"

------Scenario:---= ---
1. Many Users load page from Primary Server in a short time.= =C2=A0
2. Primary Server queries for a record for Referred Servic= e.=C2=A0
3. Primary Server caches a single IP in country "A&= quot; for Referred Service
4. Many Users hit single IP for Referr= ed Service which experiences Bad Things

The partia= l alleviation I was hypothesizing about was:
------Scenario:-----= --
1. Many Users load page from Primary Server in a short time.= =C2=A0
2. Primary Server queries for a complete RRSET for Referre= d Service=C2=A0
3. Primary Server caches country "A" RR= SET for Referred Service
4. Many Users' clients pick differen= t IPs for Referred Service and connect to them
5. Many Users'= clients receive AltSvc records telling them to use an IP in country "= B" for their next connection

Pure point of ig= norance: To your point about different clients getting different IPs - does= that extend beyond the resolver+ECS level? E.g. if 10,000 customers using = a mobile carrier in a single city hit their ECS-less resolver for a particu= lar domain, will they get different IPs?

Justin Henck=C2=A0
= Product Manager=C2=A0
212-565-9811=C2=A0
google.com/jig= saw
<= div>
PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B
<= /div>
--0000000000000e6834057a22e544-- From nobody Thu Nov 8 00:47:31 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBC41293FB for ; Thu, 8 Nov 2018 00:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable 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 M-72vh2krZyn for ; Thu, 8 Nov 2018 00:47:28 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB761130E6C for ; Thu, 8 Nov 2018 00:47:26 -0800 (PST) Received: from dhcp-8a2b.meeting.ietf.org (dhcp-8a2b.meeting.ietf.org [31.133.138.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 10BF82420FDE; Thu, 8 Nov 2018 08:47:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Thu, 8 Nov 2018 08:47:50 +0000 Cc: resolverless-dns@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8849CBF3-1950-44BB-95C9-16F35F79E350@rfc1035.com> References: To: Justin Henck X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Resolverless-dns] Load-balancing concerns X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 08:47:30 -0000 > On 8 Nov 2018, at 08:19, Justin Henck = wrote: >=20 > You'll have to forgive my ignorance - I definitely don't pretend to be = an expert in any of these areas. My understanding (please correct me!) = was that generally an authoritative will return a single A or AAAA = record based on a particular query, but with DNSSEC it will return an = entire relevant RRSET. Not quite. If an authoritative server is queried for the A or AAAA = records for some name, it will return all the matching A (or AAAA) = records. [Modulo truncated responses and TCP retries.] It won't return a = single A or AAAA record unless of course there's only one of them. When DNSSEC is used, authoritative servers return RRsets.* That's = because the signature covers the RRset and the validator has to have all = of the original data -- the RRset -- so that it can validate the signed = response. *That's pretty much the same as the unsigned response with the addition = of some extra RRtypes for the DNSSEC special sauce. From nobody Thu Nov 8 01:16:23 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3736D128BCC for ; Thu, 8 Nov 2018 01:16:21 -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 Uw98N_LcnA72 for ; Thu, 8 Nov 2018 01:16:19 -0800 (PST) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 C149712870E for ; Thu, 8 Nov 2018 01:16:18 -0800 (PST) Received: by mail-vk1-xa32.google.com with SMTP id u62so4396969vkb.3 for ; Thu, 08 Nov 2018 01:16:18 -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=DRWlrEMuTac7fcxQFwDqRVSxIUpT+HCoSN5NCJsBzYA=; b=YjkqnBaQJS5bxv4SjUx9vAhXyHvGFrx4v/bcaM8nPoDcF9vAZCSsHmHxdS6xWWDCHE GBNsmo0Qu9uD0PlgKeO8wPzvB8Eeh1gkfkFv6w6hzZGLCAUYnuw4JrabeX2wLK2L3r56 jEIF9XhF1BTuXqDy8zBqo08O6B/v6pCvZVp2M66uOT0a1srGanwtx5YwMdfcKPJZYPjb kxv9oFGZWg55ArOZppkrkF8iExvae/2K6o9MVjQLNNfTtCJy3sBJQ8IQHpkgIV1iONQE SA0qKEqrG34D9OcI6SM+bsqCAHI9yuCWpm7vu8opELVszCSI6HheLE5DRathqQZ6veCM Ii1A== 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=DRWlrEMuTac7fcxQFwDqRVSxIUpT+HCoSN5NCJsBzYA=; b=MOjX4CsI+tZxXhEy6ty+YjhyeD7KHPZFAzqjReTjXkC9LIU1s3acq9V7SVu4So22Cy vU3HzTQ+tbKljJXf33UJneE0/RP+xfqJWI8XHw6zTT1kouqVYwZt7w6HYqq1s36Y+EuA ztvJAjpRGei5IdztukMbckcZAXp870CckmzQEnzsdLGn1lj9Tw8GemXgLFKL/C7/IXsY f+b+6fGc7acqiSeJBdRejaNoDNJ8GqpGbBf5KCVo2LM2ATF7uT634W9OdYN3J681gQOJ s9ppXh3mfAche+E0Jry5uhEmUj3lDlF4GatI5UwOEEGitS22BvpaUMEbyJGFNMX2b4Ib TKCQ== X-Gm-Message-State: AGRZ1gJFecyXdzufUF7HrjZyOX+qpgMFAdxYONgXAalaD/vIkH0XgbcR jLprzQkBtoIetKmN2BiQ30UoS/ph1vDwyrepzuKqpw== X-Google-Smtp-Source: AJdET5dwJvMfRWlgo0M1g2v6+zSroKg3icnYzmmM+LFaY06xAaiiM4wr1GmDjfi+/8TZjIvixhWEZ1C4DJDrOQOwJMY= X-Received: by 2002:a1f:2145:: with SMTP id h66mr1643756vkh.65.1541668577510; Thu, 08 Nov 2018 01:16:17 -0800 (PST) MIME-Version: 1.0 References: <8849CBF3-1950-44BB-95C9-16F35F79E350@rfc1035.com> In-Reply-To: <8849CBF3-1950-44BB-95C9-16F35F79E350@rfc1035.com> From: Justin Henck Date: Thu, 8 Nov 2018 16:16:04 +0700 Message-ID: To: Jim Reid Cc: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="000000000000ed04e2057a23afbe" Archived-At: Subject: Re: [Resolverless-dns] Load-balancing concerns X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 09:16:21 -0000 --000000000000ed04e2057a23afbe Content-Type: text/plain; charset="UTF-8" Got it, I made a mistake and inferred behavior from recursives :-/ How is a "resolverless" (unrequested resolution?) solution here any different from sharing a recursive, if we use ECS or if the primary service is widely deployed? E.g. it seems to me that there are three scenarios: 1) really large globally distributed services implementing will act like geographicaply distributed resolvers, which some of them also are 2) small single-datacenter services won't produce enough traffic to matter 3) large single-datacenter services might cause a problem Are there other negative scenarios? I suppose 1 but not very well distributed? On Thu, Nov 8, 2018, 3:47 PM Jim Reid > > > On 8 Nov 2018, at 08:19, Justin Henck > wrote: > > > > You'll have to forgive my ignorance - I definitely don't pretend to be > an expert in any of these areas. My understanding (please correct me!) was > that generally an authoritative will return a single A or AAAA record based > on a particular query, but with DNSSEC it will return an entire relevant > RRSET. > > Not quite. If an authoritative server is queried for the A or AAAA records > for some name, it will return all the matching A (or AAAA) records. [Modulo > truncated responses and TCP retries.] It won't return a single A or AAAA > record unless of course there's only one of them. > > When DNSSEC is used, authoritative servers return RRsets.* That's because > the signature covers the RRset and the validator has to have all of the > original data -- the RRset -- so that it can validate the signed response. > > *That's pretty much the same as the unsigned response with the addition of > some extra RRtypes for the DNSSEC special sauce. > > --000000000000ed04e2057a23afbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got it, I made a mistake and inferred behavior from recur= sives :-/

How is a "resol= verless" (unrequested resolution?) solution here any different from sh= aring a recursive, if we use ECS or if the primary service is widely deploy= ed?

E.g. it seems to me = that there are three scenarios:
1) really large glob= ally distributed services implementing will act like geographicaply distrib= uted resolvers, which some of them also are
2) small= single-datacenter services won't produce enough traffic to matter
3) large single-datacenter services might cause a proble= m

Are there other negati= ve scenarios? I suppose 1 but not very well distributed?


On Thu= , Nov 8, 2018, 3:47 PM Jim Reid <jim@= rfc1035.com wrote:


> On 8 Nov 2018, at 08:19, Justin Henck <henck=3D40google.co= m@dmarc.ietf.org> wrote:
>
> You'll have to forgive my ignorance - I definitely don't prete= nd to be an expert in any of these areas.=C2=A0 My understanding (please co= rrect me!) was that generally an authoritative will return a single A or AA= AA record based on a particular query, but with DNSSEC it will return an en= tire relevant RRSET.

Not quite. If an authoritative server is queried for the A or AAAA records = for some name, it will return all the matching A (or AAAA) records. [Modulo= truncated responses and TCP retries.] It won't return a single A or AA= AA record unless of course there's only one of them.

When DNSSEC is used, authoritative servers return RRsets.* That's becau= se the signature covers the RRset and the validator has to have all of the = original data -- the RRset -- so that it can validate the signed response.<= br>
*That's pretty much the same as the unsigned response with the addition= of some extra RRtypes for the DNSSEC special sauce.

--000000000000ed04e2057a23afbe-- From nobody Thu Nov 8 01:27:12 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D4E130E83 for ; Thu, 8 Nov 2018 01:27:09 -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 UkBbLpQobPlG for ; Thu, 8 Nov 2018 01:27:07 -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 E89F7130E7A for ; Thu, 8 Nov 2018 01:27:05 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id D699832AB0; Thu, 8 Nov 2018 04:27:04 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23524.360.861432.338830@gro.dd.org> Date: Thu, 8 Nov 2018 04:27:04 -0500 From: Dave Lawrence To: resolverless-dns@ietf.org In-Reply-To: References: Archived-At: Subject: Re: [Resolverless-dns] Load-balancing concerns X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 09:27:09 -0000 Justin Henck writes: > You'll have to forgive my ignorance - I definitely don't pretend to > be an expert in any of these areas. My understanding (please > correct me!) was that generally an authoritative will return a > single A or AAAA record based on a particular query, but with DNSSEC > it will return an entire relevant RRSET. It depends. Non-mapping authorities, the pre-CDN norm and still very common, will return every record matching the qname/qclass/qtype tuple. That's the RRSet. Most names (hand-wavingly most--I confess no data) only had one address for A or AAAA though so your sense that they would generally return a single record is probably apt. The presence or absence of DNSSEC doesn't really change any of the preceding. Then CDNs with their mapping authorities came along and muddied things a bit. Akamai would, for example, generally provide two IP addresses in an answers to any given query, but from a much larger pool. Because the number of permutations was large that also meant CDNs were late to the party on DNSSEC implementation, and didn't offer it at all for a very long time so asking for it wouldn't have changed their behaviour. Now those that offer DNSSEC tend to do so with some form of online signing -- it's way too much to sign all the permutations individually and or to hand out all thousands of addresses in one RRset, so they sign just the one their answering with when they need to, and still only hand out a couple (or few) at a time. So the presence or absence of DNSSEC here also ultimately doesn't make a difference as far as how many addresses a client is seeing in a response. > Pure point of ignorance: To your point about different clients > getting different IPs - does that extend beyond the resolver+ECS > level? E.g. if 10,000 customers using a mobile carrier in a single > city hit their ECS-less resolver for a particular domain, will they > get different IPs? It depends again, but mostly they get the same IPs because caching. It depends a little on what time scale you're looking and other things happening at the time. CDNs can keep mappings pretty stable for long periods of time, so all those clients would tend to get the same addresses over multiple TTL cycles. If a flash mob comes along they might quickly remap the load so that successive refreshes of the cache end up with different addresses. From nobody Thu Nov 8 01:44:54 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23ACB12D4E7 for ; Thu, 8 Nov 2018 01:44:53 -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 Y-3ptaoMZeAM for ; Thu, 8 Nov 2018 01:44:52 -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 0F9E01293FB for ; Thu, 8 Nov 2018 01:44:52 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 470AD32AC2; Thu, 8 Nov 2018 04:44:51 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23524.1427.267084.889272@gro.dd.org> Date: Thu, 8 Nov 2018 04:44:51 -0500 From: Dave Lawrence To: resolverless-dns@ietf.org In-Reply-To: References: <8849CBF3-1950-44BB-95C9-16F35F79E350@rfc1035.com> Archived-At: Subject: Re: [Resolverless-dns] Load-balancing concerns X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 09:44:53 -0000 Justin Henck writes: > How is a "resolverless" (unrequested resolution?) solution here any > different from sharing a recursive, if we use ECS or if the primary > service is widely deployed? The landscape is complicated. In many cases it will offer the same results. In some cases it will be demonstrably more bad. In some cases it might even be a bit better. There are a lot of variables to suss out here. > E.g. it seems to me that there are three scenarios: > 1) really large globally distributed services implementing will act like > geographicaply distributed resolvers, which some of them also are Right this one probably ends up looking largely like a regular recursive resolver now, so is basically fine. > 2) small single-datacenter services won't produce enough traffic to matter I think maybe we shouldn't be cavalier with "to matter", because it could very well matter quite a lot to the clients here. > 3) large single-datacenter services might cause a problem Yep. > Are there other negative scenarios? I suppose 1 but not very well > distributed? Yep, From nobody Thu Nov 8 01:59:48 2018 Return-Path: X-Original-To: resolverless-dns@ietfa.amsl.com Delivered-To: resolverless-dns@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF054130DEA for ; Thu, 8 Nov 2018 01:59:47 -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 aYbTnBMGuD8F for ; Thu, 8 Nov 2018 01:59:45 -0800 (PST) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 D5E80123FFD for ; Thu, 8 Nov 2018 01:59:44 -0800 (PST) Received: by mail-vk1-xa2f.google.com with SMTP id q80so277747vka.6 for ; Thu, 08 Nov 2018 01:59:44 -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=ANDD92kba2+vJLEQWci38hI+h9dW8Ha9BgN9p49HiOI=; b=jEVUahQZJ2jFZEZ6G5i0+4KSkPLbl6/zZz/SMnky48n3EgnqoKTrqVaNVCoomnhnqT bOPJq8yX0Cvn+bvRfNNUkjo3qVZFKFp5n1KY3MGana3hyt9R2YrEwFXu3v0bx+heSfXW n91F6q3Pzj8RzuoTZA1QTOBTqg997dIflH8+JUEZe+tNxynxhA59fuEh64mziQq/vvj3 Ic9WhSi2mRMFi1hyGJd8wTDROqAKgcLupoiqC0PAGaour4WVnCjzbRBy23lVQFtZpluQ JRcgzAOXD5d66/td4CqsAjKlbMIPvdHwsJCd4Mha3Au3r7qkG/bk8nAXP/W+yFZsT6pf ADEQ== 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=ANDD92kba2+vJLEQWci38hI+h9dW8Ha9BgN9p49HiOI=; b=N8zBXqRs4LdvUPl66dZamsmCEoSd7umCwzeDP4JLp79MtPmr3x1rSjWXrt1i+TbScY 1xGxS/f3KPOaZzsRxQ5Q2i5/NkLXSedDb5SglUVpHjx8rhBePekgEnwBUA9qg0iB90BO h/oVJ6+Hr2L1Mo3EOUH5Zar7y5crzdjI7vSbYwkFmimnZrVffpGpCjtRLQrG5BvUaVsp YQlihMOQs72OtfMfBCksnZizaPQ2iTDP9Nm5HYW2MoQKu2G9YW3WXmiTmI/VC9aoVISv DJ1CRyDXwvb0c0YEiqIT7Hq5hjVQ3haOHeXKpjDa3J+6PuWKvukGzhDRZTcBZJhR6hqg Um6g== X-Gm-Message-State: AGRZ1gIBSczWEYsJiz21dI/cKnczkE6/RFN+IZOxS8XIzXznnRW8HA6x DiQywK6GzueJ9+mtIJ/K75Q7bIaZQfkUNGUvC54NJg== X-Google-Smtp-Source: AJdET5frpHA6RgbJbiTkyzooW6tJaBd3IaWQur6XY6ChawEukveUpfKFnEoOIik2j802EXUFfmWkAERTicjGq8j6IZc= X-Received: by 2002:a1f:8804:: with SMTP id k4mr255183vkd.61.1541671183494; Thu, 08 Nov 2018 01:59:43 -0800 (PST) MIME-Version: 1.0 References: <8849CBF3-1950-44BB-95C9-16F35F79E350@rfc1035.com> <23524.1427.267084.889272@gro.dd.org> In-Reply-To: <23524.1427.267084.889272@gro.dd.org> From: Justin Henck Date: Thu, 8 Nov 2018 16:59:31 +0700 Message-ID: To: David Lawrence Cc: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="000000000000411f3f057a244be5" Archived-At: Subject: Re: [Resolverless-dns] Load-balancing concerns X-BeenThere: resolverless-dns@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Resolverless DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 09:59:48 -0000 --000000000000411f3f057a244be5 Content-Type: text/plain; charset="UTF-8" > > > 2) small single-datacenter services won't produce enough traffic to > matter > > I think maybe we shouldn't be cavalier with "to matter", because > it could very well matter quite a lot to the clients here. > Point well taken. I think my definition of small was a bit self-referential. (E.g. small defined as won't produce a heavy load.) But I realize now that there are other reasons beyond load-balancing for wanting to have traffic sent to a particular geographic location. That brings me back to the idea of opt-out or constraints. Are there any minimum use cases that haven't been proposed? What about if the DNSSEC-signed records have to include the ip serving the push? That would suggest that the RRSET might be appropriate for the client. (An obvious exception: an anycast IP signed with a bunch of unicast ones.) Justin Henck Product Manager 212-565-9811 google.com/jigsaw PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B On Thu, Nov 8, 2018 at 4:44 PM Dave Lawrence wrote: > Justin Henck writes: > > How is a "resolverless" (unrequested resolution?) solution here any > > different from sharing a recursive, if we use ECS or if the primary > > service is widely deployed? > > The landscape is complicated. In many cases it will offer the same > results. In some cases it will be demonstrably more bad. In some > cases it might even be a bit better. There are a lot of variables > to suss out here. > > > E.g. it seems to me that there are three scenarios: > > 1) really large globally distributed services implementing will act like > > geographicaply distributed resolvers, which some of them also are > > Right this one probably ends up looking largely like a regular > recursive resolver now, so is basically fine. > > > 2) small single-datacenter services won't produce enough traffic to > matter > > I think maybe we shouldn't be cavalier with "to matter", because > it could very well matter quite a lot to the clients here. > > > 3) large single-datacenter services might cause a problem > > Yep. > > > Are there other negative scenarios? I suppose 1 but not very well > > distributed? > > Yep, > > -- > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns > --000000000000411f3f057a244be5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> 2) smal= l single-datacenter services won't produce enough traffic to matter
=
I think maybe we shouldn't be cavalier with "to matter&= quot;, because
it could very well matter quite a lot to the clients here= .

Point well taken. I thi= nk my definition of small was a bit self-referential.=C2=A0 (E.g. small def= ined as won't produce a heavy load.) But I realize now that there are o= ther reasons beyond load-balancing for wanting to have traffic sent to a pa= rticular geographic location.=C2=A0 That brings me back to the idea of opt-= out or constraints.

Are there any minimum use case= s that haven't been proposed?=C2=A0
What about if the DNSSEC-= signed records have to include the ip serving the push? That would suggest = that the RRSET might be appropriate for the client. (An obvious exception: = an anycast IP signed with a bunch of unicast ones.)
=

Justin Henck=C2=A0
Product Manager=C2=A0
212-565-9811=C2=A0
goo= gle.com/jigsaw

<= span>PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 8= 69A 117B


On Thu, Nov 8, 2018 at 4:44 PM Dave Lawrence <tale@dd.org> wrote:
Resolverless= -dns@ietf.org
https://www.ietf.org/mailman/listinfo/resolver= less-dns
--000000000000411f3f057a244be5--