From nobody Wed Feb 1 12:28:25 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EE312956E; Wed, 1 Feb 2017 12:28:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148598089953.19182.5406854497324968764.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 12:28:19 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:28:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : The ALT Special Use Top Level Domain Authors : Warren Kumari Andrew Sullivan Filename : draft-ietf-dnsop-alt-tld-07.txt Pages : 11 Date : 2017-02-01 Abstract: This document reserves a string (ALT) to be used as a TLD label in non-DNS contexts, or for names that have no meaning in a global context. It also provides advice and guidance to developers developing alternate namespaces. [Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication.This document is being collaborated on in Github at: https://github.com/wkumari/draft- wkumari-dnsop-alt-tld. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. NOTE: This document is currently a parked WG document -- as such, all changes are being handled in GitHub and a new version will be posted once unparked. It had been suggested (off-list) that the draft should contain instead of .ALT, and then make the WG choose a string before publication. A version of the draft like this was published on GitHub (https://github.com/wkumari/draft-wkumari-dnsop-alt-tld/ tree/7988fcf06100f7a17f21e6993b781690b5774472) (and generated no feedback). This version reverts to .ALT -- the chairs stated that the document was adopted with the string .alt, it has been discussed as .alt. IMO, it is more readable as .alt; it would also be a difficult consensus call, boiling down to beauty contests. If the WG selects a different string ("not-dns" had been suggested in the past), the editors will, of course, replace it. ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 1 12:29:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF58129575 for ; Wed, 1 Feb 2017 12:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmd3Sv5Sphci for ; Wed, 1 Feb 2017 12:29:01 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 88FFC12956E for ; Wed, 1 Feb 2017 12:29:01 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id x49so282720988qtc.2 for ; Wed, 01 Feb 2017 12:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=cLesYfGObPRL4Bx30tas2+w8DjqwRTt82FtE0YJ0H7w=; b=U1jKxxNZPWO4aSulA74XNSnz+cN/DKPqvM78l/TAaYen6y6W4FUmVDXGBueEbIeiVE PU1tzDI6XNiAX7SQcdxry/lcgyk4i8bEufeQFe1GaqEuCyM9zi5oXgOlxFpVo5krz5FU faMFSHNvo2tFOwc5EvCYKN2iNPKHHH4NyuNDbbeAt0OeROnzXez6VQmh1wIArvGvIrFq xjcDVU46VQWM9dq7inqTFclBSyaoySXJoM3VDbGKp8PRKpoPgrA2cs2IkzrEmhtRgZjM GoocuLKJTSSQkZhHDZ4yezVNQkL0JW4BK6RWG9FFoyl6HlttdJ7BDQYtMRp7Ym9z4Npc Oikg== 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=cLesYfGObPRL4Bx30tas2+w8DjqwRTt82FtE0YJ0H7w=; b=BkQngGouYCcmSEunueHCdt/AAqbysuZi7ZpSLql0SIkoBjusXMIjJubBM205JlP1/x A/Z0655cGPXcLjMTN7PYnOsrso6w3zZwDqRwBsGT4ZMviWlTbC56hEYxztGAK/EEkIf2 xGwFrqaIUrg8yGQQGxcBeeEO4q5EJ+UJpixLUQuwiUr9KIuHBY1CnQEIaFFawFIxjkyV Z0ge23gRravUgoQ0XaxUBI5efQrU2SGO/ZdQZGtuNrTUzvldvbR1J+bgIla6thFt0dBR wLnD7dPIdrJzon1g6PmCzo2kO7YOJPMjtUDCBPZKUiGnv1O+9+vvGy4I7mD3uPiMKoFB ipXA== X-Gm-Message-State: AIkVDXLTrOcOeSXFbFAdEZ0mmZ7on45uUpC5tkrkb4bB6DTV5WCp6y4g0GL+dPwKWU7eDaM7p75E4+wLd4grlH/k X-Received: by 10.55.189.130 with SMTP id n124mr4869488qkf.235.1485980940262; Wed, 01 Feb 2017 12:29:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Wed, 1 Feb 2017 12:28:29 -0800 (PST) From: Warren Kumari Date: Wed, 1 Feb 2017 15:28:29 -0500 Message-ID: To: dnsop Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:29:03 -0000 Hi there all, I have just posted a new version of alt-tld, which folds in a number of suggestions and comments from various people -- thank you for those. As the document was parked I held off making some of the larger edits; if you sent comments and I missed them, I apologize - please send them again (or point at them) and I'll try address them. The largest outstanding issue is what to do about DNSSEC -- this is (potentially) a problem for any / all 6761 type names. The root is signed, so if a query leaks into the DNS (as they will), an (unaware) validating resolver will try resolve it, and will expect either a signed answer, or proof of an insecure delegation; without this things will look bogus, and so resolvers will SERVFAIL. Clearly, a signed answer isn't feasible, so that leaves 2 options - 1: simply note that validation will fail, and that SERVFAIL will be returned in many case (to me this seems "correct"), or 2: request that the IANA insert an insecure delegation in the root, pointing to a: AS112 or b: an empty zone on the root or c" something similar. This is a fine thing to request in an IANA consideratons, but isn't necessarily *useful* -- the IANA has the technical ability to add stuff to the root zone, but not the mandate (this is like walking into a bank and requesting the teller gives you a bunch of money - they may be able to do so, but aren't actually allowed to.. :-)). Some people have suggested "Well, we (or the IAB) can just ask ICANN politely to do add this, they are in charge of the DNS root, they'll help out, no worries...." Unfortunately, this is only partly accurate -- adding an (insecure) delegation to the root would make .alt be a "real" TLD. ICANN is just an organization, they are driven by a multistakeholder[0] process, and there is a huge amount of process and similar around creating a new TLD -- go read the 300+ page gTLD Applicant Guidebook (Version 2012-06-04 ) for a fun taste of this. This would likely require convincing "the naming community" that, for some reason the IETF is special and should get a "free"[1] TLD, and that it is exempt from, well, basically all of the existing requirements..... I'd started putting some strawman text into the draft[2], so that we could have something concrete to discuss and poke holes in, but ripped it out because it was clearly not going to fly / pure fiction... So, what do we want to do here? This is a WG document, the authors will (of course) do whatever the WG wants, but my personal view is that asking for an insecure delegation, while technically superior, is simply not realistic. This discussion is somewhat about .alt, but other special use names will likely have the same issues and concerns, and so we should consider this in the larger context. For example, homenet already has had some of this discussion -- see: https://mailarchive.ietf.org/arch/search/?email_list=homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation W [0]: By law, all mentions of ICANN require the use of the word "mutistakeholder"....Hey, this is no more crazy than some of the other new rules.... [1]: Yeah, 'tis not a useable TLD in that you cannot sell names and have them work in the DNS, but this is fairly subtle... [2]: ------------------ [ Editor note: This section is a strawman (and so is more conversational than expected for the final version) -- it is likely to change significantly, or more likely, be removed entirely. ] The point of adding this entry to the "Special-Use Domain Name" registry is to create a namespace which can be used for alternate resolution contexts, and which will not collide with entries in the IANA DNS root. Unfortunately, queries will still leak into the DNS, and, as the DNS root zone is signed, validating resolvers which are unaware of .alt will attempt to DNSSEC validate responses. If there is not an insecure delgation for .alt, DNSSEC validation will fail, and validating resolvers will return SERVFAIL, causing additional lookups or other unexpected behavior. In order to avoid this, the IANA is requested to add an insecure delegation to the root-zone, delegating .alt to AS112 nameservers (or to an empty zone on hosted by the root). ------------------ -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Feb 1 12:33:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261C91299D7 for ; Wed, 1 Feb 2017 12:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 BM7b84snIwY8 for ; Wed, 1 Feb 2017 12:33:34 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 468DE129575 for ; Wed, 1 Feb 2017 12:33:33 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id 123so145054352ybe.3 for ; Wed, 01 Feb 2017 12:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lrfm7FcwXoKIWtB22Q2Ns8fUALwmAzjH8q+rSDoOmnQ=; b=MTkENwgKzm0C+D3qAs9gf/DY7/0ragCmKsdisZjxvBFACt2GnNU5YDVp+IeCxfynMd YzjrO2XBNKMg592uOOLhcvWjsUNj5CG8m/SIZJB7gejaj+9P/zpFKoRgII+rK7/3rGAy 2T/2pmb+CMowSJ7eFIpRnJfYBFCE8kPoQU0orSD/r3Z2O2i+ONtw172QyPlogw1LzT/N ReoFP6C3M5aX2GqbtN0QCOScKjiZCFRDWptpTB7hTb4Yg0TbazSaVOzkpEWVAsS89XTY +Xkij17SZVTYNFPXhnNc+JmucovIXJsWYk/KW3NplEboT+B5Tc3mIOKqOAadAinMSHGL huAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lrfm7FcwXoKIWtB22Q2Ns8fUALwmAzjH8q+rSDoOmnQ=; b=sE7wbOFduG5xayn5t7YGkHpnbElJpBM1pWV2OAwVVf2nZxcjIGojD5fFET+NFikBgY tOxZtCCLuKE7to8OwUOwdqbgB+Z1L0VpbTya/ifywu+CTUSVwtgjit+iJ2EhE6xyhxwV iKwp5J8qIbsjnX2Y4A41lCiY7q625XI+lguPNDOPhibCxdGQScio7NDJgHuCjfmTMbhD 6mBwc5mpJGqD6N3UW77oduGvPIv38AdRjm4pbbC9kDlwgMnCmhYl7wdVl3hRQ6PfqjwQ 7py9surzJos5XqX/1S64IpDaVoNGuw7OAzifNKgkCcr9gHBcUQkmIKSZ7JN5aLT9IYh6 mVag== X-Gm-Message-State: AIkVDXItllZu4mz2Az8WUUc27oUvrhzHvFbaen+oTQkf47WoKYwqwOSArWlnViYbnUf2/DvLDJktvkNNMbsSuEXy X-Received: by 10.37.219.193 with SMTP id g184mr539894ybf.19.1485981212925; Wed, 01 Feb 2017 12:33:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.237.68 with HTTP; Wed, 1 Feb 2017 12:33:32 -0800 (PST) In-Reply-To: References: <0D318AAC-5846-4E65-9030-19C91854CA8D@vpnc.org> From: Bob Harold Date: Wed, 1 Feb 2017 15:33:32 -0500 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=94eb2c186b46573e8d05477df656 Archived-At: Cc: IETF DNSOP WG Subject: Re: [DNSOP] Big changes in draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:33:36 -0000 --94eb2c186b46573e8d05477df656 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 30, 2017 at 8:08 PM, Paul Hoffman wrote: > On 30 Jan 2017, at 10:15, Bob Harold wrote: > > 2. Names >>> >> Global DNS: >> Administration of names -- >> I think we need to add IETF to this section as an administrator. >> > > Could you please say more, maybe with actual text? I can see a few > different ways to interpret the words above. > > --Paul Hoffman > I was just noting what was said in draft-ietf-dnsop-sutld-ps "The assignment of Internet Names is not under the sole control of any one organization. IETF has authority in some cases, but only with respect to "technical uses." ICANN at present is the designated administrator of the root zone, but generally not of zones other than the root zone." Perhaps adding a line: "Domain Names for technical uses are administered by IETF" -- Bob Harold --94eb2c186b46573e8d05477df656 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 30, 2017 at 8:0= 8 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 30= Jan 2017, at 10:15, Bob Harold wrote:

=C2=A02. Names
Global DNS:
Administration of names --
I think we need to add IETF to this section as an administrator.

 Could you please say more, maybe with actual text? I can see a few differen= t ways to interpret the words above.

--Paul Hoffman

I was= just noting what was said in=C2=A0
draft-i= etf-dnsop-sutld-ps
"The assignment of Internet Names is not u= nder the sole control of any
=C2=A0 =C2=A0one organization.=C2=A0 IETF h= as authority in some cases, but only with
=C2=A0 =C2=A0respect to "= technical uses." =C2=A0ICANN at present is the designated
=C2=A0 = =C2=A0administrator of the root zone, but generally not of zones other than=
=C2=A0 =C2=A0the root zone."

Perhaps adding a line:<= br>"Domain Names for technical uses are administered by IETF"
--=C2=A0
Bob Harold

--94eb2c186b46573e8d05477df656-- From nobody Wed Feb 1 12:44:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C9A12958A for ; Wed, 1 Feb 2017 12:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 2ypt0NzGgW-S for ; Wed, 1 Feb 2017 12:44:56 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A24B129431 for ; Wed, 1 Feb 2017 12:44:56 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id EF6EE12C0F11; Wed, 1 Feb 2017 15:44:55 -0500 (EST) Date: Wed, 1 Feb 2017 15:44:55 -0500 From: Robert Edmonds To: Warren Kumari Message-ID: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:44:58 -0000 Warren Kumari wrote: > The largest outstanding issue is what to do about DNSSEC -- this is > (potentially) a problem for any / all 6761 type names. > The root is signed, so if a query leaks into the DNS (as they will), > an (unaware) validating resolver will try resolve it, and will expect > either a signed answer, or proof of an insecure delegation; without > this things will look bogus, and so resolvers will SERVFAIL. > > Clearly, a signed answer isn't feasible, so that leaves 2 options - 1: > simply note that validation will fail, and that SERVFAIL will be > returned in many case (to me this seems "correct"), or 2: request that > the IANA insert an insecure delegation in the root, pointing to a: > AS112 or b: an empty zone on the root or c" something similar. Hi, Warren: I'm kind of confused. If a .ALT query leaks into the DNS, and there's neither a secure or insecure delegation in the root, isn't the result a signed NXDOMAIN, not a SERVFAIL? ; <<>> DiG 9.11.0-P1 <<>> +dnssec foo.alt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36917 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 -- Robert Edmonds From nobody Wed Feb 1 12:47:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8CB1299E5 for ; Wed, 1 Feb 2017 12:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 5hWu4YuHNX5g for ; Wed, 1 Feb 2017 12:47:20 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 54D2B1299E2 for ; Wed, 1 Feb 2017 12:47:20 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id v200so74621698ywc.3 for ; Wed, 01 Feb 2017 12:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vkxgy+Ikt1JM7W4BCVNNfSaxK175Fi6hLB9woECRDE0=; b=Ophyf2XQa7MZd9mxL1BkAr0vxzvUn/Ffg4he0e/kzTOLCvij5oGiSZ+UF9Ut14BYyL mZPpkckzrz7cY5g2Ib7t3YWbGie+1YJ5FOTzg1P9373JfoHpqSUoMtcC9eFc1q88QFgj cDR4PJB44PV2fgQdjfXigVynIWoOPz/9UpFxDk/OMcZkefHtKTIzLk1jGHDGln4UkTNE Syn+mafq3JTSHLKyJP4eoBtIz82ET/EilgxJS6jAwiF3V/+Qv7f9mfrzvQ9lnPjmE+Pm YssD/6Zr0Y3yJU55QoX43G1TNy9q3ahXyE+/XjCOu4kEGll+fFojlhMs8Nm445l6VOhj Bgww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vkxgy+Ikt1JM7W4BCVNNfSaxK175Fi6hLB9woECRDE0=; b=TxivPKJLkP0asPfFIRW7g6zOmz6hITcTlGGJYpvYEBMIxBoLZTRUyDEYJTapSvYmaH eLGfr8Zxkl9K1+5Ul1sh4nN2BbgRyNZY7vxLNAcTXztJVcRXucnAlOiO08XN4WnwSYzY E/hoXvqzuhJJiFNuERHC6U8z1KoLxedHI+IeQKt3ZtKJXfe959b4OvLhHWZVGQj174V6 CjO8rdVj4z3I9wmccVsoP8p/DH/afLt0R/m3tTAnWCfUT5TBzd+POv4q70fpn35SOZbG CcESSN2qCMNA4IEcR1NN+4JN1K3Sv7pr2wZCjpMyGjTGrhM/xnacteDd3jeryb9bbR9o SLhg== X-Gm-Message-State: AIkVDXJyLwj9R8QE9GuF3V9h91SpxwI2asf0TlNRX3izmJQK8Qy2qyY7oENmioq12DEtf8zH0A5iHwIgH0XCrhZ0 X-Received: by 10.129.141.6 with SMTP id d6mr3103445ywg.198.1485982039368; Wed, 01 Feb 2017 12:47:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.237.68 with HTTP; Wed, 1 Feb 2017 12:47:18 -0800 (PST) In-Reply-To: References: From: Bob Harold Date: Wed, 1 Feb 2017 15:47:18 -0500 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=f403045e61fc9991f405477e27d7 Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:47:23 -0000 --f403045e61fc9991f405477e27d7 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 1, 2017 at 3:28 PM, Warren Kumari wrote: > Hi there all, > > I have just posted a new version of alt-tld, which folds in a number > of suggestions and comments from various people -- thank you for > those. As the document was parked I held off making some of the larger > edits; if you sent comments and I missed them, I apologize - please > send them again (or point at them) and I'll try address them. > > > The largest outstanding issue is what to do about DNSSEC -- this is > (potentially) a problem for any / all 6761 type names. > The root is signed, so if a query leaks into the DNS (as they will), > an (unaware) validating resolver will try resolve it, and will expect > either a signed answer, or proof of an insecure delegation; without > this things will look bogus, and so resolvers will SERVFAIL. > > Clearly, a signed answer isn't feasible, so that leaves 2 options - 1: > simply note that validation will fail, and that SERVFAIL will be > returned in many case (to me this seems "correct"), or 2: request that > the IANA insert an insecure delegation in the root, pointing to a: > AS112 or b: an empty zone on the root or c" something similar. > > This is a fine thing to request in an IANA consideratons, but isn't > necessarily *useful* -- the IANA has the technical ability to add > stuff to the root zone, but not the mandate (this is like walking into > a bank and requesting the teller gives you a bunch of money - they may > be able to do so, but aren't actually allowed to.. :-)). > > Some people have suggested "Well, we (or the IAB) can just ask ICANN > politely to do add this, they are in charge of the DNS root, they'll > help out, no worries...." > Unfortunately, this is only partly accurate -- adding an (insecure) > delegation to the root would make .alt be a "real" TLD. ICANN is just > an organization, they are driven by a multistakeholder[0] process, and > there is a huge amount of process and similar around creating a new > TLD -- go read the 300+ page gTLD Applicant Guidebook (Version > 2012-06-04 ) for a fun taste of this. > This would likely require convincing "the naming community" that, for > some reason the IETF is special and should get a "free"[1] TLD, and > that it is exempt from, well, basically all of the existing > requirements..... > > I'd started putting some strawman text into the draft[2], so that we > could have something concrete to discuss and poke holes in, but ripped > it out because it was clearly not going to fly / pure fiction... > > So, what do we want to do here? This is a WG document, the authors > will (of course) do whatever the WG wants, but my personal view is > that asking for an insecure delegation, while technically superior, is > simply not realistic. > > This discussion is somewhat about .alt, but other special use names > will likely have the same issues and concerns, and so we should > consider this in the larger context. > > For example, homenet already has had some of this discussion -- see: > https://mailarchive.ietf.org/arch/search/?email_list= > homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation > > > W > [0]: By law, all mentions of ICANN require the use of the word > "mutistakeholder"....Hey, this is no more crazy than some of the other > new rules.... > > [1]: Yeah, 'tis not a useable TLD in that you cannot sell names and > have them work in the DNS, but this is fairly subtle... > > [2]: > ------------------ > [ Editor note: This section is a strawman (and so is more > conversational than expected for the final version) -- it is likely to > change significantly, or more likely, be removed entirely. ] > > The point of adding this entry to the "Special-Use Domain Name" > registry is to create a namespace which can be used for alternate > resolution contexts, and which will not collide with entries in the > IANA DNS root. > > Unfortunately, queries will still leak into the DNS, and, as the DNS > root zone is signed, validating resolvers which are unaware of .alt > will attempt to DNSSEC validate responses. If there is not an insecure > delgation for .alt, DNSSEC validation will fail, and validating > resolvers will return SERVFAIL, causing additional lookups or other > unexpected behavior. > > In order to avoid this, the IANA is requested to add an insecure > delegation to the root-zone, delegating .alt to AS112 nameservers (or > to an empty zone on hosted by the root). > ------------------ > > > It appears to me that requesting an insecure delegation is the right thing to do, as a "technical use". We have, so far, been very careful in what we ask for. If ICANN does not agree, then we can discuss other options. -- Bob Harold --f403045e61fc9991f405477e27d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 1, 2017 at 3:28 PM, Warren Kumari <= ;warren@kumari.net> wrote:
Hi there all,

I have just posted a new version of alt-tld, which folds in a number
of suggestions and comments from various people -- thank you for
those. As the document was parked I held off making some of the larger
edits; if you sent comments and I missed them, I apologize - please
send them again (or point at them) and I'll try address them.


The largest outstanding issue is what to do about DNSSEC -- this is
(potentially) a problem for any / all 6761 type names.
The root is signed, so if a query leaks into the DNS (as they will),
an (unaware) validating resolver will try resolve it, and will expect
either a signed answer, or proof of an insecure delegation; without
this things will look bogus, and so resolvers will SERVFAIL.

Clearly, a signed answer isn't feasible, so that leaves 2 options - 1:<= br> simply note that validation will fail, and that SERVFAIL will be
returned in many case (to me this seems "correct"), or 2: request= that
the IANA insert an insecure delegation in the root, pointing to a:
AS112 or b: an empty zone on the root or c" something similar.

This is a fine thing to request in an IANA consideratons, but isn't
necessarily *useful* -- the IANA has the technical ability to add
stuff to the root zone, but not the mandate (this is like walking into
a bank and requesting the teller gives you a bunch of money - they may
be able to do so, but aren't actually allowed to.. :-)).

Some people have suggested "Well, we (or the IAB) can just ask ICANN politely to do add this, they are in charge of the DNS root, they'll help out, no worries...."
Unfortunately, this is only partly accurate -- adding an (insecure)
delegation to the root would make .alt be a "real" TLD. ICANN is = just
an organization, they are driven by a multistakeholder[0] process, and
there is a huge amount of process and similar around creating a new
TLD -- go read the 300+ page gTLD Applicant Guidebook (Version
2012-06-04 ) for a fun taste of this.
This would likely require convincing "the naming community" that,= for
some reason the IETF is special and should get a "free"[1] TLD, a= nd
that it is exempt from, well, basically all of the existing
requirements.....

I'd started putting some strawman text into the draft[2], so that we could have something concrete to discuss and poke holes in, but ripped
it out because it was clearly not going to fly / pure fiction...

So, what do we want to do here? This is a WG document, the authors
will (of course) do whatever the WG wants, but my personal view is
that asking for an insecure delegation, while technically superior, is
simply not realistic.

This discussion is somewhat about .alt, but other special use names
will likely have the same issues and concerns, and so we should
consider this in the larger context.

For example, homenet already has had some of this discussion -- see:
https://mailarchive.ietf.org/arch/search/?e= mail_list=3Dhomenet&q=3D+On+the+TLD+question+and+validatably-= insecure+delegation


W
[0]: By law, all mentions of ICANN require the use of the word
"mutistakeholder"....Hey, this is no more crazy than some of the = other
new rules....

[1]: Yeah, 'tis not a useable TLD in that you cannot sell names and
have them work in the DNS, but this is fairly subtle...

[2]:
------------------
[ Editor note: This section is a strawman (and so is more
conversational than expected for the final version) -- it is likely to
change significantly, or more likely, be removed entirely. ]

The point of adding this entry to the "Special-Use Domain Name" registry is to create a namespace which can be used for alternate
resolution contexts, and which will not collide with entries in the
IANA DNS root.

Unfortunately, queries will still leak into the DNS, and, as the DNS
root zone is signed, validating resolvers which are unaware of .alt
will attempt to DNSSEC validate responses. If there is not an insecure
delgation for .alt, DNSSEC validation will fail, and validating
resolvers will return SERVFAIL, causing additional lookups or other
unexpected behavior.

In order to avoid this, the IANA is requested to add an insecure
delegation to the root-zone, delegating .alt to AS112 nameservers (or
to an empty zone on hosted by the root).
------------------


It appears to me that requesting an ins= ecure delegation is the right thing to do, as a "technical use".= =C2=A0 We have, so far, been very careful in what we ask for.=C2=A0 If ICAN= N does not agree, then we can discuss other options.

--=C2=A0
Bob Harold
=C2=A0

--f403045e61fc9991f405477e27d7-- From nobody Wed Feb 1 12:50:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB8F129431 for ; Wed, 1 Feb 2017 12:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHibvKSX-h5e for ; Wed, 1 Feb 2017 12:50:35 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 A342F129550 for ; Wed, 1 Feb 2017 12:50:35 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id v23so285031538qtb.0 for ; Wed, 01 Feb 2017 12:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=Jai3gHNGCCwwvmFOiwn2EuJE2vyYcmzrBKa8Uc2KdNQ=; b=PPugQMBKA6jXy5sSNJs5KsbGQjNuxaxZwIKEQkKVyp7WViuTKrroFkgiepyGeVqfV0 tt6Qf8zAuozSUYhHw9J/bYoE4MZI7ZY2qRO9iWL77yYZfFM2qO4ZjijBKvg/333W3dTy xYTYGXi+s7dlFYve//eGKZVHxCfdeYwriT+JxVsxZl2ibX6S2XXzeH7im8GCcERHCA1S Prr+qn0zS9DKVeZmWRjhXzKj7wNOMh9hmZgm37ppYHm5JOlNbS5gyfijQrfCHU6pvKTP WwZaqqwPxxgo9PWerESMnHZOMTrxNI8r7n5cGb8PaQsLPnX80zORoDNR0Dxvh3/1BbNw ryNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=Jai3gHNGCCwwvmFOiwn2EuJE2vyYcmzrBKa8Uc2KdNQ=; b=aiuD+nqgL/FegTRqmnYuPDByMnIk4okiScV4VR7IG80MPBLyo6aR454kJaWhUGpY0e c55tn3Rg4KzJPV4j+rvjZMZFFGWNflVXkH40WNC8c+ezho5wXTw4WoN78lGBq1sfeqwt PvmpnObVjsZ6S3r96TpCgUokPLCZiklbB1vgeuMk5FsMCwff5zs7XYLL6PeuDHGQVWqV ZWH4whZqmB1PA7orOXLMYmsSOLCMRIVUnispWjif8dyfcpCBBNpgn+bSoitipeUyDEBw Wy/xUnLqCbbexu25851nHF/uRzaDaUfRzsfWxaxdXzZGlb4GY0GGl0ThL+38YtsInSG8 9LZw== X-Gm-Message-State: AMke39k5qI4a2Y3/aUN3y1v7kdAQoq4HZSRNThSX2ck60HrSClYy1OjFxaazP/M4Xsz4Hw== X-Received: by 10.55.81.136 with SMTP id f130mr4860140qkb.75.1485982234675; Wed, 01 Feb 2017 12:50:34 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:4ca6:5062:1722:a062? ([2601:18f:801:600:4ca6:5062:1722:a062]) by smtp.gmail.com with ESMTPSA id h40sm19639083qtb.6.2017.02.01.12.50.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 12:50:34 -0800 (PST) From: Ralph Droms Content-Type: multipart/alternative; boundary="Apple-Mail=_DFE7A880-CB61-4BA2-A686-B5F8093FB8B8" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 1 Feb 2017 15:50:32 -0500 References: To: dnsop In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:50:41 -0000 --Apple-Mail=_DFE7A880-CB61-4BA2-A686-B5F8093FB8B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 1, 2017, at 3:47 PM, Bob Harold wrote: >=20 >=20 > On Wed, Feb 1, 2017 at 3:28 PM, Warren Kumari > wrote: > Hi there all, >=20 > I have just posted a new version of alt-tld, which folds in a number > of suggestions and comments from various people -- thank you for > those. As the document was parked I held off making some of the larger > edits; if you sent comments and I missed them, I apologize - please > send them again (or point at them) and I'll try address them. >=20 >=20 > The largest outstanding issue is what to do about DNSSEC -- this is > (potentially) a problem for any / all 6761 type names. > The root is signed, so if a query leaks into the DNS (as they will), > an (unaware) validating resolver will try resolve it, and will expect > either a signed answer, or proof of an insecure delegation; without > this things will look bogus, and so resolvers will SERVFAIL. >=20 > Clearly, a signed answer isn't feasible, so that leaves 2 options - 1: > simply note that validation will fail, and that SERVFAIL will be > returned in many case (to me this seems "correct"), or 2: request that > the IANA insert an insecure delegation in the root, pointing to a: > AS112 or b: an empty zone on the root or c" something similar. >=20 > This is a fine thing to request in an IANA consideratons, but isn't > necessarily *useful* -- the IANA has the technical ability to add > stuff to the root zone, but not the mandate (this is like walking into > a bank and requesting the teller gives you a bunch of money - they may > be able to do so, but aren't actually allowed to.. :-)). >=20 > Some people have suggested "Well, we (or the IAB) can just ask ICANN > politely to do add this, they are in charge of the DNS root, they'll > help out, no worries...." > Unfortunately, this is only partly accurate -- adding an (insecure) > delegation to the root would make .alt be a "real" TLD. ICANN is just > an organization, they are driven by a multistakeholder[0] process, and > there is a huge amount of process and similar around creating a new > TLD -- go read the 300+ page gTLD Applicant Guidebook (Version > 2012-06-04 ) for a fun taste of this. > This would likely require convincing "the naming community" that, for > some reason the IETF is special and should get a "free"[1] TLD, and > that it is exempt from, well, basically all of the existing > requirements..... >=20 > I'd started putting some strawman text into the draft[2], so that we > could have something concrete to discuss and poke holes in, but ripped > it out because it was clearly not going to fly / pure fiction... >=20 > So, what do we want to do here? This is a WG document, the authors > will (of course) do whatever the WG wants, but my personal view is > that asking for an insecure delegation, while technically superior, is > simply not realistic. >=20 > This discussion is somewhat about .alt, but other special use names > will likely have the same issues and concerns, and so we should > consider this in the larger context. >=20 > For example, homenet already has had some of this discussion -- see: > = https://mailarchive.ietf.org/arch/search/?email_list=3Dhomenet&q=3D+On+the= +TLD+question+and+validatably-insecure+delegation = >=20 >=20 > W > [0]: By law, all mentions of ICANN require the use of the word > "mutistakeholder"....Hey, this is no more crazy than some of the other > new rules.... >=20 > [1]: Yeah, 'tis not a useable TLD in that you cannot sell names and > have them work in the DNS, but this is fairly subtle... >=20 > [2]: > ------------------ > [ Editor note: This section is a strawman (and so is more > conversational than expected for the final version) -- it is likely to > change significantly, or more likely, be removed entirely. ] >=20 > The point of adding this entry to the "Special-Use Domain Name" > registry is to create a namespace which can be used for alternate > resolution contexts, and which will not collide with entries in the > IANA DNS root. >=20 > Unfortunately, queries will still leak into the DNS, and, as the DNS > root zone is signed, validating resolvers which are unaware of .alt > will attempt to DNSSEC validate responses. If there is not an insecure > delgation for .alt, DNSSEC validation will fail, and validating > resolvers will return SERVFAIL, causing additional lookups or other > unexpected behavior. >=20 > In order to avoid this, the IANA is requested to add an insecure > delegation to the root-zone, delegating .alt to AS112 nameservers (or > to an empty zone on hosted by the root). > ------------------ >=20 >=20 > It appears to me that requesting an insecure delegation is the right = thing to do, as a "technical use". We have, so far, been very careful = in what we ask for. If ICANN does not agree, then we can discuss other = options. I agree. - Ralph >=20 > --=20 > Bob Harold > =20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_DFE7A880-CB61-4BA2-A686-B5F8093FB8B8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Feb 1, 2017, at 3:47 PM, Bob Harold <rharolde@umich.edu> wrote:


On Wed, Feb 1, 2017 at 3:28 PM, Warren Kumari <warren@kumari.net> wrote:
Hi there all,

I have just posted a new version of alt-tld, which folds in a number
of suggestions and comments from various people -- thank you for
those. As the document was parked I held off making some of the larger
edits; if you sent comments and I missed them, I apologize - please
send them again (or point at them) and I'll try address them.


The largest outstanding issue is what to do about DNSSEC -- this is
(potentially) a problem for any / all 6761 type names.
The root is signed, so if a query leaks into the DNS (as they will),
an (unaware) validating resolver will try resolve it, and will expect
either a signed answer, or proof of an insecure delegation; without
this things will look bogus, and so resolvers will SERVFAIL.

Clearly, a signed answer isn't feasible, so that leaves 2 options - 1:
simply note that validation will fail, and that SERVFAIL will be
returned in many case (to me this seems "correct"), or 2: request that
the IANA insert an insecure delegation in the root, pointing to a:
AS112 or b: an empty zone on the root or c" something similar.

This is a fine thing to request in an IANA consideratons, but isn't
necessarily *useful* -- the IANA has the technical ability to add
stuff to the root zone, but not the mandate (this is like walking into
a bank and requesting the teller gives you a bunch of money - they may
be able to do so, but aren't actually allowed to.. :-)).

Some people have suggested "Well, we (or the IAB) can just ask ICANN
politely to do add this, they are in charge of the DNS root, they'll
help out, no worries...."
Unfortunately, this is only partly accurate -- adding an (insecure)
delegation to the root would make .alt be a "real" TLD. ICANN is just
an organization, they are driven by a multistakeholder[0] process, and
there is a huge amount of process and similar around creating a new
TLD -- go read the 300+ page gTLD Applicant Guidebook (Version
2012-06-04 ) for a fun taste of this.
This would likely require convincing "the naming community" that, for
some reason the IETF is special and should get a "free"[1] TLD, and
that it is exempt from, well, basically all of the existing
requirements.....

I'd started putting some strawman text into the draft[2], so that we
could have something concrete to discuss and poke holes in, but ripped
it out because it was clearly not going to fly / pure fiction...

So, what do we want to do here? This is a WG document, the authors
will (of course) do whatever the WG wants, but my personal view is
that asking for an insecure delegation, while technically superior, is
simply not realistic.

This discussion is somewhat about .alt, but other special use names
will likely have the same issues and concerns, and so we should
consider this in the larger context.

For example, homenet already has had some of this discussion -- see:
https://mailarchive.ietf.org/arch/search/?email_list=homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation


W
[0]: By law, all mentions of ICANN require the use of the word
"mutistakeholder"....Hey, this is no more crazy than some of the other
new rules....

[1]: Yeah, 'tis not a useable TLD in that you cannot sell names and
have them work in the DNS, but this is fairly subtle...

[2]:
------------------
[ Editor note: This section is a strawman (and so is more
conversational than expected for the final version) -- it is likely to
change significantly, or more likely, be removed entirely. ]

The point of adding this entry to the "Special-Use Domain Name"
registry is to create a namespace which can be used for alternate
resolution contexts, and which will not collide with entries in the
IANA DNS root.

Unfortunately, queries will still leak into the DNS, and, as the DNS
root zone is signed, validating resolvers which are unaware of .alt
will attempt to DNSSEC validate responses. If there is not an insecure
delgation for .alt, DNSSEC validation will fail, and validating
resolvers will return SERVFAIL, causing additional lookups or other
unexpected behavior.

In order to avoid this, the IANA is requested to add an insecure
delegation to the root-zone, delegating .alt to AS112 nameservers (or
to an empty zone on hosted by the root).
------------------


It appears to me that requesting an insecure delegation is the right thing to do, as a "technical use".  We have, so far, been very careful in what we ask for.  If ICANN does not agree, then we can discuss other options.

I agree.

- Ralph


-- 
Bob Harold
 

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--Apple-Mail=_DFE7A880-CB61-4BA2-A686-B5F8093FB8B8-- From nobody Wed Feb 1 12:57:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279291299DC for ; Wed, 1 Feb 2017 12:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 tpRckKjXLT5u for ; Wed, 1 Feb 2017 12:57:09 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65882129431 for ; Wed, 1 Feb 2017 12:57:09 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 19F5A1FCACC; Wed, 1 Feb 2017 20:57:05 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id CB432160042; Wed, 1 Feb 2017 20:57:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B7139160070; Wed, 1 Feb 2017 20:57:03 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kzFbrybcDqtF; Wed, 1 Feb 2017 20:57:03 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 04B8C160042; Wed, 1 Feb 2017 20:57:03 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id CB3356115F8E; Thu, 2 Feb 2017 07:56:56 +1100 (EST) To: Warren Kumari From: Mark Andrews References: In-reply-to: Your message of "Wed, 01 Feb 2017 15:28:29 -0500." Date: Thu, 02 Feb 2017 07:56:56 +1100 Message-Id: <20170201205656.CB3356115F8E@rock.dv.isc.org> Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:57:11 -0000 In message , Warren K umari writes: > Hi there all, > > I have just posted a new version of alt-tld, which folds in a number > of suggestions and comments from various people -- thank you for > those. As the document was parked I held off making some of the larger > edits; if you sent comments and I missed them, I apologize - please > send them again (or point at them) and I'll try address them. > > > The largest outstanding issue is what to do about DNSSEC -- this is > (potentially) a problem for any / all 6761 type names. > The root is signed, so if a query leaks into the DNS (as they will), > an (unaware) validating resolver will try resolve it, and will expect > either a signed answer, or proof of an insecure delegation; without > this things will look bogus, and so resolvers will SERVFAIL. > > Clearly, a signed answer isn't feasible, so that leaves 2 options - 1: > simply note that validation will fail, and that SERVFAIL will be > returned in many case (to me this seems "correct"), or 2: request that > the IANA insert an insecure delegation in the root, pointing to a: > AS112 or b: an empty zone on the root or c" something similar. > > This is a fine thing to request in an IANA consideratons, but isn't > necessarily *useful* -- the IANA has the technical ability to add > stuff to the root zone, but not the mandate (this is like walking into > a bank and requesting the teller gives you a bunch of money - they may > be able to do so, but aren't actually allowed to.. :-)). Actually it isn't the same. Implicit in the agreement that the IETF can get names in the root namespace is the ability to use them. Some uses require that there be a entry in the root zone. It doesn't say that the IETF can "RESERVE" a name. The IETF gets the name. > Some people have suggested "Well, we (or the IAB) can just ask ICANN > politely to do add this, they are in charge of the DNS root, they'll > help out, no worries...." > Unfortunately, this is only partly accurate -- adding an (insecure) > delegation to the root would make .alt be a "real" TLD. ICANN is just > an organization, they are driven by a multistakeholder[0] process, and > there is a huge amount of process and similar around creating a new > TLD -- go read the 300+ page gTLD Applicant Guidebook (Version > 2012-06-04 ) for a fun taste of this. > This would likely require convincing "the naming community" that, for > some reason the IETF is special and should get a "free"[1] TLD, and > that it is exempt from, well, basically all of the existing > requirements..... ICANN has already agreed that the IETF is special. Thats why there is a agreement that the IETF can request names in the root namespace outside of the regular process. There is nothing in the agreement that make the names the IETF requests gTLD. They are a different class. > I'd started putting some strawman text into the draft[2], so that we > could have something concrete to discuss and poke holes in, but ripped > it out because it was clearly not going to fly / pure fiction... > > So, what do we want to do here? This is a WG document, the authors > will (of course) do whatever the WG wants, but my personal view is > that asking for an insecure delegation, while technically superior, is > simply not realistic. > > This discussion is somewhat about .alt, but other special use names > will likely have the same issues and concerns, and so we should > consider this in the larger context. > > For example, homenet already has had some of this discussion -- see: > https://mailarchive.ietf.org/arch/search/?email_list=homenet&q=+On+the+TLD+question+and > +validatably-insecure+delegation > > > W > [0]: By law, all mentions of ICANN require the use of the word > "mutistakeholder"....Hey, this is no more crazy than some of the other > new rules.... > > [1]: Yeah, 'tis not a useable TLD in that you cannot sell names and > have them work in the DNS, but this is fairly subtle... > > [2]: > ------------------ > [ Editor note: This section is a strawman (and so is more > conversational than expected for the final version) -- it is likely to > change significantly, or more likely, be removed entirely. ] > > The point of adding this entry to the "Special-Use Domain Name" > registry is to create a namespace which can be used for alternate > resolution contexts, and which will not collide with entries in the > IANA DNS root. > > Unfortunately, queries will still leak into the DNS, and, as the DNS > root zone is signed, validating resolvers which are unaware of .alt > will attempt to DNSSEC validate responses. If there is not an insecure > delgation for .alt, DNSSEC validation will fail, and validating > resolvers will return SERVFAIL, causing additional lookups or other > unexpected behavior. > > In order to avoid this, the IANA is requested to add an insecure > delegation to the root-zone, delegating .alt to AS112 nameservers (or > to an empty zone on hosted by the root). > ------------------ > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 1 12:58:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E13F1299D8 for ; Wed, 1 Feb 2017 12:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCiANMUy4M6C for ; Wed, 1 Feb 2017 12:58:45 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 64AAF129431 for ; Wed, 1 Feb 2017 12:58:45 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id c7so26917929itd.1 for ; Wed, 01 Feb 2017 12:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GylfmzKWRHKe9mYF0TB8f/8eUQLq2FPSmovzjx88s5g=; b=CzgCOIMqmDR1hbhSoNefnIFqLtyAn0Kj6ShukfUj5HFh9nmts5IVB/eKd8f++jkzm5 /PMyWSRcAC/GRBPI4P+ftYLUPqUHWUMZAm6oXeJdnSHX3MDj1qheWOkO3B+0D0mYalP1 dZ7wYzxandWzulTGdFPlEAdjMdQ3qkRHjhRv/JGw4uqWxGrk7oQ4ioaqrrmRrPAJWlCP q3TrCe3gYLZjMTK1EI8dcLTUVdvFjPJeb17Sy/Qlo+liSchzs+3BhgitmCHKWRgztUKK erhFr4uAypDzKI1UihuSnva7Fh+yMa4PfcNOgYFlv2GoB3lTlW/XyfXccWUV729zA7gI arrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GylfmzKWRHKe9mYF0TB8f/8eUQLq2FPSmovzjx88s5g=; b=blnPCZV1M59Y+fX/AiYIyWNAB2TXqGlC6rLsS1su7bWt2415mOMdKUyTRkQMxnTY+i ZNQE+p2ykOxYmDKH45AN/V8R3kff5avpfpPvOmXDpXn6mE58QVr9BInN228uBrP+H8wq BYMfRL7C5jC5e4F3ATthlW7nn4IyBuzHv0xTRzD2eWK0ok7bNNNJ5G64kTZDDr/3Z7J3 xtdI/MTWQ6WOZlwVj/pE9z31vwBUnJn0PJccHRLH6fwbmzDnAC1C33gIJfrKTom50X9v mZQ3bzl3JrKI1a3nX1Zr9aYAbQcOs3Yj4gq0YD7P3dy4Ir354slODOiMZ35nWEzNJ6Ug +/aA== X-Gm-Message-State: AIkVDXLn9mZgtuqMuRKSRnxzGrA+Ut+abB2jRg2s7dZq3vM7opUMGQi1IkpCqQPyniVjkg== X-Received: by 10.36.91.17 with SMTP id g17mr23214166itb.70.1485982724528; Wed, 01 Feb 2017 12:58:44 -0800 (PST) Received: from [192.168.43.27] (mobile-107-92-123-98.mycingular.net. [107.92.123.98]) by smtp.gmail.com with ESMTPSA id 96sm12463875ioh.27.2017.02.01.12.58.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 12:58:43 -0800 (PST) From: Ted Lemon Message-Id: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F932D89B-F525-40CD-A475-B1FE6F919434" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 1 Feb 2017 15:58:41 -0500 In-Reply-To: To: Ralph Droms References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:58:47 -0000 --Apple-Mail=_F932D89B-F525-40CD-A475-B1FE6F919434 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 1, 2017, at 3:50 PM, Ralph Droms wrote: >> It appears to me that requesting an insecure delegation is the right = thing to do, as a "technical use". We have, so far, been very careful = in what we ask for. If ICANN does not agree, then we can discuss other = options. >=20 > I agree. I'm confused. The .ALT TLD is expected to be used for non-DNS name = lookups. So isn't a secure denial of existence exactly what we want = for .ALT? What is the utility in having an un-signed delegation? --Apple-Mail=_F932D89B-F525-40CD-A475-B1FE6F919434 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 1, 2017, at 3:50 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
It appears to me that requesting an insecure delegation is = the right thing to do, as a "technical use".  We have, so far, been = very careful in what we ask for.  If ICANN does not agree, then we = can discuss other = options.

I = agree.

I'm = confused.   The .ALT TLD is expected to be used for non-DNS name = lookups.   So isn't a secure denial of existence exactly what we = want for .ALT?   What is the utility in having an un-signed = delegation?


= --Apple-Mail=_F932D89B-F525-40CD-A475-B1FE6F919434-- From nobody Wed Feb 1 13:09:29 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B993B12957F for ; Wed, 1 Feb 2017 13:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 VSLYPGXl6bqb for ; Wed, 1 Feb 2017 13:09:26 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 EE160126FDC for ; Wed, 1 Feb 2017 13:09:25 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id v200so75106460ywc.3 for ; Wed, 01 Feb 2017 13:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6ne1NEYTbkOZ5w9vgC8/6bPiDJn4aSwMXn72XAqEBQs=; b=M8jLIbVAkN7bte3oLQxvLXZIewvbP80iU2fT4GyYnetGZQKmOqrOvfXfpt3wn9Oxdo cViC4IoRYyIS2+6tRlWv83CvoOQXo56jYUtPf9v25BvpV74Sy9Q9rSEhqAa1DvBPW6XY obPidTUbg9KeuTVBKw0p3qQuh1HoDBioJVoYhy9lzlIC2Cj7snrCpbM+UvOwzY35GveB pOAUwbxxfk6+0y5is14P8ZlawI3gDTDXz9NRVMbeNLkwyJGshglurzoMBCen7NdgY/56 s1vMWacUDa08PRq/BMXYoMJIBXidZexSS5SEAKKIwpngc0oYHs4jAM9CI1T/fC/u50th eQ5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6ne1NEYTbkOZ5w9vgC8/6bPiDJn4aSwMXn72XAqEBQs=; b=mon+yfNPc4j2TcGE5sZObN2L6bfqXQ+jq6Uv27UCdl610x81OH+/gfbSQW2+Eww9hg nu1PBXG9KltAA6NXwTNrUT5jRJNhXX4Yd+HDEw7S6/rD9WpGHQpUocgpo/S74dA/LUzZ 2008hPnJABtvMLXBTeZ7UvaS0bLK/5O/rgDN8f5n7959aTRJS5EQyof2mhK2Gp3vsOsR tBbkceU6vTKDMVz2lkpRdvgQaBwiN0Efk/0NXHE88M6BjVoh6JbscYWU22w8UHDyRSWQ PsgNotH0F1yAaHppPxcNY+ewqPZxfuCGjJ3VFG461PmfI+Tn1Sg8Pa+egpP1ax4+4uMH bdyg== X-Gm-Message-State: AIkVDXKBFrBrZkdB8dxD34F+BCW/vol2gmiUh48PB/4rjDwXY4bM5ut+FWNiOZYBuaXxwo7HTddo8zNUgOcitW1y X-Received: by 10.129.81.12 with SMTP id f12mr3310355ywb.80.1485983364896; Wed, 01 Feb 2017 13:09:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.237.68 with HTTP; Wed, 1 Feb 2017 13:09:24 -0800 (PST) In-Reply-To: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> References: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> From: Bob Harold Date: Wed, 1 Feb 2017 16:09:24 -0500 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a114630189bb40c05477e7674 Archived-At: Cc: dnsop , Ralph Droms Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 21:09:27 -0000 --001a114630189bb40c05477e7674 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 1, 2017 at 3:58 PM, Ted Lemon wrote: > On Feb 1, 2017, at 3:50 PM, Ralph Droms wrote: > > It appears to me that requesting an insecure delegation is the right thing > to do, as a "technical use". We have, so far, been very careful in what we > ask for. If ICANN does not agree, then we can discuss other options. > > > I agree. > > > I'm confused. The .ALT TLD is expected to be used for non-DNS name > lookups. So isn't a secure denial of existence exactly what we want for > .ALT? What is the utility in having an un-signed delegation? > > As I understand it, the idea is that if someone incorrectly looks up a .alt name in DNS, we want an answer that causes the requester and recursive resolver to not ask again, both to reduce traffic to the roots, and to minimize leakage of information. If querying 'something.alt', a delegation would be cached at the '.alt' level, but an NXDOMAIN would be cached as 'something.alt', and 'other.alt' would not be covered. -- Bob Harold --001a114630189bb40c05477e7674 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 1, 2017 at 3:58 PM, Ted Lemon <mellon@fugue.com>= wrote:
On Feb 1, 2017, at 3:50 PM, Ralph Droms <rdroms.ietf@gmail.co= m> wrote:
It appears to me that requesti= ng an insecure delegation is the right thing to do, as a "technical us= e".=C2=A0 We have, so far, been very careful in what we ask for.=C2=A0= If ICANN does not agree, then we can discuss other options.

= I agree.

I'm= confused. =C2=A0 The .ALT TLD is expected to be used for non-DNS name look= ups. =C2=A0 So isn't a secure denial of existence exactly what we want = for .ALT? =C2=A0 What is the utility in having an un-signed delegation?

As I understand it, the idea is th= at if someone incorrectly looks up a .alt name in DNS, we want an answer th= at causes the requester and recursive resolver to not ask again, both to re= duce traffic to the roots, and to minimize leakage of information.=C2=A0 If= querying 'something.alt', a delegation would be cached at the '= ;.alt' level, but an NXDOMAIN would be cached as 'something.alt'= ;, and 'other.alt' would not be covered.

-= -=C2=A0
Bob Harold
=C2=A0

--001a114630189bb40c05477e7674-- From nobody Wed Feb 1 13:33:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD05129A53 for ; Wed, 1 Feb 2017 13:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfIwC21OtedK for ; Wed, 1 Feb 2017 13:33:01 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DC8129A4E for ; Wed, 1 Feb 2017 13:33:00 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id j18so167239418ioe.2 for ; Wed, 01 Feb 2017 13:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XpjnzDa+Oo/qAuC+qGSf9I6SLYkhYZtxAvh1yWxH0EM=; b=RAiEBuxxHL959X2KxcRqITAfWLnL86Z3uXp46Ep5KXsezkQm2BeiBc10L1sDRXKnl5 GqwbrvSHPtcUZGK+EmEMD8A749+Whus1SwbWMgugGELIMQSyg4ozw1O72pp3yhC9JklB gSAq3qtbYr3U6rwidfgUfYwk+G0rdx29cR0fc6BP4G9XpKxSVnw/mPXpZw6/5rOKi2bx hzATW0YMxOOn1Nz8EZq8Le5Pa3rzYUhopYtSv6iJEZe45581lWkYlMlYWFT0QvfD/KAW FA5zxY+rkGLF22qJu9L8m9427NkDZ7kta15/AednYXbYc6F3GIHY29zHj/mkGx1ToBeU u2Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XpjnzDa+Oo/qAuC+qGSf9I6SLYkhYZtxAvh1yWxH0EM=; b=i9xFxyW+Ozlo3YInN3v+QluHaX6KH4qxYiQpa7JGNTF35NN85HY7INY5ROVJaXCtWx 76TaUimq7Daeoiy1pThA8rMfY/rVLQQGSwI+B32Ky3sPnQzZhJEPhDCArFYzMGOIaWJA tXxJIgBMyCH82hBP1tVwItF5aUN1vtoq0Cf5ln9ep7MavX1GdoDfwWBy3BAak22kY+D7 jtYdMNj5benKteR2KfVyjUMmKCiB4E+lVR4Lg3ATYrb7svVAGb+wQTVCcX1mPsxBQAh3 DmfxqGxN+bQlV2Fj2au1dwcZ9Dbyd2P5nxmwL8aJS+N8V9qK3dJt8/MC99hdqHxBUiQU gQYQ== X-Gm-Message-State: AIkVDXKZ+PLbTdB8KnlayTgTyUqnvf9PLmpMxrVi/4Xbu9XlZaUsn/DafVwNm15nWKskQA== X-Received: by 10.107.178.5 with SMTP id b5mr4042845iof.230.1485984780196; Wed, 01 Feb 2017 13:33:00 -0800 (PST) Received: from [192.168.43.27] (mobile-107-92-123-98.mycingular.net. [107.92.123.98]) by smtp.gmail.com with ESMTPSA id g78sm12533550ioi.41.2017.02.01.13.32.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 13:32:59 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_998F9CF4-AF99-4D61-84AD-DED6740A81AD" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 1 Feb 2017 16:32:53 -0500 In-Reply-To: To: Bob Harold References: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop , Ralph Droms Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 21:33:02 -0000 --Apple-Mail=_998F9CF4-AF99-4D61-84AD-DED6740A81AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 1, 2017, at 4:09 PM, Bob Harold wrote: > As I understand it, the idea is that if someone incorrectly looks up a = .alt name in DNS, we want an answer that causes the requester and = recursive resolver to not ask again, both to reduce traffic to the = roots, and to minimize leakage of information. If querying = 'something.alt', a delegation would be cached at the '.alt' level, but = an NXDOMAIN would be cached as 'something.alt', and 'other.alt' would = not be covered. Hm, I thought we just solved that problem with the aggressive negative = caching draft. --Apple-Mail=_998F9CF4-AF99-4D61-84AD-DED6740A81AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 1, 2017, at 4:09 PM, Bob Harold <rharolde@umich.edu> = wrote:
As I understand it, the idea is that if someone = incorrectly looks up a .alt name in DNS, we want an answer that causes = the requester and recursive resolver to not ask again, both to reduce = traffic to the roots, and to minimize leakage of information.  If = querying 'something.alt', a delegation would be cached at the '.alt' = level, but an NXDOMAIN would be cached as 'something.alt', and = 'other.alt' would not be covered.

Hm, I thought we just solved that problem = with the aggressive negative caching draft.

= --Apple-Mail=_998F9CF4-AF99-4D61-84AD-DED6740A81AD-- From nobody Wed Feb 1 13:43:01 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2624B129A65 for ; Wed, 1 Feb 2017 13:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 yPk-1u4MO6d1 for ; Wed, 1 Feb 2017 13:42:49 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855EA129A71 for ; Wed, 1 Feb 2017 13:42:35 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id B79391FCAB6; Wed, 1 Feb 2017 21:42:31 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 66405160042; Wed, 1 Feb 2017 21:42:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4F6FE160070; Wed, 1 Feb 2017 21:42:30 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5muPficYI6gr; Wed, 1 Feb 2017 21:42:30 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id CD9EC160042; Wed, 1 Feb 2017 21:42:29 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 66A4061165DC; Thu, 2 Feb 2017 08:42:26 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> In-reply-to: Your message of "Wed, 01 Feb 2017 15:58:41 -0500." <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> Date: Thu, 02 Feb 2017 08:42:26 +1100 Message-Id: <20170201214226.66A4061165DC@rock.dv.isc.org> Archived-At: Cc: dnsop , Ralph Droms Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 21:42:50 -0000 In message <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com>, Ted Lemon writes: > > On Feb 1, 2017, at 3:50 PM, Ralph Droms wrote: > >> It appears to me that requesting an insecure delegation is the right > >> thing to do, as a "technical use". We have, so far, been very careful in > >> what we ask for. If ICANN does not agree, then we can discuss other > >> options. > > > > I agree. > > I'm confused. The .ALT TLD is expected to be used for non-DNS name > lookups. So isn't a secure denial of existence exactly what we want for > .ALT? No. > What is the utility in having an un-signed delegation? Alt can be used for whatever purpose that the user wants to use it for including names served using the DNS protocol. The only requirement is that leaked queries for ".alt" get NXDOMAIN and that queries for 'alt.' get a NODATA response other than for SOA and NS. Signing those answers would further constrain how the namespace is used. Additionally such leaked queries should be answered as early as possible in the resolution processes to reduce the privacy exposure. The simple way to achieve that is to recursive server serve a "empty" 'alt.' zone. If there is a secure delegation then every recursive server would need to continually transfer a copy of that zone from some designated servers as the contents would need to be re-signed periodically. If there is a insecure delegation then no transfer of zone contents is needed as the entire contents can be hard coded into the server with only the decision about whether to serve the zone or not being needed to be made. We do this for 10.IN-ADDR.ARPA today. The rest of the configuration of the server decides if 10.IN-ADDR.ARPA is automatially served with a way to explictly disable the serving. For 10.IN-ADDR.ARPA we actually constuct a entire zone automatically as people configure zones like 0.0.10.IN-ADDR.ARPA and the intermediate names need to get a NODATA response. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 1 14:11:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB112958E for ; Wed, 1 Feb 2017 14:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrZXPNtrD-Wx for ; Wed, 1 Feb 2017 14:11:38 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 A86B212945C for ; Wed, 1 Feb 2017 14:11:38 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id w20so215270436qtb.1 for ; Wed, 01 Feb 2017 14:11:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=3KkrO/ZFW7FrgHQ6uBraOyWfMkq/XBt6xm0h4CsRjl4=; b=KuttmINYzfORzXBSXxProIZkFfPm06wdnPgF/3nO/46BZ471JDXNX6aADcTnGfPMJ9 Z4id2JXZMaDbtIMFXSH52H1jevmcQQm9C6NQxAoNn0bk0nKWizl0y3Z0iq5dTdu/ZvNA +Fb7EGiddh8vTAWZPyIwy5+HMG9GdC1xYPxpk2nW/GdmRIxq3NVryvRTZQvQjTL3lopn 7xPcxivdI5mZ1MwDW9cDwCjF2PyaD+lHgkKLmY++vx9j5NYE0SR9RSv1pJuZE98XpfVY hKhuHgqDygCxRtXL0hcZC535B0tsWBOUnkxO3VOYjkezpjWJqwQ0+qhiwW5JQggZFqhd aShw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=3KkrO/ZFW7FrgHQ6uBraOyWfMkq/XBt6xm0h4CsRjl4=; b=Yxq0+HZFZq8QQppN4JuoEjE/tf9cUL6efhjh45DZBdjes3SJ/NN7Vkau2p0X3xK+fy 1MX+cSs+m6Fzr/QvSnLcWAE4mbtzgyHTuAQ4E2K1f9p9DuDnf9mXS0BF6FprK5urLL8T eAS1PbW8FdZusmDqAWxHmB6Fc3CWj0gJPvCeXU4Rj6egz2m+kLvfc+ylFZRIusLbPUuZ l9zPPZLO5RzhvAkusUBML9D7sYBoJvJuMN3HKexzqh2MR+a7AWqwAqDIpT4pK7fWlWZE 3eEdbeyqCvxZScywtxC3MeipVR8ikFxr2yYpw3Rpbb7No7hzLa24plPY3nYvr7l9cHQH 3gPA== X-Gm-Message-State: AMke39mymUBtnBQXs/JBvim8z5nF0yyCxxCAERliBM2NDu4NfV+7GqSM8nIItX/RjkPLFQ== X-Received: by 10.55.74.3 with SMTP id x3mr5290555qka.275.1485987096371; Wed, 01 Feb 2017 14:11:36 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:adeb:fc66:eae1:f611? ([2601:18f:801:600:adeb:fc66:eae1:f611]) by smtp.gmail.com with ESMTPSA id h62sm4742166qkc.23.2017.02.01.14.11.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 14:11:36 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 1 Feb 2017 17:11:35 -0500 References: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> <20170201214226.66A4061165DC@rock.dv.isc.org> To: dnsop In-Reply-To: <20170201214226.66A4061165DC@rock.dv.isc.org> Message-Id: <9E3BFAAD-1F39-457B-95F1-A9E99B75151E@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 22:11:41 -0000 > On Feb 1, 2017, at 4:42 PM, Mark Andrews wrote: >=20 >=20 > In message <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com>, Ted Lemon = writes: >>=20 >> On Feb 1, 2017, at 3:50 PM, Ralph Droms = wrote: >>>> It appears to me that requesting an insecure delegation is the = right >>>> thing to do, as a "technical use". We have, so far, been very = careful in >>>> what we ask for. If ICANN does not agree, then we can discuss = other >>>> options. >>>=20 >>> I agree. >>=20 >> I'm confused. The .ALT TLD is expected to be used for non-DNS name >> lookups. So isn't a secure denial of existence exactly what we want = for >> .ALT? >=20 > No. >=20 >> What is the utility in having an un-signed delegation? >=20 > Alt can be used for whatever purpose that the user wants to use it > for including names served using the DNS protocol. The draft restricts use of .alt as follows: This label is intended to be used as the final (rightmost) label to signify that the name is not rooted in the DNS, and that normal registration and lookup rules do not apply. ...which would lead me to believe .alt would not be used for names = served using the DNS protocol. However, the phrase "not rooted in the DNS" might need some = clarification. In particular, would ".homenet.alt" be OK, as it is a locally-served = zone, not a subdomain of the root zone? - Ralph >=20 > The only requirement is that leaked queries for ".alt" get > NXDOMAIN and that queries for 'alt.' get a NODATA response other > than for SOA and NS. Signing those answers would further constrain > how the namespace is used. Additionally such leaked queries should > be answered as early as possible in the resolution processes to > reduce the privacy exposure. >=20 > The simple way to achieve that is to recursive server serve a "empty" > 'alt.' zone. If there is a secure delegation then every recursive > server would need to continually transfer a copy of that zone from > some designated servers as the contents would need to be re-signed > periodically. If there is a insecure delegation then no transfer > of zone contents is needed as the entire contents can be hard coded > into the server with only the decision about whether to serve the > zone or not being needed to be made. >=20 > We do this for 10.IN-ADDR.ARPA today. The rest of the configuration > of the server decides if 10.IN-ADDR.ARPA is automatially served > with a way to explictly disable the serving. For 10.IN-ADDR.ARPA > we actually constuct a entire zone automatically as people configure > zones like 0.0.10.IN-ADDR.ARPA and the intermediate names need to > get a NODATA response. >=20 > Mark >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 1 14:13:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A602D1295B7 for ; Wed, 1 Feb 2017 14:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcwtZJbx0kBY for ; Wed, 1 Feb 2017 14:12:58 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 42D7E1295BC for ; Wed, 1 Feb 2017 14:12:53 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id k15so290181121qtg.3 for ; Wed, 01 Feb 2017 14:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Fa4wyt2k1Xfhg1ebuSyN3PDbHa7iQaTIhmpCeXWIBro=; b=f+PKhneYDgvoj/RUl/0Tk9twHqnw+3NYRb6VyHIAfQ2UwUmFKuxCIC25Q2faI+ha1P 94K27Y2zq+jYitmqCVWBl87OaXc68WVUF6A8A9qaOVTdp0uWXcs4STVGipzF/n7VzFeh z2u9XYDJcS7yTm0E2T0IPgInKmUQnHUImBachVHsAMRM2hjPQrVwQzwvUpCn3b37/Zgs TBnrYro1MsVzm9EMran7WBcaiuTEi/eqFUyn2gvtk1k7Xsj9d5khQrntMjSjZlXBkYzs YbqJXY6j0ZXL4hlgs35q2PiyM0EdPwFc8LzIK5Qj5lHsCa7U9XIAUEdi82K55KBLu0b/ 8Gvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Fa4wyt2k1Xfhg1ebuSyN3PDbHa7iQaTIhmpCeXWIBro=; b=Whe1Ea5/AeuJ+TuJc5PFV2EkKeWAZALn1EotL1bAjQiVxIkUAIUDtv9l9rPnEL7k8t WYKl/mnHJ9Sir3St8IGWnpd913bGoBcUvU4KwT1KxKOrONq48xOw4JuXCt842DwXLTsb Tl9dd1CQikM473cFaxk8TkWaOOuoeu5pH0PGIg0NauTVLwVQL9tplXsy3wI8gthZue+t BJpT0AHRagQjO0+ECegDTllJQLUdPt/6p9tabXBSxYxaGYhv7eQ853EU2744vL0mmv10 uFiKeP0JRUq61pIqm3+zQxzaDJdfvaMMv938kkexZHJCqNqSncIXHByGSrGrBnvfTIDz Pjew== X-Gm-Message-State: AMke39lPQk5H/nbuPYN4KMCuJ8Q6Y4MuDDSZn+rye2DYoTlBPxU6U0DXQnr66EkbSVpksg== X-Received: by 10.55.212.157 with SMTP id s29mr5536440qks.240.1485987172303; Wed, 01 Feb 2017 14:12:52 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:adeb:fc66:eae1:f611? ([2601:18f:801:600:adeb:fc66:eae1:f611]) by smtp.gmail.com with ESMTPSA id a70sm19740135qkc.1.2017.02.01.14.12.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 14:12:51 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 1 Feb 2017 17:12:51 -0500 References: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> To: dnsop In-Reply-To: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> Message-Id: <6C409082-BE21-490D-800F-CB44A0A40B80@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 22:12:59 -0000 > On Feb 1, 2017, at 3:58 PM, Ted Lemon wrote: >=20 > On Feb 1, 2017, at 3:50 PM, Ralph Droms wrote: >>> It appears to me that requesting an insecure delegation is the right = thing to do, as a "technical use". We have, so far, been very careful = in what we ask for. If ICANN does not agree, then we can discuss other = options. >>=20 >> I agree. >=20 > I'm confused. The .ALT TLD is expected to be used for non-DNS name = lookups. So isn't a secure denial of existence exactly what we want = for .ALT? What is the utility in having an un-signed delegation? >=20 Sorry, I misinterpreted what I was responding to. I think I agree with = Ted that what we want is a signed delegation for secure denial of = existence. - Ralph >=20 From nobody Wed Feb 1 14:38:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3491295EC for ; Wed, 1 Feb 2017 14:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOV_NCZxljme for ; Wed, 1 Feb 2017 14:38:20 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 7EA2D129608 for ; Wed, 1 Feb 2017 14:38:20 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id w20so216375093qtb.1 for ; Wed, 01 Feb 2017 14:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KsgDQuXEEG6uWQw5DZf8NzhaUdfVvvcCv6gNknDbKKw=; b=nbSNnrzxhBh12C47fEpjMWLpYriGQiqII1KN2qub+u/xWn0hoRaTsNnj1CHVoB1+oF KVXe+ibl4ZuFpRzTHejQUBebUSgGVka19RhIrJCTL2zyC5AguuG0ROEWlfucI5Gh5pLQ tWoNczETa03c5faaQzkNgMfLfzYSyGzi6Bu+mLR++OG5c7BH0B/U+rN9F/h7i9a3Tklu 12p5BlwlCqmj4u73QWzfbxzLQVqQmeEFSbhZNMCyi0M0DgGp/758QlwwACHuv7OSiCmW BMtzsjrUDaomn2QJxUkmcPI4fRrHJo0dE43RJQRUWdptoATrKdHK3mN1TbK6N06ZL4bY Bguw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KsgDQuXEEG6uWQw5DZf8NzhaUdfVvvcCv6gNknDbKKw=; b=N/nJvJz4RFWHLBPWcTmFAh4h2sN2z5QzksOHnekfVFjp3GMykISCtwD08ztXPB8YIZ hx09xux9CahUBt+laGVtHlkE8ed7b94P6IaqNE/Iec7/9Qd3lrxBU6DP4XEcQrG8nPGq yFaZsHBc5NhJBcLx2YpPeSvZQU0F/qoS0IU9khtai/1ALNI5KvJvbVZ9Ae2ZXpd0zgKk UoBsqg4F5A1Ron3M5kQqrB/j+nR7lkB2fMlfwyabUnFqfS4wfZ4JzhbQgdvcJ4kv77vV iZEDMU067gHXulk+w2ys2VUv6bjKddGzgvNO1orfkdxndyQMsZKNZyeMSNytYtzvZaD7 WiZA== X-Gm-Message-State: AMke39lLvqLJVmLpD7s6omd5ui8DFSXM7b0uOS+8wqChKGdiyPPMRr6/R1U5DuKFNK3AkXEEJ53I/JM4b5KGQ83L X-Received: by 10.55.212.157 with SMTP id s29mr5628089qks.240.1485988698769; Wed, 01 Feb 2017 14:38:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Wed, 1 Feb 2017 14:37:48 -0800 (PST) In-Reply-To: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> From: Warren Kumari Date: Wed, 1 Feb 2017 17:37:48 -0500 Message-ID: To: Robert Edmonds Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 22:38:22 -0000 I'm sorry, I apparently did some overly aggressive editing of my mail before sending it (or I'm completely confused, which is ALWAYS a possibility). In order to try and stop leaks, the draft requests that the domain be added to the "Locally Served Zones" registry. This means that, when a validating stub A goes off and queries it's recursive server B for 'foo.alt', it will get back an (authoritative) answer from B, saying that there is nothing under .alt -- e.g: # dig foo.alt @204.194.23.4 ; <<>> DiG 9.11.0-P2 <<>> foo.alt @204.194.23.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36039 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 0797210975d60eb10da3940d58926228926455130e02e825 (good) ;; QUESTION SECTION: ;foo.alt. IN A ;; AUTHORITY SECTION: alt. 604800 IN SOA alt. alt. 1 604800 86400 2419200 604800 ;; Query time: 0 msec ;; SERVER: 204.194.23.4#53(204.194.23.4) ;; WHEN: Wed Feb 01 17:33:12 EST 2017 ;; MSG SIZE rcvd: 100 I **think** (perhaps incorrectly!), that when the validating stub (A) tries to validate this, it will see that there is an NSEC at the root which says that there is nothing between 'alstom' and 'am'. This makes it look like someone has tried to make .alt sprint into existence -- I had thought that the correct error for that is SERVFAIL, not NXD, but it is entirely possible that I'm wrong.... W On Wed, Feb 1, 2017 at 3:44 PM, Robert Edmonds wrote: > Warren Kumari wrote: >> The largest outstanding issue is what to do about DNSSEC -- this is >> (potentially) a problem for any / all 6761 type names. >> The root is signed, so if a query leaks into the DNS (as they will), >> an (unaware) validating resolver will try resolve it, and will expect >> either a signed answer, or proof of an insecure delegation; without >> this things will look bogus, and so resolvers will SERVFAIL. >> >> Clearly, a signed answer isn't feasible, so that leaves 2 options - 1: >> simply note that validation will fail, and that SERVFAIL will be >> returned in many case (to me this seems "correct"), or 2: request that >> the IANA insert an insecure delegation in the root, pointing to a: >> AS112 or b: an empty zone on the root or c" something similar. > > Hi, Warren: > > I'm kind of confused. If a .ALT query leaks into the DNS, and there's > neither a secure or insecure delegation in the root, isn't the result a > signed NXDOMAIN, not a SERVFAIL? > > ; <<>> DiG 9.11.0-P1 <<>> +dnssec foo.alt > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36917 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 > > -- > Robert Edmonds -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Feb 1 15:47:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A58129625 for ; Wed, 1 Feb 2017 15:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw3CG2ADUGau for ; Wed, 1 Feb 2017 15:47:22 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 5023D129623 for ; Wed, 1 Feb 2017 15:47:22 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id w20so219159327qtb.1 for ; Wed, 01 Feb 2017 15:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n8NDq06KYfQNyAJXdTTw6D9d6h9xaTSt9T1ffCLey7I=; b=iNHuB6gVuAsNaKeL6t39ojEFo5dI4mOSZdJKg6YtYCibZhh5Ope5uRBtFEOSDaX/7V tKVQJGwtuHKIwUuqRbAiinwUheYwP25VFyY/XOMxjp+UUljv7GOBYSyOBL6KZDy0edH0 Jhp/8+GmD+0m6x8p3XiNn33h1UpcPZsmqUINkmnRs0wJkkoGDGOwgZp3gzPGLPA1NRxv tZmoYDhmGVj45XR7WDirwCljcesCsQtBWjnqcj2Lgftj0/mIh0ydDyxoA0m0id27Q/Uh CtLC6HKDHD+1JCQkyLKKlG9BMkiw4s3cfTxBHHYP8Xe5ixyK7w/abalXiXwObw2s0QwJ R0wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n8NDq06KYfQNyAJXdTTw6D9d6h9xaTSt9T1ffCLey7I=; b=YEsYij5MzevJHX/+xE24EaV/4xJQDrjiadwjGHkI83QkSV/QeiLYBcUM2ZRDNsGK+a 61VRMpkOEKKOzH/1UPKLyebqf458TfTkyZh0uspyxrsKPkM5C3vz2ZKo+itvcpst77Kf B1cGqasoR4oMNYN6hfk/2Hp+4DPJsry7jopBtkiOivviSkfUk+pbHBoVfw6gwcZrQ941 B0IA87XK8oxOBj5WMH4wPPIX8x5SBnAvszC1RNq2mKXaC0vgvOHljBRIvMgeHWYDXHTO WWWq3nasQLPISg5uyQw7mukil0d8zfEhkIXX26FGCXvM0eYjNcH1yXhZFtwpJ0mKXzTW AUrw== X-Gm-Message-State: AMke39lXpU9g2aDzHS9X882TFYqa7YHbwTUMTHzx6nBMUDc5nMkfpnhYM6f+g8yBZpt7ANFnX5zVFmEoEtGugFL6 X-Received: by 10.55.78.67 with SMTP id c64mr5857922qkb.251.1485992841227; Wed, 01 Feb 2017 15:47:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Wed, 1 Feb 2017 15:46:50 -0800 (PST) In-Reply-To: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> From: Warren Kumari Date: Wed, 1 Feb 2017 18:46:50 -0500 Message-ID: To: Robert Edmonds Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 23:47:24 -0000 On Wed, Feb 1, 2017 at 3:44 PM, Robert Edmonds wrote: > Warren Kumari wrote: >> The largest outstanding issue is what to do about DNSSEC -- this is >> (potentially) a problem for any / all 6761 type names. >> The root is signed, so if a query leaks into the DNS (as they will), >> an (unaware) validating resolver will try resolve it, and will expect >> either a signed answer, or proof of an insecure delegation; without >> this things will look bogus, and so resolvers will SERVFAIL. >> >> Clearly, a signed answer isn't feasible, so that leaves 2 options - 1: >> simply note that validation will fail, and that SERVFAIL will be >> returned in many case (to me this seems "correct"), or 2: request that >> the IANA insert an insecure delegation in the root, pointing to a: >> AS112 or b: an empty zone on the root or c" something similar. > > Hi, Warren: > > I'm kind of confused. If a .ALT query leaks into the DNS, and there's > neither a secure or insecure delegation in the root, isn't the result a > signed NXDOMAIN, not a SERVFAIL? > > ; <<>> DiG 9.11.0-P1 <<>> +dnssec foo.alt > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36917 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 Yup, but if a resolver has a (empty) local zone for .alt, and someone queries it and validates, then I think you get SERVFAIL -- the root says .alt doesn't exist, but here you have an answer apparently from inside the zone -- 'tis an empty / NXD answer, but still looks like shenanigans are happening... W > > -- > Robert Edmonds -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Feb 1 16:02:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C04F1295F8 for ; Wed, 1 Feb 2017 16:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 0HEX7tL5QHUo for ; Wed, 1 Feb 2017 16:02:42 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36D8129577 for ; Wed, 1 Feb 2017 16:02:42 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 9F21E349314; Thu, 2 Feb 2017 00:02:40 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 772E9160071; Thu, 2 Feb 2017 00:02:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5B3D1160070; Thu, 2 Feb 2017 00:02:40 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VYgkkXIzxl_e; Thu, 2 Feb 2017 00:02:40 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id BCAB2160042; Thu, 2 Feb 2017 00:02:39 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A29556117F7F; Thu, 2 Feb 2017 11:02:35 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> In-reply-to: Your message of "Wed, 01 Feb 2017 15:58:41 -0500." <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> Date: Thu, 02 Feb 2017 11:02:35 +1100 Message-Id: <20170202000235.A29556117F7F@rock.dv.isc.org> Archived-At: Cc: dnsop , Ralph Droms Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:02:43 -0000 In message <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com>, Ted Lemon writes: > > On Feb 1, 2017, at 3:50 PM, Ralph Droms wrote: > >> It appears to me that requesting an insecure delegation is the right > >> thing to do, as a "technical use". We have, so far, been very careful in > >> what we ask for. If ICANN does not agree, then we can discuss other > >> options. > > > > I agree. > > I'm confused. The .ALT TLD is expected to be used for non-DNS name > lookups. The .ALT TLD is a sandbox to play in. It is a place where people can graft on alternative namespaces to play with. The names in it are not expected to be reachable in the DNS following normal DNS delegations from the root zone. This does NOT mean they are non-DNS names. I would expect all the names used in it to be syntactially valid DNS names (able to be converted to DNS wire format) but there is nothing we can do to enforce that. If they aren't convertable tools will fail to parse the names if they leak. They may be looked up using the DNS (e.g. like homenet). They may be looked up using other protocols (e.g. something like TOR). Its a place where people know that there is a risk of namespace collisions as there is no registry to prevent that. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 2 11:32:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033EB12997E for ; Thu, 2 Feb 2017 11:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 ScNzTDU6QnMt for ; Thu, 2 Feb 2017 11:32:17 -0800 (PST) Received: from out.east.pexch112.icann.org (pfe112-va-1.pexch112.icann.org [162.216.194.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D9C129975 for ; Thu, 2 Feb 2017 11:32:17 -0800 (PST) Received: from PMBX112-E1-VA-2.pexch112.icann.org (162.216.194.26) by PMBX112-E1-VA-1.pexch112.icann.org (162.216.194.24) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 2 Feb 2017 11:32:14 -0800 Received: from PMBX112-E1-VA-2.pexch112.icann.org ([162.216.194.26]) by PMBX112-E1-VA-2.PEXCH112.ICANN.ORG ([162.216.194.26]) with mapi id 15.00.1178.000; Thu, 2 Feb 2017 11:32:13 -0800 From: Matt Larson To: dnsop WG Thread-Topic: Announcement of ICANN DNS Symposium Thread-Index: AQHSfYsN/ICX0Uh3kkCSSlx+kpVGLg== Date: Thu, 2 Feb 2017 19:32:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: text/plain; charset="utf-8" Content-ID: <4A4D94412FDDE443A4C07D35DD398DDA@pexch112.icann.org> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [DNSOP] Announcement of ICANN DNS Symposium X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:32:19 -0000 KFRoaXMgZW1haWwgaXMgc2VudCBmcm9tIG15IHBlcnNvbmFsIGFjY291bnQgYmVjYXVzZSB0aGF0 J3MgaG93IEknbSBzdWJzY3JpYmVkLCBhbmQgSSBhcG9sb2dpemUgaWYgeW91IHJlY2VpdmUgbXVs dGlwbGUgY29waWVzLikNCg0KRGVhciBjb2xsZWFndWVzLA0KDQpJJ2QgbGlrZSB0byBpbnZpdGUg eW91IHRvIHRoZSBmaXJzdC1ldmVyIElDQU5OIEROUyBTeW1wb3NpdW0sIHdoaWNoIHdpbGwgYmUg aGVsZCBpbiBNYWRyaWQsIFNwYWluLCBvbiBTYXR1cmRheSwgMTMgTWF5IDIwMTcuDQoNCklDQU5O J3MgT2ZmaWNlIG9mIHRoZSBDVE8gaG9wZXMgdG8gbWFrZSB0aGUgSUNBTk4gRE5TIFN5bXBvc2l1 bSBhIHJlZ3VsYXIgZXZlbnQgZm9yIHRoZSBETlMgdGVjaG5pY2FsIGNvbW11bml0eSB3aXRoIGNo YW5naW5nIHRoZW1lcyBjb3ZlcmluZyBkaWZmZXJlbnQgYXNwZWN0cyBvZiBETlMuICBGb3IgdGhp cyBpbml0aWFsIGV2ZW50LCB3ZSBhcmUgZm9jdXNpbmcgb24gRE5TLXJlbGF0ZWQgYWN0aXZpdGll cyB3aXRoaW4gSUNBTk4uICBUaGVyZSB3aWxsIGJlIHByZXNlbnRhdGlvbnMgcmVsYXRpbmcgdG8g RE5TIHJlc2VhcmNoLCBzZWN1cml0eSwgcm9vdCBzZXJ2ZXIgb3BlcmF0aW9ucywgSUFOQSBhbmQg bW9yZS4gIE11bHRpcGxlIElDQU5OIGRlcGFydG1lbnRzIHdpbGwgcHJlc2VudCwgaW5jbHVkaW5n IHRoZSBPZmZpY2Ugb2YgdGhlIENUTywgRE5TIEVuZ2luZWVyaW5nIChyZXNwb25zaWJsZSBmb3Ig TC1yb290IG9wZXJhdGlvbnMpLCBQVEkvSUFOQSBhbmQgdGhlIEdsb2JhbCBEb21haW5zIERpdmlz aW9uIChnVExEcykuICBPdXIgZ29hbCBpcyB0byBiZSB0cmFuc3BhcmVudCB3aXRoIHRoZSBjb21t dW5pdHkgYWJvdXQgRE5TIGFjdGl2aXRpZXMgaGFwcGVuaW5nIGF0IElDQU5OIGFuZCBzb2xpY2l0 IGZlZWRiYWNrIGFuZCBzdWdnZXN0aW9ucy4NCg0KTW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUg U3ltcG9zaXVtIGlzIGF2YWlsYWJsZSBhdCBodHRwczovL3d3dy5pY2Fubi5vcmcvaWRzLg0KDQpB IHdlbGNvbWUgcmVjZXB0aW9uIHdpbGwgYmUgaGVsZCBvbiBGcmlkYXkgZXZlbmluZywgMTIgTWF5 LiAgQWxzbywgcGxlYXNlIG5vdGUgdGhhdCB0aGUgU3ltcG9zaXVtIGlzIGNvbG9jYXRlZCB3aXRo IHNldmVyYWwgb3RoZXIgZXZlbnRzOg0KDQotIElDQU5OIEdERCBJbmR1c3RyeSBTdW1taXQgKDkt MTEgTWF5KSAoaHR0cHM6Ly93d3cuaWNhbm4ub3JnL2dkZHN1bW1pdCkNCi0gVGhlIDZ0aCBSZWdp c3RyYXRpb24gT3BlcmF0aW9ucyBXb3Jrc2hvcCAoMTIgTWF5KSAoaHR0cDovL3JlZ2lvcHMubmV0 KQ0KLSBJQ0FOTiBETlMgU3ltcG9zaXVtICgxMyBNYXkpIChodHRwczovL3d3dy5pY2Fubi5vcmcv aWRzKQ0KLSBPQVJDIDI2IChETlMtT0FSQyBXb3Jrc2hvcCkgKDE0LTE1IE1heSkgKGh0dHBzOi8v aW5kaWNvLmRucy1vYXJjLm5ldC9ldmVudC8yNikNCg0KQWxsIGV2ZW50cyB3aWxsIGJlIGhlbGQg aW4gdGhlIHNhbWUgdmVudWUsIEhvdGVsIE5IIENvbGxlY3Rpb24gTWFkcmlkIEV1cm9idWlsZGlu ZywgQ2FsbGUgZGUgUGFkcmUgRGFtacOhbiwgMjMsIDI4MDM2LCBNYWRyaWQsIFNwYWluLg0KDQpS ZWdpc3RlciBmb3IgdGhlIFN5bXBvc2l1bSBub3cgYXQgaHR0cHM6Ly9yZWdpc3RyYXRpb24uaWNh bm4ub3JnL3JlZ2lzdGVyLnBocD9pZD1kbnMtc3ltcG9zaXVtLTIwMTcuDQoNCkkgaG9wZSB0byBz ZWUgeW91IGluIFNwYWluIQ0KDQpNYXR0DQotLQ0KTWF0dCBMYXJzb24gPG1hdHQubGFyc29uQGlj YW5uLm9yZz4NClZQIG9mIFJlc2VhcmNoLCBPZmZpY2Ugb2YgdGhlIENUTywgSUNBTk4NCisxIDI0 MCA0NTktOTU2MiAobW9iaWxlKQ0KDQo= From nobody Thu Feb 2 12:52:13 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54A71297BD for ; Thu, 2 Feb 2017 12:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTHJINzKBNMw for ; Thu, 2 Feb 2017 12:52:11 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 0481912956B for ; Thu, 2 Feb 2017 12:52:11 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id x49so51713304qtc.2 for ; Thu, 02 Feb 2017 12:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=jdvtd1ugG6T2bFyB4zj7YnKOEuOzzf0xx7vg/KAiZqE=; b=gGh4Om0ILGYNAJek4joMTliYdog9MSPuKsiD6hYoIWXML1gfgMfWV6VxbNcdvUoGKA SY1YCrqYL7d5JVBUvnNXhOQnoiOijuvyHdwzErJZuKrRIvWvno9G/9WEg8RDavhjVHIz K38HnmlSQ2npredX7UcbNO+FAxOrXgI8NLMf5yu4/ktKBS479cK3/7fO6T4G08Z8wwS6 nwiv0P2grzUgWh7uqn4lwhpy1Ba331+Iiqk6ZbINEvIjN/HJUURVsgx+nmqNzAHSMy0h N2rwFOcP9ylkpNaTjcCc9SQMN/I/HD0uJiSqEaNmMKRtLolP6Mn9pWecWVQlR9zcReev /Ntg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=jdvtd1ugG6T2bFyB4zj7YnKOEuOzzf0xx7vg/KAiZqE=; b=n/Wqmts9iXDoCpi7CsJGyp5iLcHbcalYNUL7FrZbkfDxNejdqpSe81xIQdi0F0e9by OLSHy7t99IoNFwZkW1YKCLH6fsL4fOTBJF0QWzGZSdpN4lP1qFi5gYTh8kyglQFz/Thx kUKwtHOHNruryO0Yy07rmV8LeMkTG+rpiFd7jhmTBYkjKK/GXcRTAhRBCO/i3Ox4F6/F /00ykygzSPMTBQKU4gQFHNw78RlTi1LkobTmlop8txfoynOEF3DahPO/YRW05rswNFqh z2Sk9RAvl7PjLHmrUzbqmsENwbwwecasoYQ2yUnaCuc3acoqx18KvNAQ/i38Sl64cCLL kOdg== X-Gm-Message-State: AIkVDXLFKnE7SuVIGOymD29X112SnEyX1eYlNRKEW/aevyhV5KyuEBiU4c/eNOahE5/w3w== X-Received: by 10.237.37.90 with SMTP id w26mr9956539qtc.112.1486068729588; Thu, 02 Feb 2017 12:52:09 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:4857:1239:3f83:3891? ([2601:181:c381:c20:4857:1239:3f83:3891]) by smtp.gmail.com with ESMTPSA id l20sm22485921qtc.5.2017.02.02.12.52.08 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Feb 2017 12:52:09 -0800 (PST) From: Suzanne Woolf Content-Type: multipart/alternative; boundary="Apple-Mail=_9BECC7D6-2518-4C33-8E21-7983869FE467" Message-Id: Date: Thu, 2 Feb 2017 15:52:07 -0500 To: dnsop Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [DNSOP] virtual interim DNSOP WG meeting and current status, special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 20:52:12 -0000 --Apple-Mail=_9BECC7D6-2518-4C33-8E21-7983869FE467 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, We=E2=80=99ve been behind the curve because one of us (Suzanne) has been = ill, but here=E2=80=99s where we are, including time/date for the = virtual interim we=E2=80=99re planning: 1. There=E2=80=99s a new revision of the special use names problem = statement, https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ = Please review, particularly if you haven=E2=80=99t looked at it recently = or had new concerns raised by the discussion in Seoul and on the list = about the HOMENET WG. We=E2=80=99re starting Working Group Last Call on it (see next message = for the formal kickoff). 2. The alt-tld draft has been revised in view of the discussion in = homenet about DNSSEC resolution and DNS protocol for local names under = .homenet. That too has been posted and Warren has kicked off a = discussion here ("Subject: ALT-TLD and (insecure) delgations.") about = how to handle that issue: = https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ = 3. We still want (and have time) to do a virtual interim WG meeting = before Chicago. We=E2=80=99ve picked a date: Thursday 17 February, 19:00 UTC, which is: 19:00 UTC 20:00 CEST (Frankfurt, Stockholm) 14:00 EST (North American Eastern) 11:00 PST (North American Western) 06:00 AEDT (Sydney, Melbourne) (Webex details will follow) As usual, scheduling isn=E2=80=99t perfect for anyone but we tried to = cover the largest possible area of the globe adequately. Preliminary agenda for the meeting is: 1. Issues from WGLC on the problem statement = (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ = ) 2. Proposals for moving forward: * reviews of alt-tld; ready for WGLC? will it help? = (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ = ) * stop here? (leave RFC 6761 as-is, continue to process = registry changes case-by-case) * proposals for process revision/update? 3. Next steps:=20 * any drafts to write? * any input or liaison to request from the IAB? = (regarding either namespace architecture or relationships of the IETF = with other groups) 4. AOB: your I-D or proposed action for the WG/IESG/IAB here thanks, Suzanne & Tim --Apple-Mail=_9BECC7D6-2518-4C33-8E21-7983869FE467 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

We=E2=80=99ve been behind = the curve because one of us (Suzanne) has been ill, but here=E2=80=99s = where we are, including time/date for the virtual interim we=E2=80=99re = planning:

1. There=E2=80=99s a new revision = of the special use names problem statement, https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/=

Please review, particularly if you = haven=E2=80=99t looked at it recently or had new concerns raised by the = discussion in Seoul and on the list about the HOMENET WG.

We=E2=80=99re starting Working Group Last Call = on it (see next message for the formal kickoff).

2. The alt-tld draft has been revised in view of the = discussion in homenet about DNSSEC resolution and DNS protocol for local = names under .homenet. That too has been posted and Warren has kicked off = a discussion here ("Subject: ALT-TLD and (insecure) = delgations.") about how to handle that issue: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/<= br class=3D"">
3. We still want (and have time) to do a = virtual interim WG meeting before Chicago. We=E2=80=99ve picked a = date:

Thursday 17 February, 19:00 UTC, which is:

19:00 UTC
20:00 CEST (Frankfurt, Stockholm)
14:00 = EST (North American Eastern)
11:00 PST (North = American Western)
06:00 AEDT (Sydney, = Melbourne)

(Webex details will = follow)

As usual, = scheduling isn=E2=80=99t perfect for anyone but we tried to cover the = largest possible area of the globe adequately.

Preliminary agenda for the meeting is:

= 1. Issues from WGLC on the problem statement (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/= )
2. Proposals for moving forward:
* reviews = of alt-tld; ready for WGLC? will it help? (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/)=
* stop here? (leave RFC 6761 as-is, continue to process = registry changes case-by-case)
* = proposals for process revision/update?
3. Next = steps: 
* any drafts to write?
= = * any input or liaison to request from the IAB? (regarding either = namespace architecture or relationships of the IETF with other = groups)
4. AOB: your I-D or proposed = action for the WG/IESG/IAB here


thanks,
Suzanne & Tim

= --Apple-Mail=_9BECC7D6-2518-4C33-8E21-7983869FE467-- From nobody Thu Feb 2 12:58:13 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4CA129526 for ; Thu, 2 Feb 2017 12:58:11 -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] 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 46V5BtE7SaoN for ; Thu, 2 Feb 2017 12:58:09 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9BE1293E4 for ; Thu, 2 Feb 2017 12:58:09 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 92B0E31C9C; Thu, 2 Feb 2017 21:58:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 193AC190A4E; Thu, 2 Feb 2017 21:57:38 +0100 (CET) Date: Thu, 2 Feb 2017 21:57:38 +0100 From: Stephane Bortzmeyer To: Warren Kumari Message-ID: <20170202205737.GA21531@sources.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.7 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 20:58:11 -0000 On Wed, Feb 01, 2017 at 03:28:29PM -0500, Warren Kumari wrote a message of 103 lines which said: > or 2: request that the IANA insert an insecure delegation in the > root, pointing to a: AS112 or b: an empty zone on the root or c" > something similar. Here, people may be interested by draft-bortzmeyer-dname-root (expired but could be revived). The main objection was the privacy issue (sending user queries to the "random" operators of AS112.) From nobody Thu Feb 2 13:48:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348471299E2 for ; Thu, 2 Feb 2017 13:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id io8PtPPWhoah for ; Thu, 2 Feb 2017 13:48:25 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 18243129431 for ; Thu, 2 Feb 2017 13:48:25 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id w20so1758235qtb.1 for ; Thu, 02 Feb 2017 13:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=0QmP2aGepfS3oF99s5klw+kuEoBflx/f8V2lbJX2pSg=; b=sxfktpn6x+q/mgXS4zuoVivWhTLxBT01iyac0Ga16Hy8ULhk0ZdJGr7Mfo7pXMtJu+ 1LnrAWbYiR+GGHHtQg19h7kcLEd3dvWEMzJkb8EUUXDDs98slivmavNnt/MY/c18sbf3 o2+SyAJIZpu48Ds/H9WDIJPrWoyy2BLoN/I1fNJInDfe3di3R4BlnD6Vngs1cOXNY95c M6d6EkyAtKqB1Is1Kzd0lJYK/jhF7TXkuwaZVorE0A7o7dgcxdyP4SThf2S2mYxzXgWt tPsA9xsCUFX2MlSTNdcU1mwfAh5QQGdZElyHF7HPw9/vPQFir6oi11SFhYD63I3sZuKd PUgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=0QmP2aGepfS3oF99s5klw+kuEoBflx/f8V2lbJX2pSg=; b=RExn//iIJk6qH+BjPYT6O/5W1WqNflw8TWCZRKhx0ZLyy8J8+mkhvKeZCLZhQSz7fI w69odVlo2zybPw5okulkp8Cwse/p7IzLzwS1XEGd4G2R+Q3g8vuY/HhPgL3Q+L0SBz/w spRoUXeVu0lc5R3arRRw+YaDD/prLYbeYfcVrxivQI6WHM970mXs+9yJeYHWpGTvlGDz 9pnWtCQQeVauzZt3oHYKmQlhDnVT0NaSWpJFEdK4ffY0FG86VnJUpE6/5tJhxY+NB7GM 4Ez6nkFrE4nia7tR7A7CWrRYsLqLx9IvXswlmUIbk/8S4r2NgWeqlFwuaH/rISg9GPpi cR3Q== X-Gm-Message-State: AIkVDXKndWxXQmW/6BmfXjwvs7A//W1cvk00JkSnOjXlwEeiu97StJYsXkzYt9iTP6J9tA== X-Received: by 10.237.37.58 with SMTP id v55mr10584854qtc.15.1486072102068; Thu, 02 Feb 2017 13:48:22 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:991d:a856:1421:39af? ([2601:181:c381:c20:991d:a856:1421:39af]) by smtp.gmail.com with ESMTPSA id q3sm22538198qte.0.2017.02.02.13.48.21 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Feb 2017 13:48:21 -0800 (PST) From: Suzanne Woolf Content-Type: multipart/alternative; boundary="Apple-Mail=_9DC955CC-FC3D-4B5B-A2DD-95E23831C2F8" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Thu, 2 Feb 2017 16:48:20 -0500 References: To: dnsop In-Reply-To: X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [DNSOP] correction Re: virtual interim DNSOP WG meeting and current status, special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 21:48:27 -0000 --Apple-Mail=_9DC955CC-FC3D-4B5B-A2DD-95E23831C2F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And because it=E2=80=99s been that day=E2=80=A6. Thanks for the off-list nudge, that=E2=80=99s ***Thursday 16 February*** = for most of the world, Friday 17 February for the AP region. We=E2=80=99ve blocked two hours for the meeting. Apologies for the error. Suzanne > On Feb 2, 2017, at 3:52 PM, Suzanne Woolf = wrote: > 3. We still want (and have time) to do a virtual interim WG meeting = before Chicago. We=E2=80=99ve picked a date: >=20 > Thursday 17 February, 19:00 UTC, which is: >=20 > 19:00 UTC > 20:00 CEST (Frankfurt, Stockholm) > 14:00 EST (North American Eastern) > 11:00 PST (North American Western) > 06:00 AEDT (Sydney, Melbourne) >=20 > (Webex details will follow) >=20 > As usual, scheduling isn=E2=80=99t perfect for anyone but we tried to = cover the largest possible area of the globe adequately. >=20 > Preliminary agenda for the meeting is: >=20 > 1. Issues from WGLC on the problem statement = (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ = ) > 2. Proposals for moving forward: > * reviews of alt-tld; ready for WGLC? will it help? = (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ = ) > * stop here? (leave RFC 6761 as-is, continue to process = registry changes case-by-case) > * proposals for process revision/update? > 3. Next steps:=20 > * any drafts to write? > * any input or liaison to request from the IAB? = (regarding either namespace architecture or relationships of the IETF = with other groups) > 4. AOB: your I-D or proposed action for the WG/IESG/IAB here >=20 >=20 > thanks, > Suzanne & Tim >=20 --Apple-Mail=_9DC955CC-FC3D-4B5B-A2DD-95E23831C2F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 And because it=E2=80=99s been that day=E2=80=A6.

Thanks for the off-list = nudge, that=E2=80=99s ***Thursday 16 February*** for most of the world, = Friday 17 February for the AP region.

We=E2=80=99ve blocked two hours for the = meeting.

Apologies for the error.


Suzanne


On Feb 2, 2017, at 3:52 PM, Suzanne Woolf <suzworldwide@gmail.com> wrote:
3. We still want (and = have time) to do a virtual interim WG meeting before = Chicago. We=E2=80=99ve picked a date:

Thursday 17 February, = 19:00 UTC, which is:

19:00 UTC
20:00 CEST (Frankfurt, = Stockholm)
14:00 EST (North American = Eastern)
11:00 PST (North American = Western)
06:00 AEDT (Sydney, Melbourne)

(Webex details will follow)

As usual, scheduling = isn=E2=80=99t perfect for anyone but we tried to cover the largest = possible area of the globe adequately.

Preliminary agenda for the meeting is:

= 1. Issues from WGLC on the problem statement (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/= )
2. Proposals for moving forward:
* reviews = of alt-tld; ready for WGLC? will it help? (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/)=
* stop here? (leave RFC 6761 as-is, continue to process = registry changes case-by-case)
* = proposals for process revision/update?
3. Next = steps: 
* any drafts to write?
= = * any input or liaison to request from the IAB? (regarding either = namespace architecture or relationships of the IETF with other = groups)
4. AOB: your I-D or proposed = action for the WG/IESG/IAB here


thanks,
Suzanne & Tim


= --Apple-Mail=_9DC955CC-FC3D-4B5B-A2DD-95E23831C2F8-- From nobody Thu Feb 2 15:04:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5EA1299BF for ; Thu, 2 Feb 2017 15:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfd75b5ACK56 for ; Thu, 2 Feb 2017 15:04:09 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 D8047129964 for ; Thu, 2 Feb 2017 15:04:08 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id x49so5483841qtc.2 for ; Thu, 02 Feb 2017 15:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=EqwdBtf7D/AEe9aI1TgccqulffmwlleS9PtvC/at5D0=; b=fvtUzstk67EraffdofyA8qKSZ9IysJTxXAmLWGDlqV4SxjzFaIfbmm2++9TzeKJHLi pbMAGerbeArygd09a6KXKHaIIvHC7lljcXDBrrjpSNgCdMN7EqoijZsuuAEaN6SBLMRw avQDchuHF7vC0C1vHqXuALxTTZ//oKgaUEa6xys3gf5vDZpk8+ZkIsi7+PQQWN0xq2I1 z48nfhpc8xr9fPAr9uV2pyaKMayQ+qFx46t11KrGT/kUVL/KjcjqY3aIDPvUplMUwXno jimDdI6EZQmtEJgL+cEwvAbo9PezJ2UqahpByTDSXvIzrf/ectT9ZaH3hUOdvXOcXsRu 4xdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=EqwdBtf7D/AEe9aI1TgccqulffmwlleS9PtvC/at5D0=; b=WjR3aJeCGRFmehGvgrHgCMpE7G/7uPQ3ED7ejCQQe2VFyBxd6LN0M2EXVkIwFdXhLw W3aalPMemyfV2TaecI63HrBfhl++ODE9T3emAvtimb46FC4CHLc/1pjEG/Qato4GyM/A Ge17qVvhk6UVvoJWDTq30yyOmGn+bSK+xBvYGasa2PqaCn11Mov1TCJQqe3XzGCncQDd IVZFuPf5Fv8tqTx4nY3aoeNMoFNqvM7EyceENGi3bp6gDt/WWof4uMjl+BcK3DXvtFB1 SYAok+HdSuTibJhLtoB+OHvSZtQp6534E/DdOooEGAE/wEeIWu+wHCuAyIwTdd3CWb6I Y0Pw== X-Gm-Message-State: AMke39lDBL5bjkQdhGXkXI5xalD5xogmNjte4geBNU+IRPW842MmuhCVANVplHtmm7Omow== X-Received: by 10.55.110.6 with SMTP id j6mr11390488qkc.92.1486076647520; Thu, 02 Feb 2017 15:04:07 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:991d:a856:1421:39af? ([2601:181:c381:c20:991d:a856:1421:39af]) by smtp.gmail.com with ESMTPSA id c141sm22624297qkb.10.2017.02.02.15.04.06 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Feb 2017 15:04:07 -0800 (PST) From: Suzanne Woolf Content-Type: multipart/alternative; boundary="Apple-Mail=_4B71E3D1-38FD-4CE7-92B2-169A353BDD45" Message-Id: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> Date: Thu, 2 Feb 2017 18:04:05 -0500 To: dnsop Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 23:04:10 -0000 --Apple-Mail=_4B71E3D1-38FD-4CE7-92B2-169A353BDD45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This message opens a Working Group Last Call for: "Special-Use Names Problem Statement" https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ = Proposed status: informational Starts: 2 Feb. 2017 Ends: 23 Feb. 2017 (3 weeks) Discussion should go to the mailing list.=20 Is this draft ready to advance for publication as an Informational RFC, = and as guidance for possible updates to RFC 6761? Does it describe the = relevant issues clearly, and cover all the relevant ones that should be = taken into account in future work in the IETF on the special use names = registry or RFC 6761? If not, can you suggest changes that would get your support for = advancing it? (=E2=80=9CSend text=E2=80=9D if possible!) thanks, Suzanne & Tim --Apple-Mail=_4B71E3D1-38FD-4CE7-92B2-169A353BDD45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This message opens a Working Group Last Call for:

"Special-Use Names = Problem Statement"
https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/=
Proposed status: informational

Starts: 2 Feb. = 2017
Ends: 23 Feb. 2017 (3 weeks)

Discussion should go to = the mailing list. 

Is this draft ready to advance for publication as an = Informational RFC, and as guidance for possible updates to RFC 6761? = Does it describe the relevant issues clearly, and cover all the relevant = ones that should be taken into account in future work in the IETF on the = special use names registry or RFC 6761?

If not, can you suggest changes that = would get your support for advancing it? (=E2=80=9CSend text=E2=80=9D if = possible!)


thanks,
Suzanne & Tim

= --Apple-Mail=_4B71E3D1-38FD-4CE7-92B2-169A353BDD45-- From nobody Thu Feb 2 18:42:35 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF9D129ADF for ; Thu, 2 Feb 2017 18:42:34 -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 ynIa_Soj29vc for ; Thu, 2 Feb 2017 18:42:33 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A5C129AD6 for ; Thu, 2 Feb 2017 18:42:32 -0800 (PST) Received: (qmail 85527 invoked from network); 3 Feb 2017 02:42:31 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Feb 2017 02:42:31 -0000 Date: 3 Feb 2017 02:42:09 -0000 Message-ID: <20170203024209.3584.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: suzworldwide@gmail.com Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 02:42:34 -0000 >If not, can you suggest changes that would get your support for advancing it? (“Send text” if possible!) It's closer than I had remembered. In the problem paragraph that starts at the bottom of page 6, on domain names that have been commandeered, I'd like it to say that there is no agreement on how to decide that a name has been comandeered, nor if or how to revisit a name to decide that it's been uncomandeered. (For that last, I'm thinking about .BELKIN, where the routers that leak the name will eventually all fail, or .CORP where people may use it less now that CAs don't sign certs any more.) I'd also like a mention of DNSSEC. DNSSEC is intended to provide a signature chain from the root to any leaf, but there is no way to chain to a SUTLD. There's also no agreement what to do with DNSSEC and existing SUTLDs, whether to have DNSSEC say they don't exist, or to create some sort of unsigned pseudo-delegation, or something else. R's, John From nobody Fri Feb 3 07:34:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57791129C48 for ; Fri, 3 Feb 2017 07:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=airmail.cc 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 IuIZX62UqlMn for ; Fri, 3 Feb 2017 07:34:40 -0800 (PST) Received: from cock.li (cock.li [185.100.85.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7C0129C41 for ; Fri, 3 Feb 2017 07:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1486136076; bh=ZDveUHkAMLvMRWvgMGRyPr+UbtamxftCkvHYWzuRfrM=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To:From; b=Pd/TA7OfvuQJw2nEZWJV4yNj9bOi/oAj1cTDjjIEYYRl3kppjoUxKt9YjLCYo5LGd ATj6j1PTYi/+eBgAvj6tbd1t0KOFQUsVe1RAO5iGFsQnIXVAM8zqgdEUSKRxoAO9rW /4CPS8mHnXaCBb1IGZCQ74yS7uuEepnV/8qVhs0ZqTlh7ehZY6+feYXy7kIwXgJ5N8 PFyzq/mzXpmE7SJDfGYraV0mjR70Z0zBSzwSKozjAgfsCJXeako6ZDbeHS11eTNNHS wvbs6arNoUb5QSvfnQrWLx4HW8RH4wgdhYFxASRKBBK8SyiSi41Eaq34eS4Ev5RPK5 u3RBlFA6xeQsA== References: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> To: dnsop@ietf.org From: Jeremy Rand Message-ID: Date: Fri, 3 Feb 2017 15:34:41 +0000 MIME-Version: 1.0 In-Reply-To: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oIVVcE56QUnAnKdESWA7GOtwujd1FO1aV" Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jeremy@veclabs.net List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 15:34:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oIVVcE56QUnAnKdESWA7GOtwujd1FO1aV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Suzanne Woolf: > This message opens a Working Group Last Call for: >=20 > "Special-Use Names Problem Statement" > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ > Proposed status: informational >=20 > Starts: 2 Feb. 2017 > Ends: 23 Feb. 2017 (3 weeks) >=20 > Discussion should go to the mailing list.=20 >=20 > Is this draft ready to advance for publication as an Informational RFC,= and as guidance for possible updates to RFC 6761? Does it describe the r= elevant issues clearly, and cover all the relevant ones that should be ta= ken into account in future work in the IETF on the special use names regi= stry or RFC 6761? >=20 > If not, can you suggest changes that would get your support for advanci= ng it? (=93Send text=94 if possible!) >=20 >=20 > thanks, > Suzanne & Tim Trivial spelling nit: Sec. 4.2.2 says "unilateral use by the TOR project". The correct spelling is "Tor" (only the "T" in "Tor" should be capitalized.) Also, according to https://www.torproject.org/docs/trademark-faq.html.en, "The Tor Project" is the correct spelling of the phrase (all 3 words should have the initial letter capitalized). Cheers, -Jeremy --oIVVcE56QUnAnKdESWA7GOtwujd1FO1aV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYlKL+AAoJELPy0WV4bWVw6sMQAMrBk9BPytKAyKwOD1mHHpQ3 MrOxNoUmj93IpV4tc1I1q/zJHfadG+TBNuRa0ZF6IYktEpbIzcrOfvTZmxvs9e0s ciRIV7af5r+EmCamCXylt7j/hFkMabZ+kcZWg2G/2KhQzVqzRRYTS2vaK2jIhEMk zRZ3CtK24/dOjQnQFyErMBITunChkmy7KUjghJ8GNwWMR/wjdcttYLI6rhZrDIDe 7zzgY+LBU+Ptz39NG6pbScFnU7biHrvIj9ZIRaxS/yx7SptrBfGTBpT3kbAXh3Xp Ai85lc9NhteR2FNUEXgxpnMVENATG5r/gR6TgqQ5zSWVMtap4rUJCwalRVEHMPN8 ZKtgaQpcVMqNCOpqFk/us0aNVrqY/qPFetu/YfnuF0XLwq6sWTkUeR4v6rO14U98 eC4/3j0OGvgR7fu7+VpNzEDFxFX9xyM80BeTfyTRUj8FDN19j69ei6L9cVi5r8Vf W2mfRtBvYCWlODIHSiSE0H0Fa0g9j0iuo/R1TVHWJVyjcFrD22Oih4qKabqKhB5G dOy3l9zi06PS1mANozuJhH6H49yFAXxVLT5npqGLCxoE2D19wJHtqSzQJiYi9n02 EBUYTcRzmZe388/0QCy2hNrdG0j0qW2862QKku193ggvvF7BGCLZNnglynSyCE1G Wvi3bjx2uMV/Ren7xeQN =m31w -----END PGP SIGNATURE----- --oIVVcE56QUnAnKdESWA7GOtwujd1FO1aV-- From nobody Fri Feb 3 07:40:31 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B862129BC9; Fri, 3 Feb 2017 07:40:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148613642634.4107.5655870150005796727.idtracker@ietfa.amsl.com> Date: Fri, 03 Feb 2017 07:40:26 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2017-02-16 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 15:40:26 -0000 The Domain Name System Operations (dnsop) Working Group will hold a virtual interim meeting on 2017-02-16 from 19:00 to 21:00 UTC. Agenda: Preliminary agenda: 1. Issues from WGLC on the problem statement (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/) 2. Proposals for moving forward: * reviews of alt-tld; ready for WGLC? will it help? (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/) * stop here? (leave RFC 6761 as-is, continue to process registry changes case-by-case) * proposals for process revision/update? 3. Next steps: * any drafts to write? * any input or liaison to request from the IAB? (regarding either namespace architecture or relationships of the IETF with other groups) 4. AOB: your I-D or proposed action for the WG/IESG/IAB here Information about remote participation: Webex details will follow From nobody Fri Feb 3 09:43:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038BD1294A6 for ; Fri, 3 Feb 2017 09:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqmO4JPzv-Hi for ; Fri, 3 Feb 2017 09:43:46 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 4723012948B for ; Fri, 3 Feb 2017 09:43:46 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id k15so45535467qtg.3 for ; Fri, 03 Feb 2017 09:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=f3GQrG0UZf0u34jp4s/vdnQo5i4sORO2rm1OGGu2//w=; b=SCpyeyQczPsmE06tE52RnWbD8PxJESMnnjNi8Haq9f513DxJrxMLKaw3lobwd+/AAy wkNuUKcFP+JzO5uiJzh3OLDwWJSEQcUgzynRbJ7KFceMdtUPuZv8sFALl1ZakYygA8p5 uplAVbxmxX09JwXBqsBBUPPhM3EUq9mS3+jzH4BCzfLOU5p5AsSMConUKQpIYYUKzjz7 DhH/TQcN9UNZ6F+554w7SmKgd2jSHXONJjLd1zPW+rAMjrYENFYoh6H1tT11hhD3oRLH +2lZyxNKWNB/nuCDJE3bRbm2eLernYAkssGSio730EHrfSaLt1MwyEf40biu7+4q1SNq i0EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=f3GQrG0UZf0u34jp4s/vdnQo5i4sORO2rm1OGGu2//w=; b=E1uxZ+jSfPMhQ7QRyKgNuEe2n1jPSvuJlZ0Tq/UijL+b3sAx37T7Ib4vcCxB76+Xwo xrvphb0WBCK3YnCIOzmwRscuzhjtU1RVtCvpcZsWYjYEb24gl8SY8cAbAdGT4wqw7k2q PUxaxKKLRf22HAqbYXceDx2F/2+wS6eO25VMH74PkkGfxWvQL5/nrrRWLDD3gVm4pe5I yJt4ptUoyTfFcwe5MPZBbc4Hf04VDBDt5PqyxgNICy5uPjf9xOsGOkXmh/wFQi4yQOE1 lE+Gv6Uh0eqtQCT/QOe3JrlzHuRaRzUjWukGx/E63XWTLdSAORWeuup6qxWtbzdp/ZuB K3EQ== X-Gm-Message-State: AIkVDXJV5EadUEp1UkiDPvRJL/M8laYRuL1WI9SrLDjAO1h3/HDGfnDi8aDCVfkSijBv3A== X-Received: by 10.200.41.91 with SMTP id z27mr14790100qtz.116.1486143824867; Fri, 03 Feb 2017 09:43:44 -0800 (PST) Received: from [10.0.0.19] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by smtp.gmail.com with ESMTPSA id q5sm24962962qtc.36.2017.02.03.09.43.44 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 09:43:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> Date: Fri, 3 Feb 2017 12:43:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <72C98AF7-61DA-4A04-ABA3-A939943A317A@gmail.com> References: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> To: dnsop X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:43:48 -0000 Hi, Some comments on the draft=E2=80=A6.no hats. I=E2=80=99ve started at the beginning and covered through the beginning = of Sec. 4; I=E2=80=99ll review the =E2=80=9Cexisting practices" material = separately. It looks severely critical because it=E2=80=99s long, but most of the = changes suggested are small, and I=E2=80=99ve tried hard to keep them in = a clear context. In general, I=E2=80=99m mostly suggesting the authors = tighten up the specifics and surface a few assumptions. I think it=E2=80=99s definitely pointed in the right direction. Thanks to the authors for their work. Suzanne =3D=3D=3D=3D=3D=3D draft-ietf-dnsop-sutld-ps-02 3 Feb 2017 Abstract 1. I think for purposes of this document, ICANN and SSAC are not = "standards organizations", just "organizations". I realize it's a = debatable point in casual use (is ICANN's documentation of its processes = for changing the root zone "standards"?) but I don=E2=80=99t think it = applies within the usual meaning of the term for the IETF and other = recognized SDOs. Introduction 2. I like that the name/resolution distinction is clearly called out = here. I=E2=80=99m not sure the names=3DDNS assumption has been entirely = banished throughout but it=E2=80=99s definitely heading in the right = direction. 3. STYLE/GRAMMAR: "....defined policies for adding to the registry, and = made some suggestions about how that policy might be implemented." This = should be "....defined a policy..." or "....about how those policies = might be implemented." 4. STYLE/GRAMMAR: This sentence is hard to parse: "In=20 support of the particular set of problems described here...." OLD: "In support of the particular set of problems described here, the document also includes documentation of existing practice as it relates to the use of Domain Names, as well as a brief history of Domain Names, and finally to describe the set of problems that exist as reported by various IETF participants with experience in the various aspects of the problem." NEW: "In support of its analysis of the particular set of issues described = here, the document also includes descriptions of existing practice as it = relates to the use of domain names, a brief history of domain names, and = some observations by various IETF participants who have experience with = various aspects of the current situation." Terminology 5. On defining "domain name," I think citing RFC 7719 and the = domain-names draft might be helpful. If it were less ambiguous in = practice this problem would be easier, but at least mentioning some = contexts where domain names are used or some of the constraints of what = can be in the strings might be helpful to readers who haven't already = seen the challenges in such a definition. 6. The terms are all defined relative to something we don't actually = have a term for, but might need one. If we're talking here about = "special use" names, what's a "normal" or "ordinary" or "expected" use, = and how is a "special use" different? You seem to be answering that = question but only by implication. Possibly add something like "The default or assumed use of a domain name = is initialization and resolution within the Domain Name System, which = includes a single global resolution scope and the Domain Name System = protocol (RFC 1034/1035). Such names are expected to be unique within = the global domain namespace. A name intended for use in the internet or = its defining protocols, following the construction rules for domain = names, but not global in scope or resolved by DNS wire protocol, could = be considered a 'special use' name." We don't have a formal, consensus definition anywhere, but RFC 7719 = takes a credible shot at a lot of what we need here, so you might mostly = be able to get away with citing it.=20 Problems associated with Special-Use Domain Names 7. STYLE/GRAMMAR: The two sentences beginning "Solutions to these = problems..." are hard to parse. This is partly because they're making a = subtle point, but: OLD: "Solutions to these problems are out of scope for this document. Because of that, problems with solutions to these problems are also out of scope for this document, and will be covered in a separate document." NEW: "Solutions to these problems, including their costs or tradeoffs, are = out of scope for this document. They will be covered in a separate document." 8. I think para. 2 (bottom of page 3) and para. 3 (top of page 4) are a = little confusing, even though I understand the rhetorical device of = using the word "problem" 12 times in half a page. I wanted to see how = you felt about that text before trying to rewrite it. 9. The text "There are several different types of names in the root of = the Domain Namespace" assumes the root is important-- that it's the = mathematical root of a tree-- without quite saying so. Citing RFC 7719, = sec. 2 is probably helpful here. 10. STYLE/GRAMMAR: "names that may not be applied for as a TLD" -> = "....applied for as TLDs" 11. STYLE/GRAMMAR: I wouldn't be surprised if the word "commandeer" made = some readers uncomfortable; it's got an implication of illegitimacy. 12. "assign names from the pool of unused names" is a little imprecise, = should probably specify slightly further: OLD: "Both ICANN and the IETF have the authority and formal processes to assign names from the pool of unused names..." NEW: "Both ICANN and the IETF have the authority and formal processes to make new assignments from the pool of unassigned domain names, and = expect names they add to be unique within the global namespace." 13. The "lack of coordination" is only a problem given the expectation = that names created under multiple set of processes will be unique within = a shared scope. This can be assumed in the definition of =E2=80=9Cdomain = name=E2=80=9D or it can be explicitly called out here, but the = uniqueness constraint has to be explicit somewhere, because without it = there=E2=80=99s (arguably) no problem. 14. You say: "The term "technical use" in RFC 2860 [RFC2860] is = considered by some to be too inclusive." Isn't the concern really that the term is ambiguous, so some people find = it too inclusive and some people find it too limited? For instance, = we've heard the view expressed that it wasn't intended to include names = defined for non-DNS resolution mechanisms, so something like .onion or = .local isn't covered; we've also seen it asserted that "technical use" = by the IETF includes the ability to force a change to the DNS root zone = by ICANN. (As a personal view, I don't support either extreme.) 15. You say "The IETF and ICANN each have administrative authority over = the Domain Namespace. Not all developers of protocols on the internet agree that this authority should reside with the IETF and ICANN." It almost makes more sense to me to say the IETF and ICANN each have an = ability to add names to the domain name space under conditions such that = people will use them, but there's no shared view of what that means in = terms of the shared global namespace. Specifically, there's no shared = view of how to avoid collisions such that the uniqueness constraint that = people expect of their domain names will be reliably honored. AFAIK the IETF has never claimed anyone would stop using a particular = string in a domain name slot just because the IETF told them not to. The = IETF can't tell people how to write their code, it just has a process = for defining what's interoperable so they can avoid problems with others = if they want to. 16. Same comments on the text "Although IETF and ICANN nominally have = authority over this namespace, neither organization can enforce that = authority over any third party who wants to just start using a subset of the = namespace." 17. More generally, on the last two comments, the use of the word = "authority" may need to be clarified here. It sounds obvious, but I = think if it really were obvious we wouldn't need to think about this = stuff quite so hard. If we assume RFC 2860 is not open for modification = (one of our ground rules from early on) and it's not the WG's job to = interpret it, we're left with the practical reality that ICANN has = operational authority over the DNS root zone under its community's = processes, the IETF has operational authority over the SUDN registry = under its processes (RFC 6761). 18. "Commandeer" again has some questionable connotations. Still not = sure of a better word, but the .onion RFC might provide one.=20 19. I'd add to the list of possible reasons for putting a name into use = without following any external process: "Names are expected to be = resolved only within the local scope for a protocol or network, or by = some non-DNS protocol, and designers don't realize or don't care that = modern systems and applications may nonetheless try to resolve domain = names with no context signaling in the global DNS." Handwaving about = authority aside, the real concern in these cases is interoperability; no = one would care if such names didn't tend to leak, but leaking is an = interoperability problem. 20. I don't like the text "These queries may constitute an operational = problem for operators of root zone authoritative name servers." They're = not. But the document is supposed to be a list of problems people have = identified without judgment as to their validity, so I won't object to = including it. :-) However, the possibility of inadvertent information = leakage (a privacy consideration) is also a real one to many people, and = perhaps that should be added. 21. The text "If there were no process for assigning names for technical = use through the IETF, there is a concern that protocols that require such names would not be able to get them." seems a little = incomplete to me. I would add something like "This view is usually justified by the = observation that the IETF has never asserted control or authority over = what protocols are 'allowed' on the internet, and that the principle of = 'permissionless innovation' suggests there should be a way for people to = include new uses of domain names in new protocols and applications." = After all, we don't ask people to prove their application is "good" = before we "let" them use TCP for it, even though we're the SDO for TCP. = (I'm not personally sure this is a good analogy, but I've heard it. = There are plenty of protocol parameter registries for which the policy = is "just ask" or FCFS or expert review, so I think this is really a = question about registry policy.) 22. You say "In cases where the IETF has made assignments through the = RFC 6761 process, technical mistakes have been made," but I admit I'm = having trouble identifying an example of an addition to the registry = that included such technical mistakes. This text almost sounds like it = meant "In cases where the IETF has *not* made assignments through the = RFC 6761 process...." 23. You say "In principle, the RFC 6761 process could be used to = document the existence of Domain Names that are not safe to assign..." = and go on to talk about draft-chapin. This para. mentions root servers = again, so my comment above (add the privacy consideration) applies here = too. 24. The next para, which begins "There are several Domain Name TLDs that = have been commandeered without due process for a variety of purposes = [SDO-ICANN-COLL]. The status of these names need to be clarified...." = puzzles me. Could you clarify why it's not redundant with the previous = case? You cite the same draft for both, but I think you're trying to = make different points ("unsafe to assign" vs. "commandeered"-- are they = the same thing? Has anyone brought up different risks associated with = them?) 25. The para that begins "No mechanism exists for adding a name to the = registry...." is talking about two different problems (IETF is = responsible, no precedence for assignment). It might be clearer if you = separate them. 26. There's also a third point that there's no precedence for = resolution, either; there's no mechanism in the registry for specifying = which protocol is expected for resolution, so no precedence between the = functional default (DNS) and others. SO for instance, the registry won't = tell people that the string ".onion" when it appears in their networks = in domain name contexts, is supposed to be resolved by an entirely = different protocol. This may be a problem with the registry structure = rather than its existence or its contents, and it may not be the only = one (early versions of draft-adpkja-dnsop-special-names-problem had some = discussion of the registry itself IIRC). 27. The text "No process exists for checking documents to make sure they = don't accidentally assign names (e.g. RFC 7788)." could be taken to = mean either that the IETF has no such process (and it's true, we don't) = or that no one else does either (which is also true). Within the IETF, = this breaks the standards process; on the wider scale, it risks = collision between the same string being assigned informally to multiple, = potentially colliding uses (the folks who wanted to use .home in = homenets, and the folks already using .home for something else), with no = certainty they won't collide and no rule for determining which use, if = either, is an error. 28. The text =E2=80=9CIt is generally assumed that protocols that need a = special-use name need a human-readable special-use name. This assumption = may not be warranted in all cases.=E2=80=9D doesn=E2=80=99t go far = enough. People assume both that they need a human-readable name, and = that they need a single label name (=E2=80=9CTLD=E2=80=9D). Both = assumptions, especially together, create a perception that there=E2=80=99s= a limited number of useful domain names in the world, with = corresponding tendencies to treat the underlying resource as scarce. = Domain names aren=E2=80=99t scarce; domain names that meet some of the = implicit assumptions people make about them might well be. From nobody Fri Feb 3 12:02:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F158129873 for ; Fri, 3 Feb 2017 12:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9OQaRuaAaw8 for ; Fri, 3 Feb 2017 12:02:48 -0800 (PST) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 BF3DB12951E for ; Fri, 3 Feb 2017 12:02:48 -0800 (PST) Received: by mail-it0-x244.google.com with SMTP id o185so2670543itb.1 for ; Fri, 03 Feb 2017 12:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=R502FTLFWEvGVHbK/dVcqpE3mu5OsPZVjAQ/qhJicKA=; b=urWDVj+Ps4aZjRKm5Ptge31XBKFacmIFk6QY3+tB24PD9TbyPK3SVBVwZwCVqt990G DSlnKOhFjzmXvC3vr1ExX80G48H+wYBD8Adxkf3j3e9XFWlsXpXpfXATZh2bSWof7OQZ Rhij+/cmRtEufQHhdmcV9j8FiUA13QhTg9SHS+V/JO7dEFNAH8Aumr2R5dT4wpNRiLog s9svCOvb4MfIbCe5GPfTfU9vSNKyqe+29EOb0RSeh8gfvkNinFPoQaaWbrWhhh0W7ryI 9xbsSpVZbMSxY2aX9QedVvQT8Japhb9XXrGPBHpV+RW+dHbT0ebNxtAp1qbirqczx4ji 5hGQ== 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=R502FTLFWEvGVHbK/dVcqpE3mu5OsPZVjAQ/qhJicKA=; b=mbrgnoI/Ik1gPlPdpnF/lcR/XnEICSR8ggoZSSaW5HUeSH5ciLM9+qmbw7LWdoSsRm pBsJiDzug3efMIvfXnforCjyFbvXHBK02FKVrxtnMSbGvUZqQ0TmqiAv8fCljoA7Ugz4 g0xBA7k4JMhoplZ8Ua4M/jB0mNUIG98Gxg3/vBUBIOye1EqRYTi/vTY3tFs8MGFJu3us p4+s/QQwWxyRi00bTqHLq85FCBPSolRulpCWjrtXnNHtnJTtVGu5AoPIMynNM2UZeSbb 2mmRpZC/YfRuVrLSwHFU+8Wtwt+M5Gxf2+dqiMaE63DXZmdZzhs4THRSRiiQkjgWay25 bvwg== X-Gm-Message-State: AIkVDXLWrqeGNYNW6ZJtlnGu5k2E9f8rrwwqi6dNrKklZSBj34G/KQk2jQXtQjleTUI24wwEx55/3HDquj6nBg== X-Received: by 10.36.164.75 with SMTP id v11mr2514197iti.101.1486152167960; Fri, 03 Feb 2017 12:02:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Fri, 3 Feb 2017 12:02:47 -0800 (PST) From: Brian Dickson Date: Fri, 3 Feb 2017 12:02:47 -0800 Message-ID: To: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary=f403045fbba80ddab20547a5c407 Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:02:50 -0000 --f403045fbba80ddab20547a5c407 Content-Type: text/plain; charset=UTF-8 Stephane wrote: > On Wed, Feb 01, 2017 at 03:28:29PM -0500, > Warren Kumari wrote > a message of 103 lines which said: > > > or 2: request that the IANA insert an insecure delegation in the > > root, pointing to a: AS112 or b: an empty zone on the root or c" > > something similar. > > Here, people may be interested by draft-bortzmeyer-dname-root (expired > but could be revived). The main objection was the privacy issue > (sending user queries to the "random" operators of AS112.) > > My opinion on these issues are as follows, roughly: - I am in favor of AS112 for ALT - For AS112, I prefer the AS112++ method (DNAME) - I do not see why the DNAME would/should not be DNSSEC signed - Any local use of ALT can be served locally and signed using an alternative trust anchor - I don't think there is any issue with having both the NXD from the root, and the local assertion of existence, both present (in cache and in authoritative data respectively) - Maybe there are issues with specific implementations? - If anyone knows of such problems, it would be helpful to identify them along with the implementation and version - For AS112 privacy, perhaps someone should write up a recommendation to set up local AS112 instances, to provide privacy, as an informational RFC? - Even simply through resolver configurations, without a full AS112 "announce routes"? - Do any resolver packages offer such a simple AS112 set-up? - Maybe the efforts for privacy should start there (implement first, then document)? - Do any stub resolver packages include host-local AS112 features/configurations? Overall, I'm obviously in favor of use of ALT, and for signing whatever is done for ALT, and for use of DNAME for ALT. Brian "DNAME" Dickson --f403045fbba80ddab20547a5c407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephane wrote:=C2=A0
On Wed, Feb 01, 201=
7 at 03:28:29PM -0500,
 Warren Kumari <warren at kumari.net&g=
t; wrote=20
 a message of 103 lines which said:

> or 2: request that the IANA insert an insecure delegation in the
> root, pointing to a: AS112 or b: an empty zone on the root or c"
> something similar.

Here, people may be interested by draft-bortzmeyer-dname-root (expired
but could be revived). The main objection was the privacy issue
(sending user queries to the "random" operators of AS112.)
<= /blockquote>

My opinion on these issues are as follows, = roughly:
  • I am in favor of AS112 for ALT
  • For AS112= , I prefer the AS112++ method (DNAME)
  • I do not see why the DNAM= E would/should not be DNSSEC signed
  • Any local use of ALT can be= served locally and signed using an alternative trust anchor
      • I don't think there is any issue with having both the NXD from the ro= ot, and the local assertion of existence, both present (in cache and in aut= horitative data respectively)
    • Maybe there are issues with specific = implementations?=C2=A0
    • If anyone knows of such problems, it would b= e helpful to identify them along with the implementation and version
    • For AS112 privacy, perhaps someone should write up a recommendation = to set up local AS112 instances, to provide privacy, as an informational RF= C?
      • Even simply through resolver configurations, without a full = AS112 "announce routes"?
      • Do any resolver packages offer s= uch a simple AS112 set-up?
      • Maybe the efforts for privacy should sta= rt there (implement first, then document)?
      • Do any stub resolver pac= kages include host-local AS112 features/configurations?
    = Overall, I'm obviously in favor of use of ALT, and for signing whatever= is done for ALT, and for use of DNAME for ALT.

<= div>Brian "DNAME" Dickson
--f403045fbba80ddab20547a5c407-- From steve.crocker@gmail.com Fri Feb 3 12:06:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A92129671 for ; Fri, 3 Feb 2017 12:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 c62kxoSU2e-W for ; Fri, 3 Feb 2017 12:06:07 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 B35D712950E for ; Fri, 3 Feb 2017 12:06:07 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id v184so2764696pgv.1 for ; Fri, 03 Feb 2017 12:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Ntnp/XEhInunFMhf7iHLlTagQ7FOqXQ/F4AVnCYaLCI=; b=rEEXcY0ja7prN92S0Tcurd3cCA80FvzPYU3yRkM4pWYuwFD93BtUqx/XDbh3vgkWU+ pzcM0bxhc//lLX2RtR8xC//6aHzY9/aTx+X85xKSlsV+IvoojSI9zNNGp44K+6XdatdK 9bPAA2jRTZI1r6nH5TI7ui1pI78QG+WlZVcILL744F/wpv6WDMI4pNJcP8nLHUGYoDAU fHTd8p5BCKdAyoh7c+lkD8VzsJy8hkVewndXjIr4575BgRGxeHHQQNY8O6TyYymj5ACQ J9DtGANMCEGOmrQMeW7Txt6RRtoULAbVZQoIJQVxqRzbaWSSYMe3RXsiSup+il7Hzlbg xmRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ntnp/XEhInunFMhf7iHLlTagQ7FOqXQ/F4AVnCYaLCI=; b=tU8azH0zr0T2u0wN70b3seOxzHvTAqN/J3nzsRQuZbhb4UHhQs0bjRdlUkyK+QwRew Mh3ajm55Ks/WBFLSqmG1QJEed6GHHlnYQ0GM9MkVRsAelHSgQp9mraS1s8/yV5NzyHz0 RuIGGwKTu961LKcwN9GKwc7aXNw2CIIjGnY5+HCZHA+oDv7b4gmIeDpHmTZEYhY8a02v JqBw/HYuAugjzs5v8GTQK5DdFyMLbJuRLwMtzRedP8R7miY5iyplCPbO9EfRnik/5zx1 7TScc/51XcFwAk2XYDB0etHXBb5AbO5PPWnxGzRBp8U0CWFBxY9Z27yXwMBrCz6LpwWF o5BQ== X-Gm-Message-State: AIkVDXLMwXc5SucKLpnTBeSIKl6lTm7gI2znYKSJze4J1ysl0xN60K3XGgL9kzmI/gYpvg== X-Received: by 10.99.67.6 with SMTP id q6mr20008710pga.156.1486152367320; Fri, 03 Feb 2017 12:06:07 -0800 (PST) Received: from [172.16.144.233] ([69.31.123.67]) by smtp.gmail.com with ESMTPSA id d29sm69168236pfk.83.2017.02.03.12.06.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 12:06:06 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_76556992-E66F-4597-8088-5A9042B305D0" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Steve Crocker In-Reply-To: Date: Fri, 3 Feb 2017 12:06:05 -0800 Message-Id: <5FD13D0D-57DE-4CED-B1A2-C823079B8D63@gmail.com> References: To: Brian Dickson X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Fri, 03 Feb 2017 12:09:10 -0800 Cc: Steve Crocker , "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:07:49 -0000 --Apple-Mail=_76556992-E66F-4597-8088-5A9042B305D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Are you also expecting ALT will never be delegated in the root? If it = were to be delegated in the root, what impact would that have on the = uses you have in mind? Steve Crocker [I am having trouble sending from steve@shinkuro.com, but I am receiving = mail without trouble. Please continue to send mail to me at = steve@shinkuro.com] > On Feb 3, 2017, at 12:02 PM, Brian Dickson = > = wrote: >=20 > Stephane wrote:=20 > On Wed, Feb 01, 2017 at 03:28:29PM -0500, > Warren Kumari > wrote=20 > a message of 103 lines which said: >=20 > > or 2: request that the IANA insert an insecure delegation in the > > root, pointing to a: AS112 or b: an empty zone on the root or c" > > something similar. >=20 > Here, people may be interested by draft-bortzmeyer-dname-root (expired > but could be revived). The main objection was the privacy issue > (sending user queries to the "random" operators of AS112.) >=20 > My opinion on these issues are as follows, roughly: > I am in favor of AS112 for ALT > For AS112, I prefer the AS112++ method (DNAME) > I do not see why the DNAME would/should not be DNSSEC signed > Any local use of ALT can be served locally and signed using an = alternative trust anchor > I don't think there is any issue with having both the NXD from the = root, and the local assertion of existence, both present (in cache and = in authoritative data respectively) > Maybe there are issues with specific implementations?=20 > If anyone knows of such problems, it would be helpful to identify them = along with the implementation and version > For AS112 privacy, perhaps someone should write up a recommendation to = set up local AS112 instances, to provide privacy, as an informational = RFC? > Even simply through resolver configurations, without a full AS112 = "announce routes"? > Do any resolver packages offer such a simple AS112 set-up? > Maybe the efforts for privacy should start there (implement first, = then document)? > Do any stub resolver packages include host-local AS112 = features/configurations? > Overall, I'm obviously in favor of use of ALT, and for signing = whatever is done for ALT, and for use of DNAME for ALT. >=20 > Brian "DNAME" Dickson > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_76556992-E66F-4597-8088-5A9042B305D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Are you also expecting ALT will never be delegated in the = root?  If it were to be delegated in the root, what impact would = that have on the uses you have in mind?

Steve = Crocker
[I am having trouble sending from steve@shinkuro.com, = but I am receiving mail without trouble.  Please continue to send = mail to me at steve@shinkuro.com]


On Feb = 3, 2017, at 12:02 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:

Stephane wrote: 
On =
Wed, Feb 01, 2017 at 03:28:29PM -0500,
 Warren Kumari <warren at kumari.net> wrote=20
 a message of 103 lines which said:

> or 2: request that the IANA insert an insecure delegation in the
> root, pointing to a: AS112 or b: an empty zone on the root or c"
> something similar.

Here, people may be interested by draft-bortzmeyer-dname-root (expired
but could be revived). The main objection was the privacy issue
(sending user queries to the "random" operators of =
AS112.)

My opinion on these issues are as follows, roughly:
  • I am in favor of AS112 for = ALT
  • For AS112, I prefer the AS112++ method (DNAME)
  • I do not see why the DNAME would/should = not be DNSSEC signed
  • Any local use of = ALT can be served locally and signed using an alternative trust = anchor
    • I don't think = there is any issue with having both the NXD from the root, and the local = assertion of existence, both present (in cache and in authoritative data = respectively)
    • Maybe there are issues with specific = implementations? 
    • If anyone knows of such = problems, it would be helpful to identify them along with the = implementation and version
  • For AS112 privacy, = perhaps someone should write up a recommendation to set up local AS112 = instances, to provide privacy, as an informational RFC?
    • Even simply through resolver configurations, = without a full AS112 "announce routes"?
    • Do any = resolver packages offer such a simple AS112 set-up?
    • Maybe the efforts for privacy should start there (implement = first, then document)?
    • Do any stub resolver packages = include host-local AS112 features/configurations?
Overall, I'm obviously in favor of use of ALT, and for = signing whatever is done for ALT, and for use of DNAME for = ALT.

Brian= "DNAME" Dickson
_______________________________________________
DNSOP = mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop




= --Apple-Mail=_76556992-E66F-4597-8088-5A9042B305D0-- From nobody Fri Feb 3 12:12:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF36912989E for ; Fri, 3 Feb 2017 12:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moZ-BgYerHjX for ; Fri, 3 Feb 2017 12:12:07 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B7812988F for ; Fri, 3 Feb 2017 12:12:07 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id v23so51772987qtb.0 for ; Fri, 03 Feb 2017 12:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+R/Xs0skX5fDrxCkEY52wPoe5O0jnXE5aDuJvyoPERo=; b=iNsZUziOehXrCffo38r54kcn8T966L3SVfH/RYTV2rxUXY3w6g5r7o6MUJx4wVJD/X bEno0AsnjXCcE46NNIQeyLcuEcx1wonp1ksRNLKvNUTfeNWVCNetixiInFkOnL/youKy L1/A53PXNyJsZu19+0Ye2hK0pjh4wnbluYz4mZliULnxOfGSutBlpZuCTSEuLkX5GsV9 lu6UktDS6ivMfjtZ14kwfMG+xBl1aY0tuA0uqs+viBi9lfKwmdVwPwHW8OkHDzw0sx+v hnq1P8uYiAQGNPLQcH+bAQ9EJ9AnfwrEZoIznP0gJXG0B7CwGxkgVm093CdHznNIgKNM U34g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+R/Xs0skX5fDrxCkEY52wPoe5O0jnXE5aDuJvyoPERo=; b=uDE4utmUE0eDQET6TracjAiYkJnYXrvttwi9VuQWqC3+GOmd7vrq5JRZxHXOzRXDI+ POqdh615XtVuJ+B/9XCtg+72dCeTjMf0B1l/mKg9rlbazK3U4owVbdYMdgMPe12cU66k uQIPsPgNZLu+QiFEokrmVe0yEmYMeeRfGj5rpXlw46xZIARiI9vizmzk+VkVOHjWYwHf PMjr2GU0qQlukcUtxdfndHmu491axFjDJ1rzlWOkTwagvJb792a7KzTOiEC0bSFlGluP WLhKKfs+8sc/BNMLFCQNqlQRc1b+v1weNpsNw6crIYpoKV2l/3WSaWwaoZVbfraYuZ6J nX0A== X-Gm-Message-State: AIkVDXIZuXybCEjZUIiSC4E7oFkRQhhD84/ob1/4xwTTE9+5htyGiFtGYInDXKT81JlBFg== X-Received: by 10.200.57.199 with SMTP id v65mr14901495qte.13.1486152726078; Fri, 03 Feb 2017 12:12:06 -0800 (PST) Received: from [10.0.0.19] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by smtp.gmail.com with ESMTPSA id r24sm25278211qkl.5.2017.02.03.12.12.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 12:12:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <20170201205656.CB3356115F8E@rock.dv.isc.org> Date: Fri, 3 Feb 2017 15:12:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170201205656.CB3356115F8E@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:12:09 -0000 > On Feb 1, 2017, at 3:56 PM, Mark Andrews wrote: >=20 >=20 > In message = , = Warren K > umari writes: >>=20 >> This is a fine thing to request in an IANA consideratons, but isn't >> necessarily *useful* -- the IANA has the technical ability to add >> stuff to the root zone, but not the mandate (this is like walking = into >> a bank and requesting the teller gives you a bunch of money - they = may >> be able to do so, but aren't actually allowed to.. :-)). >=20 > Actually it isn't the same. >=20 > Implicit in the agreement that the IETF can get names in the root > namespace is the ability to use them. Some uses require that there > be a entry in the root zone. >=20 > It doesn't say that the IETF can "RESERVE" a name. The IETF gets > the name. Can you please cite a source for this belief, so that it can be added to = the =E2=80=9Crelevant documents=E2=80=9D discussion in the problem = statement draft? It seems to me that your interpretation of the situation has never been = discussed, and there=E2=80=99s considerable reason to believe it = wouldn=E2=80=99t have consensus support across the affected groups = (Warren provided an overview of some of the reasons in his original = post), but of course I may be overlooking something. thanks, Suzanne From nobody Fri Feb 3 12:18:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B2E1298B9 for ; Fri, 3 Feb 2017 12:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c3o65WcqEM4 for ; Fri, 3 Feb 2017 12:18:32 -0800 (PST) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 ED89A129456 for ; Fri, 3 Feb 2017 12:18:31 -0800 (PST) Received: by mail-it0-x242.google.com with SMTP id e137so2706858itc.0 for ; Fri, 03 Feb 2017 12:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gORdDh1JRRKw48GIMjpV6E2NnzDvkmsTnRNWJJIUw5Q=; b=BN0ua7rjUVJKhVdgANyYr4MbK+SqxklwdqCXhPsUXKLrA0wNdKFRZ58bPyJvs5OXP3 dK1DzVqUPgMtY5vuO59zLGq9UCohx09bzA5w2Q9sgyDXwmlmfVRbXUjLf61Sq2WxA2+l V+Fp3t53B6oUfdYTzbXEafvsig5jlVBeEBHZ0s8Ie7MnVk0/IXG87C0DQIdCYncWGy6U 1oAMNCPckNfYUVjFcL0WNRM91b/yByhJq8sutHmQkY4l1OsfhofGVw/g5btwbkxDVnd9 6bJSzstPLKKSzedaTXbRf/qlqEFHatl/G2RSXJbPuM7DDQhhcnQmKjjnxF2GclNBerQi /msQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gORdDh1JRRKw48GIMjpV6E2NnzDvkmsTnRNWJJIUw5Q=; b=YraaWlP8Oy4KDse5MGQLlozPGYe3xfLGDrn8s2ZFkXF5dKdzyZmLWP8LXoBBr4pQPj b57c2fKA26KV+FkMOzlPoexP8q15sgUIAxkCUnr26EcBmKqC7G7EKfPjvh25FMeGJ05k tnvj0BqLqV5ScpkbFjyDVqVhRlQn7SGE+2aUNk67cQw2Xg1LDFk6E7kR0Cqoqo+wmZhZ EogGT78j+CGF1t+TApI2GFF/+LN9n4/3NQ0rlU/W0XKeN+uw1Pi+EPm2PFQlgSpfMVke bqR3wZE5Dn9+93wDYxnd1faquhQlwTos0cq1hSdigRICeNJNUGnZp4AUVYHw6FJUXw43 wW6A== X-Gm-Message-State: AIkVDXIx/aRbEl26j48SiiBctDigBGCPZ7rhYSNJMHF612E56zNTQ4MiHsF12vez4W1+MmcRAzKNffTbyT3oXA== X-Received: by 10.36.164.75 with SMTP id v11mr2575292iti.101.1486153111106; Fri, 03 Feb 2017 12:18:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Fri, 3 Feb 2017 12:18:30 -0800 (PST) In-Reply-To: <5FD13D0D-57DE-4CED-B1A2-C823079B8D63@gmail.com> References: <5FD13D0D-57DE-4CED-B1A2-C823079B8D63@gmail.com> From: Brian Dickson Date: Fri, 3 Feb 2017 12:18:30 -0800 Message-ID: To: Steve Crocker Content-Type: multipart/alternative; boundary=f403045fbba84522c10547a5fcda Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:18:34 -0000 --f403045fbba84522c10547a5fcda Content-Type: text/plain; charset=UTF-8 The DNAME has an effect similar to delegation, except that in the case of the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 ) , the target is a well-known & published empty zone (as112.arpa.) (Delegation and DNAME cannot coexist for the same owner name - that is one of the edicts for DNAME, similar to CNAME.) Any local configuration of something.alt (as an authoritatively served zone) would be matched before checking the cache or attempting recursive resolution, per 103[345]. I don't have any desire or intention of local something.alt, I'm just pointing out that the existence of a signed NXD result (via DNAME to an empty zone) doesn't break such a set-up. The reason for DNAME instead of delegation, is that it avoids the operators of AS112 instances from having to configure the new zone(s) whenever a new "delegation" occurs. If, instead, a delegation were done, the specific zone (.alt) would need to be configured and served somewhere. RFC7535 is designed to avoid the need for coordination in configuring such zones. (RFC7535 also allows authorities for other places in the DNS tree to make use of AS112, but that is a non-sequitur.) Brian On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker wrote: > Are you also expecting ALT will never be delegated in the root? If it > were to be delegated in the root, what impact would that have on the uses > you have in mind? > > Steve Crocker > [I am having trouble sending from steve@shinkuro.com, but I am receiving > mail without trouble. Please continue to send mail to me at > steve@shinkuro.com] > > > On Feb 3, 2017, at 12:02 PM, Brian Dickson > wrote: > > Stephane wrote: > >> On Wed, Feb 01, 2017 at 03:28:29PM -0500, >> Warren Kumari wrote >> a message of 103 lines which said: >> >> > or 2: request that the IANA insert an insecure delegation in the >> > root, pointing to a: AS112 or b: an empty zone on the root or c" >> > something similar. >> >> Here, people may be interested by draft-bortzmeyer-dname-root (expired >> but could be revived). The main objection was the privacy issue >> (sending user queries to the "random" operators of AS112.) >> >> > My opinion on these issues are as follows, roughly: > > - I am in favor of AS112 for ALT > - For AS112, I prefer the AS112++ method (DNAME) > - I do not see why the DNAME would/should not be DNSSEC signed > - Any local use of ALT can be served locally and signed using an > alternative trust anchor > - I don't think there is any issue with having both the NXD from the > root, and the local assertion of existence, both present (in cache and in > authoritative data respectively) > - Maybe there are issues with specific implementations? > - If anyone knows of such problems, it would be helpful to identify > them along with the implementation and version > - For AS112 privacy, perhaps someone should write up a recommendation > to set up local AS112 instances, to provide privacy, as an informational > RFC? > - Even simply through resolver configurations, without a full AS112 > "announce routes"? > - Do any resolver packages offer such a simple AS112 set-up? > - Maybe the efforts for privacy should start there (implement > first, then document)? > - Do any stub resolver packages include host-local AS112 > features/configurations? > > Overall, I'm obviously in favor of use of ALT, and for signing whatever is > done for ALT, and for use of DNAME for ALT. > > Brian "DNAME" Dickson > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > --f403045fbba84522c10547a5fcda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The DNAME has an effect similar to delegation, except= that in the case of the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 ) , the target is a wel= l-known & published empty zone (as112.arpa.)

(= Delegation and DNAME cannot coexist for the same owner name - that is one o= f the edicts for DNAME, similar to CNAME.)

Any loc= al configuration of something.alt (as an authoritatively served zone) would= be matched before checking the cache or attempting recursive resolution, p= er 103[345].

I don't have any desire or intent= ion of local something.alt, I'm just pointing out that the existence of= a signed NXD result (via DNAME to an empty zone) doesn't break such a = set-up.



The reason f= or DNAME instead of delegation, is that it avoids the operators of AS112 in= stances from having to configure the new zone(s) whenever a new "deleg= ation" occurs.

If, instead, a delegation were= done, the specific zone (.alt) would need to be configured and served some= where.

RFC7535 is designed to avoid the need for c= oordination in configuring such zones.

(RFC7535 al= so allows authorities for other places in the DNS tree to make use of AS112= , but that is a non-sequitur.)

Brian

On Fri, Feb 3, 2017= at 12:06 PM, Steve Crocker <steve.crocker@gmail.com> = wrote:
Are you also expecting ALT will never be delegated in the root?=C2=A0 If = it were to be delegated in the root, what impact would that have on the use= s you have in mind?

Steve Crocker
[I= am having trouble sending from steve@shinkuro.com, but I am receiving mail without troubl= e.=C2=A0 Please continue to send mail to me at steve@shinkuro.com]


On Feb 3, 2017, at 12:02 PM, Brian Dickson <brian.peter.dickson@gmail.com<= wbr>> wrote:

Stepha= ne wrote:=C2=A0
On Wed, Feb 01, 2017 at 03:28:29PM -0500, Warren Kumari <warren at kumari.net> wrote=20 a message of 103 lines which said: > or 2: request that the IANA insert an insecure delegation in the > root, pointing to a: AS112 or b: an empty zone on the root or c" > something similar. Here, people may be interested by draft-bortzmeyer-dname-root (expired but could be revived). The main objection was the privacy issue (sending user queries to the "random" operators of AS112.)<= /blockquote>

My opinion on these issues are as follows, = roughly:
  • I am in favor of AS112 for ALT
  • For AS112= , I prefer the AS112++ method (DNAME)
  • I do not see why the DNAM= E would/should not be DNSSEC signed
  • Any local use of ALT can be= served locally and signed using an alternative trust anchor
      • I don't think there is any issue with having both the NXD from the ro= ot, and the local assertion of existence, both present (in cache and in aut= horitative data respectively)
    • Maybe there are issues with specific = implementations?=C2=A0
    • If anyone knows of such problems, it would b= e helpful to identify them along with the implementation and version
    • For AS112 privacy, perhaps someone should write up a recommendation = to set up local AS112 instances, to provide privacy, as an informational RF= C?
      • Even simply through resolver configurations, without a full = AS112 "announce routes"?
      • Do any resolver packages offer s= uch a simple AS112 set-up?
      • Maybe the efforts for privacy should sta= rt there (implement first, then document)?
      • Do any stub resolver pac= kages include host-local AS112 features/configurations?
    = Overall, I'm obviously in favor of use of ALT, and for signing whatever= is done for ALT, and for use of DNAME for ALT.

<= div>Brian "DNAME" Dickson
_______________________________________________
DNSOP mailing list<= br>DNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop





--f403045fbba84522c10547a5fcda-- From nobody Fri Feb 3 12:19:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECDD1298BB for ; Fri, 3 Feb 2017 12:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 F8hkIo01EO4g for ; Fri, 3 Feb 2017 12:19:28 -0800 (PST) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (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 BD6B81298BA for ; Fri, 3 Feb 2017 12:19:28 -0800 (PST) Received: by mail-yw0-x242.google.com with SMTP id u68so2700386ywg.0 for ; Fri, 03 Feb 2017 12:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tL5J5GaWTiJxFilLEwGJoeXYniMtyvqeNtAiVwwz3LE=; b=aR+bKH8q0cOC6WYCecIMqilB/wveu4pGjD3Hfli/+SkJfNm5TIGEQY0r75znD0pSia 0VeyFePxG/xPyyV5glaVNCYuZtYychjjXwPVchmcJu0Iq4DsZDbrfwopq5pQJEQflzn7 kkXhrPFvb2aYBLpQ+jGvNEW2YkcUxLEazYRpJW7oHGI+qo5YS+8RYaP3AEaXdG2Sjv8L 7ECPYtCbgB9RhPVfa3Mec1RaWpE1kumuZVDE5skQx814lzYWMLwBrwzE1W2b5ukoDTPu xr2IY/gAEDZKOcENcB8nTEcEIlSLJOysg/bhUeXNKx2sa4TOA+l2cpOi1GEDe/9pFXqs wIJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tL5J5GaWTiJxFilLEwGJoeXYniMtyvqeNtAiVwwz3LE=; b=RpjPvkMOwBAji6XIj+LRVWldgOPVoYjDVJ06h0aACOAFU3CGv3DpDBoqajbBg/q6Po kBMShB5CATE/JxmW9Z7rGgGIy3EqMI2amJP17nXYJj88NXmTaVyFrnJpeUzh68H63TcB EhTfE0crGobIA4pyl2JGJQLaSiw9YNvjIw/OcAJbnYkM3lDcDWMO8bJAJkP4kZktAkOb bRfYvYwRKgwB7kvPm+uhGnwWJXiSm7INo/rpvNAnoEIEnkhJ4BMoPlcvSQMZCJGWOGOb VDJ0bNcPTb+BDRq++ZpaA5rR2nvxdSj3PGLq89QEfDEKZrjaFiN915TQ39YNRSgRVv5J I2hQ== X-Gm-Message-State: AIkVDXJlrY6GlV8fRHMA4OqjdbObxjTg9fFg4ddPVarSDHsgg/x4S/lWZtgMI5QXtGs4TjUV67lxh5IXKUi0OZmy X-Received: by 10.129.81.12 with SMTP id f12mr10811806ywb.80.1486153167832; Fri, 03 Feb 2017 12:19:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.237.68 with HTTP; Fri, 3 Feb 2017 12:19:27 -0800 (PST) In-Reply-To: References: From: Bob Harold Date: Fri, 3 Feb 2017 15:19:27 -0500 Message-ID: To: Brian Dickson Content-Type: multipart/alternative; boundary=001a11463018a6d14f0547a5ff9f Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:19:31 -0000 --001a11463018a6d14f0547a5ff9f Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 3:02 PM, Brian Dickson wrote: > Stephane wrote: > >> On Wed, Feb 01, 2017 at 03:28:29PM -0500, >> Warren Kumari wrote >> a message of 103 lines which said: >> >> > or 2: request that the IANA insert an insecure delegation in the >> > root, pointing to a: AS112 or b: an empty zone on the root or c" >> > something similar. >> >> Here, people may be interested by draft-bortzmeyer-dname-root (expired >> but could be revived). The main objection was the privacy issue >> (sending user queries to the "random" operators of AS112.) >> >> > My opinion on these issues are as follows, roughly: > > - I am in favor of AS112 for ALT > - For AS112, I prefer the AS112++ method (DNAME) > - I do not see why the DNAME would/should not be DNSSEC signed > - Any local use of ALT can be served locally and signed using an > alternative trust anchor > - I don't think there is any issue with having both the NXD from the > root, and the local assertion of existence, both present (in cache and in > authoritative data respectively) > - Maybe there are issues with specific implementations? > - If anyone knows of such problems, it would be helpful to identify > them along with the implementation and version > - For AS112 privacy, perhaps someone should write up a recommendation > to set up local AS112 instances, to provide privacy, as an informational > RFC? > - Even simply through resolver configurations, without a full AS112 > "announce routes"? > - Do any resolver packages offer such a simple AS112 set-up? > - Maybe the efforts for privacy should start there (implement > first, then document)? > - Do any stub resolver packages include host-local AS112 > features/configurations? > > Overall, I'm obviously in favor of use of ALT, and for signing whatever is > done for ALT, and for use of DNAME for ALT. > > Brian "DNAME" Dickson > > I would prefer an UNsigned delegation. If someone wants a signed zone, they can add a trust anchor, I assume. But if they want an unsigned zone there needs to be a way to get that. -- Bob Harold --001a11463018a6d14f0547a5ff9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 3, 2017 at 3:02 PM, Brian Dickson <= ;brian.p= eter.dickson@gmail.com> wrote:
Stephane wrote:=C2=A0
On Wed, Feb 01,=
 2017 at 03:28:29PM -0500,
 Warren Kumari <warren at kumari.net> wrote=20
 a message of 103 lines which said:

> or 2: request that the IANA insert an insecure delegation in the
> root, pointing to a: AS112 or b: an empty zone on the root or c"
> something similar.

Here, people may be interested by draft-bortzmeyer-dname-root (expired
but could be revived). The main objection was the privacy issue
(sending user queries to the "random" operators of AS112.)
<= /blockquote>

My opinion on these issues are as follows, = roughly:
  • I am in favor of AS112 for ALT
  • For AS112= , I prefer the AS112++ method (DNAME)
  • I do not see why the DNAM= E would/should not be DNSSEC signed
  • Any local use of ALT can be= served locally and signed using an alternative trust anchor
      • I don't think there is any issue with having both the NXD from the ro= ot, and the local assertion of existence, both present (in cache and in aut= horitative data respectively)
    • Maybe there are issues with specific = implementations?=C2=A0
    • If anyone knows of such problems, it would b= e helpful to identify them along with the implementation and version
    • For AS112 privacy, perhaps someone should write up a recommendation = to set up local AS112 instances, to provide privacy, as an informational RF= C?
      • Even simply through resolver configurations, without a full = AS112 "announce routes"?
      • Do any resolver packages offer s= uch a simple AS112 set-up?
      • Maybe the efforts for privacy should sta= rt there (implement first, then document)?
      • Do any stub resolver pac= kages include host-local AS112 features/configurations?
    = Overall, I'm obviously in favor of use of ALT, and for signing whatever= is done for ALT, and for use of DNAME for ALT.

<= div>Brian "DNAME" Dickson


I would prefer an UNsigned delegation.= =C2=A0 If someone wants a signed zone, they can add a trust anchor, I assum= e.=C2=A0 But if they want an unsigned zone there needs to be a way to get t= hat.

--=C2=A0
Bob Harold
=C2= =A0
--001a11463018a6d14f0547a5ff9f-- From nobody Fri Feb 3 12:26:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8256F1295D9 for ; Fri, 3 Feb 2017 12:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 il83kbrCFCEW for ; Fri, 3 Feb 2017 12:21:18 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 BBDA7129560 for ; Fri, 3 Feb 2017 12:21:18 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id e4so2214563pfg.0 for ; Fri, 03 Feb 2017 12:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=KkNJk10FMDpQOj/5fQGxsWczoAWwnq0o0gY3ISH6q0I=; b=shDCNVTemwwEy/hG7Z8adVMUHmmdrRc/DZQJ6GovgXcjbmShqYwL6Vxi2PGj8/blR1 cKRzk6eRJ5aSAXrW7YNG2tNbz822TCtgfxfXmTWgbrPfQX4bXVE7CrfVI78UmCm5pLXU 72RV8U48euf28FGFYf4zp/mFF26vjw5Wgq8Vr8dXxnfPuVwY02tsDJkeM7UhEEoiuS6D kvbZHH5D++ccGmvNQd4UunLiAXnLrr3gBgtxalGvFf2hf3Y0r7hun+2q/ApuEbfvQBhQ KOCF6l6HYMVzCW0toi34s9Zd8F33x6pUgH2gpx3H8fSBmtsyNl6IWL7j2qMyBGBQDE9z vrHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KkNJk10FMDpQOj/5fQGxsWczoAWwnq0o0gY3ISH6q0I=; b=ZtBi2yU2VP3kXNRMcDQor7U5Len6c0zuaO47Oe35BwUBZyHb1dYoixCBBGClm8c/9y g4psMc7dVGQbidNhR6nK6Y7OkXVqckHboBhKUt/7YFz4BEJINXLrHDthcMnFkoBUUVdM 2+9to0EE3JNTld87DzhpYYRsWuYZA9WpxDOa5Lbs5HHQNNsU+Jg+QbDphPBvnKPs7GUR sH2dDWutl07R66uHVfiqtIQs7/D+1xNXKVxlkSM7z2XOP5HQK9+Fq6bqy3sWFYCRvhoa hFXYkHmM5oIv/uW9HQpLZut1G/yOw6VvyZ4AbQadaN+VRZCw4BsALiLpwthquvcCWDYD gzhw== X-Gm-Message-State: AIkVDXJA8j4aIMFq4GmMH/3oPLYA/lfFD+CCtEF6UsLulw2WK5en8jsLjrcXnMXYogPh8Q== X-Received: by 10.99.167.74 with SMTP id w10mr20737144pgo.2.1486153278292; Fri, 03 Feb 2017 12:21:18 -0800 (PST) Received: from [172.16.144.233] ([69.31.123.67]) by smtp.gmail.com with ESMTPSA id b67sm69151131pfj.81.2017.02.03.12.21.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 12:21:17 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1EEEEC2D-AF0A-4971-BFAC-4EB2D2C4B355" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Steve Crocker In-Reply-To: Date: Fri, 3 Feb 2017 12:21:16 -0800 Message-Id: <74796240-46DA-4C8B-A715-DBC521EFA3F3@gmail.com> References: <5FD13D0D-57DE-4CED-B1A2-C823079B8D63@gmail.com> To: Brian Dickson X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Fri, 03 Feb 2017 12:26:56 -0800 Cc: Steve Crocker , "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:21:20 -0000 --Apple-Mail=_1EEEEC2D-AF0A-4971-BFAC-4EB2D2C4B355 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii And just to stir the pot a bit, what would you have ICANN do if someone = applies for .alt as a top level domain? Is it ok if we say yes and = delegate the name? If not, what is the basis for us to say no? Steve Crocker [I am having trouble sending from steve@shinkuro.com, but I am receiving = mail without trouble. Please continue to send mail to me at = steve@shinkuro.com] > On Feb 3, 2017, at 12:18 PM, Brian Dickson = wrote: >=20 > The DNAME has an effect similar to delegation, except that in the case = of the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 = ) , the target is a well-known & = published empty zone (as112.arpa.) >=20 > (Delegation and DNAME cannot coexist for the same owner name - that is = one of the edicts for DNAME, similar to CNAME.) >=20 > Any local configuration of something.alt (as an authoritatively served = zone) would be matched before checking the cache or attempting recursive = resolution, per 103[345]. >=20 > I don't have any desire or intention of local something.alt, I'm just = pointing out that the existence of a signed NXD result (via DNAME to an = empty zone) doesn't break such a set-up. >=20 >=20 >=20 > The reason for DNAME instead of delegation, is that it avoids the = operators of AS112 instances from having to configure the new zone(s) = whenever a new "delegation" occurs. >=20 > If, instead, a delegation were done, the specific zone (.alt) would = need to be configured and served somewhere. >=20 > RFC7535 is designed to avoid the need for coordination in configuring = such zones. >=20 > (RFC7535 also allows authorities for other places in the DNS tree to = make use of AS112, but that is a non-sequitur.) >=20 > Brian >=20 > On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker = > wrote: > Are you also expecting ALT will never be delegated in the root? If it = were to be delegated in the root, what impact would that have on the = uses you have in mind? >=20 > Steve Crocker > [I am having trouble sending from steve@shinkuro.com = , but I am receiving mail without trouble. = Please continue to send mail to me at steve@shinkuro.com = ] >=20 >=20 >> On Feb 3, 2017, at 12:02 PM, Brian Dickson = > = wrote: >>=20 >> Stephane wrote:=20 >> On Wed, Feb 01, 2017 at 03:28:29PM -0500, >> Warren Kumari > wrote=20 >> a message of 103 lines which said: >>=20 >> > or 2: request that the IANA insert an insecure delegation in the >> > root, pointing to a: AS112 or b: an empty zone on the root or c" >> > something similar. >>=20 >> Here, people may be interested by draft-bortzmeyer-dname-root = (expired >> but could be revived). The main objection was the privacy issue >> (sending user queries to the "random" operators of AS112.) >>=20 >> My opinion on these issues are as follows, roughly: >> I am in favor of AS112 for ALT >> For AS112, I prefer the AS112++ method (DNAME) >> I do not see why the DNAME would/should not be DNSSEC signed >> Any local use of ALT can be served locally and signed using an = alternative trust anchor >> I don't think there is any issue with having both the NXD from the = root, and the local assertion of existence, both present (in cache and = in authoritative data respectively) >> Maybe there are issues with specific implementations?=20 >> If anyone knows of such problems, it would be helpful to identify = them along with the implementation and version >> For AS112 privacy, perhaps someone should write up a recommendation = to set up local AS112 instances, to provide privacy, as an informational = RFC? >> Even simply through resolver configurations, without a full AS112 = "announce routes"? >> Do any resolver packages offer such a simple AS112 set-up? >> Maybe the efforts for privacy should start there (implement first, = then document)? >> Do any stub resolver packages include host-local AS112 = features/configurations? >> Overall, I'm obviously in favor of use of ALT, and for signing = whatever is done for ALT, and for use of DNAME for ALT. >>=20 >> Brian "DNAME" Dickson >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop = >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_1EEEEC2D-AF0A-4971-BFAC-4EB2D2C4B355 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii And just to stir the pot a bit, what would you have ICANN do = if someone applies for .alt as a top level domain?  Is it ok if we = say yes and delegate the name?  If not, what is the basis for us to = say no?


Steve Crocker
[I am having trouble = sending from steve@shinkuro.com, but I am receiving mail without = trouble.  Please continue to send mail to me at steve@shinkuro.com]

On Feb 3, 2017, at 12:18 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:

The DNAME has an effect similar to = delegation, except that in the case of the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 ) , the target is a = well-known & published empty zone (as112.arpa.)

(Delegation and DNAME = cannot coexist for the same owner name - that is one of the edicts for = DNAME, similar to CNAME.)

Any local configuration of something.alt (as an = authoritatively served zone) would be matched before checking the cache = or attempting recursive resolution, per 103[345].
I don't have any desire or intention = of local something.alt, I'm just pointing out that the existence of a = signed NXD result (via DNAME to an empty zone) doesn't break such a = set-up.



The = reason for DNAME instead of delegation, is that it avoids the operators = of AS112 instances from having to configure the new zone(s) whenever a = new "delegation" occurs.

If, instead, a delegation were done, the specific zone (.alt) = would need to be configured and served somewhere.
RFC7535 is designed to avoid the need = for coordination in configuring such zones.

(RFC7535 also allows authorities for = other places in the DNS tree to make use of AS112, but that is a = non-sequitur.)

Brian

On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker = <steve.crocker@gmail.com> wrote:
Are you also expecting ALT = will never be delegated in the root?  If it were to be delegated in = the root, what impact would that have on the uses you have in mind?

Steve Crocker
[I am having trouble = sending from steve@shinkuro.com, but I am receiving mail without = trouble.  Please continue to send mail to me at steve@shinkuro.com]


On Feb 3, 2017, at 12:02 PM, Brian Dickson = <brian.peter.dickson@gmail.com> = wrote:

Stephane wrote: 
On Wed, Feb 01, =
2017 at 03:28:29PM -0500,
 Warren Kumari <warren at kumari.net> wrote=20
 a message of 103 lines which said:

> or 2: request that the IANA insert an insecure delegation in the
> root, pointing to a: AS112 or b: an empty zone on the root or c"
> something similar.

Here, people may be interested by draft-bortzmeyer-dname-root (expired
but could be revived). The main objection was the privacy issue
(sending user queries to the "random" operators of =
AS112.)

My opinion on these issues are as follows, roughly:
  • I am in favor of AS112 for = ALT
  • For AS112, I prefer the AS112++ method (DNAME)
  • I do not see why the DNAME would/should = not be DNSSEC signed
  • Any local use of = ALT can be served locally and signed using an alternative trust = anchor
    • I don't think = there is any issue with having both the NXD from the root, and the local = assertion of existence, both present (in cache and in authoritative data = respectively)
    • Maybe there are issues with specific = implementations? 
    • If anyone knows of such = problems, it would be helpful to identify them along with the = implementation and version
  • For AS112 privacy, = perhaps someone should write up a recommendation to set up local AS112 = instances, to provide privacy, as an informational RFC?
    • Even simply through resolver configurations, = without a full AS112 "announce routes"?
    • Do any = resolver packages offer such a simple AS112 set-up?
    • Maybe the efforts for privacy should start there (implement = first, then document)?
    • Do any stub resolver packages = include host-local AS112 features/configurations?
Overall, I'm obviously in favor of use of ALT, and for = signing whatever is done for ALT, and for use of DNAME for = ALT.

Brian= "DNAME" Dickson
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop






= --Apple-Mail=_1EEEEC2D-AF0A-4971-BFAC-4EB2D2C4B355-- From nobody Fri Feb 3 12:29:01 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E5C1298D5 for ; Fri, 3 Feb 2017 12:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmBJjHkMZ9Yn for ; Fri, 3 Feb 2017 12:28:57 -0800 (PST) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 ECA4F1298B7 for ; Fri, 3 Feb 2017 12:28:56 -0800 (PST) Received: by mail-it0-x244.google.com with SMTP id e137so2730044itc.0 for ; Fri, 03 Feb 2017 12:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XiKkkj3ZdiDzg88Oqryrilbe8CWWxOb9F7vt1Dis2YY=; b=UvesPR6yW3Fx8PYEHNF3XAFPQ3fivITFwD8pgKwIm/6+0932oLu+EPSYv1cbOxic2S NFxng9NmSvkZ/2uei4fk4Uv/5VP7i7JXyLkjGAMPIKGrYJq3F4NgbL69i/cYICmsVyXc eeTFCFX9Zb2XIPTSce7shh7+OKclmrpH+TIFZtgRSR6zghMbyYVKpt5m7mzrHl/9wzzp uTtlwnm31lem/zSAyH6lDcpgUg13xxyzQTuqF+C11vt4H3ulLZCp2vB1IvyednRgWFDL BbdfVc8UpTMjYF8qVWWBZYIkdVRXqDxAWLDqiNUz3l1RqMbF9yQz5ZbGVvPUBLJD8TDA EIrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XiKkkj3ZdiDzg88Oqryrilbe8CWWxOb9F7vt1Dis2YY=; b=Wpo+OQoTbT6q7qr324BJvsJAhA+fkKSgmYPTqWV3iawMe6qfvCBBk54hRg3yW3JyLO LdPQDrZ4wcrMTxvtkPyEaSgsNvH4aFDOxXS89fd0Jk3rBXtMOTdAO0+sfFj+5muQH9zR B/pksb6r2ugo6Zsaic9manqYIsPiv4Gj+eE1+bss0I3ks9p67eVC8EMjVUHSN9hfo487 HMB+8DGCN411R70Mj9J5bIOmboVJlz5ybYNQ59/EMN0ZtrfKH850yMpZOpZfzlLgYROg dugf+t08b5E7JTBfJvHWQ1qo7xphyJqe32vr6RNMsLe6GiHuR3TGQj0XOERIszAlPSrd AgoQ== X-Gm-Message-State: AIkVDXJ9QxhcQjuk+Sh8uCj2TE2VfSID5MQloQxl66+20AKvgNtYI4QwebhJjHmXTwfXPL7tRXpwQVgMaYbuUQ== X-Received: by 10.36.139.133 with SMTP id g127mr2468961ite.4.1486153736277; Fri, 03 Feb 2017 12:28:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Fri, 3 Feb 2017 12:28:55 -0800 (PST) In-Reply-To: <74796240-46DA-4C8B-A715-DBC521EFA3F3@gmail.com> References: <5FD13D0D-57DE-4CED-B1A2-C823079B8D63@gmail.com> <74796240-46DA-4C8B-A715-DBC521EFA3F3@gmail.com> From: Brian Dickson Date: Fri, 3 Feb 2017 12:28:55 -0800 Message-ID: To: Steve Crocker Content-Type: multipart/alternative; boundary=94eb2c04b7d48859170547a6213a Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:28:59 -0000 --94eb2c04b7d48859170547a6213a Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker wrote: > And just to stir the pot a bit, what would you have ICANN do if someone > applies for .alt as a top level domain? Is it ok if we say yes and > delegate the name? If not, what is the basis for us to say no? > The insertion of the DNAME record in the root, instantiates the ALT domain. It says the ALT domain exists. However, the DNAME target of an empty zone, assures (with DNSSEC signatures) that no names below ALT exist. So, a query to a root server for "alt." would get the DNAME (if the query was for type DNAME or type ANY), or would get "NODATA" for any other RRTYPE. And a query to a root server for "anything.alt" would get the DNAME to AS112.ARPA, and the subsequent query (rewritten as anything.as112.arpa) would get NXD. As to the question about applying for "alt": it means no one can apply for .alt as a TLD, because it is taken. That is the basis for saying "no". Brian > > > Steve Crocker > [I am having trouble sending from steve@shinkuro.com, but I am receiving > mail without trouble. Please continue to send mail to me at > steve@shinkuro.com] > > On Feb 3, 2017, at 12:18 PM, Brian Dickson > wrote: > > The DNAME has an effect similar to delegation, except that in the case of > the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 ) , the target is a > well-known & published empty zone (as112.arpa.) > > (Delegation and DNAME cannot coexist for the same owner name - that is one > of the edicts for DNAME, similar to CNAME.) > > Any local configuration of something.alt (as an authoritatively served > zone) would be matched before checking the cache or attempting recursive > resolution, per 103[345]. > > I don't have any desire or intention of local something.alt, I'm just > pointing out that the existence of a signed NXD result (via DNAME to an > empty zone) doesn't break such a set-up. > > > > The reason for DNAME instead of delegation, is that it avoids the > operators of AS112 instances from having to configure the new zone(s) > whenever a new "delegation" occurs. > > If, instead, a delegation were done, the specific zone (.alt) would need > to be configured and served somewhere. > > RFC7535 is designed to avoid the need for coordination in configuring such > zones. > > (RFC7535 also allows authorities for other places in the DNS tree to make > use of AS112, but that is a non-sequitur.) > > Brian > > On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker > wrote: > >> Are you also expecting ALT will never be delegated in the root? If it >> were to be delegated in the root, what impact would that have on the uses >> you have in mind? >> >> Steve Crocker >> [I am having trouble sending from steve@shinkuro.com, but I am receiving >> mail without trouble. Please continue to send mail to me at >> steve@shinkuro.com] >> >> >> On Feb 3, 2017, at 12:02 PM, Brian Dickson >> wrote: >> >> Stephane wrote: >> >>> On Wed, Feb 01, 2017 at 03:28:29PM -0500, >>> Warren Kumari wrote >>> a message of 103 lines which said: >>> >>> > or 2: request that the IANA insert an insecure delegation in the >>> > root, pointing to a: AS112 or b: an empty zone on the root or c" >>> > something similar. >>> >>> Here, people may be interested by draft-bortzmeyer-dname-root (expired >>> but could be revived). The main objection was the privacy issue >>> (sending user queries to the "random" operators of AS112.) >>> >>> >> My opinion on these issues are as follows, roughly: >> >> - I am in favor of AS112 for ALT >> - For AS112, I prefer the AS112++ method (DNAME) >> - I do not see why the DNAME would/should not be DNSSEC signed >> - Any local use of ALT can be served locally and signed using an >> alternative trust anchor >> - I don't think there is any issue with having both the NXD from the >> root, and the local assertion of existence, both present (in cache and in >> authoritative data respectively) >> - Maybe there are issues with specific implementations? >> - If anyone knows of such problems, it would be helpful to >> identify them along with the implementation and version >> - For AS112 privacy, perhaps someone should write up a recommendation >> to set up local AS112 instances, to provide privacy, as an informational >> RFC? >> - Even simply through resolver configurations, without a full >> AS112 "announce routes"? >> - Do any resolver packages offer such a simple AS112 set-up? >> - Maybe the efforts for privacy should start there (implement >> first, then document)? >> - Do any stub resolver packages include host-local AS112 >> features/configurations? >> >> Overall, I'm obviously in favor of use of ALT, and for signing whatever >> is done for ALT, and for use of DNAME for ALT. >> >> Brian "DNAME" Dickson >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> >> >> >> >> > > --94eb2c04b7d48859170547a6213a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker <steve.crocker@gm= ail.com> wrote:
And just to stir the pot a bit, what would you ha= ve ICANN do if someone applies for .alt as a top level domain?=C2=A0 Is it = ok if we say yes and delegate the name?=C2=A0 If not, what is the basis for= us to say no?

The insertion of the D= NAME record in the root, instantiates the ALT domain. It says the ALT domai= n exists.

However, the DNAME target of an empty zo= ne, assures (with DNSSEC signatures) that no names below ALT exist.

So, a query to a root server for "alt." would g= et the DNAME (if the query was for type DNAME or type ANY), or would get &q= uot;NODATA" for any other RRTYPE.

And a query= to a root server for "anything.alt" would get the DNAME to AS112= .ARPA, and the subsequent query (rewritten as anything.as112.arpa) would ge= t NXD.

As to the question about applying for "= ;alt": it means no one can apply for .alt as a TLD, because it is take= n. That is the basis for saying "no".

Br= ian
=C2=A0


Steve Crocker
[I am having trouble sending from steve@shinkuro.com, but I a= m receiving mail without trouble.=C2=A0 Please continue to send mail to me = at steve@shinkuro.c= om]

On Fe= b 3, 2017, at 12:18 PM, Brian Dickson <brian.peter.dickson@gmail.com>= ; wrote:

The DNAME has an effect similar to delegation, = except that in the case of the AS112++ RFC ( https://tools.ietf.org/html/rfc753= 5 ) , the target is a well-known & published empty zone (as112.arpa= .)

(Delegation and DNAME cannot coexist for the sa= me owner name - that is one of the edicts for DNAME, similar to CNAME.)

Any local configuration of something.alt (as an autho= ritatively served zone) would be matched before checking the cache or attem= pting recursive resolution, per 103[345].

I don= 9;t have any desire or intention of local something.alt, I'm just point= ing out that the existence of a signed NXD result (via DNAME to an empty zo= ne) doesn't break such a set-up.



=
The reason for DNAME instead of delegation, is that it avo= ids the operators of AS112 instances from having to configure the new zone(= s) whenever a new "delegation" occurs.

I= f, instead, a delegation were done, the specific zone (.alt) would need to = be configured and served somewhere.

RFC7535 is des= igned to avoid the need for coordination in configuring such zones.

(RFC7535 also allows authorities for other places in the = DNS tree to make use of AS112, but that is a non-sequitur.)

<= /div>
Brian

On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker = <steve.croc= ker@gmail.com> wrote:
Are you also expecting ALT will never be del= egated in the root?=C2=A0 If it were to be delegated in the root, what impa= ct would that have on the uses you have in mind?

Steve Crocker
[I am having trouble sending from steve@shinkuro.com, but I am = receiving mail without trouble.=C2=A0 Please continue to send mail to me at= steve@shinkuro.com= ]


On Feb 3, 2017, at 12:= 02 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
Stephane wrote:=C2=A0
On Wed, Feb 01, 2017 at 03:28:29PM -0500,
 Warren Kumari <warren at kumari.net> wrote=20
 a message of 103 lines which said:

> or 2: request that the IANA insert an insecure delegation in the
> root, pointing to a: AS112 or b: an empty zone on the root or c"
> something similar.

Here, people may be interested by draft-bortzmeyer-dname-root (expired
but could be revived). The main objection was the privacy issue
(sending user queries to the "random" operators of AS112.)
<= /blockquote>

My opinion on these issues are as follows, = roughly:
  • I am in favor of AS112 for ALT
  • For AS112= , I prefer the AS112++ method (DNAME)
  • I do not see why the DNAM= E would/should not be DNSSEC signed
  • Any local use of ALT can be= served locally and signed using an alternative trust anchor
      • I don't think there is any issue with having both the NXD from the ro= ot, and the local assertion of existence, both present (in cache and in aut= horitative data respectively)
    • Maybe there are issues with specific = implementations?=C2=A0
    • If anyone knows of such problems, it would b= e helpful to identify them along with the implementation and version
    • For AS112 privacy, perhaps someone should write up a recommendation = to set up local AS112 instances, to provide privacy, as an informational RF= C?
      • Even simply through resolver configurations, without a full = AS112 "announce routes"?
      • Do any resolver packages offer s= uch a simple AS112 set-up?
      • Maybe the efforts for privacy should sta= rt there (implement first, then document)?
      • Do any stub resolver pac= kages include host-local AS112 features/configurations?
    = Overall, I'm obviously in favor of use of ALT, and for signing whatever= is done for ALT, and for use of DNAME for ALT.

<= div>Brian "DNAME" Dickson
_______________________________________________
DNSOP mailing list<= br>DNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop






--94eb2c04b7d48859170547a6213a-- From nobody Fri Feb 3 12:33:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415E8129521 for ; Fri, 3 Feb 2017 12:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 UAe9wo6c1lzN for ; Fri, 3 Feb 2017 12:33:04 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 4040212996C for ; Fri, 3 Feb 2017 12:33:04 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id 194so2817904pgd.0 for ; Fri, 03 Feb 2017 12:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Hep0SGqTxP9bQ9zDIMbvrQapVvqRiIJubZzoGNkbAXA=; b=gshRtohHzJh709lC1IJDbSAIAEfSVfNBYdu6iQuhJANBUh6ibAP56TLPq6AiI4DfmM 5wUEjoUZOG8edUgxoC3+eap7TR3jZu+Yx3jXWDm6ABJvN2akPkK13/p0JRI6Negn+1AG eq5oxwOKEIumH9sUekt/UrUxNqKWK+0Gfq3VmPFigNNdH0eq7Qpb4xIe+ucvH7ZzT2m1 ZiuyGp0MZNUaCzoJrYiJ3pw653Tg80oHUXvMJa9bIjCy2pcU8aYWZPjpzypG353RPpFn o6C5SoZDfcXSLZ0bnZlFs/EDkILNGJQYCfITI1mAWPiduhk+lLLtVPTA3nBvEO4H1J0j Lu2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Hep0SGqTxP9bQ9zDIMbvrQapVvqRiIJubZzoGNkbAXA=; b=dJAG6U9lKFjL7BvtyR92NU6YuapaNKYPqYNwNXvhqUCtP1QO5+kQtV4l5QzmIQg+fR XjXE24t7Y1RCglPPMJp+airWZg2W9JUX4xolU1EbAQmLa7G3VCVjmFcnEBn/VLdjAY64 xGLhftjW3AG7/f1DfYt7xYqqEjHF7gf41FazdxR3yJd9KQdwmM5yjh6lZUngGSZwbOuN 0MUJTsjRpcUOEK/AK80r6L+MWBeqt8f9QsiM6V+nEJFRXzqXyJomErnqmj76Ci26DCGA 43hULc/57Mi4s/3D06LtJGVmu+iovDbWq9EJf2jkOibFe2AzQoqUNtcuLeohaEZOMjkH YGAA== X-Gm-Message-State: AIkVDXLq+P2dO9Yx1kd5oWs0PxW7CYIih50LfSGDOWG7VizrS9vLQdqDENPEFJmg/HlRyg== X-Received: by 10.99.247.83 with SMTP id f19mr19988636pgk.158.1486153983780; Fri, 03 Feb 2017 12:33:03 -0800 (PST) Received: from [172.16.144.233] ([69.31.123.67]) by smtp.gmail.com with ESMTPSA id j28sm69291751pfj.2.2017.02.03.12.33.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 12:33:03 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_27E70A3C-33D4-40C0-A48C-4DDEC4C17177" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Steve Crocker In-Reply-To: Date: Fri, 3 Feb 2017 12:33:01 -0800 Message-Id: References: <5FD13D0D-57DE-4CED-B1A2-C823079B8D63@gmail.com> <74796240-46DA-4C8B-A715-DBC521EFA3F3@gmail.com> To: Brian Dickson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Steve Crocker , "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:33:06 -0000 --Apple-Mail=_27E70A3C-33D4-40C0-A48C-4DDEC4C17177 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We (ICANN) have no mechanism or process for inserting a DNAME record = into the root. We do have a process for considering the general issue, = but, so far as I know, no one has yet brought that idea into the = ICANN/PTI arena. Steve Crocker [I am having trouble sending from steve@shinkuro.com, but I am receiving = mail without trouble. Please continue to send mail to me at = steve@shinkuro.com] > On Feb 3, 2017, at 12:28 PM, Brian Dickson = wrote: >=20 >=20 >=20 > On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker = > wrote: > And just to stir the pot a bit, what would you have ICANN do if = someone applies for .alt as a top level domain? Is it ok if we say yes = and delegate the name? If not, what is the basis for us to say no? >=20 > The insertion of the DNAME record in the root, instantiates the ALT = domain. It says the ALT domain exists. >=20 > However, the DNAME target of an empty zone, assures (with DNSSEC = signatures) that no names below ALT exist. >=20 > So, a query to a root server for "alt." would get the DNAME (if the = query was for type DNAME or type ANY), or would get "NODATA" for any = other RRTYPE. >=20 > And a query to a root server for "anything.alt" would get the DNAME to = AS112.ARPA, and the subsequent query (rewritten as anything.as112.arpa) = would get NXD. >=20 > As to the question about applying for "alt": it means no one can apply = for .alt as a TLD, because it is taken. That is the basis for saying = "no". >=20 > Brian > =20 >=20 >=20 > Steve Crocker > [I am having trouble sending from steve@shinkuro.com = , but I am receiving mail without trouble. = Please continue to send mail to me at steve@shinkuro.com = ] >=20 >> On Feb 3, 2017, at 12:18 PM, Brian Dickson = > = wrote: >>=20 >> The DNAME has an effect similar to delegation, except that in the = case of the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 = ) , the target is a well-known & = published empty zone (as112.arpa.) >>=20 >> (Delegation and DNAME cannot coexist for the same owner name - that = is one of the edicts for DNAME, similar to CNAME.) >>=20 >> Any local configuration of something.alt (as an authoritatively = served zone) would be matched before checking the cache or attempting = recursive resolution, per 103[345]. >>=20 >> I don't have any desire or intention of local something.alt, I'm just = pointing out that the existence of a signed NXD result (via DNAME to an = empty zone) doesn't break such a set-up. >>=20 >>=20 >>=20 >> The reason for DNAME instead of delegation, is that it avoids the = operators of AS112 instances from having to configure the new zone(s) = whenever a new "delegation" occurs. >>=20 >> If, instead, a delegation were done, the specific zone (.alt) would = need to be configured and served somewhere. >>=20 >> RFC7535 is designed to avoid the need for coordination in configuring = such zones. >>=20 >> (RFC7535 also allows authorities for other places in the DNS tree to = make use of AS112, but that is a non-sequitur.) >>=20 >> Brian >>=20 >> On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker = > wrote: >> Are you also expecting ALT will never be delegated in the root? If = it were to be delegated in the root, what impact would that have on the = uses you have in mind? >>=20 >> Steve Crocker >> [I am having trouble sending from steve@shinkuro.com = , but I am receiving mail without trouble. = Please continue to send mail to me at steve@shinkuro.com = ] >>=20 >>=20 >>> On Feb 3, 2017, at 12:02 PM, Brian Dickson = > = wrote: >>>=20 >>> Stephane wrote:=20 >>> On Wed, Feb 01, 2017 at 03:28:29PM -0500, >>> Warren Kumari > wrote=20 >>> a message of 103 lines which said: >>>=20 >>> > or 2: request that the IANA insert an insecure delegation in the >>> > root, pointing to a: AS112 or b: an empty zone on the root or c" >>> > something similar. >>>=20 >>> Here, people may be interested by draft-bortzmeyer-dname-root = (expired >>> but could be revived). The main objection was the privacy issue >>> (sending user queries to the "random" operators of AS112.) >>>=20 >>> My opinion on these issues are as follows, roughly: >>> I am in favor of AS112 for ALT >>> For AS112, I prefer the AS112++ method (DNAME) >>> I do not see why the DNAME would/should not be DNSSEC signed >>> Any local use of ALT can be served locally and signed using an = alternative trust anchor >>> I don't think there is any issue with having both the NXD from the = root, and the local assertion of existence, both present (in cache and = in authoritative data respectively) >>> Maybe there are issues with specific implementations?=20 >>> If anyone knows of such problems, it would be helpful to identify = them along with the implementation and version >>> For AS112 privacy, perhaps someone should write up a recommendation = to set up local AS112 instances, to provide privacy, as an informational = RFC? >>> Even simply through resolver configurations, without a full AS112 = "announce routes"? >>> Do any resolver packages offer such a simple AS112 set-up? >>> Maybe the efforts for privacy should start there (implement first, = then document)? >>> Do any stub resolver packages include host-local AS112 = features/configurations? >>> Overall, I'm obviously in favor of use of ALT, and for signing = whatever is done for ALT, and for use of DNAME for ALT. >>>=20 >>> Brian "DNAME" Dickson >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop = >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_27E70A3C-33D4-40C0-A48C-4DDEC4C17177 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We (ICANN) have no mechanism or process for inserting a DNAME = record into the root.  We do have a process for considering the = general issue, but, so far as I know, no one has yet brought that idea = into the ICANN/PTI arena.

Steve Crocker
[I am having trouble = sending from steve@shinkuro.com, but I am receiving mail without = trouble.  Please continue to send mail to me at steve@shinkuro.com]

On Feb 3, 2017, at 12:28 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:



On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker = <steve.crocker@gmail.com> wrote:
And just to stir the pot a = bit, what would you have ICANN do if someone applies for .alt as a top = level domain?  Is it ok if we say yes and delegate the name?  = If not, what is the basis for us to say no?

The insertion of the = DNAME record in the root, instantiates the ALT domain. It says the ALT = domain exists.

However, the DNAME target of an empty zone, assures (with = DNSSEC signatures) that no names below ALT exist.
So, a query to a root server for = "alt." would get the DNAME (if the query was for type DNAME or type = ANY), or would get "NODATA" for any other RRTYPE.
And a query to a root server for = "anything.alt" would get the DNAME to AS112.ARPA, and the subsequent = query (rewritten as anything.as112.arpa) would get NXD.

As to the question about = applying for "alt": it means no one can apply for .alt as a TLD, because = it is taken. That is the basis for saying "no".

Brian
 


Steve Crocker
[I am having trouble = sending from steve@shinkuro.com, but I am receiving mail without = trouble.  Please continue to send mail to me at steve@shinkuro.com]

On Feb = 3, 2017, at 12:18 PM, Brian Dickson <brian.peter.dickson@gmail.com> = wrote:

The DNAME has an = effect similar to delegation, except that in the case of the AS112++ RFC = ( https://tools.ietf.org/html/rfc7535 ) , = the target is a well-known & published empty zone = (as112.arpa.)

(Delegation and DNAME cannot coexist for the same owner name = - that is one of the edicts for DNAME, similar to CNAME.)

Any local configuration = of something.alt (as an authoritatively served zone) would be matched = before checking the cache or attempting recursive resolution, per = 103[345].

I = don't have any desire or intention of local something.alt, I'm just = pointing out that the existence of a signed NXD result (via DNAME to an = empty zone) doesn't break such a set-up.



The reason for DNAME instead of = delegation, is that it avoids the operators of AS112 instances from = having to configure the new zone(s) whenever a new "delegation" = occurs.

If, = instead, a delegation were done, the specific zone (.alt) would need to = be configured and served somewhere.

RFC7535 is designed to avoid the need = for coordination in configuring such zones.

(RFC7535 also allows authorities for = other places in the DNS tree to make use of AS112, but that is a = non-sequitur.)

Brian

On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker = <steve.crocker@gmail.com> wrote:
Are you also expecting ALT = will never be delegated in the root?  If it were to be delegated in = the root, what impact would that have on the uses you have in mind?

Steve Crocker
[I am having trouble = sending from steve@shinkuro.com, but I am receiving mail without = trouble.  Please continue to send mail to me at steve@shinkuro.com]


On Feb 3, 2017, at = 12:02 PM, Brian Dickson <brian.peter.dickson@gmail.com> = wrote:

Stephane wrote: 
On Wed, Feb 01, 2017 =
at 03:28:29PM -0500,
 Warren Kumari <warren at kumari.net> wrote=20
 a message of 103 lines which said:

> or 2: request that the IANA insert an insecure delegation in the
> root, pointing to a: AS112 or b: an empty zone on the root or c"
> something similar.

Here, people may be interested by draft-bortzmeyer-dname-root (expired
but could be revived). The main objection was the privacy issue
(sending user queries to the "random" operators of =
AS112.)

My opinion on these issues are as follows, roughly:
  • I am in favor of AS112 for = ALT
  • For AS112, I prefer the AS112++ method (DNAME)
  • I do not see why the DNAME would/should = not be DNSSEC signed
  • Any local use of = ALT can be served locally and signed using an alternative trust = anchor
    • I don't think = there is any issue with having both the NXD from the root, and the local = assertion of existence, both present (in cache and in authoritative data = respectively)
    • Maybe there are issues with specific = implementations? 
    • If anyone knows of such = problems, it would be helpful to identify them along with the = implementation and version
  • For AS112 privacy, = perhaps someone should write up a recommendation to set up local AS112 = instances, to provide privacy, as an informational RFC?
    • Even simply through resolver configurations, = without a full AS112 "announce routes"?
    • Do any = resolver packages offer such a simple AS112 set-up?
    • Maybe the efforts for privacy should start there (implement = first, then document)?
    • Do any stub resolver packages = include host-local AS112 features/configurations?
Overall, I'm obviously in favor of use of ALT, and for = signing whatever is done for ALT, and for use of DNAME for = ALT.

Brian= "DNAME" Dickson
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop








= --Apple-Mail=_27E70A3C-33D4-40C0-A48C-4DDEC4C17177-- From nobody Fri Feb 3 12:44:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0DB12997E for ; Fri, 3 Feb 2017 12:44:54 -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 WlDvB_a9rUS3 for ; Fri, 3 Feb 2017 12:44:53 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1EE129973 for ; Fri, 3 Feb 2017 12:44:52 -0800 (PST) Received: (qmail 31124 invoked from network); 3 Feb 2017 20:44:51 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Feb 2017 20:44:51 -0000 Date: 3 Feb 2017 20:44:29 -0000 Message-ID: <20170203204429.14153.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: steve.crocker@gmail.com Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:44:54 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >We (ICANN) have no mechanism or process for inserting a DNAME record into the root. We do have a >process for considering the general issue, but, so far as I know, no one has yet brought that idea >into the ICANN/PTI arena. There are ccTLDs that contain nothing but a DNAME (along with the mandatory SOA and NS). Maybe that's close enough. R's, John From nobody Fri Feb 3 12:49:18 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E8212998E for ; Fri, 3 Feb 2017 12:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uU5gKynjb9d for ; Fri, 3 Feb 2017 12:49:14 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 08FA012997F for ; Fri, 3 Feb 2017 12:49:13 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id x49so53280089qtc.2 for ; Fri, 03 Feb 2017 12:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D4o+XeOawiEWuzYHmG3OgNqDMf9PoRlHJnHS0yJLRKY=; b=kCfD2kYMDUWitvOv0tpN2HOsk7L6SkoRFx+thdhwCR47bUdFErWEfbCEa95hRSsZfN 8mPkVhhA/iaOIbJxtCFxRFedSX1K8rzGGrac9zHEFcdVxAFsz86jVDRmLE7Wa5vvJ0ma MLhZN3YiuXnp8HY1m19gUbfDvrYVAqfG/sFlrnnxvTrdlSxTx4DE2yEAc5SqueWijtRn jBVdwl/pEynnU/t7vQ2fHeF5/jiypPk3xc+4ayuHQHvh6EYFzLhut4k/Ij4MSX3bziqZ KmQsJrjvZcQtYsUf2vaWeN8Tk5Pf2SYwu6dYTgPXNKyo2iELPzsmXtSe1zJiXItWwSho RQZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D4o+XeOawiEWuzYHmG3OgNqDMf9PoRlHJnHS0yJLRKY=; b=HZR6rMQ/ehhmgylFZAfC5hYeOwRxOZMOnpkkHQ3IPcOV9X6Zy5VQiLDw+WVyczZdSk PUOsc1ZKvXZrAPwyf/4I3jCgvghpOV66/djUUt09ORjevCDQh2VmiZ4x3CxYYKHFz+xE nG8TALhtt6zukWO3CMEhhsY4cOq3mg1WFyjjrWBDl5FNSjr6Tha3/ipnTcKq1kXP8Aub WNFmWDZi8NVDbhAUq0cRI6l8JwdCwrjMTIE2hwXUFSuM7oZG/gZJaNQiKz57eOFItHEw 4jaUiMlIoLJDhXfZpT3nrK5OMnN0KcmK+3IvpL7vVUqpP9qbS78pMwiLMb6q5L5NNi0z lZHg== X-Gm-Message-State: AIkVDXKJ2K0pzSQdtjQF+mdG3QHDlmDtiOBfV8uifUm0eDg9rnRtsx3i3ill3QUar50vQg== X-Received: by 10.237.51.37 with SMTP id u34mr16147489qtd.40.1486154952998; Fri, 03 Feb 2017 12:49:12 -0800 (PST) Received: from [10.0.0.19] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by smtp.gmail.com with ESMTPSA id y189sm25428154qky.39.2017.02.03.12.49.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 12:49:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <9E3BFAAD-1F39-457B-95F1-A9E99B75151E@gmail.com> Date: Fri, 3 Feb 2017 15:49:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7A477809-D794-4443-AA0F-E3CCF1203A4B@gmail.com> References: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> <20170201214226.66A4061165DC@rock.dv.isc.org> <9E3BFAAD-1F39-457B-95F1-A9E99B75151E@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:49:15 -0000 Hi, To sharpen the question slightly=E2=80=A6. > On Feb 1, 2017, at 5:11 PM, Ralph Droms wrote: >=20 >=20 >> On Feb 1, 2017, at 4:42 PM, Mark Andrews wrote: >>=20 >>=20 >> In message <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com>, Ted = Lemon writes: >>>=20 >>> On Feb 1, 2017, at 3:50 PM, Ralph Droms = wrote: >>>>> It appears to me that requesting an insecure delegation is the = right >>>>> thing to do, as a "technical use". We have, so far, been very = careful in >>>>> what we ask for. If ICANN does not agree, then we can discuss = other >>>>> options. >>>>=20 >>>> I agree. >>>=20 >>> I'm confused. The .ALT TLD is expected to be used for non-DNS name >>> lookups. So isn't a secure denial of existence exactly what we = want for >>> .ALT? >>=20 >> No. >>=20 >>> What is the utility in having an un-signed delegation? >>=20 >> Alt can be used for whatever purpose that the user wants to use it >> for including names served using the DNS protocol. >=20 > The draft restricts use of .alt as follows: >=20 > This label is intended to be used as > the final (rightmost) label to signify that the name is not rooted = in > the DNS, and that normal registration and lookup rules do not apply. >=20 > ...which would lead me to believe .alt would not be used for names = served using the DNS protocol. >=20 > However, the phrase "not rooted in the DNS" might need some = clarification. >=20 > In particular, would ".homenet.alt" be OK, as it is a locally-served = zone, not a subdomain of the root zone? As a slightly broader question, what does the WG want .ALT to do? More specifically, perhaps, what problems discussed in = draft-ietf-dnsop-sutld-ps-02.txt do we want it to solve? The WG can agree to change the current text, but I think the WG needs to = agree on the purpose of ALT, as that seems likely to make it easier to = decide what behavior we want to specify for it and, in turn, how it = should be implemented. Suzanne From nobody Fri Feb 3 12:55:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B2C12950A for ; Fri, 3 Feb 2017 12:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQC9nOuO2FbD for ; Fri, 3 Feb 2017 12:55:35 -0800 (PST) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 55CAE129506 for ; Fri, 3 Feb 2017 12:55:35 -0800 (PST) Received: by mail-it0-x241.google.com with SMTP id 203so2793726ith.2 for ; Fri, 03 Feb 2017 12:55:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fwW3l5o+KhucFuFYgrgfuutYLEF+ctRcp5CNwCpUijM=; b=FRyJwB4HTdd/VPT2Kv3n/UDCtD44Ejf+Ob0Hux2RNNn8NXaXV+bP52LeVr0BJ7d4eU zyB/0ZgZnlDaM6s05QUhLMW30TiFh+POeWhoDWqAhWRdRpFJ9AOZhr7tX2SUcipLYQh4 lZC7Ic9a4vHA/MV/2wSQFT39vKuST4snoVCCBWUnaRy3B3zoRB8+KnPo0QCJLx2sAeZH bBTGxCG2IApUEGYwjGZOodw8GvudlzF8c0tvJddLPjK5lDvyiAqiQLWOENZS8HJ6EMsa GH/HDr35eXq1COP78gyl4m+1MF+OdOKduSLv+tgcu4d9zCmE5OxvlEXwH0avt7gxV1+d qxtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fwW3l5o+KhucFuFYgrgfuutYLEF+ctRcp5CNwCpUijM=; b=JJ8si87MHAGTpkCFpzFd26L5eU6ysotmSsEyGcda/1MIvOMXX9o4LYhI7A+7fRk2WD IPQJQYiwOJQCr2xvRjIN1Duc+pdKOxsnartbAFoUVoiFqu/q3TRxGnE1K4T953Qk6zta CtWAOuGZJ4EZPO7nCnsD53OX1ZcGbIuXbr1QpzkhVQlx3anYzgAI2LDjGkhiiBk8bDZP h8gnwBF34Dzv0LeUlAM/aQ7gawC6cJ1+WvnrVDsc+Z2dlbw1E3IzxlyvRHodV4o5swNt GIpMV44z7slQ0HyWmXp/ev1NxKnS+KvSP9P3+DdOufKTu0VdQTWK+JcenJy7M0Y9OZgt bQYg== X-Gm-Message-State: AIkVDXIVcQyOXLDC4fJrcpnIFdR+9TcY4SrhjUJ90ahXcIu6/KcpOW43ZyVs7q8jp/Kwtvxn3mRR3Ppkh5JerQ== X-Received: by 10.36.105.148 with SMTP id e142mr2657882itc.95.1486155334635; Fri, 03 Feb 2017 12:55:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Fri, 3 Feb 2017 12:55:34 -0800 (PST) In-Reply-To: References: From: Brian Dickson Date: Fri, 3 Feb 2017 12:55:34 -0800 Message-ID: To: Bob Harold Content-Type: multipart/alternative; boundary=001a113f6fdecd55e20547a680f8 Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:55:37 -0000 --001a113f6fdecd55e20547a680f8 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 12:19 PM, Bob Harold wrote: > > On Fri, Feb 3, 2017 at 3:02 PM, Brian Dickson < > brian.peter.dickson@gmail.com> wrote: > >> Stephane wrote: >> >>> On Wed, Feb 01, 2017 at 03:28:29PM -0500, >>> Warren Kumari wrote >>> a message of 103 lines which said: >>> >>> > or 2: request that the IANA insert an insecure delegation in the >>> > root, pointing to a: AS112 or b: an empty zone on the root or c" >>> > something similar. >>> >>> Here, people may be interested by draft-bortzmeyer-dname-root (expired >>> but could be revived). The main objection was the privacy issue >>> (sending user queries to the "random" operators of AS112.) >>> >>> >> My opinion on these issues are as follows, roughly: >> >> - I am in favor of AS112 for ALT >> - For AS112, I prefer the AS112++ method (DNAME) >> - I do not see why the DNAME would/should not be DNSSEC signed >> - Any local use of ALT can be served locally and signed using an >> alternative trust anchor >> - I don't think there is any issue with having both the NXD from the >> root, and the local assertion of existence, both present (in cache and in >> authoritative data respectively) >> - Maybe there are issues with specific implementations? >> - If anyone knows of such problems, it would be helpful to >> identify them along with the implementation and version >> - For AS112 privacy, perhaps someone should write up a recommendation >> to set up local AS112 instances, to provide privacy, as an informational >> RFC? >> - Even simply through resolver configurations, without a full >> AS112 "announce routes"? >> - Do any resolver packages offer such a simple AS112 set-up? >> - Maybe the efforts for privacy should start there (implement >> first, then document)? >> - Do any stub resolver packages include host-local AS112 >> features/configurations? >> >> Overall, I'm obviously in favor of use of ALT, and for signing whatever >> is done for ALT, and for use of DNAME for ALT. >> >> Brian "DNAME" Dickson >> >> > I would prefer an UNsigned delegation. If someone wants a signed zone, > they can add a trust anchor, I assume. But if they want an unsigned zone > there needs to be a way to get that. > I think you would be able to do the following, via local configuration, to create an unsigned zone under ALT: Locally configure ALT. Have delegations to WHATEVER.ALT with NS, but without DS. Sign the resulting ALT zone. WHATEVER.ALT is now an unsigned zone, whose existence is signed by the local trust anchor for ALT. (The ALT trust anchor would exist alongside the real root trust anchor; the local stuff overrides the root stuff, for ALT.) Brian > > -- > Bob Harold > > --001a113f6fdecd55e20547a680f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 3, 2017 at 12:19 PM, Bob Harold <rharolde@umich.edu&g= t; wrote:

On Fri, Feb 3, 2017 at 3:02 PM, Brian Dickson <= span dir=3D"ltr"><brian.peter.dickson@gmail.com> wrote:
Stephane wrote:=C2=A0
On Wed, Feb 01, 2017 at 03:28:29PM -0500,
 Warren Kumari <warren at kumari.net> wrote=20
 a message of 103 lines which said:

> or 2: request that the IANA insert an insecure delegation in the
> root, pointing to a: AS112 or b: an empty zone on the root or c"
> something similar.

Here, people may be interested by draft-bortzmeyer-dname-root (expired
but could be revived). The main objection was the privacy issue
(sending user queries to the "random" operators of AS112.)
<= /blockquote>

My opinion on these issues are as follows, = roughly:
  • I am in favor of AS112 for ALT
  • For AS112= , I prefer the AS112++ method (DNAME)
  • I do not see why the DNAM= E would/should not be DNSSEC signed
  • Any local use of ALT can be= served locally and signed using an alternative trust anchor
      • I don't think there is any issue with having both the NXD from the ro= ot, and the local assertion of existence, both present (in cache and in aut= horitative data respectively)
    • Maybe there are issues with specific = implementations?=C2=A0
    • If anyone knows of such problems, it would b= e helpful to identify them along with the implementation and version
    • For AS112 privacy, perhaps someone should write up a recommendation = to set up local AS112 instances, to provide privacy, as an informational RF= C?
      • Even simply through resolver configurations, without a full = AS112 "announce routes"?
      • Do any resolver packages offer s= uch a simple AS112 set-up?
      • Maybe the efforts for privacy should sta= rt there (implement first, then document)?
      • Do any stub resolver pac= kages include host-local AS112 features/configurations?
    = Overall, I'm obviously in favor of use of ALT, and for signing whatever= is done for ALT, and for use of DNAME for ALT.

<= div>Brian "DNAME" Dickson


I would prefer an UNsigned= delegation.=C2=A0 If someone wants a signed zone, they can add a trust anc= hor, I assume.=C2=A0 But if they want an unsigned zone there needs to be a = way to get that.

I = think you would be able to do the following, via local configuration, to cr= eate an unsigned zone under ALT:

Locally configure= ALT.
Have delegations to WHATEVER.ALT with NS, but without DS.
Sign the resulting ALT zone.

WHATEVER.ALT= is now an unsigned zone, whose existence is signed by the local trust anch= or for ALT.

(The ALT trust anchor would exist alon= gside the real root trust anchor; the local stuff overrides the root stuff,= for ALT.)

Brian
=C2=A0

--=C2=A0
Bob Harold
=C2=A0
=

--001a113f6fdecd55e20547a680f8-- From nobody Fri Feb 3 13:01:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8295F128B37 for ; Fri, 3 Feb 2017 13:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTLDR7GqyP7C for ; Fri, 3 Feb 2017 13:01:21 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 E122C129407 for ; Fri, 3 Feb 2017 13:01:20 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id v23so54222981qtb.0 for ; Fri, 03 Feb 2017 13:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=V6PB6q2REMmPgV0ojIqp/9mG/N9JD0DN7oIueYTzeZs=; b=WNEQ7IZc9dXuRzHJt+NfMURlubq2Rgf4o2qHxFGPPLX0HcEKPIKBUgcjk4KFgXiFV1 Uh8NbUhuTHwQKkOg/PfoVyiUma8Q3gtr/qsWh0/UxYvDhBL5Lrhji7sw2K26cncVAFau 2rdn29Qpa0/qeALi8483mP5/0Gw8XElxLPLsFXOSeqb4K9FYM79Tv72KLzTZRtdZjEaf Etfj5oOIjfGfU4bkN2CBjLOxPMlHZWfYWOy75vEN3GMUbje6donaTrJ58oHFphaPI5bx nEN14xLForYJXogskYNJd9XOuW2YlwIbK6W24mMC9vHS0Lu/tYIiUrXFSPWIXkQ3984C nzgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=V6PB6q2REMmPgV0ojIqp/9mG/N9JD0DN7oIueYTzeZs=; b=jdEJHHwz29hq//BeXMhGDsFSu+nKzwTLDx+Tar0hHRNuv5LJ99ivytVHPJwW0Lz11A 8YAMI1MJeTiyCTcihsBr7ONbCEmH0PLSM9FnE0H5fZIAXonOCPFzgCgI/LDJWv+UF3X2 rJKcwmOnHCL9Zq+lAv0s9ncuKSXvYTNlBrgjmVoCIGxzCUofGAdpQJhzF+DiIex2S7QP NMKpLnWbX3eoPc4EHxjroY+FPFxO66zk74VLjsxdPrFe3De7OnqIGAzoim+K2iLaKRWN AmZVkubxi8VbxFydSROLclTRtV8egGMyn5eWBULFbR2u6je1j6uTvBezkWy8mNGosLqU 7EQQ== X-Gm-Message-State: AMke39ln7IAcsQVocVJcyAcL30Sn4EkEhwlY2khA/T21URtPErARYcFPpNWrpnunymshYg== X-Received: by 10.55.24.8 with SMTP id j8mr16594461qkh.181.1486155679837; Fri, 03 Feb 2017 13:01:19 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:902c:8449:d637:4e18? ([2601:181:c381:c20:902c:8449:d637:4e18]) by smtp.gmail.com with ESMTPSA id c41sm25515013qtd.3.2017.02.03.13.01.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 13:01:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <20170201205656.CB3356115F8E@rock.dv.isc.org> Date: Fri, 3 Feb 2017 16:01:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170201205656.CB3356115F8E@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:01:22 -0000 Mark, > On Feb 1, 2017, at 3:56 PM, Mark Andrews wrote: >=20 >=20 > In message = , = Warren K > umari writes: >> This is a fine thing to request in an IANA consideratons, but isn't >> necessarily *useful* -- the IANA has the technical ability to add >> stuff to the root zone, but not the mandate (this is like walking = into >> a bank and requesting the teller gives you a bunch of money - they = may >> be able to do so, but aren't actually allowed to.. :-)). >=20 > Actually it isn't the same. >=20 > Implicit in the agreement that the IETF can get names in the root > namespace is the ability to use them. Some uses require that there > be a entry in the root zone. >=20 > It doesn't say that the IETF can "RESERVE" a name. The IETF gets > the name. Can you suggest a citation for this belief that can be included in the = problem statement draft? It=E2=80=99s not a view that=E2=80=99s ever been discussed as far as I = can recall and it seems to me that it would be difficult to get = consensus on it across the affected communities. But I=E2=80=99m always = willing to be wrong. thanks, Suzanne From nobody Fri Feb 3 13:09:34 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9682129572 for ; Fri, 3 Feb 2017 13:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 EfkA51M-06eA for ; Fri, 3 Feb 2017 13:09:31 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A80E129561 for ; Fri, 3 Feb 2017 13:09:31 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id AA1D51FCACC; Fri, 3 Feb 2017 21:09:27 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 63CB0160046; Fri, 3 Feb 2017 21:09:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4B2AF160074; Fri, 3 Feb 2017 21:09:26 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W5emVYgPMj1w; Fri, 3 Feb 2017 21:09:26 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DC2DA160046; Fri, 3 Feb 2017 21:09:25 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7286C618213C; Sat, 4 Feb 2017 08:09:22 +1100 (EST) To: Brian Dickson From: Mark Andrews References: In-reply-to: Your message of "Fri, 03 Feb 2017 12:02:47 -0800." Date: Sat, 04 Feb 2017 08:09:22 +1100 Message-Id: <20170203210922.7286C618213C@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:09:33 -0000 In message , Brian Dickson writes: > > Stephane wrote: > > > On Wed, Feb 01, 2017 at 03:28:29PM -0500, > > Warren Kumari wrote > > a message of 103 lines which said: > > > > > or 2: request that the IANA insert an insecure delegation in the > > > root, pointing to a: AS112 or b: an empty zone on the root or c" > > > something similar. > > > > Here, people may be interested by draft-bortzmeyer-dname-root (expired > > but could be revived). The main objection was the privacy issue > > (sending user queries to the "random" operators of AS112.) > > > > > My opinion on these issues are as follows, roughly: > > - I am in favor of AS112 for ALT > - For AS112, I prefer the AS112++ method (DNAME) > - I do not see why the DNAME would/should not be DNSSEC signed > - Any local use of ALT can be served locally and signed using an > alternative trust anchor > - I don't think there is any issue with having both the NXD from the > root, and the local assertion of existence, both present (in cache and > in > authoritative data respectively) > - Maybe there are issues with specific implementations? > - If anyone knows of such problems, it would be helpful to identify > them along with the implementation and version > - For AS112 privacy, perhaps someone should write up a recommendation to > set up local AS112 instances, to provide privacy, as an informational RFC? > - Even simply through resolver configurations, without a full AS112 > "announce routes"? > - Do any resolver packages offer such a simple AS112 set-up? > - Maybe the efforts for privacy should start there (implement first, > then document)? > - Do any stub resolver packages include host-local AS112 > features/configurations? > > Overall, I'm obviously in favor of use of ALT, and for signing whatever is > done for ALT, and for use of DNAME for ALT. > > Brian "DNAME" Dickson You need a insecure delegation for ALT for the purposes we want to use ALT for. Go setup a test rig where you have a signed root with ALT as you described. A validiting recursive server which also serves foo.alt. A second validating recursive server which forwards all queries to the first recursive server. All servers are configured with a trust anchor for the test root zone and are validating responses. Try to perform a lookup on foo.alt. The second recursive server is the validating client that needs to be able to get a answer other than BOGUS. As we want to allow foo.alt to be unsigned there can't be any other trust anchors, including negative, configured. Only solutions which allow content from the foo.alt zone to be successfully resolved are acceptable. The following will not work with the above rig: * No delegation for ALT. * A secure delegation for ALT. * A DNAME for ALT in the root zone. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Feb 3 13:17:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D67129556 for ; Fri, 3 Feb 2017 13:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxJjXBz9ra9d for ; Fri, 3 Feb 2017 13:17:50 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 BFE12129554 for ; Fri, 3 Feb 2017 13:17:50 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id x49so54649934qtc.2 for ; Fri, 03 Feb 2017 13:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jSLkNus9c6tM/3NoypJuXNjAguApmCyUmo5o/SazrRM=; b=OYZMK8iFkepT4o855O1Bqxw/+3VVMOyE+YvAGUG2d5TqEcIleJw2MRxZr9ECi0SEub 5VnzyQokmOHFgI9NSJZZOSfXGc40+u1aARtHWXM/R1yv6K7D0ryiDEfCTEouyVYv1S+A eBArZqyi2ZqIHZBGnk+TCUAsyZB7k8VpDwuhWqeNaK/ou5KrTsW6xIDFTwMrZ3fkfnp7 iM3O/+NtHNTPYrLK5U3GFwC1PnuIfiVftN/nx+aEW4VR3uqOhiobJ30Vs7ikgOKKBeI2 YerCcL7LKczBJofVZxLT3v7+RBV5UBGDwWjEyyarRbsKvzaPssECbO0bs4ohCyhWCXSs bbXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jSLkNus9c6tM/3NoypJuXNjAguApmCyUmo5o/SazrRM=; b=Ty9XH/N57cHXYSl4GgCuEfjm7rwO//0bwgeZUvX7HkzWD2AEp6HpgQqRfYoNUVlX/E wtSJjJkjOX79jUILa3495Wg9FLoD2bml0LRWavh/k4LkZRSG1RzWYt5ZjhpYnPp5eAZi cmozMQm01CkeSNfZagkQdf5FLVjrTXk5G48lQGfRtSvqicinjkB5iZE1QEVtxT4AIDd4 UEH8erGAK/rx1tPqK0bttRJfJmjkYlYJ88E8q7QpGWq86XgJ8XL/FuHLmFrl21SrNgWH O64tduDnw0xfjK9TtF1WcZNeQu/7mqMWXEAOlBE2xPZFktomBfSaU2UPWv0Nes104Qly s3nQ== X-Gm-Message-State: AIkVDXL8Ne0XPZ9oPuzMzfY110d0C6X/y8+d2D8crN1DAQvXZOMF/FhXt8RRCawNGMbVGQ== X-Received: by 10.200.43.104 with SMTP id 37mr15558261qtv.61.1486156669880; Fri, 03 Feb 2017 13:17:49 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:f418:8fb8:69e1:a461? ([2601:18f:801:600:f418:8fb8:69e1:a461]) by smtp.gmail.com with ESMTPSA id q145sm25505573qke.37.2017.02.03.13.17.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 13:17:49 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ralph Droms In-Reply-To: <7A477809-D794-4443-AA0F-E3CCF1203A4B@gmail.com> Date: Fri, 3 Feb 2017 16:17:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5AE0FFA6-C1E2-4FCD-AB7E-E94D30915D3A@gmail.com> References: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> <20170201214226.66A4061165DC@rock.dv.isc.org> <9E3BFAAD-1F39-457B-95F1-A9E99B75151E@gmail.com> <7A477809-D794-4443-AA0F-E3CCF1203A4B@gmail.com> To: Suzanne Woolf X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:17:52 -0000 > On Feb 3, 2017, at 3:49 PM, Suzanne Woolf = wrote: >=20 > Hi, >=20 > To sharpen the question slightly=E2=80=A6. >=20 >> On Feb 1, 2017, at 5:11 PM, Ralph Droms = wrote: >>=20 >>=20 >>> On Feb 1, 2017, at 4:42 PM, Mark Andrews wrote: >>>=20 >>>=20 >>> In message <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com>, Ted = Lemon writes: >>>>=20 >>>> On Feb 1, 2017, at 3:50 PM, Ralph Droms = wrote: >>>>>> It appears to me that requesting an insecure delegation is the = right >>>>>> thing to do, as a "technical use". We have, so far, been very = careful in >>>>>> what we ask for. If ICANN does not agree, then we can discuss = other >>>>>> options. >>>>>=20 >>>>> I agree. >>>>=20 >>>> I'm confused. The .ALT TLD is expected to be used for non-DNS = name >>>> lookups. So isn't a secure denial of existence exactly what we = want for >>>> .ALT? >>>=20 >>> No. >>>=20 >>>> What is the utility in having an un-signed delegation? >>>=20 >>> Alt can be used for whatever purpose that the user wants to use it >>> for including names served using the DNS protocol. >>=20 >> The draft restricts use of .alt as follows: >>=20 >> This label is intended to be used as >> the final (rightmost) label to signify that the name is not rooted = in >> the DNS, and that normal registration and lookup rules do not apply. >>=20 >> ...which would lead me to believe .alt would not be used for names = served using the DNS protocol. >>=20 >> However, the phrase "not rooted in the DNS" might need some = clarification. >>=20 >> In particular, would ".homenet.alt" be OK, as it is a locally-served = zone, not a subdomain of the root zone? >=20 > As a slightly broader question, what does the WG want .ALT to do? Here's a starting point: The .alt subdomain is to be used for names that are not expected to be = resolved with the DNS protocol, and names that are expected to be = resolved with the DNS protocol through a context other than the root = zone (e.g., locally served zones). >=20 > More specifically, perhaps, what problems discussed in = draft-ietf-dnsop-sutld-ps-02.txt do we want it to solve? Roughly speaking, and open for debate: Reduces potential conflict between IETF and ICANN assignment of names in = the Domain Namespace root. Obviates the need for (most?) interpretations of "technical use". Addresses some (but not all) of the reasons an entity might commandeer a = domain name. Mitigates the problem that newly utilized special use names are assumed = to use DNS for resolution by most existing software. Helps separate the regions of the Domain Namespace over which IETF and = ICANN have authority. Allows for ad hoc assignment of special use names. This list might change depending on: * whether IETF is still allowed to declare names in the Domain Namespace = root for "technical use" * there is a registry (and associated process) for names in the .alt = subdomain For example, how do we accommodate both "sitenet.alt." as designated by = an Internet Standard and "mynewresolver.alt" as used in a local, = experimental naming system? - Ralph >=20 > The WG can agree to change the current text, but I think the WG needs = to agree on the purpose of ALT, as that seems likely to make it easier = to decide what behavior we want to specify for it and, in turn, how it = should be implemented. >=20 >=20 > Suzanne >=20 From nobody Fri Feb 3 13:31:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22AC12945D for ; Fri, 3 Feb 2017 13:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt3tHrUgAs5q for ; Fri, 3 Feb 2017 13:31:28 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 0D39C128AC9 for ; Fri, 3 Feb 2017 13:31:28 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id w20so50721982qtb.1 for ; Fri, 03 Feb 2017 13:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2yosCX747erj4VC64Z3xoLtwG1aTFAOMoJhRxXunWKU=; b=t0KAjh9ku2iSSXApikiUxL/5bC1iPgZDbhzxvsPnhWsyFmUCrKIKYcBF8kdY5/1e9u c4Brwu/H/yWJwHZ2qBBFgpRt3T4LcySAxCrUtgz8zBtJOM3btmQTjGVYSUj8sj/74HnJ 0rI503nP9WTWJ3OWUXfwViJyc9lTx6G6F270tZxYf/AoMZkEmtlpVc8yGVO15uZW0GsF GFN5RRfas2N6dD8rpMVLuapD3yCXuWNh/asqDeFckqr8u0poIYxHOacjPV4DZxcBnuuN aThzJa19Orb5A4XxwzF7ZlSZuvFZ+40R55jaLNjhCNevdS/cHjxv5YuxBaaDd/6DOa5c lGxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2yosCX747erj4VC64Z3xoLtwG1aTFAOMoJhRxXunWKU=; b=ddxufYZlKZB1oxqh47uKx7JTtG+IztAOrZNBGBn9KJeVw3lVCMaGwbuZbbR6+3nlc7 iAhQjms8ORZ6lW41IhXsxV4msZq5yvj3oOwHMsOErQIlWcGwX0sjWmNO3LxOqRvNERti M2fYTmSOdwXE13S4q1LebNKc52TIa2hlBKX38nP4pVJEf4SiTQY/7pFIKDmtC9I0HGP4 8Qm1PU7gbJx//ecOahFlfF4ui3nuKfNZhLdxAQkXD2k4LVX2YhiVjBRdF/YCVwfb1huX xWDUPU/AvDrzzt43S1thePMQM8xO2Fso5K5RhZjeI/AcILLM1Di6PxctzgiXUqJmmQmx jxvQ== X-Gm-Message-State: AIkVDXJKGyAhMCLFYnlI7KzrINVfHLPKgVIRY4rPmfr2/yP1nclFb6jYEB99oqjUItMoNA== X-Received: by 10.200.54.252 with SMTP id b57mr15956305qtc.113.1486157486549; Fri, 03 Feb 2017 13:31:26 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m12sm25560352qtm.45.2017.02.03.13.31.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 13:31:25 -0800 (PST) From: Ted Lemon Message-Id: <3307BCDA-29EC-4961-A5C8-CB7E7C1F8A61@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FF769A11-45F7-4689-987B-900A86955BAC" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 3 Feb 2017 16:31:24 -0500 In-Reply-To: <5AE0FFA6-C1E2-4FCD-AB7E-E94D30915D3A@gmail.com> To: Ralph Droms References: <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com> <20170201214226.66A4061165DC@rock.dv.isc.org> <9E3BFAAD-1F39-457B-95F1-A9E99B75151E@gmail.com> <7A477809-D794-4443-AA0F-E3CCF1203A4B@gmail.com> <5AE0FFA6-C1E2-4FCD-AB7E-E94D30915D3A@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Suzanne Woolf , dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:31:29 -0000 --Apple-Mail=_FF769A11-45F7-4689-987B-900A86955BAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 3, 2017, at 4:17 PM, Ralph Droms wrote: > Obviates the need for (most?) interpretations of "technical use". > Helps separate the regions of the Domain Namespace over which IETF and = ICANN have authority. > Allows for ad hoc assignment of special use names. I would really strongly object to adding either of these statements. = You are essentially adding policy to a draft that is not a policy draft, = and I think that's a really bad idea. > Mitigates the problem that newly utilized special use names are = assumed to use DNS for resolution by most existing software. I'm not sure I buy this one either. This only works for experimental = special-use names. I would be okay with this: > Mitigates the problem that experimental special use names are assumed = to use DNS for resolution by most existing software. --Apple-Mail=_FF769A11-45F7-4689-987B-900A86955BAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 3, 2017, at 4:17 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
Obviates the need = for (most?) interpretations of "technical use".
Helps separate the regions of the Domain = Namespace over which IETF and ICANN have authority.
Allows for ad hoc assignment of special use = names.

I = would really strongly object to adding either of these statements. =   You are essentially adding policy to a draft that is not a policy = draft, and I think that's a really bad idea.

Mitigates the problem that newly utilized special use names = are assumed to use DNS for resolution by most existing = software.

I'm not = sure I buy this one either.   This only works for experimental = special-use names.   I would be okay with this:

Mitigates the problem that experimental special use names are = assumed to use DNS for resolution by most existing software.


= --Apple-Mail=_FF769A11-45F7-4689-987B-900A86955BAC-- From nobody Fri Feb 3 13:34:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E29129561 for ; Fri, 3 Feb 2017 13:34:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIh-TqDN41T4 for ; Fri, 3 Feb 2017 13:34:25 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 06FBF1294ED for ; Fri, 3 Feb 2017 13:34:24 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id v23so55759474qtb.0 for ; Fri, 03 Feb 2017 13:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ePNdcL8gi7IImuZWiGekEWK6i2pAPuQ6gcasC+NgF3s=; b=hjFLswN6FS5bbaF215eWM0sBav4mBizBj2MZQJrBmtq0oL2acAZ6yW2iW0H7ytQS9q Jh2/PdE4OOJp7lUVruoADupNxYpS7cuaPYcaFNR2OdmlMry2oJ1frnDrauqb2+KuwXx/ kTDiL5JM5fCZhOiO0L5CEkvSOSO6CjKffFKkkxnWknpRVMbXXX3IatcAhM9hdcjjnaLx 0FldG/rnGAqDNI48ULS9bTvaXsBExOR6phFYeM3lT1w6FP704ToYsyLw5/r0QYWmUHaY KswWKzg2YeCFXMR65xXHLhu4V1sptrYO6DTPBA9I+pvD1T5xsLLFEAChK3NmA9uraFHI 3ZpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ePNdcL8gi7IImuZWiGekEWK6i2pAPuQ6gcasC+NgF3s=; b=UahUiNCH13CC3QgaKPlHoCkEbqMc9bKPg/wR9AdzgZcfwHIczZhAJQQY0+20Lza8Tg UtyEGoqeyH9RdBMeONRgTlgekVyKA1n8ZCSjMwiP6qxXFQ0BiM0ocCnMFEtWOu2VLw6V pGw+RrqntsmNsE+olZyetURPvFM8StOEI9GKIz8vvTsiVIwYZujThcDJXaKIp009k29/ 4sO+rBoy3MFQ3rWkymSeG9NgSDebwXH9BYyx61gVyFyZMib3jKhhcUkvg43XsGYsv43M BaR2Cdssjezjy9XQ6I9DqnjEvIk07YLmM/EaclCTyA3xjERc1/PbCqh+iKQox2dYG29d j/4A== X-Gm-Message-State: AMke39lXs8wo4SvfjFbxcTkBfWnjCzkcjxWOFuFuHJCvni7pi6oGVuPtPm+7//KoxzSNDg== X-Received: by 10.55.142.135 with SMTP id q129mr14888198qkd.83.1486157664102; Fri, 03 Feb 2017 13:34:24 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id o14sm25563518qtc.46.2017.02.03.13.34.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 13:34:23 -0800 (PST) From: Ted Lemon Message-Id: <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7178E45A-240A-46BB-8260-23DBAF0C4D29" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 3 Feb 2017 16:34:21 -0500 In-Reply-To: <20170203210922.7286C618213C@rock.dv.isc.org> To: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:34:26 -0000 --Apple-Mail=_7178E45A-240A-46BB-8260-23DBAF0C4D29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 3, 2017, at 4:09 PM, Mark Andrews wrote: > You need a insecure delegation for ALT for the purposes we want to > use ALT for. I don't think there's consensus on what we want to use ALT for. I see = Ralph arguing that ALT is never used to resolve things using the DNS = protocol, and I see you saying that that's one of the uses we have in = mind. We need to figure out which of these we are actually trying to = do. If you are right, we need an insecure delegation in the root, and ALT = queries will by default be answered using DNS (in the sense that = existing resolvers have no special-case handling for ALT). If Ralph is = right, you can still use the DNS protocol to resolve names in .ALT, but = you have to use a specially modified resolver to do it: one that ignores = the secure denial of existence from the root. --Apple-Mail=_7178E45A-240A-46BB-8260-23DBAF0C4D29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 3, 2017, at 4:09 PM, Mark Andrews <marka@isc.org> = wrote:
You need a insecure delegation for ALT for the = purposes we want to
use ALT for.

I = don't think there's consensus on what we want to use ALT for.   I = see Ralph arguing that ALT is never used to resolve things using the DNS = protocol, and I see you saying that that's one of the uses we have in = mind.   We need to figure out which of these we are actually trying = to do.

If you = are right, we need an insecure delegation in the root, and ALT queries = will by default be answered using DNS (in the sense that existing = resolvers have no special-case handling for ALT).   If Ralph is = right, you can still use the DNS protocol to resolve names in .ALT, but = you have to use a specially modified resolver to do it: one that ignores = the secure denial of existence from the root.

= --Apple-Mail=_7178E45A-240A-46BB-8260-23DBAF0C4D29-- From nobody Fri Feb 3 14:19:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FCD129A1C for ; Fri, 3 Feb 2017 14:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 J1MX4IrpE9Ph for ; Fri, 3 Feb 2017 14:19:35 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E511299E5 for ; Fri, 3 Feb 2017 14:19:35 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 0C9633493CD; Fri, 3 Feb 2017 22:19:33 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E8285160075; Fri, 3 Feb 2017 22:19:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D6844160074; Fri, 3 Feb 2017 22:19:32 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S9ekaInKYsNb; Fri, 3 Feb 2017 22:19:32 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 58DB9160046; Fri, 3 Feb 2017 22:19:32 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 5CC986188E8D; Sat, 4 Feb 2017 09:19:28 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> In-reply-to: Your message of "Fri, 03 Feb 2017 16:34:21 -0500." <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> Date: Sat, 04 Feb 2017 09:19:28 +1100 Message-Id: <20170203221928.5CC986188E8D@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 22:19:36 -0000 In message <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com>, Ted Lemon writes: > > On Feb 3, 2017, at 4:09 PM, Mark Andrews wrote: > > You need a insecure delegation for ALT for the purposes we want to > > use ALT for. > > I don't think there's consensus on what we want to use ALT for. I see > Ralph arguing that ALT is never used to resolve things using the DNS > protocol, and I see you saying that that's one of the uses we have in > mind. We need to figure out which of these we are actually trying to do. I think there is a consensus for a play space. I think there is consenus on there not being any delegations under this play space with iterating down from the root. I think there is consenus that leaked queries of the form foo.alt should be getting NXDOMAIN responses from a recursive server which would otherwise be iterating down from the root for this namespace. > If you are right, we need an insecure delegation in the root, and ALT > queries will by default be answered using DNS (in the sense that existing > resolvers have no special-case handling for ALT). If Ralph is right, > you can still use the DNS protocol to resolve names in .ALT, but you have > to use a specially modified resolver to do it: one that ignores the > secure denial of existence from the root. So you want to ban BYOD from the solution space? Remember adding a alt zone to a recursive server is modifying the resolver. It is changing its observed behaviour. It isn't code but it is a modification. Why does this working group feel the need to add extra proscriptions on how this play space is to be used? I've been arguing for the broadest solution space. Its also the simplest. A insecure delegation for ALT. It is also the easist one for recursive servers which are iterating from the root that are not participating in the experiment to filter leaked queries with. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Feb 3 14:47:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD76129591 for ; Fri, 3 Feb 2017 14:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 ssor6b4SYgwg for ; Fri, 3 Feb 2017 14:47:19 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253BF129550 for ; Fri, 3 Feb 2017 14:47:19 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 9B2AE1FCAB9; Fri, 3 Feb 2017 22:47:15 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 4F85B160075; Fri, 3 Feb 2017 22:47:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 108A8160074; Fri, 3 Feb 2017 22:47:14 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WPse_KPR4Zat; Fri, 3 Feb 2017 22:47:13 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7AB8A160046; Fri, 3 Feb 2017 22:47:13 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A0EE061891C7; Sat, 4 Feb 2017 09:47:08 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> In-reply-to: Your message of "Fri, 03 Feb 2017 16:34:21 -0500." <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> Date: Sat, 04 Feb 2017 09:47:08 +1100 Message-Id: <20170203224708.A0EE061891C7@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 22:47:20 -0000 Also the ICANN's rule for signed TLD delegation for new gTLD is so that delegations from those zones can be signed. It is not so that NXDOMAINS are secure or else NSEC3 with OPTOUT would be banned. There are lots of insecure answers from the new TLDs including delegations. Only those using NSEC or NSEC3 without OPTOUT are secure. Alt doesn't have any delegations. There is no reason for it to be signed. There is no reason for ICANN to object other than religious arguments. Technically they don't have a leg to stand on. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Feb 3 16:59:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E8E129524 for ; Fri, 3 Feb 2017 16:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPMijRWQJBe0 for ; Fri, 3 Feb 2017 16:59:28 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 97B171294C9 for ; Fri, 3 Feb 2017 16:59:28 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id s140so7668960qke.0 for ; Fri, 03 Feb 2017 16:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wt1INw34v4icvldi1gvxMeuxef8UQCImxUbOd3YX9Y8=; b=dwzBX3FrpKHRfCi0sSw8G7wJ60DQafuqCrTTk8+eThynUHt50b/qQMIk7UQEEWav2b 5HrIxu0nzJ8KGdRfz7hDZ9urQY2xFpzvksQJDWYj+vs6yUk+eGAQ75wyI/nYmBk2GoPV 6WeCy2h2QkQKfGE9B74aMki090ErBwLnk6WBpYrU86ePiYa/KP0X80l4Um4OpB54a+sR zYkgFAWU0Z4OlVlJrLXv9a8o8w8S1eGFlUnWWz0AUTgBnBairOJEzNcnSo5Fg5hddfqT y5MZ85D+GduWejevIXA4L1Y7e7CCm8KPbpwDz1TJ+18TVmbsVGvOcaeCh3RcYgCW7Ho9 2OtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wt1INw34v4icvldi1gvxMeuxef8UQCImxUbOd3YX9Y8=; b=iy3W73Sjx1izbXgxwPzjJ09e8fb096qCHpBOobJstN3XECvV5TDkBJIKze4dkb1frp wqp9CYT1uwEXCacfX01uT1PDJLmR3cXfPIgK4cEHGF49k8+fzjol7o8cW7kgr2ktPAyA 9DG611rxIVmgSNtOkkPWnZPReH4C8P9UMzec2VnnX8mjnyI4SylLDbm9wSKkEMTvdU3J EU+3dj4q6Flk6YwcIxAN97QMnPl34hC4Eb6Cr5WES4+Rttyps2t80Zb68e/8PaEOoygN KumcDZFiyKpEfyfLGOPtdAJhXshLlyF1yVSC+0wMNOMYCAOaqV5lx5U5JSu4NfZg0pXI bw9A== X-Gm-Message-State: AMke39lyaA4dMPtoo4fpVweGIhHbdXGIjRPBZUIvPmgPq5V68L+y4AnCKQKWCQjOFi5Wrg== X-Received: by 10.55.19.224 with SMTP id 93mr17127560qkt.198.1486169967722; Fri, 03 Feb 2017 16:59:27 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id d191sm26027055qke.15.2017.02.03.16.59.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 16:59:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: <20170203224708.A0EE061891C7@rock.dv.isc.org> Date: Fri, 3 Feb 2017 19:59:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 00:59:30 -0000 Mark, I don't think you've actually given an answer to my question. I = understood that .ALT was for alternative naming systems, not for DNS = locally-served zones. We simply need to decide whether or not that's = true. I think either answer is fine; we just need to pick one. If = the answer is that it should support locally-served zones with no stub = resolver (just to be clear, I am not talking about recursive resolvers), = then as you say, there needs to be an un-signed delegation. If on the = other hand it's really for alternative _naming systems_ then we want a = secure denial of existence. The last paragraph of the introduction seems to be saying that it's the = latter. From nobody Fri Feb 3 17:52:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D9B1295EA for ; Fri, 3 Feb 2017 17:52:03 -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] 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 m2nnbWta52pP for ; Fri, 3 Feb 2017 17:52:02 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 252361295DA for ; Fri, 3 Feb 2017 17:52:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 31CB011649 for ; Sat, 4 Feb 2017 01:52:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ex5H0JV3YYtB for ; Sat, 4 Feb 2017 01:52:04 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 9B0AD1162D for ; Sat, 4 Feb 2017 01:52:04 +0000 (UTC) Date: Fri, 3 Feb 2017 20:51:58 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170204015158.GB67739@mx2.yitter.info> References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 01:52:03 -0000 On Wed, Feb 01, 2017 at 06:46:50PM -0500, Warren Kumari wrote: > Yup, but if a resolver has a (empty) local zone for .alt, and someone > queries it and validates, then I think you get SERVFAIL -- the root > says .alt doesn't exist, but here you have an answer apparently from > inside the zone -- 'tis an empty / NXD answer, but still looks like > shenanigans are happening... > If the resolver "has a local zone for alt" -- I think this means it is authoritative for that zone -- why would it ask the root about it at all? A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Feb 3 17:55:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71871295E8 for ; Fri, 3 Feb 2017 17:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkwclqp33k7z for ; Fri, 3 Feb 2017 17:55:02 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 9A466129464 for ; Fri, 3 Feb 2017 17:55:02 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id x49so62769758qtc.2 for ; Fri, 03 Feb 2017 17:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gxsM601qYfZjTGaWIU6zezdysKKwqVNcdnJI9PhE+bI=; b=axTu5Xze4+tzF+rKBWxnxdUe+7ujYPe9HW4qem+EqRxk6myR+XLdUcHo/L/C3/dMjH 6bsXzhBF9i9o2sLOwGhqFfj6bo/Je74kg8s1jaDJVYw5jBbhfFjN5t7qQ4qQmiQXbw1i LXSy16hwzYoIwTcnI1zJAVL7uI8be65TjFMQGqFax/Byj4bhGhBHVb7rWTqjkz1simTf K40AfQY73Vq8Nkh1JZAwSil1Vy5UTdMJBexQIKiS1WpudPprrO3dgYLwrNA8RTmHj+vC r5/lAazsSZ2gFlI26W7FbJXFV+Z469X81i5c7MWyeVMUUS94cVBYaFX3P31ZEWi9MSWy QLsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gxsM601qYfZjTGaWIU6zezdysKKwqVNcdnJI9PhE+bI=; b=A09rO01LfF+3uyQB+UPmaFtHOA+glWTFUeVJQmO4xDbH3l+fnlgA2QtChaa8zv/pM5 xv42MzaDR2MT4ZeGfAaAtQZgYArFBEkgWfRYhtH+W52AxlLH0KfkXuj9nzbkeFoYgrzK 9Xw+iryd8yju/2uxjH6QIu3sbyhCsruqJF3qZpGiDlpYkb+aw3cJ/rl6v/7UNDy6/+6q s+5p9YRh+U9gGclRobTGHgicqyaHzfCl8wr0G0DJRr890wCPGgMzAi7wfB/UdQBU7vq9 uz7vupGB6dffk4FvCBDBw86jRNiYyv/HXewUYAONi0aenpNjtpT1GySCpJDuP8DuDEHi GBSg== X-Gm-Message-State: AMke39nQkeFqfTEZxjRO/KCiGtEhQpp3NG9hrY9oPXNWqPokk2wUaenMvfeiRisiyv4qRQ== X-Received: by 10.200.48.136 with SMTP id v8mr43951qta.200.1486173301708; Fri, 03 Feb 2017 17:55:01 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m12sm26166031qtm.45.2017.02.03.17.55.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 17:55:00 -0800 (PST) From: Ted Lemon Message-Id: <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5A786E8F-62C9-43DD-8A60-5180BF50291F" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 3 Feb 2017 20:54:59 -0500 In-Reply-To: <20170204015158.GB67739@mx2.yitter.info> To: Andrew Sullivan References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 01:55:04 -0000 --Apple-Mail=_5A786E8F-62C9-43DD-8A60-5180BF50291F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 3, 2017, at 8:51 PM, Andrew Sullivan = wrote: > If the resolver "has a local zone for alt" -- I think this means it is > authoritative for that zone -- why would it ask the root about it at > all? This is a rehash of the .homenet discussion we had a few weeks ago. As = long as the stub resolver isn't validating, it's no problem. If it is = validating, then the recursive resolver can't fool the stub resolver if = there's a secure denial of existence. --Apple-Mail=_5A786E8F-62C9-43DD-8A60-5180BF50291F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 3, 2017, at 8:51 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
If the resolver = "has a local zone for alt" -- I think this means it is
authoritative for that zone -- why would it ask = the root about it at
all?

This is a rehash of the .homenet discussion = we had a few weeks ago.   As long as the stub resolver isn't = validating, it's no problem. If it is validating, then the recursive = resolver can't fool the stub resolver if there's a secure denial of = existence.

= --Apple-Mail=_5A786E8F-62C9-43DD-8A60-5180BF50291F-- From nobody Fri Feb 3 17:57:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF97D129579 for ; Fri, 3 Feb 2017 17:57: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] 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 SbpN2NRgtkKc for ; Fri, 3 Feb 2017 17:57:27 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id DF4FE127735 for ; Fri, 3 Feb 2017 17:57:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 8AFC811649 for ; Sat, 4 Feb 2017 01:57:30 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsEucxlCqNn7 for ; Sat, 4 Feb 2017 01:57:30 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id DA10A1162D for ; Sat, 4 Feb 2017 01:57:29 +0000 (UTC) Date: Fri, 3 Feb 2017 20:57:22 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170204015722.GC67739@mx2.yitter.info> References: <5FD13D0D-57DE-4CED-B1A2-C823079B8D63@gmail.com> <74796240-46DA-4C8B-A715-DBC521EFA3F3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74796240-46DA-4C8B-A715-DBC521EFA3F3@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 01:57:28 -0000 On Fri, Feb 03, 2017 at 12:21:16PM -0800, Steve Crocker wrote: > And just to stir the pot a bit, what would you have ICANN do if someone applies for .alt as a top level domain? Is it ok if we say yes and delegate the name? If not, what is the basis for us to say no? > If alt ends up in the 6761 special-use names registry, that seems a reason for ICANN not to delegate the name. For adding something to the 6761 special-use names registry removes it from the possible pool of names that can be in the root zone. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Feb 3 17:58:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024851295ED for ; Fri, 3 Feb 2017 17:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxxiZA6PeI3Z for ; Fri, 3 Feb 2017 17:58:45 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060581295EA for ; Fri, 3 Feb 2017 17:58:45 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id t8so24794672vke.3 for ; Fri, 03 Feb 2017 17:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kwp6LoPniS87Hj6EjmwMGvZNeJrYxqKBUVbMmmxp/c4=; b=PWVz45Av7j7vZwMnH+NzTV8gUzm8wljBFGk2xV+/IimTyRxYMdowpXNaFeYSoy9Q66 MhfiUPYpsXBrfATG47BmHqPWGoZbORdbmSmFZ2uC62Fjr6s0x0EZrKrOoxDaxxl7Qi4p 6g2rFJQ1HrIis6Kks3iwHpdidVuI6zjD3sW/3tQFANE7/GviCatVF6Iyl3Q9vIF14foh HGmKLO5vsOVHHp/lH7IqLjqO6OkFQKwkyqf1hExuzw8izJcm0ntx8/rZiGRAdPmIE46d 1VQqjEY9lRLNxbEF6CZjDPmFRa80aOpkIVIBRY8kwYyCrk5Ky3n1E6uZFv1MjMBRONHj xdgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kwp6LoPniS87Hj6EjmwMGvZNeJrYxqKBUVbMmmxp/c4=; b=bT+as4r8UxG2SvctWjqabDZxKbBD+Vvn49Oiw5nOi8vK/ZExF7rx4LKp7kBSSM5Kfn I1vIgZOXdPdY9NbRKiwH1M2Gbe14Zx0i3jZy+jokOsOqQZ3CtPBI0B5LqN3tQ1B4u5xe Lz/+x+/0sHXgCkg0y2Lrs/5wsQJLw28hyreAbK2NlOxLnkWs6lhkmwAsxLU6sPCEqz18 0ps1z1Zgf+JxyUUAzwjWjk4fJIw8z5/5O27JXTUuapbrgB5badLtUpmovMOISZUHcyy0 amT0qv+oPt5Fgql88vZ9W1CqC86fb4nXnl+BBno4gmwLURVIg3P1T0ZZgN1CyFEPhF1n fSrA== X-Gm-Message-State: AMke39lHwuhHYYo1t9MF6FA+cm0HtEpWiIpMbJtetIicOFEjns5Sb53FokTCaRLebvpOe3WPgX9eM/X9xYH9Ig== X-Received: by 10.31.85.4 with SMTP id j4mr21663vkb.1.1486173524094; Fri, 03 Feb 2017 17:58:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.48.211 with HTTP; Fri, 3 Feb 2017 17:58:43 -0800 (PST) X-Originating-IP: [70.191.149.15] In-Reply-To: <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> From: George Michaelson Date: Fri, 3 Feb 2017 20:58:43 -0500 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dnsop WG , Andrew Sullivan Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 01:58:47 -0000 sorry to be thick, but.. can we have both on a case-by-case basis somehow? it feels like no, because the sign over the zone state implicitly carries either denial of all false, or denial of none. I can't see how it can be in a dualistic middle ground. but if we could do it somehow, cleverly, it would be neat: those that need to exist with DNSSEC as alternate namespaces can, while more normal odd names, just exist, and those who want to be denied out of all existence, are repudiated. -g On Fri, Feb 3, 2017 at 8:54 PM, Ted Lemon wrote: > On Feb 3, 2017, at 8:51 PM, Andrew Sullivan wrote: > > If the resolver "has a local zone for alt" -- I think this means it is > authoritative for that zone -- why would it ask the root about it at > all? > > > This is a rehash of the .homenet discussion we had a few weeks ago. As > long as the stub resolver isn't validating, it's no problem. If it is > validating, then the recursive resolver can't fool the stub resolver if > there's a secure denial of existence. > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Fri Feb 3 18:07:17 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B78F129464 for ; Fri, 3 Feb 2017 18:07:15 -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] 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 W2OiohFTz-dK for ; Fri, 3 Feb 2017 18:07:14 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0E1127735 for ; Fri, 3 Feb 2017 18:07:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 9154011649 for ; Sat, 4 Feb 2017 02:07:18 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z6LO7PME9H0 for ; Sat, 4 Feb 2017 02:07:17 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id AE2321162D for ; Sat, 4 Feb 2017 02:07:17 +0000 (UTC) Date: Fri, 3 Feb 2017 21:07:11 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170204020711.GD67739@mx2.yitter.info> References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170203224708.A0EE061891C7@rock.dv.isc.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 02:07:15 -0000 Hi, On Sat, Feb 04, 2017 at 09:47:08AM +1100, Mark Andrews wrote: > > Also the ICANN's rule for signed TLD delegation for new gTLD is so > that delegations from those zones can be signed. I don't think that it is up to this WG or even the IETF to make any determinations about why the names community decides the policies it does for the root zone. But in any case, there are two relevant policy issues here: 1. We are not the authority for delegations -- signed, unsigned, emtpy or otherwise -- from the root zone, and if we are going to seek any kind of entry in the actual DNS root zone then we are talking about that in entirely the wrong forum. We maybe should complete the alt draft saying what we want from it, and then insert that into the correctly-shaped receptical at ICANN. 2. Unfortunately for us, right now, there _is_ no such receptical at ICANN. For there does not appear to be an ICANN policy for delegations from the root for special uses. There is a policy for ccTLD additions, but we are not a country. There is no current policy for new gTLDs -- the previous round closed, and there has been no determination of whether a new round will happen nor what that round might entail if it happens. If you want to shape those rules, I believe there are some discussions going on within some constituencies at ICANN. > signed. There is no reason for ICANN to object other than religious > arguments. Technically they don't have a leg to stand on. I'm sorry, but it's not religious. Other communities have rules for establishing their IANA functions. If we want them to respect our rules for the IANA registries for which we set the policy, then we need to respect theirs for the registries for which they set the policy. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Feb 3 18:10:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A892E1295F1 for ; Fri, 3 Feb 2017 18:10:12 -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] 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-qgEMlZmU2e for ; Fri, 3 Feb 2017 18:10:11 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id AA4CB1295F4 for ; Fri, 3 Feb 2017 18:10:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 4ACAD11649 for ; Sat, 4 Feb 2017 02:10:16 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBJKbqCRR6lA for ; Sat, 4 Feb 2017 02:10:15 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id A0B601162D for ; Sat, 4 Feb 2017 02:10:15 +0000 (UTC) Date: Fri, 3 Feb 2017 21:10:09 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170204021009.GE67739@mx2.yitter.info> References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 02:10:13 -0000 On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote: > Mark, I don't think you've actually given an answer to my question. > I understood that .ALT was for alternative naming systems, not for > DNS locally-served zones. We simply need to decide whether or not > that's true. I think either answer is fine; we just need to pick > one. I agree with this. I will say that, when I first started working on this with Warren, it was really for the use-case where people would tread on the namespace as a protocol switch -- we wanted a sandbox in which things like onion could live. My memory is that only after that did we start thinking of a sort of 1918-style part of the DNS as well. That may have been a mistake, since as this discussion is showing the properties of an in-protocol, in-DNS namespace without delegations are somewhat different to alternative-protocol uses that do not rely on the DNS at all. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Feb 3 18:13:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A4C1295F1 for ; Fri, 3 Feb 2017 18:13:58 -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] 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 cbcAM1r255En for ; Fri, 3 Feb 2017 18:13:57 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id DFD6D127735 for ; Fri, 3 Feb 2017 18:13:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 715E711649 for ; Sat, 4 Feb 2017 02:14:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K0eMX3uzdAD for ; Sat, 4 Feb 2017 02:14:00 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id A9ABF1162D for ; Sat, 4 Feb 2017 02:14:00 +0000 (UTC) Date: Fri, 3 Feb 2017 21:13:53 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170204021353.GF67739@mx2.yitter.info> References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 02:13:58 -0000 On Fri, Feb 03, 2017 at 08:54:59PM -0500, Ted Lemon wrote: > On Feb 3, 2017, at 8:51 PM, Andrew Sullivan wrote: > > If the resolver "has a local zone for alt" -- I think this means it is > > authoritative for that zone -- why would it ask the root about it at > > all? > > As long as the stub resolver isn't validating, it's no problem. If it is validating, then the recursive resolver can't fool the stub resolver if there's a secure denial of existence. > Right, that's always been the problem with using this _for the DNS_. Homenet has no choice in that, because the whole point of the homenet name is precisely to enable in-homenet DNS without reference to the global DNS. I think you're quite correct that we need to decide whether alt is to be used for those purposes. I'm not convinced that's so useful. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Feb 3 18:14:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F161295FD for ; Fri, 3 Feb 2017 18:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwtfkaeAqMlo for ; Fri, 3 Feb 2017 18:14:35 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 53DF01295F9 for ; Fri, 3 Feb 2017 18:14:35 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id v23so63353042qtb.0 for ; Fri, 03 Feb 2017 18:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=BVm/pCaXJpMni23ytcOUgFw7DKOlbXrPss3tzoePbII=; b=WqYvp0mPvfBhJ1dzM77j2SZnkepfh45eQh9asRlo6VXbA27ec28GX73/wGlTfv/HtB AM6buSzN2cDatIH/VnZoXweDecREl9SYJ0rf4lbmv+JlSDxtOBuBGY8rGKOD5HJqEojC J0Evy05Y7MNuS4qs7yl6nG8Dz8/rmPS1M2YjYgoP+njslFfFlA8I6fMZfW6BEM0m+mbF bzY3frwMP9ERSmPaMgEhW5HaOQ1+/HEOV68KEb3r1Wfgu0JEUI+isijGduNhtIgBJ4zc jTuDjW6sijfOwQJJYOAgfilpcmEIHkgKC3Jso0DP76sK0qPCYub6nfT/4eptz07hxlk1 km1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=BVm/pCaXJpMni23ytcOUgFw7DKOlbXrPss3tzoePbII=; b=OTwnyNAqvdR1S8qQobNwmluVSy3EEjSmYHodTFTTp+/WNMKO1BGPiYrSuY7txivJ6e HBXnlJjstubg/oWYK8kTDPnfFa/x1K49i7SkbAVgSKu14I0LgMhEWKq/CFoS2V6952HX 3SR3791xdRYOhpMQqgiW1R5nxqtoor2vuQNdpARCWgU3aO+QWfkzqeyc4yV92hXDzX+D wB9FtqKQrV30vGLt7+JjazYC8afQsoDkso1kmOVF5oquy2ni2ipcEYJ+4u5xOLhEnPmc hPqdcVC2/UYlUcIQNFSbXJecNQpeq8++01Y2clHzAwOJXXvovc1rMpov6jeaX7TT+RuV HrYA== X-Gm-Message-State: AMke39l/rL2QCoWDIyQiwlgZESxDg9XPizjYMrHkOYqfEQRVgraB7OhorWkSoqEh4gMghNPWKMV/GvgLQNt1W9up X-Received: by 10.237.63.28 with SMTP id p28mr69447qtf.263.1486174474217; Fri, 03 Feb 2017 18:14:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Fri, 3 Feb 2017 18:14:03 -0800 (PST) In-Reply-To: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Fri, 3 Feb 2017 21:14:03 -0500 Message-ID: To: dnsop Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 02:14:37 -0000 Hi all, Was and I have updated this document to make it clearer and more readable. Please take a read and let us know if any parts are unclear, if you have any other feedback, etc. Is this close to done? W On Fri, Feb 3, 2017 at 6:29 PM, wrote: > > A new version of I-D, draft-hardaker-rfc5011-security-considerations-02.txt > has been successfully submitted by Warren Kumari and posted to the > IETF repository. > > Name: draft-hardaker-rfc5011-security-considerations > Revision: 02 > Title: Security Considerations for RFC5011 Publishers > Document date: 2017-02-02 > Group: Individual Submission > Pages: 8 > URL: https://www.ietf.org/internet-drafts/draft-hardaker-rfc5011-security-considerations-02.txt > Status: https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/ > Htmlized: https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-hardaker-rfc5011-security-considerations-02 > > Abstract: > This document describes the math behind the minimum time-length that > a DNS zone publisher must wait before using a new DNSKEY to sign > records when supporting the RFC5011 rollover strategies. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Feb 3 18:16:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F81B1295EF for ; Fri, 3 Feb 2017 18:16:23 -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] 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 BN2Vr1r_SRka for ; Fri, 3 Feb 2017 18:16:21 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id CD5F912952F for ; Fri, 3 Feb 2017 18:16:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 736C511649 for ; Sat, 4 Feb 2017 02:16:26 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8K2WHs1vNW8 for ; Sat, 4 Feb 2017 02:16:25 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id BC3231162D for ; Sat, 4 Feb 2017 02:16:25 +0000 (UTC) Date: Fri, 3 Feb 2017 21:16:19 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170204021619.GG67739@mx2.yitter.info> References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 02:16:23 -0000 On Fri, Feb 03, 2017 at 08:58:43PM -0500, George Michaelson wrote: > sorry to be thick, but.. can we have both on a case-by-case basis somehow? Well, if the stub that is going to query in this namespace _knows_ that it's special, then it also knows not to validate it too. So that's not a problematic case, and the provable denial of existence from the root isn't an issue. So the only question is whether this has to work properly for any random resolver doing normal operations -- is this like RFC 1918 for the DNS? If we want that (and for homenet, for instance, that's basically the use case) then we have a problem. But if we don't think that's necessary -- and I'm not sure it is -- then we don't have to care about this. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Feb 3 18:40:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A3E1294C6 for ; Fri, 3 Feb 2017 18:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MREUn3-2Pxx for ; Fri, 3 Feb 2017 18:40:37 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 CE2D6129495 for ; Fri, 3 Feb 2017 18:40:36 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s140so9025289qke.0 for ; Fri, 03 Feb 2017 18:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xKm5a1vLNkTMYkz3zXpE/FbdUjL4fYSqEA9vDmbM/b0=; b=bz/Q8Sxz06RX88h4hOG0Os2RyUZk0EjgkLOgCLW+41zKPOn4LBhRL+C4oqWXky0SLE v9X9p1lcPYsB2IKkYGnfOflvCPAb7rOzI8oN4yrX7loKeAEh0Oby0fJ0Xz1Y7g+Ewh0j EopMQlaNgR5UQAwgsG4/CY1q0XEM5An1AcrnUMnL4QcDfTV2NrNXIr+v+FJE/+ozKhuZ PeKVQm8NHCgCwbXUljuafzhwfz+2bdHrOtx9UcxoClGSKcVflvGbFqoTb3WTKi3Ydc6v jOfQOCkPGoUgzS9eyv7W6cWysUue/JMOrMFgznqpZSMJjLSX/JsfQtjBRSRnaIM9B2HG a8OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xKm5a1vLNkTMYkz3zXpE/FbdUjL4fYSqEA9vDmbM/b0=; b=kKR182O+RaRJxMu403e9biOKhAViGOQE2xub9hlRb5hqNkYMgxWMxPqUe1CuxnxiDZ Cw6c4QIhlurZT+hl+SNRZxRriZIbmkEnCSKR5h0ZPvd/MDNu5/BKCkN6wtdZiqzuCQbq BslBdM9f/73TTVUEg5BVX0OizSFq+mpHCCFPb9GypSpYasuNmTO+yQa3PzZf2Yhly6TB OAhPDYn50rvgNQRXWTDVeDkslG/Ce9EMkkhDJ6PpLqOLKQcB6xMzP5SAO3l8V7quUnem ckFLqVX3ASYC6FvnrrbJcCPW66turgAqHO4gspvZGvaStfeX5W++e6h79ufp6PsfMVW8 hrfA== X-Gm-Message-State: AMke39nHdwkbMEz/zanYLKc5uvVC+N2wsbogcMmJbi272cyNKqk39bOwcSbqPCR9qCssRw== X-Received: by 10.55.154.204 with SMTP id c195mr121675qke.293.1486176035599; Fri, 03 Feb 2017 18:40:35 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id b16sm26245594qka.9.2017.02.03.18.40.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 18:40:34 -0800 (PST) From: Ted Lemon Message-Id: <88686BFE-7874-4EB4-8E04-FF68DFB51F94@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_95F6D11E-900F-4A32-AF49-57EF2CB4397E" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 3 Feb 2017 21:40:32 -0500 In-Reply-To: <20170204021009.GE67739@mx2.yitter.info> To: Andrew Sullivan References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> <20170204021009.GE67739@mx2.yitter.info> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 02:40:38 -0000 --Apple-Mail=_95F6D11E-900F-4A32-AF49-57EF2CB4397E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 3, 2017, at 9:10 PM, Andrew Sullivan = wrote: > My memory is that only after that > did we start thinking of a sort of 1918-style part of the DNS as > well. That may have been a mistake, since as this discussion is > showing the properties of an in-protocol, in-DNS namespace without > delegations are somewhat different to alternative-protocol uses that > do not rely on the DNS at all. I think that we've seen a number of questions go by that lead to the = conclusion that it makes sense to have two hierarchies: one for = experimental non-DNS queries, and one for locally served zones. I = don't know if we _need_ the .LSZ (or whatever) SUTLDN, but if we need to = be able to have a special-use top-level domain name that has an = un-signed delegation, it probably ought to be different than the SUTLDN = that is used for non-DNS stuff, so that both names can have the = appropriate configuration in the root zone. --Apple-Mail=_95F6D11E-900F-4A32-AF49-57EF2CB4397E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 3, 2017, at 9:10 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
My memory is that = only after that
did we start thinking of a sort of = 1918-style part of the DNS as
well.  That may have been a = mistake, since as this discussion is
showing the properties of an = in-protocol, in-DNS namespace without
delegations are somewhat = different to alternative-protocol uses that
do not rely on the DNS at all.

I = think that we've seen a number of questions go by that lead to the = conclusion that it makes sense to have two hierarchies: one for = experimental non-DNS queries, and one for locally served zones.   I = don't know if we _need_ the .LSZ (or whatever) SUTLDN, but if we need to = be able to have a special-use top-level domain name that has an = un-signed delegation, it probably ought to be different than the SUTLDN = that is used for non-DNS stuff, so that both names can have the = appropriate configuration in the root zone.

= --Apple-Mail=_95F6D11E-900F-4A32-AF49-57EF2CB4397E-- From nobody Sat Feb 4 00:05:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45E21293DF for ; Sat, 4 Feb 2017 00:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 xs6DATEF5Z8c for ; Sat, 4 Feb 2017 00:05:05 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3461293DC for ; Sat, 4 Feb 2017 00:05:05 -0800 (PST) Received: from [192.165.72.121] (unknown [IPv6:2a02:80:3ffc:0:59ec:5c38:18a5:a0c3]) by mail.frobbit.se (Postfix) with ESMTPSA id 9928A2352D; Sat, 4 Feb 2017 09:05:00 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Andrew Sullivan" Date: Sat, 04 Feb 2017 09:05:00 +0100 Message-ID: <6CA33DCA-29B5-4BEF-8E9F-E93CE7115186@frobbit.se> In-Reply-To: <20170204015722.GC67739@mx2.yitter.info> References: <5FD13D0D-57DE-4CED-B1A2-C823079B8D63@gmail.com> <74796240-46DA-4C8B-A715-DBC521EFA3F3@gmail.com> <20170204015722.GC67739@mx2.yitter.info> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_CA5ECBA3-A276-4E11-8171-C6EA158F0692_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6076) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 08:05:06 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_CA5ECBA3-A276-4E11-8171-C6EA158F0692_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 4 Feb 2017, at 2:57, Andrew Sullivan wrote: > On Fri, Feb 03, 2017 at 12:21:16PM -0800, Steve Crocker wrote: > >> And just to stir the pot a bit, what would you have ICANN do if someon= e applies for .alt as a top level domain? Is it ok if we say yes and del= egate the name? If not, what is the basis for us to say no? > > If alt ends up in the 6761 special-use names registry, that seems a > reason for ICANN not to delegate the name. For adding something to > the 6761 special-use names registry removes it from the possible pool > of names that can be in the root zone. This would be my suggestion. What worries me is not names in 6761 special-use names registry but other= names ICANN "should not" add to the root zone. paf --=_MailMate_CA5ECBA3-A276-4E11-8171-C6EA158F0692_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAliViywACgkQrMabGguI180amQCffm63r2chbTQYhm+QzRLLg6mQ py8AnRRHd42IF+Eg2XBWIq98Oz3nIuDH =bI0G -----END PGP SIGNATURE----- --=_MailMate_CA5ECBA3-A276-4E11-8171-C6EA158F0692_=-- From nobody Sat Feb 4 01:46:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C6E12961C for ; Sat, 4 Feb 2017 01:46: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 zkb4mJaLVuMW for ; Sat, 4 Feb 2017 01:46:19 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D62912957A for ; Sat, 4 Feb 2017 01:46:18 -0800 (PST) Received: from [46.227.151.81] (port=62904 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1cZwvA-0004fg-2b (Exim 4.72) for dnsop@ietf.org (return-path ); Sat, 04 Feb 2017 09:46:16 +0000 References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> <20170204021353.GF67739@mx2.yitter.info> To: dnsop From: Ray Bellis Message-ID: <0c9ea76d-a541-943a-d72e-bfe255d57259@bellis.me.uk> Date: Sat, 4 Feb 2017 09:46:15 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170204021353.GF67739@mx2.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 09:46:21 -0000 On 04/02/2017 02:13, Andrew Sullivan wrote: > Right, that's always been the problem with using this _for the DNS_. > Homenet has no choice in that, because the whole point of the homenet > name is precisely to enable in-homenet DNS without reference to the > global DNS. I think you're quite correct that we need to decide > whether alt is to be used for those purposes. I'm not convinced > that's so useful. If it turns out that we can't get the insecure delegation that we need for .homenet, then I'd (personally) be reasonably happy with .homenet.alt, except that the current proposals for the use of .alt wouldn't seem to permit that. Ray From nobody Sat Feb 4 03:14:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB23D129614 for ; Sat, 4 Feb 2017 03:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 fbUOrf-Q3ESB for ; Sat, 4 Feb 2017 03:14:02 -0800 (PST) Received: from shannon.7bits.nl (shannon.7bits.nl [89.188.0.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80ABB127601 for ; Sat, 4 Feb 2017 03:14:02 -0800 (PST) Received: from [192.168.137.1] (unknown [IPv6:2001:67c:1810:f051:a8d5:c8c3:ebeb:3cd9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 410F2C1B96; Sat, 4 Feb 2017 12:14:00 +0100 (CET) From: "Peter van Dijk" To: dns-operations@dns-oarc.net, dnsop , dns-wg@ripe.net Date: Sat, 04 Feb 2017 12:14:06 +0100 Message-ID: <03975D05-EC25-423E-B32B-EB4FDC872EF2@powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate (1.9.6r5319) Archived-At: Subject: [DNSOP] DNS BoF at FOSDEM, Sunday X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 11:14:04 -0000 Hello DNS people! For those of you attending FOSDEM, we have reserved room H.3227 for Sunday(!) 13:00-14:00, to hold a DNS BoF. There is no agenda yet; please suggest items by private reply. If you are at FOSDEM, or if you know anyone who is, please make sure they know! If you think I missed a mailing list, please forward this message. If you need to reach me, please use +31-6-10908570. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Sat Feb 4 05:26:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032B5129A65 for ; Sat, 4 Feb 2017 05:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 DdD-pEN8totC for ; Sat, 4 Feb 2017 05:26:18 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C77129A61 for ; Sat, 4 Feb 2017 05:26:18 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id A23DC1FCAB6; Sat, 4 Feb 2017 13:26:13 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6B029160043; Sat, 4 Feb 2017 13:26:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5103116006E; Sat, 4 Feb 2017 13:26:12 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7HwqiZU0AzRd; Sat, 4 Feb 2017 13:26:12 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9F84D160043; Sat, 4 Feb 2017 13:26:11 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 49806618F0F5; Sun, 5 Feb 2017 00:26:08 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <20170204020711.GD67739@mx2.yitter.info> In-reply-to: Your message of "Fri, 03 Feb 2017 21:07:11 -0500." <20170204020711.GD67739@mx2.yitter.info> Date: Sun, 05 Feb 2017 00:26:08 +1100 Message-Id: <20170204132608.49806618F0F5@rock.dv.isc.org> Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 13:26:20 -0000 In message <20170204020711.GD67739@mx2.yitter.info>, Andrew Sullivan writes: > Hi, > > On Sat, Feb 04, 2017 at 09:47:08AM +1100, Mark Andrews wrote: > > > > Also the ICANN's rule for signed TLD delegation for new gTLD is so > > that delegations from those zones can be signed. > > I don't think that it is up to this WG or even the IETF to make any > determinations about why the names community decides the policies it > does for the root zone. But in any case, there are two relevant > policy issues here: > > 1. We are not the authority for delegations -- signed, unsigned, > emtpy or otherwise -- from the root zone, and if we are going to > seek any kind of entry in the actual DNS root zone then we are > talking about that in entirely the wrong forum. We maybe should > complete the alt draft saying what we want from it, and then > insert that into the correctly-shaped receptical at ICANN. > > 2. Unfortunately for us, right now, there _is_ no such receptical > at ICANN. For there does not appear to be an ICANN policy for > delegations from the root for special uses. There is a policy for > ccTLD additions, but we are not a country. There is no current > policy for new gTLDs -- the previous round closed, and there has > been no determination of whether a new round will happen nor what > that round might entail if it happens. If you want to shape those > rules, I believe there are some discussions going on within some > constituencies at ICANN. > > > signed. There is no reason for ICANN to object other than religious > > arguments. Technically they don't have a leg to stand on. > > I'm sorry, but it's not religious. Other communities have rules for > establishing their IANA functions. If we want them to respect our > rules for the IANA registries for which we set the policy, then we > need to respect theirs for the registries for which they set the > policy. Given there are no rules for this type of namespace we need to respect the reasons for the other rules which I did but you choose to completely cut out of the reply. This isn't a registry. It's a non-registry. It is different. Mark > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Feb 4 05:29:52 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EC5129A65 for ; Sat, 4 Feb 2017 05:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 ZL6D2CkpQYiT for ; Sat, 4 Feb 2017 05:29:49 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6AC129A61 for ; Sat, 4 Feb 2017 05:29:49 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 21FF23493BC; Sat, 4 Feb 2017 13:29:47 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 101AE160043; Sat, 4 Feb 2017 13:29:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E3B1916006E; Sat, 4 Feb 2017 13:29:46 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6muzbGkJZcvl; Sat, 4 Feb 2017 13:29:46 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 44D56160043; Sat, 4 Feb 2017 13:29:46 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 45609618F1BA; Sun, 5 Feb 2017 00:29:43 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> <20170204021353.GF67739@mx2.yitter.info> In-reply-to: Your message of "Fri, 03 Feb 2017 21:13:53 -0500." <20170204021353.GF67739@mx2.yitter.info> Date: Sun, 05 Feb 2017 00:29:43 +1100 Message-Id: <20170204132943.45609618F1BA@rock.dv.isc.org> Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 13:29:50 -0000 In message <20170204021353.GF67739@mx2.yitter.info>, Andrew Sullivan writes: > On Fri, Feb 03, 2017 at 08:54:59PM -0500, Ted Lemon wrote: > > On Feb 3, 2017, at 8:51 PM, Andrew Sullivan wrote: > > > If the resolver "has a local zone for alt" -- I think this means it is > > > authoritative for that zone -- why would it ask the root about it at > > > all? > > > > As long as the stub resolver isn't validating, it's no problem. If it is validating, t > hen the recursive resolver can't fool the stub resolver if there's a secure denial of ex > istence. > > > > Right, that's always been the problem with using this _for the DNS_. > Homenet has no choice in that, because the whole point of the homenet > name is precisely to enable in-homenet DNS without reference to the > global DNS. I think you're quite correct that we need to decide > whether alt is to be used for those purposes. I'm not convinced > that's so useful. It's a problem for ALL special names. BOGUS / SERVFAIL isn't the response leaked names should get. Its bad engineering. > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Feb 4 05:45:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9F3129634 for ; Sat, 4 Feb 2017 05:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_Cmayq_g51F for ; Sat, 4 Feb 2017 05:45:28 -0800 (PST) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 2C478129A86 for ; Sat, 4 Feb 2017 05:45:28 -0800 (PST) Received: by mail-qk0-x244.google.com with SMTP id u25so2473106qki.2 for ; Sat, 04 Feb 2017 05:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=UbICaGcK8Cw23PMEp8cAR+mZNw0qOe+f1rbx9M58fRQ=; b=T/BiK2YLVkwIMvBB2oQuZ5Y8uBX8Os64/pWHIOZZcwaV0As7ssGYpMySM5S6puf5uP l6c19L5tVKlj4sAZ3bBo3lVYecvlbXjN8RWVLQHSX5GcMKbrgzdszstsPEw3abXrvl82 7Jt/MLfEprEFSsBcXHl7fXcHLWW51jcNcNfIA9NsuxUTkp2tFPF8ev1KVz4vivB9YwYk 3wT6+WwpK95TrTZrlyG2yHst1mBtDUNUAAtIO9lVolm+Q8khAV8mZU+Z02A6RdkkeorM 2KJQoRlIUmcvFmx623m4AjA7vgALNIXsx/7ZH0bfFCTHeWMqimeYcMvY1NvqZ+qE+V0s q0EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UbICaGcK8Cw23PMEp8cAR+mZNw0qOe+f1rbx9M58fRQ=; b=SHaCUBKyzgyoIWU6/7KspKA3qK9I/1d89aYIoN4dHBsyZllvKkn1s4Dd/8uVez/fmc kgqtp7JnZ1T+2X3LBuvD/wH69twOmc4Mvk0lp71C6T+Fropti4SgoOIrm45lFRyl6tPM m/70IYu/LbRzNL6IEpBMP43y5EZQ9wAnh0bTPs828gMmH26LPZ5QNLDBEyqQzTNM1uw8 KAHhqBR35g+fCjpmvOf+2+Ny9QbFWMDuga+b1zyKuyMIbhhs2UyDyPRjE1rZKC4WB0Qf 1O1VfRZMvTtkvszUzDX9oU6AMN5VbnDuwbmC3ELauDhicYRar5tHWjdpP42dga1+CrBd gU4g== X-Gm-Message-State: AMke39kf8xF05UwwQikocJzzD7jzpLW9QxnWJs+nzne1FCnnqFGn2PFsRWPyyWfs4fCLKg== X-Received: by 10.55.104.79 with SMTP id d76mr2159559qkc.114.1486215927042; Sat, 04 Feb 2017 05:45:27 -0800 (PST) Received: from [10.0.0.19] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by smtp.gmail.com with ESMTPSA id k19sm27511113qtf.37.2017.02.04.05.45.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 04 Feb 2017 05:45:26 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_99A4C4ED-23E3-4594-914D-F0D23791BCA4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <88686BFE-7874-4EB4-8E04-FF68DFB51F94@fugue.com> Date: Sat, 4 Feb 2017 08:45:23 -0500 Message-Id: <81B466E3-D82D-4DC0-8307-23DC3236D3C5@gmail.com> References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> <20170204021009.GE67739@mx2.yitter.info> <88686BFE-7874-4EB4-8E04-FF68DFB51F94@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dnsop@ietf.org, Andrew Sullivan Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 13:45:30 -0000 --Apple-Mail=_99A4C4ED-23E3-4594-914D-F0D23791BCA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 3, 2017, at 9:40 PM, Ted Lemon wrote: >=20 > On Feb 3, 2017, at 9:10 PM, Andrew Sullivan > wrote: >> My memory is that only after that >> did we start thinking of a sort of 1918-style part of the DNS as >> well. That may have been a mistake, since as this discussion is >> showing the properties of an in-protocol, in-DNS namespace without >> delegations are somewhat different to alternative-protocol uses that >> do not rely on the DNS at all. >=20 > I think that we've seen a number of questions go by that lead to the = conclusion that it makes sense to have two hierarchies: one for = experimental non-DNS queries, and one for locally served zones. I = don't know if we _need_ the .LSZ (or whatever) SUTLDN, but if we need to = be able to have a special-use top-level domain name that has an = un-signed delegation, it probably ought to be different than the SUTLDN = that is used for non-DNS stuff, so that both names can have the = appropriate configuration in the root zone. We may be making this harder than it has to be. It=E2=80=99s worth noting at this point that the "1918-style part of the = DNS=E2=80=9D (DNSSEC compatibility for names intended to be locally = resolved with the DNS protocol) is a solved problem, if you mean it = literally: they=E2=80=99re under .arpa. This was an obvious solution for address blocks, since in-addr.arpa was = already established by the protocol for PTR records and .arpa was = already administered under IETF rules. However, in terms of the desired behavior all the parts are there: .arpa = is a signed zone, can have signed or unsigned delegations for names = intended to be resolvable in the DNS (locally or globally), and is = administered under IETF rules that include *not* delegating special use = names under it that shouldn=E2=80=99t be in the DNS (I don=E2=80=99t see = the IAB having a problem with making a commitment that a specific string = won=E2=80=99t be delegated). The objections to .home.arpa were to the specific string =E2=80=9C.arpa=E2= =80=9D and that it wasn=E2=80=99t a single-label name, which seemed to = be strong preferences but I=E2=80=99m not sure were ever documented as = hard (=E2=80=9Cit won=E2=80=99t work otherwise=E2=80=9D) requirements. = For other special use names, they might very well not be constraints. Having already decided that =E2=80=9Csingle label=E2=80=9D is a tough = constraint to maintain if you want an unsigned delegation from a signed = zone (i.e. an unsigned TLD in the root), I=E2=80=99m not sure I see a = major difference between mystring.alt and mystring.arpa. Suzanne --Apple-Mail=_99A4C4ED-23E3-4594-914D-F0D23791BCA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 3, 2017, at 9:40 PM, Ted Lemon <mellon@fugue.com> = wrote:

On Feb 3, = 2017, at 9:10 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
My memory is that only after that
did we start thinking of a sort of 1918-style = part of the DNS as
well.  That may have been a mistake, = since as this discussion is
showing the properties of an = in-protocol, in-DNS namespace without
delegations are somewhat = different to alternative-protocol uses that
do not rely on the DNS at all.

I = think that we've seen a number of questions go by that lead to the = conclusion that it makes sense to have two hierarchies: one for = experimental non-DNS queries, and one for locally served zones.   I = don't know if we _need_ the .LSZ (or whatever) SUTLDN, but if we need to = be able to have a special-use top-level domain name that has an = un-signed delegation, it probably ought to be different than the SUTLDN = that is used for non-DNS stuff, so that both names can have the = appropriate configuration in the root = zone.

We may be = making this harder than it has to be.

It=E2=80=99s worth noting at this point that the = "1918-style part of the DNS=E2=80=9D (DNSSEC compatibility for names = intended to be locally resolved with the DNS protocol) is a solved = problem, if you mean it literally: they=E2=80=99re under = .arpa.

This was an obvious solution = for address blocks, since in-addr.arpa was already established by the = protocol for PTR records and .arpa was already administered under IETF = rules.

However, in terms of the = desired behavior all the parts are there: .arpa is a signed zone, can = have signed or unsigned delegations for names intended to be resolvable = in the DNS (locally or globally), and is administered under IETF rules = that include *not* delegating special use names under it that = shouldn=E2=80=99t be in the DNS (I don=E2=80=99t see the IAB having a = problem with making a commitment that a specific string won=E2=80=99t be = delegated).

The objections to = .home.arpa were to the specific string =E2=80=9C.arpa=E2=80=9D and that = it wasn=E2=80=99t a single-label name, which seemed to be strong = preferences but I=E2=80=99m not sure were ever documented as hard (=E2=80=9C= it won=E2=80=99t work otherwise=E2=80=9D) requirements. For other = special use names, they might very well not be = constraints.

Having already decided = that =E2=80=9Csingle label=E2=80=9D is a tough constraint to maintain if = you want an unsigned delegation from a signed zone (i.e. an unsigned TLD = in the root), I=E2=80=99m not sure I see a major difference between = mystring.alt and mystring.arpa.


Suzanne


= --Apple-Mail=_99A4C4ED-23E3-4594-914D-F0D23791BCA4-- From nobody Sat Feb 4 06:13:06 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2E2129ADF for ; Sat, 4 Feb 2017 06:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PADNhdPdBDwa for ; Sat, 4 Feb 2017 06:13:04 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 37E69129ADE for ; Sat, 4 Feb 2017 06:13:04 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id 11so17377650qkl.3 for ; Sat, 04 Feb 2017 06:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HexFQvrx1ze3eCgdSewL6tJVrGYQijwcQrBfbJFl4Yw=; b=0PDe3u4HFFen8TXMspMN1AXBy4DXXWZihkXjsg2N/KG+vPccK00TiXM7/XF79PZjxC yGBveoapJjxLf7Lci+LQyD5y2ihLea8JUB/T49kn7bLtf3y9Vvl+Hqv5qxUJBmJvTmah fZsxWO+MQcqmcD3BCWgWvDVgSNwmv13CxXEtmhtnKKwed3vKm6TuMfDuryZh9FAfZwK1 g+9aRPmr087AB0rxxY2Kn0hV7AwaZZ3BkND8jpozVU5MDEbZFhT4ccOqxz9bBcb1jI9Y LHSgkoig+CGVV0HRdcMVikZfp3MH5KK60umaQbu8F0LOAX72rkJLvEQDi9n+Ah7fLaTG ZyEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HexFQvrx1ze3eCgdSewL6tJVrGYQijwcQrBfbJFl4Yw=; b=q60oPPgeXurfB6COfWjM86QDebiWJr5oZcVeGcCeJ3rmXirbuRUWIpD9u+1TxHplXT L84Kbr8waaLTTeVlWUGOJSaizUG0s9ICmlOV2NK+UVMo8oSP2mENMS8h/fQSuaLJ3Z9T 1LudiJkoEIBcXNaWNzfjM3/hXOu7iD5jbYTK1gla1EAxi8FW+OFb2ZeG5OZgBHniYhS/ hHcRQPY8zrUnwZyN9Ab9tf4l73q1Uf/hETlaFPil7xqFkko3Fsq3xsQCFLuH33TmTMSv UuaHBNGBUDlEgn8+VFvHPgoFITKpSOW+CAOkUGeFGPqaOrVDB+93pb+KSpexRq3ES6Wx x41g== X-Gm-Message-State: AMke39k1Bwn5QOeTKBWql+KfeUzKyAmR2g5QpZdsFkiqqP2cYGj908mVMmAy5ObfK+fhaA== X-Received: by 10.233.220.134 with SMTP id q128mr1857368qkf.220.1486217583277; Sat, 04 Feb 2017 06:13:03 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 34sm27704264qtx.16.2017.02.04.06.13.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Feb 2017 06:13:02 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E4D645E3-544F-4498-8DE8-35B3A2664276" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sat, 4 Feb 2017 09:13:00 -0500 In-Reply-To: <0c9ea76d-a541-943a-d72e-bfe255d57259@bellis.me.uk> To: Ray Bellis References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> <20170204021353.GF67739@mx2.yitter.info> <0c9ea76d-a541-943a-d72e-bfe255d57259@bellis.me.uk> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 14:13:05 -0000 --Apple-Mail=_E4D645E3-544F-4498-8DE8-35B3A2664276 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 4, 2017, at 4:46 AM, Ray Bellis wrote: > If it turns out that we can't get the insecure delegation that we need > for .homenet, then I'd (personally) be reasonably happy with > .homenet.alt, except that the current proposals for the use of .alt > wouldn't seem to permit that. .alt doesn't allow for reserved allocations, so I don't think this would = fly. Also, there won't be a .alt zone (correct me if I am wrong), so = it doesn't actually solve the problem. --Apple-Mail=_E4D645E3-544F-4498-8DE8-35B3A2664276 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 4, 2017, at 4:46 AM, Ray Bellis <ray@bellis.me.uk> = wrote:
If it turns out that we can't get the insecure = delegation that we need
for .homenet, then I'd (personally) be = reasonably happy with
.homenet.alt, except that the current = proposals for the use of .alt
wouldn't seem to permit = that.

.alt = doesn't allow for reserved allocations, so I don't think this would fly. =   Also, there won't be a .alt zone (correct me if I am wrong), so = it doesn't actually solve the problem.

= --Apple-Mail=_E4D645E3-544F-4498-8DE8-35B3A2664276-- From nobody Sat Feb 4 06:14:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D185129AF3 for ; Sat, 4 Feb 2017 06:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59fYv-kQEvZa for ; Sat, 4 Feb 2017 06:14:24 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 38E91129AEE for ; Sat, 4 Feb 2017 06:14:24 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id x49so70849981qtc.2 for ; Sat, 04 Feb 2017 06:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OUO5hFTksGmBo01bZLxs3oEKc5LC9Kj6uHHBBSALc/I=; b=ZyePmuRMR8Yr560DaxsabJUmQw0rkaX2ijHhG+KYf4YZb7Vu9R/S8BkR8U/FbD+sfa 7rBcFsypnBMmiQlZ4YdyH46mrD0cHcUp9S9ELz99xC0STcfYMyvMorn5QY7feGlVZVCC f3/Ys6ytQ5BFQbdT2CEW7vLdC5oxjT5LHDM9MihGUSiRiSiJrHWKdMUMTbwRCPiLtZYo 0Y1S7IyWB8Pb6s+qZ9Heb9MH+WwKKxCsWwEZSKvp3sxMfLcpXk5HhiEJAghJK1WFpAQ9 mH0BaqB6ffORikLVwLGRlqF6HndVsLKm+I1d3CaGrZLQOptQ2NKb457f7MdcyaSMerqz CXTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OUO5hFTksGmBo01bZLxs3oEKc5LC9Kj6uHHBBSALc/I=; b=GWtYlMXw3PaOLARXbkiUKvTMA/qBsYBQBRh5tVnOKQpiv/RvGT4bpOhUH6o6otoEgL Ay6XeiSPRINbwM2+wMWviquFiMxQUwoyzvxuhh0PAgYja57XK4sNFTbJ6nvC13XTwNye 5TXdevQlt+EOJ3mrAjRgX2Q34a5ND/HfRMlducRvHA38+JxwH1nRy/oQ1jkRk7Azkp16 5Q//cfdJ43B8YBcJgKagRlk7tTcC8YUUlGrjpHqsPxa2MCC38sDiL44zY5lYwZyKbXU1 1bN9fYxgLWw2gJmRheuhPy/VE2Wv1apYW76apr6RRVZidjKAygwXrnC2DyaaS3zlP8i2 3pzw== X-Gm-Message-State: AMke39nnSDBM3m44r6AmOn40L6/YuushSoZHXtQgDwYrbOLqHlcFueiKIjgPz0Rd7jwJOA== X-Received: by 10.200.49.249 with SMTP id i54mr2082355qte.3.1486217663365; Sat, 04 Feb 2017 06:14:23 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id y194sm6165859qkb.2.2017.02.04.06.14.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Feb 2017 06:14:22 -0800 (PST) From: Ted Lemon Message-Id: <9920BDF2-E676-4262-9226-46652896E2EF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7E187897-6E02-4FB8-A4AB-587AE13B7686" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sat, 4 Feb 2017 09:14:21 -0500 In-Reply-To: <20170204132943.45609618F1BA@rock.dv.isc.org> To: Mark Andrews References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> <20170204021353.GF67739@mx2.yitter.info> <20170204132943.45609618F1BA@rock.dv.isc.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop@ietf.org, Andrew Sullivan Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 14:14:25 -0000 --Apple-Mail=_7E187897-6E02-4FB8-A4AB-587AE13B7686 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 4, 2017, at 8:29 AM, Mark Andrews wrote: >=20 > It's a problem for ALL special names. BOGUS / SERVFAIL isn't the > response leaked names should get. Its bad engineering. What is the response leaked names should get, and why is that the = correct response? Why is SERVFAIL not the correct response? --Apple-Mail=_7E187897-6E02-4FB8-A4AB-587AE13B7686 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 4, 2017, at 8:29 AM, Mark Andrews <marka@isc.org> wrote:

It's a problem for ALL special names. =  BOGUS / SERVFAIL isn't the
response leaked names should = get.  Its bad engineering.

What is the response leaked names should get, and why is that = the correct response?   Why is SERVFAIL not the correct = response?

= --Apple-Mail=_7E187897-6E02-4FB8-A4AB-587AE13B7686-- From nobody Sat Feb 4 06:44:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD37129B2B for ; Sat, 4 Feb 2017 06:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 wbrL71Rms18P for ; Sat, 4 Feb 2017 06:44:05 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72256129AF0 for ; Sat, 4 Feb 2017 06:44:05 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 8A3531FCAB6; Sat, 4 Feb 2017 14:43:57 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 42E5C160043; Sat, 4 Feb 2017 14:43:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2D46116006E; Sat, 4 Feb 2017 14:43:56 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J3kY91iy0_Tj; Sat, 4 Feb 2017 14:43:56 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 989A4160043; Sat, 4 Feb 2017 14:43:55 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9DF03618FE71; Sun, 5 Feb 2017 01:43:51 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> <20170204021353.GF67739@mx2.yitter.info> <20170204132943.45609618F1BA@rock.dv.isc.org> <9920BDF2-E676-4262-9226-46652896E2EF@fugue.com> In-reply-to: Your message of "Sat, 04 Feb 2017 09:14:21 -0500." <9920BDF2-E676-4262-9226-46652896E2EF@fugue.com> Date: Sun, 05 Feb 2017 01:43:51 +1100 Message-Id: <20170204144351.9DF03618FE71@rock.dv.isc.org> Archived-At: Cc: dnsop@ietf.org, Andrew Sullivan Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 14:44:06 -0000 In message <9920BDF2-E676-4262-9226-46652896E2EF@fugue.com>, Ted Lemon writes: > > On Feb 4, 2017, at 8:29 AM, Mark Andrews wrote: > > > > It's a problem for ALL special names. BOGUS / SERVFAIL isn't the > > response leaked names should get. Its bad engineering. > > What is the response leaked names should get, and why is that the correct > response? Why is SERVFAIL not the correct response? SERVFAIL indicates something went wrong. Clients try alternative servers on SERVFAIL. It isn't a property of the name. It the property of a server when looking up the name. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Feb 4 13:55:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C362129474 for ; Sat, 4 Feb 2017 13:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ6hCDFUor_Y for ; Sat, 4 Feb 2017 13:55:37 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 8BB1F129407 for ; Sat, 4 Feb 2017 13:55:37 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id x49so76369060qtc.2 for ; Sat, 04 Feb 2017 13:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=edlHKn7ZH+0JqORnbZd6d40YTvSNCbCSRYCPP8B6GPk=; b=Lp4Y6jb6GSFy5+l2v96VN13mN5IG/xcItY+DgFE2jZS5Eclk8pTiyPlgI33cEF9L1P 4LHphqM2184FQ9XCWfK1h8FuISq40IZXkcyxKQqP6O5Zfk+gvtYMCtcCoWekEMAxCRu1 FHaQtkMdQUcxtwBvIgmXtO/shw7OgqpVWLAWbxSbrAT6YtZGlyp7/m8FHp4I5ropVoF7 4S+hjqmYxj4qeSgJC7XBxpAci4tIDPKSPV9mCunhO2WLSdp0sDWSTP66gpRqwL/xFFdd FLHyEC6j30T1IJyrWppjdkkqOY6bQXmrKMxenkLqwJVzCyYUWRMzmpNDXh++kl3Zspb0 /J6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=edlHKn7ZH+0JqORnbZd6d40YTvSNCbCSRYCPP8B6GPk=; b=LiaQk7Hi73A8vRpkswV24mKlUK2TeIX1qjNMJXIuZ1qMu/NzosN9Kr9Ok+DV2Bn//g cmkz/cuZqnK7YkHqT9Iytkir6pleRhkKluukn5roHhv7eUBsHq2fktI9wVslT08I0qSg Dc29+omKoQPb1pznXhrN/EVuxdYIBia6cDPtG5FQtMyOtNsFSkptMfBtqixYEHIy05Dk qZwM+1Yxfe8VMO/mRM+TNPMndybRImVtemi6NUHlx//C2q+i6OSYb105JKdE7/0hhHn0 BE4ycbfFVspQjIbJu/oVohBVKVOPv5Zq8rN/oKWKljvakyFuG9TloR9j31OwcvyP/kMr AI4w== X-Gm-Message-State: AMke39mVXd1HYU0yQ2iA8zVW8U9oFQhADlR/1CV0NdfOBvn28TeXNINaHBvlkU/0JjJbQQ== X-Received: by 10.200.53.150 with SMTP id k22mr3569032qtb.19.1486245336558; Sat, 04 Feb 2017 13:55:36 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:24fd:1553:27e9:219? ([2601:181:c381:c20:24fd:1553:27e9:219]) by smtp.gmail.com with ESMTPSA id d15sm28557245qtg.22.2017.02.04.13.55.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 04 Feb 2017 13:55:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <0c9ea76d-a541-943a-d72e-bfe255d57259@bellis.me.uk> Date: Sat, 4 Feb 2017 16:55:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> <20170204021353.GF67739@mx2.yitter.info> <0c9ea76d-a541-943a-d72e-bfe255d57259@bellis.me.uk> To: Ray Bellis X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 21:55:39 -0000 > On Feb 4, 2017, at 4:46 AM, Ray Bellis wrote: >=20 >=20 >=20 > On 04/02/2017 02:13, Andrew Sullivan wrote: >> Right, that's always been the problem with using this _for the DNS_. >> Homenet has no choice in that, because the whole point of the homenet >> name is precisely to enable in-homenet DNS without reference to the >> global DNS. I think you're quite correct that we need to decide >> whether alt is to be used for those purposes. I'm not convinced >> that's so useful. >=20 > If it turns out that we can't get the insecure delegation that we need > for .homenet, then I'd (personally) be reasonably happy with > .homenet.alt, except that the current proposals for the use of .alt > wouldn't seem to permit that. The other question to keep in mind, perhaps particularly for HOMENET, is = how long are you/we willing to wait? The IETF has no process for requesting a change to the root zone (it=E2=80= =99s not one of the protocol parameter registries under the change = control of the IETF) and ICANN has no process for evaluating such a = request.. Generallly when iCANN is asked to do something for which they have no = process, their answer is Yes; No; or =E2=80=9CWe have to think about = that,=E2=80=9D and it often takes years, particularly in the last case. (no hats, just lots of experience.) Suzanne From nobody Sat Feb 4 15:08:56 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7E712958A for ; Sat, 4 Feb 2017 15:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eETKso7roSx4 for ; Sat, 4 Feb 2017 15:08:53 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 D7DE9129571 for ; Sat, 4 Feb 2017 15:08:52 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id 11so24350653qkl.3 for ; Sat, 04 Feb 2017 15:08:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=h2XuhOSC7CoQ2+b8OUTIuNFQXEw0NzuMyBTab1R5bvw=; b=VKhBouEjdIUNQ16TM3TWHbfrUTUxV63ulPFVshSxBN93hhFvHgngsP8JKJtjSyF7h1 3AZjNUmZWuG1pwrEGx4OLI17bIv0qoO7F4fNA757Umi+nkc/53LYg7+Oafovnr4AD5eg Y1YWCsNJvu1aB9Bjke6dvd8Fhhe62pRZJ+vpDtJruLBxC2SF6I5olQtLJoRZ4OylCeyI guAUBSkaqC7G1i8wl+2mnuSxjbJ3hsA8WgahH/3K2p1Jum/DO10q8SqF/sM8qLvhfBRW DFBgRFCuVfatXtMdYKglMOS6WtHJs559jEqkJjGdBkjZWBDH6SCofL8CdS2ONWP16R+U kuEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=h2XuhOSC7CoQ2+b8OUTIuNFQXEw0NzuMyBTab1R5bvw=; b=gKYdIr4gVNXucLhLnxy/eKpkyodPHid2PoDCAj6TbwCAJntybs4jvioUn1LJVFiyiz giZSAN+ab/TST6CXHbZHJ8sZ8XJURhJu42XIKOY95cBfH8DspP8RAFpA+E4BdTLcphv3 PVSTLNiLPD2KDHUKJmXooeLHNNkAswTCn4+CnZEwlrc6wgzBS45gskOatIaG2/mdYiKy GyOfE4FvB34XEco7jeU/9k6onobPraUYBfzmvhiaz9FJ9bchN9KCnHBIGJQ4uAtcS2sd g+PCnfYOGPGUQ7Ybupk4vSAmoKUHVqJloIh77cZZZtGROYO7jd8et02DvMgtjVyunD8z skuA== X-Gm-Message-State: AMke39kil34G36f0Lzw/MHRabInpXfj0287LnKr9+ny4aHcv86DzbAP2WnLcrjfLaJktqrMz9jjymxni1f1eT8uj X-Received: by 10.55.20.105 with SMTP id e102mr3369241qkh.35.1486249731771; Sat, 04 Feb 2017 15:08:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Sat, 4 Feb 2017 15:08:21 -0800 (PST) In-Reply-To: References: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> From: Warren Kumari Date: Sat, 4 Feb 2017 18:08:21 -0500 Message-ID: To: jeremy@veclabs.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dnsop Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 23:08:54 -0000 On Fri, Feb 3, 2017 at 10:34 AM, Jeremy Rand wrote: > Suzanne Woolf: >> This message opens a Working Group Last Call for: >> >> "Special-Use Names Problem Statement" >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ >> Proposed status: informational >> >> Starts: 2 Feb. 2017 >> Ends: 23 Feb. 2017 (3 weeks) >> >> Discussion should go to the mailing list. >> >> Is this draft ready to advance for publication as an Informational RFC, = and as guidance for possible updates to RFC 6761? Does it describe the rele= vant issues clearly, and cover all the relevant ones that should be taken i= nto account in future work in the IETF on the special use names registry or= RFC 6761? >> >> If not, can you suggest changes that would get your support for advancin= g it? (=E2=80=9CSend text=E2=80=9D if possible!) >> >> >> thanks, >> Suzanne & Tim > > Trivial spelling nit: Sec. 4.2.2 says "unilateral use by the TOR > project". The correct spelling is "Tor" (only the "T" in "Tor" should > be capitalized.) Also, according to > https://www.torproject.org/docs/trademark-faq.html.en, "The Tor Project" > is the correct spelling of the phrase (all 3 words should have the > initial letter capitalized). Thank you very much -- Ralph added this (and Suzanne's below) to the issue tracker. I did the easier part of addressing the nits and closing the nitty issues. We've published a version to GitHub with some of the nits addressed, and we will work on addressing more of the substantive comments. W > > Cheers, > -Jeremy > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sun Feb 5 05:22:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794E1294C4 for ; Sun, 5 Feb 2017 05:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt8sP8CFuaJR for ; Sun, 5 Feb 2017 05:22:16 -0800 (PST) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 515AD127601 for ; Sun, 5 Feb 2017 05:22:16 -0800 (PST) Received: by mail-it0-x241.google.com with SMTP id e137so5896600itc.0 for ; Sun, 05 Feb 2017 05:22:16 -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=eIFt8ZbwySSewKpaW64AHU0xv10UlgRs6cigW6gdBXA=; b=nRQjrMzD32w4YMHgkERArIIkXon0v+WgAfXtjD0chiDz3cWHRhMVWIBikW5WXGm35B DXuGNW37F2fapwuqs29GOX+/vw5TIFc0QgQll9RRqiuqS6VYV6B8ACOYfHalw4WL1UND w9Vh6fpCPifU4jL8sGOopSRV9L+T+Fqbk1nWBKeqx2KerMZGQfb+6qbCYg/9DrN/5vkJ vykX4XF54MYpeI2z7+M4b9upwkyejztRO7ep2KrfOz1lNF5ND9SdQwC4FDY4ShjyHDuG L2SVbOccHv+eZ23O4QuO5nQj2yxjApwJ5Z5T8FkVBL89fBwpAlr88O86ZyCvC0puCEyF xCIA== 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=eIFt8ZbwySSewKpaW64AHU0xv10UlgRs6cigW6gdBXA=; b=r1cybxvvUd+uUC9F+tqThKkWOlNZt/ETzOE0RJUWqAoLlqUHJ00J286K8izrYBcDYD qWMbvBzQ9KH/po0bJZreH9rxvkU/L6WYduMaM6kqpcc+nQIGYE5334QPyMtNQw2ff70k b6aWxYDdKX/6zBux1aIhxlADlu+Wh6bit+Yt8G4xOOHL+XwfD2aB83c+KwCzCyg+8k0n X55TsqUhS3ngSJC+pgtlUhqrAxdisaMAhBCloPIKSbqLnfgC1lttrbf7+FpzCFRYarbl +ywf3ssf6X1EOVmoK8uR3EMCqZqzHwr5EDlERIoYeMThNK0aY5SzjRr6LXluXe5Twevp 7UeA== X-Gm-Message-State: AIkVDXJ99TQApAbwvb8sF3C6S/MzqzhyTk18CwZk/vwEAv9feo7Hbx9HW1P24evxG3B0dt3qKW6/SiJA+WJ5iw== X-Received: by 10.36.77.10 with SMTP id l10mr3736508itb.59.1486300935547; Sun, 05 Feb 2017 05:22:15 -0800 (PST) MIME-Version: 1.0 References: <5FD13D0D-57DE-4CED-B1A2-C823079B8D63@gmail.com> <74796240-46DA-4C8B-A715-DBC521EFA3F3@gmail.com> In-Reply-To: From: william manning Date: Sun, 05 Feb 2017 13:22:04 +0000 Message-ID: To: Brian Dickson , Steve Crocker Content-Type: multipart/alternative; boundary=001a1144d0164aef800547c8670d Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 13:22:19 -0000 --001a1144d0164aef800547c8670d Content-Type: text/plain; charset=UTF-8 DNAME was considered early in the IDN evaluations, so it's not exactly unknown in the Icann community On Fri, Feb 3, 2017 at 15:33 Steve Crocker wrote: > We (ICANN) have no mechanism or process for inserting a DNAME record into > the root. We do have a process for considering the general issue, but, so > far as I know, no one has yet brought that idea into the ICANN/PTI arena. > > > > Steve Crocker > [I am having trouble sending from steve@shinkuro.com, but I am receiving > mail without trouble. Please continue to send mail to me at > steve@shinkuro.com] > > > > > > > > On Feb 3, 2017, at 12:28 PM, Brian Dickson > wrote: > > > > On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker > wrote: > > And just to stir the pot a bit, what would you have ICANN do if someone > applies for .alt as a top level domain? Is it ok if we say yes and > delegate the name? If not, what is the basis for us to say no? > > > The insertion of the DNAME record in the root, instantiates the ALT > domain. It says the ALT domain exists. > > However, the DNAME target of an empty zone, assures (with DNSSEC > signatures) that no names below ALT exist. > > So, a query to a root server for "alt." would get the DNAME (if the query > was for type DNAME or type ANY), or would get "NODATA" for any other RRTYPE. > > And a query to a root server for "anything.alt" would get the DNAME to > AS112.ARPA, and the subsequent query (rewritten as anything.as112.arpa) > would get NXD. > > As to the question about applying for "alt": it means no one can apply for > .alt as a TLD, because it is taken. That is the basis for saying "no". > > Brian > > > > > > > Steve Crocker > [I am having trouble sending from steve@shinkuro.com, but I am receiving > mail without trouble. Please continue to send mail to me at > steve@shinkuro.com] > > > > > > > > On Feb 3, 2017, at 12:18 PM, Brian Dickson > wrote: > > The DNAME has an effect similar to delegation, except that in the case of > the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 ) , the target is a > well-known & published empty zone (as112.arpa.) > > (Delegation and DNAME cannot coexist for the same owner name - that is one > of the edicts for DNAME, similar to CNAME.) > > Any local configuration of something.alt (as an authoritatively served > zone) would be matched before checking the cache or attempting recursive > resolution, per 103[345]. > > I don't have any desire or intention of local something.alt, I'm just > pointing out that the existence of a signed NXD result (via DNAME to an > empty zone) doesn't break such a set-up. > > > > The reason for DNAME instead of delegation, is that it avoids the > operators of AS112 instances from having to configure the new zone(s) > whenever a new "delegation" occurs. > > If, instead, a delegation were done, the specific zone (.alt) would need > to be configured and served somewhere. > > RFC7535 is designed to avoid the need for coordination in configuring such > zones. > > (RFC7535 also allows authorities for other places in the DNS tree to make > use of AS112, but that is a non-sequitur.) > > Brian > > On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker > wrote: > > Are you also expecting ALT will never be delegated in the root? If it > were to be delegated in the root, what impact would that have on the uses > you have in mind? > > Steve Crocker > [I am having trouble sending from steve@shinkuro.com, but I am receiving > mail without trouble. Please continue to send mail to me at > steve@shinkuro.com] > > > On Feb 3, 2017, at 12:02 PM, Brian Dickson > wrote: > > Stephane wrote: > > On Wed, Feb 01, 2017 at 03:28:29PM -0500, > > Warren Kumari wrote > > a message of 103 lines which said: > > > > > or 2: request that the IANA insert an insecure delegation in the > > > root, pointing to a: AS112 or b: an empty zone on the root or c" > > > something similar. > > > > Here, people may be interested by draft-bortzmeyer-dname-root (expired > > but could be revived). The main objection was the privacy issue > > (sending user queries to the "random" operators of AS112.) > > > My opinion on these issues are as follows, roughly: > > - I am in favor of AS112 for ALT > - For AS112, I prefer the AS112++ method (DNAME) > - I do not see why the DNAME would/should not be DNSSEC signed > - Any local use of ALT can be served locally and signed using an > alternative trust anchor > - I don't think there is any issue with having both the NXD from the > root, and the local assertion of existence, both present (in cache and in > authoritative data respectively) > - Maybe there are issues with specific implementations? > - If anyone knows of such problems, it would be helpful to identify > them along with the implementation and version > - For AS112 privacy, perhaps someone should write up a recommendation > to set up local AS112 instances, to provide privacy, as an informational > RFC? > - Even simply through resolver configurations, without a full AS112 > "announce routes"? > - Do any resolver packages offer such a simple AS112 set-up? > - Maybe the efforts for privacy should start there (implement > first, then document)? > - Do any stub resolver packages include host-local AS112 > features/configurations? > > Overall, I'm obviously in favor of use of ALT, and for signing whatever is > done for ALT, and for use of DNAME for ALT. > > Brian "DNAME" Dickson > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > > > > > > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > --001a1144d0164aef800547c8670d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
DNAME was considered early in the IDN evaluations, so it's not exa= ctly unknown in the Icann community


On Fri, Feb 3, 2017 at 15:33 Steve Crocker <steve.crocker@gmail.com> wrote:=
We (ICANN) have no mechanism or process for inserting= a DNAME record into the root.=C2=A0 We do have a process for considering t= he general issue, but, so far as I know, no one has yet brought that idea i= nto the ICANN/PTI arena.


Steve Crocker
[= I am having trouble sending from steve@shinkuro.com, but I am receivin= g mail without trouble.=C2=A0 Please continue to send mail to me at steve@= shinkuro.com]







On Feb 3, 2017, at 12:28 PM, Brian= Dickson <brian.peter.dickson@gmail.com> wrote:
=


On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker <steve.crocker@gmail.com> wrote:
And just to stir the pot a bit, = what would you have ICANN do if someone applies for .alt as a top level dom= ain?=C2=A0 Is it ok if we say yes and delegate the name?=C2=A0 If not, what= is the basis for us to say no?
=
The insertion of the= DNAME record in the root, instantiates the ALT domain. It says the ALT dom= ain exists.

However, the DNAME target of an empty zone, assures (= with DNSSEC signatures) that no names below ALT exist.

So, a quer= y to a root server for "alt." would get the DNAME (if the query w= as for type DNAME or type ANY), or would get "NODATA" for any oth= er RRTYPE.

And a query to a root server for "anything.alt&qu= ot; would get the DNAME to AS112.ARPA, and the subsequent query (rewritten = as anything.as112.arpa) would get NXD.

As to the question about a= pplying for "alt": it means no one can apply for .alt as a TLD, b= ecause it is taken. That is the basis for saying "no".

= Brian
=C2=A0

=
=

Steve Crocker
[I am having trouble sending from steve@shinkuro.com, but I am recei= ving mail without trouble.=C2=A0 Please continue to send mail to me at ste= ve@shinkuro.com]







On Feb 3, 2017, at 12:18 PM, Brian Dickson= <brian.peter.dickson@gmail.com> wrote:

The DNAME has an effect similar to delegation, except that in th= e case of the AS112++ RFC ( https://tools.ietf.org/html/rfc7535<= /a> ) , the target is a well-known & published empty zone (as112.arpa.)=

(Delegation and DNAME cannot coexist for the same owner name - t= hat is one of the edicts for DNAME, similar to CNAME.)

Any local = configuration of something.alt (as an authoritatively served zone) would be= matched before checking the cache or attempting recursive resolution, per = 103[345].

I don't have any desire or intention of local somet= hing.alt, I'm just pointing out that the existence of a signed NXD resu= lt (via DNAME to an empty zone) doesn't break such a set-up.

=

The reason for DNAME instead of delegati= on, is that it avoids the operators of AS112 instances from having to confi= gure the new zone(s) whenever a new "delegation" occurs.

If, instead, a delegation were done, the specific zone (.alt) would need = to be configured and served somewhere.

RFC7535 is designed to avo= id the need for coordination in configuring such zones.

(RFC7535 = also allows authorities for other places in the DNS tree to make use of AS1= 12, but that is a non-sequitur.)

Brian

On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker <steve.crocker@gmail.com> wrote:
Are you also expecting ALT will never be de= legated in the root?=C2=A0 If it were to be delegated in the root, what imp= act would that have on the uses you have in mind?
<= br class=3D"gmail_msg">
Steve Crocker
[I= am having trouble sending from steve@shinkuro.com, but I am receiving= mail without trouble.=C2=A0 Please continue to send mail to me at steve@= shinkuro.com]


On Feb 3, 2017, at 12:02 PM, Brian Dickson= <brian.peter.dickson@gmail.com> wrote:

Stephane = wrote:=C2=A0
On Wed, Feb 01, 2017 at 03:28:29PM -0500,
 Warren Kumari <warren at kumari.net> wrote 

 a message of 103=
 lines which said:



> or 2: request that the IANA insert a=
n insecure delegation in the

> root, pointing to a: AS112 or b: a=
n empty zone on the root or c"

> something similar.

<=
br>
Here, people may be interested by draft-bortzmeyer-dname-root (expir=
ed

but could be revived). The main objection was the privacy issue
(sending user queries to the "random" operators of AS112.)<=
/pre>

My opinion on these issues are as follows, roughly:<= /div>
  • I am in favor of AS112 for ALT
  • For AS112, I = prefer the AS112++ method (DNAME)
  • I do not see why the DNAME would/should not be DNSSEC signed
  • Any local use of ALT can b= e served locally and signed using an alternative trust anchor
    • I don't = think there is any issue with having both the NXD from the root, and the lo= cal assertion of existence, both present (in cache and in authoritative dat= a respectively)
    • Maybe there are issues with spe= cific implementations?=C2=A0
    • If anyone knows of= such problems, it would be helpful to identify them along with the impleme= ntation and version
  • For AS112 privacy, per= haps someone should write up a recommendation to set up local AS112 instanc= es, to provide privacy, as an informational RFC?
    • Even simply through resolver configurations, with= out a full AS112 "announce routes"?
    • D= o any resolver packages offer such a simple AS112 set-up?
    • Maybe the efforts for privacy should start there (implement firs= t, then document)?
    • Do any stub resolver package= s include host-local AS112 features/configurations?
Overall, I'm obviously in favor of use of ALT, and for = signing whatever is done for ALT, and for use of DNAME for ALT.
=

Brian "DNAME" Dickson


_______= ________________________________________
DNSOP maili= ng list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop














_______________________________________________

DNSOP mailing list

DNSOP@ietf.or= g

http= s://www.ietf.org/mailman/listinfo/dnsop

--001a1144d0164aef800547c8670d-- From nobody Sun Feb 5 07:16:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BDD129485 for ; Sun, 5 Feb 2017 07:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dr-j9z75Q4E for ; Sun, 5 Feb 2017 07:16:52 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 17576128BA2 for ; Sun, 5 Feb 2017 07:16:52 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id w20so81278006qtb.1 for ; Sun, 05 Feb 2017 07:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SnwFTqgN5y4ab2hAivZhRTJroB4ps9Wh3JIlQwkx6b8=; b=jUZKDBM7gAsI3lJz36SxGtYwjDM4my83AQJX2+yenQfFwNLK5y92PUVz4DLkt+WnRr 3ew8ZMHWagpLISvBGyC8N8Hn8FxsAEtghr7Cndc66qYvEazuYVpkrH+ORIH4lA1mGPcw rwvV1UWpizqohqrXq4LYwla47hkb8mbMXG8/HfpdJlZAUoK7hJ5Jishi3D2zJ11a7oeD nLBzqowF17/LEWh58xI8ttM33tp11E//D20MJ5dhUtADha0o8RTLQY20kXd8JB5NoVAN I/VWkFw23lZW8VgKjbKEV+F9aWUKeeP3V7I2VrcylR3ZvkCPjEHr41oRG2MxtwM3hj3w GfHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SnwFTqgN5y4ab2hAivZhRTJroB4ps9Wh3JIlQwkx6b8=; b=QG1F3yZv4b8UGJCj4QJ0Hu4pkfM2+vMtPhInXkL9saI8B2OPknaLnLifkX4beSc+hi XiEr7K8P3u+6c6MlySN6pvrm6pemkWDoOO60hI/aweBhredapy1sOn7K10PDObTsrH/j MYDba+O1CZJZWkjE2TfBczhO07QAa5L5Y1fNxs+9SjGB3xzbnDOSAag15FXny8RORqv4 fh11/utqbcbbgvKEUj83Cc3Eb9Mouy70eb4RIblJCg9fTEZHY9yWbRxHxc7fxAXHGxEW D6wSLUN8aoSvTbocs0AsCjMbLBBQbjZYIZvUGLbM1jWRCdEDBo1wDjwd5y+WZzngj5W4 PEAw== X-Gm-Message-State: AMke39lkIrMzKUgDpQkk5/eFDDYp9QKhZu5nG2FmIgM7z6+8369ZdRkT3LkxE5EZLrdso+3Vdry+5b1clgE7vXzi X-Received: by 10.200.54.247 with SMTP id b52mr6426605qtc.124.1486307811055; Sun, 05 Feb 2017 07:16:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Sun, 5 Feb 2017 07:16:20 -0800 (PST) In-Reply-To: <88686BFE-7874-4EB4-8E04-FF68DFB51F94@fugue.com> References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> <20170204021009.GE67739@mx2.yitter.info> <88686BFE-7874-4EB4-8E04-FF68DFB51F94@fugue.com> From: Warren Kumari Date: Sun, 5 Feb 2017 10:16:20 -0500 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dnsop , Andrew Sullivan Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 15:16:54 -0000 On Fri, Feb 3, 2017 at 9:40 PM, Ted Lemon wrote: > On Feb 3, 2017, at 9:10 PM, Andrew Sullivan wrote: > > My memory is that only after that > did we start thinking of a sort of 1918-style part of the DNS as > well. That may have been a mistake, since as this discussion is > showing the properties of an in-protocol, in-DNS namespace without > delegations are somewhat different to alternative-protocol uses that > do not rely on the DNS at all. > > > I think that we've seen a number of questions go by that lead to the > conclusion that it makes sense to have two hierarchies: one for experimental > non-DNS queries, and one for locally served zones. Yes. > I don't know if we > _need_ the .LSZ (or whatever) SUTLDN, but if we need to be able to have a > special-use top-level domain name that has an un-signed delegation, it > probably ought to be different than the SUTLDN that is used for non-DNS > stuff, so that both names can have the appropriate configuration in the root > zone. .alt was intended only for names *outside* the DNS - an alternate name resolution system (like .onion). It was never intended for use in an alternate/internal DNS namespace. If needed, we can clarify this in the draft. I fully understand the desire for names which are resolved using the DNS, but are not rooted in / connected to the DNS root -- I think that something like this would be really useful (I've got a bunch of use-cases), but it seems like a completely different kettle of fish. I'd encourage someone to write a document like this -- I started writing a such document[0] in July 2015 to reserve a name (.internal) specifically for this, but only got as far as the title and abstract before getting sidetracked. :-P So, in my opinion there should not be any sort of delegation for .alt. A new (short) draft reserving .internal (or whatever) specifically for DNS names not rooted in / connected to the IANA tree could be written, and that can ask for a delegation. W [0] Reservation of .internal as a Special Use Name. This document reserves the string "internal" for use as an internal DNS [ Ed note: Text inside square brackets ([]) is additional background information, answers to freqently asked questions, general musings, etc. They will be removed before publication.] [ This document is being collaborated on in Github at: https://github.com/__URL__. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) acept pull requests ] > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sun Feb 5 08:30:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93024129413 for ; Sun, 5 Feb 2017 08:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 ZQyp_kONNEh7 for ; Sun, 5 Feb 2017 08:30:28 -0800 (PST) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC82124281 for ; Sun, 5 Feb 2017 08:30:28 -0800 (PST) Received: from jurassic (unknown [115.118.144.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 4494656A042B; Sun, 5 Feb 2017 16:30:24 +0000 (GMT) Date: Sun, 5 Feb 2017 22:00:20 +0530 From: Mukund Sivaraman To: Warren Kumari Message-ID: <20170205163020.GA12569@jurassic> References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> <20170204021009.GE67739@mx2.yitter.info> <88686BFE-7874-4EB4-8E04-FF68DFB51F94@fugue.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: dnsop , Ted Lemon , Andrew Sullivan Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 16:30:38 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 05, 2017 at 10:16:20AM -0500, Warren Kumari wrote: > [0] > Reservation of .internal as a Special Use > Name. ... > > This document reserves the string "internal" for use as an inter= nal > DNS >=20 > [ Ed note: Text inside square brackets ([]) is additional backgr= ound > information, answers to freqently asked questions, general musings,= etc. > They will be removed before publication.] >=20 > [ This document is being collaborated on in Github at: > https://github.com/__URL__. The most recent version of the document, > open issues, etc should all be available here. The authors (gratefu= lly) > acept pull requests ] > > If you'd uploaded this, it could've been the shortest first draft! Mukund --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYl1MbAAoJEB9EXrAiC5LsVMEP/RhaZfBaP2xYPRgdo4ZQOvJ/ Ubmyb6YNdiV05GCSc323fy2JscQ4rAMkRV5p884a7VV9JSNdu89PLx1YUerRLqPs yYDm+F9NEy02/7YvK9XKmyxmuprzHodNiQgkUmkJIXXlLjs8M+CBGT2AhOVwBMnu nqidAfK+koys0QfuBik301YDdlbx4QcoIcNej8dwJulXzx6x0HRZ0+GomxQEQNdr NMx0NRF8BNP6W+RvCfZhvrvFob5mBbfzztJoMNaw1BUZlutYQiYl77ILScGZvG5f olrrYNpWe2A2EBUwCCH55B2Q2bvOZcVdxobaIMN5t7v8zYIOnmTEKxczwfP5Xr13 FKRoeKvvAFXiC2tcdNWUUnPZJHkMgBCcBW0fX2IFrDWG30Vh7EcTTiCYNm7SgEIE xzHu8xJtn7FHkQsBmHugcL9CtDlpeht6diwTRSfGFSbOFHTwTPzM9dcaBiB8kEvk Me83+89ssS6DWZAGmtsIULFnfmmR0hDxKN6rDgQNgX622TGiQAcST3E1/sz+s5Qh s5nZfgpr04JVSwfHAKCKyMsevBujgiFn78JsGpDcBOR69XEoI2aDfcb721A9pzFw byyRTYBBLsD3eCJkuk2VWgQCzm/eD75vKy3l/SKPfCL016buVxEIFJwqVqTPseMy RDb5Xu/hnqBK8Cv320J1 =5rLw -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From nobody Sun Feb 5 08:32:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94769129441 for ; Sun, 5 Feb 2017 08:32:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=nV4TGuwF; dkim=pass (1024-bit key) header.d=yitter.info header.b=NFRGxO3+ 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 dYh8dQUnZGDx for ; Sun, 5 Feb 2017 08:32:07 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6AF129418 for ; Sun, 5 Feb 2017 08:32:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id A3495BD554 for ; Sun, 5 Feb 2017 16:31:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1486312296; bh=9n+iQjuq1iTLR9qBoLN2kK2neFh03VVkdqnW6xla67M=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nV4TGuwFhhg7RubjuUqsv/pkntagDr3EcmMpCTSWD6hregduWt1ZKKJfDyYwfciRL /yJNdpdxpTrYoYxP7tSq9WW7X6aimPSSAroUbPofAwxflUoZA8qZyWm2FfxNhJD3Ng Z4vANkZTUHoKdvRTpVxCCV823ALN+LE23HrKpzkg= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xIhryMY5S9W for ; Sun, 5 Feb 2017 16:31:35 +0000 (UTC) Date: Sun, 5 Feb 2017 11:31:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1486312295; bh=9n+iQjuq1iTLR9qBoLN2kK2neFh03VVkdqnW6xla67M=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NFRGxO3+VQ8M6I7vVVkAqH9yAmYhg2cMm5quOEyoyDOxwucpN1vbP/9UDLbwrafhg kEkIQbOP+vXVy9WHOpKinEP+agOuXyF7Qvi/FWflF2LLf/280rGvAt3eHtIegbxEWZ buQxjnnaHVUPXhdP3as0m1SbpQOsAp22GgZKzLc8= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170205163133.GB75503@mx4.yitter.info> References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <20170204020711.GD67739@mx2.yitter.info> <20170204132608.49806618F0F5@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170204132608.49806618F0F5@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 16:32:08 -0000 On Sun, Feb 05, 2017 at 12:26:08AM +1100, Mark Andrews wrote: > > Given there are no rules for this type of namespace Which "type of namespace" do you mean? I think there are three possible namespaces you're talking about: 1. Domain names. There are rules for these, though they're possibly underspecified. The IETF now has change control over the namespace definition documents (though the creation of said namespace predates the IETF). For this reason, the IETF was in a position to create the 6761 registry and thereby establish that there are some domain names that are treated specially. 2. Domain names that are candidates for some DNS zone. There is a policy authority for these, and it's the operator of the zone in question. Its rules for that zone apply. In the case of the DNS root zone, the policy authority for that zone is the names community as expressed through ICANN. (Similarly, I am the policy authority for the crankycanuck.ca zone, and if you want a delegation in there you can talk to me.) 3. Domain names that are _not_ for use in the DNS. This is one of the purposes of 6761, though perhaps not the only one. So far, the rules for these have been mostly underspecified, though I think 6761 gives pretty compelling reasons why it's a good idea at least to register the use there. The trouble we seem to be having is that we want something that is in (2) but with no single policy authority for the zone. It is not clear that we have a way to do that if we start from the root. We _might_ have a way to do it if we start from arpa, since the IAB is in charge of arpa and doesn't have the policy problems that ICANN does. The alt draft that Warren and I worked on was really intended to carve out a place for (3). > respect the reasons for the other rules which I did but you choose > to completely cut out of the reply. I cut them out because I don't believe the IETF is the unambiguous source of those reasons. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Feb 5 18:51:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A15129A92 for ; Sun, 5 Feb 2017 18:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mbHCzudMAMY for ; Sun, 5 Feb 2017 18:51:21 -0800 (PST) Received: from smtp69.iad3a.emailsrvr.com (smtp69.iad3a.emailsrvr.com [173.203.187.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92CD1294AD for ; Sun, 5 Feb 2017 18:51:21 -0800 (PST) Received: from smtp1.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 668A45DD1; Sun, 5 Feb 2017 21:51:18 -0500 (EST) X-Auth-ID: ogud@ogud.com Received: by smtp1.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 474565B9B; Sun, 5 Feb 2017 21:51:09 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-71-191-33-181.washdc.fios.verizon.net [71.191.33.181]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sun, 05 Feb 2017 21:51:18 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Olafur Gudmundsson In-Reply-To: <0c9ea76d-a541-943a-d72e-bfe255d57259@bellis.me.uk> Date: Sun, 5 Feb 2017 21:51:11 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> <20170204021353.GF67739@mx2.yitter.info> <0c9ea76d-a541-943a-d72e-bfe255d57259@bellis.me.uk> To: Ray Bellis X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 02:51:23 -0000 > On Feb 4, 2017, at 4:46 AM, Ray Bellis wrote: > > > > On 04/02/2017 02:13, Andrew Sullivan wrote: >> Right, that's always been the problem with using this _for the DNS_. >> Homenet has no choice in that, because the whole point of the homenet >> name is precisely to enable in-homenet DNS without reference to the >> global DNS. I think you're quite correct that we need to decide >> whether alt is to be used for those purposes. I'm not convinced >> that's so useful. > > If it turns out that we can't get the insecure delegation that we need > for .homenet, then I'd (personally) be reasonably happy with > .homenet.alt, except that the current proposals for the use of .alt > wouldn't seem to permit that. > > Ray What is wrong with homenet.arpa ? you can have that next month and no-one will complain Olafur From nobody Sun Feb 5 18:54:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEAB129A92 for ; Sun, 5 Feb 2017 18:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKyqfJw9Dvuw for ; Sun, 5 Feb 2017 18:54:45 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 5B1371294AD for ; Sun, 5 Feb 2017 18:54:45 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s186so42862753qkb.1 for ; Sun, 05 Feb 2017 18:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Awdsub9uQZWR3TxIora4gC+uFDk2kv0CG2zJe0+2B3o=; b=QXb+4/pJnn2usBxoSJG3H18Kkjiw1oSY6knm8P/RGQqzjdKg1H4xThuD0YhELRHNEn zk+iZt2CKUuR8RlTTwryBm/ez/Lj8rZx2mV2ithgvMlX57CBUEEMW1TlGybuejla8JLc c/iER+wy6kPXYHSNgWDO+qUdo0o5LUoEORIKZAYRMX8c46uKmd+OvVfo40o6Izfq82Es kHJrUVbpJaWPI9DHXkCIAkS1emDdhOCbeqeCvtBN5RzS2dDEJtXWgqtivpLVVHcd//PJ ETifT8Xk4Ks6odKoYVIJDJd4Yg6qDRo4G5Sp/2vp/G44NAWfu6XsUiTSse3VX+w4R2R0 Y1jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Awdsub9uQZWR3TxIora4gC+uFDk2kv0CG2zJe0+2B3o=; b=Tlce/Jfx2Np/vclDFksxQWNYgFvK/eVZz04K1gA5oeKUU4PZLVZusiJozCSo9k966k GwJ9j2AeL1im2Y6omXrm+rfAfa9+BUa9fBfJ39iEBFaL6uKyJajPyLLgcOzm18Ewd1W6 pnzdWpjSP+45z7qoKOLukCH5xCLgpflIDqZFhUTFrWpHDGkWOEmRkuSls7ox2yFrY2cc A8Z2+By8CjA4fyYsM+EAfYZoSrAeZ0u8HjvQWtBR7156AzF6ZgltEe4ETJ3NEKNlN22r KJ/jEmVh2e6jQh3ZMjQQewiUfzvdyYgR9sznFTYVuM8t5F3NXkeLgfkBmkvk+QNLSmhM 05DA== X-Gm-Message-State: AMke39l4pYK01S/a8q3PhnBAl5yq+lMfoVIw97mV6rs+Ua//+AXSmLW6hIDcAXoCdiVOwg== X-Received: by 10.233.223.129 with SMTP id t123mr7157267qkf.191.1486349684505; Sun, 05 Feb 2017 18:54:44 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id p70sm25277303qke.48.2017.02.05.18.54.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Feb 2017 18:54:43 -0800 (PST) From: Ted Lemon Message-Id: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4BA03119-B5D6-4FE7-9FDC-DB34965D2177" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 5 Feb 2017 21:54:41 -0500 In-Reply-To: To: Olafur Gudmundsson References: <20170201204455.6nymmjlj5lzq2ect@mycre.ws> <20170204015158.GB67739@mx2.yitter.info> <5BB1A3F5-5EFB-4164-9720-68E262E58636@fugue.com> <20170204021353.GF67739@mx2.yitter.info> <0c9ea76d-a541-943a-d72e-bfe255d57259@bellis.me.uk> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop , Ray Bellis Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 02:54:46 -0000 --Apple-Mail=_4BA03119-B5D6-4FE7-9FDC-DB34965D2177 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 5, 2017, at 9:51 PM, Olafur Gudmundsson wrote: > What is wrong with homenet.arpa ?=20 homenet.arpa sounds like a service out there on the arpanet somewhere, = not something local. --Apple-Mail=_4BA03119-B5D6-4FE7-9FDC-DB34965D2177 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 5, 2017, at 9:51 PM, Olafur Gudmundsson <ogud@ogud.com> = wrote:
What is wrong with homenet.arpa ? 

homenet.arpa sounds like a service out there on the arpanet = somewhere, not something local.

= --Apple-Mail=_4BA03119-B5D6-4FE7-9FDC-DB34965D2177-- From nobody Sun Feb 5 20:05:43 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AEA129B25 for ; Sun, 5 Feb 2017 20:05:41 -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 tmeis1iAWHEM for ; Sun, 5 Feb 2017 20:05:40 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17212129B24 for ; Sun, 5 Feb 2017 20:05:39 -0800 (PST) Received: (qmail 58573 invoked from network); 6 Feb 2017 04:05:38 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 6 Feb 2017 04:05:38 -0000 Date: 6 Feb 2017 04:05:16 -0000 Message-ID: <20170206040516.1701.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: mellon@fugue.com Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 04:05:41 -0000 In article <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> you write: >On Feb 5, 2017, at 9:51 PM, Olafur Gudmundsson wrote: >> What is wrong with homenet.arpa ? > >homenet.arpa sounds like a service out there on the arpanet somewhere, not something local. Why would that be important? It's mostly managed automatically. From nobody Sun Feb 5 20:09:29 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33454129B25 for ; Sun, 5 Feb 2017 20:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDxcuSXbdDqO for ; Sun, 5 Feb 2017 20:09:26 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 3F1DD129B23 for ; Sun, 5 Feb 2017 20:09:26 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id x1so37930470lff.0 for ; Sun, 05 Feb 2017 20:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pZvCmDAfq9mIM51nWFbIINWqTa2uGCNilovZ2KP5Bi8=; b=wH7xTdP0KafTTKT+89Rth5c7VTXo9RNk+pLr+1lGY/lKfHi26Fak0nZ2fqEMQWoY3U iKkJcYoHbfkZwq9pJo+ohFfnGt0yZKrwdi2GaGxrrNjDJfOhtM96NOT7Dk+rhHepeeX3 fpZWj1T+7sd/RfCDQlycuRuiOiEdS17ijRgzrWxmFx1JI77i0VqESd2lDrmPfp+TREWT NagKYi+MblnLGZfnAvTq8269EdoqL9YmCNd3kIIYlQyFHOFhYbLHs94+w9OgQS2lD8SN ZBV77s2QrgRr0/0EHXkpRVjHcmbxsVeYS4qEbsoxOIxzCK//qxYm+mkMscGoraO5bSOK xqhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pZvCmDAfq9mIM51nWFbIINWqTa2uGCNilovZ2KP5Bi8=; b=ax0IHIWZDyXDoXR9Yqkm5OJIvlO5ZaQJ4G+zWJ6ZA38zK4NwB5dPL/12vh2c0INAdt F4+lrj9cqhh6URV5mUDyjOYSpB665UhIoZRhEiDy85ZoQdJCnzA7UzuNOcZY+twqyo1S DUsYH9Zk5x1w1xO3+Y+qbGKG//TmAFzdmro24tU4iKx0Fz0mXkSYlH6OoJhTSfFl1JB5 UiNAUt+WJj4adbWy5GqIgKFWhxwvotMlLW/QpLfKK0mWkgN3pHOAuySE/kT7Mpl8eUky hr6TurR0q+MiRjwphUVCNheRQPVFm/I/GgoyT3gnzQtbVr5wQ4px3U0GZRnEoRPJ2wDu lmXw== X-Gm-Message-State: AIkVDXJ5dVovFWooHGN9QgdmPxMRoTvOHo7qMMuvagBVqX0ZXxuLBRq8dgZI25Z4SKtabJ/6GsURNyLqHkKUwg== X-Received: by 10.25.215.103 with SMTP id o100mr2694724lfg.126.1486354164347; Sun, 05 Feb 2017 20:09:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.20.67 with HTTP; Sun, 5 Feb 2017 20:09:23 -0800 (PST) Received: by 10.25.20.67 with HTTP; Sun, 5 Feb 2017 20:09:23 -0800 (PST) In-Reply-To: <20170206040516.1701.qmail@ary.lan> References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> From: Ted Lemon Date: Sun, 5 Feb 2017 23:09:23 -0500 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a1140e192fa0bab0547d4cb48 Archived-At: Cc: dnsop WG Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 04:09:28 -0000 --001a1140e192fa0bab0547d4cb48 Content-Type: text/plain; charset=UTF-8 I'm pretty sure I've explained it enough times on this mailing list and in the relevant documents by now. If you don't agree, maybe we should just accept that. If you don't remember the explanation, it's in the homenet naming architecture doc I wrote. On Feb 5, 2017 11:05 PM, "John Levine" wrote: > In article <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> you write: > >On Feb 5, 2017, at 9:51 PM, Olafur Gudmundsson wrote: > >> What is wrong with homenet.arpa ? > > > >homenet.arpa sounds like a service out there on the arpanet somewhere, > not something local. > > Why would that be important? It's mostly managed automatically. > > --001a1140e192fa0bab0547d4cb48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm pretty sure I've explained it enough times on= this mailing list and in the relevant documents by now. If you don't a= gree, maybe we should just accept that. If you don't remember the expla= nation, it's in the homenet naming architecture doc I wrote.=C2=A0

On Feb 5, 2017 1= 1:05 PM, "John Levine" <joh= nl@taugh.com> wrote:
In article <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> y= ou write:
>On Feb 5, 2017, at 9:51 PM, Olafur Gudmundsson <ogud@ogud.com> wrote:
>> What is wrong with homenet.arpa ?
>
>homenet.arpa sounds like a service out there on the arpanet somewhere, = not something local.

Why would that be important?=C2=A0 It's mostly managed automatically.
--001a1140e192fa0bab0547d4cb48-- From nobody Sun Feb 5 20:18:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F8C129B39 for ; Sun, 5 Feb 2017 20:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=TKaRvqBo; dkim=pass (1536-bit key) header.d=taugh.com header.b=hzIjJv7p 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 Qa3OiR1Qak54 for ; Sun, 5 Feb 2017 20:18:20 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C11129B2F for ; Sun, 5 Feb 2017 20:18:19 -0800 (PST) Received: (qmail 59572 invoked from network); 6 Feb 2017 04:18:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=e8b2.5897f90b.k1702; bh=B/NEmBuWv2TO+lEq/0fZWsnmKMNNXWSFPzYM6Suh5Ds=; b=TKaRvqBo0c9kRkFxjuVUrDYSfwvD8rIW5GIhGwoW6TWfatzYTKVO/NfD0jRexgB4YBo6DX52Z3y5idjhPWgbkEMnzgsMBgFMU4veeW3qxaehRmDLe53FKtDkXZXMzcwqx6O06rK8FTNjvM6PpycXEX2DT1cvX9wZoRFX/BffojYUd1k0sDcrTifWwJl755pPFn60a1u9t4OEzuUDlwmkyDtOTPSsB2hU9Oh5UvT5EWQjZcNwuHkPFtYLSzOL29sE DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=e8b2.5897f90b.k1702; bh=B/NEmBuWv2TO+lEq/0fZWsnmKMNNXWSFPzYM6Suh5Ds=; b=hzIjJv7p3tDz+7e7Qp7LQJJQNUEat2usWVNTwR0DusSbvA34lg+t2FeD9LGe8PvpK/XLxkNx6cW0ymy2PburP2md4iRMniRdftT8aN20+Jnz7JWbrEHkzo/jIjiwUSWuH19upcJQk5CHNIeGZNQg9wlR4rbwfkhwg9DHgjPJs9zzm0Q3/fu5jddDQ5w98pAVyrLEFwcKN7h/xwCEXX4CjZUOR+Z4/R78Zai86DsWfidDQIG15Ji01bD4TbVKhGp2 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 06 Feb 2017 04:18:18 -0000 Date: 5 Feb 2017 23:18:18 -0500 Message-ID: From: "John R Levine" To: "Ted Lemon" In-Reply-To: References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dnsop WG Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 04:18:21 -0000 > I'm pretty sure I've explained it enough times on this mailing list and in > the relevant documents by now. If you don't agree, maybe we should just > accept that. If you don't remember the explanation, it's in the homenet > naming architecture doc I wrote. Well, OK, I took another look, and from what I can see, it's a belief that people will find toaster.homenet.arpa harder or more confusing to type than toaster.homenet. Just out of curiosity, how long is it worth waiting to get .homenet rather than .homenet.arpa? If it took five more years, which at the current rate seems optimistic, would homenet still be relevant? R's, John From nobody Sun Feb 5 20:22:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEA1129B43 for ; Sun, 5 Feb 2017 20:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyJk2v6T98WA for ; Sun, 5 Feb 2017 20:22:38 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 60F07129B39 for ; Sun, 5 Feb 2017 20:22:38 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id v186so37983800lfa.1 for ; Sun, 05 Feb 2017 20:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SWLqIdmODMv9b7MZdSymrwG+jFv5loLJPay5/1BewL0=; b=cnbTJmiWkURMfdvsGBhWoa3NLFweXTTAc/vMnp+JwX1jfseNcannCEQwZiTU+3Mn+r wClovgrGbUtCGYZHWU+w0IVRWUw9/D3D2zqrtIXMzKUtT69q4ypC6pWldEfCP4VqEYB4 5bDN/iP7cx+X4SAyJ7Q2TF+fXa1nIMdnj2LhfCxYGgOjLZ3PKyyg1rgLumdTDlIhbIZw /NbbvRtVJMUfcAqoutANUThWtsDzuQt8t+LUKoB/YCBpwmz/6xmK05Z/ZS/tZ3pt9mRm MjgNrOfsXWUCerZR2NtR7jm9UmbM8Pa4Kpu/Y3VKArg/yMwBAPwNTjyVPFPQcI/yCIlu Lfkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SWLqIdmODMv9b7MZdSymrwG+jFv5loLJPay5/1BewL0=; b=TWI1OGEXtgsa1JqHIsqKyqS+vyZJI3AwXWhI0bF+h75AwTb/f7JQM+vucCjSHhLcR4 2VVbntEwTxCwGgwMNThFrOf2LU5aIWmlwYeUQahQeEJoaNeDUZzkQ4Yzk4+FpqQbURc2 3bJt7Gft7ENh7fxZdKqNnOTwkCIFyIIwIfpwlKBcaKlzlmlORsGjouGbJ1SJO8mh4vpe 9/6enuEiIxw9bkowC3EhSuJfSUj//WWBmTl5anF8Xl+8NyIuBVlyuK3ULVDfrDnWsvf0 UCyXvp9hG81KMLMbva22qJgzPQNx74VZHpSsST9A6kEmDwhDNqQD0nDSHxBWQXJa6/B/ HyCQ== X-Gm-Message-State: AIkVDXIJTb77QA/UvOBaVzLdUN3lpII1I1SnSlLGx14Kw2eJorZU7u2GU2rZ/IWP4yJeSS0rBVg0nD1f3nkiFA== X-Received: by 10.46.75.1 with SMTP id y1mr1340040lja.75.1486354956588; Sun, 05 Feb 2017 20:22:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.20.67 with HTTP; Sun, 5 Feb 2017 20:22:35 -0800 (PST) Received: by 10.25.20.67 with HTTP; Sun, 5 Feb 2017 20:22:35 -0800 (PST) In-Reply-To: References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> From: Ted Lemon Date: Sun, 5 Feb 2017 23:22:35 -0500 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=f403045ea47a32b1dc0547d4fb04 Archived-At: Cc: dnsop WG Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 04:22:40 -0000 --f403045ea47a32b1dc0547d4fb04 Content-Type: text/plain; charset=UTF-8 The working group has consensus to give it a try. We may change our minds of it takes too long, but it seems worth exploring from a process perspective anyway. On Feb 5, 2017 11:18 PM, "John R Levine" wrote: > I'm pretty sure I've explained it enough times on this mailing list and in >> the relevant documents by now. If you don't agree, maybe we should just >> accept that. If you don't remember the explanation, it's in the homenet >> naming architecture doc I wrote. >> > > Well, OK, I took another look, and from what I can see, it's a belief that > people will find toaster.homenet.arpa harder or more confusing to type than > toaster.homenet. > > Just out of curiosity, how long is it worth waiting to get .homenet rather > than .homenet.arpa? If it took five more years, which at the current rate > seems optimistic, would homenet still be relevant? > > R's, > John > --f403045ea47a32b1dc0547d4fb04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The working group has consensus to give it a try.=C2=A0 W= e may change our minds of it takes too long, but it seems worth exploring f= rom a process perspective anyway.=C2=A0
On Feb 5, 2017 11:18 PM, "John R Levine&qu= ot; <johnl@taugh.com> wrote:
I'm pretty sure I've explained it enough times on this mailing list= and in
the relevant documents by now. If you don't agree, maybe we should just=
accept that. If you don't remember the explanation, it's in the hom= enet
naming architecture doc I wrote.

Well, OK, I took another look, and from what I can see, it's a belief t= hat people will find toaster.homenet.arpa harder or more confusing to type = than toaster.homenet.

Just out of curiosity, how long is it worth waiting to get .homenet rather = than .homenet.arpa?=C2=A0 If it took five more years, which at the current = rate seems optimistic, would homenet still be relevant?

R's,
John
--f403045ea47a32b1dc0547d4fb04-- From nobody Mon Feb 6 04:12:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBC8129D00 for ; Mon, 6 Feb 2017 04:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 PYE_xsf6UWaq for ; Mon, 6 Feb 2017 04:12:04 -0800 (PST) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17292129536 for ; Mon, 6 Feb 2017 04:12:03 -0800 (PST) Received: from [2001:470:78c8:2:6ce0:82ed:b11b:7f37] (helo=pallas.home.time-travellers.org) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1cai9g-0007Vv-BE; Mon, 06 Feb 2017 12:12:24 +0000 Date: Mon, 6 Feb 2017 13:11:53 +0100 From: Shane Kerr To: Warren Kumari Message-ID: <20170206131153.52329a04@pallas.home.time-travellers.org> In-Reply-To: References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/yIN72=0uBg8/MAMRMg2G2hX"; protocol="application/pgp-signature" Archived-At: Cc: dnsop Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 12:12:07 -0000 --Sig_/yIN72=0uBg8/MAMRMg2G2hX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Warren, I am still wondering about the: 3 * (DNSKEY RRSIG Signature Validity) / 2 Term in the draft, which I see survived the update. Why is this not just the DNSKEY RRSIG Signature Validity? In principle once the signature has expired it cannot be used to replay the old DNSKEY RRset right? Cheers, -- Shane At 2017-02-03 21:14:03 -0500 Warren Kumari wrote: > Hi all, >=20 > Was and I have updated this document to make it clearer and more > readable. Please take a read and let us know if any parts are unclear, > if you have any other feedback, etc. >=20 > Is this close to done? > W >=20 > On Fri, Feb 3, 2017 at 6:29 PM, wrote: > > > > A new version of I-D, draft-hardaker-rfc5011-security-considerations-02= .txt > > has been successfully submitted by Warren Kumari and posted to the > > IETF repository. > > > > Name: draft-hardaker-rfc5011-security-considerations > > Revision: 02 > > Title: Security Considerations for RFC5011 Publishers > > Document date: 2017-02-02 > > Group: Individual Submission > > Pages: 8 > > URL: https://www.ietf.org/internet-drafts/draft-hardaker-rfc= 5011-security-considerations-02.txt > > Status: https://datatracker.ietf.org/doc/draft-hardaker-rfc5011= -security-considerations/ > > Htmlized: https://tools.ietf.org/html/draft-hardaker-rfc5011-secu= rity-considerations-02 > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-hardaker-rfc5= 011-security-considerations-02 > > > > Abstract: > > This document describes the math behind the minimum time-length that > > a DNS zone publisher must wait before using a new DNSKEY to sign > > records when supporting the RFC5011 rollover strategies. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > =20 >=20 >=20 >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 --Sig_/yIN72=0uBg8/MAMRMg2G2hX Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdhRx2J+MnJeBOVlgNzKXnPlnswYFAliYaAkACgkQNzKXnPln swZvGA//WrxbXZmzfFmDq1JOrMJEv55gcM5yVdfINnLDjwZ+9ieCU4CYQuRvoRX1 VJGOHYp8KMyzBioi8QvbeVovOP2s6tcMcTo6Gnr6mrAv3/EdmXm89cKUQDnl9p2G 27TXzH1JLqpEfuUPrVoiXHN0vBpjgCXkph3MsJqTCgG0zAxGSe8icY1LzrJhKX/L OCqUKIS8ziw4HbWru9bxOZiJUNRRfYhhAQ6elwmRX1xlLNnbqASgcMbTgvAhZDRN GhXUZBqUFK2NYGOa0qR7+aH3pgxc6nyd5jioVmNbbxfpQIFysqJiHHw+O6ebKVfA URteM0aUSTkM2J89z0yPLXfyGadcuMazUEWo4eR2cU+yAGydDthaxf8Zk4s6apOK MKaAL8nqX+jkrfPPWI16HBJejzvGJ8S69u590OpC/nI9WurxdAHqZpkIrI5O4bLD fRNb6FX76hVGRawjV8S4xJb1viRBsE51JReoy20BpjBDRnFjw4NKuBDP0pliWFAx 0m5cQsqSTCzpCb6T8RwpenD60WNBygtTt71LZtrjARo1kg8WrQf3bf6yy1CtXZmg qMMRMyGjIYopr0H148oawUdIqmiXT4PF3gmSHtFpc5dNlQOIrJ+KL4oEF+qC2Wko 91jWCjFb6lI+NfVHLxEQuPpsl2Fv/rCSGcmIntpHjgoW/B27u28= =kdDe -----END PGP SIGNATURE----- --Sig_/yIN72=0uBg8/MAMRMg2G2hX-- From nobody Mon Feb 6 06:17:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C9B129DA3 for ; Mon, 6 Feb 2017 06:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 ljNYfKA6vsVm for ; Mon, 6 Feb 2017 06:17:53 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 8F7FA129DB1 for ; Mon, 6 Feb 2017 06:17:46 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id o65so25694332ybo.2 for ; Mon, 06 Feb 2017 06:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o8gMjDLk+GaY6jGbkrEQ0OIWfgDoicD5lMV/QIeSJNw=; b=eOK+Jre4mtNUplF/G3zG68KrUuUqsjy7wAJIeyI3t5m2viTsi6S9vz9rg2rxRjloQb L3IypniZ3d1+S5mX7dU0vrjg+4x2IRuNtn0yQ2F9I2WS3cGceWLIWsXCMmNop+mIkcDZ VWzXcwQE7g5MLTB79Lm+J9mqkj8dcaQEiD8KO0gLgtIMcjhu2ZnI5Z9FjPHBKMmBenho 3HPsejrij1vabjAT2AjSgdK/jIGOi/yZlytqd3gpc43z8evccq+3DbH6K2Whe5viDHaO BofSzEtL+iAxtyCM+0/xc5ayJFt4iont6fv7DdZhv7G0E3Zhg/OFmkApPPBLlJIY6uj1 c/UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o8gMjDLk+GaY6jGbkrEQ0OIWfgDoicD5lMV/QIeSJNw=; b=Gu2oGHy+JimG0KjdGNQRYqve54Y5EOnLgXX5fgb7Pe2CoZQ3rHYB86bfdUt13w0Ar5 2K8rKlBi4C6a8LbN+smzvtHQwUm5LLW0igMPh7xo6nkO1PCU+Lh9BrRbEWyRjQon3MQf IQHrR1N0IAcTNxMt0YjzBKyO3uqlh1kkAzEs4xRAN/OtLD1VLkP+JOSaNDGZDqmhB3ax uWgGmyoFZAO1t8yO3VLXkh6b5K+hZ0LE40OS+um6Nqxt8jaU12TuTZheBgHAqhsG6Yns njzrJXqaJi2yvoflx1UD65Amm+TCsDfPXiow1EYy1WLIa5Uj1UN7VxnuKrqHnOHC42F/ v14w== X-Gm-Message-State: AMke39kiaTMWc6E9Al2IdGjEkydd0mRRiZKj7GvdtYO2/lLe6qeMZU33OSm6wHhxqHZB1RBeBylUBJD85QzGg0CY X-Received: by 10.37.162.40 with SMTP id b37mr960774ybi.142.1486390665625; Mon, 06 Feb 2017 06:17:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.237.68 with HTTP; Mon, 6 Feb 2017 06:17:45 -0800 (PST) In-Reply-To: References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> From: Bob Harold Date: Mon, 6 Feb 2017 09:17:45 -0500 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=94eb2c198ec29f91f60547dd4be3 Archived-At: Cc: dnsop Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 14:17:55 -0000 --94eb2c198ec29f91f60547dd4be3 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 9:14 PM, Warren Kumari wrote: > Hi all, > > Was and I have updated this document to make it clearer and more > readable. Please take a read and let us know if any parts are unclear, > if you have any other feedback, etc. > > Is this close to done? > W > > On Fri, Feb 3, 2017 at 6:29 PM, wrote: > > > > A new version of I-D, draft-hardaker-rfc5011- > security-considerations-02.txt > > has been successfully submitted by Warren Kumari and posted to the > > IETF repository. > > > > Name: draft-hardaker-rfc5011-security-considerations > > Revision: 02 > > Title: Security Considerations for RFC5011 Publishers > > Document date: 2017-02-02 > > Group: Individual Submission > > Pages: 8 > > URL: https://www.ietf.org/internet- > drafts/draft-hardaker-rfc5011-security-considerations-02.txt > > Status: https://datatracker.ietf.org/doc/draft-hardaker-rfc5011- > security-considerations/ > > Htmlized: https://tools.ietf.org/html/draft-hardaker-rfc5011- > security-considerations-02 > > Diff: https://www.ietf.org/rfcdiff? > url2=draft-hardaker-rfc5011-security-considerations-02 > > > > Abstract: > > This document describes the math behind the minimum time-length that > > a DNS zone publisher must wait before using a new DNSKEY to sign > > records when supporting the RFC5011 rollover strategies. > Thanks for your work on this. Some minor formatting issues: Table of contents: sections 5 and 5.1 have large blank space in middle (as formatted at https://www.ietf.org/id/draft-hardaker-rfc5011-security-considerations-02.txt ) section 8 is wrapped unnecessarily Section 3: large space in first line Section 5: "poising" -> "poisoning" Section 5.1.1 "(a new)" -> "(anew)" Section 6 47 - 35 = 12 days (not 11)? -- Bob Harold --94eb2c198ec29f91f60547dd4be3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Feb 3, 2017 at 9:14 PM, Warren Kumari <warren@kumari.net> wrote:
Hi all,
Was and I have updated this document to make it clearer and more
readable. Please take a read and let us know if any parts are unclear,
if you have any other feedback, etc.

Is this close to done?
W

On Fri, Feb 3, 2017 at 6:29 PM,=C2=A0 <internet-drafts@ietf.org> wrote:
>
> A new version of I-D, draft-hardaker-rfc5011-security-considerati= ons-02.txt
> has been successfully submitted by Warren Kumari and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardaker-rfc5011-<= wbr>security-considerations
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Security Considerations for R= FC5011 Publishers
> Document date:=C2=A0 2017-02-02
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hardaker-rfc5011-security-considerations-02.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-harda= ker-rfc5011-security-considerations/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hardaker-rfc5011-<= wbr>security-considerations-02
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2= =3Ddraft-hardaker-rfc5011-security-considerations-02
>
> Abstract:
>=C2=A0 =C2=A0 This document describes the math behind the minimum time-= length that
>=C2=A0 =C2=A0 a DNS zone publisher must wait before using a new DNSKEY = to sign
>=C2=A0 =C2=A0 records when supporting the RFC5011 rollover strategies.<= br> =

Thanks for your work on this= .=C2=A0 Some minor formatting issues:

Table of con= tents:
sections 5 and 5.1 have large blank space in middle
<= div>(as formatted at=C2=A0https://www.ietf.org/id/draft-hard= aker-rfc5011-security-considerations-02.txt)
section 8 is wra= pped unnecessarily=C2=A0

Section 3:
larg= e space in first line

Section 5:
"poising"= -> "poisoning"

Section 5.1.1
"= (a new)" -> &= quot;(anew)&qu= ot;

Section 6=
47 - 35 =3D 12 days (not 11)?

--=C2=A0
Bob Harold
=C2=A0

--94eb2c198ec29f91f60547dd4be3-- From nobody Mon Feb 6 07:30:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7C3127076 for ; Mon, 6 Feb 2017 07:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, 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 XUC4lVjJCpeG for ; Mon, 6 Feb 2017 07:30:11 -0800 (PST) Received: from smtp117.ord1c.emailsrvr.com (smtp117.ord1c.emailsrvr.com [108.166.43.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181F6129E41 for ; Mon, 6 Feb 2017 07:30:09 -0800 (PST) Received: from smtp7.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 76DB9A0186; Mon, 6 Feb 2017 10:30:06 -0500 (EST) X-Auth-ID: ogud@ogud.com Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id E07D5A02F2; Mon, 6 Feb 2017 10:30:01 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [IPv6:2607:fb90:91e:147c:7a5e:1b92:696c:f8b3] ([UNAVAILABLE]. [172.56.21.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Mon, 06 Feb 2017 10:30:06 -0500 Date: Mon, 06 Feb 2017 09:29:58 -0600 User-Agent: K-9 Mail for Android In-Reply-To: References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----12591QIFVKSWFOSQJOGNZ7KEWKGKMT" Content-Transfer-Encoding: 7bit To: dnsop@ietf.org, Ted Lemon , John R Levine From: =?ISO-8859-1?Q?=D3lafur_Gudmundsson?= Message-ID: <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> Archived-At: Cc: dnsop WG Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:30:13 -0000 ------12591QIFVKSWFOSQJOGNZ7KEWKGKMT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted, What RFC are you referring to? Why do you think =2EARPA is for services? It's for infrastructure and homenet wants to join the infrastructure=2E It is waste of time arguing if name A or B is better take the one you can = get faster=2E =C3=93lafur On February 5, 2017 10:22:35 PM CST, Ted Lemon wrote: >The working group has consensus to give it a try=2E We may change our >minds >of it takes too long, but it seems worth exploring from a process >perspective anyway=2E > >On Feb 5, 2017 11:18 PM, "John R Levine" wrote: > >> I'm pretty sure I've explained it enough times on this mailing list >and in >>> the relevant documents by now=2E If you don't agree, maybe we should >just >>> accept that=2E If you don't remember the explanation, it's in the >homenet >>> naming architecture doc I wrote=2E >>> >> >> Well, OK, I took another look, and from what I can see, it's a belief >that >> people will find toaster=2Ehomenet=2Earpa harder or more confusing to >type than >> toaster=2Ehomenet=2E >> >> Just out of curiosity, how long is it worth waiting to get =2Ehomenet >rather >> than =2Ehomenet=2Earpa? If it took five more years, which at the curre= nt >rate >> seems optimistic, would homenet still be relevant? >> >> R's, >> John >> --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------12591QIFVKSWFOSQJOGNZ7KEWKGKMT Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted,

What RFC are you referring to?

Why do you think =2EARPA is for services?
It's for infrastructure and homenet wants to join the infrastructure= =2E

It is waste of time arguing if name A or B is better take the one you can = get faster=2E

=C3=93lafur


On February 5, 2017 10:22:35 PM CST, Te= d Lemon <mellon@fugue=2Ecom> wrote:
The working group has consensus to give it a try=2E = ; We may change our minds of it takes too long, but it seems worth explorin= g from a process perspective anyway=2E 

On Feb 5, 2017 11:18 PM, "John R Le= vine" <johnl@taugh=2Ecom&g= t; wrote:
I'm pretty sure I've explained it enough times on this mailing list and in=
the relevant documents by now=2E If you don't agree, maybe we should just<= br /> accept that=2E If you don't remember the explanation, it's in the homenet<= br /> naming architecture doc I wrote=2E

Well, OK, I took another look, and from what I can see, it's a belief that= people will find toaster=2Ehomenet=2Earpa harder or more confusing to type= than toaster=2Ehomenet=2E

Just out of curiosity, how long is it worth waiting to get =2Ehomenet rath= er than =2Ehomenet=2Earpa?  If it took five more years, which at the c= urrent rate seems optimistic, would homenet still be relevant?

R's,
John

--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------12591QIFVKSWFOSQJOGNZ7KEWKGKMT-- From nobody Mon Feb 6 07:36:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4ED129E70 for ; Mon, 6 Feb 2017 07:36:15 -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, RP_MATCHES_RCVD=-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 bIjwUwCzCEbv for ; Mon, 6 Feb 2017 07:36:14 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D54D129E41 for ; Mon, 6 Feb 2017 07:36:14 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 076312421227; Mon, 6 Feb 2017 15:36:12 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> Date: Mon, 6 Feb 2017 15:36:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <629EE965-1E35-4477-B883-B8771942C1AF@rfc1035.com> References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF dnsop WG Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:36:15 -0000 > On 6 Feb 2017, at 15:29, =C3=93lafur Gudmundsson = wrote: >=20 > It is waste of time arguing if name A or B is better take the one you = can get faster. +100 Says he wishing the arguments over A or B (for some definition of both) = would just go away and never return. From nobody Mon Feb 6 07:52:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3207129EA6 for ; Mon, 6 Feb 2017 07:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiwstiZN7IUb for ; Mon, 6 Feb 2017 07:52:56 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B406129EA5 for ; Mon, 6 Feb 2017 07:52:56 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id x49so108358673qtc.2 for ; Mon, 06 Feb 2017 07:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jy+sbE/A+LtJwQo74LlZtQ+eO5LwU/QEVGieGyZwAEg=; b=euw/vtFXUB1vYWyVqI3xl2LXyUEN6tuafKy3lxeDqFdTpHs2NznTCm8Mao/Q3ZlBA4 0AWYGpP3jj6mb0Qlc92NMLxi6skBJYKTqxcFPTKCl1OmQon/ycw5/F88NVFtD6qkgmLW 810UCpGn0DeQklultsFIeba6SLrbx963LHcp9BbQtyBycgDb0kQRfcuIgMAxxCVnytDy ujX4icicJZG+tNWPzpa/pq8Pvl5YAps0KEZj97NNKmBVDn1fBKdj3/H56xuVncyPLHy2 wcpTgTB2XzvUifMQvGJtUevCl0hwEBMeDmFMpIUHBAqHgDTdS8qbp1N5hYDQTzHRq8Ke QuXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jy+sbE/A+LtJwQo74LlZtQ+eO5LwU/QEVGieGyZwAEg=; b=OwP9Im1KBysACDkeXeaXQm6ncxY4aivTpLlx94pGWocgrbFA8YI0cgZHQdiwCa25SL FDexoWNuSFIY21qD6vWKbH9AasnOu3yBalsDW3Hg1jblX9RFI7eMS96wFCjWQO4mRdNo VzAT6rD0lqG4tXi8FXPLOWI+1OhGtG3gE+sLdhlefSM4WUAakSmmpdC2yVe2OwS1wrnk K545pROr5vBcwD1MTMtILoMD6HjVM5H5zd1iqpGoo/LdYiDp6no60gI72cfi2lpExcrt epKaFNN3wSgl0zKkhXZWmuAYdYDYxA5SZS2H5hv38d7t5p5Uawv34KmtT9rIK4xSV1iX pPxw== X-Gm-Message-State: AMke39l6CzpqSSrkSy6Igxn05SmOWv42GqwPd1CLb9GXZVKBgduS4F99E5dW2cp9q5ktZg== X-Received: by 10.200.34.77 with SMTP id p13mr10331778qtp.35.1486396375221; Mon, 06 Feb 2017 07:52:55 -0800 (PST) Received: from [172.16.3.59] (c-24-91-157-47.hsd1.ma.comcast.net. [24.91.157.47]) by smtp.gmail.com with ESMTPSA id b36sm831526qte.21.2017.02.06.07.52.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 07:52:54 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-11E18364-4440-4392-A3BF-29858B5C31DC Mime-Version: 1.0 (1.0) From: Ralph Droms X-Mailer: iPhone Mail (14D27) In-Reply-To: <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> Date: Mon, 6 Feb 2017 10:52:53 -0500 Content-Transfer-Encoding: 7bit Message-Id: <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> To: =?utf-8?Q?=C3=93lafur_Gudmundsson?= Archived-At: Cc: John R Levine , dnsop@ietf.org, Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:52:57 -0000 --Apple-Mail-11E18364-4440-4392-A3BF-29858B5C31DC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Feb 6, 2017, at 10:29 AM, =C3=93lafur Gudmundsson wrote= : >=20 > Ted, >=20 > What RFC are you referring to? >=20 > Why do you think .ARPA is for services? > It's for infrastructure and homenet wants to join the infrastructure. >=20 > It is waste of time arguing if name A or B is better take the one you can g= et faster. The WG has considered the alternatives, and WG consensus is to specify ".hom= enet" - Ralph >=20 > =C3=93lafur >=20 >=20 >> On February 5, 2017 10:22:35 PM CST, Ted Lemon wrote: >> The working group has consensus to give it a try. We may change our mind= s of it takes too long, but it seems worth exploring from a process perspect= ive anyway.=20 >>=20 >> On Feb 5, 2017 11:18 PM, "John R Levine" wrote: >>>> I'm pretty sure I've explained it enough times on this mailing list and= in >>>> the relevant documents by now. If you don't agree, maybe we should just= >>>> accept that. If you don't remember the explanation, it's in the homenet= >>>> naming architecture doc I wrote. >>>=20 >>> Well, OK, I took another look, and from what I can see, it's a belief th= at people will find toaster.homenet.arpa harder or more confusing to type th= an toaster.homenet. >>>=20 >>> Just out of curiosity, how long is it worth waiting to get .homenet rath= er than .homenet.arpa? If it took five more years, which at the current rat= e seems optimistic, would homenet still be relevant? >>>=20 >>> R's, >>> John >=20 > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail-11E18364-4440-4392-A3BF-29858B5C31DC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Feb 6= , 2017, at 10:29 AM, =C3=93lafur Gudmundsson <ogud@ogud.com> wrote:

Ted,

What RFC are you referring to?

Why do you think .ARPA is for services?
It's for infrastructure and homenet wants to join the infrastructure.

It is waste of time arguing if name A or B is better take the one you can ge= t faster.

The WG has considered the alt= ernatives, and WG consensus is to specify ".homenet"

- Ra= lph


=C3=93lafur


On February 5, 2017 10:22:35 PM CST, Ted L= emon <mellon@fugue.com> wrote:=
The working group has consensus to give it a try.  We= may change our minds of it takes too long, but it seems worth exploring fro= m a process perspective anyway. 

On Feb 5, 2017 11:18 PM, "John R Levine" <johnl@taugh.com> wrote:
I'm pretty sure I've explained it enough times on this mailing list and in the relevant documents by now. If you don't agree, maybe we should just
accept that. If you don't remember the explanation, it's in the homenet
naming architecture doc I wrote.

Well, OK, I took another look, and from what I can see, it's a belief that p= eople will find toaster.homenet.arpa harder or more confusing to type than t= oaster.homenet.

Just out of curiosity, how long is it worth waiting to get .homenet rather t= han .homenet.arpa?  If it took five more years, which at the current ra= te seems optimistic, would homenet still be relevant?

R's,
John

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
____________________________= ___________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/lis= tinfo/dnsop
= --Apple-Mail-11E18364-4440-4392-A3BF-29858B5C31DC-- From nobody Mon Feb 6 07:56:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1555129EB2 for ; Mon, 6 Feb 2017 07:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 9nqMMBxQkIx0 for ; Mon, 6 Feb 2017 07:56:03 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB91129412 for ; Mon, 6 Feb 2017 07:56:03 -0800 (PST) Received: from [46.227.151.81] (port=58247 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1cale3-0003cU-T1 (Exim 4.72) for dnsop@ietf.org (return-path ); Mon, 06 Feb 2017 15:55:59 +0000 To: dnsop@ietf.org References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> From: Ray Bellis Message-ID: Date: Mon, 6 Feb 2017 15:56:01 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:56:05 -0000 On 06/02/2017 15:29, lafur Gudmundsson wrote: > Ted, > > What RFC are you referring to? > > Why do you think .ARPA is for services? > It's for infrastructure and homenet wants to join the infrastructure. > > It is waste of time arguing if name A or B is better take the one you > can get faster. It really isn't. If I type "arpa" into Google (without the leading dot) I don't get the new "Address and Routing Parameter Area" definition. I get a big side bar with the DARPA logo and mention of the US DoD everywhere. That might well be fine for us "in the know" techies, but as far as I'm concerned it's not fine for the residential users that are the target market for Homenet. That's even more true now than it was before November. Ray (no hat) From nobody Mon Feb 6 07:57:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255B6129EBF for ; Mon, 6 Feb 2017 07:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X02hjcDN2Rrj for ; Mon, 6 Feb 2017 07:57:03 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 3F1BF129EB5 for ; Mon, 6 Feb 2017 07:57:03 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id v23so108815895qtb.0 for ; Mon, 06 Feb 2017 07:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GKpSvCZ5ZJ/FJY8KayEGjRIlxMNTQxEdzQgiP+sXlvI=; b=mNC7m3deGk0kuq2YHVquiZkC/hR56CRXeBDStj0ANwpB7TZlKBJTcttJCqgvRDEm3C beq+VpOOIePcf1NgXNeYfxRLDDws5oWezEji/Qz7BUEBcrF9/70Sm4MQLjCRJlGMxcQQ Nz4jHz+tG7tdv7QV6a62EYFEtVjARPLvI2AGmFZcMxpFCbGeQ1ML18GyRC8QrEu3Z9gA lRq9f2/EmWMgBODsp3EdmPjBi/xQQVojeO1JEBnXm1NPb/PoX2gRNrhwgzxauRtdlaaH c9bfP3C4fXNfhaK7tr8aP9mso5Dqkz5DgF4XS6jKB3k7/PZ9cPvotLEdnI/mU/BfQuEb LuUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GKpSvCZ5ZJ/FJY8KayEGjRIlxMNTQxEdzQgiP+sXlvI=; b=n3mFOSbLYihZJqg2g2QpeVXoS9m/qf+dNbSuqZOBac+e4d1AYeLoOBSWUwHi5qopCD nHAsNXMcokwae0eRdaac/v6wZw7dPnnvoUzPS6fuNpwUTOiQGL5SMP0tNC5Zpz3sy2u8 WBUc73GYIpksJcj9UvJ0RRmIKjKkoXpM2k0eQHaPzab4VMXHzDU6oSzIJcioQM23ezrs GvyxvCA24Y2V/dKSDHuhW2WTOsVetroM42A7MGXS1wmODzl9w/V8y8VMuvWfs4iFKVvN /Ddh7aKC+pS1NsCRf5HpT7w7TPR4lgjq9a2VqYOatKN/O7rIQxra13lv9tJQorsczcGY xtpg== X-Gm-Message-State: AMke39m84n4RooA0jDYCdsJS77lOyJ7b7amFE82Z3oepYKWnQMYDAamim0L/xCOjtnbyJg== X-Received: by 10.237.37.202 with SMTP id y10mr10632470qtc.170.1486396622288; Mon, 06 Feb 2017 07:57:02 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id u49sm817856qtc.44.2017.02.06.07.57.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 07:57:01 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8A7B47B1-ADD8-4DB5-8035-21B2A431BA15" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 6 Feb 2017 10:56:59 -0500 In-Reply-To: <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> To: =?utf-8?Q?=C3=93lafur_Gudmundsson?= References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop@ietf.org, John R Levine Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:57:05 -0000 --Apple-Mail=_8A7B47B1-ADD8-4DB5-8035-21B2A431BA15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 6, 2017, at 10:29 AM, =C3=93lafur Gudmundsson = wrote: > What RFC are you referring to? I wasn't referring to an RFC=E2=80=94I was referring to the homenet = naming architecture document that we've been working on. > Why do you think .ARPA is for services? > It's for infrastructure and homenet wants to join the infrastructure. What made you think I though that. What I mean is that it sounds like = it's something global, not something local, because of the .arpa = subdomain. > It is waste of time arguing if name A or B is better take the one you = can get faster. This is your opinion. I don't recall hearing you express it when I = asked the working group which option they preferred. We have a = substantial amount of time to waste; the working group decided to waste = it. I don't see a problem with that. If we need to revisit this = later, when it becomes a pressing issue, I think we have a pretty clear = expedient solution, as you say, so there is no harm in trying for the = solution that we want, and that we thing produces the better result for = end users. --Apple-Mail=_8A7B47B1-ADD8-4DB5-8035-21B2A431BA15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 6, 2017, at 10:29 AM, =C3=93lafur Gudmundsson <ogud@ogud.com> = wrote:
What RFC are you referring to?

I wasn't referring to an RFC=E2=80=94I was referring to = the homenet naming architecture document that we've been working = on.

Why do you think .ARPA is for = services?
It's for infrastructure and homenet wants to = join the infrastructure.

What made you = think I though that.   What I mean is that it sounds like it's = something global, not something local, because of the .arpa = subdomain.

It is waste of time = arguing if name A or B is better take the one you can get = faster.

This= is your opinion.   I don't recall hearing you express it when I = asked the working group which option they preferred.   We have a = substantial amount of time to waste; the working group decided to waste = it.   I don't see a problem with that.   If we need to revisit = this later, when it becomes a pressing issue, I think we have a pretty = clear expedient solution, as you say, so there is no harm in trying for = the solution that we want, and that we thing produces the better result = for end users.

= --Apple-Mail=_8A7B47B1-ADD8-4DB5-8035-21B2A431BA15-- From nobody Mon Feb 6 07:57:34 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54146129EB5 for ; Mon, 6 Feb 2017 07:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, 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 tTRXX3i4UAbU for ; Mon, 6 Feb 2017 07:57:31 -0800 (PST) Received: from smtp109.iad3a.emailsrvr.com (smtp109.iad3a.emailsrvr.com [173.203.187.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39E1129EB2 for ; Mon, 6 Feb 2017 07:57:31 -0800 (PST) Received: from smtp22.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C09446938; Mon, 6 Feb 2017 10:57:28 -0500 (EST) X-Auth-ID: ogud@ogud.com Received: by smtp22.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id D461C67C7; Mon, 6 Feb 2017 10:57:17 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [IPv6:2607:fb90:91e:147c:7a5e:1b92:696c:f8b3] ([UNAVAILABLE]. [172.56.21.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Mon, 06 Feb 2017 10:57:28 -0500 Date: Mon, 06 Feb 2017 09:57:15 -0600 User-Agent: K-9 Mail for Android In-Reply-To: <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----2DR8N0X9HD5PPO6C7WX0V4SNGLH6YA" Content-Transfer-Encoding: 7bit To: Ralph Droms From: =?ISO-8859-1?Q?=D3lafur_Gudmundsson?= Message-ID: Archived-At: Cc: John R Levine , dnsop@ietf.org, Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:57:33 -0000 ------2DR8N0X9HD5PPO6C7WX0V4SNGLH6YA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ralph,=20 A WG can come to a consensus on a topic without all information available= =2E Now go back and see if reality changes consensus=2E Just my =2E02 cents=2E =C3=93lafur On February 6, 2017 9:52:53 AM CST, Ralph Droms wrote: > > >> On Feb 6, 2017, at 10:29 AM, =C3=93lafur Gudmundsson >wrote: >>=20 >> Ted, >>=20 >> What RFC are you referring to? >>=20 >> Why do you think =2EARPA is for services? >> It's for infrastructure and homenet wants to join the infrastructure=2E >>=20 >> It is waste of time arguing if name A or B is better take the one you >can get faster=2E > >The WG has considered the alternatives, and WG consensus is to specify >"=2Ehomenet" > >- Ralph > >>=20 >> =C3=93lafur >>=20 >>=20 >>> On February 5, 2017 10:22:35 PM CST, Ted Lemon >wrote: >>> The working group has consensus to give it a try=2E We may change our >minds of it takes too long, but it seems worth exploring from a process >perspective anyway=2E=20 >>>=20 >>> On Feb 5, 2017 11:18 PM, "John R Levine" wrote: >>>>> I'm pretty sure I've explained it enough times on this mailing >list and in >>>>> the relevant documents by now=2E If you don't agree, maybe we should >just >>>>> accept that=2E If you don't remember the explanation, it's in the >homenet >>>>> naming architecture doc I wrote=2E >>>>=20 >>>> Well, OK, I took another look, and from what I can see, it's a >belief that people will find toaster=2Ehomenet=2Earpa harder or more >confusing to type than toaster=2Ehomenet=2E >>>>=20 >>>> Just out of curiosity, how long is it worth waiting to get =2Ehomenet >rather than =2Ehomenet=2Earpa? If it took five more years, which at the >current rate seems optimistic, would homenet still be relevant? >>>>=20 >>>> R's, >>>> John >>=20 >> --=20 >> Sent from my Android device with K-9 Mail=2E Please excuse my brevity= =2E >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dnsop --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------2DR8N0X9HD5PPO6C7WX0V4SNGLH6YA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ralph,
A WG can come to a consensus on a topic without all information available= =2E
Now go back and see if reality changes consensus=2E

Just my =2E02 cents=2E


=C3=93lafur

On February 6, 2017 9:52:53 = AM CST, Ralph Droms <rdroms=2Eietf@gmail=2Ecom> wrote:


On Feb 6, 2017, at 10:29 AM, &Oacut= e;lafur Gudmundsson <ogud@ogud=2Ecom<= /a>> wrote:


The WG has considere= d the alternatives, and WG consensus is to specify "=2Ehomenet"


Ólafur


On February 5, 2017 10:22:35 PM CST= , Ted Lemon <mellon@fugue=2Ecom> wrote:
The working group has consensus to give it a try=2E = ; We may change our minds of it takes too long, but it seems worth explorin= g from a process perspective anyway=2E 

On Feb 5, 2017 11:18 PM, "John R Le= vine" <johnl@taugh=2Ecom&g= t; wrote:
I'm pretty sure I've explained it enough times on this mailing list and in=
the relevant documents by now=2E If you don't agree, maybe we should just<= br /> accept that=2E If you don't remember the explanation, it's in the homenet<= br /> naming architecture doc I wrote=2E

Well, OK, I took another look, and from what I can see, it's a belief that= people will find toaster=2Ehomenet=2Earpa harder or more confusing to type= than toaster=2Ehomenet=2E

Just out of curiosity, how long is it worth waiting to get =2Ehomenet rath= er than =2Ehomenet=2Earpa?  If it took five more years, which at the c= urrent rate seems optimistic, would homenet still be relevant?

R's,
John

--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
_____________________= __________________________
DNSOP mailing list
DNSOP@ietf=2Eorg
https://= www=2Eietf=2Eorg/mailman/listinfo/dnsop
=
--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------2DR8N0X9HD5PPO6C7WX0V4SNGLH6YA-- From nobody Mon Feb 6 07:59:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309D3129EC5 for ; Mon, 6 Feb 2017 07:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2Ea3iBD0mkY for ; Mon, 6 Feb 2017 07:59:13 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 D5326129E94 for ; Mon, 6 Feb 2017 07:59:12 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id s140so59222823qke.0 for ; Mon, 06 Feb 2017 07:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nmjD6gUHGDC+b5ixTLtYE0g8nFi1eTRlXidC+LJTgKQ=; b=CalNYzcNlE8f/Y3QhLuWhYg3inpiol2+AcK13V6mB8RYfePvPLE+onXw0LkDhva8Gf elHGpxjx2N4spFvQJ3ChCUZ9HZ04IRsMSpVrLCzo8iNfz8fqvCUAr81dzgr+8QOsE/ba 131GkVAxgwjx2jZz9gMPjxmo9yyf76BqFkBLXMmXELrn5Sf1Og1ekbch12RAG7AnUKog ICMSvcN75vgyOeRqr1Hflq+nCsMv9CotTozh1IR1xZ6XYKI7j4H6G7gnIizKrF0WESU0 QtqJg5NFYfqNkexh5uGGioA4XizLTSannW59dj4VOVN+LNl+lF5NE+iUXCRjyDC9wxy3 Po9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nmjD6gUHGDC+b5ixTLtYE0g8nFi1eTRlXidC+LJTgKQ=; b=EXY2GUooXppLNhtUpmmm27zBRA9c6XNoma5Zv7ICBAmxDfrGCuNLks7mPs+TEB8pZP TDg8C1SD1hUwrwH6XC/26B0XX7tJWUPo0Pnv9oMaF3ORU2oT1cJGtVKqz3t3149pKgtx 9f4x93BjG/AJNPckgrd2NhF73yFoTH0UA9PBhY34F2zfmLUWO+quQS+Ki2hu/XtCemtm 8M2SPl7GKHBd9R79V3n453QTujGbpEqfbrDnf2B2Nssbm96K6VFCCNqwe2SjrFxXHZuc XJey+tDgvK7zu8JjseEbkHb/wMo4eC+0pAMPMjSFPzrgVhKjN3bupsBWAusjLTRx4h3n hTeA== X-Gm-Message-State: AMke39kAeLcnp+FbDmVZ8OiZJuLrIeOzb7JSkmKc6pKIpDejEcyrapWJzV5D+XViz6y5hA== X-Received: by 10.55.26.218 with SMTP id l87mr10888538qkh.59.1486396751966; Mon, 06 Feb 2017 07:59:11 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id o199sm831588qke.35.2017.02.06.07.59.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 07:59:10 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9804043F-E585-46C0-BF80-B1444F7FDC56" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 6 Feb 2017 10:59:09 -0500 In-Reply-To: To: =?utf-8?Q?=C3=93lafur_Gudmundsson?= References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop@ietf.org, John R Levine , Ralph Droms Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:59:14 -0000 --Apple-Mail=_9804043F-E585-46C0-BF80-B1444F7FDC56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 6, 2017, at 10:57 AM, =C3=93lafur Gudmundsson = wrote: > A WG can come to a consensus on a topic without all information = available. > Now go back and see if reality changes consensus. I presented a detailed explanation of the tradeoffs, which the working = group considered. If you think something has changed, you should first = review the discussion, since it sounds like you never read that detailed = explanation. In that explanation, I made the precise point you are = making: that homenet.arpa would be more expedient than .homenet. --Apple-Mail=_9804043F-E585-46C0-BF80-B1444F7FDC56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 6, 2017, at 10:57 AM, =C3=93lafur Gudmundsson <ogud@ogud.com> = wrote:
A WG can come to a consensus on a topic without = all information available.
Now go back and see if reality changes = consensus.

I= presented a detailed explanation of the tradeoffs, which the working = group considered.   If you think something has changed, you should = first review the discussion, since it sounds like you never read that = detailed explanation.  In that explanation, I made the precise = point you are making: that homenet.arpa would be more expedient than = .homenet.

= --Apple-Mail=_9804043F-E585-46C0-BF80-B1444F7FDC56-- From nobody Mon Feb 6 08:04:46 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811CE129ED1 for ; Mon, 6 Feb 2017 08:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 FT9OkskFt8RV for ; Mon, 6 Feb 2017 08:04:43 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C20129EB2 for ; Mon, 6 Feb 2017 08:04:42 -0800 (PST) Received: from [172.20.6.227] (unknown [172.20.6.227]) by mail.nic.cz (Postfix) with ESMTPSA id CEC55600C8 for ; Mon, 6 Feb 2017 17:04:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1486397081; bh=JTRfGkqAmne+C6iI6FuqoH8r8t+lwAiQ4RRggkOTFaE=; h=From:To:Date; b=hPFFqV0Q9NZ6WPzutM/vBfK743YUWgcA67dXfi6qixQKhCb2Ahusy3hjBNO3HKi1O tnmIdrBlY8UWhgXhB9BlLeuv6qP7iBAcXNcbqKgV+eehlDgEm6HqHiPIwB/P/J23OI 6JNGd9ZOGJgCkQx7SPI1UOTpHtNyqzFR9FDsKd0Q= From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= To: dnsop@ietf.org References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> <20170206131153.52329a04@pallas.home.time-travellers.org> Organization: CZ.NIC Message-ID: <7dd02b3e-910b-b287-14cf-d7fe7755cd2d@nic.cz> Date: Mon, 6 Feb 2017 17:04:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170206131153.52329a04@pallas.home.time-travellers.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:04:44 -0000 On 02/06/2017 01:11 PM, Shane Kerr wrote: > Warren, > > I am still wondering about the: > > 3 * (DNSKEY RRSIG Signature Validity) / 2 > > Term in the draft, which I see survived the update. > > Why is this not just the DNSKEY RRSIG Signature Validity? In principle > once the signature has expired it cannot be used to replay the old > DNSKEY RRset right? Shane was faster than me, I'm also wondering how 3/2 got here. I expect that 3/2 = 2/2 to avoid replay attack + 1/2 from RFC 5011. In any case, it would be awesome if each component in section 6 had own explanation what role the particular component plays in the equation. -- Petr Špaček @ CZ.NIC > > Cheers, > > -- > Shane > > At 2017-02-03 21:14:03 -0500 > Warren Kumari wrote: > >> Hi all, >> >> Was and I have updated this document to make it clearer and more >> readable. Please take a read and let us know if any parts are unclear, >> if you have any other feedback, etc. >> >> Is this close to done? From nobody Mon Feb 6 08:12:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B25129EDB for ; Mon, 6 Feb 2017 08:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nl7lIXKgcdKT for ; Mon, 6 Feb 2017 08:12:04 -0800 (PST) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 87EAA129ED8 for ; Mon, 6 Feb 2017 08:12:04 -0800 (PST) Received: by mail-qt0-x242.google.com with SMTP id h53so15402882qth.3 for ; Mon, 06 Feb 2017 08:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=BNL1wkOxWiNnWvXl5Fi22+gYC6OMc9Kyl1on0yMOWfo=; b=rs8S9/EcIKkScYaMif6i8D0d9mE25bR4eQ2P5jUILcBAt9eaPe/TN6oel/Cx6IJAdD 6HLYaaGxJjfeyBSM4nnTgng9EjmUle2s5waFiMYFWpYLJiNMf4Kh9bZxjxmyWRwHwJ1b ldbHuc0U9FPR0fZhp/dd0GQ+oiNIVaJz/4ge3SNGKteLGcdGA1h7uOSMNmuwY51vWct6 7fApQFtPAazsWXfXyyXFpTttGGBm6CEzDILd6nkqEvFx4nl2O1TqYG6O2SL/Fg/bIqQJ X95GYddcJTtLEd1xYJbVsfEzZPPUliVBO4eDMKRwpCO1dJscW2Q/RSU2hAPeSH69mBXZ v4rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=BNL1wkOxWiNnWvXl5Fi22+gYC6OMc9Kyl1on0yMOWfo=; b=ESmfZDuVtOJO4OTPqcelz0ZaqXo7TfDCUXQmLxF8Zx8DXA1KzVU8sRat+ljsIBANfk xVj0GLTmyLy6ztH9zS9KubhinMEFu44pGskcU5YUpitxxxRjxq6Q885q0OgUk/6aq5L1 gqyrg2ZDlWAgDfUaX2O2pl9MusPi6ZAVaFQoWCIfamGu46C8/whdP0Vywv0IrbiXXz69 GsYhuRPcuoMRmIgiCqQfmaobxeCPUeqUQDAnZmgUCXOVzdEMUxRUXGtrSuLE7g2mlcUo 7E0wOShgr14Qzpi8IQ0WuF87IHjsqlgVJMDPB+GTCSLgnibvt4t9GccTdGX8Yv6RafDb ibRQ== X-Gm-Message-State: AMke39l8TZG6lijuId+D/NqjjzcrRRIlwUWogvlKb/QrZydrQSYp55pQWQ2wXuBLQ66QBg== X-Received: by 10.237.53.77 with SMTP id b13mr10634477qte.151.1486397523569; Mon, 06 Feb 2017 08:12:03 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:b01a:2951:5c86:cdc5? ([2601:181:c381:c20:b01a:2951:5c86:cdc5]) by smtp.gmail.com with ESMTPSA id r10sm888114qte.1.2017.02.06.08.12.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Feb 2017 08:12:02 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_93AE260D-F9F2-4A72-A49C-6564B1827A9B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: Date: Mon, 6 Feb 2017 11:12:01 -0500 Message-Id: <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> To: =?utf-8?Q?=C3=93lafur_Gudmundsson?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Ted Lemon , dnsop@ietf.org, John R Levine , Ralph Droms Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:12:06 -0000 --Apple-Mail=_93AE260D-F9F2-4A72-A49C-6564B1827A9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Before this goes any further, I=E2=80=99m not sure an incomplete = rehashing of the consensus in another WG is a good use of our time. For now, let=E2=80=99s keep it relevant to the decision this WG has to = make, about what to do with .alt and whether it=E2=80=99s important to = us to accommodate cases like .homenet. So far, it seems that the = .homenet case is much like =E2=80=9Clocally-served zones=E2=80=9D. thanks, Suzanne > On Feb 6, 2017, at 10:57 AM, =C3=93lafur Gudmundsson = wrote: >=20 >=20 > Ralph,=20 > A WG can come to a consensus on a topic without all information = available. > Now go back and see if reality changes consensus. >=20 > Just my .02 cents. >=20 >=20 > =C3=93lafur >=20 > On February 6, 2017 9:52:53 AM CST, Ralph Droms = wrote: >=20 >=20 > On Feb 6, 2017, at 10:29 AM, =C3=93lafur Gudmundsson > wrote: >=20 >> Ted, >>=20 >> What RFC are you referring to? >>=20 >> Why do you think .ARPA is for services? >> It's for infrastructure and homenet wants to join the infrastructure. >>=20 >> It is waste of time arguing if name A or B is better take the one you = can get faster. >=20 > The WG has considered the alternatives, and WG consensus is to specify = ".homenet" >=20 > - Ralph >=20 >>=20 >> =C3=93lafur >>=20 >>=20 >> On February 5, 2017 10:22:35 PM CST, Ted Lemon > wrote: >> The working group has consensus to give it a try. We may change our = minds of it takes too long, but it seems worth exploring from a process = perspective anyway.=20 >>=20 >> On Feb 5, 2017 11:18 PM, "John R Levine" > wrote: >> I'm pretty sure I've explained it enough times on this mailing list = and in >> the relevant documents by now. If you don't agree, maybe we should = just >> accept that. If you don't remember the explanation, it's in the = homenet >> naming architecture doc I wrote. >>=20 >> Well, OK, I took another look, and from what I can see, it's a belief = that people will find toaster.homenet.arpa harder or more confusing to = type than toaster.homenet. >>=20 >> Just out of curiosity, how long is it worth waiting to get .homenet = rather than .homenet.arpa? If it took five more years, which at the = current rate seems optimistic, would homenet still be relevant? >>=20 >> R's, >> John >>=20 >> --=20 >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop = >=20 > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_93AE260D-F9F2-4A72-A49C-6564B1827A9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Before = this goes any further, I=E2=80=99m not sure an incomplete rehashing of = the consensus in another WG is a good use of our time.

For now, let=E2=80=99s = keep it relevant to the decision this WG has to make, about what to do = with .alt and whether it=E2=80=99s important to us to accommodate cases = like .homenet. So far, it seems that the .homenet case is much like = =E2=80=9Clocally-served zones=E2=80=9D.


thanks,
Suzanne

On Feb 6, 2017, at 10:57 AM, =C3=93lafur Gudmundsson <ogud@ogud.com> = wrote:


Ralph,
A WG can come to a consensus on a topic without all information = available.
Now go back and see if reality changes consensus.

Just my .02 cents.


=C3=93lafur

On = February 6, 2017 9:52:53 AM CST, Ralph Droms <rdroms.ietf@gmail.com> wrote:


On Feb 6, 2017, at 10:29 AM, =C3=93lafur = Gudmundsson <ogud@ogud.com> wrote:

Ted,

What RFC are you referring to?

Why do you think .ARPA is for services?
It's for infrastructure and homenet wants to join the infrastructure.

It is waste of time arguing if name A or B is better take the one you = can get faster.

The WG has considered the alternatives, and WG = consensus is to specify ".homenet"

- Ralph


=C3=93lafur


On February 5, = 2017 10:22:35 PM CST, Ted Lemon <mellon@fugue.com> wrote:
The working group has consensus to give it = a try.  We may change our minds of it takes too long, but it seems = worth exploring from a process perspective anyway. 

On Feb = 5, 2017 11:18 PM, "John R Levine" <johnl@taugh.com> wrote:
I'm pretty sure I've explained it enough times on this mailing list and = in
the relevant documents by now. If you don't agree, maybe we should = just
accept that. If you don't remember the explanation, it's in the = homenet
naming architecture doc I wrote.

Well, OK, I took another look, and from what I can see, it's a belief = that people will find toaster.homenet.arpa harder or more confusing to = type than toaster.homenet.

Just out of curiosity, how long is it worth waiting to get .homenet = rather than .homenet.arpa?  If it took five more years, which at = the current rate seems optimistic, would homenet still be relevant?

R's,
John

--
Sent from my Android device with K-9 Mail. Please excuse my = brevity.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--
Sent from my Android device with K-9 Mail. Please excuse my = brevity.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

= --Apple-Mail=_93AE260D-F9F2-4A72-A49C-6564B1827A9B-- From nobody Mon Feb 6 08:15:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A850129ED1 for ; Mon, 6 Feb 2017 08:15:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 dEvtgPNxF16U for ; Mon, 6 Feb 2017 08:15:20 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606D5129EAC for ; Mon, 6 Feb 2017 08:15:20 -0800 (PST) Received: from [46.227.151.81] (port=58661 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1calwi-0003yc-Um (Exim 4.72) for dnsop@ietf.org (return-path ); Mon, 06 Feb 2017 16:15:16 +0000 To: dnsop@ietf.org References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> From: Ray Bellis Message-ID: Date: Mon, 6 Feb 2017 16:15:18 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:15:21 -0000 On 06/02/2017 16:12, Suzanne Woolf wrote: > Hi, > > Before this goes any further, Im not sure an incomplete rehashing of > the consensus in another WG is a good use of our time. +1 :) > For now, lets keep it relevant to the decision this WG has to make, > about what to do with .alt and whether its important to us to > accommodate cases like .homenet. So far, it seems that the .homenet case > is much like locally-served zones. Yes, that's right, with the caveat that all existing locally served zones are in the reverse space - there's no forward zones registered (yet). Ray From nobody Mon Feb 6 08:18:44 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B26129EF8 for ; Mon, 6 Feb 2017 08:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5dEOCl_Ghw0 for ; Mon, 6 Feb 2017 08:18:41 -0800 (PST) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 8CA9C129EF6 for ; Mon, 6 Feb 2017 08:18:41 -0800 (PST) Received: by mail-qk0-x242.google.com with SMTP id 11so9190840qkl.0 for ; Mon, 06 Feb 2017 08:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0iAAHayQ1g6bBJBpzLuP7tJWE8aVeSkf7sIp4vJQ0f0=; b=aJqFariQyqbxFulMxb8LUpMXXJZyIqGEXsxjRWHtSMNYWsGZNyCefbgf9xcQklfAlI YPQLsWNlRkITVjtY/Ete0Ix9ifS61AAwb46Ej9PpTGKk7O7cJaUGtM+QnJRats6mKNag 52L1rxwbzQ//8wq8dUazGNtRJ5ryu7bsPCwpnbkvgy4pTge0LZRnIMPFO//mbC8eC9uL bDqjtq15CLhNQ9GfQdGpH7hUmVzYGv71dfaHGsSlP6Cg2vz+wO3Qq8DK6UEA+5pxuJiu skAhVW01X1g+7+LKquSFkL3sOfOVdpIuNRsZLLUquzKNLwxhsTtDNlOnG3sFtIEzLQj2 v6vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0iAAHayQ1g6bBJBpzLuP7tJWE8aVeSkf7sIp4vJQ0f0=; b=rWnItHJX8FiW+ByeTJ5KHelN6rIdzc9E4e4V/28+Brn6MJXKsfUHaoL5S1NBKFtUL4 ILgJP0vR8Ge+FXOvUaNoXVWZ+yP0owQLbuLclo5tcNWT/MCrTHpPQT2/8j+7gQ+FWItI Fd0tbnbyvPSib478/biso2131nBL6AabVZ9+nXESMwBSYBu7sDy0YmRfJPg9YMtqk7Tg fWQqChwIpZXWYC1l/yLt20xndJWWAkBUcbyHzrqbQd0gzlt3l9mzFKsGzqo57E3LnYxy SIB4XERIghs8d32m+7r3M6/B1GcsC7Xvug94YDp0cNPKAWnMPKli9YBL4PFcteTRLMuP EY2Q== X-Gm-Message-State: AMke39nYR/FcWNXb/PzHO6lPs+ZSM2mykZZq/SxA6/NgPm8BEGYCG4pRjEzmq7H5I24zeA== X-Received: by 10.55.19.16 with SMTP id d16mr11415666qkh.179.1486397920566; Mon, 06 Feb 2017 08:18:40 -0800 (PST) Received: from [10.0.0.19] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by smtp.gmail.com with ESMTPSA id c41sm904346qtd.3.2017.02.06.08.18.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Feb 2017 08:18:39 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: Date: Mon, 6 Feb 2017 11:18:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> To: Ray Bellis X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:18:42 -0000 > On Feb 6, 2017, at 11:15 AM, Ray Bellis wrote: >=20 >> For now, let=92s keep it relevant to the decision this WG has to = make, >> about what to do with .alt and whether it=92s important to us to >> accommodate cases like .homenet. So far, it seems that the .homenet = case >> is much like =93locally-served zones=94. >=20 > Yes, that's right, with the caveat that all existing locally served > zones are in the reverse space - there's no forward zones registered = (yet). Could you clarify why that=92s relevant? Does it just come down to the assumption that reverse zones are not = supposed to have human-visible/human-friendly names? Or is there some = other characteristic of how those names are used that=92s important = here? thanks, Suzanne From nobody Mon Feb 6 08:25:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E03129EE8 for ; Mon, 6 Feb 2017 08:25:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Fk0Zv3zjN2kl for ; Mon, 6 Feb 2017 08:25:00 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F2D129E8F for ; Mon, 6 Feb 2017 08:24:59 -0800 (PST) Received: from [46.227.151.81] (port=58832 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1cam64-0004BH-8W (Exim 4.72) (return-path ); Mon, 06 Feb 2017 16:24:56 +0000 To: Suzanne Woolf References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> From: Ray Bellis Message-ID: <77e5c7ed-7900-3475-07ec-57eeb4400be6@bellis.me.uk> Date: Mon, 6 Feb 2017 16:24:58 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:25:01 -0000 On 06/02/2017 16:18, Suzanne Woolf wrote: >> Yes, that's right, with the caveat that all existing locally >> served zones are in the reverse space - there's no forward zones >> registered (yet). > > Could you clarify why thats relevant? > > Does it just come down to the assumption that reverse zones are not > supposed to have human-visible/human-friendly names? Or is there some > other characteristic of how those names are used thats important > here? In the back of my mind I was recalling some conversations I've heard that perhaps some other "reserved" forward names should be treated like locally served zones (e.g. ".invalid") but currently aren't. Ray From nobody Mon Feb 6 08:50:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B577120726 for ; Mon, 6 Feb 2017 08:50:09 -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] 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 ZLSLZpezCA-l for ; Mon, 6 Feb 2017 08:50:05 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7CF0129575 for ; Mon, 6 Feb 2017 08:50:04 -0800 (PST) Received: from [10.32.60.141] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v16Gmobr014060 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Feb 2017 09:48:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.141] From: "Paul Hoffman" To: "Suzanne Woolf" Date: Mon, 06 Feb 2017 08:50:01 -0800 Message-ID: <4433DBF7-3BAC-47D1-9489-0B948680D1B1@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: dnsop Subject: Re: [DNSOP] correction Re: virtual interim DNSOP WG meeting and current status, special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:50:09 -0000 On 2 Feb 2017, at 13:48, Suzanne Woolf wrote: >> (Webex details will follow) This Webex will be recorded for those of us who cannot attend, yes? --Paul Hoffman From nobody Mon Feb 6 08:55:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69F2129596 for ; Mon, 6 Feb 2017 08:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 qCW7ABSnXlO4 for ; Mon, 6 Feb 2017 08:55:21 -0800 (PST) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF4E129592 for ; Mon, 6 Feb 2017 08:55:20 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:55240) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1camZT-000LjT-iH (Exim 4.88) (return-path ); Mon, 06 Feb 2017 16:55:19 +0000 Date: Mon, 6 Feb 2017 16:55:19 +0000 From: Tony Finch To: Ray Bellis In-Reply-To: Message-ID: References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:55:25 -0000 Ray Bellis wrote: > > Yes, that's right, with the caveat that all existing locally served > zones are in the reverse space - there's no forward zones registered (yet). There are several :-) RFC 6761 specifies localhost, invalid, test as locally served zones. RFC 6762 specifies local. RFC 7686 specifies onion. RFC 7534 says that the AS112 DNAME target zones should be locally served, though they are not listed in the special use registry. The example domains are special use but not locally served. BIND currently has empty.as112.arpa as its only built-in locally-served forward domain. My servers have some awkwardness to sink .local mDNS queries without making Avahi think there is a private non-multicast DNS .local domain. This does not conform to the requirements of RFC 6762 but it is necessary for interop :-/ zone local { type master; file "/zm/null"; allow-query { !0.0.0.0/0; !::/0; }; }; Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Viking, North Utsire, South Utsire, Forties, Cromarty: Southeasterly 7 to severe gale 9, perhaps storm 10 later in Viking. Rough or very rough becoming very rough or high. Rain or sleet. Moderate or good, occasionally poor. From nobody Mon Feb 6 09:19:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C221293EE for ; Mon, 6 Feb 2017 09:19:51 -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 10wxUWIpbVTx for ; Mon, 6 Feb 2017 09:19:51 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED02129408 for ; Mon, 6 Feb 2017 09:19:50 -0800 (PST) Received: (qmail 77877 invoked from network); 6 Feb 2017 17:19:49 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 6 Feb 2017 17:19:49 -0000 Date: 6 Feb 2017 17:19:27 -0000 Message-ID: <20170206171927.5460.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: suzworldwide@gmail.com Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 17:19:52 -0000 In article you write: >> Yes, that's right, with the caveat that all existing locally served >> zones are in the reverse space - there's no forward zones registered (yet). > >Could you clarify why thats relevant? Perhaps because the management rules follow more or less mechanically from the management rules for the corresponding IP space. R's, John PS: I don't think that's hugely compelling. From nobody Mon Feb 6 10:12:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302C01295AD for ; Mon, 6 Feb 2017 10:12:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 GWlC9r-o0iZl for ; Mon, 6 Feb 2017 10:12:34 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8D9129404 for ; Mon, 6 Feb 2017 10:12:33 -0800 (PST) Received: from [46.227.151.81] (port=62023 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1canm9-0006JY-3H (Exim 4.72) for dnsop@ietf.org (return-path ); Mon, 06 Feb 2017 18:12:29 +0000 To: dnsop@ietf.org References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> From: Ray Bellis Message-ID: Date: Mon, 6 Feb 2017 18:12:31 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 18:12:36 -0000 On 06/02/2017 16:55, Tony Finch wrote: > Ray Bellis wrote: >> >> Yes, that's right, with the caveat that all existing locally served >> zones are in the reverse space - there's no forward zones registered (yet). > > There are several :-) RFC 6761 specifies localhost, invalid, test as > locally served zones. RFC 6762 specifies local. RFC 7686 specifies onion. > > RFC 7534 says that the AS112 DNAME target zones should be locally served, > though they are not listed in the special use registry. > > The example domains are special use but not locally served. The "locally served zones" and "special use domains" registries are different. There is potentially scope for overlap. It's possible that some special use domains might benefit from special treatment in the root zone, too (".localhost" ?) Ray From nobody Mon Feb 6 11:21:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3531295C1 for ; Mon, 6 Feb 2017 11:21:53 -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, HTML_MESSAGE=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 6j99NgjLDjSq for ; Mon, 6 Feb 2017 11:21:51 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6C61294C7 for ; Mon, 6 Feb 2017 11:21:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DB8BF300424 for ; Mon, 6 Feb 2017 14:21:50 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2YEN0TOcwKNI for ; Mon, 6 Feb 2017 14:21:49 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 021A7300222; Mon, 6 Feb 2017 14:21:48 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4A62C5B-15A4-470A-B02E-9B3B3EEF7450" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> Date: Mon, 6 Feb 2017 14:21:46 -0500 Message-Id: References: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> To: Suzanne Woolf X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: dnsop Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 19:21:54 -0000 --Apple-Mail=_C4A62C5B-15A4-470A-B02E-9B3B3EEF7450 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > This message opens a Working Group Last Call for: >=20 > "Special-Use Names Problem Statement" > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ > Proposed status: informational >=20 > Starts: 2 Feb. 2017 > Ends: 23 Feb. 2017 (3 weeks) >=20 > Discussion should go to the mailing list.=20 >=20 > Is this draft ready to advance for publication as an Informational = RFC, and as guidance for possible updates to RFC 6761? Does it describe = the relevant issues clearly, and cover all the relevant ones that should = be taken into account in future work in the IETF on the special use = names registry or RFC 6761? I think the document should be published an Informational RFC once the = comments are resolved. I think it offers a good foundation for a future = rfc6761bis document. I have several comments=85 I think the title should be Special-Use Domain Names Problem Statement. = The abstract talks about domain names, so the title should match. Will I-D.lewis-domain-names be published as an Informational RFC as = well? If not, then the Introduction needs to extract highlights from = that document. These three bullets in Section 3 overlap: o Both ICANN and the IETF have the authority and formal processes to assign names from the pool of unused names, but no formal coordination process exists. The lack of coordination complicates the management of the root of the Domain Namespace and may lead to conflicts in name assignments [SDO-ICANN-SAC090]. o The IETF and ICANN each have administrative authority over the Domain Namespace. Not all developers of protocols on the internet agree that this authority should reside with the IETF and ICANN. o Although IETF and ICANN nominally have authority over this namespace, neither organization can enforce that authority over any third party who wants to just start using a subset of the namespace. I think there is one main point and two observations. The main point is = that both ICANN and the IETF have the authority and formal processes to = assign previously unused names. The first observation is that ICANN and = the IETF need to coordinate to avoid conflicts. The second observation = is that some think that the authority is misplaced. The second = observation needs to be expanded to state the consequence, which I = assume is squatting. If I guessed correctly, the text should explain = that squatting leads to conflicts. The third observation is that = neither ICANN nor the IETF has any technical means to prevent squatting. I think that the Section 3 bullet on .local should explain that the = amount of time involved was excessive, but part of the reason was that = the process for special-use assignments was being invented. As a = result, .onion took much less time. I think that theSection 3 bullet that references = https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html should = be reworded. The information in the Ed Note probably does not belong in = the Informational RFC. I think that Section 4.2.5 should include a reference to the SSAC = document. I know it is also referenced elsewhere. And a few Nits=85 The =93SUDN=94 and =93SUTLDN=94 acronyms are defined, but they are not = used very often. I wonder is spelling it out in every case would be = more clear. In Section 3, there is bad formatting and duplicate informations in the = bullet about ICANN Reserved Names. I suggest: s/(see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names )/(seeSection = 2.2.1.2.1of [SDO-ICANN-DAG]) In Section 4.1.1: s/TOR browser/Tor Browser [TP]/ s/connecting over TOR/connecting over the Tor network/ [TP] =3D https://www.torproject.org In Section 4.1.3: s/Memorandum of Understanding[RFC2860]/Memorandum of Understanding = [RFC2860]/ Russ= --Apple-Mail=_C4A62C5B-15A4-470A-B02E-9B3B3EEF7450 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

This message opens a = Working Group Last Call for:

"Special-Use Names Problem Statement"
https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/=
Proposed status: informational

Starts: 2 Feb. = 2017
Ends: 23 Feb. 2017 (3 weeks)

Discussion should go to = the mailing list. 

Is this draft ready to advance for publication as an = Informational RFC, and as guidance for possible updates to RFC 6761? = Does it describe the relevant issues clearly, and cover all the relevant = ones that should be taken into account in future work in the IETF on the = special use names registry or RFC = 6761?

I think the document = should be published an Informational RFC once the comments are resolved. =  I think it offers a good foundation for a future rfc6761bis = document.

I have several = comments=85

I think the title should = be Special-Use Domain Names Problem Statement.  The abstract = talks about domain names, so the title should = match.

Will I-D.lewis-domain-names be = published as an Informational RFC as well?  If not, then the = Introduction needs to extract highlights from that = document.

These three bullets in Section 3 = overlap:

   o  Both ICANN = and the IETF have the authority and formal processes to
  =     assign names from the pool of unused names, but no = formal
      coordination process exists. =  The lack of coordination complicates
    =   the management of the root of the Domain Namespace and may lead = to
      conflicts in name assignments = [SDO-ICANN-SAC090].

   o =  The IETF and ICANN each have administrative authority over = the
      Domain Namespace.  Not all = developers of protocols on the internet
      = agree that this authority should reside with the IETF and = ICANN.

   o  Although IETF = and ICANN nominally have authority over this
    =   namespace, neither organization can enforce that authority = over
      any third party who wants to just = start using a subset of the
      = namespace.

I think there is one main = point and two observations.  The main point is that both ICANN and = the IETF have the authority and formal processes to assign previously = unused names.  The first observation is that ICANN and the IETF = need to coordinate to avoid conflicts.  The second observation is = that some think that the authority is misplaced.  The second = observation needs to be expanded to state the consequence, which I = assume is squatting.  If I guessed correctly, the text should = explain that squatting leads to conflicts.  The third observation = is that neither ICANN nor the IETF has any technical means to prevent = squatting.

I think that the Section 3 bullet on = .local should explain that the amount of time involved was excessive, = but part of the reason was that the process for special-use assignments = was being invented.  As a result, .onion took much less = time.

I think that theSection 3  bullet = that references https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html = should be reworded.  The information in the Ed Note probably does = not belong in the Informational RFC.

I think = that Section 4.2.5 should include a reference to the SSAC document. =  I know it is also referenced = elsewhere.


And a few = Nits=85

The =93SUDN=94 and =93SUTLDN=94 = acronyms are defined, but they are not used very often.  I wonder = is spelling it out in every case would be more = clear.

In Section 3, there is bad = formatting and duplicate informations in the bullet about ICANN = Reserved Names.  I suggest:
s/(see [SDO-ICANN-DAG]Section = 2.2.1.2.1, Reserved Names )/(seeSection 2.2.1.2.1of = [SDO-ICANN-DAG])

In Section = 4.1.1:
s/TOR browser/Tor Browser [TP]/
s/connecting = over TOR/connecting over the Tor network/


In Section 4.1.3:
s/Memorandum of = Understanding[RFC2860]/Memorandum of Understanding = [RFC2860]/

Russ
= --Apple-Mail=_C4A62C5B-15A4-470A-B02E-9B3B3EEF7450-- From nobody Mon Feb 6 12:11:49 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C81B1294A6; Mon, 6 Feb 2017 12:11:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148641190463.18994.6016388072102193026.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 12:11:44 -0800 Archived-At: Cc: dnsop@ietf.org, ipr-announce@ietf.org Subject: [DNSOP] IPR Disclosure VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-rfc4641bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 20:11:44 -0000 Dear Olaf M. Kolkman, Matthijs Mekking, R. (Miek) Gieben: An IPR disclosure that pertains to your RFC entitled "DNSSEC Operational Practices, Version 2" (RFC6781) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2877/). The title of the IPR disclosure is "VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-rfc4641bis" Thank you IETF Secretariat From nobody Mon Feb 6 13:04:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28581294E0 for ; Mon, 6 Feb 2017 13:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qvp7sVTYfN2t for ; Mon, 6 Feb 2017 13:04:08 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 F09E91294DA for ; Mon, 6 Feb 2017 13:04:07 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id u25so68318506qki.2 for ; Mon, 06 Feb 2017 13:04:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Fm0mq/edlFMHBctdRkh4fOp+902CCUXV4ZiCW3PIj5k=; b=q2/2dYgblTHmOEYShH4eobjrgZ5wLElRjW3jpIdoDdEtabG73tfGJASecDpzXTR551 sYLUsgWW+ZMgP8xn6ElK4pAQhbN4Qo6sJWhwsRyrdlwmEGXkJX02VXWMkARs4bmQpW3J lCUqO02wz7WuIhMv2b5RopeTA59Kfyr1G0Mh5xiNV+jpYOQTE2teKJ42IfK+gttZnsKK Fkm/Ese8IBwsXKbht7Ci/HbAstmASDq6iXxpcHY9ttBMYfkV8Q6qTEV6Vs2gMFY/XFt+ dUzlE8mz3+tnjIcXIBL1Bd1xjvvrmQeE7XONj/nE08HMmTVvRHfZObGye28I0qKtRgNo tdZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Fm0mq/edlFMHBctdRkh4fOp+902CCUXV4ZiCW3PIj5k=; b=IQhSaE4HCGycGq9IW4U+jyjYD5lywT3BzUhClPMsUVhOcP6sS7d60iOk9VvFvwReK6 Hyzzqlvlo4v6By3KnO+qiGbuqNzlrSAhuAO88HuRpc7V0pW6C8VZde7AygTe+/+o4mkJ Cqgf85Qe9H76rg6k4C0alY18i5bWzMn2T04K+5hXpvp9Zjk8MrX+E/SXGq8nsiPbUuEr R6RqRfKYqg6ilmLHFIBKnWh0zsxVNCNfiX4KmjhHdauBK+ZHGpNRcNXUgyErnMm2+eT/ vIaPpZXdI8kUD21oD9CWeNiRsOSiuS49sjA7Idq0VJ89HgBiSPOAEKpOj3EaOYpTvcVM OrbA== X-Gm-Message-State: AMke39laQwTnalj6tXg4z/KdL32Vfv5cY/R26AItKxTRRd/UOo0vrEjEfrCiuLILhfJg7w== X-Received: by 10.55.0.148 with SMTP id t20mr10584792qkg.299.1486415047144; Mon, 06 Feb 2017 13:04:07 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:7074:fbd6:4df:cdf7? ([2601:18f:801:600:7074:fbd6:4df:cdf7]) by smtp.gmail.com with ESMTPSA id 37sm1493294qto.43.2017.02.06.13.04.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 13:04:06 -0800 (PST) From: Ralph Droms Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3D72D99D-5B57-4AE1-B4B6-ACBB0632A1E6" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 6 Feb 2017 16:04:05 -0500 In-Reply-To: To: Russ Housley References: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Suzanne Woolf , dnsop Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 21:04:10 -0000 --Apple-Mail=_3D72D99D-5B57-4AE1-B4B6-ACBB0632A1E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for your review and comments, Russ. I've extracted the issues = from your review and entered them in the GitHub issue tracker for the = document. - Ralph > On Feb 6, 2017, at 2:21 PM, Russ Housley wrote: >=20 >>=20 >> This message opens a Working Group Last Call for: >>=20 >> "Special-Use Names Problem Statement" >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ = >> Proposed status: informational >>=20 >> Starts: 2 Feb. 2017 >> Ends: 23 Feb. 2017 (3 weeks) >>=20 >> Discussion should go to the mailing list.=20 >>=20 >> Is this draft ready to advance for publication as an Informational = RFC, and as guidance for possible updates to RFC 6761? Does it describe = the relevant issues clearly, and cover all the relevant ones that should = be taken into account in future work in the IETF on the special use = names registry or RFC 6761? >=20 > I think the document should be published an Informational RFC once the = comments are resolved. I think it offers a good foundation for a future = rfc6761bis document. >=20 > I have several comments=E2=80=A6 >=20 > I think the title should be Special-Use Domain Names Problem = Statement. The abstract talks about domain names, so the title should = match. >=20 > Will I-D.lewis-domain-names be published as an Informational RFC as = well? If not, then the Introduction needs to extract highlights from = that document. >=20 > These three bullets in Section 3 overlap: >=20 > o Both ICANN and the IETF have the authority and formal processes = to > assign names from the pool of unused names, but no formal > coordination process exists. The lack of coordination = complicates > the management of the root of the Domain Namespace and may lead = to > conflicts in name assignments [SDO-ICANN-SAC090]. >=20 > o The IETF and ICANN each have administrative authority over the > Domain Namespace. Not all developers of protocols on the = internet > agree that this authority should reside with the IETF and ICANN. >=20 > o Although IETF and ICANN nominally have authority over this > namespace, neither organization can enforce that authority over > any third party who wants to just start using a subset of the > namespace. >=20 > I think there is one main point and two observations. The main point = is that both ICANN and the IETF have the authority and formal processes = to assign previously unused names. The first observation is that ICANN = and the IETF need to coordinate to avoid conflicts. The second = observation is that some think that the authority is misplaced. The = second observation needs to be expanded to state the consequence, which = I assume is squatting. If I guessed correctly, the text should explain = that squatting leads to conflicts. The third observation is that = neither ICANN nor the IETF has any technical means to prevent squatting. >=20 > I think that the Section 3 bullet on .local should explain that the = amount of time involved was excessive, but part of the reason was that = the process for special-use assignments was being invented. As a = result, .onion took much less time. >=20 > I think that theSection 3 bullet that references = https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html = = should be reworded. The information in the Ed Note probably does not = belong in the Informational RFC. >=20 > I think that Section 4.2.5 should include a reference to the SSAC = document. I know it is also referenced elsewhere. >=20 >=20 > And a few Nits=E2=80=A6 >=20 > The =E2=80=9CSUDN=E2=80=9D and =E2=80=9CSUTLDN=E2=80=9D acronyms are = defined, but they are not used very often. I wonder is spelling it out = in every case would be more clear. >=20 > In Section 3, there is bad formatting and duplicate informations in = the bullet about ICANN Reserved Names. I suggest: > s/(see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names )/(seeSection = 2.2.1.2.1of [SDO-ICANN-DAG]) >=20 > In Section 4.1.1: > s/TOR browser/Tor Browser [TP]/ > s/connecting over TOR/connecting over the Tor network/ >=20 > [TP] =3D https://www.torproject.org >=20 > In Section 4.1.3: > s/Memorandum of Understanding[RFC2860]/Memorandum of Understanding = [RFC2860]/ >=20 > Russ > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop = --Apple-Mail=_3D72D99D-5B57-4AE1-B4B6-ACBB0632A1E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for your review and comments, Russ.  I've = extracted the issues from your review and entered them in the GitHub = issue tracker for the document.

- Ralph

On Feb 6, 2017, at 2:21 PM, = Russ Housley <housley@vigilsec.com> wrote:


This message opens a Working Group = Last Call for:

"Special-Use Names Problem Statement"
https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/=
Proposed status: informational

Starts: 2 Feb. = 2017
Ends: 23 Feb. 2017 (3 weeks)

Discussion should go to = the mailing list. 

Is this draft ready to advance for publication as an = Informational RFC, and as guidance for possible updates to RFC 6761? = Does it describe the relevant issues clearly, and cover all the relevant = ones that should be taken into account in future work in the IETF on the = special use names registry or RFC = 6761?

I= think the document should be published an Informational RFC once the = comments are resolved.  I think it offers a good foundation for a = future rfc6761bis document.

I have several comments=E2=80=A6

I think the title = should be Special-Use Domain Names Problem Statement.  The = abstract talks about domain names, so the title should match.

Will I-D.lewis-domain-names be published as an = Informational RFC as well?  If not, then the Introduction needs to = extract highlights from that document.

These three bullets in Section 3 overlap:

  =  o  Both ICANN and the IETF have the authority and formal = processes to
      assign names from = the pool of unused names, but no formal
  =     coordination process exists.  The lack of = coordination complicates
      the = management of the root of the Domain Namespace and may lead to
      conflicts in name assignments = [SDO-ICANN-SAC090].

   o  The IETF and ICANN = each have administrative authority over the
  =     Domain Namespace.  Not all developers of protocols on = the internet
      agree that this = authority should reside with the IETF and ICANN.

   o =  Although IETF and ICANN nominally have authority over = this
      namespace, neither = organization can enforce that authority over
  =     any third party who wants to just start using a subset of = the
      namespace.

I think there is one = main point and two observations.  The main point is that both ICANN = and the IETF have the authority and formal processes to assign = previously unused names.  The first observation is that ICANN and = the IETF need to coordinate to avoid conflicts.  The second = observation is that some think that the authority is misplaced. =  The second observation needs to be expanded to state the = consequence, which I assume is squatting.  If I guessed correctly, = the text should explain that squatting leads to conflicts.  The = third observation is that neither ICANN nor the IETF has any technical = means to prevent squatting.

I think that the Section 3 bullet on .local should explain = that the amount of time involved was excessive, but part of the reason = was that the process for special-use assignments was being invented. =  As a result, .onion took much less time.

I think that theSection 3  bullet = that references https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.ht= ml should be = reworded.  The information in the Ed Note probably does not belong = in the Informational RFC.

I think that Section 4.2.5 should include a reference to = the SSAC document.  I know it is also referenced = elsewhere.


And a few Nits=E2=80=A6

The =E2=80=9CSUDN=E2=80=9D and = =E2=80=9CSUTLDN=E2=80=9D acronyms are defined, but they are not used = very often.  I wonder is spelling it out in every case would be = more clear.

In Section 3, there is = bad formatting and duplicate informations in the bullet about ICANN = Reserved Names.  I suggest:
s/(see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names = )/(seeSection 2.2.1.2.1of [SDO-ICANN-DAG])

In Section 4.1.1:
s/TOR browser/Tor Browser [TP]/
s/connecting over = TOR/connecting over the Tor network/

[TP] =3D https://www.torproject.org

In Section 4.1.3:
s/Memorandum of Understanding[RFC2860]/Memorandum of = Understanding [RFC2860]/

Russ
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
= --Apple-Mail=_3D72D99D-5B57-4AE1-B4B6-ACBB0632A1E6-- From nobody Mon Feb 6 13:46:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4001C1295A6 for ; Mon, 6 Feb 2017 13:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPViEP3AFKaC for ; Mon, 6 Feb 2017 13:46:56 -0800 (PST) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 835F1129581 for ; Mon, 6 Feb 2017 13:46:56 -0800 (PST) Received: by mail-qk0-x244.google.com with SMTP id u25so10500914qki.2 for ; Mon, 06 Feb 2017 13:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SHLhiEweJR9xTVWOd7/sccJAdQDQoiVXOz3Fwp1KV5o=; b=eDE0zkZS1n/bgo+gKgM+4n4iKFJEiVWqxdB8geB3GQYvGxG6+122Nc2mdIZ7itYdfR yF//H/Zz23tH3aktPTbr0sP5JWl0040oJ2p80QrZkWhua32KTwX83rH+ibMH3X5/8dvP an3oAO5YAXHm44+Rfh1jNgH4rJXAt41ZDuGDX8DhG+G0zjgkUnHAQXsom+yxU2fXSjaL iAnl6iVNMxWxFrjUIBUIHjoYHSNyDDVbmC7WozO6D4PdRFqcLYLR4Cmhsg8PA1LfAstP FYmBYvW8P4/EpxLnzWWvQxsbh2bEFoNZZMY8mNlidqeuQAge3tsKGWOavB+nXmT0Tnhu qebw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SHLhiEweJR9xTVWOd7/sccJAdQDQoiVXOz3Fwp1KV5o=; b=RPedgN0M4nsf/TQNi2WUmtU0d5/C8ID7W4qMu2OfexySvTKdcUlwW4vkkkLyTlYjSK GXIeB/7klmRpZvNYJWC8/0PHyISBsC6Fs+EzqCKQBXfxvhZHv88LTU0MxPdju+GBtTcQ E85+iEVhY5IMtsWBj6qm2n2PZwk1WObWzm3eOx1MbA0lGKBtVKCDjfuGLBk+spLWG30D LDP05a/viAn3DXARDvYt52m4+xlipEZ+CjroNQLdi7zBO9etNjHkXJKs2ur9GNeKjvhZ ZtXuKiLsRlWvFWBRlq6vXfLjilQkGGpQQJqMUzBOlwTtxB/wI7rpf8sQHO89qK7soBkO pGQA== X-Gm-Message-State: AMke39krM5MPmgD04DjZpGiYlFy5ymgXqwWsQ9vSM+uXlu1CQaxp14sMaCkqtg6te4p+hw== X-Received: by 10.233.220.134 with SMTP id q128mr11052326qkf.220.1486417615688; Mon, 06 Feb 2017 13:46:55 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:7074:fbd6:4df:cdf7? ([2601:18f:801:600:7074:fbd6:4df:cdf7]) by smtp.gmail.com with ESMTPSA id s20sm1572076qtc.39.2017.02.06.13.46.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 13:46:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ralph Droms In-Reply-To: <20170204021009.GE67739@mx2.yitter.info> Date: Mon, 6 Feb 2017 16:46:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <203E2636-1391-4100-9B1A-4F2DCC9A32BB@gmail.com> References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> <20170204021009.GE67739@mx2.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 21:46:58 -0000 > On Feb 3, 2017, at 9:10 PM, Andrew Sullivan = wrote: >=20 > On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote: >> Mark, I don't think you've actually given an answer to my question. >> I understood that .ALT was for alternative naming systems, not for >> DNS locally-served zones. We simply need to decide whether or not >> that's true. I think either answer is fine; we just need to pick >> one. >=20 > I agree with this. I will say that, when I first started working on > this with Warren, it was really for the use-case where people would > tread on the namespace as a protocol switch -- we wanted a sandbox in > which things like onion could live. My memory is that only after that > did we start thinking of a sort of 1918-style part of the DNS as > well. That may have been a mistake, since as this discussion is > showing the properties of an in-protocol, in-DNS namespace without > delegations are somewhat different to alternative-protocol uses that > do not rely on the DNS at all. Andrew - I have come around to agree that the properties and = requirements of non-DNS resolution mechanisms are different from those = of DNS resolution that does not use the root zone as a resolution = context. I believe that these properties and requirements cannot be = served by the single .alt delegation, so, in my opinion, = draft-ietf-dnsop-alt-tld should specify .alt for use of non-DNS = resolution mechanisms. How to proceed with DNS resolution that does not use the root zone as a = resolution context is open for discussion. - Ralph >=20 > Best regards, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Feb 6 14:24:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AF4129658 for ; Mon, 6 Feb 2017 14:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 RUPKLB_UYYnl for ; Mon, 6 Feb 2017 14:24:38 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52FB129656 for ; Mon, 6 Feb 2017 14:24:37 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 35E543493CF; Mon, 6 Feb 2017 22:24:34 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 25004160048; Mon, 6 Feb 2017 22:24:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E5D75160076; Mon, 6 Feb 2017 22:24:33 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id apRRQhdfEHOa; Mon, 6 Feb 2017 22:24:33 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 61844160048; Mon, 6 Feb 2017 22:24:33 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DAC32631951F; Tue, 7 Feb 2017 09:24:29 +1100 (EST) To: Ralph Droms From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> <20170204021009.GE67739@mx2.yitter.info> <203E2636-1391-4100-9B1A-4F2DCC9A32BB@gmail.com> In-reply-to: Your message of "Mon, 06 Feb 2017 16:46:53 -0500." <203E2636-1391-4100-9B1A-4F2DCC9A32BB@gmail.com> Date: Tue, 07 Feb 2017 09:24:29 +1100 Message-Id: <20170206222429.DAC32631951F@rock.dv.isc.org> Archived-At: Cc: dnsop@ietf.org, Andrew Sullivan Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 22:24:39 -0000 In message <203E2636-1391-4100-9B1A-4F2DCC9A32BB@gmail.com>, Ralph Droms writes: > > > On Feb 3, 2017, at 9:10 PM, Andrew Sullivan wrote: > > > > On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote: > >> Mark, I don't think you've actually given an answer to my question. > >> I understood that .ALT was for alternative naming systems, not for > >> DNS locally-served zones. We simply need to decide whether or not > >> that's true. I think either answer is fine; we just need to pick > >> one. > > > > I agree with this. I will say that, when I first started working on > > this with Warren, it was really for the use-case where people would > > tread on the namespace as a protocol switch -- we wanted a sandbox in > > which things like onion could live. My memory is that only after that > > did we start thinking of a sort of 1918-style part of the DNS as > > well. That may have been a mistake, since as this discussion is > > showing the properties of an in-protocol, in-DNS namespace without > > delegations are somewhat different to alternative-protocol uses that > > do not rely on the DNS at all. > > Andrew - I have come around to agree that the properties and requirements > of non-DNS resolution mechanisms are different from those of DNS re > solution that does not use the root zone as a resolution context. I believe > that these properties and requirements cannot be served by the single .alt > delegation, so, in my opinion, draft-ietf-dnsop-alt-tld should specify .alt > for use of non-DNS resolution mechanisms. > > How to proceed with DNS resolution that does not use the root zone as a > resolution context is open for discussion. > > - Ralph Whether a DNS transport is use or not for the names. Any scheme where names in use needs to have a insecure delegation if we expect recursive server to answer for that namespace even if it is just to stop query / name leaks. That is basic DNSSEC. .ONION needs this treatment. If the ISP's recursive server is answering for leaked .ONION names and the ISP's clients validating recursive server is forwarding to the ISP's server (this is a common configuration for some Linux distributions) then there will be reties to all the ISP's servers. No set of systems, when configured as specified by RFC, should ever result in SERVFAIL being returned. That is just poor engineering. That will have the punters chasing configuration bugs that don't exist. Mark > > Best regards, > > > > A > > > > -- > > Andrew Sullivan > > ajs@anvilwalrusden.com > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 6 19:37:29 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E1512988F for ; Mon, 6 Feb 2017 19:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RauqDFtj0fmE for ; Mon, 6 Feb 2017 19:37:26 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 422DE129882 for ; Mon, 6 Feb 2017 19:37:26 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id v96so81271896ioi.0 for ; Mon, 06 Feb 2017 19:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BOsqZFkhnY3ULJNj4itClOoH9Mf/56sJSjdAVH+fcmQ=; b=UY88CUuXAXoCoyW4MHzt7/lHsgZfzKSHfOKR3rDm9GM7jMUkNFFqZo4Df0Paso4KwI t09ts93ZNeqLwps91Xa614p1moMBunHIW9iVb9jYXnglQHLjNxePktHDTEB1r0z4sq7U m8xqOoaEOx5/Dc/VNJle7F/s05R4Leb6unxnUyroTYq5vwHOZau8URcdJ2cAfgeRW6g0 nTrBt9WvwMWaKROI+MpMrwihCu+rUMcR/6DjcNMj0Bu513vjxbo20TS+CA5TFn0Baj26 LzTkZgOK9wFJD9AeeXxYX7EtEWzCvuSmfocqUZfCMkrJ6GLJ81z9EmzlIIbyMzsBdhuH fJYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BOsqZFkhnY3ULJNj4itClOoH9Mf/56sJSjdAVH+fcmQ=; b=f9vr+4YcWLyHLqKwQmNtfuM42jz/pALPnrceei/RVyQbJeXv+CRIjbXyj8eVUbfRqs +m0KMurehLoOPe3sCpFrWMDU8BRUXfDoBvoQV4/Nl+CK4L95aJNL66ViduC3MNnf3mJm 2u0VRhWOFg/t1qiHSpT6IdSaOiIRXHFq9BkcXvhhOmsgTYoMOJMidCINM2UD9wR+y4LU wnsGrg0Qw7rcBcYNF4TVnmCSDA4hjhUvZYftJcAaKRgExzWQUS0X+g/RDJ85OY1N9oJE ywWPeO+gNaVyG+Fj1U52fsCBdNhf54skhn55bl6ucbRkNz6cqCZwLJeEaM7uUmrXsWIO Oupw== X-Gm-Message-State: AMke39lCho/TV5RXELVr2Z/hMecSlKF+Kps0GZmGmTYAmVdBIc5LesihsUvqLCM8jKdJWtCPiUhoEn8myiysGQ== X-Received: by 10.107.16.14 with SMTP id y14mr2229645ioi.164.1486438645540; Mon, 06 Feb 2017 19:37:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Mon, 6 Feb 2017 19:37:24 -0800 (PST) In-Reply-To: <20170203210922.7286C618213C@rock.dv.isc.org> References: <20170203210922.7286C618213C@rock.dv.isc.org> From: Brian Dickson Date: Mon, 6 Feb 2017 19:37:24 -0800 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a113fece272cf3b0547e877d3 Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 03:37:28 -0000 --001a113fece272cf3b0547e877d3 Content-Type: text/plain; charset=UTF-8 TL;DR: it is possible to have a signed DNAME in the root for alt (to empty.as112.arpa), AND have a local signed alt. Things under this local alt can be signed or unsigned. On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews wrote: > > In message mail.gmail.com> > , Brian Dickson writes: > > > > - I am in favor of AS112 for ALT > > - For AS112, I prefer the AS112++ method (DNAME) > > - I do not see why the DNAME would/should not be DNSSEC signed > > - Any local use of ALT can be served locally and signed using an > > alternative trust anchor > > You need a insecure delegation for ALT for the purposes we want to > use ALT for. > > Go setup a test rig where you have a signed root with ALT as you > described. A validiting recursive server which also serves foo.alt. > A second validating recursive server which forwards all queries to > the first recursive server. All servers are configured with a trust > anchor for the test root zone and are validating responses. Try > to perform a lookup on foo.alt. > I spent some time mocking up a variety of configurations. My original assertion stands; the particulars on making it work are perhaps not interesting to everyone. However, it falls in the "pics or it didn't happen" category, so here's what I did to make it work. 1 - set up a general resolver with the standard ICANN root trust anchor. Call it "X". 2 - set up a local "fake root server" which delegates to a "local alt server". Call this fake root server "F" 3 - set up a local "alt server" which serves the local "alt" domain (including any delegations, etc). Cal this "A". 3 - set up a second resolver, with appropriate trust anchor(s), that uses a "fake root server" instead of the real root. Call this "Y". 4 - set up a forwarder, which is configured to always forward to "X", except for the zone "alt", where it forwards to "Y". Make sure the necessary trust anchors are configured. Call this "Z". Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust anchors) Z->X otherwise (and validates using the ICANN root trust anchor). When I do this, I get real answers for everything but "alt". For anything at or under "alt", I get my own local copy. Everything validates (or is from below an insecure delegation point). > > The second recursive server is the validating client that needs to > be able to get a answer other than BOGUS. As we want to allow > foo.alt to be unsigned there can't be any other trust anchors, > including negative, configured. > In the above scenario, you CAN have an unsigned foo.alt, and it will not get BOGUS. If you want me to send you configs, just drop me a line. > > Only solutions which allow content from the foo.alt zone to be > successfully resolved are acceptable. > > The following will not work with the above rig: > * No delegation for ALT. > * A secure delegation for ALT. > * A DNAME for ALT in the root zone. > > Mark The problem is with your set-up, not the ability to have a working local-alt set-up. You need to put "foo.alt" somewhere OTHER than on the validating recursive server (which knows how to find the local "alt" stuff.) TIL you can't mix authority and recursive on the same server, when you are the target of a forwarder. If the two are separated, it works correctly, including using an alternate trust anchor for "alt". Brian --001a113fece272cf3b0547e877d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TL;DR: it is possible to have a signed DNAME in the root f= or alt (to empty.as112.arpa), AND have a local signed alt. Things under thi= s local alt can be signed or unsigned.

On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews <marka@i= sc.org> wrote:

In message <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSX= oM13DTg@mail.gmail.com>
, Brian Dickson writes:
>
>=C2=A0 =C2=A0 - I am in favor of AS112 for ALT
>=C2=A0 =C2=A0 - For AS112, I prefer the AS112++ method (DNAME)
>=C2=A0 =C2=A0 - I do not see why the DNAME would/should not be DNSSEC s= igned
>=C2=A0 =C2=A0 - Any local use of ALT can be served locally and signed u= sing an
>=C2=A0 =C2=A0 alternative trust anchor

You need a insecure delegation for ALT for the purposes we want to use ALT for.

Go setup a test rig where you have a signed root with ALT as you
described.=C2=A0 A validiting recursive server which also serves foo.alt. A second validating recursive server which forwards all queries to
the first recursive server.=C2=A0 All servers are configured with a trust anchor for the test root zone and are validating responses.=C2=A0 Try
to perform a lookup on foo.alt.

I spent= some time mocking up a variety of configurations.

My original assertion stands; the particulars on making it work are perhap= s not interesting to everyone.
However, it falls in the "pic= s or it didn't happen" category, so here's what I did to make = it work.

1 - set up a general resolver with the st= andard ICANN root trust anchor. Call it "X".
2 - set up= a local "fake root server" which delegates to a "local alt = server". Call this fake root server "F"
3 - se= t up a local "alt server" which serves the local "alt" = domain (including any delegations, etc). Cal this "A".
= 3 - set up a second resolver, with appropriate trust anchor(s), that uses a= "fake root server" instead of the real root. Call this "Y&q= uot;.
4 - set up a forwarder, which is configured to always forwa= rd to "X", except for the zone "alt", where it forwards= to "Y". Make sure the necessary trust anchors are configured. Ca= ll this "Z".

Z->Y if QNAME matches &q= uot;alt" or "*.alt" (and validates with local trust anchors)=
Z->X otherwise (and validates using the ICANN root trust anch= or).

When I do this, I get real answers for everyt= hing but "alt". For anything at or under "alt", I get m= y own local copy.

Everything validates (or is from= below an insecure delegation point).
=C2=A0

The second recursive server is the validating client that needs to
be able to get a answer other than BOGUS.=C2=A0 As we want to allow
foo.alt to be unsigned there can't be any other trust anchors,
including negative, configured.

In the = above scenario, you CAN have an unsigned foo.alt, and it will not get BOGUS= .

If you want me to send you configs, just drop me= a line.=C2=A0

Only solutions which allow content from the foo.alt zone to be
successfully resolved are acceptable.

The following will not work with the above rig:
* No delegation for ALT.
* A secure delegation for ALT.
* A DNAME for ALT in the root zone.

Mark

The problem is with your= set-up, not the ability to have a working local-alt set-up.

=
You need to put "foo.alt" somewhere OTHER than on the = validating recursive server (which knows how to find the local "alt&qu= ot; stuff.)=C2=A0

TIL you can't mix authority = and recursive on the same server, when you are the target of a forwarder.

If the two are separated, it works correctly, inclu= ding using an alternate trust anchor for "alt".

Brian
--001a113fece272cf3b0547e877d3-- From nobody Mon Feb 6 19:44:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BCB129894 for ; Mon, 6 Feb 2017 19: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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 qEYe_eOu1FlY for ; Mon, 6 Feb 2017 19:44:51 -0800 (PST) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848B212987F for ; Mon, 6 Feb 2017 19:44:51 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v173il0T009604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2017 20:44:48 -0700 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 61EC91E0088; Mon, 6 Feb 2017 21:44:41 -0600 (CST) Received: from lxomp07u.corp.intranet (unknown [151.117.18.14]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 9D7041E0140; Mon, 6 Feb 2017 21:44:40 -0600 (CST) Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v173iUat023042; Mon, 6 Feb 2017 21:44:30 -0600 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v173iUXR023036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Feb 2017 21:44:30 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0294.000; Mon, 6 Feb 2017 21:44:30 -0600 From: "Woodworth, John R" To: "'Ray Bellis'" , "dnsop@ietf.org" Thread-Topic: [DNSOP] ALT-TLD and (insecure) delgations. Thread-Index: AQHSfMnvkXNtPT4di0y/0CDCqL340aFVAxeAgAAy1ACAA0egAIAAANiAgAAFR4CAAH5kgIACsLKAgAAA+oCAABO5AIAAASaAgAACfgCAAAEygIAAuncAgAAGZ4CAAAE5gIAABCCAgAAA6wCAAAsugIAAFZKAgAA6b9A= Date: Tue, 7 Feb 2017 03:44:29 +0000 Message-ID: References: <6391B5BB-19BD-4717-B9BB-ECD145F7B4F6@fugue.com> <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "Woodworth, John R" , "Ballew, Dean" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 03:44:53 -0000 > On 06/02/2017 16:55, Tony Finch wrote: > > Ray Bellis wrote: > >> > >> Yes, that's right, with the caveat that all existing locally served > >> zones are in the reverse space - there's no forward zones registered (= yet). > > > > There are several :-) RFC 6761 specifies localhost, invalid, test as > > locally served zones. RFC 6762 specifies local. RFC 7686 specifies onio= n. > > > > RFC 7534 says that the AS112 DNAME target zones should be locally > > served, though they are not listed in the special use registry. > > > > The example domains are special use but not locally served. > > The "locally served zones" and "special use domains" registries are diffe= rent. > There is potentially scope for overlap. > > It's possible that some special use domains might benefit from special > treatment in the root zone, too (".localhost" ?) I know I am late to the game but as I understand the issue (still catching = up) the .alt is intended for both non-DNS and special-use DNS (expected to be resolved locally). Just spitballing but what about a new RR type to actively flag the owner as officially not-existing (e.g. NXD). These RRs could be used in *any* zone including root and combined with the special use registry (for policy) could flag the namespace as both reserved and non-existent. I tend to agree with Mark on this, SERVFAIL feels wrong. /John > Ray > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Mon Feb 6 20:06:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ADD12994F for ; Mon, 6 Feb 2017 20:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 b3epwfz2onVK for ; Mon, 6 Feb 2017 20:06:00 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00A71298D3 for ; Mon, 6 Feb 2017 20:06:00 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C0FC634950E; Tue, 7 Feb 2017 04:05:57 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B3AE0160048; Tue, 7 Feb 2017 04:05:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A4DA5160054; Tue, 7 Feb 2017 04:05:57 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J5KtT0TzUH74; Tue, 7 Feb 2017 04:05:57 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A6012160048; Tue, 7 Feb 2017 04:05:56 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8BDCC632F192; Tue, 7 Feb 2017 15:05:52 +1100 (EST) To: Brian Dickson From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> In-reply-to: Your message of "Mon, 06 Feb 2017 19:37:24 -0800." Date: Tue, 07 Feb 2017 15:05:52 +1100 Message-Id: <20170207040552.8BDCC632F192@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 04:06:02 -0000 In message , Brian Dickson writes: > > TL;DR: it is possible to have a signed DNAME in the root for alt (to > empty.as112.arpa), AND have a local signed alt. Things under this local alt > can be signed or unsigned. So now there is the problem of distributing trust anchors for the locally signed .alt zone just to be able to generate a NXDOMAIN response locally so that you don't leak names to the root servers. Note: we have no automatic solution to this problem and there is no possible solution. A DNAME at the root is not the right solution to this. Mark > On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews wrote: > > > > > In message > mail.gmail.com> > > , Brian Dickson writes: > > > > > > - I am in favor of AS112 for ALT > > > - For AS112, I prefer the AS112++ method (DNAME) > > > - I do not see why the DNAME would/should not be DNSSEC signed > > > - Any local use of ALT can be served locally and signed using an > > > alternative trust anchor > > > > You need a insecure delegation for ALT for the purposes we want to > > use ALT for. > > > > Go setup a test rig where you have a signed root with ALT as you > > described. A validiting recursive server which also serves foo.alt. > > A second validating recursive server which forwards all queries to > > the first recursive server. All servers are configured with a trust > > anchor for the test root zone and are validating responses. Try > > to perform a lookup on foo.alt. > > > > I spent some time mocking up a variety of configurations. > > My original assertion stands; the particulars on making it work are perhaps > not interesting to everyone. > However, it falls in the "pics or it didn't happen" category, so here's > what I did to make it work. > > 1 - set up a general resolver with the standard ICANN root trust anchor. > Call it "X". > 2 - set up a local "fake root server" which delegates to a "local alt > server". Call this fake root server "F" > 3 - set up a local "alt server" which serves the local "alt" domain > (including any delegations, etc). Cal this "A". > 3 - set up a second resolver, with appropriate trust anchor(s), that uses a > "fake root server" instead of the real root. Call this "Y". > 4 - set up a forwarder, which is configured to always forward to "X", > except for the zone "alt", where it forwards to "Y". Make sure the > necessary trust anchors are configured. Call this "Z". > > Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust > anchors) > Z->X otherwise (and validates using the ICANN root trust anchor). > > When I do this, I get real answers for everything but "alt". For anything > at or under "alt", I get my own local copy. > > Everything validates (or is from below an insecure delegation point). > > > > > > The second recursive server is the validating client that needs to > > be able to get a answer other than BOGUS. As we want to allow > > foo.alt to be unsigned there can't be any other trust anchors, > > including negative, configured. > > > > In the above scenario, you CAN have an unsigned foo.alt, and it will not > get BOGUS. > > If you want me to send you configs, just drop me a line. > > > > > Only solutions which allow content from the foo.alt zone to be > > successfully resolved are acceptable. > > > > The following will not work with the above rig: > > * No delegation for ALT. > > * A secure delegation for ALT. > > * A DNAME for ALT in the root zone. > > > > Mark > > > The problem is with your set-up, not the ability to have a working > local-alt set-up. > > You need to put "foo.alt" somewhere OTHER than on the validating recursive > server (which knows how to find the local "alt" stuff.) > > TIL you can't mix authority and recursive on the same server, when you are > the target of a forwarder. > > If the two are separated, it works correctly, including using an alternate > trust anchor for "alt". > > Brian > > --001a113fece272cf3b0547e877d3 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > >
TL;DR: it is possible to have a signed DNAME in the root f= > or alt (to empty.as112.arpa), AND have a local signed alt. Things under thi= > s local alt can be signed or unsigned.

iv class=3D"gmail_quote">On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews dir=3D"ltr"><marka@i= > sc.org> wrote:
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= > t:1ex">
> In message < SXoM13DTg@mail.gmail.com">CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSX= > oM13DTg@mail.gmail.com>
> , Brian Dickson writes:
> >
> >=C2=A0 =C2=A0 - I am in favor of AS112 for ALT
> >=C2=A0 =C2=A0 - For AS112, I prefer the AS112++ method (DNAME)
> >=C2=A0 =C2=A0 - I do not see why the DNAME would/should not be DNSSEC s= > igned
> >=C2=A0 =C2=A0 - Any local use of ALT can be served locally and signed u= > sing an
> >=C2=A0 =C2=A0 alternative trust anchor
>
> You need a insecure delegation for ALT for the purposes we want to r> > use ALT for.
>
> Go setup a test rig where you have a signed root with ALT as you
> described.=C2=A0 A validiting recursive server which also serves foo.alt. r> > A second validating recursive server which forwards all queries to
> the first recursive server.=C2=A0 All servers are configured with a trust r> > anchor for the test root zone and are validating responses.=C2=A0 Try
> to perform a lookup on foo.alt.

I spent= > some time mocking up a variety of configurations.

>My original assertion stands; the particulars on making it work are perhap= > s not interesting to everyone.
However, it falls in the "pic= > s or it didn't happen" category, so here's what I did to make = > it work.

1 - set up a general resolver with the st= > andard ICANN root trust anchor. Call it "X".
2 - set up= > a local "fake root server" which delegates to a "local alt = > server". Call this fake root server "F"
3 - se= > t up a local "alt server" which serves the local "alt" = > domain (including any delegations, etc). Cal this "A".
= > 3 - set up a second resolver, with appropriate trust anchor(s), that uses a= > "fake root server" instead of the real root. Call this "Y&q= > uot;.
4 - set up a forwarder, which is configured to always forwa= > rd to "X", except for the zone "alt", where it forwards= > to "Y". Make sure the necessary trust anchors are configured. Ca= > ll this "Z".

Z->Y if QNAME matches &q= > uot;alt" or "*.alt" (and validates with local trust anchors)= >
Z->X otherwise (and validates using the ICANN root trust anch= > or).

When I do this, I get real answers for everyt= > hing but "alt". For anything at or under "alt", I get m= > y own local copy.

Everything validates (or is from= > below an insecure delegation point).
=C2=A0
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid = > rgb(204,204,204);padding-left:1ex"> >
> The second recursive server is the validating client that needs to
> be able to get a answer other than BOGUS.=C2=A0 As we want to allow
> foo.alt to be unsigned there can't be any other trust anchors,
> including negative, configured.

In the = > above scenario, you CAN have an unsigned foo.alt, and it will not get BOGUS= > .

If you want me to send you configs, just drop me= > a line.=C2=A0
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> >
> Only solutions which allow content from the foo.alt zone to be
> successfully resolved are acceptable.
>
> The following will not work with the above rig:
> * No delegation for ALT.
> * A secure delegation for ALT.
> * A DNAME for ALT in the root zone.
>
> Mark

The problem is with your= > set-up, not the ability to have a working local-alt set-up.

= >
You need to put "foo.alt" somewhere OTHER than on the = > validating recursive server (which knows how to find the local "alt&qu= > ot; stuff.)=C2=A0

TIL you can't mix authority = > and recursive on the same server, when you are the target of a forwarder. div>

If the two are separated, it works correctly, inclu= > ding using an alternate trust anchor for "alt".

iv>
Brian
> > --001a113fece272cf3b0547e877d3-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 6 21:50:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D884C129A3C for ; Mon, 6 Feb 2017 21:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uEDrtWHQ9Da for ; Mon, 6 Feb 2017 21:50:28 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 38F3B129A33 for ; Mon, 6 Feb 2017 21:50:28 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id 194so35497369pgd.2 for ; Mon, 06 Feb 2017 21:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aEzg6I250X06CAweFF9qPcvU0mT6MeNG4xxl4QDGO70=; b=usgCQrS0VffSpnzPCd+DNAERpfREblC2uRkWIiWKN7jWZJsgl8b97rcZsWfxLRFCed FtpKJZbSbLqsI+0KAkrn5TGA+ySHR/hbLsYA9USFWw1sefpJkqJUdVn8jyw5fmo2yoJN uw+HOVYiokjnZeQJsuYIw57FXmWHxp5JKllIViWIgW/451oLN9/lwBpYa08CFSp5FH9z AeNgEsnwctQp6tTqoUxLQLCnHRRrhG88kVTk50HxfDVfx5gKvpx7uvOsIEQfW2rFXHYX TsaGcj/2StWaHAAjnzVl8ngExxvF61mBQMOjHnptRtwCvQjYL6GbjVq6RwMzDGzSpX6y 4EXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aEzg6I250X06CAweFF9qPcvU0mT6MeNG4xxl4QDGO70=; b=DlYodOThKu7ODuXfShaMHfHToTAXaOr6Z6CjPRG+6Wjmx84KuUkn+wEoNaS12YCqv6 yEpnk1GMAjbxZlpBOrP0U3hCwyG3f6C1Gtk1ajzaVNe1TPf7Jd02t98rn2rJ3xbNCDDK TxUzZyuiw3TBgal/ZjfhItm6kbYJYmtR6xBecj6Dj0PzTraqtLObQJ1dHcZ+DGUopm7G /fCgDVCnu4TcjF0PtBcI/OE1oFW7ZTEA6c9IgBYHSv8FVzXFDnrqZ08t9cCnjdHrpQ7l 8+PCEi5wmXvaYzhq0Ewsxz4sAeiOBaiusGfIJ40cgYEcCtOLB+9pTpdsOGfy38H6NSyv rFAA== X-Gm-Message-State: AIkVDXJaJJ2ocv+HGh1t1gbBjdj64VIJ2+Kmb8bLrST2esY9/jWOw2RavIv6+THcWxdkiA== X-Received: by 10.99.8.133 with SMTP id 127mr18398240pgi.42.1486446627502; Mon, 06 Feb 2017 21:50:27 -0800 (PST) Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id f9sm7079776pfj.56.2017.02.06.21.50.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 21:50:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (14D27) In-Reply-To: <20170207040552.8BDCC632F192@rock.dv.isc.org> Date: Mon, 6 Feb 2017 21:50:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> To: Mark Andrews Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 05:50:30 -0000 Mark, I don't think the use cases for most of the sandbox involving alt, and/or th= e homenet use case, requires support for validating stubs. If stubs aren't a= lready validating, the incremental addition of a local alt, only requires di= stribution of the trust anchor to the resolvers. That is a solvable problem f= or most values of "local". If use cases for non-local or validating stubs exits, IMHO that rises to the= level of requiring something real, not an alt name. If you think that is something that there is a demand for, I don't know if i= t might belong in a separate domain. An insecure delegation from the root may be seen as an invitation for exploi= tation by squatters. Sent from my iPhone > On Feb 6, 2017, at 8:05 PM, Mark Andrews wrote: >=20 >=20 > In message , Brian Dickson writes: >>=20 >> TL;DR: it is possible to have a signed DNAME in the root for alt (to >> empty.as112.arpa), AND have a local signed alt. Things under this local a= lt >> can be signed or unsigned. >=20 > So now there is the problem of distributing trust anchors for the > locally signed .alt zone just to be able to generate a NXDOMAIN > response locally so that you don't leak names to the root servers. >=20 > Note: we have no automatic solution to this problem and there is > no possible solution. >=20 > A DNAME at the root is not the right solution to this. >=20 > Mark >=20 >>> On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews wrote: >>>=20 >>>=20 >>> In message >> mail.gmail.com> >>> , Brian Dickson writes: >>>>=20 >>>> - I am in favor of AS112 for ALT >>>> - For AS112, I prefer the AS112++ method (DNAME) >>>> - I do not see why the DNAME would/should not be DNSSEC signed >>>> - Any local use of ALT can be served locally and signed using an >>>> alternative trust anchor >>>=20 >>> You need a insecure delegation for ALT for the purposes we want to >>> use ALT for. >>>=20 >>> Go setup a test rig where you have a signed root with ALT as you >>> described. A validiting recursive server which also serves foo.alt. >>> A second validating recursive server which forwards all queries to >>> the first recursive server. All servers are configured with a trust >>> anchor for the test root zone and are validating responses. Try >>> to perform a lookup on foo.alt. >>>=20 >>=20 >> I spent some time mocking up a variety of configurations. >>=20 >> My original assertion stands; the particulars on making it work are perha= ps >> not interesting to everyone. >> However, it falls in the "pics or it didn't happen" category, so here's >> what I did to make it work. >>=20 >> 1 - set up a general resolver with the standard ICANN root trust anchor. >> Call it "X". >> 2 - set up a local "fake root server" which delegates to a "local alt >> server". Call this fake root server "F" >> 3 - set up a local "alt server" which serves the local "alt" domain >> (including any delegations, etc). Cal this "A". >> 3 - set up a second resolver, with appropriate trust anchor(s), that uses= a >> "fake root server" instead of the real root. Call this "Y". >> 4 - set up a forwarder, which is configured to always forward to "X", >> except for the zone "alt", where it forwards to "Y". Make sure the >> necessary trust anchors are configured. Call this "Z". >>=20 >> Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust >> anchors) >> Z->X otherwise (and validates using the ICANN root trust anchor). >>=20 >> When I do this, I get real answers for everything but "alt". For anything= >> at or under "alt", I get my own local copy. >>=20 >> Everything validates (or is from below an insecure delegation point). >>=20 >>=20 >>>=20 >>> The second recursive server is the validating client that needs to >>> be able to get a answer other than BOGUS. As we want to allow >>> foo.alt to be unsigned there can't be any other trust anchors, >>> including negative, configured. >>>=20 >>=20 >> In the above scenario, you CAN have an unsigned foo.alt, and it will not >> get BOGUS. >>=20 >> If you want me to send you configs, just drop me a line. >>=20 >>>=20 >>> Only solutions which allow content from the foo.alt zone to be >>> successfully resolved are acceptable. >>>=20 >>> The following will not work with the above rig: >>> * No delegation for ALT. >>> * A secure delegation for ALT. >>> * A DNAME for ALT in the root zone. >>>=20 >>> Mark >>=20 >>=20 >> The problem is with your set-up, not the ability to have a working >> local-alt set-up. >>=20 >> You need to put "foo.alt" somewhere OTHER than on the validating recursiv= e >> server (which knows how to find the local "alt" stuff.) >>=20 >> TIL you can't mix authority and recursive on the same server, when you ar= e >> the target of a forwarder. >>=20 >> If the two are separated, it works correctly, including using an alternat= e >> trust anchor for "alt". >>=20 >> Brian >>=20 >> --001a113fece272cf3b0547e877d3 >> Content-Type: text/html; charset=3DUTF-8 >> Content-Transfer-Encoding: quoted-printable >>=20 >>
TL;DR: it is possible to have a signed DNAME in the ro= ot f=3D >> or alt (to empty.as112.arpa), AND have a local signed alt. Things under t= hi=3D >> s local alt can be signed or unsigned.
> iv class=3D3D"gmail_quote">On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews <= span=3D >> dir=3D3D"ltr"><= marka@i=3D >> sc.org> wrote:
> margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-l= ef=3D >> t:1ex">
>> In message <> SXoM13DTg@mail.gmail.com">CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebht= SX=3D >> oM13DTg@mail.gmail.com>
>> , Brian Dickson writes:
>> >
>> >=3DC2=3DA0 =3DC2=3DA0 - I am in favor of AS112 for ALT
>> >=3DC2=3DA0 =3DC2=3DA0 - For AS112, I prefer the AS112++ method (DNAME= )
>> >=3DC2=3DA0 =3DC2=3DA0 - I do not see why the DNAME would/should not b= e DNSSEC s=3D >> igned
>> >=3DC2=3DA0 =3DC2=3DA0 - Any local use of ALT can be served locally an= d signed u=3D >> sing an
>> >=3DC2=3DA0 =3DC2=3DA0 alternative trust anchor
>>
>> You need a insecure delegation for ALT for the purposes we want to= > r> >> use ALT for.
>>
>> Go setup a test rig where you have a signed root with ALT as you
>> described.=3DC2=3DA0 A validiting recursive server which also serves foo.= alt.> r> >> A second validating recursive server which forwards all queries to
>> the first recursive server.=3DC2=3DA0 All servers are configured with a t= rust> r> >> anchor for the test root zone and are validating responses.=3DC2=3DA0 Try=
>> to perform a lookup on foo.alt.

I spe= nt=3D >> some time mocking up a variety of configurations.

>> My original assertion stands; the particulars on making it work are perh= ap=3D >> s not interesting to everyone.
However, it falls in the "p= ic=3D >> s or it didn't happen" category, so here's what I did to mak= e =3D >> it work.

1 - set up a general resolver with the s= t=3D >> andard ICANN root trust anchor. Call it "X".
2 - set u= p=3D >> a local "fake root server" which delegates to a "local alt= =3D >> server". Call this fake root server "F"
3 - s= e=3D >> t up a local "alt server" which serves the local "alt"= ; =3D >> domain (including any delegations, etc). Cal this "A".
=3D >> 3 - set up a second resolver, with appropriate trust anchor(s), that uses= a=3D >> "fake root server" instead of the real root. Call this "Y&= q=3D >> uot;.
4 - set up a forwarder, which is configured to always for= wa=3D >> rd to "X", except for the zone "alt", where it forwar= ds=3D >> to "Y". Make sure the necessary trust anchors are configured. C= a=3D >> ll this "Z".

Z->Y if QNAME matches &= q=3D >> uot;alt" or "*.alt" (and validates with local trust anchor= s)=3D >>
Z->X otherwise (and validates using the ICANN root trust an= ch=3D >> or).

When I do this, I get real answers for ever= yt=3D >> hing but "alt". For anything at or under "alt", I get= m=3D >> y own local copy.

Everything validates (or is fr= om=3D >> below an insecure delegation point).
=3DC2=3DA0
> ss=3D3D"gmail_quote" style=3D3D"margin:0px 0px 0px 0.8ex;border-left:1px s= olid =3D >> rgb(204,204,204);padding-left:1ex"> >>
>> The second recursive server is the validating client that needs to
>> be able to get a answer other than BOGUS.=3DC2=3DA0 As we want to allow >> foo.alt to be unsigned there can't be any other trust anchors,
>> including negative, configured.

In th= e =3D >> above scenario, you CAN have an unsigned foo.alt, and it will not get BOG= US=3D >> .

If you want me to send you configs, just drop m= e=3D >> a line.=3DC2=3DA0
> px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> >>
>> Only solutions which allow content from the foo.alt zone to be
>> successfully resolved are acceptable.
>>
>> The following will not work with the above rig:
>> * No delegation for ALT.
>> * A secure delegation for ALT.
>> * A DNAME for ALT in the root zone.
>>
>> Mark

The problem is with yo= ur=3D >> set-up, not the ability to have a working local-alt set-up.
=3D >>
You need to put "foo.alt" somewhere OTHER than on th= e =3D >> validating recursive server (which knows how to find the local "alt&= qu=3D >> ot; stuff.)=3DC2=3DA0

TIL you can't mix auth= ority =3D >> and recursive on the same server, when you are the target of a forwarder.= > div>

If the two are separated, it works correctly, inc= lu=3D >> ding using an alternate trust anchor for "alt".

<= /d=3D >> iv>
Brian
>>=20 >> --001a113fece272cf3b0547e877d3-- > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 6 22:31:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0810129A94 for ; Mon, 6 Feb 2017 22:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 uiOv4bkZw4xu for ; Mon, 6 Feb 2017 22:31:54 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C080A1270B4 for ; Mon, 6 Feb 2017 22:31:54 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 53E053493EF; Tue, 7 Feb 2017 06:31:52 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 318EF160048; Tue, 7 Feb 2017 06:31:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1B980160054; Tue, 7 Feb 2017 06:31:52 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tPzV3z7tiWzR; Tue, 7 Feb 2017 06:31:52 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B9401160048; Tue, 7 Feb 2017 06:31:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BC04763357A9; Tue, 7 Feb 2017 17:31:46 +1100 (EST) To: Brian Dickson From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> In-reply-to: Your message of "Mon, 06 Feb 2017 21:50:24 -0800." <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> Date: Tue, 07 Feb 2017 17:31:46 +1100 Message-Id: <20170207063146.BC04763357A9@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 06:31:56 -0000 In message <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com>, Brian Dickson writes: > Mark, > > I don't think the use cases for most of the sandbox involving alt, and/or > the homenet use case, requires support for validating stubs. If stubs > aren't already validating, the incremental addition of a local alt, only > requires distribution of the trust anchor to the resolvers. That is a > solvable problem for most values of "local". It's not just stubs. > If use cases for non-local or validating stubs exits, IMHO that rises to > the level of requiring something real, not an alt name. > > If you think that is something that there is a demand for, I don't know > if it might belong in a separate domain. > > An insecure delegation from the root may be seen as an invitation for > exploitation by squatters. And if they could find a way to squat here (which requires intercepting queries) what would be the problem? We are expecting the namespace to be squatted. Thats the whole point of the namespace. In fact we are going to tell nameserver vendors to squat on .alt by default* to generate the NXDOMAIN responses. There is absolutely no need for a secure NXDOMAIN here. Just as there is zero need for secure NXDOMAINs in COM, ORG, NET or any other gTLD. The gTLDs prevent secure delegations being spoofed away. The don't prevent names being spoofed into existence between the secure delegations. There is absolutely no need for a secure delegation here. I have not seen anyone demonstrate a technical need for a secure delegation for alt. There are no formal delegation in alt so there can be no secure delegations from alt. Mark > Sent from my iPhone -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 6 23:08:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9EF129A9A for ; Mon, 6 Feb 2017 23:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJcX4TdlUVY0 for ; Mon, 6 Feb 2017 23:08:23 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 5A2FF12009C for ; Mon, 6 Feb 2017 23:08:23 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id v184so36167319pgv.3 for ; Mon, 06 Feb 2017 23:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FwP9pv9PZbmBUGvXgCCsAzbT4PtGnozBtnm2ljZSq0s=; b=jgs3I4TrKh7yFBG+v3VaoqA6LxIoQkJ6CM/aVXyyKA1MA1KAcwKoGhGLvy9Z5EknPp dK22u2tzlAAU2u4/F8cSTd6w30fiXTiNOrB6gDihiXlJghP7mtYEzG2LLjY6Q+Ajg1rj F6u6DMUN/SuR17YFTTReGZz2ibLzartw8hyuQP+uC7WxTx5M//q4C6bjd9ng+Eq21Bjs iO/9HjJgQr7HoWf7TYAMD7OFipKzbECFGXDK8LNgd47SPYNjmtGlpzuxQfcYxqxSX+n9 KcxSvWyvFmb9iQXshEucej52S+Z0QIc5GkOjHcesnIjum2JMbuZmfIhVZCyq7/d9kvNo eJFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FwP9pv9PZbmBUGvXgCCsAzbT4PtGnozBtnm2ljZSq0s=; b=U0jA921D+LU/dVLbj8uenzw26wg5XCDyuVvl4ES7lqdYxlThGvAukmveEgQkwKsVnW /qDFN1AC9qHgIBPYwPX7lGg/dC0dn1xDhxAzNdLH7oA99Qo6w8LYo3vdIB7ENI/MU24V Wbca37iEa3BjNkVUQi0dnQcWSbR9IBBW/nq/7nAb+6szHup7HOdYwXKE3PFC5KMGhT67 fVogKTyjXrovImFAZhzlGUpTR1af2qIwwFXn+8fT+wlOeRm76BxL+dQ0b461RONHmD3Y Pjcv/u6cXxDkVy3yGeLct16m6oED5r2UrrKrvdwGippc/XWxzGGf+1rr8t/WfPdnUDx2 Lpvg== X-Gm-Message-State: AIkVDXIH1rnJP2dlwNsDpbn7zNXvD10iXScjUMU7uleJFaBv5HCmvr2Hnc8l+iAZe286kA== X-Received: by 10.84.178.7 with SMTP id y7mr23336871plb.60.1486451302850; Mon, 06 Feb 2017 23:08:22 -0800 (PST) Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id g64sm7902493pfc.57.2017.02.06.23.08.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 23:08:21 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (14D27) In-Reply-To: <20170207063146.BC04763357A9@rock.dv.isc.org> Date: Mon, 6 Feb 2017 23:08:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <99431A77-7B62-4655-89EF-FAA32F2A82F6@gmail.com> References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <20170207063146.BC04763357A9@rock.dv.isc.org> To: Mark Andrews Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 07:08:25 -0000 The suggestion of DNAME to empty.as112.arpa involves some subtle details, wh= ich IMHO may in combination be the right mix here. The DNAME target is an insecure empty zone. This avoids the validation issue, and facilitates use of local "alt" namespa= ces. The default response to queries under alt would be unsigned NXDOMAINs. I am not seeing a problem with this. Am I missing anything? Brian Sent from my iPhone > On Feb 6, 2017, at 10:31 PM, Mark Andrews wrote: >=20 >=20 >=20 >=20 > In message <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com>, Brian Dickson= writes: >> Mark, >>=20 >> I don't think the use cases for most of the sandbox involving alt, and/or= >> the homenet use case, requires support for validating stubs. If stubs >> aren't already validating, the incremental addition of a local alt, only >> requires distribution of the trust anchor to the resolvers. That is a >> solvable problem for most values of "local". >=20 > It's not just stubs. >=20 >> If use cases for non-local or validating stubs exits, IMHO that rises to >> the level of requiring something real, not an alt name. >>=20 >> If you think that is something that there is a demand for, I don't know >> if it might belong in a separate domain. >>=20 >> An insecure delegation from the root may be seen as an invitation for >> exploitation by squatters. >=20 > And if they could find a way to squat here (which requires intercepting > queries) what would be the problem? We are expecting the namespace > to be squatted. Thats the whole point of the namespace. In fact > we are going to tell nameserver vendors to squat on .alt by default* > to generate the NXDOMAIN responses. >=20 > There is absolutely no need for a secure NXDOMAIN here. Just as > there is zero need for secure NXDOMAINs in COM, ORG, NET or any > other gTLD. The gTLDs prevent secure delegations being spoofed > away. The don't prevent names being spoofed into existence between > the secure delegations. >=20 > There is absolutely no need for a secure delegation here. >=20 > I have not seen anyone demonstrate a technical need for a secure > delegation for alt. There are no formal delegation in alt so there > can be no secure delegations from alt. >=20 > Mark >=20 >> Sent from my iPhone > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 6 23:27:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7362129A9D for ; Mon, 6 Feb 2017 23:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 iSacLNb3vXEs for ; Mon, 6 Feb 2017 23:27:56 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05F2129A9C for ; Mon, 6 Feb 2017 23:27:56 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id F230E3493DF; Tue, 7 Feb 2017 07:27:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E2C23160054; Tue, 7 Feb 2017 07:27:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B79D816005C; Tue, 7 Feb 2017 07:27:54 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iR-2EnMXwyxR; Tue, 7 Feb 2017 07:27:54 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 1632C160054; Tue, 7 Feb 2017 07:27:54 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 333B56339A7F; Tue, 7 Feb 2017 18:27:50 +1100 (EST) To: Brian Dickson From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <20170207063146.BC04763357A9@rock.dv.isc.org> <99431A77-7B62-4655-89EF-FAA32F2A82F6@gmail.com> In-reply-to: Your message of "Mon, 06 Feb 2017 23:08:21 -0800." <99431A77-7B62-4655-89EF-FAA32F2A82F6@gmail.com> Date: Tue, 07 Feb 2017 18:27:50 +1100 Message-Id: <20170207072750.333B56339A7F@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 07:27:58 -0000 In message <99431A77-7B62-4655-89EF-FAA32F2A82F6@gmail.com>, Brian Dickson writes: > The suggestion of DNAME to empty.as112.arpa involves some subtle details, > which IMHO may in combination be the right mix here. > > The DNAME target is an insecure empty zone. > > This avoids the validation issue, and facilitates use of local "alt" > namespaces. No it doesn't. > The default response to queries under alt would be unsigned NXDOMAINs. No, it would be a secure response saying that foo.alt is covered by a DNAME. The names under empty.as112.arpa are unsigned NXDOMAINs. The difference between the two descriptions is critical to why a DNAME in the root zone will not work. You *have* to leak names to the root to get a DNAME returned by ordinary processing because the DNAME is signed. > I am not seeing a problem with this. > > Am I missing anything? Yes. A solution that *works*. > Brian > > Sent from my iPhone -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 6 23:56:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E9812941E for ; Mon, 6 Feb 2017 23:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBiSuoesxVJY for ; Mon, 6 Feb 2017 23:56:00 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 39434129488 for ; Mon, 6 Feb 2017 23:56:00 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id c7so73963929itd.1 for ; Mon, 06 Feb 2017 23:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JXgXkYnDg6cEs7lUZW4Sw/p6c7IDj4UAQMY2TqtlOqE=; b=u1z3bw+x2hf08X8glj1N6h4/H33VOt4qK/S6b/exthtHbZ91hlY3z+kOkqyFnGnQWR Q2Jw5MH8X4qSM+dqHkZGc5vXXRM7nEPWaTtrhCCULbWh1CDsg51iyKhumQ3VKywsrumH wlVhIE3VkRZpUCZUvgsmn79fHDrfEJ/3sa/6cU2W5ButMJpMTvzNo843j7A9aeZk4XhY ZvezmYrZsMEBeHbZW+TtXIFF/ISh04fxWh4icHvjw/mh0eX/7fNfx+f3oBUvsk9W/vRL xaMK/YmmshwksEwriCgaNFB68w0Ty1CKhaQ6ppzKHdUmk9yyTfkIGsrNXt09SHAQWlbX ymRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JXgXkYnDg6cEs7lUZW4Sw/p6c7IDj4UAQMY2TqtlOqE=; b=FldJoeAeVtqEokYDftXqbVnhsCZBRABllAMmrGC4oiBu8QuO0hVl5BfZe0yhnh8I4w QTj5bpOUSYUAU8VV44OHCJfOFkHY30eJzfggBlIMSsRklobm0wMTTc5jgSCzQ41uXQLG /TpwUTji+kOEE18S1IV3/fdMwxb/Jb5Knuxf9ck2afT1/FH9q20J3Fu/h+5YmP+PIQ2I yaYPE47uSvegHRaBcUgn8tT6pu5/oRhu8FyAfghWZoTkntu0XvHtdEoylK1U5JH6tBj0 h8vXTun54Z5gDdRWT5sD1AugEkBdMO5NST+v3XFLa/LRpUvghFHhzh/vydQAbYcEMH4H yfTg== X-Gm-Message-State: AIkVDXISoUyR58xVeU8i/42tTQLxN4BnbLEgJzQQsuyEQHHrN7UNSG9S85/xm+rQA8eIaLRgleYS0mObBCP0Pw== X-Received: by 10.36.105.148 with SMTP id e142mr10837502itc.95.1486454159540; Mon, 06 Feb 2017 23:55:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Mon, 6 Feb 2017 23:55:58 -0800 (PST) In-Reply-To: <20170207072750.333B56339A7F@rock.dv.isc.org> References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <20170207063146.BC04763357A9@rock.dv.isc.org> <99431A77-7B62-4655-89EF-FAA32F2A82F6@gmail.com> <20170207072750.333B56339A7F@rock.dv.isc.org> From: Brian Dickson Date: Mon, 6 Feb 2017 23:55:58 -0800 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a113f6fde278e9b0547ec143a Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 07:56:01 -0000 --001a113f6fde278e9b0547ec143a Content-Type: text/plain; charset=UTF-8 On Mon, Feb 6, 2017 at 11:27 PM, Mark Andrews wrote: > > In message <99431A77-7B62-4655-89EF-FAA32F2A82F6@gmail.com>, Brian > Dickson writes: > > The suggestion of DNAME to empty.as112.arpa involves some subtle details, > > which IMHO may in combination be the right mix here. > > > > The DNAME target is an insecure empty zone. > > > > This avoids the validation issue, and facilitates use of local "alt" > > namespaces. > > No it doesn't. > > > The default response to queries under alt would be unsigned NXDOMAINs. > > No, it would be a secure response saying that foo.alt is covered > by a DNAME. The names under empty.as112.arpa are unsigned NXDOMAINs. > > The difference between the two descriptions is critical to why a > DNAME in the root zone will not work. You *have* to leak names to > the root to get a DNAME returned by ordinary processing because the > DNAME is signed. > > > I am not seeing a problem with this. > > > > Am I missing anything? > > Yes. A solution that *works*. > > What are the specific requirements for the solution? I am inferring that the following are needed: The ability to have a local authority server for *.alt, where responses to queries with DO=1 do not include any DNSSEC RRs, i.e. unsigned responses. The ability to have validating forwarders configured to point to one or more resolvers, where the resolvers are configured to use these alt server(s) (directly or indirectly) The ability of validating stub resolvers to accept the answers received (not BOGUS). Does the existence of query rewriting matter, as long as the end result RDATA is the expected value? I.e. If the query is "my-thing.foo.alt", returns a combo of "alt DNAME empty.as112.arpa" plus "my-thing.foo.empty.as112.arpa ", is that acceptable, as long as there is no validation failure? Whatever initiated the DNS call, via the stub, would get back , and presumably be unaware of the presence of the DNAME. I just want to be sure what is or is not acceptable, and what is explicitly within the requirements for a working solution. Brian --001a113f6fde278e9b0547ec143a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 6, 2017 at 11:27 PM, Mark Andrews <marka@isc.org> wrote:

In message <99431A77-7B62-4655-89EF-FAA32F2A82F6@gmail.com>, Brian Di= ckson writes:
> The suggestion of DNAME to empty.as112.arpa involves some subtle detai= ls,
> which IMHO may in combination be the right mix here.
>
> The DNAME target is an insecure empty zone.
>
> This avoids the validation issue, and facilitates use of local "a= lt"
> namespaces.

No it doesn't.

> The default response to queries under alt would be unsigned NXDOMAINs.=

No, it would be a secure response saying that foo.alt is covered
by a DNAME.=C2=A0 The names under empty.as112.arpa are unsigned NXDOMAINs.<= br>
The difference between the two descriptions is critical to why a
DNAME in the root zone will not work.=C2=A0 You *have* to leak names to
the root to get a DNAME returned by ordinary processing because the
DNAME is signed.

> I am not seeing a problem with this.
>
> Am I missing anything?

Yes.=C2=A0 A solution that *works*.


What are the sp= ecific requirements for the solution?

I am inferri= ng that the following are needed:

The ability to h= ave a local authority server for *.alt, where responses to queries with DO= =3D1 do not include any DNSSEC RRs, i.e. unsigned responses.

=
The ability to have validating forwarders configured to point to= one or more resolvers, where the resolvers are configured to use these alt= server(s) (directly or indirectly)

The ability of= validating stub resolvers to accept the answers received (not BOGUS).

Does the existence of query rewriting matter, as long = as the end result RDATA is the expected value?
I.e. If the query = is "my-thing.foo.alt", returns a combo of "alt DNAME empty.a= s112.arpa" plus "my-thing.foo.empty.as112.arpa <RRTYPE> <= ;RRDATA>", is that acceptable, as long as there is no validation fa= ilure?

Whatever initiated the DNS call, via the st= ub, would get back <RRDATA>, and presumably be unaware of the presenc= e of the DNAME.

I just want to be sure what is or = is not acceptable, and what is explicitly within the requirements for a wor= king solution.

Brian

--001a113f6fde278e9b0547ec143a-- From nobody Tue Feb 7 04:11:17 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC3112949D for ; Tue, 7 Feb 2017 04:11:15 -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_HELO_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 C-RoOOF7kNtB for ; Tue, 7 Feb 2017 04:11:13 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) by ietfa.amsl.com (Postfix) with ESMTP id 876BC12940A for ; Tue, 7 Feb 2017 04:11:13 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:33535) by ppsw-42.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cb4c3-000m4g-7K (Exim 4.88) (return-path ); Tue, 07 Feb 2017 12:11:11 +0000 Date: Tue, 7 Feb 2017 12:11:11 +0000 From: Tony Finch To: Brian Dickson In-Reply-To: Message-ID: References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <20170207063146.BC04763357A9@rock.dv.isc.org> <99431A77-7B62-4655-89EF-FAA32F2A82F6@gmail.com> <20170207072750.333B56339A7F@rock.dv.isc.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 12:11:15 -0000 Brian Dickson wrote: > > Does the existence of query rewriting matter, as long as the end result > RDATA is the expected value? > I.e. If the query is "my-thing.foo.alt", returns a combo of "alt DNAME > empty.as112.arpa" plus "my-thing.foo.empty.as112.arpa ", > is that acceptable, as long as there is no validation failure? If there is a local namespace squatting on .alt (directly, not on the rewritten alt.empty.as112.arpa) then this will conflict with the DNAME in the root, which will cause resolution failures. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Irish Sea: West or northwest 4 or 5, increasing 6 at times, becoming variable then southeast later, 3 or 4. Slight or moderate, occasionally rough in south. Rain or squally showers. Moderate or good. From nobody Tue Feb 7 05:07:06 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0336B129BB9 for ; Tue, 7 Feb 2017 05:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7sbh0DvbcH4 for ; Tue, 7 Feb 2017 05:07:03 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 A0970129426 for ; Tue, 7 Feb 2017 05:07:03 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id k15so133715827qtg.3 for ; Tue, 07 Feb 2017 05:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=G+CwDwLt9QN7H/jNMcZej/kiUdXk8Be1ZFTOymovuUw=; b=Sucs/DZnVK3Ewavdy6IRXiLV/8EGFDMdjuBbmjArV2I5kjV6ygXexRvOsQSwPa5Mlk NxDHRDN3hSEekpq8wQQk2hk5x5k78YoOsmpwSawmORWwh2s9umujadcXfDnPVqhYgxQs oqTU+a8UZLO0Ykj1Uxnm4jdB6477mG6iiSO4VVSD2QFR8P3kSRakVeGNvB2R6ASfHkcP gWuMvjdTl6TXbQEhUILZ4JxYxIjSPbE4fl7iB7WcHJEI6vsh1N5UGxPhdPMbW0m9KACY sijJcg4naaVwYPHqU9oQi+bv4nvbDKp4vlJUVKiMmR6oCgCvhG05MQ4MYwWNeY0b5ZOC mQWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=G+CwDwLt9QN7H/jNMcZej/kiUdXk8Be1ZFTOymovuUw=; b=tNFO9+ITsU7PzfgAlGBUCL5nTIBe70bzkPJpWQrEDdq7sjwJZDm5UqBK39+0hL94wN PRGbtIaDr8rDVgLN5b0qp2m6VWMvczoaFBV+7qul76M7BDMHN2G653DAF5EF6ettyH2D BxyT7ZfTi2nblegO8kH/IaplU56TbbNNcRtudFyvVMvIKP2Hp5HzqOHvWw8LIbHzPYgK OampRMeOeiW3YY8C0y+y57CkgXs8EpvU7RvXsmJSrNOg0YRKLpGhhkZQTjXmskewspnW EqObLaMNRRaZyM4sbn1RT8qDOC2urXRxUYRvCXk2ID7Gko60g6hw+5AlyU8HtmFgNQ72 wdNw== X-Gm-Message-State: AMke39l/wqc7QujnV+8yaxOSSq+pFAuoRLr/5r3PGlLa1HMNveKyNiMcUEiLWDbkh8v0PA== X-Received: by 10.200.44.236 with SMTP id 41mr13806766qtx.267.1486472822605; Tue, 07 Feb 2017 05:07:02 -0800 (PST) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id u5sm3288003qkd.46.2017.02.07.05.07.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 05:07:00 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_65C91BE4-5654-4E07-9424-D399E437BC17" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 7 Feb 2017 08:06:59 -0500 In-Reply-To: <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> To: Brian Dickson References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 13:07:05 -0000 --Apple-Mail=_65C91BE4-5654-4E07-9424-D399E437BC17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 7, 2017, at 12:50 AM, Brian Dickson = wrote: > I don't think the use cases for most of the sandbox involving alt, = and/or the homenet use case, requires support for validating stubs. If .alt is being used for non-DNS names, you are correct, because = non-DNS names cannot be validated, and should never enter the validation = process. However, if it is being used for DNS names, then you have to = assume that the stub is validating. Even though that is not the status = quo at present, that's the direction things are likely to go in the = future, and this document needs to continue to be correct in the future. --Apple-Mail=_65C91BE4-5654-4E07-9424-D399E437BC17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 7, 2017, at 12:50 AM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
I don't think the = use cases for most of the sandbox involving alt, and/or the homenet use = case, requires support for validating = stubs.

If = .alt is being used for non-DNS names, you are correct, because non-DNS = names cannot be validated, and should never enter the validation = process.   However, if it is being used for DNS names, then you = have to assume that the stub is validating.   Even though that is = not the status quo at present, that's the direction things are likely to = go in the future, and this document needs to continue to be correct in = the future.

= --Apple-Mail=_65C91BE4-5654-4E07-9424-D399E437BC17-- From nobody Tue Feb 7 07:01:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9429129C8C for ; Tue, 7 Feb 2017 07:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 n4vbDBBYWBa2 for ; Tue, 7 Feb 2017 07:01:25 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 A2C80129BC5 for ; Tue, 7 Feb 2017 07:01:25 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id w75so68166348ywg.1 for ; Tue, 07 Feb 2017 07:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+FxmRYiC3foaeqSTjCC5S45uwXdXnYPDTMSNaBKH1JY=; b=CqdQmmX/aRmzecqXUFqgandMs+5F04nQxmEFQQYJ1LyRNTLCAW0WjY5hmugAFFIIgx kd7NKdvLpsYi0HPANcjAvf7nehBZF4z75IlDmzxkYrpY3dA8pps8UG5uJqCDXUiH6a89 rLI14gtGm4yRuqk2MFkiBJyh2xET8+wsJzofPqf1eTew/5YLQ0AqQlwYLiRnQArJlgNf rIlPUygdfrZGSnE7j+xob+9GkgVFBKrWo9TU3WYQReLKF6/Y5HucNXvKcd8ZDuuYWrw0 uNfxdQYXVL4LrEW/U2lHqLu1uPmnj0vPfx8q4Bz55uJY9gOEGZ/6BbWGn6LaG9l1g9SX pozA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+FxmRYiC3foaeqSTjCC5S45uwXdXnYPDTMSNaBKH1JY=; b=FVC+9a9jplDIY48PgXgJnnu4vuxR4CSzMm5302HXtZ7c/nE+MYlftAyDv/9hZNV9rJ 5G8lblX3Xh3DAarZTVs0NC1xKFh2W+XBFW1Hymc/GkEcgmaQIc7olK/HOBaM9JMDK5AV g1uIXxJXC8EW2S+mXfr86Eh/KoW1P2dgkasf+7PU3EDEZVADusL5aZZGuNM5hJAw4J6D czfScqwiD0FKBX2xX7LLEra1KH9lBQ7OX9L1TMdLepIE+zTCGN05JTyuDDWFJ9SRgLyD 0xcHlInbA6wyn8f8RXPUbsu3MvE67DXP4IaYJ8AUTYoYC/2buDPPffxD3McntLc/ceQQ L7hw== X-Gm-Message-State: AMke39l8oMJmfRPEuLcSSXBrKi07c2H3Ij8hr72I6ZtBIYkwH1wuvtTejCANjrUwmv9x4t+caBJrFYD06Z917KYe X-Received: by 10.129.81.12 with SMTP id f12mr11162864ywb.80.1486479684500; Tue, 07 Feb 2017 07:01:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.237.68 with HTTP; Tue, 7 Feb 2017 07:01:23 -0800 (PST) In-Reply-To: References: <20170203210922.7286C618213C@rock.dv.isc.org> From: Bob Harold Date: Tue, 7 Feb 2017 10:01:23 -0500 Message-ID: To: Brian Dickson Content-Type: multipart/alternative; boundary=001a114630188fb7460547f2055c Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 15:01:31 -0000 --001a114630188fb7460547f2055c Content-Type: text/plain; charset=UTF-8 On Mon, Feb 6, 2017 at 10:37 PM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > TL;DR: it is possible to have a signed DNAME in the root for alt (to > empty.as112.arpa), AND have a local signed alt. Things under this local alt > can be signed or unsigned. > > On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews wrote: > >> >> In message > gmail.com> >> , Brian Dickson writes: >> > >> > - I am in favor of AS112 for ALT >> > - For AS112, I prefer the AS112++ method (DNAME) >> > - I do not see why the DNAME would/should not be DNSSEC signed >> > - Any local use of ALT can be served locally and signed using an >> > alternative trust anchor >> >> You need a insecure delegation for ALT for the purposes we want to >> use ALT for. >> >> Go setup a test rig where you have a signed root with ALT as you >> described. A validiting recursive server which also serves foo.alt. >> A second validating recursive server which forwards all queries to >> the first recursive server. All servers are configured with a trust >> anchor for the test root zone and are validating responses. Try >> to perform a lookup on foo.alt. >> > > I spent some time mocking up a variety of configurations. > > My original assertion stands; the particulars on making it work are > perhaps not interesting to everyone. > However, it falls in the "pics or it didn't happen" category, so here's > what I did to make it work. > > 1 - set up a general resolver with the standard ICANN root trust anchor. > Call it "X". > 2 - set up a local "fake root server" which delegates to a "local alt > server". Call this fake root server "F" > 3 - set up a local "alt server" which serves the local "alt" domain > (including any delegations, etc). Cal this "A". > 3 - set up a second resolver, with appropriate trust anchor(s), that uses > a "fake root server" instead of the real root. Call this "Y". > 4 - set up a forwarder, which is configured to always forward to "X", > except for the zone "alt", where it forwards to "Y". Make sure the > necessary trust anchors are configured. Call this "Z". > > Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust > anchors) > Z->X otherwise (and validates using the ICANN root trust anchor). > > When I do this, I get real answers for everything but "alt". For anything > at or under "alt", I get my own local copy. > > Everything validates (or is from below an insecure delegation point). > > >> >> The second recursive server is the validating client that needs to >> be able to get a answer other than BOGUS. As we want to allow >> foo.alt to be unsigned there can't be any other trust anchors, >> including negative, configured. >> > > In the above scenario, you CAN have an unsigned foo.alt, and it will not > get BOGUS. > > If you want me to send you configs, just drop me a line. > >> >> Only solutions which allow content from the foo.alt zone to be >> successfully resolved are acceptable. >> >> The following will not work with the above rig: >> * No delegation for ALT. >> * A secure delegation for ALT. >> * A DNAME for ALT in the root zone. >> >> Mark > > > The problem is with your set-up, not the ability to have a working > local-alt set-up. > > You need to put "foo.alt" somewhere OTHER than on the validating recursive > server (which knows how to find the local "alt" stuff.) > > TIL you can't mix authority and recursive on the same server, when you are > the target of a forwarder. > > If the two are separated, it works correctly, including using an alternate > trust anchor for "alt". > > Brian > > That's a lot of overhead just to get a local .alt domain. What I envision for the future is an insecure delegation of .alt, and an option in future cable modems to enable a local "homenet.alt" domain, which would just work, even if some stub resolvers in the house are validating. The cable modem is already a recursive resolver or forwarder, and dhcp server, so it seems a logical place for the local domain. -- Bob Harold --001a114630188fb7460547f2055c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 6, 2017 at 10:37 PM, Brian Dickson &l= t;brian.= peter.dickson@gmail.com> wrote:
TL;DR: it is possible to have a signed DNAME in the r= oot for alt (to empty.as112.arpa), AND have a local signed alt. Things unde= r this local alt can be signed or unsigned.
<= br>
On Fri, Feb 3, 2017 at 1:09 = PM, Mark Andrews <marka@isc.org> wrote:

In message <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com>
, Brian Dickson writes:
>
>=C2=A0 =C2=A0 - I am in favor of AS112 f= or ALT
>=C2=A0 =C2=A0 - For AS112, I prefer the AS112++ method (DNAME)
>=C2=A0 =C2=A0 - I do not see why the DNAME would/should not be DNSSEC s= igned
>=C2=A0 =C2=A0 - Any local use of ALT can be served locally and signed u= sing an
>=C2=A0 =C2=A0 alternative trust anchor

You need a insecure delegation for ALT for t= he purposes we want to
use ALT for.

Go setup a test rig where you have a signed root with ALT as you
described.=C2=A0 A validiting recursive server which also serves foo.alt. A second validating recursive server which forwards all queries to
the first recursive server.=C2=A0 All servers are configured with a trust anchor for the test root zone and are validating responses.=C2=A0 Try
to perform a lookup on foo.alt.

= I spent some time mocking up a variety of configurations.

My original assertion stands; the particulars on making it work are= perhaps not interesting to everyone.
However, it falls in the &q= uot;pics or it didn't happen" category, so here's what I did t= o make it work.

1 - set up a general resolver with= the standard ICANN root trust anchor. Call it "X".
2 -= set up a local "fake root server" which delegates to a "loc= al alt server". Call this fake root server "F"
3 - set up a local "alt server" which serves the local "alt= " domain (including any delegations, etc). Cal this "A".
3 - set up a second resolver, with appropriate trust anchor(s), that= uses a "fake root server" instead of the real root. Call this &q= uot;Y".
4 - set up a forwarder, which is configured to alway= s forward to "X", except for the zone "alt", where it f= orwards to "Y". Make sure the necessary trust anchors are configu= red. Call this "Z".

Z->Y if QNAME mat= ches "alt" or "*.alt" (and validates with local trust a= nchors)
Z->X otherwise (and validates using the ICANN root tru= st anchor).

When I do this, I get real answers for= everything but "alt". For anything at or under "alt", = I get my own local copy.

Everything validates (or = is from below an insecure delegation point).
=C2= =A0

The second recursive server is the validating client that needs to
be able to get a answer other than BOGUS.=C2=A0 As we want to allow
foo.alt to be unsigned there can't be any other trust anchors,
including negative, configured.

= In the above scenario, you CAN have an unsigned foo.alt, and it will not ge= t BOGUS.

If you want me to send you configs, just = drop me a line.=C2=A0

Only solutions which allow content from the foo.alt zone to be
successfully resolved are acceptable.

The following will not work with the above rig:
* No delegation for ALT.
* A secure delegation for ALT.
* A DNAME for ALT in the root zone.
<= br> Mark

The problem is wi= th your set-up, not the ability to have a working local-alt set-up.

You need to put "foo.alt" somewhere OTHER than = on the validating recursive server (which knows how to find the local "= ;alt" stuff.)=C2=A0

TIL you can't mix aut= hority and recursive on the same server, when you are the target of a forwa= rder.

If the two are separated, it works correctly= , including using an alternate trust anchor for "alt".

Brian

That's a= lot of overhead just to get a local .alt domain.

= What I envision for the future is an insecure delegation of .alt, and an op= tion in future cable modems to enable a local "homenet.alt" domai= n, which would just work, even if some stub resolvers in the house are vali= dating.=C2=A0 The cable modem is already a recursive resolver or forwarder,= and dhcp server, so it seems a logical place for the local domain.

--=C2=A0
Bob Harold
=C2=A0

--001a114630188fb7460547f2055c-- From nobody Tue Feb 7 08:46:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09FD129D6E for ; Tue, 7 Feb 2017 08:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM-xXTbNIH2V for ; Tue, 7 Feb 2017 08:45:58 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 85A9C129D6C for ; Tue, 7 Feb 2017 08:45:55 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id w20so134938492qtb.1 for ; Tue, 07 Feb 2017 08:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uyQyjpKskgasXwJi6LE4bw3SBI9Ke9ie270blrzY1ko=; b=XLS+hKT/DPhc7P9Z21sYQEPfzosD/zyh4912aOh+kPByWddm5+uA0d6MEzu87qDQJ3 h49xoW4ys9EPJKdIi1k4QG5K2ubLefiqrcpbPyL5dweZQp2oli+ga3D5GCL1C9zPK35u 3OUeFcEjUJsrHu3DYd/sJXhBaiY7LTg6Hl3VyQjadQdT/3XHzi1PeQ7dn/Dyvdnxt49w ODDDJ9vCTWS1cimjBjSRbKZyfodvcBZr4qVg/uwEtTGtMQRJm2Mc6NzKxqJ+wWhEezzf xhxDqmwqgc7SWVe4OsXt8DHI5MYn0KA9jUaEBP0rIHbvlixZrEsw+wRi93KskPM8zI8o WfdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uyQyjpKskgasXwJi6LE4bw3SBI9Ke9ie270blrzY1ko=; b=mEFctMF3GoT7QhdNZuRA2Nl1HSvKQSKjHWYfWmptrEV9/YNGNZI8TB5RAsg5W0qeWB AZ2TSijwFwzO9ReWzj0sniSVxQkRIB6UPpA9nTRS1QeG6agra+dbvkrZGt2WfRV8TCld Ii20xNSM26WsoLMLTdcbZLJ4J7lrI5vIBp+qS585hYnZbLk0R5f94hsK/PXklkcZqUGB Y2rWq8mSgtI89OGoq59bt5zVxVwug2hIur/1kaOSF7m69iPUeoOjrQkhvgg46AL33wxx WBAzG35BUiq9lA0W7Tm86RwjoEMkl0iWFoQ0X72fyehhpIs9CoQStyCsr6IboL6SFSOt ReZA== X-Gm-Message-State: AMke39m8RsvIYeJdsIDxJqBJTOJ+PCZqYMkulFSsVL8HUzbxDDEoOGsBQ+cIhxuMScEamva/lcZ9kLgruGFzhzy/ X-Received: by 10.237.62.68 with SMTP id m4mr14786724qtf.171.1486485954537; Tue, 07 Feb 2017 08:45:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Tue, 7 Feb 2017 08:45:23 -0800 (PST) In-Reply-To: References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> From: Warren Kumari Date: Tue, 7 Feb 2017 11:45:23 -0500 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:46:02 -0000 Yay! Centithread! On Tue, Feb 7, 2017 at 8:06 AM, Ted Lemon wrote: > On Feb 7, 2017, at 12:50 AM, Brian Dickson > wrote: > > I don't think the use cases for most of the sandbox involving alt, and/or > the homenet use case, requires support for validating stubs. > > > If .alt is being used for non-DNS names, you are correct, because non-DNS > names cannot be validated, and should never enter the validation process. > However, if it is being used for DNS names, then you have to assume that the > stub is validating. Even though that is not the status quo at present, > that's the direction things are likely to go in the future, and this > document needs to continue to be correct in the future. I still believe that .alt should be for non-DNS names only -- if they happen to leak into the DNS, this is an error / failure -- the purpose of having .alt as a locally served zone is to preserve the privacy of the queries, not to over-ride them to some other local DNS name. For DNS names, I think that there should be a *different* string (and a different document) -- they have different meanings / behaviors. I don't think I've seen a good argument for NOT doing the above -- why (other thabn the sunk time / effort) don't we do two? W > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Feb 7 09:18:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27279129D9D for ; Tue, 7 Feb 2017 09:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApsogrDSOBBi for ; Tue, 7 Feb 2017 09:18:28 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 87B0C129587 for ; Tue, 7 Feb 2017 09:18:28 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id s140so95130055qke.0 for ; Tue, 07 Feb 2017 09:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DSk6nUyRVxSOeIikxVR/04gH918S0Y0G6BUuPIc92uA=; b=WWt5bywFhQ+ak73Q5pEXpfIaa+sWgOUwCct+0fgWvJ9poNuENgU9YfqqcvxoeDCZ8G 7DdjB6hToe29H2cW6DVJUJBIde3EnlsnY86bpbH6vq2mwd2vfZknaWG2Fjpu7y9EPEXE 6IBlN2cxtDHsAT4Do6nMm8syjP49ZjOpwN110lHplBHCuf5Sm2W4gSuLAKA5EOtXjOTs uYF4nDZaE8BiBIc2zt4a+Qs1kK1fh84lkCRecLqtHe5n8nCEY/vyoOFcHjz18YLUOyz9 w54phHnCG/H6xLCtsZXL/NmkrSONXsWwsrODSv4WRDuDedEGIVSU3sHRxqhQlzAACjW8 XiCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DSk6nUyRVxSOeIikxVR/04gH918S0Y0G6BUuPIc92uA=; b=IgnNAfa/NiViLojt/CEOBpXD15mzuyBgR7ZotOzowJBeL2gPAunVe3lv5Qo9mZ+s6b GWxj9O5QzRPDQagAa2FmwMtgleHosqUNOisVSFRpjkGIvJmqiShSHuNWjib9qeXbzyJm D4rkTgRw+XjA6dawcBFQjgEytvUmoE4PbMh8Am8UJUrTDy03dPntLue6eGz8haiRPNde CAGrrBeRMtvDVBBiDz8uK/nwZdRjhvIFqGeSLYM1OMWXFxJrv/eaHZuhZ8M6AsfIAEiW TCkujaLrdjW1J9absoIeQb+g1Y0IXefzsK0IQDfpCqN6LMVy6lFMh4hMmd4ikJ/KAsQn t8yw== X-Gm-Message-State: AMke39mYNa0QtAhEKIzOM+tz1AWZ6TFdOjw92DQNGuwG2/rVuYgyoZi7mdtL+iI2+ugaBw== X-Received: by 10.55.200.195 with SMTP id t64mr15662690qkl.294.1486487907607; Tue, 07 Feb 2017 09:18:27 -0800 (PST) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id k19sm3838897qtf.37.2017.02.07.09.18.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 09:18:25 -0800 (PST) From: Ted Lemon Message-Id: <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_68DAA081-D6BE-42DA-8523-3753A3650A98" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 7 Feb 2017 12:18:23 -0500 In-Reply-To: To: Warren Kumari References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:18:30 -0000 --Apple-Mail=_68DAA081-D6BE-42DA-8523-3753A3650A98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 7, 2017, at 11:45 AM, Warren Kumari wrote: > I don't think I've seen a good argument for NOT doing the above -- why > (other thabn the sunk time / effort) don't we do two? Right, this just seems obvious to me. If we do two, we can tailor each = solution to the need it is intended to fill, rather than trying to come = up with some compromise that isn't ideal for either case. --Apple-Mail=_68DAA081-D6BE-42DA-8523-3753A3650A98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 7, 2017, at 11:45 AM, Warren Kumari <warren@kumari.net> = wrote:
I don't think I've seen a good argument for NOT = doing the above -- why
(other thabn the sunk time / effort) = don't we do two?

Right, = this just seems obvious to me.   If we do two, we can tailor each = solution to the need it is intended to fill, rather than trying to come = up with some compromise that isn't ideal for either case.

= --Apple-Mail=_68DAA081-D6BE-42DA-8523-3753A3650A98-- From nobody Tue Feb 7 10:50:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F46129418 for ; Tue, 7 Feb 2017 10:50:10 -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 tl_luuPApVrR for ; Tue, 7 Feb 2017 10:50:09 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE68B129428 for ; Tue, 7 Feb 2017 10:50:08 -0800 (PST) Received: (qmail 91565 invoked from network); 7 Feb 2017 18:50:07 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 7 Feb 2017 18:50:07 -0000 Date: 7 Feb 2017 18:49:45 -0000 Message-ID: <20170207184945.10052.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:50:10 -0000 >I don't think I've seen a good argument for NOT doing the above -- why >(other thabn the sunk time / effort) don't we do two? I checked with the protocol police who told me that even with their tasers set to maximum, they can't force people to use the right one. I really doubt that if we bless both .alt and .lcl (or whatever) that the people building stuff will use the one we want them to use. R's, John From nobody Tue Feb 7 10:57:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41C21295AB for ; Tue, 7 Feb 2017 10:57:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gs0_MPv4I0T for ; Tue, 7 Feb 2017 10:57:17 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 E67E9129404 for ; Tue, 7 Feb 2017 10:57:16 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id v23so143898309qtb.0 for ; Tue, 07 Feb 2017 10:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pyC/MViL8Ze7v1kZPH9iaPKkK+Ipw3LJlYQyJCUgKS8=; b=v2ClUPMYxhAJtFECwB/1jR+w5waMSqrPdQAyABEG02yRP1FWhDHOe8OvwIoHMvpH7w bkqz1iCzdIL4UIIwnAnOeB1G1+0z6qfgdneIfJS38atEUtNmkP0XCA3QWDMkiTaYyLQs j7ghYPq55X3hk+ERJHyPqqIQ6RFkqQha5Re7ePiMiZyn7aXGYKUoWMaAyj/XS42dx/Ty WeE1EdbC5WK/fbXPBaAi/6lmzEv+4I4E0a1Zs0gNNNQEVxLAwkFU/uu440vtokQyFn9M vDIoSVa51DQn+aPc0KllRhqSSTQYIfRcK2/++BPOwnoM47abunEcYDmUdSg5AhvlLP9r RvlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pyC/MViL8Ze7v1kZPH9iaPKkK+Ipw3LJlYQyJCUgKS8=; b=A35L/D3BUv7hszfY2zINw2fF7qxTmVV+v7+MqjjfZ2JtStDWKAfIzNavCYnewvvh5i 3FT3u6A2dRL+XSqKZuGYE4fC5ktRYpiCAep7KVPT8gAjHafSMLRs1fqaUytKiRwk2hZh udlQfELSw7zo2WVRLRZSBNo9+KL26JbniQ6NYXgHXPWrlAutJhT2y85ay+VPXA8j/lpq qD62HSgTY7ZhjK0fBHEf0u8Xd4GicBeRve/5GwDEW3z6EHJpl3+l3aatFxJ+qIGtC/tV rIfcHv6KsOLlRMD88kOXDIsNDrrE8mHG55vXxBm0/1tlPdYbeFseF/SBPZ8AXNamUQrZ 8ozQ== X-Gm-Message-State: AMke39nYpiB3UbrMnOZLglsEE9J19GaopMtmuOb4XDCD9D9OFXEus2GAE9+/y3Jo/9HpCQ== X-Received: by 10.237.59.213 with SMTP id s21mr15151529qte.146.1486493835991; Tue, 07 Feb 2017 10:57:15 -0800 (PST) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id b1sm4096880qkc.33.2017.02.07.10.57.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 10:57:14 -0800 (PST) From: Ted Lemon Message-Id: <63D0E93E-BD79-4427-8C7B-DB67582BC156@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3D77C27E-DE0F-4B40-806E-A7C11B91F59B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 7 Feb 2017 13:57:13 -0500 In-Reply-To: <20170207184945.10052.qmail@ary.lan> To: John Levine References: <20170207184945.10052.qmail@ary.lan> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:57:19 -0000 --Apple-Mail=_3D77C27E-DE0F-4B40-806E-A7C11B91F59B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 7, 2017, at 1:49 PM, John Levine wrote: > I really doubt that if we bless both .alt and .lcl (or whatever) that > the people building stuff will use the one we want them to use. Then it won't work for them. But fashionable though this sort of = cynicism is, clear specifications do get read, and not everybody is a = blithering idiot. We can't protect people from shooting themselves in = the foot, but we can make it possible for them not to shoot themselves = in the foot. That's what Warren is proposing. --Apple-Mail=_3D77C27E-DE0F-4B40-806E-A7C11B91F59B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 7, 2017, at 1:49 PM, John Levine <johnl@taugh.com> = wrote:
I really doubt that if we bless both .alt and = .lcl (or whatever) that
the people building stuff will use the = one we want them to use.

Then it won't work for them.   But = fashionable though this sort of cynicism is, clear specifications do get = read, and not everybody is a blithering idiot.   We can't protect = people from shooting themselves in the foot, but we can make it possible = for them not to shoot themselves in the foot.   That's what Warren = is proposing.

= --Apple-Mail=_3D77C27E-DE0F-4B40-806E-A7C11B91F59B-- From nobody Tue Feb 7 12:56:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24490129411 for ; Tue, 7 Feb 2017 12:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 m1kFYhKEW3Hz for ; Tue, 7 Feb 2017 12:56:04 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7891A1293FF for ; Tue, 7 Feb 2017 12:56:04 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id B72481FCB02; Tue, 7 Feb 2017 20:56:00 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7114B160054; Tue, 7 Feb 2017 20:55:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4F505160077; Tue, 7 Feb 2017 20:55:59 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r9WdFCv4UpSL; Tue, 7 Feb 2017 20:55:59 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DD8CC160054; Tue, 7 Feb 2017 20:55:58 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B6974633BE40; Wed, 8 Feb 2017 07:55:54 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> In-reply-to: Your message of "Tue, 07 Feb 2017 12:18:23 -0500." <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> Date: Wed, 08 Feb 2017 07:55:54 +1100 Message-Id: <20170207205554.B6974633BE40@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 20:56:06 -0000 In message <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com>, Ted Lemon writes: > > On Feb 7, 2017, at 11:45 AM, Warren Kumari wrote: > > I don't think I've seen a good argument for NOT doing the above -- why > > (other thabn the sunk time / effort) don't we do two? > > Right, this just seems obvious to me. If we do two, we can tailor each > solution to the need it is intended to fill, rather than trying to come > up with some compromise that isn't ideal for either case. Because we want to prevent the names leaking any further than we have to and to not have the leaked names get SERVFAIL the solution to both is the same. The delegation properties are driven by privacy and the DNS protocol which includes DNSSEC because that is where the leaked names are being looked up. If you really do want to spend the time and effort to create two delegations when only one is needed the only difference is does the recursive server always instantiate the local empty zone or not. i.e. is it recursing rather than iterating to get answers for *.alt. The delegation in the root zone needs the same properties in both cases. For RFC 1918 zones named only instantiates the empty zone when the recursive server will iterate for answers. If it always forwards to another recursive server then the instantiation is blocked. You will note that 10.in-addr.arpa has a insecure delegation in the global dns namespace like every other locally served zone. They have such a delegations so that recursive server can give answers which can be validated regardless of whether the RFC 1918 address space is in use or not. We did good engineering for locally served zones (RFC 6303). Lets follow the good engineering there rather that religiously demand that the delegation be signed because the later does not work. The E in IETF is for ENGINEERING. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 7 13:34:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35603129633 for ; Tue, 7 Feb 2017 13:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1R3yq4NzEIU for ; Tue, 7 Feb 2017 13:34:31 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 1B32812962E for ; Tue, 7 Feb 2017 13:34:30 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id k15so148084854qtg.3 for ; Tue, 07 Feb 2017 13:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H+S0Shz1A1BkcNxQjLOa4eqbRDOTdS1p9j0PxVUN0KM=; b=QMV6DdvpS4xZox+fj/u+F+dxENNNPiT4U7Rdh+LWoFTUPPHT+Deu69WHT+D4eVUokZ 3zaf53KeuVtUVf6feBVEyP6jjzjNOn1pYTBZ1aDnklWn5NuvbQ2N6GZTF6RX3Ll+XGzp PH/dtg77p7/Z1sk7CD+vibAyrl6enNwPbx7xiK5uYZtzsb62k5oCSPta9yEKOZ/zhNTY +SmqK92gUFUHVCeVFti104FgCmqdvCH6jPEkX75JJpxfMY+e+Y+WNghrI74K+Q7HY5Wq 2607jspOGg3cUI4VJ2fGEFaZgLtnu0G6JzUqohebx8X+KgFPtRnX3tZHJs3lStRvxeHZ KI3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H+S0Shz1A1BkcNxQjLOa4eqbRDOTdS1p9j0PxVUN0KM=; b=h+MEfEGly1gGLIEO/dYhc5/DUcc2r4ZNCFpuRlGOF69pnpjJiAPWYlrxggS9Q1bq7I EOTmzzSUHCQvdnJOTCKkRYYsGa7rF/LGD3diRMiyDT6uxDDLVKAagCPI2s7RYuWFpOZ2 gcFDLtUDva6aXAmLXoO01n+HcVhMtuzQbltvAbeZIgJDMsfOGPBDGN53/voUZpC+ghTj lrEFZImH/X83UuqLE2IuknHJTtFBBmohSSAoc+6EJ0ZagVuzUI3DMUplvRRndepa6h8Z kSd7OW/zfynL/JBHdajAIXXdlSEf+6EVNdbm/KoNzGOURp/8l9EJClEM+0I6XKpVCbh9 DVbQ== X-Gm-Message-State: AMke39nZBRbr+w9lZJ1Jbna3GQEBnrXC8iGnNsY+BKB3mGseCsORjVcCqQqff9MvAz90Dg== X-Received: by 10.200.36.75 with SMTP id d11mr16025333qtd.268.1486503269252; Tue, 07 Feb 2017 13:34:29 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id w44sm4441461qta.4.2017.02.07.13.34.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 13:34:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: <20170207205554.B6974633BE40@rock.dv.isc.org> Date: Tue, 7 Feb 2017 16:34:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:34:33 -0000 Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. = When I validate, I get a secure denial of existence. This is the = correct behavior. Why do you think we would get a SERVFAIL? From nobody Tue Feb 7 13:48:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E3F1295DF for ; Tue, 7 Feb 2017 13:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 XQWJbNkEcbjK for ; Tue, 7 Feb 2017 13:48:56 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4019F1294D7 for ; Tue, 7 Feb 2017 13:48:56 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 09F841FCB0D; Tue, 7 Feb 2017 21:48:53 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 99714160054; Tue, 7 Feb 2017 21:48:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 871EC160076; Tue, 7 Feb 2017 21:48:51 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DOjFyORr_T4D; Tue, 7 Feb 2017 21:48:51 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 00841160054; Tue, 7 Feb 2017 21:48:50 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B66EF633C6C5; Wed, 8 Feb 2017 08:48:46 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> In-reply-to: Your message of "Tue, 07 Feb 2017 16:34:25 -0500." <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> Date: Wed, 08 Feb 2017 08:48:46 +1100 Message-Id: <20170207214846.B66EF633C6C5@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:48:57 -0000 In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemon writes: > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > When I validate, I get a secure denial of existence. This is the > correct behavior. Why do you think we would get a SERVFAIL? Because your testing is incomplete. Go add a empty zone (SOA and NS records only) for alt to your recursive server. This is what needs to be done to prevent privacy leaks. Configure another recursive server to forward its queries to this server and enable validation. Now ask for foo.alt from this second server. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 7 13:53:43 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381B31294A4 for ; Tue, 7 Feb 2017 13:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0ZhmMDtxill for ; Tue, 7 Feb 2017 13:53:40 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 974D81288B8 for ; Tue, 7 Feb 2017 13:53:40 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id j18so101226073ioe.2 for ; Tue, 07 Feb 2017 13:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wK5ZZQXFEMNMpp7cwaeNku8A1004p+nYGDlyotJG46g=; b=msIL2PV58G19qEsW/+YTHzNdCth7idQxBwphekclwyFhmoCeI7qKGvKxaBVTGIv+zf 40QkgpikCPJyPmeZF4jz94+NgtFsQ8AG5RGI86RjXd+g3mpwg07V5hac3/rP0VpuBhuG BfCsq9tewf8LHbzVvcOfcCgZyX2+xWslkwXmjtazGW4ST5CW1qsdGg6eDa+Myx/QKK4o 26xIVNGax4QT1wnJMAhtsyX8dcUQxNxIgw+KYjHywxOQoZGU+L3riK4GMiqJaWHgd2Um ZX6PVIAKvOVC8549T9maDoNNwDiOKA2RnUGKxcYJBx0yttN9oV7b2aqK6HXjbjTUTaZ0 6Ncg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wK5ZZQXFEMNMpp7cwaeNku8A1004p+nYGDlyotJG46g=; b=XPV8nHotIcaIdeYDPWP8KZ7PG3tXlSfk0sMxKn7z8akAEVGn8DnOr8ldh9xwdxnZrs owjT9krZoXTppXiwU6UkQgI0rYr8chXEsdO+kaqltql6Nk/DTr59BZR+w5cjzycN3miR ppsr3KfBRr6nWmNR6hyT/sYTDynxdCQ3WcSK0bLB0m4kKnU9NDb8g/u/oxCSkb3tTkWi YdR0+ZooE02sRB0/Qa0e83bdYCLjl0kCZ0NzQ8asafTN5T5yGycsTHaO7W3EFQUJ7pTI n39eemgwpCy/M/l2rlh9y1x8Fv4w7o+34KUZ1J/8NbiMmCm2DmuWnpmtTVk+eK+lKXfk ru3w== X-Gm-Message-State: AMke39mtROjvi/A+Em7IeLnKwOec5b5KZXqLGJbNmJFU5buD9674F2Givl8dxwRi6XB4sP4C6QzsDBXeK+mmVw== X-Received: by 10.107.16.14 with SMTP id y14mr5839016ioi.164.1486504419957; Tue, 07 Feb 2017 13:53:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Tue, 7 Feb 2017 13:53:39 -0800 (PST) In-Reply-To: <20170207214846.B66EF633C6C5@rock.dv.isc.org> References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> From: Brian Dickson Date: Tue, 7 Feb 2017 13:53:39 -0800 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a113fece2e8a7ce0547f7c7b3 Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:53:42 -0000 --001a113fece2e8a7ce0547f7c7b3 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote: > > In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemon > writes: > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > > When I validate, I get a secure denial of existence. This is the > > correct behavior. Why do you think we would get a SERVFAIL? > > Because your testing is incomplete. > > Go add a empty zone (SOA and NS records only) for alt to your > recursive server. This is what needs to be done to prevent > privacy leaks. > > Configure another recursive server to forward its queries to this > server and enable validation. > > I believe this is an erroneous configuration. You need to have the recursive server (the first one) forward to another server for the empty zone, otherwise that zone's contents do not end up in the recursive server's cache. Once you have that, the other recursive server (added and forwarding to the first recursive) only gets back the non-leak results. Since the first server is always forwarding to the empty zone, it never queries the root, and never gets the authenticated denial of existence. Brian > Now ask for foo.alt from this second server. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --001a113fece2e8a7ce0547f7c7b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews <marka@isc.org>= wrote:

In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemo= n writes:
> Hm.=C2=A0 =C2=A0When I look for foo.alt, what I get is NXDOMAIN, not S= ERVFAIL.
> When I validate, I get a secure denial of existence.=C2=A0 =C2=A0This = is the
> correct behavior.=C2=A0 =C2=A0Why do you think we would get a SERVFAIL= ?

Because your testing is incomplete.

Go add a empty zone (SOA and NS records only) for alt to your
recursive server.=C2=A0 This is what needs to be done to prevent
privacy leaks.

Configure another recursive server to forward its queries to this
server and enable validation.


I believe this is an erroneous configu= ration.

You need to have the recursive server (the= first one) forward to another server for the empty zone, otherwise that zo= ne's contents do not end up in the recursive server's cache.
<= div>
Once you have that, the other recursive server (added an= d forwarding to the first recursive) only gets back the non-leak results.

Since the first server is always forwarding to the = empty zone, it never queries the root, and never gets the authenticated den= ial of existence.

Brian
=C2=A0
Now ask for foo.alt from this second server.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0INTERNET: marka@isc.org

--001a113fece2e8a7ce0547f7c7b3-- From nobody Tue Feb 7 14:18:46 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C49F12950F for ; Tue, 7 Feb 2017 14:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq3FaXsmDS3W for ; Tue, 7 Feb 2017 14:18:42 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 8B276129508 for ; Tue, 7 Feb 2017 14:18:42 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id 203so87758247ith.0 for ; Tue, 07 Feb 2017 14:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4GnV+zy3SI5BGFuD+NiYUKG+LhSRAyOO2Kq/LudEkf8=; b=E5xTGyKwozaXhxfH3grCQC3WM+65uZP9D06Z3kDNPNT9d9p95H8axn5HJO7hc5YabT Vo0WXKM5C6/HT+nKMUvkrRKwn8C2ZQpjxH84opFI6zxFcC9A3KIDNOIQNjOBmMMMeloA fv1L4YVBRyStbMctlOydX4wtM+Zkolko09BVn+/jaojJs2upyMCsRSYBAe54c5YRqNQ6 tZz+kFnW8lUOmNJ8TcFkTUvGVFzJK+wXdJ00pEd1rMuv/YQG6v8rYbPoYp0oJHcurZ2e bVTVktTOYGNXcN7zeMHLJ8vdBqE0r2L4fzrroKQXpPr8vUGnb9aRG/YneheieIZ0IxDz KGNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4GnV+zy3SI5BGFuD+NiYUKG+LhSRAyOO2Kq/LudEkf8=; b=kTVGNrx4kNWlzWkvdXFYhiWs0WZik+SHy3MxDmg1PKqZVQvSOh/kMsaGHz1CR74qai vMUwXUoLhD6WQq+7zz7VgfbwxOivxE/es+38fhxn0ktA58vYk8MywJZgcydBuQb4NIs/ DoqYjxutAylLEksALIlishpGAdeb+IDzisB1zqsgk6vyuM6rotw5irTAi/PDQk+8S5eR V7RgpOfhSo9xgKttWeHnbXPh700zPCk+koNG9jv2vz0yW/0vPp5pWMxufA8oMCmm3btE zcp2ZyYLfm/ANLSdQBB6ljGw7x4E0HrvXuXzl2EVmUevPM5/D87U48gvmTdfo8JIRuiR aT/g== X-Gm-Message-State: AIkVDXLjsF902r1k1bOxM2OdINvZclIt6F8mm0gKKz9iMjbWXBpYfh6b6qN0s80P+UrqmoUvMb+DWMknOxYDmQ== X-Received: by 10.36.164.75 with SMTP id v11mr14547985iti.101.1486505921794; Tue, 07 Feb 2017 14:18:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Tue, 7 Feb 2017 14:18:41 -0800 (PST) In-Reply-To: <20170207214846.B66EF633C6C5@rock.dv.isc.org> References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> From: Brian Dickson Date: Tue, 7 Feb 2017 14:18:41 -0800 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=f403045fbba86cf7240547f82103 Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 22:18:45 -0000 --f403045fbba86cf7240547f82103 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote: > > In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemon > writes: > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > > When I validate, I get a secure denial of existence. This is the > > correct behavior. Why do you think we would get a SERVFAIL? > > Because your testing is incomplete. > > Go add a empty zone (SOA and NS records only) for alt to your > recursive server. This is what needs to be done to prevent > privacy leaks. > > Here are some possible alternatives (to having the empty zone be named "alt."). First: make the locally served empty zone be "empty.as112.arpa". Or, second method: have the DNAME RDATA be "alt.empty.as112.arpa", and the locally served zone be the same name. Or, third, have some other name for the zone (anything other than alt, or really anything that doesn't collide with a global name), and then use a local DNAME from "empty.as112.arpa" (or "alt.empty,as112.arpa") to that zone's name (e.g. "homenet" or "homenet.local" or whatever you wish). Since all of the above occur at or below the transition to unsigned, they should validate. (I need to test these, but I don't see why they wouldn't work, and all of the above avoid leaking queries to the root or to AS112 servers.) Brian > Configure another recursive server to forward its queries to this > server and enable validation. > > Now ask for foo.alt from this second server. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --f403045fbba86cf7240547f82103 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews <marka@isc.org>= wrote:

In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemo= n writes:
> Hm.=C2=A0 =C2=A0When I look for foo.alt, what I get is NXDOMAIN, not S= ERVFAIL.
> When I validate, I get a secure denial of existence.=C2=A0 =C2=A0This = is the
> correct behavior.=C2=A0 =C2=A0Why do you think we would get a SERVFAIL= ?

Because your testing is incomplete.

Go add a empty zone (SOA and NS records only) for alt to your
recursive server.=C2=A0 This is what needs to be done to prevent
privacy leaks.


Here are some possible alternatives (t= o having the empty zone be named "alt.").

First: make the locally served empty zone be "empty.as112.arpa"= .

Or, second method: have the DNAME RDATA be "= ;alt.empty.as112.arpa", and the locally served zone be the same name.<= /div>

Or, third, have some other name for the zone (anyt= hing other than alt, or really anything that doesn't collide with a glo= bal name), and then use a local DNAME from "empty.as112.arpa" (or= "alt.empty,as112.arpa") to that zone's name (e.g. "home= net" or "homenet.local" or whatever =C2=A0you wish).

Since all of the above occur at or below the transition t= o unsigned, they should validate. (I need to test these, but I don't se= e why they wouldn't work, and all of the above avoid leaking queries to= the root or to AS112 servers.)

Brian
=C2=A0
Configure another recursive server to forward its queries to this
server and enable validation.

Now ask for foo.alt from this second server.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0INTERNET: marka@isc.org

--f403045fbba86cf7240547f82103-- From nobody Tue Feb 7 15:21:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CCE129641 for ; Tue, 7 Feb 2017 15:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 tynvtIWZ7usU for ; Tue, 7 Feb 2017 15:21:16 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DA81294E7 for ; Tue, 7 Feb 2017 15:21:16 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 4A6391FCAE6; Tue, 7 Feb 2017 23:21:11 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EF8C9160054; Tue, 7 Feb 2017 23:21:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DA964160076; Tue, 7 Feb 2017 23:21:09 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FpA_88iYYvXa; Tue, 7 Feb 2017 23:21:09 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id F3C1E160054; Tue, 7 Feb 2017 23:21:08 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 06A14633CEE5; Wed, 8 Feb 2017 10:21:05 +1100 (EST) To: Brian Dickson From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> In-reply-to: Your message of "Tue, 07 Feb 2017 13:53:39 -0800." Date: Wed, 08 Feb 2017 10:21:04 +1100 Message-Id: <20170207232105.06A14633CEE5@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 23:21:18 -0000 In message , Brian Dickson writes: > On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote: > > > > > In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemon > > writes: > > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > > > When I validate, I get a secure denial of existence. This is the > > > correct behavior. Why do you think we would get a SERVFAIL? > > > > Because your testing is incomplete. > > > > Go add a empty zone (SOA and NS records only) for alt to your > > recursive server. This is what needs to be done to prevent > > privacy leaks. > > > > Configure another recursive server to forward its queries to this > > server and enable validation. > > > > > I believe this is an erroneous configuration. > > You need to have the recursive server (the first one) forward to another > server for the empty zone, otherwise that zone's contents do not end up in > the recursive server's cache. No you don't. The DS query for ALT needs to be answered from the root zone. This can still be done with default empty zones in play. The below is for 10.in-addr.arpa as I can't be bothered with configuring a ALT zone but it shows that it works with shipping code. I run lots of experimental code but not in this area. % dig ds 10.in-addr.arpa +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> ds 10.in-addr.arpa +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2471 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: ba4fd3e10ed3b4972daf8a53589a50ba29889ab19d1a982d (good) ;; QUESTION SECTION: ;10.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 10.in-addr.arpa. 3594 IN RRSIG NSEC 8 3 3600 20170226113733 20170205111120 4341 in-addr.arpa. im4xV0dDtx/ccyflDHOwta5h5hLslomiR4JRHynxSE0Tlm4DenVQ2t7B hwWVGE1eoNuVsagkDiYnRykkQX4bQCChsqKKWTVL57f3onXBmiTWXgWI Ruqzo3Oxa3jlbQ2dgO9bF/xpFrJ3/F7BTyoifA7h33dH1Ef1u2OW3p5p kfvR90s= 10.in-addr.arpa. 3594 IN NSEC 100.in-addr.arpa. NS RRSIG NSEC in-addr.arpa. 3594 IN SOA b.in-addr-servers.arpa. nstld.iana.org. 2016110943 1800 900 604800 3600 in-addr.arpa. 3594 IN RRSIG SOA 8 2 3600 20170301070658 20170207211120 4341 in-addr.arpa. JPiSzCVosbzqFnGmIY+WpANm7Si3cTrSFnTfl5ODB7YfyyzRb0TYsA1o nqpmUw5fQyWHY0nClNfqMEW2V529wT+FoG38SlQBNePtuZSjl3k3WIps snl/3HCY6ZFEaMvq+VmLm/9JQP9Nl2+o3n3qKUErZMxHjeJOmBq4O7E9 j0RUGAE= ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 08 09:56:58 EST 2017 ;; MSG SIZE rcvd: 528 [rock:~/git/bind9] marka% dig soa 10.in-addr.arpa +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> soa 10.in-addr.arpa +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7409 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: ef3c1c716b970b68d635c9d6589a50cceaa7428cb432d7df (good) ;; QUESTION SECTION: ;10.in-addr.arpa. IN SOA ;; ANSWER SECTION: 10.in-addr.arpa. 86400 IN SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 08 09:57:16 EST 2017 ;; MSG SIZE rcvd: 122 [rock:~/git/bind9] marka% Now if I ask with a non recursive query for DS I get the answer from the empty zone. [rock:~/git/bind9] marka% dig ds 10.in-addr.arpa +dnssec +norec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> ds 10.in-addr.arpa +dnssec +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32952 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 330bcb4d5f583a7463a60035589a52444193e9f918ef9905 (good) ;; QUESTION SECTION: ;10.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 10.IN-ADDR.ARPA. 86400 IN SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 08 10:03:32 EST 2017 ;; MSG SIZE rcvd: 122 [rock:~/git/bind9] marka% Now if I add a second validating server forwarding to this server I will only see the first two responses. There are lots of corner cases with DNSSEC which this demonstrates but any server that supports DNSSEC will do. This difference in answers is similar to asking with recursive and non recursive queries for the NS records at a delegation point towards a parent server which supports recursion for the client. You get answers from the child (answer) or parent zone (referral) depending on the state of the RD bit. Mark > Once you have that, the other recursive server (added and forwarding to the > first recursive) only gets back the non-leak results. > > Since the first server is always forwarding to the empty zone, it never > queries the root, and never gets the authenticated denial of existence. Brian. Go do the experiment with VALIDATION ON. You can have heaps of different configurations if you are not validating. Once you have validation being performed then there is only one way to do this that doesn't leak names beyond ALT itself. You can't prevent ALT being leaked if there is a validating client. Mark > Brian > > > Now ask for foo.alt from this second server. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > --001a113fece2e8a7ce0547f7c7b3 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > >


te">On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews < ref=3D"mailto:marka@isc.org" target=3D"_blank">marka@isc.org>= > wrote:
der-left:1px #ccc solid;padding-left:1ex">
=3D"h5">
> In message < .com">18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemo= > n writes:
> > Hm.=C2=A0 =C2=A0When I look for foo.alt, what I get is NXDOMAIN, not S= > ERVFAIL.
> > When I validate, I get a secure denial of existence.=C2=A0 =C2=A0This = > is the
> > correct behavior.=C2=A0 =C2=A0Why do you think we would get a SERVFAIL= > ?
>
>
Because your testing is incomplete.
>
> Go add a empty zone (SOA and NS records only) for alt to your
> recursive server.=C2=A0 This is what needs to be done to prevent
> privacy leaks.
>
> Configure another recursive server to forward its queries to this
> server and enable validation.
>

I believe this is an erroneous configu= > ration.

You need to have the recursive server (the= > first one) forward to another server for the empty zone, otherwise that zo= > ne's contents do not end up in the recursive server's cache.
<= > div>
Once you have that, the other recursive server (added an= > d forwarding to the first recursive) only gets back the non-leak results. div>

Since the first server is always forwarding to the = > empty zone, it never queries the root, and never gets the authenticated den= > ial of existence.

Brian
=C2=A0
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= > cc solid;padding-left:1ex"> > Now ask for foo.alt from this second server.
>

> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2= > 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= > =A0INTERNET: marka@isc.org
>

> > --001a113fece2e8a7ce0547f7c7b3-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 7 15:44:17 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94316129EA0 for ; Tue, 7 Feb 2017 15:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 2I4H3TVfMWMw for ; Tue, 7 Feb 2017 15:44:15 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF764129E90 for ; Tue, 7 Feb 2017 15:44:14 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id EAE681FCB02; Tue, 7 Feb 2017 23:44:10 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A80B4160077; Tue, 7 Feb 2017 23:44:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 92418160076; Tue, 7 Feb 2017 23:44:09 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gMRLM9B_OGNz; Tue, 7 Feb 2017 23:44:09 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 00304160054; Tue, 7 Feb 2017 23:44:08 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 99248633D3CA; Wed, 8 Feb 2017 10:44:05 +1100 (EST) To: Brian Dickson From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> In-reply-to: Your message of "Tue, 07 Feb 2017 14:18:41 -0800." Date: Wed, 08 Feb 2017 10:44:05 +1100 Message-Id: <20170207234405.99248633D3CA@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 23:44:16 -0000 In message , Brian Dickson writes: > --f403045fbba86cf7240547f82103 > Content-Type: text/plain; charset=UTF-8 > > On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote: > > > > > In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemon > > writes: > > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > > > When I validate, I get a secure denial of existence. This is the > > > correct behavior. Why do you think we would get a SERVFAIL? > > > > Because your testing is incomplete. > > > > Go add a empty zone (SOA and NS records only) for alt to your > > recursive server. This is what needs to be done to prevent > > privacy leaks. > > > > > Here are some possible alternatives (to having the empty zone be named > "alt."). > > First: make the locally served empty zone be "empty.as112.arpa". > > Or, second method: have the DNAME RDATA be "alt.empty.as112.arpa", and the > locally served zone be the same name. Which does not work. If you are serving up a local ALT. SOA ... ALT. NS ... ALT. DNAME alt.empty.as112.arpa. then it will not have RRSIG records so it will not validate unless there is a INSECURE delegation for .ALT. I really don't see the point in having the DNAME there other than you seem to want a DNAME there. The public version of the insecure .ALT zone could have a DNAME but we are not talking about those contents at the moment. We are talking about what goes into the root zone to make this work. > Or, third, have some other name for the zone (anything other than alt, or > really anything that doesn't collide with a global name), Nothing doesn't collide with a global name. This is all about carving a namespace out of the global namespace. > and then use a > local DNAME from "empty.as112.arpa" (or "alt.empty,as112.arpa") to that > zone's name (e.g. "homenet" or "homenet.local" or whatever you wish). Homenet is still part of the global namespace. Once there is a delegation and a RFC which states that it is not part of the global namespace then you have other issues or should we start squatting on the homenet space? > Since all of the above occur at or below the transition to unsigned, they > should validate. (I need to test these, but I don't see why they wouldn't > work, and all of the above avoid leaking queries to the root or to AS112 > servers.) > > Brian > > > > > Configure another recursive server to forward its queries to this > > server and enable validation. > > > > Now ask for foo.alt from this second server. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > --f403045fbba86cf7240547f82103 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > >


te">On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews < ref=3D"mailto:marka@isc.org" target=3D"_blank">marka@isc.org>= > wrote:
der-left:1px #ccc solid;padding-left:1ex">
=3D"h5">
> In message < .com">18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemo= > n writes:
> > Hm.=C2=A0 =C2=A0When I look for foo.alt, what I get is NXDOMAIN, not S= > ERVFAIL.
> > When I validate, I get a secure denial of existence.=C2=A0 =C2=A0This = > is the
> > correct behavior.=C2=A0 =C2=A0Why do you think we would get a SERVFAIL= > ?
>
>
Because your testing is incomplete.
>
> Go add a empty zone (SOA and NS records only) for alt to your
> recursive server.=C2=A0 This is what needs to be done to prevent
> privacy leaks.
>

Here are some possible alternatives (t= > o having the empty zone be named "alt.").

v>First: make the locally served empty zone be "empty.as112.arpa"= > .

Or, second method: have the DNAME RDATA be "= > ;alt.empty.as112.arpa", and the locally served zone be the same name.<= > /div>

Or, third, have some other name for the zone (anyt= > hing other than alt, or really anything that doesn't collide with a glo= > bal name), and then use a local DNAME from "empty.as112.arpa" (or= > "alt.empty,as112.arpa") to that zone's name (e.g. "home= > net" or "homenet.local" or whatever =C2=A0you wish).
iv>
Since all of the above occur at or below the transition t= > o unsigned, they should validate. (I need to test these, but I don't se= > e why they wouldn't work, and all of the above avoid leaking queries to= > the root or to AS112 servers.)

Brian
r>
=C2=A0
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > Configure another recursive server to forward its queries to this
> server and enable validation.
>
> Now ask for foo.alt from this second server.
>

> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2= > 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= > =A0INTERNET: marka@isc.org
>

> > --f403045fbba86cf7240547f82103-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 7 16:00:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0A6129514 for ; Tue, 7 Feb 2017 16:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpmobx5m73-b for ; Tue, 7 Feb 2017 16:00:10 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 A532F128B37 for ; Tue, 7 Feb 2017 16:00:10 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id j13so103525453iod.3 for ; Tue, 07 Feb 2017 16:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sy227/Rp3tzSXI0oAKExEg5gskuSP6+xXTDOti3mnio=; b=cpdiTvTv/kxu5iT30i0CLPlhFUXGyq8ibwgIMbSlcI9WAi+Cbmyljo/OWGzx3bJXu0 OQUOcpLh1vhD8/Mtx2wGW1TyA7GKupRfEYu4QBjVTNMoVQhG0rq+Mr9Mie6JlPPUvYXC VX5nBIJqiGHX4neB1zBqNH7JfK6Fg0jkIkfmHvT5tUKirGkCHj2KzC1Nwu6/3cnF4cbK nPRkkJMFCUuwmcQ9ObBWdG4HTaTBlQ0Ryu/YtPxWTLHVdG+dPt0FN807Prt8O2uVcyzk szuO9B03tII16BoM5ykf/VnQUIh/UROrQtz38xB95eZGHbLGv4vwQKFsCqFnH16EglA/ ORBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Sy227/Rp3tzSXI0oAKExEg5gskuSP6+xXTDOti3mnio=; b=XLr+ljDap7dxeTEy04Z3QUYeQC+4y4m3kQNwUxMUyqD8+uV4wycS9AA1sCKqOWcDBD foQrsBPUPQPpTKB86yYKmDMYTnfyRkcIMSl3IA5x6kFP+KCyh1Vt119wC8CX5BGuaRa7 pq7YrVHQ7rIaxOPVcNmv3/JRv3q9uD7r3UR6v/WVr2RY4it9H6IiM6sudNWBiMBMJ0Tm 891NUkzXTEhfSE4gccT1lyGO8s5ZouRQWdv7aNiyHfvDNczy9VjU8IX+wyWaCE8v3SGs U5sWEwkL8P/aLen3MZLXc3j4s7V27SXo6vX5JW8eDUFg8qMHGIC8yxVs7YBPwBCUkiEr L4dA== X-Gm-Message-State: AMke39l9Kqqh0A6PMumpivbXh0yqCUj+H9R1tM32fIKP8deDQAVYhnFMyM/4pMrFIUjNEIT9J7aMez7iMdh+Jg== X-Received: by 10.107.149.18 with SMTP id x18mr6385679iod.167.1486512009876; Tue, 07 Feb 2017 16:00:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Tue, 7 Feb 2017 16:00:09 -0800 (PST) In-Reply-To: <20170207234405.99248633D3CA@rock.dv.isc.org> References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170207234405.99248633D3CA@rock.dv.isc.org> From: Brian Dickson Date: Tue, 7 Feb 2017 16:00:09 -0800 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a1140fee44d9e500547f98cf1 Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 00:00:13 -0000 --001a1140fee44d9e500547f98cf1 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 7, 2017 at 3:44 PM, Mark Andrews wrote: > > In message mail.gmail.com> > , Brian Dickson writes: > > --f403045fbba86cf7240547f82103 > > Content-Type: text/plain; charset=UTF-8 > > > > On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote: > > > > > > > > In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemon > > > writes: > > > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > > > > When I validate, I get a secure denial of existence. This is the > > > > correct behavior. Why do you think we would get a SERVFAIL? > > > > > > Because your testing is incomplete. > > > > > > Go add a empty zone (SOA and NS records only) for alt to your > > > recursive server. This is what needs to be done to prevent > > > privacy leaks. > > > > > > > > Here are some possible alternatives (to having the empty zone be named > > "alt."). > > > > First: make the locally served empty zone be "empty.as112.arpa". > > > > Or, second method: have the DNAME RDATA be "alt.empty.as112.arpa", and > the > > locally served zone be the same name. > > Which does not work. If you are serving up a local > > ALT. SOA ... > ALT. NS ... > ALT. DNAME alt.empty.as112.arpa. > No, I am saying the following: In the root, assume the existence of "ALT. DNAME alt.empty.as112.arpa." Locally, serve your desired content (for what would be reachable below "alt") at: ALT.EMPTY.AS112.ARPA SOA ... ALT.EMPTY.AS112.ARPA NS ... FOO.ALT.EMPTY.AS112.ARPA etc The second DNAME would be for convenience only, so your local zone name isn't causing too much confusion. It does not matter one whit what that zone name (as the DNAME RDATA) would be, so long as it is not at or beneath a real global name. Suppose you want to use "foo.x" instead of "foo.alt.empty.as112.arpa": $ORIGIN alt.empty.as112.arpa. foo DNAME foo.x. foo.x. SOA ... foo.x NS ... $ORIGIN foo.x bar TXT "I am bar.foo.x, reachable via bar.foo.alt.empty.as112.arpa or via bar.foo.alt." The first DNAME gets you default protection via the AS112 empty zone, assuming (the generalized you) are not doing local "alt" things. The local service of "alt.empty" over-rides the insecure empty zone, but does not block the validation path down to it. The second DNAME is for convenience only, or potentially for welding some locally served "homenet" onto "homenet.alt". (The latter I am pointing out the feasibility of, not advocating for.) Brian > > then it will not have RRSIG records so it will not validate unless there > is a INSECURE delegation for .ALT. > > I really don't see the point in having the DNAME there other than you > seem to want a DNAME there. > > The public version of the insecure .ALT zone could have a DNAME but > we are not talking about those contents at the moment. We are > talking about what goes into the root zone to make this work. > > > Or, third, have some other name for the zone (anything other than alt, or > > really anything that doesn't collide with a global name), > > Nothing doesn't collide with a global name. This is all about carving > a namespace out of the global namespace. > > > and then use a > > local DNAME from "empty.as112.arpa" (or "alt.empty,as112.arpa") to that > > zone's name (e.g. "homenet" or "homenet.local" or whatever you wish). > > Homenet is still part of the global namespace. Once there is a delegation > and a RFC which states that it is not part of the global namespace then > you have other issues or should we start squatting on the homenet space? > > > Since all of the above occur at or below the transition to unsigned, they > > should validate. (I need to test these, but I don't see why they wouldn't > > work, and all of the above avoid leaking queries to the root or to AS112 > > servers.) > > > > Brian > > > > > > > > > Configure another recursive server to forward its queries to this > > > server and enable validation. > > > > > > Now ask for foo.alt from this second server. > > > > > > Mark > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > > > > --f403045fbba86cf7240547f82103 > > Content-Type: text/html; charset=UTF-8 > > Content-Transfer-Encoding: quoted-printable > > > >


class=3D"gmail_quo= > > te">On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews dir=3D"ltr">< > ref=3D"mailto:marka@isc.org" target=3D"_blank">marka@isc.org > >= > > wrote:
.8ex;bor= > > der-left:1px #ccc solid;padding-left:1ex">
class= > > =3D"h5">
> > In message < 4CC5-B02C-2E5EA0B8CC23@fugue= > > .com">18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted > Lemo= > > n writes:
> > > Hm.=C2=A0 =C2=A0When I look for foo.alt, what I get is NXDOMAIN, > not S= > > ERVFAIL.
> > > When I validate, I get a secure denial of existence.=C2=A0 > =C2=A0This = > > is the
> > > correct behavior.=C2=A0 =C2=A0Why do you think we would get a > SERVFAIL= > > ?
> >
> >
Because your testing is incomplete.
> >
> > Go add a empty zone (SOA and NS records only) for alt to your
> > recursive server.=C2=A0 This is what needs to be done to prevent
> > privacy leaks.
> >

Here are some possible > alternatives (t= > > o having the empty zone be named "alt.").
< > br>
> v>First: make the locally served empty zone be > "empty.as112.arpa"= > > .

Or, second method: have the DNAME RDATA be > "= > > ;alt.empty.as112.arpa", and the locally served zone be the same > name.<= > > /div>

Or, third, have some other name for the zone > (anyt= > > hing other than alt, or really anything that doesn't collide with a > glo= > > bal name), and then use a local DNAME from "empty.as112.arpa" > (or= > > "alt.empty,as112.arpa") to that zone's name (e.g. > "home= > > net" or "homenet.local" or whatever =C2=A0you > wish).
> iv>
Since all of the above occur at or below the > transition t= > > o unsigned, they should validate. (I need to test these, but I don't > se= > > e why they wouldn't work, and all of the above avoid leaking queries > to= > > the root or to AS112 servers.)

>
Brian
> r>
=C2=A0
style=3D"margin:= > > 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > > Configure another recursive server to forward its queries to this
> > server and enable validation.
> >
> > Now ask for foo.alt from this second server.
> >

> > Mark
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: value=3D"+61298714742">+61 2= > > 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2= > > =A0INTERNET: marka@isc.org
> >

> > > > --f403045fbba86cf7240547f82103-- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --001a1140fee44d9e500547f98cf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 7, 2017 at 3:44 PM, Mark Andrews <marka@isc.org>= wrote:

In message <CAH1iCip=3DJKo4-WiMttKDNs3v_8KzP0PTd13KSPtzL6N7pPHWWQ= @mail.gmail.com>
, Brian Dickson writes:
> --f403045fbba86cf7240547f82103
> Content-Type: text/plain; charset=3DUTF-8
>
> On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews <marka@isc.org> wrote:
>
> >
> > In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>= , Ted Lemon
> > writes:
> > > Hm.=C2=A0 =C2=A0When I look for foo.alt, what I get is NXDOM= AIN, not SERVFAIL.
> > > When I validate, I get a secure denial of existence.=C2=A0 = =C2=A0This is the
> > > correct behavior.=C2=A0 =C2=A0Why do you think we would get = a SERVFAIL?
> >
> > Because your testing is incomplete.
> >
> > Go add a empty zone (SOA and NS records only) for alt to your
> > recursive server.=C2=A0 This is what needs to be done to prevent<= br> > > privacy leaks.
> >
> >
> Here are some possible alternatives (to having the empty zone be named=
> "alt.").
>
> First: make the locally served empty zone be "empty.as112.arpa&qu= ot;.
>
> Or, second method: have the DNAME RDATA be "alt.empty.as112.arpa&= quot;, and the
> locally served zone be the same name.

Which does not work.=C2=A0 If you are serving up a local

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ALT. SOA ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ALT. NS ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ALT. DNAME alt.empty.as112.arpa.

No, I am saying the following:
In the root,= assume the existence of "ALT. DNAME alt.empty.as112.arpa."=C2=A0=

Locally, serve your desired content (for what wou= ld be reachable below "alt") at:

ALT.EMP= TY.AS112.ARPA SOA ...
ALT.EMPTY.AS112.ARPA NS ...
FOO.A= LT.EMPTY.AS112.ARPA <RRTYPE> <RDATA>
etc
The second DNAME would be for convenience only, so your local = zone name isn't causing too much confusion.

It= does not matter one whit what that zone name (as the DNAME RDATA) would be= , so long as it is not at or beneath a real global name.

Suppose you want to use "foo.x" instead of "foo.alt.e= mpty.as112.arpa":
$ORIGIN alt.empty.as112.arpa.
fo= o DNAME foo.x.

foo.x. SOA ...
foo.x NS .= ..
$ORIGIN foo.x
bar TXT "I am bar.foo.x, reachabl= e via bar.foo.alt.empty.as112.arpa or via bar.foo.alt."

=
The first DNAME gets you default protection via the AS112 empty = zone, assuming (the generalized you) are not doing local "alt" th= ings.

The local service of "alt.empty" o= ver-rides the insecure empty zone, but does not block the validation path d= own to it.

The second DNAME is for convenience onl= y, or potentially for welding some locally served "homenet" onto = "homenet.alt".
(The latter I am pointing out the feasib= ility of, not advocating for.)

Brian
=C2= =A0

then it will not have RRSIG records so it will not validate unless there is a INSECURE delegation for .ALT.

I really don't see the point in having the DNAME there other than you seem to want a DNAME there.

The public version of the insecure .ALT zone could have a DNAME but
we are not talking about those contents at the moment.=C2=A0 We are
talking about what goes into the root zone to make this work.

> Or, third, have some other name for the zone (anything other than alt,= or
> really anything that doesn't collide with a global name),

Nothing doesn't collide with a global name.=C2=A0 This is all ab= out carving
a namespace out of the global namespace.

> and then use a
> local DNAME from "empty.as112.arpa" (or "alt.empty,as11= 2.arpa") to that
> zone's name (e.g. "homenet" or "homenet.local"= or whatever=C2=A0 you wish).

Homenet is still part of the global namespace.=C2=A0 Once there is a= delegation
and a RFC which states that it is not part of the global namespace then
you have other issues or should we start squatting on the homenet space?
> Since all of the above occur at or below the transition to unsigned, t= hey
> should validate. (I need to test these, but I don't see why they w= ouldn't
> work, and all of the above avoid leaking queries to the root or to AS1= 12
> servers.)
>
> Brian
>
>
>
> > Configure another recursive server to forward its queries to this=
> > server and enable validation.
> >
> > Now ask for foo.alt from this second server.
> >
> > Mark
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0INTERNET: marka@isc.org > >
>
> --f403045fbba86cf7240547f82103
> Content-Type: text/html; charset=3DUTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D3D"ltr"><br>&= lt;div class=3D3D"gmail_extra"><br><div class=3D3D&qu= ot;gmail_quo=3D
> te">On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews <span dir= =3D3D"ltr">&lt;<a h=3D
> ref=3D3D"mailto:marka@isc.org" target=3D3D"_blank">m= arka@isc.org</a>&gt;</span>=3D
>=C2=A0 wrote:<br><blockquote class=3D3D"gmail_quote"= style=3D3D"margin:0 0 0 .8ex;bor=3D
> der-left:1px #ccc solid;padding-left:1ex"><div class=3D3D&q= uot;HOEnZb"><div class=3D
> =3D3D"h5"><br>
> In message &lt;<a href=3D3D"mailto:18F2EB0D-5BD0-4CC5-B02C-2E5EA0B= 8CC23@fugue=3D
> .com">18F2EB0D-5BD0-4CC5-B02C-<wbr>2E5EA0B8CC23@fugue.com</a>&gt;= , Ted Lemo=3D
> n writes:<br>
> &gt; Hm.=3DC2=3DA0 =3DC2=3DA0When I look for foo.alt, what I get i= s NXDOMAIN, not S=3D
> ERVFAIL.<br>
> &gt; When I validate, I get a secure denial of existence.=3DC2=3DA= 0 =3DC2=3DA0This =3D
> is the<br>
> &gt; correct behavior.=3DC2=3DA0 =3DC2=3DA0Why do you think we wou= ld get a SERVFAIL=3D
> ?<br>
> <br>
> </div></div>Because your testing is incomplete.<= br>
> <br>
> Go add a empty zone (SOA and NS records only) for alt to your<br>= ;
> recursive server.=3DC2=3DA0 This is what needs to be done to prevent&l= t;br>
> privacy leaks.<br>
> <br></blockquote><div><br></div><= ;div>Here are some possible alternatives (t=3D
> o having the empty zone be named &quot;alt.&quot;).</div>= ;<div><br></div><di=3D
> v>First: make the locally served empty zone be &quot;empty.as11= 2.arpa&quot;=3D
> .</div><div><br></div><div>Or, second me= thod: have the DNAME RDATA be &quot=3D
> ;alt.empty.as112.arpa&quot;, and the locally served zone be the sa= me name.<=3D
> /div><div><br></div><div>Or, third, have so= me other name for the zone (anyt=3D
> hing other than alt, or really anything that doesn&#39;t collide w= ith a glo=3D
> bal name), and then use a local DNAME from &quot;empty.as112.arpa&= amp;quot; (or=3D
>=C2=A0 &quot;alt.empty,as112.arpa&quot;) to that zone&= #39;s name (e.g. &quot;home=3D
> net&quot; or &quot;homenet.local&quot; or whatever =3DC2= =3DA0you wish).</div><d=3D
> iv><br></div><div>Since all of the above occur at= or below the transition t=3D
> o unsigned, they should validate. (I need to test these, but I don&= ;#39;t se=3D
> e why they wouldn&#39;t work, and all of the above avoid leaking q= ueries to=3D
>=C2=A0 the root or to AS112 servers.)</div><div><br>&= lt;/div><div>Brian</div><div><b=3D
> r></div><div>=3DC2=3DA0</div><blockquote = class=3D3D"gmail_quote" style=3D3D"margin:=3D
> 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Configure another recursive server to forward its que= ries to this<br>
> server and enable validation.<br>
> <br>
> Now ask for foo.alt from this second server.&l= t;br>
> <div class=3D3D"HOEnZb"><div class=3D3D"h5&quo= t;><br>
> Mark<br>
> --<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D3D"tel:%2B61%202%209871%204742" val= ue=3D3D"+61298714742">+61 2=3D
>=C2=A0 9871 4742</a>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3D
> =3DA0INTERNET: <a href=3D3D"mailto:marka@isc.org">mark= a@isc.org</a><br>
> </div></div></blockquote></div><br>= </div></div>
>
> --f403045fbba86cf7240547f82103--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0INTERNET: marka@isc.org

--001a1140fee44d9e500547f98cf1-- From nobody Tue Feb 7 16:57:06 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BDF129739 for ; Tue, 7 Feb 2017 16:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 FCSpNp9-CUf8 for ; Tue, 7 Feb 2017 16:56:58 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220B6129771 for ; Tue, 7 Feb 2017 16:56:55 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id A6108349476; Wed, 8 Feb 2017 00:56:52 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7EE9F160077; Wed, 8 Feb 2017 00:56:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6EC8E160076; Wed, 8 Feb 2017 00:56:52 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OQhFnIvbUWpg; Wed, 8 Feb 2017 00:56:52 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 6950F160054; Wed, 8 Feb 2017 00:56:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E8281633D93F; Wed, 8 Feb 2017 11:56:46 +1100 (EST) To: Brian Dickson From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170207234405.99248633D3CA@rock.dv.isc.org> In-reply-to: Your message of "Tue, 07 Feb 2017 16:00:09 -0800." Date: Wed, 08 Feb 2017 11:56:46 +1100 Message-Id: <20170208005646.E8281633D93F@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 00:57:00 -0000 In message , Brian Dickson writes: > --001a1140fee44d9e500547f98cf1 > Content-Type: text/plain; charset=UTF-8 > > On Tue, Feb 7, 2017 at 3:44 PM, Mark Andrews wrote: > > > > > In message > mail.gmail.com> > > , Brian Dickson writes: > > > --f403045fbba86cf7240547f82103 > > > Content-Type: text/plain; charset=UTF-8 > > > > > > On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote: > > > > > > > > > > > In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemon > > > > writes: > > > > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > > > > > When I validate, I get a secure denial of existence. This is the > > > > > correct behavior. Why do you think we would get a SERVFAIL? > > > > > > > > Because your testing is incomplete. > > > > > > > > Go add a empty zone (SOA and NS records only) for alt to your > > > > recursive server. This is what needs to be done to prevent > > > > privacy leaks. > > > > > > > > > > > Here are some possible alternatives (to having the empty zone be named > > > "alt."). > > > > > > First: make the locally served empty zone be "empty.as112.arpa". > > > > > > Or, second method: have the DNAME RDATA be "alt.empty.as112.arpa", and > > the > > > locally served zone be the same name. > > > > Which does not work. If you are serving up a local > > > > ALT. SOA ... > > ALT. NS ... > > ALT. DNAME alt.empty.as112.arpa. > > > > No, I am saying the following: > In the root, assume the existence of "ALT. DNAME alt.empty.as112.arpa." So how do you get the DNAME returned without leaking a qname? Answer: You don't with current nameservers. To prevent leaking you need to have something that regularly asks for ALT/DNAME so that the answer is in the cache before the first *.alt name comes along or you special case *.alt, make a DNAME query for ALT instead of *.alt then resume the original query processing. That is new code just to avoid a insecure delegation in the root zone when we know we need a insecure delegation in the root zone for .homenet. You also generate bigger answers, run the risk of returning YXDOMAIN and increase the validation cost. There is a place for that DNAME in a insecurely delegated ALT zone. That sinks all the traffic that is not caught by the other mechanism. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 7 20:51:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815341298BA for ; Tue, 7 Feb 2017 20:51:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUVjtBC1Ne7d for ; Tue, 7 Feb 2017 20:51:08 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 009011298A5 for ; Tue, 7 Feb 2017 20:51:07 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id s186so111126059qkb.1 for ; Tue, 07 Feb 2017 20:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wqSXtdshvhlJWeKhyIDr130Qa2fsMfTLQbOtQQ0+NKA=; b=crGUFSawFVGP5q2eKCQuAfFIvBVbRsCMwQNcL5DgrZowZDfsoHEjJPTNWlLS2/23OT CIKxxPTlpsPXjxD4UKmYRzAh4EEJYMN+yoMwCo0YoC4o94nZl6fKlvOk+LdUuFKn8O/l Rg07tyDp+rTHab6fnnk14t5Qmdr9fSrQfBZlV/oUcOpnYWoko93dRJTU1JO7pj1bzauV gCAwhWhkyNVJkfnq2M/C4YY3XEJZjfVlcfZW6tiQroB/Z/2iqHkxKboH78FA/Yy3hyA7 hqrCeXp79viQ9W5VWftKC1aJ+cR02fv9WKziOevZq6gEzY9StFlKYIe2dpPsU6S/1fbT PGkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wqSXtdshvhlJWeKhyIDr130Qa2fsMfTLQbOtQQ0+NKA=; b=o/WzAhfn18E8XzbeprqagC3tZ+THKM0gMYJ9VZPWdxzioK4sJL8oAX1wQu74FQMHRZ 4Us/0A+2qillWTUhoXNuMPtmfLRSjIoYlhvdcSVP1lNtbE3Q0AARucx7Vp6E01weRySM hoolrzvKjmWAX5322OIHdmC6yRxw/RQhkwnOCr+gpxdTbcBGwyK1EauEmWe0IeHhPnGg +wFLzM2ea5v5mXX9kkCS9EKHKYLeDpvzbKn5xQztzjdeiJ2FmUZBhwpxEUzzkvRot88C r6j3EVWA/B+jQE2CSWxaaVugpbe2dvalT2xlw3CT0pR25oHGatgslqnO/gG3DInPGu6n njcw== X-Gm-Message-State: AMke39lB25YGXguYdymPOPtNGtQ/dekM9aPueP3GuIvVXZwIcE8BjuVehZB/St4Y4uyCNg== X-Received: by 10.55.16.67 with SMTP id a64mr18054746qkh.226.1486529467023; Tue, 07 Feb 2017 20:51:07 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 7sm5282963qkx.49.2017.02.07.20.51.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 20:51:05 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F2B545AB-BF45-4AAE-8E5C-CBE4A688F3C0" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 7 Feb 2017 23:51:03 -0500 In-Reply-To: <20170207214846.B66EF633C6C5@rock.dv.isc.org> To: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 04:51:09 -0000 --Apple-Mail=_F2B545AB-BF45-4AAE-8E5C-CBE4A688F3C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 7, 2017, at 4:48 PM, Mark Andrews wrote: > Go add a empty zone (SOA and NS records only) for alt to your > recursive server. This is what needs to be done to prevent > privacy leaks. No, the recursive server can just cache the proof of nonexistence. I = didn't query the root when I did my test=E2=80=94I ran the query through = comcast's servers. Worked just fine. Yes, if you configure your = local server to lie, that won't work. That's by design. --Apple-Mail=_F2B545AB-BF45-4AAE-8E5C-CBE4A688F3C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 7, 2017, at 4:48 PM, Mark Andrews <marka@isc.org> = wrote:
Go add a empty zone (SOA and NS records only) = for alt to your
recursive server.  This is what = needs to be done to prevent
privacy = leaks.

No, = the recursive server can just cache the proof of nonexistence.   I = didn't query the root when I did my test=E2=80=94I ran the query through = comcast's servers.   Worked just fine.   Yes, if you configure = your local server to lie, that won't work.   That's by = design.

= --Apple-Mail=_F2B545AB-BF45-4AAE-8E5C-CBE4A688F3C0-- From nobody Tue Feb 7 21:25:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEC5129980 for ; Tue, 7 Feb 2017 21:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 OxKhf8UDZ4re for ; Tue, 7 Feb 2017 21:25:55 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E4412997F for ; Tue, 7 Feb 2017 21:25:55 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 2452D3493CF; Wed, 8 Feb 2017 05:25:49 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 04BFD16004F; Wed, 8 Feb 2017 05:25:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DA6E5160054; Wed, 8 Feb 2017 05:25:48 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GpB9GmNzf75B; Wed, 8 Feb 2017 05:25:48 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 5B3E216004F; Wed, 8 Feb 2017 05:25:48 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 862956356F33; Wed, 8 Feb 2017 16:25:44 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> In-reply-to: Your message of "Tue, 07 Feb 2017 23:51:03 -0500." Date: Wed, 08 Feb 2017 16:25:44 +1100 Message-Id: <20170208052544.862956356F33@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 05:25:57 -0000 In message , Ted Lemon writes: > > On Feb 7, 2017, at 4:48 PM, Mark Andrews wrote: > > Go add a empty zone (SOA and NS records only) for alt to your > > recursive server. This is what needs to be done to prevent > > privacy leaks. > > No, the recursive server can just cache the proof of nonexistence. I > didn't query the root when I did my test—I ran the query through > comcast's servers. Worked just fine. Yes, if you configure your local > server to lie, that won't work. That's by design. And how does the server get the proof of non-existence? It needs to leak a query. You server asked comcasts servers. They in turn asked the root servers. By doing so you leaked the query to both comcast and the root. Unless you have aggressive negative caching or qname minimisation you will leak all the leaked *.alt names. Are you requiring that every recursive nameserver on the planet older than a couple of months be upgraded rather than reconfigured to get privacy? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 7 21:44:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7391299A2 for ; Tue, 7 Feb 2017 21:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz1j_RpkBVqI for ; Tue, 7 Feb 2017 21:44:20 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 5FA9B12954E for ; Tue, 7 Feb 2017 21:44:20 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id s140so112049007qke.0 for ; Tue, 07 Feb 2017 21:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PVqlJXKhPjtS3YMPcCyRMjndXaqqJLPkhyeBwneYr4Y=; b=0W9lHWyAlbLom0DtZ3RUghO5wNK/NOz/p2eFhlS8u8J0pbI5FuENg7+AIvc2lBCLz+ UAZI4k/SfIrDoqOV0/vNgm+IjBSnUa5oBq2ToP+bUmtsBQwrM6ihUGUnM4WQ5/0zAiX/ ueNeMEaYgMIKlJRGOPpJtYF6lHYYcuJm6dWwX0OI8mbPFP1x7nn/DuDoMBJRDwH9Dm2W lxKKmmKGYHzJCwm83VCSAbhMi8pE6cmxehhI2wuuecLajANj2uBzeA410rQnGksFbz2k FhyfZ5zosi1l1l1Xguoq8yOYMQC7B+EkR+QKX9LwyEEv/KO8xNjNZHwigu2Owt62xyEp tkcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PVqlJXKhPjtS3YMPcCyRMjndXaqqJLPkhyeBwneYr4Y=; b=oebYNEPRCspivPMbjP4jvg1zN03N0/RbOihagNhw7mmv4vk2B3OcnsBLc2+zHeQkHY 2cg+SnWJmQx5lk0gaeZ8D/wU2H/OzYp+hr+Cgrxv5yI7cTE0pJqOrrFEXVhLQeh+TQWL aMpvZiOGHVRYdxUbenoTkA1hyz94WMTsuyr5Tmx8jwnL4PahUTKEzziVgusfuDUzhZyH ruJVtgXgxeNR64/J4WNZcCUWXtejuEaiESaoSkYmoa4XAcDqM1F9s/OlfiljWz8kLe2+ s60c/1cO/Wt+WBAeLoeK2u9IqgeqxVm2/X5n3DisWsTh0qgGXDs4C0e8b2luDbU8W9hQ zFnQ== X-Gm-Message-State: AMke39kkOPHoT/bfZNTzOMVkz2uUvFA0i/XAQ2OdgaMEoI5vMphrztCsIf4MTJ1BC4SiWw== X-Received: by 10.55.221.79 with SMTP id n76mr17308295qki.276.1486532659582; Tue, 07 Feb 2017 21:44:19 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id p7sm5360121qtf.47.2017.02.07.21.44.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 21:44:18 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_06269020-BA56-4FA9-BB6B-23D241822035" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 00:44:16 -0500 In-Reply-To: <20170208052544.862956356F33@rock.dv.isc.org> To: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 05:44:22 -0000 --Apple-Mail=_06269020-BA56-4FA9-BB6B-23D241822035 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 8, 2017, at 12:25 AM, Mark Andrews wrote: > And how does the server get the proof of non-existence? It needs > to leak a query. If it has proof of non-existence for .alt cached, it doesn't need to ask = any further questions to deny the existence of any subdomain of .alt. = Leaking a query to .alt is harmless. --Apple-Mail=_06269020-BA56-4FA9-BB6B-23D241822035 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 8, 2017, at 12:25 AM, Mark Andrews <marka@isc.org> = wrote:
And how does the server get the proof of = non-existence?  It needs
to leak a = query.

If = it has proof of non-existence for .alt cached, it doesn't need to ask = any further questions to deny the existence of any subdomain of .alt. =   Leaking a query to .alt is harmless.

= --Apple-Mail=_06269020-BA56-4FA9-BB6B-23D241822035-- From nobody Tue Feb 7 22:02:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870671299DC for ; Tue, 7 Feb 2017 22:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 yKIxHyCFzFAD for ; Tue, 7 Feb 2017 22:02:19 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE6F1299DB for ; Tue, 7 Feb 2017 22:02:19 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 220581FCB02; Wed, 8 Feb 2017 06:02:14 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C6B0C16004F; Wed, 8 Feb 2017 06:02:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A9448160054; Wed, 8 Feb 2017 06:02:12 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id shfLlBZa4nCi; Wed, 8 Feb 2017 06:02:12 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 38AEC16004F; Wed, 8 Feb 2017 06:02:12 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8C8E1635864D; Wed, 8 Feb 2017 17:02:08 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> In-reply-to: Your message of "Wed, 08 Feb 2017 00:44:16 -0500." Date: Wed, 08 Feb 2017 17:02:08 +1100 Message-Id: <20170208060208.8C8E1635864D@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 06:02:20 -0000 In message , Ted Lemon writes: > > On Feb 8, 2017, at 12:25 AM, Mark Andrews wrote: > > And how does the server get the proof of non-existence? It needs > > to leak a query. > > If it has proof of non-existence for .alt cached, it doesn't need to ask > any further questions to deny the existence of any subdomain of .alt. Which assumes agggressive negative caching. I'm going to make a realistic assumption that it will take 10+ years for there to be meaningful (>50%) deployment of aggressive negative caching. > Leaking a query to .alt is harmless. Is it? What reports are we going to see over the next 20 year of DITL data on *.alt. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 8 00:36:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598D3129636 for ; Wed, 8 Feb 2017 00:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 W5tnYuubNsxF for ; Wed, 8 Feb 2017 00:36:27 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6BA129623 for ; Wed, 8 Feb 2017 00:36:27 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 864532806BA; Wed, 8 Feb 2017 09:36:25 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 7FAAE2806B8; Wed, 8 Feb 2017 09:36:25 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 7DA8CB3800C; Wed, 8 Feb 2017 09:35:55 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 71BD540335; Wed, 8 Feb 2017 09:35:55 +0100 (CET) Date: Wed, 8 Feb 2017 09:35:55 +0100 From: Stephane Bortzmeyer To: Mark Andrews Message-ID: <20170208083555.sv6t7esbewfblu3r@nic.fr> References: <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170208060208.8C8E1635864D@rock.dv.isc.org> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 08:36:29 -0000 On Wed, Feb 08, 2017 at 05:02:08PM +1100, Mark Andrews wrote a message of 30 lines which said: > > If it has proof of non-existence for .alt cached, it doesn't need > > to ask any further questions to deny the existence of any > > subdomain of .alt. > > Which assumes agggressive negative caching. If by "aggressive negative caching", you mean draft-ietf-dnsop-nsec-aggressiveuse, then I disagree with you: it is *not* necessary (since the name is the same), you just need RFC 8020 support. > I'm going to make a realistic assumption that it will take 10+ years > for there to be meaningful (>50%) deployment of aggressive negative > caching. I would be quite happy to have RFC 8020 in BIND, if you don't mind :-) From nobody Wed Feb 8 00:43:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4733A129959 for ; Wed, 8 Feb 2017 00:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Vj5PSspSSg-t for ; Wed, 8 Feb 2017 00:43:46 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3DB129487 for ; Wed, 8 Feb 2017 00:43:46 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id B28062806BA; Wed, 8 Feb 2017 09:43:44 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id AD44E2806B8; Wed, 8 Feb 2017 09:43:44 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id AB9D9B38003; Wed, 8 Feb 2017 09:43:14 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id A566340335; Wed, 8 Feb 2017 09:43:14 +0100 (CET) Date: Wed, 8 Feb 2017 09:43:14 +0100 From: Stephane Bortzmeyer To: Ray Bellis Message-ID: <20170208084314.dqpqw3meow76wmer@nic.fr> References: <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 08:43:47 -0000 On Mon, Feb 06, 2017 at 06:12:31PM +0000, Ray Bellis wrote a message of 28 lines which said: > The "locally served zones" and "special use domains" registries are > different. Why are they different, by the way? I really do not understand that. The "locally served zones" registry should be a strict subset of the "special use domains" registry, for the case where RFC 6761 says "4. Caching DNS Servers: Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?" and the answer is "serve locally". [Speaking of this, the lack of a formal language in the "special use domains" registry, allowing a resolver to be compiled with automatic inclusion of all the special cases, is the only really serious problem in RFC 6761. I regret that draft-ietf-dnsop-sutld-ps-02 does not even mention it.] > It's possible that some special use domains might benefit from > special treatment in the root zone, too (".localhost" ?) Let me advertise again my draft :-) draft-bortzmeyer-dname-root From nobody Wed Feb 8 00:47:06 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B0712941E for ; Wed, 8 Feb 2017 00:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 9rRb5L3AHdmF for ; Wed, 8 Feb 2017 00:47:03 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864C9129959 for ; Wed, 8 Feb 2017 00:47:03 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 19E7C2806BA; Wed, 8 Feb 2017 09:47:02 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 145982806B8; Wed, 8 Feb 2017 09:47:02 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 1284DB38025; Wed, 8 Feb 2017 09:46:32 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 0C74F40337; Wed, 8 Feb 2017 09:46:32 +0100 (CET) Date: Wed, 8 Feb 2017 09:46:32 +0100 From: Stephane Bortzmeyer To: Tony Finch Message-ID: <20170208084631.2gttv6nfmjtri4hh@nic.fr> References: <20170206040516.1701.qmail@ary.lan> <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: dnsop@ietf.org, Ray Bellis Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 08:47:05 -0000 On Mon, Feb 06, 2017 at 04:55:19PM +0000, Tony Finch wrote a message of 36 lines which said: > > Yes, that's right, with the caveat that all existing locally > > served zones are in the reverse space - there's no forward zones > > registered (yet). > > There are several :-) RFC 6761 specifies localhost, invalid, test as > locally served zones. De facto, yes. But it does not use this language, and these names are not in From nobody Wed Feb 8 01:16:13 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FB0129810 for ; Wed, 8 Feb 2017 01:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 5PXO_yWMUzGT for ; Wed, 8 Feb 2017 01:16:09 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C655A129614 for ; Wed, 8 Feb 2017 01:16:09 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2C24A2806BD; Wed, 8 Feb 2017 10:16:08 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 265232806B8; Wed, 8 Feb 2017 10:16:08 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id C0FA2B38027; Wed, 8 Feb 2017 10:15:36 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 6F33B40337; Wed, 8 Feb 2017 10:15:36 +0100 (CET) Date: Wed, 8 Feb 2017 10:15:36 +0100 From: Stephane Bortzmeyer To: Suzanne Woolf Message-ID: <20170208091536.vqwftrhpole33opl@nic.fr> References: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: dnsop Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 09:16:11 -0000 On Thu, Feb 02, 2017 at 06:04:05PM -0500, Suzanne Woolf wrote a message of 82 lines which said: > This message opens a Working Group Last Call for: > > "Special-Use Names Problem Statement" I've read draft-ietf-dnsop-sutld-ps-02 I'm not convinced that there really is a "problem" with special-use domain names and I would like to see some sort of applicability statement saying (I send text...) "The issues listed here should not be interpreted as indicating that special-use domain names should not be reserved and used. While we may see one day a RFC 6761bis, in the mean time, the process it describes should continue to be open and available." Biggest problem with the draft: it fails to mention the only real technical problem with RFC 6761, the lack of a formal language for the registry, thus preventing the programmers of resolving software to compile automatically the code for the various cases. I send text: after the paragraph "When a special-use Domain Name is added to the special-use Domain Names registry, not all software that processes such names will understand the special use of that name.", add: o This problem is made more difficult by the fact that there is no formal language for the registry. The list of SUDN with their specific requirments is not machine-readable. As a result, software developers who write resolving code have to translate the registry by hand into their code, a process which is painful, brittle, and unlikely to be repeated often (thus making software obsolete with respect to the registry). Now, the details: > Both ICANN and the IETF have the authority and formal processes to > assign names from the pool of unused names, but no formal > coordination process exists. As I said several times, this is not true Was this mechanism used once for special-use domain names? What was the result? > Organizations do in fact sometimes commandeer subsets of the > namespace. Reasons a third party might do this include: There are others: * Intended use is covered by gTLD process, don't recognize ICANN's right to block these TLD * Intended use is covered by some IETF process, but the process is too long, too bureaucratice and too incertain [before you jump on this one, remember IETF never replied to requests to reserve names like .bit or .zkey] > the fact of its unilateral use by the TOR project without following > the RFC 6761 process This is ridiculous, .onion was used since 2004 and RFC 6761 was published in 2013. From nobody Wed Feb 8 02:37:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC771299E9 for ; Wed, 8 Feb 2017 02:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 ZQEMaQ_2e_nZ for ; Wed, 8 Feb 2017 02:37:18 -0800 (PST) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DFA1299E8 for ; Wed, 8 Feb 2017 02:37:18 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v18AbGCu023578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2017 03:37:16 -0700 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 8DDAA1E0049; Wed, 8 Feb 2017 04:37:11 -0600 (CST) Received: from lxdnp32k.corp.intranet (unknown [151.117.18.14]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 67BBC1E003F; Wed, 8 Feb 2017 04:37:11 -0600 (CST) Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v18AbBHN032751; Wed, 8 Feb 2017 03:37:11 -0700 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v18AbAUK032748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Feb 2017 03:37:10 -0700 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0294.000; Wed, 8 Feb 2017 04:37:10 -0600 From: "Woodworth, John R" To: "'dnsop@ietf.org'" Thread-Topic: New Version Notification for draft-woodworth-bulk-rr-04.txt Thread-Index: AQHSgfW/v/1e+SB2+U+Wpl6/e37X2KFe6NAw Date: Wed, 8 Feb 2017 10:37:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: 'JW' , 'shash raghu' , "Woodworth, John R" , "Ballew, Dean" Subject: [DNSOP] FW: New Version Notification for draft-woodworth-bulk-rr-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 10:37:19 -0000 QWxsLA0KDQpJIGp1c3Qgc3VibWl0dGVkIC0wNCBpbiByZXNwb25zZSB0byBjb21tZW50cyByZWNl aXZlZC4NCg0KQXMgdXN1YWwsIGFsbCBmZWVkYmFjayBpcyB3ZWxjb21lLg0KDQoNClRoYW5rcyBh Z2FpbiwNCkpvaG4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCioqICBJLUQgIkJVTEsgRE5TIFJlc291cmNlIFJlY29yZHMiIE1pbmkt RkFRICAgMDEtMzEtMTcgKioNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpRKSBXaHkgZG8gd2UgbmVlZCBCVUxLIFJScz8NCkEp IEJVTEsgaXMgYSB0b29sIGxpa2UgbWFueSBvdGhlcnMuDQogICBJdCB3YXMgZGVzaWduZWQgdG8g aGVscCBzaW1wbGlmeSB0aGUgbWFuYWdlbWVudCBvZg0KICAgcGF0dGVybiBiYXNlZCAiZ2VuZXJp YyIgcmVjb3JkcyBhbmQgc2NhbGUgdG8gZml0IHRoZQ0KICAgZ3Jvd2luZyBkZW1hbmQgb2YgSVB2 NiBzdXBwb3J0LiBJdCBidWlsZHMgb24gcG9wdWxhcg0KICAgdGVjaG5vbG9neSBjdXJyZW50bHkg dXNlZCB0b2RheSB3aGlsZSBwcm92aWRpbmcgYQ0KICAgbnVtYmVyIG9mIG1vZGVybiBlbmhhbmNl bWVudHMuIFRoZSBhdXRob3JzIGZlZWwgQlVMSw0KICAgaXMgdGhlIG5leHQgbG9naWNhbCBwcm9n cmVzc2lvbiBvZiB3aGF0IGlzIGFscmVhZHkNCiAgIGZpZWxkLXByb3ZlbiBhbmQgYWNjZXB0ZWQg aW4gdGhlIGluZHVzdHJ5IHRvZGF5Lg0KDQoNClEpIERvZXMgQlVMSyBjb3ZlciBhbGwgUlIgdHlw ZXM/DQpBKSBOby4gVGhlIGRyYWZ0IG9ubHkgY292ZXJzIEEsIEFBQUEsIFBUUiBhbmQgQ05BTUUg UlIgdHlwZXMuDQoNCg0KUSkgV2hhdCBoYXBwZW5zIGlmIHRoZXJlIGFyZSBvdGhlciBSUnMgd2hp Y2ggZmFsbCBpbnNpZGUNCiAgIGEgQlVMSyBwYXR0ZXJuIHJhbmdlPw0KQSkgQlVMSyByZWNvcmRz IGNhbiBvbmx5IGV4aXN0IHdoZXJlIG90aGVyIHJlY29yZHMgZG8gbm90LA0KICAgYSBjb25jZXB0 IHJlZmVycmVkIHRvIGFzICJSZWNvcmQgU3VwZXJpbXBvc2l0aW9uIiBbNS4xXQ0KDQoNClEpIENh biBCVUxLIGdlbmVyYXRlZCBSUnMgYmUgRE5TU0VDIHZhbGlkYXRlZC4NCkEpIFRoZSBkcmFmdCBv ZmZlcnMgdHdvIEROU1NFQyBzb2x1dGlvbnMsIG9uLXRoZS1mbHkNCiAgIGdlbmVyYXRlZCBzaWdu YXR1cmVzIGFuZCBhIHBhdHRlcm4gYmFzZWQgc29sdXRpb24gaW4NCiAgIHRoZSBmb3JtIG9mIGEg c3VwcG9ydCBOUE4gUlIgdHlwZSAoaW5jbHVkZWQgaW4gdGhlIGRyYWZ0KS4NCg0KDQpRKSBJcyBC VUxLIG9ubHkgZm9yIElQdjYgbmFtZXNwYWNlPw0KQSkgTm8sIEJVTEsgaXMgaW50ZW5kZWQgdG8g c2ltcGxpZnkgbWFuYWdlbWVudCBvZiBib3RoIElQdjQNCiAgIGFuZCBJUHY2ICJnZW5lcmljIiBy ZWNvcmRzLg0KDQoNClEpIFdoeSBub3QganVzdCBzY3JpcHQgdGhlc2UgcmFuZ2VzLCB1c2UgJEdF TkVSQVRFIG9yDQogICBzaW1wbHkgZm9yYmlkIHRoZSBsYXJnZXIgb25lcz8NCkEpIFR3byBmdW5k YW1lbnRhbCBnb2FscyBiZWhpbmQgQlVMSyBhcmUgdG8gYmUgYWJsZSB0bw0KICAgcHJvdmlkZSB0 aGUgc2FtZSBjYXBhYmlsaXR5IGJlaGluZCBzY3JpcHRpbmcgYW5kDQogICAkR0VORVJBVEVzIHdp dGhvdXQgdGhlIG1lbW9yeSByZXF1aXJlbWVudHMgYW5kDQogICBiZSBhYmxlIHRvIHRyYW5zZmVy IHRoZSB6b25lIG1haW50YWluZXIncyAiaW50ZW50Ii4NCiAgIEZvciBleGFtcGxlLCB3aGVuIHlv dSB0cmFuc2ZlciBSUnMgbWFuYWdlZCBieSBhIHNjcmlwdA0KICAgb3IgJEdFTkVSQVRFIHRoZSBy ZWNlaXZlciBnZXRzICJhbGwiIHJlY29yZHMgYW5kIG5vdA0KICAgdGhlIHNob3J0aGFuZCB1c2Vk IHRvIGNyZWF0ZSB0aGVtLiAgQlVMSyB0cmFuc2ZlcnMNCiAgIHRoaXMgaW50ZW50IHNvIHRoZSBj b3B5IGxvb2tzIGp1c3QgbGlrZSB0aGUgb3JpZ2luYWwuDQogICBTZXZlcmFsIEROUyBTb2Z0d2Fy ZSBWZW5kb3JzIGFyZSBhbHJlYWR5IHByb3ZpZGluZw0KICAgdGhpcyBjYXBhYmlsaXR5IGluIGEg cHJvcHJpZXRhcnkgbWFubmVyLCBCVUxLIG9mZmVycw0KICAgYW4gb3BlbiAic3RhbmRhcmQiIHdh eSB0byBleGNoYW5nZSB0aGVzZSByZWNvcmRzDQogICB3aGljaCBzY2FsZXMgdG8gZml0IGFueSBz aXplLg0KDQoNClEpIEJVTEsgc3ludGF4IGxvb2tzIGxpa2UgcmVndWxhciBleHByZXNzaW9uLCBp c24ndCB0aGF0DQogICBhIGJpdCB0b28gY29tcGxpY2F0ZWQ/DQpBKSBCVUxLIGRvZXMgb2ZmZXIg YWR2YW5jZWQgcmVndWxhci1leHByZXNzaW9uLWVzcXVlDQogICBiYWNrcmVmZXJlbmNlcyBidXQg aW4gYSBzaW1wbGlmaWVkIG1hbm5lci4gSW4gZmFjdCwNCiAgIHRoZSAic3RhciIgYmFja3JlZmVy ZW5jZSB3aWxsIHdvcmsgZmluZSBpbiBtb3N0DQogICBzY2VuYXJpb3MgKGUuZy4gIm1lbWJlci0k eyp9LmV4YW1wbGUuY29tLiIpLiBOQVBUUg0KICAgUlJzIGN1cnJlbnRseSBwcm92aWRlIGNsaWVu dC1hc3Npc3RlZCByZWd1bGFyLQ0KICAgZXhwcmVzc2lvbiBwYXR0ZXJuIHN1YnN0aXR1dGlvbiBz byBCVUxLIGxldmVyYWdlcw0KICAgYSBmYW1pbGlhciAiZmVlbCIgd2hpbGUgYWxzbyBwcm92aWRp bmcgc29tZSBvZiB0aGUNCiAgIGhlYXZ5IGxpZnRpbmcuDQoNCi0tDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXdvb2R3b3J0aC1idWxrLXJyLTA0LnR4dA0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC13b29kd29ydGgtYnVsay1yci0wNC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBKb2huIFdvb2R3b3J0aCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9z aXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC13b29kd29ydGgtYnVsay1ycg0KUmV2aXNp b246ICAgICAgIDA0DQpUaXRsZTogICAgICAgICAgQlVMSyBETlMgUmVzb3VyY2UgUmVjb3Jkcw0K RG9jdW1lbnQgZGF0ZTogIDIwMTctMDItMDcNCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAzMg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13b29kd29ydGgtYnVsay1yci0wNC50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13 b29kd29ydGgtYnVsay1yci8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtd29vZHdvcnRoLWJ1bGstcnItMDQNCkRpZmY6ICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd29vZHdvcnRoLWJ1bGstcnItMDQNCg0K QWJzdHJhY3Q6DQogICBUaGUgQlVMSyBETlMgcmVzb3VyY2UgcmVjb3JkIHR5cGUgZGVmaW5lcyBh IG1ldGhvZCBvZiBwYXR0ZXJuIGJhc2VkDQogICBjcmVhdGlvbiBvZiBETlMgcmVzb3VyY2UgcmVj b3JkcyB0byBiZSB1c2VkIGluIHBsYWNlIG9mIE5YRE9NQUlODQogICBlcnJvcnMgd2hpY2ggd291 bGQgbm9ybWFsbHkgYmUgcmV0dXJuZWQuICBUaGVzZSByZWNvcmRzIGFyZSBjdXJyZW50bHkNCiAg IHJlc3RyaWN0ZWQgdG8gcmVnaXN0ZXJlZCBETlMgcmVzb3VyY2UgcmVjb3JkIHR5cGVzIEEsIEFB QUEsIFBUUiBhbmQNCiAgIENOQU1FLiAgVGhlIGtleSBiZW5lZml0IG9mIHRoZSBCVUxLIHJlc291 cmNlIHJlY29yZCB0eXBlIGlzIHRoZQ0KICAgc2ltcGxpZmljYXRpb24gb2YgbWFpbnRhaW5pbmcg ImdlbmVyaWMiIHJlY29yZCBhc3NpZ25tZW50cyB3aGljaA0KICAgd291bGQgb3RoZXJ3aXNlIGJl IHRvbyBtYW55IHRvIG1hbmFnZSBvciByZXF1aXJlIHNjcmlwdHMgb3INCiAgIHByb3ByaWV0YXJ5 IG1ldGhvZHMgYXMgYmluZCdzICRHRU5FUkFURS4NCg0KICAgVGhpcyBkb2N1bWVudCB1cGRhdGVz IFJGQ3MgMjMwOCwgNDAzMywgNDAzNCBhbmQgNDAzNS4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCi0tIFRIRVNFIEFS RSBUSEUgRFJPSURTIFRPIFdIT00gSSBSRUZFUjoNClRoaXMgY29tbXVuaWNhdGlvbiBpcyB0aGUg cHJvcGVydHkgb2YgQ2VudHVyeUxpbmsgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkIGluZm9ybWF0aW9uLiBVbmF1dGhvcml6ZWQgdXNlIG9mIHRoaXMgY29tbXVuaWNh dGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0 ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29w aWVzIG9mIHRoZSBjb21tdW5pY2F0aW9uIGFuZCBhbnkgYXR0YWNobWVudHMuDQo= From nobody Wed Feb 8 03:26:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F491129406 for ; Wed, 8 Feb 2017 03:26:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 LkFZ2h4-07xp for ; Wed, 8 Feb 2017 03:26:31 -0800 (PST) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8261293DC for ; Wed, 8 Feb 2017 03:26:30 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:47172) by ppsw-43.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cbQOK-0002fH-oA (Exim 4.88) (return-path ); Wed, 08 Feb 2017 11:26:28 +0000 Date: Wed, 8 Feb 2017 11:26:28 +0000 From: Tony Finch To: Stephane Bortzmeyer In-Reply-To: <20170208083555.sv6t7esbewfblu3r@nic.fr> Message-ID: References: <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208083555.sv6t7esbewfblu3r@nic.fr> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 11:26:32 -0000 Stephane Bortzmeyer wrote: > Mark Andrews wrote: > > Ted Lemon wrote: > > > > > > If it has proof of non-existence for .alt cached, it doesn't need > > > to ask any further questions to deny the existence of any > > > subdomain of .alt. > > > > Which assumes agggressive negative caching. > > If by "aggressive negative caching", you mean > draft-ietf-dnsop-nsec-aggressiveuse, then I disagree with you: it is > *not* necessary (since the name is the same), you just need RFC 8020 > support. For RFC 8020 to suppress these .alt leaked queries properly, you also need qname minimization. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fisher: East 5 to 7, occasionally gale 8 at first. Moderate or rough. Snow showers. Moderate or good, occasionally very poor. From nobody Wed Feb 8 03:34:43 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000AD1295BA for ; Wed, 8 Feb 2017 03:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 y7OrQ-BYUNsN for ; Wed, 8 Feb 2017 03:34:40 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2B3129406 for ; Wed, 8 Feb 2017 03:34:40 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 92F372806BD; Wed, 8 Feb 2017 12:34:38 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 8C3112806B9; Wed, 8 Feb 2017 12:34:38 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 8A26EB38003; Wed, 8 Feb 2017 12:34:08 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 837134034A; Wed, 8 Feb 2017 12:34:08 +0100 (CET) Date: Wed, 8 Feb 2017 12:34:08 +0100 From: Stephane Bortzmeyer To: Tony Finch Message-ID: <20170208113408.vhecdlgkctnqqqdv@nic.fr> References: <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208083555.sv6t7esbewfblu3r@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: Ted Lemon , "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 11:34:42 -0000 On Wed, Feb 08, 2017 at 11:26:28AM +0000, Tony Finch wrote a message of 23 lines which said: > For RFC 8020 to suppress these .alt leaked queries properly, you > also need qname minimization. Yes, but anyone uses RFC 7816, anyway :-) From nobody Wed Feb 8 06:53:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28D8129547 for ; Wed, 8 Feb 2017 06:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kyqCw8En_rX for ; Wed, 8 Feb 2017 06:53:11 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 473221299E1 for ; Wed, 8 Feb 2017 06:53:11 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id k15so167450876qtg.3 for ; Wed, 08 Feb 2017 06:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gfomu+S/+4y6FdmslTRBESrYTIwpWJPsRu+6xbhwN3w=; b=Mq8L/gktWkNzMsFb7niRuPuJAW5NF9BQkCXJGdNAFTuUxD8URIgYaMu+UZWC9216Fx hAO7EqBZENNmf0tsL4EGRUJZNpjEXYxDMV4hdAqRGvzINWjUmK8qWiVkLV7ysL60cCC2 ljjkznZxocAifPcopRCm95VsbsBLzlQsAjKFYyL8BsZbowx8Lug/xdPMPPzyVn91z2zH GTFetpxeqxdBa9A3DtWS347W9fvbClFX9LWWSa4eiYOXIL69WYwILKTjo0q9IQp8Uv3o ZCCF4j/S14+r16QQcZ/38CP+btl7KfdLVVXhC60BNDxY5wnA+vNX4XikPSr/ZW/elo4q Z52w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gfomu+S/+4y6FdmslTRBESrYTIwpWJPsRu+6xbhwN3w=; b=Veqi5actgGymde06AXLNlyaW4sRsHAFB1KTPYqHEP5E0CZBgRFdjhh3fm9DU+lsSVQ 0gPe1axrWb6iRE6rlT99wUfgXc2AeeEhmysy1U/nyuZmE4Wxb4qqQssDduMlEVb5Hwv4 TWD0c9cjyfFlHqT4VS+zvmw2vNnZMPg6JRVZ2UDkkA1UrxBaXoeh0sY8TYIjBIU80lUn k1CnqxPbuTBh2tcAB05IYR+XRtKINsDmjhL819xWiSlcBu/2sPpEbMtCFU7nQJAE94oe JYs30VSDKJPBQdKS7wDHaQcmfignh3C4IatPUyDn6pRfNczrY3VAXiNd2XDDw924qxax Q6Lw== X-Gm-Message-State: AMke39lOfd5eX9fmY3/aisSBRQO40S7jF8Nf1LcOZoxPWLAy5q4tdInVQby1pN1pfo3pZg== X-Received: by 10.200.43.33 with SMTP id 30mr19439130qtu.107.1486565590421; Wed, 08 Feb 2017 06:53:10 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id r30sm6378309qtc.15.2017.02.08.06.53.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 06:53:09 -0800 (PST) From: Ted Lemon Message-Id: <034298A1-3DC4-4B55-B0D2-1723C034C2EB@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7135C336-2A87-4628-8D70-4D6FBD294512" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 09:53:07 -0500 In-Reply-To: <20170208084314.dqpqw3meow76wmer@nic.fr> To: Stephane Bortzmeyer References: <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> <20170208084314.dqpqw3meow76wmer@nic.fr> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop@ietf.org, Ray Bellis Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:53:12 -0000 --Apple-Mail=_7135C336-2A87-4628-8D70-4D6FBD294512 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 8, 2017, at 3:43 AM, Stephane Bortzmeyer = wrote: > Why are they different, by the way? There is more than one way to handle a special-use name. That's why = we're debating which way to handle .alt, after all! :) --Apple-Mail=_7135C336-2A87-4628-8D70-4D6FBD294512 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 8, 2017, at 3:43 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> = wrote:
Why are they different, by the = way?

There = is more than one way to handle a special-use name.   That's why = we're debating which way to handle .alt, after all!   :)

= --Apple-Mail=_7135C336-2A87-4628-8D70-4D6FBD294512-- From nobody Wed Feb 8 06:59:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54729129B6A for ; Wed, 8 Feb 2017 06:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywAqBSUoQGqE for ; Wed, 8 Feb 2017 06:59:30 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 377EC129570 for ; Wed, 8 Feb 2017 06:59:30 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id k15so167633742qtg.3 for ; Wed, 08 Feb 2017 06:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HaUNS5miawaht9K+J3VNu+16nLj0kpVGZM54sgWu7XY=; b=2CZa9umrUldCK4w33RCXusxs3TW14NIUUTOCHUqRamSZ74jUGWs95lpVd1yPHLC+pb /+vBvn7MEFt/IpQQvYjknaM6qRbqRuEK9Bv6GXHG+p4HqKyoI/S01otuX9YZcRBos9ed H3esMFg6Dhn86OF0TQW6lk8ag4RQ2nIrJxBp/IlAtiu4ZH9Lwkl+S8GN5XrtjAfEQKn+ yaZCuX9n0Lqejyhprmoakg6WFVSSzdYLIqt0Fs7FWkcTFvBWgA+qcpXi7aka4uFDClaO J5t4rSvQo1JgpUhsxca5VK5XJ7hBORqg6HKfGZ50hE1bpRXWashone7VMCdoK97mlOWs A+PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HaUNS5miawaht9K+J3VNu+16nLj0kpVGZM54sgWu7XY=; b=Ifp//AZk5SNS42uj5rUS4VKHOLSX//xxLehOv3fs8+cOAwpvz9hPOMo90aOcNeNpde vkND419yTAXJpCubcLN5cCQbVnXaamqCrKOO6mrTTGBg127fE8tHE6fA1sAmOrf+08sz Z5Pe7IwrRe9SA5OKra7jw4qEkfjWD85W3LK5tIZmy8aEcV2y+q0lmg8Q6cW7GJMvmW0K 6AkKlPaUBr82SB4BbsWrcelHmvLnrLi6hKFTMPJYOefylE/sHA7QW/kERoSSROnoBeut +ieSq9mpF5lNJAD1eEkTVjS0QuXqM6zmkciHIGIuH6yA5KexIFwE1McnS5StYgkqSgoj qMJw== X-Gm-Message-State: AMke39mC0DabaoX0tLWxeJHj3pNMW5vbYqRkns4tcwezYIiPdBqswqF2Ln3iwvwt4aMDFA== X-Received: by 10.237.42.164 with SMTP id t33mr21537975qtd.27.1486565969274; Wed, 08 Feb 2017 06:59:29 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id u5sm6381665qkd.46.2017.02.08.06.59.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 06:59:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: <20170208091536.vqwftrhpole33opl@nic.fr> Date: Wed, 8 Feb 2017 09:59:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> <20170208091536.vqwftrhpole33opl@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:59:36 -0000 I think you have read the draft as if it were about "the problems with = special-use names." This is not the intended reading. It is intended = to be read as "the set of problems that motivated RFC 6761, plus the set = of problems that would motivate an update to RFC 6761." Solutions are out of scope. It would be helpful if you could read the = document again assuming the motivation I just described, and tell me = where you think it deviates from that motivation: that is, whether you = just mis-read it, and now that I point it out, it's obvious, or whether = you think the document doesn't actually do what it sets out to do. It would be ideal if you could avoid using phrases like "the only = problem with RFC 6761." What you mean, of course, is "the only problem = I see with RFC 6761." Other people see other problems; the point of = the document is to list all of those problems, not for everybody to = agree that those problems need to be solved. > On Feb 8, 2017, at 4:15 AM, Stephane Bortzmeyer = wrote: >=20 > On Thu, Feb 02, 2017 at 06:04:05PM -0500, > Suzanne Woolf wrote=20 > a message of 82 lines which said: >=20 >> This message opens a Working Group Last Call for: >>=20 >> "Special-Use Names Problem Statement" >=20 > I've read draft-ietf-dnsop-sutld-ps-02 >=20 > I'm not convinced that there really is a "problem" with special-use > domain names and I would like to see some sort of applicability > statement saying (I send text...) "The issues listed here should not > be interpreted as indicating that special-use domain names should not > be reserved and used. While we may see one day a RFC 6761bis, in the > mean time, the process it describes should continue to be open and > available." >=20 > Biggest problem with the draft: it fails to mention the only real > technical problem with RFC 6761, the lack of a formal language for the > registry, thus preventing the programmers of resolving software to > compile automatically the code for the various cases. >=20 > I send text: after the paragraph "When a special-use Domain Name is > added to the special-use Domain Names registry, not all software that > processes such names will understand the special use of that name.", = add: >=20 > o This problem is made more difficult by the fact that there is no > formal language for the registry. The list of SUDN with their > specific requirments is not machine-readable. As a result, software > developers who write resolving code have to translate the registry > by hand into their code, a process which is painful, brittle, and > unlikely to be repeated often (thus making software obsolete with > respect to the registry). >=20 > Now, the details: >=20 >> Both ICANN and the IETF have the authority and formal processes to >> assign names from the pool of unused names, but no formal >> coordination process exists. >=20 > As I said several times, this is not true > Was this mechanism used > once for special-use domain names? What was the result? >=20 >> Organizations do in fact sometimes commandeer subsets of the >> namespace. Reasons a third party might do this include: >=20 > There are others: >=20 > * Intended use is covered by gTLD process, don't recognize ICANN's > right to block these TLD >=20 > * Intended use is covered by some IETF process, but the process is too > long, too bureaucratice and too incertain [before you jump on this > one, remember IETF never replied to requests to reserve names like > .bit or .zkey] >=20 >> the fact of its unilateral use by the TOR project without following >> the RFC 6761 process >=20 > This is ridiculous, .onion was used since 2004 > and > RFC 6761 was published in 2013. >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Wed Feb 8 07:05:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DF7129BBA for ; Wed, 8 Feb 2017 07:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YrVpd5LzJp6 for ; Wed, 8 Feb 2017 07:05:47 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 B2F60129BB7 for ; Wed, 8 Feb 2017 07:05:46 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id w20so162465785qtb.1 for ; Wed, 08 Feb 2017 07:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rrvY8ue0oTJxT3rLt0GWGTwBFASGOp0+9aBsvnmAf9Y=; b=s9W4SA+G1LuJ3E1nqM+WjPRibE/YxSjcEeLKgymYnJPvNFpwYFU2NOc1WGOyVV6YRI dgCKUuF0N0rp7LgvxdWXkuc4h77VGqIfrozXZiv+i08bTMaj2rlnMUTLM/qyiSSLwO1g b9kzKcTR48Ke68uhP7iIlRnmh4UcNyLBeoPwwRBU1nOg7jIoKFybXo7QIfQGpNOpYJa9 wX6Fj4BqmIK648xQ17mRL2c1oWuoIrwTDoQpwA66dnTrtX8rx7ODG/srk2GWtvGuyN7t 1NFt88c3Zk6NPsaG+qBq6X1MbqBAispvrQ+l0iGAQSWE0H/1kMEJbhvKAv9Cn7i+rjb5 UfYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rrvY8ue0oTJxT3rLt0GWGTwBFASGOp0+9aBsvnmAf9Y=; b=bmMuGGlLhQQwgRrxv9JUhs7UacuoczDWa8NIZW6klrgr3V4MJ3bbS+RRRpYTXjHPfX fYza2zqVDDOYwbbeDF/28vjSCR15Z4bKwPnc+8K4LcIEpRLSRjaDyqYqVAFbt+GR1BGc fXo63btY5GFSWeYhTcX6ZrVkVZ4UzhDGVgjVF6q/XYkpaHtqRncgGOzbW67xEFYLcUDB chLKQO6dl7XexSI6h41VfhjfRBJURJy80UDeR2wzlIclgUGXa9k1aIsMbmpbpDk5+r2C yNrJoREPzU50aTfL/lUBcxbPyajJHPdmr99hBl8YIGlMjG5VBBHkpM2e6qRA2qvNxarQ kMaA== X-Gm-Message-State: AMke39mLf6fuVqIi6pVsjAK9fpGA1r9ffqqFGFhrCo816aFNrdOqmUsxwg5HVAYwBUgshg== X-Received: by 10.237.59.186 with SMTP id r55mr22488849qte.25.1486566345759; Wed, 08 Feb 2017 07:05:45 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id d52sm6408270qtc.2.2017.02.08.07.05.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 07:05:44 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8130BE97-BDAE-449F-8AC3-4EA451992E2B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 10:05:42 -0500 In-Reply-To: <20170208060208.8C8E1635864D@rock.dv.isc.org> To: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:05:48 -0000 --Apple-Mail=_8130BE97-BDAE-449F-8AC3-4EA451992E2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 8, 2017, at 1:02 AM, Mark Andrews wrote: > Which assumes agggressive negative caching. I'm going to make a > realistic assumption that it will take 10+ years for there to be > meaningful (>50%) deployment of aggressive negative caching. First of all, this probably isn't true, since most of the caches we care = about are run by network operators, who tend to update more frequently = for obvious reasons. But the solution you propose, which causes a = SERVFAIL, involves a specially-prepared resolver. So if you get to = _create_ the problem with a specially-prepared resolver, I get to solve = it with a differently specially-prepared resolver. If you want queries = to .alt not to leak, you have to preload your cache with a proof of = nonexistence for .alt, and you have to keep it up to date. This is not = terribly difficult to arrange. >> Leaking a query to .alt is harmless. >=20 > Is it? What reports are we going to see over the next 20 year of > DITL data on *.alt. How is that relevant? Suppose we don't create .alt, and instead people = just pick random top-level domains for their experiments, as they do = now. Will the number of bogus queries to the root be greater, or = fewer? Furthermore, queries for .alt are legitimate, in just the same = way that queries for .com are. They just have a different answer. --Apple-Mail=_8130BE97-BDAE-449F-8AC3-4EA451992E2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 8, 2017, at 1:02 AM, Mark Andrews <marka@isc.org> = wrote:
Which assumes agggressive negative caching. =   I'm going to make a
realistic assumption that it = will take 10+ years for there to be
meaningful (>50%) deployment = of aggressive negative caching.

First of = all, this probably isn't true, since most of the caches we care about = are run by network operators, who tend to update more frequently for = obvious reasons.   But the solution you propose, which causes a = SERVFAIL, involves a specially-prepared resolver.   So if you get = to _create_ the problem with a specially-prepared resolver, I get to = solve it with a differently specially-prepared resolver.   If you = want queries to .alt not to leak, you have to preload your cache with a = proof of nonexistence for .alt, and you have to keep it up to date. =   This is not terribly difficult to arrange.

Leaking a query to .alt is = harmless.

Is it?  What reports are we = going to see over the next 20 year of
DITL data on = *.alt.

How = is that relevant?   Suppose we don't create .alt, and instead = people just pick random top-level domains for their experiments, as they = do now.   Will the number of bogus queries to the root be greater, = or fewer?   Furthermore, queries for .alt are legitimate, in just = the same way that queries for .com are.   They just have a = different answer.

= --Apple-Mail=_8130BE97-BDAE-449F-8AC3-4EA451992E2B-- From nobody Wed Feb 8 07:11:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49C8129BC6 for ; Wed, 8 Feb 2017 07:11:24 -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 Ityaipfyn-My for ; Wed, 8 Feb 2017 07:11:24 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF887129B83 for ; Wed, 8 Feb 2017 07:11:23 -0800 (PST) Received: (qmail 88364 invoked from network); 8 Feb 2017 15:11:23 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Feb 2017 15:11:23 -0000 Date: 8 Feb 2017 15:11:01 -0000 Message-ID: <20170208151101.14753.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: <20170208091536.vqwftrhpole33opl@nic.fr> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:11:25 -0000 In article <20170208091536.vqwftrhpole33opl@nic.fr> you write: >Biggest problem with the draft: it fails to mention the only real >technical problem with RFC 6761, the lack of a formal language for the >registry, thus preventing the programmers of resolving software to >compile automatically the code for the various cases. Considering the vastly different ways that software handles .local and .onion and example.com and 10.in-addr.arpa, and that next thing to come along (.homenet?) will likely be different from any of the existing ones, this strikes me as akin to asking for a pony. If you just want a list of the names so your recursive resolver can stub them out, we already have that, of course. R's, John From nobody Wed Feb 8 08:06:17 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A532F129BC8 for ; Wed, 8 Feb 2017 08:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGC_uxuXFeqB for ; Wed, 8 Feb 2017 08:06:15 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 DC833129422 for ; Wed, 8 Feb 2017 08:06:14 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id w20so164337695qtb.1 for ; Wed, 08 Feb 2017 08:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lirBHv1aNUfIXqUz40E4zMDixiixXLfcr6+BrW3Btn0=; b=qwqz9pgP9E/2IKKSbc0NEmmlh25kAHVrgq9w0p0oGy4i4cCKSZu3L0Q3YBaG+uvIho 6xg/GHYYZRvOaKwpMs+AZpq+5v0XqBq1GrNiJ2rrjMtdgaCViIRXN3r2tzN6qzH8JfX0 pC0B7RDvG1argpgEzxsa/bumKVAz23wbfJCMk8FgaYmO8JfR8uqORpW3s67r7FTMTyiY GFatWp2lMZQ5ZYPozuO3C+XjemUPOqiIzyFS/4v/HyoLpRNtlA1BdlpXggHDMOthhmge 2mINdHc+yBiTyFNb7xlLLuo4+DovAjDOpeVDxWIKVIvDWrm9CwIRvYY0DnSRf1Za6uQQ vFSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lirBHv1aNUfIXqUz40E4zMDixiixXLfcr6+BrW3Btn0=; b=ZrAVihYOwO/CMZrnYiI5CU4RMvcMVJjt0pJpgpJP6CpE9FWWiRe/vDERdT1P2RzEfb KiBC8h/9ZWi8JO1htDwwXUT38x1/f//Ov2nBVtQBg5tY2v6rClCRZCaCByoixusTWff0 KomnYUt/7WctQZcrcwd4cCNVw8AHeT8tfDO9vNl57IAzAuQ/DSadKmqyGPcysORKopy2 S0VFInZY8AS97Y4e5Q8c6PO6E0j1cQ1uJVja6oxUUa1swUzOZIG+nftvRx8DX80E1p3y JZIfW0091Er4hlhvNQ2iE7+IDJyjQvIXZZ2YHaoMug7XJoSln73SVk6yXgUkXnxbINz/ g1iA== X-Gm-Message-State: AMke39n0GuUnIbFpsO0p4OOTp/P9VDVJMjbWUu/IL/m7QmHu1Eu6a9Og27FnkFCIiU0Xww== X-Received: by 10.237.43.71 with SMTP id p65mr19444913qtd.187.1486569973870; Wed, 08 Feb 2017 08:06:13 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:4986:5f29:30fe:60bc? ([2601:181:c381:c20:4986:5f29:30fe:60bc]) by smtp.gmail.com with ESMTPSA id t35sm6488740qtc.40.2017.02.08.08.06.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Feb 2017 08:06:13 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <20170208091536.vqwftrhpole33opl@nic.fr> Date: Wed, 8 Feb 2017 11:06:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> <20170208091536.vqwftrhpole33opl@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dnsop Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 16:06:16 -0000 Hi Stephane, Thanks for the review, it=E2=80=99s helpful. I=E2=80=99ll leave it to the editors to take the first pass at = integrating your comments, but: > On Feb 8, 2017, at 4:15 AM, Stephane Bortzmeyer = wrote: >=20 > Biggest problem with the draft: it fails to mention the only real > technical problem with RFC 6761, the lack of a formal language for the > registry, thus preventing the programmers of resolving software to > compile automatically the code for the various cases. >=20 If you have a specific suggestion on how to improve the registry, please = consider posting an internet-draft.=20 The roadmap for DNSOP on special use names has for some time included = the expectation that a problem statement would precede solutions, but = that problem statement is in WGLC after extensive development, and = we=E2=80=99ve returned the alt-tld draft to active status as well.=20 We didn=E2=80=99t encourage proposed changes until we had some level of = agreement on what problem(s) we might be attempting to solve. However, = it seems we=E2=80=99ve now gotten that far. thanks, Suzanne From nobody Wed Feb 8 08:24:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991EF129C2B for ; Wed, 8 Feb 2017 08:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 1ljP4XOmMUlS for ; Wed, 8 Feb 2017 08:24:19 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12C6129C28 for ; Wed, 8 Feb 2017 08:24:18 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 0CB772806C3; Wed, 8 Feb 2017 17:24:17 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 073C82806B8; Wed, 8 Feb 2017 17:24:17 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 05110B38003; Wed, 8 Feb 2017 17:23:47 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id F304040375; Wed, 8 Feb 2017 17:23:46 +0100 (CET) Date: Wed, 8 Feb 2017 17:23:46 +0100 From: Stephane Bortzmeyer To: Ted Lemon Message-ID: <20170208162346.vnbwvmrqwmbxibjl@nic.fr> References: <4E481C14-1C2B-4A18-A4F2-582208C1DDE3@ogud.com> <6B4E9F56-1487-4E09-9245-167C4790AB3D@gmail.com> <91527611-CBAE-4DFD-8086-5D6499594108@gmail.com> <20170208084314.dqpqw3meow76wmer@nic.fr> <034298A1-3DC4-4B55-B0D2-1723C034C2EB@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <034298A1-3DC4-4B55-B0D2-1723C034C2EB@fugue.com> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: dnsop@ietf.org, Ray Bellis Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 16:24:20 -0000 On Wed, Feb 08, 2017 at 09:53:07AM -0500, Ted Lemon wrote a message of 37 lines which said: > > Why are they different, by the way? > > There is more than one way to handle a special-use name. Yes, but "serve it locally" is just one way, and it has its own registry, which is not the case with the other ways. And it is inconsistent: the semantics of ".localhost" in RFC 6761 are "serve it locally" but it is not in the registry of locally-served zones. I'm glad I don't maintain a DNS resolver, it seems messy to just get a comprehensive list of domains that a resolver has to know by default, with the rules to follow. From nobody Wed Feb 8 08:27:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807B4129C33 for ; Wed, 8 Feb 2017 08:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 uGkDbAjPFVId for ; Wed, 8 Feb 2017 08:27:49 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E820129BED for ; Wed, 8 Feb 2017 08:27:49 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2147F2806C3; Wed, 8 Feb 2017 17:27:48 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 1C3F42806B8; Wed, 8 Feb 2017 17:27:48 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 1A581B3800C; Wed, 8 Feb 2017 17:27:18 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 14D2840375; Wed, 8 Feb 2017 17:27:18 +0100 (CET) Date: Wed, 8 Feb 2017 17:27:18 +0100 From: Stephane Bortzmeyer To: John Levine Message-ID: <20170208162718.jxaesl23jc6frykl@nic.fr> References: <20170208091536.vqwftrhpole33opl@nic.fr> <20170208151101.14753.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170208151101.14753.qmail@ary.lan> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20161126 (1.7.1) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 16:27:50 -0000 On Wed, Feb 08, 2017 at 03:11:01PM -0000, John Levine wrote a message of 16 lines which said: > Considering the vastly different ways that software handles .local > and .onion and example.com and 10.in-addr.arpa, and that next thing > to come along (.homenet?) will likely be different from any of the > existing ones, this strikes me as akin to asking for a pony. Some people in the discussion wanted ICANN to do something. This is akin to asking for an unicorn (at least, ponies do exist). > If you just want a list of the names so your recursive resolver can > stub them out, we already have that, of course. URL, please, with the expected behavior of the resolver when queried for the domain. From nobody Wed Feb 8 08:40:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD10129C4C for ; Wed, 8 Feb 2017 08:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ozEAYRsG; dkim=pass (1536-bit key) header.d=taugh.com header.b=JBihkntf 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 AtCFJYa5YLvK for ; Wed, 8 Feb 2017 08:40:18 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32404129C33 for ; Wed, 8 Feb 2017 08:40:18 -0800 (PST) Received: (qmail 1293 invoked from network); 8 Feb 2017 16:40:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=50b.589b49f0.k1702; bh=a2lhFd58VZ024czf0W+bioM/42KUJ7O5IKraaEqG7DA=; b=ozEAYRsGzxMSyDgRS6LeAiOZ279JFKZVRhswV7CJJREn3ub/w5itbJhp8zJwY1d+ZwCE1WBHpC2ABG/wkZZO70ZrVYa6ZyInTVionbYpG+Ip0MDoJSPMCS270QCzLUXv4uplYeu7j+eP/CY3u2KbzZDE+rM4ehsEiErGnofSlbfwKirh5Nig5t5L6eMnTsxJS4Z+vE7N6XQnVggVeJcbKeYSYuPHYtfS4ya+Ksw69G8IZiUwudzCjBNtTP8J8p67 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=50b.589b49f0.k1702; bh=a2lhFd58VZ024czf0W+bioM/42KUJ7O5IKraaEqG7DA=; b=JBihkntf4FhlxPp02Z2W7VyySLun13hU9Q+btknpkt76vJmAnKsMMzqAHJy48g33LzlbT9CQR2vLMho2rdfE1X3WOc6wlrswXKTuqsNC/j9sv/WQxc2rNPwQk1oX1MQHlMhfryasVHJxUu6mojZ1+SnujmbvFsIlnFFT8xb3Z8DnCIIbskTVS5m+OUGCG2fDaD8Nhp6HHu7x4Ey4l+ETRzPpnV+at8KOG/4Yp2EbrrXFwKTfCxZkN8Gpt309M7YL Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 08 Feb 2017 16:40:16 -0000 Date: 8 Feb 2017 11:40:16 -0500 Message-ID: From: "John R Levine" To: "Stephane Bortzmeyer" In-Reply-To: <20170208162718.jxaesl23jc6frykl@nic.fr> References: <20170208091536.vqwftrhpole33opl@nic.fr> <20170208151101.14753.qmail@ary.lan> <20170208162718.jxaesl23jc6frykl@nic.fr> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 16:40:19 -0000 >> to come along (.homenet?) will likely be different from any of the >> existing ones, this strikes me as akin to asking for a pony. > > Some people in the discussion wanted ICANN to do something. This is > akin to asking for an unicorn (at least, ponies do exist). I wouldn't disagree. >> If you just want a list of the names so your recursive resolver can >> stub them out, we already have that, of course. > > URL, please, with the expected behavior of the resolver when queried > for the domain. It's the IANA list of special use domains: http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml also available as CSV for the traditionally inclined. As I said, you might want to have your resolver stub these out to prevent leakage if it doesn't know how to handle them. I use unbound, where it's easy to turn them into "local-zone always_nxdomain" which won't make applications very happy, but at least they won't leak. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Feb 8 11:42:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0B5129FD3 for ; Wed, 8 Feb 2017 11:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 aoUKj6oheTe9 for ; Wed, 8 Feb 2017 11:42:22 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0CBA1295A5 for ; Wed, 8 Feb 2017 11:42:22 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 19F3D34930F; Wed, 8 Feb 2017 19:42:15 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 05BED160041; Wed, 8 Feb 2017 19:42:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E7DBD160054; Wed, 8 Feb 2017 19:42:14 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7xJfd6o7qvps; Wed, 8 Feb 2017 19:42:14 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 036EB160041; Wed, 8 Feb 2017 19:42:14 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DB02C635DD72; Thu, 9 Feb 2017 06:42:08 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> In-reply-to: Your message of "Wed, 08 Feb 2017 10:05:42 -0500." Date: Thu, 09 Feb 2017 06:42:08 +1100 Message-Id: <20170208194208.DB02C635DD72@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:42:23 -0000 In message , Ted Lemon writes: > > On Feb 8, 2017, at 1:02 AM, Mark Andrews wrote: > > Which assumes agggressive negative caching. I'm going to make a > > realistic assumption that it will take 10+ years for there to be > > meaningful (>50%) deployment of aggressive negative caching. > > First of all, this probably isn't true, since most of the caches we care > about are run by network operators, who tend to update more frequently > for obvious reasons. But the solution you propose, which causes a > SERVFAIL, involves a specially-prepared resolver. So if you get to > _create_ the problem with a specially-prepared resolver, I get to solve > it with a differently specially-prepared resolver. If you want queries > to .alt not to leak, you have to preload your cache with a proof of > nonexistence for .alt, and you have to keep it up to date. This is not > terribly difficult to arrange. > > >> Leaking a query to .alt is harmless. > > > > Is it? What reports are we going to see over the next 20 year of > > DITL data on *.alt. > > How is that relevant? Suppose we don't create .alt, and instead people > just pick random top-level domains for their experiments, as they do now. > Will the number of bogus queries to the root be greater, or fewer? > Furthermore, queries for .alt are legitimate, in just the same way that > queries for .com are. They just have a different answer. Me, I'm trying to prevent the SERVFAIL issues the IETF has created for .onion. In particular this from RFC7686 4. Caching DNS Servers: Caching servers, where not explicitly adapted to interoperate with Tor, SHOULD NOT attempt to look up records for .onion names. They MUST generate NXDOMAIN for all such queries. Without .onion being a insecurely delegation this results in SERVFAIL or BOGUS being returned for .onion named when validation is performed by any validating software that is not RFC7686 aware. Nameserver vendors have a choice. Follow RFC7686 and have their clients get a answer that they know cannot be validated or ignore this clause and pretend that RFC7686 has never been written so that their client get a validatable answer. Should the IETF have put Nameserver vendors in this position? At this stage we have not yet implemented this clause in BIND. We are aware of RFC7686 and at some point someone will complain that we don't implement this. At that point we will point out to them that this results in SERVFAIL or bogus being returned. Note all through the debate about .onion I raise this issue. Go look at the archives. Now draft-ietf-dnsop-alt-tld-07 has almost identical wording 4. Caching DNS servers SHOULD recognize these names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve these names. Instead, caching DNS servers SHOULD generate immediate negative responses for all such queries. This clause results in BOGUS or SERVFAIL being returned to the DNS application if there is a validator in the return DNS path between the caching DNS server and the application. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 8 11:49:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328F112A009 for ; Wed, 8 Feb 2017 11:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7jnqGfUqJQY for ; Wed, 8 Feb 2017 11:49:37 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 834CA129FD4 for ; Wed, 8 Feb 2017 11:49:37 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id k15so176335156qtg.3 for ; Wed, 08 Feb 2017 11:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9U7RBiA2Ot8CIzbm5WNEDUzW8tediwFoch5yMs8PME8=; b=ZYmxHotlcMjCzOEh2jR6h3RgUBBwKyJ3/0eY+179Ox4hMh0n0SEqgknQYSZIhtpskE GHsiRjJktTP1xc1vblUHIaHwpU52RdQad9m5HTS78IfjITRuHoMyR9iq6zWa+5CET7yS eTx7NiSxxziDAiwpmnLKMvOxexYQvdvd/aX+M/hrgkCI19xKk6VFqim2RhAlotiJQNO/ K3xEgq8jRRyFr2OgF3GFi4z6fsdosAHghMJxPArkAkUnGmN2EzwFRub+yH79lN2iZ8IH Kc6Y4E6SOYqnLYZRy91nfxXF+eGzSUP1ITnaViBwQs+jm47SvHeOOOXeHQNY1FjaLyBd lm4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9U7RBiA2Ot8CIzbm5WNEDUzW8tediwFoch5yMs8PME8=; b=N4Nzu6BrJMK3kOFb2GKYiVnz7yDDabI1DRUxtnUZkODURX9pKD4CjzwDPuTfLKX07O I3OJ7HDj9GhUwjwRGApWqmEKQIz09jlVIceCsvhAju7d2jYDOIl0T68H7YMFZgOwVvKJ 0f4gULbQ7mQT7m+uQlQmE1QB0WFwwkX4bstAYNdf46ni/ApahZaASCzj+2oz5dwSALRY vMr2gzu717WUT2F0xpc592NCgAzfRUc4XLJRJssF86FgQdwm7L6Y767gn7I21+mmsP09 4pG27dlIDo/GQY9FRXnrzxLK7odOeT68oVVE6bGbb9Xo85BEmqmANvxyPwyvv4yY9tWZ vKJw== X-Gm-Message-State: AMke39lYOGF7gZyQbOmL6mavYz8ZzRx9i01sjX3EmyXIDQHQS/UflvQS6dY5qiMGf3yp0Q== X-Received: by 10.200.48.110 with SMTP id g43mr20982051qte.277.1486583376577; Wed, 08 Feb 2017 11:49:36 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 7sm7026580qkx.49.2017.02.08.11.49.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 11:49:35 -0800 (PST) From: Ted Lemon Message-Id: <00767076-FA43-42C0-A4AF-39F4E1087F11@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E33CAC61-03F4-4B2E-9B7E-5D9E011D1D5B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 14:49:34 -0500 In-Reply-To: <20170208194208.DB02C635DD72@rock.dv.isc.org> To: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:49:39 -0000 --Apple-Mail=_E33CAC61-03F4-4B2E-9B7E-5D9E011D1D5B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Feb 8, 2017, at 2:42 PM, Mark Andrews wrote: > 4. Caching DNS servers SHOULD recognize these names as special and > SHOULD NOT, by default, attempt to look up NS records for them, > or otherwise query authoritative DNS servers in an attempt to > resolve these names. Instead, caching DNS servers SHOULD > generate immediate negative responses for all such queries. > > This clause results in BOGUS or SERVFAIL being returned to the DNS > application if there is a validator in the return DNS path between > the caching DNS server and the application. So, that is the thing to fix. --Apple-Mail=_E33CAC61-03F4-4B2E-9B7E-5D9E011D1D5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 8, 2017, at 2:42 PM, Mark Andrews <marka@isc.org> = wrote:
  4.  Caching DNS servers SHOULD = recognize these names as special and
      SHOULD NOT, by default, = attempt to look up NS records for them,
      or otherwise query = authoritative DNS servers in an attempt to
      resolve these names. =  Instead, caching DNS servers SHOULD
      generate immediate = negative responses for all such queries.

This clause results in BOGUS or SERVFAIL being = returned to the DNS
application if there is a validator in = the return DNS path between
the caching DNS server and the = application.

So, that is the thing to fix.

= --Apple-Mail=_E33CAC61-03F4-4B2E-9B7E-5D9E011D1D5B-- From nobody Wed Feb 8 12:30:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFF5129E25 for ; Wed, 8 Feb 2017 12:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 3muqs_6kEKSg for ; Wed, 8 Feb 2017 12:30:25 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB0C1294BC for ; Wed, 8 Feb 2017 12:30:25 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 46861349528; Wed, 8 Feb 2017 20:30:23 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2A68D160041; Wed, 8 Feb 2017 20:30:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 140AC160054; Wed, 8 Feb 2017 20:30:23 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id O8HX_MTldyvs; Wed, 8 Feb 2017 20:30:23 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 82ACE160041; Wed, 8 Feb 2017 20:30:22 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id CF0B5635DFA1; Thu, 9 Feb 2017 07:30:18 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <00767076-FA43-42C0-A4AF-39F4E1087F11@fugue.com> In-reply-to: Your message of "Wed, 08 Feb 2017 14:49:34 -0500." <00767076-FA43-42C0-A4AF-39F4E1087F11@fugue.com> Date: Thu, 09 Feb 2017 07:30:18 +1100 Message-Id: <20170208203018.CF0B5635DFA1@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 20:30:27 -0000 In message <00767076-FA43-42C0-A4AF-39F4E1087F11@fugue.com>, Ted Lemon writes: > charset=us-ascii > > On Feb 8, 2017, at 2:42 PM, Mark Andrews wrote: > > 4. Caching DNS servers SHOULD recognize these names as special and > > SHOULD NOT, by default, attempt to look up NS records for them, > > or otherwise query authoritative DNS servers in an attempt to > > resolve these names. Instead, caching DNS servers SHOULD > > generate immediate negative responses for all such queries. > > > > This clause results in BOGUS or SERVFAIL being returned to the DNS > > application if there is a validator in the return DNS path between > > the caching DNS server and the application. > > So, that is the thing to fix. And if the service has the same privacy issues as .onion has? So we leak names until every recursive server in the world is validating (what % is that today?) and supports agressive negative caching (still a I-D). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 8 12:36:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B71912941A for ; Wed, 8 Feb 2017 12:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPBnZ_bWurDP for ; Wed, 8 Feb 2017 12:36:25 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 027DF1289C4 for ; Wed, 8 Feb 2017 12:36:25 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id v96so209816ioi.0 for ; Wed, 08 Feb 2017 12:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1Gtm1SpMjToXW9ZgWPwoQGV5IoMnnufx3HrVsIWkZEc=; b=s0KUqZQilCv8Yf3CnsUz7hyyVablbWaY0bc0jpBXjk3m39d+cxq0odNJHauJCCK3XA pckN0XtRNL9ghFgZQcpzEQ6bFOE/43c51GS+wDmIu5m7qTuooWEAGgyojKcWDUBDr78x OpdpbxD2susiy0dy76O/UVa/MWF4QEBMwlZ6XiVLPYDFLKbfNsKn2knys1QJuPe2uaNk lN7IVvQ9UIR25nQTMM37wyit6gTTAnpEij05ZQ0cxvCqjuDP6UsUF2AS6yprOjcWd8Ha cWLrIfWOXXre1ns0fj6QTlZCrhGfjSYlnpGVBkcP2GBhXral7WxD5rl1CI40HEIJ4QVu y9lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1Gtm1SpMjToXW9ZgWPwoQGV5IoMnnufx3HrVsIWkZEc=; b=rZDEomZSWLf30BMRQerj4ivz7zybqOpuzsHP+lfgkKQWyg9mPPbrktWW9wrDer5Vgf XSQqKGftqNyyo0KLfaHOyinKSszyVxdOVMWWlAe81HtyMTh4fUUltimjXbN5d6BTnZ0K C59Pj3pRRWiToyS9+z9IrGGHLBoy37GoNJgn2l2RKa+rnyCTyUyGpYUNqrM9BMD+Z1/4 gvUJvUhlotIGfiYG1dy9KZRDg3xFhqOR8MCAZGhA7Wo+scNz3Nu8i1gQNpubW4+URvbM zAwZfjW1XOsHN/3TaeVmDnjh38wEXZ8t07RkZEn0QLhV67iWdFUrgdQ7eE2Lph1Q3l4Q Pg+Q== X-Gm-Message-State: AMke39mE0dSd6D+FX6kQ3Zre+Xaf2cbQoDl71CuMt1nhxY6WQPoWXTEcekDsX3bcH1YZchWL0ITJbLl7QWo4Aw== X-Received: by 10.107.16.14 with SMTP id y14mr7236ioi.164.1486586184229; Wed, 08 Feb 2017 12:36:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Wed, 8 Feb 2017 12:36:23 -0800 (PST) In-Reply-To: <20170208194208.DB02C635DD72@rock.dv.isc.org> References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> From: Brian Dickson Date: Wed, 8 Feb 2017 12:36:23 -0800 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a113fece27069d105480ad1ac Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 20:36:26 -0000 --001a113fece27069d105480ad1ac Content-Type: text/plain; charset=UTF-8 On Wed, Feb 8, 2017 at 11:42 AM, Mark Andrews wrote: > > In message , Ted Lemon > writes: > > > > On Feb 8, 2017, at 1:02 AM, Mark Andrews wrote: > > > Which assumes agggressive negative caching. I'm going to make a > > > realistic assumption that it will take 10+ years for there to be > > > meaningful (>50%) deployment of aggressive negative caching. > > > > First of all, this probably isn't true, since most of the caches we care > > about are run by network operators, who tend to update more frequently > > for obvious reasons. But the solution you propose, which causes a > > SERVFAIL, involves a specially-prepared resolver. So if you get to > > _create_ the problem with a specially-prepared resolver, I get to solve > > it with a differently specially-prepared resolver. If you want queries > > to .alt not to leak, you have to preload your cache with a proof of > > nonexistence for .alt, and you have to keep it up to date. This is not > > terribly difficult to arrange. > > > > >> Leaking a query to .alt is harmless. > > > > > > Is it? What reports are we going to see over the next 20 year of > > > DITL data on *.alt. > > > > How is that relevant? Suppose we don't create .alt, and instead people > > just pick random top-level domains for their experiments, as they do now. > > Will the number of bogus queries to the root be greater, or fewer? > > Furthermore, queries for .alt are legitimate, in just the same way that > > queries for .com are. They just have a different answer. > > Me, I'm trying to prevent the SERVFAIL issues the IETF has created for > .onion. In particular this from RFC7686 > > 4. Caching DNS Servers: Caching servers, where not explicitly > adapted to interoperate with Tor, SHOULD NOT attempt to look up > records for .onion names. They MUST generate NXDOMAIN for all > such queries. > > Without .onion being a insecurely delegation this results in SERVFAIL > or BOGUS being returned for .onion named when validation is performed > by any validating software that is not RFC7686 aware. > > So, while technically the instruction (SHOULD NOT) applies to full .onion names, it is a SHOULD NOT, not a MUST NOT. Again, technically, the bit of code to do the following, IMHO, nears the level of "trivial": - upon startup, do a query for "onion" (the non-existent TLD), with DO=1. - cache the response, and as appropriate, re-query periodically. - If a query for .onion is received, reply with the authenticated denial of existence from the root (cached in step 2) I believe this should prevent any SERVFAIL or BOGUS. (I think this turns on the pedantic reading of "generate".) > Nameserver vendors have a choice. Follow RFC7686 and have their > clients get a answer that they know cannot be validated or ignore > this clause and pretend that RFC7686 has never been written so that > their client get a validatable answer. Should the IETF have put > Nameserver vendors in this position? > > At this stage we have not yet implemented this clause in BIND. We > are aware of RFC7686 and at some point someone will complain that > we don't implement this. At that point we will point out to them > that this results in SERVFAIL or bogus being returned. > > Note all through the debate about .onion I raise this issue. Go > look at the archives. > > Now draft-ietf-dnsop-alt-tld-07 has almost identical wording > > 4. Caching DNS servers SHOULD recognize these names as special and > SHOULD NOT, by default, attempt to look up NS records for them, > or otherwise query authoritative DNS servers in an attempt to > resolve these names. Instead, caching DNS servers SHOULD > generate immediate negative responses for all such queries. > > This clause results in BOGUS or SERVFAIL being returned to the DNS > application if there is a validator in the return DNS path between > the caching DNS server and the application. > See above; maybe the text of alt-tld should be less prescriptive, and instead use aggressive-negative compatible language (including use of legitimate, signed denial of existence RRsets). Brian > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --001a113fece27069d105480ad1ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 8, 2017 at 11:42 AM, Mark Andrews <marka@isc.org> wrote:

In message <E0A42577-0984-4ADD-8658-91413CBE783D@fugue.com>, Ted Lemo= n writes:
>
> On Feb 8, 2017, at 1:02 AM, Mark Andrews <marka@isc.org> wrote:
> > Which assumes agggressive negative caching.=C2=A0 =C2=A0I'm g= oing to make a
> > realistic assumption that it will take 10+ years for there to be<= br> > > meaningful (>50%) deployment of aggressive negative caching. >
> First of all, this probably isn't true, since most of the caches w= e care
> about are run by network operators, who tend to update more frequently=
> for obvious reasons.=C2=A0 =C2=A0But the solution you propose, which c= auses a
> SERVFAIL, involves a specially-prepared resolver.=C2=A0 =C2=A0So if yo= u get to
> _create_ the problem with a specially-prepared resolver, I get to solv= e
> it with a differently specially-prepared resolver.=C2=A0 =C2=A0If you = want queries
> to .alt not to leak, you have to preload your cache with a proof of > nonexistence for .alt, and you have to keep it up to date.=C2=A0 =C2= =A0This is not
> terribly difficult to arrange.
>
> >> Leaking a query to .alt is harmless.
> >
> > Is it?=C2=A0 What reports are we going to see over the next 20 ye= ar of
> > DITL data on *.alt.
>
> How is that relevant?=C2=A0 =C2=A0Suppose we don't create .alt, an= d instead people
> just pick random top-level domains for their experiments, as they do n= ow.
>=C2=A0 =C2=A0Will the number of bogus queries to the root be greater, o= r fewer?
> Furthermore, queries for .alt are legitimate, in just the same way tha= t
> queries for .com are.=C2=A0 =C2=A0They just have a different answer.
Me, I'm trying to prevent the SERVFAIL issues the IETF has = created for
.onion.=C2=A0 In particular this from RFC7686

=C2=A0 =C2=A04.=C2=A0 Caching DNS Servers: Caching servers, where not expli= citly
=C2=A0 =C2=A0 =C2=A0 =C2=A0adapted to interoperate with Tor, SHOULD NOT att= empt to look up
=C2=A0 =C2=A0 =C2=A0 =C2=A0records for .onion names.=C2=A0 They MUST genera= te NXDOMAIN for all
=C2=A0 =C2=A0 =C2=A0 =C2=A0such queries.

Without .onion being a insecurely delegation this results in SERVFAIL
or BOGUS being returned for .onion named when validation is performed
by any validating software that is not RFC7686 aware.


So, while technically the instruction = (SHOULD NOT) applies to full .onion names,
it is a SHOULD NOT, no= t a MUST NOT.

Again, technically, the bit of code = to do the following, IMHO, nears the level of "trivial":
- upon startup, do a query for "onion" (the non-existent TLD), = with DO=3D1.
- cache the response, and as appropriate, re-query p= eriodically.
- If a query for <anything>.onion is received,= reply with the authenticated denial of existence from the root (cached in = step 2)

I believe this should prevent any SERVFAIL= or BOGUS.

(I think this turns on the pedantic rea= ding of "generate".)

=C2=A0
Nameserver vendors have a choice.=C2=A0 Follow RFC7686 and have their
clients get a answer that they know cannot be validated or ignore
this clause and pretend that RFC7686 has never been written so that
their client get a validatable answer.=C2=A0 Should the IETF have put
Nameserver vendors in this position?

At this stage we have not yet implemented this clause in BIND.=C2=A0 We
are aware of RFC7686 and at some point someone will complain that
we don't implement this.=C2=A0 At that point we will point out to them<= br> that this results in SERVFAIL or bogus being returned.

Note all through the debate about .onion I raise this issue.=C2=A0 Go
look at the archives.

Now draft-ietf-dnsop-alt-tld-07 has almost identical wording

=C2=A0 =C2=A04.=C2=A0 Caching DNS servers SHOULD recognize these names as s= pecial and
=C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD NOT, by default, attempt to look up NS re= cords for them,
=C2=A0 =C2=A0 =C2=A0 =C2=A0or otherwise query authoritative DNS servers in = an attempt to
=C2=A0 =C2=A0 =C2=A0 =C2=A0resolve these names.=C2=A0 Instead, caching DNS = servers SHOULD
=C2=A0 =C2=A0 =C2=A0 =C2=A0generate immediate negative responses for all su= ch queries.

This clause results in BOGUS or SERVFAIL being returned to the DNS
application if there is a validator in the return DNS path between
the caching DNS server and the application.

=
See above; maybe the text of alt-tld should be less prescriptive, and = instead use aggressive-negative compatible language (including use of legit= imate, signed denial of existence RRsets).

Brian

=C2=A0

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0INTERNET: marka@isc.org

--001a113fece27069d105480ad1ac-- From nobody Wed Feb 8 13:13:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C11129478 for ; Wed, 8 Feb 2017 13:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obZnzIrJuJt5 for ; Wed, 8 Feb 2017 13:13:01 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2B2129472 for ; Wed, 8 Feb 2017 13:13:01 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id x49so177967544qtc.2 for ; Wed, 08 Feb 2017 13:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hCK5QLgCtADLimbjJLmCgYdd318tDtAWRr2KFHP5TA0=; b=cmvWs1Qd/9L0MMwtu9bYf6jwiOjWAFM1ifJlJOPJNzaoGjbsICxbgxLViOQ2+qnYWI mYvGfJFJJPQ3reVauxpgZoMX3d1ydwuG2wtR7+OvN8RShFZax+RSWEBJe8zLE5ufffp8 OV58HuUQfQ8vYGj3S0yZNvmNg4jpKqLRsoUzZAAT98mUwqv/Hzqfj/p4/b3Pg0tIzhGV 1onabmNtY3fSp0TlSL7lMvx1I9+zvftGVU5xOBajvQUdkFxg2QhW+ss0zPNotolUo7di bAmx+oqzHZlmbhsfTQQE6OaLcNYTxYhOMtY62oq7ZXQ7DrzlC/dLDoX9ptAS6xEvQ+wC kWmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hCK5QLgCtADLimbjJLmCgYdd318tDtAWRr2KFHP5TA0=; b=Xw0aheStsus0vBcnCEaV1jOYnJF6HB2+pFkJ7XAzo6/PajsQ2xBCY79d6Zl4R1PfON XR7Qifi1FdO3YuNMl1vy8HsVyMRPCU5XiwYUgwmcQPraBuSE9Z/eJDLW6mDtiiDPeNGJ S6p4/OjZ9L1MkPAnBWl/PMxgOAHV/dSv3B6AMGfnc+Np8zbqxU18soMdUXyckEamGXpP 6+ZkkQyRQjCcT0aMXGHUMwiAKsvwmq/SZfPLCeBwyOc8xrhKvwL2KL9WhRAj8Ear0iP6 dLnPG2kAD30tS2R/3hyu23xCBBQ8XHxi3E0Anro3Ckh9n7KxUcycB66/pp3jeXgE17qR QFcg== X-Gm-Message-State: AMke39mXLaVfk9YFGYOCl3YPGWSRP7Q+IAE6ibZHUgziaqqlwBVn4q3jmbZgFOYRFyt97Q== X-Received: by 10.237.55.65 with SMTP id i59mr23549552qtb.261.1486588380335; Wed, 08 Feb 2017 13:13:00 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id u5sm7208304qkd.46.2017.02.08.13.12.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 13:12:59 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0242884B-41F6-4261-AB31-4EE545B5ED65" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 16:12:57 -0500 In-Reply-To: <20170208203018.CF0B5635DFA1@rock.dv.isc.org> To: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <00767076-FA43-42C0-A4AF-39F4E1087F11@fugue.com> <20170208203018.CF0B5635DFA1@rock.dv.isc.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:13:03 -0000 --Apple-Mail=_0242884B-41F6-4261-AB31-4EE545B5ED65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote: > And if the service has the same privacy issues as .onion has? >=20 > So we leak names until every recursive server in the world is > validating (what % is that today?) and supports agressive negative > caching (still a I-D). I feel like I am arguing with a wall, so if this doesn't work I will = just give up. But if it's okay for us to ask resolvers to make a = chance, it is okay for us to ask resolvers to make the right change. = And if they don't, yes, it's possible that some queries will leak. = There is nothing we can do to prevent that other than harden caching = servers and stub resolvers; if we are going to do that, we might as well = do it right, by caching the full proof of nonexistence, rather lying = about what's in the root zone. --Apple-Mail=_0242884B-41F6-4261-AB31-4EE545B5ED65 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 8, 2017, at 3:30 PM, Mark Andrews <marka@isc.org> = wrote:
And if the service has the same privacy issues = as .onion has?

So we leak names until every recursive server in = the world is
validating (what % is that today?) and supports = agressive negative
caching (still a = I-D).

I = feel like I am arguing with a wall, so if this doesn't work I will just = give up.   But if it's okay for us to ask resolvers to make a = chance, it is okay for us to ask resolvers to make the right change. =   And if they don't, yes, it's possible that some queries will = leak.   There is nothing we can do to prevent that other than = harden caching servers and stub resolvers; if we are going to do that, = we might as well do it right, by caching the full proof of nonexistence, = rather lying about what's in the root zone.

= --Apple-Mail=_0242884B-41F6-4261-AB31-4EE545B5ED65-- From nobody Wed Feb 8 13:32:13 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031C51295D2 for ; Wed, 8 Feb 2017 13:32:13 -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] 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 SoNN2D-2BIcF for ; Wed, 8 Feb 2017 13:32:11 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75C2B1295E8 for ; Wed, 8 Feb 2017 13:32:11 -0800 (PST) Received: from [10.32.60.56] ([75.104.68.192]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v18LUjuZ076906 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 8 Feb 2017 14:30:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host [75.104.68.192] claimed to be [10.32.60.56] From: "Paul Hoffman" To: dnsop@ietf.org Date: Wed, 08 Feb 2017 16:31:56 -0500 Message-ID: <390DDFE7-E70F-4E4E-96AB-AECFE25672E0@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Subject: [DNSOP] A nudge on the new terms in draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:32:13 -0000 [[ Hopefully the WG can focus on multiple topics at once; this one has an effect on the upcoming interim WG meeting. ]] [[ We got a few responses to our earlier message about the new terms in draft-ietf-dnsop-terminology-bis-04, but would certainly like to hear more. From our earlier message: ]] The authors have tentatively made some substantial changes to the draft, to define "domain name", "global DNS", and "private DNS" in a manner that can be used by other work in the IETF, particularly around RFC 6761. Our first cut of definitions are in the new draft, but we fully expect significant discussion in the WG before there is even rough consensus. We are not even sure that the WG will agree with the idea of adding "global DNS" and "private DNS" to the document. The authors are not even sure they agree with all of this. At the same time, we think that it would be easier to track open issues in our GitHub repo at https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis rather than in the document as comments. To be clear, the discussion of how issues are to be resolved should be mostly done on the mailing list, but using GitHub to track issues might give easier-to-follow history of the discussions. We also are open to using GitHub for pull requests for specific changes to the document. As a final note, this version of the draft also has some changes not related to the above, and we encourage review of those changes, plus anything else in the draft, of course. --Paul Hoffman On 27 Jan 2017, at 10:08, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the > IETF. > > Title : DNS Terminology > Authors : Paul Hoffman > Andrew Sullivan > Kazunori Fujiwara > Filename : draft-ietf-dnsop-terminology-bis-04.txt > Pages : 34 > Date : 2017-01-27 > > Abstract: > The DNS is defined in literally dozens of different RFCs. The > terminology used by implementers and developers of DNS protocols, > and > by operators of DNS systems, has sometimes changed in the decades > since the DNS was first defined. This document gives current > definitions for many of the terms used in the DNS in a single > document. > > This document will be the successor to RFC 7719. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-04 From nobody Wed Feb 8 14:41:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3F71294A4 for ; Wed, 8 Feb 2017 14:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 Z0WFKgt1nX2V for ; Wed, 8 Feb 2017 14:41:39 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6608B129DB7 for ; Wed, 8 Feb 2017 14:41:39 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id CED913494F5; Wed, 8 Feb 2017 22:41:36 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B9358160077; Wed, 8 Feb 2017 22:41:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A8A5A160076; Wed, 8 Feb 2017 22:41:36 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mIWqvq51wRGN; Wed, 8 Feb 2017 22:41:36 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 22D32160054; Wed, 8 Feb 2017 22:41:36 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 256CC635E87D; Thu, 9 Feb 2017 09:41:31 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <00767076-FA43-42C0-A4AF-39F4E1087F11@fugue.com> <20170208203018.CF0B5635DFA1@rock.dv.isc.org> In-reply-to: Your message of "Wed, 08 Feb 2017 16:12:57 -0500." Date: Thu, 09 Feb 2017 09:41:31 +1100 Message-Id: <20170208224131.256CC635E87D@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 22:41:44 -0000 In message , Ted Lemon writes: > > On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote: > > And if the service has the same privacy issues as .onion has? > > > > So we leak names until every recursive server in the world is > > validating (what % is that today?) and supports agressive negative > > caching (still a I-D). > > I feel like I am arguing with a wall, so if this doesn't work I will just > give up. But if it's okay for us to ask resolvers to make a chance, it > is okay for us to ask resolvers to make the right change. And if they > don't, yes, it's possible that some queries will leak. There is nothing > we can do to prevent that other than harden caching servers and stub > resolvers; if we are going to do that, we might as well do it right, by > caching the full proof of nonexistence, rather lying about what's in the > root zone. Actually we can do something that doesn't require that validation be enabled. We don't have to create that linkage. It's not like the names are not supposed to exist. They do/will exist and not as in they are/will be squatted upon. Oh sorry, you can't have privacy unless you validate. And only because people are too scared to ask for changes to the root zone to add a delegation. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 8 15:05:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D931E12941D for ; Wed, 8 Feb 2017 15:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mr7kWfWp2Dd2 for ; Wed, 8 Feb 2017 15:05:51 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 5306712A0A5 for ; Wed, 8 Feb 2017 15:05:51 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id j18so3409544ioe.2 for ; Wed, 08 Feb 2017 15:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8mJNbQGtKJqlZyycQCuII7hYO1rf1f8cEmWn/INitjY=; b=o4IS215+wejOSmwFy5MGz+qC14Oi4LUg1OZC9XKF79569Rkz6Ag2F/bRuUm7co1BsX QshtvSYQnYCBbQ8RrNE85AYO9Yc77iSk1mnmMe4FJBXCmuKkSN8S7KIuYYtQW3Fj2mAR kt0de7jEXHkrXldsFQdF23uV/0vgE00I5yP7q4SVbFIDuvPw4mKTGv1P+sewABDKCa12 CM2as/hD8ITf8OzaiDXQ3goR2l29n5BMPLiV6yqcsJFARpLnr6Ya05SZAkfL/GymhYWm O628ORob7rrqk+5qxrv553LO6zdqGBTz+NnxDo2d3etIdLFyz+Ebk9F296oY4v/GEibq 3GQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8mJNbQGtKJqlZyycQCuII7hYO1rf1f8cEmWn/INitjY=; b=SlNIeVvU0W7w60fU6B6xTsXJ4R6H29llmOhGVYLxNBPa1BW5yWTSWNWOfE5CZ/+EIK sCmxUcwP2zn2vVtGvi1tw5HnzkHRl/Shjq6LjLpARuzmHOScSVJaBA2Jx9VSFJTDINFW bigCopgLPFgVFd18DmlIYhMOu/c6Hvm6idVEKaXtcNYTS+RlmW3yqsiGcOC+OX9lM3yD fPE4arWkNqujBCtUr9wf3C5jo0RjolRfmkLodvbVq/LlYIqH2Loo0vVnACYKPaoaQ9Rx Dn9KouK7lLFDcH2dGHNT1w5FJdStB9t1tol0SRxj4gBWfVCIeSqIjOYgryO7LUkkpfTj DZJQ== X-Gm-Message-State: AMke39l3hoP41n0N2nHd/2KiRAedG8oS0oPnHrezZ6pZ/MecSJkNONcMhAqC8DYNaTGXpWJZpTNVcis2km69/g== X-Received: by 10.107.131.229 with SMTP id n98mr672507ioi.39.1486595150634; Wed, 08 Feb 2017 15:05:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Wed, 8 Feb 2017 15:05:49 -0800 (PST) In-Reply-To: <20170208224131.256CC635E87D@rock.dv.isc.org> References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <00767076-FA43-42C0-A4AF-39F4E1087F11@fugue.com> <20170208203018.CF0B5635DFA1@rock.dv.isc.org> <20170208224131.256CC635E87D@rock.dv.isc.org> From: Brian Dickson Date: Wed, 8 Feb 2017 15:05:49 -0800 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a113ec5f4e0f12b05480ce78e Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 23:05:53 -0000 --001a113ec5f4e0f12b05480ce78e Content-Type: text/plain; charset=UTF-8 On Wed, Feb 8, 2017 at 2:41 PM, Mark Andrews wrote: > > In message , Ted Lemon > writes: > > > > On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote: > > > And if the service has the same privacy issues as .onion has? > > > > > > So we leak names until every recursive server in the world is > > > validating (what % is that today?) and supports agressive negative > > > caching (still a I-D). > > > > I feel like I am arguing with a wall, so if this doesn't work I will just > > give up. But if it's okay for us to ask resolvers to make a chance, it > > is okay for us to ask resolvers to make the right change. And if they > > don't, yes, it's possible that some queries will leak. There is nothing > > we can do to prevent that other than harden caching servers and stub > > resolvers; if we are going to do that, we might as well do it right, by > > caching the full proof of nonexistence, rather lying about what's in the > > root zone. > > Actually we can do something that doesn't require that validation > be enabled. We don't have to create that linkage. It's not like > the names are not supposed to exist. They do/will exist and not > as in they are/will be squatted upon. > I'm confused here. The point of ALT (and/or LCL if a 2nd draft is created), and ONION, is that they exist ONLY within their own (local) scope, if they exist at all. >From the viewpoint of the global DNS, they do not exist, and the point of those I-Ds/RFCs is to enforce that non-existence, in the global scope. My problem with what you are proposes, is that it removes the mechanism for that enforcement. Here's a thought - for any/all validating stubs, use CD=1 for names in the set of "things that are meant to be local", and turn off validation of those. That *should*, if I understand 4035's directives for CD=1, prevent validation by the recursive resolver in use by the client, and will return whatever answers are present, with or without DNSSEC records. Or, perhaps the organizations that represent the requestor of the 6761 names, could establish something like a "distrust anchor" - a trust anchor which is only to be used for signing negative assertions about the TLD name, or assertions about its insecure status to enable local service of the TLD name, and which can be published to the community, along with a static DNS zone file to be served by the -aware resolvers? Again, just to reiterate, in the global root zone, and for any resolvers which are not yet onion-aware, onion does not exist and must not exist. For onion-aware resolvers, everything related to onion is just an optimization; avoiding leakage for privacy reasons might be an issue for some folks, but IMHO must not tread on the previous requirement - that onion must not exist in the root, and must not appear to exist to any onion-unaware resolvers. If you want to find a way to fix that, without resulting in BOGUS or SERVFAIL, there may be ways that aren't easy, but the one way not permitted by the published RFCs is, an unsigned delegation in the root. I'm not sure why you disagree with this, it is clear as day in the relevant RFCs. Brian > > Oh sorry, you can't have privacy unless you validate. And only > because people are too scared to ask for changes to the root > zone to add a delegation. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --001a113ec5f4e0f12b05480ce78e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 8, 2017 at 2:41 PM, Mark Andrews <marka@isc.org>= wrote:

In message <A6839264-7054-4A08-828B-66BFA6C94352@fugue.com>, Ted Lemo= n writes:
>
> On Feb 8, 2017, at 3:30 PM, Mark Andrews <marka@isc.org> wrote:
> > And if the service has the same privacy issues as .onion has?
> >
> > So we leak names until every recursive server in the world is
> > validating (what % is that today?) and supports agressive negativ= e
> > caching (still a I-D).
>
> I feel like I am arguing with a wall, so if this doesn't work I wi= ll just
> give up.=C2=A0 =C2=A0But if it's okay for us to ask resolvers to m= ake a chance, it
> is okay for us to ask resolvers to make the right change.=C2=A0 =C2=A0= And if they
> don't, yes, it's possible that some queries will leak.=C2=A0 = =C2=A0There is nothing
> we can do to prevent that other than harden caching servers and stub > resolvers; if we are going to do that, we might as well do it right, b= y
> caching the full proof of nonexistence, rather lying about what's = in the
> root zone.

Actually we can do something that doesn't require that vali= dation
be enabled.=C2=A0 We don't have to create that linkage.=C2=A0 It's = not like
the names are not supposed to exist.=C2=A0 They do/will exist and not
as in they are/will be squatted upon.

I= 'm confused here.

The point of ALT (and/or LCL= if a 2nd draft is created), and ONION, is that they exist ONLY within thei= r own (local) scope, if they exist at all.

From th= e viewpoint of the global DNS, they do not exist, and the point of those I-= Ds/RFCs is to enforce that non-existence, in the global scope.
My problem with what you are proposes, is that it removes the = mechanism for that enforcement.

Here's a thoug= ht - for any/all validating stubs, use CD=3D1 for names in the set of "= ;things that are meant to be local", and turn off validation of those.=
That *should*, if I understand 4035's directives for CD=3D1,= prevent validation by the recursive resolver in use by the client, and wil= l return whatever answers are present, with or without DNSSEC records.

Or, perhaps the organizations that represent the reque= stor of the 6761 names, could establish something like a "distrust anc= hor" - a trust anchor which is only to be used for signing negative as= sertions about the TLD name, or assertions about its insecure status to ena= ble local service of the TLD name, and which can be published to the commun= ity, along with a static DNS zone file to be served by the <name>-awa= re resolvers?

Again, just to reiterate, in the glo= bal root zone, and for any resolvers which are not yet onion-aware, onion d= oes not exist and must not exist.

For onion-aware = resolvers, everything related to onion is just an optimization; avoiding le= akage for privacy reasons might be an issue for some folks, but IMHO must n= ot tread on the previous requirement - that onion must not exist in the roo= t, and must not appear to exist to any onion-unaware resolvers.
<= br>
If you want to find a way to fix that, without resulting in B= OGUS or SERVFAIL, there may be ways that aren't easy, but the one way n= ot permitted by the published RFCs is, an unsigned delegation in the root.<= /div>

I'm not sure why you disagree with this, it is= clear as day in the relevant RFCs.

Brian


=C2=A0

Oh sorry, you can't have privacy unless you validate.=C2=A0 And only because people are too scared to ask for changes to the root
zone to add a delegation.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0INTERNET: marka@isc.org

--001a113ec5f4e0f12b05480ce78e-- From nobody Wed Feb 8 15:56:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEE612962A for ; Wed, 8 Feb 2017 15:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 eL3qJS7EDaIX for ; Wed, 8 Feb 2017 15:56:39 -0800 (PST) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79CDB12963D for ; Wed, 8 Feb 2017 15:56:39 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v18Nubwq011122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2017 16:56:37 -0700 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 25C611E006D; Wed, 8 Feb 2017 16:56:32 -0700 (MST) Received: from lxomp07u.corp.intranet (unknown [151.119.92.134]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id EBFCA1E0064; Wed, 8 Feb 2017 16:56:31 -0700 (MST) Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v18NuVov015398; Wed, 8 Feb 2017 17:56:31 -0600 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v18NuVSO015391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Feb 2017 17:56:31 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0294.000; Wed, 8 Feb 2017 17:56:31 -0600 From: "Woodworth, John R" To: "'Brian Dickson'" , Mark Andrews Thread-Topic: [DNSOP] ALT-TLD and (insecure) delgations. Thread-Index: AQHSflh9kXNtPT4di0y/0CDCqL340aFXxwMugAWH3gD//6ORF4AAgZgAgAB5+4CAAD0FgIAACTmA///YcYCAAG8YgP//n7A+ABtJ0ID//6VfaIAAaX8A//+gjBmAAPxRAP//6OTpgABmawD//6c4SwAEkoP7AA1hN4AADFLRgA== Date: Wed, 8 Feb 2017 23:56:30 +0000 Message-ID: References: <20170203210922.7286C618213C@rock.dv.isc.org> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <00767076-FA43-42C0-A4AF-39F4E1087F11@fugue.com> <20170208203018.CF0B5635DFA1@rock.dv.isc.org> <20170208224131.256CC635E87D@rock.dv.isc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "dnsop@ietf.org WG" , "Woodworth, John R" , Ted Lemon , "Ballew, Dean" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 23:56:45 -0000 PiBPbiBXZWQsIEZlYiA4LCAyMDE3IGF0IDI6NDEgUE0sIE1hcmsgQW5kcmV3cyA8bWFya2FAaXNj Lm9yZz4gd3JvdGU6DQo+DQo+IEluIG1lc3NhZ2UgPEE2ODM5MjY0LTcwNTQtNEEwOC04MjhCLTY2 QkZBNkM5NDM1MkBmdWd1ZS5jb20+LCBUZWQgTGVtb24gd3JpdGVzOg0KPiA+DQo+ID4gT24gRmVi IDgsIDIwMTcsIGF0IDM6MzAgUE0sIE1hcmsgQW5kcmV3cyA8bWFya2FAaXNjLm9yZz4gd3JvdGU6 DQo+ID4gPiBBbmQgaWYgdGhlIHNlcnZpY2UgaGFzIHRoZSBzYW1lIHByaXZhY3kgaXNzdWVzIGFz IC5vbmlvbiBoYXM/DQo+ID4gPg0KPiA+ID4gU28gd2UgbGVhayBuYW1lcyB1bnRpbCBldmVyeSBy ZWN1cnNpdmUgc2VydmVyIGluIHRoZSB3b3JsZCBpcw0KPiA+ID4gdmFsaWRhdGluZyAod2hhdCAl IGlzIHRoYXQgdG9kYXk/KSBhbmQgc3VwcG9ydHMgYWdyZXNzaXZlIG5lZ2F0aXZlDQo+ID4gPiBj YWNoaW5nIChzdGlsbCBhIEktRCkuDQo+ID4NCj4gPiBJIGZlZWwgbGlrZSBJIGFtIGFyZ3Vpbmcg d2l0aCBhIHdhbGwsIHNvIGlmIHRoaXMgZG9lc24ndCB3b3JrIEkgd2lsbCBqdXN0DQo+ID4gZ2l2 ZSB1cC4gICBCdXQgaWYgaXQncyBva2F5IGZvciB1cyB0byBhc2sgcmVzb2x2ZXJzIHRvIG1ha2Ug YSBjaGFuY2UsIGl0DQo+ID4gaXMgb2theSBmb3IgdXMgdG8gYXNrIHJlc29sdmVycyB0byBtYWtl IHRoZSByaWdodCBjaGFuZ2UuICAgQW5kIGlmIHRoZXkNCj4gPiBkb24ndCwgeWVzLCBpdCdzIHBv c3NpYmxlIHRoYXQgc29tZSBxdWVyaWVzIHdpbGwgbGVhay4gICBUaGVyZSBpcyBub3RoaW5nDQo+ ID4gd2UgY2FuIGRvIHRvIHByZXZlbnQgdGhhdCBvdGhlciB0aGFuIGhhcmRlbiBjYWNoaW5nIHNl cnZlcnMgYW5kIHN0dWINCj4gPiByZXNvbHZlcnM7IGlmIHdlIGFyZSBnb2luZyB0byBkbyB0aGF0 LCB3ZSBtaWdodCBhcyB3ZWxsIGRvIGl0IHJpZ2h0LCBieQ0KPiA+IGNhY2hpbmcgdGhlIGZ1bGwg cHJvb2Ygb2Ygbm9uZXhpc3RlbmNlLCByYXRoZXIgbHlpbmcgYWJvdXQgd2hhdCdzIGluIHRoZQ0K PiA+IHJvb3Qgem9uZS4NCj4NCj4gQWN0dWFsbHkgd2UgY2FuIGRvIHNvbWV0aGluZyB0aGF0IGRv ZXNuJ3QgcmVxdWlyZSB0aGF0IHZhbGlkYXRpb24NCj4gYmUgZW5hYmxlZC4gIFdlIGRvbid0IGhh dmUgdG8gY3JlYXRlIHRoYXQgbGlua2FnZS4gIEl0J3Mgbm90IGxpa2UNCj4gdGhlIG5hbWVzIGFy ZSBub3Qgc3VwcG9zZWQgdG8gZXhpc3QuICBUaGV5IGRvL3dpbGwgZXhpc3QgYW5kIG5vdA0KPiBh cyBpbiB0aGV5IGFyZS93aWxsIGJlIHNxdWF0dGVkIHVwb24uDQo+DQo+IEknbSBjb25mdXNlZCBo ZXJlLg0KPg0KPiBUaGUgcG9pbnQgb2YgQUxUIChhbmQvb3IgTENMIGlmIGEgMm5kIGRyYWZ0IGlz IGNyZWF0ZWQpLCBhbmQgT05JT04sIGlzDQo+IHRoYXQgdGhleSBleGlzdCBPTkxZIHdpdGhpbiB0 aGVpciBvd24gKGxvY2FsKSBzY29wZSwgaWYgdGhleSBleGlzdCBhdCBhbGwuDQo+DQo+IEZyb20g dGhlIHZpZXdwb2ludCBvZiB0aGUgZ2xvYmFsIEROUywgdGhleSBkbyBub3QgZXhpc3QsIGFuZCB0 aGUgcG9pbnQNCj4gb2YgdGhvc2UgSS1Ecy9SRkNzIGlzIHRvIGVuZm9yY2UgdGhhdCBub24tZXhp c3RlbmNlLCBpbiB0aGUgZ2xvYmFsIHNjb3BlLg0KPg0KPiBNeSBwcm9ibGVtIHdpdGggd2hhdCB5 b3UgYXJlIHByb3Bvc2VzLCBpcyB0aGF0IGl0IHJlbW92ZXMgdGhlIG1lY2hhbmlzbQ0KPiBmb3Ig dGhhdCBlbmZvcmNlbWVudC4NCj4NCj4gSGVyZSdzIGEgdGhvdWdodCAtIGZvciBhbnkvYWxsIHZh bGlkYXRpbmcgc3R1YnMsIHVzZSBDRD0xIGZvciBuYW1lcyBpbiB0aGUNCj4gc2V0IG9mICJ0aGlu Z3MgdGhhdCBhcmUgbWVhbnQgdG8gYmUgbG9jYWwiLCBhbmQgdHVybiBvZmYgdmFsaWRhdGlvbiBv Zg0KPiB0aG9zZS4gIFRoYXQgKnNob3VsZCosIGlmIEkgdW5kZXJzdGFuZCA0MDM1J3MgZGlyZWN0 aXZlcyBmb3IgQ0Q9MSwgcHJldmVudA0KPiB2YWxpZGF0aW9uIGJ5IHRoZSByZWN1cnNpdmUgcmVz b2x2ZXIgaW4gdXNlIGJ5IHRoZSBjbGllbnQsIGFuZCB3aWxsIHJldHVybg0KPiB3aGF0ZXZlciBh bnN3ZXJzIGFyZSBwcmVzZW50LCB3aXRoIG9yIHdpdGhvdXQgRE5TU0VDIHJlY29yZHMuDQo+DQo+ IE9yLCBwZXJoYXBzIHRoZSBvcmdhbml6YXRpb25zIHRoYXQgcmVwcmVzZW50IHRoZSByZXF1ZXN0 b3Igb2YgdGhlIDY3NjENCj4gbmFtZXMsIGNvdWxkIGVzdGFibGlzaCBzb21ldGhpbmcgbGlrZSBh ICJkaXN0cnVzdCBhbmNob3IiIC0gYSB0cnVzdA0KPiBhbmNob3Igd2hpY2ggaXMgb25seSB0byBi ZSB1c2VkIGZvciBzaWduaW5nIG5lZ2F0aXZlIGFzc2VydGlvbnMNCj4gYWJvdXQgdGhlIFRMRCBu YW1lLCBvciBhc3NlcnRpb25zIGFib3V0IGl0cyBpbnNlY3VyZSBzdGF0dXMgdG8gZW5hYmxlDQo+ IGxvY2FsIHNlcnZpY2Ugb2YgdGhlIFRMRCBuYW1lLCBhbmQgd2hpY2ggY2FuIGJlIHB1Ymxpc2hl ZCB0byB0aGUNCj4gY29tbXVuaXR5LCBhbG9uZyB3aXRoIGEgc3RhdGljIEROUyB6b25lIGZpbGUg dG8gYmUgc2VydmVkIGJ5IHRoZQ0KPiA8bmFtZT4tYXdhcmUgcmVzb2x2ZXJzPw0KPg0KPiBBZ2Fp biwganVzdCB0byByZWl0ZXJhdGUsIGluIHRoZSBnbG9iYWwgcm9vdCB6b25lLCBhbmQgZm9yIGFu eSByZXNvbHZlcnMNCj4gd2hpY2ggYXJlIG5vdCB5ZXQgb25pb24tYXdhcmUsIG9uaW9uIGRvZXMg bm90IGV4aXN0IGFuZCBtdXN0IG5vdCBleGlzdC4NCj4NCj4gRm9yIG9uaW9uLWF3YXJlIHJlc29s dmVycywgZXZlcnl0aGluZyByZWxhdGVkIHRvIG9uaW9uIGlzIGp1c3QgYW4NCj4gb3B0aW1pemF0 aW9uOyBhdm9pZGluZyBsZWFrYWdlIGZvciBwcml2YWN5IHJlYXNvbnMgbWlnaHQgYmUgYW4gaXNz dWUNCj4gZm9yIHNvbWUgZm9sa3MsIGJ1dCBJTUhPIG11c3Qgbm90IHRyZWFkIG9uIHRoZSBwcmV2 aW91cyByZXF1aXJlbWVudA0KPiAtIHRoYXQgb25pb24gbXVzdCBub3QgZXhpc3QgaW4gdGhlIHJv b3QsIGFuZCBtdXN0IG5vdCBhcHBlYXIgdG8gZXhpc3QNCj4gdG8gYW55IG9uaW9uLXVuYXdhcmUg cmVzb2x2ZXJzLg0KPg0KPiBJZiB5b3Ugd2FudCB0byBmaW5kIGEgd2F5IHRvIGZpeCB0aGF0LCB3 aXRob3V0IHJlc3VsdGluZyBpbiBCT0dVUyBvcg0KPiBTRVJWRkFJTCwgdGhlcmUgbWF5IGJlIHdh eXMgdGhhdCBhcmVuJ3QgZWFzeSwgYnV0IHRoZSBvbmUgd2F5IG5vdA0KPiBwZXJtaXR0ZWQgYnkg dGhlIHB1Ymxpc2hlZCBSRkNzIGlzLCBhbiB1bnNpZ25lZCBkZWxlZ2F0aW9uIGluIHRoZSByb290 Lg0KPg0KDQpJIHdvdWxkIGxpa2UgdG8ganVzdCB0aHJvdyB0aGlzIG91dCB0aGVyZSBhZ2Fpbi4u IHdoYXQgYWJvdXQgYSBuZXcNClJSIHR5cGUgdG8gYWN0aXZlbHkgZmxhZyB0aGUgb3duZXIgYXMg b2ZmaWNpYWxseSBub3QtZXhpc3Rpbmc/DQpJIGNvdWxkIGV2ZW4gdm9sdW50ZWVyIHRvIHdyaXRl IHRoaXMgaWYgaXQgc2VlbXMgcmVhc29uYWJsZS4NCg0KSXQgc2VlbXMgdG8gbWUgdGhpcyBpc3N1 ZSBoYXMgY29tZSB1cCBhIG51bWJlciBvZiB0aW1lcyAoLm9uaW9uLCBldGMuKQ0KYW5kIGl0IGtl ZXBzIG5lZWRpbmcgdG8gYmUgc29sdmVkIGVhY2ggdGltZS4gIFRoZSA2NzYxLCBldGMuIGFuZCBy ZWxhdGVkDQpzcGVjaWFsLXVzZSByZWdpc3RyeSBjb250YWlucyBhIG51bWJlciBvZiAnU0hPVUxE JyBhbmQgJ1NIT1VMRCBOT1QnDQpyZXF1aXJlbWVudHMgdGhhdCBuZWVkIHRvIGJlIGNvbXBpbGVk IGludG8gc29mdHdhcmUsIHdoeSBub3QgZ2VuZXJhbGl6ZQ0KdGhpcyBhIGJpdCBtb3JlIGp1c3Qg aW4gY2FzZSBpdCBoYXBwZW5zIGFnYWluLg0KDQpUaGVyZSBpcyBhbHNvIHRoZSBzbWFsbCBtYXR0 ZXIgb2YgbW9uZXkgdnMuIGZyZWUuICBJZiBhIHpvbmUgaXMgInNpbXBseSINCmRlbGVnYXRlZCBp biB0aGUgcm9vdCB6b25lLCBhdCBzb21lIGZ1dHVyZSBwb2ludCB0aGlzIGRlbGVnYXRpb24gImNv dWxkIg0KYmVjb21lIGEgZnJlZSBzZXJ2aWNlLiAgV2l0aG91dCBkZWZpbml0aXZlICJ0ZWNobmlj YWwiIHJhdGlvbmFsIGZvciBuYW1lDQp1c2UsIHRoaXMgaXMgYSBkaWZmaWN1bHQgc2VsbC4gIEJ5 IGRlZmluaW5nIGFuIFJSIHR5cGUgcHVycG9zZWZ1bGx5DQpwcmV2ZW50aW5nIHRoaXMgY29uZGl0 aW9uLCBpdCBtaWdodCBiZSBhbiBlYXNpZXIgcGl0Y2guIEp1c3QgYSB0aG91Z2h0Lg0KDQoNClRo YW5rcywNCkpvaG4NCg0KPiBJJ20gbm90IHN1cmUgd2h5IHlvdSBkaXNhZ3JlZSB3aXRoIHRoaXMs IGl0IGlzIGNsZWFyIGFzIGRheSBpbiB0aGUNCj4gcmVsZXZhbnQgUkZDcy4NCj4NCj4gQnJpYW4N Cj4NCj4NCj4NCj4NCj4gT2ggc29ycnksIHlvdSBjYW4ndCBoYXZlIHByaXZhY3kgdW5sZXNzIHlv dSB2YWxpZGF0ZS4gIEFuZCBvbmx5DQo+IGJlY2F1c2UgcGVvcGxlIGFyZSB0b28gc2NhcmVkIHRv IGFzayBmb3IgY2hhbmdlcyB0byB0aGUgcm9vdA0KPiB6b25lIHRvIGFkZCBhIGRlbGVnYXRpb24u DQo+DQo+IE1hcmsNCj4gLS0NCj4gTWFyayBBbmRyZXdzLCBJU0MNCj4gMSBTZXltb3VyIFN0Liwg RHVuZGFzIFZhbGxleSwgTlNXIDIxMTcsIEF1c3RyYWxpYQ0KPiBQSE9ORTogKzYxIDIgOTg3MSA0 NzQyICAgICAgICAgICAgICAgICBJTlRFUk5FVDogbWFya2FAaXNjLm9yZw0KPg0KLS0gVEhFU0Ug QVJFIFRIRSBEUk9JRFMgVE8gV0hPTSBJIFJFRkVSOg0KVGhpcyBjb21tdW5pY2F0aW9uIGlzIHRo ZSBwcm9wZXJ0eSBvZiBDZW50dXJ5TGluayBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIFVuYXV0aG9yaXplZCB1c2Ugb2YgdGhpcyBjb21tdW5p Y2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRp YXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBj b3BpZXMgb2YgdGhlIGNvbW11bmljYXRpb24gYW5kIGFueSBhdHRhY2htZW50cy4NCg== From nobody Wed Feb 8 21:56:42 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1CD1294CE; Wed, 8 Feb 2017 21:56:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2017 21:56:36 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 05:56:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY Authors : Joe Abley Olafur Gudmundsson Marek Majkowski Filename : draft-ietf-dnsop-refuse-any-04.txt Pages : 10 Date : 2017-02-08 Abstract: The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance or other reasons. The DNS specification does not include specific guidance for the behaviour of DNS servers or clients in this situation. This document aims to provide such guidance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 8 21:58:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F631294D0 for ; Wed, 8 Feb 2017 21:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 C6pCHS1YcXvC for ; Wed, 8 Feb 2017 21:58:06 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 5FC8E129882 for ; Wed, 8 Feb 2017 21:58:06 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id v186so70306841wmd.0 for ; Wed, 08 Feb 2017 21:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ovwfQLn4HCntQJN+Y7JkBKzcVokQIoA/LYgxxu3AMYU=; b=NXpLEOHX0KMj1ZiyCAKEyXcWtkDgkIsZfMkZjOB7LHdREGINyXEqQaBVtGnxnJW+7R r2TGwtZNvmLfcB+rLYY1OUXIsbbBpflw/xO7ehi3CHWZqJKekUFmaqX3vdIjFZx2THTp 6ibmvthd7hCoSwiqnBqDG2nMWlWNFSpTtsl+I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ovwfQLn4HCntQJN+Y7JkBKzcVokQIoA/LYgxxu3AMYU=; b=CApecuIIVLJSovaBE/peNaEWHYftjDp9fzi5jrEZSM9bULBc6QXOYp+AuIEWOUoOMi Wxp6qCfxm2kv7Uzi1/1crs/YkK6w6GaBr+9tKrpwb0efmHDXhI2in0XcFiM1FjhxOWrJ mfY4NA/YPKYwP2Qh0CQM5TDA0K9x/4m1OQi2Ty0CcTN2jH6e2nfkgAeqejPTp8l6EZCZ 9wwczLKyfM47esN5G/lG0sVXwQQs213g8hjyb0wRpjH11pr4tIou9KgxfpzBka13cdIt HdzmERONfAnxqWxtV1YeJ8t0zA5tnDOd+fednKbmTtYvmauYtZKk5IvVWahttHrPKEJ7 8ZGQ== X-Gm-Message-State: AMke39n3Bi+sQ52En+Iuni7XuQ/IXE1clUuI/EDKHS2GcBFTlAY+cmMbg+B3Unhc5RuDk7j8tyIjh/8N3yN02YUm X-Received: by 10.28.179.7 with SMTP id c7mr19593733wmf.128.1486619884581; Wed, 08 Feb 2017 21:58:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.164.194 with HTTP; Wed, 8 Feb 2017 21:58:03 -0800 (PST) In-Reply-To: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Wed, 8 Feb 2017 21:58:03 -0800 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary=001a11452e4c2309b1054812aa5a Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 05:58:09 -0000 --001a11452e4c2309b1054812aa5a Content-Type: text/plain; charset=UTF-8 This version addresses all the comments that the chair's determined needed addressing. Olafur On Wed, Feb 8, 2017 at 9:56 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : Providing Minimal-Sized Responses to DNS Queries > that have QTYPE=ANY > Authors : Joe Abley > Olafur Gudmundsson > Marek Majkowski > Filename : draft-ietf-dnsop-refuse-any-04.txt > Pages : 10 > Date : 2017-02-08 > > Abstract: > The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". > The operator of an authoritative DNS server might choose not to > respond to such queries for reasons of local policy, motivated by > security, performance or other reasons. > > The DNS specification does not include specific guidance for the > behaviour of DNS servers or clients in this situation. This document > aims to provide such guidance. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a11452e4c2309b1054812aa5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This version addresses all the comments tha= t the chair's determined needed addressing.=C2=A0

Ol= afur


On Wed, Feb 8, 2017 at 9:56 PM, <internet-drafts@ietf.org>= ; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Providing Minimal-Sized Responses to DNS Queries that have QTYPE=3DANY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Joe = Abley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Olafur Gudmundsson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Marek Majkowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-refuse-any-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-02-08

Abstract:
=C2=A0 =C2=A0The Domain Name System (DNS) specifies a query type (QTYPE) &q= uot;ANY".
=C2=A0 =C2=A0The operator of an authoritative DNS server might choose not t= o
=C2=A0 =C2=A0respond to such queries for reasons of local policy, motivated= by
=C2=A0 =C2=A0security, performance or other reasons.

=C2=A0 =C2=A0The DNS specification does not include specific guidance for t= he
=C2=A0 =C2=A0behaviour of DNS servers or clients in this situation.=C2=A0 T= his document
=C2=A0 =C2=A0aims to provide such guidance.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-dnsop-refuse-any/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ie= tf-dnsop-refuse-any-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-dnsop-refuse-any-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a11452e4c2309b1054812aa5a-- From nobody Thu Feb 9 00:53:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351B01295DA for ; Thu, 9 Feb 2017 00:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 X2pHGkWQjEFM for ; Thu, 9 Feb 2017 00:53:30 -0800 (PST) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39491293D6 for ; Thu, 9 Feb 2017 00:53:30 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v198rTi9002053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Feb 2017 01:53:29 -0700 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 55C8F1E0049; Thu, 9 Feb 2017 01:53:24 -0700 (MST) Received: from lxdnp31k.corp.intranet (unknown [151.119.92.134]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 3C8101E0035; Thu, 9 Feb 2017 01:53:24 -0700 (MST) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v198rObt013440; Thu, 9 Feb 2017 01:53:24 -0700 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v198rNPi013432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Feb 2017 01:53:24 -0700 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0294.000; Thu, 9 Feb 2017 02:53:23 -0600 From: "Woodworth, John R" To: =?utf-8?B?J8OTbGFmdXIgR3XDsG11bmRzc29uJw==?= , dnsop Thread-Topic: [DNSOP] Review of draft [draft-ietf-dnsop-refuse-any-04.txt] Thread-Index: AQHSgq76IQmXyncSSk6eWHtGX0j5VQ== Date: Thu, 9 Feb 2017 08:53:22 +0000 Message-ID: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "Woodworth, John R" , "Ballew, Dean" Subject: [DNSOP] Review of draft [draft-ietf-dnsop-refuse-any-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 08:53:32 -0000 T2xhZnVyLA0KDQpUaGlzIGlzIG15IGZpcnN0IGRyYWZ0IHJldmlldyBzbyBhcG9sb2dpZXMgaWYg aXQgc2VlbXMgaGFyc2gsIEkNCnJlYWxseSBsaWtlIHRoZSBjb25jZXB0IG9mIHRoaXMgZHJhZnQu DQoNCg0KQ29tbWVudHM6DQoNCi0tDQpTZWN0aW9uIDQuMSAiU2VsZWN0IG9uZSBSUlNldCBtb2Rl IiAtDQoNClRoZSBzZWN0aW9uIGluY2x1ZGluZyAiLi4uY2hvb3NlIGEgc21hbGwgb25lKHMpIHRv Li4uIiBzZWVtcw0KY29uZnVzaW5nLCBhIHNpbmdsZSBSUlNldCBpcyBleHBlY3RlZCB3aHkgdGhl IHBvc3NpYmlsaXR5IG9mDQptdWx0aXBsZSBSUnNldHM/DQoNCg0KLS0NClNlY3Rpb24gNC4yICJT eW50aGVzaXNlZCBISU5GTyBSUnNldCIgLQ0KDQpJIGRvIG5vdCBmb2xsb3cgdGhlIHNlY3Rpb24g aW5jbHVkaW5nICIuLi5xdWVyeSBpbmNsdWRlcyBETz0xLi4uIi4NClNob3VsZCB0aGUgaW1wbGVt ZW50YXRpb24gZmFsbCBiYWNrIHRvIHRoZSBvbmUtUlJTZXQtbW9kZT8gIElmIHRoZQ0Kb25seSBS UlNldCByZXR1cm5lZCBpcyBhIHN5bnRoZXNpemVkIEhJTkZPIG9uZSwgd2hhdCBkb2VzIHRoZQ0K cmV0dXJuZWQgUlJTSUcgY29ycmVzcG9uZCB0bz8NCg0KDQotLQ0KR2VuZXJhbCAtDQoNCkkgd291 bGQgcGVyc29uYWxseSBsaWtlIHRvIHNlZSBtb3JlIGRpcmVjdGlvbiBmb3IgaW1wbGVtZW50ZXJz DQpwcm92aWRlZCBpbiB0aGUgZHJhZnQsIGUuZy4gZXhwZWN0ZWQgY29uZmlndXJhYmxlIGZlYXR1 cmVzLg0KSSByZWFsaXplIHRoaXMgaXMgYSBtYXR0ZXIgb2YgcGVyc29uYWwgdGFzdGUuDQoNCg0K VGhhbmtzIGFuZCBnb29kIGx1Y2ssDQpKb2huDQoNCi0tIFRIRVNFIEFSRSBUSEUgRFJPSURTIFRP IFdIT00gSSBSRUZFUjoNClRoaXMgY29tbXVuaWNhdGlvbiBpcyB0aGUgcHJvcGVydHkgb2YgQ2Vu dHVyeUxpbmsgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uLiBVbmF1dGhvcml6ZWQgdXNlIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUg c2VuZGVyIGJ5IHJlcGx5IGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBjb21t dW5pY2F0aW9uIGFuZCBhbnkgYXR0YWNobWVudHMuDQo= From nobody Thu Feb 9 05:53:44 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2481F129EB1 for ; Thu, 9 Feb 2017 05:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAtConEiqVHN for ; Thu, 9 Feb 2017 05:53:41 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 1278C129DC6 for ; Thu, 9 Feb 2017 05:53:38 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id 11so4573535qkl.3 for ; Thu, 09 Feb 2017 05:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Kf/dwiUtcYQ6W1VTVU0spLsc1jZOrUt5SSFYbnw9aOw=; b=leIl9HitlX3CpIYTphartbwq7L2YgLGU0D6bsCYPPfeKheik4MHwRMRVQDpNw/pw2E B6CDydC0FKyYXVLGM/4aKrgDpxcrLBWwkhDc6accf5iyHNYJ6Hnk48ngMHOdhYRItg26 gFhusHSkzZ34eKEwKoiaekb+1SudP67gqqyN/bt5jMFV47aAvvJ01siznFdcVH+joUlC nSTBVRSWVVLmTP1wATIjFRHIpX/dp+kKSs/Se9jYT85CwZ9vgWhvBWJd89qH+je7QF5t 1In55hH80xYtaz4gT60utTzEWC4PVOj0x9rtbJ/XnV/D14nDVSuxRVi7mYiZIrhlt2zK lHEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Kf/dwiUtcYQ6W1VTVU0spLsc1jZOrUt5SSFYbnw9aOw=; b=CcTX6zjJNmi2JeTtqRg6feX4eXCfByboafJVVPZpSQCLxgRJUoq3dRdDbFCgpBFmoy HVMG0iL+uKVL7joQ44zahFDIX0iGo6fmZsRRo7jMT1mlyD8hIXNtklZKqc/ARtE394l8 +t3jZBRuENiwWXVtPGCyVwt1TvX2mWsMMvmW2jIXGhYXmyORE1yWk3Lv+Rhw6hhRMRHH z4gCKqmHgrRF9JLpUKVPAtNJyEcYAllMugCoJ+p17NIQM9raQl8pTcliDF2oZuOGeNTC JSImBLDf4CIzQbh+sbQz7HtKhxmwIsH6nQid+VbHZ5GLI11I5fleB2B5HbUHv446s8Z/ 5NcA== X-Gm-Message-State: AMke39kGfatOneiF313HiEGOsq5LNknyN/dn6DcATPmRCA6fgGQSQJHNa+16pjeWko9g3A== X-Received: by 10.55.54.19 with SMTP id d19mr3201983qka.290.1486648417176; Thu, 09 Feb 2017 05:53:37 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:68af:5536:77eb:4363? ([2601:18f:801:600:68af:5536:77eb:4363]) by smtp.gmail.com with ESMTPSA id 11sm9170711qke.38.2017.02.09.05.53.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 05:53:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ralph Droms In-Reply-To: <390DDFE7-E70F-4E4E-96AB-AECFE25672E0@vpnc.org> Date: Thu, 9 Feb 2017 08:53:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7D15FFBE-5095-4852-8B05-7E6C26DAD269@gmail.com> References: <390DDFE7-E70F-4E4E-96AB-AECFE25672E0@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] A nudge on the new terms in draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 13:53:43 -0000 Paul - I finished my review of the terminology doc; added 1 issue today. - Ralph > On Feb 8, 2017, at 4:31 PM, Paul Hoffman = wrote: >=20 > [[ Hopefully the WG can focus on multiple topics at once; this one has = an effect on the upcoming interim WG meeting. ]] >=20 > [[ We got a few responses to our earlier message about the new terms = in draft-ietf-dnsop-terminology-bis-04, but would certainly like to hear = more. =46rom our earlier message: ]] >=20 > The authors have tentatively made some substantial changes to the = draft, to define "domain name", "global DNS", and "private DNS" in a = manner that can be used by other work in the IETF, particularly around = RFC 6761. Our first cut of definitions are in the new draft, but we = fully expect significant discussion in the WG before there is even rough = consensus. We are not even sure that the WG will agree with the idea of = adding "global DNS" and "private DNS" to the document. The authors are = not even sure they agree with all of this. >=20 > At the same time, we think that it would be easier to track open = issues in our GitHub repo at = https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis rather than in = the document as comments. To be clear, the discussion of how issues are = to be resolved should be mostly done on the mailing list, but using = GitHub to track issues might give easier-to-follow history of the = discussions. We also are open to using GitHub for pull requests for = specific changes to the document. >=20 > As a final note, this version of the draft also has some changes not = related to the above, and we encourage review of those changes, plus = anything else in the draft, of course. >=20 > --Paul Hoffman >=20 > On 27 Jan 2017, at 10:08, internet-drafts@ietf.org wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Domain Name System Operations of the = IETF. >>=20 >> Title : DNS Terminology >> Authors : Paul Hoffman >> Andrew Sullivan >> Kazunori Fujiwara >> Filename : draft-ietf-dnsop-terminology-bis-04.txt >> Pages : 34 >> Date : 2017-01-27 >>=20 >> Abstract: >> The DNS is defined in literally dozens of different RFCs. The >> terminology used by implementers and developers of DNS protocols, = and >> by operators of DNS systems, has sometimes changed in the decades >> since the DNS was first defined. This document gives current >> definitions for many of the terms used in the DNS in a single >> document. >>=20 >> This document will be the successor to RFC 7719. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-terminology-bis-04= >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Feb 9 07:30:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF4F129AB7 for ; Thu, 9 Feb 2017 07:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 Qp1VOMpmkALD for ; Thu, 9 Feb 2017 07:30:11 -0800 (PST) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 09A8F129ABD for ; Thu, 9 Feb 2017 07:29:53 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id o16so86264202wra.1 for ; Thu, 09 Feb 2017 07:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ak94DYcXKe7Gm1CertAuJiyR1aFWuKDNI6wGC2LOtHE=; b=rHrOgLOExDBc0ijKa8aO7o83H+aqZ/IvDmioclEGzEfGmsx8RdSbMwI7UcVgyvleio KieMWPS9B1NZ2RCi09Z1tSC/OxDfJt2dLGuZPyIPOSCYx6aBuGwTas8yQxNqFl1Qnv6Y Cy+HRPFfOWShdyISV+FLJFr69R6HZTvx/VEIU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ak94DYcXKe7Gm1CertAuJiyR1aFWuKDNI6wGC2LOtHE=; b=rGITry7m+u+3XXF5t9HncBJoRxGPe8FKWtsuZHE6c+X6lw6UeRy4uGCA424NrkcCV8 dmU1uwEF8W2QnG9CUk4VVTT7wqMTRI3/7fg/Tq9kh/R+1rUC73Ehx77+HygWO8f4mc3Y TKepwR4kQn6vjKXzePq4fp/V4q4gNFmlz3k4BJASUcy6s4Kra6q9vtEY1HKBMof4FXUP EM5Q9VWyrIp6xAsbCWPBerYZFCeqsLKCvdK32WEzeBBuwTou04h+ueppa1OAWwIgsmFv WJ7TrePdaVv8ljdAPldYSgVLz9uMKsMKM/0PisjD4tf8cakKAjLlgPKSpFg0swpKpr7q /nRw== X-Gm-Message-State: AMke39mQtK3XHdKvsIsTazcHhPEKe3D+TDB3WLoxR6ujVjREgo3ZzogUr39mFIt/xSvRK80mPy7O6f1nLiI97PbP X-Received: by 10.223.161.130 with SMTP id u2mr3915211wru.127.1486654191261; Thu, 09 Feb 2017 07:29:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.164.194 with HTTP; Thu, 9 Feb 2017 07:29:50 -0800 (PST) In-Reply-To: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Thu, 9 Feb 2017 07:29:50 -0800 Message-ID: To: "Woodworth, John R" Content-Type: multipart/alternative; boundary=f403045f3ed4f974d305481aa6ca Archived-At: Cc: dnsop , "Ballew, Dean" Subject: Re: [DNSOP] Review of draft [draft-ietf-dnsop-refuse-any-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 15:30:12 -0000 --f403045f3ed4f974d305481aa6ca Content-Type: text/plain; charset=UTF-8 John, Thanks for the review you are spot on, I should not edit while watching a soccer game :-( I will post an updated version in the next few days. how about for section 4.1: I was trying to cover the case where the RRSET selected has Multiple RRSIG's not About 4.2. Implementation may choose this when it can, if it can not for a zone then fall back on 4.1 as for the guidance, I tried, but there are strong opinions out there and ..... Olafur On Thu, Feb 9, 2017 at 12:53 AM, Woodworth, John R < John.Woodworth@centurylink.com> wrote: > Olafur, > > This is my first draft review so apologies if it seems harsh, I > really like the concept of this draft. > > > Comments: > > -- > Section 4.1 "Select one RRSet mode" - > > The section including "...choose a small one(s) to..." seems > confusing, a single RRSet is expected why the possibility of > multiple RRsets? > > > -- > Section 4.2 "Synthesised HINFO RRset" - > > I do not follow the section including "...query includes DO=1...". > Should the implementation fall back to the one-RRSet-mode? If the > only RRSet returned is a synthesized HINFO one, what does the > returned RRSIG correspond to? > > > -- > General - > > I would personally like to see more direction for implementers > provided in the draft, e.g. expected configurable features. > I realize this is a matter of personal taste. > > > Thanks and good luck, > John > > -- THESE ARE THE DROIDS TO WHOM I REFER: > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender > by reply e-mail and destroy all copies of the communication and any > attachments. > --f403045f3ed4f974d305481aa6ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

John,=C2=A0

Thanks for t= he review=C2=A0
you are spot on, I should not edit while watching= a soccer game :-(=C2=A0

I will post an updated ve= rsion in the next few days.=C2=A0

how about for se= ction 4.1:=C2=A0
I was trying to cover the case where the RRSET s= elected has Multiple RRSIG's not=C2=A0

About 4= .2.=C2=A0
Implementation may choose this when it can, if it can n= ot for a zone then fall back on 4.1=C2=A0

as for t= he guidance, I tried, but there are strong opinions out there and .....

Olafur



On Thu, Feb 9, 2017 at= 12:53 AM, Woodworth, John R <John.Woodworth@centurylink.com<= /a>> wrote:
Olafur,

This is my first draft review so apologies if it seems harsh, I
really like the concept of this draft.


Comments:

--
Section 4.1 "Select one RRSet mode" -

The section including "...choose a small one(s) to..." seems
confusing, a single RRSet is expected why the possibility of
multiple RRsets?


--
Section 4.2 "Synthesised HINFO RRset" -

I do not follow the section including "...query includes DO=3D1...&quo= t;.
Should the implementation fall back to the one-RRSet-mode?=C2=A0 If the
only RRSet returned is a synthesized HINFO one, what does the
returned RRSIG correspond to?


--
General -

I would personally like to see more direction for implementers
provided in the draft, e.g. expected configurable features.
I realize this is a matter of personal taste.


Thanks and good luck,
John

-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments.

--f403045f3ed4f974d305481aa6ca-- From nobody Thu Feb 9 08:27:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6831E129B8D for ; Thu, 9 Feb 2017 08:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 GxQ1CQCZOPCw for ; Thu, 9 Feb 2017 08:27:27 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0022C129B8E for ; Thu, 9 Feb 2017 08:27:26 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 293292807C2; Thu, 9 Feb 2017 17:27:25 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 22DC52807BF; Thu, 9 Feb 2017 17:27:25 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 20C40B38003; Thu, 9 Feb 2017 17:26:55 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 19C393FB86; Thu, 9 Feb 2017 17:26:55 +0100 (CET) Date: Thu, 9 Feb 2017 17:26:55 +0100 From: Stephane Bortzmeyer To: Mark Andrews Message-ID: <20170209162655.l3lbm45zrhizjwbc@nic.fr> References: <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <00767076-FA43-42C0-A4AF-39F4E1087F11@fugue.com> <20170208203018.CF0B5635DFA1@rock.dv.isc.org> <20170208224131.256CC635E87D@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170208224131.256CC635E87D@rock.dv.isc.org> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:27:29 -0000 On Thu, Feb 09, 2017 at 09:41:31AM +1100, Mark Andrews wrote a message of 38 lines which said: > And only because people are too scared to ask for changes to the > root zone to add a delegation. Being afraid to ask ICANN to do something is not cowardice, it is common sense :-) From nobody Thu Feb 9 08:31:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9FF129BA1 for ; Thu, 9 Feb 2017 08:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 IP2aA8BAkMNc for ; Thu, 9 Feb 2017 08:31:55 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65ED129B9F for ; Thu, 9 Feb 2017 08:31:54 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 7A8092807C2; Thu, 9 Feb 2017 17:31:53 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 744CE2807BF; Thu, 9 Feb 2017 17:31:53 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 725A7B38003; Thu, 9 Feb 2017 17:31:23 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 6CE143FA79; Thu, 9 Feb 2017 17:31:23 +0100 (CET) Date: Thu, 9 Feb 2017 17:31:23 +0100 From: Stephane Bortzmeyer To: Brian Dickson Message-ID: <20170209163123.56hdbzaluekmvbh7@nic.fr> References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:31:56 -0000 On Wed, Feb 08, 2017 at 12:36:23PM -0800, Brian Dickson wrote a message of 258 lines which said: > - upon startup, do a query for "onion" (the non-existent TLD), with DO=1. > - cache the response, and as appropriate, re-query periodically. > - If a query for .onion is received, reply with the authenticated > denial of existence from the root (cached in step 2) Note that, if you implement RFC 7816 and RFC 8020, you already have this behavior. No work for us :-) From nobody Thu Feb 9 08:37:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1153A129BB1 for ; Thu, 9 Feb 2017 08:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 GgLrpbKrGMBj for ; Thu, 9 Feb 2017 08:37:11 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A61129B92 for ; Thu, 9 Feb 2017 08:37:11 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 18DA32807C2; Thu, 9 Feb 2017 17:37:10 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 138732807BF; Thu, 9 Feb 2017 17:37:10 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 11482B38003; Thu, 9 Feb 2017 17:36:40 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 065243FA79; Thu, 9 Feb 2017 17:36:40 +0100 (CET) Date: Thu, 9 Feb 2017 17:36:39 +0100 From: Stephane Bortzmeyer To: John R Levine Message-ID: <20170209163639.sxvw6jg6lqxsavuq@nic.fr> References: <20170208091536.vqwftrhpole33opl@nic.fr> <20170208151101.14753.qmail@ary.lan> <20170208162718.jxaesl23jc6frykl@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:37:13 -0000 On Wed, Feb 08, 2017 at 11:40:16AM -0500, John R Levine wrote a message of 27 lines which said: > > URL, please, with the expected behavior of the resolver when queried > > for the domain. > > It's the IANA list of special use domains: > > >http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml It is not complete. For instance, {in-addr,ip6}.arpa domains for the documentation networks (e.g. 2.0.192.IN-ADDR.ARPA) are not present (but they are in the other registry, ) Also, unfortunately, the SU registry it lists the domains, not the expected behavior (example: .onion requires a NXDOMAIN, .localhost a reply for A/AAAA queries). So, you still need to read all the RFCs. From nobody Thu Feb 9 10:40:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE4C12957E for ; Thu, 9 Feb 2017 10:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=BK3R+4SC; dkim=pass (1536-bit key) header.d=taugh.com header.b=KbBE+sBp 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 B1kcEg-fTBgC for ; Thu, 9 Feb 2017 10:40:25 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80AFC124281 for ; Thu, 9 Feb 2017 10:40:24 -0800 (PST) Received: (qmail 43398 invoked from network); 9 Feb 2017 18:40:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a984.589cb797.k1702; bh=f2QsPi5tmPXmzj8gPEOFPrpPj0AbG0ItpVwhg+xRGm0=; b=BK3R+4SC/0O5B1qZWvvLCzr+OEcljLA98Rp46OKP2hyk19KDUplh7eY+7c5wsp4BKmZpAVtV+JKg67lnk4iA1sAuJ55FhHBRnjR/7Hdn0yaIieKFQIGONMvLTxLS6zqp8PshPXxWSkWX20/0q69Ps3D8QWqmPqd6MMN//4DipwAZbLcrMjzPc3D1Yad8/Zyt66VmOFRRhzRsMtY3z/I0RwyyKvyUlV0rcT2KKy+gkmIYYIt8Ao4iIhuZzgvXo2+4 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a984.589cb797.k1702; bh=f2QsPi5tmPXmzj8gPEOFPrpPj0AbG0ItpVwhg+xRGm0=; b=KbBE+sBpbR8VgFK+1gxAqZAb+H7cZLr8iUvLs2ISwY0oBmTLfycZJt67s/SJgIZHiwHMEmTfZ4MvGN69Tp9intN6vs7O/O4IPwGtwK2v8nx43dqUKkqOHLJhaPPlZl1CfHxM3U9vJlg7bSPrtKhfRwBbhiNiVKGDu8GyFt/AG8I070U67ej7hFz8Ajrq+lEUo05t3kWG0/S3Fs+/yGVBmHgv2tsF89/RQEf+GxtAh81xXAeEAeMGMbfB0FbZ7S8o Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 09 Feb 2017 18:40:23 -0000 Date: 9 Feb 2017 13:40:23 -0500 Message-ID: From: "John R Levine" To: "Stephane Bortzmeyer" In-Reply-To: <20170209163639.sxvw6jg6lqxsavuq@nic.fr> References: <20170208091536.vqwftrhpole33opl@nic.fr> <20170208151101.14753.qmail@ary.lan> <20170208162718.jxaesl23jc6frykl@nic.fr> <20170209163639.sxvw6jg6lqxsavuq@nic.fr> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] RFC 6761 vs. 6303 WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 18:40:26 -0000 On Thu, 9 Feb 2017, Stephane Bortzmeyer wrote: >> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml > > It is not complete. For instance, {in-addr,ip6}.arpa domains for the > documentation networks (e.g. 2.0.192.IN-ADDR.ARPA) are not present > (but they are in the other registry, > ) That's an interesting observation. RFC 6761 imported the RFC 1918 zones from RFC 6303 section 4.1, but not the other zones from sections 4.2 through 4.6. Was that deliberate of an oversight? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Feb 9 11:57:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774BD1294F4 for ; Thu, 9 Feb 2017 11:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 4cTBJOZa57Ug for ; Thu, 9 Feb 2017 11:57:30 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F806129450 for ; Thu, 9 Feb 2017 11:57:30 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 2E09034930F; Thu, 9 Feb 2017 19:57:28 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1DDCB160076; Thu, 9 Feb 2017 19:57:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0EC7016006C; Thu, 9 Feb 2017 19:57:28 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LhrMZWrMbsnj; Thu, 9 Feb 2017 19:57:27 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A7BF5160042; Thu, 9 Feb 2017 19:57:27 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DC1AB636586C; Fri, 10 Feb 2017 06:57:22 +1100 (EST) To: Stephane Bortzmeyer From: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> In-reply-to: Your message of "Thu, 09 Feb 2017 17:31:23 +0100." <20170209163123.56hdbzaluekmvbh7@nic.fr> Date: Fri, 10 Feb 2017 06:57:22 +1100 Message-Id: <20170209195722.DC1AB636586C@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 19:57:31 -0000 In message <20170209163123.56hdbzaluekmvbh7@nic.fr>, Stephane Bortzmeyer writes : > On Wed, Feb 08, 2017 at 12:36:23PM -0800, > Brian Dickson wrote > a message of 258 lines which said: > > > - upon startup, do a query for "onion" (the non-existent TLD), with DO=1. > > - cache the response, and as appropriate, re-query periodically. > > - If a query for .onion is received, reply with the authenticated > > denial of existence from the root (cached in step 2) > > Note that, if you implement RFC 7816 and RFC 8020, you already have > this behavior. No work for us :-) Only if you are willing to break lookups for names where there are missing delegations in parent zone and the parent and child zones share the same nameservers or the nameserver just misimplements ENT or the nameserver implements RFC 2535 NXDOMAIN (ENT don't exist with RFC 2535). All of these result in NXDOMAIN for ENT. RFC7816 A problem can also appear when a name server does not react properly to ENTs (Empty Non-Terminals). If ent.example.com has no resource records but foobar.ent.example.com does, then ent.example.com is an ENT. Whatever the QTYPE, a query for ent.example.com must return NODATA (NOERROR / ANSWER: 0). However, some name servers incorrectly return NXDOMAIN for ENTs. If a resolver queries only foobar.ent.example.com, everything will be OK, but if it implements QNAME minimisation, it may query ent.example.com and get an NXDOMAIN. See also Section 3 of [DNS-Res-Improve] for the other bad consequences of this bad behaviour. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 9 12:14:35 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E948D129C71 for ; Thu, 9 Feb 2017 12:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x9w7E5AVFh3 for ; Thu, 9 Feb 2017 12:14:32 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 AB580129C63 for ; Thu, 9 Feb 2017 12:14:32 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id f144so2935243pfa.2 for ; Thu, 09 Feb 2017 12:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w8OVUCEFXfWDzqms/NHDcl5NR1bDLyPOzPUywpSrZNc=; b=UW2VhB1kSCMLuEiSuo/afie8Ri1LR51QnHFxxbk65vJlDmet9fcIZAXlTSmzvOxg5c dk2Q77rXrQwLhDREzMj9KvIEk+C+vJRE9fdaAdmV7ZxIjsY1+eD5sUH1buGOHl1udREE kl5vp/0pN48ujsjV1+3uH1XE2ZIE76uJAzNK59gGLAKjnUOIpe0zejuiKjMwiJyykpuk kR86xhYiQJJFy/utzzUu53uaGJhKLEBYVXW19bevE8b1nH6gKgz4Bn5EmyL0A2doRjCu Bq7z1jRGb2NRa4C2Hh16V9I31GOr6q7hNVnWV/aWgcSispkk+3tNCNW2zyjnarx7JyIZ Z77A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w8OVUCEFXfWDzqms/NHDcl5NR1bDLyPOzPUywpSrZNc=; b=ff2MP3Qm7v/CC9N9e+sPXS2hof3JTh4cvGZd/dXJCLuAHBjV5RJa3YMjZvgHZyXheG jkQUkMalz3W5wsXD6GrXih1E1TTQUl7LODpeuaCaikhdC6gs9nG/v3x7nve7RpG7idOI kjujMZ3Z6PublZk58Veyqs6apOS/QqhfGU88yC7gSI5POe01Ff1+Tgzm6Bkqir5fiES9 5i3ITfpx4+MWTGjGNaq3LsS1wYZPGdJFatL0MReZYJi9eRePdH4sDK0qQJInMWkjPqwW atJcY0rbppeYR1HULO+c0j8nJh4K09lDlcYDV9Uw/a8ASgmvqo/uaCJSA7uKdjAqVRFv M4zQ== X-Gm-Message-State: AMke39kAkEoUyteE6MVol2PN14H98MgkinnmtZLhRyFdAHaI7vSxtQHB+1jAxh53L+AgYQ== X-Received: by 10.98.0.143 with SMTP id 137mr5621937pfa.173.1486671272226; Thu, 09 Feb 2017 12:14:32 -0800 (PST) Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id z127sm31224146pgz.29.2017.02.09.12.14.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 12:14:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (14D27) In-Reply-To: <20170209195722.DC1AB636586C@rock.dv.isc.org> Date: Thu, 9 Feb 2017 12:14:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> To: Mark Andrews Archived-At: Cc: Ted Lemon , "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 20:14:34 -0000 Maybe DNS authority server software could auto-generate TXT records for what= would otherwise be ENTs, or zone administrators could add them manually, E.g. ent.example.com TXT "This object intentionally left blank." This avoids the ENT issue. I can't think of any way that would break anything. The issue with ENTs is t= hat they have children, which are not changed or harmed. Preventing the erro= neous NXDOMAIN by a hack is still preventing an NXDOMAIN which should not be= returned. Brian Sent from my iPhone > On Feb 9, 2017, at 11:57 AM, Mark Andrews wrote: >=20 >=20 > In message <20170209163123.56hdbzaluekmvbh7@nic.fr>, Stephane Bortzmeyer w= rites > : >> On Wed, Feb 08, 2017 at 12:36:23PM -0800, >> Brian Dickson wrote=20 >> a message of 258 lines which said: >>=20 >>> - upon startup, do a query for "onion" (the non-existent TLD), with DO=3D= 1. >>> - cache the response, and as appropriate, re-query periodically. >>> - If a query for .onion is received, reply with the authentica= ted >>> denial of existence from the root (cached in step 2) >>=20 >> Note that, if you implement RFC 7816 and RFC 8020, you already have >> this behavior. No work for us :-) >=20 > Only if you are willing to break lookups for names where there are > missing delegations in parent zone and the parent and child zones > share the same nameservers or the nameserver just misimplements ENT > or the nameserver implements RFC 2535 NXDOMAIN (ENT don't exist > with RFC 2535). All of these result in NXDOMAIN for ENT. >=20 > RFC7816 >=20 > A problem can also appear when a name server does not react properly > to ENTs (Empty Non-Terminals). If ent.example.com has no resource > records but foobar.ent.example.com does, then ent.example.com is an > ENT. Whatever the QTYPE, a query for ent.example.com must return > NODATA (NOERROR / ANSWER: 0). However, some name servers incorrectly > return NXDOMAIN for ENTs. If a resolver queries only > foobar.ent.example.com, everything will be OK, but if it implements > QNAME minimisation, it may query ent.example.com and get an NXDOMAIN. > See also Section 3 of [DNS-Res-Improve] for the other bad > consequences of this bad behaviour. >=20 > Mark >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 9 12:34:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782321294A0 for ; Thu, 9 Feb 2017 12:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkIOz3TObnWe for ; Thu, 9 Feb 2017 12:34:28 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 9EAA312706D for ; Thu, 9 Feb 2017 12:34:28 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id w20so15697173qtb.1 for ; Thu, 09 Feb 2017 12:34:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Zeml20hty6sUhFVZC6MtP+lnV1f8i/jjhBMgUqucSic=; b=p8E/J19401+hSGjwwGWQXNNz7VQtQc4zrVRg53opLVgDgT2XrRRevq5ltTUqGy9oV5 KOPaJUrZVYSeXKMGO687Hp4GgFIrb7FpMheiVP54OSQszbfInNEq3MQoWrNrBWgcmyag 9sak7WvnFUh1vqP4wgo801G0+keil1c7CXLmKaTZBsYhc9bIQD937L0pipYJ9Z+9j95c 6BNZzv7O13lkZDTcGrhxCyLATuBM6G0aZ/PIl3kU6GZmDoLHHY18Il/NsDkkv7Ih8vwy FAtMaldJjOBGduV05j8Z74ua3bhJnH0H56G2lO/J89U4aiMssqkKK5KZnBxUiugaQn1H xd/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Zeml20hty6sUhFVZC6MtP+lnV1f8i/jjhBMgUqucSic=; b=C23UD250IISm/kRPAZ45LNUkN8buvBjNCshtMWdGN9j8x1UShKjhnkrnjrqZ9l7ZEd +Oy2lXrWKBkK8PYn5LKnUKgU+J7roMjDZSbbcDsqV981BpRTAPSpGXmvnRY3x6WBvZ7J dpA72SsUM2bkbAdOzR1HtPFb5nzZ5I70Eadqp8JkQ66VIwuf6qAtYvtlMEg04GfDyM1z IXH4ocmuLFlIEOU1Y8eziPDh68+Lx8fiw1cB+75bblv0eBfMz6mxQRuoK9IesQJXAGVy f15a+5+vJKnG1pSMqmWWZAZqE7tF8fD5bZ+9ZFXLN2NHsGWrxT6PybSBVyIAtXBDiz2k 4y8g== X-Gm-Message-State: AMke39lxrXD0htqDverLhx6V5PR5EZDEG9X+0/jtqCbtjhby5ntE1x3AfgFmfXatzt0SWg== X-Received: by 10.200.42.200 with SMTP id c8mr5179890qta.156.1486672467691; Thu, 09 Feb 2017 12:34:27 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id a70sm10151643qkc.1.2017.02.09.12.34.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 12:34:26 -0800 (PST) From: Ted Lemon Message-Id: <86C2B05D-7B70-46CF-938F-14DB73E60104@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_37361992-6846-41BD-B66A-B32F2B73E6B9" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 15:34:25 -0500 In-Reply-To: To: John R Levine References: <20170208091536.vqwftrhpole33opl@nic.fr> <20170208151101.14753.qmail@ary.lan> <20170208162718.jxaesl23jc6frykl@nic.fr> <20170209163639.sxvw6jg6lqxsavuq@nic.fr> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] RFC 6761 vs. 6303 WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 20:34:30 -0000 --Apple-Mail=_37361992-6846-41BD-B66A-B32F2B73E6B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2017, at 1:40 PM, John R Levine wrote: > That's an interesting observation. RFC 6761 imported the RFC 1918 = zones from RFC 6303 section 4.1, but not the other zones from sections = 4.2 through 4.6. Was that deliberate of an oversight? RFC 6761 doesn't actually reference RFC6303. I suspect that this was = indeed an oversight, although it can also be argued that there is no = special need to list these zones in the special-use names registry. But this inconsistency is certainly worthy of note. --Apple-Mail=_37361992-6846-41BD-B66A-B32F2B73E6B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 9, 2017, at 1:40 PM, John R Levine <johnl@taugh.com> = wrote:
That's an interesting observation.  RFC = 6761 imported the RFC 1918 zones from RFC 6303 section 4.1, but not the = other zones from sections 4.2 through 4.6.  Was that deliberate of = an oversight?

RFC = 6761 doesn't actually reference RFC6303.   I suspect that this was = indeed an oversight, although it can also be argued that there is no = special need to list these zones in the special-use names = registry.

But = this inconsistency is certainly worthy of note.

= --Apple-Mail=_37361992-6846-41BD-B66A-B32F2B73E6B9-- From nobody Thu Feb 9 12:45:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FBE12941A for ; Thu, 9 Feb 2017 12:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 rris08IWfcdA for ; Thu, 9 Feb 2017 12:45:13 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F06F12940D for ; Thu, 9 Feb 2017 12:45:13 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B47503493ED; Thu, 9 Feb 2017 20:45:10 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A2186160042; Thu, 9 Feb 2017 20:45:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 88D0916006C; Thu, 9 Feb 2017 20:45:10 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lJNfqoTvdWsP; Thu, 9 Feb 2017 20:45:10 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A6F7E160042; Thu, 9 Feb 2017 20:45:09 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BC40D6365CBE; Fri, 10 Feb 2017 07:45:06 +1100 (EST) To: Brian Dickson From: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> In-reply-to: Your message of "Thu, 09 Feb 2017 12:14:30 -0800." <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> Date: Fri, 10 Feb 2017 07:45:06 +1100 Message-Id: <20170209204506.BC40D6365CBE@rock.dv.isc.org> Archived-At: Cc: Ted Lemon , "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 20:45:15 -0000 In message <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com>, Brian Dickson writ es: > Maybe DNS authority server software could auto-generate TXT records for what= > would otherwise be ENTs, or zone administrators could add them manually, > > E.g. ent.example.com TXT "This object intentionally left blank." > > This avoids the ENT issue. > > I can't think of any way that would break anything. The issue with ENTs is t= > hat they have children, which are not changed or harmed. Preventing the erro= > neous NXDOMAIN by a hack is still preventing an NXDOMAIN which should not be= > returned. > > Brian Brian. There is only one time you can trust a NXDOMAIN to mean there is no data under it. That is when it validates as secure. At the moment we have Ted saying that if you want privacy you MUST also turn on DNSSEC validation and implement QNAME minimisation and implement agressive negative caching (still a I-D). This is all because of ungrounded fears of people using DNS as a way to do a opt-in experimental naming in .alt where we intend to have experimental opt-in naming services. Add to that it is suggested that we create yet another TLD (.lcl) where such services would be allowed. Mind boggling inconsistancy. Mark > Sent from my iPhone > > > On Feb 9, 2017, at 11:57 AM, Mark Andrews wrote: > >=20 > >=20 > > In message <20170209163123.56hdbzaluekmvbh7@nic.fr>, Stephane Bortzmeyer w= > rites > > : > >> On Wed, Feb 08, 2017 at 12:36:23PM -0800, > >> Brian Dickson wrote=20 > >> a message of 258 lines which said: > >>=20 > >>> - upon startup, do a query for "onion" (the non-existent TLD), with DO=3D > = > 1. > >>> - cache the response, and as appropriate, re-query periodically. > >>> - If a query for .onion is received, reply with the authentica= > ted > >>> denial of existence from the root (cached in step 2) > >>=20 > >> Note that, if you implement RFC 7816 and RFC 8020, you already have > >> this behavior. No work for us :-) > >=20 > > Only if you are willing to break lookups for names where there are > > missing delegations in parent zone and the parent and child zones > > share the same nameservers or the nameserver just misimplements ENT > > or the nameserver implements RFC 2535 NXDOMAIN (ENT don't exist > > with RFC 2535). All of these result in NXDOMAIN for ENT. > >=20 > > RFC7816 > >=20 > > A problem can also appear when a name server does not react properly > > to ENTs (Empty Non-Terminals). If ent.example.com has no resource > > records but foobar.ent.example.com does, then ent.example.com is an > > ENT. Whatever the QTYPE, a query for ent.example.com must return > > NODATA (NOERROR / ANSWER: 0). However, some name servers incorrectly > > return NXDOMAIN for ENTs. If a resolver queries only > > foobar.ent.example.com, everything will be OK, but if it implements > > QNAME minimisation, it may query ent.example.com and get an NXDOMAIN. > > See also Section 3 of [DNS-Res-Improve] for the other bad > > consequences of this bad behaviour. > >=20 > > Mark > >=20 > > --=20 > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 9 13:01:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9603212940D for ; Thu, 9 Feb 2017 13:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RothYOEwzDnS for ; Thu, 9 Feb 2017 13:01:16 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 E070A126D74 for ; Thu, 9 Feb 2017 13:01:15 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id k15so16379974qtg.3 for ; Thu, 09 Feb 2017 13:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jfhVQv3AYBo3BD18ty+pLTQk+8EXZoQ3yhikNUF3msw=; b=EADqZtEVNdsSD+/JKr5Zn7f8vC43tMFK+HtCIs8zJesoTt7BQ/exGsYEy/iaCcSu3e Xy3fChWLs5joXkjhnJerF3ZH5/z2qm7ZE3Vgd4PU8XnneDBuljHzGYjrLqzmmHHA6vbO C7KWgR33cvP4UKqOVlujsK8nbt7/y54BGdUvy4IGITPB5lrNsbeEcvgkdlzKsGmKTIXq VPYvv8SsX601wgtBFhYFZCy2smKmEt6FMBh2IhfBVT5vVTvBCcg9trjYhgYGOCuh/3Ko Qt7OvaGmj/HWB2LIjJcRKAiSom+1+HDE+BqsOCgkGnLubZhAvCChV8TGMSSfbaO9wMin voDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jfhVQv3AYBo3BD18ty+pLTQk+8EXZoQ3yhikNUF3msw=; b=XyR+hW6YQKxp1wnxObF1pGwSVrKAE5Xtv50lCdffxUoI62t023zFAhAqP8EGSsksC1 rYQxRDOaNlrOtdET7RUy1kmNI2HYPjeZmTpy7D8idwbyPL3d4nBD5E9ByQEwELY/hRPU CyBZnMkAgIiWc+qIrERFjl3XBvkBa196qKjaGIfpOwg8wwbWHlt03hRttcRAJW/NkGTg rDZ+7oF0zEYDZbn4jLCA8ZytqFMCDRzPSIqtzTF5gRCNUl0NYh3zEi0pEYJW19gaH/Je 7KPkzDWAL4nqVq8LjlK6DmMZ8smuuCfaFuxDjvgwmIiGdol5D4BtJBhZENQJfZbJ/YVH hO9w== X-Gm-Message-State: AMke39mBkaBIT3G2cqBbnqGsShETx/5rDAMIagqpQ+0qquef9y+E3h5icAJF+7cQV4qM1g== X-Received: by 10.237.56.135 with SMTP id k7mr5210479qte.42.1486674075051; Thu, 09 Feb 2017 13:01:15 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 12sm10179621qtv.31.2017.02.09.13.01.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 13:01:13 -0800 (PST) From: Ted Lemon Message-Id: <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0F044607-62A2-4D4E-8752-E3D4D4F710A7" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 16:01:12 -0500 In-Reply-To: <20170209204506.BC40D6365CBE@rock.dv.isc.org> To: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:01:17 -0000 --Apple-Mail=_0F044607-62A2-4D4E-8752-E3D4D4F710A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote: > At the moment we have Ted saying that if you want privacy you MUST > also turn on DNSSEC validation and implement QNAME minimisation and > implement agressive negative caching (still a I-D). No, I am _not_ saying that. I am saying that an unsigned delegation = doesn't help with privacy unless you also specially configure your local = resolver, and if you are going to specially configure your local = resolver, then there are several options for how to do that. The only = reason you need DNSSEC is that if you specially configure your local = resolver to lie, then DNSSEC validation will break that. If you aren't = doing DNSSEC validation, you can say any old thing in your local = resolver and the stub will believe it. --Apple-Mail=_0F044607-62A2-4D4E-8752-E3D4D4F710A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 9, 2017, at 3:45 PM, Mark Andrews <marka@isc.org> = wrote:
At the moment we have Ted saying that if you = want privacy you MUST
also turn on DNSSEC validation and = implement QNAME minimisation and
implement agressive negative = caching (still a I-D).

No, I am _not_ saying that.   I am saying that an = unsigned delegation doesn't help with privacy unless you also specially = configure your local resolver, and if you are going to specially = configure your local resolver, then there are several options for how to = do that.   The only reason you need DNSSEC is that if you specially = configure your local resolver to lie, then DNSSEC validation will break = that.   If you aren't doing DNSSEC validation, you can say any old = thing in your local resolver and the stub will believe it.

= --Apple-Mail=_0F044607-62A2-4D4E-8752-E3D4D4F710A7-- From nobody Thu Feb 9 14:49:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8254D129616 for ; Thu, 9 Feb 2017 14:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 E3DADxdFMTsK for ; Thu, 9 Feb 2017 14:49:05 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56903129448 for ; Thu, 9 Feb 2017 14:49:04 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 201F31FCAB3; Thu, 9 Feb 2017 22:48:56 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B821B160042; Thu, 9 Feb 2017 22:48:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A1EB616006C; Thu, 9 Feb 2017 22:48:54 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3Ey25DWePEwj; Thu, 9 Feb 2017 22:48:54 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 1B91F160042; Thu, 9 Feb 2017 22:48:54 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2FB1B63666E6; Fri, 10 Feb 2017 09:48:51 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> In-reply-to: Your message of "Thu, 09 Feb 2017 16:01:12 -0500." <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> Date: Fri, 10 Feb 2017 09:48:51 +1100 Message-Id: <20170209224851.2FB1B63666E6@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 22:49:06 -0000 In message <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com>, Ted Lemon writes: > > On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote: > > At the moment we have Ted saying that if you want privacy you MUST > > also turn on DNSSEC validation and implement QNAME minimisation and > > implement agressive negative caching (still a I-D). > > No, I am _not_ saying that. I am saying that an unsigned delegation > doesn't help with privacy unless you also specially configure your local > resolver, and if you are going to specially configure your local > resolver, then there are several options for how to do that. The only > reason you need DNSSEC is that if you specially configure your local > resolver to lie, then DNSSEC validation will break that. If you aren't > doing DNSSEC validation, you can say any old thing in your local resolver > and the stub will believe it. And a signed answer doesn't help unless the recursive server is validating (so it can trust the NXDOMAIN) and has QNAME minimimistion (to prevent *.alt leaking in the first place) and has agressive negative caching (so the answer from the minimised QNAME query get turned into a answer for *.alt). Now we can put QNAME minimisation into a server. Now we can put the code to support agressive negative caching into a server. We can't force validation to be enabled. We need all three things for the privacy leakage to stop. Any two alone doesn't stop it. The alternative is to do a insecure delegation and build in a default empty zone for alt. You then have to take steps to break the privacy leak by disabling the empty zone. Additionally it works with all existing servers if they just add a empty .alt zone. It doesn't require validation to be enabled. It's the difference between defaulting private or not. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 9 15:07:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AF01299C2 for ; Thu, 9 Feb 2017 15:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CKTRaSqTaLI for ; Thu, 9 Feb 2017 15:07:51 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 0C04912955E for ; Thu, 9 Feb 2017 15:07:51 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id n124so11465007lfd.2 for ; Thu, 09 Feb 2017 15:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NP2E9NRr+j57xEOeKBn4Zew8fSCDVAylriiE4xRULhg=; b=1ifFQteiYcHW0SZbjsQmrfb3RJrZNFW+iit4EhZZl1CgPAVli+LecuMWsBIi9bhBUl Z7KJhAeqGMAn/f2X+Jbaf4teX1LKWjR9bmD9VwPiYcyXCEdDAbscnnGbL5utLIkDMfdX z/KXfKevs8tQQGwMsFciopS+82E4WtK4rHc5fZFf63zcuMUQFjLFQeQasCZgTQvF9RDK zmxDJf3gOem3EqYkNSOx2T0VT1fq2UtBmlgcZvO7YB/UjH3wPoPeJkDE4cdMHPju/Tzl 86D35yVHTNog57xWlx1WfqkJMnCeQiE+0Jt0feNVvR+GeoBfYpNqOFZ1ZWnOhJqrCgTb jCow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NP2E9NRr+j57xEOeKBn4Zew8fSCDVAylriiE4xRULhg=; b=AFq8RZ2UlVBAL66OhWOp0rlCETOCHQ3NL+6BqDXRc7e2KwRjQshP/v2EwrsNi9G+Dk hckh8tHOKEIIbm3lO9l9sh2RjFPN5RWQwFSsTsMzMNwbeOXDkOUMRj09rzTwkQQuK7Sk oB+/m+Lo1Ih5yg1ACrRYphvdavevYkxljj/JvJBio4jEfrxMIbLzBJFg6B+ewPr7Q5ps EpwZxVU362vPT3qLlgN8/6CHv/xJeJu7SZx+DN0W/5prYF5B5NfADndsrDFGSROJX5M6 3sdn4HoX73YTJffXQ5xfSs81XzRp9YT8J1CdWZ6khjK/jpCOonAt6eKnjqDR96UKkyCx TKxQ== X-Gm-Message-State: AMke39kTvHkzg8WS9XlTCOd99DwevKpPdIXZPRjAIVTfRwO+bwZ0QToIVYT11x9hYFEcOB1goC+Ul5vtH61ibw== X-Received: by 10.25.92.217 with SMTP id u86mr2064980lfi.5.1486681669256; Thu, 09 Feb 2017 15:07:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.151.83 with HTTP; Thu, 9 Feb 2017 15:07:08 -0800 (PST) In-Reply-To: <20170209224851.2FB1B63666E6@rock.dv.isc.org> References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> From: Ted Lemon Date: Thu, 9 Feb 2017 18:07:08 -0500 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=94eb2c0c8e5cca568e0548210c07 Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 23:07:53 -0000 --94eb2c0c8e5cca568e0548210c07 Content-Type: text/plain; charset=UTF-8 How does a query for, e.g., super-s3kr1t.alt leak if your caching resolver is doing qname minimization? On Thu, Feb 9, 2017 at 5:48 PM, Mark Andrews wrote: > > In message <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com>, Ted Lemon > writes: > > > > On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote: > > > At the moment we have Ted saying that if you want privacy you MUST > > > also turn on DNSSEC validation and implement QNAME minimisation and > > > implement agressive negative caching (still a I-D). > > > > No, I am _not_ saying that. I am saying that an unsigned delegation > > doesn't help with privacy unless you also specially configure your local > > resolver, and if you are going to specially configure your local > > resolver, then there are several options for how to do that. The only > > reason you need DNSSEC is that if you specially configure your local > > resolver to lie, then DNSSEC validation will break that. If you aren't > > doing DNSSEC validation, you can say any old thing in your local resolver > > and the stub will believe it. > > And a signed answer doesn't help unless the recursive server is > validating (so it can trust the NXDOMAIN) and has QNAME minimimistion > (to prevent *.alt leaking in the first place) and has agressive > negative caching (so the answer from the minimised QNAME query get > turned into a answer for *.alt). > > Now we can put QNAME minimisation into a server. > Now we can put the code to support agressive negative caching into a > server. > We can't force validation to be enabled. > > We need all three things for the privacy leakage to stop. Any two > alone doesn't stop it. > > The alternative is to do a insecure delegation and build in a default > empty zone for alt. You then have to take steps to break the privacy > leak by disabling the empty zone. Additionally it works with all > existing servers if they just add a empty .alt zone. It doesn't > require validation to be enabled. > > It's the difference between defaulting private or not. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --94eb2c0c8e5cca568e0548210c07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How does a query for, e.g., super-s3kr1t.alt leak if your = caching resolver is doing qname minimization?

On Thu, Feb 9, 2017 at 5:48 PM, Mark Andr= ews <marka@isc.org> wrote:

In message <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com>, Ted Lemo= n writes:
>
> On Feb 9, 2017, at 3:45 PM, Mark Andrews <marka@isc.org> wrote:
> > At the moment we have Ted saying that if you want privacy you MUS= T
> > also turn on DNSSEC validation and implement QNAME minimisation a= nd
> > implement agressive negative caching (still a I-D).
>
> No, I am _not_ saying that.=C2=A0 =C2=A0I am saying that an unsigned d= elegation
> doesn't help with privacy unless you also specially configure your= local
> resolver, and if you are going to specially configure your local
> resolver, then there are several options for how to do that.=C2=A0 =C2= =A0The only
> reason you need DNSSEC is that if you specially configure your local > resolver to lie, then DNSSEC validation will break that.=C2=A0 =C2=A0I= f you aren't
> doing DNSSEC validation, you can say any old thing in your local resol= ver
> and the stub will believe it.

And a signed answer doesn't help unless the recursive serve= r is
validating (so it can trust the NXDOMAIN) and has QNAME minimimistion
(to prevent *.alt leaking in the first place) and has agressive
negative caching (so the answer from the minimised QNAME query get
turned into a answer for *.alt).

Now we can put QNAME minimisation into a server.
Now we can put the code to support agressive negative caching into a server= .
We can't force validation to be enabled.

We need all three things for the privacy leakage to stop.=C2=A0 Any two
alone doesn't stop it.

The alternative is to do a insecure delegation and build in a default
empty zone for alt.=C2=A0 You then have to take steps to break the privacy<= br> leak by disabling the empty zone.=C2=A0 Additionally it works with all
existing servers if they just add a empty .alt zone.=C2=A0 It doesn't require validation to be enabled.

It's the difference between defaulting private or not.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0INTERNET: marka@isc.org

--94eb2c0c8e5cca568e0548210c07-- From nobody Thu Feb 9 15:09:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E721298A3 for ; Thu, 9 Feb 2017 15:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhXBNDCWqCA4 for ; Thu, 9 Feb 2017 15:09:48 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 51235129612 for ; Thu, 9 Feb 2017 15:09:48 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id l66so36546961ioi.1 for ; Thu, 09 Feb 2017 15:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ma7Z8abY/APalx2o0UvySj4vyNrMPwt9pzqhU0V22fA=; b=k/ehqdSKNfL5iQ4V6o3EryNhAVLkjjqgNjyjmmZDhxgQONAqbClxWa6wuzeH2TMRRn +DMetH47N6mgawNk5pxZ1CI7ic58HSiVWVhWFDmiJrQGUgzpespXkRjqTdfIWzx8aJul 7m/IevB4EIwhOJHo9vCTmHLfe9oWwky2fEJx6dyw7hK8m4r2YCmv53cQgNGQw1sJQm51 30xDsJK7mISIfD/ASgYtppElFcRo9QnygCvCd1tJ+ICcnUb+owKqqcyo2El0487Wc7FO LtpudBfNXGNkyGUIZq6qwDVk9xbIo2EY61Jngd+bQJOTEzl6qE5QWFBAdA+2lGax7cY2 UDMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ma7Z8abY/APalx2o0UvySj4vyNrMPwt9pzqhU0V22fA=; b=fKzTioQIJegdTn6EIeMzb63NUuTlmrGjH3p8MnT+8YPruizylivaNfBZL3Qnq323MD 6lcHOlGI9j8Q8VciGuhdNnDOP4ESch0Kr3cS5Z8rnZHGppsqM010+p55BDNs4WdwIWHO +sOJ+yztwhoL/NQCX+QQPBk6ylU24LSrCWcQXGT91iG6W79q0dQAZeel3ZHO1ABF17wD OlgftPWI9zHuH8xobCmXylLlGkAoldSJasekPwc0squmXs310S+yeuKWII+5cUhce+CK 0z4Fc7LmVDxwu3p9RtJVDRg+viAWh6Qi7gompYhtQwnv9onDcgTw4cuQbQiIK++uFsQO EpnQ== X-Gm-Message-State: AMke39neegQT/wpcA0NFENn28q3+B1fnzowzkMFJ10t2ZbnWgUEWGGiLzE0QrqFjFJrTbjmbl6Nwg0BF2wHpvQ== X-Received: by 10.107.16.14 with SMTP id y14mr5541455ioi.164.1486681787680; Thu, 09 Feb 2017 15:09:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Thu, 9 Feb 2017 15:09:46 -0800 (PST) In-Reply-To: <20170209224851.2FB1B63666E6@rock.dv.isc.org> References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> From: Brian Dickson Date: Thu, 9 Feb 2017 15:09:46 -0800 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a113fece2d952b805482113d7 Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 23:09:50 -0000 --001a113fece2d952b805482113d7 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews wrote: > > In message <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com>, Ted Lemon > writes: > > > > On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote: > > > At the moment we have Ted saying that if you want privacy you MUST > > > also turn on DNSSEC validation and implement QNAME minimisation and > > > implement agressive negative caching (still a I-D). > > > > No, I am _not_ saying that. I am saying that an unsigned delegation > > doesn't help with privacy unless you also specially configure your local > > resolver, and if you are going to specially configure your local > > resolver, then there are several options for how to do that. The only > > reason you need DNSSEC is that if you specially configure your local > > resolver to lie, then DNSSEC validation will break that. If you aren't > > doing DNSSEC validation, you can say any old thing in your local resolver > > and the stub will believe it. > > Suppose a signed delegation for alt, to some widely operated, centrally managed servers (say, the arpa servers). Now suppose an unsigned delegation for some other name under alt, such as "foo.alt", to an empty zone on the same set of servers. The only difference here is where the unsigned delegation is, and what the scope of that delegation is. In this scenario, any local "foo.alt" can lie about the contents of "foo.alt", because it is outside of the secure delegation chain from the root. The only difference is that the delegation is not directly from the root. Any other name under "alt" would have its existence securely denied, unless and until a request for an insecure delegation was made and approved. Is there a problem with this scenario? > And a signed answer doesn't help unless the recursive server is > validating (so it can trust the NXDOMAIN) and has QNAME minimimistion > (to prevent *.alt leaking in the first place) and has agressive > negative caching (so the answer from the minimised QNAME query get > turned into a answer for *.alt). > > Now we can put QNAME minimisation into a server. > Now we can put the code to support agressive negative caching into a > server. > We can't force validation to be enabled. > > We need all three things for the privacy leakage to stop. Any two > alone doesn't stop it. > There's something I don't understand. In the case where the local namespace (in your email, that would be "alt", in my example above, that would be "foo.alt") is not configured, why does leaking matter? Obviously the real local use case is "won't work - broken config", and leaking is mostly moot. In the case where the local namespace is instantiated, the queries won't leak to the root, so privacy is assured. Are you saying that leakage when the local namespace is non-existent, is a/the issue? I don't agree, if that is what you are asserting. Queries for "rumplestiltskin.foo.alt" can't expect privacy, unless they are using a resolver specifically configured for "foo.alt". Note that defaulting to providing "empty.as112.arpa", and having the DNAME to "alt.empty.as112.arpa", would further actually accomplish privacy, without affecting the local instantiation of "foo.alt" via "foo.alt.empty.as112.arpa". Brian > > The alternative is to do a insecure delegation and build in a default > empty zone for alt. You then have to take steps to break the privacy > leak by disabling the empty zone. Additionally it works with all > existing servers if they just add a empty .alt zone. It doesn't > require validation to be enabled. > > It's the difference between defaulting private or not. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --001a113fece2d952b805482113d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews <marka@isc.org>= wrote:

In message <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com>, Ted Lemo= n writes:
>
> On Feb 9, 2017, at 3:45 PM, Mark Andrews <marka@isc.org> wrote:
> > At the moment we have Ted saying that if you want privacy you MUS= T
> > also turn on DNSSEC validation and implement QNAME minimisation a= nd
> > implement agressive negative caching (still a I-D).
>
> No, I am _not_ saying that.=C2=A0 =C2=A0I am saying that an unsigned d= elegation
> doesn't help with privacy unless you also specially configure your= local
> resolver, and if you are going to specially configure your local
> resolver, then there are several options for how to do that.=C2=A0 =C2= =A0The only
> reason you need DNSSEC is that if you specially configure your local > resolver to lie, then DNSSEC validation will break that.=C2=A0 =C2=A0I= f you aren't
> doing DNSSEC validation, you can say any old thing in your local resol= ver
> and the stub will believe it.


Suppose a signed delegatio= n for alt, to some widely operated, centrally managed servers (say, the arp= a servers).
Now suppose an unsigned delegation for some other nam= e under alt, such as "foo.alt", to an empty zone on the same set = of servers.

The only difference here is where the = unsigned delegation is, and what the scope of that delegation is.

In this scenario, any local "foo.alt" can lie abo= ut the contents of "foo.alt", because it is outside of the secure= delegation chain from the root.

The only differen= ce is that the delegation is not directly from the root.

Any other name under "alt" would have its existence secure= ly denied, unless and until a request for an insecure delegation was made a= nd approved.

Is there a problem with this scenario= ?
=C2=A0
And a signed answer doesn't help unless the recursive serve= r is
validating (so it can trust the NXDOMAIN) and has QNAME minimimistion
(to prevent *.alt leaking in the first place) and has agressive
negative caching (so the answer from the minimised QNAME query get
turned into a answer for *.alt).

Now we can put QNAME minimisation into a server.
Now we can put the code to support agressive negative caching into a server= .
We can't force validation to be enabled.

We need all three things for the privacy leakage to stop.=C2=A0 Any two
alone doesn't stop it.


There's something I don't understand.=C2=A0

=
In the case where the local namespace (in your email, that would be &q= uot;alt", in my example above, that would be "foo.alt") is n= ot configured, why does leaking matter? Obviously the real local use case i= s "won't work - broken config", and leaking is mostly moot.

In the case where the local namespace is instantiat= ed, the queries won't leak to the root, so privacy is assured.

Are you saying that leakage when the local namespace is no= n-existent, is a/the issue?

I don't agree, if = that is what you are asserting.
Queries for "rumplestiltskin= .foo.alt" can't expect privacy, unless they are using a resolver s= pecifically configured for "foo.alt".
Note that default= ing to providing "empty.as112.arpa", and having the DNAME to &quo= t;alt.empty.as112.arpa", would further actually accomplish privacy, wi= thout affecting the local instantiation of "foo.alt" via "fo= o.alt.empty.as112.arpa".

Brian
=C2= =A0

The alternative is to do a insecure delegation and build in a default
empty zone for alt.=C2=A0 You then have to take steps to break the privacy<= br> leak by disabling the empty zone.=C2=A0 Additionally it works with all
existing servers if they just add a empty .alt zone.=C2=A0 It doesn't require validation to be enabled.

It's the difference between defaulting private or not.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0INTERNET: marka@isc.org

--001a113fece2d952b805482113d7-- From nobody Thu Feb 9 15:28:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96580129CF8 for ; Thu, 9 Feb 2017 15:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 AngOxa_XfFUt for ; Thu, 9 Feb 2017 15:28:36 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F718129CFB for ; Thu, 9 Feb 2017 15:28:36 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id CC9D13493C7; Thu, 9 Feb 2017 23:28:33 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B770D160042; Thu, 9 Feb 2017 23:28:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A25AC16006C; Thu, 9 Feb 2017 23:28:33 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RKI7fIlUwBBi; Thu, 9 Feb 2017 23:28:33 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DA0F9160042; Thu, 9 Feb 2017 23:28:32 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0DE1B63669D6; Fri, 10 Feb 2017 10:28:30 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> In-reply-to: Your message of "Thu, 09 Feb 2017 18:07:08 -0500." Date: Fri, 10 Feb 2017 10:28:30 +1100 Message-Id: <20170209232830.0DE1B63669D6@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 23:28:38 -0000 In message , Ted Lemon writes: > How does a query for, e.g., super-s3kr1t.alt leak if your caching resolver > is doing qname minimization? Because QNAME minimization does not stop on NXDOMAIN. Too much broken stuff out there to stop on NXDOMAIN. The purpose of QNAME minimization is prevent leaking too much information about the qname to the parent zone. It does nothing to prevent leakage of the QNAME to the containing zone. For that to happen you need the other two conditions to be met. > On Thu, Feb 9, 2017 at 5:48 PM, Mark Andrews wrote: > > > > > In message <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com>, Ted Lemon > > writes: > > > > > > On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote: > > > > At the moment we have Ted saying that if you want privacy you MUST > > > > also turn on DNSSEC validation and implement QNAME minimisation and > > > > implement agressive negative caching (still a I-D). > > > > > > No, I am _not_ saying that. I am saying that an unsigned delegation > > > doesn't help with privacy unless you also specially configure your local > > > resolver, and if you are going to specially configure your local > > > resolver, then there are several options for how to do that. The only > > > reason you need DNSSEC is that if you specially configure your local > > > resolver to lie, then DNSSEC validation will break that. If you aren't > > > doing DNSSEC validation, you can say any old thing in your local resolver > > > and the stub will believe it. > > > > And a signed answer doesn't help unless the recursive server is > > validating (so it can trust the NXDOMAIN) and has QNAME minimimistion > > (to prevent *.alt leaking in the first place) and has agressive > > negative caching (so the answer from the minimised QNAME query get > > turned into a answer for *.alt). > > > > Now we can put QNAME minimisation into a server. > > Now we can put the code to support agressive negative caching into a > > server. > > We can't force validation to be enabled. > > > > We need all three things for the privacy leakage to stop. Any two > > alone doesn't stop it. > > > > The alternative is to do a insecure delegation and build in a default > > empty zone for alt. You then have to take steps to break the privacy > > leak by disabling the empty zone. Additionally it works with all > > existing servers if they just add a empty .alt zone. It doesn't > > require validation to be enabled. > > > > It's the difference between defaulting private or not. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > --94eb2c0c8e5cca568e0548210c07 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > >
How does a query for, e.g., super-s3kr1t.alt leak if your = > caching resolver is doing qname minimization?
a">
On Thu, Feb 9, 2017 at 5:48 PM, Mark Andr= > ews < ">marka@isc.org> wrote:
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> v class=3D"HOEnZb">

> In message < .com">12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com>, Ted Lemo= > n writes:
> >
> > On Feb 9, 2017, at 3:45 PM, Mark Andrews < sc.org">marka@isc.org> wrote:
> > > At the moment we have Ted saying that if you want privacy you MUS= > T
> > > also turn on DNSSEC validation and implement QNAME minimisation a= > nd
> > > implement agressive negative caching (still a I-D).
> >
> > No, I am _not_ saying that.=C2=A0 =C2=A0I am saying that an unsigned d= > elegation
> > doesn't help with privacy unless you also specially configure your= > local
> > resolver, and if you are going to specially configure your local
> > resolver, then there are several options for how to do that.=C2=A0 =C2= > =A0The only
> > reason you need DNSSEC is that if you specially configure your local r> > > resolver to lie, then DNSSEC validation will break that.=C2=A0 =C2=A0I= > f you aren't
> > doing DNSSEC validation, you can say any old thing in your local resol= > ver
> > and the stub will believe it.
>
>
And a signed answer doesn't help unless the recursive serve= > r is
> validating (so it can trust the NXDOMAIN) and has QNAME minimimistion
> (to prevent *.alt leaking in the first place) and has agressive
> negative caching (so the answer from the minimised QNAME query get
> turned into a answer for *.alt).
>
> Now we can put QNAME minimisation into a server.
> Now we can put the code to support agressive negative caching into a server= > .
> We can't force validation to be enabled.
>
> We need all three things for the privacy leakage to stop.=C2=A0 Any two
> alone doesn't stop it.
>
> The alternative is to do a insecure delegation and build in a default
> empty zone for alt.=C2=A0 You then have to take steps to break the privacy<= > br> > leak by disabling the empty zone.=C2=A0 Additionally it works with all
> existing servers if they just add a empty .alt zone.=C2=A0 It doesn't r> > require validation to be enabled.
>
> It's the difference between defaulting private or not.
>
> Mark
>
--
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2= > 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= > =A0INTERNET: marka@isc.org
>

> > --94eb2c0c8e5cca568e0548210c07-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 9 15:47:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD5312945D for ; Thu, 9 Feb 2017 15:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 GTZsoBPSQVae for ; Thu, 9 Feb 2017 15:47:41 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEB51288B8 for ; Thu, 9 Feb 2017 15:47:41 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id D31761FCAB6; Thu, 9 Feb 2017 23:47:32 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8613E160042; Thu, 9 Feb 2017 23:47:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6CC8B16006C; Thu, 9 Feb 2017 23:47:31 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8W2wv9sJT8Ml; Thu, 9 Feb 2017 23:47:31 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 58214160042; Thu, 9 Feb 2017 23:47:30 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D30AD6366A94; Fri, 10 Feb 2017 10:47:26 +1100 (EST) To: Brian Dickson From: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> In-reply-to: Your message of "Thu, 09 Feb 2017 15:09:46 -0800." Date: Fri, 10 Feb 2017 10:47:26 +1100 Message-Id: <20170209234726.D30AD6366A94@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 23:47:43 -0000 In message , Brian Dickson writes: > > On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews wrote: > > > > > In message <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com>, Ted Lemon > > writes: > > > > > > On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote: > > > > At the moment we have Ted saying that if you want privacy you MUST > > > > also turn on DNSSEC validation and implement QNAME minimisation and > > > > implement agressive negative caching (still a I-D). > > > > > > No, I am _not_ saying that. I am saying that an unsigned delegation > > > doesn't help with privacy unless you also specially configure your local > > > resolver, and if you are going to specially configure your local > > > resolver, then there are several options for how to do that. The only > > > reason you need DNSSEC is that if you specially configure your local > > > resolver to lie, then DNSSEC validation will break that. If you aren't > > > doing DNSSEC validation, you can say any old thing in your local resolver > > > and the stub will believe it. > > Suppose a signed delegation for alt, to some widely operated, centrally > managed servers (say, the arpa servers). All delegations from the root are signed as the root zone is signed. The difference is it a secure delegation (with DS record) or a insecure delegation (proof of non existance of the DS). I'd insecurely delegate alt to the root servers themselves. There is no point in spreading the leakage. > Now suppose an unsigned delegation for some other name under alt, such as > "foo.alt", to an empty zone on the same set of servers. > > The only difference here is where the unsigned delegation is, and what the > scope of that delegation is. > > In this scenario, any local "foo.alt" can lie about the contents of > "foo.alt", because it is outside of the secure delegation chain from the > root. > > The only difference is that the delegation is not directly from the root. > > Any other name under "alt" would have its existence securely denied, unless > and until a request for an insecure delegation was made and approved. > > Is there a problem with this scenario? It requires alt to be a registry. One of the point of this I-D is to get a namespace that doesn't have a registry. > > And a signed answer doesn't help unless the recursive server is > > validating (so it can trust the NXDOMAIN) and has QNAME minimimistion > > (to prevent *.alt leaking in the first place) and has agressive > > negative caching (so the answer from the minimised QNAME query get > > turned into a answer for *.alt). > > > > Now we can put QNAME minimisation into a server. > > Now we can put the code to support agressive negative caching into a > > server. > > We can't force validation to be enabled. > > > > We need all three things for the privacy leakage to stop. Any two > > alone doesn't stop it. > > > > > There's something I don't understand. > > In the case where the local namespace (in your email, that would be "alt", > in my example above, that would be "foo.alt") is not configured, why does > leaking matter? Obviously the real local use case is "won't work - broken > config", and leaking is mostly moot. > > In the case where the local namespace is instantiated, the queries won't > leak to the root, so privacy is assured. > > Are you saying that leakage when the local namespace is non-existent, is > a/the issue? Because when TPB go on a witch hunt for all users of xxxx.alt we don't want the root servers operators to be able to return the addresses. It's not a matter of if, just when. We have seen that happen too many times. > I don't agree, if that is what you are asserting. > Queries for "rumplestiltskin.foo.alt" can't expect privacy, unless they are > using a resolver specifically configured for "foo.alt". > Note that defaulting to providing "empty.as112.arpa", and having the DNAME > to "alt.empty.as112.arpa", would further actually accomplish privacy, > without affecting the local instantiation of "foo.alt" via > "foo.alt.empty.as112.arpa". A DNAME doesn't give privacy. You need QNAME minimisation with a qtype of DNAME instead of NS. > Brian > > > > > > The alternative is to do a insecure delegation and build in a default > > empty zone for alt. You then have to take steps to break the privacy > > leak by disabling the empty zone. Additionally it works with all > > existing servers if they just add a empty .alt zone. It doesn't > > require validation to be enabled. > > > > It's the difference between defaulting private or not. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > --001a113fece2d952b805482113d7 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > >


te">On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews < ref=3D"mailto:marka@isc.org" target=3D"_blank">marka@isc.org>= > wrote:
der-left:1px #ccc solid;padding-left:1ex">
=3D"h5">
> In message < .com">12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com>, Ted Lemo= > n writes:
> >
> > On Feb 9, 2017, at 3:45 PM, Mark Andrews < sc.org">marka@isc.org> wrote:
> > > At the moment we have Ted saying that if you want privacy you MUS= > T
> > > also turn on DNSSEC validation and implement QNAME minimisation a= > nd
> > > implement agressive negative caching (still a I-D).
> >
> > No, I am _not_ saying that.=C2=A0 =C2=A0I am saying that an unsigned d= > elegation
> > doesn't help with privacy unless you also specially configure your= > local
> > resolver, and if you are going to specially configure your local
> > resolver, then there are several options for how to do that.=C2=A0 =C2= > =A0The only
> > reason you need DNSSEC is that if you specially configure your local r> > > resolver to lie, then DNSSEC validation will break that.=C2=A0 =C2=A0I= > f you aren't
> > doing DNSSEC validation, you can say any old thing in your local resol= > ver
> > and the stub will believe it.
>

Suppose a signed delegatio= > n for alt, to some widely operated, centrally managed servers (say, the arp= > a servers).
Now suppose an unsigned delegation for some other nam= > e under alt, such as "foo.alt", to an empty zone on the same set = > of servers.

The only difference here is where the = > unsigned delegation is, and what the scope of that delegation is.
>
In this scenario, any local "foo.alt" can lie abo= > ut the contents of "foo.alt", because it is outside of the secure= > delegation chain from the root.

The only differen= > ce is that the delegation is not directly from the root.

v>
Any other name under "alt" would have its existence secure= > ly denied, unless and until a request for an insecure delegation was made a= > nd approved.

Is there a problem with this scenario= > ?
=C2=A0
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
">
>
And a signed answer doesn't help unless the recursive serve= > r is
> validating (so it can trust the NXDOMAIN) and has QNAME minimimistion
> (to prevent *.alt leaking in the first place) and has agressive
> negative caching (so the answer from the minimised QNAME query get
> turned into a answer for *.alt).
>
> Now we can put QNAME minimisation into a server.
> Now we can put the code to support agressive negative caching into a server= > .
> We can't force validation to be enabled.
>
> We need all three things for the privacy leakage to stop.=C2=A0 Any two
> alone doesn't stop it.


iv>There's something I don't understand.=C2=A0

= >
In the case where the local namespace (in your email, that would be &q= > uot;alt", in my example above, that would be "foo.alt") is n= > ot configured, why does leaking matter? Obviously the real local use case i= > s "won't work - broken config", and leaking is mostly moot. div>

In the case where the local namespace is instantiat= > ed, the queries won't leak to the root, so privacy is assured.
v>
Are you saying that leakage when the local namespace is no= > n-existent, is a/the issue?

I don't agree, if = > that is what you are asserting.
Queries for "rumplestiltskin= > .foo.alt" can't expect privacy, unless they are using a resolver s= > pecifically configured for "foo.alt".
Note that default= > ing to providing "empty.as112.arpa", and having the DNAME to &quo= > t;alt.empty.as112.arpa", would further actually accomplish privacy, wi= > thout affecting the local instantiation of "foo.alt" via "fo= > o.alt.empty.as112.arpa".

Brian
=C2= > =A0
r-left:1px #ccc solid;padding-left:1ex"> >
> The alternative is to do a insecure delegation and build in a default
> empty zone for alt.=C2=A0 You then have to take steps to break the privacy<= > br> > leak by disabling the empty zone.=C2=A0 Additionally it works with all
> existing servers if they just add a empty .alt zone.=C2=A0 It doesn't r> > require validation to be enabled.
>
> It's the difference between defaulting private or not.
>
> Mark
>
--
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2= > 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= > =A0INTERNET: marka@isc.org
>

> > --001a113fece2d952b805482113d7-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 9 16:28:13 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BAA1294EE for ; Thu, 9 Feb 2017 16:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOr2o3UzvcRB for ; Thu, 9 Feb 2017 16:28:10 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E5A12967E for ; Thu, 9 Feb 2017 16:28:09 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id k15so20662780qtg.3 for ; Thu, 09 Feb 2017 16:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4zuhjAfaq/wU+GuF+hFxEcKrtIUvGjlz7ug1QHKImfQ=; b=DNWP7Qz1I6W9spNPLz9ABBJ8FoulEG3eG2CPjdyXlJMhcwn+Tc14eUWzi2ogIRv2fu OQJugTOL68M59+f+Dri9WHOHSC1c82RSU2k9JD013yJXFC2SkmjhrpVtcMqGbM8lmyuz dB+morftlIUBb1cvGIUlT+qyjXhiwZUf6T39DlC3fTejkNlqZjnWm5jWZ4AFihVpisGp qyimto/HlYgg1Zb8IgRphL0akWnse9bU1U+U0GSUCUz3UGVqmcq8QVReA47+A70sAVdr ss82/tDX2+xrBBF03nIbdbMIuUiUmlDwaHyoIy/gfE6C6f5pJdx9sbAK6k6J1S4K7al/ h27g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4zuhjAfaq/wU+GuF+hFxEcKrtIUvGjlz7ug1QHKImfQ=; b=FnMNmDG9PTHk5n64FoX+1YkniOMd0BC58cluuiDaEjklabjwSL2V6RHHpCVkYMAkwj UdLB7DcYagP/ByF6q+IFDcr5JcMRZ/Adklu83B55CLjWPxnVvfURxyj9r1ldaXuUoWn3 3EXpVtdAbWfWLvJ46kDYZjBK3vfTbf01T9zrDnHSPejGgRyeWzwNVRmQqm7iciuk2Trh H6TDLtU9vPF66+gtXD4rwj3W2risIOsYmAioV2qdfh1YsuwC3EbTbR2f903L9VcCgaOO ZAugSSOo3ufie/haU0k+Zwox6bP3+6orzOkYaJAiGn7S04+x0ySDGkNCHJLAwtzx/u/A HtPA== X-Gm-Message-State: AMke39kh6W0zSzeFH6W/liArl6UAUlxxVYMSuoxmrSY7x2UOOV5DGRBPLPnXUIv68ArN+w== X-Received: by 10.200.55.178 with SMTP id d47mr6030875qtc.60.1486686488784; Thu, 09 Feb 2017 16:28:08 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 23sm10644094qtp.20.2017.02.09.16.28.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 16:28:07 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C5C01EA4-EA9B-4343-843C-6E5AD0E9AC32" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 19:28:05 -0500 In-Reply-To: <20170209232830.0DE1B63669D6@rock.dv.isc.org> To: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209232830.0DE1B63669D6@rock.dv.isc.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 00:28:12 -0000 --Apple-Mail=_C5C01EA4-EA9B-4343-843C-6E5AD0E9AC32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2017, at 6:28 PM, Mark Andrews wrote: > Because QNAME minimization does not stop on NXDOMAIN. Too much > broken stuff out there to stop on NXDOMAIN. The purpose of QNAME > minimization is prevent leaking too much information about the qname > to the parent zone. It does nothing to prevent leakage of the QNAME > to the containing zone. Er, maybe I don't understand qname minimization correctly. My = understanding is that the way it works is that the recursive resolver = does not forward the entire query up the chain: it just forwards the bit = it needs resolved to answer the next question. So, if you ask for = foo.alt, the resolver should first ask for "." (except it probably = already has it), and then "alt.", which will return an NXDOMAIN. So it = will never ask anybody for foo.alt, because it has no-one to ask. --Apple-Mail=_C5C01EA4-EA9B-4343-843C-6E5AD0E9AC32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 9, 2017, at 6:28 PM, Mark Andrews <marka@isc.org> = wrote:
Because QNAME minimization does not stop on = NXDOMAIN.  Too much
broken stuff out there to stop on = NXDOMAIN.  The purpose of QNAME
minimization is prevent leaking = too much information about the qname
to the parent zone.  It = does nothing to prevent leakage of the QNAME
to the containing = zone.

Er, = maybe I don't understand qname minimization correctly.   My = understanding is that the way it works is that the recursive resolver = does not forward the entire query up the chain: it just forwards the bit = it needs resolved to answer the next question.   So, if you ask for = foo.alt, the resolver should first ask for "." (except it probably = already has it), and then "alt.", which will return an NXDOMAIN.   = So it will never ask anybody for foo.alt, because it has no-one to = ask.

= --Apple-Mail=_C5C01EA4-EA9B-4343-843C-6E5AD0E9AC32-- From nobody Thu Feb 9 16:40:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0174B1295DF for ; Thu, 9 Feb 2017 16:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4yxuc8qb1JJ for ; Thu, 9 Feb 2017 16:40:24 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 B1ADA129512 for ; Thu, 9 Feb 2017 16:40:24 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id j13so38943567iod.3 for ; Thu, 09 Feb 2017 16:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gM2Kbst1J6++MBow0sKWvbGeOei0JXYUKJ3q1FLk05o=; b=Ult8rgJlejlKtMi5Lvx4ivGI/GVxSvNQgckwOQopPpF49QGFWgxYHbvMR/dxesEwOp UanzNXHcP0zHF7HHQglZX5puOn7YTAz0UMjmYrcygnlEbRYUwBwCXcRAeevNyU3jIeHH U6EFsxlc/NbJo/nqMP603/hwLJrVPO/qW9hkzGzx0qNJpZPhoK6Mkg/7X+62+kREvffJ LlsJEpM3AMNzq2RxTLg//k9ghblm6YknqMuT1m67xP1O2pnAV5ubqwSCcv500oPvDsNo biPac1+Ko6TIISoPoeRLebH7WSGvoXRfbKFnWQiYijkG/M963OT/+si2e/AT9w4Qe/Tj DQXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gM2Kbst1J6++MBow0sKWvbGeOei0JXYUKJ3q1FLk05o=; b=Nf9JOq7qPahDMi86W4nyNcf2ks2Da8qWIkP7Mq7QkVWtcC8OuDRhBSHriDSZz8HOAE yOMP1ikcqIu8jKYKZqPFRy9dxyfm4NwaFHJO4GG7MmGS9XZ8dvA9lOHhB0b5XBgYxP5d CJXbE86ITgRdjGkb0SpgspBckxDr5tzqci5bAE3lePDpZavlKMt3dhpV5+rSXz8F6Hzf kSOEDxQgmEDcG3hasYCKojRHtCzRzmIQpt9vE0suttzw9XgJlG60ugaQfsjheYLs94LH 8Le6NrrGMINRoBvCY9czkn2HWK0y5eqvKJgXLE3j9ATsRjrXEQgahXvChj+GcAWJbwPS yQoA== X-Gm-Message-State: AMke39ntc3/aOXCGh201chtc68FCvW0/6cLfk8ApPUKNsZYCPaY6JjWdh2jrns7aEYhLikv3boYU0LZvSdn+xA== X-Received: by 10.107.149.18 with SMTP id x18mr5876059iod.167.1486687224105; Thu, 09 Feb 2017 16:40:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Thu, 9 Feb 2017 16:40:23 -0800 (PST) In-Reply-To: <20170209234726.D30AD6366A94@rock.dv.isc.org> References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209234726.D30AD6366A94@rock.dv.isc.org> From: Brian Dickson Date: Thu, 9 Feb 2017 16:40:23 -0800 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a1140fee4e29498054822576c Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 00:40:26 -0000 --001a1140fee4e29498054822576c Content-Type: text/plain; charset=UTF-8 On Thu, Feb 9, 2017 at 3:47 PM, Mark Andrews wrote: > > In message 54SLpw@mail.gmail.com> > , Brian Dickson writes: > > > Are you saying that leakage when the local namespace is non-existent, is > > a/the issue? > > Because when TPB go on a witch hunt for all users of xxxx.alt we > don't want the root servers operators to be able to return the > addresses. It's not a matter of if, just when. We have seen that > happen too many times. > I'm not sure who "TPB" is, but... If you really care about privacy, IMHO, the place to instantiate the private namespace, is under one of the heavily used AS112 zones. E.g. 10.in-addr.arpa, or 168.192.in-addr.arpa. It's unsigned, by default (for BIND) local already, and even if a leak occurs, it will be hiding among the sheer volume of crap. Plus, having the AS112 decentralization applied, means any incidental leakage is going to be nearly impossible to find. Using a new TLD for local use-cases that do want to be in a privately forked piece or the global namespace, is perhaps unwise. One thing to consider: the client will not know whether the resolver has leaked or not. Maybe this should be a DPRIVE topic, rather than general dnsop? Brian --001a1140fee4e29498054822576c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 9, 2017 at 3:47 PM, Mark Andrews <marka@isc.org>= wrote:

In message <CAH1iCiqi_xJjwXvsR-x76fcz20NiugnjYqameK1ZH= Wd+54SLpw@mail.gmail.com>
, Brian Dickson writes:

> Are you saying that leakage when the local namespace is non-existent, = is
> a/the issue?

Because when TPB go on a witch hunt for all users of xxxx.alt we
don't want the root servers operators to be able to return the
addresses.=C2=A0 It's not a matter of if, just when.=C2=A0 We have seen= that
happen too many times.

I'm not sure= who "TPB" is, but...

If you really care= about privacy, IMHO, the place to instantiate the private namespace, is un= der one of the heavily used AS112 zones.

E.g. 10.i= n-addr.arpa, or 168.192.in-addr.arpa.

It's uns= igned, by default (for BIND) local already, and even if a leak occurs, it w= ill be hiding among the sheer volume of crap.
Plus, having the AS= 112 decentralization applied, means any incidental leakage is going to be n= early impossible to find.

Using a new TLD for loca= l use-cases that do want to be in a privately forked piece or the global na= mespace, is perhaps unwise.

One thing to consider:= the client will not know whether the resolver has leaked or not.

Maybe this should be a DPRIVE topic, rather than general dn= sop?

Brian
--001a1140fee4e29498054822576c-- From nobody Thu Feb 9 16:48:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D0F129DD4 for ; Thu, 9 Feb 2017 16:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 bFylYkDddyYf for ; Thu, 9 Feb 2017 16:48:08 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2DA8129DD1 for ; Thu, 9 Feb 2017 16:48:07 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 57E453493C7; Fri, 10 Feb 2017 00:48:06 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 423C0160076; Fri, 10 Feb 2017 00:48:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2ADCA16006C; Fri, 10 Feb 2017 00:48:06 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xcblxq5BDeCH; Fri, 10 Feb 2017 00:48:06 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B8AF1160042; Fri, 10 Feb 2017 00:48:05 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EEFE9636B89C; Fri, 10 Feb 2017 11:48:01 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209232830.0DE1B63669D6@rock.dv.isc.org> In-reply-to: Your message of "Thu, 09 Feb 2017 19:28:05 -0500." Date: Fri, 10 Feb 2017 11:48:01 +1100 Message-Id: <20170210004801.EEFE9636B89C@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 00:48:09 -0000 In message , Ted Lemon writes: > > On Feb 9, 2017, at 6:28 PM, Mark Andrews wrote: > > Because QNAME minimization does not stop on NXDOMAIN. Too much > > broken stuff out there to stop on NXDOMAIN. The purpose of QNAME > > minimization is prevent leaking too much information about the qname > > to the parent zone. It does nothing to prevent leakage of the QNAME > > to the containing zone. > > Er, maybe I don't understand qname minimization correctly. My > understanding is that the way it works is that the recursive resolver > does not forward the entire query up the chain: it just forwards the bit > it needs resolved to answer the next question. So, if you ask for > foo.alt, the resolver should first ask for "." (except it probably > already has it), and then "alt.", which will return an NXDOMAIN. So it > will never ask anybody for foo.alt, because it has no-one to ask. No, it will ask for foo.alt because: 1) there is too much brokeness out there that returns NXDOMAIN instead of a NODATA for a ENT. 2) the cache don't have a DNSSEC proof of non existence for foo.alt without also having agressive negative caching (code and configuration) and the answer for alt having validated as a secure NXDOMAIN. QNAME minimisation prevents the root learning about foo.com because there is a delegation for com in the root zone. This does not apply for foo.alt. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 9 17:15:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B864D129553 for ; Thu, 9 Feb 2017 17:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mGtW5byxEJf for ; Thu, 9 Feb 2017 17:15:36 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 957F41295C8 for ; Thu, 9 Feb 2017 17:15:36 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id v23so21527987qtb.0 for ; Thu, 09 Feb 2017 17:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jOV+rhijElkf4kVfmsnrtq1SB9AGGLl+JuDokWpAQa8=; b=RE23ZHj79pFPHfugHGNpEutpVKFZYzwsaoM8V6AcLxqJvNxImbacwJOqd+XbUT6DDB nHTLYmtdgFT1JfxfL6lmKgAWLesiKjos5cgnVbERI3yvVaXswT9eg21xPx9NLryLKtA1 Kl5BFuzZinbh/cg/t3CcUQlI2cIXV1WIvzejF8ZyQPgB0my/Jx7duHyzv3b7Zkg5MCsL Yn0ifbe+DK3sUwYND+kGwU7UeGYezDa75dFFiDoU88eJtknerDYbNWBHgSVXL9BU74Bn r1UmmQ/StCLAJ//RwJjdDj2Y0DcTa++VIBsKTg8NAPB88e8OCsGrkj5uuhMasr3THNkW Em/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jOV+rhijElkf4kVfmsnrtq1SB9AGGLl+JuDokWpAQa8=; b=dHbfKjUL+4mgvWWbffmchVGXoWiMygF9UjWWLFgWGztxTawoDmyOrniByTfzyOJBFy clcQx1s2q+hf2YxWTMaoTZW3XQNhaZ2cA0TxLpPKIrrf7sLTy+OUiWsZFX26E0soVnYe CeDQ5pwhfY8TT2gd0LzxiUod19hUP6kJbtyHT/GuPpIfj+FNs/AvOzwBNpG0dVOPlQTS MGmFEgSBf9bYeDmOqDufIyAf2Nxi4nr32hf3KVbEKVkUDT2hTttW5i9AxnDlz3+4tL6m g7NtMTrJpSrrn1WqZFdY7X4pqVYuA614sTCoDUWdJoG/rpvYi1E4NUmSe2zRzRR5skOx v4vw== X-Gm-Message-State: AMke39npxQwNllZ5td66PPkuJ3PdW7OXL7KKQ2wEEISM1MVWyZYfjs+o5fJ0CVseF+SwIw== X-Received: by 10.237.37.58 with SMTP id v55mr6030098qtc.15.1486689335758; Thu, 09 Feb 2017 17:15:35 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id f35sm52927qtb.49.2017.02.09.17.15.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 17:15:34 -0800 (PST) From: Ted Lemon Message-Id: <653A3403-DFC8-491A-B083-7873D1886A12@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C090C60D-F1E2-4D80-938C-036F9E94569B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 20:15:32 -0500 In-Reply-To: <20170210004801.EEFE9636B89C@rock.dv.isc.org> To: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209232830.0DE1B63669D6@rock.dv.isc.org> <20170210004801.EEFE9636B89C@rock.dv.isc.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 01:15:39 -0000 --Apple-Mail=_C090C60D-F1E2-4D80-938C-036F9E94569B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2017, at 7:48 PM, Mark Andrews wrote: > 1) there is too much brokeness out there that returns NXDOMAIN instead = of > a NODATA for a ENT. So you're saying that a root nameserver is going to return an incorrect = result? And what does this have to do with intelligent trees?= --Apple-Mail=_C090C60D-F1E2-4D80-938C-036F9E94569B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 9, 2017, at 7:48 PM, Mark Andrews <marka@isc.org> = wrote:
1) there is too much brokeness out there that = returns NXDOMAIN instead of
  a NODATA for a = ENT.

So = you're saying that a root nameserver is going to return an incorrect = result?   And what does this have to do with intelligent = trees?
= --Apple-Mail=_C090C60D-F1E2-4D80-938C-036F9E94569B-- From nobody Thu Feb 9 17:57:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549DD12965D for ; Thu, 9 Feb 2017 17:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 Cd7YovQSZK_C for ; Thu, 9 Feb 2017 17:57:34 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFC112965B for ; Thu, 9 Feb 2017 17:57:34 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 1A7E91FCAB3; Fri, 10 Feb 2017 01:57:31 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AFE7016006C; Fri, 10 Feb 2017 01:57:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 95C21160055; Fri, 10 Feb 2017 01:57:29 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ksaHGJhqASwX; Fri, 10 Feb 2017 01:57:29 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id F334C160042; Fri, 10 Feb 2017 01:57:28 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BF777636C97F; Fri, 10 Feb 2017 12:57:25 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209232830.0DE1B63669D6@rock.dv.isc.org> <20170210004801.EEFE9636B89C@rock.dv.isc.org> <653 A3403-DFC8-491A-B083-7873D1886A12@fugue.com> In-reply-to: Your message of "Thu, 09 Feb 2017 20:15:32 -0500." <653A3403-DFC8-491A-B083-7873D1886A12@fugue.com> Date: Fri, 10 Feb 2017 12:57:25 +1100 Message-Id: <20170210015725.BF777636C97F@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 01:57:35 -0000 In message <653A3403-DFC8-491A-B083-7873D1886A12@fugue.com>, Ted Lemon writes: > > On Feb 9, 2017, at 7:48 PM, Mark Andrews wrote: > > 1) there is too much brokeness out there that returns NXDOMAIN instead > > of a NODATA for a ENT. > > So you're saying that a root nameserver is going to return an incorrect > result? And what does this have to do with intelligent trees? I'm developing software that will be run on private internets with various degrees of compentence from the adminitrators as well as the public Internet. That private internet may have a ENT for ALT that returns NXDOMAIN. The server has to work in that environment. So NXDOMAIN doesn't stop the query. Even with everything working properly QNAME minimisation DOES NOT STOP THE QUERIES. RFC 4035 + RFC 7816 -> leaks (synthesis of negative answers is banned by RFC 4035) RFC 4035 + RFC 7816 + ANC supported by the code w/o validation -> leaks RFC 4035 + RFC 7816 + ANC supported by the code + validation -> no leaks Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 9 18:04:34 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21B8129667 for ; Thu, 9 Feb 2017 18:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.881 X-Spam-Level: X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 y2KiRJT_BYr9 for ; Thu, 9 Feb 2017 18:04:31 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6A4129662 for ; Thu, 9 Feb 2017 18:04:31 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 737F7349422; Fri, 10 Feb 2017 02:04:29 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 64FDE160042; Fri, 10 Feb 2017 02:04:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 468F516006C; Fri, 10 Feb 2017 02:04:29 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q1rMpSv6-Itx; Fri, 10 Feb 2017 02:04:29 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9B813160042; Fri, 10 Feb 2017 02:04:28 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 79016636CA12; Fri, 10 Feb 2017 13:04:25 +1100 (EST) From: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209232830.0DE1B63669D6@rock.dv.isc.org> <20170210004801.EEFE9636B89C@rock.dv.isc.org> <653 A3403-DFC8-491A-B083-7873D1886A12@fugue.com> <20170210015725.BF777636C97F@rock.dv.isc.org> In-reply-to: Your message of "Fri, 10 Feb 2017 12:57:25 +1100." <20170210015725.BF777636C97F@rock.dv.isc.org> Date: Fri, 10 Feb 2017 13:04:25 +1100 Message-Id: <20170210020425.79016636CA12@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 02:04:33 -0000 In message <20170210015725.BF777636C97F@rock.dv.isc.org>, Mark Andrews writes: > > In message <653A3403-DFC8-491A-B083-7873D1886A12@fugue.com>, Ted Lemon writes: > > > > On Feb 9, 2017, at 7:48 PM, Mark Andrews wrote: > > > 1) there is too much brokeness out there that returns NXDOMAIN instead > > > of a NODATA for a ENT. > > > > So you're saying that a root nameserver is going to return an incorrect > > result? And what does this have to do with intelligent trees? > > I'm developing software that will be run on private internets with > various degrees of compentence from the adminitrators as well as > the public Internet. That private internet may have a ENT for ALT > that returns NXDOMAIN. The server has to work in that environment. > > So NXDOMAIN doesn't stop the query. > > Even with everything working properly QNAME minimisation DOES NOT > STOP THE QUERIES. > > RFC 4035 + RFC 7816 -> leaks (synthesis of negative answers is banned by RFC 4035) > RFC 4035 + RFC 7816 + ANC supported by the code w/o validation -> leaks > RFC 4035 + RFC 7816 + ANC supported by the code + validation -> no leaks And to complete the table RFC 4035 + ANC supported by the code + validation -> leaks (no queries for alt) > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 9 18:54:44 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E66F129683 for ; Thu, 9 Feb 2017 18:54:42 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 nvcqh-DO0F0u for ; Thu, 9 Feb 2017 18:54:41 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C88E12968C for ; Thu, 9 Feb 2017 18:44:55 -0800 (PST) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 3FAB174001F for ; Fri, 10 Feb 2017 02:44:55 +0000 (UTC) Received: from [192.168.1.228] (73.167.64.188) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 9 Feb 2017 18:44:54 -0800 From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_F030304D-E773-4493-8A86-C372A21102A6" MIME-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 21:44:53 -0500 References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209232830.0DE1B63669D6@rock.dv.isc.org> <20170210004801.EEFE9636B89C@rock.dv.isc.org> <653 A3403-DFC8-491A-B083-7873D1886A12@fugue.com> <20170210015725.BF777636C97F@rock.dv.isc.org> To: "dnsop@ietf.org WG" In-Reply-To: <20170210015725.BF777636C97F@rock.dv.isc.org> Message-ID: X-Mailer: Apple Mail (2.3259) X-Originating-IP: [73.167.64.188] Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 02:54:42 -0000 --Apple-Mail=_F030304D-E773-4493-8A86-C372A21102A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Feb 9, 2017, at 8:57 PM, Mark Andrews wrote: > I'm developing software that will be run on private internets with > various degrees of compentence from the adminitrators as well as > the public Internet. That private internet may have a ENT for ALT > that returns NXDOMAIN. The server has to work in that environment. I don't know what an ENT is. In any case, I don't see what this has to = do with what we are talking about. It is an absolute fact that if you = want ALT queries not to leak you need to have a specially-configured = recursive resolver, or else one that is really quite up to date. If = you have one that is really quite up to date, a secure denial of = existence will do the right thing. So we are really just arguing about how to specially configure = out-of-date resolvers. This is really out of scope. There is nothing = dnsop can do to make sure that these queries do not leak, so we should = just decide what the right design is assuming that all the moving parts = are working correctly, and leave it at that. --Apple-Mail=_F030304D-E773-4493-8A86-C372A21102A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" On Feb 9, 2017, at 8:57 PM, Mark Andrews <marka@isc.org> = wrote:
I'm developing software that will be run on = private internets with
various degrees of compentence from the = adminitrators as well as
the public Internet.  That private = internet may have a ENT for ALT
that returns NXDOMAIN.  The = server has to work in that = environment.

I don't know what an ENT is.   In any case, I don't see = what this has to do with what we are talking about.   It is an = absolute fact that if you want ALT queries not to leak you need to have = a specially-configured recursive resolver, or else one that is really = quite up to date.   If you have one that is really quite up to = date, a secure denial of existence will do the right thing.

So we are really just = arguing about how to specially configure out-of-date resolvers.   = This is really out of scope.   There is nothing dnsop can do to = make sure that these queries do not leak, so we should just decide what = the right design is assuming that all the moving parts are working = correctly, and leave it at that.

= --Apple-Mail=_F030304D-E773-4493-8A86-C372A21102A6-- From nobody Thu Feb 9 20:48:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1574129FA5 for ; Thu, 9 Feb 2017 20:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 bL1YA_iSoDgK for ; Thu, 9 Feb 2017 20:47:59 -0800 (PST) Received: from mail-ua0-x248.google.com (mail-ua0-x248.google.com [IPv6:2607:f8b0:400c:c08::248]) (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 3B1D1129FA9 for ; Thu, 9 Feb 2017 20:47:57 -0800 (PST) Received: by mail-ua0-x248.google.com with SMTP id f2so14918681uaf.2 for ; Thu, 09 Feb 2017 20:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FMECZJt7dGrkDmbkM/3mQ+Ydy9LHBKUJYFXJEohH3WY=; b=EK4+zRApS2aEcXZTNN3e0vkZhhEukKqfMD3wsbJX+PC/IIJKe/C/bXJ0r7IHbdNgh+ KY9KMDt62/c4c10FXHkc98STruKwGAaIJmiyhW6gubPvxht5Cc+n2iZFT1KV4FA7njHi /Q9KmmY0TCe1d4Jn386IOzeHOrr8sBC12oqGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FMECZJt7dGrkDmbkM/3mQ+Ydy9LHBKUJYFXJEohH3WY=; b=K90k3dsBnARXACBCD1mYvNWXJ3QG52WEKPpdcm0k2Ltee/ZH7EfSuoxoxpVlEyPcnD Ch0C9fTsOaWX/zZo3u4I0tNoWjEiZql0Ns8I147vdu7wudSt+Tp8+gGKY7zwT3e0q21n lwz4ilrFPS3QouOsrH8cKJEyULMcFXeDyI6VaSk/JjJmQQMiNP3EKdaxO435Xjho49gA dvQcg/oFR3t5IvMmllAMkxcep8pQS2kzWVVGHsQseOWINM1MZATwiiVt82ItOybATvOE iBkkTfidLrmH+H1XTQGt54/yLK+hBCaXiIODeBXrkkASmqMeGKEp/NNoqBIVImOLrjsJ APOQ== X-Gm-Message-State: AMke39nt2wsr2qYaeHRkVUQkWX3LJMD/IUlAljb5MVYoYcU58C35eJOC94P8D75k5hmyt2U648Cs7LwXBW4/0XGH X-Received: by 10.176.23.81 with SMTP id k17mr3625944uaf.99.1486702076200; Thu, 09 Feb 2017 20:47:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.5.131 with HTTP; Thu, 9 Feb 2017 20:47:35 -0800 (PST) In-Reply-To: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> From: Richard Gibson Date: Thu, 9 Feb 2017 23:47:35 -0500 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=f40304361f32239ace054825cd3d Archived-At: Cc: dnsop@ietf.org, i-d-announce@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 04:48:01 -0000 --f40304361f32239ace054825cd3d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable With full realization that this is coming very late in the game, we had a great deal of internal conversation within Dyn about implementing refuse-any, and came away unsatisfied with both the "subset" and "HINFO" approaches=E2=80=94the latter because of reasons that have already been cov= ered, and the former for lacking in-band signaling of non-"conventional" incompleteness to aid legitimate use. I believe there is sufficient cause to reserve a new OPT record EDNS header flag bit for indicating "partial response" (as distinct from "truncation"). It will be safely ignored by current clients, but convey the desired information to those in the know. P.S. Our discussion also raised some more minor points: - Insisting that the HINFO OS field SHOULD be empty ("set to the null string") seems a little too strong; there's room in it for (and value from) a short explanation (e.g., cloudflare.com. 3789 IN HINFO "Please stop asking for ANY" "See draft-ietf-dnsop-refuse-any"). I'd prefer text like "The OS field of the HINFO RDATA SHOULD be short to minimize the si= ze of the response, and MAY be empty or MAY include a summarized description of local policy." - "Conventional [ANY] response" is used but not defined. - "ANY does not mean ALL" is misleading=E2=80=94RFC 1035 is clear about QTYPE=3D255 being "a request for *all* records" (emphasis mine). That said, the proposed *response* behavior is consistent with that RFC. On Thu, Feb 9, 2017 at 12:56 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the IET= F. > > Title : Providing Minimal-Sized Responses to DNS Querie= s > that have QTYPE=3DANY > Authors : Joe Abley > Olafur Gudmundsson > Marek Majkowski > Filename : draft-ietf-dnsop-refuse-any-04.txt > Pages : 10 > Date : 2017-02-08 > > Abstract: > The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". > The operator of an authoritative DNS server might choose not to > respond to such queries for reasons of local policy, motivated by > security, performance or other reasons. > > The DNS specification does not include specific guidance for the > behaviour of DNS servers or clients in this situation. This document > aims to provide such guidance. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-refuse-any-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --f40304361f32239ace054825cd3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With full realization that this is coming very late in the= game, we had a great deal of internal conversation within Dyn about implem= enting refuse-any, and came away unsatisfied with both the "subset&quo= t; and "HINFO" approaches=E2=80=94the latter because of reasons t= hat have already been covered, and the former for lacking in-band signaling= of non-"conventional" incompleteness to aid legitimate use.
=
I believe there is sufficient cause to reserve a new OPT rec= ord EDNS header flag bit for indicating "pa= rtial response" (as distinct from "truncation"). It will be = safely ignored by current clients, but convey the desired information to th= ose in the know.

P.S. Our discussion also raised som= e more minor points:
  • Insisting that=C2=A0the=C2=A0HINFO OS field SHOULD be empty ("set to the null string"= ;) seems a little too strong; there's room=C2=A0in=C2=A0it for (and value from) a short=C2=A0explanation (e.g.,=C2=A0cloudflare.com. 3789 IN HINFO "Please stop asking for ANY= " "See draft-ietf-dnsop-refuse-any"). I'd prefer text like "The=C2=A0OS field of=C2=A0the=C2=A0HINFO RDATA SHOULD= be short to minimize=C2=A0the=C2=A0size of=C2=A0the=C2=A0response, and MAY be empty or MAY include a = summarized description of local policy."
  • "Conventi= onal [ANY] response" is used but not defined.
  • "ANY does n= ot mean ALL" is misleading=E2=80=94RFC= 1035=C2=A0is clear about QTYPE=3D255 = being "a request=C2=A0for=C2=A0al= l=C2=A0records" (emphasis mine). = That said, the=C2=A0proposed=C2=A0response=C2=A0be= havior is consistent with that RFC.

On Thu, Feb 9, 2017 at= 12:56 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Providing Minimal-Sized Responses to DNS Queries that have QTYPE=3DANY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Joe = Abley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Olafur Gudmundsson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Marek Majkowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-refuse-any-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-02-08

Abstract:
=C2=A0 =C2=A0The Domain Name System (DNS) specifies a query type (QTYPE) &q= uot;ANY".
=C2=A0 =C2=A0The operator of an authoritative DNS server might choose not t= o
=C2=A0 =C2=A0respond to such queries for reasons of local policy, motivated= by
=C2=A0 =C2=A0security, performance or other reasons.

=C2=A0 =C2=A0The DNS specification does not include specific guidance for t= he
=C2=A0 =C2=A0behaviour of DNS servers or clients in this situation.=C2=A0 T= his document
=C2=A0 =C2=A0aims to provide such guidance.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-dnsop-refuse-any/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ie= tf-dnsop-refuse-any-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-dnsop-refuse-any-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--f40304361f32239ace054825cd3d-- From nobody Thu Feb 9 22:02:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13BD129473 for ; Thu, 9 Feb 2017 22:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 lTYix3SOxVQJ for ; Thu, 9 Feb 2017 22:02:19 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0C412948A for ; Thu, 9 Feb 2017 22:02:18 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3F9FB3494AC; Fri, 10 Feb 2017 06:02:15 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2940F160055; Fri, 10 Feb 2017 06:02:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0CF9D160076; Fri, 10 Feb 2017 06:02:15 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 607ESyBXWE25; Fri, 10 Feb 2017 06:02:14 +0000 (UTC) Received: from rock.dv.isc.org (pa49-195-77-168.pa.nsw.optusnet.com.au [49.195.77.168]) by zmx1.isc.org (Postfix) with ESMTPSA id 9B0A3160042; Fri, 10 Feb 2017 06:02:14 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 704E56371DBB; Fri, 10 Feb 2017 16:07:01 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209232830.0DE1B63669D6@rock.dv.isc.org> <20170210004801.EEFE9636B89C@rock.dv.isc.org> <653 A3403-DFC8-491A-B083-7873D1886A12@fugue.com> <20170210015725.BF777636C97F@rock.dv.isc.org> In-reply-to: Your message of "Thu, 09 Feb 2017 21:44:53 -0500." Date: Fri, 10 Feb 2017 16:07:01 +1100 Message-Id: <20170210050701.704E56371DBB@rock.dv.isc.org> Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 06:02:21 -0000 In message , Ted Lemon writes : > > On Feb 9, 2017, at 8:57 PM, Mark Andrews wrote: > > I'm developing software that will be run on private internets with > > various degrees of compentence from the adminitrators as well as > > the public Internet. That private internet may have a ENT for ALT > > that returns NXDOMAIN. The server has to work in that environment. > > I don't know what an ENT is. Empty Non Terminal which is a quite common acronym in this group. > In any case, I don't see what this has to do with what we are talking > about. It is an absolute fact that if you want ALT queries not to leak > you need to have a specially-configured recursive resolver, Pray tell what specially-configured recursive resolver works? > or else one that is really quite up to date. Actually one from the future. We don't have a RFC that say to perform agressive negative caching. > If you have one that is really quite > up to date, a secure denial of existence will do the right thing. Only if you also validate. You are putting the "you can play bar" for privacy at the ceiling. > So we are really just arguing about how to specially configure > out-of-date resolvers. This is really out of scope. There is nothing > dnsop can do to make sure that these queries do not leak, so we should > just decide what the right design is assuming that all the moving parts > are working correctly, and leave it at that. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 9 22:23:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82501296FC for ; Thu, 9 Feb 2017 22:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHXFtT-5hWV3 for ; Thu, 9 Feb 2017 22:23:27 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 B2CD61298A6 for ; Thu, 9 Feb 2017 22:23:26 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id n124so15566599lfd.2 for ; Thu, 09 Feb 2017 22:23:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IoP4qGY615VLUz5t4F5AdCToSUGD2k45fsP2oAGvzHk=; b=VEc8WZfgVWmXNmoNTRB7G4XYosdtudCAgEaExC3nd1S/cJ2AAYEqruC83f+HOOJT9/ n67UeEO77N+HNGHMNID72QT5El8IvZZDoK+xfb6BlpgWJT/qQtwXWRrAlb0RVb/0rflz AlGm3wHXVNYCv2UJNHIH1sXKaTGco5Hp0zITdss47wk3C33x9b4mveFN0BlLFr+bOWJs 7DiVyExkd+QEPD01xdeYMyNT4BS40i7OgTF5+tgQG5TDaVJjd88h7JbwFoZnz2IM//1j 6A8D7ImR77nNbygInkTEEvzP9yBvhjPMnxBzdhaMEdbopVvZfHhckAXXK4ku9MzJVZl3 DY+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IoP4qGY615VLUz5t4F5AdCToSUGD2k45fsP2oAGvzHk=; b=Z62mv6+J8OPsy7Dp98X5q/1PyUVXUKuvW/SORSMTOQ/4bZ7oazKVNM0lzUHEyWmrKD BFMKQnsLmmm0e27NQjQWTkeOvswhAQ6k6+GeAcoM10d0PKjk0Ih6XSsETTiVjkLcqzCP nvcJICsJTcBNW2ktLEAEbnPpm/jsV2EZqXT9ySGnoqKeK2bypH21hqSaByoyx3b5qV+J v21YEQKMpp1xyD+OSU7hCxH1TsyIfVx8OxzCvrLdrWwx9/1stiUzdzTZPtz+SAiabYgL e/zYkyR2PkA7czVtovxXBgPDighTLLLXtleMB/0eOycRgFtOBavJZvWhOa9B4LlJ5WP7 ExnA== X-Gm-Message-State: AMke39nDZOFLocSy//P+eD1vNPDTEMQPzlhO8v45hiXkbTpHfKZj3RKJdArNM4TckY/ZX2QTr3+mU/vuIR0kJQ== X-Received: by 10.46.69.215 with SMTP id s206mr2651127lja.26.1486707804974; Thu, 09 Feb 2017 22:23:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.20.67 with HTTP; Thu, 9 Feb 2017 22:23:23 -0800 (PST) Received: by 10.25.20.67 with HTTP; Thu, 9 Feb 2017 22:23:23 -0800 (PST) In-Reply-To: <20170210050701.704E56371DBB@rock.dv.isc.org> References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209232830.0DE1B63669D6@rock.dv.isc.org> <20170210004801.EEFE9636B89C@rock.dv.isc.org> <20170210015725.BF777636C97F@rock.dv.isc.org> <20170210050701.704E56371DBB@rock.dv.isc.org> From: Ted Lemon Date: Fri, 10 Feb 2017 01:23:23 -0500 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a114b162899d0e505482722be Archived-At: Cc: dnsop WG , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 06:23:29 -0000 --001a114b162899d0e505482722be Content-Type: text/plain; charset=UTF-8 Could your concern be addressed with secure denial of existence plus the right text about how to configure recursive resolvers? On Feb 10, 2017 1:02 AM, "Mark Andrews" wrote: > > In message , Ted Lemon > writes > : > > > > On Feb 9, 2017, at 8:57 PM, Mark Andrews wrote: > > > I'm developing software that will be run on private internets with > > > various degrees of compentence from the adminitrators as well as > > > the public Internet. That private internet may have a ENT for ALT > > > that returns NXDOMAIN. The server has to work in that environment. > > > > I don't know what an ENT is. > > Empty Non Terminal which is a quite common acronym in this group. > > > In any case, I don't see what this has to do with what we are talking > > about. It is an absolute fact that if you want ALT queries not to leak > > you need to have a specially-configured recursive resolver, > > Pray tell what specially-configured recursive resolver works? > > > or else one that is really quite up to date. > > Actually one from the future. We don't have a RFC that say to perform > agressive negative caching. > > > If you have one that is really quite > > up to date, a secure denial of existence will do the right thing. > > Only if you also validate. > > You are putting the "you can play bar" for privacy at the ceiling. > > > So we are really just arguing about how to specially configure > > out-of-date resolvers. This is really out of scope. There is nothing > > dnsop can do to make sure that these queries do not leak, so we should > > just decide what the right design is assuming that all the moving parts > > are working correctly, and leave it at that. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a114b162899d0e505482722be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Could your concern be addressed with secure denial of exi= stence plus the right text about how to configure recursive resolvers?

On Feb 10, 2017 = 1:02 AM, "Mark Andrews" <mark= a@isc.org> wrote:

In message <E5AB0A08-0DDA-496A-811E-25C1BA2765BA@nominum.com>, Ted = Lemon writes
:
>
> On Feb 9, 2017, at 8:57 PM, Mark Andrews <marka@isc.org> wrote:
> > I'm developing software that will be run on private internets= with
> > various degrees of compentence from the adminitrators as well as<= br> > > the public Internet.=C2=A0 That private internet may have a ENT f= or ALT
> > that returns NXDOMAIN.=C2=A0 The server has to work in that envir= onment.
>
> I don't know what an ENT is.

Empty Non Terminal which is a quite common acronym in this group.

>=C2=A0 =C2=A0In any case, I don't see what this has to do with what= we are talking
> about.=C2=A0 =C2=A0It is an absolute fact that if you want ALT queries= not to leak
> you need to have a specially-configured recursive resolver,

Pray tell what specially-configured recursive resolver works?

> or else one that is really quite up to date.

Actually one from the future.=C2=A0 We don't have a RFC that say to per= form
agressive negative caching.

> If you have one that is really quite
> up to date, a secure denial of existence will do the right thing.

Only if you also validate.

You are putting the "you can play bar" for privacy at the ceiling= .

> So we are really just arguing about how to specially configure
> out-of-date resolvers.=C2=A0 =C2=A0This is really out of scope.=C2=A0 = =C2=A0There is nothing
> dnsop can do to make sure that these queries do not leak, so we should=
> just decide what the right design is assuming that all the moving part= s
> are working correctly, and leave it at that.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0INTERNET: marka@isc.org

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--001a114b162899d0e505482722be-- From nobody Fri Feb 10 00:56:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D687129490 for ; Fri, 10 Feb 2017 00:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 roULTd_KzIsZ for ; Fri, 10 Feb 2017 00:56:17 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D4D129410 for ; Fri, 10 Feb 2017 00:56:17 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id EAF7D2807EC; Fri, 10 Feb 2017 09:56:14 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id E32182807B6; Fri, 10 Feb 2017 09:56:14 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id E0266B38027; Fri, 10 Feb 2017 09:55:44 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id DD1474008E; Fri, 10 Feb 2017 09:55:44 +0100 (CET) Date: Fri, 10 Feb 2017 09:55:44 +0100 From: Stephane Bortzmeyer To: Mark Andrews Message-ID: <20170210085544.cdo73hdr32lzbkw4@nic.fr> References: <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170209195722.DC1AB636586C@rock.dv.isc.org> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: Ted Lemon , "dnsop@ietf.org WG" , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 08:56:19 -0000 On Fri, Feb 10, 2017 at 06:57:22AM +1100, Mark Andrews wrote a message of 40 lines which said: > Only if you are willing to break lookups for names where there are > missing delegations in parent zone and the parent and child zones > share the same nameservers or the nameserver just misimplements ENT > or the nameserver implements RFC 2535 NXDOMAIN (ENT don't exist > with RFC 2535). All of these result in NXDOMAIN for ENT. Funny, I did not expect *you* to claim we have to accomodate broken name servers :-) From nobody Fri Feb 10 00:59:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3479129493 for ; Fri, 10 Feb 2017 00:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 FEkhp_imL6vh for ; Fri, 10 Feb 2017 00:59:17 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA39129410 for ; Fri, 10 Feb 2017 00:59:16 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 6AD622807EC; Fri, 10 Feb 2017 09:59:15 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 64C992807B6; Fri, 10 Feb 2017 09:59:15 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 6330EB38003; Fri, 10 Feb 2017 09:58:45 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 5D0C84008E; Fri, 10 Feb 2017 09:58:45 +0100 (CET) Date: Fri, 10 Feb 2017 09:58:45 +0100 From: Stephane Bortzmeyer To: Mark Andrews Message-ID: <20170210085845.674cshyx7rclhhdd@nic.fr> References: <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170209224851.2FB1B63666E6@rock.dv.isc.org> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 08:59:17 -0000 On Fri, Feb 10, 2017 at 09:48:51AM +1100, Mark Andrews wrote a message of 43 lines which said: > and has agressive negative caching (so the answer from the minimised > QNAME query get turned into a answer for *.alt). As I already said here, if by "agressive negative caching", you mean draft-ietf-dnsop-nsec-aggressiveuse, then the above sentence is *false*. RFC 8020 is enough to "turn the answer from the minimised QNAME query to a answer for *.alt". [And I would really like to see BIND implement it.] From nobody Fri Feb 10 01:11:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10B11294FB for ; Fri, 10 Feb 2017 01:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 wQlGs_8hLWem for ; Fri, 10 Feb 2017 01:11:25 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82FC1294B9 for ; Fri, 10 Feb 2017 01:11:25 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 50EBA2807EC; Fri, 10 Feb 2017 10:11:24 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 4AD1D2807B6; Fri, 10 Feb 2017 10:11:24 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 48889B3800C; Fri, 10 Feb 2017 10:10:54 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 40CAE4008E; Fri, 10 Feb 2017 10:10:54 +0100 (CET) Date: Fri, 10 Feb 2017 10:10:54 +0100 From: Stephane Bortzmeyer To: Mark Andrews Message-ID: <20170210091054.ubhlgmbprwcosx4h@nic.fr> References: <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209232830.0DE1B63669D6@rock.dv.isc.org> <20170210004801.EEFE9636B89C@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170210004801.EEFE9636B89C@rock.dv.isc.org> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 09:11:26 -0000 On Fri, Feb 10, 2017 at 11:48:01AM +1100, Mark Andrews wrote a message of 36 lines which said: > No, it will ask for foo.alt because: This is false (and Ted Lemon was correct in describing QNAME minimisation). Here, with a recent Unbound, when I ping foo.alt, I see only: 09:05:55.233366 IP6 2001:4b98:dc2:43:216:3eff:fea9:41a.64146 > 2a01:4f8:161:6106:1::10.53: 36407% [1au] A? alt. (32) If, afterwards, I ping bar.alt, there is no outgoing DNS request (this is because of "NXDOMAIN cut"). > QNAME minimisation prevents the root learning about foo.com because > there is a delegation for com in the root zone. This does not apply > for foo.alt. This does not seem true. From nobody Fri Feb 10 01:15:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D831294B9 for ; Fri, 10 Feb 2017 01:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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-k78RKCb6wi for ; Fri, 10 Feb 2017 01:15:11 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1380E129410 for ; Fri, 10 Feb 2017 01:15:11 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id A701C2807EC; Fri, 10 Feb 2017 10:15:09 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id A0F3E2807B6; Fri, 10 Feb 2017 10:15:09 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 9F21AB3800C; Fri, 10 Feb 2017 10:14:39 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 98F5C4008E; Fri, 10 Feb 2017 10:14:39 +0100 (CET) Date: Fri, 10 Feb 2017 10:14:39 +0100 From: Stephane Bortzmeyer To: Brian Dickson Message-ID: <20170210091439.ow5dgowffir3xagt@nic.fr> References: <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209234726.D30AD6366A94@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 09:15:12 -0000 On Thu, Feb 09, 2017 at 04:40:23PM -0800, Brian Dickson wrote a message of 78 lines which said: > If you really care about privacy, IMHO, the place to instantiate the > private namespace, is under one of the heavily used AS112 zones. [...] > even if a leak > occurs, it will be hiding among the sheer volume of crap. > Plus, having the AS112 decentralization applied, means any incidental > leakage is going to be nearly impossible to find. This was proposed in draft-bortzmeyer-dname-root. But read its Security considerations section: not everyone agrees that leaking to AS112 is harmless. From nobody Fri Feb 10 01:27:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34F6129518 for ; Fri, 10 Feb 2017 01:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 2YfG2QEp5zpR for ; Fri, 10 Feb 2017 01:27:14 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014631294CA for ; Fri, 10 Feb 2017 01:27:14 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 7C47B2807EC; Fri, 10 Feb 2017 10:27:12 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 761162807B6; Fri, 10 Feb 2017 10:27:12 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 73E22B3800C; Fri, 10 Feb 2017 10:26:42 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 706B74008E; Fri, 10 Feb 2017 10:26:42 +0100 (CET) Date: Fri, 10 Feb 2017 10:26:42 +0100 From: Stephane Bortzmeyer To: Mark Andrews Message-ID: <20170210092642.w3rl7tyn5g46trj2@nic.fr> References: <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com> <20170209204506.BC40D6365CBE@rock.dv.isc.org> <12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue.com> <20170209224851.2FB1B63666E6@rock.dv.isc.org> <20170209232830.0DE1B63669D6@rock.dv.isc.org> <20170210004801.EEFE9636B89C@rock.dv.isc.org> <653A3403-DFC8-491A-B083-7873D1886A12@fugue.com> <20170210015725.BF777636C97F@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170210015725.BF777636C97F@rock.dv.isc.org> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "dnsop@ietf.org WG" , Ted Lemon , Brian Dickson Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 09:27:15 -0000 On Fri, Feb 10, 2017 at 12:57:25PM +1100, Mark Andrews wrote a message of 29 lines which said: > Even with everything working properly QNAME minimisation DOES NOT > STOP THE QUERIES. > > RFC 4035 + RFC 7816 -> leaks (synthesis of negative answers is banned by RFC 4035) RFC 4035 (if more security needed, but it is not *necessary*) + RFC 7816 + RFC 8020 -> no leaks From nobody Fri Feb 10 04:52:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EFA1296A3 for ; Fri, 10 Feb 2017 04:52:21 -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] 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 TaYhcjfyFt3S for ; Fri, 10 Feb 2017 04:52:19 -0800 (PST) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A50129637 for ; Fri, 10 Feb 2017 04:52:19 -0800 (PST) Received: from [192.168.137.1] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 98774C1B96; Fri, 10 Feb 2017 13:52:16 +0100 (CET) From: "Peter van Dijk" To: dnsop@ietf.org Date: Fri, 10 Feb 2017 13:52:16 +0100 Message-ID: In-Reply-To: References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> <54C32FCA-8248-441A-9D44-9EEFEB1F00E5@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5344) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 12:52:21 -0000 Hello Ray, On 6 Jan 2017, at 23:02, Ray Bellis wrote: > On 06/01/2017 18:43, Wessels, Duane wrote: > >> The idea of "X-Forwarded-For" for DNS makes me nervous, but it is >> probably inevitable. >> >> It is of course quite similar to EDNS client subnet, except that >> there is no masking and the client cannot opt-out. Might be worth >> saying in your document why EDNS client subnet wouldn't work for this >> purpose. > > I believe that dnsdist / PowerDNS is already (ab)using the ECS option > for this purpose. > > The intent in part is to provide a separate option so that "real" ECS > can pass unhindered. [ not that I think ECS is a good idea, but some > folks want it, c'est la vie ] Indeed, dnsdist uses ECS to pass the actual client IP to the real backend DNS server. And indeed, this gets confusing when there is also ‘real’ ECS. So thank you for writing this draft, it will be very useful! However, both in ECS, and now in XPF, we do not get client’s port number. With increasing CGNAT deployment, this makes it impossible to distinguish clients once a request has passed through a proxy, like dnsdist or a TLS frontend. Can you please consider adding a port number field? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Fri Feb 10 05:12:35 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF121297EA for ; Fri, 10 Feb 2017 05:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 RSbhSvJjMlcz for ; Fri, 10 Feb 2017 05:12:32 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8751296F8 for ; Fri, 10 Feb 2017 05:12:31 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 10 Feb 2017 05:12:29 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Fri, 10 Feb 2017 05:12:29 -0800 From: Edward Lewis To: Paul Hoffman , "dnsop@ietf.org" Thread-Topic: [Ext] [DNSOP] A nudge on the new terms in draft-ietf-dnsop-terminology-bis Thread-Index: AQHSglLSM9FEBIFpVU6ShiTd1bkEtaFibE8A Date: Fri, 10 Feb 2017 13:12:28 +0000 Message-ID: <310D014B-1B3F-420C-A411-DEF6A67016D5@icann.org> References: <390DDFE7-E70F-4E4E-96AB-AECFE25672E0@vpnc.org> In-Reply-To: <390DDFE7-E70F-4E4E-96AB-AECFE25672E0@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3569559150_1770826219" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] A nudge on the new terms in draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 13:12:34 -0000 --B_3569559150_1770826219 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 2/8/17, 16:31, "DNSOP on behalf of Paul Hoffman" wrote: > The authors have tentatively made some substantial changes to the draft, to define "domain name" I have a fundamental problem with that, meaning that a document within DNSOP is defining domain names. Work I did to write (the still in progress) draft on Domain Names has led me to believe that domain names are a concept beyond the DNS protocol. On the other hand, the DNS protocol and operators of it, deserve to have a definition in place, so I'm not totally convinced this is a bad idea. Diving into the definition contained in the draft though, it needs work. Referring to: https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04, for "Domain Name" and "Label" : ) Domain name: An ordered list of zero or more labels. ) Label: An ordered list of zero or more octets and which makes up a portion of a domain name. This is a circular definition which makes it quite meaningless. E.g., "A is a string of B's" and "B is a component of A." I don't have a suggested fix. In as much as this isn't worth the paper you are reading this on, I've been trying to find time to update my draft on Domain Names, including, for now, rules on what would make a good definition. I only mention this to express my frustration over not having something better to offer. The closest I have to a suggestion is to put any definition of Domain Name in a DNS terminology document strictly in the context of documentation on the DNS protocol, at least for now. --B_3569559150_1770826219 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUTLxustV7ytIA0eqI qfz+baf5tAIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw MjEwMTMxMjMwWjANBgkqhkiG9w0BAQEFAASCAQASAScj6z5B71BBbwGTYyqTiVHMEL6tPJN4 nK9rImQBDnarm8BsxDxuVqGD51jBMKPSqYck0V5hgf7fbR15RQ8SoIMOwKExj0ofiZXyEakt uID8JZbPugW1w7Osly8H6wDH+9xnK716JJzCfAlVGwr17Rx7E1bVJeZKZ22PPivTV+uE2grP /INMBmdpGbwo6Bam5Q1VG9t7f3lIerTH1pNFvtOSc1EibJoDr+P8YuTszTLUBy0b2KOnjrnk XzTh0PLHWJdpjW6j6LJhzZKNv6cMUImoQpPUvYuOqlEcJRcmM+OJfAiGi0BnMho4K476o5KZ isoqhDdfwmmNCDWXdzvf --B_3569559150_1770826219-- From nobody Fri Feb 10 05:12:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16DB1298BC for ; Fri, 10 Feb 2017 05:12:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 cp47SnaQtT0x for ; Fri, 10 Feb 2017 05:12:47 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD7B1298C1 for ; Fri, 10 Feb 2017 05:12:46 -0800 (PST) Received: from [46.227.151.81] (port=52943 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1ccB0F-0004un-TV (Exim 4.72) for dnsop@ietf.org (return-path ); Fri, 10 Feb 2017 13:12:43 +0000 To: dnsop@ietf.org References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> <54C32FCA-8248-441A-9D44-9EEFEB1F00E5@verisign.com> From: Ray Bellis Message-ID: <3a687531-932a-c88b-8f9c-2d8ca4df0433@bellis.me.uk> Date: Fri, 10 Feb 2017 13:12:45 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 13:12:49 -0000 On 10/02/2017 12:52, Peter van Dijk wrote: > However, both in ECS, and now in XPF, we do not get client’s port > number. With increasing CGNAT deployment, this makes it impossible to > distinguish clients once a request has passed through a proxy, like > dnsdist or a TLS frontend. > > Can you please consider adding a port number field? I see where you're coming from, but I'm not inclined to add it (yet) for a couple of reasons: 1. CGNAT is evil ;-) 2. If I add this, then folks will want other transport related fields (indeed I already had at least one other person suggest this). Are the server side ACLs etc that need to be able to identify the client so fine grained that they'd really give different treatment to different clients arriving from the same CGN IP address? This is probably something that the WG should consider if (or hopefully when) this becomes a WG item. kind regards, Ray From nobody Fri Feb 10 05:26:06 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6071298BC for ; Fri, 10 Feb 2017 05:26:04 -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] 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 Ra0rXy7YLYqn for ; Fri, 10 Feb 2017 05:26:03 -0800 (PST) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7A81296F8 for ; Fri, 10 Feb 2017 05:26:03 -0800 (PST) Received: from [192.168.137.1] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id BBAF2C1B96; Fri, 10 Feb 2017 14:26:01 +0100 (CET) From: "Peter van Dijk" To: dnsop@ietf.org Date: Fri, 10 Feb 2017 14:26:00 +0100 Message-ID: In-Reply-To: <3a687531-932a-c88b-8f9c-2d8ca4df0433@bellis.me.uk> References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> <54C32FCA-8248-441A-9D44-9EEFEB1F00E5@verisign.com> <3a687531-932a-c88b-8f9c-2d8ca4df0433@bellis.me.uk> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5344) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 13:26:04 -0000 Hello Ray, On 10 Feb 2017, at 14:12, Ray Bellis wrote: > On 10/02/2017 12:52, Peter van Dijk wrote: > >> Can you please consider adding a port number field? > > I see where you're coming from, but I'm not inclined to add it (yet) > for > a couple of reasons: > > 1. CGNAT is evil ;-) You have my full agreement on that! However, it is also a reality that we have to deal with today. > 2. If I add this, then folks will want other transport related fields > (indeed I already had at least one other person suggest this). I suggest weighing every such request individually - saying yes to ports is no reason to say yes to something else :) > Are the server side ACLs etc that need to be able to identify the > client > so fine grained that they'd really give different treatment to > different > clients arriving from the same CGN IP address? Sadly, yes. In ISP networks, there may be policy differences per subscriber, and given CGNAT the DNS server can only identify the subscribers by their IP+port. > This is probably something that the WG should consider if (or > hopefully > when) this becomes a WG item. I encourage WG adoption in any case! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Fri Feb 10 09:08:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09AC129A57 for ; Fri, 10 Feb 2017 09:08:03 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=OThijt1X; dkim=pass (1024-bit key) header.d=yitter.info header.b=WsZj7aij 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 1m7QuA7_1RY8 for ; Fri, 10 Feb 2017 09:08:02 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8791D129A50 for ; Fri, 10 Feb 2017 09:08:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id E0777BD554 for ; Fri, 10 Feb 2017 17:08:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1486746481; bh=iDtM8goTzH5zVo+hSW/S8uEg3ukn7FZjQYYbG9JE6cA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=OThijt1X2eQHFRWnNlMMjGxm/UjPhCbLzuFaVtiPYYcDG9rSfm38TUbEg7kKw6tG3 2gzjMiBM/T8k+ipcJo4Fert4T62Vs7vkVUuMBtanL+Yl+iTp4xRxzqSRInetDD9RyD CxGuoGy9obizcf+rPvFI8rGIRjmQdZOxnGYrb/O0= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxg2lHfF4kP7 for ; Fri, 10 Feb 2017 17:08:00 +0000 (UTC) Date: Fri, 10 Feb 2017 12:07:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1486746480; bh=iDtM8goTzH5zVo+hSW/S8uEg3ukn7FZjQYYbG9JE6cA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=WsZj7aijKbZBmuodw476mP3COuQoYbwzTVPO+uc/e0CL3Izmq2vc0v6Rd+xlRNsNN 5dXRSjcthU0sY9xQnbw/zv6tqAzPVraP9aQWRV6w5zbwaSGqbGmGqqmg5I2U0sIHd/ 0amih7zt3cjZ3HbGTLA76YEBJG1sNXQYWfPMZ6bQ= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170210170758.GD91545@mx4.yitter.info> References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <20170208052544.862956356F33@rock.dv.isc.org> <20170208060208.8C8E1635864D@rock.dv.isc.org> <20170208194208.DB02C635DD72@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 17:08:04 -0000 On Wed, Feb 08, 2017 at 12:36:23PM -0800, Brian Dickson wrote: > So, while technically the instruction (SHOULD NOT) applies to full .onion > names, > it is a SHOULD NOT, not a MUST NOT. Note also that the original request was that it be a MUST NOT, and some of us tried to explain that RFCs do not actually determine what people may do and it's the Internet, and so you couldn't make a requirement in one RFC that would be guaranteed to be implemented by those who don't implement that RFC. Which means that the restricton is a stupid one. The result was a compromise in which it says "SHOULD NOT". In this case, the pretty good reason not to implement the restriction is that the Internet doesn't work the way the people who wanted onion to work thought it did. Any name under alt -- which is, rememeber, _supposed_ to be the protocol switch in the way Warren and I originally were thinking -- should never get looked up in the global DNS. If it does, that's because someone is trying to use a name that contains right in itself an indication that it needs an alternative resolution context, and not having that resolution context available. It might be that such a computer will erroneously fall back on the global DNS. That's not a reason for us to do contortions in the specification. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Feb 10 09:31:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AE6129A64 for ; Fri, 10 Feb 2017 09:31:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=XVgT5sDF; dkim=pass (1024-bit key) header.d=yitter.info header.b=HVQjynzx 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 mXhp5vJkcjPI for ; Fri, 10 Feb 2017 09:31:28 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F972129A5B for ; Fri, 10 Feb 2017 09:31:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 80472BD554 for ; Fri, 10 Feb 2017 17:31:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1486747887; bh=8LNT99nLpPTub95unaQb4yqCWPgcI5X+3X4yJUsCXYI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=XVgT5sDFbJRgYWTc7HlHE2SBOowheKZZr3UzBEKn6UrnGdvZ1tpViYvFkP5RQeRQT YRW9uaqN4UjM3htOqafELEafwHdF9ozQUyUkxhk7aCrxkeIvrHhCmV30iTrRvAFiUv ChhewKDoxBW5j9oW5OvqWD3LbgE/jTF3MuuMwmaY= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdc0zMfMwKZ9 for ; Fri, 10 Feb 2017 17:31:26 +0000 (UTC) Date: Fri, 10 Feb 2017 12:31:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1486747886; bh=8LNT99nLpPTub95unaQb4yqCWPgcI5X+3X4yJUsCXYI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HVQjynzxx1ZP6bsk+5C2h3xqSt/Rw2dL2fvAne7ebUOMOEf1+cdV7OJmcKVPcr35a L9vNL+NWybVztoja0KhZbm7n57PTmVBqBAcR7V7HXkfPnzF93Dic/Len72t9f5stFm q0z5Vn2gt1htKFzl+W0F0CLroIJZZSM5ZGFfRCKQ= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170210173124.GF91545@mx4.yitter.info> References: <20170203210922.7286C618213C@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 17:31:29 -0000 On Tue, Feb 07, 2017 at 10:01:23AM -0500, Bob Harold wrote: > What I envision for the future is an insecure delegation of .alt, and an > option in future cable modems to enable a local "homenet.alt" domain, which > would just work, even if some stub resolvers in the house are validating. > The cable modem is already a recursive resolver or forwarder, and dhcp > server, so it seems a logical place for the local domain. No, it won't just work if a stub is validating, because the validating stub will want to validate the delegation from the parent, and that will be a proof of non-existence. Provable non-existence prevents you from being poisoned through typosquatting, but it means you can't inject things in the tree without co-operation from the parent. This is part of why I don't want to extend alt this way, and the more I think about it the less desirable it seems to me. We have a particular problem: non-DNS-protocol switching for applications that want to use a DNS-compatible domain name slot (see RFC 5890). This is problems like onion, local, and so on. We propose a solution in which we steal four of the available 255 octets to create a "safe" space from DNS delegation. Now anyone can use that space for their non-DNS protocol, and every resolver library in the world knows that if it runs into a name in the alt tree it shouldn't need to look it up in DNS. If the query leaks to the root and gets a proof of non-existence, it doesn't matter because it was supposed to be a different protocol. Non-existence in the DNS is analytically true. If a validating resolver gets an answer back from another resolver that provides NXDOMAIN without the proof of non-existence and treats the result as bogus instead, who cares? It was never supposed to resolve in the DNS anyway. The homenet case is different, because it _is_ supposed to work with DNS. In that case, the missing proofs are a problem for validating end points. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Feb 10 10:25:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65564129A88 for ; Fri, 10 Feb 2017 10:25:52 -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 EWg0jwnQ80aD for ; Fri, 10 Feb 2017 10:25:51 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0233A129A80 for ; Fri, 10 Feb 2017 10:25:50 -0800 (PST) Received: (qmail 65252 invoked from network); 10 Feb 2017 18:25:50 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Feb 2017 18:25:50 -0000 Date: 10 Feb 2017 18:25:28 -0000 Message-ID: <20170210182528.24266.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: <20170210173124.GF91545@mx4.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: ajs@anvilwalrusden.com Subject: Re: [DNSOP] solving a problem by creating a worse problem, ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 18:25:52 -0000 >> What I envision for the future is an insecure delegation of .alt, and an >> option in future cable modems to enable a local "homenet.alt" domain, which >> would just work, even if some stub resolvers in the house are validating. >> The cable modem is already a recursive resolver or forwarder, and dhcp >> server, so it seems a logical place for the local domain. > >No, it won't just work if a stub is validating, because the validating >stub will want to validate the delegation from the parent, and that >will be a proof of non-existence. ... Yeah. It seems to me that if we want DNSSEC to work for locally served DNS subtrees, we need some way to distribute trust anchors for the subtrees to those cable modems. While that is probably not an insoluble problem, it is not one that I would plan to solve any time soon, so it's one I would prefer to address separately. >This is part of why I don't want to extend alt this way, and the more >I think about it the less desirable it seems to me. We have a >particular problem: non-DNS-protocol switching for applications that >want to use a DNS-compatible domain name slot (see RFC 5890). Agreed. Say that you can do anything you want with .ALT (duh) but you SHOULD NOT resolve .ALT names via the DNS protocol because of the DNSSEC problems. To minimize leakage, we can use the tools we already have: qname minimization, local mirrors of the root, and special casing in DNS caches as many now do for .onion. R's, John From nobody Fri Feb 10 10:41:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A091129A6A for ; Fri, 10 Feb 2017 10:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMvxR6a2EdYR for ; Fri, 10 Feb 2017 10:41:08 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 B4C9E12958B for ; Fri, 10 Feb 2017 10:41:08 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id v23so43166494qtb.0 for ; Fri, 10 Feb 2017 10:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ATRbMOUBVtSSPihqQqOcZ6+fe2Iy3N+cocu+extz3OQ=; b=Z0mIH64J0Sua7emRtuKNj1EVEsrY77Ufo7jpkOtP04Yq9Z+3A7xrvxwpkj3m25mdjJ g2X/KtnOvyTtG9c2/HCqzTiY1KMOL6av8xvPfRRZmYuOrcn0gkpXIprRk7jeubVEJcGE VIR9UN7ltrfCCyIYorTWb4PSTFZJ3DYLOaaldbPCa0UQjFjBAyIG0LbwOqySQLmd74d6 87NK2h6sXqhfxM35Us2StjtvAsTIuCgAwWFxaJ34oLG67qwQke28Bv3RtWXXxjzY3IE/ RuxytjbKK14jtJnrG2FeV9msYmUBDDM7yj+Plpso9sZYFAuHbRBBca/PhURUjOImSyrh SjQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ATRbMOUBVtSSPihqQqOcZ6+fe2Iy3N+cocu+extz3OQ=; b=jc+lCVYN+stYPc7I0jPakivwZ7mZrgzfHNfj+qyk9oA9kgx2SYNyusX4k8hS6o6QXm S27z4Y+rQjtRja2MLPcAu/clMtBPHR4IgbIbEWJ5UCWr4rPTZ/hq9SPj5lDbUJAyTjU9 1c/wUaP6cHtRtIEyPwa/cXHlSyGHW73aMxf/5SHTDRkwmAxu3omeXZxP8Yu65quuZnZ4 3ykzCGFN58zVNM+6fHR3stgq6m39m+AQCUDyDbmxcnqfTLUq4RZc0XnIYWOyVrHQDPcQ qWlwUark41DKsUanBzicebHpnf6skb5t/o48Z6bG0iPV35iv+j8bJXmvTVkd0eutQnIj GBHw== X-Gm-Message-State: AMke39mfgPqkfbFEh8VLz31t8qCicloqnVwFgQpIOl6aNwVYLXrqkTF2iFHYtdf3aNPwpA== X-Received: by 10.237.42.69 with SMTP id k5mr9190344qtf.214.1486752067673; Fri, 10 Feb 2017 10:41:07 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:1df9:8cfe:58cb:dd3c? ([2601:181:c381:c20:1df9:8cfe:58cb:dd3c]) by smtp.gmail.com with ESMTPSA id p7sm2126915qtf.47.2017.02.10.10.41.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Feb 2017 10:41:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <20170210182528.24266.qmail@ary.lan> Date: Fri, 10 Feb 2017 13:41:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8B15DBEA-8E72-421F-A2D2-9EE5B35D8E35@gmail.com> References: <20170210182528.24266.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dnsop Subject: Re: [DNSOP] solving a problem by creating a worse problem, ALT-TLD and (insecure) delgations. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 18:41:10 -0000 Hi, The editors hold the token on text for this, but it seems to me that the = discussion has started going in circles. A number of arguments have been made, and in some cases repeated. = Let=E2=80=99s assume the editors have heard them and try to restrict = followups to new observations, questions, or arguments. > On Feb 10, 2017, at 1:25 PM, John Levine wrote: >=20 >> This is part of why I don't want to extend alt this way, and the more >> I think about it the less desirable it seems to me. We have a >> particular problem: non-DNS-protocol switching for applications that >> want to use a DNS-compatible domain name slot (see RFC 5890). >=20 > Agreed. Say that you can do anything you want with .ALT (duh) but you > SHOULD NOT resolve .ALT names via the DNS protocol because of the > DNSSEC problems. To minimize leakage, we can use the tools we already > have: qname minimization, local mirrors of the root, and special > casing in DNS caches as many now do for .onion. This sounds reasonable to me. Suzanne From nobody Fri Feb 10 10:44:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CD8129A85 for ; Fri, 10 Feb 2017 10:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 3cdkphoER4sU for ; Fri, 10 Feb 2017 10:44:18 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 5EF68129A6F for ; Fri, 10 Feb 2017 10:44:18 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id o16so114569230wra.1 for ; Fri, 10 Feb 2017 10:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tsZt7BigDkZl8k8ZM/5Oe9crtyJcU/TLkT6LuM00Kiw=; b=oxzKk9HLPFztgPQu4R0xTuvhMlQZJ40Hca04hiL9WwHirjvRapM6x3ys1eYmbvmmv0 usLU2V5k8nXOcSFKc2sUiiJ8MwXSBY3zw6s721Hn5ANjheKx8sWiDyPnQfDAf70tgiKy s1BtYkSTo+XmnGeSwVXY4hJ7Q7V7dPCeLY1DI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tsZt7BigDkZl8k8ZM/5Oe9crtyJcU/TLkT6LuM00Kiw=; b=oA0LysodWRpchtaZ0IS7fieARDOxNPxxR2/gLv3XrZXdfMFX0LTWj7PxWqdNrbSSj5 IyZBOhUn9J7wNNpI/0UZbdFNGzTFbO/TSm5EFf/r09cDI9i7eEmGGoLSJXbdA6cP7YZZ pHeOgarzHjnpQ5Kn6FNj/x/UXK1VAMpoEu+pHz+9AZAq+x/COkd+7SR1JeGoKdE3Z9+0 Qtm1lYRSMnkGeN0teQlUKYzGkHSaohAI9iPiVqdmE8nVe600ZdhdjxpvWrYJRYGY6b2D mLMADn2zJNcqhvVMnYQwlL1NjcdIjoSmrj79gSMAaiD+Bxg2fV3aGi8LGT5D4nDmBMua EiIg== X-Gm-Message-State: AMke39kUo8EgX/S+NBvEdN++mCpV+uj3g750hDt083kLEz6UKntp1tutWlPdR8IMflqvWGx40HF9n5XU8LsMXQ+y X-Received: by 10.223.139.12 with SMTP id n12mr8954898wra.176.1486752256809; Fri, 10 Feb 2017 10:44:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.164.194 with HTTP; Fri, 10 Feb 2017 10:44:16 -0800 (PST) In-Reply-To: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Fri, 10 Feb 2017 10:44:16 -0800 Message-ID: To: Richard Gibson Content-Type: multipart/alternative; boundary=f403045ea3e022f1a10548317c43 Archived-At: Cc: dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 18:44:21 -0000 --f403045ea3e022f1a10548317c43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for your comments Q: why do you think it is useful to complicate things with a EDNS0 flag ? Olafur On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson wrote: > With full realization that this is coming very late in the game, we had a > great deal of internal conversation within Dyn about implementing > refuse-any, and came away unsatisfied with both the "subset" and "HINFO" > approaches=E2=80=94the latter because of reasons that have already been c= overed, > and the former for lacking in-band signaling of non-"conventional" > incompleteness to aid legitimate use. > > I believe there is sufficient cause to reserve a new OPT record EDNS > header flag bit > > for indicating "partial response" (as distinct from "truncation"). It wil= l > be safely ignored by current clients, but convey the desired information = to > those in the know. > > P.S. Our discussion also raised some more minor points: > > - Insisting that the HINFO OS field SHOULD be empty ("set to the null > string") seems a little too strong; there's room in it for (and value > from) a short explanation (e.g., cloudflare.com. 3789 IN HINFO "Please > stop asking for ANY" "See draft-ietf-dnsop-refuse-any"). I'd prefer > text like "The OS field of the HINFO RDATA SHOULD be short to minimize > the size of the response, and MAY be empty or MAY include a summarized > description of local policy." > - "Conventional [ANY] response" is used but not defined. > - "ANY does not mean ALL" is misleading=E2=80=94RFC 1035 > is clear about > QTYPE=3D255 being "a request for *all* records" (emphasis mine). That > said, the proposed *response* behavior is consistent with that RFC. > > > On Thu, Feb 9, 2017 at 12:56 AM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain Name System Operations of the >> IETF. >> >> Title : Providing Minimal-Sized Responses to DNS >> Queries that have QTYPE=3DANY >> Authors : Joe Abley >> Olafur Gudmundsson >> Marek Majkowski >> Filename : draft-ietf-dnsop-refuse-any-04.txt >> Pages : 10 >> Date : 2017-02-08 >> >> Abstract: >> The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". >> The operator of an authoritative DNS server might choose not to >> respond to such queries for reasons of local policy, motivated by >> security, performance or other reasons. >> >> The DNS specification does not include specific guidance for the >> behaviour of DNS servers or clients in this situation. This document >> aims to provide such guidance. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-refuse-any-04 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --f403045ea3e022f1a10548317c43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for your comments

Q: why do y= ou think it is useful to complicate things with a EDNS0 flag ?=C2=A0
<= div>
Olafur



On Thu, Feb 9,= 2017 at 8:47 PM, Richard Gibson <rgibson@dyn.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
With full realization that t= his is coming very late in the game, we had a great deal of internal conver= sation within Dyn about implementing refuse-any, and came away unsatisfied = with both the "subset" and "HINFO" approaches=E2=80=94t= he latter because of reasons that have already been covered, and the former= for lacking in-band signaling of non-"conventional" incompletene= ss to aid legitimate use.

I believe there is sufficient = cause to reserve a new OPT record = EDNS header flag bit for indicating "partial response" (as di= stinct from "truncation"). It will be safely ignored by current c= lients, but convey the desired information to those in the know.
P.S. Our discussion also raised some more minor points:
<= div>
  • Insisting that=C2=A0the= =C2=A0HINFO OS field SHOULD be empty ("set to the null string") s= eems a little too strong; there's room=C2=A0in=C2=A0it for (and value from) a short=C2=A0explanatio= n (e.g.,=C2=A0cloudflare.com= . 3789 IN HINFO "Please stop asking for ANY" "See dr= aft-ietf-dnsop-refuse-any"). I= 'd prefer text like "The=C2=A0OS field of=C2=A0the= =C2=A0HINFO RDATA SHOULD be short to minimize=C2=A0the=C2=A0size of=C2=A0the=C2=A0response, and MAY be empty or MAY include a summarize= d description of local policy."
  • "Conventional [ANY= ] response" is used but not defined.
  • "ANY does not mean A= LL" is misleading=E2=80=94RFC 1035= =C2=A0is clear about QTYPE=3D255 being &qu= ot;a request=C2=A0for=C2=A0all=C2=A0records" (emphasis mine). That said= , the=C2=A0proposed=C2=A0response=C2=A0behavior is consistent with that RFC.
<= /div>
On Thu, Feb 9, 2017 at 12:56 AM, <inte= rnet-drafts@ietf.org> wrote:
https://datatracker.ietf.org/doc/d= raft-ietf-dnsop-refuse-any/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ie= tf-dnsop-refuse-any-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-refuse-any-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--f403045ea3e022f1a10548317c43-- From nobody Fri Feb 10 12:02:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4AE129B5B for ; Fri, 10 Feb 2017 12:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 Z8_7kj7Cr3N6 for ; Fri, 10 Feb 2017 12:02:19 -0800 (PST) Received: from mail-vk0-x248.google.com (mail-vk0-x248.google.com [IPv6:2607:f8b0:400c:c05::248]) (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 16031129B5A for ; Fri, 10 Feb 2017 12:02:19 -0800 (PST) Received: by mail-vk0-x248.google.com with SMTP id 23so26258859vkc.1 for ; Fri, 10 Feb 2017 12:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DQJMHKiFcJKChNkHZS1MvYvaDWOBBWp2kldwP+rQFus=; b=ctGWtoK3IXiWiOapxbC2ZUGIP7tX+0GWM7Z2LpbXwNK6RVB9l2A/FxP0k8w69l/yzB tyhtddVVARrjf8BFwJ08sN0w20NMPyAr3BVrSoxQ2kcEJhSW9QMn4Eux24PvsP5PxY7F lPSRM7R7KpLCS6NjglIHqj2jNm+e7eh/PUoxc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DQJMHKiFcJKChNkHZS1MvYvaDWOBBWp2kldwP+rQFus=; b=dHvEfdwHx9NSkQfxE+i8xMt4jqhMgDXWvCkLPftvTjlfGxyZ8hOrJGjQSqVbudLudo i51YSTdwGddjIYC71b4SUI4DpEdbrceDniSVoe389zfLKKU5xrgFxwQY1ZsktLMEqdIE BWzaC9RGOZnwI3gRe9dce7dPTCkERpAwSOs6SUzrA88AfX+RvWl7/Q9rlc8nPZfibLwh 1vj8jG3whZWnW0TMpy8wggJw0SXMAgW3PzTJoED+LR9gs3gWtAlWtn2cFQAOeL82Nu60 sAkCT86BJ2KArGwR7vjffNAj/DA/RiwH+BWXaVDW/X8oZQO1oDUIZfSrjG801jNCTRvr 6JKw== X-Gm-Message-State: AMke39ld3VBBJUW4pCxl3wX6KGoYxZRPWv0p23Dph2Yh/z/SGOBlRMYHuRT0L1nackS4w/fkOQBJN+7z1uAmDe0k X-Received: by 10.31.63.88 with SMTP id m85mr4409292vka.158.1486756938102; Fri, 10 Feb 2017 12:02:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.5.131 with HTTP; Fri, 10 Feb 2017 12:01:57 -0800 (PST) In-Reply-To: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> From: Richard Gibson Date: Fri, 10 Feb 2017 15:01:57 -0500 Message-ID: To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Content-Type: multipart/alternative; boundary=001a114dccfe29f4610548329372 Archived-At: Cc: dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:02:21 -0000 --001a114dccfe29f4610548329372 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Because without such a signal, humans using ANY for legitimate diagnostic purposes have no means of differentiating section 4.1/4.3 "subset" responses from conventional responses where there just happen to be only a small number of RRSets at the queried name, encouraging (or at least doing nothing to dissuade) a conclusion that the response is in fact conventional and complete. On Fri, Feb 10, 2017 at 1:44 PM, =C3=93lafur Gu=C3=B0mundsson wrote: > Thank you for your comments > > Q: why do you think it is useful to complicate things with a EDNS0 flag ? > > Olafur > > > > On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson wrote: > >> With full realization that this is coming very late in the game, we had = a >> great deal of internal conversation within Dyn about implementing >> refuse-any, and came away unsatisfied with both the "subset" and "HINFO" >> approaches=E2=80=94the latter because of reasons that have already been = covered, >> and the former for lacking in-band signaling of non-"conventional" >> incompleteness to aid legitimate use. >> >> I believe there is sufficient cause to reserve a new OPT record EDNS >> header flag bit >> >> for indicating "partial response" (as distinct from "truncation"). It wi= ll >> be safely ignored by current clients, but convey the desired information= to >> those in the know. >> >> P.S. Our discussion also raised some more minor points: >> >> - Insisting that the HINFO OS field SHOULD be empty ("set to the null >> string") seems a little too strong; there's room in it for (and value >> from) a short explanation (e.g., cloudflare.com. 3789 IN HINFO "Pleas= e >> stop asking for ANY" "See draft-ietf-dnsop-refuse-any"). I'd prefer >> text like "The OS field of the HINFO RDATA SHOULD be short to >> minimize the size of the response, and MAY be empty or MAY include a >> summarized description of local policy." >> - "Conventional [ANY] response" is used but not defined. >> - "ANY does not mean ALL" is misleading=E2=80=94RFC 1035 >> is clear about >> QTYPE=3D255 being "a request for *all* records" (emphasis mine). That >> said, the proposed *response* behavior is consistent with that RFC. >> >> >> On Thu, Feb 9, 2017 at 12:56 AM, wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Domain Name System Operations of the >>> IETF. >>> >>> Title : Providing Minimal-Sized Responses to DNS >>> Queries that have QTYPE=3DANY >>> Authors : Joe Abley >>> Olafur Gudmundsson >>> Marek Majkowski >>> Filename : draft-ietf-dnsop-refuse-any-04.txt >>> Pages : 10 >>> Date : 2017-02-08 >>> >>> Abstract: >>> The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". >>> The operator of an authoritative DNS server might choose not to >>> respond to such queries for reasons of local policy, motivated by >>> security, performance or other reasons. >>> >>> The DNS specification does not include specific guidance for the >>> behaviour of DNS servers or clients in this situation. This documen= t >>> aims to provide such guidance. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-refuse-any-04 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> > --001a114dccfe29f4610548329372 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Because without such a signal, humans using ANY for legiti= mate diagnostic purposes have no means of differentiating section 4.1/4.3 &= quot;subset" responses from conventional responses where there just ha= ppen to be only a small number of RRSets at the queried name, encouraging (= or at least doing nothing to dissuade) a conclusion that the response is in= fact conventional and complete.

On Fri, Feb 10, 2017 at 1:44 PM, =C3=93lafur Gu=C3=B0m= undsson <olafur@cloudflare.com> wrote:
Thank you for your comments

Q: why do you think it is useful to complicate things with a EDNS0 fl= ag ?=C2=A0

Olafur


On Thu, Feb 9, 2017 at 8:47 PM, = Richard Gibson <rgibson@dyn.com> wrote:
With full realization that this is coming ve= ry late in the game, we had a great deal of internal conversation within Dy= n about implementing refuse-any, and came away unsatisfied with both the &q= uot;subset" and "HINFO" approaches=E2=80=94the latter becaus= e of reasons that have already been covered, and the former for lacking in-= band signaling of non-"conventional" incompleteness to aid legiti= mate use.

I believe there is sufficient cause to reserve= a new OPT record EDNS header flag= bit for indicating "partial response" (as distinct from &quo= t;truncation"). It will be safely ignored by current clients, but conv= ey the desired information to those in the know.

P.S= . Our discussion also raised some more minor points:
  • Insi= sting that=C2=A0the=C2=A0HINFO OS field SHOULD be empty ("set to the null string"= ;) seems a little too strong; there's room=C2=A0in=C2=A0it for (and value from)= a short=C2=A0explanation (e.g.,=C2=A0cloudflare.com. 3789 IN HINFO &qu= ot;Please stop asking for ANY" "See draft-ietf-dnsop-refuse-any&q= uot;). I'd prefer text like &qu= ot;The= =C2=A0OS field of=C2=A0the=C2=A0HINFO RDATA SHOULD be short to minimize=C2=A0the=C2=A0size= of=C2=A0the=C2=A0response, and MAY be empty or MAY include a summarized descriptio= n of local policy."
  • "Conventional [ANY] response&q= uot; is used but not defined.
  • "ANY does not mean ALL" is = misleading=E2=80=94RFC 1035=C2=A0is clear about QTYPE=3D255 being "a reques= t=C2=A0for=C2=A0all=C2=A0records" (emphasis mine). That said, the=C2=A0proposed= =C2=A0response=C2=A0behavior is consistent with that RFC.

On Thu, Feb 9, 2017 at 12:56 AM, <internet-drafts@ietf.org= > wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Providing Minimal-Sized Responses to DNS Queries that have QTYPE=3DANY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Joe = Abley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Olafur Gudmundsson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Marek Majkowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-refuse-any-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-02-08

Abstract:
=C2=A0 =C2=A0The Domain Name System (DNS) specifies a query type (QTYPE) &q= uot;ANY".
=C2=A0 =C2=A0The operator of an authoritative DNS server might choose not t= o
=C2=A0 =C2=A0respond to such queries for reasons of local policy, motivated= by
=C2=A0 =C2=A0security, performance or other reasons.

=C2=A0 =C2=A0The DNS specification does not include specific guidance for t= he
=C2=A0 =C2=A0behaviour of DNS servers or clients in this situation.=C2=A0 T= his document
=C2=A0 =C2=A0aims to provide such guidance.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-dnsop-refuse-any/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ie= tf-dnsop-refuse-any-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-refuse-any-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



--001a114dccfe29f4610548329372-- From nobody Fri Feb 10 12:43:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F43B129BD5 for ; Fri, 10 Feb 2017 12:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 JjFSwiPk4C5r for ; Fri, 10 Feb 2017 12:43:21 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02FAC129BDB for ; Fri, 10 Feb 2017 12:43:20 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v1AKhIFE053493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2017 14:43:19 -0600 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A21271E0087; Fri, 10 Feb 2017 13:43:13 -0700 (MST) Received: from lxomp06u.corp.intranet (unknown [151.119.92.134]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 792A61E007E; Fri, 10 Feb 2017 13:43:13 -0700 (MST) Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v1AKhDYk000963; Fri, 10 Feb 2017 14:43:13 -0600 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v1AKhDhR000951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Feb 2017 14:43:13 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0294.000; Fri, 10 Feb 2017 14:43:12 -0600 From: "Woodworth, John R" To: "'Richard Gibson'" , =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt Thread-Index: AQHSgpl3U3YBSPPM/0Gynw7H0jqNgqFiEPqAgADpxACAABW0gP//ot/Q Date: Fri, 10 Feb 2017 20:43:11 +0000 Message-ID: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: multipart/alternative; boundary="_000_A05B583C828C614EBAD1DA920D92866BD06D5E0BPODCWMBXEX501ct_" MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: dnsop , "Woodworth, John R" , "Ballew, Dean" Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:43:22 -0000 --_000_A05B583C828C614EBAD1DA920D92866BD06D5E0BPODCWMBXEX501ct_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmljaGFyZCwgT2xhZnVyOw0KDQpKdXN0IHJlcmVhZCB5b3VyIGRyYWZ0IGFuZCBoYWQgYSBxdWVz dGlvbi4NCg0KV291bGQgaXQgYmUgd29ydGh3aGlsZSB0byBmb3JtYWxpemUgYSBkZWZhdWx0IHJl c3VsdC1zZXQgZm9yIGFuIEFOWSBxdWVyeSBpbiB5b3VyIGRyYWZ0PyAgU2VlbXMgbGlrZSB0aGVy ZSBpcyBhIGdyZWF0IGRpc3Bhcml0eSBhbW9uZyBpbXBsZW1lbnRhdGlvbnMgYW5kIGFzIHBvaW50 ZWQgb3V0IGluIHlvdXIgZHJhZnQgY2xpZW50cyBsb29raW5nIHRvIHNhdmUgY2Fsb3JpZXMgd2l0 aCBhIHNpbmdsZSBxdWVyeSBzdGlsbCByZXF1aXJlIGZhbGxiYWNrIGxvZ2ljIOKAnGp1c3QgaW4g Y2FzZeKAnSB0aGV5IGRvbuKAmXQgZ2V0IHdoYXQgaXMgZXhwZWN0ZWQuDQoNClNpbmNlIHRoaXMg ZHJhZnQgZGVmaW5lcyAzIGFsdGVybmF0ZSBtZXRob2RzIGZvciBkZXRlcm1pbmluZyByZXNwb25z ZXMsIGEgNHRoIGNvdWxkIGZvcm1hbGx5IGRlZmluZSDigJxub3JtYWzigJ0uICBKdXN0IGEgdGhv dWdodC4NCg0KQlRXOiBsaWtlIHRoZSBpZGVhIG9mIGEgdGhlIGZsYWcgdG8gYmV0dGVyIGNvbnRy b2wgaW50ZW50Lg0KDQoNClRoYW5rcywNCkpvaG4NCg0KRnJvbTogRE5TT1AgW21haWx0bzpkbnNv cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmljaGFyZCBHaWJzb24NCg0KQmVjYXVz ZSB3aXRob3V0IHN1Y2ggYSBzaWduYWwsIGh1bWFucyB1c2luZyBBTlkgZm9yIGxlZ2l0aW1hdGUg ZGlhZ25vc3RpYyBwdXJwb3NlcyBoYXZlIG5vIG1lYW5zIG9mIGRpZmZlcmVudGlhdGluZyBzZWN0 aW9uIDQuMS80LjMgInN1YnNldCIgcmVzcG9uc2VzIGZyb20gY29udmVudGlvbmFsIHJlc3BvbnNl cyB3aGVyZSB0aGVyZSBqdXN0IGhhcHBlbiB0byBiZSBvbmx5IGEgc21hbGwgbnVtYmVyIG9mIFJS U2V0cyBhdCB0aGUgcXVlcmllZCBuYW1lLCBlbmNvdXJhZ2luZyAob3IgYXQgbGVhc3QgZG9pbmcg bm90aGluZyB0byBkaXNzdWFkZSkgYSBjb25jbHVzaW9uIHRoYXQgdGhlIHJlc3BvbnNlIGlzIGlu IGZhY3QgY29udmVudGlvbmFsIGFuZCBjb21wbGV0ZS4NCg0KT24gRnJpLCBGZWIgMTAsIDIwMTcg YXQgMTo0NCBQTSwgw5NsYWZ1ciBHdcOwbXVuZHNzb24gPG9sYWZ1ckBjbG91ZGZsYXJlLmNvbTxt YWlsdG86b2xhZnVyQGNsb3VkZmxhcmUuY29tPj4gd3JvdGU6DQpUaGFuayB5b3UgZm9yIHlvdXIg Y29tbWVudHMNCg0KUTogd2h5IGRvIHlvdSB0aGluayBpdCBpcyB1c2VmdWwgdG8gY29tcGxpY2F0 ZSB0aGluZ3Mgd2l0aCBhIEVETlMwIGZsYWcgPw0KDQpPbGFmdXINCg0KLS0gVEhFU0UgQVJFIFRI RSBEUk9JRFMgVE8gV0hPTSBJIFJFRkVSOg0KVGhpcyBjb21tdW5pY2F0aW9uIGlzIHRoZSBwcm9w ZXJ0eSBvZiBDZW50dXJ5TGluayBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24uIFVuYXV0aG9yaXplZCB1c2Ugb2YgdGhpcyBjb21tdW5pY2F0aW9u IGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkg bm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMg b2YgdGhlIGNvbW11bmljYXRpb24gYW5kIGFueSBhdHRhY2htZW50cy4NCg== --_000_A05B583C828C614EBAD1DA920D92866BD06D5E0BPODCWMBXEX501ct_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4ubS03ODAzNzI1 Nzk3OTAzMTgyODM2bTU2ODk2NDc3NzE4NzI0NjY1MzhnbWFpbC1pbA0KCXttc28tc3R5bGUtbmFt ZTptXy03ODAzNzI1Nzk3OTAzMTgyODM2bV81Njg5NjQ3NzcxODcyNDY2NTM4Z21haWwtaWw7fQ0K c3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA3NTU4NTQyNTsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6ODM2NTY1MjY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJpY2hhcmQsIE9sYWZ1cjs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pkp1c3QgcmVyZWFkIHlvdXIgZHJhZnQgYW5kIGhhZCBhIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V291 bGQgaXQgYmUgd29ydGh3aGlsZSB0byBmb3JtYWxpemUgYSBkZWZhdWx0IHJlc3VsdC1zZXQgZm9y IGFuIEFOWSBxdWVyeSBpbiB5b3VyIGRyYWZ0PyZuYnNwOyBTZWVtcyBsaWtlIHRoZXJlIGlzIGEg Z3JlYXQgZGlzcGFyaXR5IGFtb25nIGltcGxlbWVudGF0aW9ucyBhbmQgYXMNCiBwb2ludGVkIG91 dCBpbiB5b3VyIGRyYWZ0IGNsaWVudHMgbG9va2luZyB0byBzYXZlIGNhbG9yaWVzIHdpdGggYSBz aW5nbGUgcXVlcnkgc3RpbGwgcmVxdWlyZSBmYWxsYmFjayBsb2dpYyDigJxqdXN0IGluIGNhc2Xi gJ0gdGhleSBkb27igJl0IGdldCB3aGF0IGlzIGV4cGVjdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2luY2UgdGhp cyBkcmFmdCBkZWZpbmVzIDMgYWx0ZXJuYXRlIG1ldGhvZHMgZm9yIGRldGVybWluaW5nIHJlc3Bv bnNlcywgYSA0dGggY291bGQgZm9ybWFsbHkgZGVmaW5lIOKAnG5vcm1hbOKAnS4mbmJzcDsgSnVz dCBhIHRob3VnaHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CVFc6IGxpa2UgdGhlIGlkZWEgb2YgYSB0aGUgZmxhZyB0 byBiZXR0ZXIgY29udHJvbCBpbnRlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Kb2hu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRE5TT1AgW21haWx0bzpk bnNvcC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5SaWNoYXJkIEdpYnNv bjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJlY2F1c2Ugd2l0aG91dCBzdWNoIGEgc2lnbmFsLCBodW1hbnMgdXNp bmcgQU5ZIGZvciBsZWdpdGltYXRlIGRpYWdub3N0aWMgcHVycG9zZXMgaGF2ZSBubyBtZWFucyBv ZiBkaWZmZXJlbnRpYXRpbmcgc2VjdGlvbiA0LjEvNC4zICZxdW90O3N1YnNldCZxdW90OyByZXNw b25zZXMgZnJvbSBjb252ZW50aW9uYWwgcmVzcG9uc2VzIHdoZXJlIHRoZXJlIGp1c3QgaGFwcGVu IHRvIGJlIG9ubHkgYSBzbWFsbCBudW1iZXIgb2YgUlJTZXRzDQogYXQgdGhlIHF1ZXJpZWQgbmFt ZSwgZW5jb3VyYWdpbmcgKG9yIGF0IGxlYXN0IGRvaW5nIG5vdGhpbmcgdG8gZGlzc3VhZGUpIGEg Y29uY2x1c2lvbiB0aGF0IHRoZSByZXNwb25zZSBpcyBpbiBmYWN0IGNvbnZlbnRpb25hbCBhbmQg Y29tcGxldGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBGcmksIEZlYiAxMCwgMjAxNyBhdCAxOjQ0IFBNLCDDk2xhZnVyIEd1w7BtdW5kc3NvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm9sYWZ1ckBjbG91ZGZsYXJlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm9s YWZ1ckBjbG91ZGZsYXJlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50czxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UTogd2h5IGRvIHlvdSB0aGlu ayBpdCBpcyB1c2VmdWwgdG8gY29tcGxpY2F0ZSB0aGluZ3Mgd2l0aCBhIEVETlMwIGZsYWcgPyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbGFmdXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+LS0gVEhFU0UgQVJFIFRIRSBEUk9J RFMgVE8gV0hPTSBJIFJFRkVSOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8Y2VudGVyPlRoaXMgY29tbXVuaWNhdGlvbiBpcyB0aGUgcHJvcGVydHkgb2YgQ2VudHVyeUxp bmsgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u LiBVbmF1dGhvcml6ZWQgdXNlIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9o aWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5DQogbm90aWZ5IHRoZSBzZW5k ZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIGNvbW11bmlj YXRpb24gYW5kIGFueSBhdHRhY2htZW50cy48L2NlbnRlcj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A05B583C828C614EBAD1DA920D92866BD06D5E0BPODCWMBXEX501ct_-- From nobody Sat Feb 11 13:13:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AF31294DF for ; Sat, 11 Feb 2017 13:13:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 sPzLGIJSZZAZ for ; Sat, 11 Feb 2017 13:13:09 -0800 (PST) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1435E1294C4 for ; Sat, 11 Feb 2017 13:13:09 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v1BLD70Z063693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 11 Feb 2017 14:13:07 -0700 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 785781E004E for ; Sat, 11 Feb 2017 14:13:02 -0700 (MST) Received: from lxomp06u.corp.intranet (unknown [151.119.92.134]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 531121E0035 for ; Sat, 11 Feb 2017 14:13:02 -0700 (MST) Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v1BLD1PH058768 for ; Sat, 11 Feb 2017 15:13:01 -0600 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v1BLD1wu058765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 11 Feb 2017 15:13:01 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0294.000; Sat, 11 Feb 2017 15:13:01 -0600 From: "Woodworth, John R" To: dnsop Thread-Topic: DNS-Server distribution statistics Thread-Index: AdKEq6BG7HXC5MAlQSGPwmoHhB7TZQ== Date: Sat, 11 Feb 2017 21:13:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: multipart/alternative; boundary="_000_A05B583C828C614EBAD1DA920D92866BD06D7056PODCWMBXEX501ct_" MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "Woodworth, John R" , "Ballew, Dean" Subject: [DNSOP] DNS-Server distribution statistics X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 21:13:10 -0000 --_000_A05B583C828C614EBAD1DA920D92866BD06D7056PODCWMBXEX501ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Apologies if this is not the perfect forum for this but I am trying to get = an idea of what the breakdown for DNS is on the server side. I was unable = to find anything equivalent to a zeitgeist breakdown for DNS. My best guess, without intending to offend, would be something like 'bind',= 'argon' and some random mixture of water vapor but am looking for somethin= g more specific (i.e. vendor/version). Does anyone have a list they can point me to or at least share real world o= r anecdotal data? Thanks in advance, John -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. --_000_A05B583C828C614EBAD1DA920D92866BD06D7056PODCWMBXEX501ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Apologies if this is not the perfect forum for this = but I am trying to get an idea of what the breakdown for DNS is on the serv= er side.  I was unable to find anything equivalent to a zeitgeist brea= kdown for DNS.

 

My best guess, without intending to offend, would be= something like ‘bind’, ‘argon’ and some random mix= ture of water vapor but am looking for something more specific (i.e. vendor= /version).

 

Does anyone have a list they can point me to or at l= east share real world or anecdotal data?

 

 

Thanks in advance,

John

 

-- THESE ARE THE DROIDS TO WHOM I REFER:

 

This communication is the property of CenturyLink and may contain c= onfidential or privileged information. Unauthorized use of this communicati= on is strictly prohibited and may be unlawful. If you have received this co= mmunication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communicat= ion and any attachments.
--_000_A05B583C828C614EBAD1DA920D92866BD06D7056PODCWMBXEX501ct_-- From nobody Sat Feb 11 14:49:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBC9129476 for ; Sat, 11 Feb 2017 14:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 7RRvYdB6554G for ; Sat, 11 Feb 2017 14:49:27 -0800 (PST) Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CB312944B for ; Sat, 11 Feb 2017 14:49:26 -0800 (PST) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id 3FBBBA0452 for ; Sat, 11 Feb 2017 22:49:26 +0000 (UTC) X-hush-tls-connected: 1 Received: from smtp.hushmail.com (w3.hushmail.com [65.39.178.62]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS; Sat, 11 Feb 2017 22:49:23 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 78115C0660; Sat, 11 Feb 2017 22:49:23 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 11 Feb 2017 17:49:23 -0500 To: "John R Woodworth" , "dnsop" From: "Allan Liska" In-Reply-To: Content-Type: multipart/alternative; boundary="=_6a90729f2fe91dce9ba733587087b39a" Message-Id: <20170211224923.78115C0660@smtp.hushmail.com> Archived-At: Cc: Dean Ballew Subject: Re: [DNSOP] DNS-Server distribution statistics X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 22:49:28 -0000 --=_6a90729f2fe91dce9ba733587087b39a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" ISC runs a monthly survey of DNS statistics: https://ftp.isc.org/www/survey/reports/current/fpdns.txt (this is from January 2017). Information about the survey is here: https://ftp.isc.org/www/survey/reports/current/survey.html Not sure how useful their data is, but they have been doing it for a long time, so they have great trending analysis. allan On 2/11/2017 at 4:13 PM, "John R Woodworth" wrote: All, Apologies if this is not the perfect forum for this but I am trying to get an idea of what the breakdown for DNS is on the server side. I was unable to find anything equivalent to a zeitgeist breakdown for DNS. My best guess, without intending to offend, would be something like ‘bind’, ‘argon’ and some random mixture of water vapor but am looking for something more specific (i.e. vendor/version). Does anyone have a list they can point me to or at least share real world or anecdotal data? Thanks in advance, John --=_6a90729f2fe91dce9ba733587087b39a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" ISC runs a monthly sur= vey of DNS statistics:


Information about the survey is here:


No= t sure how useful their data is, but they have been doing it for a long tim= e, so they have great trending analysis.



allan


On 2/11/2017 at 4:13 PM, "John= R Woodworth" <John.Woodworth@CenturyLink.com> wrote:

All,

 

Apologies if this is not the perfect forum for this = but I am trying to get an idea of what the breakdown for DNS is on the serv= er side.  I was unable to find anything equivalent to a zeitgeist brea= kdown for DNS.

 

My best guess, without intending to offend, would be= something like =E2=80=98bind=E2=80=99, =E2=80=98argon=E2=80=99 and some ra= ndom mixture of water vapor but am looking for something more specific (i.e= . vendor/version).

 

Does anyone have a list they can point me to or at l= east share real world or anecdotal data?

 

 

Thanks in advance,

John


--=_6a90729f2fe91dce9ba733587087b39a-- From nobody Sat Feb 11 21:21:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E3812966A for ; Sat, 11 Feb 2017 21:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 Fdk9T3W7zclm for ; Sat, 11 Feb 2017 21:21:39 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6120D12965B for ; Sat, 11 Feb 2017 21:21:39 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v1C5LZgN014692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Feb 2017 23:21:36 -0600 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A57821E003F; Sat, 11 Feb 2017 23:21:30 -0600 (CST) Received: from lxomp06u.corp.intranet (unknown [151.117.18.14]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 8018A1E0032; Sat, 11 Feb 2017 23:21:30 -0600 (CST) Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v1C5LUvO052885; Sat, 11 Feb 2017 23:21:30 -0600 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v1C5LUf2052882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Feb 2017 23:21:30 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0294.000; Sat, 11 Feb 2017 23:21:30 -0600 From: "Woodworth, John R" To: "'Allan Liska'" , dnsop Thread-Topic: [DNSOP] DNS-Server distribution statistics Thread-Index: AdKEq6BG7HXC5MAlQSGPwmoHhB7TZQAP8DqAAADYl0A= Date: Sun, 12 Feb 2017 05:21:29 +0000 Message-ID: References: <20170211224923.78115C0660@smtp.hushmail.com> In-Reply-To: <20170211224923.78115C0660@smtp.hushmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "Woodworth, John R" , "Ballew, Dean" Subject: Re: [DNSOP] DNS-Server distribution statistics X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 05:21:41 -0000 QWxsYW4sDQoNCk1hbnkgdGhhbmtzIGZvciB0aGUgbGlua3MuICBUaGlzIGlzIGdyZWF0IGluZm8g YW5kIHJpZ2h0IG9uIHBvaW50IQ0KDQoNClRoYW5rcyBhZ2FpbiwNCkpvaG4NCg0KRnJvbTogQWxs YW4gTGlza2EgW21haWx0bzphbGxhbkBhbGxhbi5vcmddDQpTZW50OiBTYXR1cmRheSwgRmVicnVh cnkgMTEsIDIwMTcgNTo0OSBQTQ0KVG86IFdvb2R3b3J0aCwgSm9obiBSOyBkbnNvcA0KQ2M6IEJh bGxldywgRGVhbg0KU3ViamVjdDogUmU6IFtETlNPUF0gRE5TLVNlcnZlciBkaXN0cmlidXRpb24g c3RhdGlzdGljcw0KDQpJU0MgcnVucyBhIG1vbnRobHkgc3VydmV5IG9mIEROUyBzdGF0aXN0aWNz Og0KDQpodHRwczovL2Z0cC5pc2Mub3JnL3d3dy9zdXJ2ZXkvcmVwb3J0cy9jdXJyZW50L2ZwZG5z LnR4dCAodGhpcyBpcyBmcm9tIEphbnVhcnkgMjAxNykuDQoNCkluZm9ybWF0aW9uIGFib3V0IHRo ZSBzdXJ2ZXkgaXMgaGVyZToNCg0KaHR0cHM6Ly9mdHAuaXNjLm9yZy93d3cvc3VydmV5L3JlcG9y dHMvY3VycmVudC9zdXJ2ZXkuaHRtbA0KDQpOb3Qgc3VyZSBob3cgdXNlZnVsIHRoZWlyIGRhdGEg aXMsIGJ1dCB0aGV5IGhhdmUgYmVlbiBkb2luZyBpdCBmb3IgYSBsb25nIHRpbWUsIHNvIHRoZXkg aGF2ZSBncmVhdCB0cmVuZGluZyBhbmFseXNpcy4NCg0KDQoNCmFsbGFuDQoNCg0KT24gMi8xMS8y MDE3IGF0IDQ6MTMgUE0sICJKb2huIFIgV29vZHdvcnRoIiA8Sm9obi5Xb29kd29ydGhAQ2VudHVy eUxpbmsuY29tPiB3cm90ZToNCkFsbCwNCg0KQXBvbG9naWVzIGlmIHRoaXMgaXMgbm90IHRoZSBw ZXJmZWN0IGZvcnVtIGZvciB0aGlzIGJ1dCBJIGFtIHRyeWluZyB0byBnZXQgYW4gaWRlYSBvZiB3 aGF0IHRoZSBicmVha2Rvd24gZm9yIEROUyBpcyBvbiB0aGUgc2VydmVyIHNpZGUuICBJIHdhcyB1 bmFibGUgdG8gZmluZCBhbnl0aGluZyBlcXVpdmFsZW50IHRvIGEgemVpdGdlaXN0IGJyZWFrZG93 biBmb3IgRE5TLg0KDQpNeSBiZXN0IGd1ZXNzLCB3aXRob3V0IGludGVuZGluZyB0byBvZmZlbmQs IHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlIOKAmGJpbmTigJksIOKAmGFyZ29u4oCZIGFuZCBzb21l IHJhbmRvbSBtaXh0dXJlIG9mIHdhdGVyIHZhcG9yIGJ1dCBhbSBsb29raW5nIGZvciBzb21ldGhp bmcgbW9yZSBzcGVjaWZpYyAoaS5lLiB2ZW5kb3IvdmVyc2lvbikuDQoNCkRvZXMgYW55b25lIGhh dmUgYSBsaXN0IHRoZXkgY2FuIHBvaW50IG1lIHRvIG9yIGF0IGxlYXN0IHNoYXJlIHJlYWwgd29y bGQgb3IgYW5lY2RvdGFsIGRhdGE/DQoNCg0KVGhhbmtzIGluIGFkdmFuY2UsDQpKb2huDQoNCg0K LS0gVEhFU0UgQVJFIFRIRSBEUk9JRFMgVE8gV0hPTSBJIFJFRkVSOg0KVGhpcyBjb21tdW5pY2F0 aW9uIGlzIHRoZSBwcm9wZXJ0eSBvZiBDZW50dXJ5TGluayBhbmQgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIFVuYXV0aG9yaXplZCB1c2Ugb2YgdGhp cyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1 bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVh c2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0 cm95IGFsbCBjb3BpZXMgb2YgdGhlIGNvbW11bmljYXRpb24gYW5kIGFueSBhdHRhY2htZW50cy4N Cg== From nobody Sun Feb 12 06:40:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29D212973E for ; Sun, 12 Feb 2017 06:40:47 -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] 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 U_5WLOv5jy2X for ; Sun, 12 Feb 2017 06:40:46 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E6512946A for ; Sun, 12 Feb 2017 06:40:46 -0800 (PST) Received: from [10.32.60.18] ([75.104.71.67]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v1CEd77R061909 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Feb 2017 07:39:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host [75.104.71.67] claimed to be [10.32.60.18] From: "Paul Hoffman" To: "Allan Liska" Date: Sun, 12 Feb 2017 09:40:21 -0500 Message-ID: <667F88F0-FD47-41C6-8A66-581070395FC0@vpnc.org> In-Reply-To: <20170211224923.78115C0660@smtp.hushmail.com> References: <20170211224923.78115C0660@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5344) Archived-At: Cc: dnsop , John R Woodworth , Dean Ballew Subject: Re: [DNSOP] DNS-Server distribution statistics X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 14:40:47 -0000 On 11 Feb 2017, at 17:49, Allan Liska wrote: > ISC runs a monthly survey of DNS statistics: > https://ftp.isc.org/www/survey/reports/current/fpdns.txt (this is from > January 2017). > Information about the survey is here: > https://ftp.isc.org/www/survey/reports/current/survey.html > Not sure how useful their data is, but they have been doing it for a > long time, so they have great trending analysis. Do note, however, that fingerprinting DNS servers has gotten much harder over time, so take the results with a very large grain of salt. For example, the software that runs that survey seems to think that there are no versions of BIND 9 since 9.4.0a0. --Paul Hoffman From nobody Sun Feb 12 11:55:56 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6711C129485 for ; Sun, 12 Feb 2017 11:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 pzD9kN_vgb_p for ; Sun, 12 Feb 2017 11:55:54 -0800 (PST) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8B9129421 for ; Sun, 12 Feb 2017 11:55:54 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v1CJtnUR007708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Feb 2017 12:55:49 -0700 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2AB531E0058; Sun, 12 Feb 2017 13:55:44 -0600 (CST) Received: from lxomp07u.corp.intranet (unknown [151.117.18.14]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 099461E0053; Sun, 12 Feb 2017 13:55:44 -0600 (CST) Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v1CJthYE062863; Sun, 12 Feb 2017 13:55:43 -0600 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v1CJthjI062860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Feb 2017 13:55:43 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0294.000; Sun, 12 Feb 2017 13:55:43 -0600 From: "Woodworth, John R" To: "'Paul Hoffman'" , Allan Liska Thread-Topic: [DNSOP] DNS-Server distribution statistics Thread-Index: AdKEq6BG7HXC5MAlQSGPwmoHhB7TZQAP8DqAACE2ToAAAa8kwA== Date: Sun, 12 Feb 2017 19:55:42 +0000 Message-ID: References: <20170211224923.78115C0660@smtp.hushmail.com> <667F88F0-FD47-41C6-8A66-581070395FC0@vpnc.org> In-Reply-To: <667F88F0-FD47-41C6-8A66-581070395FC0@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: dnsop , "Woodworth, John R" , "Ballew, Dean" Subject: Re: [DNSOP] DNS-Server distribution statistics X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 19:55:55 -0000 -----Original Message----- From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Paul Hoffman > > On 11 Feb 2017, at 17:49, Allan Liska wrote: > > > ISC runs a monthly survey of DNS statistics: > > https://ftp.isc.org/www/survey/reports/current/fpdns.txt (this is from > > January 2017). > > Information about the survey is here: > > https://ftp.isc.org/www/survey/reports/current/survey.html > > Not sure how useful their data is, but they have been doing it for a > > long time, so they have great trending analysis. > > Do note, however, that fingerprinting DNS servers has gotten much harder > over time, so take the results with a very large grain of salt. For > example, the software that runs that survey seems to think that there > are no versions of BIND 9 since 9.4.0a0. > Thanks Paul! I was wondering about that. Figured there would be more people at least near the bleeding-edge. Thanks, John > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Sun Feb 12 14:44:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B6E129430 for ; Sun, 12 Feb 2017 14:44:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bdao27abUA9 for ; Sun, 12 Feb 2017 14:44:44 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 88D15126BF6 for ; Sun, 12 Feb 2017 14:44:44 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id 35so56367651uak.1 for ; Sun, 12 Feb 2017 14:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=YYcMCjRdtjGqdHsjJYPYsIgy5Mc+PzpKEryv2TQ6uAQ=; b=s9wxbyDzm7hCKlxDjYZctdZG8lXehXsUt8tu/NtmeTceIpUXM/0TtOr9khnmLV4omg g56up+i8wmQIgbvMFRZHnRU33ewQTnmnDqLQ8F8Z/fpL7vzex4BnCMHc5/op134JgURt o3Av+ZxwVt6vi1vrbTAbCp2NwYF7z6/QLtBjmQRqmP+S/4EGjcqGMolpx1GRz3cylal/ Ux1bb1MQzWeO2pCjhXb34qiWnRDnc+6CFh4Fcdy0rhCCRTeCmONrYurqP0B7yvlnvkQd NzY36zWsMPILiyURX9kRMsDViTmbe09guO1N5qhJLgp8xssJvBh2JfU1OFMGLoC4/hGr a4Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=YYcMCjRdtjGqdHsjJYPYsIgy5Mc+PzpKEryv2TQ6uAQ=; b=iQwUN+dNABaRscN0Gx3N1893W1AEEps244CyND2Xwoo0hqxZ1ctgrLXWYQ63NQe3aT F09mrol3+af2k+iHmHCpFrZfatsKUYfjDB8ghjtwJqi2mkugLmHIwYI2EmbobtS4iE8B 4Lw7uMiIuXWnEED5CKnSqjuYHBIIL3eWq5+h19f0LKsDV8rTJRL1X2TUMQahccVNnS28 NrQjd6Yh9sC3rwP/ewG6p03T/gfO0/G711tmiIcJ7xrKrRJFWCt8L+zKd+yD/pyzhVQB H3m2rzs1Cr4i0Lm6d5LE5S3cIw4y/FxDTtrw8Gd09WKnWkoWgYL99keTReSi3R+S1yua W7bw== X-Gm-Message-State: AMke39kWcEgMLbMa3W7IBpIRX+w+8nSQ0F0X7HvpWCSxGSkzdqUJ+Qk9ZtxxJONVHM3mje3H2Ro5JPU0l0WTHg== X-Received: by 10.176.91.72 with SMTP id v8mr10565153uae.23.1486939483376; Sun, 12 Feb 2017 14:44:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.48.211 with HTTP; Sun, 12 Feb 2017 14:44:43 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:99d7:e508:81bc:2836] In-Reply-To: References: <20170211224923.78115C0660@smtp.hushmail.com> <667F88F0-FD47-41C6-8A66-581070395FC0@vpnc.org> From: George Michaelson Date: Mon, 13 Feb 2017 00:44:43 +0200 Message-ID: To: dnsop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] DNS-Server distribution statistics X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 22:44:47 -0000 I have never entirely got with the people who think obscuring version information is necessary and correct. Designing for the bad actors presupposes they will somehow magically not attack you, simply because you obscured the version info. Root ops (I may misremember) stand out in my mind as a group who have from time to time said "we don't feel we need, or should tell you that" So on the whole, I think we should explore this "what version are you" question more, and possibly do better at flagging it. Having said which: people lie all the time. Either by intent, or because they reply with information which was correct when they set it, but has aged out. So even with the best of intentions, version-flagging needs to be taken with a grain of salt. -G On Sun, Feb 12, 2017 at 9:55 PM, Woodworth, John R wrote: > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Paul Hoffman >> >> On 11 Feb 2017, at 17:49, Allan Liska wrote: >> >> > ISC runs a monthly survey of DNS statistics: >> > https://ftp.isc.org/www/survey/reports/current/fpdns.txt (this is from >> > January 2017). >> > Information about the survey is here: >> > https://ftp.isc.org/www/survey/reports/current/survey.html >> > Not sure how useful their data is, but they have been doing it for a >> > long time, so they have great trending analysis. >> >> Do note, however, that fingerprinting DNS servers has gotten much harder >> over time, so take the results with a very large grain of salt. For >> example, the software that runs that survey seems to think that there >> are no versions of BIND 9 since 9.4.0a0. >> > > Thanks Paul! > > I was wondering about that. Figured there would be more people at least > near the bleeding-edge. > > > Thanks, > John > >> --Paul Hoffman >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > -- THESE ARE THE DROIDS TO WHOM I REFER: > This communication is the property of CenturyLink and may contain confide= ntial or privileged information. Unauthorized use of this communication is = strictly prohibited and may be unlawful. If you have received this communic= ation in error, please immediately notify the sender by reply e-mail and de= stroy all copies of the communication and any attachments. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Sun Feb 12 14:57:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBF012943A for ; Sun, 12 Feb 2017 14:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_7E9GCJDXv8 for ; Sun, 12 Feb 2017 14:57:28 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 13158126BF6 for ; Sun, 12 Feb 2017 14:57:27 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id u25so80250386qki.2 for ; Sun, 12 Feb 2017 14:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=o36kdbzBk/M3IbQ67V+1rN+cqsPvxL9s08BJ3HtzjiY=; b=meF4gnu8crl67QmXLS92ielBPKITT1qeWs+ENhX847Ll88LrLO6zfS4bcUP/TUNBhs uuWTKiPEPzKk6pHCmo0LjiJJkoc/75cH05w5CZF7+T7NUzV+p6BNvyXHn/IEXGfA4+K+ ZrMJ6zAhTWlNMMjqkkIGQljYbngFz5tGmbyR/cTo+RKmQNo62eW0+iE0jL3psyaDitjW k4rBzIQMAdnOHjIfRd0hImMcJGd1fRY/lFrU8Nb77IiSpSzc6Bc0kObr9i8RacByz6N/ rF2C1oDy7NhO9rA0mAkOJGxGyYsTBemI285unsLrlWcCjf07PagwJpYxgFU9XDHpdWzo Umog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=o36kdbzBk/M3IbQ67V+1rN+cqsPvxL9s08BJ3HtzjiY=; b=tto+bVEgCTZRadrlWKL8NGITQ/i0C2ddrQEg4grMvuST88325r/4zrRdF1OvGCxTJQ 8fYPtv18sGOZwCG8qEKFlkVH73soTmusgN717tdyRIYoRhu+Lney7byIQUYUnvvuw59I TfRFlkjn6RsILbqi9eZY6FwRcsAC/hlpC30Sent5uTFoY4WOi9YtMDByHSEAofmtIXOl i7K5AXafIfKKpU7H0+93vXX/MMVLSZmcqEu85TtH7TzheIidi06loODUWPQ9IlnOkv7d bUdapworaaaegWaYdzQWlsShZ/OCnaKnZn9FswnOxG6tVddVh8qFGJUwUITtgHqOwMAD S1og== X-Gm-Message-State: AMke39mjyEdJ8RVp7mqeW+qHJo9gwclxMQBoAzb0rd/WeiEihPPPTkq2Efe9mxaAQTbWWTtDPtHjPmwvmnd3/5L4 X-Received: by 10.55.42.207 with SMTP id q76mr6717294qkq.35.1486940246949; Sun, 12 Feb 2017 14:57:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Sun, 12 Feb 2017 14:56:56 -0800 (PST) In-Reply-To: References: <20170211224923.78115C0660@smtp.hushmail.com> <667F88F0-FD47-41C6-8A66-581070395FC0@vpnc.org> From: Warren Kumari Date: Sun, 12 Feb 2017 17:56:56 -0500 Message-ID: To: George Michaelson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dnsop Subject: Re: [DNSOP] DNS-Server distribution statistics X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 22:57:30 -0000 On Sun, Feb 12, 2017 at 5:44 PM, George Michaelson wrote= : > I have never entirely got with the people who think obscuring version > information is necessary and correct. Designing for the bad actors > presupposes they will somehow magically not attack you, simply because > you obscured the version info. > > Root ops (I may misremember) stand out in my mind as a group who have > from time to time said "we don't feel we need, or should tell you > that" > > So on the whole, I think we should explore this "what version are you" > question more, and possibly do better at flagging it. > > Having said which: people lie all the time. Either by intent, or > because they reply with information which was correct when they set > it, but has aged out. https://puck.nether.net/~jared/version.bind.results.20160402.txt What?!!!! You don't believe that there is at least one person running version 3.14159? How 'bout "19,800yen"? Surely you don't doubt that "An Italian is COMBING his hair in suburban DES MOINES!" Still, nice to know that someone is keeping the love with a "C=3D64 with Final Cartridge II and 1541 discdrive" W > So even with the best of intentions, > version-flagging needs to be taken with a grain of salt. > > -G > > On Sun, Feb 12, 2017 at 9:55 PM, Woodworth, John R > wrote: >> -----Original Message----- >> From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Paul Hoffman >>> >>> On 11 Feb 2017, at 17:49, Allan Liska wrote: >>> >>> > ISC runs a monthly survey of DNS statistics: >>> > https://ftp.isc.org/www/survey/reports/current/fpdns.txt (this is fro= m >>> > January 2017). >>> > Information about the survey is here: >>> > https://ftp.isc.org/www/survey/reports/current/survey.html >>> > Not sure how useful their data is, but they have been doing it for a >>> > long time, so they have great trending analysis. >>> >>> Do note, however, that fingerprinting DNS servers has gotten much harde= r >>> over time, so take the results with a very large grain of salt. For >>> example, the software that runs that survey seems to think that there >>> are no versions of BIND 9 since 9.4.0a0. >>> >> >> Thanks Paul! >> >> I was wondering about that. Figured there would be more people at least >> near the bleeding-edge. >> >> >> Thanks, >> John >> >>> --Paul Hoffman >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> >> -- THESE ARE THE DROIDS TO WHOM I REFER: >> This communication is the property of CenturyLink and may contain confid= ential or privileged information. Unauthorized use of this communication is= strictly prohibited and may be unlawful. If you have received this communi= cation in error, please immediately notify the sender by reply e-mail and d= estroy all copies of the communication and any attachments. >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sun Feb 12 16:25:34 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8331294B8 for ; Sun, 12 Feb 2017 16:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxrDmsBx7nf0 for ; Sun, 12 Feb 2017 16:25:30 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 E7703129417 for ; Sun, 12 Feb 2017 16:25:29 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id c7so62141880itd.1 for ; Sun, 12 Feb 2017 16:25:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s2NFUR533zvY1yDb2unu6JH8WjlVEK06uJdGz3mtN80=; b=UpsmQEA9Bd74NwXb3SO0q+Im/dQE+wS0p5Xsh2qTtKWdCmUIsF/UWEsBTMHc36AlFj 2ypvuqo6usoroyItRT3gr2NQpgJXemtyuRUtUeyZlw9i0oxU1wMsYZkCltKeizrnqzBu QOMnH8CD0VMxsJRFEg3NjPp1CksKaDPtbA3AP4CyMQSqnEo08yvsD0BC+vH6Lw8ATE/+ Uyf3Dd4Ci6lRuNfrZ0Y0Coa8ilmiy0hVrduBQPrhv/homhixmoQmO4hIicKe5RjLlcfM 5/VuGhvaGaK70ttfNW2lqKowpySk0nLix9NSbhclozXfWvwsQ71gMMHSSw0UvVajG4hg Ydhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s2NFUR533zvY1yDb2unu6JH8WjlVEK06uJdGz3mtN80=; b=KtSu90s1c/OxDoqKMmVDkgDEMD2DIEkxm+XuZpnL3zE2CpBRUbu1ucGzJsbIwA0HkC NgVyzZnmlCeCH+QSKwxrrB5Cd3A9vU7P0YTITV8od0KnzJ6bqb1TpV10OXnktAYxiN7h ZvGyXc2ru+tcoWlkXHdWZqjN/3a+2vpX5UE5sh9U5Il3+radZNsFTSmtklXTFP1ec1d+ R9pg4oH7bKcywBP4n1gunEr3tzZbcKHCsFFTxQq5TD11p6v76gJamkEQo+ogDPafGRwi hEE2EUtuVY2ZuTBFl6jQoDo4zL3wtM5q2drkkJ4mBbpkHFCdWvJ1rOdrBp8susZeoCn8 v6CQ== X-Gm-Message-State: AMke39lvhHJ8UcXYMGrd2zaK90g7pgAT2CrJqdoNWs1a57FIx1lN6WSmp9EFeVgHJyheO9Throxtkz0grwiz7Q== X-Received: by 10.107.147.6 with SMTP id v6mr21141864iod.235.1486945529218; Sun, 12 Feb 2017 16:25:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.159.209 with HTTP; Sun, 12 Feb 2017 16:25:28 -0800 (PST) In-Reply-To: References: <20170211224923.78115C0660@smtp.hushmail.com> <667F88F0-FD47-41C6-8A66-581070395FC0@vpnc.org> From: william manning Date: Sun, 12 Feb 2017 16:25:28 -0800 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=94eb2c05be5611d1f305485e7c73 Archived-At: Cc: dnsop , George Michaelson Subject: Re: [DNSOP] DNS-Server distribution statistics X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 00:25:32 -0000 --94eb2c05be5611d1f305485e7c73 Content-Type: text/plain; charset=UTF-8 which is why, Warren, that modern fingerprinting does not rely on what the server lies about. /W On Sun, Feb 12, 2017 at 2:56 PM, Warren Kumari wrote: > On Sun, Feb 12, 2017 at 5:44 PM, George Michaelson > wrote: > > I have never entirely got with the people who think obscuring version > > information is necessary and correct. Designing for the bad actors > > presupposes they will somehow magically not attack you, simply because > > you obscured the version info. > > > > Root ops (I may misremember) stand out in my mind as a group who have > > from time to time said "we don't feel we need, or should tell you > > that" > > > > So on the whole, I think we should explore this "what version are you" > > question more, and possibly do better at flagging it. > > > > Having said which: people lie all the time. Either by intent, or > > because they reply with information which was correct when they set > > it, but has aged out. > > https://puck.nether.net/~jared/version.bind.results.20160402.txt > > What?!!!! You don't believe that there is at least one person running > version 3.14159? How 'bout "19,800yen"? > Surely you don't doubt that "An Italian is COMBING his hair in > suburban DES MOINES!" > > Still, nice to know that someone is keeping the love with a "C=64 with > Final Cartridge II and 1541 discdrive" > > W > > > > So even with the best of intentions, > > version-flagging needs to be taken with a grain of salt. > > > > -G > > > > On Sun, Feb 12, 2017 at 9:55 PM, Woodworth, John R > > wrote: > >> -----Original Message----- > >> From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Paul Hoffman > >>> > >>> On 11 Feb 2017, at 17:49, Allan Liska wrote: > >>> > >>> > ISC runs a monthly survey of DNS statistics: > >>> > https://ftp.isc.org/www/survey/reports/current/fpdns.txt (this is > from > >>> > January 2017). > >>> > Information about the survey is here: > >>> > https://ftp.isc.org/www/survey/reports/current/survey.html > >>> > Not sure how useful their data is, but they have been doing it for a > >>> > long time, so they have great trending analysis. > >>> > >>> Do note, however, that fingerprinting DNS servers has gotten much > harder > >>> over time, so take the results with a very large grain of salt. For > >>> example, the software that runs that survey seems to think that there > >>> are no versions of BIND 9 since 9.4.0a0. > >>> > >> > >> Thanks Paul! > >> > >> I was wondering about that. Figured there would be more people at least > >> near the bleeding-edge. > >> > >> > >> Thanks, > >> John > >> > >>> --Paul Hoffman > >>> > >>> _______________________________________________ > >>> DNSOP mailing list > >>> DNSOP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dnsop > >> > >> > >> -- THESE ARE THE DROIDS TO WHOM I REFER: > >> This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender > by reply e-mail and destroy all copies of the communication and any > attachments. > >> > >> _______________________________________________ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c05be5611d1f305485e7c73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
which is why, Warren, that modern fingerprinting does not = rely on what the server lies about. =C2=A0

/W

On Sun, Feb 12, = 2017 at 2:56 PM, Warren Kumari <warren@kumari.net> wrote:
On Sun, Feb 12, 2017 at 5:= 44 PM, George Michaelson <ggm@algebr= as.org> wrote:
> I have never entirely got with the people who think obscuring version<= br> > information is necessary and correct. Designing for the bad actors
> presupposes they will somehow magically not attack you, simply because=
> you obscured the version info.
>
> Root ops (I may misremember) stand out in my mind as a group who have<= br> > from time to time said "we don't feel we need, or should tell= you
> that"
>
> So on the whole, I think we should explore this "what version are= you"
> question more, and possibly do better at flagging it.
>
> Having said which: people lie all the time. Either by intent, or
> because they reply with information which was correct when they set > it, but has aged out.

https://puck.nether.net/~jared/version.bind.results.20160402.txt

What?!!!! You don't believe that there is at least one person running version 3.14159? How 'bout "19,800yen"?
Surely you don't doubt that "An Italian is COMBING his hair in
suburban DES MOINES!"

Still, nice to know that someone is keeping the love with a "C=3D64 wi= th
Final Cartridge II and 1541 discdrive"

W


> So even with the best of intentions,
> version-flagging needs to be taken with a grain of salt.
>
> -G
>
> On Sun, Feb 12, 2017 at 9:55 PM, Woodworth, John R
> <John.Woodworth@c= enturylink.com> wrote:
>> -----Original Message-----
>> From: DNSOP [mailto:dnso= p-bounces@ietf.org] On Behalf Of Paul Hoffman
>>>
>>> On 11 Feb 2017, at 17:49, Allan Liska wrote:
>>>
>>> > ISC runs a monthly survey of DNS statistics:
>>> > https://ftp.isc.org/www/survey/reports/current/fpdns.txt (this is from
>>> > January 2017).
>>> > Information about the survey is here:
>>> > https://ftp.isc.org/www/= survey/reports/current/survey.html
>>> > Not sure how useful their data is, but they have been doi= ng it for a
>>> > long time, so they have great trending analysis.
>>>
>>> Do note, however, that fingerprinting DNS servers has gotten m= uch harder
>>> over time, so take the results with a very large grain of salt= . For
>>> example, the software that runs that survey seems to think tha= t there
>>> are no versions of BIND 9 since 9.4.0a0.
>>>
>>
>> Thanks Paul!
>>
>> I was wondering about that.=C2=A0 Figured there would be more peop= le at least
>> near the bleeding-edge.
>>
>>
>> Thanks,
>> John
>>
>>> --Paul Hoffman
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/d= nsop
>>
>>
>> -- THESE ARE THE DROIDS TO WHOM I REFER:
>> This communication is the property of CenturyLink and may contain = confidential or privileged information. Unauthorized use of this communicat= ion is strictly prohibited and may be unlawful. If you have received this c= ommunication in error, please immediately notify the sender by reply e-mail= and destroy all copies of the communication and any attachments.
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop=
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop=



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--94eb2c05be5611d1f305485e7c73-- From nobody Mon Feb 13 05:03:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C23129656 for ; Mon, 13 Feb 2017 05:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 pSViZNrhHYpy for ; Mon, 13 Feb 2017 05:03:24 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) by ietfa.amsl.com (Postfix) with ESMTP id CE2BB12965B for ; Mon, 13 Feb 2017 05:03:19 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:53279) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cdGHn-000sAJ-00 (Exim 4.88) (return-path ); Mon, 13 Feb 2017 13:03:19 +0000 Date: Mon, 13 Feb 2017 13:03:18 +0000 From: Tony Finch To: Richard Gibson In-Reply-To: Message-ID: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: =?UTF-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 13:03:26 -0000 Richard Gibson wrote: > Because without such a signal, humans using ANY for legitimate diagnostic > purposes have no means of differentiating section 4.1/4.3 "subset" > responses from conventional responses where there just happen to be only a > small number of RRSets at the queried name, encouraging (or at least doing > nothing to dissuade) a conclusion that the response is in fact conventional > and complete. There are several ways to avoid this pitfall: Use TCP Look for an NSEC(3) record Query for the specific types you want to know about Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Irish Sea: East 7 to severe gale 9, occasionally storm 10 at first near welsh coast, veering southeast 5 to 7. Moderate or rough. Mainly fair. Moderate or good. From nobody Mon Feb 13 06:33:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49315129633 for ; Mon, 13 Feb 2017 06:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 iugFR-bq1p5V for ; Mon, 13 Feb 2017 06:33:57 -0800 (PST) Received: from mail-ua0-x245.google.com (mail-ua0-x245.google.com [IPv6:2607:f8b0:400c:c08::245]) (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 F25331295E0 for ; Mon, 13 Feb 2017 06:33:56 -0800 (PST) Received: by mail-ua0-x245.google.com with SMTP id d5so69964281uag.5 for ; Mon, 13 Feb 2017 06:33:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HfzkQOHpGAjLauhCZ9XobXEuap1XG1oOzSnFV03JITs=; b=MXK4eQpI9JTdoqp/1scBvRu0qGnDXL0PL6EdqDLxTbCR3YvePFRk9Rw0ricxBJu0Hz HQcD9WWhBWZW8o3vRdAi4BoH0VEzV1KORlsaxti1aOWXRjui5e/A0fEudAW0jOk5kZ8b NhxW2Wa3LU3s3ftRzTMv+oSqkMhR5U+8yMKUI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HfzkQOHpGAjLauhCZ9XobXEuap1XG1oOzSnFV03JITs=; b=Sm0XjqJqx5aFHGw3ygIHbBJHDWCcpQOZQzDAwNlyHVEF1lunKzvnJLyT6ZKw8FeWpT +oI/qp2/5uBa5sH6Sco7UiAXZmCI8hQhGlNs+fTp8WAHZR90O9iY9GR8ZAWxpVQtZx6N 6iqPVs2YOiBTTfnmmysSFuDwzVFuqGa2LLN6Bsmnw2PUPeiJXCAjSZffNiKVhMvP0WDs FyzZHr0KHaWZ68wb8COTLGDvoO4nRw4Qh1OerOJJ7EgeaxlCmO41CZNwLfkMalHn1lmx o4NyzW9gZf5Hk9yG/Dyxm1HCl+8qHjBVmYpU53AVzSAbGzf7g10m75M9dmtINj2HNuBE 7PaA== X-Gm-Message-State: AMke39l8KfXJ1DbbGOZr3SJi3fEq7KWanJnwcSqYz6gl/SoNKIHtq8Fkx+vlwk3horqbCxc6jP7XLyKsnLjll1ZW X-Received: by 10.159.34.228 with SMTP id 91mr12065270uan.159.1486996436075; Mon, 13 Feb 2017 06:33:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.5.131 with HTTP; Mon, 13 Feb 2017 06:33:35 -0800 (PST) In-Reply-To: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> From: Richard Gibson Date: Mon, 13 Feb 2017 09:33:35 -0500 Message-ID: To: Tony Finch Content-Type: multipart/alternative; boundary=94eb2c03bb665afad805486a56a1 Archived-At: Cc: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 14:33:58 -0000 --94eb2c03bb665afad805486a56a1 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 13, 2017 at 8:03 AM, Tony Finch wrote: > There are several ways to avoid this pitfall: > > Use TCP > > Look for an NSEC(3) record > > Query for the specific types you want to know about The pitfall comes from unexamined muscle-memory assumptions when inspecting a DNS response, so none of those methods avoid it. They're expecting people to remember that longstanding behavior has changed without providing any clue about it. --94eb2c03bb665afad805486a56a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 13, 2017 at 8:03 AM, Tony Finch <dot@dotat.at> wrote:
=
There are several ways to= avoid this pitfall:

Use TCP

Look for an NSEC(3) record

Query for the specific types you want to know about

The pitfall comes from unexamined muscle-memory assumptions=C2=A0w= hen inspecting a DNS response, so none of those methods avoid it. They'= re expecting people to remember that longstanding behavior has changed with= out providing any clue about it.
--94eb2c03bb665afad805486a56a1-- From nobody Mon Feb 13 08:46:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BBC1295A5 for ; Mon, 13 Feb 2017 08:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 yn94QR0cguTB for ; Mon, 13 Feb 2017 08:46:04 -0800 (PST) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5391295AE for ; Mon, 13 Feb 2017 08:46:04 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:33145) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cdJlL-000Irn-ga (Exim 4.88) (return-path ); Mon, 13 Feb 2017 16:46:03 +0000 Date: Mon, 13 Feb 2017 16:46:03 +0000 From: Tony Finch To: Richard Gibson In-Reply-To: Message-ID: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: =?UTF-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 16:46:05 -0000 Richard Gibson wrote: > > The pitfall comes from unexamined muscle-memory assumptions when inspecting > a DNS response, so none of those methods avoid it. They're expecting people > to remember that longstanding behavior has changed without providing any > clue about it. OK. But does an EDNS flag help? What if you are using old tools? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Hebrides, Bailey: Southeasterly 5 to 7, occasionally gale 8 in south. Rough, becoming very rough for a time in south. Fair. Good. From nobody Mon Feb 13 09:06:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0101296B2 for ; Mon, 13 Feb 2017 09:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 d8NqKpJsmp_V for ; Mon, 13 Feb 2017 09:06:36 -0800 (PST) Received: from mail-vk0-x247.google.com (mail-vk0-x247.google.com [IPv6:2607:f8b0:400c:c05::247]) (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 2A0E4128B38 for ; Mon, 13 Feb 2017 09:06:36 -0800 (PST) Received: by mail-vk0-x247.google.com with SMTP id t8so70480091vke.3 for ; Mon, 13 Feb 2017 09:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wvJEGi7OsE3XWseTlrc0fMdmPP2reBU9Fs+P5P7PruY=; b=lEcTUqoIEJH/oqxm7okX6fHFNla0GKmH4INT3rnfi6zZZyN058NcjzqOhsj0yCF1TG EoMhD7sHJNWErbcELginacmtokvsumnbzBAkW5BUxHfP3Kk3Mvwbq/GBN68wW6i0zVmt teSktxF7QWg2FSIzzJGn8b2xhlWQXNYzUUR5Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wvJEGi7OsE3XWseTlrc0fMdmPP2reBU9Fs+P5P7PruY=; b=IU/MIX9Ig25qj5ZrZFCYM7p64jr+j4FGSsNDsedR0CL5wpcslBGuSTd0ooYWBcQhvS qm6sSLUngrqcBwlhLSwuaxVizSSTfB6jYz8SJOop1Loc4Zs6uC5xUyG4SqfUi+sjxdGl bRYJ6VIb2wMN7PJ0UWkBbbjPtK5g6fF360x8dv/cVrxJ/l5rcSlHCoxdmbZ4Am5ErIa0 IRYK3cMJ/gRC56jUxflNmCr0oaEV3G7NYAcpziATHBvzwKGnUn98jhrT7x0kU2/HyJNX thUEOG4UQ0OTxyZfk+W/zWg36YxQj1b7bVxxKCX+iaPmeoAI7n0yu9HA4aB8wBMkHAQ5 e5tg== X-Gm-Message-State: AMke39l6bGKOmb3W6V1qSuylIZQGpen4eMQ9iQ/nz+D3ZWhOije7/uJic0oV13EsLgl1/i6xXDxeBqf+rQuncJjv X-Received: by 10.31.173.69 with SMTP id w66mr11758412vke.127.1487005595145; Mon, 13 Feb 2017 09:06:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.5.131 with HTTP; Mon, 13 Feb 2017 09:06:14 -0800 (PST) In-Reply-To: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> From: Richard Gibson Date: Mon, 13 Feb 2017 12:06:14 -0500 Message-ID: To: Tony Finch Content-Type: multipart/alternative; boundary=001a1143fcd2472aa005486c7811 Archived-At: Cc: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 17:06:37 -0000 --001a1143fcd2472aa005486c7811 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 13, 2017 at 11:46 AM, Tony Finch wrote: > OK. But does an EDNS flag help? What if you are using old tools? If you are using old tools, then you don't get new conveniences (the same is true of using OPT class to specify a maximum payload size exceeding 512 bytes, using the DO bit to request DNSSEC records, and using the COOKIE option for authentication). But a flag would still be there, conveying information even if any given client or tool isn't looking for it. --001a1143fcd2472aa005486c7811 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 13, 2017 at 11:46 AM, Tony Finch <dot@dotat.at> wrote:
OK. But does an EDNS fla= g help? What if you are using old tools?

If= you are using old tools, then you don't get new conveniences (the same= is true of using OPT class to specify a maximum payload size exceeding 512= bytes,=C2=A0using the DO bit to request DNSSEC records, and using the COOK= IE option for authentication). But a flag would still be there, conveying i= nformation even if any given client or tool isn't looking for it.
=
--001a1143fcd2472aa005486c7811-- From nobody Mon Feb 13 09:38:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADA4126DFB for ; Mon, 13 Feb 2017 09:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 fRbk4YRY7FEa for ; Mon, 13 Feb 2017 09:38:02 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07171293EB for ; Mon, 13 Feb 2017 09:38:01 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id 0C52212C0E75; Mon, 13 Feb 2017 12:38:01 -0500 (EST) Date: Mon, 13 Feb 2017 12:38:01 -0500 From: Robert Edmonds To: Richard Gibson Message-ID: <20170213173801.j7dpxzjy5morksg5@mycre.ws> References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Cc: Tony Finch , =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 17:38:05 -0000 Richard Gibson wrote: > On Mon, Feb 13, 2017 at 11:46 AM, Tony Finch wrote: > > > OK. But does an EDNS flag help? What if you are using old tools? > > > If you are using old tools, then you don't get new conveniences (the same > is true of using OPT class to specify a maximum payload size exceeding 512 > bytes, using the DO bit to request DNSSEC records, and using the COOKIE > option for authentication). But a flag would still be there, conveying > information even if any given client or tool isn't looking for it. It looks like dig does display unknown EDNS flags -- as a masked hex value: https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=lib/dns/message.c;h=45bd0ba9ea31be49ffa5bca2aebb77ebc2f3b95c;hb=4801fbccaa431ca6a72753150cbb58e5d4627cc4#l3408 You think this would actually provide any sort of useful information? No operator would understand what "MBZ: 0xNNNN" means without re-training, and if you're re-training operators you may as well point them to this document. -- Robert Edmonds From nobody Mon Feb 13 09:50:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1039C129441 for ; Mon, 13 Feb 2017 09:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 8hMwy_KNVV1R for ; Mon, 13 Feb 2017 09:50:37 -0800 (PST) Received: from mail-vk0-x247.google.com (mail-vk0-x247.google.com [IPv6:2607:f8b0:400c:c05::247]) (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 AA333129559 for ; Mon, 13 Feb 2017 09:50:37 -0800 (PST) Received: by mail-vk0-x247.google.com with SMTP id x75so70896187vke.5 for ; Mon, 13 Feb 2017 09:50:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LoEAg7zlmdIx8Pw5P5+5NmgmSBmLRdbZmqYgk/071Zo=; b=CXWrKSE9I0JghfkemCeYh+Rs4HPUJMXGWSydFg9Va7n7MHCax7QsPwhx2sAbhvqjvo 39DPb0D3+wV9Gj1LFCcyDzfX7m3XOD6hz7kmHXB5p5F7DFKhDHwnNwCbWa7P56QDeKrK SD/WBodfGRb9AXE/4qpyS/QYTbUCrgUGk7h8g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LoEAg7zlmdIx8Pw5P5+5NmgmSBmLRdbZmqYgk/071Zo=; b=TDeXuDbmETzioX86jy7SzvxzXJQ4nTkCFvqIs5im3ixqdSIIQ3Pr8kz/SGoZtmv+Ug eJpiOilN0T3GY1gqqFD8o6vcY4upirR39IYeaSm61noGWf14FhAieMa+78Td6p6Eu8Fe buzrNGk9ChuWfIz6HTfscQDS+QIeuhjpd8z/dEeb5gJrmJjAXEeTtnDeNYc7JT7N+vaz 3oVrhCXfAIm+oJjRFm+dn94KMlx+x5yLgc1QtC+mUYe5cXKEzU1p3nVGYpka2a2prg6S Dbn3bReLATj8zof3RVo9WNKuJyPda/S4mcjBirIdeBaIR9Ao5PWacfG/aoJ1XH6cMa0o Jx9w== X-Gm-Message-State: AMke39ls+y/B0foPN5+ZN0LAsTKZy68fQyC2qC/1q+ri5fT8eBbMnpcixhJK8nesGeQMEbI/aEs8YDXRCsRyCE/u X-Received: by 10.31.98.196 with SMTP id w187mr10325617vkb.169.1487008236787; Mon, 13 Feb 2017 09:50:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.5.131 with HTTP; Mon, 13 Feb 2017 09:50:16 -0800 (PST) In-Reply-To: <20170213173801.j7dpxzjy5morksg5@mycre.ws> References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> <20170213173801.j7dpxzjy5morksg5@mycre.ws> From: Richard Gibson Date: Mon, 13 Feb 2017 12:50:16 -0500 Message-ID: To: Robert Edmonds Content-Type: multipart/alternative; boundary=94eb2c07b57abb723105486d15f9 Archived-At: Cc: Tony Finch , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 17:50:39 -0000 --94eb2c07b57abb723105486d15f9 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds wrote: > You think this would actually provide any sort of useful information? No > operator would understand what "MBZ: 0xNNNN" means without re-training, > and if you're re-training operators you may as well point them to this > document. I think it would be _very_ useful. People easily forget new information, but seeing unexpected data like that would provide the necessary trigger for remembering this document and e.g. retrying with +tcp. --94eb2c07b57abb723105486d15f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 13, 2017 at 12:38 PM, Robert Edmonds <edmonds@mycre.ws> wrote:
You think this would actually= provide any sort of useful information? No
operator would understand what "MBZ: 0xNNNN" means without re-tra= ining,
and if you're re-training operators you may as well point them to this<= br> document.

I think it would be _very_ useful= . People easily forget new information, but seeing unexpected data like tha= t would provide the necessary trigger for remembering this document and e.g= . retrying with +tcp.
--94eb2c07b57abb723105486d15f9-- From nobody Mon Feb 13 10:03:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2CE129722 for ; Mon, 13 Feb 2017 10:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 MmUSqaBU8EfS for ; Mon, 13 Feb 2017 10:03:00 -0800 (PST) Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693EB129735 for ; Mon, 13 Feb 2017 10:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=883; q=dns/txt; s=VRSN; t=1487008981; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bqRcOSKYRLDGcmq9389GuwEV1GcrT+rrCkoUnx/VAKI=; b=DrTZbvDtanWa7JdYUkVmMUkwI4p8l3ggQvVjc+HpgBO1R87ANM8JJ6AL iBAI1IjkIIb0McZV0LE+768FxCMKbA1R92Xert+R50wtNVjdhVAiwi7/Q tVwmifZ97UMciOlG+zg6WFbMuwMf7NNEwXfA25XsERfN/lmnybw1gAOoR aqifMc2fRBrrwcqiJ6CpQ5V+JjhLLvEHu2JKJhMHez76/VCvGuXsF9dMe JuMuJCImujXFqfadN7JZkFSqs0wrNHDpeizgRwWqA80beem8oRicxOlrw BzB9YNdfVl4QfMslyg3jX8AHFhdkYsIkEjJFjcmkwTRETXrQtF3GRcCf7 Q==; X-IronPort-AV: E=Sophos;i="5.35,156,1484006400"; d="scan'208";a="1660282" IronPort-PHdr: =?us-ascii?q?9a23=3AQKlXyxPwm2lnL+kJ+uUl6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0K/z5o8bcNUDSrc9gkEXOFd2CrakV16yH6Ou5ATFIyK3CmUhKSIZLWR4BhJ?= =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+?= =?us-ascii?q?KPjrFY7OlcS30P2594HObwlSijewZbx/IA+yoAjfucUanJduJ6YswRbVv3VEfP?= =?us-ascii?q?hby3l1LlyJhRb84cmw/J9n8ytOvv8q6tBNX6bncakmVLJUFDspPXw7683trhnD?= =?us-ascii?q?UBCA5mAAXWUMkxpHGBbK4RfnVZrsqCT6t+592C6HPc3qSL0/RDqv47t3RBLulS?= =?us-ascii?q?wKLCAy/n3JhcNsjaJbuBOhqAJ5w47Ie4GeKf5ycrrAcd8GWWZNW8BcXDFDDIyh?= =?us-ascii?q?dYsCF+oPM/hFoYnhqVUArhW+CgutBOzzxTFHiWT73bEj0+QkDQ3KwBAsE88IvX?= =?us-ascii?q?/JrNv1LqASUeWtwaXGzTrMcehW2Szj54jMaRAtueyHU7xtccXLz0kgCQ3JhUiX?= =?us-ascii?q?pIP4MTKayP8Ns3OF4OpkTuKikHAnpB9rojiu3ccsi4bJhoQPxl/Y8iV5xZ84KN?= =?us-ascii?q?ulQ0B4ed6pCIZcuz2AO4drQM4vTXtktDs6x7AIo5K3YicHxZQ/yxLCd/CLaZWE?= =?us-ascii?q?7xDtWeqLPDt1hGxpdKiwihu07EOu0PfzVtOu31ZPtidFl97MuW0T2BHL8ciHT+?= =?us-ascii?q?d9/l+m2TaSywDf8uFELl4wlarcM5Mu2aQwlpwOvUTHES72nV/5jK6SdkUj5+io?= =?us-ascii?q?9/jrbqv8qp+CKYB0kAD+Mr8vmsywB+Q0KBQBX2+e+eik1b3j+1P2QKlSg/Erjq?= =?us-ascii?q?XVqo3WKMYVq6KjHgNY0ogu5wyhAzqp0NkUhXwHI0hEeBKDgYjpIVbOIPXgAPii?= =?us-ascii?q?jVWjjixrx+vYMb3lGZXANWbDn6n7fbZ88E5cyQUzzdZF651IDbEBJer/WlXtu9?= =?us-ascii?q?zAEh85Lwu0zv76B9V7zYMeXnqPD7SYMKzMrV+I6PgjI+6WZI8aoDz9MeQq5+by?= =?us-ascii?q?jX8lnl8QZa6p3Z8NZ3C2A/RmOV6UbmbogtcGDGcFowQ+TOjwh12YTzFffWq9X6?= =?us-ascii?q?U55jsjEoKpEZ/DRpyxgLyGxCq0A5pWZnxdB1+RFnfoa5+LW+sWZC2IPs9riiYE?= =?us-ascii?q?WqS5S489yRGusxf3xKR6IerR/S0Ys4/s1MNu6u3WlRA96SZ0ANqH32CDVGF+hn?= =?us-ascii?q?kISCMu3KBjvUx9zU+O0bJ3g/xZDtNT/PRJUgEhOJHBz+16Dcr+VR7GfteMGx6a?= =?us-ascii?q?RYCcADoxR8g9i/APaV16HZ32lB/C1TGtBZcZhrrND5sxpPHyxX/0coxCxm3d2a?= =?us-ascii?q?06yxEKX8JJOCfu0qJg+hPICorSu1uUjaexdKsamiXK8THQniK1oEhEXVsoAu3+?= =?us-ascii?q?VncFax6T9Iyh6w=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2GEBAC686FY//WZrQpeHAEBBAEBCgEBFwEBBAEBCgEBhRE?= =?us-ascii?q?Hn0cfkyeCD4IMhiICgi0WAQEBAQEBAQEBAQECgQeCMxsBghoBAQEBAgF5BQsCA?= =?us-ascii?q?QgNAQouMiUCBA4FHIlGsHiLRQEBAQEBAQQBAQEBAQEihk2CBAiCYoRUgzSCMQW?= =?us-ascii?q?QA4tpBgGjGJMVJgGBMVEVTgGGMXWJIYEMAQEB?= Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id v1DI2vIA031443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Feb 2017 13:02:57 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Mon, 13 Feb 2017 13:02:57 -0500 From: "Wessels, Duane" To: Richard Gibson Thread-Topic: [EXTERNAL] Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt Thread-Index: AQHShh/0ljU3SFbXNE6m+ayAmc+93qFnitYAgAADmAA= Date: Mon, 13 Feb 2017 18:02:56 +0000 Message-ID: <49D21A98-86D6-4A91-8456-B64C4F54DB6F@verisign.com> References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> <20170213173801.j7dpxzjy5morksg5@mycre.ws> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9B9736B071759A4A95714E6AE70A4853@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Tony Finch , Robert Edmonds , dnsop , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 18:03:02 -0000 > On Feb 13, 2017, at 9:50 AM, Richard Gibson wrote: >=20 > On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds wrote= : > You think this would actually provide any sort of useful information? No > operator would understand what "MBZ: 0xNNNN" means without re-training, > and if you're re-training operators you may as well point them to this > document. >=20 > I think it would be _very_ useful. People easily forget new information, = but seeing unexpected data like that would provide the necessary trigger fo= r remembering this document and e.g. retrying with +tcp. I dislike the idea of a EDNS "partial response" flag. Tools like dig, when asked to issue an ANY query over UDP can: 1) fail with "ANY over UDP is deprecated", or 2) warn with "ANY over UDP might give partial results", or 3) automatically use TCP DW From nobody Mon Feb 13 10:05:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22FC129793 for ; Mon, 13 Feb 2017 10:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 qcyFsgtcFR-X for ; Mon, 13 Feb 2017 10:05:57 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CA6129722 for ; Mon, 13 Feb 2017 10:05:56 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id 89so156102075wrr.2 for ; Mon, 13 Feb 2017 10:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T8X1LZKNnMNFUX8oPJ17uXNJt7ZIDxOYrvJOaJMa+TI=; b=u8RneP/gPyrR26yFyuv1YfNfDarTH+yC6zX/kf903LxLTGGVGFGmVYzsva3WNO51Fm cyTQsEN+0ls+Uq8+c0OJ/Wb/hPdyRJPAIRwo5J46EUSLptMYwBEaT5eihQibGz0Kt4SM K+q/25Gd8EVedq+8r00aVksciKxHAko30qSls= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T8X1LZKNnMNFUX8oPJ17uXNJt7ZIDxOYrvJOaJMa+TI=; b=td/mw66uEx9L7Sx7rYYVemj/Zw1C9CEfBm5QoWx9kijieErIjQFO11nN4vRVXC01AE i55vay3N1jvgOPzcgGobaEBXFNhxo/ynu7FFQeFd7ST3cmxQszeNgAC/HOUJ2kGpuzQ2 2TfViu/0NxhM/PCCKHyqb2YwgTujqKExCHHqb5g+9IDvVF/f10O6m2WuiHW3mq16zE4I yN5TGjFwQtylYcYAjPTTj/sIMH7NoLG/kOrrb0zz7OXMPlITDu0vNXWHeH8miMn/+tnJ sR+cwQY41foDmlcu9PP3UPa2d4U2xXqrY0+1DlXNGswQpwuXdoemvRg0OpmEVm73pfC/ DfOg== X-Gm-Message-State: AMke39kF2KbW2vEA5ahAaprRGBGz1XC74aR928mrYzgQWpDA9eVqIAAgKXvcMbFQOBYviWULK1rv3ktvX6iOk1Vj X-Received: by 10.223.161.130 with SMTP id u2mr24033108wru.127.1487009154999; Mon, 13 Feb 2017 10:05:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.164.194 with HTTP; Mon, 13 Feb 2017 10:05:53 -0800 (PST) In-Reply-To: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> <20170213173801.j7dpxzjy5morksg5@mycre.ws> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Mon, 13 Feb 2017 10:05:53 -0800 Message-ID: To: Richard Gibson Content-Type: multipart/alternative; boundary=f403045f3ed4766c2f05486d4ca3 Archived-At: Cc: Tony Finch , Robert Edmonds , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 18:05:58 -0000 --f403045f3ed4766c2f05486d4ca3 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 13, 2017 at 9:50 AM, Richard Gibson wrote: > On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds wrote: > >> You think this would actually provide any sort of useful information? No >> operator would understand what "MBZ: 0xNNNN" means without re-training, >> and if you're re-training operators you may as well point them to this >> document. > > > I think it would be _very_ useful. People easily forget new information, > but seeing unexpected data like that would provide the necessary trigger > for remembering this document and e.g. retrying with +tcp. > Richard, HINIFO is such a signal :-) thus your request applies only to Send-one and Send-useful responses. I do not think adding complexity will help at all. ... you want an overhead cost forever just because of "muscle memory" learning curve for few people. Olafur --f403045f3ed4766c2f05486d4ca3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 13, 2017 at 9:50 AM, Richard Gibson <<= a href=3D"mailto:rgibson@dyn.com" target=3D"_blank">rgibson@dyn.com>= wrote:
On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds <edmonds@mycre= .ws> wrote:
You think this wou= ld actually provide any sort of useful information? No
operator would understand what "MBZ: 0xNNNN" means without re-tra= ining,
and if you're re-training operators you may as well point them to this<= br> document.

I think it would be _very_= useful. People easily forget new information, but seeing unexpected data l= ike that would provide the necessary trigger for remembering this document = and e.g. retrying with +tcp.

Richard,=C2=A0
=
HINIFO is such a signal :-)=C2=A0
thus your reques= t applies only to Send-one and Send-useful responses.=C2=A0
I do = not think adding complexity will help at all.=C2=A0

=C2=A0... you want an overhead cost forever just because of "muscle = memory" learning curve for few people.=C2=A0

= Olafur

--f403045f3ed4766c2f05486d4ca3-- From nobody Mon Feb 13 10:15:50 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225B71296F4 for ; Mon, 13 Feb 2017 10:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 B-AiH-_IvmX6 for ; Mon, 13 Feb 2017 10:15:46 -0800 (PST) Received: from mail-ua0-x245.google.com (mail-ua0-x245.google.com [IPv6:2607:f8b0:400c:c08::245]) (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 80EC8129556 for ; Mon, 13 Feb 2017 10:15:46 -0800 (PST) Received: by mail-ua0-x245.google.com with SMTP id j94so76002870uad.0 for ; Mon, 13 Feb 2017 10:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7zmA/T3ZryYUBBlxx/eZeQtWWKJg57U0D75BzpMbP9w=; b=avuKXPWXY5MNABQaQ1ldfI2+oINLQ7cYPnBC0VaZhMmBiHLvfMuUuyacVGelEAbgJD a1ACcEcCsPyNp1TqRs8u1NBIpsEhIH/I6xp6FKrU0x97UbsuUdmNAf6ouUdGagoVHyGL ghVWpsfAPXNzjHaTza8rlpX9+C99uEBVi9knw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7zmA/T3ZryYUBBlxx/eZeQtWWKJg57U0D75BzpMbP9w=; b=sWAqH8fDSTAtpkwVMZ0sScV1AzIL+/aZ+97acMtpp/h6A+8UAzp/jaBSGUNtnFnKji OTjCgUGU+GO6kX0gjB5gnmVTTXIrNNFmI9dJlm1bk6S2UPQn9DMc0Hzxf79Oj6a3A/C/ B8WJyzjaqrZeZxDEInOCGUVR+kz7ZGSciPzBFHLvuKK8sBA+HESIB85REQI3z1piz/rF w8ob6cNQGn0IhdKSTTAlwXNnXylO/JkyDw6rErg5Qf4z50O60rl7rw/KO9Hh/upwtBsG OGOz8VDtq38aAHSVzYNXbxVQAMo8nrQyBotyXD37SymRJoh40+mUWdettKGrt6RlWnaq LYDQ== X-Gm-Message-State: AMke39my4SXdJxEy4dFd1p6X2RrMwog1honNcBoyiUkeW6op+Wq/AOnlgdEE6wWburNVTJqRXeQ+V2HFXUHkoSp2 X-Received: by 10.31.70.66 with SMTP id t63mr8479026vka.19.1487009745578; Mon, 13 Feb 2017 10:15:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.5.131 with HTTP; Mon, 13 Feb 2017 10:15:25 -0800 (PST) In-Reply-To: <49D21A98-86D6-4A91-8456-B64C4F54DB6F@verisign.com> References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> <20170213173801.j7dpxzjy5morksg5@mycre.ws> <49D21A98-86D6-4A91-8456-B64C4F54DB6F@verisign.com> From: Richard Gibson Date: Mon, 13 Feb 2017 13:15:25 -0500 Message-ID: To: "Wessels, Duane" Content-Type: multipart/alternative; boundary=001a11484ae0a9c03805486d6f70 Archived-At: Cc: Tony Finch , Robert Edmonds , dnsop , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 18:15:48 -0000 --001a11484ae0a9c03805486d6f70 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 13, 2017 at 1:02 PM, Wessels, Duane wrote: > Tools like dig, when asked to issue an ANY query over UDP can: > > 1) fail with "ANY over UDP is deprecated", or > That's not true, though, and tools have no way of knowing whether or not such a failure is appropriate without the very signal I'm requesting. 2) warn with "ANY over UDP might give partial results", or > 3) automatically use TCP Regardless of anything else, those are both reasonable. --001a11484ae0a9c03805486d6f70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--001a11484ae0a9c03805486d6f70-- From nobody Mon Feb 13 10:15:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0A5129762 for ; Mon, 13 Feb 2017 10:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 N2Ow_2bnO71l for ; Mon, 13 Feb 2017 10:15:50 -0800 (PST) Received: from mail-ua0-x245.google.com (mail-ua0-x245.google.com [IPv6:2607:f8b0:400c:c08::245]) (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 47953129556 for ; Mon, 13 Feb 2017 10:15:50 -0800 (PST) Received: by mail-ua0-x245.google.com with SMTP id a88so76091902uaa.1 for ; Mon, 13 Feb 2017 10:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BIWI3Hhur/WBWXFO7ctV0kri6mLpoWtCjeFDTcpjAtM=; b=aXFM2ivKG+Uf1x9la+UYmm/e7amobijRm5hHKoB0XU5Yvvn7BnUYrTcC//6e2fUWSd TgnPlo25sCn/CGZTGo7ItuCeaP5WbVQKRtnjnERMexwvw/jocBkVo0CZidqM+zQXd9yc OI9CvD/bL4L42Qavuy+4h/T7BMzCF2VsmBnQg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BIWI3Hhur/WBWXFO7ctV0kri6mLpoWtCjeFDTcpjAtM=; b=Eq8l6vM8xZ2v909PvW5nbXB6NzznumtFYg6/7AWu6OmuRDp6cTqUf+OtUaBcDW9XLN +hBadAErIA66v/HFLQc6wgIJbu1UdBZWKo3oOIzh/33lLYdMMy41lHDUhrFdb3KxnR96 FUTDGNMfL5kVw6pBw2R7I5Sn1oWMt/MBiXtvOax/DlCamG8vN7j5FyaMEoJbVxhZSfhZ OYyUnAbRL9LxIV+raPeHsaoMEkIlmKZHcfL+I0JctVo6EDmx/yL0FQueo/KOSMfwf4Gv OiXPPFke2MYTM+zPuQ3Il/HLH+680BCUKGGWbNBV9t9Wicl0GlvvLslS8HUkEoP0hBi8 tJDg== X-Gm-Message-State: AMke39mqaUXVKFYnyb9ry1xFnQXNEE5vF2zBZg5r70Pt0rIiwYNVZDLPyak4flfhQElujVNGILKXf3Xmf8gx2CEx X-Received: by 10.159.34.228 with SMTP id 91mr12715333uan.159.1487009749361; Mon, 13 Feb 2017 10:15:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.5.131 with HTTP; Mon, 13 Feb 2017 10:15:28 -0800 (PST) In-Reply-To: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> <20170213173801.j7dpxzjy5morksg5@mycre.ws> From: Richard Gibson Date: Mon, 13 Feb 2017 13:15:28 -0500 Message-ID: To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Content-Type: multipart/alternative; boundary=94eb2c03bb66e429f605486d6fbc Archived-At: Cc: Tony Finch , Robert Edmonds , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 18:15:52 -0000 --94eb2c03bb66e429f605486d6fbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 13, 2017 at 1:05 PM, =C3=93lafur Gu=C3=B0mundsson wrote: > HINIFO is such a signal :-) > thus your request applies only to Send-one and Send-useful responses. > Correct, as I covered in my initial message. I do not think adding complexity will help at all. > > ... you want an overhead cost forever just because of "muscle memory" > learning curve for few people. > The overhead is already proposed by this document for name servers to apply special QTYPE=3DANY processing; I'm just advocating for its communication t= o clients. --94eb2c03bb66e429f605486d6fbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 13, 2017 at 1:05 PM, =C3=93lafur Gu=C3=B0mundsson <olafur@clou= dflare.com> wrote:
HINIFO = is such a signal :-)=C2=A0
thus your request applies only to Send-one and Send-useful responses.=

Correct, as I covered in= my initial message.

I do not think adding complex= ity will help at all.=C2=A0

=C2=A0... you want an = overhead cost forever just because of "muscle memory" learning cu= rve for few people.

The o= verhead is already proposed by this document for name servers to apply spec= ial QTYPE=3DANY processing; I'm just advocating for its communication t= o clients.
--94eb2c03bb66e429f605486d6fbc-- From nobody Mon Feb 13 10:31:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D00129795 for ; Mon, 13 Feb 2017 10:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 TaA03RUEKA45 for ; Mon, 13 Feb 2017 10:31:51 -0800 (PST) Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3FE1294A0 for ; Mon, 13 Feb 2017 10:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=813; q=dns/txt; s=VRSN; t=1487010711; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Y5XWgy1qU0tLPXa8z2jHOPcK+kmFB5e1fvekdMS9RN0=; b=TywUah4s9HdwibpABQSluHZNtTa3K2MusitWGUfrmrZZB50CPgRpvxnh BHiJGToIQkI8ktcxX/3FcblRwv7gfMBfC047plbOSqRZZJjjIybo4C6gD C9kEh8roKjP/Taam7mbjgzC+JkK+SFVMMPepPJfeKO5wiq4kre64eukPQ /Jzk/xl8yr0o+w3wq33IY+8hKnSyz2MiFJ+2Ak6Yv3P4AuzpqQwROX3ZD QLvQsF1A2JZQqtCeGMA3AP0K+D6c2RgIT1bOECzu7+r0V085K7BeQ6uGC qp0hb59yowOL0YHOGzj+ea6QQ65PL71cu+tK3ggVjYlCSA4x9Wz7vzlfY w==; X-IronPort-AV: E=Sophos;i="5.35,156,1484006400"; d="scan'208";a="1660567" IronPort-PHdr: =?us-ascii?q?9a23=3ApcVCohHmDX1sMkRLOfj9x51GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ76p86+bnLW6fgltlLVR4KTs6sC0LuK9fG7EjVZuN6oizMrSNR0TRgLiM?= =?us-ascii?q?EbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVr?= =?us-ascii?q?O+/7BpDdj9it1+C15pbffxhEiCCzbL52Ixi6twHcu8cZjYd/N6o91wbCr2dVde?= =?us-ascii?q?hR2W5mP0+YkQzm5se38p5j8iBQtOwk+sVdT6j0fLk2QKJBAjg+PG87+MPktR/Y?= =?us-ascii?q?TQuS/XQcSXkZkgBJAwfe8h73WIr6vzbguep83CmaOtD2TawxVD+/4apnVAPkhS?= =?us-ascii?q?EaPDMi7mrZltJ/g75aoBK5phxw3YjUYJ2ONPFjeq/RZM4WSXZdUspUUSFKH4Gy?= =?us-ascii?q?YJYVD+cZPehWsZTzp0cAoxW9CwmjBuLvxSNHiHD5xqA6z/0hEQTa0AA8A94CrX?= =?us-ascii?q?LZp8j1OqcIVuC1ybHFwTvDYPxIwjf985bHchQ6of2UQLl+f9fRxlMpFwzbgFmb?= =?us-ascii?q?tIvoMC6b1+sTqGib9PRvVea0i2M8tQF+vCKvxsY3ionIiYIVzErI+jl+wIYwPN?= =?us-ascii?q?C1TlNwb928EJZIqi2WK5F6Tt4gTmxmoio2170LtJChcCQUx5kqyAbTZ+Gbf4SS?= =?us-ascii?q?/x7uVuicLS1liH9lZr6znRm//E69wePmTMa0ykxFri9dn9nJsXACygLc59CcSv?= =?us-ascii?q?t44kehwTGP1x3P6u1cIUA7i67bK5k5z7ErjJoTt1nPHiv5mUXzlqCWd0Ek+u+1?= =?us-ascii?q?6+T7frnqu4WQN5FqhQHkM6Qugc2/Aes+MgQUQ2eb/uG82KXi/U3/XrpKkuU7nr?= =?us-ascii?q?TFvJzAOMgWpKC0DxVI3osj5RuzFSmq3dsXkHUfKVJKYhOHj4znO1HUJ/D4CO+y?= =?us-ascii?q?jEmikTh13PDGJaPuApHWLnXYjrfuY6x9609HyAoywtBf4YhYBa0GIPL2QkPxrs?= =?us-ascii?q?DXDgclMwyoxObqEMhy1oUFWWKIGq+UK6LSvkGU5uIhOeWMY5UVuDnlIfg/+/Hu?= =?us-ascii?q?lWM5mUMafaSx2psXbGq3Hvp7I0WDenfjntMBEWAXvgUjQuzqjEeNUSRNaHqoQ6?= =?us-ascii?q?084TQ7Apq8DYjfXoCtnKCB3CCjE5JLYWBGFkuBHmrvd4WYQfgMdDieLdV9kjYc?= =?us-ascii?q?T7iuV5ch1Q2ytA/907doMPfb+igftZLlydd1/PbelRQy9DNoFcSSzXuBTm9vnm?= =?us-ascii?q?kQXT85wLh/oVBhyleEyaV4mfNYFd1I6PNSVQc6M4XRwPF6CtD0QA7OYtCJSFP1?= =?us-ascii?q?CumhVAswRdI42dNGTEd3ANKkxkTZ0CugGLgTv7CaAto/9aeKjFbrIMMogUnLz7?= =?us-ascii?q?Isi0JiCudSPGurzOYr+xfeHJXEl16xiauwdL8d0yiL/2CGmznd9HpEWRJ9BP2W?= =?us-ascii?q?FUsUYVHb+JGgvhvP?= X-IPAS-Result: =?us-ascii?q?A2GEBAAD+6FY//SZrQpeHAEBBAEBCgEBFwEBBAEBCgEBhRE?= =?us-ascii?q?Hn0cfkyeCD4IMhiICgi4XAQEBAQEBAQEBAQECgQeCMxsBghoBAQEBAgF5BQsCA?= =?us-ascii?q?QgNAQouMiUCBA4FiWKxC4tHAQEBAQEFAQEBAQEBIoZNggQIgmKEVIM0gjEFkAO?= =?us-ascii?q?LaQYBlA6IZ4YjkxUhA4E0URUYNgGGMXWJIYEMAQEB?= Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v1DIVmq2011169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Feb 2017 13:31:49 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Mon, 13 Feb 2017 13:31:48 -0500 From: "Wessels, Duane" To: Richard Gibson Thread-Topic: [EXTERNAL] Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt Thread-Index: AQHShh/0ljU3SFbXNE6m+ayAmc+93qFnitYAgAADmACAAANugIAABJOA Date: Mon, 13 Feb 2017 18:31:48 +0000 Message-ID: References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> <20170213173801.j7dpxzjy5morksg5@mycre.ws> <49D21A98-86D6-4A91-8456-B64C4F54DB6F@verisign.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Tony Finch , Robert Edmonds , dnsop , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 18:31:52 -0000 > On Feb 13, 2017, at 10:15 AM, Richard Gibson wrote: >=20 > On Mon, Feb 13, 2017 at 1:02 PM, Wessels, Duane w= rote: > Tools like dig, when asked to issue an ANY query over UDP can: >=20 > 1) fail with "ANY over UDP is deprecated", or >=20 > That's not true, though, and tools have no way of knowing whether or not = such a failure is appropriate without the very signal I'm requesting. Deprecated may not be the best choice of wording, even though it was in the= title of the original draft and got my hopes up. However, the authors of dig and other tools, having read this new RFC, can = decide that they will no longer support ANY over UDP and exit with an error= message saying so and provide hints ("use +tcp") for how to make it work. DW From nobody Mon Feb 13 14:22:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EF612998C for ; Mon, 13 Feb 2017 14:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 RFFKg-Lo5n_q for ; Mon, 13 Feb 2017 14:22:03 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67C71299A2 for ; Mon, 13 Feb 2017 14:21:56 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id A263F3493BC; Mon, 13 Feb 2017 22:21:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8E9BB160073; Mon, 13 Feb 2017 22:21:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7CB9E160072; Mon, 13 Feb 2017 22:21:54 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ByCbSsm5JUEZ; Mon, 13 Feb 2017 22:21:54 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 1408B160053; Mon, 13 Feb 2017 22:21:54 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 436CF6397520; Tue, 14 Feb 2017 09:21:50 +1100 (EST) To: "Wessels, Duane" From: Mark Andrews References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> <20170213173801.j7dpxzjy5morksg5@mycre.ws> <49D21A98-86D6-4A91-8456-B64C4F54DB6F@verisign.com> In-reply-to: Your message of "Mon, 13 Feb 2017 18:31:48 -0000." Date: Tue, 14 Feb 2017 09:21:50 +1100 Message-Id: <20170213222150.436CF6397520@rock.dv.isc.org> Archived-At: Cc: Tony Finch , Robert Edmonds , dnsop , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 22:22:07 -0000 We don't need any new signalling. If the answer is truncated you set tc=1. This works with all existing clients. If there is only a single RRset + RRSIGs then you don't get tc=1 except for traditional space reasons. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 13 14:30:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0F12998C for ; Mon, 13 Feb 2017 14:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.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 flZhPJXW9xUs for ; Mon, 13 Feb 2017 14:29:59 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E1112946E for ; Mon, 13 Feb 2017 14:29:59 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 97962208D7; Mon, 13 Feb 2017 17:29:58 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute4.internal (MEProxy); Mon, 13 Feb 2017 17:29:58 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=ls Fsaooh8ceV0bxQ6uqZpQ/vtPc=; b=d0nId0GJiI+XtdGmzs4bKNt2/k4GXEB8Df Ccy46EpE2+S3UWcqMnA8RPypIdJCyN1VMMUy+myaw24z0HeM8NbpOVGVvuGr0g4X kpaF/uFtg2hGQSXO+jctaHRM+nd/V1hMubLr/NIcLkDhlqQapYTR0ODTAfcTxF+T zD+8CrYa4= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6D0BEAA6C5; Mon, 13 Feb 2017 17:29:58 -0500 (EST) Message-Id: <1487024998.1521302.879922640.52B598B0@webmail.messagingengine.com> From: Tony Finch To: Mark Andrews , "Wessels, Duane" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_148702499815213021" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3dff962b In-Reply-To: <20170213222150.436CF6397520@rock.dv.isc.org> Date: Mon, 13 Feb 2017 22:29:58 +0000 References: <148661979638.4286.4234665114055399732.idtracker@ietfa.amsl.com> <20170213173801.j7dpxzjy5morksg5@mycre.ws> <49D21A98-86D6-4A91-8456-B64C4F54DB6F@verisign.com> <20170213222150.436CF6397520@rock.dv.isc.org> Archived-At: Cc: =?utf-8?Q?=C3=93lafur=20Gu=C3=B0mundsson?= , Robert Edmonds , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 22:30:01 -0000 This is a multi-part message in MIME format. --_----------=_148702499815213021 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Mark Andrews wrote: > > We don't need any new signalling. If the answer is truncated you > set tc=1. This works with all existing clients. One of the points of minimal-any is that the answer is not truncated because you do not want clients to automatically retry over TCP. This is to handle situations where many third-party recursive servers are under attack using one of your names, so the recursive servers are hitting your authoritative servers hard. RRL does not work in this case, because the clients are legitimate recursive servers. You want to give them an answer asap, that they can cache without hitting TCP. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn-- zr8h punycode --_----------=_148702499815213021 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"

Mark Andrews <marka@isc.org> wrote:
>
> We don't need any new signalling.  If the answer is truncated you
> set tc=1.  This works with all existing clients.

One of the points of minimal-any is that the answer is not truncated because you do not want clients to automatically retry over TCP. This is to handle situations where many third-party recursive servers are under attack using one of your names, so the recursive servers are hitting your authoritative servers hard. RRL does not work in this case, because the clients are legitimate recursive servers. You want to give them an answer asap, that they can cache without hitting TCP.

Tony.
--
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode


--_----------=_148702499815213021-- From nobody Mon Feb 13 14:43:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7A31299C2 for ; Mon, 13 Feb 2017 14:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Qe_vpbYzalFW for ; Mon, 13 Feb 2017 14:43:38 -0800 (PST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261AA1299BD for ; Mon, 13 Feb 2017 14:43:38 -0800 (PST) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v1DMhNUw062301 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Mon, 13 Feb 2017 22:43:23 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v1DMhNKr062300 for dnsop@ietf.org; Mon, 13 Feb 2017 22:43:23 GMT Date: Mon, 13 Feb 2017 22:43:23 GMT From: Vernon Schryver Message-Id: <201702132243.v1DMhNKr062300@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: <1487024998.1521302.879922640.52B598B0@webmail.messagingengine.com> X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 22:43:39 -0000 > From: Tony Finch > One of the points of minimal-any is that the answer is not truncated > because you do not want clients to automatically retry over TCP. This is > to handle situations where many third-party recursive servers are under > attack using one of your names, so the recursive servers are hitting > your authoritative servers hard. RRL does not work in this case, because > the clients are legitimate recursive servers. You want to give them an > answer asap, that they can cache without hitting TCP. On the contrary, as that case is described, RRL works fine, and this minimal-any mechanism won't help the obvious attack situation in that might be intended. Each legitimate recursive server will ask once per some TTL and cache the rrsets that it gets. No single legitimate recursive server will make a lot of ANY requests per unit time. An attack that might be intended involves many open recursive servers (perhaps open only local infected eyeball stubs) being hit for only a few requests each (or at least passing on only a few each request) for your names but many all together. However, in that case how many legitimate recursive servers will send ANY requests to authorities? Vernon Schryver vjs@rhyolite.com From nobody Mon Feb 13 15:07:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30011299DE for ; Mon, 13 Feb 2017 15:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 GJ7riXxRcUuE for ; Mon, 13 Feb 2017 15:07:11 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A624129453 for ; Mon, 13 Feb 2017 15:07:11 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B503F3493EF; Mon, 13 Feb 2017 23:07:08 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 98244160053; Mon, 13 Feb 2017 23:07:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7ED70160072; Mon, 13 Feb 2017 23:07:08 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aUWNLZpnaY1y; Mon, 13 Feb 2017 23:07:08 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 26AAA160053; Mon, 13 Feb 2017 23:07:08 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 390AF6397A00; Tue, 14 Feb 2017 10:07:04 +1100 (EST) To: Vernon Schryver From: Mark Andrews References: <201702132243.v1DMhNKr062300@calcite.rhyolite.com> In-reply-to: Your message of "Mon, 13 Feb 2017 22:43:23 +0000." <201702132243.v1DMhNKr062300@calcite.rhyolite.com> Date: Tue, 14 Feb 2017 10:07:04 +1100 Message-Id: <20170213230704.390AF6397A00@rock.dv.isc.org> Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 23:07:12 -0000 In message <201702132243.v1DMhNKr062300@calcite.rhyolite.com>, Vernon Schryver writes: > > From: Tony Finch > > > One of the points of minimal-any is that the answer is not truncated > > because you do not want clients to automatically retry over TCP. This is > > to handle situations where many third-party recursive servers are under > > attack using one of your names, so the recursive servers are hitting > > your authoritative servers hard. RRL does not work in this case, because > > the clients are legitimate recursive servers. You want to give them an > > answer asap, that they can cache without hitting TCP. > > On the contrary, as that case is described, RRL works fine, and > this minimal-any mechanism won't help the obvious attack situation > in that might be intended. > > Each legitimate recursive server will ask once per some TTL and > cache the rrsets that it gets. No single legitimate recursive > server will make a lot of ANY requests per unit time. > > An attack that might be intended involves many open recursive servers > (perhaps open only local infected eyeball stubs) being hit for only a > few requests each (or at least passing on only a few each request) for > your names but many all together. > > However, in that case how many legitimate recursive servers will > send ANY requests to authorities? Any with a empty cache for name when the query comes in and a qtype 255 in the request. The hard part of a 255 request is just having cached negative responses for individual types doesn't result in useful response to the request. You still need to recurse with qtype 255 to get some data to return including NODATA for a ENT. Mark > Vernon Schryver vjs@rhyolite.com > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 13 15:29:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D1D1299F7 for ; Mon, 13 Feb 2017 15:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.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 GQaDLza_Vpd2 for ; Mon, 13 Feb 2017 15:29:51 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4022B129A00 for ; Mon, 13 Feb 2017 15:29:42 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8E1FA20992; Mon, 13 Feb 2017 18:29:41 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute4.internal (MEProxy); Mon, 13 Feb 2017 18:29:41 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=N6 4bL9g1lbZzoBeyqRG9L6gPWRQ=; b=OvMAuTDZ0+GznRqcGvO+mVSqJFQzmrfk7O oAPUTGRuhY+UCLQf0ibhUDTJZY1TZETcSxSmaPuuqlSBZW6bOtgEp1bjdt2Og3L0 Y90Omx458QwGnSvR/1/0fXqWKh3IgQp4y8fnj8U2W8seOq271xkzHZ1sHAylTbgm yJQk9yq7E= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6EB4EAA6C8; Mon, 13 Feb 2017 18:29:41 -0500 (EST) Message-Id: <1487028581.1533622.879980992.48B3C400@webmail.messagingengine.com> From: Tony Finch To: Vernon Schryver , dnsop@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_148702858115336220" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3dff962b References: <201702132243.v1DMhNKr062300@calcite.rhyolite.com> In-Reply-To: <201702132243.v1DMhNKr062300@calcite.rhyolite.com> Date: Mon, 13 Feb 2017 23:29:41 +0000 Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 23:29:53 -0000 This is a multi-part message in MIME format. --_----------=_148702858115336220 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Vernon Schryver wrote: > > From: Tony Finch > > > One of the points of minimal-any is that the answer is not truncated > > because you do not want clients to automatically retry over TCP. > > This is > > to handle situations where many third-party recursive servers > > are under > > attack using one of your names, so the recursive servers are hitting > > your authoritative servers hard. RRL does not work in this case, > > because > > the clients are legitimate recursive servers. You want to give > > them an > > answer asap, that they can cache without hitting TCP. > > On the contrary, as that case is described, RRL works fine, and > this minimal-any mechanism won't help the obvious attack situation > in that might be intended. > > Each legitimate recursive server will ask once per some TTL and > cache the rrsets that it gets. Not if the authoritative server is overloaded and has run out of TCP sockets and is unable to answer the question. The recursive servers will all then be perpetually retrying while the attack continues, so the authoritative servers will never recover from overload. > However, in that case how many legitimate recursive servers will > send ANY requests to authorities? In the case of this attack it was thousands. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn-- zr8h punycode --_----------=_148702858115336220 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"

Vernon Schryver <vjs@rhyolite.com> wrote:
> > From: Tony Finch <dot@dotat.at>
>
> > One of the points of minimal-any is that the answer is not truncated
> > because you do not want clients to automatically retry over TCP. This is
> > to handle situations where many third-party recursive servers are under
> > attack using one of your names, so the recursive servers are hitting
> > your authoritative servers hard. RRL does not work in this case, because
> > the clients are legitimate recursive servers. You want to give them an
> > answer asap, that they can cache without hitting TCP.
>
> On the contrary, as that case is described, RRL works fine, and
> this minimal-any mechanism won't help the obvious attack situation
> in that might be intended.
>
> Each legitimate recursive server will ask once per some TTL and
> cache the rrsets that it gets.

Not if the authoritative server is overloaded and has run out of TCP sockets and is unable to answer the question. The recursive servers will all then be perpetually retrying while the attack continues, so the authoritative servers will never recover from overload.

> However, in that case how many legitimate recursive servers will
> send ANY requests to authorities?

In the case of this attack it was thousands.

Tony.
--
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode


--_----------=_148702858115336220-- From nobody Mon Feb 13 15:34:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C8C12998C for ; Mon, 13 Feb 2017 15:34:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 c2cRGw2qlcoL for ; Mon, 13 Feb 2017 15:34:37 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B94812958B for ; Mon, 13 Feb 2017 15:34:36 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0CCF8284E51; Mon, 13 Feb 2017 23:34:36 +0000 (UTC) Date: Mon, 13 Feb 2017 23:34:35 +0000 From: Viktor Dukhovni To: "dnsop@ietf.org" Message-ID: <20170213233435.GF24579@mournblade.imrryr.org> References: <390DDFE7-E70F-4E4E-96AB-AECFE25672E0@vpnc.org> <310D014B-1B3F-420C-A411-DEF6A67016D5@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <310D014B-1B3F-420C-A411-DEF6A67016D5@icann.org> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] [Ext] A nudge on the new terms in draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dnsop@ietf.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 23:34:39 -0000 On Fri, Feb 10, 2017 at 01:12:28PM +0000, Edward Lewis wrote: > I have a fundamental problem with that, meaning that a document within > DNSOP is defining domain names. Work I did to write (the still in progress) > draft on Domain Names has led me to believe that domain names are a concept > beyond the DNS protocol. On the other hand, the DNS protocol and operators > of it, deserve to have a definition in place, so I'm not totally convinced > this is a bad idea. > > Diving into the definition contained in the draft though, it needs work. Referring to: > > https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04, for "Domain Name" and "Label" : > > ) Domain name: An ordered list of zero or more labels. > > ) Label: An ordered list of zero or more octets and which makes up a > portion of a domain name. > > This is a circular definition which makes it quite meaningless. E.g., "A > is a string of B's" and "B is a component of A." The definition is not as circular as it may seem. A domain is a sequence of labels, and a labels is a sequence of octets. My beef would be with the "zero or more" part, as applied to labels, since zero length labels (if construed as actual labels rather than just termination sentinels) do not occur except to terminate a domain name. Otherwise, if the zero length terminator is a label, then domains have at least one (terminal zero-length) label. I would also be tempted to not designate relative names as "domain names". To me, those are just sequences of labels that make up an initial part of a domain name. Not sure whether such hair splitting is needed. The important take-away from the definitions is that the document defines domain names abstractly, as nodes on a rooted acyclic directed graph with siblings distinguished by distinct non-empty octet strings known as labels. The sequence of labels from a node up to the root is its domain name. Such domain names can then represented in various semantically equivalent forms. -- Viktor. From nobody Mon Feb 13 15:54:52 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C83129436 for ; Mon, 13 Feb 2017 15:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 C-9GoCPy2rUb for ; Mon, 13 Feb 2017 15:54:50 -0800 (PST) Received: from mail-vk0-x248.google.com (mail-vk0-x248.google.com [IPv6:2607:f8b0:400c:c05::248]) (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 E1460129455 for ; Mon, 13 Feb 2017 15:54:49 -0800 (PST) Received: by mail-vk0-x248.google.com with SMTP id k127so76936975vke.7 for ; Mon, 13 Feb 2017 15:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jgG67VBL1BMiTSlVKTo8JmKB9o3W9zcapXFA2j3uXFc=; b=rh5KSQudZJNCu9nJSwhc8ThxB2b/jTwmTW8PvDKlicIdU+p0bENplxIrOldUTmCHUR mL/e6Xt7qHqRZ0VJZoLK8J2reHg4XMX6wxd8a2aAgI04GfpKyboGU58MVJR7nyqR9VpZ V/gwPgYkRoWQqp9F58H1tYS5kFi5z+28EMIUg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jgG67VBL1BMiTSlVKTo8JmKB9o3W9zcapXFA2j3uXFc=; b=tIosShd8xxek5Y2soWtWAmPoeFU4mbMSUWqAA8y8xSttyr6da2c9MgfSgYdJx9HnuX 0viaS0LobsccRwf0WSfcrwLbszxlMjor92uh6Kzre++N/U9K2HhAMjRJpt7DU11GvXlO D7KSVZMUu2i0eZGFIT9u2bVBJBIgHiE+GTNB4RELlHrhTvRnLC///F1VczdZKeMKpwKf 2fS1i+RCXsRe4b5zOkRiFHzW8KKQcUc9yb6h1A7gx3Hv0TBmqFg7ylrVYFKEFabKpAkO u9mRDh5nD70ZCq4lkgc6ztB/qeramdIAapLMoLsvDokPe1blrGjmT4AXiPVIQblwWhnR YJgQ== X-Gm-Message-State: AMke39lQ3YwH2Ks8xJ4KNovxmjX6p77vWJDJsO7bWGYHMx2ANY2M4ZK7uYmNFiD47HXbmzUm6etQUo1wlfjVZTo9 X-Received: by 10.176.81.234 with SMTP id h39mr13948349uaa.83.1487030088833; Mon, 13 Feb 2017 15:54:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.5.131 with HTTP; Mon, 13 Feb 2017 15:54:28 -0800 (PST) In-Reply-To: <20170213233435.GF24579@mournblade.imrryr.org> References: <390DDFE7-E70F-4E4E-96AB-AECFE25672E0@vpnc.org> <310D014B-1B3F-420C-A411-DEF6A67016D5@icann.org> <20170213233435.GF24579@mournblade.imrryr.org> From: Richard Gibson Date: Mon, 13 Feb 2017 18:54:28 -0500 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary=94eb2c19204c37afd60548722c51 Archived-At: Subject: Re: [DNSOP] [Ext] A nudge on the new terms in draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 23:54:51 -0000 --94eb2c19204c37afd60548722c51 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 13, 2017 at 6:34 PM, Viktor Dukhovni wrote: > My beef > would be with the "zero or more" part, as applied to labels, since > zero length labels (if construed as actual labels rather than just > termination sentinels) do not occur except to terminate a domain > name. Otherwise, if the zero length terminator is a label, then > domains have at least one (terminal zero-length) label. > https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/6 --94eb2c19204c37afd60548722c51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 13, 2017 at 6:34 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
My beef
would be with the "zero or more" part, as applied to labels, sinc= e
zero length labels (if construed as actual labels rather than just
termination sentinels) do not occur except to terminate a domain
name.=C2=A0 Otherwise, if the zero length terminator is a label, then
domains have at least one (terminal zero-length) label.
<= /div>
https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issu= es/6
--94eb2c19204c37afd60548722c51-- From nobody Mon Feb 13 16:06:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA3A129460 for ; Mon, 13 Feb 2017 16:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldWUlcmcuq9x for ; Mon, 13 Feb 2017 16:06:55 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 3B358129436 for ; Mon, 13 Feb 2017 16:06:55 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id c7so10063187itd.1 for ; Mon, 13 Feb 2017 16:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=odcAPsGKytvCxYSCUz50al+QY5Xu5fEqJOu1NHG0Rrc=; b=OiIghF9T1Y2t4j6hdGnh50uH0lGOg4P0fLBsicvwUXycHqwdGSy/G34r+4oOWG/sMI xtyZ1fTAk2U/syOSHuC8zj5KMoW6ILm2Kryliu0wduczHas/0t2ix2d+wVjXLah7/OMH AYcRwNGA+F0XAYQdiXOuSlW3n5SKc0Lf/IgK9yp+Cvob7qBZAkVa3BJL2edKDXogK2vX hvM6eJOZrrYWiaqqGnBVQtvd2Jarp+D/wlTiVwYnsDHOir7cFIt6ABkgVarhpwV35GLJ cWBSu4Zs2n01Ws7NIDeXO185y0HbW4IIdMi+NIOEdWe6fcE9dZzowp8czqvzkIghSXh2 ZYwA== 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=odcAPsGKytvCxYSCUz50al+QY5Xu5fEqJOu1NHG0Rrc=; b=Hsgs57TRrmhAZ/Nz3+toDqg7mcNia1R42R1wbwkhjAuV6XwVh+lLdrofOs7SLuSTDH JcyjyKkiqKSz2WTOZapT4gv04/cZcdFoUx+wcJ0wVPjxi5EhqG3RPr4ApMRKO22ft8A6 sXPDYKOCItIiS+wvul+hQ2iGykNxceqioOtvZC3pBy1coZGRL6iY4N1AXGGbfDZQS9f2 jHXSVDrGQWz77Ihp8rE4FPxDlvZZq8yy+2m2gCLD7FJaw959E2jZIEcd4wK9TWjPiJIw yCotHlREo8/4LI+L/Iw6uuUJFGH+BtRpQdIK6Uyl9RCjiSwAT2idu20WO35b1EHNg3va 7weQ== X-Gm-Message-State: AMke39lHJlip/rtPbcMi+0hj1CfpSGT5BgjmZfwQDQWcf1/UgbA4tusHuEusvbsM9O0BGflRhxHWh9gYtoHVbg== X-Received: by 10.107.149.18 with SMTP id x18mr23305260iod.167.1487030814204; Mon, 13 Feb 2017 16:06:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.208 with HTTP; Mon, 13 Feb 2017 16:06:53 -0800 (PST) From: Brian Dickson Date: Mon, 13 Feb 2017 16:06:53 -0800 Message-ID: To: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary=001a1140fee4737a690548725706 Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 00:06:56 -0000 --001a1140fee4737a690548725706 Content-Type: text/plain; charset=UTF-8 > > Richard Gibson wrote: > > Because without such a signal, humans using ANY for legitimate diagnostic > > purposes have no means of differentiating section 4.1/4.3 "subset" > > responses from conventional responses where there just happen to be only > a > > small number of RRSets at the queried name, encouraging (or at least > doing > > nothing to dissuade) a conclusion that the response is in fact > conventional > > and complete. > There are several ways to avoid this pitfall: > Use TCP > Look for an NSEC(3) record > Query for the specific types you want to know about > Tony. I hope it's not too late to discuss additions to the I-D. Sorry for not contributing sooner. So, I have a question about EDNS and DNSSEC (and maybe when DO=1): Suppose a zone is NOT signed, but the requestor uses EDNS (and maybe DO=1). What would resolvers do if they received, in addition to normal RRs, one or more NSEC or NSEC3 records, and no RRSIGs? That would be one way to provide information about RRtypes at the owner name, even if the zone was unsigned. Would it be feasible to limit the behavior of "refuse-any" returning "partial" UDP responses, to situations where EDNS with DO=1 is used? Older resolvers would need to have some method of getting answers, so maybe for those, use the TC=1 method? Specifically: When a QTYPE=ANY is received, respond with some "arbitrary" choice of RRTYPE, and add an unsigned NSEC or NSEC3 record to list RRTYPEs present. In the case of SIGNED zone, returning a random RRtype and including the NSEC/NSEC3 would be ideal for both signaling that "ANY" is not supported, as well as what else to query for. I think NSEC or NSEC3 could be used in an unsigned zone, and generated "on the fly" with trival or empty values for "next owner", with the caveat that it MUST NOT be used for generating negative or empty responses. But that is a stretch, and probably not worth pursuing without some further investigation into resolvers' handling of such unsigned responses inside unsigned zones. (This on-the-fly suggestion is a compromise to avoid the need for NSEC/NSEC3 over unsigned zones, or forcing everything to be signed, which is clearly not yet a reasonable suggestion.) Thoughts? Brian --001a1140fee4737a690548725706 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Richard = Gibson <rgibson at dyn.com> wrote:
> Because without such a signal, humans using ANY for legitimate diagnos= tic
> purposes have no means of differentiating section 4.1/4.3 "= ;subset"
> responses from conventional responses where there jus= t happen to be only a
> small number of RRSets at the queried name, e= ncouraging (or at least doing
> nothing to dissuade) a conclusion tha= t the response is in fact conventional
> and complete.
There are several ways to avoid this pitfall:
Use TCP
Look for an NSEC(3) record
Query for the specific types you want to know about
Tony.

I hope it's not too late to discu= ss additions to the I-D. Sorry for not contributing sooner.

<= /div>
So, I have a question about EDNS and DNSSEC (and maybe when DO=3D= 1):

Suppose a zone is NOT signed, but the requesto= r uses EDNS (and maybe DO=3D1).

What would resolve= rs do if they received, in addition to normal RRs, one or more NSEC or NSEC= 3 records, and no RRSIGs?

That would be one way to= provide information about RRtypes at the owner name, even if the zone was = unsigned.

Would it be feasible to limit the behavi= or of "refuse-any" returning "partial" UDP responses, t= o situations where EDNS with DO=3D1 is used? Older resolvers would need to = have some method of getting answers, so maybe for those, use the TC=3D1 met= hod?

Specifically:
=C2=A0When a QTYPE=3D= ANY is received, respond with some "arbitrary" choice of RRTYPE, = and add an unsigned NSEC or NSEC3 record to list RRTYPEs present.=C2=A0

In the case of SIGNED zone, returning a random RRtype= and including the NSEC/NSEC3 would be ideal for both signaling that "= ANY" is not supported, as well as what else to query for.
I think NSEC or NSEC3 could be used in an unsigned zone, and g= enerated "on the fly" with trival or empty values for "next = owner", with the caveat that it MUST NOT be used for generating negati= ve or empty responses. But that is a stretch, and probably not worth pursui= ng without some further investigation into resolvers' handling of such = unsigned responses inside unsigned zones.

(This on= -the-fly suggestion is a compromise to avoid the need for NSEC/NSEC3 over u= nsigned zones, or forcing everything to be signed, which is clearly not yet= a reasonable suggestion.)

Thoughts?
Bri= an
--001a1140fee4737a690548725706-- From nobody Tue Feb 14 08:30:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDE71296A4 for ; Tue, 14 Feb 2017 08:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 51dfsxr32mNk for ; Tue, 14 Feb 2017 08:30:16 -0800 (PST) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) by ietfa.amsl.com (Postfix) with ESMTP id 97502129692 for ; Tue, 14 Feb 2017 08:30:16 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:36936) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cdfzb-0010yG-iM (Exim 4.88) (return-path ); Tue, 14 Feb 2017 16:30:15 +0000 Date: Tue, 14 Feb 2017 16:30:15 +0000 From: Tony Finch To: Brian Dickson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 16:30:18 -0000 Brian Dickson wrote: > > Would it be feasible to limit the behavior of "refuse-any" returning > "partial" UDP responses, to situations where EDNS with DO=1 is used? No, this is a defence mechanism, so it needs to cope with uncooperative clients. > Older resolvers would need to have some method of getting answers, so > maybe for those, use the TC=1 method? There's no "need", partial answers to QTYPE=ANY interoperate fine. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Trafalgar: Southerly or southwesterly backing southeasterly at times, 4 or 5, increasing 6 or 7 at times. Moderate or rough. Rain or showers. Moderate or good. From nobody Tue Feb 14 10:03:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF71F1294C3 for ; Tue, 14 Feb 2017 10:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 qe8Gem20mJAv for ; Tue, 14 Feb 2017 10:02:59 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 68CFB12949F for ; Tue, 14 Feb 2017 10:02:59 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id x75so42497923itb.0 for ; Tue, 14 Feb 2017 10:02:59 -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=DUR80zzMy8w/Vk79UPXoy+uTJz8UHAt3kZLTkZ0pSzg=; b=v9r21ZnhNsJPaEfbgkNHQdIw9u+JoKJlpTLz6k+CH/3g8nhJSxHiKbr64qt8tdfALI k69Cfkf/lhxkBGNEsGo2x38sssD+lxOFAxqotXHGwZGGxwu8maZ8Rd8NhYApKJIFooLP ZXt25SeulaHNCEXNgEMvqF5t4Ai4hXd6bGRC+RUUjJ6/yV5NZnwVHk0iUjeE4iPu/HeL bOCUUzlu8S5RV++isztU/Z3+u5/e5CkDs7XH/8coMCrwe769VppXCSMAFoJT9DFURjLK g/qRe/vCsNQFMRHHPgXvIn9iCbCmJvPeHZu6iuTfB9mjEPJ5V5RhkPL3bdc6kRlxbD3g jzvA== 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=DUR80zzMy8w/Vk79UPXoy+uTJz8UHAt3kZLTkZ0pSzg=; b=NZrF1monyehJhfEIkOmhtRGIXHo46BJYQJOJA4QXbpAkKxtXEKPeeoaqX+QUahntls MGvSN64apMoO8W2J33VxkYmgoAHvA0GnU8fhktK11AskpNqMU5u+yaB11v23kJ20Urt6 SSDWtzxFQLmDihutm4DaGrB0beBjo6EBHZTIvW1IGTyiaviVPaGN5DzFJWL3/DIjEYyL 3Nn4RCq2IiHp0W/WmcwSIwaGNizr8J7mISUsKpgFQD6C8Hq+fsrgoz2v+kKwkfu1s8v7 uM+y8i901GpRBMG3OwoN2ucoAstzBGW2+6WRHrky0DxutTbq4j6b/XdcDYbiyAJP5wJJ PyXQ== X-Gm-Message-State: AMke39ngQMojqlYGQyLgymvM8I0WA95pqldx9xYRzEkNz/xs8w66EYAz5DfLPhe2qEN+sITu+4DFzlODPWbi9y92 X-Received: by 10.107.34.10 with SMTP id i10mr26408534ioi.41.1487095378076; Tue, 14 Feb 2017 10:02:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.164 with HTTP; Tue, 14 Feb 2017 10:02:57 -0800 (PST) From: Ben Schwartz Date: Tue, 14 Feb 2017 13:02:57 -0500 Message-ID: To: dnsop@ietf.org Content-Type: multipart/alternative; boundary=001a1140ec68c2571d0548815f49 Archived-At: Subject: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 18:03:01 -0000 --001a1140ec68c2571d0548815f49 Content-Type: text/plain; charset=UTF-8 Hi dnsop, I've written a draft proposal to improve the privacy of TLS connections, by letting servers use the DNS to tell clients what SNI to send. https://tools.ietf.org/html/draft-schwartz-dns-sni-01 I've incorporated some helpful feedback [1] from the TLS WG, but now I could use your help analyzing the DNS side. All comments welcome; this draft will change based on your feedback. One particular issue that I could use advice on: should this be a new record type, or should it reuse/repurpose an existing type like SRV or PTR? Thanks, Ben [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html --001a1140ec68c2571d0548815f49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi dnsop,

I've written a= draft proposal to improve the privacy of TLS connections, by letting serve= rs use the DNS to tell clients what SNI to send.

https://tools.ietf.org/html/draft-schwar= tz-dns-sni-01

I've incorporated some helpful fee= dback [1] from the TLS WG, but now I could use your help analyzing the DNS = side. All comments welcome; this draft will change based on your feedback.<= /div>

One particular issue that I could use advice on: s= hould this be a new record type, or should it reuse/repurpose an existing t= ype like SRV or PTR?

Thanks,
Ben

--001a1140ec68c2571d0548815f49-- From nobody Tue Feb 14 11:16:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062FC129771 for ; Tue, 14 Feb 2017 11:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 eYRcZASiJxhK for ; Tue, 14 Feb 2017 11:16:16 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE3B12971B for ; Tue, 14 Feb 2017 11:16:16 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id 3923C12C159E; Tue, 14 Feb 2017 14:16:15 -0500 (EST) Date: Tue, 14 Feb 2017 14:16:15 -0500 From: Robert Edmonds To: Ben Schwartz Message-ID: <20170214191615.rwawyluf6nf4lfnm@mycre.ws> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 19:16:18 -0000 Ben Schwartz wrote: > Hi dnsop, > > I've written a draft proposal to improve the privacy of TLS connections, by > letting servers use the DNS to tell clients what SNI to send. > > https://tools.ietf.org/html/draft-schwartz-dns-sni-01 > > I've incorporated some helpful feedback [1] from the TLS WG, but now I > could use your help analyzing the DNS side. All comments welcome; this > draft will change based on your feedback. > > One particular issue that I could use advice on: should this be a new > record type, or should it reuse/repurpose an existing type like SRV or PTR? > > Thanks, > Ben > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html Hi, Ben: I'm kind of curious: your examples are pretty HTTP-centric, and HTTP already has some pretty strong features for origins to persistently modify how clients perform TLS, i.e., HTTP Strict Transport Security and HTTP Public Key Pinning, along with preloading of those settings by the browser vendors. Why not follow that same model for the functionality in your draft? -- Robert Edmonds From nobody Tue Feb 14 11:25:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E161294C2 for ; Tue, 14 Feb 2017 11:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O1yRDE6SKDW for ; Tue, 14 Feb 2017 11:25:00 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA67129555 for ; Tue, 14 Feb 2017 11:25:00 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vNC6d2ZdLz378; Tue, 14 Feb 2017 20:24:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1487100297; bh=IQ81KCT+2HcZDfQmpvdnCEBoi53lOWlI7pJdiQ8ZqDg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eqtBDffDyeXchmgoZ6MN0a+xisaM/TkQABup4axqTUa4a2EvNVF3ohOTJgDODghgm glU8F9NV7bW+ApNBZ3PpM6voET6L2DvVY6Oc/unD6tNRlZnSudCOIjg27mYW9auMrG xDHEn9YYkfugn8csPmH9YHPsrxTLyl01oT5NcvmM= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id m720gyT_LUFw; Tue, 14 Feb 2017 20:24:54 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 14 Feb 2017 20:24:54 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1F03E2DEFFF; Tue, 14 Feb 2017 14:24:53 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1F03E2DEFFF Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0A15641DA42F; Tue, 14 Feb 2017 14:24:52 -0500 (EST) Date: Tue, 14 Feb 2017 14:24:52 -0500 (EST) From: Paul Wouters To: Ben Schwartz In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 19:25:02 -0000 On Tue, 14 Feb 2017, Ben Schwartz wrote: > I've written a draft proposal to improve the privacy of TLS connections, by letting servers use the DNS to tell clients what SNI > to send. > > https://tools.ietf.org/html/draft-schwartz-dns-sni-01 > I've incorporated some helpful feedback [1] from the TLS WG, but now I could use your help analyzing the DNS side. All comments > welcome; this draft will change based on your feedback. This seems like a bandaid to TLS that I think just needs fixing in the TLS protocol. If I was a passive attacker logging lots of traffic, I would just query the SNI's of all major sites (and/or any other A/AAAA records I encounter while monitoring the traffic streams) so the protection this offers is lost very quickly. I don't think the additional TLS to DNS "ephemeral SNI" synchronisation is worth the trouble. It would make more sense to have the TLS client take the hit of some additional roundtrip to the server to convey this privately after the EDH. Also, it would make more sense to actually use the TLS server PUBKEY for this, if the server uses the same pubkey for a lot of certificates or SubjectAltNames. It is just as meaningless to the observer as an ephemeral SNI, but now the TLS server can select the proper key if it is configured with multiple different keypairs. Paul From nobody Tue Feb 14 11:29:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FA612971B for ; Tue, 14 Feb 2017 11:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unqQbwuh9Njl for ; Tue, 14 Feb 2017 11:29:45 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 EF4D0129559 for ; Tue, 14 Feb 2017 11:29:44 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id p22so40720453qka.0 for ; Tue, 14 Feb 2017 11:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=B0kiOXdvdoIN7MOtVVGi2n1ncleRWsln7GwTVS0cxtY=; b=CDa/mUbpkZakyS65uJWM2gACvkssKmF851ZA6kcVFJ43giJzc1vZ5nD54UBsUj7cCi SCiWC63ZEbekB0uPLdjVj4TUM4jD03T0E/UojZTdWoGN21Bs5LCXyjPau82mssZ7v+Li tpuZAHhyjx9rzGqEcC2tr1c0SqLZ1fphGW48cCWMPgpwGVPA+K8lTrG6i7pxv4RAV0NH u5uvEDCZjCljVUhGuVZqOf9r8ltt1tjUMdWG8TU3abW8oQrfwe8/2dd5/UodzIO0+/yn vbRlMy16ieCSIrpTiw4qNl7WvKE5MdGVbqCMM5qHFMhd8qN3fHEqq8xLEnBbC+9xnd0m Dh8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=B0kiOXdvdoIN7MOtVVGi2n1ncleRWsln7GwTVS0cxtY=; b=GmXeJ7x2V7f+lQj+Hl7+Ld4k+Trmq+OvRPT0x1aBWm2xKx/mSShDiHVtf0r+8yuqZH eElIOe0XM4kjf5zI50JV11nA7gGu6tVp+puxRw5wuqMud5sNmxB1wxYo7bdxRor1/EKy 6B/xR8Z3oL1rgnkZvlWEEcU5tKHPINrajneSfd6o4/9V/KyY0YEOtHTeXPzBoSDbJipp RpoLyOdM0wL/lRns7SUkB/OvvqQQ0/+UMRpCTD2D0cQSJHbKDdn6e9bKpXFOpqOaz+bx 4E8uxhhVMHNFgZLWR/h9i7Pk1tJEUaN9GiH0jvMLQGZfevrKZPH0MZdT51bHlmTfkX1O CNaQ== X-Gm-Message-State: AMke39mAHa1/WReB79InA0b/xB/49JV4sPbGi3S2sOD2It2QCI5jYye7cLskhpV00oyFLC+bNWUVi1yQtG39bQ== X-Received: by 10.55.124.7 with SMTP id x7mr29231834qkc.149.1487100583792; Tue, 14 Feb 2017 11:29:43 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Tue, 14 Feb 2017 11:29:43 -0800 (PST) In-Reply-To: <02D05E11-F351-405F-8E25-8DC529425FF2@fugue.com> References: <02D05E11-F351-405F-8E25-8DC529425FF2@fugue.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 14 Feb 2017 11:29:43 -0800 X-Google-Sender-Auth: jnjKyKQ905d0-PzA5KUGvOi8-CA Message-ID: To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dnsop Subject: Re: [DNSOP] draft-ietf-dnsop-terminology-bis and "recursive resolver" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 19:29:46 -0000 At Thu, 19 Jan 2017 13:51:33 -0500, Ted Lemon wrote: > I'm updating a document for another working group, and Ralph Droms > in his last call comments on that document asked me to use > "recursive resolver" instead of "caching name server", referencing > draft-ietf-dnsop-terminology-bis. That document doesn't actually > define "recursive resolver," but instead "full service resolver," > which means almost, but not quite, the same thing. The document > does use the term "recursive resolver" fairly liberally despite > there not being a definition for it. Given that "recursive > resolver" is in such common use, including in this document, I think > the document should include a definition for "recursive resolver". I agree. My understanding is that the original terminology draft restricted itself to terms already defined in existing RFCs an that's probably why "recursive resolver" wasn't given a definition. I thought we are now more flexible in bis, so it makes sense to me to give a "formal definition" to widely used terms like "recursive resolver". -- JINMEI, Tatuya From nobody Tue Feb 14 11:33:56 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0101296FA for ; Tue, 14 Feb 2017 11:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 y-oxdCP1PwGG for ; Tue, 14 Feb 2017 11:33:54 -0800 (PST) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594A4129559 for ; Tue, 14 Feb 2017 11:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2954; q=dns/txt; s=VRSN; t=1487100835; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eF8fE1NHpxJtjC31XZ1SwPeixwAkB2rordxeEocV/Xo=; b=IWfzQs3SspOlZDttdujZmd43gzQww3uRud2cW8NqHfFdjRipoE/v3aq1 1bNdZcjcxW9eMNnBaHXtWvPv7bgL0PoTRYbpMjndHECyPbZZAARMBz3oo +cZJz+A2eUdYAeqTAYiP9y0MNitXpDd+QXExxlxzYK8T/FpUs2MkKrK0Y SBiXITNkhMAn10QiJ5qqx6eN3ski1yZmrW19JMe/P/UNTVskUglyoka5j qVU2coKu1IcuUouePlLO0kl0ik55UKY9+SoNxBso2Tt1NcTqdZREVcV+9 Bc8LPbQZa5NptrwJDmIHxlcUo7qdmGNGtfyf0ZHnoZ9IV2optLN7r9Z9v w==; X-IronPort-AV: E=Sophos;i="5.35,162,1484006400"; d="scan'208";a="1503439" IronPort-PHdr: =?us-ascii?q?9a23=3AgB4Dkx9ilC8k1/9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?2+scTK2v8tzYMVDF4r011RmSDNids6oP0rKM+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZPebgFIiTanfb9+MBq6oRjNusUInIBvNrs/xhzVr3VSZu?= =?us-ascii?q?9Y33loJVWdnxb94se/4ptu+DlOtvwi6sBNT7z0c7w3QrJEAjsmNXs15NDwuhnY?= =?us-ascii?q?UQSP/HocXX4InRdOHgPI8Qv1Xpb1siv9q+p9xCyXNtD4QLwoRTiv6bpgRRn1gy?= =?us-ascii?q?kFKjE56nnahMxugqxGvBKvqR9xw4DWb4GUKPVwcazScMgGRWpYW8ZdSzBNDp+i?= =?us-ascii?q?Y4YJEuEPPfxYr474p1YWoxexBRejBPj0yjBWgn/2xrU22PkvHwHbxgMgGcwBvH?= =?us-ascii?q?rJp9jyKagTX/66zLLTzTrda/NWwizw6JbWfRA7oPGMRrNwccXXyUU1CwzFiVCQ?= =?us-ascii?q?pJXjMjiI2OoNtG2b4PBhVeKpk2MotQ5wrSKqxsc0jonGmJgZxUzD9SV8xos+ON?= =?us-ascii?q?62SFZjbNK5DJdcrTyWOol4T884Xm1luCg3xqcYtZO0cyUG0IkrywLFZ/CacYWF?= =?us-ascii?q?7AjvWPuRLDtmnn5od7SyjAuo/0e60O3zTMy03U5PripCj9bDqGgA1wfW6sibUv?= =?us-ascii?q?t9+Vqh2SqX2wDT9O5EJUc0mLLAJJ47xL48i54TsEvGHiDsmUX2iKiWdlg4+uS0?= =?us-ascii?q?9ujreKvmqYGGN491kQH+M6sumsqlDeskNQgOWnCX+eW61LL94U30WKhGguEsnq?= =?us-ascii?q?XEsp3XK94XqrO5DgJbyIov9RmyAji+3NQdh3YHLVZFeBydj4juPlHDOO33DPmh?= =?us-ascii?q?jFS3izdk2fTGPqb6D5XTMHfDirbhfa18605Tzgo/18xQ55VRCr0ZOvL8RlfxtM?= =?us-ascii?q?DEDh8+KwG73uDnCM561oMGQm+PA7GWML/csVOS4eIvOeaMbpcPuDnhM/gl++Lu?= =?us-ascii?q?jXghlFAGY6ap2IEYaGukEfl9LEWZZn3sgtgFEWgUpAYxUOvqiFjRGQJUMly/We?= =?us-ascii?q?oH7TEkAZi6H8+XTI2oiaeK9Ci8GZJSayZNDVXaQlnycIDREcgBczmfJtQl2hAZ?= =?us-ascii?q?XL6sAcd12Q6jrxT3z6FPMOfO+zYZupSl399wsb6A3Sou/CB5WpzOm1qGSHt5yz?= =?us-ascii?q?sF?= X-IPAS-Result: =?us-ascii?q?A2HTAAB8W6NY//SZrQpeGgEBAQECAQEBAQgBAQEBFgEBAQM?= =?us-ascii?q?BAQEJAQEBhAiBCQefSx+TJ4IPgS0FWiaFfAKCPhcBAQEBAQEBAQEBAQKBB4IzG?= =?us-ascii?q?Q89PAEBAQEBASMCOjABAQEBAgE6PwULAgEIDQEKHhAyJQIEDgWJY7IUi2cBAQE?= =?us-ascii?q?BAQEEAQEBAQEBAQEBAQEdhk2CBAiCYoQ+FoM0gjEFj0OMKQYBhm6NIFOIFIYjk?= =?us-ascii?q?xUgAYEAN1EVTgGEMx2BYXWHZiuBA4EMAQEB?= Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v1EJXdw9009100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Feb 2017 14:33:39 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Tue, 14 Feb 2017 14:33:39 -0500 From: "Wessels, Duane" To: Ben Schwartz Thread-Topic: [EXTERNAL] [DNSOP] Proposal for a new record type: SNI Thread-Index: AQHShuyb/6dMJIvc3kmOxocjw/jhBqFpOHIA Date: Tue, 14 Feb 2017 19:33:38 +0000 Message-ID: <16A41EBF-8B43-4806-B548-345A1BEA7E96@verisign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 19:33:55 -0000 > On Feb 14, 2017, at 10:02 AM, Ben Schwartz wrote: >=20 > Hi dnsop, >=20 > I've written a draft proposal to improve the privacy of TLS connections, = by letting servers use the DNS to tell clients what SNI to send. >=20 Hi Ben, > _443._tcp.subdomain1.example.com. IN SNI subdomain2.example.com As I read this part I was assuming that the RDATA of the SNI record is an R= FC 1035 and the lack of a trailing dot made me twitch a littl= e bit. It seems to me that you need to decide what the format of the RDATA will be= . Throughout most of the doc it looks like a , but in other p= laces it sounds like an opaque string (particularly the paragraph about ext= ensibility). > When initiating a TLS connection to a domain and port, a client > application SHOULD query the SNI record for the prefixed domain at > the same time as the A or AAAA query, and wait for a response before > initiating TLS.=20 In the Introduction you said "Clients can make use of this record without a= dding delay to their connection process" but here the instruction is to wai= t. How long should a client wait for a response to its SNI query? Oh, I see later you wrote: A client application SHOULD NOT delay initiating= a TCP connection while waiting for the SNI DNS response. > The application MUST discard or ignore any SNI > record whose RDATA is not a well-formed domain name or an empty > string.=20 This might need more clarification. Here's a place where the RDATA sounds = very much like . But then the empty label "." becomes particu= larly tricky here because, arguably, a can never be an empty = string. > If > the selected SNI record is present with an empty RDATA (RLENGTH =3D 0)= , > then the client SHOULD omit the Server Name Indication. Again, advice here will depend on what you choose for the RDATA format. If= its then you can't really have RDLEN=3D0. > Client applications MUST NOT allow the contents of the SNI record to > influence their certificate validation behavior. The client's > certificate validation MUST be based on the user's specified > destination, not the RDATA of the SNI DNS record. =20 Given this, it sounds like there is no real reason that the SNI value needs= to be a domain name. It could be something else, like an opaque string or= an RFC4122 UUID? I think this doc also needs a privacy considerations that talks about ways = it could be abused by server operators. For example, I think it could be u= sed as a component of a so-called super cookie. Each client could get a un= ique SNI from the DNS server, allowing the web site to track individuals. = While you may be improving privacy with respect to passive attackers, it ca= n reduce privacy between web clients and servers. DW From nobody Tue Feb 14 12:03:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5CE129559 for ; Tue, 14 Feb 2017 12:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 sBvJvPXbbRMV for ; Tue, 14 Feb 2017 12:03:19 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 B347B1297E7 for ; Tue, 14 Feb 2017 12:03:10 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id c7so48092458itd.1 for ; Tue, 14 Feb 2017 12:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yG37EAi3P4tCew5O/8jmq89hn6p2C59M1sO275M/zDg=; b=n7O7wx5AmtA61O9nVMhPtxUc1+kJaGEiV+qbsiFVAFj2Lu+Q8IYTv1cSIU6Twtz5Ze RXxw8T9tA6H1bgrGbNl81dAbCK2/m61HY8OolrqxCVD19jtCx6E+K8GwqVe94CiiFytZ omu1Sbsj4Ho3wI/h7d+f4lYev7wKyVbQLJHbvQq8bCRvkuXHrnfi/DFKEWm7ipMugjri 2kbxoQGP2qLss9UD34kuM7NF5ehrIHhRrY/baUhvXy5WtUfnUTfJWFtyeQbOVeIK4RLP IEzreFEswCUjeFMl49ny0brjp4JdST8w/dotypHen3pPXsjdLH1N3KcjAeazcxMm6ryO URdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yG37EAi3P4tCew5O/8jmq89hn6p2C59M1sO275M/zDg=; b=fZfSE+QtaOrV7gOUUzVc9DoAv4b21mqrvjWEEyHYr+mmWymm8pXgJxh1GG03ckmcGI yVT8YT27GQRucwn21oQFjxWWsg3A8oHQchCy+PFtBAJwUStaf5Pxx2dZgBOS2QUKPvQS SrpDE5XUCN0IE0eL0uq2ixRo53hLQfONV35pW4WuDA7pmVBND/bHfxlHObv5bjIdktRq nL1gv3qZcOcsu3/T8bHThsPcKyWRcs9t08xNQHbuvHaaq6GsTJ0fcO6TzWx45A5VLh8i BYSWrNRegS0hQnHsnykgUX0eYFKLwAnl3vhH5ABq3shbc506WRiYGEZzYyv9xO0MBHKa GrtA== X-Gm-Message-State: AMke39mLuqxcznkfyUtMGG+rbZa7elKRjKJD7lSzGoGIHNHpxwq0ld+UQeeZOjmpQiinxIVXQ2jmWOegt7ZBcOsh X-Received: by 10.107.34.10 with SMTP id i10mr26990814ioi.41.1487102589822; Tue, 14 Feb 2017 12:03:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.164 with HTTP; Tue, 14 Feb 2017 12:03:09 -0800 (PST) In-Reply-To: <20170214191615.rwawyluf6nf4lfnm@mycre.ws> References: <20170214191615.rwawyluf6nf4lfnm@mycre.ws> From: Ben Schwartz Date: Tue, 14 Feb 2017 15:03:09 -0500 Message-ID: To: Robert Edmonds Content-Type: multipart/alternative; boundary=001a1140ec689cbd1f0548830d24 Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 20:03:21 -0000 --001a1140ec689cbd1f0548830d24 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 14, 2017 at 2:16 PM, Robert Edmonds wrote: > Ben Schwartz wrote: > > Hi dnsop, > > > > I've written a draft proposal to improve the privacy of TLS connections, > by > > letting servers use the DNS to tell clients what SNI to send. > > > > https://tools.ietf.org/html/draft-schwartz-dns-sni-01 > > > > I've incorporated some helpful feedback [1] from the TLS WG, but now I > > could use your help analyzing the DNS side. All comments welcome; this > > draft will change based on your feedback. > > > > One particular issue that I could use advice on: should this be a new > > record type, or should it reuse/repurpose an existing type like SRV or > PTR? > > > > Thanks, > > Ben > > > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html > > Hi, Ben: > > I'm kind of curious: your examples are pretty HTTP-centric, and HTTP > already has some pretty strong features for origins to persistently > modify how clients perform TLS, i.e., HTTP Strict Transport Security and > HTTP Public Key Pinning, along with preloading of those settings by the > browser vendors. Why not follow that same model for the functionality in > your draft? > > -- > Robert Edmonds > Hi Robert, While this technique would apply to any use of TLS, you're right that I'm mainly motivated by improvements for HTTPS. It's true, we could accomplish something like this by preloading a data file into browsers. In some sense, this is also true for any aspect of DNS! Obviously, preloading fares very badly when the data in question is valid for short times, or applies to many thousands or millions of domains, and I think both problems apply here. For example, a CDN that operates DNS on behalf of its customers could apply SNI records to all of their domains. Preloading all of those domains into every browser seems impractical, and the list will quickly become outdated. Without preloading, we cannot solve the problem of revealing the destination in the initial connection. I would also note that HSTS and HPKP could not have been implemented using insecure DNS, given their adversary model. The SNI record is very different, and does not require DNSSEC. --Ben --001a1140ec689cbd1f0548830d24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 14, 2017 at 2:16 PM, Robert Edmonds <edmonds@= mycre.ws> wrote:
Ben Schwartz= wrote:
> Hi dnsop,
>
> I've written a draft proposal to improve the privacy of TLS connec= tions, by
> letting servers use the DNS to tell clients what SNI to send.
>
> https://tools.ietf.org/html/draft-sc= hwartz-dns-sni-01
>
> I've incorporated some helpful feedback [1] from the TLS WG, but n= ow I
> could use your help analyzing the DNS side. All comments welcome; this=
> draft will change based on your feedback.
>
> One particular issue that I could use advice on: should this be a new<= br> > record type, or should it reuse/repurpose an existing type like SRV or= PTR?
>
> Thanks,
> Ben
>
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html

Hi, Ben:

I'm kind of curious: your examples are pretty HTTP-centric, and HTTP already has some pretty strong features for origins to persistently
modify how clients perform TLS, i.e., HTTP Strict Transport Security and HTTP Public Key Pinning, along with preloading of those settings by the
browser vendors. Why not follow that same model for the functionality in your draft?

--
Robert Edmonds

Hi Ro= bert,

While this technique would apply to any use of TLS= , you're right that I'm mainly motivated by improvements for HTTPS.=

It's true, we could accomplish something like= this by preloading a data file into browsers.=C2=A0 In some sense, this is= also true for any aspect of DNS!=C2=A0 Obviously, preloading fares very ba= dly when the data in question is valid for short times, or applies to many = thousands or millions of domains, and I think both problems apply here.

For example, a CDN that operates DNS on behalf of its= customers could apply SNI records to all of their domains.=C2=A0 Preloadin= g all of those domains into every browser seems impractical, and the list w= ill quickly become outdated.

Without preloading, w= e cannot solve the problem of revealing the destination in the initial conn= ection.

I would also note that HSTS and HPKP could= not have been implemented using insecure DNS, given their adversary model.= =C2=A0 The SNI record is very different, and does not require DNSSEC.
=

--Ben
--001a1140ec689cbd1f0548830d24-- From nobody Tue Feb 14 12:39:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8743E129853 for ; Tue, 14 Feb 2017 12:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 L9ixpH6zyOBX for ; Tue, 14 Feb 2017 12:39:24 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFAC129847 for ; Tue, 14 Feb 2017 12:39:24 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id 0886112C159E; Tue, 14 Feb 2017 15:39:24 -0500 (EST) Date: Tue, 14 Feb 2017 15:39:24 -0500 From: Robert Edmonds To: Ben Schwartz Message-ID: <20170214203924.5c4v6l5b3bjipcfw@mycre.ws> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 20:39:25 -0000 Hi, Ben: In your draft, the reason for not using TXT is given as: 2.1.3. Using TXT We could encode this information in a TXT record, but that would violate the intended purpose of TXT records: to convey information to human readers. I'm not sure if it's true that TXT records are intended only for human consumption. TXT RRs contain "descriptive text" where "[t]he semantics of the text depends on the domain where it is found". If you define "where the domain is found" as, e.g., domains like _443._tcp._sni.www.example.com, then you get to define the semantics of what is described by the TXT record at that location. I think DKIM is an example of a protocol that uses this kind of scheme with TXT records. -- Robert Edmonds From nobody Tue Feb 14 13:48:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04C01298AD for ; Tue, 14 Feb 2017 13:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqOgdacG-GoX for ; Tue, 14 Feb 2017 13:48:13 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 9112712983F for ; Tue, 14 Feb 2017 13:48:12 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id u25so135888906qki.2 for ; Tue, 14 Feb 2017 13:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=ZsMp4ABrv65eTIJO0RcHtSfjBQkEh9AQLCw4ZBptewY=; b=QA9wfL8CmfHe4JPgkk2VxcSPjdHga5YFLza+C6DwWT6hWn4G0j/4Llyk9s1rhwaTRp Bbm/szYCvWmGqDRFPSdhIIS5DaFPeQ9z65sgdZe0ddUdUxEUSaF+bfregSzCEqqCCru/ 4k/DBgL3numayHK6NKumpqbpC4PAF5L2tKnEnVhsl39zaoUL4Rkk4iDe7qqTyZPYspHa 3OIpQAHE5yvH+gWo3C2pMrRyuYZGPMr3V6oMe0QEbsTae7Yisxxw0lAzS3XEOYzVbqvF x3NiEN9S3kk/yxH4E/fLOd0wQIWZeDwIOnGU9hUIfgqDdiXm0KERf9qFArHRq69Qo1ea 0NeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=ZsMp4ABrv65eTIJO0RcHtSfjBQkEh9AQLCw4ZBptewY=; b=SAjlTqYxq6w44lg79mZ5h5Te23g1q5ALhPFOunO2P+KilSFQoLrkP3xmtoaXLuhARP gvSg34JwdRpwbXxVHPy6I4qxBOq6Jv0+P1By5FDeYAkMfGecWB9H0k+xauvnScSYIjuf 2B9u/TL34UrlacinDmDcL/8q+7kemHXmEFiZu61KazpZ3f7cI+/8FJ5A5oQmAggzwvjc EiJcMMbOgwsCLNZa5qvKi+32jf3IMsoBGJ1goeFJvGswxCs2d1mNxDDxIXZypGZ0dX0/ 0ZaFHyOAk2+cEmbGuONCeZIoTztEgZoUijgYS69C8hFkhl/DmMM08FkEuu6BAiZQ/MBk KsCQ== X-Gm-Message-State: AMke39njZYIzDa7plBrxBcaqAfSPtTHibXzKxy3Zmu1sxE9jRQAuC8RUZSBNSKiC2JnseA== X-Received: by 10.55.204.92 with SMTP id r89mr14429947qki.306.1487108891657; Tue, 14 Feb 2017 13:48:11 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:85a6:b899:5f11:dfea? ([2601:18f:801:600:85a6:b899:5f11:dfea]) by smtp.gmail.com with ESMTPSA id d191sm1088405qke.15.2017.02.14.13.48.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 13:48:11 -0800 (PST) From: Ralph Droms Content-Type: multipart/alternative; boundary="Apple-Mail=_D9C49BA4-3687-4A52-9F13-492C482490BC" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Feb 2017 16:48:06 -0500 References: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> To: dnsop In-Reply-To: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> Message-Id: <4A0B1143-B900-47C4-A495-720B76F0F77C@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 21:48:18 -0000 --Apple-Mail=_D9C49BA4-3687-4A52-9F13-492C482490BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We've extracted issues from the reviews of draft-ietf-dnsop-sutld-ps = posted to the list so far, and entered them into the GitHub repo: = https://github.com/Abhayakara/draft-tldr-sutld-ps = We're tracking = discussion and resolution for issues there, as well. Text revisions for = a few issues have been committed to the XML source and the associated = issues have been closed. Additional feedback during the WG last call is, of course, encouraged... - Ralph > On Feb 2, 2017, at 6:04 PM, Suzanne Woolf = wrote: >=20 > This message opens a Working Group Last Call for: >=20 > "Special-Use Names Problem Statement" > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ = > Proposed status: informational >=20 > Starts: 2 Feb. 2017 > Ends: 23 Feb. 2017 (3 weeks) >=20 > Discussion should go to the mailing list.=20 >=20 > Is this draft ready to advance for publication as an Informational = RFC, and as guidance for possible updates to RFC 6761? Does it describe = the relevant issues clearly, and cover all the relevant ones that should = be taken into account in future work in the IETF on the special use = names registry or RFC 6761? >=20 > If not, can you suggest changes that would get your support for = advancing it? (=E2=80=9CSend text=E2=80=9D if possible!) >=20 >=20 > thanks, > Suzanne & Tim >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_D9C49BA4-3687-4A52-9F13-492C482490BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We've extracted issues from the reviews of = draft-ietf-dnsop-sutld-ps posted to the list so far, and entered = them into the GitHub repo: https://github.com/Abhayakara/draft-tldr-sutld-ps  = We're tracking discussion and resolution for issues there, as well. =  Text revisions for a few issues have been committed to the XML = source and the associated issues have been closed.

Additional feedback during the WG last = call is, of course, encouraged...

- Ralph


On = Feb 2, 2017, at 6:04 PM, Suzanne Woolf <suzworldwide@gmail.com> wrote:

This message = opens a Working Group Last Call for:

"Special-Use Names Problem = Statement"
https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/=
Proposed status: informational

Starts: 2 Feb. = 2017
Ends: 23 Feb. 2017 (3 weeks)

Discussion should go to = the mailing list. 

Is this draft ready to advance for publication as an = Informational RFC, and as guidance for possible updates to RFC 6761? = Does it describe the relevant issues clearly, and cover all the relevant = ones that should be taken into account in future work in the IETF on the = special use names registry or RFC 6761?

If not, can you suggest changes that = would get your support for advancing it? (=E2=80=9CSend text=E2=80=9D if = possible!)


thanks,
Suzanne & Tim

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

= --Apple-Mail=_D9C49BA4-3687-4A52-9F13-492C482490BC-- From nobody Tue Feb 14 14:14:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BD81294F2 for ; Tue, 14 Feb 2017 14:14:56 -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 KdlE5FgwBg2d for ; Tue, 14 Feb 2017 14:14:55 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63576129454 for ; Tue, 14 Feb 2017 14:14:55 -0800 (PST) Received: (qmail 3856 invoked from network); 14 Feb 2017 22:14:54 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Feb 2017 22:14:54 -0000 Date: 14 Feb 2017 22:14:32 -0000 Message-ID: <20170214221432.15487.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: paul@nohats.ca Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 22:14:56 -0000 In article you write: >This seems like a bandaid to TLS that I think just needs >fixing in the TLS protocol. For once I agree with Paul. If you're going to change the client anyway, why is this better than a modified handshake that sets up the encrypted channel before sending the SNI? I realize this is not a great time to open up TLS, with the dust from TLS 1.3 just settling, but there's never a good time for some stuff. You should assume that bad guys have access to passive DNS databases, so it's not hard to reverse the indirection that SNI records provide. If you used TXT records the reversal would be slightly harder, since you'd have to pick them out from all the other cruft that's encoded in _prefix TXT records. R's, John From nobody Tue Feb 14 14:19:50 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F01B129863 for ; Tue, 14 Feb 2017 14:19: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 PB6T4PcMOjVs for ; Tue, 14 Feb 2017 14:19:48 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0BC1294BA for ; Tue, 14 Feb 2017 14:19:47 -0800 (PST) Received: (qmail 4456 invoked from network); 14 Feb 2017 22:19:47 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Feb 2017 22:19:47 -0000 Date: 14 Feb 2017 22:19:25 -0000 Message-ID: <20170214221925.15515.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: <20170214203924.5c4v6l5b3bjipcfw@mycre.ws> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: edmonds@mycre.ws Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 22:19:49 -0000 In article <20170214203924.5c4v6l5b3bjipcfw@mycre.ws> you write: > We could encode this information in a TXT record, but that would > violate the intended purpose of TXT records: to convey information to > human readers. > >I'm not sure if it's true that TXT records are intended only for human >consumption. TXT RRs contain "descriptive text" where "[t]he semantics >of the text depends on the domain where it is found". That horse left the barn at least a decade ago, before SPF, DKIM, DMARC, and a lot of other TXT records primarily intended to be consumed by computers. Humans can read them, but this human can't do much with records like this: taugh.com. IN TXT "google-site-verification=7SCAvuZtE7dOCpG0drHDEBOqco9JnPzFUIUBSgU3eWc" Whether to use a TXT record is of course a subsidiary question to whether DNS SNI indirection is a good idea in the first place. R's, John From nobody Tue Feb 14 15:47:43 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA092129962 for ; Tue, 14 Feb 2017 15:47:41 -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] 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 2V3sp3tkQzyk for ; Tue, 14 Feb 2017 15:47:41 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B4D129863 for ; Tue, 14 Feb 2017 15:47:40 -0800 (PST) Received: from [10.32.60.18] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v1ENkLJV041104 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 Feb 2017 16:46:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.18] From: "Paul Hoffman" To: dnsop@ietf.org Date: Tue, 14 Feb 2017 15:47:38 -0800 Message-ID: In-Reply-To: <148613642634.4107.5655870150005796727.idtracker@ietfa.amsl.com> References: <148613642634.4107.5655870150005796727.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5344) Archived-At: Subject: Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2017-02-16 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 23:47:42 -0000 On 3 Feb 2017, at 7:40, IESG Secretary wrote: > Webex details will follow Hopefully before the meeting. Setting up WebEx can take at least two tries for any new meeting. --Paul Hoffman From nobody Tue Feb 14 16:32:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3108612945B for ; Tue, 14 Feb 2017 16:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-KbdiWPzGXJ for ; Tue, 14 Feb 2017 16:32:05 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B48129444 for ; Tue, 14 Feb 2017 16:32:05 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id u25so138760979qki.2 for ; Tue, 14 Feb 2017 16:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PrjZ3ySCkS9KvY8s6eho2cnMtrQZtqw1OwAZJRHBRT8=; b=0zXOYNBnB3zqumO6fjl8ZYEm9p/eyLEVS02+aC/DHrULl7K12Gf0CaMVM/iKe6j2QS A4/26tR3jKNvn5ShM58vGR7z6v1QCtd5/RMKXzIS1/LpJJEPdfsXjWA37OdIfIcv3Ncv 3CNpmPnCO6FRrAP3hH7KVqYynUUYLUUU7e4bTXIGHoO8RQBeMYqQAhHaQIzUgFXbw8LO CNiHXXhm2p4mZG1qUbe/F0BpnwoO4hhKmVQiClXxJPwspFu6ISOd8tR5H8bMKMoeX1j2 KaEkAMAxS+1eYfPjdiK6dJWBESCs7m43Qn+AiUBbf/jhbTaXyzB7Fs0+pScNI98SSuJY 1rFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PrjZ3ySCkS9KvY8s6eho2cnMtrQZtqw1OwAZJRHBRT8=; b=gMaY8AUu3Fx+lt4CsWOv23xUF28qcw8pXxoXUptV19mgHvNYH/K4C+h8jqon90DJJH KuzwItVycpHxjNosT9CRo8UvARU9nsyvHLsHJY1uqHb5HHkg1zeTB/ySu1r1Fc+gwABE qhVD6upVNKxE3niVpjceWb/s8p4wj3eB7IQpFrtH6LEB8aTlwryKAwKi0bYZGUOH467y fsbIYe0MIwON3Qgcw523TVhbkS3atqFHPtNOjUchhwrjJPtdD+KoJ6Wuu/Y5GlCSRgdg yeOOwXHl60nABhAbR1YS0Gn00EPBEMLvV9T9aJTppkt7GAP8EOYE6AwlIuiiNcZ2G2Qr ECsA== X-Gm-Message-State: AMke39nqEJNNA7VchyH/CDzh6Va23Z63Ux/OjZEFs7lju1+r1chTID2koIaKES9Jq0/6Ao3WyJ3vBAGS5SksAMH8 X-Received: by 10.55.71.202 with SMTP id u193mr33199890qka.72.1487118724446; Tue, 14 Feb 2017 16:32:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Tue, 14 Feb 2017 16:31:33 -0800 (PST) In-Reply-To: <20170214221432.15487.qmail@ary.lan> References: <20170214221432.15487.qmail@ary.lan> From: Warren Kumari Date: Tue, 14 Feb 2017 19:31:33 -0500 Message-ID: To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dnsop , Paul Wouters Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 00:32:07 -0000 On Tue, Feb 14, 2017 at 5:14 PM, John Levine wrote: > In article you write: >>This seems like a bandaid to TLS that I think just needs >>fixing in the TLS protocol. > > For once I agree with Paul. > > If you're going to change the client anyway, why is this better than a > modified handshake that sets up the encrypted channel before sending > the SNI? I realize this is not a great time to open up TLS, with the > dust from TLS 1.3 just settling, but there's never a good time for > some stuff. I'm /soooo/ not a TLS person, but I think that this was discussed in the TLS WG and didn't make it into the final spec -- it requires (at least) an additional RTT. You do get SNI encryption with Zero-RTT, but it's too later by then... Some slideware: https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.pdf The DNS SNI lookup could at least be done in parallel with the "normal" DNS one (and, possibly returned in a draft-wkumari-dnsop-multiple-responses answer :-)) > > You should assume that bad guys have access to passive DNS databases, > so it's not hard to reverse the indirection that SNI records provide. Yup. I believe that much of the privacy benefit is gained if you happen to host your site on the same domain / IP as many other sites. Unfortunately this is true not just for domain fronting / this technique, but for many other situations -- it doesn't matter how well the SNI is hidden, if you connect to an IP address which only hosts a small number of sites (or sites all on the same topic) you've lost. An example of this is aa.org - the only other site on that IP is www.alcoholicsanonymous.org - if you had an expectation of privacy, it probably doesn't matter which one of the two names you went to... > If you used TXT records the reversal would be slightly harder, since > you'd have to pick them out from all the other cruft that's encoded > in _prefix TXT records. Hmmmm... are you suggesting we make TXT records cruftier to increase privacy? :-) W > > R's, > John > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Feb 14 16:51:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B85A12945D for ; Tue, 14 Feb 2017 16:51:05 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 eKIXfl8btAJ4 for ; Tue, 14 Feb 2017 16:51:03 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E272612706D for ; Tue, 14 Feb 2017 16:51:02 -0800 (PST) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.4 (Build 5915)) with SMTP id <0000964626@smtp.qbik.com>; Wed, 15 Feb 2017 13:51:00 +1300 From: "Adrien de Croy" To: "Ben Schwartz" , "Robert Edmonds" Date: Wed, 15 Feb 2017 00:51:00 +0000 Message-Id: In-Reply-To: References: <20170214191615.rwawyluf6nf4lfnm@mycre.ws> User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB18CF7FD7-3BF0-403F-B801-54CF9AEEDC36" Archived-At: Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Adrien de Croy List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 00:51:05 -0000 --------=_MB18CF7FD7-3BF0-403F-B801-54CF9AEEDC36 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable presuming that the client will have to look up the hostname of the=20 destination at some stage, and presuming that a passive network attacker= =20 may see DNS requests as well as TCP connections, how does this help? Or does this require the use of DNS over TLS. And also there will be leakage of certificate IDs in OCSP lookups which=20 cannot be secured due to the paradox that would create. An attacker=20 could mine sites for cert IDs and do a reverse mapping from that. Adrien ------ Original Message ------ From: "Ben Schwartz" To: "Robert Edmonds" Cc: "dnsop@ietf.org" Sent: 15/02/2017 9:03:09 AM Subject: Re: [DNSOP] Proposal for a new record type: SNI > > >On Tue, Feb 14, 2017 at 2:16 PM, Robert Edmonds =20 >wrote: >>Ben Schwartz wrote: >> > Hi dnsop, >> > >> > I've written a draft proposal to improve the privacy of TLS=20 >>connections, by >> > letting servers use the DNS to tell clients what SNI to send. >> > >> > https://tools.ietf.org/html/draft-schwartz-dns-sni-01=20 >> >> > >> > I've incorporated some helpful feedback [1] from the TLS WG, but now= =20 >>I >> > could use your help analyzing the DNS side. All comments welcome;=20 >>this >> > draft will change based on your feedback. >> > >> > One particular issue that I could use advice on: should this be a=20 >>new >> > record type, or should it reuse/repurpose an existing type like SRV= =20 >>or PTR? >> > >> > Thanks, >> > Ben >> > >> > [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html= =20 >> >> >>Hi, Ben: >> >>I'm kind of curious: your examples are pretty HTTP-centric, and HTTP >>already has some pretty strong features for origins to persistently >>modify how clients perform TLS, i.e., HTTP Strict Transport Security=20 >>and >>HTTP Public Key Pinning, along with preloading of those settings by=20 >>the >>browser vendors. Why not follow that same model for the functionality=20 >>in >>your draft? >> >>-- >>Robert Edmonds > >Hi Robert, > >While this technique would apply to any use of TLS, you're right that=20 >I'm mainly motivated by improvements for HTTPS. > >It's true, we could accomplish something like this by preloading a data= =20 >file into browsers. In some sense, this is also true for any aspect of= =20 >DNS! Obviously, preloading fares very badly when the data in question=20 >is valid for short times, or applies to many thousands or millions of=20 >domains, and I think both problems apply here. > >For example, a CDN that operates DNS on behalf of its customers could=20 >apply SNI records to all of their domains. Preloading all of those=20 >domains into every browser seems impractical, and the list will quickly= =20 >become outdated. > >Without preloading, we cannot solve the problem of revealing the=20 >destination in the initial connection. > >I would also note that HSTS and HPKP could not have been implemented=20 >using insecure DNS, given their adversary model. The SNI record is=20 >very different, and does not require DNSSEC. > >--Ben --------=_MB18CF7FD7-3BF0-403F-B801-54CF9AEEDC36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


presuming= that the client will have to look up the hostname of the destination at= some stage, and presuming that a passive network attacker may see DNS requ= ests as well as TCP connections, how does this help?

=
Or does this require the use of DNS over TLS.

And also there will be leakage of certificate IDs in OCSP lookups which= cannot be secured due to the paradox that would create. =C2=A0An attacker= could mine sites for cert IDs and do a reverse mapping from that.

Adrien

------ Original Message ------
From: "Ben Schwartz" <bemasc@g= oogle.com>
To: "Robert Edmonds" <edmonds@m= ycre.ws>
Cc: "dnsop@ietf.org" <dnsop@ietf.= org>
Sent: 15/02/2017 9:03:09 AM
Subject: Re: [DNSOP] Proposal for a new record type: SNI


On Tue, Feb 14, 2017 at 2:16 PM, Robert Edmonds <edmonds@mycre.ws&g= t; wrote:
Ben Schwartz wrote:
> Hi dnsop,
>
> I've written a draft proposal to improve the privacy of TLS connection= s, by
> letting servers use the DNS to tell clients what SNI to send.
>
> https://tools.ietf.org/html/draft-schwartz-dns-sni-01<= /wbr>
>
> I've incorporated some helpful feedback [1] from the TLS WG, but now= I
> could use your help analyzing the DNS side. All comments welcome; this=
> draft will change based on your feedback.
>
> One particular issue that I could use advice on: should this be a new<= br /> > record type, or should it reuse/repurpose an existing type like SRV= or PTR?
>
> Thanks,
> Ben
>
> [1] https://www.ietf.org/mail-archive/web/tls= /current/msg22353.html

Hi, Ben:

I'm kind of curious: your examples are pretty HTTP-centric, and HTTP
already has some pretty strong features for origins to persistently
modify how clients perform TLS, i.e., HTTP Strict Transport Security and HTTP Public Key Pinning, along with preloading of those settings by the browser vendors. Why not follow that same model for the functionality in your draft?

--
Robert Edmonds

Hi= Robert,

While this technique would apply to any use= of TLS, you're right that I'm mainly motivated by improvements for HTTPS.<= /div>

It's true, we could accomplish something like= this by preloading a data file into browsers.=C2=A0 In some sense, this= is also true for any aspect of DNS!=C2=A0 Obviously, preloading fares very= badly when the data in question is valid for short times, or applies to= many thousands or millions of domains, and I think both problems apply = here.

For example, a CDN that operates DNS on= behalf of its customers could apply SNI records to all of their domains.= =C2=A0 Preloading all of those domains into every browser seems impractical= , and the list will quickly become outdated.

Wit= hout preloading, we cannot solve the problem of revealing the destination= in the initial connection.

I would also note= that HSTS and HPKP could not have been implemented using insecure DNS, = given their adversary model.=C2=A0 The SNI record is very different, and= does not require DNSSEC.

--Ben
--------=_MB18CF7FD7-3BF0-403F-B801-54CF9AEEDC36-- From nobody Tue Feb 14 18:09:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9513C129478 for ; Tue, 14 Feb 2017 18:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 JnC7uI3-OZK5 for ; Tue, 14 Feb 2017 18:09:07 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A6D12944A for ; Tue, 14 Feb 2017 18:09:07 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id c7so57473543itd.1 for ; Tue, 14 Feb 2017 18:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LpgFbPjrBJub0MEtUz5m+2B+SbuIcz9oOd1Wc9ad5ms=; b=ZrT8YzK27rIoiAH0kaW9FCYiQclT4xDMx+NgPCoG574ZqCztzvkcqnCbD0aTBZDNdr 6ZelyrMPfwiGqT9yEO2OwY+fg+U4qL3K1kWqpB3VsRz2BGp+X2zOE79dS/jynkIewjE/ JqSQZ2U0ERmqnUgIIMfXoic4Du/Uuh/qi7aTOzpitW+JDzaxzKPONLEYT8kjm13pLI0o iNPr7Y2C1aseMvNqhjCSz1KiHol/EKUcpmfmP1U2nTJWyG6HWkr682c9O1LJgp2EMEvw dIELegpwT2509KyZJpMqQNqEBnGkkcNYYpEGOR0pw2qPQ3eu8nSaixt3n9fKuURGy6kN s+Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LpgFbPjrBJub0MEtUz5m+2B+SbuIcz9oOd1Wc9ad5ms=; b=XIVHIjNkTwyCCNz0k27yk+qMOwyJW0SOHvb/Equs9oS1H7/LZovs+C3+/9Fohgzxyt YwGFd2Wyn0wE+PF81p4rmmHin+ETYHbm8YIuBbwICnoSLaIcRwvQvE2SBcYQqFx8KzcE OdMMaC2C8i/2Smb9MIIr/ff57zPA/VPDuKshGrwBRthVJfArWFb1YlTBQtwH1Wx8prdi N5h+MS7fIRGJlq2XRb8MdrYf8ewc29O10ASiGNyK0DrhYarxKcuFMJdrAn3+cwpC5aCu ahfSb7fvVqKgBrGGJ7EA5xzOeacAdj8oyx4Idm4McyefJOqisat+ukJpYqMYmCDKjMm1 llng== X-Gm-Message-State: AMke39m9krLVxKkOkRmpFe2M+IgoQhCL/6U9MZItbhCjrWA9ViRfqjWTosiY2/2B1YAanP/K1bVAIJaWOzqpEc2z X-Received: by 10.36.120.73 with SMTP id p70mr6645820itc.115.1487124546359; Tue, 14 Feb 2017 18:09:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.164 with HTTP; Tue, 14 Feb 2017 18:09:05 -0800 (PST) In-Reply-To: References: <20170214191615.rwawyluf6nf4lfnm@mycre.ws> From: Ben Schwartz Date: Tue, 14 Feb 2017 21:09:05 -0500 Message-ID: To: Adrien de Croy Content-Type: multipart/alternative; boundary=001a114a9de8532f5d0548882ab2 Archived-At: Cc: Robert Edmonds , "dnsop@ietf.org" Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 02:09:09 -0000 --001a114a9de8532f5d0548882ab2 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 14, 2017 at 7:51 PM, Adrien de Croy wrote: > > > presuming that the client will have to look up the hostname of the > destination at some stage, and presuming that a passive network attacker > may see DNS requests as well as TCP connections, how does this help? > > Or does this require the use of DNS over TLS. > The draft says: A passive adversary who monitors the client's DNS queries could learn which domain the client is accessing, defeating the confidentiality benefits of this record type. Therefore, clients wishing to conceal browsing history from a passive adversary SHOULD also use DNS over TLS [RFC7858 ]. However, clients MAY use SNI records with standard DNS, in order to provide protection against a weak passive adversary who can monitor only the link between the client and the TLS server, not the link between the client and the DNS server. And also there will be leakage of certificate IDs in OCSP lookups which > cannot be secured due to the paradox that would create. An attacker could > mine sites for cert IDs and do a reverse mapping from that. > Interesting observation! I'll add a note. However, I don't think this is a big problem. The goal is not to hide which certificate is being used. The goal is to hide which domain is being accessed within a multi-domain (SAN/UCC or wildcard) certificate. > Adrien > > ------ Original Message ------ > From: "Ben Schwartz" > To: "Robert Edmonds" > Cc: "dnsop@ietf.org" > Sent: 15/02/2017 9:03:09 AM > Subject: Re: [DNSOP] Proposal for a new record type: SNI > > > > On Tue, Feb 14, 2017 at 2:16 PM, Robert Edmonds wrote: > >> Ben Schwartz wrote: >> > Hi dnsop, >> > >> > I've written a draft proposal to improve the privacy of TLS >> connections, by >> > letting servers use the DNS to tell clients what SNI to send. >> > >> > https://tools.ietf.org/html/draft-schwartz-dns-sni-01 >> > >> > I've incorporated some helpful feedback [1] from the TLS WG, but now I >> > could use your help analyzing the DNS side. All comments welcome; this >> > draft will change based on your feedback. >> > >> > One particular issue that I could use advice on: should this be a new >> > record type, or should it reuse/repurpose an existing type like SRV or >> PTR? >> > >> > Thanks, >> > Ben >> > >> > [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html >> >> Hi, Ben: >> >> I'm kind of curious: your examples are pretty HTTP-centric, and HTTP >> already has some pretty strong features for origins to persistently >> modify how clients perform TLS, i.e., HTTP Strict Transport Security and >> HTTP Public Key Pinning, along with preloading of those settings by the >> browser vendors. Why not follow that same model for the functionality in >> your draft? >> >> -- >> Robert Edmonds >> > > Hi Robert, > > While this technique would apply to any use of TLS, you're right that I'm > mainly motivated by improvements for HTTPS. > > It's true, we could accomplish something like this by preloading a data > file into browsers. In some sense, this is also true for any aspect of > DNS! Obviously, preloading fares very badly when the data in question is > valid for short times, or applies to many thousands or millions of domains, > and I think both problems apply here. > > For example, a CDN that operates DNS on behalf of its customers could > apply SNI records to all of their domains. Preloading all of those domains > into every browser seems impractical, and the list will quickly become > outdated. > > Without preloading, we cannot solve the problem of revealing the > destination in the initial connection. > > I would also note that HSTS and HPKP could not have been implemented using > insecure DNS, given their adversary model. The SNI record is very > different, and does not require DNSSEC. > > --Ben > > --001a114a9de8532f5d0548882ab2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 14, 2017 at 7:51 PM, Adrien de Croy <adrien@qbik.com> wrote:
<= div>

presuming that the client will have to lo= ok up the hostname of the destination at some stage, and presuming that a p= assive network attacker may see DNS requests as well as TCP connections, ho= w does this help?

Or does this require the use of = DNS over TLS.

The draft says:

   A passive adversary who monitors the client's DNS querie=
s could learn
   which domain the client is accessing, defeating the confidentiality
   benefits of this record type.  Therefore, clients wishing to conceal
   browsing history from a passive adversary SHOULD also use DNS over
   TLS [RFC7858]. =
 However, clients MAY use SNI records with standard
   DNS, in order to provide protection against a weak passive adversary
   who can monitor only the link between the client and the TLS server,
   not the link between the client and the DNS server.


Adrien

------ Original Message ------
From: "Ben Schwartz" <bemasc@google.com>
To: "Robert Edmonds" <edmonds@mycre.ws>
Sent: 15/02/2017 9:03:09 AM
Subject: Re: [DNSOP] Proposal for a new record type: SNI


On Tue, Feb 14, 2017 at 2:16 PM, Robert Edmonds <edmonds@= mycre.ws> wrote:
Ben Schwartz wrote:
> Hi dnsop,
>
> I've written a draft proposal to improve the privacy of TLS connec= tions, by
> letting servers use the DNS to tell clients what SNI to send.
>
> https://tools.ietf.org/html/draft-sc= hwartz-dns-sni-01
>
> I've incorporated some helpful feedback [1] from the TLS WG, but n= ow I
> could use your help analyzing the DNS side. All comments welcome; this=
> draft will change based on your feedback.
>
> One particular issue that I could use advice on: should this be a new<= br> > record type, or should it reuse/repurpose an existing type like SRV or= PTR?
>
> Thanks,
> Ben
>
> [1] https://www.ietf.org/mail-ar= chive/web/tls/current/msg22353.html

Hi, Ben:

I'm kind of curious: your examples are pretty HTTP-centric, and HTTP already has some pretty strong features for origins to persistently
modify how clients perform TLS, i.e., HTTP Strict Transport Security and HTTP Public Key Pinning, along with preloading of those settings by the
browser vendors. Why not follow that same model for the functionality in your draft?

--
Robert Edmonds

Hi Ro= bert,

While this technique would apply to any use of TLS= , you're right that I'm mainly motivated by improvements for HTTPS.=

It's true, we could accomplish something like= this by preloading a data file into browsers.=C2=A0 In some sense, this is= also true for any aspect of DNS!=C2=A0 Obviously, preloading fares very ba= dly when the data in question is valid for short times, or applies to many = thousands or millions of domains, and I think both problems apply here.

For example, a CDN that operates DNS on behalf of its= customers could apply SNI records to all of their domains.=C2=A0 Preloadin= g all of those domains into every browser seems impractical, and the list w= ill quickly become outdated.

Without preloading, w= e cannot solve the problem of revealing the destination in the initial conn= ection.

I would also note that HSTS and HPKP could= not have been implemented using insecure DNS, given their adversary model.= =C2=A0 The SNI record is very different, and does not require DNSSEC.
=

--Ben

--001a114a9de8532f5d0548882ab2-- From nobody Wed Feb 15 02:34:00 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7F812955F for ; Wed, 15 Feb 2017 02:33:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 NQ3HrFFz8pTA for ; Wed, 15 Feb 2017 02:33:57 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C194E1294E1 for ; Wed, 15 Feb 2017 02:33:57 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v1FAXu3a018178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2017 04:33:56 -0600 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 4D33C1E0059; Wed, 15 Feb 2017 04:33:51 -0600 (CST) Received: from lxomp07u.corp.intranet (unknown [151.117.18.14]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 2BC131E0058; Wed, 15 Feb 2017 04:33:51 -0600 (CST) Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v1FAXoBK004418; Wed, 15 Feb 2017 04:33:50 -0600 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v1FAXoeA004415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Feb 2017 04:33:50 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0294.000; Wed, 15 Feb 2017 04:33:50 -0600 From: "Woodworth, John R" To: "'dnsop@ietf.org'" Thread-Topic: Kindly review draft-woodworth-bulk-rr-05.txt Thread-Index: AQHSh3MZ+ZDvSwGOnkOBz2+cOwa2Xw== Date: Wed, 15 Feb 2017 10:33:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: 'JW' , 'shash raghu' , "Woodworth, John R" , "Ballew, Dean" Subject: [DNSOP] Kindly review draft-woodworth-bulk-rr-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 10:33:59 -0000 QWxsLA0KDQpJIGZ1bGx5IHVuZGVyc3RhbmQgd2UgYXJlIHNjaGVkdWxlZCB0byBob2xkIGFuIGlu dGVyaW0gbWVldGluZyB0b21vcnJvdyBhbmQgaGF2ZSBhIElvdCB0byB0aGluayBhYm91dCBidXQg YW0gaG9waW5nIGF0IGxlYXN0IGEgaGFuZGZ1bCBvZiB5b3UgbWF5IGhhdmUgYSBjeWNsZSBvciB0 d28gbGVmdCBpbiB5b3UgdG8gbG9vayBhdCBvdXIgdXBkYXRlZCBkcmFmdCAoLTA1KS4NCg0KV2Ug d2VsY29tZSBfYW55XyBmZWVkYmFjayBvbiB0aGUgZHJhZnQgYXMgd2UgYXJlIGhvcGluZyB0byBo YXZlIGl0IChvciBzb21lIGluY2FybmF0aW9uKSBhZG9wdGVkIGJ5IHRoZSBXRyBzb29uIGFuZCBs b29rIHRvIHJhbGx5IG1vcmUgaW50ZXJlc3QgYXJvdW5kIGl0Lg0KDQpXZSd2ZSBzZWVuIGEgbG90 IG9mIHJlY2VudCBuZWVkIHRvIGFkZHJlc3MgdGhlIGlzc3VlcyB0aGlzIGRyYWZ0IGF0dGVtcHRz IHRvIHNvbHZlIGFuZCBob3BlIG90aGVycyBvbiB0aGlzIGxpc3QgaGF2ZSBhcyB3ZWxsLiAgV2Un dmUgYWxzbyBwcm92aWRlZCBhIHNob3J0IE1pbmktRkFRIHRvIGhlbHAgZGV0ZXJtaW5lIGlmIHlv dSBmZWVsIGl0IG1heSBiZSBvZiBpbnRlcmVzdCBhbmQgd29ydGggYSBsb29rLg0KDQoNCk1hbnkg dGhhbmtzLA0KSm9obg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KKiogIEktRCAiQlVMSyBETlMgUmVzb3VyY2UgUmVjb3JkcyIgTWlu aS1GQVEgICAwMS0zMS0xNyAqKg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNClEpIFdoeSBkbyB3ZSBuZWVkIEJVTEsgUlJzPw0K QSkgQlVMSyBpcyBhIHRvb2wgbGlrZSBtYW55IG90aGVycy4NCiAgIEl0IHdhcyBkZXNpZ25lZCB0 byBoZWxwIHNpbXBsaWZ5IHRoZSBtYW5hZ2VtZW50IG9mDQogICBwYXR0ZXJuIGJhc2VkICJnZW5l cmljIiByZWNvcmRzIGFuZCBzY2FsZSB0byBmaXQgdGhlDQogICBncm93aW5nIGRlbWFuZCBvZiBJ UHY2IHN1cHBvcnQuIEl0IGJ1aWxkcyBvbiBwb3B1bGFyDQogICB0ZWNobm9sb2d5IGN1cnJlbnRs eSB1c2VkIHRvZGF5IHdoaWxlIHByb3ZpZGluZyBhDQogICBudW1iZXIgb2YgbW9kZXJuIGVuaGFu Y2VtZW50cy4gVGhlIGF1dGhvcnMgZmVlbCBCVUxLDQogICBpcyB0aGUgbmV4dCBsb2dpY2FsIHBy b2dyZXNzaW9uIG9mIHdoYXQgaXMgYWxyZWFkeQ0KICAgZmllbGQtcHJvdmVuIGFuZCBhY2NlcHRl ZCBpbiB0aGUgaW5kdXN0cnkgdG9kYXkuDQoNCg0KUSkgRG9lcyBCVUxLIGNvdmVyIGFsbCBSUiB0 eXBlcz8NCkEpIE5vLiBUaGUgZHJhZnQgb25seSBjb3ZlcnMgQSwgQUFBQSwgUFRSIGFuZCBDTkFN RSBSUiB0eXBlcy4NCg0KDQpRKSBXaGF0IGhhcHBlbnMgaWYgdGhlcmUgYXJlIG90aGVyIFJScyB3 aGljaCBmYWxsIGluc2lkZQ0KICAgYSBCVUxLIHBhdHRlcm4gcmFuZ2U/DQpBKSBCVUxLIHJlY29y ZHMgY2FuIG9ubHkgZXhpc3Qgd2hlcmUgb3RoZXIgcmVjb3JkcyBkbyBub3QsDQogICBhIGNvbmNl cHQgcmVmZXJyZWQgdG8gYXMgIlJlY29yZCBTdXBlcmltcG9zaXRpb24iIFs1LjFdDQoNCg0KUSkg Q2FuIEJVTEsgZ2VuZXJhdGVkIFJScyBiZSBETlNTRUMgdmFsaWRhdGVkLg0KQSkgVGhlIGRyYWZ0 IG9mZmVycyB0d28gRE5TU0VDIHNvbHV0aW9ucywgb24tdGhlLWZseQ0KICAgZ2VuZXJhdGVkIHNp Z25hdHVyZXMgYW5kIGEgcGF0dGVybiBiYXNlZCBzb2x1dGlvbiBpbg0KICAgdGhlIGZvcm0gb2Yg YSBzdXBwb3J0IE5QTiBSUiB0eXBlIChpbmNsdWRlZCBpbiB0aGUgZHJhZnQpLg0KDQoNClEpIElz IEJVTEsgb25seSBmb3IgSVB2NiBuYW1lc3BhY2U/DQpBKSBObywgQlVMSyBpcyBpbnRlbmRlZCB0 byBzaW1wbGlmeSBtYW5hZ2VtZW50IG9mIGJvdGggSVB2NA0KICAgYW5kIElQdjYgImdlbmVyaWMi IHJlY29yZHMuDQoNCg0KUSkgV2h5IG5vdCBqdXN0IHNjcmlwdCB0aGVzZSByYW5nZXMsIHVzZSAk R0VORVJBVEUgb3INCiAgIHNpbXBseSBmb3JiaWQgdGhlIGxhcmdlciBvbmVzPw0KQSkgVHdvIGZ1 bmRhbWVudGFsIGdvYWxzIGJlaGluZCBCVUxLIGFyZSB0byBiZSBhYmxlIHRvDQogICBwcm92aWRl IHRoZSBzYW1lIGNhcGFiaWxpdHkgYmVoaW5kIHNjcmlwdGluZyBhbmQNCiAgICRHRU5FUkFURXMg d2l0aG91dCB0aGUgbWVtb3J5IHJlcXVpcmVtZW50cyBhbmQNCiAgIGJlIGFibGUgdG8gdHJhbnNm ZXIgdGhlIHpvbmUgbWFpbnRhaW5lcidzICJpbnRlbnQiLg0KICAgRm9yIGV4YW1wbGUsIHdoZW4g eW91IHRyYW5zZmVyIFJScyBtYW5hZ2VkIGJ5IGEgc2NyaXB0DQogICBvciAkR0VORVJBVEUgdGhl IHJlY2VpdmVyIGdldHMgImFsbCIgcmVjb3JkcyBhbmQgbm90DQogICB0aGUgc2hvcnRoYW5kIHVz ZWQgdG8gY3JlYXRlIHRoZW0uICBCVUxLIHRyYW5zZmVycw0KICAgdGhpcyBpbnRlbnQgc28gdGhl IGNvcHkgbG9va3MganVzdCBsaWtlIHRoZSBvcmlnaW5hbC4NCiAgIFNldmVyYWwgRE5TIFNvZnR3 YXJlIFZlbmRvcnMgYXJlIGFscmVhZHkgcHJvdmlkaW5nDQogICB0aGlzIGNhcGFiaWxpdHkgaW4g YSBwcm9wcmlldGFyeSBtYW5uZXIsIEJVTEsgb2ZmZXJzDQogICBhbiBvcGVuICJzdGFuZGFyZCIg d2F5IHRvIGV4Y2hhbmdlIHRoZXNlIHJlY29yZHMNCiAgIHdoaWNoIHNjYWxlcyB0byBmaXQgYW55 IHNpemUuDQoNCg0KUSkgQlVMSyBzeW50YXggbG9va3MgbGlrZSByZWd1bGFyIGV4cHJlc3Npb24s IGlzbid0IHRoYXQNCiAgIGEgYml0IHRvbyBjb21wbGljYXRlZD8NCkEpIEJVTEsgZG9lcyBvZmZl ciBhZHZhbmNlZCByZWd1bGFyLWV4cHJlc3Npb24tZXNxdWUNCiAgIGJhY2tyZWZlcmVuY2VzIGJ1 dCBpbiBhIHNpbXBsaWZpZWQgbWFubmVyLiBJbiBmYWN0LA0KICAgdGhlICJzdGFyIiBiYWNrcmVm ZXJlbmNlIHdpbGwgd29yayBmaW5lIGluIG1vc3QNCiAgIHNjZW5hcmlvcyAoZS5nLiAibWVtYmVy LSR7Kn0uZXhhbXBsZS5jb20uIikuIE5BUFRSDQogICBSUnMgY3VycmVudGx5IHByb3ZpZGUgY2xp ZW50LWFzc2lzdGVkIHJlZ3VsYXItDQogICBleHByZXNzaW9uIHBhdHRlcm4gc3Vic3RpdHV0aW9u IHNvIEJVTEsgbGV2ZXJhZ2VzDQogICBhIGZhbWlsaWFyICJmZWVsIiB3aGlsZSBhbHNvIHByb3Zp ZGluZyBzb21lIG9mIHRoZQ0KICAgaGVhdnkgbGlmdGluZy4NCg0KLS0NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtd29vZHdvcnRoLWJ1bGstcnItMDUudHh0DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LXdvb2R3b3J0aC1idWxrLXJyLTA1LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEpvaG4gV29vZHdvcnRoIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LXdvb2R3b3J0aC1idWxrLXJyDQpSZXZp c2lvbjogICAgICAgMDUNClRpdGxlOiAgICAgICAgICBCVUxLIEROUyBSZXNvdXJjZSBSZWNvcmRz DQpEb2N1bWVudCBkYXRlOiAgMjAxNy0wMi0xNQ0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDMyDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdvb2R3b3J0aC1idWxrLXJyLTA1LnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXdvb2R3b3J0aC1idWxrLXJyLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC13b29kd29ydGgtYnVsay1yci0wNQ0KRGlmZjogICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13b29kd29ydGgtYnVsay1yci0wNQ0K DQpBYnN0cmFjdDoNCiAgIFRoZSBCVUxLIEROUyByZXNvdXJjZSByZWNvcmQgdHlwZSBkZWZpbmVz IGEgbWV0aG9kIG9mIHBhdHRlcm4gYmFzZWQNCiAgIGNyZWF0aW9uIG9mIEROUyByZXNvdXJjZSBy ZWNvcmRzIHRvIGJlIHVzZWQgaW4gcGxhY2Ugb2YgTlhET01BSU4NCiAgIGVycm9ycyB3aGljaCB3 b3VsZCBub3JtYWxseSBiZSByZXR1cm5lZC4gIFRoZXNlIHJlY29yZHMgYXJlIGN1cnJlbnRseQ0K ICAgcmVzdHJpY3RlZCB0byByZWdpc3RlcmVkIEROUyByZXNvdXJjZSByZWNvcmQgdHlwZXMgQSwg QUFBQSwgUFRSIGFuZA0KICAgQ05BTUUuICBUaGUga2V5IGJlbmVmaXQgb2YgdGhlIEJVTEsgcmVz b3VyY2UgcmVjb3JkIHR5cGUgaXMgdGhlDQogICBzaW1wbGlmaWNhdGlvbiBvZiBtYWludGFpbmlu ZyAiZ2VuZXJpYyIgcmVjb3JkIGFzc2lnbm1lbnRzIHdoaWNoDQogICB3b3VsZCBvdGhlcndpc2Ug YmUgdG9vIG1hbnkgdG8gbWFuYWdlIG9yIHJlcXVpcmUgc2NyaXB0cyBvcg0KICAgcHJvcHJpZXRh cnkgbWV0aG9kcyBhcyBiaW5kJ3MgJEdFTkVSQVRFLg0KDQogICBUaGlzIGRvY3VtZW50IHVwZGF0 ZXMgUkZDcyAyMzA4LCA0MDMzLCA0MDM0IGFuZCA0MDM1Lg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KLS0gVEhFU0Ug QVJFIFRIRSBEUk9JRFMgVE8gV0hPTSBJIFJFRkVSOg0KVGhpcyBjb21tdW5pY2F0aW9uIGlzIHRo ZSBwcm9wZXJ0eSBvZiBDZW50dXJ5TGluayBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIFVuYXV0aG9yaXplZCB1c2Ugb2YgdGhpcyBjb21tdW5p Y2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRp YXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBj b3BpZXMgb2YgdGhlIGNvbW11bmljYXRpb24gYW5kIGFueSBhdHRhY2htZW50cy4NCg== From nobody Wed Feb 15 03:46:51 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C18127735; Wed, 15 Feb 2017 03:46:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148715920949.17373.17836563263400509822.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 03:46:49 -0800 Archived-At: Cc: tjw.ietf@gmail.com, draft-ietf-dnsop-edns-key-tag@ietf.org, dnsop@ietf.org, dnsop-chairs@ietf.org Subject: [DNSOP] Alexey Melnikov's No Record on draft-ietf-dnsop-edns-key-tag-04: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 11:46:49 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dnsop-edns-key-tag-04: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Are there existing or planned implementations of both approaches? I am sorry if I missed that in the shepherding writeup. From nobody Wed Feb 15 08:05:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F110129542 for ; Wed, 15 Feb 2017 08:05:47 -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_HELO_PASS=-0.001, 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 A6R4OtQrDuIb for ; Wed, 15 Feb 2017 08:05:46 -0800 (PST) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA02126579 for ; Wed, 15 Feb 2017 08:05:45 -0800 (PST) Received: from [2001:470:78c8:2:6ce0:82ed:b11b:7f37] (helo=pallas.home.time-travellers.org) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ce25m-0003yw-5d; Wed, 15 Feb 2017 16:06:06 +0000 Date: Wed, 15 Feb 2017 17:05:32 +0100 From: Shane Kerr To: "Woodworth, John R" Message-ID: <20170215170532.71bdb7e5@pallas.home.time-travellers.org> In-Reply-To: References: X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/33lMz0omHFeHLfwxxpyqyBe"; protocol="application/pgp-signature" Archived-At: Cc: "'dnsop@ietf.org'" , "Ballew, Dean" , 'shash raghu' , 'JW' Subject: Re: [DNSOP] Kindly review draft-woodworth-bulk-rr-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 16:05:47 -0000 --Sig_/33lMz0omHFeHLfwxxpyqyBe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable John, At 2017-02-15 10:33:50 +0000 "Woodworth, John R" wrote: > I fully understand we are scheduled to hold an interim meeting > tomorrow and have a Iot to think about but am hoping at least a > handful of you may have a cycle or two left in you to look at our > updated draft (-05). >=20 > We welcome _any_ feedback on the draft as we are hoping to have it > (or some incarnation) adopted by the WG soon and look to rally more > interest around it. >=20 > We've seen a lot of recent need to address the issues this draft > attempts to solve and hope others on this list have as well. We've > also provided a short Mini-FAQ to help determine if you feel it may > be of interest and worth a look. Full disclosure: I hate reverse DNS, which seems to be a strong motivator for things like $GENERATE and the BULK proposal. :) The benefit of the BULK proposal is that it performs a nice compression compared to $GENERATE when sending via AXFR, and also enables on-the-fly generation of answers for things like IPv6 reverse DNS which cannot be done with $GENERATE. I have a few mostly minor comments, feel free to ignore any and all of them. My main concern is with the proposal for NPN. That's at the end of this e-mail. -------- I'd move section 2.4 to the top of section 2. Looking at the examples first can make understanding the rest clearer. -------- It might be nice if the examples could be re-worked to use the documentation IP addresses from RFC 3330 (192.0.2.0/24) or RFC 3849 (2001:DB8::/32). I realize that for IPv4 this might be unworkable, because of the limited size of the prefix. ------- In 2.2.2. The Domain Name Pattern Field, we see: number =3D 1*DIGIT / 1*HEXDIG However a HEXDIG already includes DIGIT in RFC 5234. (This is also true in 2.2.3. The Replacement Pattern Field.) In fact, I don't see any way to disambiguate. Does [9-11] mean "9, 10, 11" or "9, 10, 11, 12, 13, 14, 15, 16, 17"?=20 While the server will eventually figure this out based on the record type, to me it seems better to define the grammar completely separately for IPv4 (decimal) versus IPv6 (hex). Or perhaps use the "0x" prefix for hex, although I can see why that might be too clumsy. This might even get rid of the need for the rules in 3.3.2. Manual Domain Name Pattern Matching. ------- In 2.2.2. The Domain Name Pattern Field, we see: range =3D number [ "-" number ] =20 I don't understand the motivation here. If you are just using a single number then why include it in a range? It seems like it complicates parsing (and possibly automatic generation) for no real gain. I propose making range: range =3D number "-" number This would apply when used in 2.2.3. The Replacement Pattern Field also. -------- In 2.2.3. The Replacement Pattern Field, the term "stage" is introduced in a bit of a haphazard way. I am pretty sure I understand the intent, but for example the phrase "stage one" is never used. I think that I would say something like: This field MUST be evaluated for proper syntax for resource records of its Match Type, as defined above. This validation MAY be done when a new version of the zone is received, such as through a zone transfer or when loaded from a file. In this case, the version of the zone containing the invalid RR is not used. If validation is not done then, then validation MUST be done prior to returning generated replacement answers. -------- In 3.4.1.1.8. Backreference Position, it makes me nervous to have context-based rules about reversed order or not. As the text indicates, this was done to make the syntax intuitive. Since I have been working on computers for many years, I have no intuition any more, but it still seems like a source of potential mistakes to specify some rules operate in reverse and others not. I don't strongly oppose this, but it does make me nervous. :) -------- In 5.1 Record Superimposition, "SWIP" is an ARIN-ism (I think). Perhaps this should be replaced with some text describing what is meant by the term instead of using it. -------- Now... for DNSSEC and the NPN record. My own preference here would be for on-the-fly signing, but this is of course not always possible. Certainly if you are using a commercial secondary service you don't want to hand the provider your DNSSEC keys in many cases. :) So I understand the motivation for NPN, but if I understand the NPN record itself, then it can allow certain types of spoofed data. Basically, we are saying that we are going to ignore part of the answer when we do our checks. In the case of a typical IPv6 setup with a /64 network, that would allow an attacker to provide an AAAA record anywhere in the network. This might allow an attacker to direct traffic to anything in the network to any hacked device. I wonder if a better approach might be to simply supply the BULK record itself to a resolver, and have it perform the rewriting itself. We could add an EDNS0 option where a resolver indicates that it understands the BULK format. If the zone is signed and the flag is used, then the authoritative server can include the BULK record and its RRSIG in the answer. This also makes me think of complications with NXDOMAIN results. * In the case where there is an error that is not caught on load (the "stage two" checking in the text), the NXDOMAIN will not have a signed NSEC or NSEC3 record to return, and a validating resolver will not accept the response. Possibly it is better to return SERVFAIL if an error is discovered when sending a reply. * In the case where there is no error but no patterns match, probably it is better to return an empty answer (what BIND 9 calls NODATA, I think) rather than NXDOMAIN, since we don't have a signed NSEC or NSEC3 record. This will work with the EDNS0 hack that I described, but I do not think it will work with NPN.=20 I think that's about it. I spent way more time on this than I expected, hopefully it is helpful. :) Cheers, -- Shane --Sig_/33lMz0omHFeHLfwxxpyqyBe Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdhRx2J+MnJeBOVlgNzKXnPlnswYFAlikfEwACgkQNzKXnPln swY9ug/+N9ZMQLMnvZ7WTe64QJR4PWp9+Sz717ev6WoRM7ZXMcaawPGtTCqfyJwl YLW7rYAYdFgv0k6iFD7esybgEN3KAycSzCmxF86RXCYC9Qf04870o7aOA70B07Rs OtFpWREL7h5fxok1kV5AjYt/fGEe/pYWEaPD5X1IUalVQ6J/vXvbS5wtGBM3FFdu BBGgeRfjQtTYcBOxLdMHCy7dtV5TEB+EpP7o32PJmDGins7PHI6xdRsSemK6l4Sm HoaRFEMsI1JfE7PEE2rdWuoDPWs28NEPJqjljuAVKwYqxaOI8EmgLdTqGMM4yQa1 RvjqP05GGpc76HYrcZtUbfY4TzJmHLise1Bgiq0UoGuRQ/+hyq54HxkHxpXMisK5 Y67H3w1xmUdAziLjL52O7whp/Y3AZ23jFL3kRYuBQSxptAUFyYCvNf5SqufCgWpf 9NgunA0dhsYfk9qjW/lcjSDifKMjxKcQ63KeskaYvc778H0G4T+Pl8V9ybxnXzcM 6bPDqF60Hq4mlyKLmWIuKC/2ix4Vgj2TqW7MTZuNWe3Lp1LYpMjkqWNTk8jboWgr OQDcjX/McTl3cqvJlpM3kcnrZwP8aAY6ZxOHDWwMKgMChKubqG4ppP5gYH3q6eqX WxwLCtXh4kZI12u8vtOfEo85IM+iJa4yTxUauJcNsKEyU8wPM5M= =qF1Y -----END PGP SIGNATURE----- --Sig_/33lMz0omHFeHLfwxxpyqyBe-- From nobody Wed Feb 15 11:27:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D86129A1B for ; Wed, 15 Feb 2017 11:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 gKHhClHBMvdW for ; Wed, 15 Feb 2017 11:27:45 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2CE129706 for ; Wed, 15 Feb 2017 11:27:45 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 15 Feb 2017 11:27:43 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 15 Feb 2017 11:27:42 -0800 From: Edward Lewis To: "dnsop@ietf.org" Thread-Topic: [Ext] New Version Notification for draft-lewis-domain-names-05.txt Thread-Index: AQHShxbNEZbPvoAcxkqikiK9m6DMKKFqp0KA Date: Wed, 15 Feb 2017 19:27:42 +0000 Message-ID: <5CDF78D7-13F7-4A9D-AF01-2048249A093A@icann.org> References: <148711351243.10038.201222941475671758.idtracker@ietfa.amsl.com> In-Reply-To: <148711351243.10038.201222941475671758.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3570013661_1415239488" MIME-Version: 1.0 Archived-At: Subject: [DNSOP] FW: [Ext] New Version Notification for draft-lewis-domain-names-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:27:51 -0000 --B_3570013661_1415239488 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit In advance of the interim meeting... https://tools.ietf.org/html/draft-lewis-domain-names-05 On 2/14/17, 18:05, "internet-drafts@ietf.org" wrote: A new version of I-D, draft-lewis-domain-names-05.txt has been successfully submitted by Edward Lewis and posted to the IETF repository. Name: draft-lewis-domain-names Revision: 05 Title: Domain Names Document date: 2017-02-14 Group: Individual Submission Pages: 19 --B_3570013661_1415239488 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUGYsVsBPKOWF8eksR gf9EGnXRshQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw MjE1MTkyNzQxWjANBgkqhkiG9w0BAQEFAASCAQCDuDMIS27L8p26FjjEAwHAiTlAJBWfjqO7 xRwKu4fhePvrWE9UU86Ue5B18Urf5TyM2fACYj3KU1bEj1xQe+WfKALCXbgHK3h9VkzNzv8h KzlEHrzmrX9Q3k3kgICDN0LQ7hv+F58wby9PjQt8JTqb5b8uxXSWZ+S8ctmsnCDjgz2GtIZP XPsmPP0YwfWzs2gHL4SfFkyhwrEHTlJzXWH9ocvOBFLmV0zWZ21KTjKg5GGgPzGkrUuTZhJ0 HfuWnyoFg5DZVkgnrPKhOvFKBW+CHgu6yBpVJOVpcI9HH525LIDxDk1x54GvgeZxlZN0ezaK d+Dp7Ky32or3WPuKeufk --B_3570013661_1415239488-- From nobody Wed Feb 15 14:57:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35795129721 for ; Wed, 15 Feb 2017 14:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 6kpiQGE7BcOb for ; Wed, 15 Feb 2017 14:57:20 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B67112985F for ; Wed, 15 Feb 2017 14:57:20 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v1FMvIEx021018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2017 16:57:19 -0600 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id BA9421E0053; Wed, 15 Feb 2017 15:57:13 -0700 (MST) Received: from lxdnp31k.corp.intranet (unknown [151.119.92.134]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 99BDC1E005F; Wed, 15 Feb 2017 15:57:13 -0700 (MST) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v1FMvDHG063153; Wed, 15 Feb 2017 15:57:13 -0700 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v1FMvDiq063149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Feb 2017 15:57:13 -0700 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0294.000; Wed, 15 Feb 2017 16:57:13 -0600 From: "Woodworth, John R" To: "'Shane Kerr'" Thread-Topic: [DNSOP] Kindly review draft-woodworth-bulk-rr-05.txt Thread-Index: AQHSh3MZ+ZDvSwGOnkOBz2+cOwa2X6FqoFkA///6gWA= Date: Wed, 15 Feb 2017 22:57:11 +0000 Message-ID: References: <20170215170532.71bdb7e5@pallas.home.time-travellers.org> In-Reply-To: <20170215170532.71bdb7e5@pallas.home.time-travellers.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "'dnsop@ietf.org'" , 'JW' , 'shash raghu' , "Woodworth, John R" , "Ballew, Dean" Subject: Re: [DNSOP] Kindly review draft-woodworth-bulk-rr-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 22:57:22 -0000 Shane, Thanks so much for the review, it is very detailed and your comments are fantastic! > John, > > Full disclosure: I hate reverse DNS, which seems to be a strong > motivator for things like $GENERATE and the BULK proposal. :) > :) > The benefit of the BULK proposal is that it performs a nice > compression compared to $GENERATE when sending via AXFR, and > also enables on-the-fly generation of answers for things like > IPv6 reverse DNS which cannot be done with $GENERATE. > > I have a few mostly minor comments, feel free to ignore any > and all of them. My main concern is with the proposal for > NPN. That's at the end of this e-mail. > > -------- > > I'd move section 2.4 to the top of section 2. Looking at > the examples first can make understanding the rest clearer. Good idea. We struggled a bit with this as we didn't want to throw too much at the reader too soon. It is a rather long draft to get through. > -------- > > It might be nice if the examples could be re-worked to use > the documentation IP addresses from RFC 3330 (192.0.2.0/24) > or RFC 3849 (2001:DB8::/32). I realize that for IPv4 this > might be unworkable, because of the limited size of the > prefix. > We can rework the IPv6 as you suggest but we wanted to point out the significance of the larger ranges even in IPv4. > ------- > > In 2.2.2. The Domain Name Pattern Field, we see: > > number =3D 1*DIGIT / 1*HEXDIG > > However a HEXDIG already includes DIGIT in RFC 5234. > (This is also true in 2.2.3. The Replacement Pattern Field.) > Good point. This was done more for readability, if it is confusing we can try to find another way. > In fact, I don't see any way to disambiguate. Does [9-11] > mean "9, 10, 11" or "9, 10, 11, 12, 13, 14, 15, 16, 17"? > > While the server will eventually figure this out based on > the record type, to me it seems better to define the > grammar completely separately for IPv4 (decimal) versus > IPv6 (hex). Or perhaps use the "0x" prefix for hex, > although I can see why that might be too clumsy. This > might even get rid of the need for the rules in 3.3.2. > Manual Domain Name Pattern Matching. > We will take a close look at this section to see where we can tune it a bit and maybe provide better clarity. > ------- > > In 2.2.2. The Domain Name Pattern Field, we see: > > range =3D number [ "-" number ] > > I don't understand the motivation here. If you are just using > a single number then why include it in a range? It seems like > it complicates parsing (and possibly automatic generation) > for no real gain. The main motivation behind this is only ranges are captured and if you want to use all octets/nibbles in the backreference even a single number should be able to work. Guess it depends on how the zone maintainer wants to segment their rules. > I propose making range: > > range =3D number "-" number > > This would apply when used in 2.2.3. The Replacement Pattern > Field also. > The replacement pattern accepts something like ${1,3,4,6} to allow more control over the backreferences. This feature requires single digits to maintain a clean look. > -------- > > In 2.2.3. The Replacement Pattern Field, the term "stage" is > introduced in a bit of a haphazard way. I am pretty sure I > understand the intent, but for example the phrase "stage one" > is never used. > > I think that I would say something like: > > This field MUST be evaluated for proper syntax for resource > records of its Match Type, as defined above. This validation > MAY be done when a new version of the zone is received, > such as through a zone transfer or when loaded from a file. > In this case, the version of the zone containing the invalid > RR is not used. If validation is not done then, then > validation MUST be done prior to returning generated > replacement answers. > Good suggestion, we will reevaluate the wording here. We don't want a "1st, B, and finally" scenario :) . > -------- > > In 3.4.1.1.8. Backreference Position, it makes me nervous to have > context-based rules about reversed order or not. As the text > indicates, this was done to make the syntax intuitive. Since I > have been working on computers for many years, I have no > intuition any more, but it still seems like a source of potential > mistakes to specify some rules operate in reverse and others not. > I don't strongly oppose this, but it does make me nervous. :) > I am personally torn on this point as well. On one hand, it "feels" nicer to have the numbers automatically reversed (it is a computer after all); but on the other hand, giving up control in the matter is difficult. Overall, I tend to lean toward the automatic assignment but maybe there could be a parameter to control this behavior. > -------- > > In 5.1 Record Superimposition, "SWIP" is an ARIN-ism (I think). > Perhaps this should be replaced with some text describing what > is meant by the term instead of using it. > The main point of this section is to show how non BULK RRs inserted within the range of a BULK RR are automatically "superimposed" where they belong. For too long, we have had to break up $GENERATES into multiple $GENERATES (especially for singletons) to support a new customer assignment. While this feature piggybacks on wildcard logic, we find it to be worth pointing out its utility and novelty. Perhaps it would be worthwhile to expand this section with an example to make this feature more apparent. > -------- > > Now... for DNSSEC and the NPN record. > > My own preference here would be for on-the-fly signing, but > this is of course not always possible. Certainly if you are > using a commercial secondary service you don't want to hand > the provider your DNSSEC keys in many cases. :) > > So I understand the motivation for NPN, but if I understand > the NPN record itself, then it can allow certain types of > spoofed data. > Basically, we are saying that we are going to ignore part > of the answer when we do our checks. This is where we expected the biggest concern. DNSSEC was a hard nut to crack so we had to stroll down a very seedy road to get there :) . To be clear, the "ignore" fields control which part of the RR would remain completely untouched by the "normalization" process. The normalization then collapses hexadecimal and decimal ranges into a fixed single digit allowing for the number "65535" to become "9" for evaluation purposes. > In the case of a typical IPv6 setup with a /64 network, > that would allow an attacker to provide an AAAA record > anywhere in the network. > This might allow an attacker to direct traffic to anything > in the network to any hacked device. > We had great concerns about this as well initially but after further experimentation realized the scope was a lot smaller than the hair on the back of our necks had led us to suspect. > I wonder if a better approach might be to simply supply > the BULK record itself to a resolver, and have it perform > the rewriting itself. We could add an EDNS0 option where > a resolver indicates that it understands the BULK format. > If the zone is signed and the flag is used, then the > authoritative server can include the BULK record and its > RRSIG in the answer. > > This also makes me think of complications with NXDOMAIN > results. > > * In the case where there is an error that is not caught > on load (the "stage two" checking in the text), the > NXDOMAIN will not have a signed NSEC or NSEC3 record > to return, and a validating resolver will not accept > the response. Possibly it is better to return SERVFAIL > if an error is discovered when sending a reply. Good point. We will comb through this section as well. Our instinct here was to leave the system the same way we found it (i.e. NXDOMAIN) if we were unable to synthesize RRs but DNSSEC greatly complicates this. > * In the case where there is no error but no patterns > match, probably it is better to return an empty answer > (what BIND 9 calls NODATA, I think) rather than NXDOMAIN, > since we don't have a signed NSEC or NSEC3 record. This > will work with the EDNS0 hack that I described, but I > do not think it will work with NPN. > > I think that's about it. I spent way more time on this > than I expected, hopefully it is helpful. :) > Thanks again for your thoughtful and thorough review, it has given us much to think about. Thanks, John > Cheers, > > -- > Shane > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Wed Feb 15 15:03:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DFF1298D5 for ; Wed, 15 Feb 2017 15:03:05 -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, RP_MATCHES_RCVD=-0.001, 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 yPfImKIX573X for ; Wed, 15 Feb 2017 15:03:03 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE4312985F for ; Wed, 15 Feb 2017 15:03:03 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 1CC113F468; Wed, 15 Feb 2017 18:03:02 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22692.56870.30405.552781@gro.dd.org> Date: Wed, 15 Feb 2017 18:03:02 -0500 From: Dave Lawrence To: dnsop@ietf.org Archived-At: Subject: [DNSOP] Client ID in Forwarded DNS Queries X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:03:05 -0000 FYI. ------- start of forwarded message (RFC 934 encapsulation) ------- From: Subject: New Version Notification for draft-tale-dnsop-edns0-clientid-00.txt Date: Wed, 15 Feb 2017 13:56:46 -0800 A new version of I-D, draft-tale-dnsop-edns0-clientid-00.txt has been successfully submitted by David C Lawrence and posted to the IETF repository. Name: draft-tale-dnsop-edns0-clientid Revision: 00 Title: Client ID in Forwarded DNS Queries Document date: 2017-02-14 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-tale-dnsop-edns0-clientid-00.txt Status: https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/ Htmlized: https://tools.ietf.org/html/draft-tale-dnsop-edns0-clientid-00 Abstract: This draft defines a DNS EDNS option to carry a client-specific identifier in DNS queries, with guidance for privacy protection of such information. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ------- end ------- From nobody Wed Feb 15 15:10:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D9E129721 for ; Wed, 15 Feb 2017 15:10:31 -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 Z9q--fxDkT36 for ; Wed, 15 Feb 2017 15:10:30 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4912129952 for ; Wed, 15 Feb 2017 15:10:29 -0800 (PST) Received: (qmail 19880 invoked from network); 15 Feb 2017 23:10:28 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 15 Feb 2017 23:10:28 -0000 Date: 15 Feb 2017 23:10:06 -0000 Message-ID: <20170215231006.19946.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:10:31 -0000 >I'm /soooo/ not a TLS person, but I think that this was discussed in >the TLS WG and didn't make it into the final spec -- it requires (at >least) an additional RTT. You do get SNI encryption with Zero-RTT, but >it's too later by then... >Some slideware: https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.pdf >The DNS SNI lookup could at least be done in parallel with the >"normal" DNS one (and, possibly returned in a >draft-wkumari-dnsop-multiple-responses answer :-)) To put it baldly, if it is a problem that SNI leaks, the solution is to fix SNI. This is not a solution, it is at most a band-aid that will deter a subset of unsophisticated snoops while adding useless complexity to https. For example, what are users supposed to do when the SNI DNS records and the SNI mapping in the servers inevitably get out of sync? "But fixing SNI is hard" isn't a good reason to do this. I understand that adding an extra round trip to the handshake would be a problem, but I am a long way from believing that's the only way to fix SNI. R's, John From nobody Wed Feb 15 15:48:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6B7129BEB for ; Wed, 15 Feb 2017 15:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 221fXCQwhF0N for ; Wed, 15 Feb 2017 15:48:43 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 0EB12129BEA for ; Wed, 15 Feb 2017 15:48:43 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id d9so29169550itc.0 for ; Wed, 15 Feb 2017 15:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NgRZExdn2/1H0a888Mt52RUPMGmqghF81b8sQOKSgMI=; b=vK5uyYu3o0oqG1pl3WVSeJwe8oVDYHuXO0C/Q6/sgb++pqprLN4Ep9uRTBZ7U4Xm7k ey15x2+Pr+O8mMo0Ch4JozvIhA/uwnObiPq6XIZ+SvqDVvIgz9CWasIRh7RpQIxgtTuP nFhM2lJz617a6e0oEqpVJYx6kiRwoSXWM3DDN69oiRrv5jZSBwfrFsp/gJjDG92Vocft PRUhn497N0yKacCxK5r5B4ZF8xbT5kanPigTU/efYpvm1+immEgAcM2vlySf9Kumg2bh +UXyDXU2N4WthnTIRYOqfwx1yrAbFuWbfsQKHKup5lvof783HwSi8vK/9QH/e373mJmy Cylw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NgRZExdn2/1H0a888Mt52RUPMGmqghF81b8sQOKSgMI=; b=DXtY+I4gEWCbnZ9qw351BRKFMaGpSbMA5Jb0KPEReHjjqnuZ5nFcAaLcC/foqEmiPZ dRZBBBnHF3m274TUFcVo8vCZjdK+/dWzPNJ2NoRUNKfT9W8clsXoiTIBbVEq4XDSZq7d 8LJ/gpbVSv9Uq+qV1PWHdCRm6BZ5VYOivdIzWQwkl/K7oenE2l+UG+6+WHFlj5qPiAsH YpdPL7QvdRY3kfn2PfhcenkfcecuxzOjLd35PYZG4Z3OcUwpV2nbXN6Uu3zsD8c+wNGR JnDQx2sJ4u/oI1K8s3whSoJIj2hituS//PfD6DJBGW665kupogWPzM6kVT9Tq6c3z+hR 06hg== X-Gm-Message-State: AMke39nrMsfdVh6Q7t2ZFMcEBe1UdwXmi3ko8pcv9rFqeKvUsa4ePTbCoDo+6xk166l8UX4TsHrfdTMkMGqNpPf5 X-Received: by 10.36.120.73 with SMTP id p70mr11364113itc.115.1487202522109; Wed, 15 Feb 2017 15:48:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.164 with HTTP; Wed, 15 Feb 2017 15:48:41 -0800 (PST) In-Reply-To: <20170215231006.19946.qmail@ary.lan> References: <20170215231006.19946.qmail@ary.lan> From: Ben Schwartz Date: Wed, 15 Feb 2017 18:48:41 -0500 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a114a9de80a982605489a52cc Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:48:44 -0000 --001a114a9de80a982605489a52cc Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 6:10 PM, John Levine wrote: > >I'm /soooo/ not a TLS person, but I think that this was discussed in > >the TLS WG and didn't make it into the final spec -- it requires (at > >least) an additional RTT. You do get SNI encryption with Zero-RTT, but > >it's too later by then... > >Some slideware: https://www.ietf.org/proceedings/94/slides/slides- > 94-tls-8.pdf > >The DNS SNI lookup could at least be done in parallel with the > >"normal" DNS one (and, possibly returned in a > >draft-wkumari-dnsop-multiple-responses answer :-)) > > To put it baldly, if it is a problem that SNI leaks, the solution is > to fix SNI. This is not a solution, it is at most a band-aid that > will deter a subset of unsophisticated snoops while adding useless > complexity to https. For example, what are users supposed to do when > the SNI DNS records and the SNI mapping in the servers inevitably get > out of sync? > FWIW, the draft recommends users retry with whatever their behavior would have been otherwise, effectively imposing a one roundtrip penalty in this failure case. > "But fixing SNI is hard" isn't a good reason to do this. I understand > that adding an extra round trip to the handshake would be a problem, > but I am a long way from believing that's the only way to fix SNI. > Removing SNI without adding an extra roundtrip to every SSL connection logically requires the client to learn an additional piece of information about the server before it contacts the server. In a typical situation (e.g. hyperlink following), the client's only initial piece of information about the server is its domain name. Mapping a domain name to information about the thing that lives at that domain name is the defining characteristic of the DNS. It seems to me, therefore, that any solution to the SNI problem must either use DNS or reinvent DNS. I'd prefer the former. There are certainly alternative ways that we could use DNS (e.g. publishing a public key). Of the available options, I felt this was the simplest. I think it could reasonably be extended to a more sophisticated solution if one were developed. > > R's, > John > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a114a9de80a982605489a52cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 6:10 PM, John Levine <johnl@taugh.com> wro= te:
>I'm /soooo/ = not a TLS person, but I think that this was discussed in
>the TLS WG and didn't make it into the final spec -- it requires (a= t
>least) an additional RTT. You do get SNI encryption with Zero-RTT, but<= br> >it's too later by then...
>Some slideware: https://www.ietf.o= rg/proceedings/94/slides/slides-94-tls-8.pdf
>The DNS SNI lookup could at least be done in parallel with the
>"normal" DNS one (and, possibly returned in a
>draft-wkumari-dnsop-multiple-responses answer :-))

To put it baldly, if it is a problem that SNI leaks, the solution is=
to fix SNI.=C2=A0 This is not a solution, it is at most a band-aid that
will deter a subset of unsophisticated snoops while adding useless
complexity to https.=C2=A0 For example, what are users supposed to do when<= br> the SNI DNS records and the SNI mapping in the servers inevitably get
out of sync?

FWIW, the draft recommends= users retry with whatever their behavior would have been otherwise, effect= ively imposing a one roundtrip penalty in this failure case.
=C2= =A0
"But fixing SNI is hard" isn't a good reason to do this.=C2= =A0 I understand
that adding an extra round trip to the handshake would be a problem,
but I am a long way from believing that's the only way to fix SNI.
<= /blockquote>

Removing SNI without adding an extra roundt= rip to every SSL connection logically requires the client to learn an addit= ional piece of information about the server before it contacts the server.= =C2=A0 In a typical situation (e.g. hyperlink following), the client's = only initial piece of information about the server is its domain name.

Mapping a domain name to information about the thing t= hat lives at that domain name is the defining characteristic of the DNS.=C2= =A0 It seems to me, therefore, that any solution to the SNI problem must ei= ther use DNS or reinvent DNS.=C2=A0 I'd prefer the former.
There are certainly alternative ways that we could use DNS (e.= g. publishing a public key).=C2=A0 Of the available options, I felt this wa= s the simplest.=C2=A0 I think it could reasonably be extended to a more sop= histicated solution if one were developed.
=C2=A0

R's,
John


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a114a9de80a982605489a52cc-- From nobody Wed Feb 15 15:50:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C616129BF1 for ; Wed, 15 Feb 2017 15:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEga1qm6cgxG for ; Wed, 15 Feb 2017 15:50:05 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 14E1B129BF0 for ; Wed, 15 Feb 2017 15:50:05 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id x49so1530536qtc.2 for ; Wed, 15 Feb 2017 15:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=xMjD2wNAeXrHSoSXr8gCp+qMVUWa9sHZhZhtZDdGQhQ=; b=ITG4Y41GqzxDqqI7QYxX8h8Y308ujy/dCUFOqU2gtaRM4H4540vJNyzkWst3E0MYD9 GrflUMHuW0bP63Osxe5tQpr5s0BZvDfVZ7+2XoAfpRiVrnc+0+XmCxg01875LGo8ok2M OmDsoXulYguEVdrFHeaE1QRSxlMbdgfX8wZSZpYjUpVv8NsnYcbed85cmtQoXuEgEt2Q VBDi8JQOolVa+dhpoeR+pVKLQcTjWm60j2oV7vTGRnfP8zSS14SbYRC0Jg5oDiQMog+3 yAH3rStybCosazGgCyF830YtNOYqA8OrlGoo+aAXOttNUW2KODpyvmjQo9woqdOBtj1H TnOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=xMjD2wNAeXrHSoSXr8gCp+qMVUWa9sHZhZhtZDdGQhQ=; b=sGIYvpPoPA3HW+vErZNit19pxIMkuzGpJCe41RBac3H1bk7PUea5y91PuOhkTwRw4G 5QizWRb7GKOmhIWUfdNw5MirCPk9eg7SPrSovMKY2bo4rP7SO9GwsIsx/TRhJe0oYORk rWqoRTer2fYPqplU8FqZYo5M3IGwXGjRXAldnlj92C3PMfq6y9zPJNGMfQOeC3MJLJvS d7BvmTMFQW7Oje53LEW25w9BcbHAmzJp2IutJuMwzMO3m5wKcjNp3KXze6WTrPycejS9 guDADEsTJxF1oOc9hTjoEoQ9j1SvqrxM/eXUmDnU3wB3LG3Zuw69M4p6THFj7ooPhET6 sIcQ== X-Gm-Message-State: AMke39k+GpdMZgLH09J2Qii0/A5eX02+qbGAL6FcHC7qUXjcsOnb8DgqfVGW7+2B7Hau/g== X-Received: by 10.200.51.186 with SMTP id c55mr34845715qtb.270.1487202603880; Wed, 15 Feb 2017 15:50:03 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:59a5:f597:9c76:f782? ([2601:181:c381:c20:59a5:f597:9c76:f782]) by smtp.gmail.com with ESMTPSA id q48sm3284087qta.62.2017.02.15.15.50.02 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Feb 2017 15:50:02 -0800 (PST) From: Suzanne Woolf Content-Type: multipart/alternative; boundary="Apple-Mail=_D556B5AA-6A1C-4025-B51C-0477FEF0E25A" Message-Id: <5E800A1B-96F2-42CC-B2CD-78349BB2F38B@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Wed, 15 Feb 2017 18:50:01 -0500 References: To: dnsop In-Reply-To: X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [DNSOP] Webex details Re: correction Re: virtual interim DNSOP WG meeting and current status, special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:50:07 -0000 --Apple-Mail=_D556B5AA-6A1C-4025-B51C-0477FEF0E25A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, The secretariat has graciously given us access to a webex login for the = WG, so the setup details for the virtual interim tomorrow are: Meeting number: 644 850 881 Meeting password: special Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm420b562577eec300c73de2e3c9b7d49f= Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 644 850 881 Agenda: 0. Intro/note well/agenda bash (chairs) 1. Issues from WGLC on the problem statement = (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps) (authors) 2. Update on alt-tld = ((https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/) (authors) 3. Proposals for moving forward: * alt-tld to WGLC? * stop here? (leave RFC 6761 as-is, continue to process registry changes = case-by-case) * proposals for process revision/update? * any drafts to write? * any input or liaison that DNSOP should request from the IAB? = (regarding either namespace architecture or relationships of the IETF = with other groups) 4. AOB: your I-D or proposed action for the WG/IESG/IAB here > On Feb 2, 2017, at 4:48 PM, Suzanne Woolf = wrote: >=20 > And because it=E2=80=99s been that day=E2=80=A6. >=20 > Thanks for the off-list nudge, that=E2=80=99s ***Thursday 16 = February*** for most of the world, Friday 17 February for the AP region. >=20 > We=E2=80=99ve blocked two hours for the meeting. >=20 > Apologies for the error. >=20 >=20 > Suzanne >=20 >=20 >> On Feb 2, 2017, at 3:52 PM, Suzanne Woolf > wrote: >> 3. We still want (and have time) to do a virtual interim WG meeting = before Chicago. We=E2=80=99ve picked a date: >>=20 >> Thursday 17 February, 19:00 UTC, which is: >>=20 >> 19:00 UTC >> 20:00 CEST (Frankfurt, Stockholm) >> 14:00 EST (North American Eastern) >> 11:00 PST (North American Western) >> 06:00 AEDT (Sydney, Melbourne) >>=20 >> (Webex details will follow) >>=20 >> As usual, scheduling isn=E2=80=99t perfect for anyone but we tried to = cover the largest possible area of the globe adequately. >>=20 >> Preliminary agenda for the meeting is: >>=20 >> 1. Issues from WGLC on the problem statement = (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ = ) >> 2. Proposals for moving forward: >> * reviews of alt-tld; ready for WGLC? will it help? = (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ = ) >> * stop here? (leave RFC 6761 as-is, continue to process = registry changes case-by-case) >> * proposals for process revision/update? >> 3. Next steps:=20 >> * any drafts to write? >> * any input or liaison to request from the IAB? = (regarding either namespace architecture or relationships of the IETF = with other groups) >> 4. AOB: your I-D or proposed action for the WG/IESG/IAB here >>=20 >>=20 >> thanks, >> Suzanne & Tim >>=20 >=20 --Apple-Mail=_D556B5AA-6A1C-4025-B51C-0477FEF0E25A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

The = secretariat has graciously given us access to a webex login for the WG, = so the setup details for the virtual interim tomorrow are:

Meeting = number: 644 850 881
Meeting = password: special

Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm420b562577eec300c73de= 2e3c9b7d49f

Audio connection:

= 1-877-668-4493 Call-in toll free number (US/Canada)

= 1-650-479-3208 Call-in toll number (US/Canada)

Access = code: 644 850 881

Agenda:

0. Intro/note well/agenda = bash (chairs)

1. Issues from WGLC on the problem statement (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps)= (authors)

2. Update on alt-tld ((https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/)= (authors)

3. Proposals for moving forward:

* = alt-tld to WGLC?

* stop here? (leave RFC 6761 as-is, continue to = process registry changes case-by-case)

* proposals for process = revision/update?

* any drafts to write?

* = any input or liaison that DNSOP should request from the IAB? (regarding = either namespace architecture or relationships of the IETF with other = groups)

4. AOB: your I-D or proposed action for the = WG/IESG/IAB here

On Feb 2, 2017, at 4:48 PM, Suzanne Woolf <suzworldwide@gmail.com> wrote:

And because = it=E2=80=99s been that day=E2=80=A6.

Thanks for the off-list nudge, that=E2=80= =99s ***Thursday 16 February*** for most of the world, Friday 17 = February for the AP region.

We=E2=80=99ve blocked two hours for the meeting.

Apologies for the = error.


Suzanne


On Feb = 2, 2017, at 3:52 PM, Suzanne Woolf <suzworldwide@gmail.com> wrote:
3. We still want (and = have time) to do a virtual interim WG meeting before = Chicago. We=E2=80=99ve picked a date:

Thursday 17 February, = 19:00 UTC, which is:

19:00 UTC
20:00 CEST (Frankfurt, = Stockholm)
14:00 EST (North American = Eastern)
11:00 PST (North American = Western)
06:00 AEDT (Sydney, Melbourne)

(Webex details will follow)

As usual, scheduling = isn=E2=80=99t perfect for anyone but we tried to cover the largest = possible area of the globe adequately.

Preliminary agenda for the meeting is:

= 1. Issues from WGLC on the problem statement (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/= )
2. Proposals for moving forward:
* reviews = of alt-tld; ready for WGLC? will it help? (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/)=
* stop here? (leave RFC 6761 as-is, continue to process = registry changes case-by-case)
* = proposals for process revision/update?
3. Next = steps: 
* any drafts to write?
= = * any input or liaison to request from the IAB? (regarding either = namespace architecture or relationships of the IETF with other = groups)
4. AOB: your I-D or proposed = action for the WG/IESG/IAB here


thanks,
Suzanne & Tim



= --Apple-Mail=_D556B5AA-6A1C-4025-B51C-0477FEF0E25A-- From nobody Wed Feb 15 18:14:46 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E071B129C18; Wed, 15 Feb 2017 18:14:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148721128491.31391.12912602191917167130.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 18:14:44 -0800 Archived-At: Cc: tjw.ietf@gmail.com, draft-ietf-dnsop-edns-key-tag@ietf.org, dnsop@ietf.org, dnsop-chairs@ietf.org Subject: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-edns-key-tag-04: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 02:14:45 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-edns-key-tag-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - abstract: referring to section 1.1 from here seems wrong, the abstract ought be readable by itself - section 5: Is the key tag query only and solely intended to allow the authoritative to track how clients are paying attention (or not) to key rollovers? If there's another purpose I'm not clear about it. - 5.3: "I believe that to be..." seems like the wrong language to use with >1 author. - section 7/8: Is there a missing security/privacy consideration here, in that an authoritative server here could arrange to hand out key tags that are specific to (in the limit) each query, so that when the resolver queries a sub-domain, and thereafter, the client will be identifiable to the authoritative server? One could do this by generating new keys per querier so that if I ask about example.com I get given a tag that's unique to me, and then some web content pushes me to ask about www.example.com and every time I do that I emit that user-specific key tag. While that'd be unlikely for a large zone, it might be feasible as a tracker if some "bad" domain sets up a specific subdomain for such purposes. That said, I'm not clear how much better this is for the attacker compared to simply using a tracking name in the authority component of the URL for e.g. some 1x1 gif. From nobody Wed Feb 15 19:50:30 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD557129540; Wed, 15 Feb 2017 19:50:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148721702870.31395.2353566837595419712.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 19:50:28 -0800 Archived-At: Cc: tjw.ietf@gmail.com, draft-ietf-dnsop-edns-key-tag@ietf.org, dnsop@ietf.org, dnsop-chairs@ietf.org Subject: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-edns-key-tag-04: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 03:50:28 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dnsop-edns-key-tag-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It's unfortunate that the working group couldn't agree on one mechanism, but that's not enough to stand in the way of publication. From nobody Thu Feb 16 02:29:40 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E512C1299FB; Thu, 16 Feb 2017 02:29:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148724097993.15976.5522065446395112543.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 02:29:39 -0800 Archived-At: Cc: tjw.ietf@gmail.com, draft-ietf-dnsop-edns-key-tag@ietf.org, dnsop@ietf.org, dnsop-chairs@ietf.org, mjethanandani@gmail.com Subject: [DNSOP] Benoit Claise's No Objection on draft-ietf-dnsop-edns-key-tag-04: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 10:29:40 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dnsop-edns-key-tag-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Discussion engaged between the Mahesh (OPS DIR reviewer) and the author. https://www.ietf.org/mail-archive/web/ops-dir/current/msg02457.html From nobody Thu Feb 16 04:40:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C551129578 for ; Thu, 16 Feb 2017 04:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 z4rekvXC6drk for ; Thu, 16 Feb 2017 04:40:12 -0800 (PST) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570EE129C47 for ; Thu, 16 Feb 2017 04:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=23440; q=dns/txt; s=VRSN; t=1487248813; h=from:to:date:message-id:references:in-reply-to: mime-version; bh=/MEp3rQd9TcsdRTvhVx90eHu4sc6haSwefvGpCQxEF4=; b=FN1dDL24f1v/VYPK4shxRjg8bjCu/eD1cBgzQuIti7SAIvpD/HkQCevT NS8OKJbBDM3AZbSArhl361gNYcyW6BtUcKJc4O0ntEWthVFpOu/6fgR4S c2aMV+V5niqxmaQbkrob0lkF3deAOCYPbGdA43zsgeZUvomqYxzfFNkgl SWryicYN+/G/HFo+AR4AzWKZHHJiOjq6w0UyDQOxPlS3yrVeI3p2z0YkY pu5QFkAoDVDeM/yPOzUIj+uT6ST6QToMdTDfQaQl+7/BdOQ/7Io+yZmGQ i+2R8g22ex0igRScywNWwPXH7RKr6Cv/nyGHyxYF7MrX69q4+gKBR6AI6 A==; X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="1519741" IronPort-PHdr: =?us-ascii?q?9a23=3Am7DQnBRQjObT90pAvwNEas0mdNpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa6zbBSN2/xhgRfzUJnB7Loc0qyN4v2mATBLusnJmUtBWaQEbwUCh8?= =?us-ascii?q?QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFRrlKAV6?= =?us-ascii?q?OPn+FJLMgMSrzeCy/IDYbxlViDanb75/KBW7oR/NusQZjodvJKQ8wQbVr3VVfO?= =?us-ascii?q?hb2XlmLk+JkRbm4cew8p9j8yBOtP8k6sVNT6b0cbkmQLJBFDgpPHw768PttRnY?= =?us-ascii?q?UAuA/WAcXXkMkhpJGAfK8hf3VYrsvyTgt+p93C6aPdDqTb0xRD+v4btnRAPuhS?= =?us-ascii?q?waMTMy7WPZhdFqjK9DoByvuQFxw5Labo+WOvpxfKLdcs8VSmdaRMldSyhMD5mg?= =?us-ascii?q?Y4cTDecMO/tToYnnp1sJqBuzHQegCuHoyj9Mgn/5w6s63P8/Hg7a3wwsB88Fvm?= =?us-ascii?q?nIo9XyKKcSTe65x7TPwDXYb/NW3jP96IzWfRAnuv6DQ65/ccnKxEkxCQzFlFSQ?= =?us-ascii?q?qZfkPzOa0OQBqXSU7+1lVe+2jWMstg9/oj+qxsg2i4nJgJoYy17a+ipi3ok0Ks?= =?us-ascii?q?e0R1J8Yd6hCJdQtj+VN5d4Qs84RGFooik6x7sbspC4ZCgH0IkrywLFZ/CacYWF?= =?us-ascii?q?7AjvWPuRLDp2nn5pZr2yihaq/US91uHwTNS43VREoyZfj9XBtm4B2wbc58WBV/?= =?us-ascii?q?Bz5F2u2SyV2ADW8uxEJEc0mrfFJJM52b4wk4YTsVzEHi/rhEX6lK+WeVsg+uiv?= =?us-ascii?q?8+noea/mppmBO49whQD+N74hms27AeQ/LwgOQ3SX9fqm2L3940L5WrRKjuY3kq?= =?us-ascii?q?nWtpDWP9gUpqm8AwNN04Yj7QiwDyu+3dgFgXULNk9JdRCJgoTzJl3DIP71Ae2h?= =?us-ascii?q?j1mjkDpn3/XGMafgApXJIHjDirDhfbNl5k5HyAozytRf55ZKBbEHO/38RFP+tN?= =?us-ascii?q?/DAx8nLQO02efnCM581oMRX2KDGLOWMKTXsVOQ/OIgP/GMZJMJuDb6M/Uq+vju?= =?us-ascii?q?jWQ+mV8FZqSp3IUYaGy2Hvh8JEWZe3XsiM8bEWgWpgo+UPDqiFqaXD5IenazXq?= =?us-ascii?q?w95jYhCIKiEIjCSIGtj6Gf0yqgEZ1WY3pJClGIEXvya4qEXPIMO2quJZor3ScZ?= =?us-ascii?q?R6emUYstyhCiuSf1zrNmKqzf/ShX/9q3z8Vn+OrJkR0t9DB5J8uY2mCJCWpzmz?= =?us-ascii?q?VMD3V50KZkplRVy1qf3+5/mfMXX5QH6/VSVR8SNJPAwap9Ed+kCSzbedLcAnah?= =?us-ascii?q?RtGrBzs8RdF1i+QFZFphUZ32lRDE2y6nBbUYnL+jGpEu87nd0H63LMF4nSWVnJ?= =?us-ascii?q?I9hkUrF5McfVatgbRyolDe?= X-IPAS-Result: =?us-ascii?q?A2EvAABxnaVY//WZrQpEFwMaAQEBAQIBAQEBCAEBAQEVAQE?= =?us-ascii?q?BAQIBAQEBCAEBAQGCRIFDgQkHg1KKCJIQgx2EbosZgg+BJQQgQyyFdgIagkcYA?= =?us-ascii?q?QEBAQEBAQEBAQECgQeCMyAPPQYEMgEBAQEBAQEBAQEBAQEBAQEBARcCPQESAQE?= =?us-ascii?q?YAQEBAQMjCjkMFwIBCA0EAQMBAQsKAgEBCwEDAwICAh8RFAMGBwECBAESCIlMA?= =?us-ascii?q?yMtr3SCJYNUg2QNg3YBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZNhG6BPAGBFEa?= =?us-ascii?q?BLhEVChURAQEFghImLoIXGgWJdotmhWk0BgGGb4YzWoYVjwuILYIKiGEfdURRU?= =?us-ascii?q?oRGHRl9S3UBh3sNgSGBDQEBAQ?= Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id v1GCe7sm002243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 07:40:07 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Thu, 16 Feb 2017 07:40:07 -0500 From: "Hollenbeck, Scott" To: "'suzworldwide@gmail.com'" , "'dnsop@ietf.org'" Thread-Topic: [EXTERNAL] [DNSOP] Webex details Re: correction Re: virtual interim DNSOP WG meeting and current status, special use names Thread-Index: AQHSh+ZF9uai2HRXLU6cdyq15uZHzqFrk3eQ Date: Thu, 16 Feb 2017 12:40:06 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F56F2A589@BRN1WNEXMBX02.vcorp.ad.vrsn.com> References: <5E800A1B-96F2-42CC-B2CD-78349BB2F38B@gmail.com> In-Reply-To: <5E800A1B-96F2-42CC-B2CD-78349BB2F38B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F56F2A589BRN1WNEXMBX02vc_" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] Webex details Re: correction Re: virtual interim DNSOP WG meeting and current status, special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 12:40:19 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F56F2A589BRN1WNEXMBX02vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2lsbCB0aGUgamFiYmVyIHJvb20gYXQgZG5zb3BAamFiYmVyLmlldGYub3JnPG1haWx0bzpkbnNv cEBqYWJiZXIuaWV0Zi5vcmc+IGFsc28gYmUgdXNlZD8NCg0KDQoNClNjb3R0DQoNCg0KDQpGcm9t OiBETlNPUCBbbWFpbHRvOmRuc29wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXph bm5lIFdvb2xmDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAyMDE3IDY6NTAgUE0NClRv OiBkbnNvcCA8ZG5zb3BAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFtETlNPUF0gV2Vi ZXggZGV0YWlscyBSZTogY29ycmVjdGlvbiBSZTogdmlydHVhbCBpbnRlcmltIEROU09QIFdHIG1l ZXRpbmcgYW5kIGN1cnJlbnQgc3RhdHVzLCBzcGVjaWFsIHVzZSBuYW1lcw0KDQoNCg0KSGksDQoN Cg0KDQpUaGUgc2VjcmV0YXJpYXQgaGFzIGdyYWNpb3VzbHkgZ2l2ZW4gdXMgYWNjZXNzIHRvIGEg d2ViZXggbG9naW4gZm9yIHRoZSBXRywgc28gdGhlIHNldHVwIGRldGFpbHMgZm9yIHRoZSB2aXJ0 dWFsIGludGVyaW0gdG9tb3Jyb3cgYXJlOg0KDQoNCg0KICAgICAgICAgIE1lZXRpbmcgbnVtYmVy OiA2NDQgODUwIDg4MQ0KDQogICAgICAgICAgTWVldGluZyBwYXNzd29yZDogc3BlY2lhbA0KDQoN Cg0KICAgICAgICAgIE1lZXRpbmcgbGluazogaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bTQyMGI1NjI1NzdlZWMzMDBjNzNkZTJlM2M5YjdkNDlmDQoNCg0KDQogICAgICAg ICAgQXVkaW8gY29ubmVjdGlvbjoNCg0KDQoNCiAgICAgICAgICAxLTg3Ny02NjgtNDQ5MyBDYWxs LWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkNCg0KDQoNCiAgICAgICAgICAxLTY1MC00 NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQoNCg0KDQogICAgICAgICAg QWNjZXNzIGNvZGU6IDY0NCA4NTAgODgxDQoNCg0KDQpBZ2VuZGE6DQoNCg0KDQowLiBJbnRyby9u b3RlIHdlbGwvYWdlbmRhIGJhc2ggKGNoYWlycykNCg0KDQoNCjEuIElzc3VlcyBmcm9tIFdHTEMg b24gdGhlIHByb2JsZW0gc3RhdGVtZW50IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWRuc29wLXN1dGxkLXBzKSAoYXV0aG9ycykNCg0KDQoNCjIuIFVwZGF0ZSBv biBhbHQtdGxkICgoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1k bnNvcC1hbHQtdGxkLykgKGF1dGhvcnMpDQoNCg0KDQozLiBQcm9wb3NhbHMgZm9yIG1vdmluZyBm b3J3YXJkOg0KDQoNCg0KKiBhbHQtdGxkIHRvIFdHTEM/DQoNCg0KDQoqIHN0b3AgaGVyZT8gKGxl YXZlIFJGQyA2NzYxIGFzLWlzLCBjb250aW51ZSB0byBwcm9jZXNzIHJlZ2lzdHJ5IGNoYW5nZXMg Y2FzZS1ieS1jYXNlKQ0KDQoNCg0KKiBwcm9wb3NhbHMgZm9yIHByb2Nlc3MgcmV2aXNpb24vdXBk YXRlPw0KDQoNCg0KKiBhbnkgZHJhZnRzIHRvIHdyaXRlPw0KDQoNCg0KKiBhbnkgaW5wdXQgb3Ig bGlhaXNvbiB0aGF0IEROU09QIHNob3VsZCByZXF1ZXN0IGZyb20gdGhlIElBQj8gKHJlZ2FyZGlu ZyBlaXRoZXIgbmFtZXNwYWNlIGFyY2hpdGVjdHVyZSBvciByZWxhdGlvbnNoaXBzIG9mIHRoZSBJ RVRGIHdpdGggb3RoZXIgZ3JvdXBzKQ0KDQoNCg0KNC4gQU9COiB5b3VyIEktRCBvciBwcm9wb3Nl ZCBhY3Rpb24gZm9yIHRoZSBXRy9JRVNHL0lBQiBoZXJlDQoNCg0KDQogICBPbiBGZWIgMiwgMjAx NywgYXQgNDo0OCBQTSwgU3V6YW5uZSBXb29sZiA8c3V6d29ybGR3aWRlQGdtYWlsLmNvbTxtYWls dG86c3V6d29ybGR3aWRlQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCg0KICAgQW5kIGJlY2F1c2Ug aXTigJlzIGJlZW4gdGhhdCBkYXnigKYuDQoNCg0KDQogICBUaGFua3MgZm9yIHRoZSBvZmYtbGlz dCBudWRnZSwgdGhhdOKAmXMgKioqVGh1cnNkYXkgMTYgRmVicnVhcnkqKiogZm9yIG1vc3Qgb2Yg dGhlIHdvcmxkLCBGcmlkYXkgMTcgRmVicnVhcnkgZm9yIHRoZSBBUCByZWdpb24uDQoNCg0KDQog ICBXZeKAmXZlIGJsb2NrZWQgdHdvIGhvdXJzIGZvciB0aGUgbWVldGluZy4NCg0KDQoNCiAgIEFw b2xvZ2llcyBmb3IgdGhlIGVycm9yLg0KDQoNCg0KDQoNCiAgIFN1emFubmUNCg0KDQoNCg0KDQog ICAgICBPbiBGZWIgMiwgMjAxNywgYXQgMzo1MiBQTSwgU3V6YW5uZSBXb29sZiA8c3V6d29ybGR3 aWRlQGdtYWlsLmNvbTxtYWlsdG86c3V6d29ybGR3aWRlQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQog ICAgICAzLiBXZSBzdGlsbCB3YW50IChhbmQgaGF2ZSB0aW1lKSB0byBkbyBhIHZpcnR1YWwgaW50 ZXJpbSBXRyBtZWV0aW5nIGJlZm9yZSBDaGljYWdvLiBXZeKAmXZlIHBpY2tlZCBhIGRhdGU6DQoN Cg0KDQogICAgICBUaHVyc2RheSAxNyBGZWJydWFyeSwgMTk6MDAgVVRDLCB3aGljaCBpczoNCg0K DQoNCiAgICAgIDE5OjAwIFVUQw0KDQogICAgICAyMDowMCBDRVNUIChGcmFua2Z1cnQsIFN0b2Nr aG9sbSkNCg0KICAgICAgMTQ6MDAgRVNUIChOb3J0aCBBbWVyaWNhbiBFYXN0ZXJuKQ0KDQogICAg ICAxMTowMCBQU1QgKE5vcnRoIEFtZXJpY2FuIFdlc3Rlcm4pDQoNCiAgICAgIDA2OjAwIEFFRFQg KFN5ZG5leSwgTWVsYm91cm5lKQ0KDQoNCg0KICAgICAgKFdlYmV4IGRldGFpbHMgd2lsbCBmb2xs b3cpDQoNCg0KDQogICAgICBBcyB1c3VhbCwgc2NoZWR1bGluZyBpc27igJl0IHBlcmZlY3QgZm9y IGFueW9uZSBidXQgd2UgdHJpZWQgdG8gY292ZXIgdGhlIGxhcmdlc3QgcG9zc2libGUgYXJlYSBv ZiB0aGUgZ2xvYmUgYWRlcXVhdGVseS4NCg0KICAgICAgUHJlbGltaW5hcnkgYWdlbmRhIGZvciB0 aGUgbWVldGluZyBpczoNCg0KICAgICAgICAgICAgICAgIDEuIElzc3VlcyBmcm9tIFdHTEMgb24g dGhlIHByb2JsZW0gc3RhdGVtZW50IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWRuc29wLXN1dGxkLXBzLykNCiAgICAgICAgICAgICAgICAyLiBQcm9wb3NhbHMg Zm9yIG1vdmluZyBmb3J3YXJkOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICogcmV2aWV3 cyBvZiBhbHQtdGxkOyByZWFkeSBmb3IgV0dMQz8gd2lsbCBpdCBoZWxwPyAoaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kbnNvcC1hbHQtdGxkLykNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAqIHN0b3AgaGVyZT8gKGxlYXZlIFJGQyA2NzYxIGFzLWlzLCBj b250aW51ZSB0byBwcm9jZXNzIHJlZ2lzdHJ5IGNoYW5nZXMgY2FzZS1ieS1jYXNlKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICogcHJvcG9zYWxzIGZvciBwcm9jZXNzIHJldmlzaW9uL3Vw ZGF0ZT8NCiAgICAgICAgICAgICAgICAzLiBOZXh0IHN0ZXBzOg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICogYW55IGRyYWZ0cyB0byB3cml0ZT8NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAqIGFueSBpbnB1dCBvciBsaWFpc29uIHRvIHJlcXVlc3QgZnJvbSB0aGUgSUFCPyAocmVn YXJkaW5nIGVpdGhlciBuYW1lc3BhY2UgYXJjaGl0ZWN0dXJlIG9yIHJlbGF0aW9uc2hpcHMgb2Yg dGhlIElFVEYgd2l0aCBvdGhlciBncm91cHMpDQoNCiAgICAgICAgICAgICAgICA0LiBBT0I6IHlv dXIgSS1EIG9yIHByb3Bvc2VkIGFjdGlvbiBmb3IgdGhlIFdHL0lFU0cvSUFCIGhlcmUNCg0KDQoN Cg0KDQogICAgICB0aGFua3MsDQoNCiAgICAgIFN1emFubmUgJiBUaW0NCg0KDQoNCg0KDQoNCg0K --_000_831693C2CDA2E849A7D7A712B24E257F56F2A589BRN1WNEXMBX02vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtdGFiLXNw YW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxF bmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2lsbCB0aGUgamFiYmVy IHJvb20gYXQNCjwvc3Bhbj48L2E+PGEgaHJlZj0ibWFpbHRvOmRuc29wQGphYmJlci5pZXRmLm9y ZyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+ZG5zb3BAamFiYmVyLmlldGYub3JnPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPg0K IGFsc28gYmUgdXNlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2NvdHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBETlNPUCBbbWFpbHRvOmRuc29wLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2YgPC9iPlN1emFubmUgV29vbGY8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBGZWJydWFyeSAxNSwgMjAxNyA2OjUwIFBNPGJyPg0KPGI+VG86PC9iPiBkbnNvcCAmbHQ7ZG5z b3BAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gW0ROU09QXSBX ZWJleCBkZXRhaWxzIFJlOiBjb3JyZWN0aW9uIFJlOiB2aXJ0dWFsIGludGVyaW0gRE5TT1AgV0cg bWVldGluZyBhbmQgY3VycmVudCBzdGF0dXMsIHNwZWNpYWwgdXNlIG5hbWVzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2VjcmV0YXJpYXQgaGFzIGdyYWNpb3Vz bHkgZ2l2ZW4gdXMgYWNjZXNzIHRvIGEgd2ViZXggbG9naW4gZm9yIHRoZSBXRywgc28gdGhlIHNl dHVwIGRldGFpbHMgZm9yIHRoZSB2aXJ0dWFsIGludGVyaW0gdG9tb3Jyb3cgYXJlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5NZWV0aW5nIG51bWJlcjogNjQ0 IDg1MCA4ODE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5NZWV0aW5nIHBhc3N3b3JkOiBz cGVjaWFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5NZWV0aW5nIGxpbms6IDxhIGhy ZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW00MjBiNTYyNTc3ZWVj MzAwYzczZGUyZTNjOWI3ZDQ5ZiI+DQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/ TVRJRD1tNDIwYjU2MjU3N2VlYzMwMGM3M2RlMmUzYzliN2Q0OWY8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBs ZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj5BdWRpbyBjb25uZWN0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+MS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5h ZGEpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4xLTY1MC00NzktMzIwOCBDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5B Y2Nlc3MgY29kZTogNjQ0IDg1MCA4ODE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdlbmRhOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4wLiBJbnRyby9ub3RlIHdlbGwvYWdlbmRhIGJhc2gg KGNoYWlycyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+MS4gSXNzdWVzIGZyb20gV0dMQyBvbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgKDxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG5zb3Atc3V0 bGQtcHMiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG5zb3At c3V0bGQtcHM8L2E+KSAoYXV0aG9ycyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gVXBkYXRlIG9uIGFsdC10bGQgKCg8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRuc29wLWFsdC10bGQvIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRuc29wLWFsdC10bGQv PC9hPikgKGF1dGhvcnMpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjMuIFByb3Bvc2FscyBmb3IgbW92aW5nIGZvcndhcmQ6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogYWx0LXRsZCB0byBX R0xDPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4qIHN0b3AgaGVyZT8gKGxlYXZlIFJGQyA2NzYxIGFzLWlzLCBjb250aW51ZSB0byBwcm9jZXNz IHJlZ2lzdHJ5IGNoYW5nZXMgY2FzZS1ieS1jYXNlKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIHByb3Bvc2FscyBmb3IgcHJvY2VzcyByZXZp c2lvbi91cGRhdGU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiogYW55IGRyYWZ0cyB0byB3cml0ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBhbnkgaW5wdXQgb3IgbGlhaXNvbiB0aGF0 IEROU09QIHNob3VsZCByZXF1ZXN0IGZyb20gdGhlIElBQj8gKHJlZ2FyZGluZyBlaXRoZXIgbmFt ZXNwYWNlIGFyY2hpdGVjdHVyZSBvciByZWxhdGlvbnNoaXBzIG9mIHRoZSBJRVRGIHdpdGggb3Ro ZXIgZ3JvdXBzKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj40LiBBT0I6IHlvdXIgSS1EIG9yIHByb3Bvc2VkIGFjdGlvbiBmb3IgdGhlIFdHL0lF U0cvSUFCIGhlcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMiwgMjAxNywgYXQgNDo0OCBQTSwgU3V6 YW5uZSBXb29sZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1endvcmxkd2lkZUBnbWFpbC5jb20iPnN1 endvcmxkd2lkZUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBiZWNhdXNlIGl04oCZcyBiZWVuIHRoYXQgZGF5 4oCmLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz IGZvciB0aGUgb2ZmLWxpc3QgbnVkZ2UsIHRoYXTigJlzICoqKlRodXJzZGF5IDE2IEZlYnJ1YXJ5 KioqIGZvciBtb3N0IG9mIHRoZSB3b3JsZCwgRnJpZGF5IDE3IEZlYnJ1YXJ5IGZvciB0aGUgQVAg cmVnaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XZeKAmXZlIGJsb2NrZWQgdHdvIGhvdXJzIGZvciB0aGUgbWVldGluZy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXBvbG9naWVzIGZv ciB0aGUgZXJyb3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U3V6YW5uZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMiwgMjAxNywgYXQgMzo1MiBQTSwgU3V6YW5uZSBX b29sZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1endvcmxkd2lkZUBnbWFpbC5jb20iPnN1endvcmxk d2lkZUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBXZSBzdGlsbCB3YW50IChhbmQgaGF2 ZSB0aW1lKSB0byBkbyBhIHZpcnR1YWwgaW50ZXJpbSBXRyBtZWV0aW5nIGJlZm9yZSBDaGljYWdv LiZuYnNwO1dl4oCZdmUgcGlja2VkIGEgZGF0ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRodXJzZGF5IDE3IEZlYnJ1YXJ5LCAxOTowMCBVVEMsIHdoaWNo IGlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4xOTowMCBVVEM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjIwOjAwIENFU1QgKEZyYW5rZnVydCwgU3RvY2tob2xtKTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MTQ6MDAgRVNUIChOb3J0aCBBbWVy aWNhbiBFYXN0ZXJuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MTE6MDAgUFNUIChOb3J0aCBBbWVyaWNhbiBXZXN0ZXJuKTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MDY6MDAgQUVEVCAoU3lkbmV5 LCBNZWxib3VybmUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+KFdlYmV4IGRldGFpbHMgd2lsbCBmb2xsb3cpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyB1c3VhbCwgc2NoZWR1bGluZyBpc27igJl0IHBlcmZlY3Qg Zm9yIGFueW9uZSBidXQgd2UgdHJpZWQgdG8gY292ZXIgdGhlIGxhcmdlc3QgcG9zc2libGUgYXJl YSBvZiB0aGUgZ2xvYmUgYWRlcXVhdGVseS48YnI+DQo8YnI+DQpQcmVsaW1pbmFyeSBhZ2VuZGEg Zm9yIHRoZSBtZWV0aW5nIGlzOjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3Bh biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj4xLiBJc3N1ZXMgZnJvbSBXR0xDIG9uIHRoZSBwcm9ibGVtIHN0YXRlbWVudCAoPGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kbnNvcC1z dXRsZC1wcy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG5z b3Atc3V0bGQtcHMvPC9hPik8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ Mi4gUHJvcG9zYWxzIGZvciBtb3ZpbmcgZm9yd2FyZDo8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+KiByZXZpZXdzIG9mIGFsdC10bGQ7IHJlYWR5 IGZvciBXR0xDPyB3aWxsIGl0IGhlbHA/ICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWRuc29wLWFsdC10bGQvIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRuc29wLWFsdC10bGQvPC9hPik8YnI+DQo8c3BhbiBj bGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+KiBzdG9wIGhlcmU/IChs ZWF2ZSBSRkMgNjc2MSBhcy1pcywgY29udGludWUgdG8gcHJvY2VzcyByZWdpc3RyeSBjaGFuZ2Vz IGNhc2UtYnktY2FzZSk8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+KiBwcm9wb3NhbHMgZm9yIHByb2Nlc3MgcmV2aXNpb24vdXBkYXRlPzxicj4N CjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4zLiBOZXh0IHN0ZXBzOiZuYnNwOzxi cj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4qIGFu eSBkcmFmdHMgdG8gd3JpdGU/PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPiogYW55IGlucHV0IG9yIGxpYWlzb24gdG8gcmVxdWVzdCBmcm9tIHRo ZSBJQUI/IChyZWdhcmRpbmcgZWl0aGVyIG5hbWVzcGFjZSBhcmNoaXRlY3R1cmUgb3IgcmVsYXRp b25zaGlwcyBvZiB0aGUgSUVURiB3aXRoIG90aGVyIGdyb3Vwcyk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt c3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj40LiBBT0I6IHlvdXIgSS1EIG9yIHByb3Bvc2VkIGFjdGlvbiBmb3IgdGhlIFdH L0lFU0cvSUFCIGhlcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj50aGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TdXphbm5lICZhbXA7IFRpbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_831693C2CDA2E849A7D7A712B24E257F56F2A589BRN1WNEXMBX02vc_-- From nobody Thu Feb 16 04:42:52 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593DD129CE6 for ; Thu, 16 Feb 2017 04:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqnQJzjvuTg2 for ; Thu, 16 Feb 2017 04:42:48 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 8FCD1129566 for ; Thu, 16 Feb 2017 04:42:48 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id u25so13924192qki.2 for ; Thu, 16 Feb 2017 04:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ZjNl6t1t0kArHwGGOI0l3+o/FAt2wgjbqAKnr6u8lzQ=; b=U3K093cJNfbDD1jxTTfxDggBNIF6deG+jLK4HgTJUq0myiLEr2PnBMhnzlZc2y7Nf5 3nGk3R3qxerRthOd+lHCIMTg3JMe7DRwyRH1Oxn66iqL1wVRIRGe0iZh72T9kb5yjdnc dMJ6hu/yR1sQRyjXXA7EXwUin9N0mWGQrIOziXo9cTZshRAbplaht+JL2G/hHH4VjSrp s8RcyoiLLVUbYBEgtoXnIuebzTGkRiNwUnfbiil32OgMYUI65Zvixo90v0OAM7vSBHtB YpvhtE5ZZXDxdgHXteuch+hIP2xB/nbYB0l1z5EOKfVkPAeHhBTG91vo8hPuPb0vCdYx m77A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZjNl6t1t0kArHwGGOI0l3+o/FAt2wgjbqAKnr6u8lzQ=; b=lHYc82txgOTkKqiennpTmbz/VuPwRlVXW6WS4ehssVcO9Yb3gjm1o8lJnpGDr/9amN 4T8iI/Qe3/zrYmS2TGTvU4381IiBcKYEYzkFgHEAZnbrjWDEtfCi0v1FZcRfcvGRuI6s esDuOW176KBzkY13Tr2xz3s9RmH17QR0gsgQ+UaKraPr6GgP+THd1l+2PP2rnGWlROAl ki9rjRSHecy901lclPwsjRvahyJ1JGWKUPF7xp79slrg4f4p/lCpp3mpyR4aSQY5/jOP Cw++eDS6A5kIL1ugt2HoNuu6/0IvY28wpmYy1UBQhoGXA1G/sOHltLc39GpTZTN4QEEO 5gmA== X-Gm-Message-State: AMke39n3JZWNKj67r4pd1su2BQ7Bxk0GzXeal+TZjydHDUgk3hwbmRPmkijYoGwFWzna8A== X-Received: by 10.55.183.133 with SMTP id h127mr1912547qkf.121.1487248967554; Thu, 16 Feb 2017 04:42:47 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:791f:21c2:484:8f4c? ([2601:181:c381:c20:791f:21c2:484:8f4c]) by smtp.gmail.com with ESMTPSA id q3sm4337127qte.0.2017.02.16.04.42.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 04:42:46 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5042B31B-5E3E-4CE6-A020-F2469C86A2BE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F56F2A589@BRN1WNEXMBX02.vcorp.ad.vrsn.com> Date: Thu, 16 Feb 2017 07:42:44 -0500 Message-Id: References: <5E800A1B-96F2-42CC-B2CD-78349BB2F38B@gmail.com> <831693C2CDA2E849A7D7A712B24E257F56F2A589@BRN1WNEXMBX02.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Webex details Re: correction Re: virtual interim DNSOP WG meeting and current status, special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 12:42:50 -0000 --Apple-Mail=_5042B31B-5E3E-4CE6-A020-F2469C86A2BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The intent is to conduct the session as much like an ordinary IETF WG = meeting as possible. So yes, we=E2=80=99ll monitor the jabber room and record the session. This also means we=E2=80=99ll need a note-taker, any volunteers?? Suzanne > On Feb 16, 2017, at 7:40 AM, Hollenbeck, Scott = wrote: >=20 > Will the jabber room at=C2=A0 <>dnsop@jabber.ietf.org = also be used? > =20 > Scott > =20 > From: DNSOP [mailto:dnsop-bounces@ietf.org = ] On Behalf Of Suzanne Woolf > Sent: Wednesday, February 15, 2017 6:50 PM > To: dnsop > > Subject: [EXTERNAL] [DNSOP] Webex details Re: correction Re: virtual = interim DNSOP WG meeting and current status, special use names > =20 > Hi, > =20 > The secretariat has graciously given us access to a webex login for = the WG, so the setup details for the virtual interim tomorrow are: > =20 > Meeting number: 644 850 881 > Meeting password: special > =20 > Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm420b562577eec300c73de2e3c9b7d49f= = > =20 > Audio connection: > =20 > 1-877-668-4493 Call-in toll free number (US/Canada) > =20 > 1-650-479-3208 Call-in toll number (US/Canada) > =20 > Access code: 644 850 881 > =20 > Agenda: > =20 > 0. Intro/note well/agenda bash (chairs) > =20 > 1. Issues from WGLC on the problem statement = (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps = ) (authors) > =20 > 2. Update on alt-tld = ((https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ = ) (authors) > =20 > 3. Proposals for moving forward: > =20 > * alt-tld to WGLC? > =20 > * stop here? (leave RFC 6761 as-is, continue to process registry = changes case-by-case) > =20 > * proposals for process revision/update? > =20 > * any drafts to write? > =20 > * any input or liaison that DNSOP should request from the IAB? = (regarding either namespace architecture or relationships of the IETF = with other groups) > =20 > 4. AOB: your I-D or proposed action for the WG/IESG/IAB here > =20 > On Feb 2, 2017, at 4:48 PM, Suzanne Woolf > wrote: > =20 > And because it=E2=80=99s been that day=E2=80=A6. > =20 > Thanks for the off-list nudge, that=E2=80=99s ***Thursday 16 = February*** for most of the world, Friday 17 February for the AP region. > =20 > We=E2=80=99ve blocked two hours for the meeting. > =20 > Apologies for the error. > =20 > =20 > Suzanne > =20 > =20 > On Feb 2, 2017, at 3:52 PM, Suzanne Woolf > wrote: > 3. We still want (and have time) to do a virtual interim WG meeting = before Chicago. We=E2=80=99ve picked a date: > =20 > Thursday 17 February, 19:00 UTC, which is: > =20 > 19:00 UTC > 20:00 CEST (Frankfurt, Stockholm) > 14:00 EST (North American Eastern) > 11:00 PST (North American Western) > 06:00 AEDT (Sydney, Melbourne) > =20 > (Webex details will follow) > =20 > As usual, scheduling isn=E2=80=99t perfect for anyone but we tried to = cover the largest possible area of the globe adequately. >=20 > Preliminary agenda for the meeting is: >=20 > 1. Issues from WGLC on the problem statement = (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ = ) > 2. Proposals for moving forward: > * reviews of alt-tld; ready for WGLC? will it = help? (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ = ) > * stop here? (leave RFC 6761 as-is, continue to = process registry changes case-by-case) > * proposals for process revision/update? > 3. Next steps:=20 > * any drafts to write? > * any input or liaison to request from the IAB? = (regarding either namespace architecture or relationships of the IETF = with other groups) > 4. AOB: your I-D or proposed action for the WG/IESG/IAB here > =20 > =20 > thanks, > Suzanne & Tim --Apple-Mail=_5042B31B-5E3E-4CE6-A020-F2469C86A2BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The intent is to conduct the session as much like an ordinary = IETF WG meeting as possible.

So yes, we=E2=80=99ll monitor the jabber room and record the = session.

This also means we=E2=80=99ll need a note-taker, any = volunteers??


Suzanne

On Feb 16, 2017, at 7:40 AM, = Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

Will the jabber room at dnsop@jabber.ietf.org also be = used?
 
Scott
 
From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf = Of Suzanne = Woolf
Sent: Wednesday, February 15, = 2017 6:50 PM
To: dnsop <dnsop@ietf.org>
Subject: [EXTERNAL] [DNSOP] Webex = details Re: correction Re: virtual interim DNSOP WG meeting and current = status, special use names
 
Hi,
 
The secretariat has graciously given us access to a = webex login for the WG, so the setup details for the virtual interim = tomorrow are:
 
        &= nbsp; Meeting = number: 644 850 881
        &= nbsp; Meeting = password: special
 
        &= nbsp; Meeting = link: https://ietf.webex.com/ietf/j.php?MTID=3Dm420b562577eec300c73de= 2e3c9b7d49f
 
        &= nbsp; Audio = connection:
 
        &= nbsp; 1-877-668-4493 = Call-in toll free number (US/Canada)
 
        &= nbsp; 1-650-479-3208 = Call-in toll number (US/Canada)
 
        &= nbsp; Access = code: 644 850 881
 
Agenda:
 
0. Intro/note well/agenda bash (chairs)
 
1. Issues from WGLC on the problem = statement (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps)= (authors)
 
2. Update on alt-tld ((https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/)= (authors)
 
3. Proposals for moving forward:
 
* alt-tld to WGLC?
 
* stop here? (leave RFC 6761 as-is, = continue to process registry changes case-by-case)
 
* proposals for process = revision/update?
 
* any drafts to write?
 
* any input or liaison that DNSOP should = request from the IAB? (regarding either namespace architecture or = relationships of the IETF with other groups)
 
4. AOB: your I-D or proposed action for = the WG/IESG/IAB here
 
On Feb 2, 2017, at = 4:48 PM, Suzanne Woolf <suzworldwide@gmail.com> wrote:
 
And because it=E2=80=99s been that = day=E2=80=A6.
 
Thanks for the off-list nudge, that=E2=80=99s = ***Thursday 16 February*** for most of the world, Friday 17 February for = the AP region.
 
We=E2=80=99ve blocked two hours for the meeting.
 
Apologies for the error.
 
 
Suzanne
 
 
On = Feb 2, 2017, at 3:52 PM, Suzanne Woolf <suzworldwide@gmail.com> = wrote:
3. We still want (and = have time) to do a virtual interim WG meeting before = Chicago. We=E2=80=99ve picked a date:
 
Thursday 17 February, 19:00 UTC, which is:
 
19:00 UTC
20:00 CEST (Frankfurt, Stockholm)
14:00 EST (North American Eastern)
11:00 PST (North American Western)
06:00 AEDT (Sydney, Melbourne)
 
(Webex details will follow)
 
As usual, scheduling isn=E2=80=99t = perfect for anyone but we tried to cover the largest possible area of = the globe adequately.

Preliminary agenda = for the meeting is:

        &= nbsp; 1. Issues = from WGLC on the problem statement (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/= )
        &= nbsp; 2. = Proposals for moving forward:
        &= nbsp;           &nb= sp; * reviews = of alt-tld; ready for WGLC? will it help? (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/)=
        &= nbsp;           &nb= sp; * stop = here? (leave RFC 6761 as-is, continue to process registry changes = case-by-case)
        &= nbsp;           &nb= sp; * proposals = for process revision/update?
        &= nbsp; 3. Next = steps: 
        &= nbsp;           &nb= sp; * any = drafts to write?
        &= nbsp;           &nb= sp; * any input = or liaison to request from the IAB? (regarding either namespace = architecture or relationships of the IETF with other groups)
        &= nbsp; 4. AOB: = your I-D or proposed action for the WG/IESG/IAB here
 
 
thanks,
Suzanne & = Tim

= --Apple-Mail=_5042B31B-5E3E-4CE6-A020-F2469C86A2BE-- From nobody Thu Feb 16 04:54:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9158A129CEF; Thu, 16 Feb 2017 04:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vlj9upmr4EQq; Thu, 16 Feb 2017 04:54:55 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92568129AD5; Thu, 16 Feb 2017 04:54:55 -0800 (PST) Received: from [2001:b98:204:102:fffa::498b] (port=56662 helo=[10.32.60.87]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ceLaH-00019W-8o; Thu, 16 Feb 2017 12:54:53 +0000 From: "John Dickinson" To: dnsop@ietf.org, draft-ietf-dnsop-sutld-ps@ietf.org Date: Thu, 16 Feb 2017 12:54:50 +0000 Message-ID: In-Reply-To: <148587593254.2430.14973732777369498327.idtracker@ietfa.amsl.com> References: <148587593254.2430.14973732777369498327.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_D353B881-2138-4411-81AC-274AE60C34B9_="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.6r5344) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 12:54:57 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_D353B881-2138-4411-81AC-274AE60C34B9_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I originally wrote these notes against the -00 version. -02 is much impro= ved and many of my notes have gone away. However, there are a couple of minor= things I think could be tweaked=E2=80=A6. =C2=A71 "...When reading this document, care must be taken to not assume that the term Domain Name implies the particular protocol for resolving these names, the Domain Name System [RFC1034]. ..." parses badly. Do you mean "...When reading this document, care must be taken to not assume that the term Domain Name implies the use of th= e Domain Name System [RFC1034] for resolving these names. ..."? =C2=A73 Wording of some points after "Organizations do in fact sometimes commandeer subsets of the namespace. Reasons a third party might do this include:" could be improved. e.g. s/Intended use is covered by gTLD process, don't want to pay fee/Intended= use is covered by gTLD process but the third party don't want to pay a fee/ "When a special-use Domain Name is added ..." emphasise that most softwar= e may never get updated. s/Assertion of authority: there is a sense that the namespace/ Assertion of authority: there is a sense that the TLD portion of the name= space/ s/If there is an IETF process through which a name can be assigned at zero cost other than time, this process will be used as an alternative to purchasing the name through ICANN./ If there is an IETF process through which a TLD can be assigned at zero cost other than time, this process will be used as an alternative to more costly approach of getting the TL= DN registered through ICANN./ Additional problem: The availability of special use names may encourage p= rotocol designers to design "bad" protocols. Originally, I kind of felt that the document may flow better if =C2=A74 w= ere before =C2=A73 but since the -01 and -02 changes I am not as bothered as I was. regards John On 31 Jan 2017, at 15:18, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Domain Name System Operations of the I= ETF. > > Title : Special-Use Names Problem Statement > Authors : Ted Lemon > Ralph Droms > Warren Kumari > Filename : draft-ietf-dnsop-sutld-ps-02.txt > Pages : 20 > Date : 2017-01-31 > > Abstract: > The Special-Use Domain Names IANA registry policy defined in RFC 676= 1 > has been shown through experience to present unanticipated > challenges. This memo presents a list, intended to be comprehensive= , > of the problems that have been identified. In addition it reviews > the history of Domain Names and summarizes current IETF publications= > and some publications from other standards organizations relating to= > special-use Domain Names. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-sutld-ps-02 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop John Dickinson http://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robinson Avenue Oxford OX4 4GA U.K. --=_MailMate_D353B881-2138-4411-81AC-274AE60C34B9_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYpaEbAAoJEC3GFEI9J+IsQ8oP/jMjFLw8eKe1C43fpaaVvMee NgUjLCo7qpIAJBpvEYuoezG5die2Rijyhk7qTNy0t0v1QZMV+cpzhxpCeE/T7APV ArfJ8vDSNQoPdIBhuM033G4opSzJGJENxove3Q2vggPvHmtc2aTKcVeDTlRG91OP ESoBIYSRKnW4WBLokTyYtWxv9Woz8CjmrebVVK3SaURMepR6M0EZO7BJI058n9Z+ cz0cVRUNdrzcGYAR36LGvfhefUQE17oBsH3gtHziFeECijs58uY1QAggrPWd6WEp tgqsHSECJCUCM+VRad1f9spvDV4SlU/nQTsNkvwvnaGDwhR3O6QGdrdoAYR3MfhK 721gXMtUDYqAbgCBqCGPiK1CuAohQw772LMjw3dhVgyn6JZyCb8Uls4FxdObNQBP kiOGWN3Nwf7Z0rA/h2pfih/dl8xxsdWs0mYkKxlXky0Msq5yw68CA4/hO3j+zL/8 mICk065JaZPuoI5e0D6V3LX6N12eW1cDZBzR+tFvc9oNoVd2WFRIVoKOwmebd4Co FAtsRfKSACJ/AVTmZwDsugXAcDkOfxlIZYcT3Outtw5a/AacrN50gTrhzDH7P1GL dQZIZt/5LpNJGPgsNI3dkU96vhyKaFiM8Eqvr1JhlfLK/14UT150I6NxBorC//3H mpP+3EPCDIOAHk0sDS68 =3+Od -----END PGP SIGNATURE----- --=_MailMate_D353B881-2138-4411-81AC-274AE60C34B9_=-- From nobody Thu Feb 16 08:18:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A37129D9F for ; Thu, 16 Feb 2017 08:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 OBiOo9vBFE3F for ; Thu, 16 Feb 2017 08:18:50 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F37129D9C for ; Thu, 16 Feb 2017 08:18:50 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 16 Feb 2017 08:18:47 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 16 Feb 2017 08:18:47 -0800 From: Edward Lewis To: dnsop Thread-Topic: Ed's comment s on Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps Thread-Index: AQHSiHBZOUYkQk4EIUKztTlqk8NFCg== Date: Thu, 16 Feb 2017 16:18:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3570088726_1417514986" MIME-Version: 1.0 Archived-At: Subject: [DNSOP] Ed's comment s on Re: WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:18:53 -0000 --B_3570088726_1417514986 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Lines beginning with "#" are from the document. "# ..." means I removed the section as I had no comment on it. # Network Working Group T. Lemon # Internet-Draft Nominum, Inc. # Intended status: Informational R. Droms # Expires: August 3, 2017 # W. Kumari # Google # January 30, 2017 # # # Special-Use Names Problem Statement # draft-ietf-dnsop-sutld-ps-02 # # Abstract # # The Special-Use Domain Names IANA registry policy defined in RFC 6761 # has been shown through experience to present unanticipated # challenges. This memo presents a list, intended to be comprehensive, # of the problems that have been identified. In addition it reviews # the history of Domain Names and summarizes current IETF publications # and some publications from other standards organizations relating to # special-use Domain Names. # # 1. Introduction # # One of the key services required to use the Internet is name # resolution. Name resolution is the process of translating a symbolic # name into some object or set of objects to which the name refers, # most typically one or more IP addresses. These names are often # referred to as Domain Names. When reading this document, care must # be taken to not assume that the term Domain Name implies the # particular protocol for resolving these names, the Domain Name System # [RFC1034]. An excellent presentation on this topic can be found in # Domain Names [I-D.lewis-domain-names]. # # Special-Use Domain Names [RFC6761] created an IANA registry for # special-use Domain Names [SDO-IANA-SUDR], defined policies for adding # to the registry, and made some suggestions about how that policy # might be implemented. Since the publication of RFC 6761, the IETF # has been asked to designate several new special-use Domain Names in # this registry. During the evaluation process for these special-use It would be good to provide a list of requests for new special use names. Especially for a problem statement, this provides a way to estimate the "size and shape" of the problem and the urgency. # Domain Names, the IETF encountered several different sorts of issues. # Because of this, the IETF has decided to investigate the problem and # decide if and how the RFC 6761 process can be improved, or whether it # should be deprecated. # # This document presents a list, believed to be complete, of the # problems associated with the assignment of special-use names. In # support of the particular set of problems described here, the # document also includes documentation of existing practice as it # relates to the use of Domain Names, as well as a brief history of # Domain Names, and finally to describe the set of problems that exist # as reported by various IETF participants with experience in the # various aspects of the problem. # # 2. Terminology # # For the sake of brevity this document uses a number of abbreviations. # These are expanded here: # # Domain Name A name which serves as input to a name resolution # process, for example 'EXAMPLE.ORG'. # # Domain Namespace The set of all possible Domain Names. # # SUDN Special Use Domain Name # # SUTLDN Special-Use Top-Level Domain Name # # IANA Internet Assigned Numbers Authority # # ICANN Internet Corporation for Assigned Names and Numbers # # 3. Problems associated with Special-Use Domain Names # # This section presents a list of problems that have been identified # with respect to the assignment of special-use names. Solutions to # these problems are out of scope for this document. Because of that, # problems with solutions to these problems are also out of scope for # this document, and will be covered in a separate document. # # No assertion is made that any of these problems is more or less # important than any other. The point of this is simply to enumerate # and briefly describe the problems that have been raised during # discussions of the special-use name problem. The degree of detail is # intended to be sufficient that that participants in the discussion # can agree that the problems they've raised have been adequately # described, and no more. These problems should not appear to every # reader to all be problems: we intend to cover any problem that any # participant considers a problem, not just those problems that # everyone agrees are problems. # # In addition, no assertion is made that all of these problems must be # addressed, or that, if we think they should be addressed, the IETF is # the organization with competence to address them. While each problem # has one or more solutions, the solutions may in some cases be # mutually contradictory, or may come with costs that do not justify # the benefit that would be obtained from solving them. # # This is the list of problems: On my second pass, the list is more a list of "complaints heard" rather than any analysis to synthesize a solvable set of "problems." Members of this list are repetitive to some extent and seem to reflect unhappiness with the set up rather than a quantification of the issues (as would a list of pending name requests mentioned earlier). # o There are several different types of names in the root of the # Domain Namespace: # # * Reserved by the IETF for technical purposes # # * Assigned by ICANN to the public DNS root # # * ICANN Reserved Names; names that may not be applied for as a # TLD (see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names ) # # * Commandeered for use by other organizations # # * Not a member of any other category I think the same verb should be used in the first two bullets. By using different terms, one could read an imbalance between the two processes for designating domain name states. The third bullet is redundant with the first two. Commandeered is a subjective term, implying intent to take over something. I would suggest "In use via other means." This bullet also addresses "the root", but the Special Use Domain Name registry is not exclusively filled by top-level domain names. One of the over-hanging issues is how to resolve designations of arbitrary domain names with the special treatment in the root zone, further, to understand what that root zone is. # o Both ICANN and the IETF have the authority and formal processes to # assign names from the pool of unused names, but no formal # coordination process exists. The lack of coordination complicates # the management of the root of the Domain Namespace and may lead to # conflicts in name assignments [SDO-ICANN-SAC090]. I'm not sure that I agree with this as a problem. It's potentially a problem. I mean, ICANN could potentially create a process that could lead to collision with an IETF process but currently there is no such process. (Note: ICANN applicaitons for gTLDs are restricted to windows of time that are an outcome of an extensive policy process. The last window existed in 2012, there are no concrete future windows in a calendar, saying this in light that it is always possible.) # o The term "technical use" in RFC 2860 [RFC2860] is considered by # some to be too inclusive. I'd call it "ill defined". The phrase is begging for testable attributes. # o The IETF and ICANN each have administrative authority over the # Domain Namespace. Not all developers of protocols on the internet # agree that this authority should reside with the IETF and ICANN. If one creates a virtual space, how can they not have administrative authority? If not, the virtual space has no value to anyone. # o Although IETF and ICANN nominally have authority over this # namespace, neither organization can enforce that authority over # any third party who wants to just start using a subset of the # namespace. I don't think that's a properly stated problem, but it does point to something. The problem is that the name space nominally defined and created between IETF and ICANN is susceptible to interference. If another entity decides to use identifiers that are confusingly similar to the Domain Namespace, the existing system is not prepared to "heal itself." # o Organizations do in fact sometimes commandeer subsets of the # namespace. Reasons a third party might do this include: # # * Unaware that a process exists for assigning such names # # * Intended use is covered by gTLD process, but no gTLD process is # ongoing # # * Intended use is covered by gTLD process, don't want to pay fee # # * Intended use is covered by some IETF process, but don't want to # follow process # # * Intended use is covered by ICANN or IETF process, but expected # outcome is refusal or non-action Bullet #2 is impossible...if there is no process ongoing then their is no process "covering". I would combine the first and last bullets - no process is known or the process discourages applicants. I know we are staying away from solutions, but the solution to the two is basically - education/designing an easy process. (Same situation DNS once faced with allocation of Resource Record type codes.) If I buy a relational database from a vendor, am I required to have the same data schemas as everyone else? In parallel to following the DNS documents to implement and run a DNS server, do I need to have the same names in it as the global public Internet? I think not - but the point is that we need to place the discussion appropriately. The Special Use Domain Name registry is not something that alters the DNS protocol, it does have an impact on how the global public Internet operates the shared DNS system. # o There is demand for more than one name resolution protocol for # Domain Names, but Domain Names contain no metadata to indicate # which protocol to use to resolve them. This isn't a problem with special use domain names. It's part of a larger, architectural problem with Domain Names. # o When a special-use Domain Name is added to the special-use Domain # Names registry, not all software that processes such names will # understand the special use of that name. In many cases, name # resolution software will use the Domain Name System for resolution # of names not known to have a special use. Consequently, any such # use will result in queries for special-use names being sent to # Domain Name System authoritative servers. These queries may # constitute an operational problem for operators of root zone # authoritative name servers. "Leaking" isn't a problem for the special use domain name registry, it's a problem for applications that think a special reservation is the solution to that. # o The RFC6761 process is sufficiently uncertain that some protocol # developers have assumed they could not get a name assigned; the # process of assigning the first new name ('.local') using the RFC # 6761 process took more than ten years from beginning to end: # longer by a factor of ten than any other part of the protocol # development process. Other uses of the process have proceeded # more smoothly, but there is a reasonably justified perception that # using this process is likely to be slow and difficult, with an # uncertain outcome. That paragraph is unclear. The protocol development process is often cited as being slow to come to conclusion (e.g., look at the publication of DNSSEC and adoption curves, look at EDNS0). As far as other names reservations, past gTLD "rounds" have taken many years to complete. (See https://www.nanog.org/sites/default/files/nanog63-dnstrack-lewis-newgtlds.pdf, specifically slide 5.) # o There is strong resistance within the IETF to assigning Domain # Names to resolution systems outside of the DNS, for a variety of # reasons: # # * Requires a mechanism for identifying which of a set of # resolution processes is required in order to resolve a # particular name. # # * Assertion of authority: there is a sense that the Domain # Namespace is "owned" by the IETF or by ICANN, and so, if a name # is claimed outside of that process, the person or entity that # claimed that name should suffer some consequence that would, # presumably, deter future circumvention of the official process. We need to clean up the notion of a concept for a name space under Domain Names and the notion that there is an operational Domain Name space. For the latter, under which the Special Use Domain Name registry operates, there is some authority, originally resting with whomever instantiated it. (To make this a bit more concrete, the DNS protocol allows for software to be written that would serve a TLD called "*". I've done this, it works, for some value of works. But, this wouldn't work on the global public Internet version of the Domain Name namespace, if because the value of "works" is different.) # # * More than one name resolution protocol is bad, in the sense # that a single protocol is less complicated to implement and # deploy. This speaks against "permission-less innovation." If by listing this, it is meant that some have perceived this as a problem, it would be helpful to provide references. (A general statement for all of these.) # * The semantics of alternative resolution protocols may differ # from the DNS protocol; DNS has the concept of RRtypes; other # protocols may not support RRtypes, or may support some entirely # different data structuring mechanism. If this is seen as a problem, please provide references. # * If there is an IETF process through which a name can be # assigned at zero cost other than time, this process will be # used as an alternative to purchasing the name through ICANN. I think it is divisive and distracting to refer to "purchasing" or paying a fee as an important hurdle to reserving a name via ICANN. In the spirit of building a cooperative environment, the issue is that there are two (plus) potential sources of processes for reserving names and it would be wise to avoid allowing them to compete. # * A name might be assigned for a particular purpose when a more # general use of the name would be more beneficial. This is an understatement - besides "more general" there are many other considerations when a resource is used for one particular case out of many. # * If the IETF assigns a name that some third party or parties # believes belongs to them in some way, the IETF could become # embroiled in an expensive dispute with those parties. It's best if we stick to technical issues than try to wade into other fields outside the expertise of the group, for the sake of consensus. E.g., expensive dispute" to me implies legal actions - which sometimes are worth the cost. # o If there were no process for assigning names for technical use # through the IETF, there is a concern that protocols that require # such names would not be able to get them. Conflicting with the notion that others are using them outside the process. # o In cases where the IETF has made assignments through the RFC 6761 # process, technical mistakes have been made due either to # misunderstandings as to the actual process that RFC 6761 specifies # (e.g., treating the list of suggested considerations for assigning # a name as a set of requirements all of which must be met), or to a # failure to follow the process that was defined in RFC 6761. An example of this would be appreciated. In the sense that I don't follow. # o In principle, the RFC 6761 process could be used to document the # existence of Domain Names that are not safe to assign, and provide # information on how those names are used in practice. However, # attempts to use RFC6761 to accomplish this # [I-D.chapin-additional-reserved-tlds] have not been successful. # One side effect of this is that any mitigation effect on the root # name servers has been missed. It is not that the process failed, the reasons why it failed are the problems. (I.e., the process fail is a symptom of underlying unresolved issues.) # o There are several Domain Name TLDs that have been commandeered # without due process for a variety of purposes [SDO-ICANN-COLL]. # The status of these names need to be clarified and recorded to # avoid future disputes about their use. [ Ed note: We note that # DNSOP has previously discussed some of these in draft-chapin- # additional-reserved-tlds-02, and decided not to adopt the draft - # https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html # . The authors are not recommending that DNSOP revisit this, # rather that is needs to be addressed in some venue. ] One issue is establishing what is "due process" in the face of "permission-less innovation." # o No mechanism exists for adding a name to the registry without # claiming that the IETF is responsible for that name, nor is it # possible to state a precedence for the name, e.g. "if ICANN # delegates this name, ICANN's delegation takes precedence." Would it be desirable to have rankings? A quote from George Orwell's "Animal Farm" (https://en.wikipedia.org/wiki/Animal_Farm) comes to mind: "All animals are equal but some animals are more equal than others." Apologies - couldn't resist. # o No process exists for checking documents to make sure they don't # accidentally assign names (e.g. RFC 7788). Now - this is good, citing a reference to the use case behind the statement. Please more of this. # o Use of the registry is inconsistent--some SUTLDN RFCs specify # registry entries, some don't; some specify delegation, some don't. # # o There exists no safe, non-process-violating mechanism for ad-hoc # assignment of special-use names. # # o It is generally assumed that protocols that need a special-use # name need a human-readable special-use name. This assumption may # not be warranted in all cases. # # o RFC 6761 uses the term "Domain Name" to describe the thing for # which special uses are registered. This creates a great deal of # confusion because some readers take "Domain Name" to imply the use # of the DNS protocol. # # The problems we have stated here represent the current understanding # of the authors of the document as to the complete set of problems # that have been identified during discussion by the working group on # this topic. The remainder of this document provides additional # context that will be needed for reasoning about these problems. # # 4. Existing Practice Regarding SUDNs # ... # 4.1. Primary SUDN Documents # ... # 4.1.1. IAB Technical Comment on the Unique DNS Root # ... # 4.1.2. Special-Use Domain Names # ... # 4.1.3. MoU Concerning the Technical Work of the IANA # # There exists a Memorandum of Understanding[RFC2860] between the IETF # and ICANN (Internet Corporation for Assigned Names and Numbers) which # discusses how names and numbers will be managed through the IANA # (Internet Assigned Numbers Authority). This document is important to # the discussion of SUDNs because, while it delegates authority for # managing the Domain Name System Namespace generally to ICANN, it # reserves to the IETF the authority that RFC 6761 formalizes: # # Note that (a) assignments of Domain Names for technical uses (such # as Domain Names for inverse DNS lookup), (b) assignments of # specialised address blocks (such as multicast or anycast blocks), # and (c) experimental assignments are not considered to be policy # issues, and shall remain subject to the provisions of this # Section 4. # # The above text is an addendum to the following: # # Two particular assigned spaces present policy issues in addition # to the technical considerations specified by the IETF: the # assignment of Domain Names, and the assignment of IP address # blocks. These policy issues are outside the scope of this MOU. # # In general, then, the assignment of names in the DNS root zone, and # the management of the DNS namespace, is a function that is performed # by ICANN. However, the MoU specifically exempts domain names # assigned for technical use, and uses the example of domains used for # inverse DNS lookup. Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the # special-use Domain Names registry. # # The point here is not to say what the implications of this statement # in the MoU are, but rather to call the reader's attention to the # existence of this statement. This last paragraph seems to contradict the section. If the point is not to interpret the MoU, then citing it is sufficient. Providing an interpretation (as in the preceding paragraph) is a statement on the implications. # 4.2. Secondary documents relating to the SUTLDN question # ... # 4.2.1. Multicast DNS # # Multicast DNS [RFC6762] defines the Multicast DNS protocol, which # uses the '.LOCAL' SUTLDN. Section 3 describes the semantics of # "multicast DNS names." It is of considerable historical importance # to note that the -00 version of this document, an individual # submission, was published in July of 2001. This version contains I don't understand the "considerable historical importance." My personal memory was that the WG wasn't all that excited about this work. When the IESG returned the document to the WG, it took a large effort by the chairs to fix it in face of general apathy (again, my recollection). # substantially the same text in section 3, and was discussed in the # DNSEXT working group at IETF 51 in August of 2001[IETF-PRO-51]. The # first version of this document designated '.LOCAL.ARPA' as the What I recall of that session was the debate over the A6 record. Just to say I don't get the comment above about "considerable historical importance" and to suggest that the authors/editors elaborate more. I'm not saying that there is no importance, I'm saying that whatever it is, it begs more explaining. # special-use name. This idea was strongly opposed by DNSEXT working # group participants, and as a result the author eventually switched to # using '.LOCAL'. # # The history of RFC 6762 is documented in substantial detail in # Appendix H; some notable milestones include the initial proposal to # replace Appletalk's NBP in July 1997, the chartering of the Zeroconf # working group in September 1999, assignment of a multicast address # for link-local name discovery in April of 2000. A companion # requirements document, eventually published as [RFC6760] was first # published in September of 2001. # # The point of mentioning these dates is so that discussions involving # the time when the '.LOCAL' domain was first deployed, and the context # in which it was deployed, may be properly informed. Four years seems like a blink of an eye in IETF terms. Not to discount that, but again, there seems to be a need to explain why this is mentioned. # 4.2.2. The .onion Special-Use TLD # # The .onion Special Use TLD [RFC7686] is important because it is the # most recent IETF action on the topic of SUTLDNs; although it does not # set new policy, the mere fact of its publication is worth thinking # about. # # Two important points to consider about this document are that: # # o The IETF gained consensus to publish it # # o The situation was somewhat forced, both by the fact of its # unilateral use by the TOR project without following the RFC 6761 # process, and because a deadline had been set by the CA/Browser # Forum [SDO-CABF-INT] after which all .onion PKI certificates would # expire and no new certificates would be issued, unless the .onion # SUTLDN were to be recognized by the IETF. This sounds like consensus was more of a "shotgun wedding." (https://en.wikipedia.org/wiki/Shotgun_wedding) Speaking as someone who never understood "the consensus" but is willing to live with it. (I certainly asked questions that went unanswered.) This is what spurred me to write the Domain Names draft (note: draft), even digging through documents for that found it hard to find a documented background on the Tor project in sufficient detail to answer my questions on how the DNS was impacted. # 4.2.3. Locally Served DNS Zones # ... # 4.2.4. Name Collision in the DNS # ... # 4.2.5. SSAC Advisory on the Stability of the Domain Namespace # # This document reports on some issues surrounding the conflicting # uses, interested parties and processes related to the Domain # Namespace. The document recommends the development of collaborative # processes among the various interested parties to coordinate their # activities related to the Domain Namespace. A reference to the document would be good. # 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis # # Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis # [RFC7050] is an example of a document that successfully used the RFC # 6761 process to designate '.ipv4only.arpa' as a special-use name; in # this case the process worked smoothly and without controversy. # # Unfortunately, while the IETF process worked smoothly, in the sense # that there was little controversy or delay in approving the new use, # it did not work correctly: the name 'ipv4only.arpa' was never added # to the special-use Domain Names registry. This appears to have # happened because the IAB was able to simply add the name to the .ARPA # zone, which the IAB administers. This is an illustration of one of # the problems that we have with the 6761 process: it is apparently # fairly easy to miss the step of adding the name to the registry. s/the registry/the appropriate registry/ # 4.2.7. Additional Reserved Top Level Domains # # Additional Reserved Top Level Domains # [I-D.chapin-additional-reserved-tlds] is an example of a document # that attempted to reserve several TLDs identified by ICANN as # particularly at risk for collision as special-use Domain Names with # no documented use. This attempt failed. # # Although this document failed to gain consensus to publish, the need # it was intended to fill still exists. Unfortunately, although a fair # amount is known about the use of these names, no document exists that # documents how they are used, and why it would be a problem to # delegate them. Additionally, to the extent that the uses being made # of these names are valid, no document exists indicating when it might # make sense to use them, and when it would not make sense to use them. # # RFC 7788 [RFC7788] defines the Domain Name TLD ".home" for use as the # default name for name resolution relative to a home network context. # Although, as defined in RFC 7788, ".home" is a special-use Domain # Name, RFC 7788 did not follow the process in RFC 6761 and request the # addition of ".home" to the IANA Special-Use Domain Name registry. # Additionally, ".home" is an example of an attempt to reuse a Domain # Name that has already been commandeered for other purposes # [SDO-ICANN-COLL], which further complicates the situation. At the # time this document was written, the IETF was developing a solution to # this problem. That description doesn't mention the errata filed to remove .home from the document. --B_3570088726_1417514986 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU7G89HG4gLOC1ayhM Qrc15FF5ryswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw MjE2MTYxODQ2WjANBgkqhkiG9w0BAQEFAASCAQAwbNlG4CTOReQbNyPKHP8+JU/UAWdQ3jn4 i6VaYUR6NDWuqrnkcvXNTuiDDmRwO21UW7NL2835/qpGIrMO6vhhMoN1/gEDhUuUS8Tj4KQ0 YFx3UCO7e/OuaahkgSxTDB5atUUEhZ5scRf7DRoWyUuvf49X6+6QIvPjlEeTV5Xvc38g7ZU7 Rh1Rjgwi4WgZRk65MsL7M0z7zem4rMDQn3yb1YUpx99SRmXqfiIwsPNZDUFjrJxAHaBcSeyt Gh3Xbl4Sbz8kq+PyQHL3gp29Q69sD14xfKAFqnVK73u71i3pgvYSlUoZQZ3ZR0aLJubjXzE7 JmY3cKh3lDMpqfkOyR8C --B_3570088726_1417514986-- From nobody Thu Feb 16 08:25:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255DF129DA3 for ; Thu, 16 Feb 2017 08:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 IuLve-fMRUpk for ; Thu, 16 Feb 2017 08:25:21 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FD3129D8A for ; Thu, 16 Feb 2017 08:25:21 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 0CEB03212F; Thu, 16 Feb 2017 08:25:20 -0800 (PST) From: Wes Hardaker To: Petr =?utf-8?B?xaBwYcSNZWs=?= References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> <20170206131153.52329a04@pallas.home.time-travellers.org> <7dd02b3e-910b-b287-14cf-d7fe7755cd2d@nic.cz> Date: Thu, 16 Feb 2017 08:25:19 -0800 In-Reply-To: <7dd02b3e-910b-b287-14cf-d7fe7755cd2d@nic.cz> ("Petr =?utf-8?B?xaBwYcSNZWsiJ3M=?= message of "Mon, 6 Feb 2017 17:04:38 +0100") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:25:23 -0000 Petr =C5=A0pa=C4=8Dek writes: > Shane was faster than me, I'm also wondering how 3/2 got here. Yep. And had we been smarter and written it down when we first wrote it, there wouldn't be this question. Sadly, we had a reason and now Warren and I have to remember it. We spent a long time wandering around random streets on Berlin and the 3/2 was a sudden aha (oh no) moment if I recall. Anyway, we'll revamp the document again in the near future with the terms better spelled out, because I agree they need to be. --=20 Wes Hardaker USC/ISI From nobody Thu Feb 16 08:34:01 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96D9129DB6 for ; Thu, 16 Feb 2017 08:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 IXIWUDEQHOxC for ; Thu, 16 Feb 2017 08:34:00 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8115129DB3 for ; Thu, 16 Feb 2017 08:33:59 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 71E003212F; Thu, 16 Feb 2017 08:33:59 -0800 (PST) From: Wes Hardaker To: Bob Harold References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 08:33:59 -0800 In-Reply-To: (Bob Harold's message of "Mon, 6 Feb 2017 09:17:45 -0500") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dnsop Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:34:01 -0000 Bob Harold writes: > Thanks for your work on this.=C2=A0 Some minor formatting issues: Odd. I think *someone* wasn't using a real editor (*cough*emacs*cough*) and it inserted some odd white space into XML components. Thanks for the catches; fixed on all accounts. --=20 Wes Hardaker USC/ISI From nobody Thu Feb 16 08:46:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE395129695 for ; Thu, 16 Feb 2017 08:46:36 -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, HTML_MESSAGE=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 jT6H4-IZdSpw for ; Thu, 16 Feb 2017 08:46:35 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B601270B4 for ; Thu, 16 Feb 2017 08:46:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2D023300435 for ; Thu, 16 Feb 2017 11:46:35 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6hyPfIuY3pHi for ; Thu, 16 Feb 2017 11:46:34 -0500 (EST) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 00254300254; Thu, 16 Feb 2017 11:46:33 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_98C3E2EF-CA66-40DB-8E22-D1DBB93A223B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 16 Feb 2017 11:46:32 -0500 In-Reply-To: To: Edward Lewis References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Ed's comment s on Re: WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:46:37 -0000 --Apple-Mail=_98C3E2EF-CA66-40DB-8E22-D1DBB93A223B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ed: > # Special-Use Domain Names [RFC6761] created an IANA registry for > # special-use Domain Names [SDO-IANA-SUDR], defined policies for = adding > # to the registry, and made some suggestions about how that policy > # might be implemented. Since the publication of RFC 6761, the = IETF > # has been asked to designate several new special-use Domain Names = in > # this registry. During the evaluation process for these = special-use >=20 > It would be good to provide a list of requests for new special use = names. > Especially for a problem statement, this provides a way to estimate = the=20 > "size and shape" of the problem and the urgency. No matter how you count, the volume will remain small if this is done = properly. However, the special name requests can still be important and = urgent. Russ --Apple-Mail=_98C3E2EF-CA66-40DB-8E22-D1DBB93A223B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ed:

#    Special-Use Domain Names = [RFC6761] created an IANA registry for
#    special-use Domain Names = [SDO-IANA-SUDR], defined policies for adding
# =    to the registry, and made some suggestions about how = that policy
#    might be implemented. =  Since the publication of RFC 6761, the IETF
# =    has been asked to designate several new special-use = Domain Names in
#    this registry.  During = the evaluation process for these special-use

It would be good to provide a list of = requests for new special use names.
Especially for a problem statement, this = provides a way to estimate the 
"size and shape" of = the problem and the urgency.

No matter how you count, the volume = will remain small if this is done properly.  However, the special = name requests can still be important and urgent.

Russ

= --Apple-Mail=_98C3E2EF-CA66-40DB-8E22-D1DBB93A223B-- From nobody Thu Feb 16 09:23:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E90129675 for ; Thu, 16 Feb 2017 09:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spYdof7IjAFP for ; Thu, 16 Feb 2017 09:23:33 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 3E5BF129564 for ; Thu, 16 Feb 2017 09:23:33 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id p22so22081495qka.0 for ; Thu, 16 Feb 2017 09:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=KAvZ94CoOtviTUg+DGNlN99+dmYXtP+Kb6boEvPi6Ek=; b=UA4uNubPsl6bRA7i/YQdRxI1V2d1hFkb4YelnKvBqviB1+lpQiOFi0yhVdKezERSgF 1yWQ7rkpkivYfeUPswmQy9ZJNsk29oAeRJQAGsUwdMD+sfF6A78rylHzdiWMAHmoSyje vszwzEJ9CHOV5CUUvaUNia6UmqHpsTr7eS96XgUZrSdanje9AVpIhEMbtkvGh1ANoMkV xTmGUU1e8PP+2puZ/xvPhnp+CBsQzvDQwPDy7T0EytRZsnyaQvnHzHZ8Fdi454lYrvsN mnmdoHskGEXfvtMqmsCtKQcf+jDGtm1aCeXeuCevvQAhkfW+Kf8zvFhxHxlwsMamtQwx KGSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KAvZ94CoOtviTUg+DGNlN99+dmYXtP+Kb6boEvPi6Ek=; b=q36g4dkKGcfvyv5rD1TtngpGLTxdJoPkjTE7FvFPGD3aHmUuYeN/cvPiJTuQiZG+PY tWA6VTIFEp1YJZiVHMqSJLBOBYmyALYOJVZiMFxFR2Mw8Vdn8go8Cr1Wi9VLdhTPJmw0 2c9guayfnCH2gUOKEfrYNYWXD3gU7VUJDdOeMXtYzKDkzZUvcmY8yTUGZnF+bEq4MYVq asNpwLmSZ5tbTpwucSuOUK/MtJ2hsuEGS1HjmlH2XuOx//rC+bWRzK6zJ4SlMktC9qdv 1ANU+qdwCuXwL960HOgMhLO3vKLNl9lleruQwxmi5gOpF3hNKLeYferz6fpZ2bLkUMqT vl4w== X-Gm-Message-State: AMke39kc2/to/LX8UWY24s8tzo2Ox2gZEnU9iOrv/4J80Ho9wkYAXE2RSbn8+6SRI6IpyQ== X-Received: by 10.55.167.136 with SMTP id q130mr1665145qke.274.1487265812244; Thu, 16 Feb 2017 09:23:32 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:89dd:b6a4:11d3:2d85? ([2601:181:c381:c20:89dd:b6a4:11d3:2d85]) by smtp.gmail.com with ESMTPSA id c141sm4800017qkb.10.2017.02.16.09.23.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 09:23:31 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_77AD4484-117C-4A17-9CE7-0E36B2C8C38B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: Date: Thu, 16 Feb 2017 12:23:29 -0500 Message-Id: <9F197C8D-77F6-430F-8D71-B338BFB998EB@gmail.com> References: To: Russ Housley X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Edward Lewis , dnsop Subject: Re: [DNSOP] Ed's comment s on Re: WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:23:35 -0000 --Apple-Mail=_77AD4484-117C-4A17-9CE7-0E36B2C8C38B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 16, 2017, at 11:46 AM, Russ Housley = wrote: >=20 > Ed: >=20 >> # Special-Use Domain Names [RFC6761] created an IANA registry for >> # special-use Domain Names [SDO-IANA-SUDR], defined policies for = adding >> # to the registry, and made some suggestions about how that policy >> # might be implemented. Since the publication of RFC 6761, the = IETF >> # has been asked to designate several new special-use Domain Names = in >> # this registry. During the evaluation process for these = special-use >>=20 >> It would be good to provide a list of requests for new special use = names. >> Especially for a problem statement, this provides a way to estimate = the=20 >> "size and shape" of the problem and the urgency. >=20 > No matter how you count, the volume will remain small if this is done = properly. However, the special name requests can still be important and = urgent. I also note it=E2=80=99s fairly difficult to estimate.=20 At one point DNSOP had been asked to consider several drafts asking for = various things (and some asking for more than one name). We didn=E2=80=99t= adopt the .home/.corp/.mail draft. The .onion request went to the IESG = and eventual acceptance. We adopted the .alt draft because it claimed to = solve a significant chunk of the problem, and then parked it pending = agreement on what problem we actually have. The HOMENET WG currently has = a draft requesting .homenet as both a special use name and a root zone = entry. All of the drafts besides those for .onion, .alt, and .homenet have = expired, which tells us nothing about whether or how they might come = back. There=E2=80=99s also limited empirical data about what names = people are simply appropriating for uses outside of the global public = DNS, or how widely used they might be; leaked traffic to large recursors = and the root servers is probably a proxy for some of it but how much we = don=E2=80=99t know. Suzanne --Apple-Mail=_77AD4484-117C-4A17-9CE7-0E36B2C8C38B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 16, 2017, at 11:46 AM, Russ Housley <housley@vigilsec.com> wrote:

Ed:

#    Special-Use Domain Names [RFC6761] = created an IANA registry for
#    special-use Domain Names = [SDO-IANA-SUDR], defined policies for adding
# =    to the registry, and made some suggestions about how = that policy
#    might be implemented. =  Since the publication of RFC 6761, the IETF
# =    has been asked to designate several new special-use = Domain Names in
#    this registry.  During = the evaluation process for these special-use

It would be good to provide a list of = requests for new special use names.
Especially for a problem statement, this = provides a way to estimate the 
"size and shape" of = the problem and the urgency.

No matter how you count, the volume = will remain small if this is done properly.  However, the special = name requests can still be important and = urgent.

I also = note it=E2=80=99s fairly difficult to estimate. 

At one point DNSOP had been asked to consider = several drafts asking for various things (and some asking for more than = one name). We didn=E2=80=99t adopt the .home/.corp/.mail draft. The = .onion request went to the IESG and eventual acceptance. We adopted the = .alt draft because it claimed to solve a significant chunk of the = problem, and then parked it pending agreement on what problem we = actually have. The HOMENET WG currently has a draft requesting .homenet = as both a special use name and a root zone entry.

All of the drafts besides those for .onion, .alt, = and .homenet have expired, which tells us nothing about whether or how = they might come back. There=E2=80=99s also limited empirical data about = what names people are simply appropriating for uses outside of the = global public DNS, or how widely used they might be; leaked traffic to = large recursors and the root servers is probably a proxy for some of it = but how much we don=E2=80=99t know.


Suzanne

= --Apple-Mail=_77AD4484-117C-4A17-9CE7-0E36B2C8C38B-- From nobody Thu Feb 16 09:29:18 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339B512946A for ; Thu, 16 Feb 2017 09:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 qSDIkQR69usx for ; Thu, 16 Feb 2017 09:29:16 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CABD129453 for ; Thu, 16 Feb 2017 09:29:16 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 19D7726305; Thu, 16 Feb 2017 09:29:16 -0800 (PST) From: Wes Hardaker To: Wes Hardaker References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> <20170206131153.52329a04@pallas.home.time-travellers.org> <7dd02b3e-910b-b287-14cf-d7fe7755cd2d@nic.cz> Date: Thu, 16 Feb 2017 09:29:15 -0800 In-Reply-To: (Wes Hardaker's message of "Thu, 16 Feb 2017 08:25:19 -0800") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: dnsop@ietf.org, Petr =?utf-8?B?xaBwYcSNZWs=?= Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:29:17 -0000 Wes Hardaker writes: > Sadly, we had a reason and now Warren and I have to remember it. Fortunately, after a quick conversation we've recovered the reason. Publishing a new version with a break-out explanation shortly. The 3/2 is absolutely is needed. -- Wes Hardaker USC/ISI From nobody Thu Feb 16 09:43:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF19B129535 for ; Thu, 16 Feb 2017 09:43:53 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tpny7NHwwbgh for ; Thu, 16 Feb 2017 09:43:51 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 3B9A6126CD8 for ; Thu, 16 Feb 2017 09:43:51 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id x49so20647401qtc.2 for ; Thu, 16 Feb 2017 09:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xssL/0q3YJxgUD93+n4NjMoqTIUSJzGr9dEi7ac/VZA=; b=VcXMkfzJrIlrL9I44H186UTANMS8BrPiYqUzSOrVBdH1wtv0aOWQmDOkA4BbBx4yRe kKbZSQI7b+yg8lkBzDLsYj+0VQygZ7Lh8i74WdgeA5FmHyfP426Mqg8mx9S2ny3lHmsD VvTn2cMFZFwt2jN7zd8JgV0oOFMLKw+ihPLbnLhxFAeHjwAxg552U8lIgDmbwiJVm5+U +s/IBieNCBOyqkAB+zTQrSRWKTxrilAJiqTDJHlTJKrJmAYvDUzjNYSGrJWhR3+FNKSq VBaEM03LL6cJc4Re62LgaYMU+stbPo/oy5gXZfXWMXOeHMJpozSab2id98+SLveDJVt0 uN/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xssL/0q3YJxgUD93+n4NjMoqTIUSJzGr9dEi7ac/VZA=; b=S50jWHnySIq+aafIxsYWlFXIh9h6y2U9ogejZCFa+WsefhZPbAZFplN8cRpMnU79y7 OKKnLTWAlXfeH8gOEAktnSH6tHn2F9qy8EUcc1Z/Lt2zaWyoSn1ArPo+50OATYpRa+KV DyLeNiLv/HZgG6sSZ+Z+4ordzwbDL6YXn07kCAiBBmSHvMrBSd/cy4dYO9bVQGOhUqp9 Z142oMrEINOOWay5fgdpP/X55Y0akkPVUg7FVP4fYaLFy8kBOhr326S9TvvLmA7r+e5o hn3nfiP69qPOdc5rNgPMHQDcDfBNgbHFKb1KgycZ2C+2bmRCFAVKi+07CrhDEyMO5d1s 7WGQ== X-Gm-Message-State: AMke39lJK18fMlr4VgXF5NSnxi6QhRwDhwNRHzSVwxbcXPXqNec8a1xUryGL6/aXzzyzpYroVCETmIWGQ8DMJv/3 X-Received: by 10.237.34.116 with SMTP id o49mr3245917qtc.122.1487267030026; Thu, 16 Feb 2017 09:43:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Thu, 16 Feb 2017 09:43:19 -0800 (PST) In-Reply-To: References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Thu, 16 Feb 2017 12:43:19 -0500 Message-ID: To: Wes Hardaker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Bob Harold , dnsop Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:43:54 -0000 On Thu, Feb 16, 2017 at 11:33 AM, Wes Hardaker wrote: > Bob Harold writes: > >> Thanks for your work on this. Some minor formatting issues: > > Odd. I think *someone* wasn't using a real editor (*cough*emacs*cough*) > and it inserted some odd white space into XML components. ... and it seems that that someone was Wes :-P W > > Thanks for the catches; fixed on all accounts. > -- > Wes Hardaker > USC/ISI -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Feb 16 09:47:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7A7129535 for ; Thu, 16 Feb 2017 09:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 LgNqXmd6fbCs for ; Thu, 16 Feb 2017 09:47:52 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44251294F1 for ; Thu, 16 Feb 2017 09:47:51 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 16 Feb 2017 09:47:49 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 16 Feb 2017 09:47:49 -0800 From: Edward Lewis To: dnsop Thread-Topic: [Ext] Re: [DNSOP] Ed's comment s on Re: WGLC for draft-ietf-dnsop-sutld-ps Thread-Index: AQHSiHRBXdLVQC0lkkyHYZOxQSwNAKFsZ/qA//+y+gA= Date: Thu, 16 Feb 2017 17:47:48 +0000 Message-ID: <399731CA-227F-4FC3-B009-4D1861C2BC3F@icann.org> References: <9F197C8D-77F6-430F-8D71-B338BFB998EB@gmail.com> In-Reply-To: <9F197C8D-77F6-430F-8D71-B338BFB998EB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3570094068_2001056001" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Ed's comment s on Re: WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:47:53 -0000 --B_3570094068_2001056001 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 2/16/17, 12:23, "Suzanne Woolf" wrote: On Feb 16, 2017, at 11:46 AM, Russ Housley wrote: Ed:=20 >>>It would be good to provide a list of requests for new special use names= . >>>Especially for a problem statement, this provides a way to estimate the=C2= =A0 >>>"size and shape" of the problem and the urgency. (Russ:) >>No matter how you count, the volume will remain small if this is done=20 >>properly. =C2=A0However, the special name requests can still be=20 >>important and urgent. (Suzanne:) >I also note it=E2=80=99s fairly difficult to estimate.=C2=A0 > >... .home/.corp/.mail ... .onion ... .alt ... .homenet=20 There is also a use of .id by Blockstack? as opposed to the ccTLD for Indon= esia. (This one just jumps to mind.) I did some looking and despite thinking there was once a backlog of a dozen= , I haven't come across it in the mailing list. (I could be wrong.) What a= bout .belkin, often cited as a string seen but not allocated? My goal is to see the problem statement document get more detailed so we ca= n know when we've solved the problem. ("The problem" is meant to be general= , not necessarily the problem at hand.) >All of the drafts besides those for .onion, .alt, and .homenet have expire= d, which tells us nothing about whether or how they might come back. I don't think liveness of drafts is a sufficient measure of activity, consi= dering the problem statement talks about uses from folks not engaging in the= IETF process. (If I'm hungry and in line at a restaurant, then walk away b= ecause the wait is too long, I'm still hungry.) --B_3570094068_2001056001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUCHtb6ZLrKMSL4twd or3nxK7tIsEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw MjE2MTc0NzQ4WjANBgkqhkiG9w0BAQEFAASCAQAVoNSykVEA+zuxoKhIYBrOEKMaYB3hjNoT End2uhW5UN4XzjHtetSoJXbjRkdCqzlgyON3k2QmsNl4JFJkhYfHdeZvhkU5PU+ThKMjRDBY uK4gTfUgXaABV+e8n8FVxODsXDikr+fGEf4fTtgW/LiPrA1HQeqzYP5oS80mfWHVd258jpmV 8S5T/KB4EfIvCTFy/ExOVuSGx+5gLYn9gF0FCHWegGFgaiUwQjt63ZyU4tE4oNHvv0O2zmeK 56Gd+APnRAY97by+1IqDHVjCHH47M3Ev9yp9r1zEreHfrDDqL8UN/NL9qDW5FzcnVt1vYQtQ 5JdSL95PLrMt9fWU6Wba --B_3570094068_2001056001-- From nobody Thu Feb 16 10:29:43 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351681293DC for ; Thu, 16 Feb 2017 10:29:42 -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, RP_MATCHES_RCVD=-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 P52NRShH0LOb for ; Thu, 16 Feb 2017 10:29:41 -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 48FFE129406 for ; Thu, 16 Feb 2017 10:22:17 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 3EB02242125A; Thu, 16 Feb 2017 18:21:57 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_945F498E-769E-432A-A869-DCCFE326C46E"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Jim Reid In-Reply-To: <399731CA-227F-4FC3-B009-4D1861C2BC3F@icann.org> Date: Thu, 16 Feb 2017 18:21:56 +0000 Message-Id: <91AE52F4-A179-4469-A4E3-7E90265702AD@rfc1035.com> References: <9F197C8D-77F6-430F-8D71-B338BFB998EB@gmail.com> <399731CA-227F-4FC3-B009-4D1861C2BC3F@icann.org> To: Ed Lewis X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF DNSOP WG Subject: [DNSOP] .belkin as a special use name X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:29:42 -0000 --Apple-Mail=_945F498E-769E-432A-A869-DCCFE326C46E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Feb 2017, at 17:47, Edward Lewis wrote: >=20 > What about .belkin, often cited as a string seen but not allocated? It was so prominent in one year=E2=80=99s root server DITL data (in the = top 20 TLDs that were queried?) that it was mentioned in the 2013 = Interisle Name Collision report I helped to produce. IIRC it didn=E2=80=99= t show up much in the other year of DITL data that got crunched for that = report. Or the previous years of DITL data that were analysed after that = report had been published. It=E2=80=99ll just be a simple matter of progamming and a few CPU-months = to run through the datasets at DNS-OARC and get the top N TLD strings = for in the root server DITL data since 2006. I=E2=80=99m not sure this = would be much help to the WG=E2=80=99s consideration of what to do about = special use labels though. That data might be useful for anyone who has = the urge to compile yet another list of these = heavily-used-but-not-properly-registered* labels/TLDs. I=E2=80=99d be willing to gather that information if someone can make a = convincing case for doing that. *for some definition of these 6 words. --Apple-Mail=_945F498E-769E-432A-A869-DCCFE326C46E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJYpe3EAAoJEP9ZkLtFeehfek8H/AhYKmYiFl8vt0RHKAxUja62 hUeLE2fbJjZG0t4fJ+6QKnF0hR/WI/1AnLxX6IyhLDNH0Tg+391+cnC9q3DnpE+j HyspcY7CxEbpDPgpI+cAXkz2mm20HKf7n6mcPVKagQfjzXwcmrC/IeYxpKNs+23v Jf6eHr29VfaWSUZ09NMckPdFK//5BJGOukB6tRHGTsJjFSknhkEYZLHoOZLyiCN8 YmJQYPnkT09wpaHfVFKjI1Y2AJeQPLTJDfuN0Z747/ZahbfV0iDmdo6w611K/yRO gQIRCLLk+p4p1GjTaiROUuEllbVNAbC9E/xO23ChceaSI46Y9tzubAqFyofPlhI= =kaZ9 -----END PGP SIGNATURE----- --Apple-Mail=_945F498E-769E-432A-A869-DCCFE326C46E-- From nobody Thu Feb 16 13:44:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2812967D; Thu, 16 Feb 2017 13:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 uuMvmYzlOubl; Thu, 16 Feb 2017 13:44:31 -0800 (PST) Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5EA1296CC; Thu, 16 Feb 2017 13:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2939; q=dns/txt; s=VRSN; t=1487281469; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=iD8XtltvCKFzz7+mtSxK3eZqicGSsIwmWIvK4nR7En0=; b=WStVV4hRoh1ybuDFeuKuDFqFz+oO5snK59pcrp3qdzWktfbtG/JRHYKr 4y0mmE28D56H/P8dYDJeEzXZi+LCwV83w68XQ3vE0F39dDafXfjM8Z2xE ozh5PfnrRulxYZ0mFIlfDD5CWJTSfBO0iiOJuCq4z7CtgTiwxE0M/VO+v bah//LLqU7b/VzQUWi5VbSdPYCS0zZRy3VEp8jj8QmFSbcebnU/nWNR37 c2CmOsRM3Iu8T+AIM0rTqeXfqCRgMuWK+cboWWedma2upduX5gaoFpNEN Cta2wpy/EmJEz+H9E8+H2UhYbY3PA0n3byofUFNV+FAcgYBZ4yFYHQO+L g==; X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208";a="1698221" IronPort-PHdr: =?us-ascii?q?9a23=3A8H1skRVlkjAlHI/YWzeqCuGw1lXV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYZRWOvqdThVPEFb/W9+hDw7KP9fuxBCpYvd3Y7ShKWacPfidNsd?= =?us-ascii?q?8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3wOgVv?= =?us-ascii?q?O+v6BJPZgdip2OCu4Z3TZBhDiCagbb9oIhi7qQXcutMKjYZtJao91xvErmdVcO?= =?us-ascii?q?lK2G1kIk6ekQzh7cmq5p5j9CpQu/Ml98FeVKjxYro1Q79FAjk4Km45/MLkuwXN?= =?us-ascii?q?QguJ/XscT34ZkgFUDAjf7RH1RYn+vy3nvedgwiaaPMn2TbcpWTS+6qpgVRHlhD?= =?us-ascii?q?sbOzM/7WrakdJ7gr5Frx29phx/24/Ub5+TNPpiZaPWYNcWSXNcUspNSyBNB4Wx?= =?us-ascii?q?ZJYNAeUcJ+ZVt4nzqUUToxuiCweiB+3vxT1JhnDq0qM13P8sER3f3AwlA94CrG?= =?us-ascii?q?jYoMvzOawPUe611q7IzTDbYv9Y2Tjy9pPIcgs/rvGIRrJ8adfax0cyFwzfiFWf?= =?us-ascii?q?t4LpNC6S2+sQvWmU8fFgVfmxhG4jsAF8uSavydk2ionInYIVy1/E9SNjzIkpIt?= =?us-ascii?q?24TVd2bNi5G5VesCGaMpF5QsIkQ2xwpik7xacJuZujfCgO1psr3QLQa/uCc4WO?= =?us-ascii?q?/xntV/6RLC9liH55Yr6zmhS//Ea6xuHhVsS53kxGojRKn9TDrnwBygDf5tKaRv?= =?us-ascii?q?Z/8EqtwyuD2gDN5u1eLk05k7fQJYQ7zb4qjJUTtFzOHirxmErrkqCbbl4k+u20?= =?us-ascii?q?6+T/ZbXmu4OcO5d0ig7gNqQundSyDv8iMggIQmSb/eu91Lj58k34RLVKieA2kr?= =?us-ascii?q?XFvJzHP8gbuLC2AxVU0oY46ha/ADGm3M4EknkAKVJJYBOHj473NFHSOP30EOuz?= =?us-ascii?q?j06xnDppyf3KJKDtD5XDI3TZjrvscrlw51ZZyAUpzNBf45xUCqsGIPL2QkL+qd?= =?us-ascii?q?LZAQEiMwyv3ennDM5925gAWW2RGK+ZMbjSsV6H5uIpOeWDeIgVuDPlJ/g/+/Hu?= =?us-ascii?q?lWM5mUMafaSxwJQXbmu4HvN+I0iCYHrjnMsBEWkQsgo5Vuzqh0WIUSRPaHaqQ6?= =?us-ascii?q?I8+jY7BZq7AofFXYCth6SB0D6nEZ1WfG9GC0qMEWzzeoWFRfgMdCySLtVmkjwe?= =?us-ascii?q?WrirU5Uh2g22tA/m17pnKfLZ+jEatZPtztR15vPclQ089TFvAMSd1nuCT2Bwnm?= =?us-ascii?q?8SWzA226V/q1Rnylifyah4n+BYFdtL6vxUSAc1L5Dcz/BjB9DzRA3BYtmJRE+7?= =?us-ascii?q?TdWgGjExScoxz8YQbElgHdWilQnP3ym0DL4VjrCLGIY78q3H0njwOcl913jG2L?= =?us-ascii?q?Mmj1k8TctFLXemibJn9wjPG47JlF2Ul6e0eqQH0y7A72aDwnSSvEFWSgJwVr/F?= =?us-ascii?q?XX8HbEvMsdv5/l/CT6OpCbk/KQtB1dCNKrNKatL3i1VKXvnjN87EY2KrhWiwAR?= =?us-ascii?q?KIy6iQY4rxYWkdwDnSB1UenwAS43nVfTQ5Uxy9rnreATomO1v1eU7o9aEqs2+2?= =?us-ascii?q?Vk85yUeEZld72r6x0hUOw+CXR7US0+RXlj0mrmA+I1umxN/SEJ7IixdoeqgWKY?= =?us-ascii?q?cx/1pczm/drCRjM4ahNKFtgBgVdAEh7BCm7Al+FogVyZtil3gt1gcnbPvAiF4?= =?us-ascii?q?=3D?= X-IPAS-Result: =?us-ascii?q?A2EEBABOHKZY//SZrQpeGwEBAQMBAQEJAQEBFgEBAQMBAQE?= =?us-ascii?q?JAQEBhAeBCQezDYIPggwaCIYAAoJRFgEBAQEBAQEBAQEBAoEHgjMiAQw9PAEBA?= =?us-ascii?q?QEBASMCOjEGOg8wEAIBCA0pEDIlAgQOvHmLVgEBAQEBAQEDAQEBAQEBASGGTYI?= =?us-ascii?q?EgmqEMQ0WgzSCMQWGX4IvhjiGAYYyBgGGb4ZEhzGJKoUOkxgmB4ErURVOAYQ0H?= =?us-ascii?q?RmBSHWHe4EvgQ0BAQE?= Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v1GLhNrf028536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 16:43:23 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Thu, 16 Feb 2017 16:43:22 -0500 From: "Wessels, Duane" To: Stephen Farrell Thread-Topic: [EXTERNAL] Stephen Farrell's Yes on draft-ietf-dnsop-edns-key-tag-04: (with COMMENT) Thread-Index: AQHSh/pzzwVmJ8Hh3kaBwg2aK5veVKFsfz+A Date: Thu, 16 Feb 2017 21:43:22 +0000 Message-ID: <30D3A4E8-D55D-4D5E-AB3F-28D3B0C4EF99@verisign.com> References: <148721128491.31391.12912602191917167130.idtracker@ietfa.amsl.com> In-Reply-To: <148721128491.31391.12912602191917167130.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <365DC6DAA86C0E40B021D62A2ADE4E46@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Tim Wicinski , "draft-ietf-dnsop-edns-key-tag@ietf.org" , "dnsop@ietf.org" , "dnsop-chairs@ietf.org" , The IESG Subject: Re: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-edns-key-tag-04: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:44:32 -0000 Hi Stephen, >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - abstract: referring to section 1.1 from here seems wrong, > the abstract ought be readable by itself Agreed. I propose to remove that sentence and let the abstract stand on its= own. >=20 > - section 5: Is the key tag query only and solely intended to > allow the authoritative to track how clients are paying > attention (or not) to key rollovers? If there's another > purpose I'm not clear about it. Yes, that is the sole purpose. Do you think this needs to be made more exp= licit? >=20 > - 5.3: "I believe that to be..." seems like the wrong language > to use with >1 author. Yes. This sentence was already removed from the authors' shared source fil= e shortly after -04 was sent out. >=20 > - section 7/8: Is there a missing security/privacy > consideration here, in that an authoritative server here could > arrange to hand out key tags that are specific to (in the > limit) each query, so that when the resolver queries a > sub-domain, and thereafter, the client will be identifiable to > the authoritative server? One could do this by generating new > keys per querier so that if I ask about example.com I get > given a tag that's unique to me, and then some web content > pushes me to ask about www.example.com and every time I do > that I emit that user-specific key tag. While that'd be > unlikely for a large zone, it might be feasible as a tracker > if some "bad" domain sets up a specific subdomain for such > purposes. That said, I'm not clear how much better this is for > the attacker compared to simply using a tracking name in the > authority component of the URL for e.g. some 1x1 gif. One important aspect to clarify here is that resolver shouldn't be transmit= ting the key tags for every query. They are only to be sent with or at the= same time as DNSKEY queries. 4.2 says that the edns-key-tag option MUST NOT be sent for non-DNSKEY queri= es. 5.2 says the need to issue a DNSKEY query is also the trigger to issue a ke= y tag query. Additionally, the document says that resolvers SHOULD transmit the key tags= for zones with configured trust anchors and MAY do so for non-trust anchor= zones. For most resolvers only the root zone would be configured as a tru= st anchor. Lastly, there is a practical limitation here in that each unique key given = out would require a corresponding unique DS record in the parent zone. A m= alicious zone operator might be able to get away with tens of unique keys, = but probably not hundreds. The one exception to this would be if the malic= ious actor operated both a parent zone and a child zone. Given all that, do you think it warrants a paragraph in the privacy section= ? DW From nobody Thu Feb 16 14:33:37 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A7A12973A; Thu, 16 Feb 2017 14:33:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148728441609.983.17291975684694973749.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 14:33:36 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:33:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) Authors : Duane Wessels Warren Kumari Paul Hoffman Filename : draft-ietf-dnsop-edns-key-tag-05.txt Pages : 12 Date : 2017-02-16 Abstract: The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain-of-trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain-of-trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-edns-key-tag-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-key-tag-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 16 15:19:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044A91294E9 for ; Thu, 16 Feb 2017 15:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 LgoOAFuiiM82 for ; Thu, 16 Feb 2017 15:19:52 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9423C129455 for ; Thu, 16 Feb 2017 15:19:52 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 51578276C0; Thu, 16 Feb 2017 15:19:52 -0800 (PST) From: Wes Hardaker To: Warren Kumari References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 15:19:52 -0800 In-Reply-To: (Warren Kumari's message of "Thu, 16 Feb 2017 12:43:19 -0500") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Bob Harold , dnsop , Wes Hardaker Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 23:19:54 -0000 Warren Kumari writes: > On Thu, Feb 16, 2017 at 11:33 AM, Wes Hardaker wrote: >> Bob Harold writes: >> >>> Thanks for your work on this. Some minor formatting issues: >> >> Odd. I think *someone* wasn't using a real editor (*cough*emacs*cough*) >> and it inserted some odd white space into XML components. > > ... and it seems that that someone was Wes :-P Yeah... I'll go eat my shoe now. -- Wes Hardaker USC/ISI From nobody Thu Feb 16 15:21:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56F1129421 for ; Thu, 16 Feb 2017 15:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 FzFscpeWqND8 for ; Thu, 16 Feb 2017 15:21:24 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73671295DA for ; Thu, 16 Feb 2017 15:21:23 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 7B28B3217D; Thu, 16 Feb 2017 15:21:23 -0800 (PST) From: Wes Hardaker To: Wes Hardaker References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> <20170206131153.52329a04@pallas.home.time-travellers.org> <7dd02b3e-910b-b287-14cf-d7fe7755cd2d@nic.cz> Date: Thu, 16 Feb 2017 15:21:23 -0800 In-Reply-To: (Wes Hardaker's message of "Thu, 16 Feb 2017 09:29:15 -0800") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: dnsop@ietf.org, Petr =?utf-8?B?xaBwYcSNZWs=?= Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 23:21:26 -0000 Wes Hardaker writes: > Fortunately, after a quick conversation we've recovered the reason. > Publishing a new version with a break-out explanation shortly. The 3/2 > is absolutely is needed. I've published -03 which adds new text just below the equation explaining the components (and the equation got more complex to match the complexity of 5011). Anyway, please do let me know if you think the new text adequately explains the problem to you. I probably need to go back and insert the "worst case" timing into the example timeline, but that would make the example a bit more messy. -- Wes Hardaker USC/ISI From nobody Thu Feb 16 17:10:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048B5129650; Thu, 16 Feb 2017 17:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 eOMCIkc81IAr; Thu, 16 Feb 2017 17:10:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA7C129559; Thu, 16 Feb 2017 17:10:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 56996BE77; Fri, 17 Feb 2017 01:10:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlByu1hcW1OI; Fri, 17 Feb 2017 01:10:25 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 892ACBE74; Fri, 17 Feb 2017 01:10:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487293825; bh=P09LBwMDdtG3xN00breqOoIc7jC03yJVkuFq3x+FqcQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qIXQf4zQqfRgOV0nCGWPgE9DLZNgr5iYoMfTPEsibgR+NF0UgMdTnpUgY5tAD/rD3 hM9R/3RvKw/hZjYeDRKlAynwQjQWE7EM2rOf81TIo8RFQHouNTyQJ6nypn++uZPOhW znbPpxy1c7wPAUW6pghsyYFW0tFYj6WiF+XRF6yE= To: "Wessels, Duane" References: <148721128491.31391.12912602191917167130.idtracker@ietfa.amsl.com> <30D3A4E8-D55D-4D5E-AB3F-28D3B0C4EF99@verisign.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 17 Feb 2017 01:10:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <30D3A4E8-D55D-4D5E-AB3F-28D3B0C4EF99@verisign.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="864VCvAC0rwGpT1ExVNhTVw6FMA9adlph" Archived-At: Cc: Tim Wicinski , "draft-ietf-dnsop-edns-key-tag@ietf.org" , "dnsop@ietf.org" , "dnsop-chairs@ietf.org" , The IESG Subject: Re: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-edns-key-tag-04: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 01:10:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --864VCvAC0rwGpT1ExVNhTVw6FMA9adlph Content-Type: multipart/mixed; boundary="0d6QXMCoI0wBREqwLpvesgldl9M2tqslp"; protected-headers="v1" From: Stephen Farrell To: "Wessels, Duane" Cc: Tim Wicinski , "draft-ietf-dnsop-edns-key-tag@ietf.org" , "dnsop@ietf.org" , "dnsop-chairs@ietf.org" , The IESG Message-ID: Subject: Re: Stephen Farrell's Yes on draft-ietf-dnsop-edns-key-tag-04: (with COMMENT) References: <148721128491.31391.12912602191917167130.idtracker@ietfa.amsl.com> <30D3A4E8-D55D-4D5E-AB3F-28D3B0C4EF99@verisign.com> In-Reply-To: <30D3A4E8-D55D-4D5E-AB3F-28D3B0C4EF99@verisign.com> --0d6QXMCoI0wBREqwLpvesgldl9M2tqslp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 16/02/17 21:43, Wessels, Duane wrote: >=20 > Hi Stephen, >=20 >=20 >>=20 >> ----------------------------------------------------------------------= >> >>=20 COMMENT: >> ----------------------------------------------------------------------= >> >> >> >>=20 - abstract: referring to section 1.1 from here seems wrong, >> the abstract ought be readable by itself >=20 > Agreed. I propose to remove that sentence and let the abstract stand > on its own. >=20 >=20 >>=20 >> - section 5: Is the key tag query only and solely intended to allow >> the authoritative to track how clients are paying attention (or >> not) to key rollovers? If there's another purpose I'm not clear >> about it. >=20 > Yes, that is the sole purpose. Do you think this needs to be made > more explicit? Up to you. It wasn't clear to me at first, but was clear when I finished reading. >=20 >=20 >>=20 >> - 5.3: "I believe that to be..." seems like the wrong language to >> use with >1 author. >=20 > Yes. This sentence was already removed from the authors' shared > source file shortly after -04 was sent out. >=20 >>=20 >> - section 7/8: Is there a missing security/privacy consideration >> here, in that an authoritative server here could arrange to hand >> out key tags that are specific to (in the limit) each query, so >> that when the resolver queries a sub-domain, and thereafter, the >> client will be identifiable to the authoritative server? One could >> do this by generating new keys per querier so that if I ask about >> example.com I get given a tag that's unique to me, and then some >> web content pushes me to ask about www.example.com and every time I >> do that I emit that user-specific key tag. While that'd be unlikely >> for a large zone, it might be feasible as a tracker if some "bad" >> domain sets up a specific subdomain for such purposes. That said, >> I'm not clear how much better this is for the attacker compared to >> simply using a tracking name in the authority component of the URL >> for e.g. some 1x1 gif. >=20 > One important aspect to clarify here is that resolver shouldn't be > transmitting the key tags for every query. They are only to be sent > with or at the same time as DNSKEY queries. >=20 > 4.2 says that the edns-key-tag option MUST NOT be sent for non-DNSKEY > queries. >=20 > 5.2 says the need to issue a DNSKEY query is also the trigger to > issue a key tag query. >=20 > Additionally, the document says that resolvers SHOULD transmit the > key tags for zones with configured trust anchors and MAY do so for > non-trust anchor zones. For most resolvers only the root zone would > be configured as a trust anchor. >=20 > Lastly, there is a practical limitation here in that each unique key > given out would require a corresponding unique DS record in the > parent zone. A malicious zone operator might be able to get away > with tens of unique keys, but probably not hundreds. The one > exception to this would be if the malicious actor operated both a > parent zone and a child zone. >=20 > Given all that, do you think it warrants a paragraph in the privacy > section? Again, up to you. The issue is fairly borderline so I won't argue if you don't wanna. S. >=20 >=20 > DW >=20 --0d6QXMCoI0wBREqwLpvesgldl9M2tqslp-- --864VCvAC0rwGpT1ExVNhTVw6FMA9adlph Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYpk2AAAoJEC88hzaAX42i9R4H/Ri881b+bVRQFI2IrNtIavpu gSUkuICKLenNLR1cmV5RfbgJCUPcoEVv+ite0XVCqlcbqDWu5vlNM1sFGVxP9DjT vZxv0qXX8tDm4iizINz+01wQNlgm7Z5QS3Q/LnHTRJ31o+FQBAa9T2TZS/wXW5kj MS84HqKb2MpX+rdNDnAwW2Ga3rKkDOPY/YS9M0HeKxXPotk3Yb0LI7ePuPLZasxF LPOchrzJhJaj8Ark2maK+N2NE3VdeIRBJYeGOMzPURjQ6IP5/9z6YMyZtYZQa+pZ d53aqDVo54M51Db/U6xjjxJvsVqemeX+KMyMzi7WPvTL+52uciz3an/d7isYAVc= =LqZI -----END PGP SIGNATURE----- --864VCvAC0rwGpT1ExVNhTVw6FMA9adlph-- From nobody Fri Feb 17 04:00:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103391299BE for ; Fri, 17 Feb 2017 04:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 qPnTpjkaEH-P for ; Fri, 17 Feb 2017 04:00:02 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA201299C4 for ; Fri, 17 Feb 2017 04:00:01 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:6838:2cff:fe1a:3e51] (unknown [IPv6:2001:1488:fffe:6:6838:2cff:fe1a:3e51]) by mail.nic.cz (Postfix) with ESMTPSA id 07E966010D; Fri, 17 Feb 2017 12:59:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487332799; bh=/c4rN0qkgaRFaDRXFbZQqDCGTuIGDd9cixCqzqjabMc=; h=To:From:Date; b=v1ft8PKnPqqQz5cQyG7ghkzx5zcrr6biSy54hF7JlR1wM+zHbsa3BV7D6i2Sq4n7b SIijQWCaIADhMbYTCy7hefw50MtEMX2/yTeMeZDrob0FyWDM79ANIkFkmsB57bX15V v0LBMUombBB5IyhK50awK1V5MGXxS+b68PS95pes= To: dnsop@ietf.org, Wes Hardaker References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> <20170206131153.52329a04@pallas.home.time-travellers.org> <7dd02b3e-910b-b287-14cf-d7fe7755cd2d@nic.cz> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <8f3db72f-69ff-be02-2e30-2499f77dd2cb@nic.cz> Date: Fri, 17 Feb 2017 12:59:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 12:00:04 -0000 On 02/17/2017 12:21 AM, Wes Hardaker wrote: > Wes Hardaker writes: > >> Fortunately, after a quick conversation we've recovered the reason. >> Publishing a new version with a break-out explanation shortly. The 3/2 >> is absolutely is needed. > > I've published -03 which adds new text just below the equation > explaining the components (and the equation got more complex to match > the complexity of 5011). Thanks! The equation seems more complex at first glance but it is way more understandable for me. When reading the quote from the RFC5011 "Active Refresh" requirements, I realized the equation is not complete without: MAX(MIN(...), 1 hour) I.e. the waitTime would be too short for quick turn-around zones. This is probably not that important for practical deployment but it gets veeery important when transforming RFC text to a compliance test. Please add the MAX(), it will help someone in future. (I'm just trying to write compliance test for RFC 6672 ...) > Anyway, please do let me know if you think the new text adequately > explains the problem to you. The explanation seems good to me. Just a few comments about the text: It would be easier to understand for me if this paragraph was split into two (1st the constraint + 2nd prelude for analysis): /the matter/ The important timing constraint that must be considered is the last point at which a validating resolver may have received a replayed the original DNSKEY set (K_old) without the new key. It's the next query of the RFC5011 validator that the assured K_new will be seen. /prelude for analysis/ For the following paragraph, we use the more common case where (DNSKEY RRSIG Signature Validity) is greater than (original TTL for the DNSKEY RRSet), although the equation above takes both cases into account. Moreover the /prelude for analysis/ seems little bit confusing. What about something along these lines? /replacement prelude for analysis, preferably as separate paragraph/ The interval used by RFC5011 resolver is determined by lesser of (DNSKEY RRSIG Signature Validity) or (original TTL for the DNSKEY RRSet). Following text assumes that (DNSKEY RRSIG Signature Validity) is smaller of the two. /original text continues here/ Thus, ... > I probably need to go back and insert the > "worst case" timing into the example timeline, but that would make the > example a bit more messy. It seems sufficient to me to keep the analysis in (current) section 6. Maybe just a forwad-reference would suffice. Thank you for the clarification! -- Petr Špaček @ CZ.NIC From nobody Fri Feb 17 10:24:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EBC129B19 for ; Fri, 17 Feb 2017 10:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.145 X-Spam-Level: X-Spam-Status: No, score=0.145 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 7kSmFgdkdeqz for ; Fri, 17 Feb 2017 10:24:33 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0042.hostedemail.com [216.40.44.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1E2129B17 for ; Fri, 17 Feb 2017 10:24:32 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 19E38351D1B for ; Fri, 17 Feb 2017 18:24:31 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, avri@acm.org, :, RULES_HIT:41:355:379:599:854:967:973:988:989:1042:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1515:1516:1518:1534:1538:1593:1594:1683:1711:1714:1730:1747:1777:1792:2393:2525:2560:2563:2682:2685:2693:2740:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3350:3865:3867:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4184:4250:5007:7652:7901:7903:8985:9025:10004:10400:10848:11232:11658:11914:12043:12109:12114:12760:13019:13069:13071:13311:13357:13436:14180:14181:14721:14764:14777:21060:21080:21366:21433:30022:30029:30054, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fp, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:2, LUA_SUMMARY:none X-HE-Tag: owner80_7eacb60c99330 X-Filterd-Recvd-Size: 1435 Received: from [127.0.0.1] (unknown [23.106.43.243]) (Authenticated sender: avri@doria.org) by omf01.hostedemail.com (Postfix) with ESMTPA for ; Fri, 17 Feb 2017 18:24:30 +0000 (UTC) References: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> <4A0B1143-B900-47C4-A495-720B76F0F77C@gmail.com> To: dnsop@ietf.org From: Avri Doria Organization: Technicalities Message-ID: <8823a337-c09a-d49f-da92-a868bdc223b6@acm.org> Date: Fri, 17 Feb 2017 18:24:28 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <4A0B1143-B900-47C4-A495-720B76F0F77C@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 170216-1, 02/16/2017), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: avri@acm.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 18:24:35 -0000 Hi, Just rereading before the meeting. Re: > If there is an IETF process through which a name can be assigned at > zero cost other than time, this process will be used as an alternative > to purchasing the name through ICANN. perhaps just a small thing but it is not really a purchase but more like a licensing (though am not postive that is the word either) avri --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Fri Feb 17 12:49:17 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704E4129BD5 for ; Fri, 17 Feb 2017 12:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 8LADmXkQu82d for ; Fri, 17 Feb 2017 12:49:14 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 D3370129BD3 for ; Fri, 17 Feb 2017 12:49:13 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id h10so32363626ith.1 for ; Fri, 17 Feb 2017 12:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=4UvPCqVLyTexZXbDSGRt0zvnKlxn3GbLqFW0QOMtWGM=; b=Qw5EcuGP6QZTSN6m4BONM3jtZutRbpRqp21R4t0YDVoMaLsZXPQHNDTe1c0w+t0P4f o/Bs1BpnNqSWHtuNmNDqKosYfjKYmQpf9OM0LYbpBZZ6I+bRHMJPTX6Q0pOFUN2dtE1c mN1+tlK5+N/oTYGo8KtOssIZ9qBWcG3fFlKdhQMxrLs6vbA+5labc+UHjmZs1+KXKSy9 UUa6z/HoyZN4Mu9xufgnKKrXxoIUlnnmbUHPmAHk9i8AgA9Qy0JxS3uQ/ClGp2lTz+5j DA2iPTQfIv2vVGDsdzPZtVF7TddjdxpFC7BtMSuZnzD7ghsXFlzPaXuljJrlmwA5qEpj vQBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4UvPCqVLyTexZXbDSGRt0zvnKlxn3GbLqFW0QOMtWGM=; b=LTvLIvcFqnHfCw6dmkWUQ5eskaXpdJ8VdNG6ltHQcEWGaQoIhMaUzRXJs/FC7yTFMC 9qYQnBpO0qGsWVk94TeVctFG5pp2WSBrtbaiLbUjXTxyt09PmPiLZFoRjZY5+BLjJBfF YEqvDr2/+n9MBXblgodiYrdyu5RT/GqhF3LRpT2FIXxig5mrr554nr3VHCEc4lpMvsf9 gq+8WJoBVI+q8rrYsSbuH2b8TYirWywTVvXtMosjU1KxDqeauTDXLKgJRkj6SnQK5Cke 0A6AIvetbZLe+kP553/NXoY0q1i3pB49A7I7NiB/kMIfnuuuW7lqSHbTd64Fmiovc5pv HPzg== X-Gm-Message-State: AMke39lBvjFEN4656xypclvww+4Lpo3eyP4TuviWEryT4Ec1jibIqj7qXX6UnSIMEjs1mJaJg+ZE00Jb0Yxo5xhM X-Received: by 10.36.71.207 with SMTP id t198mr6258004itb.98.1487364552879; Fri, 17 Feb 2017 12:49:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.164 with HTTP; Fri, 17 Feb 2017 12:49:12 -0800 (PST) In-Reply-To: References: From: Ben Schwartz Date: Fri, 17 Feb 2017 15:49:12 -0500 Message-ID: To: dnsop@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1145b664d8410d0548c00b10" Archived-At: Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 20:49:15 -0000 --001a1145b664d8410d0548c00b10 Content-Type: multipart/alternative; boundary=001a1145b664d3e31f0548c00b5e --001a1145b664d3e31f0548c00b5e Content-Type: text/plain; charset=UTF-8 Thanks for the input everyone! Here's an updated version with some clarifications based on your feedback: https://tools.ietf.org/html/draft-schwartz-dns-sni-02 Diff: https://www.ietf.org/rfcdiff?url1=draft-schwartz-dns-sni-01&url2=draft-schwartz-dns-sni-02 I know this approach is controversial, so I'm also very curious to hear any suggestions of other ways that we could fix this privacy leak without slowing down everyone's connections. As a friend put it: if everyone can see you're reading justinbieber.tumblr.com, "that defeats the whole point of HTTPS". On Tue, Feb 14, 2017 at 1:02 PM, Ben Schwartz wrote: > Hi dnsop, > > I've written a draft proposal to improve the privacy of TLS connections, > by letting servers use the DNS to tell clients what SNI to send. > > https://tools.ietf.org/html/draft-schwartz-dns-sni-01 > > I've incorporated some helpful feedback [1] from the TLS WG, but now I > could use your help analyzing the DNS side. All comments welcome; this > draft will change based on your feedback. > > One particular issue that I could use advice on: should this be a new > record type, or should it reuse/repurpose an existing type like SRV or PTR? > > Thanks, > Ben > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html > --001a1145b664d3e31f0548c00b5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the input everyone!=C2=A0 Here's an updated= version with some clarifications based on your feedback:

Diff:
https://www.ietf.org/rfcdiff?url1= =3Ddraft-schwartz-dns-sni-01&url2=3Ddraft-schwartz-dns-sni-02

I know this approach is controversial, so I'm a= lso very curious to hear any suggestions of other ways that we could fix th= is privacy leak without slowing down everyone's connections.=C2=A0 As a= friend put it: if everyone can see you're reading justinbieber.tumblr.com, "that defeats the = whole point of HTTPS".

On Tue, Feb 14, 2017 at 1:02 PM, Ben Schwartz <bemas= c@google.com> wrote:
Hi dnsop,

I've written a draft= proposal to improve the privacy of TLS connections, by letting servers use= the DNS to tell clients what SNI to send.

https://tools.ietf.org/html/draft-schwartz-dns= -sni-01

I've incorporated some helpful feedback = [1] from the TLS WG, but now I could use your help analyzing the DNS side. = All comments welcome; this draft will change based on your feedback.
<= div>
One particular issue that I could use advice on: should = this be a new record type, or should it reuse/repurpose an existing type li= ke SRV or PTR?

Thanks,
Ben

--001a1145b664d3e31f0548c00b5e-- --001a1145b664d8410d0548c00b10 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMdhJKC5aeSlGRk8YNMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDIxNjE4MDA1NVoXDTE3MDgx NTE4MDA1NVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC8JMN/Ya86Mmyv36dxJwPZXCrBZx8Hi0G6muYM3u+QThV/mu6B MpT3gEisJW8pU6iVPzxumyU7mDMwW8eshDTny91C+hTAP+cu1t4eIAmAZuNvXNd//DdmXOHvQvOU 2rH7+wTEYN0lvlSFydes0gud9VWl2hMTayncmyloIefNk/6lc2LRqw2geNw50jN1VqFpNMoxBOAp R+qJHuzxnanR4m3K1ujYUIeOUjLMFE4VxsOBtuF1FDx+SoXj18NpQyfioGPDXAgOIIE6PS244eZE 0De/SF3kvRf0AyCSrX102ZNu7i0L6Bb7P3bIDA0NB5uV5UNa2bBpuXq69gX07F/pAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFB6zCsWx7DJYdsxPym0ajAsc2DNCMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAckYJsVmfrg36lwFYD oepVYSEb0nhq9Y2/3T+cTKK/MCaU1oIRZ7LjmeFxkmA27jTy29y8+X+k5w9+I2E5vDI4D52vlKT+ FaouZnHGy1/oKZtUhMqjVn+DyEFdo1vOkir5R7cbxCK2QukpLQOb+RvzU5mOAYvwLgqn21yrcqBc 3pcYh4NlREjPe455gpwJl0d5TvYSCXEDUBXcWV7Bic7oVuPR0zXGsHQRQN7hkQsuEpwH0RhmaB/a GVYPktJvahNnk7JYoU8eRu7xwwA35VaXbUAuJCMq3UxAgBB59guHTeLZK9PSn0FqFo4sN12g4lsv ivmunuxPsD/Ozdn6yxtfMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMdhJKC5ae SlGRk8YNMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDPLxCe2AyNuBwa6HiFiBxM ev0177yZ2+NvLVjZEfvQWjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAyMTcyMDQ5MTNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAHaqueEZPTsGwuVD0DtgMtrAoy0cKxp9EOoy0NXag 4wirRTmB5p795/UUaGGE7UN5kbbdVIKqiP3H1kFnRD5XHCm5UTJ/vq5WP36BSfYrKEGVOt8mky1N PoTjSWp9EWuWKCizX5imI3wp2ELF9ji4ED69ZW4K7tJDpdZQL7hCGkgciL54ctKGCZMCFoNhhK/f VL2Hmv6JZplbxOyz4Rm+FOTQAIusaWyPGB2MLCc0HOcZ6xZc8V0is5ipQKfLVMQFetBaQ5cunRsj 3ihn6557BrwiQUF5A7+rW2geLyvtzj2/L45+44FBtsWCvk++yvNLJESdQ9pZDt12Ty7mt1xhiA== --001a1145b664d8410d0548c00b10-- From nobody Fri Feb 17 13:38:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E061296C7 for ; Fri, 17 Feb 2017 13:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 KVnjYK6C3rFx for ; Fri, 17 Feb 2017 13:38:28 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8B91296AD for ; Fri, 17 Feb 2017 13:38:28 -0800 (PST) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id ECAC327C6B for ; Fri, 17 Feb 2017 13:38:26 -0800 (PST) From: Wes Hardaker To: dnsop@ietf.org Date: Fri, 17 Feb 2017 13:38:25 -0800 Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [DNSOP] Published: draft-hardaker-rfc5011-security-considerations-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 21:38:29 -0000 For those following along with this draft, I've just published -04. -- Wes Hardaker USC/ISI From nobody Fri Feb 17 14:03:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C1A129C1C for ; Fri, 17 Feb 2017 14:03:38 -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 UQHaEE1bxKBS for ; Fri, 17 Feb 2017 14:03:37 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22CE129C0A for ; Fri, 17 Feb 2017 14:03:32 -0800 (PST) Received: (qmail 75574 invoked from network); 17 Feb 2017 22:03:31 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 17 Feb 2017 22:03:31 -0000 Date: 17 Feb 2017 22:03:09 -0000 Message-ID: <20170217220309.9637.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 22:03:39 -0000 In article you write: >I know this approach is controversial, so I'm also very curious to hear any >suggestions of other ways that we could fix this privacy leak without >slowing down everyone's connections. I have problems with the word "other". This approach depends for its security on the assumption that it is hard to reverse SNI record lookups, that is, to find the qname(s) that have SNI records with given contents. That is a poor assumption. There are many large passive DNS databases, and a lot of people have access to them. My working assumption is that anyone sophisticated enough to peek at TLS handshake packets is sophisticated enough to find a passive DNS source. So to me the question is whether the small speculative incremental increase in user security is worth the investment to define a new record type, add it to DNS servers and provisioning systems, add it to web server configuration languages, and set up whatever infrastructure is needed to coordinate the published SNI records and what the web servers expect. I'd also note that if the assumption is that people will publish SNI records through the usual registrar and dns hosting operators managed through web consoles, there is no chance that the webware will support SNI records. We know this because they don't support any other RRTYPEs defined in the past decade, either. R's, John From nobody Fri Feb 17 18:09:44 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DA0126B6D for ; Fri, 17 Feb 2017 18:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 Tfz4Z0WZgC0F for ; Fri, 17 Feb 2017 18:09:41 -0800 (PST) Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::244]) (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 90A7E128BA2 for ; Fri, 17 Feb 2017 18:02:15 -0800 (PST) Received: by mail-ua0-x244.google.com with SMTP id k3so5152576uak.3 for ; Fri, 17 Feb 2017 18:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QnKl5rBPNd+rbyEXODbpengGiLnyKEdiH0z1bF63b3Y=; b=rvTZUwKUaAWjf+XgucpK4NbGjVSQBI8YFHXgHF0h25W2X3F+L6F9mwycH3aZ8AESpU romYttIHI+8NqmUm3yarojtE8L3XkLymOQfDBl03YVu3H7Od+aPfMpEoyxd5auer5Zho UWX1d2WUJQz4F2wnexhGCqwA5tgaJE/rvSPQetk59k+ujSdWq8U1AO5Z21ngeLlzmvyE c8Vh7LSn27TgDvfTUrLufpt4gkku9LihhkHqGSVbsVXq/LFLdAqLdJW2C9OPfejpyAQ0 YViIlo9lFRbmh4EQSWRbj0ZgCdyQlYX3zlEwdeNF9jsNdZxy2jXfgK2oq6wmB4aNg9mn k+eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QnKl5rBPNd+rbyEXODbpengGiLnyKEdiH0z1bF63b3Y=; b=kniGK4xpAq6u5po1j4xi2xAWUc4jUhJl/lpgDGSO3eTg6SXCWUNivjb2nnVyt0tBVf av2ymWJvj8MLCygypvB1GQwBfCw1tbPaNw7mIXiwAtnhG76sm29Yy3HdqvNZyZztHEvI kixrIjn1q7+Wyj8Tz7+pwemhBNcgc32JAgylDWp4/c25inCYcjQgyErRHvmbuUChZTQt CG1JTZw5vNAm5dx/wh0sh2PqpFCH90pYzZHzSowL+inLDcXYN5Di4+4u2o1cwqV/1mup O/d6tHH0BzYdpiVBl+5CNHJtp+ZbZuGyKTrX7mZynftFrkf2kWiMhL9PfyMU93BtF+7O Iatw== X-Gm-Message-State: AMke39kEBBr4fajtphK6PJOQpFGbDLKal7IapISspe6vnna1effa8RKMjATrbl3Nhc2mImQEYLsHGORFalW2GQ== X-Received: by 10.176.74.30 with SMTP id q30mr1922273uae.4.1487383334631; Fri, 17 Feb 2017 18:02:14 -0800 (PST) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.103.146.79 with HTTP; Fri, 17 Feb 2017 18:02:14 -0800 (PST) In-Reply-To: References: From: Erik Nygren Date: Fri, 17 Feb 2017 21:02:14 -0500 X-Google-Sender-Auth: -qwCd63tnAckZMh81Vu9Ill9k5U Message-ID: To: Ben Schwartz Content-Type: multipart/alternative; boundary=f403045f87164e416b0548c46bde Archived-At: Cc: dnsop@ietf.org, dkg@fifthhorseman.net Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 02:09:43 -0000 --f403045f87164e416b0548c46bde Content-Type: text/plain; charset=UTF-8 I wrote a similar draft a few years ago which I've been considering resurrecting if there is interest: https://tools.ietf.org/html/draft-nygren-service-bindings-00 One of the big challenges that at least in the web context, browsers want to make as few DNS lookups as possible prior to making HTTP requests. (For example, some home gateways choke if too many requests are outstanding.) Having to lookup both A and AAAA is already a problem. So if we're going to add something, ideally we'd add something that was extensible that could be used for multiple purposes. For this case, the result could be something like: _https._b.www.example.com IN B 2 0 www.example.com. { "alpn": "h2", "tls-sni": "SOME_TOKEN", "hsts": true } _https._b.www.example.com IN B 1 0 www-alt.example.com. { "alpn": "quic352", "tp": 443, "tls-sni": "SOME_OTHER_TOKEN", "hsts": true } By adding this one single lookup, you both get to specify an alternate SNI, be able to force HTTPS-only, and specify Alternative Services (ala rfc7838 but allowing it to be done in DNS). Having an extensible model here also increases the value of a client doing the lookup as once the records exist other optional attributes can be added in. (Ignore the specific key/value pair examples in that expired I-D. They made more sense when some other things were being considered.) Based on our extensive discussions in the TLS WG over the past few years, introducing something like this into the DNS to indicate an alternate SNI value (which might be one shared with many other hostnames) or telling the client not to send an SNI value seemed to be one of the best ways to help with the SNI privacy problems, at least once there is a DNS privacy path. For example, for a cert like *.example.com (perhaps with lots of other SANs as well) there is no reason the client needs to send " something-potentially-private.example.com" when sending an SNI value of "wildcard.example.com" would do just fine. The TLS handshake is too late to learn this, but if we could move it into the DNS then clients could learn it (and potentially other useful info) before connecting. [I added DKG as he was a strong advocate of doing something in this space for signalling TLS SNI omission, alteration, or aliasing in DNS records.] Erik On Fri, Feb 17, 2017 at 3:49 PM, Ben Schwartz wrote: > Thanks for the input everyone! Here's an updated version with some > clarifications based on your feedback: > https://tools.ietf.org/html/draft-schwartz-dns-sni-02 > > Diff: > https://www.ietf.org/rfcdiff?url1=draft-schwartz-dns-sni- > 01&url2=draft-schwartz-dns-sni-02 > > I know this approach is controversial, so I'm also very curious to hear > any suggestions of other ways that we could fix this privacy leak without > slowing down everyone's connections. As a friend put it: if everyone can > see you're reading justinbieber.tumblr.com, "that defeats the whole point > of HTTPS". > > On Tue, Feb 14, 2017 at 1:02 PM, Ben Schwartz wrote: > >> Hi dnsop, >> >> I've written a draft proposal to improve the privacy of TLS connections, >> by letting servers use the DNS to tell clients what SNI to send. >> >> https://tools.ietf.org/html/draft-schwartz-dns-sni-01 >> >> I've incorporated some helpful feedback [1] from the TLS WG, but now I >> could use your help analyzing the DNS side. All comments welcome; this >> draft will change based on your feedback. >> >> One particular issue that I could use advice on: should this be a new >> record type, or should it reuse/repurpose an existing type like SRV or PTR? >> >> Thanks, >> Ben >> >> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html >> > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --f403045f87164e416b0548c46bde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wrote a similar draft= a few years ago which I've been considering resurrecting if there is i= nterest:

=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-nygren-s= ervice-bindings-00

One of the big challenges that at least= in the web context, browsers want
to make as few DNS lookups as p= ossible prior to making HTTP requests.
(For example, some home gat= eways choke if too many requests are outstanding.)
Having to looku= p both A and AAAA is already a problem.=C2=A0 So if we're going to add<= br>
something, ideally we'd add something that was extensible that= could be used
for multiple purposes.

For this case,= the result could be something like:
_https=
._b.www.example.com IN B 2 0 www.example.com. { "alpn": &quo=
t;h2", "tls-sni": "SOME_TOKEN", "hsts": =
true }
_https._b.www.example.com IN B 1 0 www-alt.example.com. =
{ "alpn": "quic352", "tp": 443, "tls-sni=
": "SOME_OTHER_TOKEN", "hsts": true }=C2=A0
By adding this one single lookup, you=
 both get to specify an alternate SNI,
be able to force HTTPS-only, and =
specify Alternative Services (ala rfc7838
but allowing it to be done in =
DNS).=C2=A0 Having an extensible model here also increases
th=
e value of a client doing the lookup as once the records exist other option=
al
attributes can be added in.

(Ignore the =
specific key/value pair examples in that expired I-D.=C2=A0 They made more<=
br>
sense when some other things were being considered.) 

Based on our extensive discussions in the TLS WG over=
 the past few years,
introducing something like this into the=
 DNS to indicate an alternate SNI value
(which might be one s=
hared with many other hostnames) or telling the client 
not to send an S=
NI value seemed to be one of the best ways to help with 
the =
SNI privacy problems, at least once there is a DNS privacy path.
<=
div>
For example, for a cert like *.examp=
le.com (perhaps with lots of other SANs as well)
there is no reason =
the client needs to send "something-potentially-private.example.com" when s=
ending
an SNI value of "wildcard.example.com" would do just fine.=C2=A0 The TLS ha=
ndshake
is too late to learn this, but if we could move it in=
to the DNS then clients
could learn it (and potentially other=
 useful info) before connecting.

[I added DKG =
as he was a strong advocate of doing something in this space
=
for signalling TLS SNI omission, alteration, or aliasing in DNS records.]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik




On Fri, Feb 17, 2017 at 3:49 PM, Ben Schwartz <bemasc@goo=
gle.com> wrote:
Thanks for the input everyone!=C2=A0 Here's an updated version wi=
th some clarifications based on your feedback:

Diff:

I know=
 this approach is controversial, so I'm also very curious to hear any s=
uggestions of other ways that we could fix this privacy leak without slowin=
g down everyone's connections.=C2=A0 As a friend put it: if everyone ca=
n see you're reading justinbieber.tumblr.com, "that defeats the whole point=
 of HTTPS".

On Tue, Feb 14, 2017 at =
1:02 PM, Ben Schwartz <bemasc@google.com> wrote:
Hi dnsop,

=

I've written a draft proposal to improve the privacy of TLS connec=
tions, by letting servers use the DNS to tell clients what SNI to send.

https://tools.ietf.org=
/html/draft-schwartz-dns-sni-01

I've incorp=
orated some helpful feedback [1] from the TLS WG, but now I could use your =
help analyzing the DNS side. All comments welcome; this draft will change b=
ased on your feedback.

One particular issue that I=
 could use advice on: should this be a new record type, or should it reuse/=
repurpose an existing type like SRV or PTR?







_______________________________________________

DNSOP mailing list

DNSOP@ietf.org

https://www.ietf.org/mailman/listinfo/dnsop





--f403045f87164e416b0548c46bde--


From nobody Fri Feb 17 18:23:49 2017
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B1C1295F7 for ; Fri, 17 Feb 2017 18:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 E5BxAeEMFhId for ; Fri, 17 Feb 2017 18:23:45 -0800 (PST)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 5A1CA129584 for ; Fri, 17 Feb 2017 18:23:45 -0800 (PST)
Received: by mail-io0-x232.google.com with SMTP id j13so4398674iod.3 for ; Fri, 17 Feb 2017 18:23:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rE5KTCnizQDLmgAF0y3W4i94bOFFt5ViOO5e/YMIdOw=; b=FEosVjGhccqp6rQA4KCY26pVG3IZhZmSZ+w7Jd+h1JZkq+GYAOzwiNLWPLIq7N/FCW nz8E/rSIsvHAqRNVBchjoVIq5ZU5CEm3klM/AmjXX0JvBh3/oW3Z69/Ycss+7RAEBziE sOk0IynJgl+WYCKAvagQC9HFInkzsF3honERb1bHHLc1JzCHzBWPg12WWbK7iLyyJmfi m3OxEtCPDCznV25I+uZ3TQOOMAAvHuThsmxQGvRWkFRp9qSAGbqUSxOOsvIcoC8gXup4 8c+YGUInpQ0oAljOtRN8++NLSCWhwU7FAk1DUXoD3OiKcJ0Nqt+Py+4WL8/IWqAPGEw8 QddA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rE5KTCnizQDLmgAF0y3W4i94bOFFt5ViOO5e/YMIdOw=; b=RR8ssDZN+RbTy6n14oDEA05GPlB4amUFqXpgU5qC8Yx2ebWfMJMSja9BXX4WSv0JRq zG+hea3bqBe3juE01rllW8Roqmzc4ZQtr7QW2WrVXRSSVxD7sXcUEfKwmF6nzCOQPouD ywjl/p+0KgIestQ50I0j2CccrRDn6/ySSsn2Nh5u1tdMkU5mmnyDbQ+L7GQUrQgzJcG1 dhNRfumIgki9xteuvyZbACa4rdm4goL26JRvl++qVHGFM0DiOFjKrYuF43adgnlYSy+m ln6TDgu0bFe8gDaFdqR0zpXZ0DRhsncIPh2Z7019As2cA3L1TjkCRGs2gVxx9G4EFS4K iKrQ==
X-Gm-Message-State: AMke39nmG601wfbsU+PqNc5hZDQnzSd6l6pRZVm9oU7uOVZimrH1WGKXLdX3d/LLjmx3QZc8m84Nz/B3dXfdJUVs
X-Received: by 10.107.34.10 with SMTP id i10mr9005631ioi.41.1487384624464; Fri, 17 Feb 2017 18:23:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Fri, 17 Feb 2017 18:23:43 -0800 (PST)
In-Reply-To: <20170217220309.9637.qmail@ary.lan>
References:  <20170217220309.9637.qmail@ary.lan>
From: Ben Schwartz 
Date: Fri, 17 Feb 2017 21:23:43 -0500
Message-ID: 
To: John Levine 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1140ec6834b3380548c4b85c"
Archived-At: 
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Feb 2017 02:23:47 -0000

--001a1140ec6834b3380548c4b85c
Content-Type: multipart/alternative; boundary=001a1140ec682fed150548c4b87d

--001a1140ec682fed150548c4b87d
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 17, 2017 at 5:03 PM, John Levine  wrote:

> In article  mail.gmail.com> you write:
> >I know this approach is controversial, so I'm also very curious to hear
> any
> >suggestions of other ways that we could fix this privacy leak without
> >slowing down everyone's connections.
>
> I have problems with the word "other".  This approach depends for its
> security on the assumption that it is hard to reverse SNI record
> lookups, that is, to find the qname(s) that have SNI records with
> given contents.
>

That was not my intent, and I don't think it's accurate.  We can consider
two cases

1. Multiple domains on the same host set the same SNI record.  Possession
of a global DNS database is no help to the adversary.  The adversary still
cannot distinguish the domains.  This is the intended use.

2. A domain sets an SNI record that is unique to that domain.  This is not
the intended use.

Case 1 is achievable whenever there are multiple domains in a certificate
(Subject Alternative Name or wildcard), with greater privacy protection as
a wider range of domains shares a certificate.

Case 2 is the only option if the domain is alone in its certificate.  In
this scenario, with current TLS, this is unavoidable.

We can certainly imagine solutions to Case 2.  For example, the SNI record
could include a public key that can be used to encrypt the SNI, e.g. RDATA
= "pubkey=".  I would strongly support such a proposal.

Implementation of such a proposal would require changes to TLS, but would
be compatible with this draft's extensibility model.  I view this draft as
a modest step toward such solutions, allowing us to separate the question
of a new DNS record from possible TLS changes.


> That is a poor assumption.  There are many large passive DNS
> databases, and a lot of people have access to them.  My working
> assumption is that anyone sophisticated enough to peek at TLS
> handshake packets is sophisticated enough to find a passive DNS
> source.
>
> So to me the question is whether the small speculative incremental
> increase in user security is worth the investment to define a new
> record type, add it to DNS servers and provisioning systems, add it to
> web server configuration languages, and set up whatever infrastructure
> is needed to coordinate the published SNI records and what the web
> servers expect.
>
> I'd also note that if the assumption is that people will publish SNI
> records through the usual registrar and dns hosting operators managed
> through web consoles, there is no chance that the webware will support
> SNI records.  We know this because they don't support any other
> RRTYPEs defined in the past decade, either.
>
> R's,
> John
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

--001a1140ec682fed150548c4b87d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Feb 17, 2017 at 5:03 PM, John Levine <johnl@taugh.com> wro=
te:
In article <CAHbrMsA278usgFNzxhrsLS6_EfXPeMoAKN65ec0YhCW93oKNYg@mail.gm=
ail.com> you write:

>I know this approach is controversial, so I'm also very curious to =
hear any

>suggestions of other ways that we could fix this privacy leak without
>slowing down everyone's connections.



I have problems with the word "other".=C2=A0 This approach=
 depends for its

security on the assumption that it is hard to reverse SNI record

lookups, that is, to find the qname(s) that have SNI records with

given contents.

That was not my intent,=
 and I don't think it's accurate.=C2=A0 We can consider two cases

1. Multiple domains on the same host set the same S=
NI record.=C2=A0 Possession of a global DNS database is no help to the adve=
rsary.=C2=A0 The adversary still cannot distinguish the domains.=C2=A0 This=
 is the intended use.

2. A domain sets an SNI reco=
rd that is unique to that domain.=C2=A0 This is not the intended use.
=


Case 1 is achievable whenever there are multiple domain=
s in a certificate (Subject Alternative Name or wildcard), with greater pri=
vacy protection as a wider range of domains shares a certificate.

Case 2 is the only option if the domain is alone in its cer=
tificate.=C2=A0 In this scenario, with current TLS, this is unavoidable.

We can certainly imagine solutions to Case 2.=C2=A0 =
For example, the SNI record could include a public key that can be used to =
encrypt the SNI, e.g. RDATA =3D "pubkey=3D<base64 encoded key>&q=
uot;.=C2=A0 I would strongly support such a proposal.

<=
div>Implementation of such a proposal would require changes to TLS, but wou=
ld be compatible with this draft's extensibility model.=C2=A0 I view th=
is draft as a modest step toward such solutions, allowing us to separate th=
e question of a new DNS record from possible TLS changes.




That is a poor assumption.=C2=A0 There are many large passive DNS

databases, and a lot of people have access to them.=C2=A0 My working

assumption is that anyone sophisticated enough to peek at TLS

handshake packets is sophisticated enough to find a passive DNS

source.



So to me the question is whether the small speculative incremental

increase in user security is worth the investment to define a new

record type, add it to DNS servers and provisioning systems, add it to

web server configuration languages, and set up whatever infrastructure

is needed to coordinate the published SNI records and what the web

servers expect.



I'd also note that if the assumption is that people will publish SNI
records through the usual registrar and dns hosting operators managed

through web consoles, there is no chance that the webware will support

SNI records.=C2=A0 We know this because they don't support any other
RRTYPEs defined in the past decade, either.




R's,

John



_______________________________________________

DNSOP mailing list

DNSOP@ietf.org

https://www.ietf.org/mailman/listinfo/dnsop





--001a1140ec682fed150548c4b87d--

--001a1140ec6834b3380548c4b85c
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
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMdhJKC5aeSlGRk8YNMA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDIxNjE4MDA1NVoXDTE3MDgx
NTE4MDA1NVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC8JMN/Ya86Mmyv36dxJwPZXCrBZx8Hi0G6muYM3u+QThV/mu6B
MpT3gEisJW8pU6iVPzxumyU7mDMwW8eshDTny91C+hTAP+cu1t4eIAmAZuNvXNd//DdmXOHvQvOU
2rH7+wTEYN0lvlSFydes0gud9VWl2hMTayncmyloIefNk/6lc2LRqw2geNw50jN1VqFpNMoxBOAp
R+qJHuzxnanR4m3K1ujYUIeOUjLMFE4VxsOBtuF1FDx+SoXj18NpQyfioGPDXAgOIIE6PS244eZE
0De/SF3kvRf0AyCSrX102ZNu7i0L6Bb7P3bIDA0NB5uV5UNa2bBpuXq69gX07F/pAgMBAAGjggFu
MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB
BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j
cnQwHQYDVR0OBBYEFB6zCsWx7DJYdsxPym0ajAsc2DNCMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz
IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v
d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j
cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAckYJsVmfrg36lwFYD
oepVYSEb0nhq9Y2/3T+cTKK/MCaU1oIRZ7LjmeFxkmA27jTy29y8+X+k5w9+I2E5vDI4D52vlKT+
FaouZnHGy1/oKZtUhMqjVn+DyEFdo1vOkir5R7cbxCK2QukpLQOb+RvzU5mOAYvwLgqn21yrcqBc
3pcYh4NlREjPe455gpwJl0d5TvYSCXEDUBXcWV7Bic7oVuPR0zXGsHQRQN7hkQsuEpwH0RhmaB/a
GVYPktJvahNnk7JYoU8eRu7xwwA35VaXbUAuJCMq3UxAgBB59guHTeLZK9PSn0FqFo4sN12g4lsv
ivmunuxPsD/Ozdn6yxtfMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv
YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMdhJKC5ae
SlGRk8YNMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBCjMlz1BvQb7Lw4jzxfRzV
psvAKzaqY96rIR+g5b8VuDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNzAyMTgwMjIzNDRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB
FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg
hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAKTEjSCdUY+kiv82fiNgyxjAAlbHYv1lTOL5+AZID
e8EljbA6b1MToJfjz8JiskIchFNhy6fytTohdQPJB6iUbUzPiM1cS9SfPui9WLLYkVapQXLzBXb2
gK5/ld76r//4j7nB4R00HQEP6GKUGWbMa30XLJrIr15e0Fw78u9pctkfW8Kx0OvySXfgw9x6ZY9q
ePJ8dymivfg7rd2dGtId7SPwWkd9bv0XdnmNG/A6OVKcXZPcWfTi3zi9iMrWOBhHpI2uJjK6aTuC
ITtplMwsQ1Zw72KYd6kXmQogDSlRjHTaLNR2SZV1LEtiFOqZoytSAlgFzgjOGYyc31S5armiaw==
--001a1140ec6834b3380548c4b85c--


From nobody Fri Feb 17 18:37:40 2017
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2E51296D4 for ; Fri, 17 Feb 2017 18:37:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 SxRO3Xmii-t8 for ; Fri, 17 Feb 2017 18:37:37 -0800 (PST)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 AF6EE1296D2 for ; Fri, 17 Feb 2017 18:37:37 -0800 (PST)
Received: by mail-it0-x229.google.com with SMTP id g67so29420754itb.1 for ; Fri, 17 Feb 2017 18:37:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RIYYsSeLZTH9UfJ4LfJuIbChktcFz9NqdiG/+H7jR+8=; b=MvWCDomUyLfyOoqC6YOunJ7Ph+y0zicVivc2FBKOW7egNAwngSOJiVMtwZh8MXknsB 1uBViGsAlP7PpmjmPwpWmS4Lvzl2MXbf7KumR7Sdavh2faDNn7uw8C2cSMBCC1O7B3il H4VJqsraXGKkyqTUIu2csB+FCTJOGldnnmy7TIf6iEwd1pw43bID45xVOWSOI7uldJ3M YfqY9sEESNR50EthgSy97IpIc//+q0fcOkKdGzSwhIvIxtdHoY63UrmnjENEJFPGLblA unjjTfsQvuKPNT3R+gKil+wXcumqb65/4uc+8Qymqc4dN6KHmfNrJynEN2o2K0EiSHx0 XImQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RIYYsSeLZTH9UfJ4LfJuIbChktcFz9NqdiG/+H7jR+8=; b=X1BcBU02Im81B5MdeEPfViJ3jUCyaBQSIbgn+ZwW4W2rTQMJM2JHt2AcwR4OwFORLD cAwMX5Y+MmWF60vrInoovw2f4xEiI3jD0xFYba/OOrsrLaCtVF7J+F1QkKF0Ahf/ZIxH i3F7RNuoYGwcV5Kc2FqTDRDOCrpDDHEqA/fT8chD26K1TQW6FOXrxcwGOmCLYUW62k3C rNS20Ps1ARfp1GfGMdKjjqDRtKYnFy1vGFaKml0EAHaIQPpQaxrrJgXlaXxrSbDR1HQP HHTfFL/5fRW5MRa2WqfpyRo0JPKedVEes8g+3gnGlZAvwYscq8ljqBvwAdoTAljEA52h 6PLQ==
X-Gm-Message-State: AMke39lt+qotWp74bfcARu6e9iCocZNCulwX5OmT4MWVZwYVM8tthg7XWAWSMMNDnPAwY8lmY2GvdLKWZHEsR0Ny
X-Received: by 10.36.196.8 with SMTP id v8mr7613516itf.115.1487385456893; Fri, 17 Feb 2017 18:37:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Fri, 17 Feb 2017 18:37:36 -0800 (PST)
In-Reply-To: 
References:   
From: Ben Schwartz 
Date: Fri, 17 Feb 2017 21:37:36 -0500
Message-ID: 
To: Erik Nygren 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c05d0d4d246220548c4e9ed"
Archived-At: 
Cc: dnsop@ietf.org, dkg@fifthhorseman.net
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Feb 2017 02:37:40 -0000

--94eb2c05d0d4d246220548c4e9ed
Content-Type: multipart/alternative; boundary=94eb2c05d0d4cd9cf70548c4e9bf

--94eb2c05d0d4cd9cf70548c4e9bf
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 17, 2017 at 9:02 PM, Erik Nygren  wrote:

> I wrote a similar draft a few years ago which I've been considering
> resurrecting if there is interest:
>
>     https://tools.ietf.org/html/draft-nygren-service-bindings-00
>

Thanks for pointing this out, Erik!  I think a flexible binding record like
B could be a great way to solve this problem and also enable clean future
extensibility.

With the standardization of DNS over TLS, I think your binding draft might
make more sense.  Maybe it's time to revisit.

The major concerns I have about B as described there are latency and
graceful degradation.  Does this add delay to new connections?  Does it
break connections if the client is behind a resolver that silently drops
all queries other than "A"?  My impression is that, for a new record to be
widely usable, both answers must be "no".

My draft attempts to resolve both dilemmas by (1) getting a head start on
the SYNACK and (2) specifying fallback behavior if the SNI response doesn't
arrive in time, along with a strategy to minimize the impact of fallback.
Maybe those ideas could be applied to some version of B.


>
>
> One of the big challenges that at least in the web context, browsers want
> to make as few DNS lookups as possible prior to making HTTP requests.
> (For example, some home gateways choke if too many requests are
> outstanding.)
> Having to lookup both A and AAAA is already a problem.  So if we're going
> to add
> something, ideally we'd add something that was extensible that could be
> used
> for multiple purposes.
>
> For this case, the result could be something like:
>
> _https._b.www.example.com IN B 2 0 www.example.com. { "alpn": "h2", "tls-sni": "SOME_TOKEN", "hsts": true }
> _https._b.www.example.com IN B 1 0 www-alt.example.com. { "alpn": "quic352", "tp": 443, "tls-sni": "SOME_OTHER_TOKEN", "hsts": true }
>
> By adding this one single lookup, you both get to specify an alternate SNI,
> be able to force HTTPS-only, and specify Alternative Services (ala rfc7838
> but allowing it to be done in DNS).  Having an extensible model here also
> increases
> the value of a client doing the lookup as once the records exist other
> optional
> attributes can be added in.
>
> (Ignore the specific key/value pair examples in that expired I-D.  They
> made more
> sense when some other things were being considered.)
>
> Based on our extensive discussions in the TLS WG over the past few years,
> introducing something like this into the DNS to indicate an alternate SNI
> value
> (which might be one shared with many other hostnames) or telling the
> client
> not to send an SNI value seemed to be one of the best ways to help with
> the SNI privacy problems, at least once there is a DNS privacy path.
>
> For example, for a cert like *.example.com (perhaps with lots of other
> SANs as well)
> there is no reason the client needs to send "something-potentially-
> private.example.com" when sending
> an SNI value of "wildcard.example.com" would do just fine.  The TLS
> handshake
> is too late to learn this, but if we could move it into the DNS then
> clients
> could learn it (and potentially other useful info) before connecting.
>
> [I added DKG as he was a strong advocate of doing something in this space
> for signalling TLS SNI omission, alteration, or aliasing in DNS records.]
>
>              Erik
>
>
>
>
> On Fri, Feb 17, 2017 at 3:49 PM, Ben Schwartz  wrote:
>
>> Thanks for the input everyone!  Here's an updated version with some
>> clarifications based on your feedback:
>> https://tools.ietf.org/html/draft-schwartz-dns-sni-02
>>
>> Diff:
>> https://www.ietf.org/rfcdiff?url1=draft-schwartz-dns-sni-01&
>> url2=draft-schwartz-dns-sni-02
>>
>> I know this approach is controversial, so I'm also very curious to hear
>> any suggestions of other ways that we could fix this privacy leak without
>> slowing down everyone's connections.  As a friend put it: if everyone can
>> see you're reading justinbieber.tumblr.com, "that defeats the whole
>> point of HTTPS".
>>
>> On Tue, Feb 14, 2017 at 1:02 PM, Ben Schwartz  wrote:
>>
>>> Hi dnsop,
>>>
>>> I've written a draft proposal to improve the privacy of TLS connections,
>>> by letting servers use the DNS to tell clients what SNI to send.
>>>
>>> https://tools.ietf.org/html/draft-schwartz-dns-sni-01
>>>
>>> I've incorporated some helpful feedback [1] from the TLS WG, but now I
>>> could use your help analyzing the DNS side. All comments welcome; this
>>> draft will change based on your feedback.
>>>
>>> One particular issue that I could use advice on: should this be a new
>>> record type, or should it reuse/repurpose an existing type like SRV or PTR?
>>>
>>> Thanks,
>>> Ben
>>>
>>> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html
>>>
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>

--94eb2c05d0d4cd9cf70548c4e9bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Feb 17, 2017 at 9:02 PM, Erik Nygren <erik+ietf@nygren.org><=
/span> wrote:
=

I wrote a similar draft a few years ago which I=
9;ve been considering resurrecting if there is interest:

=C2=A0=C2=
=A0=C2=A0 https://tools.ietf.org/html/draft-nygren-ser=
vice-bindings-00

Thanks for pointing this out, Erik!=C2=A0 I =
think a flexible binding record like B could be a great way to solve this p=
roblem and also enable clean future extensibility.

With the standardization of DNS over TLS, I think your binding draft might=
 make more sense.=C2=A0 Maybe it's time to revisit.

The major concerns I have about B as described there are latency and =
graceful degradation.=C2=A0 Does this add delay to new connections?=C2=A0 D=
oes it break connections if the client is behind a resolver that silently d=
rops all queries other than "A"?=C2=A0 My impression is that, for=
 a new record to be widely usable, both answers must be "no".

My draft attempts to resolve both dilemmas by (1) get=
ting a head start on the SYNACK and (2) specifying fallback behavior if the=
 SNI response doesn't arrive in time, along with a strategy to minimize=
 the impact of fallback.=C2=A0 Maybe those ideas could be applied to some v=
ersion of B.
=C2=A0


One of the big=
 challenges that at least in the web context, browsers want
to mak=
e as few DNS lookups as possible prior to making HTTP requests.
(F=
or example, some home gateways choke if too many requests are outstanding.)=

Having to lookup both A and AAAA is already a problem.=C2=A0 So i=
f we're going to add
something, ideally we'd add something=
 that was extensible that could be used 
for multiple purposes.
For this case, the result could be something like:
_https._b.www.example.com IN B 2 0 www.example.com. { "alpn"=
;: "h2", "tls-sni": "SOME_TOKEN", "hsts&=
quot;: true }
_https._b.www.example.com IN B 1 0 www-alt.example.com. { "alpn": "quic35=
2", "tp": 443, "tls-sni": "SOME_OTHER_TOKEN&q=
uot;, "hsts": true }=C2=A0
By adding this one single lookup, you both get to specify an alternat=
e SNI,
be able to force HTTPS-only, and specify Alternative Services (al=
a rfc7838
but allowing it to be done in DNS).=C2=A0 Having an extensible=
 model here also increases
the value of a client doing the lo=
okup as once the records exist other optional
attributes can =
be added in.

(Ignore the specific key/value pair examples=
 in that expired I-D.=C2=A0 They made more
sense when some ot=
her things were being considered.) 

Based on o=
ur extensive discussions in the TLS WG over the past few years,
introducing something like this into the DNS to indicate an alternate SN=
I value
(which might be one shared with many other hostnames)=
 or telling the client 
not to send an SNI value seemed to be one of the=
 best ways to help with 
the SNI privacy problems, at least o=
nce there is a DNS privacy path.

For example, for a cert =
like *.example.com (pe=
rhaps with lots of other SANs as well)
there is no reason the client nee=
ds to send "something-potentially-private.example.com&quo=
t; when sending
an SNI value of "wildcard.example.com" would do =
just fine.=C2=A0 The TLS handshake
is too late to learn this,=
 but if we could move it into the DNS then clients
could lear=
n it (and potentially other useful info) before connecting.
<=
br>
[I added DKG as he was a strong advocate of doing something i=
n this space
for signalling TLS SNI omission, alteration, or =
aliasing in DNS records.]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Erik




On Fri, Feb 17, 2017 at 3:49 PM, Ben S=
chwartz <bemasc@google.com> wrote:
Thanks for t=
he input everyone!=C2=A0 Here's an updated version with some clarificat=
ions based on your feedback:

Diff:

I know this approach is contr=
oversial, so I'm also very curious to hear any suggestions of other way=
s that we could fix this privacy leak without slowing down everyone's c=
onnections.=C2=A0 As a friend put it: if everyone can see you're readin=
g justinbieber=
.tumblr.com, "that defeats the whole point of HTTPS".

On Tue=
, Feb 14, 2017 at 1:02 PM, Ben Schwartz <bemasc@google.com> =
wrote:
Hi dnsop,

I've written a draft proposal to improve the pri=
vacy of TLS connections, by letting servers use the DNS to tell clients wha=
t SNI to send.

http=
s://tools.ietf.org/html/draft-schwartz-dns-sni-01

I've incorporated some helpful feedback [1] from the TLS WG, but now=
 I could use your help analyzing the DNS side. All comments welcome; this d=
raft will change based on your feedback.

One parti=
cular issue that I could use advice on: should this be a new record type, o=
r should it reuse/repurpose an existing type like SRV or PTR?






______________________________=
_________________

DNSOP mailing list

DNSOP@ietf.org

https://www.ietf.org/mailman/listinfo/dnsop








--94eb2c05d0d4cd9cf70548c4e9bf--

--94eb2c05d0d4d246220548c4e9ed
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
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMdhJKC5aeSlGRk8YNMA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDIxNjE4MDA1NVoXDTE3MDgx
NTE4MDA1NVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC8JMN/Ya86Mmyv36dxJwPZXCrBZx8Hi0G6muYM3u+QThV/mu6B
MpT3gEisJW8pU6iVPzxumyU7mDMwW8eshDTny91C+hTAP+cu1t4eIAmAZuNvXNd//DdmXOHvQvOU
2rH7+wTEYN0lvlSFydes0gud9VWl2hMTayncmyloIefNk/6lc2LRqw2geNw50jN1VqFpNMoxBOAp
R+qJHuzxnanR4m3K1ujYUIeOUjLMFE4VxsOBtuF1FDx+SoXj18NpQyfioGPDXAgOIIE6PS244eZE
0De/SF3kvRf0AyCSrX102ZNu7i0L6Bb7P3bIDA0NB5uV5UNa2bBpuXq69gX07F/pAgMBAAGjggFu
MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB
BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j
cnQwHQYDVR0OBBYEFB6zCsWx7DJYdsxPym0ajAsc2DNCMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz
IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v
d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j
cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAckYJsVmfrg36lwFYD
oepVYSEb0nhq9Y2/3T+cTKK/MCaU1oIRZ7LjmeFxkmA27jTy29y8+X+k5w9+I2E5vDI4D52vlKT+
FaouZnHGy1/oKZtUhMqjVn+DyEFdo1vOkir5R7cbxCK2QukpLQOb+RvzU5mOAYvwLgqn21yrcqBc
3pcYh4NlREjPe455gpwJl0d5TvYSCXEDUBXcWV7Bic7oVuPR0zXGsHQRQN7hkQsuEpwH0RhmaB/a
GVYPktJvahNnk7JYoU8eRu7xwwA35VaXbUAuJCMq3UxAgBB59guHTeLZK9PSn0FqFo4sN12g4lsv
ivmunuxPsD/Ozdn6yxtfMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv
YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMdhJKC5ae
SlGRk8YNMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCpxfFn29CG/d5+GotgysdT
NPFQUmimTa4ycfix0emnBzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNzAyMTgwMjM3MzdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB
FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg
hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAkLT4+5f3PCtYx4Z870fTPE/R00NJCbMgKzVZFFCX
SF2dWEzmPCBkgagmf/vdDQ1xH07AOuYQXGYdHjnapLQKwQs1lnrjpTyOGYk1Ey7yaElPcqtV6L8p
s/AYjhhsfwJc9lBROVbHeeEsj0XJcxU0NDXyu8lqIUNF1rMQ1yH10ZmO2B+ruz0/ja+XrLJ9MJm2
EhakvcxjtGy3Uu4hlC6jXy/WIAtuk11Ux6Ubf1PvFU3qSfcSgrI31Gs4LlYctI/5TKQuQio6Xw2o
QWFxhwFDsVnHGeZRogkbpsZakrItAMw0Qj+r4Fr7bOftErXIWlA0UfXw0p1ISRSipnY2Tvqj2Q==
--94eb2c05d0d4d246220548c4e9ed--


From nobody Fri Feb 17 18:47:34 2017
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C9B1293E3 for ; Fri, 17 Feb 2017 18:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=cqs0NYso; dkim=pass (1536-bit key) header.d=taugh.com header.b=TyAIJKJL
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 IxRXwUFqpehD for ; Fri, 17 Feb 2017 18:47:32 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5073E1289B0 for ; Fri, 17 Feb 2017 18:47:32 -0800 (PST)
Received: (qmail 9144 invoked from network); 18 Feb 2017 02:47:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=23b5.58a7b5c3.k1702; bh=SOqwric9nghHSa66e9ffdTZkekGhQWEcwwTFMEfgcBo=; b=cqs0NYsoMo0ui/05dNr8XCQC5UJ9nbaR0pvSfjBmRsbWtcO1JL7AO5xTQ/Y4Lf1KpFI5bVtTv835xGPYHiucMo59sg7eI2sYcn/Iw5dtdLNwzUYv8GO7eN/90Zo0C86csMxC5nepSEy16QvJHr2AE6igpuwHyAlCC7JuDVDW27eDNC4m0lyBQZCuw4bdUlD9C7CGI6zeiY4vp9CMUgQqu+BWlWklTqLdihdlwcAgBTArekIDK/3hjpD9OJ2slTGV
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=23b5.58a7b5c3.k1702; bh=SOqwric9nghHSa66e9ffdTZkekGhQWEcwwTFMEfgcBo=; b=TyAIJKJL1JYVsNbp370Ua+vvUKrSzIXx1TlgZFD5r/nDqgzqlsLbwZqhXD3x/h02toAommLzy7XkDfl32WKVunF8KAtOAFZSZjX14iJTFZlf6nwiXH/IS6kCNY44q6H8ZM5YCS5dGzb1NVDqu67vFxyvQy2Af1nqPz4NdjpYItk1TAGU7lyZqH/l00KJ5qMqbcodCg4YJJEDVALrxmIPBsOPUu3fkWeKW4GnPyZqHfyn+6eCFU8M36MghVlByUCe
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 18 Feb 2017 02:47:31 -0000
Date: 17 Feb 2017 21:47:30 -0500
Message-ID: 
From: "John R Levine" 
To: "Ben Schwartz" 
In-Reply-To: 
References:  <20170217220309.9637.qmail@ary.lan> 
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Feb 2017 02:47:34 -0000

> 1. Multiple domains on the same host set the same SNI record.  Possession
> of a global DNS database is no help to the adversary.  The adversary still
> cannot distinguish the domains.  This is the intended use.

Now I'm really confused.  If the SNI value is just a cover name, and the 
client's going to send the real name later, why not just pick a fixed 
impossible cover name like SNI.INVALID and skip the SNI lookup?

Presumably if this became at all popular, everyone will send SNI.INVALID 
so it wouldn't leak anything interesting.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Fri Feb 17 19:41:33 2017
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB977129463 for ; Fri, 17 Feb 2017 19:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 v9xtJqrbMNy2 for ; Fri, 17 Feb 2017 19:41:31 -0800 (PST)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 11D3C120727 for ; Fri, 17 Feb 2017 19:41:31 -0800 (PST)
Received: by mail-it0-x22a.google.com with SMTP id g67so29747378itb.1 for ; Fri, 17 Feb 2017 19:41:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D5hGo+M/RFk3l2C5kUWjcKpGf5H4OYNdf2mt4yGGV/k=; b=Qo+irajc3sB8y03rjSJv6Ei1my2VZU7O2aFEs4Sk0viUjYIhUdMpDkBeNQ6Iwl8gJa r4k63BwvBiK4RsSEDRvsmrdACJmh9bLwolo0FmIJHbyzCEseGnoGRMRtH6sr/4YInZTZ mSNhN70pwhl92XNhPJUXlXBoZye8gVV8RLRCQshbp3KXjOX++Tw0RXOHQ8Q34dV1poE5 jPQ1dsUdzmmDkmvn5KtloB6sOnsSYa+6aG8ZmhIrT/02fUvy1Kng9QhXAhMuBu/d1Anc yNJu4nNdbxUQaEKiLgqfq2PmiKVDzBRC52zvUxoVz4SAm00PZe9457lCnpev3QGmkCMU uHTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D5hGo+M/RFk3l2C5kUWjcKpGf5H4OYNdf2mt4yGGV/k=; b=EjHWu7EdP6/E0IVteiRr4QtUpKH688iznFbHgYODNN4tgfzA2Tmp5cj/1IG35b8rWp ha1RiS+nw9HCSx6Psc+GErR1WJ07aKsbTFBEc1gsjKVCGG9gHR7bmiqVTQ6skdUYENBM tb0BdqS2P6dTR5mOttGKAo+Cg12LgYa/8nsW0yJOV1WF83YS4DDyJxjUNTP4QHr7L6wX jp43+x0q+vLCSIGMWCn1CRAncZBv0tsGpn/evI1EjvyXpMqGEjOIJGgdEG6ogQyWhyT5 DVjKMARyMO4NaZjrz77AWj7cT23HkB5kVvQH5VmoLAZyKhL+w+2Od4UcRhf42WfQ/jxq HYLA==
X-Gm-Message-State: AMke39mOlzj23U6OUGfdgj2FRPo1QU2vo6OvFB5XsLuDLXaj4hZGCWGd2eyJG6jbG4757HAYseni4o43ldhu8Vz8
X-Received: by 10.36.25.83 with SMTP id b80mr4767221itb.98.1487389290208; Fri, 17 Feb 2017 19:41:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Fri, 17 Feb 2017 19:41:29 -0800 (PST)
In-Reply-To: 
References:  <20170217220309.9637.qmail@ary.lan>  
From: Ben Schwartz 
Date: Fri, 17 Feb 2017 22:41:29 -0500
Message-ID: 
To: John R Levine 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114401824e292b0548c5ce5e"
Archived-At: 
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Feb 2017 03:41:33 -0000

--001a114401824e292b0548c5ce5e
Content-Type: multipart/alternative; boundary=001a1144018249829b0548c5cec7

--001a1144018249829b0548c5cec7
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 17, 2017 at 9:47 PM, John R Levine  wrote:

> 1. Multiple domains on the same host set the same SNI record.  Possession
>> of a global DNS database is no help to the adversary.  The adversary still
>> cannot distinguish the domains.  This is the intended use.
>>
>
> Now I'm really confused.  If the SNI value is just a cover name, and the
> client's going to send the real name later, why not just pick a fixed
> impossible cover name like SNI.INVALID and skip the SNI lookup?
>

In that case, one would simply omit the SNI, since it is optional.  The
draft specifies that an empty RDATA instructs the client to omit the SNI.
Currently, most TLS servers do not require SNI at all, so this will often
work ... but there's no way for the client to know ahead of time if it's
safe to omit, so the clients always include it.

The reason to allow non-empty RDATA is to support servers that serve
multiple multi-domain certificates from a single IP address, dispatched by
SNI.  This is common on CDNs and other large internet serving systems.


> Presumably if this became at all popular, everyone will send SNI.INVALID
> so it wouldn't leak anything interesting.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>

--001a1144018249829b0548c5cec7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Feb 17, 2017 at 9:47 PM, John R Levine <johnl@taugh.com> w=
rote:

1. Multiple domains on the same host set the same SNI record.=C2=A0 Possess=
ion

of a global DNS database is no help to the adversary.=C2=A0 The adversary s=
till

cannot distinguish the domains.=C2=A0 This is the intended use.





Now I'm really confused.=C2=A0 If the SNI value is just a cover name, a=
nd the client's going to send the real name later, why not just pick a =
fixed impossible cover name like SNI.INVALID and skip the SNI lookup?

In that case, one would simply omit the SNI,=
 since it is optional.=C2=A0 The draft specifies that an empty RDATA instru=
cts the client to omit the SNI.=C2=A0 Currently, most TLS servers do not re=
quire SNI at all, so this will often work ... but there's no way for th=
e client to know ahead of time if it's safe to omit, so the clients alw=
ays include it.

The reason to allow non-empty RDAT=
A is to support servers that serve multiple multi-domain certificates from =
a single IP address, dispatched by SNI.=C2=A0 This is common on CDNs and ot=
her large internet serving systems.




Presumably if this became at all popular, everyone will send SNI.INVALID so=
 it wouldn't leak anything interesting.



Regards,

John Levine, johnl@tau=
gh.com, Taughannock Networks, Trumansburg NY

Please consider the environment before reading this e-mail. https://jl.ly





--001a1144018249829b0548c5cec7--

--001a114401824e292b0548c5ce5e
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
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMdhJKC5aeSlGRk8YNMA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDIxNjE4MDA1NVoXDTE3MDgx
NTE4MDA1NVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC8JMN/Ya86Mmyv36dxJwPZXCrBZx8Hi0G6muYM3u+QThV/mu6B
MpT3gEisJW8pU6iVPzxumyU7mDMwW8eshDTny91C+hTAP+cu1t4eIAmAZuNvXNd//DdmXOHvQvOU
2rH7+wTEYN0lvlSFydes0gud9VWl2hMTayncmyloIefNk/6lc2LRqw2geNw50jN1VqFpNMoxBOAp
R+qJHuzxnanR4m3K1ujYUIeOUjLMFE4VxsOBtuF1FDx+SoXj18NpQyfioGPDXAgOIIE6PS244eZE
0De/SF3kvRf0AyCSrX102ZNu7i0L6Bb7P3bIDA0NB5uV5UNa2bBpuXq69gX07F/pAgMBAAGjggFu
MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB
BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j
cnQwHQYDVR0OBBYEFB6zCsWx7DJYdsxPym0ajAsc2DNCMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz
IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v
d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j
cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAckYJsVmfrg36lwFYD
oepVYSEb0nhq9Y2/3T+cTKK/MCaU1oIRZ7LjmeFxkmA27jTy29y8+X+k5w9+I2E5vDI4D52vlKT+
FaouZnHGy1/oKZtUhMqjVn+DyEFdo1vOkir5R7cbxCK2QukpLQOb+RvzU5mOAYvwLgqn21yrcqBc
3pcYh4NlREjPe455gpwJl0d5TvYSCXEDUBXcWV7Bic7oVuPR0zXGsHQRQN7hkQsuEpwH0RhmaB/a
GVYPktJvahNnk7JYoU8eRu7xwwA35VaXbUAuJCMq3UxAgBB59guHTeLZK9PSn0FqFo4sN12g4lsv
ivmunuxPsD/Ozdn6yxtfMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv
YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMdhJKC5ae
SlGRk8YNMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCC2KYSQo9Cp49IwHFFxU9l1
F/1fI+wc1iir3IWDSvRsSDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNzAyMTgwMzQxMzBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB
FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg
hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAnu5TaUq0ZuIJbGC17gDibOjJU0gyUGuYZEECvP/v
eVgmoQt0Q6EPkePlsvpxrhiBL8HtfcQzH+1oiz24sq3LPEldo7sMjjjo4bzhhwM3XQKr2MqTtgXE
GesU1W8Q0eMDAg3KQGyd8osd7np12gXJaHnp3+2Mb4zquAV3yzAGrUsPUY67opRgm7J5c2/HjhfP
NAZkXnpjLU3k62fXmWAn4eRB7itEbbYVGcsgvC96m4lJOlVurz/aJlzC/iGj1PGrdx9HJdQ4mrfd
Oz443M4GGj60WH3+npSoll1XJ/UF7LdZ42ZRqAz4SbluoTvuqVzKqMowoIMLBcMj7z+JZZG9yA==
--001a114401824e292b0548c5ce5e--


From nobody Sun Feb 19 07:25:05 2017
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8B912949B for ; Sun, 19 Feb 2017 07:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001,  URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=jS15+V54; dkim=pass (1536-bit key) header.d=taugh.com header.b=RSJHvWPj
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 6kOMZOmoOUxt for ; Sun, 19 Feb 2017 07:25:01 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44AAC129466 for ; Sun, 19 Feb 2017 07:25:01 -0800 (PST)
Received: (qmail 89024 invoked from network); 19 Feb 2017 15:25:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15bbe.58a9b8cc.k1702; bh=NJAFofH1ZjmsuHVikW7E1jm9K38BzSC+Tqc9pmlaFKk=; b=jS15+V54khYqLIP02/lX78b0R8f2pxLJITT29DJZSCuDWi822Em+lyNPpD8uGSJrKRCsc6tVQkZJ3UDXutE67eSu8rLmAcCtQNx2TFmeFdz0jhN95olUKzpKMmrxGWH5z1sMcFXE0XCfK0rz5ePuoIQvu/CXyY/1xbui67xtnBLA6MQQ+A1k/23qHl1Y4ckuDkmuzlpA28yjKoGMPOHVwzsAA8nHchuhDzvYqRI3V1IgLfIk3ay+UO7rTDuwxWP4
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15bbe.58a9b8cc.k1702; bh=NJAFofH1ZjmsuHVikW7E1jm9K38BzSC+Tqc9pmlaFKk=; b=RSJHvWPjWDby+yFul96O+OdHuJaKu6WnR242D3pM4+Y/hHyJMzrsMwzlnFgWGyufasCaDl81/f4Bru0Ny1tcBfdxjxGokkOHByzMjFqhrijihy6iy/qOB9BKdBrPf/c5YaBFqpANyrdDAI3UA46iz9dlKDb74p0mffQ0zteLqcTILbWqsoutMI2r4/RoFwAB6pX/7oTAcuUrWYPUbxlBM69Jh46Us4Gbuv37REmwHWtfgYOm6gqge82DcjDBDJC9
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 19 Feb 2017 15:25:00 -0000
Date: 19 Feb 2017 10:24:59 -0500
Message-ID: 
From: "John R Levine" 
To: "Ben Schwartz" 
In-Reply-To: 
References:  <20170217220309.9637.qmail@ary.lan>   
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: 
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Feb 2017 15:25:03 -0000

> The reason to allow non-empty RDATA is to support servers that serve
> multiple multi-domain certificates from a single IP address, dispatched by
> SNI.  This is common on CDNs and other large internet serving systems.

Oh, OK, that's helpful.

So the use case is a web server that serves a zillion domains, with the 
domains grouped into clusters that share a certificate.  For each cluster, 
you pick one of the names as the cover name, and the SNI points to that
name.  The cover name doesn't have to be in the DNS, but if it's not, that 
makes it stick out like a sore thumb.

Passive DNS on the server's IP address will reveal all of the server's 
names, and probes on those names to get the certs will reveal which names 
are in which cluster, so all SNI reveals is which names are the cover 
names.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Sun Feb 19 12:14:26 2017
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB57C12953D for ; Sun, 19 Feb 2017 12:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.451
X-Spam-Level: 
X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, SPF_PASS=-0.001, URIBL_BLOCKED=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 ol3gyMbe4YDd for ; Sun, 19 Feb 2017 12:14:23 -0800 (PST)
Received: from mail01.sigterm.no (mail01.sigterm.no [193.150.121.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A6612950B for ; Sun, 19 Feb 2017 12:14:22 -0800 (PST)
Received: from smtp.postman.i2p (unknown [193.150.121.26]) by postman.meeh.i2p (Postfix) with ESMTP id EDAD52E0F3A for ; Sun, 19 Feb 2017 21:14:19 +0100 (CET)
X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: str4d 
To: dnsop@ietf.org
References:   <9F197C8D-77F6-430F-8D71-B338BFB998EB@gmail.com> <20170216174816.088AFADF00@smtp.postman.i2p>
MIME-Version: 1.0
In-Reply-To: <20170216174816.088AFADF00@smtp.postman.i2p>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NhicTrIGxtLkRiS8lsNqMnU4oSbH1FR55"
Message-Id: <20170219184747.2D6D6ADF17@smtp.postman.i2p>
Date: Sun, 19 Feb 2017 18:47:47 +0000 (UTC)
Archived-At: 
Subject: Re: [DNSOP] [Ext] Re: Ed's comment s on Re: WGLC for draft-ietf-dnsop-sutld-ps
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Feb 2017 20:14:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--NhicTrIGxtLkRiS8lsNqMnU4oSbH1FR55
Content-Type: multipart/mixed; boundary="oScvaxEThgnda1opSDnnhmxhKJs41KdcR";
 protected-headers="v1"
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: str4d 
To: dnsop@ietf.org
Subject: Re: [DNSOP] [Ext] Re: Ed's comment s on Re: WGLC for
 draft-ietf-dnsop-sutld-ps
References: 
 
 <9F197C8D-77F6-430F-8D71-B338BFB998EB@gmail.com>
 <20170216174816.088AFADF00@smtp.postman.i2p>
In-Reply-To: <20170216174816.088AFADF00@smtp.postman.i2p>

--oScvaxEThgnda1opSDnnhmxhKJs41KdcR
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 02/17/2017 06:48 AM, Edward Lewis wrote:
> On 2/16/17, 12:23, "Suzanne Woolf"  wrote:
> On Feb 16, 2017, at 11:46 AM, Russ Housley  wrote=
:
> Ed:=20
>>>> It would be good to provide a list of requests for new special use n=
ames.
>>>> Especially for a problem statement, this provides a way to estimate =
the=20
>>>> "size and shape" of the problem and the urgency.
> (Russ:)
>>> No matter how you count, the volume will remain small if this is done=
=20
>>> properly.  However, the special name requests can still be=20
>>> important and urgent.
> (Suzanne:)
>> I also note it=92s fairly difficult to estimate.=20
>>
>> ... .home/.corp/.mail ... .onion ... .alt ... .homenet=20
>=20
> There is also a use of .id by Blockstack? as opposed to the ccTLD for I=
ndonesia.  (This one just jumps to mind.)
>=20
> I did some looking and despite thinking there was once a backlog of a d=
ozen, I haven't come across it in the mailing list.  (I could be wrong.) =
 What about .belkin, often cited as a string seen but not allocated?

You missed the ones that started all the drama ;P

- .gnu
- .zkey
- .exit
- .i2p
- .bit

>=20
> My goal is to see the problem statement document get more detailed so w=
e can know when we've solved the problem.  ("The problem" is meant to be =
general, not necessarily the problem at hand.)
>=20
>> All of the drafts besides those for .onion, .alt, and .homenet have ex=
pired, which tells us nothing about whether or how they might come back.
>=20
> I don't think liveness of drafts is a sufficient measure of activity, c=
onsidering the problem statement talks about uses from folks not engaging=
 in the IETF process.  (If I'm hungry and in line at a restaurant, then w=
alk away because the wait is too long, I'm still hungry.)

+1. I have a vested interest in the outcome of this discussion (being
involved in a relevant project), and offered to participate in the
problem statement design process. But with the significant general
headwind around the former, and never hearing back about the latter, I
decided my time was better spent on other things.

Also note that for at least some of these drafts, their inactivity and
expiry likely stems from the very loud "We are freezing the 6761 process
indefinitely" announcement. I doubt anyone outside of the existing IEFT
community would be willing to spend time working on a 6761-dependent
draft without knowing whether it will even exist in future.

Cheers,
str4d



--oScvaxEThgnda1opSDnnhmxhKJs41KdcR--

--NhicTrIGxtLkRiS8lsNqMnU4oSbH1FR55
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYqehJAAoJEGppFNr76gDaXQYP/10nNSARCl8X+oNRVm5czJqv
kuFteFDUmzg8FHpm+xXJvpUTHR5ggcQdPZeWqcL41IuubqesQbU2RiX9JOXZMBCO
7I+zo29uTJQgCk5P3EfpsFo/A6M+LoQSPwU118uoshyvYAbAC2u2gyBVEt8RwRKB
eXYOSRvOyfqnrzYaQg5RJqRgQifP5mGR+BSHzxwGtulLK+VkQkAnULugPZaCDdlL
oSM7sSLro9LjT07AD5RSIc60DXrJDz0uABtgGkHUm0M0jw2ak6EYyHSfQ1U2EKtF
5ibkh/6ohXLv/rBZed/gMm6Vt1eLMGKGExFUc6W01YHzsyLlsAKQ2/3xgsp1lXN0
je+VYpDMQf29Of0dXGE6dV+MjmsAMNffdpHxjcVd+S8tkrsNRmfKyXpHd/gkBePo
xfO+gvjMqESX1lXnN7KJ2UTzwwq7iedCbY9K0YQlw4DoGPpzulOmHXM/RPehilQu
6DT0wLI+FNTAECLhzMeZ2lkttiRsbhskcUtc32jYjdM08durnj93pPzhRA3o0+Jn
0ff2getOx2246bH9blKn/sV1tpxMRHPBjkJZqKbMT6UJp8h/O/6ecjHfyO527Gs0
2Vvhy039KmxkAcKuMWOlz4p4SQRo7RirIQ8xkAQKiMOAMv+WNBo+zBVHCcACfLvO
OQOHphFub8c4QfzKPUO5
=hMGW
-----END PGP SIGNATURE-----

--NhicTrIGxtLkRiS8lsNqMnU4oSbH1FR55--


From nobody Mon Feb 20 07:00:31 2017
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9EF1294D2 for ; Mon, 20 Feb 2017 07:00:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 BcMxyFFHHFW1 for ; Mon, 20 Feb 2017 07:00:28 -0800 (PST)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF95129405 for ; Mon, 20 Feb 2017 07:00:28 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:41080) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cfpRz-000TGX-iW (Exim 4.88) (return-path ); Mon, 20 Feb 2017 15:00:28 +0000
Date: Mon, 20 Feb 2017 15:00:27 +0000
From: Tony Finch 
To: Ben Schwartz 
In-Reply-To: 
Message-ID: 
References:  <20170217220309.9637.qmail@ary.lan>    
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: 
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2017 15:00:30 -0000

Would it be easier or harder, instead of adding a new SNI RRtype, to use
DANE TLSA records to identify the server's cert or key, and use a
variation of TLS SNI to request the cert by digest instead of by name?

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: West backing southwest 6 to gale 8. Rough or very rough,
becoming high later in west Bailey. Showers, then rain later. Good,
occasionally poor.


From nobody Mon Feb 20 12:39:38 2017
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2BE1294B9 for ; Mon, 20 Feb 2017 12:39:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSQxbswuNVlu for ; Mon, 20 Feb 2017 12:39:36 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 18D13129480 for ; Mon, 20 Feb 2017 12:39:36 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id v200so55146990ywc.3 for ; Mon, 20 Feb 2017 12:39:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=I5ZDvlutjMpjsP3qysM4ojF5z0pqZT/0VacMyUQh7Sg=; b=MOn9in3yqaiDOxe/oa6xGbK134OSCPtdXkchmOWuCO0bebH8VAkNcK2IWpuU83Ubdd nvoHIoQhHw8BOVkesfwFWQcqQmz7kUH3TkfEuLym0//UHZueZNdX++okj/lyc4uqhoTV SgA4C/0o62ibD/M141sG11eptpx5+FCbBv8+uwkkpDLrf1GTygdmlb1nFMIzJYzcZ/pE iNHJcRU4fV5z9haTC8BA/bfqJ62D595SrPuqSfz8p033xepYjcqIga+4UzuwoPR4gKkR /j1Tv1Vds4c44+mZxDP9Vk2uSDnIEM93GNfxBR12ubPwIpkvztLLyRdtO64i9tPC7xKJ rb6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=I5ZDvlutjMpjsP3qysM4ojF5z0pqZT/0VacMyUQh7Sg=; b=L3fjU8pdsF2I7hmnMZi/S3Sppm2cNRLbTskf8P3h5t+OxR74I2qZECW/XC2ps2idp/ lkMEkbJPePRorbwv3pq/hsJ412FnjGH0pQCqSHCFHkbblOmJWcwQnEqPrnRQWl3I5Mwn iegez+MG1rcfFNn8ldqFCfYVtR0lSqkdtMQLrTVdjFjmgf4uYAETcdEtFSMZsOql9wzd 6FFPyYNqWnGGt0JiwkPQLvB/clkp2aJuGnbjOFVtq/bPW2ETpmyiOE3z6OZgHgamxsTG hGf5ftNp8VqwG2/6dDFIucVhqdcR53LaD51V7eIRajISR2or5F1YUywYQaZiuKoaWYTs hMMw==
X-Gm-Message-State: AMke39lud/42QK+lxU1+YgL3i8QkLGEVT/C4tc+LZBMt7lVLmMG2mXqFKLZL2sAZz1TjK1nC0efxmqU2aLT8MQ==
X-Received: by 10.129.101.195 with SMTP id z186mr17060267ywb.340.1487623175295;  Mon, 20 Feb 2017 12:39:35 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.83.17.140 with HTTP; Mon, 20 Feb 2017 12:39:34 -0800 (PST)
In-Reply-To: 
References:  <20170217220309.9637.qmail@ary.lan>     
From: Phillip Hallam-Baker 
Date: Mon, 20 Feb 2017 15:39:34 -0500
X-Google-Sender-Auth: xRF5_ZZCeOrNxGJofcMKd6POttM
Message-ID: 
To: Tony Finch 
Content-Type: multipart/alternative; boundary=001a114c6c9cec6d840548fc4215
Archived-At: 
Cc: Ben Schwartz , "dnsop@ietf.org" 
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2017 20:39:38 -0000

--001a114c6c9cec6d840548fc4215
Content-Type: text/plain; charset=UTF-8

I really don't like the proposal at all. The idea of beginning the TLS
handshake in DNS is sound. But it is a completely new handshake and
authentication layer.

Right now we have a bit of a mess with service discovery. We have a solid
proposal that makes sense written up as a standard and we have a lot of
folk saying we should do something different, either for legacy reasons or
because they find it impure.

The solid proposal is as follows:

* Discover all services using SRV *without exception*

* Use TXT records to provide additional data *that is required for
discovery and binding*

* TXT records may be bound to the service definition, thus covering all
hosts or be bound to a specific host instance.

* Domain names used for services MAY use CNAME or DNAME. Domain names that
identify services MUST NOT.

* Treat everything else as legacy. Expect Port numbers to be supplanted by
SRV prefixes. Accept that TLSA is dead. Don't tilt at windmills with yet
more discovery schemes.

I see a distinction between Hosts and Services. An internet service is
defined by an SRV prefix. A Host has a unique IP address and may support
multiple services which may also share ports.

If the objective is to conceal the service name being connected to, it
follows that any key used to conceal the service negotiation must be bound
to the host rather than the service.

The protocol that these constraints points to would use a lightweight key
agreement with a client supplied nonce and a host specific DNS key to
protect the initial TLS key agreement and then feed that key as one of the
inputs into the KDF for the service level key agreement.

One bonus of this approach is that if you don't care about authentication,
you can dispense with the service authentication altogether and use
encryption based on the host encryption alone. TLS is designed to provide
service authentication that is its purpose and the reason for most of the
complexity.

--001a114c6c9cec6d840548fc4215
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I r=
eally don't like the proposal at all. The idea of beginning the TLS han=
dshake in DNS is sound. But it is a completely new handshake and authentica=
tion layer.
Right now we =
have a bit of a mess with service discovery. We have a solid proposal that =
makes sense written up as a standard and we have a lot of folk saying we sh=
ould do something different, either for legacy reasons or because they find=
 it impure.
The solid pro=
posal is as follows:

* Di=
scover all services using SRV *without exception*

* Use TXT records to provide additional data *that=
 is required for discovery and binding*

* TXT records may be bound to the service definition, thus c=
overing all hosts or be bound to a specific host instance.

* Domain names used for services MAY use=
 CNAME or DNAME. Domain names that identify services MUST NOT.=C2=A0
<=
div class=3D"gmail_default" style=3D"font-size:small">
* Treat everything else as leg=
acy. Expect Port numbers to be supplanted by SRV prefixes. Accept that TLSA=
 is dead. Don't tilt at windmills with yet more discovery schemes.

I see a distinction between H=
osts and Services. An internet service is defined by an SRV prefix. A Host =
has a unique IP address and may support multiple services which may also sh=
are ports.

=

If the objecti=
ve is to conceal the service name being connected to, it follows that any k=
ey used to conceal the service negotiation must be bound to the host rather=
 than the service.

The pr=
otocol that these constraints points to would use a lightweight key agreeme=
nt with a client supplied nonce and a host specific DNS key to protect the =
initial TLS key agreement and then feed that key as one of the inputs into =
the KDF for the service level key agreement.

One bonus of this approach is that if you don't ca=
re about authentication, you can dispense with the service authentication a=
ltogether and use encryption based on the host encryption alone. TLS is des=
igned to provide service authentication that is its purpose and the reason =
for most of the complexity.



--001a114c6c9cec6d840548fc4215--


From nobody Mon Feb 20 13:08:37 2017
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C81C1294FF for ; Mon, 20 Feb 2017 13:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 q1e3Vt0BcYe5 for ; Mon, 20 Feb 2017 13:08:34 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B002E1294B9 for ; Mon, 20 Feb 2017 13:08:34 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id 203so84246565ith.0 for ; Mon, 20 Feb 2017 13:08:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sZopbgG/Yk+qdMcXAagygEgfRnHnmxbPP50+4vLWYEk=; b=kpcesnvnkn2AoFLGtgZncNyEf0bdNl/xgjbZ3Wj3APLMYP8i51SH7zbA4LskFbkCvd OQboZn/5PHE4qq5i9iTbkPN5rLvFR93LIxosFOYzk/nxYPD5d1stms7L6OAmTmN/YdZ5 K1YvT8u63ppRayPQ/VgmDAeqllQyM0HAheGH3tAfHtLwQMTsqjMEWtfVQPzM+88Pb4Oo Cdk/MlQS3dNoMta6uyJURFBsBbNG1alN2yeAyRJEqFFSoLE5FixM+vvFVic44eFcxE4v xYErPyCfJs29ti32D4MTnBrBURHu0Xvh1yiteSgar8U8thABfcIaWyusXtMJ/5kSUane vWoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sZopbgG/Yk+qdMcXAagygEgfRnHnmxbPP50+4vLWYEk=; b=sTVwqfvrzYIClRNuYhIKcj1v7csel0X4U8ojThQQwqiAWq9hJwdbo5y3krnadpS3iw t3rHxPd9GKQm7GG9yO6pqrGwnoVYmqfmP47t4juLoPv7Ynj+Ui0HA2i16SjWSX4E1MqZ PHxYPuHyD5J2rVqUdgmmOqijafLLgpMgMYjLJVAvUBq1HUsLOL6vkqyr48/lyb0Nkkov Jm466eqs7EmXWrab5NufkUxGQJPGB58ORQixD2rfbVBzop9q+Adbg0aqJg+NZDnSIQWr +6mxCzgkNkxruyIpt9qv4IJcJ3xOR7A+tx+GM/X0LUBXuEsrq5bR48kJq0Ifz8p4DMVX F5cQ==
X-Gm-Message-State: AMke39mDjmR5O3BwjkRDC66TSJpmb7v1SXDAttOtFwzF9uebgxJnWc7UeBMMJIrqkklQVhNjT2Ruw0X0AfA/b3e4
X-Received: by 10.36.25.83 with SMTP id b80mr13404624itb.98.1487624913659; Mon, 20 Feb 2017 13:08:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Mon, 20 Feb 2017 13:08:33 -0800 (PST)
In-Reply-To: 
References:  <20170217220309.9637.qmail@ary.lan>      
From: Ben Schwartz 
Date: Mon, 20 Feb 2017 16:08:33 -0500
Message-ID: 
To: Phillip Hallam-Baker 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114401829139300548fcaa56"
Archived-At: 
Cc: Tony Finch , "dnsop@ietf.org" 
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2017 21:08:36 -0000

--001a114401829139300548fcaa56
Content-Type: multipart/alternative; boundary=001a114401828a064b0548fcaa95

--001a114401828a064b0548fcaa95
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker  wrote:

> I really don't like the proposal at all. The idea of beginning the TLS
> handshake in DNS is sound. But it is a completely new handshake and
> authentication layer.
>

What you're proposing does sound like a completely new handshake.  To be
clear, this proposal makes no change to TLS.


> Right now we have a bit of a mess with service discovery. We have a solid
> proposal that makes sense written up as a standard
>

Could you point me to which document you're referring to?


> and we have a lot of folk saying we should do something different, either
> for legacy reasons or because they find it impure.
>
> The solid proposal is as follows:
>
> * Discover all services using SRV *without exception*
>
> * Use TXT records to provide additional data *that is required for
> discovery and binding*
>
> * TXT records may be bound to the service definition, thus covering all
> hosts or be bound to a specific host instance.
>
> * Domain names used for services MAY use CNAME or DNAME. Domain names that
> identify services MUST NOT.
>

I'm not sure I understand this distinction.

* Treat everything else as legacy. Expect Port numbers to be supplanted by
> SRV prefixes. Accept that TLSA is dead. Don't tilt at windmills with yet
> more discovery schemes.
>
> I see a distinction between Hosts and Services. An internet service is
> defined by an SRV prefix. A Host has a unique IP address and may support
> multiple services which may also share ports.
>
> If the objective is to conceal the service name being connected to, it
> follows that any key used to conceal the service negotiation must be bound
> to the host rather than the service.
>
> The protocol that these constraints points to would use a lightweight key
> agreement with a client supplied nonce and a host specific DNS key to
> protect the initial TLS key agreement and then feed that key as one of the
> inputs into the KDF for the service level key agreement.
>

How many DNS and destination roundtrips does this require?  My impression
is that SRV records have proven unpopular in part because they generally
add a DNS roundtrip delay to each initial connection.


>
> One bonus of this approach is that if you don't care about authentication,
> you can dispense with the service authentication altogether and use
> encryption based on the host encryption alone. TLS is designed to provide
> service authentication that is its purpose and the reason for most of the
> complexity.
>
>

--001a114401828a064b0548fcaa95
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker <phill@hallambaker.c=
om> wrote:
I really don't like the proposal at all=
. The idea of beginning the TLS handshake in DNS is sound. But it is a comp=
letely new handshake and authentication layer.

What you're proposing does sound like a completely new =
handshake.=C2=A0 To be clear, this proposal makes no change to TLS.
=C2=A0
Right now we have a bit of a mess with service discove=
ry. We have a solid proposal that makes sense written up as a standard 

Could you point me to which docume=
nt you're referring to?
=C2=A0
and we have a lot of =
folk saying we should do something different, either for legacy reasons or =
because they find it impure.

=

The solid proposal is as follows:

* Discov=
er all services using SRV *without exception*

* Use TXT records to provid=
e additional data *that is required for discovery and binding*

* TXT reco=
rds may be bound to the service definition, thus covering all hosts or be b=
ound to a specific host instance.

<=
/div>
* Domain names used for services MAY us=
e CNAME or DNAME. Domain names that identify services MUST NOT.=C2=A0
=


I'm not sure I understand this d=
istinction.

* Treat everything else as legacy. Expe=
ct Port numbers to be supplanted by SRV prefixes. Accept that TLSA is dead.=
 Don't tilt at windmills with yet more discovery schemes.

I see a dis=
tinction between Hosts and Services. An internet service is defined by an S=
RV prefix. A Host has a unique IP address and may support multiple services=
 which may also share ports.

=

If the objective is to conceal the service n=
ame being connected to, it follows that any key used to conceal the service=
 negotiation must be bound to the host rather than the service.

The proto=
col that these constraints points to would use a lightweight key agreement =
with a client supplied nonce and a host specific DNS key to protect the ini=
tial TLS key agreement and then feed that key as one of the inputs into the=
 KDF for the service level key agreement.

=

How many DNS and destination roundtrips does this require?=C2=A0=
 My impression is that SRV records have proven unpopular in part because th=
ey generally add a DNS roundtrip delay to each initial connection.
=C2=A0

One bonus of thi=
s approach is that if you don't care about authentication, you can disp=
ense with the service authentication altogether and use encryption based on=
 the host encryption alone. TLS is designed to provide service authenticati=
on that is its purpose and the reason for most of the complexity.

--001a114401828a064b0548fcaa95-- --001a114401829139300548fcaa56 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMdhJKC5aeSlGRk8YNMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDIxNjE4MDA1NVoXDTE3MDgx NTE4MDA1NVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC8JMN/Ya86Mmyv36dxJwPZXCrBZx8Hi0G6muYM3u+QThV/mu6B MpT3gEisJW8pU6iVPzxumyU7mDMwW8eshDTny91C+hTAP+cu1t4eIAmAZuNvXNd//DdmXOHvQvOU 2rH7+wTEYN0lvlSFydes0gud9VWl2hMTayncmyloIefNk/6lc2LRqw2geNw50jN1VqFpNMoxBOAp R+qJHuzxnanR4m3K1ujYUIeOUjLMFE4VxsOBtuF1FDx+SoXj18NpQyfioGPDXAgOIIE6PS244eZE 0De/SF3kvRf0AyCSrX102ZNu7i0L6Bb7P3bIDA0NB5uV5UNa2bBpuXq69gX07F/pAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFB6zCsWx7DJYdsxPym0ajAsc2DNCMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAckYJsVmfrg36lwFYD oepVYSEb0nhq9Y2/3T+cTKK/MCaU1oIRZ7LjmeFxkmA27jTy29y8+X+k5w9+I2E5vDI4D52vlKT+ FaouZnHGy1/oKZtUhMqjVn+DyEFdo1vOkir5R7cbxCK2QukpLQOb+RvzU5mOAYvwLgqn21yrcqBc 3pcYh4NlREjPe455gpwJl0d5TvYSCXEDUBXcWV7Bic7oVuPR0zXGsHQRQN7hkQsuEpwH0RhmaB/a GVYPktJvahNnk7JYoU8eRu7xwwA35VaXbUAuJCMq3UxAgBB59guHTeLZK9PSn0FqFo4sN12g4lsv ivmunuxPsD/Ozdn6yxtfMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMdhJKC5ae SlGRk8YNMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCcQrY6+BuRO8IZBZR/17Yk Aq7cIHu00R56kJHQRpDuLDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAyMjAyMTA4MzRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAcj8BcNpCfuTXZ17evRBkOWr2l9FfsQQFSQjTQIff xfz8JLh3qsmYVdhipo/6u/47BGLWl4yimF4tOHLTMxrsCp4c6oLjXb4r+iCX8C6M9ydLPfR+guY7 wRZDPYMcxpHACqn9v/J6PydPNaxdXDYeWdfPQCZix2DOu8jns83MFqieZGXwWpLmpvTrh8ziVKnf pLKWDqbbQLXn16QvBUquC0HlSuL8FgVH3flw6scpbWk3l9MlZMpXD1khvIWIpBlHe3mS9RNgb1iR VsNXvc6r3LpZhxsvHd7TJIU8XCrUNSB78xg5rjTxAQY97zJpU0h1gdeYow0ztqnd4hrjojCfHA== --001a114401829139300548fcaa56-- From nobody Mon Feb 20 13:19:52 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD54129480 for ; Mon, 20 Feb 2017 13:19:50 -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 tkIOB186hWmZ for ; Mon, 20 Feb 2017 13:19:49 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CD312954C for ; Mon, 20 Feb 2017 13:19:48 -0800 (PST) Received: (qmail 9236 invoked from network); 20 Feb 2017 21:19:47 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 20 Feb 2017 21:19:47 -0000 Date: 20 Feb 2017 21:19:25 -0000 Message-ID: <20170220211925.1906.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: dot@dotat.at Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 21:19:51 -0000 In article you write: >Would it be easier or harder, instead of adding a new SNI RRtype, to use >DANE TLSA records to identify the server's cert or key, and use a >variation of TLS SNI to request the cert by digest instead of by name? I don't see how that would help. Using passive DNS it's easy to find all the names that point to a server, which makes it easy to get all of the TLSA records for those names so the bad guy knows the hashes. R's, John From nobody Mon Feb 20 15:24:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1C81293F8 for ; Mon, 20 Feb 2017 15:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRp99KFxKY_a for ; Mon, 20 Feb 2017 15:24:36 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 2356F127077 for ; Mon, 20 Feb 2017 15:24:36 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id u188so32788415qkc.2 for ; Mon, 20 Feb 2017 15:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cv+jmdc9Thy714hhPhm2RnSpyZomfLuYIM/E8oJSBxk=; b=iLDyXZnthxIqty1RJFkH3agvFgHk8WEf0ws1jDiHbFN8C1TLPrcSUnRCW2koxCJpJn 7K0H45TPavjoCdbX/p5A1EWS6SgekVnAAi0+SyxkOC2KDI9ZEwPfCQ/ICVvjAHSTdYWz VST+OXaHGUZJxEs6kZ0cNumS48NGVKdSM3Vx9uIIYoZVY5YQmbdCigtcrtzis8b2VdV9 g4LGhwO264YzqNWmZt2bS43zTn5LMZUYG5hkUnlcSvWKnvreLbTtBc0xg2ChRdyOZXBZ o3UsF49GH+IZ3eRQHFmWAaDv1EplYL//h9ecx++BthRPmG8ianL/YJpbwUz+SiTfx7A/ tVvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cv+jmdc9Thy714hhPhm2RnSpyZomfLuYIM/E8oJSBxk=; b=sK/aFJZ2goIXXmCiD5HUKEmPvOGdOED0vZWV3mJLr54T2wcl4XRdpDresZGSSgoz8k riAn34eq0i5xzXZ2XqdL3eT8R206QBO1baMKf7JdCOTOTp8b9HV/02EF1ViIBCtHK3P8 EGg4L8W999+fTmKbcjcWJgj42ZJMhmGpaiG8gvnnLy/LAoZdFU2qMEU588STBRcwiDhf RAGT4T+kU0s3RmEvo1QofE8MlzF/TsR61sUYZCNrcX6pJD7SuzYPSjLgrUIbJ2TMDXiY IihH6LCz3YNDGC3wbPv+GwpHZl9cDUUX4kbdghmUKo0Bjwb8TnhQvsZG0KMcgrgGGyL2 PSqQ== X-Gm-Message-State: AMke39lYo/xvxAcVqCmrUSAP6Rnk3kOj4GrU3Phvt13oZUmQkyI/EG2Mc71wmXR2Jkdt/xKpyv4j9xmzBt+yiQK8 X-Received: by 10.55.145.7 with SMTP id t7mr20984836qkd.2.1487633075024; Mon, 20 Feb 2017 15:24:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.169.4 with HTTP; Mon, 20 Feb 2017 15:24:04 -0800 (PST) In-Reply-To: <20170220211925.1906.qmail@ary.lan> References: <20170220211925.1906.qmail@ary.lan> From: Warren Kumari Date: Mon, 20 Feb 2017 18:24:04 -0500 Message-ID: To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Tony Finch , dnsop Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 23:24:38 -0000 On Mon, Feb 20, 2017 at 4:19 PM, John Levine wrote: > In article you write: >>Would it be easier or harder, instead of adding a new SNI RRtype, to use >>DANE TLSA records to identify the server's cert or key, and use a >>variation of TLS SNI to request the cert by digest instead of by name? > > I don't see how that would help. Using passive DNS it's easy to find > all the names that point to a server, which makes it easy to get all > of the TLSA records for those names so the bad guy knows the hashes. http://www.bieberfever.com/ ("The Official Juston Bieber Fan Club") is hosted by Akamai on 23.38.103.18. According to DNSDB (IMO the best passive DNS service), there are 605 other sites *also* hosted on 23.38.103.18. No doubt pervasive monitors (and others) will use passive DNS systems to build a map of SNI DNS RRs, but I'd much much rather have the men in black thinking that I'm visiting www.precisiondoor.net, www.theman.in, or www.worldsleadingcruiselines.com than knowing my dirty little secret love of the Bieb... Even more embarrassing is my love of Kylie Minogue -- 162.249.104.157 [0] I'd much rather have anyone watching my TLS connections think that I'm a fan of www.artofnoiseofficial.com, lilyallen.de or one of the other 900+ sites on that IP address. Yes, maps of $site -> SNI *will* be made, and will be used for profiling -- but ... "I read Playboy for the articles" only works if they have articles -- I only went to www.worldsleadingcruiselines.com to read that, *not* to try buy the new poster, you know, the one where he's hair is *sooo* dreamy... W > > R's, > John > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Feb 20 15:35:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD518128E18 for ; Mon, 20 Feb 2017 15:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Rb5Z8b+g; dkim=pass (1536-bit key) header.d=taugh.com header.b=B4+PRm8i 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 2JUUj7WODNoN for ; Mon, 20 Feb 2017 15:35:24 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47991128874 for ; Mon, 20 Feb 2017 15:35:24 -0800 (PST) Received: (qmail 23281 invoked from network); 20 Feb 2017 23:35:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5aef.58ab7d3b.k1702; bh=3msdCPA25ZyZXB4XUSBr6mIVSIFKdiRCEFA5IQhbODA=; b=Rb5Z8b+gStwPJNp+9g65RSmS+8tVAN6rABU9eyy2xDvK4LJYrOjTcVWIDTbnOn4VRI05TM1FqsgrscaWSJWK/rRNutPvnDV/qSXSEHoyHBRx6wqFi3kpH4cPNTWtq1GWmwFWupEBCnHhePxPDgbMSVFXjHejqFBh2s4VRwJ+eR2xKMsK9FoGlUYoC/q8MN5/f2JfdTdmp30OkdklTT2B9EaayNpmmHAQXyBMYYcW3atjiD37tE4y5yaWTM54O/ae DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5aef.58ab7d3b.k1702; bh=3msdCPA25ZyZXB4XUSBr6mIVSIFKdiRCEFA5IQhbODA=; b=B4+PRm8irKtPGdNCjCdIvpBt7kKvSqwf8t1O49AEY/7A7K//htyiYA2fG13/FYCE/u1noBPgjYfQGRFgidNTNTa8Cco9Jvvcvb7wUWUTgz9Hx4nDMEr0/b+bu70Ykefyn4Hg8Ui+TrSg4U8VP2eJeK2CN8WuoU2G7GceyF59pNVteIZ4Z3UTEVWzy5pES9mZmkgbDTfAfR4ctUbwJRDaC1vEAIw64W3TsF02wixMZu4bIV8GR6FTtCGggLxbnqdc Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Feb 2017 23:35:22 -0000 Date: 20 Feb 2017 15:35:22 -0800 Message-ID: From: "John R Levine" To: "Warren Kumari" In-Reply-To: References: <20170220211925.1906.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dnsop Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 23:35:26 -0000 > http://www.bieberfever.com/ ("The Official Juston Bieber Fan Club") is > hosted by Akamai on 23.38.103.18. > According to DNSDB (IMO the best passive DNS service), there are 605 > other sites *also* hosted on 23.38.103.18. > No doubt pervasive monitors (and others) will use passive DNS systems > to build a map of SNI DNS RRs, but I'd much much rather have the men > in black thinking that I'm visiting www.precisiondoor.net, > www.theman.in, or www.worldsleadingcruiselines.com than knowing my > dirty little secret love of the Bieb... I really don't get this. The bad guys we're worried about have to be sophisticated enough to do a packet capture and pick the SNI bits out of TLS handshakes. How plausible is it that those bad guys would say, oh, using a script to find the cert hashes that will reveal the specific site is too hard so never mind? R's, John From nobody Mon Feb 20 16:06:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D261D129467 for ; Mon, 20 Feb 2017 16:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Nvias8Jg8GIQ for ; Mon, 20 Feb 2017 16:06:25 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CD112943B for ; Mon, 20 Feb 2017 16:06:25 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id B11E512C0DC6; Mon, 20 Feb 2017 19:06:24 -0500 (EST) Date: Mon, 20 Feb 2017 19:06:24 -0500 From: Robert Edmonds To: John R Levine Message-ID: <20170221000624.wxgvpytby7ozznxe@mycre.ws> References: <20170220211925.1906.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Cc: dnsop Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 00:06:27 -0000 John R Levine wrote: > > http://www.bieberfever.com/ ("The Official Juston Bieber Fan Club") is > > hosted by Akamai on 23.38.103.18. > > According to DNSDB (IMO the best passive DNS service), there are 605 > > other sites *also* hosted on 23.38.103.18. > > > No doubt pervasive monitors (and others) will use passive DNS systems > > to build a map of SNI DNS RRs, but I'd much much rather have the men > > in black thinking that I'm visiting www.precisiondoor.net, > > www.theman.in, or www.worldsleadingcruiselines.com than knowing my > > dirty little secret love of the Bieb... > > I really don't get this. The bad guys we're worried about have to be > sophisticated enough to do a packet capture and pick the SNI bits out of TLS > handshakes. How plausible is it that those bad guys would say, oh, using a > script to find the cert hashes that will reveal the specific site is too > hard so never mind? Isn't the server's certificate encrypted in TLS 1.3? And even in previous versions of TLS, at least in the CDN world it's somewhat common to put unrelated domains on the same SAN certificate. -- Robert Edmonds From nobody Mon Feb 20 16:06:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF24F1294A2 for ; Mon, 20 Feb 2017 16:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-htptqkzBIC for ; Mon, 20 Feb 2017 16:06:39 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 02F71129415 for ; Mon, 20 Feb 2017 16:06:39 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id d128so8956443ybh.2 for ; Mon, 20 Feb 2017 16:06:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PnILmlbWl7wJ2d7UqxkxDc8fs/h+e61h5knVXF+qMUQ=; b=hHaQJofgQ+DxvS5M8lmN2gJeqiMrBtXESyFQVZnELpSB5ZkOhWUkVq6Juf18LIavBv frGomOtXR5QAGLB2afYn6dSPUCGwjo58R5mLk0uJ50CxgJnVU8qz/+AV27C2GEnnl+fQ FuT77BCFxMcYJm4knpNKUbPxRkxHiAnNFimC8trFJz10pIKNgI2uxyRwvOUSKrfTQLvJ FuJwHhNkzPekoIVYOPMr2/lujsxVo69Qq3J6lcYZqk4s5YB1EzthNkaHn7oHOhWN7CHt ONUXlUdl5E9bu7iX8KZavf87KpRtRH4voP1FHGUhvxhHTc3m9XVH5O8odNaajuT5LX9F AyfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PnILmlbWl7wJ2d7UqxkxDc8fs/h+e61h5knVXF+qMUQ=; b=fyCnHVJt6N1L/8/yrVNNJFWIqZrr0rlZXNj59mEsEA0WCogvsq/hL8bK36/3QlTk5d aXiisXOKBQXSjJrxl3V4syKBReTt/tPdeXRz0N8VsjrBHbe+POrpAXX9Tn2EkW5E4ltJ jfh1OyvIJIurVXDUlo0FpyGq26apqdfFUFe2h20E+o6VQnjgtLbIcXMqfvj9nv7QDg1p +j+NXogq7cFGokqG/Qa+3ZQ44lCAeS0cFR3SmjaulfJr4QTqqmXAectirZddZOciAAlw 3RxNpw5c5BEImOJiqulSfJjMGQsLUt7LG2bklzRcr7S+mxB1rO1Mgmij1Ia1pY/6WkRo oKsQ== X-Gm-Message-State: AMke39n6WItVB4SfUz/6tpnhh3S6R1XEPDzxnp2Uc2lJZiGZPbqXSaGnTRWY0/tA7QSOoNyMvrwbCjgjlrwp5A== X-Received: by 10.37.36.86 with SMTP id k83mr9734226ybk.130.1487635598199; Mon, 20 Feb 2017 16:06:38 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.17.140 with HTTP; Mon, 20 Feb 2017 16:06:37 -0800 (PST) In-Reply-To: References: <20170217220309.9637.qmail@ary.lan> From: Phillip Hallam-Baker Date: Mon, 20 Feb 2017 19:06:37 -0500 X-Google-Sender-Auth: O4-txCQU2w2bw9wM8p-tTZbk34g Message-ID: To: Ben Schwartz Content-Type: multipart/alternative; boundary=001a113d46ec62d0750548ff2704 Archived-At: Cc: Tony Finch , "dnsop@ietf.org" Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 00:06:41 -0000 --001a113d46ec62d0750548ff2704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 20, 2017 at 4:08 PM, Ben Schwartz wrote: > On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> I really don't like the proposal at all. The idea of beginning the TLS >> handshake in DNS is sound. But it is a completely new handshake and >> authentication layer. >> > > What you're proposing does sound like a completely new handshake. To be > clear, this proposal makes no change to TLS. > =E2=80=8BWell there is your problem. There is little point in doing this un= less you feed the result into the TLS handshake to follow. =E2=80=8B Right now we have a bit of a mess with service discovery. We have a solid >> proposal that makes sense written up as a standard >> > > Could you point me to which document you're referring to? > https://tools.ietf.org/html/rfc6763 > and we have a lot of folk saying we should do something different, either >> for legacy reasons or because they find it impure. >> >> The solid proposal is as follows: >> >> * Discover all services using SRV *without exception* >> >> * Use TXT records to provide additional data *that is required for >> discovery and binding* >> >> * TXT records may be bound to the service definition, thus covering all >> hosts or be bound to a specific host instance. >> >> * Domain names used for services MAY use CNAME or DNAME. Domain names >> that identify services MUST NOT. >> > > I'm not sure I understand this distinction. > =E2=80=8BOoops...=E2=80=8B Domain names that identify =E2=80=8BHOSTS MUST NOT. =E2=80=8BA service is an abstract Internet service which may be provided by= any host chosen from group of hosts =E2=80=8Bspecified in an SRV record. A host= is a physical machine. =E2=80=8BSRV records map services to hosts.=E2=80=8B =E2=80=8BA and AAAA records map hosts to IP addresses.=E2=80=8B > How many DNS and destination roundtrips does this require? My impression > is that SRV records have proven unpopular in part because they generally > add a DNS roundtrip delay to each initial connection. > =E2=80=8BOne if it is done right.=E2=80=8B You are going to want to lock down your client to resolver DNS and you might as well fix the protocol at the same time. That is why standardizing on DNS-SD for everything is the way to go. --001a113d46ec62d0750548ff2704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Fe= b 20, 2017 at 4:08 PM, Ben Schwartz <bemasc@google.com> wrot= e:
= On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker <= ;phill@hallambak= er.com> wrote:
I really don't l= ike the proposal at all. The idea of beginning the TLS handshake in DNS is = sound. But it is a completely new handshake and authentication layer.
=

What you're proposing doe= s sound like a completely new handshake.=C2=A0 To be clear, this proposal m= akes no change to TLS.

<= div>
=E2=80=8BWell th= ere is your problem. There is little point in doing this unless you feed th= e result into the TLS handshake to follow. =E2=80=8B

=
Right now we have a bit of a mess with service dis= covery. We have a solid proposal that makes sense written up as a standard =

Could you point me to w= hich document you're referring to?
=


=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
and we have a lot of folk saying we should do something dif= ferent, either for legacy reasons or because they find it impure.

The sol= id proposal is as follows:

* Discover all services using SRV *without exc= eption*

* Use TXT records to provide additional data *that is required fo= r discovery and binding*

* TXT records may be bound to the service defini= tion, thus covering all hosts or be bound to a specific host instance.

* = Domain names used for services MAY use CNAME or DNAME. Domain names that id= entify services MUST NOT.=C2=A0

I'm not sure I understand this distinction.

=E2=80=8BOoops...=E2=80=8B

= =C2=A0Domain names that identify
=E2=80=8BHOSTS
=C2=A0MUST NOT.

=E2=80=8BA service is = an abstract Internet service which may be provided by any host chosen from = group of hosts =E2=80=8Bspecified in an SRV record. A host is a physical ma= chine.

=E2=80=8BSRV records map services to hosts.=E2=80=8B
=E2=80=8BA and AAAA records ma= p hosts to IP addresses.=E2=80=8B
=C2=A0
How many DNS and destination roundtrips does this requ= ire?=C2=A0 My impression is that SRV records have proven unpopular in part = because they generally add a DNS roundtrip delay to each initial connection= .

=E2=80=8BOne if it is done right.=E2= =80=8B

You are going to w= ant to lock down your client to resolver DNS and you might as well fix the = protocol at the same time. That is why standardizing on DNS-SD for everythi= ng is the way to go.

--001a113d46ec62d0750548ff2704-- From nobody Mon Feb 20 16:59:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16BE12955B for ; Mon, 20 Feb 2017 16:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=GHk5dUce; dkim=pass (1536-bit key) header.d=taugh.com header.b=R4ljq/MD 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 ox-6NBx4b6lY for ; Mon, 20 Feb 2017 16:59:39 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D86129561 for ; Mon, 20 Feb 2017 16:59:39 -0800 (PST) Received: (qmail 34521 invoked from network); 21 Feb 2017 00:59:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=86d7.58ab90f9.k1702; bh=06hQpLn7zA1Czw/SeuuOMq/Omh0kpzLfWaxDgLablNQ=; b=GHk5dUce9rSghtlTcXcbBDHnAr8dGIY4Zo8WmlExNfvV6icsJDlT/lKsI0NhkOZOiporPe1eTGqIailCko94LUuQEZmoc/GvUf1XNigU9sFwfaPp6NuP8xgrEqO3QHwziN70FZ0t5p5XcqQVTEgY9Oc6OAB/XiyKxdtfoJAftJls8WQ3tnDgzSP4K/B5R+WoYiTG9tSPplQX8nnYVTkJzMQ2V9eikDp0DDnnrjnO5hrJsZMXvFKOgCFNdzhZtttW DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=86d7.58ab90f9.k1702; bh=06hQpLn7zA1Czw/SeuuOMq/Omh0kpzLfWaxDgLablNQ=; b=R4ljq/MDCEpLEnwFiNhEEnj1L7JO/mmv+Qfq0omHnz5WEc39M/VmayLU5dIKTjd5X5dqg/9hB4tWHdqFaLNFFwdqyCoQPYN9t1dxI4qodvDnkSIXkzOClpXqva4+mj3115TONv79kn92Jvp4IEBzwOZWF7fU9loC067JDbW+yq5+jhHYXs1BBFk260xJ7VG8aByakMStyYrJDe/IbSbFsk49wL55dij7UVtx8LQDLR16n0qxox0gOb/fcGcKC1R2 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 21 Feb 2017 00:59:37 -0000 Date: 20 Feb 2017 16:59:36 -0800 Message-ID: From: "John R Levine" To: "Robert Edmonds" In-Reply-To: <20170221000624.wxgvpytby7ozznxe@mycre.ws> References: <20170220211925.1906.qmail@ary.lan> <20170221000624.wxgvpytby7ozznxe@mycre.ws> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dnsop Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 00:59:46 -0000 >> script to find the cert hashes that will reveal the specific site is too >> hard so never mind? > > Isn't the server's certificate encrypted in TLS 1.3? Yes, but Tony's proposal as I understood it was to use the hash from a TLSA certificate instead of the text of the SNI domain. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Feb 20 17:42:52 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF14129573 for ; Mon, 20 Feb 2017 17:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 zpJENtHNmj8K for ; Mon, 20 Feb 2017 17:42:49 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 EB465129572 for ; Mon, 20 Feb 2017 17:42:48 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id E29F824AE08; Tue, 21 Feb 2017 01:42:38 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id BED88160043; Tue, 21 Feb 2017 01:42:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id ADFCE160055; Tue, 21 Feb 2017 01:42:37 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Jt0FpXzzkEh4; Tue, 21 Feb 2017 01:42:37 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7217F160043; Tue, 21 Feb 2017 01:42:34 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id ACBFF643FBCF; Tue, 21 Feb 2017 12:42:30 +1100 (EST) To: Phillip Hallam-Baker From: Mark Andrews References: <20170217220309.9637.qmail@ary.lan> In-reply-to: Your message of "Mon, 20 Feb 2017 19:06:37 -0500." Date: Tue, 21 Feb 2017 12:42:30 +1100 Message-Id: <20170221014230.ACBFF643FBCF@rock.dv.isc.org> Archived-At: Cc: Ben Schwartz , Tony Finch , "dnsop@ietf.org" Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 01:42:51 -0000 In message , Phillip Hallam-Baker writes: > On Mon, Feb 20, 2017 at 4:08 PM, Ben Schwartz wrote: > > > On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker < > > phill@hallambaker.com> wrote: > > > >> I really don't like the proposal at all. The idea of beginning the TLS > >> handshake in DNS is sound. But it is a completely new handshake and > >> authentication layer. > >> > > > > What you're proposing does sound like a completely new handshake. To be > > clear, this proposal makes no change to TLS. > > > > Well there is your problem. There is little point in doing this unless > you > feed the result into the TLS handshake to follow. > > > Right now we have a bit of a mess with service discovery. We have a solid > >> proposal that makes sense written up as a standard > >> > > > > Could you point me to which document you're referring to? > > > > https://tools.ietf.org/html/rfc6763 > > > > > and we have a lot of folk saying we should do something different, > either > >> for legacy reasons or because they find it impure. > >> > >> The solid proposal is as follows: > >> > >> * Discover all services using SRV *without exception* > >> > >> * Use TXT records to provide additional data *that is required for > >> discovery and binding* > >> > >> * TXT records may be bound to the service definition, thus covering all > >> hosts or be bound to a specific host instance. > >> > >> * Domain names used for services MAY use CNAME or DNAME. Domain names > >> that identify services MUST NOT. > >> > > > > I'm not sure I understand this distinction. > > > > Ooops... > > Domain names that identify > HOSTS > MUST NOT. > > A service is an abstract Internet service which may be provided by any > host chosen from group of hosts specified in an SRV record. A host is a > physical machine. > > SRV records map services to hosts. > A and AAAA records map hosts to IP addresses. > > > > How many DNS and destination roundtrips does this require? My > impression > > is that SRV records have proven unpopular in part because they generally > > add a DNS roundtrip delay to each initial connection. > > > > One if it is done right. Zero if it is done right. We can easily extend the DNS to say "Fetch the additional record for the SRV records before answering" if you have this EDNS option present or just have the server do it without the option. There is nothing preventing a recursive server just doing this today. This is the essential difference between a CNAME and SRV records as far as browser vendors are concerned. Waiting for the "full" answer rather than returning a partial answer when there are no cached address records. We already have RFC that say go lookup missing data before constructing a response. We do this for DNS64. We do this for CNAME. If the SRV prefix is _http._tcp or _https._tcp then the recursive server SHOULD fetch any missing additional address records for the SRV server including CNAME records if the server name maps to a CNAME and add them to the addtional section prior to returning the response. You could even just do this for all SRV lookups. A RFC saying something like this would solve the SRV issue over the long term a recursive servers get replaced. Unfortunately brower vendors don't seem to want to say "yes, we will add SRV support if you change the DNS to do this". And if they have a issue with the prefix one can allocate a new TYPE(s) for class IN that does the same as SRV records but is for http and https. Service to address can be done with a single lookup and can include the TLSA records as well. This is a server that prefetches missing additional data and know about looking up TLSA records. You will notice that the additional section get populated just by the client looking up MX records. If you ask with DO=1 you can even get validatible results. Mark [rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50368 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 5d5611ff91b234cea8fc5d2858ab99833bfd56c3a5adef30 (good) ;; QUESTION SECTION: ;isc.org. IN MX ;; ANSWER SECTION: isc.org. 7200 IN MX 20 mx.ams1.isc.org. isc.org. 7200 IN MX 10 mx.pao1.isc.org. isc.org. 7200 IN RRSIG MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ= ;; Query time: 2435 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Feb 21 12:36:03 EST 2017 ;; MSG SIZE rcvd: 279 [rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47874 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 577d2fa83b7277682a8675f358ab9986654bdc6b80e4161c (good) ;; QUESTION SECTION: ;isc.org. IN MX ;; ANSWER SECTION: isc.org. 7197 IN MX 20 mx.ams1.isc.org. isc.org. 7197 IN MX 10 mx.pao1.isc.org. isc.org. 7197 IN RRSIG MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ= ;; ADDITIONAL SECTION: mx.pao1.isc.org. 3599 IN A 149.20.64.53 mx.pao1.isc.org. 3599 IN RRSIG A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk= ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Feb 21 12:36:06 EST 2017 ;; MSG SIZE rcvd: 467 [rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64268 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: eb9c5203e623a5489e068cae58ab9988f7a5f11cc716a2df (good) ;; QUESTION SECTION: ;isc.org. IN MX ;; ANSWER SECTION: isc.org. 7195 IN MX 10 mx.pao1.isc.org. isc.org. 7195 IN MX 20 mx.ams1.isc.org. isc.org. 7195 IN RRSIG MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ= ;; ADDITIONAL SECTION: mx.pao1.isc.org. 3597 IN A 149.20.64.53 mx.pao1.isc.org. 3598 IN AAAA 2001:4f8:0:2::2b mx.pao1.isc.org. 3597 IN RRSIG A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk= mx.pao1.isc.org. 3598 IN RRSIG AAAA 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. rOGdKaW/50E/UWD1Ko0rWwcMDJa9gp2tlX+LS1yoHm95TNZ6v5ZIxugj WUPl73nG3mJ8S15/rP+CLz6twIDJkFi5eCS7wXEmBXjuCVJfBhqDzIVJ tA+9AalM44j77nZpn71FWi50EW8M7NVV89c8BxdOkHtV/o4RjvVEs1iU GV0= ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Feb 21 12:36:08 EST 2017 ;; MSG SIZE rcvd: 667 [rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6978 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 7 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 1a50a8309bac059e81215eed58ab998ad77ca4375f67865f (good) ;; QUESTION SECTION: ;isc.org. IN MX ;; ANSWER SECTION: isc.org. 7193 IN MX 10 mx.pao1.isc.org. isc.org. 7193 IN MX 20 mx.ams1.isc.org. isc.org. 7193 IN RRSIG MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ= ;; ADDITIONAL SECTION: mx.pao1.isc.org. 3595 IN A 149.20.64.53 mx.pao1.isc.org. 3596 IN AAAA 2001:4f8:0:2::2b mx.pao1.isc.org. 3595 IN RRSIG A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk= mx.pao1.isc.org. 3596 IN RRSIG AAAA 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. rOGdKaW/50E/UWD1Ko0rWwcMDJa9gp2tlX+LS1yoHm95TNZ6v5ZIxugj WUPl73nG3mJ8S15/rP+CLz6twIDJkFi5eCS7wXEmBXjuCVJfBhqDzIVJ tA+9AalM44j77nZpn71FWi50EW8M7NVV89c8BxdOkHtV/o4RjvVEs1iU GV0= _25._tcp.mx.pao1.isc.org. 3598 IN RRSIG TLSA 5 6 3600 20170322234239 20170220234239 56778 pao1.isc.org. VnV0NTtAdpvfqpLaS2zF4IDKjIN97YPuKSmZ1tXrMLvoVlxutwPiH6El cTCQe/1Pi3QTqTFWr3kste3zIxDgAnnbmCKPbQDH2qsf67MBKM/Rv01O 1jmny3qM18Oqhsf+XTMsYEPe/YYsJzyw9aNydqI2egzkb4X8mpCTl+ge di4= _25._tcp.mx.pao1.isc.org. 3598 IN TLSA 3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Feb 21 12:36:10 EST 2017 ;; MSG SIZE rcvd: 895 [rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50265 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 9 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 1143a155c849920e213ee6cf58ab998f2fc22d8d9cdeb566 (good) ;; QUESTION SECTION: ;isc.org. IN MX ;; ANSWER SECTION: isc.org. 7188 IN MX 10 mx.pao1.isc.org. isc.org. 7188 IN MX 20 mx.ams1.isc.org. isc.org. 7188 IN RRSIG MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ= ;; ADDITIONAL SECTION: mx.pao1.isc.org. 3590 IN A 149.20.64.53 mx.ams1.isc.org. 3597 IN A 199.6.1.65 mx.pao1.isc.org. 3591 IN AAAA 2001:4f8:0:2::2b mx.pao1.isc.org. 3590 IN RRSIG A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk= mx.pao1.isc.org. 3591 IN RRSIG AAAA 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. rOGdKaW/50E/UWD1Ko0rWwcMDJa9gp2tlX+LS1yoHm95TNZ6v5ZIxugj WUPl73nG3mJ8S15/rP+CLz6twIDJkFi5eCS7wXEmBXjuCVJfBhqDzIVJ tA+9AalM44j77nZpn71FWi50EW8M7NVV89c8BxdOkHtV/o4RjvVEs1iU GV0= _25._tcp.mx.pao1.isc.org. 3593 IN RRSIG TLSA 5 6 3600 20170322234239 20170220234239 56778 pao1.isc.org. VnV0NTtAdpvfqpLaS2zF4IDKjIN97YPuKSmZ1tXrMLvoVlxutwPiH6El cTCQe/1Pi3QTqTFWr3kste3zIxDgAnnbmCKPbQDH2qsf67MBKM/Rv01O 1jmny3qM18Oqhsf+XTMsYEPe/YYsJzyw9aNydqI2egzkb4X8mpCTl+ge di4= mx.ams1.isc.org. 3597 IN RRSIG A 5 4 3600 20170322234059 20170220234059 13926 ams1.isc.org. AWHYspeFvJNWrYl78Q4XNnrhIFTUgYS40RUD8tYK0lJ/cIm61yMVzfSJ 5goMRIDXGDBFCAhkNoh7Ld09hfxI4rP6p0pxSRZIbuBj/CQDQ9e8/Wry o4WfRnKajj80/aU4p+68JNg8Fy92s2s/MWqsfBbtJ35Bubc4Qq33rvTE YYE= _25._tcp.mx.pao1.isc.org. 3593 IN TLSA 3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Feb 21 12:36:15 EST 2017 ;; MSG SIZE rcvd: 1083 [rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24483 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 11 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 0d0910d171a5c357fa78b5e458ab999a280908b6527ae8bb (good) ;; QUESTION SECTION: ;isc.org. IN MX ;; ANSWER SECTION: isc.org. 7177 IN MX 10 mx.pao1.isc.org. isc.org. 7177 IN MX 20 mx.ams1.isc.org. isc.org. 7177 IN RRSIG MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ= ;; ADDITIONAL SECTION: mx.pao1.isc.org. 3579 IN A 149.20.64.53 mx.ams1.isc.org. 3586 IN A 199.6.1.65 mx.pao1.isc.org. 3580 IN AAAA 2001:4f8:0:2::2b mx.ams1.isc.org. 3589 IN AAAA 2001:500:60::65 mx.pao1.isc.org. 3579 IN RRSIG A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk= mx.pao1.isc.org. 3580 IN RRSIG AAAA 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. rOGdKaW/50E/UWD1Ko0rWwcMDJa9gp2tlX+LS1yoHm95TNZ6v5ZIxugj WUPl73nG3mJ8S15/rP+CLz6twIDJkFi5eCS7wXEmBXjuCVJfBhqDzIVJ tA+9AalM44j77nZpn71FWi50EW8M7NVV89c8BxdOkHtV/o4RjvVEs1iU GV0= _25._tcp.mx.pao1.isc.org. 3582 IN RRSIG TLSA 5 6 3600 20170322234239 20170220234239 56778 pao1.isc.org. VnV0NTtAdpvfqpLaS2zF4IDKjIN97YPuKSmZ1tXrMLvoVlxutwPiH6El cTCQe/1Pi3QTqTFWr3kste3zIxDgAnnbmCKPbQDH2qsf67MBKM/Rv01O 1jmny3qM18Oqhsf+XTMsYEPe/YYsJzyw9aNydqI2egzkb4X8mpCTl+ge di4= mx.ams1.isc.org. 3586 IN RRSIG A 5 4 3600 20170322234059 20170220234059 13926 ams1.isc.org. AWHYspeFvJNWrYl78Q4XNnrhIFTUgYS40RUD8tYK0lJ/cIm61yMVzfSJ 5goMRIDXGDBFCAhkNoh7Ld09hfxI4rP6p0pxSRZIbuBj/CQDQ9e8/Wry o4WfRnKajj80/aU4p+68JNg8Fy92s2s/MWqsfBbtJ35Bubc4Qq33rvTE YYE= mx.ams1.isc.org. 3589 IN RRSIG AAAA 5 4 3600 20170322234059 20170220234059 13926 ams1.isc.org. RsCprRb3PCx0I6U5H+F5QVGNZhg978B1UJCHP/OEoZ8tK0cPZFyiXKk/ BhKeW9QjuDPWg2oYEXYmggowvMy3lWxlOODA161vD1DPaaS79lxCSp19 4GRmdl1146FYZD+jFi2OHsOpn2cTcXtw4bAK4KG9YiFytOBEftD58q3B h+g= _25._tcp.mx.pao1.isc.org. 3582 IN TLSA 3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Feb 21 12:36:26 EST 2017 ;; MSG SIZE rcvd: 1283 [rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58776 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 13 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 9a370fc4fe12b2f891fb40ef58ab9a32f9725da6e638d98c (good) ;; QUESTION SECTION: ;isc.org. IN MX ;; ANSWER SECTION: isc.org. 7025 IN MX 20 mx.ams1.isc.org. isc.org. 7025 IN MX 10 mx.pao1.isc.org. isc.org. 7025 IN RRSIG MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ= ;; ADDITIONAL SECTION: mx.pao1.isc.org. 3427 IN A 149.20.64.53 mx.ams1.isc.org. 3434 IN A 199.6.1.65 mx.pao1.isc.org. 3428 IN AAAA 2001:4f8:0:2::2b mx.ams1.isc.org. 3437 IN AAAA 2001:500:60::65 mx.pao1.isc.org. 3427 IN RRSIG A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk= mx.pao1.isc.org. 3428 IN RRSIG AAAA 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. rOGdKaW/50E/UWD1Ko0rWwcMDJa9gp2tlX+LS1yoHm95TNZ6v5ZIxugj WUPl73nG3mJ8S15/rP+CLz6twIDJkFi5eCS7wXEmBXjuCVJfBhqDzIVJ tA+9AalM44j77nZpn71FWi50EW8M7NVV89c8BxdOkHtV/o4RjvVEs1iU GV0= _25._tcp.mx.pao1.isc.org. 3430 IN RRSIG TLSA 5 6 3600 20170322234239 20170220234239 56778 pao1.isc.org. VnV0NTtAdpvfqpLaS2zF4IDKjIN97YPuKSmZ1tXrMLvoVlxutwPiH6El cTCQe/1Pi3QTqTFWr3kste3zIxDgAnnbmCKPbQDH2qsf67MBKM/Rv01O 1jmny3qM18Oqhsf+XTMsYEPe/YYsJzyw9aNydqI2egzkb4X8mpCTl+ge di4= mx.ams1.isc.org. 3434 IN RRSIG A 5 4 3600 20170322234059 20170220234059 13926 ams1.isc.org. AWHYspeFvJNWrYl78Q4XNnrhIFTUgYS40RUD8tYK0lJ/cIm61yMVzfSJ 5goMRIDXGDBFCAhkNoh7Ld09hfxI4rP6p0pxSRZIbuBj/CQDQ9e8/Wry o4WfRnKajj80/aU4p+68JNg8Fy92s2s/MWqsfBbtJ35Bubc4Qq33rvTE YYE= mx.ams1.isc.org. 3437 IN RRSIG AAAA 5 4 3600 20170322234059 20170220234059 13926 ams1.isc.org. RsCprRb3PCx0I6U5H+F5QVGNZhg978B1UJCHP/OEoZ8tK0cPZFyiXKk/ BhKeW9QjuDPWg2oYEXYmggowvMy3lWxlOODA161vD1DPaaS79lxCSp19 4GRmdl1146FYZD+jFi2OHsOpn2cTcXtw4bAK4KG9YiFytOBEftD58q3B h+g= _25._tcp.mx.ams1.isc.org. 3448 IN RRSIG TLSA 5 6 3600 20170322234059 20170220234059 13926 ams1.isc.org. IFlqqd2rOCNA/9lj++bw1UnlpwpvNE4AcgFpNj1JFwhHUvW6lbEWBjVY nYraYR1OMypOC+GxFxpxiSfTo+17V9j+PomD4tj7HeFVJNDteE1Uqqs9 iSfFj6pdtKK+DkA04svaO2CIKLONd/TabDb2f8fOMa7AFH/H6cSN69Qt uz4= _25._tcp.mx.pao1.isc.org. 3430 IN TLSA 3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0 _25._tcp.mx.ams1.isc.org. 3448 IN TLSA 3 0 1 5EF9B10DA21B2711522982EAD699FBABE77FD07FF07AC810608A85DA 66AFE916 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Feb 21 12:38:58 EST 2017 ;; MSG SIZE rcvd: 1511 [rock:~/git/bind9-marka] marka% > You are going to want to lock down your client to resolver DNS and you > might as well fix the protocol at the same time. That is why standardizing > on DNS-SD for everything is the way to go. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 20 18:08:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147D412959C for ; Mon, 20 Feb 2017 18:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lFKaaAET-0Y for ; Mon, 20 Feb 2017 18:08:39 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 5D14C12959E for ; Mon, 20 Feb 2017 18:08:39 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id l19so57953557ywc.2 for ; Mon, 20 Feb 2017 18:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MsrYD+p8pBirQH8O9mmwuQidf5LudmUDS12ytAzPFhs=; b=F+jZy67WaSR5bGV67ucPj4ArFhM/3H1lT6PACVff3XMju+D0wWV5nshOuD06b8kpTj 7xH6XNmXaeJfPwxDrGfh/9FUMm5qSevOGp5Tc7Br9t1zbp9JwWO3XBnuzzV79jOxPbPl Xz6IieJ/1WtkzJV/hjO3FT/5QmhIArfVkfb9cjO8W3TiIqJTtC4iNbu8T4cEiJ/Qt5DE XU15PUCO/RwRvJFjyTeOT/VD7sOjqAF1RgrDJ+25Yr2n8Vjr5iKN2MrWIsXgymRwh41W yZ4osmyAn8OSDZU33NjKvKsOgk725mhFJZYCr5Io5T1rHF3oBPl2SOGYmCvM9EBkHC/H 9M1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MsrYD+p8pBirQH8O9mmwuQidf5LudmUDS12ytAzPFhs=; b=QX1cQDAvkOBUZJxxEWudmC6k0V7NnJpu7FZ4/XPhuVXPUgM0HUT9Na8RnHJNTYDdhr Xmsez+g6g2LCoQF+lEm2naQoOdm1V+qFI542lP8gbvEvR6UXetk2CnUr7LCTdkA60oJx P//7oxv4C515kSRoinGOw2Ea8N4WzALN9nrv9FUBekjnbNfdoEKLqYU1mPdFBCKN+3EC SK00sgzH32I0A9Ia4Tpb8tEf1+cnnfB+2lEtbWwPC2fuIjE9g18+AlTSuawAqmH51T4Y N52tuKmes9slYjCTMcLHyYPCJCFd0o4FaeiZE4XfifdE8WEneVLpyg5T+S3bhIas99E9 vdcw== X-Gm-Message-State: AMke39kWDc7jvnIXx1UQYfUgsy275Szh7r+9kBsDR6TiqdkNqcgTxUhwFmdXijYO1cNxfWDo39QoAcWNzvH+rQ== X-Received: by 10.129.101.195 with SMTP id z186mr17876601ywb.340.1487642918574; Mon, 20 Feb 2017 18:08:38 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.17.140 with HTTP; Mon, 20 Feb 2017 18:08:37 -0800 (PST) In-Reply-To: <20170221014230.ACBFF643FBCF@rock.dv.isc.org> References: <20170217220309.9637.qmail@ary.lan> <20170221014230.ACBFF643FBCF@rock.dv.isc.org> From: Phillip Hallam-Baker Date: Mon, 20 Feb 2017 21:08:37 -0500 X-Google-Sender-Auth: qbzAU1zvqgahdNbXdRpB0z1RBgc Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a114c6c9cb6e27b054900dbdb Archived-At: Cc: Ben Schwartz , Tony Finch , "dnsop@ietf.org" Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 02:08:41 -0000 --001a114c6c9cb6e27b054900dbdb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 20, 2017 at 8:42 PM, Mark Andrews wrote: > > > Zero if it is done right. We can easily extend the DNS to say > "Fetch the additional record for the SRV records before answering" > if you have this EDNS option present or just have the server do it > without the option. There is nothing preventing a recursive server > just doing this today. > =E2=80=8B+1 Actually that is what I was assuming. If we are using the current DNS protocol then all we need to do is to program the DNS servers to intelligently add the necessary additional RRs. Alternatively, if we are doing DNS over QUIC then we could tweak the protocol so that this is the default.=E2=80=8B If the SRV prefix is _http._tcp or _https._tcp then the recursive > server SHOULD fetch any missing additional address records for the > SRV server including CNAME records if the server name maps to a > CNAME and add them to the addtional section prior to returning the > response. You could even just do this for all SRV lookups. > =E2=80=8BYup. The only catch is that we all need to do discovery the same w= ay. That is why SRV+TXT as specified in RFC6763 is the way to go=E2=80=8B > A RFC saying something like this would solve the SRV issue over the > long term a recursive servers get replaced. Unfortunately brower > vendors don't seem to want to say "yes, we will add SRV support if > you change the DNS to do this". > I don't think they are interested in SRV just for SRV. But SRV for this plus SNI encryption could be enough. We could also fix up some sort of backwards compatibility scheme. A DNS server that knows that _http._tcp.example.com is http over port 80 can convert A/AAAA records as needed. If we are dealing with a trusted DNS resolver chosen by the relying party that is constant, we can do things like advertise 'next generation discovery'. > And if they have a issue with the prefix one can allocate a new TYPE(s) > for class IN that does the same as SRV records but is for http and https. > > Service to address can be done with a single lookup and can include the > TLSA records as well. > I would prefer to specify the security policy in an accompanying prefixed TXT record because I need more than TLSA provides. --001a114c6c9cb6e27b054900dbdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Fe= b 20, 2017 at 8:42 PM, Mark Andrews <marka@isc.org> wrote:


Zero if it is done right.=C2=A0 We can easily extend the DNS to= say
"Fetch the additional record for the SRV records before answering"= ;
if you have this EDNS option present or just have the server do it
without the option.=C2=A0 There is nothing preventing a recursive server just doing this today.

=E2=80=8B+1 Actually that is what I = was assuming.
<= br>
If we are u= sing the current DNS protocol then all we need to do is to program the DNS = servers to intelligently add the necessary additional RRs.

Alternatively, if we are doing DNS over = QUIC then we could tweak the protocol so that this is the default.=E2=80=8B=

If the SRV prefix is _http._= tcp or _https._tcp then the recursive
server SHOULD fetch any missing additional address records for the
SRV server including CNAME records if the server name maps to a
CNAME and add them to the addtional section prior to returning the
response.=C2=A0 You could even just do this for all SRV lookups.

=E2=80=8BYup. The only catch is that we all need to do discovery the = same way. That is why SRV+TXT as specified in RFC6763 is the way to go=E2= =80=8B

=C2=A0
A RFC saying something like this would solve the SRV issue over the
long term a recursive servers get replaced.=C2=A0 Unfortunately brower
vendors don't seem to want to say "yes, we will add SRV support if=
you change the DNS to do this".

I don't think they= are interested in SRV just for SRV. But SRV for this plus SNI encryption c= ould be enough.

We could = also fix up some sort of backwards compatibility scheme. A DNS server that = knows that _http._tcp.example.com is= http over port 80 can convert A/AAAA records as needed.

If we are dealing with a trusted DNS resolv= er chosen by the relying party that is constant, we can do things like adve= rtise 'next generation discovery'.

= =C2=A0
And if they have a issue with the prefix one can allocate a new TYPE(s)
for class IN that does the same as SRV records but is for http and https.
Service to address can be done with a single lookup and can include the
TLSA records as well.

I would prefer to specify the securit= y policy in an accompanying prefixed TXT record because I need more than TL= SA provides.

--001a114c6c9cb6e27b054900dbdb-- From nobody Mon Feb 20 18:35:34 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7806C129457 for ; Mon, 20 Feb 2017 18:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 oJQod0SxOzw3 for ; Mon, 20 Feb 2017 18:35:31 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 31938129567 for ; Mon, 20 Feb 2017 18:35:31 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 1FCAF24AE08; Tue, 21 Feb 2017 02:34:12 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id BDD39160043; Tue, 21 Feb 2017 02:34:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A18C0160055; Tue, 21 Feb 2017 02:34:10 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lBGzl5I8JJe9; Tue, 21 Feb 2017 02:34:10 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 85680160043; Tue, 21 Feb 2017 02:34:09 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id CC5C76440839; Tue, 21 Feb 2017 13:34:05 +1100 (EST) To: Phillip Hallam-Baker From: Mark Andrews References: <20170217220309.9637.qmail@ary.lan> <20170221014230.ACBFF643FBCF@rock.dv.isc.org> In-reply-to: Your message of "Mon, 20 Feb 2017 21:08:37 -0500." Date: Tue, 21 Feb 2017 13:34:05 +1100 Message-Id: <20170221023405.CC5C76440839@rock.dv.isc.org> Archived-At: Cc: Ben Schwartz , Tony Finch , "dnsop@ietf.org" Subject: Re: [DNSOP] Proposal for a new record type: SNI X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 02:35:32 -0000 In message , Phillip Hallam-Baker writes: > On Mon, Feb 20, 2017 at 8:42 PM, Mark Andrews wrote: > > > > > > > Zero if it is done right. We can easily extend the DNS to say > > "Fetch the additional record for the SRV records before answering" > > if you have this EDNS option present or just have the server do it > > without the option. There is nothing preventing a recursive server > > just doing this today. > > > > +1 Actually that is what I was assuming. > > If we are using the current DNS protocol then all we need to do is to > program the DNS servers to intelligently add the necessary additional RRs. > > Alternatively, if we are doing DNS over QUIC then we could tweak the > protocol so that this is the default. > > If the SRV prefix is _http._tcp or _https._tcp then the recursive > > server SHOULD fetch any missing additional address records for the > > SRV server including CNAME records if the server name maps to a > > CNAME and add them to the addtional section prior to returning the > > response. You could even just do this for all SRV lookups. > > > > Yup. The only catch is that we all need to do discovery the same way. > That > is why SRV+TXT as specified in RFC6763 is the way to go > > > > > A RFC saying something like this would solve the SRV issue over the > > long term a recursive servers get replaced. Unfortunately brower > > vendors don't seem to want to say "yes, we will add SRV support if > > you change the DNS to do this". > > > > I don't think they are interested in SRV just for SRV. But SRV for this > plus SNI encryption could be enough. > > We could also fix up some sort of backwards compatibility scheme. A DNS > server that knows that _http._tcp.example.com is http over port 80 can > convert A/AAAA records as needed. Or just add the A/AAAA records to the additional section of the NXDOMAIN/NODATA response to the SRV query using the base name. The client can synthesize the response using the additional data. That way the DNS server doesn't need to know the port mappings. If qtype is SRV strip off leading underscore labels and add addresses records for the resulting name to the additional section of the response. Or the client can just do parallel lookups and wait for all the responses before proceeding. Set a flag day N years out for when to stop performing the A/AAAA lookups. They can decide to stop doing parallel lookups much earlier when they see SRV records being returned consistently. The flag day is just to sunset backwards lookups. > If we are dealing with a trusted DNS resolver chosen by the relying party > that is constant, we can do things like advertise 'next generation > discovery'. > > > > > And if they have a issue with the prefix one can allocate a new TYPE(s) > > for class IN that does the same as SRV records but is for http and https. > > > > Service to address can be done with a single lookup and can include the > > TLSA records as well. > > > > I would prefer to specify the security policy in an accompanying prefixed > TXT record because I need more than TLSA provides. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 20 19:09:46 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF1C129607 for ; Mon, 20 Feb 2017 19:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 ngD6Dz-9hsa5 for ; Mon, 20 Feb 2017 19:09:44 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 E80CA129605 for ; Mon, 20 Feb 2017 19:09:43 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id DC27724AE08 for ; Tue, 21 Feb 2017 03:08:24 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A4547160043 for ; Tue, 21 Feb 2017 03:08:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 90281160055 for ; Tue, 21 Feb 2017 03:08:23 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6YI_gmsY2oqC for ; Tue, 21 Feb 2017 03:08:23 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 14D4E160043 for ; Tue, 21 Feb 2017 03:08:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E0C9F64426A4 for ; Tue, 21 Feb 2017 14:08:18 +1100 (EST) To: dnsop@ietf.org From: Mark Andrews Date: Tue, 21 Feb 2017 14:08:18 +1100 Message-Id: <20170221030818.E0C9F64426A4@rock.dv.isc.org> Archived-At: Subject: [DNSOP] finding the issue tracker X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 03:09:45 -0000 It's hard to find issue trackers if they are not recorded as such. https://github.com/Abhayakara/draft-tldr-sutld-ps/issues should be listed as the issues tracker for https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 20 20:34:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2225129A1E for ; Mon, 20 Feb 2017 20:34:56 -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=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 cAel3m5ZLmTj for ; Mon, 20 Feb 2017 20:34:55 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B391129A5B for ; Mon, 20 Feb 2017 20:34:55 -0800 (PST) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0B9697A3302 for ; Tue, 21 Feb 2017 04:34:54 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 20 Feb 2017 23:34:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: dnsop@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 123, Issue 70 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dnsop@ietf.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 04:34:57 -0000 > On Feb 20, 2017, at 4:19 PM, dnsop-request@ietf.org wrote: >=20 > Accept that TLSA is dead. Don't tilt at windmills with yet more = discovery schemes. There at least ~2400 MX hosts with published TLSA records for SMTP = serving over 100k domains and growing. In addition to Postfix and Exim, vendors are = starting to implement DANE for SMTP. Adoption is not surprisingly slow, but TLSA = for SMTP is certainly not "dead", and adoption will accelerate as more MTAs and = service providers add support. If you're talking about TLSA for HTTPS, then indeed it is not likely to = be used at all soon... Whether that's dead or just dormant is presently = academic. --=20 Viktor. From nobody Mon Feb 20 23:37:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535E312988A for ; Mon, 20 Feb 2017 23:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 7-6O2UqoT1ai for ; Mon, 20 Feb 2017 23:37:01 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD07129416 for ; Mon, 20 Feb 2017 23:37:01 -0800 (PST) Received: from [192.168.3.170] (unknown [95.82.146.6]) by mail.nic.cz (Postfix) with ESMTPSA id 410C960106; Tue, 21 Feb 2017 08:37:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487662620; bh=xx4XEuudtKXUUV7mV1pAjW2lryyYRle70258j+/jR/g=; h=To:From:Date; b=Z0vhZ7G2W8Okl5Xj9JSqqK+29c8QrR5Zek9mJJzrOu/AY94Hv4D2w9NVJudXSuJFT W4nHdsGyI59KuUYlywdQYusOF4LRbw8pICUge6iAr9JVK/NSAqi00HTa0OeyehqbDq +ziex7Q4UA1GxNT0Ichpyk8h0HINS8AbUa4Od2+Y= To: Wes Hardaker , dnsop@ietf.org References: From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <0d241cea-bb78-63e7-3088-2912538c4dcb@nic.cz> Date: Tue, 21 Feb 2017 08:36:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Published: draft-hardaker-rfc5011-security-considerations-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 07:37:03 -0000 Version 04 addresses all my comments, thank you! If you decide to mention me in the document feel to use "Petr Spacek" as ASCII version of my name to avoid the Unicode madness. Have a nice day. Petr Špaček @ CZ.NIC On 02/17/2017 10:38 PM, Wes Hardaker wrote: > > For those following along with this draft, I've just published -04. From nobody Tue Feb 21 03:36:51 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDB21293F3; Tue, 21 Feb 2017 03:36:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148767700983.32635.5525058061405932673.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2017 03:36:49 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 11:36:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : C-DNS: A DNS Packet Capture Format Authors : John Dickinson Jim Hague Sara Dickinson Terry Manderson John Bond Filename : draft-ietf-dnsop-dns-capture-format-01.txt Pages : 48 Date : 2017-02-21 Abstract: This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic monitoring applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 21 03:39:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E598612965B for ; Tue, 21 Feb 2017 03:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cczXQw3fqCXg for ; Tue, 21 Feb 2017 03:39:20 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244131293F3 for ; Tue, 21 Feb 2017 03:39:20 -0800 (PST) Received: from [2001:b98:204:102:fffa::9] (port=61389) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1cg8ms-0007eh-B4 for dnsop@ietf.org; Tue, 21 Feb 2017 11:39:18 +0000 From: Sara Dickinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 21 Feb 2017 11:39:14 +0000 References: <148767700983.32635.5525058061405932673.idtracker@ietfa.amsl.com> To: dnsop In-Reply-To: <148767700983.32635.5525058061405932673.idtracker@ietfa.amsl.com> Message-Id: <1E671B09-B07B-451A-B18C-B96CBEFBE03D@sinodun.com> X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 11:39:22 -0000 Hi All,=20 This update to the draft tries to address the recent comments: * Many editorial improvements by Paul Hoffman * Included discussion of malformed packet handling * Improved Appendix C on Comparison of Binary Formats * Now using C-DNS field names in the tables in section 8 * A handful of new fields included (CDDL updated) * Timestamps now include optional picoseconds * Added details of block statistics Regards Sara.=20 > On 21 Feb 2017, at 11:36, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Domain Name System Operations of the = IETF. >=20 > Title : C-DNS: A DNS Packet Capture Format > Authors : John Dickinson > Jim Hague > Sara Dickinson > Terry Manderson > John Bond > Filename : draft-ietf-dnsop-dns-capture-format-01.txt > Pages : 48 > Date : 2017-02-21 >=20 > Abstract: > This document describes a data representation for collections of DNS > messages. The format is designed for efficient storage and > transmission of large packet captures of DNS traffic; it attempts to > minimize the size of such packet capture files but retain the full > DNS message contents along with the most useful transport metadata. > It is intended to assist with the development of DNS traffic > monitoring applications. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-01 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-dns-capture-format-01= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue Feb 21 09:21:45 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5902E12943D; Tue, 21 Feb 2017 09:21:44 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148769770436.19017.83220160998183434.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2017 09:21:44 -0800 Archived-At: Cc: Tim Wicinski , dnsop-chairs@ietf.org, joelja@gmail.com, draft-ietf-dnsop-edns-key-tag@ietf.org, The IESG , dnsop@ietf.org, rfc-editor@rfc-editor.org Subject: [DNSOP] Protocol Action: 'Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)' to Proposed Standard (draft-ietf-dnsop-edns-key-tag-05.txt) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 17:21:44 -0000 The IESG has approved the following document: - 'Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)' (draft-ietf-dnsop-edns-key-tag-05.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ Technical Summary This document specifies two different ways for validating DNS resolvers to signal to a server which DNSSEC keys are referenced in their chain-of- trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone. This document describes two independent methods for validating resolvers to publish their referenced keys: an EDNS option and a different DNS query. Working Group Summary The working group was in strong consensus behind this document. One thing which did emerge was that there was a division over two methods for publishihng the keys (EDNS option vs a DNS query). It turned out that each method had its positives and its negatives. The consensus from the working group was to offer both alternatives, documents the flaws in each. Document Quality The document shepherd did a deep dive on the document for technical correctness, as well as an editorial pass for grammar and diction. The shepherd feels this document is ready for publication. (4) Personnel Tim Wickinski is the document shpeherd, Joel Jaeggli is the Area Director From nobody Tue Feb 21 13:31:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786FD129CF2 for ; Tue, 21 Feb 2017 13:31:15 -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, RP_MATCHES_RCVD=-0.001, 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 jXvXyvAeDZMx for ; Tue, 21 Feb 2017 13:31:14 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF5D1294FF for ; Tue, 21 Feb 2017 13:31:14 -0800 (PST) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 0CA96215C0; Tue, 21 Feb 2017 13:31:13 -0800 (PST) From: Wes Hardaker To: Petr =?utf-8?B?xaBwYcSNZWs=?= References: <0d241cea-bb78-63e7-3088-2912538c4dcb@nic.cz> Date: Tue, 21 Feb 2017 13:31:12 -0800 In-Reply-To: <0d241cea-bb78-63e7-3088-2912538c4dcb@nic.cz> ("Petr =?utf-8?B?xaBwYcSNZWsiJ3M=?= message of "Tue, 21 Feb 2017 08:36:59 +0100") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dnsop@ietf.org, Wes Hardaker Subject: Re: [DNSOP] Published: draft-hardaker-rfc5011-security-considerations-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 21:31:15 -0000 Petr =C5=A0pa=C4=8Dek writes: > If you decide to mention me in the document feel to use "Petr Spacek" as > ASCII version of my name to avoid the Unicode madness. We've been publishing UTF-8 RFCs for a while now I think. --=20 Wes Hardaker USC/ISI From nobody Thu Feb 23 08:28:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B0C129A1A for ; Thu, 23 Feb 2017 08:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibqAGuGoc-Mr for ; Thu, 23 Feb 2017 08:28:04 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 AB0E51299EB for ; Thu, 23 Feb 2017 08:28:04 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id n127so36340345qkf.0 for ; Thu, 23 Feb 2017 08:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=yMLuR/Q2JdLOhYPy+m5mzyYZXjxp+UwhL5qtUgXGDvA=; b=Q22CzOExwB97Niv+yrPRJkKeJk0me5Ags5nV39BiyvoYdCaa5WGkidxF9f0mqm6+lg MxuXYdPlA/rCw/lEuUe0IvmRA4JvWCTvYpWaDqoyJGCwbXj+ZMrZlXEoiGrviRCa7eq7 sPusnl7w/VS+BEGmATi3bcwoNQuHNvkozgfFoDelw+Xqr0CzyzhB5qM3IMXno2Cy/NAc juODhTbQnAIw0gFTTnTnYjV6wt83Z5Wmu6L8NJRw8r+n2Hf3AfFsI7fShDlMDQFNkF6g kIfaeZxYCmx6vClTGeYnp0k6cRNaLvIfOe41oMPEVTkUyXEXIA8B0r/qdd/QQY2imV7Q qd+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=yMLuR/Q2JdLOhYPy+m5mzyYZXjxp+UwhL5qtUgXGDvA=; b=SVuM056+UXbrJuB/oV/X8iH0AVzfknUU2mwArUFutDKDD6zVkdiTzR38yqVsIbkFTx sfQcqvoTHMyad6Zpy74GOaSLtxrdXUEkdWeC4xqMGjdWkuqAhn4tTfoXLXDsvoaMmE8z SkILbOogQ4BhRnn8kSpTmwAfZwfx1WHYHxtFhD6pmaPqZY+Cqu2F2tDfylHCyGYPtBwS 3+5VC39KISAFpzQTTcXCkcrBeWhTuh6v5JcwCyFPjHyHac7L52mVQWx4198RBaX3/B4j vjKSpjnWUILaQFJb1ydJ5E50243rIBNj3uge+nVo4Ua3AUKxbAb/vUce4ozSfdubLbFm P1zA== X-Gm-Message-State: AMke39k1Wnh8PfPc3Kyf2btInfqs9UPE2uKuv5lJI/a1V1VP00FtRmT4f8lk4l5gp3I+FA== X-Received: by 10.55.120.69 with SMTP id t66mr18493328qkc.182.1487867283467; Thu, 23 Feb 2017 08:28:03 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:c43c:1d42:40e2:60bd? ([2601:181:c381:c20:c43c:1d42:40e2:60bd]) by smtp.gmail.com with ESMTPSA id x125sm2987983qkd.17.2017.02.23.08.28.02 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Feb 2017 08:28:02 -0800 (PST) From: Suzanne Woolf Content-Type: multipart/alternative; boundary="Apple-Mail=_89039BFE-57D4-4521-A7A9-1A27CCFFDBA3" Message-Id: <6CCF192E-6D67-4121-80F9-DDA8637B249D@gmail.com> Date: Thu, 23 Feb 2017 11:28:01 -0500 To: dnsop Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [DNSOP] summary: virtual interim meeting, 16 Feb. 2017 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 16:28:06 -0000 --Apple-Mail=_89039BFE-57D4-4521-A7A9-1A27CCFFDBA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, The chairs=E2=80=99 summary from the WG virtual interim meeting last = week appears below. Recording of the webex session:=20 = https://ietf.webex.com/ietf/ldr.php?RCID=3D09e87536cf71661d1e4e7339abcf001= e = Chairs=E2=80=99 summary of the discussion 1. sutld-ps WGLC: * editors are resolving issues, quite a few have been raised and = most are straightforward to resolve * distinction between special use names generally and =E2=80=9CTLD= s=E2=80=9D needs to be clear, also distinction between names to be = resolved with DNS and names to be resolved otherwise * Question came up of where we stand process-wise, particularly = if the IETF or IESG change or don't publish the problem statement. = There's been no commitment to publish it, but the roadmap that blocked = other action on having one was discussed multiple times with our AD; and = even if we don=E2=80=99t publish it, the exercise has been useful for = the WG * Future action may not occur in DNSOP at all; that=E2=80=99s = largely up to the IESG. 2. alt-tld: * mostly done; we know what it will and won=E2=80=99t do, and = there was agreement that more distinction needs to be made in the = document * as discussed on the list, consensus seems to be against asking = for a signed delegation in the root for .alt * open issue discussed here was whether to add .alt to the = locally-served zones registry; consensus on the call seemed to be not to = do that either; editors will propose text to wrap up both issues. Some = people felt the justification for the latter should be in a =E2=80=9CSecur= ity Considerations,=E2=80=9D others felt it should be in a =E2=80=9CPrivac= y Considerations=E2=80=9D. 3. next steps * no one is ready to propose concrete next steps beyond =E2=80=9Cf= ind out what the IESG thinks=E2=80=9D * some people feel this topic isn=E2=80=99t DNSOP WG business, = because there are technical issues but they won=E2=80=99t be resolved = within the scope of the WG charter; a few feel it=E2=80=99s a =E2=80=9Clay= er violation=E2=80=9D that has nothing to do with the IETF, because = it=E2=80=99s intrinsically and entirely political. * some confusion on the scope limitation put in place for the = problem statement that we/the IESG might want to relax for DNSOP (or = anyone else) to consider solutions --Apple-Mail=_89039BFE-57D4-4521-A7A9-1A27CCFFDBA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

The chairs=E2=80=99 summary from the WG virtual interim = meeting last week appears below.

Recording of the webex = session: 

https://ietf.webex.com/ietf/ldr.php?RCID=3D09e87536cf71661d1e4e= 7339abcf001e


Chairs=E2=80=99 summary of the discussion

1. = sutld-ps WGLC:
* editors are resolving issues, = quite a few have been raised and most are straightforward to = resolve
* distinction between special use = names generally and =E2=80=9CTLDs=E2=80=9D needs to be clear, also = distinction between names to be resolved with DNS and names to be = resolved otherwise
* Question came up of where we = stand process-wise, particularly if the IETF or IESG change or don't = publish the problem statement. There's been no commitment to publish it, = but the roadmap that blocked other action on having one was discussed = multiple times with our AD; and even if we don=E2=80=99t publish it, the = exercise has been useful for the WG
* Future = action may not occur in DNSOP at all; that=E2=80=99s largely up to the = IESG.

2. = alt-tld:
* mostly done; we know what it = will and won=E2=80=99t do, and there was agreement that more distinction = needs to be made in the document
* as = discussed on the list, consensus seems to be against asking for a signed = delegation in the root for .alt
* open = issue discussed here was whether to add .alt to the locally-served zones = registry; consensus on the call seemed to be not to do that either; = editors will propose text to wrap up both issues. Some people felt the = justification for the latter should be in a =E2=80=9CSecurity = Considerations,=E2=80=9D others felt it should be in a =E2=80=9CPrivacy = Considerations=E2=80=9D.

3. next steps
* no one = is ready to propose concrete next steps beyond =E2=80=9Cfind out what = the IESG thinks=E2=80=9D
* some = people feel this topic isn=E2=80=99t DNSOP WG business, because there = are technical issues but they won=E2=80=99t be resolved within the scope = of the WG charter; a few feel it=E2=80=99s a =E2=80=9Clayer violation=E2=80= =9D that has nothing to do with the IETF, because it=E2=80=99s = intrinsically and entirely political.
* some = confusion on the scope limitation put in place for the problem statement = that we/the IESG might want to relax for DNSOP (or anyone else) to = consider solutions

= --Apple-Mail=_89039BFE-57D4-4521-A7A9-1A27CCFFDBA3-- From nobody Thu Feb 23 10:27:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C939129A3E for ; Thu, 23 Feb 2017 10:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 5uaX-EVH_UZE for ; Thu, 23 Feb 2017 10:27:55 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 F1E1012A247 for ; Thu, 23 Feb 2017 10:27:54 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id v200so20740714ywc.3 for ; Thu, 23 Feb 2017 10:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=//nH7gIpSsDNDcmxB6Mz0S/Px5PTeCq4aubnLAl8I+Y=; b=MwatJh2uzMXo0O2bPGU4Q1vbexu4pcx5ddKafazHqSdX2HvJUvwnYW7T0VklKkkbdg VFvutXrGqdssKEVBVUNGf7bpjxHtnnVefy7JR4egZ9i+/Z30XWEsu6Qw9UBiBzUMThLz PkBDX4M86Vj0wNwdZ3vezI8vmV3pjxW0oza5Kl1TjswKqgoYQAo4FvR9gqLNdZ7eNAnl BCpOl9nw3BxjqfcBaD8cBOIU+HuY5i6qqaNXBfUdrYUba2GxpqgH9blH8mlYnHcZogYc oaFgHyduaLGaNvWB0sh0rwz7sJ5RPVLqa2dOE9gGm2lsuVal5ScfGAJsK/8Rxnj0A3ED OWqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=//nH7gIpSsDNDcmxB6Mz0S/Px5PTeCq4aubnLAl8I+Y=; b=OQ0El+605tBSXxsMdZMDeFX+7B+yP2tQK4wz8v720ZNOLD/5ue5kCiaCoUD1+TeRew 9if2xaaDw2fBp8RigQWUkBPHXv/uUCGbbUUmExLOOAN2eRt7bpkYhh8awpaiiUpEYAQq gBNgSiVt4Z3ijZHKnMdsKsOX92Z2QaBkHv97i1WNflb0AdVnvzfPjhcXWdWhMb3JRYYq 9Pg3Gqihsn3RWHEIYY96uZw+k69m34pmQG/veM5dnVC9kz07+4YiD99FS/laZIzE8+/b 5HTG8vi2StDLquPT1oqH7QediXAwCxITXnlU4g5HDujew4xS7HumQP6OSUXF11GH2qo/ cxQA== X-Gm-Message-State: AMke39kZTNGEHDjitKj0E7rGejoQjzi7THMVDs6csmveV+ej3XPHNaFOZ7y1fVhljxKWNvGXpxZbs8iMOfMW5c/4 X-Received: by 10.13.193.71 with SMTP id c68mr29132469ywd.104.1487874473619; Thu, 23 Feb 2017 10:27:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.237.68 with HTTP; Thu, 23 Feb 2017 10:27:53 -0800 (PST) In-Reply-To: References: From: Bob Harold Date: Thu, 23 Feb 2017 13:27:53 -0500 Message-ID: To: Wes Hardaker Content-Type: multipart/alternative; boundary=001a114ca9c878aa32054936c550 Archived-At: Cc: IETF DNSOP WG Subject: Re: [DNSOP] Published: draft-hardaker-rfc5011-security-considerations-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 18:27:57 -0000 --001a114ca9c878aa32054936c550 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 17, 2017 at 4:38 PM, Wes Hardaker wrote: > > For those following along with this draft, I've just published -04. > > -- > Wes Hardaker > USC/ISI > > Thanks for your work on this. I see you updated the formula in section 6. Minimum RFC5011 Timing Requirements The paragraph after it says: "The most confusing element of the above equation comes from the "3 * (DNSKEY RRSIG Signature Validity) / 2" element, but is the most critical to understand and get right." But the formula no longer contains "3 * " anything. Also, diff2 does not handle the UTF-8 in Petr's name. https://tools.ietf.org/rfcdiff?url2=draft-hardaker-rfc5011-security-considerations-04.txt and even the normal view https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-04 -- Bob Harold --001a114ca9c878aa32054936c550 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 17, 2017 at 4:3= 8 PM, Wes Hardaker <wjhns1@hardakers.net> wrote:

For those following along with this draft, I've just published -04.

--
Wes Hardaker
USC/ISI


Thanks for yo= ur work on this.

I see you updated the formula in = section 6. =C2=A0Minimum RFC5011 Timing Requirements
The paragraph after it says:
"The most confusing element of the ab= ove equation comes from the "3 *=09 (DNSKEY RRSIG Signature Validity) / 2" element, but is the most=09 critical to understand and get right."

But the formula n= o longer contains "3 * " anything.

Also, diff= 2 does not handle the UTF-8 in Petr's name.
and even the normal view
https://tools.ietf.org/html/draft-harda= ker-rfc5011-security-considerations-04

= --
Bob Harold
<= br>

--001a114ca9c878aa32054936c550-- From nobody Thu Feb 23 10:58:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AD5129A74 for ; Thu, 23 Feb 2017 10:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 xSLE6gWhpMua for ; Thu, 23 Feb 2017 10:58:20 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 51B7212986E for ; Thu, 23 Feb 2017 10:58:19 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id a5so11283297ybb.2 for ; Thu, 23 Feb 2017 10:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ocp+5litrm2y+Dgo2R6H/xdUF49rkb45CIs4LajtI7c=; b=kKTDNQ66+T9pAx6thzT2x+DKZYCgBdbx8PHKNt3UWUE9S+jfOhJD1cA7UlKiF/ng00 WANCthmai1qoe5I7sUFWzZya6Ad6MYt/IUAOSoAZZteecxXBy5dW6uINsMXgIsf21mPe gRP6NCFIFRjrDP3Y/4OpzLnuEi3/iiyq0uKW2NTyS4faTXftMobvOwNIE9dsImc0Xesg xXA/Pkav1+W7jN+S8hhPEqzjWrcz4mxMCQlQGP0TE1Y4IfFz6ZgmTGw81lqicOAA/Jp3 j28bM1kOBV2hMJMYzBXfz/BREJebenvcG6AbYFNuKNbfK+8LK7r07dbY0uT1i8ZWWa8h b2NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ocp+5litrm2y+Dgo2R6H/xdUF49rkb45CIs4LajtI7c=; b=rk5okRMB5n+RBm7St1A9SCv9PjrMZovxAE1SznpMoaZeoVKim236xmt5tqcxjCE+F2 i+5g+VBtlf4mRbN1aid0B8MHsTjB5WydPLAIghA62fcj/i9N5v0xNf9QJF+nMWDgiUtp /HwWk/Xc88TTDeyT0QH3sdSnetybK9cQu5h28E6J/xVJQrc4iz4t0ohQHYFSmHqfUoSv LsckPz/BxPEBQPm/6d+avt7JL8LqkXmvbpkY1K83YnTM4b0HYF6FGlWoj2a0wsX7vJ+m Flsrmf8uTfw7myAy8i6TgJWOrNlnhn2k4/ox1bruQJn21HHQZQAeO7gx9LHvGL3WZTfT d/lg== X-Gm-Message-State: AMke39m4PhISY6jhnp/FfEBj3eF8a/GdGkTAavBxEKfjeEqr1yj0KuezEgUIY1rTiK65Nt4BRj62s7qpOlQRxsui X-Received: by 10.37.164.196 with SMTP id g62mr27684535ybi.18.1487876298888; Thu, 23 Feb 2017 10:58:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.237.68 with HTTP; Thu, 23 Feb 2017 10:58:18 -0800 (PST) In-Reply-To: <1E671B09-B07B-451A-B18C-B96CBEFBE03D@sinodun.com> References: <148767700983.32635.5525058061405932673.idtracker@ietfa.amsl.com> <1E671B09-B07B-451A-B18C-B96CBEFBE03D@sinodun.com> From: Bob Harold Date: Thu, 23 Feb 2017 13:58:18 -0500 Message-ID: To: Sara Dickinson Content-Type: multipart/alternative; boundary=94eb2c13b51043eedc0549373273 Archived-At: Cc: dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 18:58:22 -0000 --94eb2c13b51043eedc0549373273 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 21, 2017 at 6:39 AM, Sara Dickinson wrote: > Hi All, > > This update to the draft tries to address the recent comments: > > * Many editorial improvements by Paul Hoffman > > * Included discussion of malformed packet handling > > * Improved Appendix C on Comparison of Binary Formats > > * Now using C-DNS field names in the tables in section 8 > > * A handful of new fields included (CDDL updated) > > * Timestamps now include optional picoseconds > > * Added details of block statistics > > Regards > > Sara. > > > On 21 Feb 2017, at 11:36, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Domain Name System Operations of the > IETF. > > > > Title : C-DNS: A DNS Packet Capture Format > > Authors : John Dickinson > > Jim Hague > > Sara Dickinson > > Terry Manderson > > John Bond > > Filename : draft-ietf-dnsop-dns-capture-format-01.txt > > Pages : 48 > > Date : 2017-02-21 > > > > Abstract: > > This document describes a data representation for collections of DNS > > messages. The format is designed for efficient storage and > > transmission of large packet captures of DNS traffic; it attempts to > > minimize the size of such packet capture files but retain the full > > DNS message contents along with the most useful transport metadata. > > It is intended to assist with the development of DNS traffic > > monitoring applications. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-01 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Is it possible to have a case where the software does not know if promiscuous mode was enabled ? If so, we should allow for an "unspecified" or "unknown" code for "promisc" Perhaps a pcap to C-DNS converter would have this issue, if the pcap format does not include "promisc" info? -- Bob Harold --94eb2c13b51043eedc0549373273 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 21, 2017 at 6:39 AM, Sara Dickin= son <sara@sinodun.com> wrote:
Hi All,

This update to the draft tries to address the recent comments:

* Many editorial improvements by Paul Hoffman

* Included discussion of malformed packet handling

* Improved Appendix C on Comparison of Binary Formats

* Now using C-DNS field names in the tables in section 8

* A handful of new fields included (CDDL updated)

* Timestamps now include optional picoseconds

* Added details of block statistics

Regards

Sara.

> On 21 Feb 2017, at 11:36, = internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Domain Name System Operations of the = IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: C-DNS: A DNS Packet Capture Format
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = John Dickinson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Jim Hague
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Sara Dickinson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Terry Manderson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 John Bond
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dnsop-dns-capture-format-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 48
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-02-21
>
> Abstract:
>=C2=A0 =C2=A0This document describes a data representation for collecti= ons of DNS
>=C2=A0 =C2=A0messages.=C2=A0 The format is designed for efficient stora= ge and
>=C2=A0 =C2=A0transmission of large packet captures of DNS traffic; it a= ttempts to
>=C2=A0 =C2=A0minimize the size of such packet capture files but retain = the full
>=C2=A0 =C2=A0DNS message contents along with the most useful transport = metadata.
>=C2=A0 =C2=A0It is intended to assist with the development of DNS traff= ic
>=C2=A0 =C2=A0monitoring applications.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.o= rg/doc/draft-ietf-dnsop-dns-capture-format/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/<= wbr>draft-ietf-dnsop-dns-capture-format-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-dnsop-dns-capture-format-01
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>


Is it possible to have a case wher= e the software does not know if promiscuous mode was enabled ?=C2=A0 If so,= we should allow for an "unspecified" or "unknown" code= for "promisc"

Perhaps a pcap to C-DNS converter would have this issue,= if the pcap format does not include "promisc" info?

--=C2=A0
Bob Harold

=

--94eb2c13b51043eedc0549373273-- From nobody Thu Feb 23 15:24:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518B71296A2 for ; Thu, 23 Feb 2017 15:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 iCFwTjxZZj2P for ; Thu, 23 Feb 2017 15:24:37 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67A7129B08 for ; Thu, 23 Feb 2017 15:24:35 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 139683493CF for ; Thu, 23 Feb 2017 23:24:33 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 032E2216C1C; Thu, 23 Feb 2017 23:24:33 +0000 (UTC) Date: Thu, 23 Feb 2017 23:24:32 +0000 From: Evan Hunt To: dnsop@ietf.org Message-ID: <20170223232432.GA41294@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [DNSOP] order of records in DNAME responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 23:24:38 -0000 RFC 6672 saith: A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME RR is synthesized and included in the answer section when the DNAME is employed as a substitution instruction. The DNSSEC specification ([RFC4033] [RFC4034] [RFC4035]) says that the synthesized CNAME does not have to be signed. The signed DNAME has an RRSIG, and a validating resolver can check the CNAME against the DNAME record and validate the signature over the DNAME RR. The phrase "included in", as opposed to "appended to", provides no guidance about the order in which records appear, so presumably it's legal to have the synthesized CNAME appear first and the DNAME from which it was synthesized afterward. Most implementations, however, do send the DNAME first. We had a problem with BIND a while back when we encountered a server that didn't. BIND processes the RRsets in an answer in the order they're received (I suspect nearly all resolvers do this). In this case, the decisions about how to validate and cache the CNAME went wrong because we didn't have the flag set saying we'd previously seen a DNAME. We rejiggered the code so it wouldn't care about the order of records anymore (incidentally, and embarrassingly, introducing another bug in the process, but that's another story). It would have been simpler and more painless if we could have just treated this condition as a FORMERR. I'd like to start a discussion of that now. Does anyone have a problem with the idea of clarifying the protocol here, saying that the order of records in the answer section of a chaining response is significant, and in particular, that a DNAME MUST precede the corresponding synthesized CNAME? -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Fri Feb 24 02:40:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F985129678 for ; Fri, 24 Feb 2017 02:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 qmIuVjhkwIrO for ; Fri, 24 Feb 2017 02:40:31 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6D6129688 for ; Fri, 24 Feb 2017 02:40:31 -0800 (PST) Received: from [192.168.8.180] (firewall.vs.uni-duisburg-essen.de [134.91.78.130]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id v1OAeSLI023518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 24 Feb 2017 11:40:29 +0100 To: dnsop@ietf.org References: <20170223232432.GA41294@isc.org> From: =?UTF-8?Q?Matth=c3=a4us_Wander?= Organization: =?UTF-8?Q?Universit=c3=a4t_Duisburg-Essen?= Message-ID: <8c600688-2ec3-141e-82af-d0b73a9ca865@uni-due.de> Date: Fri, 24 Feb 2017 11:40:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170223232432.GA41294@isc.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050009030909050807050806" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Archived-At: Subject: Re: [DNSOP] order of records in DNAME responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 10:40:36 -0000 This is a cryptographically signed message in MIME format. --------------ms050009030909050807050806 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable * Evan Hunt [2017-02-24 00:24]: > I'd like to start a discussion of that now. Does anyone have a problem= > with the idea of clarifying the protocol here, saying that the order of= > records in the answer section of a chaining response is significant, an= d in > particular, that a DNAME MUST precede the corresponding synthesized CNA= ME? Do you mean clarifying as in "how it always was meant to be but stated in unclear words" or as in "change to protocol"? In the latter case, you'd still need code to parse responses from implementations that don't make assumptions about the order of records. Regards, Matt --------------ms050009030909050807050806 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EKowggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQw NzIyMTIwODI2WhcNMTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZO LVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xv YmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTD llA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1 OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8B r3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9 bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSa cXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT 1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1UdIARbMFkwEQYPKwYBBAGB rSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAQEEAwEwDwYNKwYB BAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1odHRwOi8vcGtp MDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEEbDBqMCwG CCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEFBQcw AoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhth Jxb/w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvN TVx07iHydQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEs jmpttzUCGc/1OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6h L5Kp2AvGhB8Exuse6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtU FzCCBa4wggSWoAMCAQICBxekJLcH4EswDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUx EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1W ZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA1MjcxNDU0MzFaFw0xOTA3MDkyMzU5MDBa MIHGMQswCQYDVQQGEwJERTEkMCIGA1UEChMbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2Vu MTUwMwYDVQQLEyxaZW50cnVtIGZ1ZXIgSW5mb3JtYXRpb25zLSB1bmQgTWVkaWVuZGllbnN0 ZTEsMCoGA1UEAxMjVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuIENBIC1HMDExLDAqBgkq hkiG9w0BCQEWHWNhYWRtaW5AdW5pLWR1aXNidXJnLWVzc2VuLmRlMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAq5XrJk5ojJCsz7hyCQ1KcaY4gpDy9fH6KQvQrnuJ9cUQcT50 hLLCP9lwG+JB1qyZpT43dtvNT9h5iEJGo/pjzsNMRpM2Gp/6ykW/IL8G+L/3CYQu0yIqD00O zX73zIOYaDWFu5nMpABGNHhZTvNHSxzSyzFEJvFUcTw0vbA5R4CFGnZjNWDZICdzwdH9A6ke 1oi6MoIC3b8SGQ5Ap3BaZIW67311NJEFVHI/JDDRuReRIDVGv9ZE6anzlPt4wIpGDD5T4X1u Dbym0qZvKeQW0RyUJbXttKU3lhRgGrb+kYztdHlh6D/PJUvaojph/pJP3Kqj9rcz6OGhOtgY houDiQIDAQABo4ICCjCCAgYwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYw EQYDVR0gBAowCDAGBgRVHSAAMB0GA1UdDgQWBBRmZryWm0hN6N28IqemW9WoQZ+V7jAfBgNV HSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAoBgNVHREEITAfgR1jYWFkbWluQHVuaS1k dWlzYnVyZy1lc3Nlbi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5k Zm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsG AQUFBwEBBIHKMIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1At U2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFs LXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2Rw Mi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEAJjyWphFD/Nq+YmFq+yvRvPu2yCPO/LAXfUUMyWFc/EgfvSuUuNnz K49FHY8eFo0i60wVvKs52yfRsdOhAZjga5gnOlx5lx97Ovifn0O8WUsPukaGTWjF6J2KEE6N 62tg6K1zU6MHktel6FaLCmW6XmCWA9PbYkURzYylYPgQyx4fT7H57I9IXQQhZNu8F8OKosM3 MWFsE1QhLgqV3VC8zKxVBWgS5Bblw2t4Gp7tCWpCC6NAibSzvihD5TpD3ZTcecC329+CSVkY 34OlS6LtuFXXxJCETi4XzyZeLnxE0FGNvnb02QEZURNR6S4lmcRxB685FClXNU96enn9Lu3K JTCCBhswggUDoAMCAQICBxmU245GdXUwDQYJKoZIhvcNAQELBQAwgcYxCzAJBgNVBAYTAkRF MSQwIgYDVQQKExtVbml2ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4xNTAzBgNVBAsTLFplbnRy dW0gZnVlciBJbmZvcm1hdGlvbnMtIHVuZCBNZWRpZW5kaWVuc3RlMSwwKgYDVQQDEyNVbml2 ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4gQ0EgLUcwMTEsMCoGCSqGSIb3DQEJARYdY2FhZG1p bkB1bmktZHVpc2J1cmctZXNzZW4uZGUwHhcNMTUwNjA4MDkxODU0WhcNMTgwNjA3MDkxODU0 WjBqMQswCQYDVQQGEwJERTEkMCIGA1UECgwbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2Vu MRowGAYDVQQLDBFWZXJ0ZWlsdGUgU3lzdGVtZTEZMBcGA1UEAwwQTWF0dGhhZXVzIFdhbmRl cjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKuZL9zfm3+ltyC1RoY6p4gwKVcW tz5gJ5rYGBN/15R4V8gsbxr7fA6Depc9K5FQm2bFWHxPWCo8clQ7jwWxTp8S3sCzyqbGNZbC e4PhaGOYOBVoGKT2rU1es168AHtgYXrEXw/3ias4ZknAwCQdo419uuvfvZR7EZJ56tc6u42V IstJ8DeT1DO6DIXw7hGvUFiq6QlCdhI/Mz0xv9SSsx2jEqqSikr7745qGXRvQv6D9wM9APTE /AIT260MuMjFktvIyfUjHrCO7GtLbvz6saW/Tnf0qRN/tAd8MSgpDv861NC1b0eYpHeT5ouQ 2awgssXSSV1d/C1UI1ZS2CuZZ4UCAwEAAaOCAmcwggJjMEAGA1UdIAQ5MDcwEQYPKwYBBAGB rSGCLAEBBAMDMBEGDysGAQQBga0hgiwCAQQDATAPBg0rBgEEAYGtIYIsAQEEMAkGA1UdEwQC MAAwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4E FgQUsuTmt3sT/g9SedrlhdVg7DRYQuAwHwYDVR0jBBgwFoAUZma8lptITejdvCKnplvVqEGf le4wJgYDVR0RBB8wHYEbbWF0dGhhZXVzLndhbmRlckB1bmktZHVlLmRlMIGXBgNVHR8EgY8w gYwwRKBCoECGPmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWR1aXNidXJnLWVzc2VuLWNh L3B1Yi9jcmwvY2FjcmwuY3JsMESgQqBAhj5odHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1k dWlzYnVyZy1lc3Nlbi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB5QYIKwYBBQUHAQEEgdgwgdUw MwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBO BggrBgEFBQcwAoZCaHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmktZHVpc2J1cmctZXNzZW4t Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0ME4GCCsGAQUFBzAChkJodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL3VuaS1kdWlzYnVyZy1lc3Nlbi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJ KoZIhvcNAQELBQADggEBAGmHuL7MZ71iI9bFasDBqkFE1ngRPUEbh1rDRAw3xYIv2ZJ6ReV2 taXKXQn9g0uhPsHJ6HZTgE/AjN07EynrPR8Lk9Hyg2tIvAxTTlGMLxTCp+baJfNAp92adwWp cdsRiCTgOCmoNwONPwCcnnf79bVT3Ncpm4A3E+qWjpp0JKE8zr1VzyKlUKBAZlY9c80myOyX i+o3fdDIFhS7XawPM6TlGiC+ZWwCkB3m2ZatKDqjtmC8xhMivoo1muWVNS+RzTphxJQKiTaR h9pfPqDt7LA/Hry2YXH7305UnUwLJoFGCaLBLDXgOEthz5OUvjIx2QMeOzv3LOnrQ6UOqU3j 0WQxggSnMIIEowIBATCB0jCBxjELMAkGA1UEBhMCREUxJDAiBgNVBAoTG1VuaXZlcnNpdGFl dCBEdWlzYnVyZy1Fc3NlbjE1MDMGA1UECxMsWmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0g dW5kIE1lZGllbmRpZW5zdGUxLDAqBgNVBAMTI1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3Nl biBDQSAtRzAxMSwwKgYJKoZIhvcNAQkBFh1jYWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5k ZQIHGZTbjkZ1dTANBglghkgBZQMEAgEFAKCCAqUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTcwMjI0MTA0MDI2WjAvBgkqhkiG9w0BCQQxIgQgMq8+Oyay DPxXqZJ3JrzIP6MPeOl8VF2dKkIyvxkFyaIwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQsw CQYDVQQGEwJERTEkMCIGA1UEChMbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuMTUwMwYD VQQLEyxaZW50cnVtIGZ1ZXIgSW5mb3JtYXRpb25zLSB1bmQgTWVkaWVuZGllbnN0ZTEsMCoG A1UEAxMjVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuIENBIC1HMDExLDAqBgkqhkiG9w0B CQEWHWNhYWRtaW5AdW5pLWR1aXNidXJnLWVzc2VuLmRlAgcZlNuORnV1MIHlBgsqhkiG9w0B CRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxJDAiBgNVBAoTG1VuaXZlcnNpdGFldCBEdWlz YnVyZy1Fc3NlbjE1MDMGA1UECxMsWmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0gdW5kIE1l ZGllbmRpZW5zdGUxLDAqBgNVBAMTI1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3NlbiBDQSAt RzAxMSwwKgYJKoZIhvcNAQkBFh1jYWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5kZQIHGZTb jkZ1dTANBgkqhkiG9w0BAQEFAASCAQA+ZAchf25JSW5Sc2onp2sgwifbeO5rex9Bdix09OWl knqG9FhZhTgZSwq6pBb1BQwYycOGTwR0ejNCXmy5pqlIlOCebaNuohCceJpbK8V31s3ln2W/ FsiGh2YuH2u1LLu95OUpnKaMFeu/+y64uoe1KNXSDA9vtzWl1NbJsFEEBff8fN9ypbKUS8PG IG3PFjObiWJuOL2y6fb6yrDuxY4H+iDjz1P/8pT3DEsUxC7MMzmRB8Vj4gWpxtenWVCvDwfp FhHxIBR1KzAPZSoOyO1St6XDJTZqx4w4zllVxijh29CeBidF74lgHV+8LggaZ+4rrWomF4bw rJGhh8fAOXZsAAAAAAAA --------------ms050009030909050807050806-- From nobody Fri Feb 24 06:46:35 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE81129865 for ; Fri, 24 Feb 2017 06:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 9NkgCD_OrARc for ; Fri, 24 Feb 2017 06:46:32 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6E5129DCD for ; Fri, 24 Feb 2017 06:46:32 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 24 Feb 2017 06:46:30 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Fri, 24 Feb 2017 06:46:29 -0800 From: Edward Lewis To: Evan Hunt , "dnsop@ietf.org" Thread-Topic: [Ext] [DNSOP] order of records in DNAME responses Thread-Index: AQHSjiwD4KoT0bB3kEid/D7WYDU4y6F4b4MA Date: Fri, 24 Feb 2017 14:46:28 +0000 Message-ID: <475CA1CA-E1D3-44D8-AE4D-6629A52C068C@icann.org> References: <20170223232432.GA41294@isc.org> In-Reply-To: <20170223232432.GA41294@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3570774390_1385830826" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] order of records in DNAME responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 14:46:35 -0000 --B_3570774390_1385830826 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 2/23/17, 18:24, "DNSOP on behalf of Evan Hunt" wrote: >I'd like to start a discussion of that now. Does anyone have a problem >with the idea of clarifying the protocol here, saying that the order of >records in the answer section of a chaining response is significant, and in >particular, that a DNAME MUST precede the corresponding synthesized CNAME? Protocol Specification Wars Episode MMCMLXVII A long, long time ago in a galaxy far, far away... >From a time when I spent a lot of attention on the section titled "The Algorithm" in "Domain names - concepts and facilities", that is section 4.3.2 of RFC 1034, I was reminded by one of the originators of the protocol that the RFCs were intended to capture the spirit of the protocol, that passages such as that in 4.3.2 weren't crafted even to the point of being pseudo-code. There were merely spirit guides. Since then I've thought of the RFCs as guides to how to enable interoperability between implementations rather than standards documents with testable criteria for compliance. (As an engineer and one-time coder, I wanted spec docs, tried to write that way. I'm sympathetic to that desire, but, the IETF was founded to promote interoperability not solve user stories.) I'm just throwing that out as a point of history, unsupported by any reference because it was either in person or in private email. To me it explains how the, at least, early documents were prepared, with "earlier" meaning lower in RFC series number. The reason I point this out is that the order of records in a section has been famously undefined, with the convention of supporting round robin (an undocumented feature of the protocol) hanging around, for all of eternity. I can see an implementation recommendation note because it makes sense, but, if we use the old rule of "for interoperability" I don't see specifying the order of records as necessary. I also think that goats have already left the burning barn on this. Going forward code might put the DNAME ahead of the CNAME, but if past code doesn't, going forward code must account for that. It's the same for compression of domain names in RDATA - despite originally being limited to the first set of resources records, later code expanded it to the point that there's a set of resource records than must be expected to be compressed incoming and never compressed outgoing. All in all, I think the suggestion makes sense. But there are other cases where the original definitions are "too loose for comfort" to fix as well. And, to spread fear, uncertainty and doubt, once we try to plug holes there's the ever-present chance we create a rift in the protocol. Not to mention the difficulties in writing so-called clarification documents. They aren't all that pleasant... --B_3570774390_1385830826 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUzBrBAQD8pLJy9KCL eT98J1tze/kwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw MjI0MTQ0NjMwWjANBgkqhkiG9w0BAQEFAASCAQC+ZPSFuQjX61iKvZh28rmbb1i0139RyZCK MLZQYK3lPA/hSKmiGabov+PfLJyZ3kOCP93VHQIIAP+bAd0C1squxIowmrQrLCNwgFSRD+OO 3EXIRfT0etA7Bi3BtUdpm9Aa12/sBjGLn6p2KdavWOWXgsJJXlUtM9fiF8lWh7F6XkjzhjL7 Yjdiv1HfCNvCP5hL+k8QNShsWVx/oBraQfUDAtlAZHFAfFAQDwZvRagEga/W6Kj4H/0wfeLt tmf43osaiIkO+d0hrqZtycIGh2IzJO+FvpEPZzm7MCkd+KLRveKKsI9eWzqRIDei85C+cVDY tj6slZhufKayJijPaWgP --B_3570774390_1385830826-- From nobody Fri Feb 24 09:00:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8C11293E4 for ; Fri, 24 Feb 2017 09:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 Vif2nxyQHOgt for ; Fri, 24 Feb 2017 09:00:35 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2589A1293EE for ; Fri, 24 Feb 2017 09:00:35 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5A4723494AE; Fri, 24 Feb 2017 17:00:32 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 4D73C216C1C; Fri, 24 Feb 2017 17:00:32 +0000 (UTC) Date: Fri, 24 Feb 2017 17:00:32 +0000 From: Evan Hunt To: =?iso-8859-1?Q?Matth=E4us?= Wander Message-ID: <20170224170031.GA55999@isc.org> References: <20170223232432.GA41294@isc.org> <8c600688-2ec3-141e-82af-d0b73a9ca865@uni-due.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8c600688-2ec3-141e-82af-d0b73a9ca865@uni-due.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] order of records in DNAME responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:00:36 -0000 On Fri, Feb 24, 2017 at 11:40:26AM +0100, Matthus Wander wrote: > Do you mean clarifying as in "how it always was meant to be but stated > in unclear words" or as in "change to protocol"? I meant the former. I wasn't involved, but I suspect that DNAME-first was the intended behavior all along, and nobody thought to mention it. However, if the group doesn't agree, then I guess I mean the latter. > In the latter case, you'd still need code to parse responses from > implementations that don't make assumptions about the order of records. What I'd like is to be able to send FORMERR with a clear conscience. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Fri Feb 24 09:24:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704BC129424 for ; Fri, 24 Feb 2017 09:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 h_U6jI_I5Avo for ; Fri, 24 Feb 2017 09:24:07 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE491293FF for ; Fri, 24 Feb 2017 09:24:07 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 24 Feb 2017 09:24:04 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Fri, 24 Feb 2017 09:24:04 -0800 From: Edward Lewis To: Evan Hunt , =?utf-8?B?TWF0dGjDpHVzIFdhbmRlcg==?= Thread-Topic: [Ext] Re: [DNSOP] order of records in DNAME responses Thread-Index: AQHSjopz6zsF1qRoj0WNLXZT5U75PKF46AsA//+ywIA= Date: Fri, 24 Feb 2017 17:24:04 +0000 Message-ID: <87D4CC1A-E173-450E-8E4C-CAD9598716D9@icann.org> References: <20170223232432.GA41294@isc.org> <8c600688-2ec3-141e-82af-d0b73a9ca865@uni-due.de> <20170224170031.GA55999@isc.org> In-Reply-To: <20170224170031.GA55999@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3570783843_1746629285" MIME-Version: 1.0 Archived-At: Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] [Ext] Re: order of records in DNAME responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:24:08 -0000 --B_3570783843_1746629285 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 2/24/17, 12:00, "DNSOP on behalf of Evan Hunt" wrote: > On Fri, Feb 24, 2017 at 11:40:26AM +0100, Matth=C3=A4us Wander wrote: > > Do you mean clarifying as in "how it always was meant to be but stat= ed > > in unclear words" or as in "change to protocol"? > =20 > I meant the former. I wasn't involved, but I suspect that DNAME-first > was the intended behavior all along, and nobody thought to mention it. > However, if the group doesn't agree, then I guess I mean the latter. I wasn't there either...but in general, whenever you want to "clarify" what= was intended by stating it explicitly, someone somewhere will claim it is a= change and not a clarification. That was my experience with wild cards and= to a lesser extent zone transfer (but someone else had and is why that docu= ment fell to me). > =20 > > In the latter case, you'd still need code to parse responses from > > implementations that don't make assumptions about the order of recor= ds. > =20 > What I'd like is to be able to send FORMERR with a clear conscience. Given the lax rules of the field, I'd lean to saying you can't. For DNSSEC this was a pain. Because we couldn't outlaw round robin we had = to sort the records in the set as it arrived. All we could do was simplify = the sorting comparison but not having to copy the data, sort, work, and disp= ose of the copy to retain the original ordering. The copy came to be 100% w= asted cycles as you had to retain the original order.=20 --B_3570783843_1746629285 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU1ixWObeWIUq3KbyP b7apy8w6zncwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw MjI0MTcyNDAzWjANBgkqhkiG9w0BAQEFAASCAQCPj3Cf2DxCDi00sBiz8DIn17iFO9+WjHzA dpW3nIbp9pCQM+D3HHVi8LGcFs6KGwEsu/6ukeloeVKLiy3V01Tasa1Lfj7KIr0QP0pX8y88 Prpk32Ra+DycJgUKYTBAehqNfFEeKLNyonDZ361EacAvouihmFsO/wzdWMjjRcmGfKKRdBuo R60sCMtyv6u3AkWhelQ/G9zcRDnYwMKl6oy4m7zdX0OJKlfm2IQQe30Kp2MLxi5QP+NxiCtT BY+B9oCKWfSePgMF66WOyr4nzk045npNAuqRbozRQOObkEnrJutUBSNgfdqbv/m+ZBdLHbkE wacQ/0qKWihM+hMK2JTv --B_3570783843_1746629285-- From nobody Fri Feb 24 09:33:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865B912943F for ; Fri, 24 Feb 2017 09:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 4jdttSHt6Okj for ; Fri, 24 Feb 2017 09:33:01 -0800 (PST) Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FEF0129424 for ; Fri, 24 Feb 2017 09:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=866; q=dns/txt; s=VRSN; t=1487957581; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=EIenDZEA23JYyNn75FzUOvOd6BjD1ZPTK5XxUsf/154=; b=Q0WsgzYGrU2VSsDttha443gYj27gpWgcUHXQIkySzMcT7gyF/0pQHsld J9TUBhBexioVi8StT9l8DeWZkQ3giFpFtCvF3l6C+9b+HLJ/0s0LV+kne S88qJCSSwgesluKzGzc0qOQEflFLO7blEXMoJHjXeqOCnHdFU1HtRxiUu BVk9YxOhp37etDu7rmQU6pwbjWHs83zU9Gs1s7iqyaL+weZJWV7CNi6aR gRMkXQ7M0EaaGbAdEHJZLgSf13QZ+plxD51RDyVHuKas9u0Cqp8YqjE6p YQKQx+x8xnzEsyhrQyaKqomDa8K6H6lJBDa9RgIjDTJjnRIv04/iBxzKG A==; X-IronPort-AV: E=Sophos;i="5.35,201,1484006400"; d="scan'208";a="1630794" IronPort-PHdr: =?us-ascii?q?9a23=3A2z7XUhOCpzDkhJqnSOEl6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0Iv74rarrMEGX3/hxlliBBdydsKMZzbCO+Pm4AyQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9GiTe5Yb5+Ngu6oRneusULnYduNLs6xwfUrHdPZ+?= =?us-ascii?q?lY335jK0iJnxb76Mew/Zpj/DpVtvk86cNOUrj0crohQ7BAAzsoL2465MvwtRne?= =?us-ascii?q?VgSP/WcTUn8XkhVTHQfI6gzxU4rrvSv7sup93zSaPdHzQLspVzmu87tnRRn1gy?= =?us-ascii?q?oBKjU38nzYitZogaxbvhyvugB/zYDXboGbNvV+f7/Sc9wVSmdaQsZRTilBDp+g?= =?us-ascii?q?Y4cTEeYMO/tToYnnp1sJqBuzHQegC+PxxT9TnX/5w6k60/85HQrb0gIgAsgBsH?= =?us-ascii?q?LKo9n7KawfVv26zafWwjXYdPNZxzP96JPTfxA/v/6MR7NwcdHQyUkgEQPJlEmf?= =?us-ascii?q?qYvgPz6M0OkGrmuV7/J4WO6yl2IrsRx9rzqhy8s2l4XEhowYxkra+Sh2z4s5Pc?= =?us-ascii?q?C0RFJhbdK5EpZduTuWO5Z2T888WW1ltyA3waAct5GhZigF0pEnygbaa/yAboeH?= =?us-ascii?q?/AruVP2UITdknHJlf6+/hwqq/Uig1OL8Us603U5RoSpflNnAq3QN1hPW6sedS/?= =?us-ascii?q?t9+kCh2SuT1wzP9+1IO140mrTBK54g2b4wl5UTsULZEiDqn0X2ibeadkQi+ue2?= =?us-ascii?q?9+TqeqjqqoOGO4NpiAzzPL4iltG/DOk2KAQCQWeW9Ouk2L3m50L5QbFKjvMskq?= =?us-ascii?q?netZDXPdkUp6CnDA9OyYYs9RK/Dyy93dQGg3YHNlNFeAmGj4jmPVHCOuz3DfC6?= =?us-ascii?q?g1i0ijdk2+jGPqH9ApXKNnXMjbHhfa16605E0wczzM5Q545aCr0bJ/LzQEDxvs?= =?us-ascii?q?TCDhAlKwy03/rnCNJl24wAQ22AHq+ZPbjTsV+T+u0jOe6MZJUauGW1F/9wyuDn?= =?us-ascii?q?izcZhFkBNf2k1JAXQHGjFbJhOUrPMlT2hdJUW1gHpREzSPeuwHGfWDheLT7mU7?= =?us-ascii?q?0x/So2DJmOE4rZR5usj7rH1yC+SM4FLltaA0yBRC+7P76PXO0BPXqf?= X-IPAS-Result: =?us-ascii?q?A2GHAQDobbBY//SZrQpdGwEBAQMBAQEJAQEBFwEBBAEBCgE?= =?us-ascii?q?BhQ8HjVyRX5Mmgg+CDYYiAoJNGAEBAQEBAQEBAQEBAoEHgjMggh0BAQEBAgE6P?= =?us-ascii?q?wULAgEIDQEKHhAyJQIEDgWJbLBhi0EBAQEBAQEBAwEBAQEBAQEBAQEBHYZNggS?= =?us-ascii?q?CaoRUgzSCMQWcFAYBihWZJYNfj04fgTpUFU8Bhjt1iRyBDQEBAQ?= Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v1OHWx54001130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Feb 2017 12:33:00 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Fri, 24 Feb 2017 12:32:59 -0500 From: "Wessels, Duane" To: Evan Hunt Thread-Topic: [EXTERNAL] [DNSOP] order of records in DNAME responses Thread-Index: AQHSjiwHIOprHxaxvUai48fjOWiAEqF4v4yA Date: Fri, 24 Feb 2017 17:32:58 +0000 Message-ID: <3B843A1D-DB10-4CDF-BF15-70588B392644@verisign.com> References: <20170223232432.GA41294@isc.org> In-Reply-To: <20170223232432.GA41294@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <45802EC27FF71A47AD389DD3D02427D2@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] order of records in DNAME responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:33:02 -0000 > On Feb 23, 2017, at 3:24 PM, Evan Hunt wrote: >=20 > I'd like to start a discussion of that now. Does anyone have a problem > with the idea of clarifying the protocol here, saying that the order of > records in the answer section of a chaining response is significant, and = in > particular, that a DNAME MUST precede the corresponding synthesized CNAME= ? Hi Evan, Even though I think "be liberal in what you accept" has been sort of harmfu= l, I've always felt that the ordering of RRsets in a message should not mat= ter at all. Also I worry that once we start clarifying ordering for the case you've pro= posed, we'll find a lot of other cases where ordering could be made to matt= er. CNAME and its target, for example. SRV and its target(s). RRSIGs and= the records they cover. NSEC* enclosers. And so on. DW From nobody Fri Feb 24 09:35:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9249D129437 for ; Fri, 24 Feb 2017 09:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 yJyECxBpcbj5 for ; Fri, 24 Feb 2017 09:35:21 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD62D129424 for ; Fri, 24 Feb 2017 09:35:21 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id E4E383493BC; Fri, 24 Feb 2017 17:35:19 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id D705D216C1C; Fri, 24 Feb 2017 17:35:19 +0000 (UTC) Date: Fri, 24 Feb 2017 17:35:19 +0000 From: Evan Hunt To: Edward Lewis Message-ID: <20170224173519.GB55999@isc.org> References: <20170223232432.GA41294@isc.org> <475CA1CA-E1D3-44D8-AE4D-6629A52C068C@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475CA1CA-E1D3-44D8-AE4D-6629A52C068C@icann.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] [Ext] order of records in DNAME responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:35:22 -0000 On Fri, Feb 24, 2017 at 02:46:28PM +0000, Edward Lewis wrote: > The reason I point this out is that the order of records in a section has > been famously undefined, with the convention of supporting round robin > (an undocumented feature of the protocol) hanging around, for all of > eternity. I can see an implementation recommendation note because it > makes sense, but, if we use the old rule of "for interoperability" I > don't see specifying the order of records as necessary. The order of RR's within an RRset is undefined and needs to remain so, but can there be constraints on the order of RRsets within a section? > I also think that goats have already left the burning barn on this. > Going forward code might put the DNAME ahead of the CNAME, but if past > code doesn't, going forward code must account for that. It took us a very long time to encounter the first server that did CNAME-first. Most are going to do DNAME-first because it's simpler to code that way: it's easier to append to a message than insert something into the middle. IMHO the problem is now big enough to see, but still small enough to step on by declaring we didn't mean for it to be legal. > Not to mention the difficulties in writing so-called clarification > documents. They aren't all that pleasant... Well, that's why I started with an email thread... -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Fri Feb 24 09:42:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31B1129451 for ; Fri, 24 Feb 2017 09:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 3OTNq75F2RCp for ; Fri, 24 Feb 2017 09:42:55 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC67D12944E for ; Fri, 24 Feb 2017 09:42:55 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 24 Feb 2017 09:42:53 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Fri, 24 Feb 2017 09:42:53 -0800 From: Edward Lewis To: Evan Hunt Thread-Topic: [DNSOP] [Ext] order of records in DNAME responses Thread-Index: AQHSjsRjcMawmep4l0OjbKVdxlvuxqF4n5uA Date: Fri, 24 Feb 2017 17:42:53 +0000 Message-ID: <4818EDE5-C093-47C0-8508-0740A47E5ECE@icann.org> References: <20170223232432.GA41294@isc.org> <475CA1CA-E1D3-44D8-AE4D-6629A52C068C@icann.org> <20170224173519.GB55999@isc.org> In-Reply-To: <20170224173519.GB55999@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3570784973_1385348195" MIME-Version: 1.0 Archived-At: Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] [Ext] order of records in DNAME responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:42:59 -0000 --B_3570784973_1385348195 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 2/24/17, 12:35, "Evan Hunt" wrote: > Well, that's why I started with an email thread... I'm certainly *not* saying: "Don't do it!" (Sorry for the double negative.) But the hours spent writing the code to handle the issue might be less than the hours spent "producing" the clarification document. ;) --B_3570784973_1385348195 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU9a9ag5lZdswdT/PN lTGI+6jyKu4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw MjI0MTc0MjUzWjANBgkqhkiG9w0BAQEFAASCAQBMyt2kZ1+iebmOsb+bw52EIyHeDFjbRHnC UBbThLbdcH65Q1nZ8SfZNRegO0YuJ+cSJmLI24tSHIa4N5m3Of2dtrOi2ueyg39Ass47IHL7 T0VbGgx6OlPTOvQaBSieQAf0U3kWpxZ5ltO5Tj6mprAhvISN6wr6emNUqZWsPclHNfB9og9m D4sSd+9bblojQZyeG1Avsrr0oo65lxRw0xkkt5TJpqLA/f3tuZSrdDpEkk6ccuAPrTBced0a e0JhLswTPtm+MtOcRf91gOUl1+y1e0V/u8Uj3vBMpzUm0wmGRTJFTOSHB/qK3kK7APT0WlaD x+A/nOic0WjARLE0Ff2C --B_3570784973_1385348195-- From nobody Sat Feb 25 11:52:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE2C1294AC for ; Sat, 25 Feb 2017 11:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zuXlDHS72NAF for ; Sat, 25 Feb 2017 11:52:17 -0800 (PST) Received: from smtp133.dfw.emailsrvr.com (smtp133.dfw.emailsrvr.com [67.192.241.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8169B1294A5 for ; Sat, 25 Feb 2017 11:52:17 -0800 (PST) Received: from smtp25.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 9B005C0137; Sat, 25 Feb 2017 14:52:16 -0500 (EST) X-Auth-ID: ogud@ogud.com Received: by smtp25.relay.dfw1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 0E349C0133; Sat, 25 Feb 2017 14:52:15 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-71-191-33-181.washdc.fios.verizon.net [71.191.33.181]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 25 Feb 2017 14:52:16 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Olafur Gudmundsson In-Reply-To: <20170224173519.GB55999@isc.org> Date: Sat, 25 Feb 2017 14:52:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4DAB3353-9DCF-44F5-B87F-13C10A88FCD5@ogud.com> References: <20170223232432.GA41294@isc.org> <475CA1CA-E1D3-44D8-AE4D-6629A52C068C@icann.org> <20170224173519.GB55999@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Edward Lewis , "dnsop@ietf.org" Subject: Re: [DNSOP] [Ext] order of records in DNAME responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 19:52:19 -0000 > On Feb 24, 2017, at 12:35 PM, Evan Hunt wrote: >=20 > On Fri, Feb 24, 2017 at 02:46:28PM +0000, Edward Lewis wrote: >> The reason I point this out is that the order of records in a section = has >> been famously undefined, with the convention of supporting round = robin >> (an undocumented feature of the protocol) hanging around, for all of >> eternity. I can see an implementation recommendation note because it >> makes sense, but, if we use the old rule of "for interoperability" I >> don't see specifying the order of records as necessary. >=20 > The order of RR's within an RRset is undefined and needs to remain so, = but > can there be constraints on the order of RRsets within a section? While I would love to say Yes to above, that can not be any stronger = than =E2=80=9CSHOULD=E2=80=9D=20 The old RFC=E2=80=99s are much less prescriptive than modern ones.=20 If we ever do a RFC2181-bis or followup work then this should be one of = the topics=20 There are basically two ways to handle it=20 - Prescribe order=20 - Dicate that whole section must be consumed and =E2=80=9Cordered=E2=80=9D= before processing. One corner case that I seen on couple of occasions is CNAME chain out of = order,=20 I have no idea how that can happen =E2=80=A6=20 >=20 >> I also think that goats have already left the burning barn on this. >> Going forward code might put the DNAME ahead of the CNAME, but if = past >> code doesn't, going forward code must account for that. >=20 > It took us a very long time to encounter the first server that did > CNAME-first. Most are going to do DNAME-first because it's simpler to > code that way: it's easier to append to a message than insert = something > into the middle. >=20 > IMHO the problem is now big enough to see, but still small enough > to step on by declaring we didn't mean for it to be legal. >=20 I was around the time DNAME was defined, and my recollection was that CNAME after DNAME was so obvious that no-one thought is was needed to = specify.=20 >> Not to mention the difficulties in writing so-called clarification >> documents. They aren't all that pleasant... >=20 > Well, that's why I started with an email thread=E2=80=A6 Thank you for bringing real issue to WG Olafur From nobody Mon Feb 27 07:45:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860D012A17A for ; Mon, 27 Feb 2017 07:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 iNCycx6N92GD for ; Mon, 27 Feb 2017 07:45:42 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7974412A177 for ; Mon, 27 Feb 2017 07:45:42 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Feb 2017 07:45:40 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 27 Feb 2017 07:45:39 -0800 From: Edward Lewis To: Olafur Gudmundsson , Evan Hunt Thread-Topic: [DNSOP] [Ext] order of records in DNAME responses Thread-Index: AQHSjsRjcMawmep4l0OjbKVdxlvuxqF6qeaAgAKL7gA= Date: Mon, 27 Feb 2017 15:45:39 +0000 Message-ID: References: <20170223232432.GA41294@isc.org> <475CA1CA-E1D3-44D8-AE4D-6629A52C068C@icann.org> <20170224173519.GB55999@isc.org> <4DAB3353-9DCF-44F5-B87F-13C10A88FCD5@ogud.com> In-Reply-To: <4DAB3353-9DCF-44F5-B87F-13C10A88FCD5@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3571037136_1126232802" MIME-Version: 1.0 Archived-At: Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] [Ext] order of records in DNAME responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 15:45:43 -0000 --B_3571037136_1126232802 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 2/25/17, 14:52, "Olafur Gudmundsson" wrote: >...can not be any stronger than =E2=80=9CSHOULD=E2=80=9D... And that is why it remains you "MUST" be liberal in what you accept. ;) --B_3571037136_1126232802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUhDYzTdd+92aK31hv HR2E0WojDKkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw MjI3MTU0NTM2WjANBgkqhkiG9w0BAQEFAASCAQCPU4KYxzce/zLJsn8K8ChgsGq75WXNeisZ E+FwxuCmt6NtV4DlTfJmkjGyxrPV9WS2XuvI9bL5s3ylCsIB5Mx7m4aPn5fsD2siF5lja9N8 Kf1iSyuooOBfwtqT0pHVAykcx4Edqa5GqEShhsmL1IenOP/h7foAW0CYLVOtWRM7m35PbfKt diBTLwtXD4h/yJn5aYeQjx69FEKoUMgJV2tCcPc6OQTsNNIghMVmnqNwE8NzrPjM/Fe2BPVU ybBd5jvRoFMHrzPvvavjgTWPxaT3vxehieutkTn/ZjNDKvYOUWTLClACU2xxjBZ/ye221hJ9 R3BX3C8J0PDkIFf2Dv7W --B_3571037136_1126232802-- From nobody Mon Feb 27 10:49:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63A4129B0F for ; Mon, 27 Feb 2017 10:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 A5KoR1JZb1y2 for ; Mon, 27 Feb 2017 10:49:09 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B0B127071 for ; Mon, 27 Feb 2017 10:49:09 -0800 (PST) Received: from [2001:470:1f09:d2::d83] (port=53946 helo=hagrid.localnet) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ciQM5-0001W3-ES; Mon, 27 Feb 2017 18:49:06 +0000 From: Jim Hague To: dnsop@ietf.org Date: Mon, 27 Feb 2017 18:48:59 +0000 Message-ID: <1649382.sfAXfZOMk1@hagrid> Organization: Sinodun Internet Technologies Ltd X-Face: "YyOu7Hab"VGm^bAO1; {iOPso3{hw9JL`&?c6?!@&m`z?E\ZMv; T44B_v+/9i''$IUz\h: 7+|+U\Sm3S)ajt}IU6bG#OB^ma3dQ%l4]6jGS1:=9N]LF\ZmxO!"2bQ}v@,\x?0{/mu; a, g3:!#KL>aL\D; )@?UJG=m@@vt; LJJxqV.w-.VxYKp-r1'$`0+>4D72C#o5(tax+Dp:0UWU ]+s_'{u[#cEm^9VXGTf0+#@VwB/%U?KWb~C<@19. References: <148767700983.32635.5525058061405932673.idtracker@ietfa.amsl.com> <1E671B09-B07B-451A-B18C-B96CBEFBE03D@sinodun.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = 50 Archived-At: Cc: Bob Harold , Sara Dickinson Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 18:49:11 -0000 On Thursday, 23 February 2017 13:58:18 GMT Bob Harold wrote: > Is it possible to have a case where the software does not know if > promiscuous mode was enabled ? If so, we should allow for an "unspecified" > or "unknown" code for "promisc" > > Perhaps a pcap to C-DNS converter would have this issue, if the pcap format > does not include "promisc" info? Thanks, that's a good point. Yes, it is certainly possible to not have a known promiscuous mode, and also of course in the case of a pcap conversion the interface is not known. We're discussing the best approach to handling this; whether to have specified 'unspecified' values, or specify that, since all config items in C-DNS are optional, values should only be present if definitely known. -- Jim Hague jim@sinodun.com Never trust a computer you can't lift. Sinodun Internet Technologies Ltd. +44 7941 697732 From nobody Tue Feb 28 13:19:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DA7128E18 for ; Tue, 28 Feb 2017 13:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec 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 1rfKNHFpbLXl for ; Tue, 28 Feb 2017 13:19:39 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 32DE3127601 for ; Tue, 28 Feb 2017 13:19:38 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id s186so39405361qkb.1 for ; Tue, 28 Feb 2017 13:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=m6VjVCQ1tUgqiybykx/6m49ppGexVnevXx8CofUy6cA=; b=QeSYaBBvG1UFJe21+oa3UbALHlzdb7TJkhESlLfgC54tUvpBJef5mFkH4vA2v8QoRt L1AXlPGFjP6RFE/7a7QCSiBXbFl89UiXfKuusS/kzZA5LxPyKmz7KFCLRRWSRDsWNLzx P6X/f42aExADTIjimL526WVy+Pnw9f7rfa8Ik= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=m6VjVCQ1tUgqiybykx/6m49ppGexVnevXx8CofUy6cA=; b=BTrXD4cj+aZWARpQE7VzVPrcVAspfKimt7Ki0hkJSNFa2yYMM4+V9gm248sy/E/pqY dfyoyv2+Xhs1mR7bdQKygvrOTlKdkwxQwrKi2VRDS6nCubdLrxRu6f6soh4+bNPcRLOk mZEYCMy6g9uegzYXSmKHrL+qEL5I0boedZJY+EGPXgfYY7dcDnMIGU9CvUmVnAapOFJF mUt5vT2VvUQec6nMYApt73T0FnU5Tpgi9nZrFDsUZ+t8nBPrmWTnWrPvMx42q3mfwUR/ +ppOTjCqeU7uRZyWmwyiXmnHnrctX6hX9Yl7RDODAHda6zueRsGQRO8P0t6fu5wDBJe2 0dTg== X-Gm-Message-State: AMke39nCBS21Ud5rinERQj2VH8zVJckmxGXyFKF6lOL15t/l8JhHI2bBKMG8OC05fdPPyQ== X-Received: by 10.200.50.112 with SMTP id y45mr5289318qta.75.1488316777723; Tue, 28 Feb 2017 13:19:37 -0800 (PST) Received: from [192.168.1.82] (host81-156-184-24.range81-156.btcentralplus.com. [81.156.184.24]) by smtp.gmail.com with ESMTPSA id j14sm1787136qtj.32.2017.02.28.13.19.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Feb 2017 13:19:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Roy Arends In-Reply-To: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> Date: Tue, 28 Feb 2017 21:19:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> To: dnsop X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:19:41 -0000 I have reviewed the draft. Since the last update of this draft, a full collision has been found.=20 Do the authors intend to update the draft to state that SHA1 SHOULD NOT = be used for DNSSEC signing (DNSKEY algorithm 5,6,7) and for DNSSEC = Delegation (DS and CDS algorithm 1) ? Please also refrain from using MUST- SHOULD+ and SHOULD-. Roy > On 5 Jan 2017, at 21:28, Tim Wicinski wrote: >=20 > All >=20 > Since we're having so much fun on adopting work, let's have another = one. We discussed this work in Seoul, and there was a solid hum on = adopting this work. >=20 > This starts a Call for Adoption for: > draft-wouters-sury-dnsop-algorithm-update >=20 > The draft is available here: > = https://datatracker.ietf.org/doc/draft-wouters-sury-dnsop-algorithm-update= / >=20 > Please review this draft to see if you think it is suitable for = adoption by DNSOP, and comments to the list, clearly stating your view. >=20 > Please also indicate if you are willing to contribute text, review, = etc. >=20 > This call for adoption ends: 19 January 2017 >=20 > Thanks, > tim wicinski > DNSOP co-chair >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue Feb 28 13:35:52 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11419129500 for ; Tue, 28 Feb 2017 13:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7uxCn0TTuT0 for ; Tue, 28 Feb 2017 13:35:48 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B01C126D73 for ; Tue, 28 Feb 2017 13:35:48 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vXsM42yFTz95; Tue, 28 Feb 2017 22:35:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1488317744; bh=r5WHX4fRLpYk4YYRp0SpyLrxq6VHdS1Hp9372jY0ov8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cFqSgaueW2IYWVIlTXRcCqIUM1VNZU5R/KEJDl58e7zlSavbEsPqE5VuCCsRtdu8z b+glLvFUs3z8oh+FIXwVU7jd7DHLm6R7At1GhCnAdVumN+usm5wLsc/3lqJuA5VYoQ NZocd4iidpPmtGgnQrUfVyBb+WgUlx4u/9cx7W5U= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wuJTxV9ka468; Tue, 28 Feb 2017 22:35:42 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 28 Feb 2017 22:35:41 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E2BB436A2; Tue, 28 Feb 2017 16:35:40 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E2BB436A2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D001C407E85F; Tue, 28 Feb 2017 16:35:40 -0500 (EST) Date: Tue, 28 Feb 2017 16:35:40 -0500 (EST) From: Paul Wouters To: Roy Arends In-Reply-To: Message-ID: References: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dnsop Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:35:50 -0000 On Tue, 28 Feb 2017, Roy Arends wrote: > Since the last update of this draft, a full collision has been found. > > Do the authors intend to update the draft to state that SHA1 SHOULD NOT be used for DNSSEC signing (DNSKEY algorithm 5,6,7) and for DNSSEC Delegation (DS and CDS algorithm 1) ? That seems a bit dramatic to this author :) We can't stuff PDF prefixes into this, there are a lot less bytes for an attacker to play with. > Please also refrain from using MUST- SHOULD+ and SHOULD-. For this SHA1 case or in general? I'd say we could update the DNSSEC Signing entry from MUST- to SHOULD NOT but I would leave SHA1 for DNSSEC validation at MUST-. There is a need to move people away from SHA1, but I don't think this specific attack changing anything with respect to DNSSEC. Paul From nobody Tue Feb 28 13:45:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FD51296B4 for ; Tue, 28 Feb 2017 13:45:10 -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] 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 rlxE8i4sB_3q for ; Tue, 28 Feb 2017 13:45:08 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29B8129537 for ; Tue, 28 Feb 2017 13:45:08 -0800 (PST) Received: from [10.32.60.87] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v1SLj5gF020172 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 28 Feb 2017 14:45:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.87] From: "Paul Hoffman" To: dnsop Date: Tue, 28 Feb 2017 13:45:06 -0800 Message-ID: <85834F4E-C2BB-4912-8275-3C006B1E41F3@vpnc.org> In-Reply-To: References: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:45:10 -0000 The recommendations in the document are completely unclear if it is talking about: - what should be in signer implementations - what should be in validator implementations - what someone who is starting to sign today SHOULD/MUST use - what someone who is already signing SHOULD/MUST use I think those four lists are probably different. Before the document is picked up by the WG, it would be good if it made clear which lists it is for. My personal feeling is that if we do the third, we should say MUST NOT with any SHA1 algorithm because they're going to get nailed in the future by people who refuse to validate it. If we do the fourth, I would say SHOULD NOT use now and SHOULD change within two years (or some moral equivalent of that). --Paul Hoffman From nobody Tue Feb 28 13:55:17 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D01126B6D for ; Tue, 28 Feb 2017 13:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3h5xzfrFvaJ for ; Tue, 28 Feb 2017 13:55:15 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B7B12009C for ; Tue, 28 Feb 2017 13:55:15 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vXsnX1JCHz95; Tue, 28 Feb 2017 22:55:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1488318912; bh=PMVkjAvEmqiAduiHCuzzJjn0+JCUxeLmW3V9c0VyBzk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Z520V0fGGrbwPBTKgqUX/DnnbVfGIo4xO6gmGZjF3VkDSdPzCf5CzGb8nB80nWEUR IQAf4f5ZbZo1ENQTEnLbtBkc36/dLlG2dkwTq5xEEY+xKsk3s98qUYR2+UxOuhkKAs 6UXbcbjw7TVVxdtm7WI4K0JNa9oJQaTqcyOIg7+0= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id dA1Fy4F_wdpd; Tue, 28 Feb 2017 22:55:06 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 28 Feb 2017 22:55:06 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7DE6436A2; Tue, 28 Feb 2017 16:55:05 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7DE6436A2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 680114168D46; Tue, 28 Feb 2017 16:55:05 -0500 (EST) Date: Tue, 28 Feb 2017 16:55:05 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <85834F4E-C2BB-4912-8275-3C006B1E41F3@vpnc.org> Message-ID: References: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> <85834F4E-C2BB-4912-8275-3C006B1E41F3@vpnc.org> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dnsop Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:55:16 -0000 On Tue, 28 Feb 2017, Paul Hoffman wrote: > The recommendations in the document are completely unclear if it is talking > about: > > - what should be in signer implementations > - what should be in validator implementations That is clearly Section 3 in two seperate columns > - what someone who is starting to sign today SHOULD/MUST use Obviously pick one of the mandatory-to-implement DNSSEC Signing" algortihms of Sesction 3. Obviously, picking a MUST over a SHOULD would be a safer bet. > - what someone who is already signing SHOULD/MUST use Try to do the same as above, provided their software is fully testing and can handle algorithm rollovers. > I think those four lists are probably different. The Signer / Validator column is obviously different, as the validator needs to deal with the long tail versus insecurity, whereas the signer software can be a little more aggressive in dropping support for weak things. I don't see why the recommendation of "already signing" and "newly signing" should be different, other then "ensure you can do an algorithm rollover". > Before the document is > picked up by the WG, it would be good if it made clear which lists it is for. I do not think that is needed. > My personal feeling is that if we do the third, we should say MUST NOT with > any SHA1 algorithm because they're going to get nailed in the future by > people who refuse to validate it. If we do the fourth, I would say SHOULD NOT > use now and SHOULD change within two years (or some moral equivalent of > that). I don't think adding that much more flavours and granularity brings more clarity. Heck, someone just said that our + and - symbols was already too much granularity :P And then we have some software people who say "we will never remove anything because that can break our users' scripts"..... Paul From nobody Tue Feb 28 14:08:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDC61293E8 for ; Tue, 28 Feb 2017 14:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec 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 E01z3an0-ZtL for ; Tue, 28 Feb 2017 14:08:09 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49255127A90 for ; Tue, 28 Feb 2017 14:08:09 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id u188so41492940qkc.2 for ; Tue, 28 Feb 2017 14:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=mG88h5xoaTztA0nZ73ZLMzgPSqLNG/H8c3EfSM4D1mE=; b=hpYfwX9SoQo7Tahb+C2P/jI16gU3MBok398gu6WGqxCizzgllN6liJSyWM4ruP5Z+g ajgSKx0eFev1eUZUKV/jaDcFzw5N/d1Jv87qY9W4ozxmxrfaIHCFvCXXnLJrckIYWbVA dtOnXmVjiSJznsZ4ZlYofsPiEPt50BxMvw2KU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=mG88h5xoaTztA0nZ73ZLMzgPSqLNG/H8c3EfSM4D1mE=; b=I1AzHKr54nPQpsEDMbBFAQ5OwZxin9CFODEYqJR/G7X6tdn9mPp5HHUMNvr7u61H5L zlSvPoj8lmmQ1wUQZyoLEFlbEwBQl+STdZr9QjD0q7DWSSBusFyYEAw4dFmQXtEOu0hJ Y76SirpN141R83gztDmaBRuqre4w/8Ra4IiGhdTxWHGxxQwvvozg+BT2rrFj6BkhgRRT ++hT0xNwu4q5cWgyX5Zep6SiUlu4PCAuOjaHefORWtdxnxRUgjw94ElbzqT8834WQb7J Py2z7V2Vasr8P33FXUlvjICO8MbKk1mY/u0HOxHvD+6pABMMICv/c3ZA3kZWmGp9+59i 5DdQ== X-Gm-Message-State: AMke39nBD3oIzLQakGhWTvYy7lvtc4m9f9H6ShSiWDGo2rVfLfWttELvWNCWtBeAutpqVw== X-Received: by 10.55.204.11 with SMTP id r11mr5817952qki.169.1488319687625; Tue, 28 Feb 2017 14:08:07 -0800 (PST) Received: from [192.168.1.82] (host81-156-184-24.range81-156.btcentralplus.com. [81.156.184.24]) by smtp.gmail.com with ESMTPSA id r20sm1873805qka.2.2017.02.28.14.08.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Feb 2017 14:08:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Roy Arends In-Reply-To: Date: Tue, 28 Feb 2017 22:08:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <920390D7-BFF8-4680-B2D8-488777671DCA@dnss.ec> References: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> To: dnsop X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:08:11 -0000 > On 28 Feb 2017, at 21:35, Paul Wouters wrote: >=20 > On Tue, 28 Feb 2017, Roy Arends wrote: >=20 >> Since the last update of this draft, a full collision has been found. >>=20 >> Do the authors intend to update the draft to state that SHA1 SHOULD = NOT be used for DNSSEC signing (DNSKEY algorithm 5,6,7) and for DNSSEC = Delegation (DS and CDS algorithm 1) ? >=20 > That seems a bit dramatic to this author :) >=20 > We can't stuff PDF prefixes into this, We don=E2=80=99t need to. > there are a lot less bytes > for an attacker to play with. A CNAME chain will give you plenty of bytes to futz with.=20 >=20 >> Please also refrain from using MUST- SHOULD+ and SHOULD-. >=20 > For this SHA1 case or in general? In general. > I'd say we could update the DNSSEC > Signing entry from MUST- to SHOULD NOT Good. That is exactly my request. > but I would leave SHA1 for > DNSSEC validation at MUST-. I=E2=80=99d say you have to update that as well to SHOULD NOT. > There is a need to move people away from SHA1, Yes, there is. Roy= From nobody Tue Feb 28 17:57:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674B81293FD for ; Tue, 28 Feb 2017 17:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EE5w3E_r2v9J for ; Tue, 28 Feb 2017 17:56:58 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB8D1289C4 for ; Tue, 28 Feb 2017 17:56:58 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vXz8Q08t8z3xJ; Wed, 1 Mar 2017 02:56:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1488333414; bh=OnJbpuZpuOAZvkkdECWeOEMLrkugAJMXCYXibaoH6ng=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=B31ELZjUB65MmNgRCoXs4A0yUu7jm0kSBcTwB67XxFyl0W5BLaMBwHD/mqzJ/WuRz pmNbpsotWc3LipQYOBSExPvv+ZcAfVxjQ1GRAFKw4G/deGaYNC+RIFGLh+u4QoA16n 6iB+KGLSs2yGChI7XD2ot0ZjS4werRQMziLIGBNo= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id jjpMzccbOAkv; Wed, 1 Mar 2017 02:56:50 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Mar 2017 02:56:50 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0E65336A2; Tue, 28 Feb 2017 20:56:48 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0E65336A2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ED4A8418A26F; Tue, 28 Feb 2017 20:56:48 -0500 (EST) Date: Tue, 28 Feb 2017 20:56:48 -0500 (EST) From: Paul Wouters To: Roy Arends In-Reply-To: <920390D7-BFF8-4680-B2D8-488777671DCA@dnss.ec> Message-ID: References: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> <920390D7-BFF8-4680-B2D8-488777671DCA@dnss.ec> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: dnsop Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 01:57:00 -0000 On Tue, 28 Feb 2017, Roy Arends wrote: >> We can't stuff PDF prefixes into this, > > We don’t need to. > >> there are a lot less bytes >> for an attacker to play with. > > A CNAME chain will give you plenty of bytes to futz with. None of the SHA1 hases we use are covering a chain of records. >>> Please also refrain from using MUST- SHOULD+ and SHOULD-. >> >> For this SHA1 case or in general? > > In general. I disagree then. Did you read the motivation of why we use those terms to clarify that we expect an algorithm to be promoted or demoted in a future update? >> I'd say we could update the DNSSEC >> Signing entry from MUST- to SHOULD NOT > > Good. That is exactly my request. This is still only meaningful if the signer software vendors in general agree with this. If they will just ignore this document, then I feel there isn't much point in proceeding with it. >> but I would leave SHA1 for >> DNSSEC validation at MUST-. > > I’d say you have to update that as well to SHOULD NOT. That is just unreasonable. Do you want half the the DNSSEC signed zones in the world to go insecure or bogus? Migration should be done responsibly. Paul