From nobody Sat Apr 1 13:56: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 7909E127077 for ; Sat, 1 Apr 2017 13:56:10 -0700 (PDT) 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 7ZTJo5_NsmDD for ; Sat, 1 Apr 2017 13:56:08 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 BE2D2129692 for ; Sat, 1 Apr 2017 13:56:06 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 9EEDF31C7D; Sat, 1 Apr 2017 22:56:04 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id C240FEC0E0F; Sat, 1 Apr 2017 22:17:27 +0200 (CEST) Date: Sat, 1 Apr 2017 15:17:27 -0500 From: Stephane Bortzmeyer To: Suzanne Woolf Cc: dnsop Message-ID: <20170401201727.GA5948@laperouse.bortzmeyer.org> References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 20:56:10 -0000 On Sun, Mar 12, 2017 at 07:20:55PM -0400, Suzanne Woolf wrote a message of 92 lines which said: > This message opens a Working Group Last Call for: > > "The ALT Special Use Top Level Domain" > https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ I've read -08 and I believe I understand this draft. I'm not convinced it's useful (most users of alternative resolution systems won't use it and, anyway, I'm not even sure it will be added in the Special-Use registry, which was wrongly frozen by the IESG) but I don't see big issues with the draft, it seems to me it correctly describes the new TLD. Editorial : Section 1: "and that should not be resolved" I cannot parse it. Missing "it"? Section 5 : After "and anyone watching queries along the path", add a reference to RFC 7626? Normative references: Why is RFC 6303 a normative reference? It is no longer used. Why is RFC 7686 a normative reference? It is just an example. From nobody Mon Apr 3 04:55: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 030FF1250B8 for ; Mon, 3 Apr 2017 04:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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] 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 ZnnR1IdHmEqQ for ; Mon, 3 Apr 2017 04:55:51 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B373312947E for ; Mon, 3 Apr 2017 04:55:51 -0700 (PDT) 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]:57175) 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 1cv0aL-0004G3-0e (Exim 4.89) (return-path ); Mon, 03 Apr 2017 12:55:49 +0100 Date: Mon, 3 Apr 2017 12:55:49 +0100 From: Tony Finch To: Peter van Dijk cc: dnsop@ietf.org In-Reply-To: <9232F4F4-772F-48AA-80FB-C990662AFD7A@powerdns.com> Message-ID: References: <20170330230806.6273.qmail@ary.lan> <9232F4F4-772F-48AA-80FB-C990662AFD7A@powerdns.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 11:55:54 -0000 Peter van Dijk wrote: > > There are PowerDNS ALIAS deployments that signs offline (for some > stretch of the definition of offline) - every minute. For small zones > the NOTIFY+XFR overhead is very tolerable, and the public auths do not > need the private key data. If you expand ALIAS on the master server like this, I would expect that most of the time the target addresses won't change very frequently, so the IXFR rate should be much less than the ALIAS polling frequency. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Humber, Thames: South or southwest, veering northwest later, 5 or 6. Slight, occasionally moderate in Humber. Fog patches, rain later. Moderate, occasionally very poor. From nobody Mon Apr 3 05:11: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 7B6D3127601 for ; Mon, 3 Apr 2017 05:11:03 -0700 (PDT) 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 SbgFHUCiqr7r for ; Mon, 3 Apr 2017 05:11:01 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.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 63E2C126BF7 for ; Mon, 3 Apr 2017 05:11:01 -0700 (PDT) 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]:48174) 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 1cv0p0-000s6c-ia (Exim 4.89) (return-path ); Mon, 03 Apr 2017 13:10:58 +0100 Date: Mon, 3 Apr 2017 13:10:58 +0100 From: Tony Finch To: Peter van Dijk cc: dnsop@ietf.org In-Reply-To: <49454161-E6D2-4607-8C0C-AE3B102297F0@powerdns.com> Message-ID: References: <20170330230806.6273.qmail@ary.lan> <20170330231358.GA92307@isc.org> <49454161-E6D2-4607-8C0C-AE3B102297F0@powerdns.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 12:11:03 -0000 Peter van Dijk wrote: > On 31 Mar 2017, at 12:10, Tony Finch wrote: > > > > Does the more ambitious version use the NSEC rdata format so that you can > > have different target names for different alias RR types? > > I got this question some time ago when I was working on ALIAS for PowerDNS. > Back then I said no, as nobody showed me an actual use case for it and I did > not like the extra complexity. Today I feel the same way and the upcoming > draft does not have type bitmaps currently. That's probably sensible :-) The vague idea I had was ALIAS A AAAA for your web hosting provider and ALIAS MX TXT for your mail hosting provider. But the latter isn't actually very useful, since MX and SPF records have built-in indirection, and TXT is also used for other purposes (domain authorization, quite frequently in my experience), and it doesn't cover DKIM or MUA SRV records. And other scenarios stub their toes in similar ways, e.g. for SIP there's a mess of SRV records plus NAPTR, and a NAPTR RRset can cover multiple unrelated protocols and providers. So I think my conclusion is that ALIAS is both unnecessary and unhelpful for RRtypes other than A and AAAA. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Trafalgar: North or northeast 4 or 5, increasing 6 at times. Moderate at first in east, otherwise rough. Fair. Good. From nobody Mon Apr 3 12:12: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 44C3E1294FA for ; Mon, 3 Apr 2017 12:12:45 -0700 (PDT) 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 Mzgo9zO2ldYt for ; Mon, 3 Apr 2017 12:12:44 -0700 (PDT) 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 DEC681294C3 for ; Mon, 3 Apr 2017 12:12:43 -0700 (PDT) Received: (qmail 61442 invoked from network); 3 Apr 2017 19:12:41 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Apr 2017 19:12:41 -0000 Date: 3 Apr 2017 19:12:19 -0000 Message-ID: <20170403191219.33461.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: dot@dotat.at 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] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:12:45 -0000 In article you write: >So I think my conclusion is that ALIAS is both unnecessary and unhelpful >for RRtypes other than A and AAAA. Depends. If you allow what I described, shadowing records from a server that thinks it's authoritative from the zone but isn't, it's definitely useful for MX, possibly for others. R's, John From nobody Mon Apr 3 12:40: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 E64B8129506 for ; Mon, 3 Apr 2017 12:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-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=isoc.onmicrosoft.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 mFrbrZFVKxpK for ; Mon, 3 Apr 2017 12:40:26 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0072.outbound.protection.outlook.com [104.47.32.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD391294C3 for ; Mon, 3 Apr 2017 12:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KMKdcurEKJNjTaW5yB3KpURPlKD9Rs5nvdVAK9uhb2w=; b=AtRXfCZOjv9bmILGN/6hS/LHO71Hlf1DI4Kgt8Kyd6P6rRRs4breIObGH6Pb6UMU+W70o3FuSJE+SP/CauiBaEDBnS/g18/3jTtXiybI2InxmxESxCQRC5ZZqoGnev5ACl/39cUYUbepL6FHxqQg4q3JuNNBj871KusRudcxQZY= Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) by CY1PR0601MB1658.namprd06.prod.outlook.com (10.163.232.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Mon, 3 Apr 2017 19:40:22 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) with mapi id 15.01.1005.018; Mon, 3 Apr 2017 19:40:22 +0000 From: Dan York To: Evan Hunt CC: John R Levine , Bob Harold , "dnsop@ietf.org" Thread-Topic: [DNSOP] New draft for ALIAS/ANAME type Thread-Index: AQHSqJOk4uYaLh3aM0+m1+rB3NB73KGtcPsAgACS2ACAAAGkAIAGDaMA Date: Mon, 3 Apr 2017 19:40:22 +0000 Message-ID: <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> References: <20170330230806.6273.qmail@ary.lan> <20170330231358.GA92307@isc.org> In-Reply-To: <20170330231358.GA92307@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: isc.org; dkim=none (message not signed) header.d=none;isc.org; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.75.87.222] x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1658; 7:Q2CRlXl4DYARprKPfWne+k0m2BPfOMiPHq8ZRA+qu2nIdEJak/OOIq1ZR8fHoHFQ7Tukkp3Fa4Wb+rmIwrWjNm32qWirs0V/YH9mBeYvwvfKZmUIMXI8orWZXykFCgiWBAd2S7XCtMUFx5GmqCyRC07yJcS0lmADzVclxawshZa3MagQvr6dLMJ4TgLSNEGJO7vGF6Iych5v/xRtVbzDxHLCZIXdsj29LJZRPrbpqgmEkEXRx0RfZLKRMvzlYTmLrVpx+8SZBN6m/EpK/7BR0mw9OCgv2ObxWaVccK6Y3J2ySZ1PFJY9Bes4m3f9VbUwgGTkpq6rc2OFB8SChkLk9A== x-ms-office365-filtering-correlation-id: fbd9a580-35d1-49d4-598b-08d47ac9449c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR0601MB1658; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:CY1PR0601MB1658; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1658; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39400400002)(39840400002)(39410400002)(24454002)(377454003)(8936002)(189998001)(7906003)(2906002)(229853002)(66066001)(54356999)(2900100001)(86362001)(7736002)(53936002)(50986999)(122556002)(76176999)(5660300001)(6246003)(6512007)(83716003)(54896002)(53386004)(53376002)(966004)(3280700002)(6506006)(6436002)(33656002)(25786009)(6306002)(6486002)(3660700001)(77096006)(8656002)(606005)(54906002)(4326008)(99286003)(82746002)(2950100002)(8676002)(38730400002)(3846002)(236005)(81166006)(110136004)(6916009)(36756003)(6116002)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1658; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3A4E28342BD44DC39D5AA15B3DCDA738isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2017 19:40:22.2563 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1658 Archived-At: Subject: Re: [DNSOP] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:40:29 -0000 --_000_3A4E28342BD44DC39D5AA15B3DCDA738isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I very much like the idea of this draft, given that I use multiple DNS host= ing providers who all have their own unique (and proprietary) way of doing = "CNAME flattening at the apex". I think the reality of today's user experie= nce with domain names is that we are increasingly dropping the "www" or any= other kind of second-level domain. So we want to talk about our sites as "= example.com" ... but as the publisher we want to use CD= Ns, load balancers and other systems that need us to use a CNAME. A standar= dized way of doing this would be helpful. One comment... On Mar 30, 2017, at 7:13 PM, Evan Hunt > = wrote: (Incidentally, I'm working on a somewhat more ambitious ANAME draft with Peter van Dijk and Anthony Eden, who has kindly agreed to merge his efforts with ours. I expect to post it in a few days, stay tuned.) ... I think it would be helpful for the new draft to have a few examples of= what the RR would look like in a zone file. (This was the one component I= found missing from Anthony's ALIAS draft.) Thanks for doing this, Dan -- Dan York Senior Manager, Content & Web Strategy, Internet Society york@isoc.org +1-603-439-0024 Jabber: york@jabber.isoc.org Skype: danyork = http://twitter.com/danyork http://www.internetsociety.org/ --_000_3A4E28342BD44DC39D5AA15B3DCDA738isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <37C03A9B7FC23948BB8B6AD5F4B5763A@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable I very much like the idea of this draft, given that I use multiple DNS host= ing providers who all have their own unique (and proprietary) way of doing = "CNAME flattening at the apex". I think the reality of today's us= er experience with domain names is that we are increasingly dropping the "www" or any other kind of second-= level domain. So we want to talk about our sites as "example.com" ... but as the publisher we = want to use CDNs, load balancers and other systems that need us to use a CNAME. A standardized way of doing this would be helpful.

One comment... 

On Mar 30, 2017, at 7:13 PM, Evan Hunt <each@isc.org> wrote:

(Incidentally, I'm working on a somewhat more ambitious ANAME draft with Peter van Dijk and Anthony Eden, who has kindly agreed to merge his efforts=
with ours. I expect to post it in a few days, stay tuned.)

... I think it would be helpful for the new draft to have a few exampl= es of what the RR would look like in a zone file.  (This was the one c= omponent I found missing from Anthony's ALIAS draft.)

Thanks for doing this,
Dan

--
Dan York
Senior Manager, Content & Web Strategy, Internet Society
york@isoc.org   &= #43;1-603-439-0024 
Jabber: york@jabber= .isoc.org  Skype: danyork   http://twitter.com/danyork

http://www.internets= ociety.org/

--_000_3A4E28342BD44DC39D5AA15B3DCDA738isocorg_-- From nobody Mon Apr 3 12: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 1CCCC129514 for ; Mon, 3 Apr 2017 12:49:11 -0700 (PDT) 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 lzKAymRe3PUE for ; Mon, 3 Apr 2017 12:49:08 -0700 (PDT) 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 11DCC12963F for ; Mon, 3 Apr 2017 12:48:54 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vxjN35M9MzCwZ; Mon, 3 Apr 2017 21:48:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491248931; bh=eamw0N3/C3WQYUH5ElGDXazMg4ad9V3aIWxRQz6RgY4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hhVUc1HjdF92JVb74LoUy/YGwrSUtFM56RIpzv9PDHT1e06OD4Zpb1QBqLDtxPbVE +C10k25S8932ElUq5iUMRJjOo3c46PHzQmfENwQh3j/VcT76KOVNwpqdCjLcTqi/if uYbxUSogSMcYksfnI67Jaz88Xw7P4byaqsoGB/uA= 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 kF9A3XHi9XlC; Mon, 3 Apr 2017 21:48:50 +0200 (CEST) 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; Mon, 3 Apr 2017 21:48:50 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9D8403943A4; Mon, 3 Apr 2017 15:48:49 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9D8403943A4 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 86F7C400088C; Mon, 3 Apr 2017 15:48:49 -0400 (EDT) Date: Mon, 3 Apr 2017 15:48:49 -0400 (EDT) From: Paul Wouters To: Dan York cc: "dnsop@ietf.org" In-Reply-To: <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> Message-ID: References: <20170330230806.6273.qmail@ary.lan> <20170330231358.GA92307@isc.org> <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:49:11 -0000 On Mon, 3 Apr 2017, Dan York wrote: > I very much like the idea of this draft, given that I use multiple DNS hosting providers who all have their own unique (and proprietary) way of doing > "CNAME flattening at the apex". I think the reality of today's user experience with domain names is that we are increasingly dropping the "www" or any > other kind of second-level domain. So we want to talk about our sites as "example.com" ... but as the publisher we want to use CDNs, load balancers and > other systems that need us to use a CNAME. A standardized way of doing this would be helpful. > One comment... I hate it :) As Evan said, there should not be any code in an authoritative server that requires it to do recursive validation. > (Incidentally, I'm working on a somewhat more ambitious ANAME draft with > Peter van Dijk and Anthony Eden, who has kindly agreed to merge his efforts > with ours. I expect to post it in a few days, stay tuned.) Staying tuned :) Paul From nobody Mon Apr 3 12:57: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 78B43129501 for ; Mon, 3 Apr 2017 12:57:56 -0700 (PDT) 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 7py06-wjvEiW for ; Mon, 3 Apr 2017 12:57:54 -0700 (PDT) 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 4809C12950B for ; Mon, 3 Apr 2017 12:57:54 -0700 (PDT) Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:84e4:75f2:3020:8a8e]) (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 56C54CD996; Mon, 3 Apr 2017 21:57:51 +0200 (CEST) From: "Peter van Dijk" To: "dnsop@ietf.org" Date: Mon, 03 Apr 2017 21:57:52 +0200 Message-ID: <95E305D4-D7D0-4F14-9314-942D76CC2F90@powerdns.com> In-Reply-To: <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> References: <20170330230806.6273.qmail@ary.lan> <20170330231358.GA92307@isc.org> <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:57:56 -0000 Hi Dan, On 3 Apr 2017, at 21:40, Dan York wrote: > I very much like the idea of this draft, given that I use multiple DNS > hosting providers who all have their own unique (and proprietary) way > of doing "CNAME flattening at the apex". I think the reality of > today's user experience with domain names is that we are increasingly > dropping the "www" or any other kind of second-level domain. So we > want to talk about our sites as "example.com" ... > but as the publisher we want to use CDNs, load balancers and other > systems that need us to use a CNAME. A standardized way of doing this > would be helpful. Thank you for your kind words. As I said in another post indeed, I hope this draft (assuming it becomes an RFC) will remove one point of suffering for those who use multiple DNS providers. > One comment... > > On Mar 30, 2017, at 7:13 PM, Evan Hunt > > wrote: > > > > (Incidentally, I'm working on a somewhat more ambitious ANAME draft > with > > Peter van Dijk and Anthony Eden, who has kindly agreed to merge his > efforts > > with ours. I expect to post it in a few days, stay tuned.) > > ... I think it would be helpful for the new draft to have a few > examples of what the RR would look like in a zone file. (This was the > one component I found missing from Anthony's ALIAS draft.) Our current draft-draft does not have that yet but I fully agree. I find many published RFCs are lacking in examples and test vectors, and I’ll make sure we do better on this. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Mon Apr 3 13:01: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 78EE9120726 for ; Mon, 3 Apr 2017 13:00:59 -0700 (PDT) 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 yx_23SQG_46w for ; Mon, 3 Apr 2017 13:00:58 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08303129501 for ; Mon, 3 Apr 2017 13:00:58 -0700 (PDT) Received: from linux-hs2j.localnet (unknown [201.220.7.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 449AF61F9C; Mon, 3 Apr 2017 20:00:57 +0000 (UTC) From: Paul Vixie To: dnsop@ietf.org Cc: Paul Wouters , Dan York Date: Mon, 03 Apr 2017 20:00:56 +0000 Message-ID: <7458227.fcc3KKjKTW@linux-hs2j> Organization: Vixie Freehold In-Reply-To: References: <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [DNSOP] the power of ideas X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 20:00:59 -0000 On Monday, April 3, 2017 7:48:49 PM GMT Paul Wouters wrote: > ... > As Evan said, there should not be any code in an authoritative server > that requires it to do recursive validation. in the internet dns as practiced, our choice is not whether an idea thought by some to be "bad", as in, "a bad idea", will be widely implemented. our only choice is whether such ideas are documented, interoperable, and subject to fine tuning by the rest of the community. as someone who finds most ideas bad, i often wish this weren't so. as someone whose ideas are often thought to be bad by others, i am often glad that this is so. in any case, it is so. ideas, good or bad, plus implementation, creates relevance. that relevance stands independent of the perceived goodness or badness of the ideas themselves. with or without an applicability statement, the underlying message of an rfc from the dnsop working group is not "we think this is good engineering" but rather "if you want to do this in a way that interoperates with others who are also doing it, here is one way to achieve that result." so, phrases like "should not be" are irrelevant in this place at this time. vixie From nobody Mon Apr 3 13:33: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 CCA301293FB for ; Mon, 3 Apr 2017 13:33:47 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdJQjoJr6WF5 for ; Mon, 3 Apr 2017 13:33:46 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 62D5C127978 for ; Mon, 3 Apr 2017 13:33:46 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v33KZrjX017999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 3 Apr 2017 13:35:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1491251754; bh=LVfSwP81uEhdOngdxpOmdxymAFS9Tj4pNWAEY3NOkGQ=; h=Subject:To:References:Cc:Reply-To:From:Date:In-Reply-To:From; b=flR0747uO1yMkN+B/tF+28AXTnNHgdwec9MNHb+Lonrul+iP4DVEQ1bZmrucgaj6O rOxvKW2/Itw0Vm5Z61ni16W70QQnX1mBKdUwADh9PuueBT9eXylav1UcGJNs+Eb1vb MFzFHIAq88cBkSZ11ZQvsysaSmlnz2O8pJQpfEu8= To: Paul Vixie , dnsop@ietf.org References: <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> <7458227.fcc3KKjKTW@linux-hs2j> Cc: Paul Wouters , Dan York Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 3 Apr 2017 13:33:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7458227.fcc3KKjKTW@linux-hs2j> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] the power of ideas X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 20:33:48 -0000 On 4/3/2017 1:00 PM, Paul Vixie wrote: > with or without an applicability statement, the underlying message of an rfc > from the dnsop working group is not "we think this is good engineering" but > rather "if you want to do this in a way that interoperates with others who are > also doing it, here is one way to achieve that result." > > so, phrases like "should not be" are irrelevant in this place at this time. There's a legitimate substitute for the should(not) statements: Statements of implication. Along with describing the how, describing what will ensue, is likely to ensue, or is at least a possibility. These might even be labeled 'downsides' or 'upsides' if the authors want to get frisky. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Apr 3 15:09: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 67B68124BE8 for ; Mon, 3 Apr 2017 15:09:07 -0700 (PDT) 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 XYl1D4HJARFr for ; Mon, 3 Apr 2017 15:09:05 -0700 (PDT) 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 4C73B1294F0 for ; Mon, 3 Apr 2017 15:09:02 -0700 (PDT) Received: from lxdnp04n.corp.intranet (lxdnp04n.corp.intranet [151.119.92.83]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v33M8xYH030614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 3 Apr 2017 17:08:59 -0500 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v33M8sDB013661; Mon, 3 Apr 2017 16:08:54 -0600 Received: from lxomp06u.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v33M8rKa013631 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Mon, 3 Apr 2017 16:08:54 -0600 Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v33M8rKS046162; Mon, 3 Apr 2017 17:08:53 -0500 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v33M8rvO046156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Apr 2017 17:08:53 -0500 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.196]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Mon, 3 Apr 2017 17:08:54 -0500 From: "Woodworth, John R" To: "'Tony Finch'" CC: "'dnsop@ietf.org'" , "Ballew, Dean" , "'JW'" , "Woodworth, John R" Thread-Topic: [DNSOP] Perl related question on BULK RR Thread-Index: AdKnNHlp8TWdUeDYQ/qmHdlSCDbwXAAoizEAAAAXlNABNqUQEA== Date: Mon, 3 Apr 2017 22:08:53 +0000 Message-ID: References: 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: Subject: Re: [DNSOP] Perl related question on BULK RR X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:09:07 -0000 > -----Original Message----- > From: Woodworth, John R > > > -----Original Message----- > > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Tony Finch > ... > > > > So my question is, how does the BULK rewriting system interact > > with DNS loops? Is there a CPU-eating tarpit in there? > > > Hi Tony, Thanks again for your question. According to RFC1034, protection should already be in place for all compliant nameserver implementations. ... domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error. Although this does not specifically call out other RR types, it does set precedence for following chains and avoiding loops. I've run through a number of thought exercises and believe this should still be the case with BULK RRs. Having said this, I believe your point to be valid and our draft as well as any implementations would benefit from explicit guidance for loop avoidance specific to processing BULK RRs. This should provide greater consistency across implementations and help avoid any confusion and error prone logic. I've also been meaning to flesh out the section regarding sanity checks while reading BULK RRs into memory (from file or wire). This could help with avoiding a particular type of loop. I will work to get these changes added into our draft. Thanks, John > > > Tony. > > -- > > f.anthony.n.finch http://dotat.at/ - I xn--zr8h > > punycode South Utsire: Northwesterly 4 or 5 backing southwesterly > > 3 or 4. Slight or moderate. Fog patches, drizzle. Moderate or good, > > occasionally very poor. > > > > _______________________________________________ > > 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 Apr 3 15:25: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 A36CB1293FC for ; Mon, 3 Apr 2017 15:25:33 -0700 (PDT) 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 NSqiZ26F7M_5 for ; Mon, 3 Apr 2017 15:25:32 -0700 (PDT) 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 64A44128B44 for ; Mon, 3 Apr 2017 15:25:32 -0700 (PDT) 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 2BAB03493AC; Mon, 3 Apr 2017 22:25:31 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 1F75B216C1C; Mon, 3 Apr 2017 22:25:31 +0000 (UTC) Date: Mon, 3 Apr 2017 22:25:31 +0000 From: Evan Hunt To: Paul Wouters Cc: Dan York , "dnsop@ietf.org" Message-ID: <20170403222531.GB72941@isc.org> References: <20170330230806.6273.qmail@ary.lan> <20170330231358.GA92307@isc.org> <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:25:34 -0000 On Mon, Apr 03, 2017 at 03:48:49PM -0400, Paul Wouters wrote: > As Evan said, there should not be any code in an authoritative server > that requires it to do recursive validation. I said what now? Had I recently had dental surgery? I don't remember this. If you mean the comment I made on the ANAME thread, I was just saying that it's possible to implement CNAME flattening without a built-in resolver; several implementations already do. (I do believe an authoritative server should be *able* to operate without built-in recursive code, and enabling such operation is on my list of things to get around to someday in BIND: if auth servers could be configured to use external resolvers, then security bugs affecting only the recursive code wouldn't be any risk to them. But I definitely wouldn't phrase that as "there should not be any code".) -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Mon Apr 3 17:27: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 44C2B129467 for ; Mon, 3 Apr 2017 17:27:36 -0700 (PDT) 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, 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=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 MIK8Kni-dSgl for ; Mon, 3 Apr 2017 17:27:33 -0700 (PDT) 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 706CA129432 for ; Mon, 3 Apr 2017 17:27:33 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id s68so158265617vke.3 for ; Mon, 03 Apr 2017 17:27:33 -0700 (PDT) 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=a48guHjOqPcW27vaxy7YbgWIkntEOaCVeGneNyxzsUk=; b=Z4DXALQmhoM4ihRqUm3Dwz2TbYsz4t+XgfdzdF4xPGlrRdACBnMeOvAzxoEJwSzOTv QmCKPUiZwGCmFh6fnoLs6CEHweaf83Ei+OOnjd+kCTbcf+Aq88wnlTbB/nDlQ6yCMLLY iFg+yD3Cpdr4oiPrCmNn/+4OEJYT7LoHOTbuQQu8ofFb8wvXRYuID2ZAWHL85sDfukax U6Z5HlTJIOC1USQETAZR85URLUTq8WWj6uqRveqOENy6CPaawCqQm4y2DMw1CH08tRb3 XcvNwtStYuJRu26ta3RKiAGg58fUjweU9E5BIuLRY16SqzqU+mNO6WLC+Naares+J1Vx OFAw== 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=a48guHjOqPcW27vaxy7YbgWIkntEOaCVeGneNyxzsUk=; b=KcYmxU/fWlr8Ppvnnl4tMUPbvS1RyyViI2tjj1ihvrKzIAzuEftQ4idB5SmIYhVrAO C9JMcaSpTwxKPLZqHZkQEUGBtfUauH5ck8/evZ5pAO/8WKSpjfgn5UHOwSOp04JZsOo7 nEGumPpAHrI7t9/PwcOWHtg9B7j/tZajETdkllq3NwuzcSHSmsFkw8aCQsWI+vjk32xv 6W2kg8CPl6QhSyEh9xzHeJSoJIIeBHZFBOcKiBV+on3lrFianQcZMQN+DGLxs8VB/v5p BLLVZNZdANg2FnInQ8fmvuIXUaygt50oEk6DWDxLHYLV/jRQ+ysjmteE2MKLc/M0tcPC 3aqg== X-Gm-Message-State: AFeK/H2uEilfw/Msti/96sxOpNiHXZYsRcDcV0o0xztno6qsSIN+0cUTbxlnd1n2BTRs50MSmSmGlogODkh1Wg== X-Received: by 10.31.11.73 with SMTP id 70mr9288117vkl.83.1491265652486; Mon, 03 Apr 2017 17:27:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.20 with HTTP; Mon, 3 Apr 2017 17:27:32 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:465:201f:394f:6f28] In-Reply-To: <20170401201727.GA5948@laperouse.bortzmeyer.org> References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> From: George Michaelson Date: Mon, 3 Apr 2017 19:27:32 -0500 Message-ID: To: Stephane Bortzmeyer Cc: Suzanne Woolf , dnsop Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 00:27:36 -0000 isn't this OBE and it's alt.arpa now? Serious question btw. I do not think that this document can proceed without significant re-drafting to a 2LD if that is the case. G On Sat, Apr 1, 2017 at 3:17 PM, Stephane Bortzmeyer wrote: > On Sun, Mar 12, 2017 at 07:20:55PM -0400, > Suzanne Woolf wrote > a message of 92 lines which said: > >> This message opens a Working Group Last Call for: >> >> "The ALT Special Use Top Level Domain" >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ > > I've read -08 and I believe I understand this draft. I'm not convinced > it's useful (most users of alternative resolution systems won't use it > and, anyway, I'm not even sure it will be added in the Special-Use > registry, which was wrongly frozen by the IESG) but I don't see big > issues with the draft, it seems to me it correctly describes the new > TLD. > > Editorial : > > Section 1: > > "and that should not be resolved" I cannot parse it. Missing "it"? > > Section 5 : > > After "and anyone watching queries along the path", add a reference to > RFC 7626? > > Normative references: > > Why is RFC 6303 a normative reference? It is no longer used. > > Why is RFC 7686 a normative reference? It is just an example. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Apr 3 17:51: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 52F70129467 for ; Mon, 3 Apr 2017 17:51:58 -0700 (PDT) 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 mhMUu_91H1XO for ; Mon, 3 Apr 2017 17:51:57 -0700 (PDT) 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 EA91E12702E for ; Mon, 3 Apr 2017 17:51:56 -0700 (PDT) Received: from [169.254.126.148] (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 v340pcmp056995 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Apr 2017 17:51:40 -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 [169.254.126.148] From: "Paul Hoffman" To: "George Michaelson" Cc: dnsop Date: Mon, 03 Apr 2017 17:51:50 -0700 Message-ID: <3C85C5DB-7F1A-45B7-BE2A-926065F2C266@vpnc.org> In-Reply-To: References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 00:51:58 -0000 On 3 Apr 2017, at 17:27, George Michaelson wrote: > isn't this OBE and it's alt.arpa now? No. > Serious question btw. I do not think that this document can proceed > without significant re-drafting to a 2LD if that is the case. Are you saying that because of: https://www.iab.org/documents/correspondence-reports-documents/2017-2= /iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domai= n/ If so, I suspect you read it wrong. My reading is that the IAB is only = saying that names that are supposed to act like DNS names (that is, to = exist in the public DNS) need to be under .arpa. This draft explicitly = is about non-DNS contexts. --Paul Hoffman From nobody Mon Apr 3 18:02: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 30C3D1267BB for ; Mon, 3 Apr 2017 18:02:23 -0700 (PDT) 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, 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=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 7ZNgVqD5yXfQ for ; Mon, 3 Apr 2017 18:02:21 -0700 (PDT) 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 C0B761201F2 for ; Mon, 3 Apr 2017 18:02:20 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id s68so158848031vke.3 for ; Mon, 03 Apr 2017 18:02:20 -0700 (PDT) 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=TgpN9DqnGSObn1dKN46XZEWLPNnHJ1w+2htXqUYlWOQ=; b=O9fz8O2X9VIonrOsYrzXTRvty0IDQ6gHgWqhPMS/uO1nkVEl79b9R1fVr0CO3D2miJ 3VeBaXR/NWsF3+575ljMn1wp+ozuNZLAnSXu+KMU0+SFtbh1A3daaoDMS6xgkwZxkAsu TNZ2s6fX33IWuVU9HfqEhxX7a+j1F+8c+zOWAYomKAuhMzh3/wDdAXx2Ug9GKfY1dB18 XI54LW2k64boqRw5oBY5HENVMaHp0MZzOpQkDX5upHT4S+4aPxtxXp8SQnyt5c3WtoK5 IuFiqtr68RVgKuUrVdKQCaUH26uTzmsw8pcNGyXWKwYZIQrJfp7mf7x4aftfE/3GMmdu oUuw== 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=TgpN9DqnGSObn1dKN46XZEWLPNnHJ1w+2htXqUYlWOQ=; b=igrO+EI57XuQzVZwTOUwyaKN1aAvK7upZCHNLyDzzD4qPoqaVQWFhy3XHdGeJqa5B5 gxF1HiKUveEFhdun0fVLAKmnUWT96eCBYGTiluMytfHOUsXnKJoeyeT9FaYPK9MEvpXj FmwOweoShaKGvvr9Q1y2GN5OwAZd3S+RLKQuN/oxQdeqq3LJOgv1UiIxxmZDrUlT0sML LakkZGl8EPMWnMdqP3T2PJdTApc2PByGn0ak0jAA3jGmzA6g31nng25PEGBL9BAlK0pi OXPd0gcjQ0S3IxIGwQsxzN6NXfRtXOsVz794GFPrXyVxCI2XArkKnpYo77uCaVmqnofM wnGg== X-Gm-Message-State: AFeK/H2I3NPZ4rm1+qKDM1OoBHIxkTrRkQFW/NDCHm+svBkptkgZT1pNXKhvCprtTySLK8kkqCrB6UfJh8rvYw== X-Received: by 10.159.35.141 with SMTP id 13mr957458uao.46.1491267739625; Mon, 03 Apr 2017 18:02:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.20 with HTTP; Mon, 3 Apr 2017 18:02:19 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:465:201f:394f:6f28] In-Reply-To: <3C85C5DB-7F1A-45B7-BE2A-926065F2C266@vpnc.org> References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> <3C85C5DB-7F1A-45B7-BE2A-926065F2C266@vpnc.org> From: George Michaelson Date: Mon, 3 Apr 2017 20:02:19 -0500 Message-ID: To: Paul Hoffman Cc: dnsop Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 01:02:23 -0000 The only reference to ICANN delegation process is in an [Ed: note] which feels to me to be wrong: its a first class issue, and should be addressed directly, not as editorial. Secondly, The authors make a judgement call in this block that they feel requesting delegation is not required. I don't feel the consensus was that strong actually, but you know, I guess I could be wrong on that. Thirdly the draft contains no language which actually explains why a TLD is required, rather than a deterministic string which denotes 'not in the DNS' -It may be blindingly obvious to you it has to be a TLD, but given that the entry of DNS label-strings into the DNS is through software, and given that at some point, the simple un-parsed string 'something.alt' has to be presented, I would have expected an explanation why 'alt.arpa' as a pattern match in the DNS entry can't work as well as 'alt'. Bear in mind, that the argumentative text states .ONION is a comparator, so poses the problem back on (future) s/w authors that currently seek a TLD as a pattern match, and now have to code to ONION.ALT as a pattern match (the match on ALT implies parsing it off, to denote ONION as a non-DNS label, or embedding of ALT in the non-DNS namespace) so the dots-parsing problem exists for the s/w owners *come what may* Lastly, I think the IAB note pretty strongly goes to 'we dont do that any more' and I think the draft at the bare minimum should say why this draft is special, against that letter. You make a compelling and simple case: because its specifically NOT-DNS, not public DNS, its not relevant. Ok, then say so. 'we didn't say so because it wasn't relevant' feels pretty weak to me. I can do this as a nit in the GIT if you prefer. -G On Mon, Apr 3, 2017 at 7:51 PM, Paul Hoffman wrote: > On 3 Apr 2017, at 17:27, George Michaelson wrote: > >> isn't this OBE and it's alt.arpa now? > > > No. > >> Serious question btw. I do not think that this document can proceed >> without significant re-drafting to a 2LD if that is the case. > > > Are you saying that because of: > > https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/ > If so, I suspect you read it wrong. My reading is that the IAB is only > saying that names that are supposed to act like DNS names (that is, to exist > in the public DNS) need to be under .arpa. This draft explicitly is about > non-DNS contexts. > > --Paul Hoffman From nobody Mon Apr 3 18:13: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 D5A6912702E for ; Mon, 3 Apr 2017 18:13:46 -0700 (PDT) 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 PlKAORDGIKJe for ; Mon, 3 Apr 2017 18:13:45 -0700 (PDT) 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 2271F1252BA for ; Mon, 3 Apr 2017 18:13:45 -0700 (PDT) Received: from [169.254.126.148] (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 v341DU09057824 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Apr 2017 18:13:31 -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 [169.254.126.148] From: "Paul Hoffman" To: "George Michaelson" Cc: dnsop Date: Mon, 03 Apr 2017 18:13:42 -0700 Message-ID: <3CEFC70C-949E-4D48-B2B1-17D87D95543F@vpnc.org> In-Reply-To: References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> <3C85C5DB-7F1A-45B7-BE2A-926065F2C266@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 01:13:47 -0000 On 3 Apr 2017, at 18:02, George Michaelson wrote: > The only reference to ICANN delegation process is in an [Ed: note] > which feels to me to be wrong: its a first class issue, and should be > addressed directly, not as editorial. The note says why the ICANN delegation process is *not* used. As the Abstract says, these notes will be removed before publication. > Secondly, The authors make a judgement call in this block that they > feel requesting delegation is not required. I don't feel the consensus > was that strong actually, but you know, I guess I could be wrong on > that. This is what WG Last Call is for. If you want to reverse what's in the current draft, you need to say so explicitly, hopefully providing text so that this WG doesn't end up with the sloppy text that the HOMENET WG got. FWIW, I thought that the authors got this version right. The discussion didn't converge on strong use cases for delegation, and there were strong reasons against. But this is a fair time to open that again. > Thirdly the draft contains no language which actually explains why a > TLD is required, rather than a deterministic string which denotes 'not > in the DNS' -It may be blindingly obvious to you it has to be a TLD, > but given that the entry of DNS label-strings into the DNS is through > software, and given that at some point, the simple un-parsed string > 'something.alt' has to be presented, I would have expected an > explanation why 'alt.arpa' as a pattern match in the DNS entry can't > work as well as 'alt'. Bear in mind, that the argumentative text > states .ONION is a comparator, so poses the problem back on (future) > s/w authors that currently seek a TLD as a pattern match, and now have > to code to ONION.ALT as a pattern match (the match on ALT implies > parsing it off, to denote ONION as a non-DNS label, or embedding of > ALT in the non-DNS namespace) so the dots-parsing problem exists for > the s/w owners *come what may* If you have such proposed text, that would be useful to evaluate. > Lastly, I think the IAB note pretty strongly goes to 'we dont do that > any more' Please define "that". If you mean "using TLDs that are not delegated", please show in the IAB statement where you get that impression. I didn't see it, but that doesn't mean it isn't there. > and I think the draft at the bare minimum should say why > this draft is special, against that letter. You make a compelling and > simple case: because its specifically NOT-DNS, not public DNS, its not > relevant. Ok, then say so. 'we didn't say so because it wasn't > relevant' feels pretty weak to me. > > I can do this as a nit in the GIT if you prefer. What you are proposing is not a "nit", but a fundamental change throughout the document. --Paul Hoffman From nobody Mon Apr 3 18:24: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 E3620129533 for ; Mon, 3 Apr 2017 18:24:48 -0700 (PDT) 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, 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=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 qF2pkYd2NrxI for ; Mon, 3 Apr 2017 18:24:46 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 45EE8129530 for ; Mon, 3 Apr 2017 18:24:46 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id z204so159608655vkd.1 for ; Mon, 03 Apr 2017 18:24:46 -0700 (PDT) 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=QxaroiGlaKXnjVoCNkMvqGrAtmJTrY/3dzj98CTYIUY=; b=TaAGZOkdUTd5L3rh0Mv3nlwsIKDP00hg6zXAuo3yOk2VWT01XDq5v+usQ+kXAayX2w Mijjh0au2WkarIpVPNEiVIsw3mGZpOAY972F7ESeIl+EdsOOPxYuC/ccZv8WyKTKRSOh ITo93ma3auqOAwXAvPmBReg6qxom/B22acxeCUZurvcny/+H8Hp/D2yas7v3JZrgQUa0 ssPmgnzFTxiXU+Pat+Sd31CWEsCI752A5Eeh0ckNb8kVRf1YgbzU0/0CbfKFevTntLFb xr1gjutfEECH9qd8QvVgU4+BTPqMM5yneALj7bPM+c+DrUNtW2SYlBVihMuNEwjW5u/z e9XA== 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=QxaroiGlaKXnjVoCNkMvqGrAtmJTrY/3dzj98CTYIUY=; b=sxPnm0g9mMJzTVP96Aqkf/4ROIAFp85mamfAKgHuBd3pdKxV/TODviac7de8iko3CE p7d8rzXFr7uQWE3+R67IxKAukILZfMBRpWo5Glg5Sda3sNlgeawNxQv1UAluAzrtKkGp Ozyd0f3bMG3jLICfYCU5skJyg90H+eEH9qBG9kCp7mG3zgVPaHm4KfLHQXVrdJhJdWaC NAzbqADS3UB8Q4qYIcBDHFHG3tnyCmZVFP32IONXLL0904vc2UbgbOVOVL5+jtH6ufKQ vN9wO20KuJhkNeyWb99mAa6m4gMZeI9mjrqzNGsd9JnImmzWgOTbRdyLgWFNTfYTPq7z K2lQ== X-Gm-Message-State: AFeK/H3CcqWHCwtcBGyBDhQWIMZAm8jAlWzjwb7yHG5Au0Bg1cMoOMZOCS4jORJi/UkLJduteMzFRrKY8D9bdQ== X-Received: by 10.176.5.199 with SMTP id e65mr4682922uae.23.1491269085068; Mon, 03 Apr 2017 18:24:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.20 with HTTP; Mon, 3 Apr 2017 18:24:44 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:465:201f:394f:6f28] In-Reply-To: <3CEFC70C-949E-4D48-B2B1-17D87D95543F@vpnc.org> References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> <3C85C5DB-7F1A-45B7-BE2A-926065F2C266@vpnc.org> <3CEFC70C-949E-4D48-B2B1-17D87D95543F@vpnc.org> From: George Michaelson Date: Mon, 3 Apr 2017 20:24:44 -0500 Message-ID: To: Paul Hoffman Cc: dnsop Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 01:24:49 -0000 On Mon, Apr 3, 2017 at 8:13 PM, Paul Hoffman wrote: > On 3 Apr 2017, at 18:02, George Michaelson wrote: > >> The only reference to ICANN delegation process is in an [Ed: note] >> which feels to me to be wrong: its a first class issue, and should be >> addressed directly, not as editorial. > > > The note says why the ICANN delegation process is *not* used. As the > Abstract says, these notes will be removed before publication. Which I think is wrong. The notes are material. I think they should uplift to the body of the document so there is a permanent RFC record of why the decison to not go to ICANN delegation was made. > >> Secondly, The authors make a judgement call in this block that they >> feel requesting delegation is not required. I don't feel the consensus >> was that strong actually, but you know, I guess I could be wrong on >> that. > > > This is what WG Last Call is for. If you want to reverse what's in the > current draft, you need to say so explicitly, hopefully providing text so > that this WG doesn't end up with the sloppy text that the HOMENET WG got. > > FWIW, I thought that the authors got this version right. The discussion > didn't converge on strong use cases for delegation, and there were strong > reasons against. But this is a fair time to open that again. No, I don't think I can demonstrate failure to converge on strong use cases for delegation is weak consensus. If nobody comes forward with a rock-solid reason to delegate, then I think its fair to call it 'not delegated' > >> Thirdly the draft contains no language which actually explains why a >> TLD is required, rather than a deterministic string which denotes 'not >> in the DNS' -It may be blindingly obvious to you it has to be a TLD, >> but given that the entry of DNS label-strings into the DNS is through >> software, and given that at some point, the simple un-parsed string >> 'something.alt' has to be presented, I would have expected an >> explanation why 'alt.arpa' as a pattern match in the DNS entry can't >> work as well as 'alt'. Bear in mind, that the argumentative text >> states .ONION is a comparator, so poses the problem back on (future) >> s/w authors that currently seek a TLD as a pattern match, and now have >> to code to ONION.ALT as a pattern match (the match on ALT implies >> parsing it off, to denote ONION as a non-DNS label, or embedding of >> ALT in the non-DNS namespace) so the dots-parsing problem exists for >> the s/w owners *come what may* > > > If you have such proposed text, that would be useful to evaluate. The problem is, I don't think I can, because I cannot argue strongly FOR a TLD, because i believe the impetus for a TLD is aesthetic and (as for homenet btw) driven by end user UI perception issues. I believe that the behaviour here is going to drive to string recognition inside code to switch: Pythonic pseudocode: if fqdn.endswith('.alt'): do_non_dns_lookup(fqdn) else: gethostbyname(fqdn) type decision. Thats what it think this document drives to. And, given that, I think endswith('.alt') can be endswith(STUBNAME) and somewhere else, STUBNAME='.alt.arpa' is going to work. > >> Lastly, I think the IAB note pretty strongly goes to 'we dont do that >> any more' > > > Please define "that". If you mean "using TLDs that are not delegated", > please show in the IAB statement where you get that impression. I didn't see > it, but that doesn't mean it isn't there. Actually you're probably right. the statement says explicitly "Other names in the Special-Use Domain Names registry are intended for exclusion from DNS resolution. An entry in the Special-Use Domain Names Registry that does not require DNS resolution does not require the registrant to control the relevant name in the DNS." So the language there goes directly to BECAUSE you intend requesting no delegation, you make the cut. Ie, the fact you've decided consensus wasn't reached to delegated, and therefore decide to say NOT DELEGATE is directly relevant to the statement from the IAB, because it goes to the language which says 'if not in the DNS, and a TLD, put it in the SUDN' So if you continue to maintain this HAS to be a TLD, (which btw, requires justifying) AND if you specifically require it NOT to be in the DNS, then the IAB statement should be cited to drive to its inclusion in the registry. > >> and I think the draft at the bare minimum should say why >> this draft is special, against that letter. You make a compelling and >> simple case: because its specifically NOT-DNS, not public DNS, its not >> relevant. Ok, then say so. 'we didn't say so because it wasn't >> relevant' feels pretty weak to me. >> >> I can do this as a nit in the GIT if you prefer. > > > What you are proposing is not a "nit", but a fundamental change throughout > the document. No, I'd like to back off that. If you do language to specify why it has to be a TLD, and if you cite the IAB, I think the document will be integral and complete. in other words "I was wrong" but "now I'm right" cheers -G > > --Paul Hoffman From nobody Mon Apr 3 19:26: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 BE2DE129536 for ; Mon, 3 Apr 2017 19:26:14 -0700 (PDT) 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 tBxzkYbZWsXy for ; Mon, 3 Apr 2017 19:26:12 -0700 (PDT) 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 7A77D126FDC for ; Mon, 3 Apr 2017 19:26:12 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id l7so87245504ioe.3 for ; Mon, 03 Apr 2017 19:26:12 -0700 (PDT) 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=CFcU1tPdRFfZPUcMOOcu7uogcAyeHBtnNm8+FrcgCHE=; b=hOdlg7jtaJs7y6KosApz+zAWPRWX4CCkn0Gv4IV/uT3v8TTfvIixk3hhqdAPNAET9D OBArLgc7rDwA4VcDxFXhL3EuLGWxb/g1bvHi9d7T+oYZlbcn9iwX6TNNhSaSXDBEZ2ua PjLa2lPbiee4C1kkRyDiauUAc0pQG+yODq9nWVsIGlmVA/vAaQFXttZ/D2YkjP5aNZ22 RuH7mVVhsHajW0FmrDHDALvNqOfjXtz329gNoym/29QWOu9vifZs8EYaAlHF0i+27WQl 7/WaSad1WL4SxzCNjzYRjZA36yx2W4ea0KC21iUIN+RnkQv5GoYkiY5BcJnqh7pc8GEA us2g== 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=CFcU1tPdRFfZPUcMOOcu7uogcAyeHBtnNm8+FrcgCHE=; b=GTGdNM/v+Xbu7MES1AS0yzjKn3vQ1MyDJreFYHXnZOg5WUkUmH1esYMojkVKNqrmT0 bfKeObAaqAINH06Vee4fe7pmJgsi6xMqJk/DluwHR1PU6S/PRb2LIWAEd2Y2gsBW48pJ JeygSMZUdA5+RtTyoVburjCN+BH+SMfdwba2puPGYyDsWpGniYhyLsZ+OOGhv9LrtTwH F8fSM6Z3t5OTp0PAhwz+l64yVM0FxtCbAvwFULtkZq5abob84lWulrDQHyiIzoRP8cVG 2T8Qbd+Z+7HKwzCLJAJ0dTtKbRbNXtrtPy1+orhXAMCpl+6pPRXg996pD8y3tO8nInTn Vf9Q== X-Gm-Message-State: AFeK/H1pDaBjwyB0w7cqzjLwWA16gK4LZ8HUYJKJVI6Hh6qMmzmK38RzPRpClDtdgCjYQTNbYL9TkvaSfB95pw== X-Received: by 10.107.136.41 with SMTP id k41mr21802803iod.160.1491272771733; Mon, 03 Apr 2017 19:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.46.151 with HTTP; Mon, 3 Apr 2017 19:26:11 -0700 (PDT) From: Brian Dickson Date: Mon, 3 Apr 2017 19:26:11 -0700 Message-ID: To: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary=001a113ec618d29e87054c4dffdf Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 02:26:15 -0000 --001a113ec618d29e87054c4dffdf Content-Type: text/plain; charset=UTF-8 In response to the latest comments by Paul Hoffman and George Michaelson, I'd like to offer my $0.02 on the meaning and purpose of the alt TLD vs the IAB statement. My read is (whether or not it is correct) that there are three possibilities for a special name. The first is, a special but needs DNS resolution. This is one case the IAB says, "register it and put it in DNS under arpa". (I don't think that is controversial at all, and a wise recommendation.) The second is, a Very Special, but does not belong in DNS. (IAB second option.) The third is, a Not Very Special, and not in DNS. Not registered, FCFS. Not covered by the IAB statement by virtue of not being registered, but IMHO not conflicting with the IAB statement. Very Special: It gets its entry in the registry in order to establish its uniqueness, but isn't in DNS, so no entry under arpa. This avoids the possibility of multiple mechanisms for interception fighting with each other, since the behavior is (or should be) name-driven. Also wise, and also in-scope for the IAB statement. Not Very Special: whoever wants the name, is reasonably sure it won't be exposed outside of a closed environment (e.g. a single application), and doesn't want or need to go through the 6761 process to get the name registered. Not Very Special is basically 6761 without the registry, in a first-come, first-served, no guarantees kind of way. The "onion" thing showed the need for some way of avoiding TLDs, avoiding conflicting names, and avoiding heavy process, IMHO. And I think "alt" is the right answer. Also IMHO, making it "alt.arpa" would be very confusing; I think any time someone sees "arpa" as the TLD, they should believe it exists in the DNS. Having "alt" be the parent name here, and not be in the DNS, keeps things clear even to non-DNS folks. And finally, maybe there is a use case for FCFS local-use names that kind-of are in the DNS. If such a need were to arise, then THAT would be something where "alt.arpa" would make sense. But given the relative ease in adding things under arpa, I don't see a good reason for creating non-registered FCFS when registered FCFS is available, under arpa. Brian --001a113ec618d29e87054c4dffdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In response to the latest comments by Paul Hoffman and Geo= rge Michaelson, I'd like to offer my $0.02 on the meaning and purpose o= f the alt TLD vs the IAB statement.

My read is (whether = or not it is correct) that there are three possibilities for a special name= .

The first is, a special but needs DNS resolution= . This is one case the IAB says, "register it and put it in DNS under = arpa". (I don't think that is controversial at all, and a wise rec= ommendation.)

The second is, a Very Special, but d= oes not belong in DNS. =C2=A0(IAB second option.)

= The third is, a Not Very Special, and not in DNS. Not registered, FCFS. Not= covered by the IAB statement by virtue of not being registered, but IMHO n= ot conflicting with the IAB statement.

Very Specia= l: It gets its entry in the registry in order to establish its uniqueness, = but isn't in DNS, so no entry under arpa. This avoids the possibility o= f multiple mechanisms for interception fighting with each other, since the = behavior is (or should be) name-driven. Also wise, and also in-scope for th= e IAB statement.=C2=A0

Not Very Special: whoever w= ants the name, is reasonably sure it won't be exposed outside of a clos= ed environment (e.g. a single application), and doesn't want or need to= go through the 6761 process to get the name registered.

Not Very Special is basically 6761 without the registry, in a first-= come, first-served, no guarantees kind of way.

The= "onion" thing showed the need for some way of avoiding TLDs, avo= iding conflicting names, and avoiding heavy process, IMHO. And I think &quo= t;alt" is the right answer.

Also IMHO, making= it "alt.arpa" would be very confusing; I think any time someone = sees "arpa" as the TLD, they should believe it exists in the DNS.=

Having "alt" be the parent name here, a= nd not be in the DNS, keeps things clear even to non-DNS folks.
<= br>
And finally, maybe there is a use case for FCFS local-use nam= es that kind-of are in the DNS. If such a need were to arise, then THAT wou= ld be something where "alt.arpa" would make sense. But given the = relative ease in adding things under arpa, I don't see a good reason fo= r creating non-registered FCFS when registered FCFS is available, under arp= a.

Brian
--001a113ec618d29e87054c4dffdf-- From nobody Mon Apr 3 19: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 9102D129549 for ; Mon, 3 Apr 2017 19:37:14 -0700 (PDT) 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, 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=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 WiKcesWyEvpH for ; Mon, 3 Apr 2017 19:37:12 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c: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 30655129542 for ; Mon, 3 Apr 2017 19:37:12 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id d188so159114099vka.0 for ; Mon, 03 Apr 2017 19:37:11 -0700 (PDT) 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=jDijzotYNfjgcmjtPbla9kH+mY7lt6z1gvVmuvuN5TY=; b=LoIMlYkr0zVIrmNW0pnNKeW53WIhYKDPFZen87xw9O5zuIzsSYIIVaFsV35ZC3SNAR 8gtYOSOaRSVoyaBmmVRz7lbpujeAH70gvIGRiViwWoiJgCmIgBiL5X0rYVjCCLL1Xwo1 rNZehLo8EFX3juDKCXtOqFXz20gNRALsYBpUg1Fea5fn7v1JcMpkh7Hq/7drliEPK7kF wIL1txZWoAEYhpvAbgonb+egcnYg0udCi0cvUECLwtX88dq0po1ccZ/1oa1QRrt6xJbJ 695c2YtW5i47L+y57OfUPcbi8nzu73bEQdRN+3C4ZiAfqCSclc67yrgIZPctzKlRpre6 F67Q== 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=jDijzotYNfjgcmjtPbla9kH+mY7lt6z1gvVmuvuN5TY=; b=rm7Cn40xwP8zxSv85LF67OlvT5uu0pI1mYYtDBp83r2TUcQyD+Zvk/W5jJjCpHuZ4R lqMajtNqO4tC8p4UssWmIt2DvRpdmvyHz9jJ+MzyJ7XzQ8AEqwl+tzfowCEU7LeEfkqM fy/QyzVr0JmVevCUsxjyu9NQW4tq2F+UfnHI9EFJGkQOfEPpV9ICUMF8YWjWjELNYr5V DXijDSWNpdGP8coyCNm3Ngk+Ci9iY7aoUGLTyteRxxm2zYuO5qJgHHD5GMUs2fwnEdQ+ O1is4Zd34gELjW76fTG7s2kV5R1v9vFC7EV1PbSiCrsUg1N1ERDPQLeGhPu270MXCZ3l ZQ3g== X-Gm-Message-State: AFeK/H1xH+7NkjCYirQ2Yr1gGSb4A2ziiJXuyr5F1IKk+k+XkkvtDmdciw+VLC8+y7oExWxU/ITb8vDWOz28tw== X-Received: by 10.176.84.147 with SMTP id p19mr8941938uaa.35.1491273430989; Mon, 03 Apr 2017 19:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.20 with HTTP; Mon, 3 Apr 2017 19:37:10 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:465:201f:394f:6f28] In-Reply-To: References: From: George Michaelson Date: Tue, 4 Apr 2017 11:37:10 +0900 Message-ID: To: Brian Dickson Cc: "dnsop@ietf.org WG" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 02:37:14 -0000 I think that's a useful mail. So in that sense, I have a question: Would you say anything to this, were you in edit mode, on a draft going to LC if that draft didn't say it? If you had a draft requesting a TLD to "exist" in some sense: in or not in a registry; passed or not passed into the DNS; delegated or not delegated via ICANN; would you reference the IAB document? If not, why not? -George On Tue, Apr 4, 2017 at 11:26 AM, Brian Dickson wrote: > In response to the latest comments by Paul Hoffman and George Michaelson, > I'd like to offer my $0.02 on the meaning and purpose of the alt TLD vs the > IAB statement. > > My read is (whether or not it is correct) that there are three possibilities > for a special name. > > The first is, a special but needs DNS resolution. This is one case the IAB > says, "register it and put it in DNS under arpa". (I don't think that is > controversial at all, and a wise recommendation.) > > The second is, a Very Special, but does not belong in DNS. (IAB second > option.) > > The third is, a Not Very Special, and not in DNS. Not registered, FCFS. Not > covered by the IAB statement by virtue of not being registered, but IMHO not > conflicting with the IAB statement. > > Very Special: It gets its entry in the registry in order to establish its > uniqueness, but isn't in DNS, so no entry under arpa. This avoids the > possibility of multiple mechanisms for interception fighting with each > other, since the behavior is (or should be) name-driven. Also wise, and also > in-scope for the IAB statement. > > Not Very Special: whoever wants the name, is reasonably sure it won't be > exposed outside of a closed environment (e.g. a single application), and > doesn't want or need to go through the 6761 process to get the name > registered. > > Not Very Special is basically 6761 without the registry, in a first-come, > first-served, no guarantees kind of way. > > The "onion" thing showed the need for some way of avoiding TLDs, avoiding > conflicting names, and avoiding heavy process, IMHO. And I think "alt" is > the right answer. > > Also IMHO, making it "alt.arpa" would be very confusing; I think any time > someone sees "arpa" as the TLD, they should believe it exists in the DNS. > > Having "alt" be the parent name here, and not be in the DNS, keeps things > clear even to non-DNS folks. > > And finally, maybe there is a use case for FCFS local-use names that kind-of > are in the DNS. If such a need were to arise, then THAT would be something > where "alt.arpa" would make sense. But given the relative ease in adding > things under arpa, I don't see a good reason for creating non-registered > FCFS when registered FCFS is available, under arpa. > > Brian > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Mon Apr 3 19:40: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 93CCE129537 for ; Mon, 3 Apr 2017 19:40:42 -0700 (PDT) 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 QKHtSEaT2M7R for ; Mon, 3 Apr 2017 19:40:40 -0700 (PDT) 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 185A1129536 for ; Mon, 3 Apr 2017 19:40:40 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id e75so57466839itd.1 for ; Mon, 03 Apr 2017 19:40:40 -0700 (PDT) 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=xTyjdgT1/nw6UYzPvtpzYIN+G1fXKksD/SUtqE8zoFw=; b=pHTh4/7rsDwuTYphTfkazy+CBncP26LFolqFtDyOQWBdUXmzVsq2x7MtqbHbCdbenx ZdR6WcibV60y4ySqpVNQxTZwLEHPxzKFSjB57DNMAmgCy7qOAlqZu/jx0XhCo0neoRtn E/jDqEEAV3ZoUUqOz9dS+0J2+kjB7I41tTG3QvJhHKA89OpGNhHS7jOjbyKl5Qa/MAl/ U072IM4k6yHR1X3oGLzElYh9SzgvR8i3xSDJiMDJVMBV4D2aTzj7fzX68XfD4NfNAab5 RL7TLGRNUl4LNB7NN9itZhHgNh4zlpxpkehTx7sxcSaVZw2Y2QSPraXRLoF+r7n4lAaz G+Vg== 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=xTyjdgT1/nw6UYzPvtpzYIN+G1fXKksD/SUtqE8zoFw=; b=caXdYc7HKOvDIivcJjQYLpMVt7aTUrE6A/XZVbkaRTITFCrEv9NRlwVx+X7GtyPTB4 Sn52LhggAbuKxLwMaZfM/M46/el47DZZVdHBRymQzXFLVCWpre3fkFfCxn16YMGaIMu3 GWKPlcgCTH7E+VQe1TA9FSaCuxxtfdVyk/Nng61Ft13lJbNM8CBFolwf3/hwBWtqeabN Y2UunkiZF61ch5weGclO3fcaaSDZo8Mu2Ds8lsfOYJJGDKhBJ07dP+AEwHpU9q3PWMRR H/gkUBcQNMrK9ialP0xHPsdhqLUb0bYMGlwkRRejI1wpOchBs9iWv0d/y7uGpmN8GwZ/ MYnw== X-Gm-Message-State: AFeK/H2eAoSAReT/Sq2G5NWgDCF02mWKTLSwCnYd57JUkZQMjmBZe6zKfr1WoFBXOiAdlw== X-Received: by 10.36.185.87 with SMTP id k23mr13141887iti.12.1491273639463; Mon, 03 Apr 2017 19:40:39 -0700 (PDT) Received: from [192.168.6.210] (ip-64-134-197-92.public.wayport.net. [64.134.197.92]) by smtp.gmail.com with ESMTPSA id p77sm8542471iod.4.2017.04.03.19.40.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Apr 2017 19:40:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: Date: Mon, 3 Apr 2017 22:40:35 -0400 Cc: Paul Hoffman , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: <7F3CEC89-AC83-484B-94F9-1C0311220530@gmail.com> References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> <3C85C5DB-7F1A-45B7-BE2A-926065F2C266@vpnc.org> To: George Michaelson X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 02:40:42 -0000 Hi, On one specific point: > On Apr 3, 2017, at 9:02 PM, George Michaelson = wrote: >=20 > Lastly, I think the IAB note pretty strongly goes to 'we dont do that > any more' and I think the draft at the bare minimum should say why > this draft is special, against that letter. You make a compelling and > simple case: because its specifically NOT-DNS, not public DNS, its not > relevant. Ok, then say so. 'we didn't say so because it wasn't > relevant' feels pretty weak to me. I=E2=80=99m fine with =E2=80=9Cthe draft needs to be updated with = reference to the relevance of .arpa=E2=80=9D as a WGLC comment, so the = below is intended as contributing to the discussion, not repressing it. On the intentions and role of the IAB:=20 An IAB statement isn=E2=80=99t an IETF document of any kind, never mind = a standards track document, and can=E2=80=99t tell the IETF what to = do=E2=80=94 including this WG. So the IAB certainly can=E2=80=99t say = =E2=80=9CWe don=E2=80=99t do that any more=E2=80=9D as a policy = statement about an IETF registry such as the special use names registry. = However, RFC 3172 is an IETF BCP, and provides direction to the IETF and = the IAB (as admin authority for .arpa) on the requirements that should = be followed for a delegation in .arpa. So as a WGLC comment, this = suggests the addition of a reference to RFC 3172 and the applicability = of the .arpa policy there to the justification for alt. It=E2=80=99s my view that, as Paul says, the IAB note was written about = a different case than the alt-tld draft was: the IAB was attempting to = point out an alternative to asking for a delegation in the root zone in = the case that a special use name is supposed to be resolvable in the = DNS. The alt-tld draft is about names that aren=E2=80=99t intended to be = resolvable in the DNS in the first place. However, since I was a contributor to the IAB document, it puts me in an = awkward position to be interpreting it for DNSOP on behalf of the IAB. = If further clarification on the IAB statement would be useful, we should = explicitly request it. best, Suzanne >=20 > I can do this as a nit in the GIT if you prefer. >=20 > -G >=20 >=20 > On Mon, Apr 3, 2017 at 7:51 PM, Paul Hoffman = wrote: >> On 3 Apr 2017, at 17:27, George Michaelson wrote: >>=20 >>> isn't this OBE and it's alt.arpa now? >>=20 >>=20 >> No. >>=20 >>> Serious question btw. I do not think that this document can proceed >>> without significant re-drafting to a 2LD if that is the case. >>=20 >>=20 >> Are you saying that because of: >>=20 >> = https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-= statement-on-the-registration-of-special-use-names-in-the-arpa-domain/ >> If so, I suspect you read it wrong. My reading is that the IAB is = only >> saying that names that are supposed to act like DNS names (that is, = to exist >> in the public DNS) need to be under .arpa. This draft explicitly is = about >> non-DNS contexts. >>=20 >> --Paul Hoffman >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Apr 3 19:47: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 E01D01293EB for ; Mon, 3 Apr 2017 19:47:52 -0700 (PDT) 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, 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=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 O-RDlEYuroIc for ; Mon, 3 Apr 2017 19:47:50 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 311BF129503 for ; Mon, 3 Apr 2017 19:47:50 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id r69so160674479vke.2 for ; Mon, 03 Apr 2017 19:47:50 -0700 (PDT) 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:content-transfer-encoding; bh=qQRGA5YqeGdBXz4HVo9ZmFQZKfPNJItFI6n82qdUpLQ=; b=VXqNyCxZwG51ZhQEOJaAl6t0xi5hosLULhMYi7OQ6fRqxuy0UwLyB8m35/940BOsfZ q4EpuU3hLDT2jFnmVu5WJjDvqFhop52VvXqZ2DDpeS0QhE3KDJd5E8h7znTXcSsw5v52 lyfZeTriEcrLEyrI2MjPgVBo4f45oq1LJLvg207NvmzcY03FpXEGSEG4LKlW6rX8LA+k TEbfA6dE3Vq589x35RDs+6EGGLz0dJNlmVpwnx3GmiEqjLyW05Lc2Uz/6XVXZxiN7R2e 0S1Wj5aFW0Ey5V/4Jc7cYLNrpVOt1OIxkkUpZsFLDAf+6NsxLJcKcer+6pMtDT+99Yut y4+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:content-transfer-encoding; bh=qQRGA5YqeGdBXz4HVo9ZmFQZKfPNJItFI6n82qdUpLQ=; b=kpR/Sz5cuykGO7jPtJt2PxCF6gaRtpVQC65mtC05Q0dWCVZlNfJ4zH8H8VwQyNViom m94+fQMDypu37E8tq34nNl4JVWxZ/cMSSbTlwchnXHtaom0GygL1fMujy8guCoxEswby dHl7ePIGXSiJjpnQdJiaZTZ3LpGFnOWTRHtQT2S0psV8vyApc7FaDxg100IAQkHiIMNh Gmn1Z0dJHq5iYn3FlkoLBRfMNTW+Wou5jiaSQuE8WClDW0IJbNl6T2+cvlfYvg88BCXe pv9cpmMUApG+a35K1ljxFSc0nad//0rSdgflkBsQ5BwnG5NYk5W2DTb1J1MMW0R8fFu5 JaIg== X-Gm-Message-State: AFeK/H2Hl1izdiyTuQlJoLBTD5wzz4Lv+34skBkoVw8O0b7qXfUTq153Sc6J+iOpYxEM4WOsg4FbVbyK9bjKFQ== X-Received: by 10.176.84.147 with SMTP id p19mr8955778uaa.35.1491274069277; Mon, 03 Apr 2017 19:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.20 with HTTP; Mon, 3 Apr 2017 19:47:48 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:465:201f:394f:6f28] In-Reply-To: <7F3CEC89-AC83-484B-94F9-1C0311220530@gmail.com> References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> <3C85C5DB-7F1A-45B7-BE2A-926065F2C266@vpnc.org> <7F3CEC89-AC83-484B-94F9-1C0311220530@gmail.com> From: George Michaelson Date: Tue, 4 Apr 2017 11:47:48 +0900 Message-ID: To: Suzanne Woolf Cc: Paul Hoffman , dnsop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 02:47:53 -0000 I could take it either way. narrow doc is narrow purpose? don't ref it. doc is highly visible, will be (mis)interpreted as being relevant? disavow it (which implies ref it) doc is highly visible, problem next door? Seek guidance. -G On Tue, Apr 4, 2017 at 11:40 AM, Suzanne Woolf wro= te: > Hi, > > On one specific point: > >> On Apr 3, 2017, at 9:02 PM, George Michaelson wrote: >> >> Lastly, I think the IAB note pretty strongly goes to 'we dont do that >> any more' and I think the draft at the bare minimum should say why >> this draft is special, against that letter. You make a compelling and >> simple case: because its specifically NOT-DNS, not public DNS, its not >> relevant. Ok, then say so. 'we didn't say so because it wasn't >> relevant' feels pretty weak to me. > > > I=E2=80=99m fine with =E2=80=9Cthe draft needs to be updated with referen= ce to the relevance of .arpa=E2=80=9D as a WGLC comment, so the below is in= tended as contributing to the discussion, not repressing it. > > On the intentions and role of the IAB: > > An IAB statement isn=E2=80=99t an IETF document of any kind, never mind a= standards track document, and can=E2=80=99t tell the IETF what to do=E2=80= =94 including this WG. So the IAB certainly can=E2=80=99t say =E2=80=9CWe = don=E2=80=99t do that any more=E2=80=9D as a policy statement about an IETF= registry such as the special use names registry. However, RFC 3172 is an I= ETF BCP, and provides direction to the IETF and the IAB (as admin authority= for .arpa) on the requirements that should be followed for a delegation in= .arpa. So as a WGLC comment, this suggests the addition of a reference to = RFC 3172 and the applicability of the .arpa policy there to the justificati= on for alt. > > It=E2=80=99s my view that, as Paul says, the IAB note was written about a= different case than the alt-tld draft was: the IAB was attempting to point= out an alternative to asking for a delegation in the root zone in the case= that a special use name is supposed to be resolvable in the DNS. The alt-t= ld draft is about names that aren=E2=80=99t intended to be resolvable in th= e DNS in the first place. > > However, since I was a contributor to the IAB document, it puts me in an = awkward position to be interpreting it for DNSOP on behalf of the IAB. If f= urther clarification on the IAB statement would be useful, we should explic= itly request it. > > best, > Suzanne > >> >> I can do this as a nit in the GIT if you prefer. >> >> -G >> >> >> On Mon, Apr 3, 2017 at 7:51 PM, Paul Hoffman wro= te: >>> On 3 Apr 2017, at 17:27, George Michaelson wrote: >>> >>>> isn't this OBE and it's alt.arpa now? >>> >>> >>> No. >>> >>>> Serious question btw. I do not think that this document can proceed >>>> without significant re-drafting to a 2LD if that is the case. >>> >>> >>> Are you saying that because of: >>> >>> https://www.iab.org/documents/correspondence-reports-documents/2017-2/i= ab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/ >>> If so, I suspect you read it wrong. My reading is that the IAB is only >>> saying that names that are supposed to act like DNS names (that is, to = exist >>> in the public DNS) need to be under .arpa. This draft explicitly is abo= ut >>> non-DNS contexts. >>> >>> --Paul Hoffman >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > From nobody Mon Apr 3 19:49: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 990AA1293EB for ; Mon, 3 Apr 2017 19:49:32 -0700 (PDT) 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 I7Nuee1MphnF for ; Mon, 3 Apr 2017 19:49:29 -0700 (PDT) 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 E0262129503 for ; Mon, 3 Apr 2017 19:49:28 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id f84so87461022ioj.0 for ; Mon, 03 Apr 2017 19:49:28 -0700 (PDT) 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=jocDnmldBro5ZxY+RkWLz6oin6H4ZTNCybM0axVpjSE=; b=fwkCNhgosqOM0skDI1f3oW9AzXnODlc0Ry0rfM57Hv9kKWagtjwSDYHjjg82FhbrWl WY/AU4bKinKubSlKvG/X+abrC0eslg3DrwzKrP3FNGysTkmQ2doYLsgkpiVK2Pa6c4iW wC53/whAqs3l/PQSmOcWYOEJ/TjcPcfAR+RpHHnaAmsGiQ5bQrhJq3Bx3HgfHzXPvtrS 76jP3WPgloxOHdDQ4CXHLtDIbUVg+pzxsIvre2/ZByjbeBn3dw62rBfv85k6dPYx3tcm ppH+0CcZq5zHQdwJnq36mlfBi3UXudRuiNmSJSW+7JD+gs7CaU/duf3ZZtwg6PFvcsMw uc0g== 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=jocDnmldBro5ZxY+RkWLz6oin6H4ZTNCybM0axVpjSE=; b=UagfrgeORHUI5AcLWER5qOYLau/dpxRf0AB1CmGEiQZ5Iq7+/s3eyveqirI8oiuBrd PW8GUbemUkHP8XOn7rmlzGQnLfus/xP2N9OaEWXvTByWrrGUx+VEKBB9cFECRAsBgUY6 HWIFF9mipfJg00vKf+I1eIdnZxjEztipp0CO/EknXVm1pfO6iCZlgOoflBnA5KMTKEBb BJMeuRvqvd6BIPDvlEoMXcudyMJdQWg4H5yZCOqLscTfIzCTJnQFK0WnCFhPfYmDcvl6 e8P/V0FtnXhAJQgkeM/iHb2paa7+jFihk51+TH/IQoPGqj5RfVPnHV1Ud7aco7PFHv9r AW/g== X-Gm-Message-State: AFeK/H19R6kQnhSPNicp7YBbdKeX4AAB4sjTEml62nn7VntwUi/MZD+tPkLebewOnle3jauB9X/kgXREzj+Xeg== X-Received: by 10.107.157.146 with SMTP id g140mr19028165ioe.63.1491274168327; Mon, 03 Apr 2017 19:49:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.46.151 with HTTP; Mon, 3 Apr 2017 19:49:27 -0700 (PDT) In-Reply-To: References: From: Brian Dickson Date: Mon, 3 Apr 2017 19:49:27 -0700 Message-ID: To: George Michaelson Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary=001a1140982410e908054c4e5361 Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 02:49:33 -0000 --001a1140982410e908054c4e5361 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 7:37 PM, George Michaelson wrote: > I think that's a useful mail. So in that sense, I have a question: > Would you say anything to this, were you in edit mode, on a draft > going to LC if that draft didn't say it? > > If you had a draft requesting a TLD to "exist" in some sense: in or > not in a registry; passed or not passed into the DNS; delegated or not > delegated via ICANN; would you reference the IAB document? If not, why > not? > Whether to reference the IAB document? In DNS - no, since the draft would conflict with the IAB statement. It would open the ICANN-IETF can of worms, which the IAB document suggests (directs?) we not do. Delegated or not, doesn't come into it I don't think. Not in DNS, but in a registry? Maybe, but only to make some distinction between what the IAB document says, and some compelling reason. Honestly, I think the IAB statement should appear pretty much as widely as possible. It should be up front on the DNSOP WG page. If it could be added to "note well", that would be cool, too. If there was a URL shortener, make the shortened URL one of the IETF wireless SSIDs! :-) As far as any TLD in the DNS is concerned -- there are only two basic ways that can explicitly happen with a signed root - a delegation (signed or unsigned), or a DNAME. I don't think there is a third way, except maybe with specific RRTYPE(s) in the root zone, for which I don't think a defined mechanism exists, procedure-wise. Brian > > -George > > On Tue, Apr 4, 2017 at 11:26 AM, Brian Dickson > wrote: > > In response to the latest comments by Paul Hoffman and George Michaelson, > > I'd like to offer my $0.02 on the meaning and purpose of the alt TLD vs > the > > IAB statement. > > > > My read is (whether or not it is correct) that there are three > possibilities > > for a special name. > > > > The first is, a special but needs DNS resolution. This is one case the > IAB > > says, "register it and put it in DNS under arpa". (I don't think that is > > controversial at all, and a wise recommendation.) > > > > The second is, a Very Special, but does not belong in DNS. (IAB second > > option.) > > > > The third is, a Not Very Special, and not in DNS. Not registered, FCFS. > Not > > covered by the IAB statement by virtue of not being registered, but IMHO > not > > conflicting with the IAB statement. > > > > Very Special: It gets its entry in the registry in order to establish its > > uniqueness, but isn't in DNS, so no entry under arpa. This avoids the > > possibility of multiple mechanisms for interception fighting with each > > other, since the behavior is (or should be) name-driven. Also wise, and > also > > in-scope for the IAB statement. > > > > Not Very Special: whoever wants the name, is reasonably sure it won't be > > exposed outside of a closed environment (e.g. a single application), and > > doesn't want or need to go through the 6761 process to get the name > > registered. > > > > Not Very Special is basically 6761 without the registry, in a first-come, > > first-served, no guarantees kind of way. > > > > The "onion" thing showed the need for some way of avoiding TLDs, avoiding > > conflicting names, and avoiding heavy process, IMHO. And I think "alt" is > > the right answer. > > > > Also IMHO, making it "alt.arpa" would be very confusing; I think any time > > someone sees "arpa" as the TLD, they should believe it exists in the DNS. > > > > Having "alt" be the parent name here, and not be in the DNS, keeps things > > clear even to non-DNS folks. > > > > And finally, maybe there is a use case for FCFS local-use names that > kind-of > > are in the DNS. If such a need were to arise, then THAT would be > something > > where "alt.arpa" would make sense. But given the relative ease in adding > > things under arpa, I don't see a good reason for creating non-registered > > FCFS when registered FCFS is available, under arpa. > > > > Brian > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > --001a1140982410e908054c4e5361 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 3, 2017 at 7:37 PM, George Michaelson <= ;ggm@algebras.org= > wrote:
I think that's a u= seful mail. So in that sense, I have a question:
Would you say anything to this, were you in edit mode, on a draft
going to LC if that draft didn't say it?

If you had a draft requesting a TLD to "exist" in some sense: in = or
not in a registry; passed or not passed into the DNS; delegated or not
delegated via ICANN; would you reference the IAB document? If not, why
not?

Whether to reference the IAB docum= ent?
In DNS - no, since the draft would conflict with the IAB sta= tement. It would open the ICANN-IETF can of worms, which the IAB document s= uggests (directs?) we not do.
Delegated or not, doesn't come = into it I don't think.

Not in DNS, but in a re= gistry? Maybe, but only to make some distinction between what the IAB docum= ent says, and some compelling reason.

Honestly, I = think the IAB statement should appear pretty much as widely as possible.
It should be up front on the DNSOP WG page.
If it could b= e added to "note well", that would be cool, too.
If the= re was a URL shortener, make the shortened URL one of the IETF wireless SSI= Ds! :-)

As far as any TLD in the DNS is concerned = -- there are only two basic ways that can explicitly happen with a signed r= oot - a delegation (signed or unsigned), or a DNAME.
I don't = think there is a third way, except maybe with specific RRTYPE(s) in the roo= t zone, for which I don't think a defined mechanism exists, procedure-w= ise.

Brian

=C2=A0

-George

On Tue, Apr 4, 2017 at 11:26 AM, Brian Dickson
<brian.peter.dickson@gm= ail.com> wrote:
> In response to the latest comments by Paul Hoffman and George Michaels= on,
> I'd like to offer my $0.02 on the meaning and purpose of the alt T= LD vs the
> IAB statement.
>
> My read is (whether or not it is correct) that there are three possibi= lities
> for a special name.
>
> The first is, a special but needs DNS resolution. This is one case the= IAB
> says, "register it and put it in DNS under arpa". (I don'= ;t think that is
> controversial at all, and a wise recommendation.)
>
> The second is, a Very Special, but does not belong in DNS.=C2=A0 (IAB = second
> option.)
>
> The third is, a Not Very Special, and not in DNS. Not registered, FCFS= . Not
> covered by the IAB statement by virtue of not being registered, but IM= HO not
> conflicting with the IAB statement.
>
> Very Special: It gets its entry in the registry in order to establish = its
> uniqueness, but isn't in DNS, so no entry under arpa. This avoids = the
> possibility of multiple mechanisms for interception fighting with each=
> other, since the behavior is (or should be) name-driven. Also wise, an= d also
> in-scope for the IAB statement.
>
> Not Very Special: whoever wants the name, is reasonably sure it won= 9;t be
> exposed outside of a closed environment (e.g. a single application), a= nd
> doesn't want or need to go through the 6761 process to get the nam= e
> registered.
>
> Not Very Special is basically 6761 without the registry, in a first-co= me,
> first-served, no guarantees kind of way.
>
> The "onion" thing showed the need for some way of avoiding T= LDs, avoiding
> conflicting names, and avoiding heavy process, IMHO. And I think "= ;alt" is
> the right answer.
>
> Also IMHO, making it "alt.arpa" would be very confusing; I t= hink any time
> someone sees "arpa" as the TLD, they should believe it exist= s in the DNS.
>
> Having "alt" be the parent name here, and not be in the DNS,= keeps things
> clear even to non-DNS folks.
>
> And finally, maybe there is a use case for FCFS local-use names that k= ind-of
> are in the DNS. If such a need were to arise, then THAT would be somet= hing
> where "alt.arpa" would make sense. But given the relative ea= se in adding
> things under arpa, I don't see a good reason for creating non-regi= stered
> FCFS when registered FCFS is available, under arpa.
>
> Brian
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop=
>

--001a1140982410e908054c4e5361-- From nobody Mon Apr 3 20:13: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 ABBF31270A7 for ; Mon, 3 Apr 2017 20:13:23 -0700 (PDT) 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 PFue-bIkBI0a for ; Mon, 3 Apr 2017 20:13:20 -0700 (PDT) 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 B0F76126C22 for ; Mon, 3 Apr 2017 20:13:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vxvDr6nBnz2pF; Tue, 4 Apr 2017 05:13:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491275597; bh=aBtO4frDuNoWmMtNWaH2Td5nvoZj6/Stjj2L99XOWbk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DNXYCXIhwUsMZrodQPsGnsv8lD0dBqs+OiVocoxRwDymn8ECUCIXE98qpKak6cSmN 5SGkhpNmiTrNWV7PtC6fXBrNzvANJbWxfddmrrlF7o6tgNvUVZlQSCBtr36eYNeWLa E0kQq3EgAOFSVV2/9NaUhwQpYKrexoSVJq3HkWZk= 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 3hmBv3G48g8P; Tue, 4 Apr 2017 05:13:14 +0200 (CEST) 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, 4 Apr 2017 05:13:14 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DF0D23943A4; Mon, 3 Apr 2017 23:13:13 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DF0D23943A4 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CC57D414493E; Mon, 3 Apr 2017 23:13:13 -0400 (EDT) Date: Mon, 3 Apr 2017 23:13:13 -0400 (EDT) From: Paul Wouters To: Evan Hunt cc: Dan York , "dnsop@ietf.org" In-Reply-To: <20170403222531.GB72941@isc.org> Message-ID: References: <20170330230806.6273.qmail@ary.lan> <20170330231358.GA92307@isc.org> <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> <20170403222531.GB72941@isc.org> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 03:13:24 -0000 On Mon, 3 Apr 2017, Evan Hunt wrote: > I said what now? Had I recently had dental surgery? I don't remember > this. Sorry about misremembering what you said. > (I do believe an authoritative server should be *able* to operate without > built-in recursive code > But I definitely wouldn't phrase that as "there should not be any code".) I'll await the new draft :) Paul From nobody Tue Apr 4 05:04: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 A87C6129666; Tue, 4 Apr 2017 05:04:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149130746853.30870.8028044269482471265@ietfa.amsl.com> Date: Tue, 04 Apr 2017 05:04:28 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 12:04:29 -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 : Security Considerations for RFC5011 Publishers Authors : Wes Hardaker Warren Kumari Filename : draft-ietf-dnsop-rfc5011-security-considerations-00.txt Pages : 9 Date : 2017-04-03 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-00 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 Apr 4 08:01: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 A868712941A for ; Tue, 4 Apr 2017 08:01:06 -0700 (PDT) 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 JXGnzTzW2sPf for ; Tue, 4 Apr 2017 08:01:05 -0700 (PDT) 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 E8835124234 for ; Tue, 4 Apr 2017 08:01:04 -0700 (PDT) Received: (qmail 49385 invoked from network); 4 Apr 2017 15:01:02 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 4 Apr 2017 15:01:02 -0000 Date: 4 Apr 2017 15:00:40 -0000 Message-ID: <20170404150040.37399.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: ggm@algebras.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] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:01:07 -0000 In article you write: >isn't this OBE and it's alt.arpa now? > >Serious question btw. I do not think that this document can proceed >without significant re-drafting to a 2LD if that is the case. Like Paul Hoffman, I read the it the opposite way. The draft says about as clearly as it can that foo.alt is for names that are handled completely outside the DNS. The IAB draft says that foo.arpa is where you put names that are handled within the DNS but with quirks. I don't see any conflict. I suppose it would be good for the draft to reference the IAB statement to say that's something else, not what .alt is about. R's, John From nobody Tue Apr 4 08: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 72F0B1296D8 for ; Tue, 4 Apr 2017 08:30:11 -0700 (PDT) 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 RJVVgunYqDUO for ; Tue, 4 Apr 2017 08:30:09 -0700 (PDT) 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 6B06512420B for ; Tue, 4 Apr 2017 08:30:09 -0700 (PDT) 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; Tue, 4 Apr 2017 08:30:07 -0700 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; Tue, 4 Apr 2017 08:30:07 -0700 From: Edward Lewis To: "dnsop@ietf.org" Thread-Topic: [Ext] [DNSOP] the power of ideas Thread-Index: AQHSrLUI3erBhIQMcUertbP/DUiqBKG1iYuA Date: Tue, 4 Apr 2017 15:30:06 +0000 Message-ID: References: <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> <7458227.fcc3KKjKTW@linux-hs2j> In-Reply-To: <7458227.fcc3KKjKTW@linux-hs2j> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 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_3574150205_1199968659" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] the power of ideas X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:30:11 -0000 --B_3574150205_1199968659 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 4/3/17, 16:00, "DNSOP on behalf of Paul Vixie" wrote: On Monday, April 3, 2017 7:48:49 PM GMT Paul Wouters wrote: > ... > As Evan said, there should not be any code in an authoritative server > that requires it to do recursive validation. I'm going to squat on Paul Vixie's subject line but not respond to anything he says, in part because something crossed my mind, based, ironically enough, in a conversation Paul and I had not long ago (at an ICANN meeting venue). We reminisced about client-subnet-id. There was a way-back time when I spoke of a q-trinity - qname, qtype, qclass - being the three things needed to get a specific response from DNS. Including any other information was a pollutant. Paul pulled that out when my name was on an early version of the client-subnet-id document (as a caretaker editor). The reason I was participating in that was seeing how the implementation of "stupid DNS tricks" (as one side of the war might call them) or "tailored DNS responses" (as the other side of the war might call the same battle) got carried out in specific contexts. They "worked" despite some flaws and dire predictions. It isn't that it's a sin to pollute the query with other information, there's a cost of doing so. In some cases, the cost is worth the benefit, in others, not. It's not a binary "do it or not" but a sliding scale of "is the cost less than the benefit?" I say sliding because "cost" and "benefit" are not fixed values over time. (Moore's law, Kaminsky's BlackHat presentation change cost and benefit calculations.) Back to the quote above. In general, an authority server having to do lookups will have scaling implications, suck performance, present a potential for abusive loading (think DoS/DDoS). (Related but different, DNSSEC once required the server verify signatures on load - that slowed loading zones, so it was dropped with the consequence of having to carefully define the AD bit in a response.) But in specific, managed and contained contexts, having authorities look up data to improve an answer can be worth the cost. Question hard-and-fast rules from the past. Things change. --B_3574150205_1199968659 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 tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU8aaw582ikZ7VZ5M4 QMk/x6MKqWYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw NDA0MTUzMDA1WjANBgkqhkiG9w0BAQEFAASCAQA2DF5vwYOQPG+m0radtip2d+DWi9NXKQ2x rPKK49V7T+H0mApSN/BtcDk5+rNCoMCYVaMDFG3hnBJJnP9/24DGRa6DZHos/RUqpj/xZeXv mrV4sRz0mYkh3QxlQjXXf3IZyHO8f5ipY2dLj/fDLx6kFSPJiFO6XYBeLozWFMeWXebFlcDz JLfWd3V3/DeadSwbRGpi7CUSLWIRoCh6j8hmDXv4Zs7gAB8TGSmIkLp8QTyi/WWPa+LIJp2j m48RwWb7uYr19dNqcVozpEDrml7EZK+OsoIZ6cFeFdSvM8yNC/OGBiljBS8HHMDpHQYDta9T zjJgeifafAsGyn7JdX4G --B_3574150205_1199968659-- From nobody Tue Apr 4 09:00: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 D5C881296D4 for ; Tue, 4 Apr 2017 09:00:41 -0700 (PDT) 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 tOU9CFchiVzw for ; Tue, 4 Apr 2017 09:00:35 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2171293F2 for ; Tue, 4 Apr 2017 09:00:35 -0700 (PDT) Received: from [10.140.203.9] (unknown [201.220.7.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 61E1161F9C for ; Tue, 4 Apr 2017 16:00:33 +0000 (UTC) Message-ID: <58E3C31C.7030507@redbarn.org> Date: Tue, 04 Apr 2017 09:00:28 -0700 From: Paul Vixie User-Agent: Postbox 5.0.12 (Windows/20170323) MIME-Version: 1.0 To: "dnsop@ietf.org" References: <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> <7458227.fcc3KKjKTW@linux-hs2j> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] [Ext] the power of ideas X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 16:00:42 -0000 Edward Lewis wrote: > ... > Question hard-and-fast rules from the past. Things change. rather than death or taxes, the hard and fast inevitability here (which things will change and in what ways?) is increasing complexity and associated reductions in diagnostic capability and general correct understanding. see also: http://queue.acm.org/detail.cfm?id=1242499 -- P Vixie From nobody Tue Apr 4 09: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 DAF921296D2 for ; Tue, 4 Apr 2017 09:32:21 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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=conundrum-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 4lIlmCY33WbX for ; Tue, 4 Apr 2017 09:32:18 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 BC02E12422F for ; Tue, 4 Apr 2017 09:32:07 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id r69so181924462vke.2 for ; Tue, 04 Apr 2017 09:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mX9gTBmsTaa00Jzmwp3OT8LKdsnsRHBujy/S/CgjWWc=; b=G4l6pE25OicwMADHn4Vbnn0hqGEzhLKnNSmp1ZBLob0DG9Rpa9ThnSXj/DkBGcwvDR WsJlbdwzQ/dROgpidzaC80OP9DJsMsNn6DEXTUqq/zHa0WIVrl/XyiCftq6Wa/yjJwB8 jh++d2uq9UGa9+nSiDxq9GMhg8jyHi7G2y2k7K+mk41d6kCrWJNQhJrOi6Sx62BVg4QQ vFqyneTaFJmFJjM9xKm23QS6s4pJ3aic9hPJAJyrnb8D181R3W9MTAFDXEr3eXJhdz21 IkLtPwgTx22IGx2qt9lm9zCR8cXd0ivGqbPnD4Cd+1z4ASd3U4YBCgnZzVnd4KL3YwhU J9hw== 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=mX9gTBmsTaa00Jzmwp3OT8LKdsnsRHBujy/S/CgjWWc=; b=ZMHJbhhVAhaIqPQPQVdvokQPnchiD/UuLrPkVnYwH4Q25iEl8VNy9tKY52xOFaRK/Q GU3rjdfPEhPey2xUlXcXiPKgpCimwSwe7ovy25AB8wuhAqONjZWLptsNj5CCS9ffh0bq WG7KsO46NsFOPT7vQz6KRHIMxtSItBOXtupc7LxcAaJm174+UrLUEcApHrYIiKD9Ht5y rUFCmSfNoQ9pCgBY3ACn9L78OBgGRaWrZpYlKhoQ/vfuoaNdp00wwsGgzEZGSI8epiud dpVykWWyzntl5A6BGsB3WMs2ERienrwUd3gAzYcBoXrxCFoZRzuuI5gzt/W9aG0c2HKM Q4Bw== X-Gm-Message-State: AFeK/H3DOtfDa2tiBx/NHLVFrWTukMAsxPKaLnzSis0VIulROmuV+al6q6wFC6xt0WpzlsAd5QRSpQ3isDmpjw== X-Received: by 10.176.2.106 with SMTP id 97mr10194361uas.158.1491323526362; Tue, 04 Apr 2017 09:32:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.69 with HTTP; Tue, 4 Apr 2017 09:32:05 -0700 (PDT) In-Reply-To: References: <20170330230806.6273.qmail@ary.lan> <9232F4F4-772F-48AA-80FB-C990662AFD7A@powerdns.com> From: Matthew Pounsett Date: Tue, 4 Apr 2017 12:32:05 -0400 Message-ID: To: Tony Finch Cc: Peter van Dijk , dnsop Content-Type: multipart/alternative; boundary=001a113d1444092c8c054c59d12b Archived-At: Subject: Re: [DNSOP] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 16:32:22 -0000 --001a113d1444092c8c054c59d12b Content-Type: text/plain; charset=UTF-8 On 3 April 2017 at 07:55, Tony Finch wrote: > > If you expand ALIAS on the master server like this, I would expect that > most of the time the target addresses won't change very frequently, so the > IXFR rate should be much less than the ALIAS polling frequency. > I believe that's a faulty assumption. Here's some data: One of our registrars has ~3.6 million zones hosted on its name servers. We have historically allowed end users to put CNAMEs wherever they want in the UI, but have a CNAME "emulator" in the publishing path replaces the illegal ones before they're inserted in a zone. During the month of February, the CNAME emulator initiated 872k changes to 28k zones, with an average of 31 changes per zone. The minimum/maximum changes per zone were 1 and 231 respectively. A change is updating one or more replaced CNAME records in a single action, so this doesn't count individual CNAMEs updated. It's also possible actual changes occurred on authoritative servers more often, since we avoid DoSing upsteam authoritatives. Here's the distribution of the number of zones per number of changes. I've used a LOG scale, since there's a spike of 10k zones with 42 changes, which makes a linear graph unreadable. --001a113d1444092c8c054c59d12b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 3 April 2017 at 07:55, Tony Finch <dot@dotat.at> wrote:
<= br> If you expand ALIAS on the master server like this, I would expect t= hat
most of the time the target addresses won't change very frequently, so = the
IXFR rate should be much less than the ALIAS polling frequency.

I believe that's a faulty assumption. =C2=A0 H= ere's some data:

One of our registrars has ~3.= 6 million zones hosted on its name servers.=C2=A0 We have historically allo= wed end users to put CNAMEs wherever they want in the UI, but have a CNAME = "emulator" in the publishing path replaces the illegal ones befor= e they're inserted in a zone. =C2=A0=C2=A0

Dur= ing the month of February, the CNAME emulator initiated 872k changes to 28k= zones, with an average of 31 changes per zone.=C2=A0 The minimum/maximum c= hanges per zone were 1 and 231 respectively. =C2=A0

A change is updating one or more replaced CNAME records in a single actio= n, so this doesn't count individual CNAMEs updated.=C2=A0 It's also= possible actual changes occurred on authoritative servers more often, sinc= e we avoid DoSing upsteam authoritatives.

Here'= ;s the distribution of the =C2=A0number of zones per number of changes.=C2= =A0 I've used a LOG scale, since there's a spike of 10k zones with = 42 changes, which makes a linear graph unreadable.

<http://imgur.com/RzuHgks><= /div>


--001a113d1444092c8c054c59d12b-- From nobody Tue Apr 4 10:21: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 9CAC4129470 for ; Tue, 4 Apr 2017 10:21:11 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 kUw1J-AKVcqm for ; Tue, 4 Apr 2017 10:21:09 -0700 (PDT) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) (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 3F500127A97 for ; Tue, 4 Apr 2017 10:21:09 -0700 (PDT) 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]:40492) 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 1cvS8h-0005xA-mo (Exim 4.89) (return-path ); Tue, 04 Apr 2017 18:21:07 +0100 Date: Tue, 4 Apr 2017 18:21:06 +0100 From: Tony Finch To: Matthew Pounsett cc: dnsop , Peter van Dijk In-Reply-To: Message-ID: References: <20170330230806.6273.qmail@ary.lan> <9232F4F4-772F-48AA-80FB-C990662AFD7A@powerdns.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 17:21:12 -0000 Matthew Pounsett wrote: > On 3 April 2017 at 07:55, Tony Finch wrote: > > > > If you expand ALIAS on the master server like this, I would expect that > > most of the time the target addresses won't change very frequently, so the > > IXFR rate should be much less than the ALIAS polling frequency. > > I believe that's a faulty assumption. Here's some data: > > [...] During the month of February, [...] an average of 31 changes per zone. [...] That seems to agree with what I meant, though I probably should have said "per-zone" somewhere :-) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Faeroes, Southeast Iceland: Northwesterly gale 8 to storm 10, backing southwesterly 5 to 7 later. High or very high becoming very rough, occasionally rough later. Squally showers, drizzle later. Moderate or poor. From nobody Tue Apr 4 10:30: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 0E25B129418 for ; Tue, 4 Apr 2017 10:30:40 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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=conundrum-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 t6Ce88X3hQKg for ; Tue, 4 Apr 2017 10:30:38 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 514BC129407 for ; Tue, 4 Apr 2017 10:30:37 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id r69so183957256vke.2 for ; Tue, 04 Apr 2017 10:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eZylQ7vVi/3RyYwiFf1AmyxlZ3EqyO6yUz1ZxJHlb6c=; b=U3ksL8d2yruuJSA5jK+MBTt5YbUlavEPX0A2vnBQFIntAjUvaATWDL115l3RDnpJ7h g4VPi2Mr441rZg03EhZdrVjo1EqXynjFMSSZRhk7+GOw07PaAxODXxvTqQ8AspFkKy+d zvjkd64aOM+kHYZLXhMzZeWRAmEk1FiNArbmFUCQp/XPyiBCSyDC18DRmMf4yQOAQvEN C/tKjDUtjdMQrShmR8Hu0wf4T2Bi14tI6cJtHCGeGQwzymTqT4nzMIRUZTESYmox11nZ 0EpcbEnpmKiEfgS2PvqvuYg0ViXm1OtcmS/MPAEB118IK5LD7X8gGddvEpq6XWlQHCo+ 7ulg== 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=eZylQ7vVi/3RyYwiFf1AmyxlZ3EqyO6yUz1ZxJHlb6c=; b=XTnyCRNq/A1+JNLz/bzidX+TKcMx9oadVhce3PwW7QaH+sFfYU2M0aIDijVoItADxQ DTGBQF1nT1mmCC0MgrjJ4rVEiwVMc6Gnpqa8OcYNAe6ZmXkbQiQ7JjBnWHmBwbK713xI uwuI0lgklLAynfdY0Cr6Ev48BKwHtGu/0pYTvCuCT6Y9UGuL+dXV5DGTzF88+PCyPA6z 7Myq/O5zvj74r8xVkyptlm7Bt6ZFC4s+oa08JYYUfcw39hweVDDnJATMeD0VMz3LX1Ww wEOG1lF9shQMu+DeA9RgGY9SkOQm+PIuyfBvMZuVDL1CM/eMKIfJ9xwoigr54JGvY7RX 27Fg== X-Gm-Message-State: AFeK/H007DSVbsPRQqW3iFJePoDuqrxOlFW0yeqJ3yfo0FePIQCLwoUzf1UL34ITmm510BHSnGTvwEGR4wDHzA== X-Received: by 10.31.167.8 with SMTP id q8mr11009776vke.101.1491327036889; Tue, 04 Apr 2017 10:30:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.69 with HTTP; Tue, 4 Apr 2017 10:30:36 -0700 (PDT) In-Reply-To: References: <20170330230806.6273.qmail@ary.lan> <9232F4F4-772F-48AA-80FB-C990662AFD7A@powerdns.com> From: Matthew Pounsett Date: Tue, 4 Apr 2017 13:30:36 -0400 Message-ID: To: Tony Finch Cc: dnsop , Peter van Dijk Content-Type: multipart/alternative; boundary=001a11425bf84752e7054c5aa2c0 Archived-At: Subject: Re: [DNSOP] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 17:30:40 -0000 --001a11425bf84752e7054c5aa2c0 Content-Type: text/plain; charset=UTF-8 On 4 April 2017 at 13:21, Tony Finch wrote: > > I believe that's a faulty assumption. Here's some data: > > > > [...] During the month of February, [...] an average of 31 changes per > zone. [...] > > That seems to agree with what I meant, though I probably should have said > "per-zone" somewhere :-) > > That's the average, but there's a not-insignificant number there being updated many times per day. Most of the time, you're right, there are few changes, but one can't assume that any given alias will have a low rate of change. --001a11425bf84752e7054c5aa2c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 4 April 2017 at 13:21, Tony Finch <dot@dotat.at> wrote:
> I believe that's = a faulty assumption.=C2=A0 =C2=A0Here's some data:
>
> [...] During the month of February, [...] an average of 31 chan= ges per zone. [...]

That seems to agree with what I meant, though I probably should have said "per-zone" somewhere :-)

That's the = average, but there's a not-insignificant number there being updated man= y times per day. =C2=A0 =C2=A0Most of the time, you're right, there are= few changes, but one can't assume that any given alias will have a low= rate of change.
--001a11425bf84752e7054c5aa2c0-- From nobody Tue Apr 4 11:35: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 3CA03129469 for ; Tue, 4 Apr 2017 11:35:38 -0700 (PDT) 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 Zz9u_5hj0U6v for ; Tue, 4 Apr 2017 11:35:36 -0700 (PDT) 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 198F6129497 for ; Tue, 4 Apr 2017 11:35:34 -0700 (PDT) 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 056203493D3; Tue, 4 Apr 2017 18:35:30 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C6A81160045; Tue, 4 Apr 2017 18:35:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 95761160071; Tue, 4 Apr 2017 18:35: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 06cigvahO9Hs; Tue, 4 Apr 2017 18:35: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 D66FD160045; Tue, 4 Apr 2017 18:35:28 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2B15A6A8A07B; Wed, 5 Apr 2017 04:35:25 +1000 (AEST) To: Stephane Bortzmeyer Cc: dnsop@ietf.org From: Mark Andrews References: <148942077219.17007.342057944218385620@ietfa.amsl.com> <20170328143352.GA12923@laperouse.bortzmeyer.org> In-reply-to: Your message of "Tue, 28 Mar 2017 09:33:52 -0500." <20170328143352.GA12923@laperouse.bortzmeyer.org> Date: Wed, 05 Apr 2017 04:35:25 +1000 Message-Id: <20170404183525.2B15A6A8A07B@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 18:35:38 -0000 In message <20170328143352.GA12923@laperouse.bortzmeyer.org>, Stephane Bortzmeyer writes: > On Mon, Mar 13, 2017 at 08:59:32AM -0700, > internet-drafts@ietf.org wrote > a message of 45 lines which said: > > > Title : DNS Terminology > > Authors : Paul Hoffman > > Andrew Sullivan > > Kazunori Fujiwara > > Filename : draft-ietf-dnsop-terminology-bis-05.txt > > The new definition of QNAME describes as equivalent two conflicting > definitions, the original one, in RFC 1034, and the one of RFC 2308, > which seems used only by this RFC. IMHO, we should keep only the RFC > 1034 definition. RFC 1034 If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Note "QNAME" refers the the name *after* CNAME substituion when you are following the process as described in 4.3.2. Algorithm. There is no confict between 1034 and 2308. Only a failure to examine all uses of QNAME in 1034. Mark > I filed an errata against RFC 2308 > > > _______________________________________________ > 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 Tue Apr 4 13: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 9740E1294F4 for ; Tue, 4 Apr 2017 13:28:11 -0700 (PDT) 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 il49tgJ383dc for ; Tue, 4 Apr 2017 13:28:09 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002: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 DBF881294BF for ; Tue, 4 Apr 2017 13:28:08 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id l201so47769020ybf.0 for ; Tue, 04 Apr 2017 13:28:08 -0700 (PDT) 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; bh=LQdElVNgAWRn5As8+/LrM/TjjEEHyNUdcGn3upfARNU=; b=ABbI0p9ckneqrnny3k+pieF5AOqdD0fFAzJ1uI72cSKofLQaNolfdVEcGkt64dzECw B6EXAjLTAk/9BezSDj5gue8LotF4ejxWqZYqALZaSfF8ulPW2h3UQ+VpuPwsV0jpdlNy oBXlim3YOG47dAsyc6nVz5flRIQRUZ1sogA170cN8qxJWFMg+b+gmzjQkntOz4lILWSz vRE6nQsGdkW7UBUYlMzzH6GrwpshF4N5i9o0747i1PGdSH6KUQN810baCVbvRbWT7lpw P6qx/XCT8Pd50Sl0CvaAtBbY5NRy0kOHqO71QHkWVobCERn0srk/ancKSXaRYL7lo9vP a38Q== 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=LQdElVNgAWRn5As8+/LrM/TjjEEHyNUdcGn3upfARNU=; b=BaoxwsZZl9+AuWM1Ec7+7HmfYWOco270MKgXTFBMpuuMNIAWywuIWqz/uH0KLgG0hF eHwRJxJRg87CmUKPGMX38IM4/PCnc6aMiZf7QvTNyuKyYqZ2P18W6kWXbmUwk152OTxV cwbB8tLQXHJZ4MB7U0Ro3fUw++pMvn8hzcmzKBduEvdTYR3uP89UNN1vEppXOllXMclc vFPajzHBZo5yXRT4URAmNfYtqtVh0H73Tea35I3adEX1j+2WK4ZYtfReWKaE/dY+dS88 8wGOANnAahu3UtumhBloYFDQeU4Ox6K+saB/JVhbB7kXm5eF0d+Lx7QBLMhUWZLro6oo 4sRQ== X-Gm-Message-State: AFeK/H2raSdLg0ikh96JCsORxoX31WNms5Hdb2LucRS85W6fIjEnCDMwpOpaOtgVfLuYi8xtl66JV4W22FS3priF X-Received: by 10.37.217.15 with SMTP id q15mr14834516ybg.23.1491337687413; Tue, 04 Apr 2017 13:28:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.109.134 with HTTP; Tue, 4 Apr 2017 13:28:06 -0700 (PDT) In-Reply-To: <149130746853.30870.8028044269482471265@ietfa.amsl.com> References: <149130746853.30870.8028044269482471265@ietfa.amsl.com> From: Bob Harold Date: Tue, 4 Apr 2017 16:28:06 -0400 Message-ID: To: IETF DNSOP WG Content-Type: multipart/alternative; boundary=94eb2c05fd82194707054c5d1d4f Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 20:28:12 -0000 --94eb2c05fd82194707054c5d1d4f Content-Type: text/plain; charset=UTF-8 On Tue, Apr 4, 2017 at 8:04 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 : Security Considerations for RFC5011 Publishers > Authors : Wes Hardaker > Warren Kumari > Filename : draft-ietf-dnsop-rfc5011- > security-considerations-00.txt > Pages : 9 > Date : 2017-04-03 > > 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011- > security-considerations/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011- > security-considerations-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security- > considerations-00 > > This one still needs to be fixed: ---------- "6. Minimum RFC5011 Timing Requirements ... 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 equation no longer contains "3 * " anywhere. -- Bob Harold --94eb2c05fd82194707054c5d1d4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 4, 2017 at 8:04= 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:= Security Considerations for RFC5011 Publishers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Wes = Hardaker
=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 Warren Kumari
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-rfc5011-security-considerations-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-04-03

Abstract:
=C2=A0 =C2=A0This document describes the math behind the minimum time-lengt= h that
=C2=A0 =C2=A0a DNS zone publisher must wait before using a new DNSKEY to si= gn
=C2=A0 =C2=A0records when supporting the RFC5011 rollover strategies.


The IETF datatracker status page for this draft is:
https://datatracke= r.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/<= /a>

There are also htmlized versions available at:
https://tools.ietf.or= g/html/draft-ietf-dnsop-rfc5011-security-considerations-00 https://dat= atracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-00


This one still needs to be fixed:

----------
"6. Minimum RFC5011 Timing Requirements=
...
The most confusing element of the above equation comes from th= e "3 *
=C2=A0 =C2=A0(DNSKEY RRSIG Signature Validity) / 2" ele= ment, but is the most
=C2=A0 =C2=A0critical to understand and get right= ."
-----------

But the equation no longer co= ntains "3 * " anywhere.

--=C2=A0
Bob Ha= rold

=C2=A0
--94eb2c05fd82194707054c5d1d4f-- From nobody Tue Apr 4 14:04: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 C68E1129531 for ; Tue, 4 Apr 2017 14:04:11 -0700 (PDT) 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=gO2p0+oh; dkim=pass (1024-bit key) header.d=yitter.info header.b=DRgbwLBB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTDzcgRyulKY for ; Tue, 4 Apr 2017 14:04:10 -0700 (PDT) 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 24E6512778E for ; Tue, 4 Apr 2017 14:04:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 7FC17BEF8C for ; Tue, 4 Apr 2017 21:03:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1491339817; bh=CEAwZWJW5WqT2N0tS5PaBA8L3k5BLDhQOYQdbAf7rok=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gO2p0+ohkJJSIBwCUaCbsL6hlS4Jae54bzF+8KDJSnEvbxouGyhWj7ZCx2WEEW4fJ 7InuWeBVqttPl/+sZwPhudobylAm59/zm/vaXY/XrOSOA/wAd2bAbp/XGIFVKVXSQ3 n8lgeT4CcLagBnPz/LkwF4M4zs4c5b6mMO7dCVOM= 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 TZu4drt_sGoD for ; Tue, 4 Apr 2017 21:03:36 +0000 (UTC) Date: Tue, 4 Apr 2017 17:03:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1491339816; bh=CEAwZWJW5WqT2N0tS5PaBA8L3k5BLDhQOYQdbAf7rok=; h=Date:From:To:Subject:References:In-Reply-To:From; b=DRgbwLBB+O4A9cvLN/Qtp8ameK93h7smsXW+AjrLm9V93LcnJWcxq8HStmC2co6vs ZfrdUBG58a3tm3HYfq6nBtltqZrTw71tcg4dN1jkXlYHm0FteyMEW0Trt94F5J69Nx tP9ck9gXIVlie6sQ9zu8sk4Frtl2DajjUiEe792U= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170404210333.GA1803@mx4.yitter.info> References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170401201727.GA5948@laperouse.bortzmeyer.org> Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 21:04:12 -0000 Hi, Thanks for the review. On Sat, Apr 01, 2017 at 03:17:27PM -0500, Stephane Bortzmeyer wrote: > Editorial : > > Section 1: > > "and that should not be resolved" I cannot parse it. Missing "it"? Yes. > > Section 5 : > > After "and anyone watching queries along the path", add a reference to > RFC 7626? A good idea. Thanks. > Normative references: > > Why is RFC 6303 a normative reference? It is no longer used. Should be removed. Thanks. > Why is RFC 7686 a normative reference? It is just an example. Yeah, we should move it. Thanks. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Apr 4 14:10: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 985B8126DFB for ; Tue, 4 Apr 2017 14:10:10 -0700 (PDT) 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=C5NUhTGr; dkim=pass (1024-bit key) header.d=yitter.info header.b=KQgdDTrV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Yd-crIE3-aY for ; Tue, 4 Apr 2017 14:10:08 -0700 (PDT) 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 BC00012778E for ; Tue, 4 Apr 2017 14:10:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 3B0A2BEF8C for ; Tue, 4 Apr 2017 21:09:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1491340177; bh=a1rV7SwFm+eKHhY2HmJdrcESsWHYS/oby9z3c3JCQN0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=C5NUhTGrTtIbca7oHPRmPe9Qztkxes+r5RjHU/J0SiwQ7yjpk8Y/eEGB/lKbXIl+G DpQ5fdUZx6gcRVnVQFh+ZIwQfLGv9IiF5Evm/rQJXkJjJWINigzknpZLsUOBgTWzo/ /ufbIG/AqTABnxPvgI2UVijYI0A8ChUzzdeMYZi0= 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 1LSQ1gInWxEf for ; Tue, 4 Apr 2017 21:09:36 +0000 (UTC) Date: Tue, 4 Apr 2017 17:09:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1491340176; bh=a1rV7SwFm+eKHhY2HmJdrcESsWHYS/oby9z3c3JCQN0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=KQgdDTrVC2YxHvgcZBjAD1P5V+cc1BCov++C9teN5i9efkXwiGmpmwa5VZc6l/w3u w01H2kwaMrpFz7ZRP4iPL5thZaFgzOQBwtBkUgJj/8Mw+8KtZKJbfqj6CRb56rqaF2 hkoU7+pAij8SK/bFfxwu4DMZhoVr0IZxX+uYOgZo= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170404210934.GB1803@mx4.yitter.info> References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> <3C85C5DB-7F1A-45B7-BE2A-926065F2C266@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 21:10:11 -0000 Hi George, On Mon, Apr 03, 2017 at 08:02:19PM -0500, George Michaelson wrote: > The only reference to ICANN delegation process Why should there be any reference to any ICANN delegation process? The name is to be added to the special-use registry, taking it out of conteplation as a DNS name. > Secondly, The authors make a judgement call in this block that they > feel requesting delegation is not required. I don't feel the consensus > was that strong actually, but you know, I guess I could be wrong on > that. We understood the WG to have decided, in my view correctly, that this name was exclusively for use outside the DNS. Section 3 makes that perfectly clear, I think: This document reserves the ALT label, using the [RFC6761] process, for use as an unmanaged pseudo-TLD namespace. The ALT label MAY be used in any domain name as a pseudo-TLD to signify that this is an alternative (non-DNS) namespace, and should not be looked up in a DNS context. > Thirdly the draft contains no language which actually explains why a > TLD is required The simple reason is to save octets, since these names need to fit in DNS protocol slots and therefore are subject to the 255 octet limit. We did remove that discussion somewhere along the line; I'm prepared to add it back if you like. Certainly the name could go under arpa, but when we discussed it before the conclusion was that it took too many octets that way. > Lastly, I think the IAB note pretty strongly goes to 'we dont do that > any more' I understand the IAB note to be about the case where the name is intended for use with the DNS, so I don't think it is relevant to this use case. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Apr 4 22:43: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 5D21E126C22 for ; Tue, 4 Apr 2017 22:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 N7fNJbFq9Shd for ; Tue, 4 Apr 2017 22:43:46 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id CA2ED126C26 for ; Tue, 4 Apr 2017 22:43:45 -0700 (PDT) Received: from jurassic (unknown [115.118.211.60]) (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 AF6AF56A0447; Wed, 5 Apr 2017 05:43:43 +0000 (GMT) Date: Wed, 5 Apr 2017 11:13:38 +0530 From: Mukund Sivaraman To: dnsop@ietf.org Message-ID: <20170405054338.GA15831@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: [DNSOP] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 05:43:47 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Evan just pointed out a case due to a system test failure that is interesting.. it's not clear what the behavior should be in this case, so please discuss: There's a nameserver that's authoritative for 2 zones example.org. and example.com. In the example.org. zone, foo.example.org. is CNAME to bar.example.com. In the example.com. zone, the name bar.example.com. doesn't exist (NXDOMAIN). A query for "foo.example.org./A" is answered by the nameserver. It adds the foo.example.org. CNAME bar.example.com. in the answer section, and then, following RFC 1034 4.3.2. 3.(a.), sets the QNAME to "bar.example.com" and looks into the "example.com" zone for "bar.example.com.". It is not found. The question is: what is the expected reply RCODE for this? 1. Is it NOERROR (0) because there is an answer section with the CNAME? 2. Is it NXDOMAIN (3) because the CNAME target was not found? 3. Does it not matter if it is either? It seems to me that it should be NOERROR(1) because RFC 1035 defines NXDOMAIN as "this code signifies that the domain name referenced in the query does not exist" which in my interpretation doesn't match the modified QNAME when following the CNAME change. Also, if a resolver caches the NXDOMAIN against the question section name (foo.example.org.) , then a follow-up query to the resolver for "foo.example.org./CNAME" will return an NXDOMAIN from cache. It seems BIND currently returns NXDOMAIN in this case, and the change in behavior between looking-into-other-zones and not-looking-into-other-zones in the nameserver algorithm caused a system test failure, hence the question. Mukund --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY5IQJAAoJEB9EXrAiC5LsThUP/jqfKBZ/fcdLQxHAM4niQ89g kRHhvbDar9zNLYgvC8lh5ZBB8Ko60SYB2S+QcYQQ3ZiGfxyKd0GgDG3b+bsvizub lFPgwo+uzG8nzA2BQ8854S1usosF0tNiD76Rh5VDEp3mZKY/XVVzbnydKfGZwY7U 6IUH+8AWe5W/ub54rqrPsGLO8AhZyZcismxpLG/AJ41biVAMBwblVWpLE8upHrOg imDgeuwT/fAqUbkN90ny7Td0mQ/hV/ctWxB/Y61F91EvzqNwaveG5kCqwuOSuhk2 EwkiT8XiX5zY7S1Sl4c4i4rpLQ6lUAxNm8k2aLTw5ddXSK/rwPNxjVdq9tTEIy87 OGhXbkyRI4NwQyt8ny/6r5ha8gSt1Nto0pn0CmpqWBDXbxAAGGDxqLRIXlI15VR2 M8VtYTdL7BZfT34xFszEJf4uf+G7NWDGNDOQIkACGzq+cgCjgTF2uJ1J59i9D4HN YAxLitCSmSl5+ZjxtwXpNX2OsemEyJJ48NrGvCjreuGRunOzoPDyzyh4NJUXYm2l iGfEeljDu27/ndLQSTjS0jBQLIpFhQE81ULkqesjtghn2dWXeW1Z0etTJmH+ayLn SJFa91IvmMDVKee2lwJEphvweQVt0HKsZFug0XQgThDFPDsGg/2cIGVTHhEqW3k6 SUeuToHfTY9ItfYo7qLw =Kb83 -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From nobody Tue Apr 4 22:47: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 7B386129418 for ; Tue, 4 Apr 2017 22:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FsbndEfG_Ymj for ; Tue, 4 Apr 2017 22:47:28 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 623AC129416 for ; Tue, 4 Apr 2017 22:47:28 -0700 (PDT) Received: from jurassic (unknown [115.118.211.60]) (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 9DBE456A0447; Wed, 5 Apr 2017 05:47:26 +0000 (GMT) Date: Wed, 5 Apr 2017 11:17:23 +0530 From: Mukund Sivaraman To: dnsop@ietf.org Message-ID: <20170405054723.GB15831@jurassic> References: <20170405054338.GA15831@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0eh6TmSyL6TZE2Uz" Content-Disposition: inline In-Reply-To: <20170405054338.GA15831@jurassic> User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [DNSOP] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 05:47:29 -0000 --0eh6TmSyL6TZE2Uz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 05, 2017 at 11:13:38AM +0530, Mukund Sivaraman wrote: > It seems to me that it should be NOERROR(1) because RFC 1035 defines s/NOERROR(1)/NOERROR(0)/ > NXDOMAIN as "this code signifies that the domain name referenced in the > query does not exist" which in my interpretation doesn't match the > modified QNAME when following the CNAME change. s/CNAME change/CNAME chain/ Mukund --0eh6TmSyL6TZE2Uz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY5ITqAAoJEB9EXrAiC5LsXc0P/ii3fWq96X9wlQQcyaFXPusT JIGRQexKSlxoxZ3js6Gqk3G6WwA0mBZxBG/lNZx66b7kwp1RSEGfW4WGt32XZi0a HuMdPi36YKl+cUXKuVK7c73EsdILOkgaf3NvWh5iZfyIro2Ts5+2MHjLxE/jn119 liqmBJjzEdNU8x09cbIDsPa2sGXzOr9yPh2bCfkmQpF/1c0l1h5fUWxBQNdXncCQ NhLHK5rU8KtHYCXnjrcfBsnXafAQqcb8/+T45NE36qkPenpWLKlpamdsGtOFQmwd d3INSiMu2LAAAzw5WAaU4Psj2uLQ4hokUnWprnqSxPYsiPbh5A8EOOztU0IoG50c KSZX34efziH/sCm4C23/Cu/FcugL8HR0VpOqrMn8wDh3PVJPsDEHB8Qmz4inL1F0 yOZ18eoHHtOpiVbSAOgpOuPMuwftuNYhyjkl42EDn2Q16mbDLlZE2g5DCqyxy+Yj H+Z6+sAgNguhdckM3nVFhuNjj825VU97TEBCo6Owq6YOhKQXBLI3BVlbK06pBKtS CLydkb/DIktqPzG5/IRHFyfLy2cSIY4SuWNR1O2OKOtuCU79sqrCQVKeUD8EbiNh nYu+8XMBIXlZrcAonYHVGzaPcEKDv2hfpNhJzpPuhFlRvW8D5ZcIa/t9oBEW+ajO ZlOEmq+jP9423PuBWLA0 =wC7c -----END PGP SIGNATURE----- --0eh6TmSyL6TZE2Uz-- From nobody Tue Apr 4 23: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 28D531292FD for ; Tue, 4 Apr 2017 23:57:19 -0700 (PDT) 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 8dhbCN6CzPqh for ; Tue, 4 Apr 2017 23:57:17 -0700 (PDT) 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 4BCB112704A for ; Tue, 4 Apr 2017 23:57:16 -0700 (PDT) Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:ec43:d35c:953f:7ad]) (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 6D215C1B96; Wed, 5 Apr 2017 08:57:14 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Wed, 05 Apr 2017 08:57:18 +0200 Message-ID: In-Reply-To: <20170328143352.GA12923@laperouse.bortzmeyer.org> References: <148942077219.17007.342057944218385620@ietfa.amsl.com> <20170328143352.GA12923@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 06:57:19 -0000 Hello Stephane, On 28 Mar 2017, at 16:33, Stephane Bortzmeyer wrote: > On Mon, Mar 13, 2017 at 08:59:32AM -0700, > internet-drafts@ietf.org wrote > a message of 45 lines which said: > >> Title : DNS Terminology >> Authors : Paul Hoffman >> Andrew Sullivan >> Kazunori Fujiwara >> Filename : draft-ietf-dnsop-terminology-bis-05.txt > > The new definition of QNAME describes as equivalent two conflicting > definitions, the original one, in RFC 1034, and the one of RFC 2308, > which seems used only by this RFC. IMHO, we should keep only the RFC > 1034 definition. > > I filed an errata against RFC 2308 > Notwithstanding your stubborn redefinition in 8020, the text in 2308 is correct and this erratum is wrong. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Wed Apr 5 00:03: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 8F7F7128B44 for ; Wed, 5 Apr 2017 00:03:49 -0700 (PDT) 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 EqdoU25ztLR7 for ; Wed, 5 Apr 2017 00:03:47 -0700 (PDT) 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 E30011292FD for ; Wed, 5 Apr 2017 00:03:40 -0700 (PDT) Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:ec43:d35c:953f:7ad]) (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 471FEC1B96; Wed, 5 Apr 2017 09:03:39 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Wed, 05 Apr 2017 09:03:43 +0200 Message-ID: <73DD364E-12F0-4367-964D-6C18E37BC12B@powerdns.com> In-Reply-To: <20170405054338.GA15831@jurassic> References: <20170405054338.GA15831@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_E9737506-7D9B-40F1-992F-14D5E6CAE68D_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 07:03:49 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_E9737506-7D9B-40F1-992F-14D5E6CAE68D_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Mukund, On 5 Apr 2017, at 7:43, Mukund Sivaraman wrote: > Evan just pointed out a case due to a system test failure that is > interesting.. it's not clear what the behavior should be in this case, > so please discuss: > > There's a nameserver that's authoritative for 2 zones example.org. and > example.com. > > In the example.org. zone, foo.example.org. is CNAME to bar.example.com.= > > In the example.com. zone, the name bar.example.com. doesn't exist (NXDO= MAIN). > > A query for "foo.example.org./A" is answered by the nameserver. It adds= > the foo.example.org. CNAME bar.example.com. in the answer section, and > then, following RFC 1034 4.3.2. 3.(a.), sets the QNAME to > "bar.example.com" and looks into the "example.com" zone for > "bar.example.com.". It is not found. > > The question is: what is the expected reply RCODE for this? > > 1. Is it NOERROR (0) because there is an answer section with the CNAME?= > > 2. Is it NXDOMAIN (3) because the CNAME target was not found? NXDOMAIN is correct. The text on this on 103x is a bit weak but 2308 2.1 = clarifies this. > 3. Does it not matter if it is either? 2308 does say =E2=80=9C Some name servers fail to set the RCODE to NXDOMAIN in the presence of CNAMEs in the answer section. If a definitive NXDOMAIN / NODATA answer is required in this case the resolver must query again using the QNAME as the query label. =E2=80=9C but not all resolvers honour this. So I=E2=80=99d say it does matter. Kind regards, -- = Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ --=_MailMate_E9737506-7D9B-40F1-992F-14D5E6CAE68D_= 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 iQIcBAEBAgAGBQJY5JbPAAoJENz1E/p+7RnzNFgQAI4scfYHu/Sd/zoIrvn+DLKZ HjWHv7ryDayznHFdLPpqJma0l8PnsOsNPLO0AdZ6yGUekJ7t2p7OVKfO3BftPeOa e0VjFCguCI+Su+xyc9Bh8pzRxA6QL7sYHHkF4W4uzBWtKqH8nSMMnRcjQkh7Ryeg zFuWLJ4lyNk5QTW50QsviCDrWSUUaXaOA1f7PAmxVjouTqKLkPv21G+hjx4GgnTr 8RECGEwV49PB2FQTmj958HNWIGkVT1eB5lDM7Nid5ViJgjcObv75P8sOP/VG/lpa vqwSX8KkeqU9RzWzPXeI8J3BWn2VO7lutTc4d5EWgmq6nQOhxTc6ms0U2sbqgTNE 9yjxzliH6+Dhac+EWvgON3j4v02lkqLq5g/klCFoDTGsYCMS4ORAWoiJYZ+iWlXK APWtk6EdemckXiRR636oQ8LpkSgrvn9F4V8ikzjqxS0Y8eKtcTFaR6Z4/DRxj4kQ FM8fabZKpqCUG4JWTyy8Pc61NcEMzPpbjEQlRh84tFqP3t9JG3KJOl4oMOOjG3ob SKYsFYOQqXLM8EDDQQ9Zo8It8/nYIxU6EofeANT+3Fd5IhbF/UyVwDZrghvYIKfP O2E9E7u1is+UkjqQGbrsVyQRHQjxsUow1s+y/4WjZnS3X0P4p0+XfBBzp0O6e+KY /Aa8eBCfQEwnz6uWkwsM =ic4D -----END PGP SIGNATURE----- --=_MailMate_E9737506-7D9B-40F1-992F-14D5E6CAE68D_=-- From nobody Wed Apr 5 00:14: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 A29FC128B44 for ; Wed, 5 Apr 2017 00:14:26 -0700 (PDT) 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 5HvEF1ZwqnZ2 for ; Wed, 5 Apr 2017 00:14:25 -0700 (PDT) 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 38F5612704A for ; Wed, 5 Apr 2017 00:14:25 -0700 (PDT) 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 4EA043493E2 for ; Wed, 5 Apr 2017 07:14:22 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3F2ED16005B; Wed, 5 Apr 2017 07:14:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2FF35160072; Wed, 5 Apr 2017 07:14:22 +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 JTvo48DLZ81z; Wed, 5 Apr 2017 07:14:22 +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 A7B4016005B; Wed, 5 Apr 2017 07:14:21 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id CF48F6A8DCB6; Wed, 5 Apr 2017 17:14:15 +1000 (AEST) To: Mukund Sivaraman Cc: dnsop@ietf.org From: Mark Andrews References: <20170405054338.GA15831@jurassic> In-reply-to: Your message of "Wed, 05 Apr 2017 11:13:38 +0530." <20170405054338.GA15831@jurassic> Date: Wed, 05 Apr 2017 17:14:15 +1000 Message-Id: <20170405071415.CF48F6A8DCB6@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 07:14:26 -0000 In message <20170405054338.GA15831@jurassic>, Mukund Sivaraman writes: > Evan just pointed out a case due to a system test failure that is > interesting.. it's not clear what the behavior should be in this case, > so please discuss: > > There's a nameserver that's authoritative for 2 zones example.org. and > example.com. > > In the example.org. zone, foo.example.org. is CNAME to bar.example.com. > > In the example.com. zone, the name bar.example.com. doesn't exist (NXDOMAIN). > > A query for "foo.example.org./A" is answered by the nameserver. It adds > the foo.example.org. CNAME bar.example.com. in the answer section, and > then, following RFC 1034 4.3.2. 3.(a.), sets the QNAME to > "bar.example.com" and looks into the "example.com" zone for > "bar.example.com.". It is not found. > > The question is: what is the expected reply RCODE for this? > > 1. Is it NOERROR (0) because there is an answer section with the CNAME? > > 2. Is it NXDOMAIN (3) because the CNAME target was not found? > > 3. Does it not matter if it is either? > > It seems to me that it should be NOERROR(1) because RFC 1035 defines > NXDOMAIN as "this code signifies that the domain name referenced in the > query does not exist" which in my interpretation doesn't match the > modified QNAME when following the CNAME change. No. The RCODE references the end of the CNAME/DNAME chain. > Also, if a resolver caches the NXDOMAIN against the question section > name (foo.example.org.) , then a follow-up query to the resolver for > "foo.example.org./CNAME" will return an NXDOMAIN from cache. Then the resolver is broken. > It seems BIND currently returns NXDOMAIN in this case, and the change in > behavior between looking-into-other-zones and > not-looking-into-other-zones in the nameserver algorithm caused a system > test failure, hence the question. > > Mukund If the qtype is CNAME or ANY the answer is NOERROR as the CNAME is not followed. If the qtype isn't CNAME or ANY the answer is NXDOMAIN as the CNAME is followed. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Apr 5 01:43: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 861FA129438 for ; Wed, 5 Apr 2017 01:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ig8wwklXAU05 for ; Wed, 5 Apr 2017 01:43:03 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id B6C86128CDC for ; Wed, 5 Apr 2017 01:43:01 -0700 (PDT) Received: from jurassic (unknown [115.118.211.60]) (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 5727D56A053B; Wed, 5 Apr 2017 08:43:00 +0000 (GMT) Date: Wed, 5 Apr 2017 14:12:57 +0530 From: Mukund Sivaraman To: dnsop@ietf.org Message-ID: <20170405084256.GA22692@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dnssec-sha3-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 08:43:05 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This was submitted today: > A new version of I-D, draft-muks-dnsop-dnssec-sha3-00.txt > has been successfully submitted by Mukund Sivaraman and posted to the > IETF repository. > Name: draft-muks-dnsop-dnssec-sha3 > Revision: 00 > Title: Use of SHA-3 (Keccak) Algorithms in DNSSEC > Document date: 2017-04-04 > Group: Individual Submission > Pages: 13 > URL: https://www.ietf.org/internet-drafts/draft-muks-dnsop-dnssec-sha3-00.txt > Status: https://datatracker.ietf.org/doc/draft-muks-dnsop-dnssec-sha3/ > Htmlized: https://tools.ietf.org/html/draft-muks-dnsop-dnssec-sha3-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dnssec-sha3-00 > Abstract: > This document describes how to produce RSA/SHA3-256, RSA/SHA3-384, > and RSA/SHA3-512 DNSKEY and RRSIG resource records for use in the > Domain Name System Security Extensions ([RFC4033], [RFC4034], and > [RFC4035]). It also describes how to produce SHA3-256 and SHA3-384 > DS digest types. An experimental BIND implementation is available here (sha3 branch): https://github.com/muks/bind9/tree/sha3 The examples in the draft were generated using this implementation. Mukund --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY5K4QAAoJEB9EXrAiC5LsDvMP/3tDHHvfjbpm//MTWREnVZyq h0Qi1GIvgfqy6KNhDdz1krIWGJ6FMEbK0jhi2tRS0pOHMbZLcP+VfI2K8JugizyX Z7M7rWeTUIZOi1ifd8SaqDx8HX8pqgyfN8q/4VAQUGn/NeBKDl2l15AR7AqtbdUe y4Fy97NK6RqtotYyqElwYAqoHeg0FaC6i2RgWhNxATdovkyf+ajwQqAAnXlaZmlw hnykEW9k3jPuUcb/8QqSHGO0YVXIYQBNq6FWsVW9LdRe/2zJoo65MjD6aAbw1ObV 9JUbU9fqq52VF5uKAW7pG2TtsiAmgG48nr7Fkyj62QIT52ew31grvKnRDWD6mjuE rD6qZ8+Ljt//JG73bq/5JWoZC39x+Goxt5NFMgiyrhuvotLG5d9/V2T+KG78CqcI ZdcjmxVmEeU6tDZPcTqbafTc0krUF3lXZXiTZjWCHBIgxvS8gw0rVRrBCdTbYTKV nkdgFkwkzJv6unu4LW+FEJCvOuRAU9jGOsD6C6tV5WNoRH+CQkSsCu6usbsoWwfJ wm7uUf74uTO/9T9NieWEeXGOAltzjKcBqYReevOLEkK1wKksriigwGGe5OxyGCd8 JYbC1E6PazBy6M2YHVusoDAXJ649dhlfUYBAVXmZtCAPK9/v5QuPIdcGRYNi3Nqd 6zCO0bGj8qiVYt6QgyAq =WPHT -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From nobody Wed Apr 5 06:34: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 A3053129405 for ; Wed, 5 Apr 2017 06:34:39 -0700 (PDT) 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 gJKV435u3_KN for ; Wed, 5 Apr 2017 06:34:37 -0700 (PDT) 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 6B570127863 for ; Wed, 5 Apr 2017 06:34:37 -0700 (PDT) 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, 5 Apr 2017 06:34:35 -0700 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, 5 Apr 2017 06:34:35 -0700 From: Edward Lewis To: Mukund Sivaraman , "dnsop@ietf.org" Thread-Topic: [Ext] [DNSOP] RCODE and CNAME chain Thread-Index: AQHSrc+er/xSohK310Ock8cYx7x68KG2+WQA Date: Wed, 5 Apr 2017 13:34:34 +0000 Message-ID: <797A6C99-C9B7-4671-A29D-6ECFEF6A5B6D@icann.org> References: <20170405054338.GA15831@jurassic> In-Reply-To: <20170405054338.GA15831@jurassic> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 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_3574229674_411370557" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:34:40 -0000 --B_3574229674_411370557 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 4/5/17, 01:43, "DNSOP on behalf of Mukund Sivaraman" wrote: >It seems BIND currently returns NXDOMAIN in this case, and the change in >behavior between looking-into-other-zones and >not-looking-into-other-zones in the nameserver algorithm caused a system >test failure, hence the question. I don't think there is one right answer. There may be a more efficient answer (in terms of some metric). The goal of the RFCs was interoperability, keep that in mind. You allude above to an implementation changing its behavior (answering from all available data vs. sticking to one zone). This is not something that is explicitly dealt with in the original RFCs, perhaps in later ones. Both choices have merit, have downsides, still the two are interoperable. As far as the protocol matters, either is a valid choice, and one that influences whether the query in question results in NOERROR/CNAME chain or NXDOMAIN. In this case, I think you don't need to worry about the querier. Rules seem to be explicit about caching responses here. If anything, make sure your test script is accurate. (Back in the day of DNSSEC protocol/code development, 1 out of 3 times DNSSEC had a protocol bug, 1 out of 3 times it was a software bug, and 1 out of 3 times everything was right but the tester - me - was expecting the wrong result.) --B_3574229674_411370557 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 tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUwfZ5QLKgW8JYAq7M XfybYyzeiFowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw NDA1MTMzNDM0WjANBgkqhkiG9w0BAQEFAASCAQCNhnaRmzGqg0J2DoIlMbHx1Vzec9QBKqEx j2Mk4AIO6PJK4LXbioJUknkMuM8ubJ1NTwRZzKqB3skE4rTEId5Ggc+siEY7gnxplez9ZLWc 22gpvc3ZeYXPXV6ZmEPH+TEfzhLPOXF8aiVCmZQIZfjZD8aoGSHbYZ0Czr07oaEOfIXv04kt TmKp0GCm9ncj1fjci1eUytjTw/i2VOWNKFRfYrEO2wnsQYPGaygb3bb/f0rNXfl/op/yCycK zHBjiXG2rVhDIB40wnezNZNWaPISqAsRdvCQ0RFzOp6TbgnZDeOvkyroox2/AgslJoaN9d0I kr0VmKTgI0djBOmSl91/ --B_3574229674_411370557-- From nobody Wed Apr 5 06:54: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 54ADF129437 for ; Wed, 5 Apr 2017 06:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 YqAWAGKoQXPV for ; Wed, 5 Apr 2017 06:54:21 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 4E11F128D3E for ; Wed, 5 Apr 2017 06:54:21 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id a140so8877917ita.0 for ; Wed, 05 Apr 2017 06:54:21 -0700 (PDT) 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; bh=oa95MsfVJrfvb26ujzuAksNKPxihlh1DkWoFUCaUzHA=; b=oAaE/Ml63KLWslmaixtOrWbCsBDqIlWzJQVLZo3OdmQapQsllzAiIvfJbam3vx5qo5 U2eDeVltIgs71mVFxzb338sW97Bn4/giGNxKT9/r7Ebgk41TC3FHBgQ57Z/zgFIOMEyk Tg5jHTfcHDazfL+zhgwWugTu85mxsIauMxHCra24xVs4sSo2emjfML2cPMrq6AqCGi2y zOHJYw5y1Pc74gUrZcqpy1XWZQfD652sKLhgmLAphLKxekCMzQaGjap27Kb4QBaeHoBC QTvzIiK0T5Dh6zTNUjNENGA8i39YAZccRE/e6F9G6i5E7xqWxNiNdMoraXQQeQRf0r4y er1g== 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; bh=oa95MsfVJrfvb26ujzuAksNKPxihlh1DkWoFUCaUzHA=; b=FeGAJVUujHXxDRZtBglxGUyr1uabjOKHXUKusjx4ltgEXj/yKWCb7tOShXhycBwObd liRg43GHhVj/LK6SQAjDnYPa7X8cF2yf6EmFclu9Y5iuJfK3a3Eojzkj7UqnN1AWgwX3 NC9AshGyuHkY7fMJB3vVwCGcKDS1NWlRNT7zrjxXEMuDoX0hZoSKUxm1v/aIqjpleSrI Ix3Ua8J5JHe6/k0gBJE0XYbJ8zcM4lmH4Esl+mIc7WRWglA4axbWCGSt2+Ewriurdj6k zr2oRNmtRH7GyHVh5hPnPSYBcroGDyGJpXk9peOCXhXjWr8PD7eLpBiXEqGI9hYbr5U9 S6gw== X-Gm-Message-State: AFeK/H2J1p438Iq1YFvOURism+mTA5EbRTHnF6RhT/rq1kRJ0OqcS6YT JVZo8k1mG6lxUphws1wOTxTBioToSQ== X-Received: by 10.36.155.11 with SMTP id o11mr21209431itd.11.1491400460711; Wed, 05 Apr 2017 06:54:20 -0700 (PDT) MIME-Version: 1.0 References: <20170405054338.GA15831@jurassic> <797A6C99-C9B7-4671-A29D-6ECFEF6A5B6D@icann.org> In-Reply-To: <797A6C99-C9B7-4671-A29D-6ECFEF6A5B6D@icann.org> From: Donald Eastlake Date: Wed, 05 Apr 2017 13:54:09 +0000 Message-ID: To: Edward Lewis , Mukund Sivaraman , "dnsop@ietf.org" Content-Type: multipart/alternative; boundary=001a114f0a14adc371054c6bba79 Archived-At: Subject: Re: [DNSOP] [Ext] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:54:26 -0000 --001a114f0a14adc371054c6bba79 Content-Type: text/plain; charset=UTF-8 See RFC 6604. Donald from iPhone On Wed, Apr 5, 2017 at 09:34 Edward Lewis wrote: > On 4/5/17, 01:43, "DNSOP on behalf of Mukund Sivaraman" < > dnsop-bounces@ietf.org on behalf of muks@isc.org> wrote: > > >It seems BIND currently returns NXDOMAIN in this case, and the change in > >behavior between looking-into-other-zones and > >not-looking-into-other-zones in the nameserver algorithm caused a system > >test failure, hence the question. > > I don't think there is one right answer. There may be a more efficient > answer (in terms of some metric). The goal of the RFCs was > interoperability, keep that in mind. > > You allude above to an implementation changing its behavior (answering > from all available data vs. sticking to one zone). This is not something > that is explicitly dealt with in the original RFCs, perhaps in later ones. > Both choices have merit, have downsides, still the two are interoperable. > As far as the protocol matters, either is a valid choice, and one that > influences whether the query in question results in NOERROR/CNAME chain or > NXDOMAIN. > > In this case, I think you don't need to worry about the querier. Rules > seem to be explicit about caching responses here. > > If anything, make sure your test script is accurate. (Back in the day of > DNSSEC protocol/code development, 1 out of 3 times DNSSEC had a protocol > bug, 1 out of 3 times it was a software bug, and 1 out of 3 times > everything was right but the tester - me - was expecting the wrong result.) > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Sent from Gmail Mobile --001a114f0a14adc371054c6bba79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
See RFC 6604.

Donald

from iPhone

On Wed, Apr 5, 2= 017 at 09:34 Edward Lewis <edw= ard.lewis@icann.org> wrote:
= On 4/5/17, 01:43, "DNSOP on behalf of Mukund Sivaraman" <= dnsop-bounces@ietf.org on behalf of muks@isc.org> wrote:

>It seems BIND currently returns NXDOMAIN in this case, and the change i= n
>behavior between looking-into-other-zones and
>not-looking-into-other-zones in the nameserver algorithm caused a syste= m
>test failure, hence the question.

I don't think there is one right answer.=C2=A0 There may be a more effi= cient answer (in terms of some metric).=C2=A0 The goal of the RFCs was inte= roperability, keep that in mind.

You allude above to an implementation changing its behavior (answering from= all available data vs. sticking to one zone).=C2=A0 This is not something = that is explicitly dealt with in the original RFCs, perhaps in later ones.= =C2=A0 Both choices have merit, have downsides, still the two are interoper= able.=C2=A0 As far as the protocol matters, either is a valid choice, and o= ne that influences whether the query in question results in NOERROR/CNAME c= hain or NXDOMAIN.

In this case, I think you don't need to worry about the querier.=C2=A0 = Rules seem to be explicit about caching responses here.

If anything, make sure your test script is accurate.=C2=A0 (Back in the day= of DNSSEC protocol/code development, 1 out of 3 times DNSSEC had a protoco= l bug, 1 out of 3 times it was a software bug, and 1 out of 3 times everyth= ing was right but the tester - me - was expecting the wrong result.)

_______________________________________________
DNSOP mailing list
DNS= OP@ietf.org
https://www.ietf.org/mailman/listinfo= /dnsop
--
Sent from Gmail Mobile
--001a114f0a14adc371054c6bba79-- From nobody Wed Apr 5 07:17: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 A76211250B8 for ; Wed, 5 Apr 2017 07:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yK1SHDt8K6nM for ; Wed, 5 Apr 2017 07:17:48 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6F5124282 for ; Wed, 5 Apr 2017 07:17:48 -0700 (PDT) Received: from jurassic (unknown [115.118.71.240]) (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 83CCD56A0366; Wed, 5 Apr 2017 14:17:45 +0000 (GMT) Date: Wed, 5 Apr 2017 19:47:42 +0530 From: Mukund Sivaraman To: Donald Eastlake Cc: Edward Lewis , "dnsop@ietf.org" Message-ID: <20170405141742.GA27811@jurassic> References: <20170405054338.GA15831@jurassic> <797A6C99-C9B7-4671-A29D-6ECFEF6A5B6D@icann.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [DNSOP] [Ext] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:17:50 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 05, 2017 at 01:54:09PM +0000, Donald Eastlake wrote: > See RFC 6604. This clears it up. Thank you. Mukund --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY5PyFAAoJEB9EXrAiC5LsoXEQAIp10Atey0uGgykrUWoz/Qkt mTYEYrfs1jSAXYQeBiM/YlrF0rRZIHM9KvH+lkhaufvY7dY+QNY+7Jl/zVIY2eC9 /Pk/tRMb4a+at9GAB0C4lvQq+Us5Mty2Di09s0dSgZ5WjweVl7x1uiH1VUOfr7lw 3tmMpQB7WNbKpVBMOW1ILYx/SxxlW179xAqr64MYvtMLFjIU8yDanBm7GgNbWZwv G4Shd6Xf0Osa8I7Jdhg7/OuJm0OWSyxPnsS0gHsMQZdwgG4Zlayrfu4OI+2SCgK/ HfSjDjMMETng53OWfiycgorWVHX2qYxS5e33iTxj33SxAuiVZ+DMkRzWoI0p7shF ZgB+oP/jJwhrtCNxhBFKPLmntylUmxElFMYzQiIDArFuH3c//wolfZWjmYLRgSrh IVHyB5Zc6MoJOD/bEI11av4UlFiY4KGW+78cN3bHhYaeu8tod5Gbb1J4e0wu1YiJ 6Q3/yHRiybesl7eifnLmBGLB858Tid5U55dGFTQXJs0K1UToVqRn3pTjrdJ0GsVy EfenX2Kd67qPs3JMwW9t+ex1Uup4pvuU1XFhNdoP50r8I1QTIMJMpEFoOyVOCqzs Fdz0YToH0SpZ/rGaCMLXdAIdQK/Qzg1MMCtwmNLhloLG9ssxH+GMZ3xG48FtM5h/ XAbwb4jFOoyIND3eDEHX =ZOQd -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From nobody Wed Apr 5 07:24: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 68CC4127BA3 for ; Wed, 5 Apr 2017 07:24:12 -0700 (PDT) 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 8SycRmc7tUQy for ; Wed, 5 Apr 2017 07:24:11 -0700 (PDT) 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 0E14A126DC2 for ; Wed, 5 Apr 2017 07:24:11 -0700 (PDT) Received: from [10.32.60.144] (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 v35ENtDh096722 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Apr 2017 07:23:56 -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.144] From: "Paul Hoffman" To: "Mukund Sivaraman" Cc: dnsop@ietf.org Date: Wed, 05 Apr 2017 07:24:11 -0700 Message-ID: <39B58207-4CC2-420B-B774-2766FC80B194@vpnc.org> In-Reply-To: <20170405084256.GA22692@jurassic> References: <20170405084256.GA22692@jurassic> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:24:12 -0000 On 5 Apr 2017, at 1:42, Mukund Sivaraman wrote: >> Name: draft-muks-dnsop-dnssec-sha3 NIST's use case for SHA3 algorithms is for when particular SHA2 algorithms are weakened. This would mean that the fallback for RSASHA256 is RSASHA512, not a SHA3 variant. Thus, the premise for this entire draft (which isn't listed until the end...) is flawed. Also, it is weird that a draft that is about having a fallback if a hash algorithm becomes weakened uses the RSASSA-PKCS1-v1_5 signature scheme, given that PKCS1 1.5 is already known to be weakened. --Paul Hoffman From nobody Wed Apr 5 07:33: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 BFC4012947A for ; Wed, 5 Apr 2017 07:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, 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 4al80XrLrxpj for ; Wed, 5 Apr 2017 07:33:18 -0700 (PDT) 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 E8CFD129420 for ; Wed, 5 Apr 2017 07:33:16 -0700 (PDT) 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; Wed, 5 Apr 2017 07:33:14 -0700 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, 5 Apr 2017 07:33:14 -0700 From: Edward Lewis To: Donald Eastlake , Mukund Sivaraman , "dnsop@ietf.org" Thread-Topic: [DNSOP] [Ext] RCODE and CNAME chain Thread-Index: AQHSrhQorn01rkS3SEWBbXgga5ZK6KG3CUGA Date: Wed, 5 Apr 2017 14:33:14 +0000 Message-ID: References: <20170405054338.GA15831@jurassic> <797A6C99-C9B7-4671-A29D-6ECFEF6A5B6D@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 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_3574233195_532983771" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:33:24 -0000 --B_3574233195_532983771 Content-type: multipart/alternative; boundary="B_3574233195_346424308" --B_3574233195_346424308 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Since you mentioned RFC 6604 "xNAME RCODE Clarification", here's a relevant= quote from Section 3 ("RCODE Clarification"): =20 >When an xNAME chain is followed, all but the last query cycle necessarily = had no error.=C2=A0 The RCODE in the ultimate DNS response MUST BE set based on = the final query cycle leading to that response.=C2=A0 If the xNAME chain was ter= minated by an error, it will be that error code.=C2=A0 If the xNAME chain termin= ated without error, it will be zero. =20 I tried a small set up, zone example with two CNAME sets.=C2=A0 name1 CNAME nam= e.example.com (zone also on the server, with nothing at name.example.com) an= d name2 CNAME name.example.xx (zone not on the server) and recursion disable= d. =20 dig for name1.example. returns the single CNAME record in the Answer, the A= A bit, SOA in Authority, and NXDOMAIN in the RCODE. dig for name2.example. returns the single CNAME record in the Answer, the A= A bit, no SOA, and NOERROR in the RCODE. =20 The first is a "final" answer - NXDOMAIN looking for the last name in the c= hain.=C2=A0 There's also an SOA record in the Authority indicating the negative = TTL to use.=C2=A0 The latter is a non-final answer (i.e., it's up to the querier= to keep asking), a "CNAME referral" - no SOA record and no hints as to wher= e to go because it's outside any domain of the name server (or that it is wi= lling to admit to having). =20 The two (final and CNAME referral) are rather hard to tell apart, it's poss= ible to determine that is the "last query cycle" as mentioned in the RFC, bu= t it takes a trained eye.=C2=A0 How?=C2=A0 Well, a querier ought to realize that, if= it didn't ask for a CNAME set and there's no error (yet), you simply haven'= t gotten a final answer yet. =20 On 4/5/17, 09:54, "DNSOP on behalf of Donald Eastlake" wrote: =20 See RFC 6604. =20 Donald =20 from iPhone =20 On Wed, Apr 5, 2017 at 09:34 Edward Lewis wrote: On 4/5/17, 01:43, "DNSOP on behalf of Mukund Sivaraman" wrote: >It seems BIND currently returns NXDOMAIN in this case, and the change in >behavior between looking-into-other-zones and >not-looking-into-other-zones in the nameserver algorithm caused a system >test failure, hence the question. I don't think there is one right answer. There may be a more efficient ans= wer (in terms of some metric). The goal of the RFCs was interoperability, k= eep that in mind. You allude above to an implementation changing its behavior (answering from= all available data vs. sticking to one zone). This is not something that i= s explicitly dealt with in the original RFCs, perhaps in later ones. Both c= hoices have merit, have downsides, still the two are interoperable. As far = as the protocol matters, either is a valid choice, and one that influences w= hether the query in question results in NOERROR/CNAME chain or NXDOMAIN. In this case, I think you don't need to worry about the querier. Rules see= m to be explicit about caching responses here. If anything, make sure your test script is accurate. (Back in the day of D= NSSEC protocol/code development, 1 out of 3 times DNSSEC had a protocol bug,= 1 out of 3 times it was a software bug, and 1 out of 3 times everything was= right but the tester - me - was expecting the wrong result.) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop[ietf.org] --=20 Sent from Gmail Mobile --B_3574233195_346424308 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Si= nce you mentioned RFC 6604 "xNAME RCODE Clarification", here's a r= elevant quote from Section 3 ("RCODE Clarification"):

 

>When = an xNAME chain is followed, all but the last query cycle necessarily had no = error.=C2=A0 The RCODE in the ultimate DNS response MUST BE set based on the fin= al query cycle leading to that response.=C2=A0 If the xNAME chain was terminated= by an error, it will be that error code.=C2=A0 If the xNAME chain terminated wi= thout error, it will be zero.

 

<= span style=3D'font-family:Calibri'>I tried a small set up, zone example with t= wo CNAME sets.=C2=A0 name1 CNAME name.example.com (zone also on the server, with= nothing at name.example.com) and name2 CNAME name.example.xx (zone not on t= he server) and recursion disabled.

<= span style=3D'font-family:Calibri'> 

dig for name1.example. returns the sin= gle CNAME record in the Answer, the AA bit, SOA in Authority, and NXDOMAIN i= n the RCODE.

dig for name2.example. returns the single CNAME record in the Ans= wer, the AA bit, no SOA, and NOERROR in the RCODE.

 

The first is a "f= inal" answer - NXDOMAIN looking for the last name in the chain.=C2=A0 There= 's also an SOA record in the Authority indicating the negative TTL to use.=C2=A0= The latter is a non-final answer (i.e., it's up to the querier to keep aski= ng), a "CNAME referral" - no SOA record and no hints as to where t= o go because it's outside any domain of the name server (or that it is willi= ng to admit to having).

 

The two (final and CNAME referral) are rather har= d to tell apart, it's possible to determine that is the "last query cyc= le" as mentioned in the RFC, but it takes a trained eye.=C2=A0 How?=C2=A0 Well,= a querier ought to realize that, if it didn't ask for a CNAME set and there= 's no error (yet), you simply haven't gotten a final answer yet.<= /span>

 

On 4/5/= 17, 09:54, "DNSOP on behalf of Donald Eastlake" <dnsop-bounces@ietf.org on behalf of d3e3e3@gmail.com> wrote:

=

 

=

See RFC 6604.

 

Donald

 

from iPhone

&nbs= p;

On Wed, Ap= r 5, 2017 at 09:34 Edward Lewis <= edward.lewis@icann.org> wrote:

O= n 4/5/17, 01:43, "DNSOP on behalf of Mukund Sivaraman" <dnsop-bounces@ietf.org = on behalf of muks@isc.org&= gt; wrote:

>It seems BIND currently returns NXDOMAIN in this case,= and the change in
>behavior between looking-into-other-zones and
&= gt;not-looking-into-other-zones in the nameserver algorithm caused a system<= br>>test failure, hence the question.

I don't think there is one r= ight answer.  There may be a more efficient answer (in terms of some me= tric).  The goal of the RFCs was interoperability, keep that in mind.
You allude above to an implementation changing its behavior (answering= from all available data vs. sticking to one zone).  This is not someth= ing that is explicitly dealt with in the original RFCs, perhaps in later one= s.  Both choices have merit, have downsides, still the two are interope= rable.  As far as the protocol matters, either is a valid choice, and o= ne that influences whether the query in question results in NOERROR/CNAME ch= ain or NXDOMAIN.

In this case, I think you don't need to worry about = the querier.  Rules seem to be explicit about caching responses here.
If anything, make sure your test script is accurate.  (Back in th= e day of DNSSEC protocol/code development, 1 out of 3 times DNSSEC had a pro= tocol bug, 1 out of 3 times it was a software bug, and 1 out of 3 times ever= ything was right but the tester - me - was expecting the wrong result.)
<= br>_______________________________________________
DNSOP mailing list
= DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop[ietf.or= g]

--

Sent from Gmail Mobile

--B_3574233195_346424308-- --B_3574233195_532983771 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 tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQURpoYz+Q0Ec7XsZHk C1/c27VmvYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw NDA1MTQzMzE1WjANBgkqhkiG9w0BAQEFAASCAQBpZw4wmqGOabnfdFA/dcQb7ad3vyOeXjT3 eiCMZELUvzyZKSEXqHgSMnTKwAdIE5Ot47AhilqJgCui0IpgjudtxAIbvkV86UEguJ+8MxHj 1H4ObPgx4zmgm+PaTNgF3LKbOT904VgdTgUCf0me44ohreqxwybUxwcu26lqKnrCLnjrcs31 eyj7+I+gGp/icOY75/k+BLao2YkXxgEqDayt1KUJ7ks9C27rhDuQvY1BrK2SpW67H+48DSnI 1n3ATU5E3oNaymE9rtNQPRC+C8kayQNW/M1aYJb91yWT8e4kPZy9c+k4AbP6Ghh2iKXlnw1E QTFfphCrOMnJP9PSbEWT --B_3574233195_532983771-- From nobody Wed Apr 5 07:50: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 9C4CF126DC2 for ; Wed, 5 Apr 2017 07:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qGoOdatoroPg for ; Wed, 5 Apr 2017 07:50:17 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1337E1250B8 for ; Wed, 5 Apr 2017 07:50:17 -0700 (PDT) Received: from jurassic (unknown [115.118.28.247]) (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 9974756A0366; Wed, 5 Apr 2017 14:50:14 +0000 (GMT) Date: Wed, 5 Apr 2017 20:20:10 +0530 From: Mukund Sivaraman To: Paul Hoffman Cc: dnsop@ietf.org Message-ID: <20170405145010.GA29337@jurassic> References: <20170405084256.GA22692@jurassic> <39B58207-4CC2-420B-B774-2766FC80B194@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <39B58207-4CC2-420B-B774-2766FC80B194@vpnc.org> User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:50:19 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Paul On Wed, Apr 05, 2017 at 07:24:11AM -0700, Paul Hoffman wrote: > On 5 Apr 2017, at 1:42, Mukund Sivaraman wrote: >=20 > > > Name: draft-muks-dnsop-dnssec-sha3 >=20 > NIST's use case for SHA3 algorithms is for when particular SHA2 algorithms > are weakened. This would mean that the fallback for RSASHA256 is RSASHA51= 2, > not a SHA3 variant. Thus, the premise for this entire draft (which isn't > listed until the end...) is flawed. =46rom FIPS 202: "The four SHA-3 hash functions in this Standard supplement the hash functions that are specified in FIPS 180-4 [1]: SHA-1 and the SHA-2 family. Together, both Standards provide resilience against future advances in hash function analysis, because they rely on fundamentally different design principles." =46rom the NIST press release: "SHA-3 is very different from SHA-2 in design," says NIST's Shu-jen Chang. "It doesn't replace SHA-2, which has not shown any problem, but offers a backup. It takes years to develop a new standard, and we wanted to be prepared in case problems do occur." Though RSA/SHA-256 vs. RSA/SHA-512 doesn't affect RRSIG lengths, there's the case of DS digest size where the fallback for SHA-256 would be SHA3-256 because SHA-512 is longer. SHA-512 hashing is known to be faster than SHA-256 on popular commodity hardware on inputs larger than a few bytes long, and though the algorithms are different, they are more siblings w.r.t. analysis. E.g., see the table below where each attack affects both SHA-256 and SHA-512: https://en.wikipedia.org/wiki/SHA-2#Cryptanalysis_and_validation > Also, it is weird that a draft that is about having a fallback if a hash > algorithm becomes weakened uses the RSASSA-PKCS1-v1_5 signature scheme, > given that PKCS1 1.5 is already known to be weakened. It was to allow simple addition of the algorithm to existing implementations. However, in light of your comment, we'll discuss revising it. Mukund --jRHKVT23PllUwdXP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIbBAEBCgAGBQJY5QQhAAoJEB9EXrAiC5LsxvMP+IAIvoyB4M7lQVfCWMBkucXy XApzdlyieVHq0dlx1UNJ0dFfibCIUWbeWW30zVnJesgojxBZ/HZCnAMfFOKkAhq2 x4MLC2ocI48sU3HxmiF5iZ2X79AAzlhuvjCgvzwBffrod+RPiciYd3GG21svU+3v fkm25HU3HeJxQlldZf1N7Y/u210bM6WMqzqN4/TYUoCEZDvT5l0TxOM0MCZ5BLt9 VAYAogVsiZVCEim4bmDZemFvOQak9HpuNnSBAhXRuVWNS6jLR6ZsLuuIqvfrkR6P AkIY7kgGQqXA1iQJmM3LTIf8ScGYCrDIdsuHygUwV0j9OrGky7w5Vp6PRAcC5tpu Fr5k9fXqEX2cGfXeacihs6DvQsLAZXRvNhn/iNdcHC6euADknQ1CnyiE0tb7k2qq S5k3eZyXeCKFXy3592DoICfoumYHm1q+SB/TC5fOQapb+Th/kbhzurNtr/CkHX+r KJ1EFE821wpYJ/lTr08aTyFHmPx45z6KxekDj6rf7LcHQQn2Xy7/abadZZiLjTj8 TS55I8sWccUo9hkRZvQ2kQfJJNQPxA+mVWCEv5qFesxmSlObKPRxzr/z5sB/pIUC iH6QG9C10IXdmVxGlAq6GYj9g+xlKgGduXRAvpqdkkwP/r8iSaDSZmVEK9Z6vTbs otWd2siqY6URajZ2/6E= =ThH3 -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From nobody Thu Apr 6 01:37: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 BE7AE12783A for ; Thu, 6 Apr 2017 01:37:42 -0700 (PDT) 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 (2048-bit key) header.d=sidn.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztFN-7tFkxe4 for ; Thu, 6 Apr 2017 01:37:40 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2F61201FA for ; Thu, 6 Apr 2017 01:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:x-originating-ip:x-clientproxiedby; bh=uZH0qZIlUVt3vu0R1lanQhWhucBQ0qSHi9hKvNRLc+k=; b=C/PcEExwKhTBAPzvFJQbvbqrfKKHpk3CEMVP9r5Oba/lpfvSPs0MQ2jbaKUoyxlklbIpJ/YGVA29q0+vuQ6KS/C+vOle+nEIqdH1AHiVaf36OaLDEpaqtC+CNbcXOaFm/52P7Th+OBWNlvQz68OmUvrQLd36aPOzy8FRnwyYE5Yr8cbgANiN3sLQjwXln7EbpTgGvCq7QOs15fag6x841npIxUdVvLsvDSJsZi+9zKKFKJj8jyU6xuF1sHcSfLHHqGr/PP29MX9TW4X0gj1bZ20OitxYsec6b4vMfJtwrbIMfih/ngRt3jG62RS5a1VUImI24vGBYdXtuUoNLaqUfw== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id v368bbQh000331-v368bbQj000331 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Thu, 6 Apr 2017 10:37:37 +0200 Received: from zen.sidnlabs.nl (94.198.159.135) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 6 Apr 2017 10:37:37 +0200 To: References: <20170405084256.GA22692@jurassic> <39B58207-4CC2-420B-B774-2766FC80B194@vpnc.org> <20170405145010.GA29337@jurassic> From: Jelte Jansen Message-ID: <1f3601da-b93c-410e-fe8e-4b85ff0519f4@sidn.nl> Date: Thu, 6 Apr 2017 10:37:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170405145010.GA29337@jurassic> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ikbELf8E7XjOpVbgXOHOqtl5PXBNwDkPS" X-Originating-IP: [94.198.159.135] X-ClientProxiedBy: ka-hubcasn02.SIDN.local (192.168.2.172) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.135, helo=, mailFrom=jelte.jansen@sidn.nl, headerFrom=jelte.jansen@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of jelte.jansen@sidn.nl designates 94.198.159.135 as permitted sender) smtp.mailfrom=jelte.jansen@sidn.nl Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 08:37:43 -0000 --ikbELf8E7XjOpVbgXOHOqtl5PXBNwDkPS Content-Type: multipart/mixed; boundary="1IeubtMkhNT3VAbBbIqVHm4BxDjrlLvGa"; protected-headers="v1" From: Jelte Jansen To: dnsop@ietf.org Message-ID: <1f3601da-b93c-410e-fe8e-4b85ff0519f4@sidn.nl> Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-00.txt References: <20170405084256.GA22692@jurassic> <39B58207-4CC2-420B-B774-2766FC80B194@vpnc.org> <20170405145010.GA29337@jurassic> In-Reply-To: <20170405145010.GA29337@jurassic> --1IeubtMkhNT3VAbBbIqVHm4BxDjrlLvGa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2017-04-05 16:50, Mukund Sivaraman wrote: >> Also, it is weird that a draft that is about having a fallback if a ha= sh >> algorithm becomes weakened uses the RSASSA-PKCS1-v1_5 signature scheme= , >> given that PKCS1 1.5 is already known to be weakened. >=20 > It was to allow simple addition of the algorithm to existing > implementations. However, in light of your comment, we'll discuss > revising it. >=20 We can certainly discuss alternative schemes, RSASSA-PSS is a potential alternative, which I understand is considered (much?) better. It has a big drawback though, in that it requires salt, which can be a big issue for large deployments. An advantage would be that then we not only have an alternative within the RSA family for SHA2, but also for the signature scheme itself. Speaking of the use-case to pick up this work; IMO having more cryptographic algorithms ready for use is generally a good thing; we don't have to wait until the existing ones are completely broken :) Jelte --1IeubtMkhNT3VAbBbIqVHm4BxDjrlLvGa-- --ikbELf8E7XjOpVbgXOHOqtl5PXBNwDkPS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEYVFopaZ3hPsk8Z9PSgPGZX58AqoFAljl/lAACgkQSgPGZX58 AqqgMg//ZzMkJHQH565JflORsnrj3bmoVCl39XSmh9yC5ZSCP42dbr8prFI7+dku 2q0L0YpxpuPpKc6ag6ttJOdvWy007lEZP0T0/2qESmKh7PlR0pFYKunCbK7Ap60R kD+fMSGebsIzDpKuvjEvV0A5zYp0ar4GIBFzDcnH63k67MgzMreNv3blNeme042C SCgECClI6+1WwX0gxcNqDudlaPcTyx73FIqgp1gzrvJkhjgYKdAeApEUvWUKlp0V mM64t4Qjf3fqKwB8bBwmoxHRnporK7/inPi7j0uoPDqCCNcViB2eJlUF4VrQQt1G x0zXJ8GT9CjWV2rMQOBRHxelulTD6PuMS/8K7Rs3GrnErI5pCCScFLLLnatI3EnN 9hkHavbzKtDnU1lrGVsrCWth0kqlDuYK81wPp1rZq+SaLgy5jk0qROTjgS5p//bq FAyTIbGvIOmDQDRUMPbrYqMkVVtQnSJ7p5Z/eumOW3ffmNws9YFLtGG5dRHY7raI //Phg9c+l0siO1IK1qGo3BGeDZRormQwQ9DhG6rfQR7jXLuuAvbQSWXoucjxnABR Jn3cJUcc0Uckjel+UIqCDjd5n4wya81Ygi3lbpcrEyovxMGDZWP23oZz+a8PW7xa nEEd/ABVjYz02Pur5/V34ZweRc9lg++Rghu5PHgkcezBvVVVk4k= =++5/ -----END PGP SIGNATURE----- --ikbELf8E7XjOpVbgXOHOqtl5PXBNwDkPS-- From nobody Thu Apr 6 02:03: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 1D0C912940B for ; Thu, 6 Apr 2017 02:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.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 Ft_9L_0LhVYu for ; Thu, 6 Apr 2017 02:03:47 -0700 (PDT) Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (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 4874A1243F6 for ; Thu, 6 Apr 2017 02:03:47 -0700 (PDT) Received: from miraculix.mork.no ([IPv6:2a02:2121:2c0:3560:b474:86ff:fe5d:4ecf]) (authenticated bits=0) by canardo.mork.no (8.14.4/8.14.4) with ESMTP id v3693hXd003569 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 6 Apr 2017 11:03:44 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1491469424; bh=1OCTUNvs5OxMmcDoz4xiaeEhHFyr9XKe/oQAwbuffvo=; h=From:To:Subject:Date:Message-ID:From; b=H4bHNXbsNHL57dYfiYXKexrAxF4OlYCvtmTXogs8sy92PHjsEinjcIL2qNaOO5nzL LFOs1REdnYJyuJYfLAFRHJ1shIzMISDfJ8CMLUB+v2vKN0vmlfFRVi37XBfN7mOnLQ XKnik+z7f1xxZi7OkqaEMk4SXYsHhHPUg8a8VgFQ= Received: from bjorn by miraculix.mork.no with local (Exim 4.89) (envelope-from ) id 1cw3KM-0003sg-JZ for dnsop@ietf.org; Thu, 06 Apr 2017 11:03:38 +0200 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: dnsop@ietf.org Organization: m Date: Thu, 06 Apr 2017 11:03:38 +0200 Message-ID: <87inmhrjpx.fsf@miraculix.mork.no> User-Agent: Gnus/5.130015 (Ma Gnus v0.15) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.99.2 at canardo X-Virus-Status: Clean Archived-At: Subject: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 09:03:54 -0000 Hello, We are currently trying out the configuration recommended by RFC7706, serving a copy of the root zone on a loopback. We are using BIND 9.10 and our configuration is directly copied from the example in appendix B.1. Even down to the actual loopback address used, as we needed a dedicated one for this instance anyway. Recently I noticed a side effect of this configuration which I consider unwanted and unexpected: It changes how BIND replies to requests without the RD bit set. BIND will normally answer such requests with a "best possible redirection", using any matching NS set it has in its cache. Which often will be the root NS. But using the RFC7706 example config, BIND will REFUSE all requests without RD set. For the record, my expectations are: Absolutely no visible effects to any DNS clients compared to a normal caching resolver, using the real root servers directly. Using the RFC7706 appedix B.1 example config, this is what I see: bjorn@miraculix:~$ dig . soa @::1 +norecur ; <<>> DiG 9.10.3-P4-Debian <<>> . soa @::1 +norecur ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 49721 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN SOA ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Apr 06 10:25:30 CEST 2017 ;; MSG SIZE rcvd: 28 Snooping on the loopback interface, shows that the query is refused without being referred to the local root instance (which makes sort of sense, as that would be recursion...): 1 0.000000000 ::1 =E2=86=92 ::1 Standard query 0xc23= 9 SOA OPT 92 DNS 2 0.000093346 ::1 =E2=86=92 ::1 Standard query respo= nse 0xc239 Refused SOA OPT 92 DNS Removing the local root zone, letting BIND fall back to its built-in hint zone: view recursive { dnssec-validation auto; allow-recursion { any; }; recursion yes; /* zone "." { type static-stub; server-addresses { 127.12.12.12; }; }; */ }; changes this behaviour. BIND now replies with NOERROR and an AUTHORITY section from its hints (or actually from the cache. Note the AD flag): bjorn@miraculix:~$ dig . soa @::1 +norecur ; <<>> DiG 9.10.3-P4-Debian <<>> . soa @::1 +norecur ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29060 ;; flags: qr ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN SOA ;; AUTHORITY SECTION: . 518378 IN NS a.root-servers.net. . 518378 IN NS g.root-servers.net. . 518378 IN NS m.root-servers.net. . 518378 IN NS j.root-servers.net. . 518378 IN NS h.root-servers.net. . 518378 IN NS e.root-servers.net. . 518378 IN NS f.root-servers.net. . 518378 IN NS k.root-servers.net. . 518378 IN NS d.root-servers.net. . 518378 IN NS l.root-servers.net. . 518378 IN NS i.root-servers.net. . 518378 IN NS c.root-servers.net. . 518378 IN NS b.root-servers.net. ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Apr 06 10:18:43 CEST 2017 ;; MSG SIZE rcvd: 239 Snooping on "any" reveals that there is no recursion in this case either, as expected. The data source is the cache: 1 0.000000000 ::1 =E2=86=92 ::1 Standard query 0x718= 4 SOA OPT 92 DNS 2 0.000213074 ::1 =E2=86=92 ::1 Standard query respo= nse 0x7184 SOA NS a.root-servers.net NS g.root-servers.net NS m.root= -servers.net NS j.root-servers.net NS h.root-servers.net NS e.root-servers.= net NS f.root-servers.net NS k.root-servers.net NS d.root-servers The problem is that configuring a "static-stub" root zone changes how BIND handles non RD requests. Note that this affects *any* such request, not only requests for root. Example with the "static-stub" root zone enabled: bjorn@miraculix:~$ dig ns mork.no @::1 +norecur ; <<>> DiG 9.10.3-P4-Debian <<>> ns mork.no @::1 +norecur ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34742 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mork.no. IN NS ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Apr 06 10:32:45 CEST 2017 ;; MSG SIZE rcvd: 36 1 0.000000000 ::1 =E2=86=92 ::1 Standard query 0x87b= 6 NS mork.no OPT 100 DNS 2 0.000121759 ::1 =E2=86=92 ::1 Standard query respo= nse 0x87b6 Refused NS mork.no OPT 100 DNS BIND will normally provide the root hint from its cache without the "static-stub" root zone configuration: bjorn@miraculix:~$ dig ns mork.no @::1 +norecur ; <<>> DiG 9.10.3-P4-Debian <<>> ns mork.no @::1 +norecur ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54393 ;; flags: qr ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mork.no. IN NS ;; AUTHORITY SECTION: . 518395 IN NS a.root-servers.net. . 518395 IN NS h.root-servers.net. . 518395 IN NS g.root-servers.net. . 518395 IN NS d.root-servers.net. . 518395 IN NS f.root-servers.net. . 518395 IN NS e.root-servers.net. . 518395 IN NS m.root-servers.net. . 518395 IN NS j.root-servers.net. . 518395 IN NS k.root-servers.net. . 518395 IN NS i.root-servers.net. . 518395 IN NS c.root-servers.net. . 518395 IN NS b.root-servers.net. . 518395 IN NS l.root-servers.net. ;; Query time: 1 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Apr 06 10:34:27 CEST 2017 ;; MSG SIZE rcvd: 247 1 0.000000000 ::1 =E2=86=92 ::1 Standard query 0xd47= 9 NS mork.no OPT 100 DNS 2 0.000255371 ::1 =E2=86=92 ::1 Standard query respo= nse 0xd479 NS mork.no NS a.root-servers.net NS h.root-servers.net NS g.root= -servers.net NS d.root-servers.net NS f.root-servers.net NS e.root-servers.= net NS m.root-servers.net NS j.root-servers.net NS k.root-servers.net NS i.= root-servers.net NS c.root-servers.net NS b.root-servers.net NS l.root-serv= ers.net OPT 311 DNS These examples are all without setting RD. I will not bore you with the results having RD set. Those all work as expected, giving identical replies with or without the "static-stub" root zone. Experimenting a bit more, I found that changing the RFC7706 example config to use a "forward" zone instead, makes BIND behave as expected while keeping advantages of the local root zone instance: view recursive { dnssec-validation auto; allow-recursion { any; }; recursion yes; zone "." { type forward; forwarders { 127.12.12.12; }; }; }; With this configuration I get similar results to the examples without a local root zone, while still having all requests for root served by the local instance. So it looks like a good solution to me. I've tried googling a bit to see if this issue has been discussed before, or if I could find any background for the selection of a "static-stub" zone type for the RFC7706 example. But I have not been able to find any. Which is why I decided to ask here. Is this a known and expected issue? Why was "static-stub" used? Was "forward" ever considered? I realize that using "forward" will change the behaviour in case of a failing local instance, but that can also be seen as a feature. Or it can be prevented by simply adding "forward only" to the config, if complete failure is preferred over falling back to the real root servers. Finally, if any of you wonder why I (or anyone else) with send queries without RD set to a caching resolver: I discovered the issue because "dig +trace" started failing. Quoting from dig(1): "Recursion is automatically disabled when the +nssearch or +trace query options are used." This makes a real use case for me. And I like to think that I'm not that special, so there are probably other users thinking this behavioural change is a bug as well. Any advice is appreciated. Our choices are basically down to either a) disable the local root instance, or b) go for the "forward" variant But I hesitate to select option b) without knowing the background for the "static-stub" recommendation. Option a) seems a lot safer at the moment... Bj=C3=B8rn From nobody Thu Apr 6 04:36: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 7193112945F for ; Thu, 6 Apr 2017 04:36:01 -0700 (PDT) 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 cb7IUutEjZj3 for ; Thu, 6 Apr 2017 04:35:59 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.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 9F0861270A7 for ; Thu, 6 Apr 2017 04:35:57 -0700 (PDT) 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]:54061) 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 1cw5hj-000d0e-ie (Exim 4.89) (return-path ); Thu, 06 Apr 2017 12:35:55 +0100 Date: Thu, 6 Apr 2017 12:35:55 +0100 From: Tony Finch To: =?UTF-8?Q?Bj=C3=B8rn_Mork?= cc: dnsop@ietf.org In-Reply-To: <87inmhrjpx.fsf@miraculix.mork.no> Message-ID: References: <87inmhrjpx.fsf@miraculix.mork.no> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-1974694534-1491478555=:17574" Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 11:36:01 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870841-1974694534-1491478555=:17574 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Bj=C3=B8rn Mork wrote: > > Recently I noticed a side effect of this configuration which I consider > unwanted and unexpected: It changes how BIND replies to requests without > the RD bit set. BIND will normally answer such requests with a "best > possible redirection", using any matching NS set it has in its cache. > Which often will be the root NS. But using the RFC7706 example config, > BIND will REFUSE all requests without RD set. I agree this behaviour is unhelpful and weird. It seems to come from the following bit of the source, though the comment doesn't help very much to explain the whys or wherefores. https://source.isc.org/cgi-bin/gitweb.cgi?p=3Dbind9.git;a=3Dblob;f=3Dbin/na= med/query.c;h=3D0cfdf9288fb16a8f991e7a31f3248118add691d5;hb=3DHEAD#l1040 =09/* =09 * Non recursive query to a static-stub zone is prohibited; its =09 * zone content is not public data, but a part of local configuration =09 * and should not be disclosed. =09 */ =09if (dns_zone_gettype(zone) =3D=3D dns_zone_staticstub && =09 !RECURSIONOK(client)) { =09=09return (DNS_R_REFUSED); =09} You might be able to work around the problem by adding a match-recursion-only option to the recursive view, and adding a non-recursive view that has allow-query-cache, and use attach-cache so all views share the same cache. I have not tried this :-) Tony. --=20 f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Viking, North Utsire, South Utsire, Northeast Forties: Westerly 5 to 7, occasionally gale 8 at first in Viking and South Utsire, veering northweste= rly 5 or 6. Rough, becoming moderate later. Occasional drizzle, fog patches developing. Moderate, occasionally very poor. --1870870841-1974694534-1491478555=:17574-- From nobody Thu Apr 6 05:07: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 48895129473 for ; Thu, 6 Apr 2017 05:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.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 le4nUqtfjuNk for ; Thu, 6 Apr 2017 05:07:46 -0700 (PDT) Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (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 B6F71129458 for ; Thu, 6 Apr 2017 05:07:43 -0700 (PDT) Received: from miraculix.mork.no ([IPv6:2a02:2121:2c0:3560:b474:86ff:fe5d:4ecf]) (authenticated bits=0) by canardo.mork.no (8.14.4/8.14.4) with ESMTP id v36C7ajB020393 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 14:07:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1491480457; bh=bLEfy92UztBbCn3Mno6J95hUxiHgsaxMIv8TXP1cWrc=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=jCJ4A42y3WBc5AoOCDq4X4baxnsU6+Mkc49IruymdP6y6yS5YtvW4WF6fmda30Z7O 5rxIPpyYG5ZC9CVWT95rHeQST745NvnmTy3O6E64lhDSYJPlVRC/qQf3JxpHHotg7I Plb7q8Et3zH3F0pz2M1IFo/IejTh0FxaOCHI9P+A= Received: from bjorn by miraculix.mork.no with local (Exim 4.89) (envelope-from ) id 1cw6CJ-00075J-55; Thu, 06 Apr 2017 14:07:31 +0200 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Tony Finch Cc: dnsop@ietf.org Organization: m References: <87inmhrjpx.fsf@miraculix.mork.no> Date: Thu, 06 Apr 2017 14:07:31 +0200 In-Reply-To: (Tony Finch's message of "Thu, 6 Apr 2017 12:35:55 +0100") Message-ID: <87pogppwn0.fsf@miraculix.mork.no> User-Agent: Gnus/5.130015 (Ma Gnus v0.15) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.99.2 at canardo X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 12:07:50 -0000 Tony Finch writes: > Bj=C3=B8rn Mork wrote: >> >> Recently I noticed a side effect of this configuration which I consider >> unwanted and unexpected: It changes how BIND replies to requests without >> the RD bit set. BIND will normally answer such requests with a "best >> possible redirection", using any matching NS set it has in its cache. >> Which often will be the root NS. But using the RFC7706 example config, >> BIND will REFUSE all requests without RD set. > > I agree this behaviour is unhelpful and weird. It seems to come from the > following bit of the source, though the comment doesn't help very much to > explain the whys or wherefores. > https://source.isc.org/cgi-bin/gitweb.cgi?p=3Dbind9.git;a=3Dblob;f=3Dbin/= named/query.c;h=3D0cfdf9288fb16a8f991e7a31f3248118add691d5;hb=3DHEAD#l1040 > > /* > * Non recursive query to a static-stub zone is prohibited; its > * zone content is not public data, but a part of local configuration > * and should not be disclosed. > */ > if (dns_zone_gettype(zone) =3D=3D dns_zone_staticstub && > !RECURSIONOK(client)) { > return (DNS_R_REFUSED); > } Thanks for the code pointer! I tried looking at the git commit log, but it didn't help explaining this either. The comment and test were part of the commit adding the "static-stub" feature. > You might be able to work around the problem by adding a > match-recursion-only option to the recursive view, and adding a > non-recursive view that has allow-query-cache, and use attach-cache > so all views share the same cache. I have not tried this :-) And the main objection I hear wrt RFC7706 is that it complicates the config :) Bj=C3=B8rn From nobody Thu Apr 6 05:32: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 5C0331294D3 for ; Thu, 6 Apr 2017 05:32:29 -0700 (PDT) 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 EpbwugkiF7pv for ; Thu, 6 Apr 2017 05:32:27 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C701294CE for ; Thu, 6 Apr 2017 05:32:27 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:e1ff:1a9e:414b:e082] (unknown [IPv6:2001:559:8000:c9:e1ff:1a9e:414b:e082]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4673A61F9C; Thu, 6 Apr 2017 12:32:27 +0000 (UTC) Message-ID: <58E63559.1030608@redbarn.org> Date: Thu, 06 Apr 2017 05:32:25 -0700 From: Paul Vixie User-Agent: Postbox 5.0.12 (Windows/20170323) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bj=F8rn_Mork?= CC: Tony Finch , dnsop@ietf.org References: <87inmhrjpx.fsf@miraculix.mork.no> <87pogppwn0.fsf@miraculix.mork.no> In-Reply-To: <87pogppwn0.fsf@miraculix.mork.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 12:32:29 -0000 Bjrn Mork wrote: > Tony Finch writes: ... >> You might be able to work around the problem by adding a >> match-recursion-only option to the recursive view, and adding a >> non-recursive view that has allow-query-cache, and use attach-cache >> so all views share the same cache. I have not tried this :-) > > And the main objection I hear wrt RFC7706 is that it complicates the > config :) if you want to run yeti-style, there are some perl scripts that will fetch and verify the root zone, edit the apex NS and DNSKEY RRsets, re-sign with your local key, and give you a zone you can run on several servers inside your internal network, such that you can point your "hints" and your dnssec anchor at servers you control, for all your internal-network recursives, the code is here: https://github.com/BII-Lab/Yeti-Project/tree/master/script/TISF note, my internal-network is the virtualbox shared network on my own laptop, so while this is a complex approach, it's fewer moving parts for me than RFC 7706 would have been. -- P Vixie From nobody Thu Apr 6 05:54: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 C95661294E6 for ; Thu, 6 Apr 2017 05:54:40 -0700 (PDT) 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 luhUA3vSCYwH for ; Thu, 6 Apr 2017 05:54:36 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D93C1294BC for ; Thu, 6 Apr 2017 05:54:30 -0700 (PDT) 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]:42391) 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 1cw6vk-000lBH-0O (Exim 4.89) (return-path ); Thu, 06 Apr 2017 13:54:28 +0100 Date: Thu, 6 Apr 2017 13:54:28 +0100 From: Tony Finch To: Jelte Jansen cc: dnsop@ietf.org In-Reply-To: <1f3601da-b93c-410e-fe8e-4b85ff0519f4@sidn.nl> Message-ID: References: <20170405084256.GA22692@jurassic> <39B58207-4CC2-420B-B774-2766FC80B194@vpnc.org> <20170405145010.GA29337@jurassic> <1f3601da-b93c-410e-fe8e-4b85ff0519f4@sidn.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 12:54:41 -0000 Jelte Jansen wrote: > > We can certainly discuss alternative schemes, RSASSA-PSS is a potential > alternative, which I understand is considered (much?) better. It has a > big drawback though, in that it requires salt, which can be a big issue > for large deployments. As I understand it the deterministic DSA trick (RFC 6979) also works for RSA SSA PSS. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode South Plymouth, North Biscay: Easterly or northeasterly 4 or 5. Moderate, occasionally rough at first in north Biscay. Fair. Moderate or good. From nobody Thu Apr 6 08:25: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 5536B129512 for ; Thu, 6 Apr 2017 08:25:40 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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=conundrum-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 4o5NSyZ87OWj for ; Thu, 6 Apr 2017 08:25:38 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 074EE126CE8 for ; Thu, 6 Apr 2017 08:25:37 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id d188so44153675vka.0 for ; Thu, 06 Apr 2017 08:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hmclpbL1EG2WXjPvDhwIPxqtETcYmI8ckbf/egaNQe0=; b=tTX4eJK5eD3XauwyM6x12njNX0NPOuiV5gh/aXdJeIjuCq1neaj2UxZEjYw6G9qCOk KWaCvxGabekcg+G3q/CKsOayucleGj/txqZKuf3/UjLztxvhv0xYU6WGGRppPgj8ukj9 Yy/4aXJYISUS82ufbW+Q3ncTQXtbRNyEl1+1fr3P33mmdenP9shHXEZoc6Tzqpf+mReE uWyIgYgPgfjHO4yK4Mbqpp7xUf4hAQM3ZaAhM7ODk1aN9FFFzoa6LB9mChey/K7bmYhH w0/fGiJ3JtijvG21ao3GqWrQ8jrTLRENh1JFCFqQkf1O4Es0gu90GFP5kWS0i1Sn2Jpt VbiA== 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=hmclpbL1EG2WXjPvDhwIPxqtETcYmI8ckbf/egaNQe0=; b=VMI/u7vsPSTwjgRGH9CxYivVRUUsVxVD9voylCVmOLqo3dJjkfEXIj4VBoza/kwaj9 Tj16KJzQJ/oddyGrvqz+a6TdpDPQg7zFapKyk5xcUqC1bDkN21LD770ExqAycdrSSzha EMcBY2UJCl3XjxahfqvIGFED7Mr15XtZN+6RUxPnv5n2WNoJC5Yvj1qu6enmrMO5hS7c GPi6zXNjsKntLD47jH5ZB5hVS9ZQ4z1cc/rM668QZ+h1kgtMWNEOac2O+vbE+0szjdM2 atYxh1C5QeVGhfJltFBKKYTQpxi4v5hdrDvUwQCQ8jpaG2TAC7KUTLC0rdfNDYmIM7ni Y+pQ== X-Gm-Message-State: AFeK/H3Zl5CcnMANNSLXrQGSjAajk42qDl74saifAY+08mMiCXSUeRXjubWkFJjVlkdOTQkUzF4P9DGXQtixQQ== X-Received: by 10.176.94.132 with SMTP id y4mr17899612uag.62.1491492336482; Thu, 06 Apr 2017 08:25:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.69 with HTTP; Thu, 6 Apr 2017 08:25:36 -0700 (PDT) In-Reply-To: References: From: Matthew Pounsett Date: Thu, 6 Apr 2017 11:25:36 -0400 Message-ID: To: Paul Hoffman Cc: dnsop WG Content-Type: multipart/alternative; boundary=f403043c39cce6cf0d054c811e4d Archived-At: Subject: Re: [DNSOP] New terminology for root name service X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 15:25:40 -0000 --f403043c39cce6cf0d054c811e4d Content-Type: text/plain; charset=UTF-8 On 15 March 2017 at 13:31, Paul Hoffman wrote: > Greetings again. RSSAC has published a lexicon of terms that are commonly > used with respect to the root of the public DNS, but are not in RFC 7719. I > have opened an issue for the terminology-bis document at > https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/17 and > would be intereted to hear what people think about including those terms in > our document. > > Hi Paul. Noting there hasn't been any actual feedback on your question ... I think the -bis document should at least reference RSAAC026, but I think importing those terms (particularly the ones that are not root-specific: instance, publish, serve) would be useful. --f403043c39cce6cf0d054c811e4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 15 March 2017 at 13:31, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings again. RSS= AC has published a lexicon of terms that are commonly used with respect to = the root of the public DNS, but are not in RFC 7719. I have opened an issue= for the terminology-bis document at https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/iss= ues/17 and would be intereted to hear what people think about including= those terms in our document.


Hi Pa= ul.=C2=A0 Noting there hasn't been any actual feedback on your question= ... I think the -bis document should at least reference RSAAC026, but I th= ink importing those terms (particularly the ones that are not root-specific= : instance, publish, serve) would be useful.=C2=A0

--f403043c39cce6cf0d054c811e4d-- From nobody Thu Apr 6 09:26: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 D2BFD1293E1 for ; Thu, 6 Apr 2017 09:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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 (1024-bit key) header.d=isoc.onmicrosoft.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 vNcUKcg7XKR1 for ; Thu, 6 Apr 2017 09:25:57 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0088.outbound.protection.outlook.com [104.47.41.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10986129546 for ; Thu, 6 Apr 2017 09:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mE/TerzMnypbFB7ZsR5XYDKUpPXPBljoFpsBSzDViPs=; b=z9jn7ZLGS2+XzCWyap+2tguXQYKz2hTNbeqI8YMAgQVPxYTxi/3oC1PKwr5+luKFF5H2Uadkd5wCDU0nU8+/52y6dmNICFDAxeNOzEjskyH8CWpMCXnXbH/BLPZmVubSa20Po8KoAViC5niOJ0wFTTtDlATqg5HBzxpZPhXOU/M= Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) by CY1PR0601MB1659.namprd06.prod.outlook.com (10.163.232.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Thu, 6 Apr 2017 16:25:54 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) with mapi id 15.01.1019.021; Thu, 6 Apr 2017 16:25:54 +0000 From: Dan York To: Matthew Pounsett CC: Paul Hoffman , dnsop WG Thread-Topic: [DNSOP] New terminology for root name service Thread-Index: AQHSnbH40sNyKI27jkyxgqbHiY6f3qG4mLAAgAAQ14A= Date: Thu, 6 Apr 2017 16:25:54 +0000 Message-ID: <26E87AA9-E342-4951-A142-699D1EA94062@isoc.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: conundrum.com; dkim=none (message not signed) header.d=none;conundrum.com; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.75.87.222] x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1659; 7:7YMJKludJ8j0HvgC6tae7oqTBrTO62RJ0+ycmRKBI2QU2sRxHjYjdh7gWPxFYFuXTD8yMqXdSwACmXTCLydEoDVswDGQOlHr0NjSP8PjApyYTLqOTTO2zidaewzgU1U+LBDbURSeErFoPZvidhvr8dxRYazNPCsrn6RdDhLMX6/g2/dyymRGTMbJLh+zcioGxe5K6gZNDgqfg4bVEj9GuWkGl7aNm4zsunDg0XlN09ehsJqgv9j0Jbo8PPwShyOJ/+2ixu82lvb5r3/CJSncZaRqqsPvNTbIE1z5hNieV6QyTXuuTwqFE0MvAsMJww99U8EYvdwmsXCFn+IGBt/noA== x-ms-office365-filtering-correlation-id: e80313ee-0936-401b-2149-08d47d099936 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR0601MB1659; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(31418570063057); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:CY1PR0601MB1659; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1659; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39830400002)(39400400002)(39450400003)(377454003)(24454002)(6436002)(53376002)(3280700002)(36756003)(8676002)(66066001)(110136004)(229853002)(3660700001)(3846002)(77096006)(86362001)(33656002)(102836003)(6486002)(6506006)(2906002)(6116002)(606005)(2900100001)(38730400002)(6916009)(99286003)(189998001)(8936002)(966004)(6246003)(81166006)(25786009)(53546009)(5660300001)(236005)(2950100002)(6306002)(6512007)(54896002)(53936002)(7736002)(4326008)(76176999)(122556002)(7906003)(50986999)(54356999)(54906002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1659; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_26E87AA9E3424951A142699D1EA94062isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 16:25:54.3002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1659 Archived-At: Subject: Re: [DNSOP] New terminology for root name service X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:26:00 -0000 --_000_26E87AA9E3424951A142699D1EA94062isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 6, 2017, at 11:25 AM, Matthew Pounsett > wrote: On 15 March 2017 at 13:31, Paul Hoffman > wrote: Greetings again. RSSAC has published a lexicon of terms that are commonly u= sed with respect to the root of the public DNS, but are not in RFC 7719. I = have opened an issue for the terminology-bis document at https://github.com= /DNSOP/draft-ietf-dnsop-terminology-bis/issues/17 and would be intereted to= hear what people think about including those terms in our document. Hi Paul. Noting there hasn't been any actual feedback on your question ...= I think the -bis document should at least reference RSAAC026, but I think = importing those terms (particularly the ones that are not root-specific: in= stance, publish, serve) would be useful. Agree with Matthew (and others) that RSAAC026 should be referenced. Also ag= ree that "instance", "publish" and "server" would be useful additions. I do= n't know that the specific root zone terms need to be incorporated. I guess a general question would be (and I don't know the answer): do we an= ticipate creating RFCs that define operations and protocols used within the= root zone? If yes or "maybe", we should incorporate the terms. If "proba= bly not" or "no", then there could just be a new section about "Root Zone t= erminology" that specifically directs people to view RSAAC026 (and successo= r documents). My 2 cents, Dan -- Dan York Senior Manager, Content & Web Strategy, Internet Society york@isoc.org +1-603-439-0024 Jabber: york@jabber.isoc.org Skype: danyork = http://twitter.com/danyork http://www.internetsociety.org/ --_000_26E87AA9E3424951A142699D1EA94062isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <548FA356E0DE1740AF580C0738691CB5@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On Apr 6, 2017, at 11:25 AM, Matthew Pounsett <matt@conundrum.com> wrote:=



On 15 March 2017 at 13:31, Paul Hoffman <p= aul.hoffman@vpnc.org> wrote:
Greetings again. RSSAC has published a lexicon of terms that are commonly u= sed with respect to the root of the public DNS, but are not in RFC 7719. I = have opened an issue for the terminology-bis document at https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/<= wbr class=3D"">issues/17 and would be intereted to hear what people thi= nk about including those terms in our document.


Hi Paul.  Noting there hasn't been any actual feedback= on your question ... I think the -bis document should at least reference R= SAAC026, but I think importing those terms (particularly the ones that are = not root-specific: instance, publish, serve) would be useful. 

Agree with Matthew (and others) that RSAAC026 should be referenced. Al= so agree that "instance", "publish" and "server&qu= ot; would be useful additions. I don't know that the specific root zone ter= ms need to be incorporated. 

I guess a general question would be (and I don't know the answer): do = we anticipate creating RFCs that define operations and protocols used withi= n the root zone?  If yes or "maybe", we should incorporate t= he terms.  If "probably not" or "no", then there could just be a new section about "Root Zone terminology" that s= pecifically directs people to view RSAAC026 (and successor documents).

My 2 cents,
Dan

--
Dan York
Senior Manager, Content & Web Strategy, Internet Society
york@isoc.org   &= #43;1-603-439-0024 
Jabber: york@jabber= .isoc.org  Skype: danyork   http://twitter.com/danyork

http://www.internets= ociety.org/

--_000_26E87AA9E3424951A142699D1EA94062isocorg_-- From nobody Thu Apr 6 11:42: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 CFE49129408 for ; Thu, 6 Apr 2017 11:42:37 -0700 (PDT) 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=unavailable 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 TW8tawwfdcAF for ; Thu, 6 Apr 2017 11:42:34 -0700 (PDT) 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 11998129446 for ; Thu, 6 Apr 2017 11:42:32 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id p77so24655715ywg.1 for ; Thu, 06 Apr 2017 11:42:32 -0700 (PDT) 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=69TZQwrhCwcBmo3PME8/P7RotTRSIW2/jOIYSpaGkh4=; b=iW3qC3xC1JHLONfLlPL2Ekqj5amAQuHeONGGHE29R3esHQ9CXzMQJu6nWKdti9TI3r r9L4Nu/VPXGUHIaVhGzCTcmwZkXT3ha6XkOI0wMC+ortSDC/xEj5ATWrKZQdPoOHf92A BmfwARwjbd5i/0UWyw+IeemnkiVrmVSOLKKp+sxvMcGwAtJm0K/JbltRefkb64F5gzzQ kKWP65ukE+yLr0rh6HkXhMozUqjlL9Iq45y5LZr5OfzRcr9QClAe3Tko1biiOQZs7SAY E/p83F9K6ZN6IcQPFKMhutOX6VoTrtaPOEfzn2WYG6pVxJV6TlwLWghW43eIxkjbRH+M op4w== 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=69TZQwrhCwcBmo3PME8/P7RotTRSIW2/jOIYSpaGkh4=; b=tMBR3FVbOeFGwhw/5FsXK5l0pJPAF/MFLFvDiZ3KKV1XZ2PezJ67IditL8uUtlHHRn QM3qglsRp+pQ4ArIPZC59ScaNDAE3rBV4vDrjFPWhh7WUKcXv/TkkCs4q7t23GzrQmSf YDHtPQ+2z9ZG8AAUH3NVCw1H2sSuNsgq/Ots/86BCtmLvJd/UK27HRA+NMwYEVGoJj0Z cUaIpjXu+uBJZISaT6ld7N1qhII1ECh2JBrQXbyhh2mWklOiBdYOkn7I/s7v4PB8DgY2 m1jI2hLGvnmBuYRjYxIl/24EYJEDRKDjBdtfqYHRlLgFsPma10Xgo9wvygg82RBoKHaw Nimw== X-Gm-Message-State: AFeK/H3auJ24CxjnXYe+hIqTTsxnw5fC5ADCvDI+BXOeFjwukLm8iG4k2Rc31CGO00tYyLZY1KySf3lFpJKiCcCY X-Received: by 10.129.76.17 with SMTP id z17mr10932093ywa.102.1491504151848; Thu, 06 Apr 2017 11:42:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.109.134 with HTTP; Thu, 6 Apr 2017 11:42:31 -0700 (PDT) In-Reply-To: <149073324374.1336.11092995826852304276.idtracker@ietfa.amsl.com> References: <149073324374.1336.11092995826852304276.idtracker@ietfa.amsl.com> From: Bob Harold Date: Thu, 6 Apr 2017 14:42:31 -0400 Message-ID: To: draft-kristoff-dnsop-dns-tcp-requirements@ietf.org Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary=001a113f2bdc271829054c83dfe7 Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 18:42:38 -0000 --001a113f2bdc271829054c83dfe7 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 28, 2017 at 4:34 PM, IETF Secretariat < ietf-secretariat-reply@ietf.org> wrote: > > The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in > state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns- > tcp-requirements/ > > I support adoption and will review. Minor nit: 6.5. IETF RFC 7873 - Domain Name System (DNS) Cookies "... should consider accept TCP ..." change to: "... should consider accepting TCP ..." -- Bob Harold --001a113f2bdc271829054c83dfe7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 28, 2017 at 4:3= 4 PM, IETF Secretariat <ietf-secretariat-reply@ietf.org&= gt; wrote:

The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in state
Candidate for WG Adoption (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.= org/doc/draft-kristoff-dnsop-dns-tcp-requirements/


I support adoption and will review.

= Minor nit:
6.5. IETF RFC 7873 - Domain Name System (DNS) Cookies

= "... =C2=A0should consider accept TCP ..."
change to:
"= ;... should consider accepting TCP ..."

--
Bob Harold
=
--001a113f2bdc271829054c83dfe7-- From nobody Thu Apr 6 15:43: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 067141294A2 for ; Thu, 6 Apr 2017 15:43:44 -0700 (PDT) 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=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 yPCT5oxxI9Ts for ; Thu, 6 Apr 2017 15:43:43 -0700 (PDT) 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 11B19128D19 for ; Thu, 6 Apr 2017 15:34:48 -0700 (PDT) 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 8ECD221976; Thu, 6 Apr 2017 15:34:46 -0700 (PDT) From: Wes Hardaker To: Bob Harold Cc: IETF DNSOP WG References: <149130746853.30870.8028044269482471265@ietfa.amsl.com> Date: Thu, 06 Apr 2017 15:34:45 -0700 In-Reply-To: (Bob Harold's message of "Tue, 4 Apr 2017 16:28:06 -0400") 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: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 22:43:44 -0000 Bob Harold writes: > This one still needs to be fixed: Thanks Bob. That was a straight copy; I hope to do a new version immediately and will certainly make that change. -- Wes Hardaker USC/ISI From nobody Thu Apr 6 17:05: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 3788F128854 for ; Thu, 6 Apr 2017 17:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-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 v5e7AgAqbEHK for ; Thu, 6 Apr 2017 17:05:28 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 3DA281296C3 for ; Thu, 6 Apr 2017 17:05:26 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id 81so49650199pgh.2 for ; Thu, 06 Apr 2017 17:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=m4yUef7owAaKw8unKx67ZlJ24XnkkzvT9f1kTOwjoEM=; b=qbzAQW+ej8WNnc+Xn6FnKoUvT4Jsu6LwnxxFopRGy9U+0tP9J5+Q7hiIfn50av7vZf HetU7/j7SafVWoc+f1FxQp6VdJA/2ZQvOouwzRGnPf0hgQQf0onCa3ZlYNGWyTDGE4cL uK/YlfS7YaSmvhJzcqOmCwbX/20dhD/jeFrsn687v4eQbekfV7nfCGCTHIcnwbRxpg/s FMp7RjGU2yivJaTZ4z7e76/m0ch+foECyYHZfdSGaMFuoKr0q5ep6MyumOVmuFCDb0ID uHk425qTgv/xZZ/npJJH1+KDBtRughqPX75y6AxID75DjBYbje36YKUMHSh5BUymsW9l tLdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=m4yUef7owAaKw8unKx67ZlJ24XnkkzvT9f1kTOwjoEM=; b=S9BiHyKhZZ6Ht9AxGGouScCwDgz+OF5jIpM0A/+vqAERqfmoOFMjxluc0x0r0AnpzQ DQEIHLpmxsV5esreKQY+9iIR8Vpu3w/icPhf2AgwCOEOhLj5SVCB7UpOSg2IOUMsjabJ dJivDC9HEuyl1CeLwgfd/b3HUZhKcnrEgZtXKgVN1Qn7ddROSBBZ8FUzcWcrq8jfIbay n3I2pc1sAw/hsHKa3WUiaZbPU16rz5vu9b9r6+7f0wds/nJejM9GS7zhriRmR+j6bspi N+kmUXbTell06ggPcuiXpjTl2BYjbz5QFvCXm9e9Rt+I5hKXoVIxmJ+oD5jPLqMX1vho C4Sg== X-Gm-Message-State: AFeK/H1UJL3zGOhtdw6TXIrA8YQxx9OlNF4G9PtX+uo1d2BWfSxiMvyP6CBaryp/JMCYNw== X-Received: by 10.84.204.136 with SMTP id b8mr45085870ple.176.1491523525887; Thu, 06 Apr 2017 17:05:25 -0700 (PDT) Received: from [172.10.3.106] ([202.65.34.7]) by smtp.gmail.com with ESMTPSA id r73sm5675167pfe.19.2017.04.06.17.05.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 17:05:24 -0700 (PDT) Date: Thu, 6 Apr 2017 13:53:25 -1000 From: David Conrad To: =?utf-8?Q?Bj=C3=B8rn_Mork?= , Paul Vixie Cc: Tony Finch , dnsop@ietf.org Message-ID: <6ac82154-9990-4f20-9d38-090df7a3e098@Spark> In-Reply-To: <58E63559.1030608@redbarn.org> References: <87inmhrjpx.fsf@miraculix.mork.no> <87pogppwn0.fsf@miraculix.mork.no> <58E63559.1030608@redbarn.org> X-Readdle-Message-ID: 6ac82154-9990-4f20-9d38-090df7a3e098@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="58e6d7c0_643c9869_12065" Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 00:05:31 -0000 --58e6d7c0_643c9869_12065 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Apr 6, 2017, 2:32 AM -1000, Paul Vixie , wrote: > if you want to run yeti-style, there are some perl scripts that will > fetch and verify the root zone, edit the apex NS and DNSKEY RRsets, > re-sign with your local key, and give you a zone you can run on several > servers inside your internal network, such that you can point your > "hints" and your dnssec anchor at servers you control, for all your > internal-network recursives, Not so sure this is something I'd go about recommending to pretty much anyone other than hardcore, very experienced DNS/DNSSEC protocol geeks since it pretty much defeats the purpose of DNSSEC (edit the apex? ugh) and requires all relying devices to configure a "non-default" trust anchor or suffer SERVFAILs. Regards, -drc --58e6d7c0_643c9869_12065 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On Apr 6, 2017, = 2:32 AM -1000, Paul Vixie <paul=40redbarn.org>, wrote:

if you want to run yeti-style,= there are some perl scripts that will
fetch and verify the root zone, edit the apex NS and DNSKEY RRsets,
= re-sign with your local key, and give you a zone you can run on several servers inside your internal network, such that you can point your
=22hints=22 and your dnssec anchor at servers you control, for all your internal-network recursives, &=23160;

Not so sure this is something I'd go about recommending to pretty mu= ch anyone other than hardcore, very experienced DNS/DNSSEC protocol geeks= since it pretty much defeats the purpose of DNSSEC (edit the apex=3F ugh= ) and requires all relying devices to configure a =22non-default=22 trust= anchor or suffer SERV=46AILs.

Regards,
-drc


--58e6d7c0_643c9869_12065-- From nobody Thu Apr 6 17:24: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 58BB0127275 for ; Thu, 6 Apr 2017 17:24:36 -0700 (PDT) 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 2r3VPKfI9nGK for ; Thu, 6 Apr 2017 17:24:34 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8401286CA for ; Thu, 6 Apr 2017 17:24:25 -0700 (PDT) Received: from linux-hs2j.localnet (dhcp-148.access.lah1.vix.su [24.104.150.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 18A4061F9C for ; Fri, 7 Apr 2017 00:24:25 +0000 (UTC) From: Paul Vixie To: dnsop@ietf.org Date: Fri, 07 Apr 2017 00:24:24 +0000 Message-ID: <2448193.4rPzoQ60ob@linux-hs2j> Organization: Vixie Freehold In-Reply-To: <6ac82154-9990-4f20-9d38-090df7a3e098@Spark> References: <87inmhrjpx.fsf@miraculix.mork.no> <58E63559.1030608@redbarn.org> <6ac82154-9990-4f20-9d38-090df7a3e098@Spark> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart3708126.Sx58FjHPgR" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 00:24:36 -0000 This is a multi-part message in MIME format. --nextPart3708126.Sx58FjHPgR Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Thursday, April 6, 2017 11:53:25 PM GMT David Conrad wrote: > On Apr 6, 2017, 2:32 AM -1000, Paul Vixie , wrote: > > if you want to run yeti-style, there are some perl scripts that will > > fetch and verify the root zone, edit the apex NS and DNSKEY RRsets, > > re-sign with your local key, and give you a zone you can run on several > > servers inside your internal network, such that you can point your > > "hints" and your dnssec anchor at servers you control, for all your > > internal-network recursives, > > Not so sure this is something I'd go about recommending to pretty much > anyone other than hardcore, very experienced DNS/DNSSEC protocol geeks > since it pretty much defeats the purpose of DNSSEC (edit the apex? ugh) and > requires all relying devices to configure a "non-default" trust anchor or > suffer SERVFAILs. other than one proviso and one misstatement, i agree with this. the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or non- experienced or non-protocol-geeks; and both approaches are appropriate only for closed internal networks where the configuration is controlled by a single administration. the misstatement is, dnssec's purpose is not defeated, because iana's signatures are checked before the zone is accepted, and new signatures are added using local keys before publication. for my many-vm's laptop environment, running on a loopback isn't a solution. see also: http://www.circleid.com/posts/20160330_let_me_make_yeti_dns_perfectly_clear/ vixie --nextPart3708126.Sx58FjHPgR Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Thursday, April 6, 2017 11:53:25 PM GMT David Conrad wrote:

> On Apr 6, 2017, 2:32 AM -1000, Paul Vixie <paul@redbarn.org>, wrote:

> > if you want to run yeti-style, there are some perl scripts that will

> > fetch and verify the root zone, edit the apex NS and DNSKEY RRsets,

> > re-sign with your local key, and give you a zone you can run on several

> > servers inside your internal network, such that you can point your

> > "hints" and your dnssec anchor at servers you control, for all your

> > internal-network recursives,

>

> Not so sure this is something I'd go about recommending to pretty much

> anyone other than hardcore, very experienced DNS/DNSSEC protocol geeks

> since it pretty much defeats the purpose of DNSSEC (edit the apex? ugh) and

> requires all relying devices to configure a "non-default" trust anchor or

> suffer SERVFAILs.

 

other than one proviso and one misstatement, i agree with this.

 

the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or non-experienced or non-protocol-geeks; and both approaches are appropriate only for closed internal networks where the configuration is controlled by a single administration.

 

the misstatement is, dnssec's purpose is not defeated, because iana's signatures are checked before the zone is accepted, and new signatures are added using local keys before publication.

 

for my many-vm's laptop environment, running on a loopback isn't a solution.

 

see also:

 

http://www.circleid.com/posts/20160330_let_me_make_yeti_dns_perfectly_clear/

 

vixie

--nextPart3708126.Sx58FjHPgR-- From nobody Thu Apr 6 18: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 32778129551 for ; Thu, 6 Apr 2017 18:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-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 F3IA_N87DYb9 for ; Thu, 6 Apr 2017 18:25:00 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 23B031293DF for ; Thu, 6 Apr 2017 18:25:00 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id g2so50266011pge.3 for ; Thu, 06 Apr 2017 18:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=57xpah1MphYSetvt47cPhUU6Uf9bZ4rXcMgA94WqDt0=; b=MWGZDwcwWGZzWxwJJC38pJbeYU1bcEsDC6Ji83mg2FLa/NKQGUgDCAbjfXUf0LyE/k DQVXbdZruetEIObYn/2RjAmsxWViWc6r0dF59RGoLa19MMeJTAR4fCWzj9ocNDfhdB5m bObpQoeCIGG/riWICbusfGWEUPPlPbIA8rDKQAbtk8woI6qYiIUozXzRemNFsxQ75BPH tbZo/1tbGA5+si+h3Wbsc9KqqhIpwvSblf2H+xqnnRDUA4aqANkDtU9HQ+NgDqmfxNa7 /gDqmieJiF/GmFmjtLLO+EW0UiauExOs6PEt2olH6kNF6lxX4Jkxdqn+zLWMspN2RjTr FC4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=57xpah1MphYSetvt47cPhUU6Uf9bZ4rXcMgA94WqDt0=; b=lkRBzkHnckwt+MGUtwybS5NOLjSfaDxBKIr6ZA0vGg6/8urmGo3swR3ckGAwHFDFKq H3tvX11Nkm3kxHN3U5D1CJvOogWBHrlNgVmrYuacPUHqba9M4NqPz5/iicL/8mR2qAXG PamrTPjLI2qiW/7XH11Yt/pLo6g6+kVO3N0KyqM+Qj5ynfECGQ4Kh6WarSmfIv10wH45 NWnKyTlpDlonQSpi0e0oCdUd5mqLGN/Aieyow4ZAhYAwGWAL1ohBN84MvFc+57egQNly +r8ZsRfryKm6gS0qpSi9lShEBbUEkiTmcFDKRzcAwsoRBnaLqh3W30Z/NUUBQDLzsvHp UF+w== X-Gm-Message-State: AFeK/H2/AAog9Z8rYAAY3lqAelTwZKHNObi2uJMAZCFLduEk2XJ6k+K9YN9xhZVLRIvZhw== X-Received: by 10.98.218.73 with SMTP id w9mr38900786pfl.100.1491528299677; Thu, 06 Apr 2017 18:24:59 -0700 (PDT) Received: from [172.10.3.106] ([202.65.34.7]) by smtp.gmail.com with ESMTPSA id m20sm5829111pgd.32.2017.04.06.18.24.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 18:24:59 -0700 (PDT) Date: Thu, 6 Apr 2017 14:51:40 -1000 From: David Conrad To: dnsop@ietf.org, Paul Vixie Message-ID: In-Reply-To: <2448193.4rPzoQ60ob@linux-hs2j> References: <87inmhrjpx.fsf@miraculix.mork.no> <58E63559.1030608@redbarn.org> <6ac82154-9990-4f20-9d38-090df7a3e098@Spark> <2448193.4rPzoQ60ob@linux-hs2j> X-Readdle-Message-ID: f321b974-2149-478d-9b63-a19d10ed013e@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="58e6ea67_66334873_12065" Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 01:25:02 -0000 --58e6ea67_66334873_12065 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Paul, On Apr 6, 2017, 2:24 PM -1000, Paul Vixie , wrote: > the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or non-experienced or non-protocol-geeks; 7706 doesn't recommend editing someone else's zone file, re-signing it, and figuring out how to replicate the hints and trust anchor to _all_ relying devices (and restoring the real hints/trust anchor when you're done). This strikes me as a bit more complicated than 7706. YMMV. > and both approaches are appropriate only for closed internal networks where the configuration is controlled by a single administration. If I set up an open resolver using 7706, what negative repercussions do you see? > the misstatement is, dnssec's purpose is not defeated, because iana's signatures are checked before the zone is accepted, and new signatures are added using local keys before publication. Meaningless given you are explicitly editing the zone as published from and signed by the authority. You claim you aren't modifying the namespace content (well, except for the root NSes), but the point of DNSSEC and the rather Byzantine structures we've built around establishing trust is that we don't have to believe you: you can see _everything_ having to do with creating the trust anchor and everything down to the leaf. The only advantage(?) I see in your approach is that is allows (forces) you to play around with the namespace and re-sign. Might be useful for neo maxi zoom DNSSEC nerd experimentation, however as mentioned previously, that doesn't strike me as something one might recommend lightheartedly. > for my many-vm's laptop environment, running on a loopback isn't a solution. I strongly suspect you could come up with a solution that didn't use loopback but which also didn't require modifying the root zone, resigning it, and getting all relying devices to use both your NS hints and trust anchor. Like, perhaps running on a non-loopback address within your flock of laptop VMs? > http://www.circleid.com/posts/20160330_let_me_make_yeti_dns_perfectly_clear/ Saw that a year ago and still think it post-hoc rationalization and specious, but I'm sure that's just me. Regards, -drc --58e6ea67_66334873_12065 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Paul,

On Apr 6, 2017, 2:24 PM -1000, Paul Vixie <paul=40redbarn.org>, wro= te:

the = proviso is, R=46C 7706 is also completely unsuitable for non-hardcore or = non-experienced or non-protocol-geeks; &=23160;


7706 doesn't recommend editing someone else's zone file, re-signing = it, and figuring out how to replicate the hints and trust anchor to =5Fal= l=5F relying devices (and restoring the real hints/trust anchor when you'= re done). This strikes me as a bit more complicated than 7706. YMMV.&=231= 60;

and = both approaches are appropriate only for closed internal networks where t= he configuration is controlled by a single administration.&=23160;
<= /p>


If I set up an open resolver using 7706, what negative repercussions= do you see=3F

the misstatement is, dnssec's purpose is not defeated, because iana's= signatures are checked before the zone is accepted, and new signatures a= re added using local keys before publication.&=23160;


Meaningless given you are explicitly editing the zone as published f= rom and signed by the authority. You claim you aren't modifying the names= pace content (well, except for the root NSes), but the point of DNSSEC an= d the rather Byzantine structures we've built around establishing trust i= s that we don't have to believe you: you can see =5Feverything=5F having = to do with creating the trust anchor and everything down to the leaf.

The only advantage(=3F) I see in your approach is that is allows (fo= rces) you to play around with the namespace and re-sign. Might be useful = for neo maxi zoom DNSSEC nerd experimentation, however as mentioned previ= ously, that doesn't strike me as something one might recommend lightheart= edly.

for= my many-vm's laptop environment, running on a loopback isn't a solution.= &=23160;


I strongly suspect you could come up with a solution that didn't use= loopback but which also didn't require modifying the root zone, resignin= g it, and getting all relying devices to use both your NS hints and trust= anchor. Like, perhaps running on a non-loopback address within your floc= k of laptop VMs=3F

http://www.circleid.com/posts/20160330=5Flet=5Fme=5Fmake=5Fyeti=5Fdns= =5Fperfectly=5Fclear/&=23160;


Saw that a year ago and still think it post-hoc rationalization and = specious, but I'm sure that's just me.

Regards,
-drc

--58e6ea67_66334873_12065-- From nobody Thu Apr 6 19:01: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 681641294A2 for ; Thu, 6 Apr 2017 19:01:46 -0700 (PDT) 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 NEtsMOqtwxAy for ; Thu, 6 Apr 2017 19:01:43 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A121124D6C for ; Thu, 6 Apr 2017 19:01:43 -0700 (PDT) Received: from linux-hs2j.localnet (dhcp-148.access.lah1.vix.su [24.104.150.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id AFBC261F9C; Fri, 7 Apr 2017 02:01:41 +0000 (UTC) From: Paul Vixie To: dnsop@ietf.org Date: Fri, 07 Apr 2017 02:01:40 +0000 Message-ID: <1560750.L0Fn6CvLxk@linux-hs2j> Organization: Vixie Freehold In-Reply-To: References: <87inmhrjpx.fsf@miraculix.mork.no> <2448193.4rPzoQ60ob@linux-hs2j> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart82869878.r0rjZrIh4N" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 02:01:46 -0000 This is a multi-part message in MIME format. --nextPart82869878.r0rjZrIh4N Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Friday, April 7, 2017 12:51:40 AM GMT David Conrad wrote: > Paul, > > On Apr 6, 2017, 2:24 PM -1000, Paul Vixie , wrote: > > the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or > > non-experienced or non-protocol-geeks; > ... This strikes me as a bit more complicated than 7706. YMMV. yes, it does. > > and both approaches are appropriate only for closed internal networks > > where the configuration is controlled by a single administration. > If I set up an open resolver using 7706, what negative repercussions do you > see? you'll need some name server features that aren't otherwise standardized, and maybe a patch or two. in my preferred approach, you just load a zone, because all of the special logic is outside of the name server and its configuration. > > the misstatement is, dnssec's purpose is not defeated, because iana's > > signatures are checked before the zone is accepted, and new signatures > > are added using local keys before publication. > Meaningless given you are explicitly editing the zone as published from and > signed by the authority. i hear you say meaningless, but i know that you know the difference between a name space and a zone that implements that namespace, and i know you've read my explainations about the importance of that distinction. it's not meaningless. > You claim you aren't modifying the namespace > content (well, except for the root NSes), ... what is namespace content? i know namespaces, and i know zone content. > but the point of DNSSEC and the > rather Byzantine structures we've built around establishing trust is that > we don't have to believe you: you can see _everything_ having to do with > creating the trust anchor and everything down to the leaf. that point is not lost. dig +trace +dnssec works as expected. transitive trust is a real thing: if i trust where i got the data, because i verified the signatures, and i trust my own keys and signatures, then trading one set of trust anchors and signatures for another lost me no root-to-leaf trust, in the eyes of my target audience, who is in the case of my laptop, me. > The only advantage(?) I see in your approach is that is allows (forces) you > to play around with the namespace and re-sign. it plays around with the zone content. not the namespace. > Might be useful for neo maxi > zoom DNSSEC nerd experimentation, however as mentioned previously, that > doesn't strike me as something one might recommend lightheartedly. note that since many enterprise networks do augment the iana namespace for internal use (creating problems like .home and .corp collisions), there is often a loss of dnssec integrity. my approach is one way to retain dnssec integrity in that situation, and has not been recommended lightheartedly. > > for my many-vm's laptop environment, running on a loopback isn't a > > solution. > I strongly suspect you could come up with a solution that didn't use > loopback but which also didn't require modifying the root zone, resigning > it, and getting all relying devices to use both your NS hints and trust > anchor. Like, perhaps running on a non-loopback address within your flock > of laptop VMs? i do run on a non-loopback address within my vm-local network. but unless i pirate the addresses of all the real root name servers (which i won't do), or re-sign the iana content with a local NS RRset and trust anchoe (which i am doing), then cache priming is going to cause my hints to be ignored by the other rdns servers local to me. note that very few people will ever run multiple rdns servers inside a laptop. i am not suggesting that my use case is or will ever be common. but it works. at a slightly broader scale, for instance my home network, it would also work. however, i'm using the yeti system here, so i can't experiment separately. at enterprise scale, or metro or region or national scale, it would also work. as you know i've suggested for some time now that iana build and sign a second root zone, having the same name space (which is regulated by icann and ietf) but having a different apex NS RRset (which i think can be regulated differently.) iana is in a perfect position to sign its zone using NS RR's and associated AAAA RR's that lead to addresses i *would* be willing to pirate. this is also called "the AS112 unowned anycast approach". if i could slave an iana-signed zone on my laptop that already had pirateable IP addresses reached by hints and the apex NS RRset, i would not need Perl to do what i'm doing. and i would be using the iana trust anchor. and it would be a configuration that i would recommend for all internet users. sadly, a lot of people saying that "the namespace and the zone are the same thing" has kept that door pretty well closed. so, here i am with Perl instead. > > http://www.circleid.com/posts/20160330_let_me_make_yeti_dns_perfectly_clear/ > Saw that a year ago and still think it post-hoc rationalization and > specious, but I'm sure that's just me. i am also sure that it's just you, because those principles were documented by the yeti project before it served its first request. vixie --nextPart82869878.r0rjZrIh4N Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Friday, April 7, 2017 12:51:40 AM GMT David Conrad wrote:

> Paul,

>

> On Apr 6, 2017, 2:24 PM -1000, Paul Vixie <paul@redbarn.org>, wrote:

> > the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or

> > non-experienced or non-protocol-geeks;

> ... This strikes me as a bit more complicated than 7706. YMMV.

 

yes, it does.

 

> > and both approaches are appropriate only for closed internal networks

> > where the configuration is controlled by a single administration.

> If I set up an open resolver using 7706, what negative repercussions do you

> see?

 

you'll need some name server features that aren't otherwise standardized, and maybe a patch or two. in my preferred approach, you just load a zone, because all of the special logic is outside of the name server and its configuration.

 

> > the misstatement is, dnssec's purpose is not defeated, because iana's

> > signatures are checked before the zone is accepted, and new signatures

> > are added using local keys before publication.

> Meaningless given you are explicitly editing the zone as published from and

> signed by the authority.

 

i hear you say meaningless, but i know that you know the difference between a name space and a zone that implements that namespace, and i know you've read my explainations about the importance of that distinction. it's not meaningless.

 

> You claim you aren't modifying the namespace

> content (well, except for the root NSes), ...

 

what is namespace content? i know namespaces, and i know zone content.

 

> but the point of DNSSEC and the

> rather Byzantine structures we've built around establishing trust is that

> we don't have to believe you: you can see _everything_ having to do with

> creating the trust anchor and everything down to the leaf.

 

that point is not lost. dig +trace +dnssec works as expected. transitive trust is a real thing: if i trust where i got the data, because i verified the signatures, and i trust my own keys and signatures, then trading one set of trust anchors and signatures for another lost me no root-to-leaf trust, in the eyes of my target audience, who is in the case of my laptop, me.

 

> The only advantage(?) I see in your approach is that is allows (forces) you

> to play around with the namespace and re-sign.

 

it plays around with the zone content. not the namespace.

 

> Might be useful for neo maxi

> zoom DNSSEC nerd experimentation, however as mentioned previously, that

> doesn't strike me as something one might recommend lightheartedly.

 

note that since many enterprise networks do augment the iana namespace for internal use (creating problems like .home and .corp collisions), there is often a loss of dnssec integrity. my approach is one way to retain dnssec integrity in that situation, and has not been recommended lightheartedly.

 

> > for my many-vm's laptop environment, running on a loopback isn't a

> > solution.

> I strongly suspect you could come up with a solution that didn't use

> loopback but which also didn't require modifying the root zone, resigning

> it, and getting all relying devices to use both your NS hints and trust

> anchor. Like, perhaps running on a non-loopback address within your flock

> of laptop VMs?

 

i do run on a non-loopback address within my vm-local network. but unless i pirate the addresses of all the real root name servers (which i won't do), or re-sign the iana content with a local NS RRset and trust anchoe (which i am doing), then cache priming is going to cause my hints to be ignored by the other rdns servers local to me.

 

note that very few people will ever run multiple rdns servers inside a laptop. i am not suggesting that my use case is or will ever be common. but it works.

 

at a slightly broader scale, for instance my home network, it would also work. however, i'm using the yeti system here, so i can't experiment separately.

 

at enterprise scale, or metro or region or national scale, it would also work.

 

as you know i've suggested for some time now that iana build and sign a second root zone, having the same name space (which is regulated by icann and ietf) but having a different apex NS RRset (which i think can be regulated differently.) iana is in a perfect position to sign its zone using NS RR's and associated AAAA RR's that lead to addresses i *would* be willing to pirate. this is also called "the AS112 unowned anycast approach".

 

if i could slave an iana-signed zone on my laptop that already had pirateable IP addresses reached by hints and the apex NS RRset, i would not need Perl to do what i'm doing. and i would be using the iana trust anchor. and it would be a configuration that i would recommend for all internet users.

 

sadly, a lot of people saying that "the namespace and the zone are the same thing" has kept that door pretty well closed. so, here i am with Perl instead.

 

> > http://www.circleid.com/posts/20160330_let_me_make_yeti_dns_perfectly_clear/

> Saw that a year ago and still think it post-hoc rationalization and

> specious, but I'm sure that's just me.

 

i am also sure that it's just you, because those principles were documented by the yeti project before it served its first request.

 

vixie

--nextPart82869878.r0rjZrIh4N-- From nobody Thu Apr 6 23:44: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 ECC3B126E01 for ; Thu, 6 Apr 2017 23:44:50 -0700 (PDT) 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 WC2Pn_QlmjCR for ; Thu, 6 Apr 2017 23:44:47 -0700 (PDT) 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 125211288B8 for ; Thu, 6 Apr 2017 23:44:46 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:3c63:bff:fe95:114f] (unknown [IPv6:2001:1488:fffe:6:3c63:bff:fe95:114f]) by mail.nic.cz (Postfix) with ESMTPSA id B2F1B60140; Fri, 7 Apr 2017 08:44:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1491547484; bh=+y2qsBP1vb70va6PiGoQ/hmj6ega3Ifp2ak0vUsy70I=; h=To:From:Date; b=GgnmlkWrZkDsHd9g6ZoNveiVjdEhrW6wzs8VYJjugbsCTWHDDpsJiyJr74Tbiy2eH KqNZAxY75KKgvaLAxAdb7WsTtV2kSw9W0/bwUBsfk/N8wSGlKUjcU6LHk9Xnn7gZFx bRDTAMt+vIzjtXEaYY2zlHmJRtE226ydZwe9c4ms= To: Matthew Pounsett , Tony Finch References: <20170330230806.6273.qmail@ary.lan> <9232F4F4-772F-48AA-80FB-C990662AFD7A@powerdns.com> Cc: dnsop , Peter van Dijk From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <887fdc84-cefa-97f4-3e93-c013cfea9fe7@nic.cz> Date: Fri, 7 Apr 2017 08:44:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.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 draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 06:44:51 -0000 On 4.4.2017 19:30, Matthew Pounsett wrote: > On 4 April 2017 at 13:21, Tony Finch > wrote: > > > I believe that's a faulty assumption. Here's some data: > > > > [...] During the month of February, [...] an average of 31 changes > per zone. [...] > > That seems to agree with what I meant, though I probably should have > said > "per-zone" somewhere :-) > > That's the average, but there's a not-insignificant number there being > updated many times per day. Most of the time, you're right, there are > few changes, but one can't assume that any given alias will have a low > rate of change. Numbers, that really helps! If I consider the numbers above and the fact that IXFR is able to deal even dynamically updated zones, I conclude that pushing ANAME logic to provisioner side is reasonable approach and that added complexity in name server itself is not warranted. -- Petr Špaček @ CZ.NIC From nobody Fri Apr 7 00:38: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 F24D11293DF for ; Fri, 7 Apr 2017 00:38:09 -0700 (PDT) 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 lkkhPo4OUIzh for ; Fri, 7 Apr 2017 00:38:07 -0700 (PDT) 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 A0F8B1205D3 for ; Fri, 7 Apr 2017 00:38:07 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:3c63:bff:fe95:114f] (unknown [IPv6:2001:1488:fffe:6:3c63:bff:fe95:114f]) by mail.nic.cz (Postfix) with ESMTPSA id E6EF562087 for ; Fri, 7 Apr 2017 09:38:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1491550685; bh=kWIY0zHPsO1JNHEVnNQVIYdBLN9UTOe0GY7h6zEO0mU=; h=To:From:Date; b=IUGs+moQweXnXUCN8R1CmzyF1dL81AfC7i4VDNNfnCIuIhAWvETeDIdxSimcH44w5 XMCStmxuyXHXY2lZgEctQ/Iw2Okkjf8IMb/bO32DoU9EHQATLtu30KdB09GF/sBVGq xI9eUZsFwzUJikHF5f+yxfeZ54yfSKG/TU7pO4GQ= To: dnsop@ietf.org References: <149071310862.30579.14412477244940530567@ietfa.amsl.com> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Fri, 7 Apr 2017 09:38:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149071310862.30579.14412477244940530567@ietfa.amsl.com> 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] I-D Action: draft-ietf-dnsop-dns-wireformat-http-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 07:38:10 -0000 Hello, On 28.3.2017 16:58, 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 wire-format over HTTP > Authors : Linjian Song > Paul Vixie > Shane Kerr > Runxia Wan > Filename : draft-ietf-dnsop-dns-wireformat-http-01.txt Version draft-ietf-dnsop-dns-wireformat-http-01 is the first one I reviewed and it is a good read. No objections to current version. Are there any implementations? -- Petr Špaček @ CZ.NIC From nobody Fri Apr 7 01:20: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 5C1FA1293FF for ; Fri, 7 Apr 2017 01:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.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 0uTEAcaAoKGY for ; Fri, 7 Apr 2017 01:20:10 -0700 (PDT) Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (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 E6847129401 for ; Fri, 7 Apr 2017 01:20:08 -0700 (PDT) Received: from miraculix.mork.no ([IPv6:2a02:2121:45:dc4d:b474:86ff:fe5d:4ecf]) (authenticated bits=0) by canardo.mork.no (8.14.4/8.14.4) with ESMTP id v378K5x2029761 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 7 Apr 2017 10:20:06 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1491553206; bh=XHEKU+xUxKo9KtFhZcGzxRagSzM2EfaQv1xJlSnNM5M=; h=From:To:Subject:References:Date:Message-ID:From; b=hNtylcoX00b5naWejP8XchjT9quCT6N+3NQIZ8GwFNxRqGcBXNjkA57CumdPxeOwz sA/ZCYZ3NzJjjPJkaF6+HwHiDp1Y5L9TfMkzPok6JAKA06ZcyaO2ay+vAynQjjgSen PY1csYqwPBYCW9UJE+CojeCa4vOtp0W3GhE6FPzI= Received: from bjorn by miraculix.mork.no with local (Exim 4.89) (envelope-from ) id 1cwP7g-00011J-2r for dnsop@ietf.org; Fri, 07 Apr 2017 10:20:00 +0200 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: dnsop@ietf.org Organization: m References: <87inmhrjpx.fsf@miraculix.mork.no> <2448193.4rPzoQ60ob@linux-hs2j> <1560750.L0Fn6CvLxk@linux-hs2j> Date: Fri, 07 Apr 2017 10:20:00 +0200 In-Reply-To: <1560750.L0Fn6CvLxk@linux-hs2j> (Paul Vixie's message of "Fri, 07 Apr 2017 02:01:40 +0000") Message-ID: <8760igpr2n.fsf@miraculix.mork.no> User-Agent: Gnus/5.130015 (Ma Gnus v0.15) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.99.2 at canardo X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 08:20:12 -0000 Just to avoid any confusion: Although I demonstrated the issue by running BIND on my laptop only, the real usage scenario is resolver service for a few million distinct administrative domains (aka "customers"). Changing the trust anchor is not an option. Bj=C3=B8rn From nobody Fri Apr 7 01:23: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 E9B26129687 for ; Fri, 7 Apr 2017 01:23:34 -0700 (PDT) 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, 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 lWwBvRkrpptx for ; Fri, 7 Apr 2017 01:23:32 -0700 (PDT) Received: from tmpmail.powerdns.com (tmpmail.powerdns.com [128.199.32.142]) by ietfa.amsl.com (Postfix) with ESMTP id D5AB9129451 for ; Fri, 7 Apr 2017 01:23:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tmpmail.powerdns.com (Postfix) with ESMTP id 3F3EF6803D; Fri, 7 Apr 2017 04:23:30 -0400 (EDT) Received: from tmpmail.powerdns.com ([127.0.0.1]) by localhost (tmpmail.powerdns.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnQVFYLNcxNf; Fri, 7 Apr 2017 04:23:28 -0400 (EDT) Received: from server.ds9a.nl (unknown [IPv6:2001:470:1f15:bba::42]) by tmpmail.powerdns.com (Postfix) with ESMTP id EDB566010F; Fri, 7 Apr 2017 04:23:27 -0400 (EDT) Received: by server.ds9a.nl (Postfix, from userid 1000) id B4413AC322F; Fri, 7 Apr 2017 10:23:26 +0200 (CEST) Date: Fri, 7 Apr 2017 10:23:26 +0200 From: bert hubert To: =?iso-8859-1?Q?Bj=F8rn?= Mork Cc: dnsop@ietf.org Message-ID: <20170407082326.GH17910@server.ds9a.nl> References: <87inmhrjpx.fsf@miraculix.mork.no> <2448193.4rPzoQ60ob@linux-hs2j> <1560750.L0Fn6CvLxk@linux-hs2j> <8760igpr2n.fsf@miraculix.mork.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8760igpr2n.fsf@miraculix.mork.no> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 08:23:35 -0000 On Fri, Apr 07, 2017 at 10:20:00AM +0200, Bjrn Mork wrote: > Just to avoid any confusion: Although I demonstrated the issue by > running BIND on my laptop only, the real usage scenario is resolver > service for a few million distinct administrative domains (aka > "customers"). Changing the trust anchor is not an option. Perhaps https://lists.isc.org/mailman/listinfo/bind-users is a great place to discuss BIND configurations and issues. Bert From nobody Fri Apr 7 01:50: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 5D2081293FF for ; Fri, 7 Apr 2017 01:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.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 JAiLZuowS4Uk for ; Fri, 7 Apr 2017 01:50:17 -0700 (PDT) Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (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 7273512948F for ; Fri, 7 Apr 2017 01:50:17 -0700 (PDT) Received: from miraculix.mork.no ([IPv6:2a02:2121:45:dc4d:b474:86ff:fe5d:4ecf]) (authenticated bits=0) by canardo.mork.no (8.14.4/8.14.4) with ESMTP id v378oEeW000341 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 10:50:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1491555015; bh=kuj5q46JowDe77skua/Uv8Q5XHeZNCYXSkRvbVQzSWI=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=kFob2P5dGm8AITS+gf7WKkpMGBQXxAz2zD/1m30jIroK13gT6pxIbFOFqm7EUfIKt cRcC8PE0VWNpvDP+ccnyA0b84GzPj6m5V/stH37d9hp3GHgdURIFOl2DR3FrFJJjOn 2zVc0tN3N8NSH6jZQCX8AxLk1rgAGEu73P8ARPrA= Received: from bjorn by miraculix.mork.no with local (Exim 4.89) (envelope-from ) id 1cwPar-00015C-GZ; Fri, 07 Apr 2017 10:50:09 +0200 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: bert hubert Cc: dnsop@ietf.org Organization: m References: <87inmhrjpx.fsf@miraculix.mork.no> <2448193.4rPzoQ60ob@linux-hs2j> <1560750.L0Fn6CvLxk@linux-hs2j> <8760igpr2n.fsf@miraculix.mork.no> <20170407082326.GH17910@server.ds9a.nl> Date: Fri, 07 Apr 2017 10:50:09 +0200 In-Reply-To: <20170407082326.GH17910@server.ds9a.nl> (bert hubert's message of "Fri, 7 Apr 2017 10:23:26 +0200") Message-ID: <87vaqgob3y.fsf@miraculix.mork.no> User-Agent: Gnus/5.130015 (Ma Gnus v0.15) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.99.2 at canardo X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 08:50:19 -0000 bert hubert writes: > On Fri, Apr 07, 2017 at 10:20:00AM +0200, Bj=C3=B8rn Mork wrote: >> Just to avoid any confusion: Although I demonstrated the issue by >> running BIND on my laptop only, the real usage scenario is resolver >> service for a few million distinct administrative domains (aka >> "customers"). Changing the trust anchor is not an option. > > Perhaps https://lists.isc.org/mailman/listinfo/bind-users is a great place > to discuss BIND configurations and issues. Definitely. Or even bind-workers when it comes to questions about the reason for making static-stub zones recursive only. The reason I ask here first, is because RFC 7706 includes a BIND specific configuration example (as well as examples for other recursive server software). So before considering changing config or code, I wanted to know the background of that example. Was there a real reason for the obscure(?) "static-stub" zone type, or was that just an arbitrary choice? My apologies if this is considered OT here. I will shut up now. Bj=C3=B8rn From nobody Fri Apr 7 04:25: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 835EB128D40 for ; Fri, 7 Apr 2017 04:25:25 -0700 (PDT) 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 PXtCj0V7qcKH for ; Fri, 7 Apr 2017 04:25:23 -0700 (PDT) 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 9A079120046 for ; Fri, 7 Apr 2017 04:25:23 -0700 (PDT) Received: from [IPv6:2001:67c:1220:80c:e4f1:5ed2:dd83:bd03] (unknown [IPv6:2001:67c:1220:80c:e4f1:5ed2:dd83:bd03]) by mail.nic.cz (Postfix) with ESMTPSA id 9F50A60900 for ; Fri, 7 Apr 2017 13:25:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1491564321; bh=LFuUncdOR/+iu3RVyKJk1o3m5ZfEeNMjLZUafIVCaHE=; h=To:From:Date; b=PLN1bLiaQXoE1bd1PTVruAy56x14dDhiv8/z0izaRcmcO1j8hTYAKMI++jIOuD/OA kbDMHqOQ/Z+i7QRrw2jQRapk6mkU574A8ke5hInvtW+Y3LRACOymtCd9O44G7KFRCh V34pMDhAikDq2vkhVMGHq4TZpRHWRYC+uOiv1h30= To: dnsop@ietf.org References: <20170331034800.GD99337@isc.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Fri, 7 Apr 2017 13:25:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170331034800.GD99337@isc.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] DNSSEC validator requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 11:25:25 -0000 On 31.3.2017 05:48, Evan Hunt wrote: > I have reviewed draft-mglt-dnsop-dnssec-validator-requirements-04.txt and > some comments on the substance of it are below. (I'll also send some > grammatical nitpicks via private mail.) > >> However, without valid trust anchor(s) and an acceptable value for the >> current time, DNSSEC validation cannot be performed. This document lists >> the requirements to be addressed so resolvers can have DNSSEC validation >> can be always-on. > > This abstract, and the introduction below, both seem to suggest that the > intention of this draft is to list requirements for automatic bootstrapping > and recovery of DNSSEC without human intervention. However, several of the > requirements actually included in the text describe mechanisms of human > intervention: for example, insertion of negative trust anchors or the > ability to flush the cache. > > To my mind, any need for human intervention contradicts the idea of DNSSEC > being "always-on"; humans can't react instantly. So I suggest revising > the abstract and the problem statement to say that these are requirements > for a DNSSEC validator to be recovered when it fails, rather than for > it always to be on. A document listing what can possibly go wrong with DNSSEC deployment in real world and what "features/tools" software vendors have to provide to ease recovery is a good idea. Having said that, I support Evan's view that here we are not talking about "always-on" but more about "human intervention"/recovery. I think that all other Evan's comments are good ideas as well and improve the document. I'm looking forward to reviewing a new version of the document. -- Petr Špaček @ CZ.NIC From nobody Fri Apr 7 06:38: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 6FEA212946E for ; Fri, 7 Apr 2017 06:38:16 -0700 (PDT) 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 AUXWdR9HThKl for ; Fri, 7 Apr 2017 06:38:14 -0700 (PDT) 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 7C297126DED for ; Fri, 7 Apr 2017 06:38:11 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id p22so62746388qka.3 for ; Fri, 07 Apr 2017 06:38:11 -0700 (PDT) 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=yYAaLlFDOJ7LY1rot13xQXPbVpy2yhRBxSW4tMfOeLk=; b=cFr7v+f0+iQuBFpc6EqC/DJQ9goD6PZUEVcs0p7Bn98SY0r+RxMdoy7iMZUS1AS5CG 0IFsFlgg0SJOEQBMP4D9hVQhz86oSZAdc3YdbgAO/eTkOn9ejIk6VsiVp5109DYpTsvf gPzXO4a4uCPOf1Fdeb3k9RDQ643GfXA7+vv7uQBSX4p62nYzdse+qIkgWPoGzmFbKPtr tDquKwVI+7OxMmOJ2eCgIWvxw7Fb8/pnlXdB1YtGT8x9VBCVSuvwlhczM4FQxd6w+iuU qzm+2h+NcQu+qLpBIHxy0LHggf16l7hdwyTucGtIaYTsrFTx6rdvrr4SqzwvSLj/elby WQjg== 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=yYAaLlFDOJ7LY1rot13xQXPbVpy2yhRBxSW4tMfOeLk=; b=l+MA3htFsCiwC37CczG7pBB+D/01TwWpM2FcD9vh2095QwWyMoGToo7YiwWYWoWxxp THQQh21+AffGprdmtJioTyuXyftYRgOU6x6asWppGXfijPYjAe+/R2s0FCvRCDpcF0sV Sak1IQwOLec5SQmekWVvNWQb8mz/MipK6ixpBtweYWU+AeYD60x/pcSj/u3F0JvsVAWu kz1GpLXrW0Is0TX4CqV2MIcMmOXu44wYkk0OxPCvCz0+FRxBBJzR6qEd2uTtHAq3TQGw X0WvabX3yJyseI+yn77s17po8YG4kbXZV9+fePkKIjppkcKPzEDc5tSww/tH/V2WyqHq znEw== X-Gm-Message-State: AFeK/H0iaJ6vorJMs+F+DB3goMO8vef8/qVautcLJNrsxAEsc3oELVVueuGAnmoq+aUSxA== X-Received: by 10.55.100.134 with SMTP id y128mr25215304qkb.291.1491572290668; Fri, 07 Apr 2017 06:38:10 -0700 (PDT) Received: from [172.20.19.221] ([66.228.68.154]) by smtp.gmail.com with ESMTPSA id z29sm3041600qtz.67.2017.04.07.06.38.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Apr 2017 06:38:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <20170401201727.GA5948@laperouse.bortzmeyer.org> Date: Fri, 7 Apr 2017 09:38:08 -0400 Cc: dnsop Content-Transfer-Encoding: quoted-printable Message-Id: References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [DNSOP] extended deadline Re: WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:38:16 -0000 Hi, We had initially scheduled the WGLC on this document to be over by now. = However, the flurry of activity around the review we were asked to do on = the homenet-dot draft, and the general traffic level on the list during = IETF 98, suggested to the chairs that we should extend the WGLC. We=E2=80=99re hereby formally extending it to next Wednesday, April 12. As always for WGLC=E2=80=94 we need to hear both support and opposition = for taking this draft to the next step in the process. thanks, Suzanne & TIm > On Apr 1, 2017, at 4:17 PM, Stephane Bortzmeyer = wrote: >=20 > On Sun, Mar 12, 2017 at 07:20:55PM -0400, > Suzanne Woolf wrote=20 > a message of 92 lines which said: >=20 >> This message opens a Working Group Last Call for: >>=20 >> "The ALT Special Use Top Level Domain" >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ = >=20 > I've read -08 and I believe I understand this draft. I'm not convinced > it's useful (most users of alternative resolution systems won't use it > and, anyway, I'm not even sure it will be added in the Special-Use > registry, which was wrongly frozen by the IESG) but I don't see big > issues with the draft, it seems to me it correctly describes the new > TLD. >=20 > Editorial : >=20 > Section 1: >=20 > "and that should not be resolved" I cannot parse it. Missing "it"? >=20 > Section 5 : >=20 > After "and anyone watching queries along the path", add a reference to > RFC 7626? >=20 > Normative references: >=20 > Why is RFC 6303 a normative reference? It is no longer used. >=20 > Why is RFC 7686 a normative reference? It is just an example. >=20 From nobody Fri Apr 7 06:51: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 1C2951294B7 for ; Fri, 7 Apr 2017 06:51:21 -0700 (PDT) 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 O_68Xxh7Z_jQ for ; Fri, 7 Apr 2017 06:51:18 -0700 (PDT) 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 AE5D11294BE for ; Fri, 7 Apr 2017 06:51:08 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id l201so17200856ybf.0 for ; Fri, 07 Apr 2017 06:51:08 -0700 (PDT) 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=q8UAO9QtBoh8YEYmDTjFhLwRDJps7oPHwOeTAGxP6PE=; b=Vvf54ptyEccJxLzBo7hHQnV1dFBJq6ZY3eGl+Vp1W6souAwqP5glY/nVXLyC9twLNv FU1j8XgIscXF0mskhCMDBJrYOdsVRE6CLh+M2VyBzF18OOIHbboGqpQdzcb83XYsCoFa xz/Fhugorgv0s0M451MsaCKmbEHpgia4vaYSmK/aRdZQj/oIZzpj4x+H128Y/idveB1N 70KiCn4dfbnDN1/sPJ7SQA5FulUSoCwBdYCj7L4T/jGSdpFij0epL4g/vDJUcjixjFP1 IjGl0gSMRmiEqO1LGGxBEPPs0261KmuyE1YgzDhcEfuKkIAlF7g5jRoWLKTbQbY7XbMH D8vw== 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=q8UAO9QtBoh8YEYmDTjFhLwRDJps7oPHwOeTAGxP6PE=; b=blo54VwZeT/V1G6SAnUqjXD2K2HcyfuYV/aVVYzVTjqcmFT2OdZVdAMfaYSpRMjpiA /T2W3zaGUveR+YmAy0irOCVQ9RWkk2//CYSat4j9l2bz49Uvmhasb1Dh+DVAt+OUY7SV INwhTkeqV3NRHILa4iYqkHmCwyUFIvMt3ik8rzkUs0NSaYj4PkaQK5/u8N8d4WNZVixQ 41KYr1+Xe3rTPNm7jnHkudaJyFD8fE+z6mB57vi/lXUHeZrlsnvfoyQxFs0StBC2nxz/ kvvNNvbWP5X0FerkjedMLSA4ytpPWJ/nXOlb6CWkQpWZIeyZjCzVe4j1CGFMVwuvzt82 DWgg== X-Gm-Message-State: AN3rC/75sfRFBz9/rBe9VmRYmUVjBmKBAbfD37yRwnfA+m+E+nAnWnUHv0SL9cX3cqYGIIbr8Jqf5T6C/+BE326s X-Received: by 10.37.215.140 with SMTP id o134mr7200382ybg.95.1491573067293; Fri, 07 Apr 2017 06:51:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.109.134 with HTTP; Fri, 7 Apr 2017 06:51:06 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB74CA@eusaamb107.ericsson.se> References: <149062396899.30595.6360166634187605799.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB74CA@eusaamb107.ericsson.se> From: Bob Harold Date: Fri, 7 Apr 2017 09:51:06 -0400 Message-ID: To: Daniel Migault Cc: dnsop Content-Type: multipart/alternative; boundary=94eb2c05c8bed58e6d054c93eac1 Archived-At: Subject: Re: [DNSOP] FW: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:51:21 -0000 --94eb2c05c8bed58e6d054c93eac1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 27, 2017 at 10:16 AM, Daniel Migault < daniel.migault@ericsson.com> wrote: > Hi, > > Please find an update of our draft on requirements for DNSSEC resolver. > > DNS resolvers hardly enable DNSSEC as 1) resolvers are not robust too DNS > authoritative operations =E2=80=93 like KSK roll over, signing errors=E2= =80=A6. =E2=80=93 and 2) > network administrators have little control on these resolvers to recover > such situations. > > The draft describes how invalid DNSSEC related RRsets may be considered b= y > the resolver. The listed requirements aim at designing mechanisms as well > as interactions with network managers can easily solve/avoid these > situations. Such mechanisms are expected to encourage DNSSEC deployment o= n > resolvers. > > Yours, > Daniel > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, March 27, 2017 9:13 AM > To: Edward Lewis ; Daniel Migault < > daniel.migault@ericsson.com>; Dan York ; york@isoc.org < > york@isoc.org> > Subject: New Version Notification for draft-mglt-dnsop-dnssec- > validator-requirements-04.txt > > > A new version of I-D, draft-mglt-dnsop-dnssec- > validator-requirements-04.txt > has been successfully submitted by Daniel Migault and posted to the IETF > repository. > > Name: draft-mglt-dnsop-dnssec-validator-requirements > Revision: 04 > Title: DNSSEC Validators Requirements > Document date: 2017-03-27 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-mglt-dnsop- > dnssec-validator-requirements-04.txt > Status: https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec- > validator-requirements/ > Htmlized: https://tools.ietf.org/html/draft-mglt-dnsop-dnssec- > validator-requirements-04 > Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-dnsop- > dnssec-validator-requirements-04 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-dnsop-dnss= ec- > validator-requirements-04 > > Abstract: > DNSSEC provides data integrity and authentication for DNSSEC > validators. However, without valid trust anchor(s) and an acceptable > value for the current time, DNSSEC validation cannot be performed. > This document lists the requirements to be addressed so resolvers can > have DNSSEC validation can be always-on. > A few minor sugguestions: The last part of the abstract "can have DNSSEC validation can be always-on" remove the last 'can' to get: "can have DNSSEC validation be always-on" 2. Introduction Second paragraph ends: "and then most of the communications relying on the DNS resolution." I would suggest "thus disabling the communications relying on the DNS resolution." Fourth paragraph starts: "The lake of management" "lake" -> "lack" Fourth paragraph near end: "these steps are way to small" "to" -> "too" and suggest "these steps are much too small" Fifth paragraph "and additiona mechanism" try either "and an additional mechanism" or "and additional mechanisms" 8. Private KSK/ZSK "split-zone" -> "split-view" --=20 Bob Harold --94eb2c05c8bed58e6d054c93eac1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Mar 27, 2017 at 10:16 AM, Daniel Migault <daniel.migault= @ericsson.com> wrote:
Hi,

Please find an update of our draft on requirements for DNSSEC resolver.

DNS resolvers hardly enable DNSSEC as 1) resolvers are not robust too DNS a= uthoritative operations =E2=80=93 like KSK roll over, signing errors=E2=80= =A6. =E2=80=93 and 2) network administrators have little control on these r= esolvers to recover such situations.

The draft describes how invalid DNSSEC related RRsets may be considered by = the resolver. The listed requirements aim at designing mechanisms as well a= s interactions with network managers can easily solve/avoid these situation= s. Such mechanisms are expected to encourage DNSSEC deployment on resolvers= .

Yours,
Daniel

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Monday, March 27, 2017 9:13 AM
To: Edward Lewis <edward.lewis= @icann.org>; Daniel Migault <daniel.migault@ericsson.com>; Dan York <york@isoc.org>; = york@isoc.org <york@isoc.org>= ;
Subject: New Version Notification for draft-mglt-dnsop-dnssec-validato= r-requirements-04.txt


A new version of I-D, draft-mglt-dnsop-dnssec-validator-requirements-0= 4.txt
has been successfully submitted by Daniel Migault and posted to the IETF re= pository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mglt-dnsop-dnssec-= validator-requirements
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNSSEC Validators Requirements
Document date:=C2=A0 2017-03-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-mglt-dnsop-dnssec-validator-requirements-04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mglt-dnsop= -dnssec-validator-requirements/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mglt-dnsop-dnssec-= validator-requirements-04
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mgl= t-dnsop-dnssec-validator-requirements-04
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-mglt-dnsop-dnssec-validator-requirements-04

Abstract:
=C2=A0 =C2=A0DNSSEC provides data integrity and authentication for DNSSEC =C2=A0 =C2=A0validators.=C2=A0 However, without valid trust anchor(s) and a= n acceptable
=C2=A0 =C2=A0value for the current time, DNSSEC validation cannot be perfor= med.
=C2=A0 =C2=A0This document lists the requirements to be addressed so resolv= ers can
=C2=A0 =C2=A0have DNSSEC validation can be always-on.
=
A few minor sugguestions:

=C2=A0The= last part of the abstract=C2=A0
"can have DNSSEC validation= can be always-on"
remove the la= st 'can' to get:
"can have DNS= SEC validation be always-on"

2.= Introduction Second paragraph ends: "and then most of the communications relying on the DNS resolution.&qu= ot; I would suggest "thus disabling the communications relying on the DNS resolution."= ;

Fourth paragraph starts:
"The lake of management"
&quo= t;lake" -> "lack"

Fourth paragraph near end:
"these steps are way to=C2=A0small"
"to" -> "too"
and suggest
"these steps ar= e much too small"

Fifth paragraph
"and = additiona mechanism"
try either
<= div class=3D"gmail_quote">"and an additional mechanism"
or
"and additio= nal mechanisms"

8.=C2=A0 Private KSK/ZSK
"split-zone" -> "split-view"

--=C2=A0
Bob Harold

--94eb2c05c8bed58e6d054c93eac1-- From nobody Fri Apr 7 07:21: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 BE5EB120227 for ; Fri, 7 Apr 2017 07:21:26 -0700 (PDT) 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 0kP_FXOsAAAB for ; Fri, 7 Apr 2017 07:21:23 -0700 (PDT) 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 2244A1243F3 for ; Fri, 7 Apr 2017 07:21:23 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:6c65:5aff:fea1:4735] (unknown [IPv6:2001:1488:fffe:6:6c65:5aff:fea1:4735]) by mail.nic.cz (Postfix) with ESMTPSA id 9E48B60A9C for ; Fri, 7 Apr 2017 16:21:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1491574881; bh=ItrMKXyf0/NorWtoBjy69kM+RI8j81kZXIENPZl4OjA=; h=To:From:Date; b=n8R1qTcy4FFnVtKq8CHmGi1aDtlvhHd7xo7kO5c6pJkOD0zinrmCa78ZNavVU8Lcb mP9uHiGVwHBpdhw2GqHN0mIjYCYoAam6X0SCld/6ehzIQ16WPa8S3ON3Pw8mhMEP12 du2dTeiZt6X1GJzVuBsK6E5FzRjvIBWnbPQjLAt8= To: dnsop@ietf.org References: <149080054550.26806.17675916795295413492@ietfa.amsl.com> <20170331155217.GA19647@laperouse.bortzmeyer.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Fri, 7 Apr 2017 16:21:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170331155217.GA19647@laperouse.bortzmeyer.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] I-D Action: draft-ietf-dnsop-attrleaf-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:21:27 -0000 On 31.3.2017 17:52, Stephane Bortzmeyer wrote: > On Wed, Mar 29, 2017 at 08:15:45AM -0700, > internet-drafts@ietf.org wrote > a message of 43 lines which said: > >> Title : DNS Scoped Data Through Global '_Underscore' Naming of Attribute Leaves >> Author : Dave Crocker >> Filename : draft-ietf-dnsop-attrleaf-02.txt Before I dive into it, let me state that I definitely support this work and I will be happy to re-review is as necessary. Here is my first review of the draft so it can be hopefully taken as "would it be understandable to a causal developer?" view: For me, the text is hard to follow. It took me some time to find a path through the text which explains what problem is the draft solving and how. Particular comments are divided by section. Abstract -------- To make it obvious what the draft is about, I propose following extension of the Abstract (it merely borrows one sentence from Section 3): Formally, any DNS "RR" may occur for any domain name. However some services have defined an operational convention that applies to DNS leaf nodes that have a reserved node name, beginning with an underscore. The underscore construct is used to define a semantic scope for DNS records that are associated with the parent domain. This specification explores the nature of this DNS usage and defines the "DNS Global Underscore Scoped Entry Registry" registry with IANA. The purpose of the Underscore registry is to avoid collisions resulting from the use of the same underscore-based name, for different applications. The text could probably use some more editing but I will leave this for people with a better sense of proper English :-) 1. Introduction ---------------- The introduction is all good except, in my eyes, the last paragraph: This specification discusses the underscore "attribute" enhancement, provides an explicit definition of it, and establishes an IANA registry for the highest-level reserved names that begin with _underscore; underscore-based names that are farther down the hierarchy is handled within the scope of the highest-level _underscore name. It updates the many existing specifications that have defined underscore names, in order to aggregate the references to a single IANA table. To me it seems too dense for a first-time reader who is not familiar with the concept (yet). Please let me propose an alternative: This document formally defines how underscore labels act as "attribute" enhancements for their parent domain names. E.g. domain name "_domainkey.example." acts as attribute of parent domain name "example." To avoid collisions resulting from the use of the same underscore-based labels for different applications, this document establishes DNS Global Underscore Scoped Entry IANA Registry and proposes to replace some other registries. As a result this document updates the many existing specifications that have defined underscore names, in order to aggregate the references to a single IANA registry. The main problem which remains is that the term "attribute" is not used anywhere past Section 1. Let me comment on that later. Beyond this, I think that term "RR" (including the quotes!) needs to be formally defined. Right now it is undefined and thus vague and prone to misunderstanding. See below. 2. Scaling Benefits and TXT and SRV Resource Records ----------------------------------------------------- It seems to me that this section would be easier to follow if it was split into two: 2. Explanation of the generic ambiguity of TXT records, 3. Two-level structure of SRV names as an attempt to solve it. Also, the SRV section could use an example to make it easier to follow. Right now I had to re-read it couple times to make sure I understood references to "local scope" and "global scope" etc. 3. DNS Global Underscore Scoped Entry Registry Function -------------------------------------------------------- The table in here is nice but the text in section 3 is not using values from the table "Example of Underscore Names" as commented examples. It would IMHO really help to make the text easier to follow. Here it would be beneficial to again use the notion of "attribute" which was introduced in section 1 to describe the function of the registry. 4. DNS Global Underscore Scoped Entry Registry Definition ---------------------------------------------------------- - Name: The the first glance, the "Name" field/column is really confusing as the text talks about DNS but this is not a DNS name not its part. It gets even worse when "Constraints" reference "name" because it again forces me to think twice "Is this a compound DNS name? Or just this entry in the table? If it is about row in the table, why reference to name??" To avoid all this confusion I propose to rename field "Name" to "ID" (or "Mnemonic"). IMHO it avoids the confusion. The definition of "Constraints" then needs to be updated. - RR(s): Here I refer to the previous question about RR definition. Here it is even without quotes but I believe that intended meaning is "RR type(s)". We either have to define what "RR" is or use RR types. - Purpose: Again, this refers to the undefined "RR". - DNS label: Here the term label describes what is technically label but semantically the attribute. IMHO it should be good to make this clear by referring to both on a prominent place, possibly in the column header "DNS label (attribute)". > Section 5 "IANA considerations" does not use the names of standard > policies. draft-leiba-cotton-iana-5226bis, currently in the RFC editor > queue, says "It is not strictly required that documents use these > terms [the standard policies]; the actual requirement is that the > instructions to IANA be clear and unambiguous. However, use of these > terms is strongly recommended because their meanings are widely > understood." > > Therefore, I suggest to replace "have been specified in any published > RFC, or are documented by a specification published by another > standards organization" by "specification required (RFC 5226bis, > section 4.6). I support use of "specification required (RFC 5226bis, section 4.6)." Besides other things, kitten WG is going to add couple more underscore names in this draft: https://tools.ietf.org/html/draft-ietf-kitten-krb-service-discovery-00 Ideally the Section 5 "IANA considerations" should give an example text which can be re-used in new RFCs to add new underscore labels to the registry. The kitten WG could use it right away. Hopefully this will help to make the draft easier to understand for people who do not watch dnsop. I will be happy to contribute, just let me know! -- Petr Špaček @ CZ.NIC From nobody Fri Apr 7 08:11: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 01743127333 for ; Fri, 7 Apr 2017 08:11:39 -0700 (PDT) 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 dZWCrv-TzRI4 for ; Fri, 7 Apr 2017 08:11:36 -0700 (PDT) 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 E5EC41270A0 for ; Fri, 7 Apr 2017 08:11:35 -0700 (PDT) Received: from [10.32.60.173] (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 v37FBI1v050477 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 08:11:21 -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.173] From: "Paul Hoffman" To: "=?utf-8?q?Bj=C3=B8rn?= Mork" Cc: dnsop@ietf.org Date: Fri, 07 Apr 2017 08:11:37 -0700 Message-ID: In-Reply-To: <87vaqgob3y.fsf@miraculix.mork.no> References: <87inmhrjpx.fsf@miraculix.mork.no> <2448193.4rPzoQ60ob@linux-hs2j> <1560750.L0Fn6CvLxk@linux-hs2j> <8760igpr2n.fsf@miraculix.mork.no> <20170407082326.GH17910@server.ds9a.nl> <87vaqgob3y.fsf@miraculix.mork.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:11:39 -0000 On 7 Apr 2017, at 1:50, Bjørn Mork wrote: > bert hubert writes: >> On Fri, Apr 07, 2017 at 10:20:00AM +0200, Bjørn Mork wrote: >>> Just to avoid any confusion: Although I demonstrated the issue by >>> running BIND on my laptop only, the real usage scenario is resolver >>> service for a few million distinct administrative domains (aka >>> "customers"). Changing the trust anchor is not an option. >> >> Perhaps https://lists.isc.org/mailman/listinfo/bind-users is a great >> place >> to discuss BIND configurations and issues. > > Definitely. Or even bind-workers when it comes to questions about the > reason for making static-stub zones recursive only. > > The reason I ask here first, is because RFC 7706 includes a BIND > specific configuration example (as well as examples for other > recursive > server software). So before considering changing config or code, I > wanted to know the background of that example. Was there a real reason > for the obscure(?) "static-stub" zone type, or was that just an > arbitrary choice? > > My apologies if this is considered OT here. I will shut up now. The contents of an RFC that went through this WG is not off-topic. Please do not shut up. (The fact that some people took your original message into "how to fix it in BIND" instead of your original topic is not relevant.) See the archives of this mailing list starting around November 11, 2014, in the thread titled "New Version Notification for draft-wkumari-dnsop-root-loopback-01.txt". --Paul Hoffman From nobody Fri Apr 7 09:12: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 38AC0129400 for ; Fri, 7 Apr 2017 09:12:44 -0700 (PDT) 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=tiggee.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 UolrzdemS1tV for ; Fri, 7 Apr 2017 09:12:41 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 A2330124282 for ; Fri, 7 Apr 2017 09:12:41 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id r69so80428300vke.2 for ; Fri, 07 Apr 2017 09:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tiggee.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BrpopjOpTLPswYCM5KNJ0lLklAWGHs6FJO89hSOO8Xc=; b=CrgchMEk7W841Byma0IfK4OpJDU6sUZUVYGmb/7GGlgOCu2WP4UGjtlHJUUNfxKyfK MpAgArnw1DO9bW6d/XcI004COjSux4TCtdNHBvOeH+72xvDbVogB0tmYnBY0eCUeiot6 yL3Dmh4Vdww++tJ5U508sqiBm5sRHt2SfWFkU= 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=BrpopjOpTLPswYCM5KNJ0lLklAWGHs6FJO89hSOO8Xc=; b=p2yx8FUBh2oRHWRzHXT5TBaafjnxCF8QjOkgL4/an2Z9zbya9TPKQ9S2P6TqQfaIIq JViIMVSZPAXo5s/eEeye8hhsWeOggh3kLeqjEyMOZEdUWGqLmiX1ZgPwrzYcVVCf58tx dsFGULXa41kj0iRdZXtfXls1Yd0uhRxoRUe2H53erDK0mUyOMsLjZ3dBdGoUkW9WIcAn vY/ZvvSpVEfGWV/84eodEGAvE4VmIrSC3tFra/lj7D+zs9RnqHIodlf3IajmQ/HHjEo8 k3bH8lEiOPZ+JT4KVf7doK3hwpgMSyt96Op2aVgPmihuFsP7zlAGF9cH+jLk/04N0GAo ESrg== X-Gm-Message-State: AFeK/H2BWkaZImf46gj6zqi8uZFotkIT3akGNnBlLy4fnJeEyllpH15W7cnSH6vHbg6TLQHWnwP/2RdA1G93C0jQ X-Received: by 10.159.48.221 with SMTP id k29mr21041931uab.6.1491581560574; Fri, 07 Apr 2017 09:12:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.73.132 with HTTP; Fri, 7 Apr 2017 09:12:39 -0700 (PDT) In-Reply-To: <887fdc84-cefa-97f4-3e93-c013cfea9fe7@nic.cz> References: <20170330230806.6273.qmail@ary.lan> <9232F4F4-772F-48AA-80FB-C990662AFD7A@powerdns.com> <887fdc84-cefa-97f4-3e93-c013cfea9fe7@nic.cz> From: Bryan Hughes Date: Fri, 7 Apr 2017 12:12:39 -0400 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: Matthew Pounsett , Tony Finch , dnsop , Peter van Dijk Content-Type: multipart/alternative; boundary=f403045dd180126ed3054c95e524 Archived-At: Subject: Re: [DNSOP] New draft for ALIAS/ANAME type X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:12:44 -0000 --f403045dd180126ed3054c95e524 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In many cases, DNS Made Easy is seeing ANAME records requiring synthesized A record updates every 90 seconds or so. Also, it is surprising to me that our non-apex ANAME record count has surpassed apex ANAME record count by a significant amount. We have approximately 25% fewer apex ANAME records than non-apex, however apex ANAME records account for over 75% of ANAME zone update activity. We currently process around 50,000 distinct ANAME records and we are seeing an average of 60, max of 925, and min of 0 zone updates per zone per day with an average of 1.74 synthesized A records per non-apex ANAME record and 1.41 synthesized A records per apex ANAME record. On Fri, Apr 7, 2017 at 2:44 AM, Petr =C5=A0pa=C4=8Dek = wrote: > On 4.4.2017 19:30, Matthew Pounsett wrote: > > On 4 April 2017 at 13:21, Tony Finch > > wrote: > > > > > I believe that's a faulty assumption. Here's some data: > > > > > > [...] During the month of February, [...] an average of 31 change= s > > per zone. [...] > > > > That seems to agree with what I meant, though I probably should hav= e > > said > > "per-zone" somewhere :-) > > > > That's the average, but there's a not-insignificant number there being > > updated many times per day. Most of the time, you're right, there ar= e > > few changes, but one can't assume that any given alias will have a low > > rate of change. > > Numbers, that really helps! > > If I consider the numbers above and the fact that IXFR is able to deal > even dynamically updated zones, I conclude that pushing ANAME logic to > provisioner side is reasonable approach and that added complexity in > name server itself is not warranted. > > -- > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --f403045dd180126ed3054c95e524 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In many cases, DNS Made Easy is seeing ANAME records requi= ring synthesized A record updates every 90 seconds or so. Also, it is surpr= ising to me that our non-apex ANAME record count has surpassed apex ANAME r= ecord count by a significant amount. We have approximately 25% fewer apex A= NAME records than non-apex, however apex ANAME records account for over 75%= of ANAME zone update activity. We currently process around 50,000 distinct= ANAME records and we are seeing an average of 60, max of 925, and min of 0= zone updates per zone per day with an average of 1.74 synthesized A record= s per non-apex ANAME record and 1.41 synthesized A records per apex ANAME r= ecord.=C2=A0


=
On Fri, Apr 7, 2017 at 2:44 AM= , Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> wrote:
On 4.4.2017 19:30, Matthew Poun= sett wrote:
> On 4 April 2017 at 13:21, Tony Finch <dot@dotat.at
> <mailto:dot= @dotat.at>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0> I believe that's a faulty assumption.=C2= =A0 =C2=A0Here's some data:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> [...] During the month of February, [...] an a= verage of 31 changes
>=C2=A0 =C2=A0 =C2=A0per zone. [...]
>
>=C2=A0 =C2=A0 =C2=A0That seems to agree with what I meant, though I pro= bably should have
>=C2=A0 =C2=A0 =C2=A0said
>=C2=A0 =C2=A0 =C2=A0"per-zone" somewhere :-)
>
> That's the average, but there's a not-insignificant number the= re being
> updated many times per day.=C2=A0 =C2=A0 Most of the time, you're = right, there are
> few changes, but one can't assume that any given alias will have a= low
> rate of change.

Numbers, that really helps!

If I consider the numbers above and the fact that IXFR is able to deal
even dynamically updated zones, I conclude that pushing ANAME logic to
provisioner side is reasonable approach and that added complexity in
name server itself is not warranted.

--
Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC

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

--f403045dd180126ed3054c95e524-- From nobody Fri Apr 7 10:19: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 2833512942F for ; Fri, 7 Apr 2017 10:19:36 -0700 (PDT) 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 iEiU4eaxK28q for ; Fri, 7 Apr 2017 10:19:34 -0700 (PDT) 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 8BB1B1293EC for ; Fri, 7 Apr 2017 10:19:34 -0700 (PDT) Received: from [10.32.60.173] (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 v37HJIlr056126 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 7 Apr 2017 10:19:19 -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.173] From: "Paul Hoffman" To: "dnsop WG" Date: Fri, 07 Apr 2017 10:19:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [DNSOP] Definition of "root zone" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:19:36 -0000 Greetings again. In a side conversation, we realized that the definition of "root zone" in RFC 7719 is DNS-centric, and does not apply to other domain name systems. I have opened an issue with two different proposed solutions: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/20 --Paul Hoffman From nobody Fri Apr 7 10:55: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 267D312957B for ; Fri, 7 Apr 2017 10:55:53 -0700 (PDT) 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 lJc0sCHaULUp for ; Fri, 7 Apr 2017 10:55:51 -0700 (PDT) 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 D746312956A for ; Fri, 7 Apr 2017 10:55:48 -0700 (PDT) Received: from [10.32.60.173] (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 v37HtW5g058433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 10:55:33 -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.173] From: "Paul Hoffman" To: "Mark Andrews" Cc: "Stephane Bortzmeyer" , dnsop@ietf.org Date: Fri, 07 Apr 2017 10:55:52 -0700 Message-ID: <02133DF7-5EE0-4064-9739-C7313B3E8F5B@vpnc.org> In-Reply-To: <20170404183525.2B15A6A8A07B@rock.dv.isc.org> References: <148942077219.17007.342057944218385620@ietfa.amsl.com> <20170328143352.GA12923@laperouse.bortzmeyer.org> <20170404183525.2B15A6A8A07B@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:55:53 -0000 On 4 Apr 2017, at 11:35, Mark Andrews wrote: > In message <20170328143352.GA12923@laperouse.bortzmeyer.org>, Stephane > Bortzmeyer writes: >> The new definition of QNAME describes as equivalent two conflicting >> definitions, the original one, in RFC 1034, and the one of RFC 2308, >> which seems used only by this RFC. IMHO, we should keep only the RFC >> 1034 definition. As noted in the current draft, RFC 1034 says: A standard query specifies a target domain name (QNAME), query type (QTYPE), and query class (QCLASS) and asks for RRs which match. To me, the use of appositives for QNAME, QTYPE, and QCLASS gives them definitions. RFC 1034 also says: The query contains a QTYPE, QCLASS, and QNAME, which describe the types and classes of desired information and the name of interest. > RFC 1034 > > If the data at the node is a CNAME, and QTYPE doesn't > match CNAME, copy the CNAME RR into the answer section > of the response, change QNAME to the canonical name in > the CNAME RR, and go back to step 1. > > Note "QNAME" refers the the name *after* CNAME substituion when you > are following the process as described in 4.3.2. Algorithm. This is indeed the definition of the algorithm, not of the terms. But RFC 1034 says that the algorithm is not definitive: "The actual algorithm used by the name server will depend on the local OS and data structures used to store RRs." > There is no confict between 1034 and 2308. Only a failure to > examine all uses of QNAME in 1034. We disagree here. RFC 2038 defines QNAME as: "...the name in the query section of an answer, or where this resolves to a CNAME, or CNAME chain, the data field of the last CNAME." That definition is derived from the optional algorithm. --Paul Hoffman From nobody Fri Apr 7 10:57: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 082AF1296D6 for ; Fri, 7 Apr 2017 10:57:06 -0700 (PDT) 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 SNyAHu5CGM-d for ; Fri, 7 Apr 2017 10:57:03 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C751296D3 for ; Fri, 7 Apr 2017 10:57:00 -0700 (PDT) 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]:42766) 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 1cwY81-000QaU-1l (Exim 4.89) (return-path ); Fri, 07 Apr 2017 18:56:57 +0100 Date: Fri, 7 Apr 2017 18:56:57 +0100 From: Tony Finch To: =?UTF-8?Q?Bj=C3=B8rn_Mork?= cc: dnsop@ietf.org In-Reply-To: <87vaqgob3y.fsf@miraculix.mork.no> Message-ID: References: <87inmhrjpx.fsf@miraculix.mork.no> <2448193.4rPzoQ60ob@linux-hs2j> <1560750.L0Fn6CvLxk@linux-hs2j> <8760igpr2n.fsf@miraculix.mork.no> <20170407082326.GH17910@server.ds9a.nl> <87vaqgob3y.fsf@miraculix.mork.no> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-2061162964-1491587817=:13590" Archived-At: Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:57:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870841-2061162964-1491587817=:13590 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Bj=C3=B8rn Mork wrote: > > The reason I ask here first, is because RFC 7706 includes a BIND > specific configuration example (as well as examples for other recursive > server software). So before considering changing config or code, I > wanted to know the background of that example. Was there a real reason > for the obscure(?) "static-stub" zone type, or was that just an > arbitrary choice? The choice between "forward" and "static-stub" depends on whether the target server offers recursive service or not. If it doesn't, then a BIND resolver that is forwarding to the server can produce the wrong results, because it is expecting a fully-resolved answer but doesn't get one. It's a lot simpler to have a local copy of the root zone without any of the view trickery, but then the resolver trusts the zone contents without verifying them. I think that if you are doing this on a production server, it would be better to have external scripting to fetch and verify the root zone so you can be sure you don't have an outage because the transfer got corrupted. Tony. --=20 f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Rockall, Malin, Hebrides: West or southwest 5 or 6, occasionally 7 except i= n Malin. Moderate or rough, occasionally very rough in north Hebrides. Occasional rain or drizzle. Good, occasionally moderate. --1870870841-2061162964-1491587817=:13590-- From nobody Fri Apr 7 10:58: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 27C951296DB for ; Fri, 7 Apr 2017 10:58:12 -0700 (PDT) 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 gtQnZmq2kFC3 for ; Fri, 7 Apr 2017 10:58:10 -0700 (PDT) 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 A639D1296CE for ; Fri, 7 Apr 2017 10:57:59 -0700 (PDT) Received: from [10.32.60.173] (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 v37HviEu058480 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 10:57:45 -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.173] From: "Paul Hoffman" To: "Peter van Dijk" Cc: dnsop@ietf.org Date: Fri, 07 Apr 2017 10:57:57 -0700 Message-ID: <88FAB370-FFE4-4E90-9B31-651C09798983@vpnc.org> In-Reply-To: References: <148942077219.17007.342057944218385620@ietfa.amsl.com> <20170328143352.GA12923@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:58:12 -0000 On 4 Apr 2017, at 23:57, Peter van Dijk wrote: > Notwithstanding your stubborn redefinition in 8020, the text in 2308 > is correct and this erratum is wrong. That "stubborn redefinition" has modern WG and IETF consensus. --Paul Hoffman From nobody Fri Apr 7 11:11: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 3F071128C82 for ; Fri, 7 Apr 2017 11:11:45 -0700 (PDT) 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 Iz32PipRYYvC for ; Fri, 7 Apr 2017 11:11:43 -0700 (PDT) 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 44600124234 for ; Fri, 7 Apr 2017 11:11:43 -0700 (PDT) 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 E2B993493EF for ; Fri, 7 Apr 2017 18:11:39 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id D6B81216C1E; Fri, 7 Apr 2017 18:11:39 +0000 (UTC) Date: Fri, 7 Apr 2017 18:11:39 +0000 From: Evan Hunt To: dnsop@ietf.org Message-ID: <20170407181139.GB66383@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] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 18:11:45 -0000 Greetings, Here's the new ANAME draft I mentioned last week. This is similar to existing non-standard approaches (ALIAS records, CNAME-flattening, etc) but also sends the ANAME record to the resolver so that, if the resolver understands the ANAME type, it can re-query for the answer just as it would with a CNAME. Please have at it. ----- Forwarded message from internet-drafts@ietf.org ----- From: internet-drafts@ietf.org To: Evan Hunt , Peter van Dijk , Anthony Eden Subject: New Version Notification for draft-hunt-dnsop-aname-00.txt Date: Fri, 07 Apr 2017 11:04:39 -0700 A new version of I-D, draft-hunt-dnsop-aname-00.txt has been successfully submitted by Evan Hunt and posted to the IETF repository. Name: draft-hunt-dnsop-aname Revision: 00 Title: Address-specific DNS Name Redirection (ANAME) Document date: 2017-04-07 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-hunt-dnsop-aname-00.txt Status: https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ Htmlized: https://tools.ietf.org/html/draft-hunt-dnsop-aname-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hunt-dnsop-aname-00 Abstract: This document defines the "ANAME" DNS RR type, to provide similar functionality to CNAME, but only redirects type A and AAAA queries. Unlike CNAME, an ANAME can coexist with other record types. The ANAME RR allows zone owners to redirect queries for apex domain names in a standards compliant manner. 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 forwarded message ----- -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Fri Apr 7 11:24: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 1EC89128C82 for ; Fri, 7 Apr 2017 11:24:26 -0700 (PDT) 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=instituut-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 xqX4BNfA5bkO for ; Fri, 7 Apr 2017 11:24:23 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 51B8012702E for ; Fri, 7 Apr 2017 11:24:23 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id w204so1024350wmd.1 for ; Fri, 07 Apr 2017 11:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=BCeacwHSVinUPgI1a7wp8C1KZlEDtCpZ1A+9gI1XiY4=; b=QkZetltb41SXbQNaRIPc5BYlGh2FBfdWlpJ2amJo1XjczZSmjSs5SJeLim/8fphMr/ xSXIwzIv38vHC/NKJTRAreppmazhc5Ir/W7zMVpbQ8YhjozWisw550ioARB4puJxV93j ZFX4t9EYbtpp9srCNaLSUo7xIYCDs2TdkWyXoCyE169jQK9tc076aCU3flejYd44IYWc hYklg1T5Z9IjZbpHd+3AtbHEckapvRieGtgeAll/Fm2jRmrKva86xMR4R/02+H7XYWxi k1PPIgFxtQIJPVtXrAyF36bgztMJKN4sx0MRO1OFAYEfzCuwsKv1NPC0aaOwSI99oB/r V+yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=BCeacwHSVinUPgI1a7wp8C1KZlEDtCpZ1A+9gI1XiY4=; b=kBpqEkELij2j0MrTuBk3nbs8GEvmTGtsDjYSpkPpDiMPtCJVc2kEFuvdI9adtSqJaT x+Xl2VQU/2Z4ctw/eXL8sjB07u48qKoypkT9oMG453M5PvENEZCKhYwppUk/ePj9+gg3 j3dJN7ylquUcIbF2xb7MNN8QDr4B2vz+BoJPGIx3jGHFVtgUcnI+KFdFchU0HBgiWqTq 71btQX01spIz3ji3D2fdoHcyLp8TqRtj5GKWMlkctm085sk7nJB3nKsBOGSq28jMpxyZ zxuW2ZUbMI+AYS3PM2RswROE02MHvszetXNxVPP3JkVC4HzEIjwwKdAgPfsWTV491ctF fRuw== X-Gm-Message-State: AN3rC/49w6cgjrOgK76gUCLK4un07dcyQHL8AXLjMCQ7GcMwOMwOcXh5 nqfY2azx9sAWEav3cjA= X-Received: by 10.28.29.138 with SMTP id d132mr580288wmd.40.1491589461659; Fri, 07 Apr 2017 11:24:21 -0700 (PDT) Received: from localhost ([192.147.168.22]) by smtp.gmail.com with ESMTPSA id y22sm6903075wry.51.2017.04.07.11.24.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 11:24:20 -0700 (PDT) Date: Fri, 7 Apr 2017 20:24:19 +0200 From: Job Snijders To: Evan Hunt Cc: dnsop@ietf.org Message-ID: <20170407182419.fdp2s65zi5b2t6io@Vurt.local> References: <20170407181139.GB66383@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170407181139.GB66383@isc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 18:24:26 -0000 Dear Evan & Authors, Can you add a RFC 7942 section to this document? Pending an IANA Early Allocation, I expect these implementations to be residing in private / beta branches until a DNS RR data type value has been assigned. I think it will be beneficial for the working group dialogue to have an overview of running code. Kind regards, Job On Fri, Apr 07, 2017 at 06:11:39PM +0000, Evan Hunt wrote: > Greetings, > > Here's the new ANAME draft I mentioned last week. > > This is similar to existing non-standard approaches (ALIAS records, > CNAME-flattening, etc) but also sends the ANAME record to the resolver so > that, if the resolver understands the ANAME type, it can re-query for the > answer just as it would with a CNAME. > > Please have at it. > > ----- Forwarded message from internet-drafts@ietf.org ----- > > From: internet-drafts@ietf.org > To: Evan Hunt , Peter van Dijk , > Anthony Eden > Subject: New Version Notification for draft-hunt-dnsop-aname-00.txt > Date: Fri, 07 Apr 2017 11:04:39 -0700 > > A new version of I-D, draft-hunt-dnsop-aname-00.txt > has been successfully submitted by Evan Hunt and posted to the > IETF repository. > > Name: draft-hunt-dnsop-aname > Revision: 00 > Title: Address-specific DNS Name Redirection (ANAME) > Document date: 2017-04-07 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-hunt-dnsop-aname-00.txt > Status: https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ > Htmlized: https://tools.ietf.org/html/draft-hunt-dnsop-aname-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-hunt-dnsop-aname-00 > > > Abstract: > This document defines the "ANAME" DNS RR type, to provide similar > functionality to CNAME, but only redirects type A and AAAA queries. > Unlike CNAME, an ANAME can coexist with other record types. The > ANAME RR allows zone owners to redirect queries for apex domain names > in a standards compliant manner. > > 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 forwarded message ----- > > -- > Evan Hunt -- each@isc.org > Internet Systems Consortium, Inc. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri Apr 7 11:40: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 DC99B12420B for ; Fri, 7 Apr 2017 11:40:08 -0700 (PDT) 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 gYzBQvEK3Zjn for ; Fri, 7 Apr 2017 11:40:04 -0700 (PDT) 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 4705C1289B5 for ; Fri, 7 Apr 2017 11:39:57 -0700 (PDT) Received: from [10.32.60.173] (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 v37IdeN6059613 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 11:39:41 -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.173] From: "Paul Hoffman" To: dnsop@ietf.org Cc: "Andrew McConachie" Date: Fri, 07 Apr 2017 11:39:53 -0700 Message-ID: In-Reply-To: <3055f4dc-900c-0a5a-aba4-4a6034b366b8@depht.com> References: <148942077219.17007.342057944218385620@ietfa.amsl.com> <3055f4dc-900c-0a5a-aba4-4a6034b366b8@depht.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 18:40:09 -0000 (I'm surprised our philosophy-minded folks didn't answer this. I'll take = a stab, acknowledging that I'm only a philosophy tourist.) On 30 Mar 2017, at 13:41, Andrew McConachie wrote: > If a domain name is made up of labels, and labels are made up of = > octets, then can there be non-digital representations of domain names? Yes. The octets in the labels can be encoded into writing systems, and = there can be a commonly-recognized display format for the representation = of a group of labels. > For example, if I spray paint 'www.example' on the side of a bus, is = > it not a domain name because it is made up of paint instead of octets? It is a rendering (in paint, on a bus) a domain name in a = commonly-accepted display format. Neither the paint nor the bus is the = domain name. Some history related to representation versus essence: = https://essenceofbuddhism.wordpress.com/2016/04/19/what-the-finger-pointi= ng-to-the-moon-analogy-really-means-from-zen-buddhism-the-buddha-in-the-s= hurangama-sutra/ > I don't see anything in this document restricting the terms to 'on the = > wire' definitions. So I assume that the scope of 'domain name' = > includes non-digital instantiations. Perhaps what's needed isn't so = > much a new definition for label, but clarification on the scope of = > these terms and their definitions. I'm not sure that us going into the ontology of domain names would help = someone reading the document. --Paul Hoffman From nobody Fri Apr 7 11:45: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 F40461200C1 for ; Fri, 7 Apr 2017 11:45:08 -0700 (PDT) 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 lzG6FB4Z462z for ; Fri, 7 Apr 2017 11:45:07 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0629129531 for ; Fri, 7 Apr 2017 11:45:04 -0700 (PDT) Received: from [192.168.7.93] (104-7-65-172.lightspeed.sntcca.sbcglobal.net [104.7.65.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 83E8161F9C; Fri, 7 Apr 2017 18:45:02 +0000 (UTC) Message-ID: <58E7DE17.9020200@redbarn.org> Date: Fri, 07 Apr 2017 11:44:39 -0700 From: Paul Vixie User-Agent: Postbox 5.0.12 (Windows/20170323) MIME-Version: 1.0 To: Paul Hoffman CC: Peter van Dijk , dnsop@ietf.org References: <148942077219.17007.342057944218385620@ietfa.amsl.com> <20170328143352.GA12923@laperouse.bortzmeyer.org> <88FAB370-FFE4-4E90-9B31-651C09798983@vpnc.org> In-Reply-To: <88FAB370-FFE4-4E90-9B31-651C09798983@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 18:45:09 -0000 Paul Hoffman wrote: > On 4 Apr 2017, at 23:57, Peter van Dijk wrote: > >> Notwithstanding your stubborn redefinition in 8020, the text in 2308 >> is correct and this erratum is wrong. > > That "stubborn redefinition" has modern WG and IETF consensus. well, yes, but, it's still wrong. -- P Vixie From nobody Fri Apr 7 11:54: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 0D52912704B for ; Fri, 7 Apr 2017 11:54:34 -0700 (PDT) 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 uyWlgV8dZmgD for ; Fri, 7 Apr 2017 11:54:32 -0700 (PDT) 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 0831912420B for ; Fri, 7 Apr 2017 11:54:32 -0700 (PDT) Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:f021:3c9d:c1a0:9cfd]) (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 D465CC5C40; Fri, 7 Apr 2017 20:54:28 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Fri, 07 Apr 2017 20:54:29 +0200 Message-ID: In-Reply-To: <20170407182419.fdp2s65zi5b2t6io@Vurt.local> References: <20170407181139.GB66383@isc.org> <20170407182419.fdp2s65zi5b2t6io@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 18:54:34 -0000 Hi Job, On 7 Apr 2017, at 20:24, Job Snijders wrote: > Dear Evan & Authors, > > Can you add a RFC 7942 section to this document? Absolutely, we’ll do that in -01. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Fri Apr 7 13:47: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 A46B31205F0 for ; Fri, 7 Apr 2017 13:47:38 -0700 (PDT) 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 rXcbs0Fv6-Hm for ; Fri, 7 Apr 2017 13:47:37 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA07F124BFA for ; Fri, 7 Apr 2017 13:47:34 -0700 (PDT) Received: from linux-hs2j.localnet (104-7-65-172.lightspeed.sntcca.sbcglobal.net [104.7.65.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 9C0B361F9C; Fri, 7 Apr 2017 20:47:33 +0000 (UTC) From: Paul Vixie To: dnsop@ietf.org Date: Fri, 07 Apr 2017 20:47:32 +0000 Message-ID: <1604073.dShiJmyce8@linux-hs2j> Organization: Vixie Freehold MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [DNSOP] Workshop on Passive DNS -- Atlanta, GA -- May 4 (13:00) to May 5 (12:00), 2017 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 20:47:38 -0000 Workshop on Passive DNS -- Atlanta, GA -- May 4 (13:00) to May 5 (12:00), 2017 Cox Communications and Farsight Security invite members of the DNS community to join a two-halfday workshop to be held in Atlanta, GA from mid-day Thursday May 4 until mid-day Friday May 5, including dinner on May 4. Short papers are welcome, as are oral histories, demonstrations, and even slideware. This will be a highly interactive workshop, with about the time allocated to focused group discussion and Q&A. Venue capacity is about 25 participants, with accepted speakers and discussion leaders having priority. We'll start after lunch on Thursday, breaking at 18:00 for dinner, then continue from 09:00 to 12:00 on Friday. Farsight will sponsor dinner and cookies; lunch will be available in the Cox cafeteria. Ideal topics include: collection, transmission, sharing, storage, indexing, use cases, applications, performance, privacy, anonymization, law, policy, and business models. Programme Committee: Paul Vixie, Farsight Matt Carothers, Cox David Dagon, GaTech Deadlines: proposals (title and abstract) by speakers and expressions of interest by non-speakers are due 2017-04-16T23:59:59Z; notices and invitations will be sent out by 2017-04-23T23:59:59Z. Submissions in plain text (no MIME/DOC/PPT please): pdns-pc@tisf.net From nobody Fri Apr 7 14:17: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 D071E127B5A for ; Fri, 7 Apr 2017 14:16:53 -0700 (PDT) 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 cgQH5XWQYtid for ; Fri, 7 Apr 2017 14:16:31 -0700 (PDT) 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 88850127867 for ; Fri, 7 Apr 2017 14:16:19 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w0C754tFKzDRF; Fri, 7 Apr 2017 23:16:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491599777; bh=e2qYiuqH0eyLDebFePNTSu9i8bvSbBnaJ3Qopt3eXKI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=oroa4xpKelK3I4h8yCgRprOw8IT43S0j3OR9j0vVq4h/6AZr6n/4fddPLxAD0BzSI jnp7LcfC80csDfYx9bJwg9kibpXfuF53cpyy5QwaSfpdkX8sZPVywj7TQeEvCv4tuo qTPWhr9lz5Wgx/+j/WwvlpbaUQlYyOLzaFiRrh1M= 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 vCR2-LLtISXz; Fri, 7 Apr 2017 23:16:15 +0200 (CEST) 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; Fri, 7 Apr 2017 23:16:15 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7D1D0559948; Fri, 7 Apr 2017 17:16:14 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7D1D0559948 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7740B410929C; Fri, 7 Apr 2017 17:16:14 -0400 (EDT) Date: Fri, 7 Apr 2017 17:16:14 -0400 (EDT) From: Paul Wouters To: Evan Hunt cc: dnsop@ietf.org In-Reply-To: <20170407181139.GB66383@isc.org> Message-ID: References: <20170407181139.GB66383@isc.org> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 21:16:54 -0000 On Fri, 7 Apr 2017, Evan Hunt wrote: > Here's the new ANAME draft I mentioned last week. I like this one a little better, but :) When an ANAME record is present at a DNS node and a query is received by an authoritative server for type A or AAAA, the authoritative server returns the ANAME RR in the answer section. This is good, then it goes on with: Because not all querying resolvers understand ANAME, the authoritative server MUST also return address records, as described below. [...] Authoritative servers implementing ANAME MUST be equipped to resolve the ANAME on the querying resolver's behalf, either by sending queries to an external recursive resolver or by implementing recursive resolution logic internally, so that address records can be expanded when the ANAME is in a separate zone from . I guess I'm still not a fan of the AUTH server doing this. Moreover: When a recursive resolver sends a query of type A or AAAA and receives a response with an ANAME RRset in the answer section, it MUST re-query for the ANAME . This is necessary because, in some cases, the address received will be dependent on network topology and other considerations, and the resolver may find a different answer than the authoritative server did. That opens up a whole can of worms :P We start with the problem of "we need addresses at the APEX be non-static, but then you add logic to support that and then it is not good enough for the job. AUTH servers already know how to return split view answers with various implementations based on geolocation, edns-subnet or what not. Also, a resolver support ANAME sending a query to a forwarding resolver might only receive the ANAME record back without anything else, and then has to do all the ANAME chasing itself anyway. So why not just always do that behaviour? So why not happy eyeball ANAME along with A/AAAA queries. Old stuff gets somewhat risky and possibly outdated A/AAAA records, and newer clients get the proper redirection. But really, what it comes down to for me is that if you are adding logic to the AUTH nameservers to synthesize ANAME into A/AAAA records, why bother ever sending ANAME over the wire? Just let clients send A/AAAA and never ask for ANAME. And have the AUTH server code that sees an ANAME in the zone at the place of the QNAME for A/AAAA synthesize by doing the queries. Paul From nobody Fri Apr 7 15:47: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 02E2112714F for ; Fri, 7 Apr 2017 15:47:52 -0700 (PDT) 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 bSQjniZ--wgp for ; Fri, 7 Apr 2017 15:47:48 -0700 (PDT) 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 2189912420B for ; Fri, 7 Apr 2017 15:47:19 -0700 (PDT) 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 C85E53493E2; Fri, 7 Apr 2017 22:47:16 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id BB630216C1E; Fri, 7 Apr 2017 22:47:16 +0000 (UTC) Date: Fri, 7 Apr 2017 22:47:16 +0000 From: Evan Hunt To: Paul Wouters Cc: dnsop@ietf.org Message-ID: <20170407224716.GB33435@isc.org> References: <20170407181139.GB66383@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 22:47:52 -0000 Hi Paul, On Fri, Apr 07, 2017 at 05:16:14PM -0400, Paul Wouters wrote: > When a recursive resolver sends a query of type A or AAAA and > receives a response with an ANAME RRset in the answer section, it > MUST re-query for the ANAME . This is necessary because, in > some cases, the address received will be dependent on network > topology and other considerations, and the resolver may find a > different answer than the authoritative server did. > > That opens up a whole can of worms :P We start with the problem of > "we need addresses at the APEX be non-static, but then you add logic > to support that and then it is not good enough for the job. AUTH servers > already know how to return split view answers with various > implementations based on geolocation, edns-subnet or what not. The hope here is that, in the long run, ANAME resolution would be the job of the resolver, which in in a position to get the best answer for its clients, given geolocation and topology considerations. Expansion of ANAME on the authoritative end is a workaround for the fact that we can't go back in time and put ANAME support into all the resolvers. > But really, what it comes down to for me is that if you are adding logic > to the AUTH nameservers to synthesize ANAME into A/AAAA records, why bother > ever sending ANAME over the wire? Just let clients send A/AAAA and never > ask for ANAME. Resolvers don't ask for ANAME. They ask for A/AAAA, and get an A/AAAA answer, along with an ANAME record so they can go directly to the source and get a better answer if they support that. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Fri Apr 7 16:36: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 B2919128DE7 for ; Fri, 7 Apr 2017 16:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 5K2BYWxSfLzw for ; Fri, 7 Apr 2017 16:35:39 -0700 (PDT) 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 B8914129451 for ; Fri, 7 Apr 2017 16:35:30 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id s141so13483135lfe.3 for ; Fri, 07 Apr 2017 16:35:30 -0700 (PDT) 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=HKk8HcR3fx/2Tnh0fJ24dvOq1ZTtbDPTD4T4i4ydq20=; b=HPHGXyJs0b2IN0ciI1RTJN7rhA/AeM5bvIjHDY760B5pnZiSxk4hGz/fHA8IPdPRRJ QNsB4XJBT3YvleGWt0QgqYN1N8/1T5akD7wosu8uv3zZPzvGGeZg9BfuuJlHVMKdn5sS yny9n03PBL8jAZRotuTWJFm29GtcApB4pfa8ItIJVgaoe0M+i1C90Nl4meEbEjk/7+iO mgucTnlzfK1+f8AbKm9Ittht0AnH/cdATkg8HcbyF5yjMFHHOvFB2ZCFSm0QmylrJr/6 7gbU053Ar/r1igbObFm9qet8/zMrKgdRkpxAUfgwo7/qNwDZW1YhCIoulNETQwTCzk20 oJ3Q== 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=HKk8HcR3fx/2Tnh0fJ24dvOq1ZTtbDPTD4T4i4ydq20=; b=P9JMsjdix/58QkYJB5drMG02iYnuFros4qk8SHU8jxkBE4FjdzAFLqJjKc9vz0Gbdk tDM+edZ0v8doYPPfYumv2I5168v12vefS1CL0XfEkWNROu3eTwON6InEd7B4q7J+IHA2 5l8Cuk9hHbXFU+fxvlcN99vUU2K+JxlehKcb3Prr9kEPSsDeq11g2gRnD44Y0TcDtwBn 2dzFRnwtNKIn2C+gONhdr7fYjBxdaO5bY0xWwkP1ST66FY9U99AKPyHBr1YMUUsydbWG h/Q2Sv+8yfG4A+WIHpFCjij2X+tpCm0JIXRnAMlI6lq5Xx9R/Bta4s3FcpGrYPxGouOZ tJyQ== X-Gm-Message-State: AFeK/H1n6zBiHAE4OZF6CDX9vfUIbT9dFgejyNWR1iFP9T2q6O00HKuaN5vmS4Zj68qOQugBa0VuXWfa/wHegQ== X-Received: by 10.46.21.94 with SMTP id 30mr13196901ljv.118.1491608129086; Fri, 07 Apr 2017 16:35:29 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Fri, 7 Apr 2017 16:35:28 -0700 (PDT) In-Reply-To: References: <149062396899.30595.6360166634187605799.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB74CA@eusaamb107.ericsson.se> From: Daniel Migault Date: Fri, 7 Apr 2017 19:35:28 -0400 X-Google-Sender-Auth: jafQZ7T5HSEt9rU7ebgIneoVZD0 Message-ID: To: Bob Harold Cc: dnsop Content-Type: multipart/alternative; boundary=94eb2c1cda68adab00054c9c1475 Archived-At: Subject: Re: [DNSOP] FW: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 23:35:55 -0000 --94eb2c1cda68adab00054c9c1475 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the review, I will update the copy on the git accordingly. Yours, Daniel On Fri, Apr 7, 2017 at 9:51 AM, Bob Harold wrote: > > On Mon, Mar 27, 2017 at 10:16 AM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi, >> >> Please find an update of our draft on requirements for DNSSEC resolver. >> >> DNS resolvers hardly enable DNSSEC as 1) resolvers are not robust too DN= S >> authoritative operations =E2=80=93 like KSK roll over, signing errors=E2= =80=A6. =E2=80=93 and 2) >> network administrators have little control on these resolvers to recover >> such situations. >> >> The draft describes how invalid DNSSEC related RRsets may be considered >> by the resolver. The listed requirements aim at designing mechanisms as >> well as interactions with network managers can easily solve/avoid these >> situations. Such mechanisms are expected to encourage DNSSEC deployment = on >> resolvers. >> >> Yours, >> Daniel >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, March 27, 2017 9:13 AM >> To: Edward Lewis ; Daniel Migault < >> daniel.migault@ericsson.com>; Dan York ; york@isoc.org < >> york@isoc.org> >> Subject: New Version Notification for draft-mglt-dnsop-dnssec-valida >> tor-requirements-04.txt >> >> >> A new version of I-D, draft-mglt-dnsop-dnssec-valida >> tor-requirements-04.txt >> has been successfully submitted by Daniel Migault and posted to the IETF >> repository. >> >> Name: draft-mglt-dnsop-dnssec-validator-requirements >> Revision: 04 >> Title: DNSSEC Validators Requirements >> Document date: 2017-03-27 >> Group: Individual Submission >> Pages: 10 >> URL: https://www.ietf.org/internet- >> drafts/draft-mglt-dnsop-dnssec-validator-requirements-04.txt >> Status: https://datatracker.ietf.org/ >> doc/draft-mglt-dnsop-dnssec-validator-requirements/ >> Htmlized: https://tools.ietf.org/html/d >> raft-mglt-dnsop-dnssec-validator-requirements-04 >> Htmlized: https://datatracker.ietf.org/ >> doc/html/draft-mglt-dnsop-dnssec-validator-requirements-04 >> Diff: https://www.ietf.org/rfcdiff? >> url2=3Ddraft-mglt-dnsop-dnssec-validator-requirements-04 >> >> Abstract: >> DNSSEC provides data integrity and authentication for DNSSEC >> validators. However, without valid trust anchor(s) and an acceptable >> value for the current time, DNSSEC validation cannot be performed. >> This document lists the requirements to be addressed so resolvers can >> have DNSSEC validation can be always-on. >> > > A few minor sugguestions: > > The last part of the abstract > "can have DNSSEC validation can be always-on" > remove the last 'can' to get: > "can have DNSSEC validation be always-on" > > 2. Introduction Second paragraph ends: "and then most of the > communications relying on the DNS resolution." I would suggest "thus > disabling the communications relying on the DNS resolution." > > Fourth paragraph starts: > "The lake of management" > "lake" -> "lack" > > Fourth paragraph near end: > "these steps are way to small" > "to" -> "too" > and suggest > "these steps are much too small" > > Fifth paragraph > "and additiona mechanism" > try either > "and an additional mechanism" > or > "and additional mechanisms" > > 8. Private KSK/ZSK > "split-zone" -> "split-view" > > -- > Bob Harold > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --94eb2c1cda68adab00054c9c1475 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the review, I will update the copy on= the git accordingly.

Yours,
Daniel

On Fri, Apr 7, 2017 at = 9:51 AM, Bob Harold <rharolde@umich.edu> wrote:

On Mon, Mar 27, 2017 at 10:16= AM, Daniel Migault <daniel.migault@ericsson.com> = wrote:
Hi,

Please find an update of our draft on requirements for DNSSEC resolver.

DNS resolvers hardly enable DNSSEC as 1) resolvers are not robust too DNS a= uthoritative operations =E2=80=93 like KSK roll over, signing errors=E2=80= =A6. =E2=80=93 and 2) network administrators have little control on these r= esolvers to recover such situations.

The draft describes how invalid DNSSEC related RRsets may be considered by = the resolver. The listed requirements aim at designing mechanisms as well a= s interactions with network managers can easily solve/avoid these situation= s. Such mechanisms are expected to encourage DNSSEC deployment on resolvers= .

Yours,
Daniel

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, March 27, 2017 9:13 AM
To: Edward Lewis <edward.lewis@icann.org>; Daniel Migault <daniel.migault@ericsson.com<= /a>>; Dan York <yo= rk@isoc.org>; yor= k@isoc.org <york@= isoc.org>
Subject: New Version Notification for draft-mglt-dnsop-dnssec-validato= r-requirements-04.txt


A new version of I-D, draft-mglt-dnsop-dnssec-validator-requirements-0= 4.txt
has been successfully submitted by Daniel Migault and posted to the IETF re= pository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mglt-dnsop-dnssec-valid= ator-requirements
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNSSEC Validators Requirements
Document date:=C2=A0 2017-03-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-mglt-dnsop-dnssec-validator-requirements-04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mglt-dnsop= -dnssec-validator-requirements/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mglt-dnsop-dnssec-valid= ator-requirements-04
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mgl= t-dnsop-dnssec-validator-requirements-04
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-mglt-dnsop-dnssec-validator-requirements-04

Abstract:
=C2=A0 =C2=A0DNSSEC provides data integrity and authentication for DNSSEC =C2=A0 =C2=A0validators.=C2=A0 However, without valid trust anchor(s) and a= n acceptable
=C2=A0 =C2=A0value for the current time, DNSSEC validation cannot be perfor= med.
=C2=A0 =C2=A0This document lists the requirements to be addressed so resolv= ers can
=C2=A0 =C2=A0have DNSSEC validation can be always-on.
=
A few minor sugguestions:

=C2=A0The last part of the abstract=C2=A0
&qu= ot;can have DNSSEC validation can be always-on"
remove the last 'can' to get:
"can have DNSSEC validation be always-on"
=

2. Introduction Second paragraph ends: "and then most of the communications relying on the DNS resolution.&qu= ot; I would suggest "thus disabling the communications relying on the DNS resolution."= ;

Fourth paragraph starts:
"The lake of management"
&quo= t;lake" -> "lack"

Fourth paragraph near end:
"these steps are way to=C2=A0small"
"to" -> "too"
and suggest
"these steps ar= e much too small"

Fifth paragraph
"and = additiona mechanism"
try either
<= div class=3D"gmail_quote">"and an additional mechanism"
or
"and additio= nal mechanisms"

8.=C2=A0 Private KSK/ZSK
"split-zone" -> "split-view"

--=C2=A0
Bob Harold


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


--94eb2c1cda68adab00054c9c1475-- From nobody Sat Apr 8 06:23: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 170CF129432 for ; Sat, 8 Apr 2017 06:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=depht-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 dSom6vwHgHLO for ; Sat, 8 Apr 2017 06:23:54 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 3CB54129422 for ; Sat, 8 Apr 2017 06:23:54 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id c55so50300815wrc.3 for ; Sat, 08 Apr 2017 06:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=depht-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=jQF5dgySTjT3vTQgKDw68+Mva23RZKUkbytSXIVkaa4=; b=tOI8shnix2mrMB0bk7nSbEEMjFrC583O5VciJhYfEBdTceJNIrYZy4iQ0bCHyNouRa 6MeILNhUGvLyba5Tta46wt+MQOPG2qj+q6eETcUHUkwv8iZeS0bWf3d6Dej40SLd4HSk RG6oHakiU4+STGBRo8F+20F5kZ9sLd23iV/5oNlFSUZsOWjyBqgQSUn6BY4Mne98gHB6 //4HpScjI068TnzA3yU+NqWx/mq/p4q5d7XwLio149cM21qyj8alx33jn7iV461z8hP7 OlMcmgXm6L19+kEiQZBz4cUO1d5BS+nkzH8AXo9M/YHmT4/+WbtNH0fIwT+uVAq/xSr4 NChg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=jQF5dgySTjT3vTQgKDw68+Mva23RZKUkbytSXIVkaa4=; b=rXkQg/5gmwGbVCybxyWZJsjif3bDOvWW6JU3ODFbSLpoMdr19g9k0zqAGdoR0IC7Os MR7si+yGOn5GaBnDgmIeZycWn89uLow4prsnkaBwePJF/qRWmxsemhwpDNuC/w/yHtDA pbZcuYlMHnRj5v4zhDtJJT/0TPRMnXc2+GVwqvDwxGCW3Rx9jDPxQE7lKYWf2qnjRJt6 rRjvqZnGWBkjnYSBHwvjVJQGW7H8OZRgGmmx0oXnSSZI4BOpKBMfwo2CSxNqsnDPx8l4 xPXnhfiGqnPOw1kKy15NBkfCsNk1xnsbngN5d9LHAReHGUUXa75+UDw5yLULNIx8QSU2 tihw== X-Gm-Message-State: AFeK/H1lPe2Emt7ZpuENdhoKwtKC6UlXVZ11NULFmuL5i6HU3vr+op5D1m4uBS27Tx9wqA== X-Received: by 10.223.165.66 with SMTP id j2mr41639893wrb.157.1491657832336; Sat, 08 Apr 2017 06:23:52 -0700 (PDT) Received: from anmc-3678.home (ip51cc02c5.adsl-surfen.hetnet.nl. [81.204.2.197]) by smtp.gmail.com with ESMTPSA id p38sm9900504wrb.31.2017.04.08.06.23.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 06:23:51 -0700 (PDT) To: Paul Hoffman , dnsop@ietf.org References: <148942077219.17007.342057944218385620@ietfa.amsl.com> <3055f4dc-900c-0a5a-aba4-4a6034b366b8@depht.com> From: Andrew McConachie Message-ID: <172223db-8ce3-4410-2b0a-f5d391e34a0e@depht.com> Date: Sat, 8 Apr 2017 15:23:50 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C2F1D63268C24012375A1CAE" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 13:23:56 -0000 This is a multi-part message in MIME format. --------------C2F1D63268C24012375A1CAE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 4/7/17 20:39, Paul Hoffman wrote: > (I'm surprised our philosophy-minded folks didn't answer this. I'll > take a stab, acknowledging that I'm only a philosophy tourist.) > > On 30 Mar 2017, at 13:41, Andrew McConachie wrote: > >> If a domain name is made up of labels, and labels are made up of >> octets, then can there be non-digital representations of domain names? > > Yes. The octets in the labels can be encoded into writing systems, and > there can be a commonly-recognized display format for the > representation of a group of labels. > >> For example, if I spray paint 'www.example' on the side of a bus, is >> it not a domain name because it is made up of paint instead of octets? > > It is a rendering (in paint, on a bus) a domain name in a > commonly-accepted display format. Neither the paint nor the bus is the > domain name. > > Some history related to representation versus essence: > https://essenceofbuddhism.wordpress.com/2016/04/19/what-the-finger-pointing-to-the-moon-analogy-really-means-from-zen-buddhism-the-buddha-in-the-shurangama-sutra/ /Ceci n'est pas une pipe./ If I understand correctly this definition of domain name incorporates actual pipes and explicitly not paintings of pipes. Since the draft says a domain name is essentially octets, and only octets, any representation of domain names not composed of octets is just a representation, not an actual domain name. I don't believe that's how the term is used in common parlance, but I can see how that definition works for this document. Thanks for the clarification! --Andrew --------------C2F1D63268C24012375A1CAE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

On 4/7/17 20:39, Paul Hoffman wrote:
(I'm surprised our philosophy-minded folks didn't answer this. I'll take a stab, acknowledging that I'm only a philosophy tourist.)

On 30 Mar 2017, at 13:41, Andrew McConachie wrote:

If a domain name is made up of labels, and labels are made up of octets, then can there be non-digital representations of domain names?

Yes. The octets in the labels can be encoded into writing systems, and there can be a commonly-recognized display format for the representation of a group of labels.

For example, if I spray paint 'www.example' on the side of a bus, is it not a domain name because it is made up of paint instead of octets?

It is a rendering (in paint, on a bus) a domain name in a commonly-accepted display format. Neither the paint nor the bus is the domain name.

Some history related to representation versus essence: https://essenceofbuddhism.wordpress.com/2016/04/19/what-the-finger-pointing-to-the-moon-analogy-really-means-from-zen-buddhism-the-buddha-in-the-shurangama-sutra/
Ceci n'est pas une pipe.

If I understand correctly this definition of domain name incorporates actual pipes and explicitly not paintings of pipes. Since the draft says a domain name is essentially octets, and only octets, any representation of domain names not composed of octets is just a representation, not an actual domain name.

I don't believe that's how the term is used in common parlance, but I can see how that definition works for this document. Thanks for the clarification!

--Andrew

--------------C2F1D63268C24012375A1CAE-- From nobody Sat Apr 8 06:38: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 18CAA12778D for ; Sat, 8 Apr 2017 06:38:11 -0700 (PDT) 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 S4SR0lZFECgO for ; Sat, 8 Apr 2017 06:38:09 -0700 (PDT) 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 0630112778E for ; Sat, 8 Apr 2017 06:38:08 -0700 (PDT) Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:f021:3c9d:c1a0:9cfd]) (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 56B29C1B96; Sat, 8 Apr 2017 15:38:04 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Sat, 08 Apr 2017 15:38:07 +0200 Message-ID: <51455D0A-0933-47D7-949A-7A9DB960E338@powerdns.com> In-Reply-To: References: <148942077219.17007.342057944218385620@ietfa.amsl.com> <20170328143352.GA12923@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 13:38:11 -0000 On 5 Apr 2017, at 8:57, Peter van Dijk wrote: > Hello Stephane, > > On 28 Mar 2017, at 16:33, Stephane Bortzmeyer wrote: > >> On Mon, Mar 13, 2017 at 08:59:32AM -0700, >> internet-drafts@ietf.org wrote >> a message of 45 lines which said: >> >>> Title : DNS Terminology >>> Authors : Paul Hoffman >>> Andrew Sullivan >>> Kazunori Fujiwara >>> Filename : draft-ietf-dnsop-terminology-bis-05.txt >> >> The new definition of QNAME describes as equivalent two conflicting >> definitions, the original one, in RFC 1034, and the one of RFC 2308, >> which seems used only by this RFC. IMHO, we should keep only the RFC >> 1034 definition. >> >> I filed an errata against RFC 2308 >> > > Notwithstanding your stubborn redefinition in 8020, the text in 2308 > is correct and this erratum is wrong. And to clarify, regardless of whether we agree on what the -right- definition of QNAME is, your erratum breaks 2308. After the sentence you replace, more sentences follow, and they no longer make sense after the replacement. Furthermore, 2308 relies on the definition of QNAME as it stands in 2308 today, so if you want to ‘fix’ the definition of QNAME in 2308, you need to make a lot more edits to it. (which given the terrible readability of 2308 is not the worst idea). Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Sat Apr 8 06:50: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 4485A12940C for ; Sat, 8 Apr 2017 06:50:53 -0700 (PDT) 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 WSP3xLRZ2Tzp for ; Sat, 8 Apr 2017 06:50:51 -0700 (PDT) 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 A24271274D2 for ; Sat, 8 Apr 2017 06:50:51 -0700 (PDT) Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:f021:3c9d:c1a0:9cfd]) (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 46A52C1B96; Sat, 8 Apr 2017 15:50:50 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Sat, 08 Apr 2017 15:50:54 +0200 Message-ID: In-Reply-To: <20170328143352.GA12923@laperouse.bortzmeyer.org> References: <148942077219.17007.342057944218385620@ietfa.amsl.com> <20170328143352.GA12923@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 13:50:53 -0000 On 28 Mar 2017, at 16:33, Stephane Bortzmeyer wrote: > I filed an errata against RFC 2308 > A question unrelated to the content of this erratum: if you had not posted here to mention your erratum, how would people have been able to find out? I can find various IETF lists that receive errata for more recent RFCs, but https://datatracker.ietf.org/doc/rfc2308/email/ does not list any addresses that I could subscribe to. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Sat Apr 8 15:32: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 3B6D61205F0 for ; Sat, 8 Apr 2017 15:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[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 NDYNIjRl75Pa for ; Sat, 8 Apr 2017 15:32:22 -0700 (PDT) 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 A5912127867 for ; Sat, 8 Apr 2017 15:32:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w0rmJ3K4pzDHG; Sun, 9 Apr 2017 00:32:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491690736; bh=hZKk9XyuIidrpLWBFfAm+bK5hyxXmekbFYGyVd2UpI8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=J0Q3qJxhacK3TEGeL/ocBEbn52BWUC3MJ49NfH2HaSO7KKnSlSn9FmzVkfNld7ssf zOBRDZe1JJVxenZgDwgXGDnRHaAlXBfTI7m+NtiSEYL2KWR41+SqAI7tmIcr1FE4t1 F2AgTdVav9t6qA2V+SCNKS5fms0oXsmrChlcZzgQ= 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 kwngWdS4G6Dk; Sun, 9 Apr 2017 00:32:14 +0200 (CEST) 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; Sun, 9 Apr 2017 00:32:13 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0F70069D772; Sat, 8 Apr 2017 18:32:12 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0F70069D772 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F025043FE06D; Sat, 8 Apr 2017 18:32:12 -0400 (EDT) Date: Sat, 8 Apr 2017 18:32:12 -0400 (EDT) From: Paul Wouters To: Evan Hunt cc: dnsop@ietf.org In-Reply-To: <20170407224716.GB33435@isc.org> Message-ID: References: <20170407181139.GB66383@isc.org> <20170407224716.GB33435@isc.org> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 22:32:24 -0000 On Fri, 7 Apr 2017, Evan Hunt wrote: > The hope here is that, in the long run, ANAME resolution would be the job > of the resolver, which in in a position to get the best answer for its > clients, given geolocation and topology considerations. > > Expansion of ANAME on the authoritative end is a workaround for the > fact that we can't go back in time and put ANAME support into all > the resolvers. > >> But really, what it comes down to for me is that if you are adding logic >> to the AUTH nameservers to synthesize ANAME into A/AAAA records, why bother >> ever sending ANAME over the wire? Just let clients send A/AAAA and never >> ask for ANAME. > > Resolvers don't ask for ANAME. They ask for A/AAAA, and get an A/AAAA > answer, along with an ANAME record so they can go directly to the source > and get a better answer if they support that. If these are the premises for ANAME, and its special handling, wouldn't it be better to generalise asking for multiple records (eg A + AAAA + ANAME) where ANAME has no special handling on its own? And then do the generealised multi-query-at-once using one of the previously suggested proposals? I thought there were some recent suggested drafts, which I cannot seem to find now, but an old one on this is draft-yao-dnsop-accompanying-questions. Then people who want to ask (A + AAAA + TLSA) or (A+AAAA+SSHFP) or (A+AAAA+IPSECKEY) could use the same mechanism. And ANAME would just be a regular DNS record without any abnormal processing. Paul From nobody Sat Apr 8 15:41: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 99B651205F0 for ; Sat, 8 Apr 2017 15:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 Z5AEExHAtzA0 for ; Sat, 8 Apr 2017 15:41:40 -0700 (PDT) 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 1A1A11200C1 for ; Sat, 8 Apr 2017 15:41:39 -0700 (PDT) Received: (qmail 82961 invoked from network); 8 Apr 2017 22:41:38 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Apr 2017 22:41:38 -0000 Date: 8 Apr 2017 22:41:16 -0000 Message-ID: <20170408224116.58162.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: paul@nohats.ca 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] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 22:41:42 -0000 >If these are the premises for ANAME, and its special handling, wouldn't >it be better to generalise asking for multiple records (eg A + AAAA >+ ANAME) where ANAME has no special handling on its own? And then do the >generealised multi-query-at-once using one of the previously suggested >proposals? But that doesn't solve the original problem. Clients ask for an A or an AAAA record, and that's what they want to get back. The ANAME is really just a provisioning hack built into the authoritative server and, depending on the implementation, maybe the cache. I suppose they might ask for both A and AAAA but that's a separate problem, even though it might use a similar mechanism. R's, John From nobody Sat Apr 8 18:38: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 786B3126B72 for ; Sat, 8 Apr 2017 18:38:53 -0700 (PDT) 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 CMUnjlhPHIML for ; Sat, 8 Apr 2017 18:38:51 -0700 (PDT) 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 6E9E0128B92 for ; Sat, 8 Apr 2017 18:38:50 -0700 (PDT) Received: by mail-ua0-x248.google.com with SMTP id u103so6706986uau.19 for ; Sat, 08 Apr 2017 18:38:50 -0700 (PDT) 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=oepguoSqOjcK0m1MtJQsdFFRNkaEoAOSvu5j1l6mNG8=; b=AW52bn0YnJR3wcXyNWXf3zEbhrHATwQY3BIzPX43HMsGlRrAYebDhz9WJHthT5kGnQ KEnqNuivSC9wPF8IYJWhnX9MqhMySitGnnPA7LAaDglG3U+nc9yyHg8H5adnvH/uxfv6 hKeYHSrjM/TFPWsLqBXA7osDZy90Ny5cpul50= 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=oepguoSqOjcK0m1MtJQsdFFRNkaEoAOSvu5j1l6mNG8=; b=CrBZyAPOHdWI08CqR54Bvi4xtpZMYXpW7zVhkS3vaicrdfK8pRtv9aPFTu/95YM2Xe TiqyQ2brMTkUaVgKIQxrAVZg7QxFiKu6J21EqJUrIREIK8OwxgA44vQbE/zT6zR7V2cK VW3/fk9DN5UkfNno4nP0Vn5SIMsh8rcMAmB5veM7EHUTlNlqlqbnJOYYuEEsUHauh/Wb 1P82i6mwzBRIBNEpWHVmwLY0jmffHqD/dr1Ih6v8MomLUzfiNXi6QH+SoDw6d3VDbzAl B4Xo8PnnhfdTx1GulYbWfx1kmfpokXu4Dwh15XcbLyANiMmt2l/oq6GmCRrM5ZoJoKa+ 1tww== X-Gm-Message-State: AN3rC/49FNlFY4SYuqGTdJ5LREPaNsIRfYLa6ib/VEh45gu8uYxWRJ84A0qdUroK45DjdFQVCTAUJi7++CU5OKJJ X-Received: by 10.31.53.136 with SMTP id c130mr6604137vka.127.1491701929427; Sat, 08 Apr 2017 18:38:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.82 with HTTP; Sat, 8 Apr 2017 18:38:29 -0700 (PDT) In-Reply-To: <20170407181139.GB66383@isc.org> References: <20170407181139.GB66383@isc.org> From: Richard Gibson Date: Sat, 8 Apr 2017 21:38:29 -0400 Message-ID: To: Evan Hunt Cc: dnsop Content-Type: multipart/alternative; boundary=001a114469c09d58d4054cb1ebd9 Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 01:38:53 -0000 --001a114469c09d58d4054cb1ebd9 Content-Type: text/plain; charset=UTF-8 I'm happy to see progress being made on this front. Some comments: *Section 3.1* This section calls for limiting the TTL of cached address records to the lesser of the ANAME TTL and the TTL of the retrieved address records, but section 3 requires servers to follow chained responses. Are the TTLs of intermediate records in a chain supposed to be ignored? What is the expected behavior when the target record set is empty, or bogus, or when resolution fails? *Section 3.2* The wording of this section could use some improvement. It seems to prohibit secondary servers from resolving ANAME targets when they are present at the same domain as address types... do I understand correctly? Are such address records still subject to TTL decrementing (presumably starting at the time of zone transfer)? And when only a single address type is present (e.g., just ANAME and A), does that still prevent resolution of the ANAME target for the other type? *Section 3.3* Although labeled "DNSSEC signing", this section also contains more general specification (e.g., "the master server MUST respect the TTLs of the address records" and "TTLs [of address records in a secondary server] will count down"). It is also mute on the use of DNSSEC for resolving ANAME target records, but that should probably be covered somewhere. On Fri, Apr 7, 2017 at 2:11 PM, Evan Hunt wrote: > Greetings, > > Here's the new ANAME draft I mentioned last week. > > This is similar to existing non-standard approaches (ALIAS records, > CNAME-flattening, etc) but also sends the ANAME record to the resolver so > that, if the resolver understands the ANAME type, it can re-query for the > answer just as it would with a CNAME. > > Please have at it. > > ----- Forwarded message from internet-drafts@ietf.org ----- > > From: internet-drafts@ietf.org > To: Evan Hunt , Peter van Dijk >, > Anthony Eden > Subject: New Version Notification for draft-hunt-dnsop-aname-00.txt > Date: Fri, 07 Apr 2017 11:04:39 -0700 > > A new version of I-D, draft-hunt-dnsop-aname-00.txt > has been successfully submitted by Evan Hunt and posted to the > IETF repository. > > Name: draft-hunt-dnsop-aname > Revision: 00 > Title: Address-specific DNS Name Redirection (ANAME) > Document date: 2017-04-07 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet- > drafts/draft-hunt-dnsop-aname-00.txt > Status: https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ > Htmlized: https://tools.ietf.org/html/draft-hunt-dnsop-aname-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-hunt-dnsop- > aname-00 > > > Abstract: > This document defines the "ANAME" DNS RR type, to provide similar > functionality to CNAME, but only redirects type A and AAAA queries. > Unlike CNAME, an ANAME can coexist with other record types. The > ANAME RR allows zone owners to redirect queries for apex domain names > in a standards compliant manner. > > 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 forwarded message ----- > > -- > Evan Hunt -- each@isc.org > Internet Systems Consortium, Inc. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a114469c09d58d4054cb1ebd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm happy to see progress being made on this fron= t. Some comments:

Section 3.1
This section calls for limiting the TTL of cached address recor= ds to the lesser of the ANAME TTL and the TTL of the retrieved address reco= rds, but section 3 requires servers to follow chained responses. Are the TT= Ls of intermediate records in a chain supposed to be ignored?
What is the expected behavior when the target record set is emp= ty, or bogus, or when resolution fails?

Sec= tion 3.2

The wording of this section could use= some improvement. It seems to prohibit secondary servers from resolving AN= AME targets when they are present at the same domain as address types... do= I understand correctly? Are such address records still subject to TTL decr= ementing (presumably starting at the time of zone transfer)? And when only = a single address type is present (e.g., just ANAME and A), does that still = prevent resolution of the ANAME target for the other type?

Section 3.3

Although labeled "= ;DNSSEC signing", this section also contains more general specificatio= n (e.g., "the master server MUST respect the TTLs of the address recor= ds" and "TTLs [of address records in a secondary server] will cou= nt down").

It is also mute on the use of DNSS= EC for resolving ANAME target records, but that should probably be covered = somewhere.

On Fri, Apr 7, 2017 at 2:11 PM, Evan Hunt <each@isc.org> wro= te:
Greetings,

Here's the new ANAME draft I mentioned last week.

This is similar to existing non-standard approaches (ALIAS records,
CNAME-flattening, etc) but also sends the ANAME record to the resolver so that, if the resolver understands the ANAME type, it can re-query for the answer just as it would with a CNAME.

Please have at it.

----- Forwarded message from in= ternet-drafts@ietf.org -----

From: internet-drafts@ietf.org<= /a>
To: Evan Hunt <each@isc.org>, Pet= er van Dijk <peter.van.di= jk@powerdns.com>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Anthony Eden <anthony.eden@dnsimple.com>
Subject: New Version Notification for draft-hunt-dnsop-aname-00.txt
Date: Fri, 07 Apr 2017 11:04:39 -0700

A new version of I-D, draft-hunt-dnsop-aname-00.txt
has been successfully submitted by Evan Hunt and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hunt-dnsop-aname
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address-specific DNS Name Redirect= ion (ANAME)
Document date:=C2=A0 2017-04-07
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hunt-dnsop-anam= e-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://too= ls.ietf.org/html/draft-hunt-dnsop-aname-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/html/draft-hunt-dnsop-aname-00


Abstract:
=C2=A0 =C2=A0This document defines the "ANAME" DNS RR type, to pr= ovide similar
=C2=A0 =C2=A0functionality to CNAME, but only redirects type A and AAAA que= ries.
=C2=A0 =C2=A0Unlike CNAME, an ANAME can coexist with other record types.=C2= =A0 The
=C2=A0 =C2=A0ANAME RR allows zone owners to redirect queries for apex domai= n names
=C2=A0 =C2=A0in a standards compliant manner.

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.

The IETF Secretariat

----- End forwarded message -----

--
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.

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

--001a114469c09d58d4054cb1ebd9-- From nobody Sun Apr 9 12:40: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 068BC128B38; Sun, 9 Apr 2017 12:40:35 -0700 (PDT) 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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149176683502.3102.2188448919139874482.idtracker@ietfa.amsl.com> Date: Sun, 09 Apr 2017 12:40:35 -0700 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-hunt-dnsop-aname in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 19:40:35 -0000 The DNSOP WG has placed draft-hunt-dnsop-aname in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ From nobody Sun Apr 9 12:56: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 F24B31276AF for ; Sun, 9 Apr 2017 12:56:22 -0700 (PDT) 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 TJ5AQjz9uAPk for ; Sun, 9 Apr 2017 12:56:21 -0700 (PDT) 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 99B0D128656 for ; Sun, 9 Apr 2017 12:56:19 -0700 (PDT) Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:f021:3c9d:c1a0:9cfd]) (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 263B3C1B96; Sun, 9 Apr 2017 21:56:16 +0200 (CEST) From: "Peter van Dijk" To: dnsop Date: Sun, 09 Apr 2017 21:56:27 +0200 Message-ID: In-Reply-To: References: <20170407181139.GB66383@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 19:56:23 -0000 Hello Richard, On 9 Apr 2017, at 3:38, Richard Gibson wrote: > I'm happy to see progress being made on this front. Some comments: Thank you for taking the time for this. > *Section 3.1* > > This section calls for limiting the TTL of cached address records to > the > lesser of the ANAME TTL and the TTL of the retrieved address records, > but > section 3 requires servers to follow chained responses. Are the TTLs > of > intermediate records in a chain supposed to be ignored? > > What is the expected behavior when the target record set is empty, or > bogus, or when resolution fails? Empty becomes empty. The common case will be ‘the ANAME target only has A, no AAAA’ which means the AAAA lookup encounters a valid ‘no data’. If resolution fails (i.e. runs into an actual SERVFAIL-like error condition, including ‘bogus’), we should also SERVFAIL. If the draft is unclear on this we should definitely fix that. > *Section 3.2* > > The wording of this section could use some improvement. It seems to > prohibit secondary servers from resolving ANAME targets when they are > present at the same domain as address types... do I understand > correctly? Yes, that is correct. We went through a few iterations and thought exercises and this seemed like the optimal behaviour. > Are such address records still subject to TTL decrementing (presumably > starting at the time of zone transfer)? And when only a single address > type > is present (e.g., just ANAME and A), does that still prevent > resolution of > the ANAME target for the other type? (1) Yes, they are still subject to TTL decrementing, but if the slave is not ANAME-aware, no decrementing will happen and the draft allows this, if we wrote it all down correctly. (2) Yes, when any address records are present, the ANAME is deemed to have already been expanded. If A is there and no AAAA, then this means that there is in fact no AAAA to be had. > *Section 3.3* > > Although labeled "DNSSEC signing", this section also contains more > general > specification (e.g., "the master server MUST respect the TTLs of the > address records" and "TTLs [of address records in a secondary server] > will > count down"). Then the section is misnamed or those specifications should be moved. I will look at that. > It is also mute on the use of DNSSEC for resolving ANAME target > records, > but that should probably be covered somewhere. This is an interesting topic actually. There are existing deployments of PowerDNS ALIAS (which of course is quite similar to ANAME) that use it instead of ‘CNAME to unsigned’ so they can sign the target addresses (that they get via a non-DNSSEC but still secure path). This draft should also allow that. If you have suggestions for a section on ANAME target resolving and DNSSEC, please let us know. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Sun Apr 9 16:04: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 8E68F127337 for ; Sun, 9 Apr 2017 16:04:29 -0700 (PDT) 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 n9i0wkcdrzqJ for ; Sun, 9 Apr 2017 16:04:27 -0700 (PDT) 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 F18481242F5 for ; Sun, 9 Apr 2017 16:04:26 -0700 (PDT) Received: by mail-ua0-x248.google.com with SMTP id 20so12225280uag.14 for ; Sun, 09 Apr 2017 16:04:26 -0700 (PDT) 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=G7sf2SvDxZ/UHnNzFM2ulgka6/aAOJ7juIjMPw2Q/5w=; b=1J/fs7FmLj4HJZuvQZlfoPD20RMKFvo1so5jeZ7fVE0sZ3fmq934a/Imo86EMN4sSR IIoNH4X4xEypr5xX1KvULjJUrLbvKGaA9kL7RV2ip2QJGMI3dVsjMJlVD8axh1av3Qlq ZcdJ/sHJSkeprF9w5xD3GFnxodH9/vTXIqo3E= 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=G7sf2SvDxZ/UHnNzFM2ulgka6/aAOJ7juIjMPw2Q/5w=; b=cv6CU/W8JXcnK4rR43xWoqB0zyPzmmKFsidROvzwv49XGm+5u2pEHnZ0VqEwxmK1wn jJoGkDHF3cgS1RVK8UExlD8BnO1Ezf1J86i04J1BOAbosGlusBfVu4y9bZWkvMC+Zoy5 Gbpk7Br6Bf8IdkMprc3hSgiYuBfVs4vPteypgk8cPXj3TSccKSa5aAcTprkpFRVjKaOj 57+7DU/QAUl23qqHJ6ZGDmDli1oLOwXiZ98dPIcIgwZeFn81ny1O7LZ/e9Wcq8UCHqo0 Q0s+oz4paP7PbZ4u3FOqiIgWkdK0nng6SufzM0rmED/GM0sAEyap9kUPaSps1sHncF6Q fm9Q== X-Gm-Message-State: AFeK/H1zLZWjo4oGN3biU3DNfqvK4gLFaBZYzpxQVDarE3dDoMLl/C3viSBv2vDoeAhz1wPdZmUr8xB7euvQNmcB X-Received: by 10.159.52.17 with SMTP id q17mr19463751uab.83.1491779065926; Sun, 09 Apr 2017 16:04:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.82 with HTTP; Sun, 9 Apr 2017 16:04:05 -0700 (PDT) In-Reply-To: References: <20170407181139.GB66383@isc.org> From: Richard Gibson Date: Sun, 9 Apr 2017 19:04:05 -0400 Message-ID: To: Peter van Dijk Cc: dnsop Content-Type: multipart/alternative; boundary=f403045dce8e4ee9d0054cc3e141 Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 23:04:30 -0000 --f403045dce8e4ee9d0054cc3e141 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Apr 9, 2017 at 3:56 PM, Peter van Dijk wrote: > Thank you for taking the time for this. My pleasure; this topic has frequently been on my mind over the past several years. Thank you for drafting it. *Section 3.1* >> > >> This section calls for limiting the TTL of cached address records to the >> lesser of the ANAME TTL and the TTL of the retrieved address records, bu= t >> section 3 requires servers to follow chained responses. Are the TTLs of >> intermediate records in a chain supposed to be ignored? >> > What was the response on this point? What is the expected behavior when the target record set is empty, or >> bogus, or when resolution fails? >> > > Empty becomes empty. The common case will be =E2=80=98the ANAME target on= ly has A, > no AAAA=E2=80=99 which means the AAAA lookup encounters a valid =E2=80=98= no data=E2=80=99. > If resolution fails (i.e. runs into an actual SERVFAIL-like error > condition, including =E2=80=98bogus=E2=80=99), we should also SERVFAIL. I= f the draft is > unclear on this we should definitely fix that. > Right; I definitely think there should be text explicitly defining behavior for timeouts, nonzero RCODEs, and bogus responses received when looking up ANAME targets. Section 4 covers part of it (for recursive servers only), but doesn't define how to determine when "resolution fails" or what to do when not opting to use the accompanying records as a fallback, and there is no guidance at all for authoritative servers. *Section 3.2* >> >> The wording of this section could use some improvement. It seems to >> prohibit secondary servers from resolving ANAME targets when they are >> present at the same domain as address types... do I understand correctly= ? >> > > Yes, that is correct. We went through a few iterations and thought > exercises and this seemed like the optimal behaviour. Dyn went another way with our ALIAS functionality, reserving same-domain address record sets for fallback data to be used whenever target resolution doesn't yield records of the appropriate type (including, perhaps controversially, NXDOMAIN and NODATA empty responses). Assuming a secondary server predating ANAME, the Dyn behavior would be slightly better when the primary server is ignorant of that gap (i.e., the secondary would always serve fallback data) and identical behavior when it is not (i.e., the authoritative would pre-expand as the draft specifies in Section 5). It also provides support for multi-type host names with single-type targets, e.g. static AAAA records sharing a domain with an ALIAS targeting a name providing only A records. Where it really shines, though, is in handling error cases like those discussed above=E2=80=94it was very important to our customers that they could prevent us from ever issuing cacheable negative responses. What thought exercises took you in this direction? Are such address records still subject to TTL decrementing (presumably >> starting at the time of zone transfer)? And when only a single address >> type >> is present (e.g., just ANAME and A), does that still prevent resolution = of >> the ANAME target for the other type? >> > > (1) Yes, they are still subject to TTL decrementing, but if the slave is > not ANAME-aware, no decrementing will happen and the draft allows this, i= f > we wrote it all down correctly. > (2) Yes, when any address records are present, the ANAME is deemed to hav= e > already been expanded. If A is there and no AAAA, then this means that > there is in fact no AAAA to be had. > I understand the motivation, but there's an interesting wrinkle with respect to forward compatibility... what happens when a new address type is added to the DNS? The assumption that pre-expansion of any address type implies pre-expansion of all address types seems like it could lead to some dramatic changes in behavior as primary servers, secondary servers, resolvers, and targeted zones become aware of the new type in a nonuniform fashion. Has any consideration been given to that concern? On a related note, should recursive resolvers query for ANAME targets even when they *don't* correspond to A or AAAA QTYPEs? It is also mute on the use of DNSSEC for resolving ANAME target records, >> but that should probably be covered somewhere. >> > > This is an interesting topic actually. There are existing deployments of > PowerDNS ALIAS (which of course is quite similar to ANAME) that use it > instead of =E2=80=98CNAME to unsigned=E2=80=99 so they can sign the targe= t addresses (that > they get via a non-DNSSEC but still secure path). This draft should also > allow that. If you have suggestions for a section on ANAME target resolvi= ng > and DNSSEC, please let us know. Addressing the above points to explicitly define behavior for bogus responses will cover the functional requirements, so this will likely take the form of MAY or SHOULD guidance for using DNSSEC when resolving ANAME targets. --f403045dce8e4ee9d0054cc3e141 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Apr 9, 2017 at 3:56 PM, Peter van Dijk <peter.van.dijk@power= dns.com> wrote:
Thank you for taking the time for = this.

My pleasure; this topic has fr= equently been on my mind over the past several years. Thank you for draftin= g it.

*Section 3.1*

This section calls for limiting the TTL of cached address records to the lesser of the ANAME TTL and the TTL of the retrieved address records, but section 3 requires servers to follow chained responses. Are the TTLs of
intermediate records in a chain supposed to be ignored?

What was the response on this point?

What is = the expected behavior when the target record set is empty, or
bogus, or when resolution fails?

Empty becomes empty. The common case will be =E2=80=98the ANAME target only= has A, no AAAA=E2=80=99 which means the AAAA lookup encounters a valid =E2= =80=98no data=E2=80=99.=C2=A0

If resolution fails (i.e. runs into an actual SERVFAIL-like error condition= , including =E2=80=98bogus=E2=80=99), we should also SERVFAIL. If the draft= is unclear on this we should definitely fix that.
Right; I definitely think there should be text explicitly defin= ing behavior for timeouts, nonzero RCODEs, and bogus responses received whe= n looking up ANAME targets. Section 4 covers part of it (for recursive serv= ers only), but doesn't define how to determine when "resolution fa= ils" or what to do when not opting to use the accompanying records as = a fallback, and there is no guidance at all for authoritative servers.

*Section 3.2*

The wording of this section could use some improvement. It seems to
prohibit secondary servers from resolving ANAME targets when they are
present at the same domain as address types... do I understand correctly?

Yes, that is correct. We went through a few iterations and thought exercise= s and this seemed like the optimal behaviour.

Dyn went another way with our ALIAS functionality, reserving same-domain= address record sets for fallback data to be used whenever target resolutio= n doesn't yield records of the appropriate type (including, perhaps con= troversially, NXDOMAIN and NODATA empty responses). Assuming a secondary se= rver predating ANAME, the Dyn behavior would be slightly better when the pr= imary server is ignorant of that gap (i.e., the secondary would always serv= e fallback data) and identical behavior when it is not (i.e., the authorita= tive would pre-expand as the draft specifies in Section 5). It also provide= s support for multi-type host names with single-type targets, e.g. static A= AAA records sharing a domain with an ALIAS targeting a name providing only = A records. Where it really shines, though, is in handling error cases like = those discussed above=E2=80=94it was very important to our customers that t= hey could prevent us from ever issuing cacheable negative responses. What t= hought exercises took you in this direction?

Are such address records still subjec= t to TTL decrementing (presumably
starting at the time of zone transfer)? And when only a single address type=
is present (e.g., just ANAME and A), does that still prevent resolution of<= br> the ANAME target for the other type?

 (1) Yes, they are still subject to TTL decrementing, but if the slave is no= t ANAME-aware, no decrementing will happen and the draft allows this, if we= wrote it all down correctly.
(2) Yes, when any address records are present, the ANAME is deemed to have = already been expanded. If A is there and no AAAA, then this means that ther= e is in fact no AAAA to be had.

I under= stand the motivation, but there's an interesting wrinkle with respect t= o forward compatibility... what happens when a new address type is added to= the DNS? The assumption that pre-expansion of any address type implies pre= -expansion of all address types seems like it could lead to some dramatic c= hanges in behavior as primary servers, secondary servers, resolvers, and ta= rgeted zones become aware of the new type in a nonuniform fashion. Has any = consideration been given to that concern?

On a rel= ated note, should recursive resolvers query for ANAME targets even when the= y don't correspond to A or AAAA QTYPEs?

It is also mute on the use of D= NSSEC for resolving ANAME target records,
but that should probably be covered somewhere.

 This is an interesting topic actually. There are existing deployments of Po= werDNS ALIAS (which of course is quite similar to ANAME) that use it instea= d of =E2=80=98CNAME to unsigned=E2=80=99 so they can sign the target addres= ses (that they get via a non-DNSSEC but still secure path). This draft shou= ld also allow that. If you have suggestions for a section on ANAME target r= esolving and DNSSEC, please let us know.

Ad= dressing the above points to explicitly define behavior for bogus responses= will cover the functional requirements, so this will likely take the form = of MAY or SHOULD guidance for using DNSSEC when resolving ANAME targets.
--f403045dce8e4ee9d0054cc3e141-- From nobody Mon Apr 10 01:34: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 A7698126DCA for ; Mon, 10 Apr 2017 01:34:28 -0700 (PDT) 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 7TVWO5NFSi_A for ; Mon, 10 Apr 2017 01:34:26 -0700 (PDT) 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 2CA30120454 for ; Mon, 10 Apr 2017 01:34:26 -0700 (PDT) Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:4121:72dd:65d3:c56d]) (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 D98E5C5C23; Mon, 10 Apr 2017 10:34:23 +0200 (CEST) From: "Peter van Dijk" To: dnsop Date: Mon, 10 Apr 2017 10:34:23 +0200 Message-ID: In-Reply-To: References: <20170407181139.GB66383@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 08:34:29 -0000 On 10 Apr 2017, at 1:04, Richard Gibson wrote: > On Sun, Apr 9, 2017 at 3:56 PM, Peter van Dijk > > wrote: > >>> This section calls for limiting the TTL of cached address records to >>> the >>> lesser of the ANAME TTL and the TTL of the retrieved address >>> records, but >>> section 3 requires servers to follow chained responses. Are the TTLs >>> of >>> intermediate records in a chain supposed to be ignored? >> > What was the response on this point? Oh, right. I suppose the right answer would be to take the lowest of all involved TTLs. > Right; I definitely think there should be text explicitly defining > behavior > for timeouts, nonzero RCODEs, and bogus responses received when > looking up > ANAME targets. Section 4 covers part of it (for recursive servers > only), > but doesn't define how to determine when "resolution fails" or what to > do > when not opting to use the accompanying records as a fallback, and > there is > no guidance at all for authoritative servers. Agreed. > *Section 3.2* >>> >>> The wording of this section could use some improvement. It seems to >>> prohibit secondary servers from resolving ANAME targets when they >>> are >>> present at the same domain as address types... do I understand >>> correctly? >>> >> >> Yes, that is correct. We went through a few iterations and thought >> exercises and this seemed like the optimal behaviour. > > > Dyn went another way with our ALIAS functionality, reserving > same-domain > address record sets for fallback data to be used whenever target > resolution > doesn't yield records of the appropriate type (including, perhaps > controversially, NXDOMAIN and NODATA empty responses). Assuming a > secondary > server predating ANAME, the Dyn behavior would be slightly better when > the > primary server is ignorant of that gap (i.e., the secondary would > always > serve fallback data) and identical behavior when it is not (i.e., the > authoritative would pre-expand as the draft specifies in Section 5). > It > also provides support for multi-type host names with single-type > targets, > e.g. static AAAA records sharing a domain with an ALIAS targeting a > name > providing only A records. Where it really shines, though, is in > handling > error cases like those discussed above—it was very important to our > customers that they could prevent us from ever issuing cacheable > negative > responses. What thought exercises took you in this direction? Working back from the premise that there -will- be ANAME unaware secondaries, we allow primaries to do the ANAME expansion during outgoing AXFR (or on load, but in any case the secondary gets actual (signed!) A/AAAA records). Thus, such a secondary will simply serve the A/AAAA. To keep things simple, we decided that an ANAME aware auth will do the same, so behaviour is consistent. The alternative, of defining those records as fallback, means that ANAME aware slaves that -do- receive a pre-expanded A/AAAA set, need configuration knobs to figure out if they should look up the ANAME target or not. We could automate this to a limit - say, if you are a slave, you understand ANAME, and you do not have the private key for the zone, then obviously you have to use what you find in the zone. However, it was my feeling that this would yield more complexity than we want. Anyway, I will ponder your use case. As for ‘AAAA from config, A from ANAME’, we’ve been discussing allowing multiple ANAMEs at a node, and then you could do something like this: www.example.com. ANAME www-v6.example.com. www.example.com. ANAME example.com.my-cdn.com www-v6.example.com. AAAA 2001:db8::80 >>> Are such address records still subject to TTL decrementing >>> (presumably >>> starting at the time of zone transfer)? And when only a single >>> address >>> type >>> is present (e.g., just ANAME and A), does that still prevent >>> resolution of >>> the ANAME target for the other type? >>> >> >> (1) Yes, they are still subject to TTL decrementing, but if the slave >> is >> not ANAME-aware, no decrementing will happen and the draft allows >> this, if >> we wrote it all down correctly. >> (2) Yes, when any address records are present, the ANAME is deemed to >> have >> already been expanded. If A is there and no AAAA, then this means >> that >> there is in fact no AAAA to be had. > > I understand the motivation, but there's an interesting wrinkle with > respect to forward compatibility... what happens when a new address > type is > added to the DNS? The assumption that pre-expansion of any address > type > implies pre-expansion of all address types seems like it could lead to > some > dramatic changes in behavior as primary servers, secondary servers, > resolvers, and targeted zones become aware of the new type in a > nonuniform > fashion. Has any consideration been given to that concern? Not by me so far, I’ll readily admit. Will ponder. > On a related note, should recursive resolvers query for ANAME targets > even > when they *don't* correspond to A or AAAA QTYPEs? Probably not. >>> It is also mute on the use of DNSSEC for resolving ANAME target >>> records, >>> but that should probably be covered somewhere. >> >> This is an interesting topic actually. There are existing deployments >> of >> PowerDNS ALIAS (which of course is quite similar to ANAME) that use >> it >> instead of ‘CNAME to unsigned’ so they can sign the target >> addresses (that >> they get via a non-DNSSEC but still secure path). This draft should >> also >> allow that. If you have suggestions for a section on ANAME target >> resolving >> and DNSSEC, please let us know. > > Addressing the above points to explicitly define behavior for bogus > responses will cover the functional requirements, so this will likely > take > the form of MAY or SHOULD guidance for using DNSSEC when resolving > ANAME > targets. Indeed. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Mon Apr 10 02:29: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 B3A1F129451 for ; Mon, 10 Apr 2017 02:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.024 X-Spam-Level: X-Spam-Status: No, score=-5.024 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cHvycwqxvxKm for ; Mon, 10 Apr 2017 02:29:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99736129467 for ; Mon, 10 Apr 2017 02:29:52 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1DE1A80461; Mon, 10 Apr 2017 09:29:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1DE1A80461 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1DE1A80461 Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 73BF386CF9; Mon, 10 Apr 2017 09:29:51 +0000 (UTC) To: Evan Hunt , dnsop@ietf.org References: <20170407181139.GB66383@isc.org> From: Florian Weimer Message-ID: Date: Mon, 10 Apr 2017 11:29:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170407181139.GB66383@isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 10 Apr 2017 09:29:52 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 09:29:56 -0000 On 04/07/2017 08:11 PM, Evan Hunt wrote: > Title: Address-specific DNS Name Redirection (ANAME) I think the introduction should discuss why it is not possible to push the CNAME to the parent zone, replacing the entire zone with an alias. Section 3 is currently written in such a way that a recursive DNS lookup must be performed at the authoritative server side. I don't think it is necessary to require that. A recursive DNS lookup of the target is just one way to implement this. In particular, the suggested recursive DNS lookup needs some form of distributed loop detection. Otherwise, a malicious customer could publish two zones with ANAME records and achieve significant traffic amplification, potentially taking down the DNS hoster. A hop count in an EDNS option or an ANAME lookup in progress indicator would be one way to implement this. Another approach would impose restrictions on the owner name of an ANAME record and its target, and restrict where CNAMEs can appear, so that a valid ANAME can never point to another valid ANAME. Thanks, Florian From nobody Mon Apr 10 02:38: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 2C0511293DA for ; Mon, 10 Apr 2017 02:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YPXzK9NPl83t for ; Mon, 10 Apr 2017 02:38:53 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id D2B7B129467 for ; Mon, 10 Apr 2017 02:38:52 -0700 (PDT) Received: from jurassic (unknown [115.117.162.37]) (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 EC7F756A023F; Mon, 10 Apr 2017 09:38:50 +0000 (GMT) Date: Mon, 10 Apr 2017 15:08:47 +0530 From: Mukund Sivaraman To: dnsop@ietf.org Message-ID: <20170410093847.GA21654@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dnssec-sha3-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 09:38:55 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all > A new version of I-D, draft-muks-dnsop-dnssec-sha3-01.txt > has been successfully submitted by Mukund Sivaraman and posted to the > IETF repository. > > Name: draft-muks-dnsop-dnssec-sha3 > Revision: 01 > Title: Use of SHA-3 (Keccak) and RSASSA-PSS in DNSSEC > Document date: 2017-04-08 > Group: Individual Submission > Pages: 26 > URL: https://www.ietf.org/internet-drafts/draft-muks-dnsop-dnssec-sha3-01.txt > Status: https://datatracker.ietf.org/doc/draft-muks-dnsop-dnssec-sha3/ > Htmlized: https://tools.ietf.org/html/draft-muks-dnsop-dnssec-sha3-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dnssec-sha3-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dnssec-sha3-01 > > Abstract: > This document specifies the use of SHA-3 (Keccak) hash functions in > DNSSEC. It also specifies the use of the RSASSA-PSS signature scheme > for RSA keys. A new revision of the draft has been uploaded: - It now uses the RSASSA-PSS signature scheme (based on comments from Paul Hoffman & Francis) and adds RSASSA-PSS/SHA3-256, RSASSA-PSS/SHA3-384 and RSASSA-PSS/SHA3-512 for using SHA-3. - It adds algorithms for RSASSA-PSS/SHA2-256 and RSASSA-PSS/SHA2-512 to use the SHA-2 algorithms with RSASSA-PSS. - It adds algorithms for ECDSA/SHA3-256 and ECDSA/SHA3-384. - It now has a better problem statement in the introduction (based on contents of reply from Paul Hoffman) - BIND implementation has been updated here: https://github.com/muks/bind9/tree/sha3 - An independently written ldns implementation is here: https://github.com/tjeb/ldns Mukund --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY61KmAAoJEB9EXrAiC5Ls73YP/iq8kooS/JbsCx8sgUI/pWFP BZ7Ur6byMe7NVneNAD4Ym2VVzKJ7+51yQkphTh6uaOvapA4FpivS2nUMDBDn/RiN 62LemarTRH5ayYR3PjTO/6ILVe1bR69yPMxe3wvUPVnmGLO28oWwqAO//ExojnyU ZA6mjpMRHMWpUgZquTjaxY2mXMjhdH/Mb4GgrguqwIzBK5DdZFvl/br2xY6CEZVn fBXu8gOphjOJ+Ixn0VQ0gEWaIwdWezuz5G+9NrGU2mhlav6pOtNJcUgDMmV9k2zo xeJcCk8XTafes7cs85PWwZVfth0T/77gKEVcUqZeTUoua18LWlIXhfmMrVAb6TPT HNFQW41pFFLulOQRsdCJjMYXV8JqU1VpQvIe5+HgjJZ6S0I394vPiDHznNIrnGk8 qkjzkmVXg7951zWLGzMt/tVO3VQ5HJ27LSTWFib+8/qNt6nlqFNySe31+BhKXMK1 LfiretIu3gDhddtS+h4cS2/oC2v+2QOU5K/t4bQeiWzskTIc9Nj2VSXs5V3eXvBK pQFFqlLKDhmoSNlUYuGguYOUrwUjUUZ5G4dR25U4vCOBvK0cOv5FYxlIRnM6jCV5 slklj5V7UCceusT8B9AHTqEt5Mh1okjRIsUjTU6E3DVfQX7ejdMr3B3wAyljchQC /Cqq1TBXL9YX6TkDd7rd =QaIz -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From nobody Mon Apr 10 03:04: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 C6CCF12946A for ; Mon, 10 Apr 2017 03:04:55 -0700 (PDT) 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 TkRmDFKPlsqO for ; Mon, 10 Apr 2017 03:04:54 -0700 (PDT) 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 0A72D120724 for ; Mon, 10 Apr 2017 03:04:54 -0700 (PDT) Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:4121:72dd:65d3:c56d]) (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 B1943C5C23; Mon, 10 Apr 2017 12:04:52 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Mon, 10 Apr 2017 12:04:52 +0200 Message-ID: <86FE867E-E1BE-4427-9FB2-D148B3F9C8C2@powerdns.com> In-Reply-To: References: <20170407181139.GB66383@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 10:04:56 -0000 On 10 Apr 2017, at 11:29, Florian Weimer wrote: > On 04/07/2017 08:11 PM, Evan Hunt wrote: >> Title: Address-specific DNS Name Redirection (ANAME) > > I think the introduction should discuss why it is not possible to push > the CNAME to the parent zone, replacing the entire zone with an alias. Why this is not possible seems obvious to me, but we’ll see what we can write. > Section 3 is currently written in such a way that a recursive DNS > lookup must be performed at the authoritative server side. I don't > think it is necessary to require that. A recursive DNS lookup of the > target is just one way to implement this. What other ways did you have in mind? > In particular, the suggested recursive DNS lookup needs some form of > distributed loop detection. Otherwise, a malicious customer could > publish two zones with ANAME records and achieve significant traffic > amplification, potentially taking down the DNS hoster. A hop count in > an EDNS option or an “ANAME lookup in progress” indicator would be > one way to implement this. Another approach would impose restrictions > on the owner name of an ANAME record and its target, and restrict > where CNAMEs can appear, so that a valid ANAME can never point to > another valid ANAME. I’m not sure it’s feasible to forbid chaining ANAMEs. I do agree there is a vector for DoS here. Section 6 currently cowardly says “Both authoritative servers and resolvers that implement ANAME should carefully check for loops and treat them as an error condition.” but I am aware that more words are needed. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Mon Apr 10 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 B1DAF124D68 for ; Mon, 10 Apr 2017 03:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 lC1hZj94Rq3I for ; Mon, 10 Apr 2017 03:39:22 -0700 (PDT) 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 2FDF312441E for ; Mon, 10 Apr 2017 03:39:21 -0700 (PDT) Received: from [46.227.151.81] (port=51957 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 1cxWj8-0000e9-F4 (Exim 4.72) for dnsop@ietf.org (return-path ); Mon, 10 Apr 2017 11:39:18 +0100 To: dnsop@ietf.org References: <20170407181139.GB66383@isc.org> <86FE867E-E1BE-4427-9FB2-D148B3F9C8C2@powerdns.com> From: Ray Bellis Message-ID: <8d63caf5-f2ce-0d0a-e431-42e4b704ab14@bellis.me.uk> Date: Mon, 10 Apr 2017 11:39:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <86FE867E-E1BE-4427-9FB2-D148B3F9C8C2@powerdns.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 10:39:23 -0000 On 10/04/2017 11:04, Peter van Dijk wrote: > Why this is not possible seems obvious to me, but we’ll see what we can > write. Many TLD registries simply don't permit CNAMEs instead of delegations for their customer domains. The only one I've heard of that does is .de Ray From nobody Mon Apr 10 03: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 0DEB5120724 for ; Mon, 10 Apr 2017 03:53:42 -0700 (PDT) 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 Wh7dQxSGVyJr for ; Mon, 10 Apr 2017 03:53:41 -0700 (PDT) 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 CD5EB12441E for ; Mon, 10 Apr 2017 03:53:40 -0700 (PDT) Received: from [46.227.151.81] (port=52154 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 1cxWx0-0000vR-DQ (Exim 4.72) for dnsop@ietf.org (return-path ); Mon, 10 Apr 2017 11:53:38 +0100 To: dnsop@ietf.org References: <20170407181139.GB66383@isc.org> <86FE867E-E1BE-4427-9FB2-D148B3F9C8C2@powerdns.com> <8d63caf5-f2ce-0d0a-e431-42e4b704ab14@bellis.me.uk> From: Ray Bellis Message-ID: <44ae341f-0424-14c7-2834-656991d402ac@bellis.me.uk> Date: Mon, 10 Apr 2017 11:53:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8d63caf5-f2ce-0d0a-e431-42e4b704ab14@bellis.me.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 10:53:42 -0000 On 10/04/2017 11:39, I wrote: > Many TLD registries simply don't permit CNAMEs instead of delegations > for their customer domains. > > The only one I've heard of that does is .de My real point being that the parent / child relationship can have policy rules in place that prevent things that are technically completely possible. Ray From nobody Mon Apr 10 04:12: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 2239512946F for ; Mon, 10 Apr 2017 04:12:58 -0700 (PDT) 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, WEIRD_PORT=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 1XyRo-yuhO3B for ; Mon, 10 Apr 2017 04:12:54 -0700 (PDT) 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 6FA65126CE8 for ; Mon, 10 Apr 2017 04:12:54 -0700 (PDT) Received: from [2001:470:78c8:2::9] (helo=earth.zonnestelsel.tk) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1cxXFw-0001j4-4s; Mon, 10 Apr 2017 11:13:12 +0000 Date: Mon, 10 Apr 2017 11:12:41 +0000 From: Shane Kerr To: Petr =?UTF-8?B?xaBwYcSNZWs=?= Cc: dnsop@ietf.org Message-ID: <20170410111241.19b45fdf@earth.zonnestelsel.tk> In-Reply-To: References: <149071310862.30579.14412477244940530567@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_/upzPWJF34.svctq.fKusxUN"; protocol="application/pgp-signature" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-wireformat-http-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 11:12:58 -0000 --Sig_/upzPWJF34.svctq.fKusxUN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Petr, At 2017-04-07 09:38:05 +0200 Petr =C5=A0pa=C4=8Dek wrote: > Hello, >=20 > On 28.3.2017 16:58, 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. > >=20 > > Title : DNS wire-format over HTTP > > Authors : Linjian Song > > Paul Vixie > > Shane Kerr > > Runxia Wan > > Filename : draft-ietf-dnsop-dns-wireformat-http-01.txt =20 >=20 > Version draft-ietf-dnsop-dns-wireformat-http-01 is the first one I > reviewed and it is a good read. No objections to current version. >=20 > Are there any implementations? There are two and a half implementations, one in C by Paul Vixie and one in Go by BII, plus a client-side version in Javascript (ug) by me. https://github.com/BII-Lab/DNSoverHTTP https://github.com/BII-Lab/DNSoverHTTPinGO http://www.blij.tk:8888/ Cheers, -- Shane --Sig_/upzPWJF34.svctq.fKusxUN Content-Type: application/pgp-signature Content-Description: OpenPGP digitale handtekening -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdhRx2J+MnJeBOVlgNzKXnPlnswYFAljraKkACgkQNzKXnPln swaA6w//X/bCF/yDUBYdDuFh3lampIqiSF/mdmBQMNbsWE629SlaaMZ0iFzHDJah WvlV1p7gowpNeFre8nK25++dXXXaBcEeS7s+KEkWuIsc7FudmagxkykUeXF6TYq1 HoKnixlfohzmHZFobJRe0tuQnoomwUYj5oMsSwHv565n1CBG1dcVSAjaDex4mqF+ PkXRGatxvGWFDiKvvHDRVc8aC/A3UtxNhGD6GPJEwF9jDXRkQ4IbWvcBc5c2AI+V ntmlDeyQGr7n1Wk8YriInrUwisjM5Nq3IhjGVfwFFL02duH9VId414SBjn+0Yz4a pn7gnS1NtJrRX/IXl3RwgZkm3WPd0lFvN1aiYT1K6M5SSZ49D+HSSwPsHWCXkV5J AqJzLc7s1Md0HR60S6ruPCRJsh1GAgcMPUsyFwy2kuGPUza8jaz4Z+xCnPU+eY1o kmpMJw1s0LTmxFk+CnS7UmXS0W5VHhrI8EOuGvKGe9sdAaFdULq6fdrjeb3YPLJb AjGaicECB2v42rb7tHSaiTNz84lG18Bqnt4FZS0TpyI8yK3CAy9QjaGVPSnNEnJy f2MUv9HMklkvfKBCE0eTrHjnuDlIsrQf/BHHGYvd4gbi05ksOziv4vDLCs1vySx9 xw9jMytfhJB4ZJuuh0Z+ghHAHfjtgCgjYf5dFR5WEE74ZPvUyQ8= =Xpve -----END PGP SIGNATURE----- --Sig_/upzPWJF34.svctq.fKusxUN-- From nobody Mon Apr 10 05: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 B5E401294B8 for ; Mon, 10 Apr 2017 05:29:45 -0700 (PDT) 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 tMH8zZQgpd5i for ; Mon, 10 Apr 2017 05:29:44 -0700 (PDT) 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 369F91294B2 for ; Mon, 10 Apr 2017 05:29:44 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 2894D611EC; Mon, 10 Apr 2017 14:29:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1491827382; bh=RE/MYxUj7tLAHOow0uHlTtwuVosqqBHyaOlbolC0IZ8=; h=Date:From:To; b=FhSHMlY1EaxSEqRcXkd9Ic0QM7C6MsRyVE33HtdDJ8FnrYdRPuXSvaEoR6r2vG3C2 NpJ7H6HQFvSKheUu1PwNHR8hBkQeMJKFAqMTiLq6Ew+f5xBZ6UsUj35PcOLHZ6dJz9 dikWbCHcGKRPf2TSVlDQzLD4Zoy5No3cEZOQxhkU= Date: Mon, 10 Apr 2017 14:29:42 +0200 (CEST) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: dnsop Cc: knot-dns@labs.nic.cz Message-ID: <951801333.6319.1491827382096.JavaMail.zimbra@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - SAF10 (Linux)/8.7.0_GA_1659) Thread-Index: YQtnmscmlVIV2onJYoHYurn4oA05NQ== Thread-Topic: Clarification: Complete or not-complete RRSets in AUTHORITY section? (non-DNSSEC) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: [DNSOP] Clarification: Complete or not-complete RRSets in AUTHORITY section? (non-DNSSEC) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 12:29:46 -0000 Hi there, I am seeking clarification on NS RRSet completeness in AUTHORITY section as we are tackling one particular RPL test from Unbound (iter_pcname.rpl). Imagine a situation where parent (.net/.com NS) gives this glue: QUESTION .example.com. IN A ANSWER AUTHORITY example.com. IN NS ns.example.net. example.com. IN NS ns.example.com. ADDITIONAL ns.example.net. IN A 10.0.0.1 ns.example.com. IN A 10.0.0.2 ~~~ ns.example.net. gives QUESTION www.example.com. IN A ANSWER www.example.com. IN A 10.10.10.1 AUTHORITY example.com. IN NS ns.example.com. ADDITIONAL ns.example.com. IN A 10.0.0.2 ~~~ ns.example.com. just returns SERVFAIL ~~~ And resolver is asked to resolve: Step 1: www.example.com. -> OK, returns 10.10.10.1 Step 2: mail.example.com. -> SERVFAIL, because the NS RRset has been overwritten by www.example.com ANSWER data from AUTHORITY due RFC 2181 5.4.1 Ranking: > Data from the authority section of an authoritative answer, Thus only ns.example.com. is asked and it SERVFAILs. ~~~ In my understanding it should be ok to return SERVFAIL, because there's no way to honor the 5.4.1 Ranking and not fail. Or am I missing something really obvious? Ondrej -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- From nobody Mon Apr 10 06:07: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 9E695129494 for ; Mon, 10 Apr 2017 06:06:58 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 acV1B1C9issP for ; Mon, 10 Apr 2017 06:06:56 -0700 (PDT) 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 B0B9D1294B7 for ; Mon, 10 Apr 2017 06:06:55 -0700 (PDT) Received: from [2001:b98:204:102:fffa::9] (port=51503) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1cxZ1x-0005My-8B for dnsop@ietf.org; Mon, 10 Apr 2017 14:06:54 +0100 From: Sara Dickinson Content-Type: multipart/alternative; boundary="Apple-Mail=_85642834-8624-415C-AAC6-4EBB5F4132FB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Apr 2017 14:06:44 +0100 References: <149073324374.1336.11092995826852304276.idtracker@ietfa.amsl.com> To: IETF DNSOP WG In-Reply-To: Message-Id: <6B544081-B18D-41F7-BFAB-CA9CB4D15EC0@sinodun.com> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 13:06:59 -0000 --Apple-Mail=_85642834-8624-415C-AAC6-4EBB5F4132FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 6 Apr 2017, at 19:42, Bob Harold wrote: >=20 >=20 > On Tue, Mar 28, 2017 at 4:34 PM, IETF Secretariat = > wrote: >=20 > The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in > state > Candidate for WG Adoption (entered by Tim Wicinski) >=20 > The document is available at > = https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements= / = >=20 >=20 > I support adoption +1 > and will review. Me too.=20 Sara.=20= --Apple-Mail=_85642834-8624-415C-AAC6-4EBB5F4132FB Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 6 Apr 2017, at 19:42, Bob Harold <rharolde@umich.edu> wrote:


On Tue, Mar 28, 2017 at 4:34 PM, IETF Secretariat <ietf-secretariat-reply@ietf.org> wrote:

The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in
state
Candidate for WG Adoption (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/


I support adoption

+1

and will review.

Me too. 

Sara. 
--Apple-Mail=_85642834-8624-415C-AAC6-4EBB5F4132FB-- From nobody Mon Apr 10 06:36: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 5C7491294E0 for ; Mon, 10 Apr 2017 06:36:07 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbiw.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzVRWBRf8DAN for ; Mon, 10 Apr 2017 06:36:06 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 01C94129498 for ; Mon, 10 Apr 2017 06:29:59 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v3ADWAsq001995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 10 Apr 2017 06:32:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bbiw.net; s=default; t=1491831131; bh=XDwY7ETVD9PfnhTKOB8sdu4Ug0P8gqxeoDZeQCv6YCQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DxaLp1yBJc5jKjqtHO7FJfcw6zeQhe7AllZDi7jJ34L+LZWd0MctDWk+Q3BM2gOm5 c01Dqes17IcSQDZR+ry3ZaoTr98bg1trzb88FMUhjn61mW5ckCkC4m3rXS934Cexdo 70OOmT+zmW/F1ejLeh9OyRFy028yK9pUUdJeFPy0= To: Stephane Bortzmeyer , dnsop@ietf.org References: <149080054550.26806.17675916795295413492@ietfa.amsl.com> <20170331155217.GA19647@laperouse.bortzmeyer.org> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <88b97201-4a1d-5378-7f8a-907abe0943bc@bbiw.net> Date: Mon, 10 Apr 2017 06:29:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170331155217.GA19647@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] Registration requirement (Was: Re: I-D Action: draft-ietf-dnsop-attrleaf-02.txt) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 13:36:07 -0000 On 3/31/2017 8:52 AM, Stephane Bortzmeyer wrote: > On Wed, Mar 29, 2017 at 08:15:45AM -0700, > internet-drafts@ietf.org wrote > a message of 43 lines which said: > >> Title : DNS Scoped Data Through Global '_Underscore' Naming of Attribute Leaves >> Author : Dave Crocker >> Filename : draft-ietf-dnsop-attrleaf-02.txt > > Section 5 "IANA considerations" does not use the names of standard > policies. draft-leiba-cotton-iana-5226bis, currently in the RFC editor Thanks. I hadn't registered that issue... > queue, says "It is not strictly required that documents use these > terms [the standard policies]; the actual requirement is that the > instructions to IANA be clear and unambiguous. However, use of these > terms is strongly recommended because their meanings are widely > understood." > > Therefore, I suggest to replace "have been specified in any published > RFC, or are documented by a specification published by another > standards organization" by "specification required (RFC 5226bis, > section 4.6). Hmm. The IANA draft's 'Specification Required' (Section 4.6) imposes a requirement both for a designated expert AND the existence of a publicly published spec. My original thought was that this registry should have a concern for stability of the reference using it, but not impose much of a barrier in terms of quality. (I figured that the other document's standards criteria would suffice for that.) While some registries do need careful quality control for each entry, this doesn't seem like it should be one of them. The namespace is essentially infinite, so we don't have to worry about exhaustion, and I don't see much downside in letting the market decide whether the entry is useful. So on reflection, I'm starting to wonder about instead going to the lesser First Come First Served (Section 4.4 of the IANA draft). This should encourage early (pre-standards) registration. It also should cover established practice that doesn't provide the level of documentation one would wish for. Which fact you've nicely documented next... Thoughts? > Also, the proposed initial registry includes: > > SPF | _spf | "TXT" | [RFC7372] > > RFC 7372 contains *nothing* about that, and SPF (RFC 7208) does not > use undesrscore names. (Yeah. RFC 7372 is wrong. It should be RFC 7208. However...) 1. RFC 7208 notes the TXT ambiguity problem 3. SPF Records ... Since TXT records have multiple uses, beware of other TXT records published there for other purposes. They might cause problems with size limits (see Section 3.4), and care has to be taken to ensure that only SPF records are used for SPF processing. 2. It requires use of TXT 3.1. DNS Resource Records SPF records MUST be published as a DNS TXT 4. All of the examples that explicit show the TXT RR show domain names that do NOT use a _spf node name. (sigh) 5. However the document also is littered with examples of using ._spf. (sigh) 6. And finally, industry documentation for SPF is loaded with directions for use of ._spf. E.g., http://www.openspf.org/FAQ/Common_mistakes Sometimes an ISP will create a special SPF record that customers can include with their record, such as _spf.example.com. So we have extensive, established practice, though one could wish for a (much) better specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Apr 10 07:16: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 23D66129515 for ; Mon, 10 Apr 2017 07:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.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 Td2U9X3ybbI6 for ; Mon, 10 Apr 2017 07:16:28 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 9530F129506 for ; Mon, 10 Apr 2017 07:16:28 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id q26so36086450uaa.0 for ; Mon, 10 Apr 2017 07:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=7ADWCkZSSqmF5CADalv/xPBPksz8ivShqGlxwKLBg1k=; b=ZoSCd7A/mbDsbxUNf1KLm7f0SAufxR80g9SDkLNivH7nFm9n5P5v7WZ9UMyaeX7kt+ Wi/Vd3GkOflqndUR085pztZWYJn9zyXZnbyzT0XUyu3enDkx7ZxDxdoKGHk4RUVlxrHy gv0cfHGoieOAFLLaFK+JvW9Rq2AKrRKuCsA1k= 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:cc; bh=7ADWCkZSSqmF5CADalv/xPBPksz8ivShqGlxwKLBg1k=; b=dgqoix1nnhZ2cVCNxAYbiQllg0YgLnpBCXTFkaBA6V+lu8XqpLc3wyrNq5wq1Xg2AW YVrcd9R+Bc+HpPGa7AgUw32+ONLwtMcYZljmJb1mYPO+s6Bnx6g0+8skx30JPwD1bpD4 /aHc2G2903TMapASYrpOn3CjktB1EFD4sHsn7W2+nO2uP0VA+Uic/M6owurPpHY7DWdF 1UObY7H2PvN2Nm35HgnKXMSdwqOE9ja3mKoGN+hUCq8VMSjtXeCO7ZXfwSn2Zp+Ylnjf sQ4UZKDUBj8gUwy0gnTJ87abB5mKvJUaig9b9FpednjunfBE5+i8mZZvNEB1jEO6VR/q fGGA== X-Gm-Message-State: AN3rC/6G7zfqyZ/2+JpLEd+HMUd0yEQzyURrYtbGmANJLPlz2V0pPWLCuY+CqgW6GWUr1rd9SkWQlXusuX8YAw== X-Received: by 10.176.3.182 with SMTP id 51mr1580350uau.66.1491833787384; Mon, 10 Apr 2017 07:16:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.33.74 with HTTP; Mon, 10 Apr 2017 07:16:06 -0700 (PDT) X-Originating-IP: [2001:1ae9:282f:2400:4938:427:61fc:936] In-Reply-To: <20170407181139.GB66383@isc.org> References: <20170407181139.GB66383@isc.org> From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Date: Mon, 10 Apr 2017 16:16:06 +0200 Message-ID: Cc: dnsop@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:16:30 -0000 On Fri, Apr 7, 2017 at 8:11 PM, Evan Hunt wrote: > Here's the new ANAME draft I mentioned last week. Hey, thanks for this one! I support the attempt to define a record type that would cover the existing vendor-specific types that synthesize A/AAAA records in zone apex. If this gets adopted by the vendors, it means possible zone transfers between these providers. On the other hand, I don't like the part which moves ANAME processing to resolvers. I'll comment on that separately. Besides that, The Security Section should warn DNS operators that ANAME may be misused to leak data from any internal networks the server is part of. This was so far concern for resolvers, but with ANAME it may become a concern for authoritative servers as well. Jan From nobody Mon Apr 10 07:38: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 F1CC412944F for ; Mon, 10 Apr 2017 07:38:16 -0700 (PDT) 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 AJy7DuKNl_oq for ; Mon, 10 Apr 2017 07:38:14 -0700 (PDT) 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 BB4F5128CFF for ; Mon, 10 Apr 2017 07:38:14 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id c45so64720076qtb.1 for ; Mon, 10 Apr 2017 07:38:14 -0700 (PDT) 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=/GcjjI9ydb+0QCrUnCf1DxFQwEVpGRl7YUzll6RGw9w=; b=kINFLHva0d+o7s/4TH1/iklC69y0vXvHcISUIDRvfMqr8qILkrysbZH74KfEmDLZcX 2tanqM6/HpLJ3PiQXwj/4HaCsEdIrFBzUdZw4WCFbrxOEVpl3P/oseW16rWa94qU2mKN euemzxhSf2uoP9ueUSAwk49RJSNYagmEeCe5+wH3Hq10PqPXBsxKkOjNBfEMqOMjj0er TLWUCYmzOAvzgX6nPpp/+HnuOdOvxpR6Jp4b7O/aRTOG/N3EsdLBfYshupy1h5L3AzNj cnX78Y8KMLB/WE8aSaxsegbNR5papkxHI8+ng29Zc2voseAbOt6Dl0od4hXaUOIQ0BEs VmjQ== 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=/GcjjI9ydb+0QCrUnCf1DxFQwEVpGRl7YUzll6RGw9w=; b=d8cx384vJHTIGpkdxbtMrG7cY1llrCklp+k+AEId5ivm/Zn19KZcxJelg/2vAGbenE 0hrY9BxAqU2lgh4CTH8o6HHMlU1TdXbWXbyi3C93aiKlRXpPlfa4cXtFF8jcV5HN9bQE 55J4BJLk823VxL8R14mS3+jP9k9yyAr7B4RQYNsMp/4dZOu8fHrFTUyFB6URXxQV9Rkx f8s0RuGbJc9N4Gox40ZAUKGmvXrXSOBt3/jiL1A/eqcHgPC7idch1FkbDiScjIwIbAsz OXy5nYJqW0W8Z8BVXuOjxBk5mBvxn3CKROCLwx7lGoofhoxESNm4xz8SUWNtQ53hdQbE L+RQ== X-Gm-Message-State: AN3rC/6UWRJkGgUyjf2Pu1SyA59KNI56guarkojwuvACmrBFhgv214Ikc7ydpZTNlBAJvg== X-Received: by 10.200.55.86 with SMTP id p22mr8061304qtb.167.1491835093431; Mon, 10 Apr 2017 07:38:13 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:e13b:ccff:f4d6:c26c? ([2601:18f:801:600:e13b:ccff:f4d6:c26c]) by smtp.gmail.com with ESMTPSA id 127sm8857156qkf.64.2017.04.10.07.38.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 07:38:12 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Apr 2017 10:38:09 -0400 References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> To: dnsop In-Reply-To: Message-Id: <2CB23C57-AB73-483B-AE9F-834A933D3EC6@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] extended deadline Re: WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:38:17 -0000 I see that draft-ietf-dnsop-alt-tld-08 gives the intended status of the = document as Informational, while it is listed in the datatracker as "In = WG Last Call: Proposed Standard". =20 There are arguments in favor of each status. The relevant text is in = section 5 of RFC 6761: An IETF "Standards Action" or "IESG Approval" document specifying some new naming behaviour, which requires a Special-Use Domain Name be reserved to implement this desired new behaviour, needs to contain a subsection of the "IANA Considerations" section titled "Domain Name Reservation Considerations" giving answers in the seven categories listed below. Publishing draft-ietf-dnsop-alt-tld-08 as Proposed Standard meets the = "Standards Action" requirement. However, Proposed Standard may not be = appropriate for draft-ietf-dnsop-alt-tld-08, as the document does not = specify a new protocol, as such. draft-ietf-dnsop-alt-tld-08 does = specify certain behaviors for components of the Internet, which could be = thought of as providing for interoperability so that Proposed Standard = status would be appropriate. On the other hand, publishing draft-ietf-dnsop-alt-tld-08 as = Informational would require an "IESG Approval" document to meet the = requirements of RFC 6761. A short sentence added to = draft-ietf-dnsop-alt-tld-08 is likely all that would be needed, to the = effect of "The IESG has reviewed this document and approves of the = request to add .alt to the Special Use Domain Names registry." In any event, in my opinion the WG needs to express its explicit = consensus about its choice of intended status for = draft-ietf-dnsop-alt-tld-08. - Ralph > On Apr 7, 2017, at 9:38 AM, Suzanne Woolf = wrote: >=20 > Hi, >=20 > We had initially scheduled the WGLC on this document to be over by = now. However, the flurry of activity around the review we were asked to = do on the homenet-dot draft, and the general traffic level on the list = during IETF 98, suggested to the chairs that we should extend the WGLC. >=20 > We=E2=80=99re hereby formally extending it to next Wednesday, April = 12. >=20 > As always for WGLC=E2=80=94 we need to hear both support and = opposition for taking this draft to the next step in the process. >=20 > thanks, > Suzanne & TIm >=20 >=20 >> On Apr 1, 2017, at 4:17 PM, Stephane Bortzmeyer = wrote: >>=20 >> On Sun, Mar 12, 2017 at 07:20:55PM -0400, >> Suzanne Woolf wrote=20 >> a message of 92 lines which said: >>=20 >>> This message opens a Working Group Last Call for: >>>=20 >>> "The ALT Special Use Top Level Domain" >>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ = >>=20 >> I've read -08 and I believe I understand this draft. I'm not = convinced >> it's useful (most users of alternative resolution systems won't use = it >> and, anyway, I'm not even sure it will be added in the Special-Use >> registry, which was wrongly frozen by the IESG) but I don't see big >> issues with the draft, it seems to me it correctly describes the new >> TLD. >>=20 >> Editorial : >>=20 >> Section 1: >>=20 >> "and that should not be resolved" I cannot parse it. Missing "it"? >>=20 >> Section 5 : >>=20 >> After "and anyone watching queries along the path", add a reference = to >> RFC 7626? >>=20 >> Normative references: >>=20 >> Why is RFC 6303 a normative reference? It is no longer used. >>=20 >> Why is RFC 7686 a normative reference? It is just an example. >>=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Apr 10 07:44: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 4E54B129508 for ; Mon, 10 Apr 2017 07:44:56 -0700 (PDT) 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 zfhmDwmdt0Tj for ; Mon, 10 Apr 2017 07:44:54 -0700 (PDT) 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 637A4129440 for ; Mon, 10 Apr 2017 07:44:52 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id v3so57529696qtd.3 for ; Mon, 10 Apr 2017 07:44:52 -0700 (PDT) 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=wbXq6xst9W3XwHcEcy5B2jt0cPdQHewEchOPKwfbuHo=; b=nZ2CgEedn08E7NAfRXwdC2V8hI++UJ7gVq35jt6KeIxv97MTNn5ipKu19bZ+VVSY1l flMMkyF00HE0PsnaZE31iBUmeU9wfjb98PD7b0cp743xvduo40CdPE5yU8niGtMQMQXf tInaA6rWc4iaVdTQNmpm2eAirjSNo8E+Rqwq2vTaAr3MmlDkey4CDb2LB9kuNHkwB03d +zTDHqmlfNn4MInTfjQd5XSW9QlvDlvF78RIgiG0mdQl6GdybcdOFoPp8XiaRc3AJnmM EosOsOmCgjT+GzBTLxfvrw/RRXJH3dPAwZsgOSWtIxcxqjaCzDHRoLwPBQ5z0FWH5kc3 pkGQ== 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=wbXq6xst9W3XwHcEcy5B2jt0cPdQHewEchOPKwfbuHo=; b=H8DU9TSrVs4MWa8GqcQteLMQQFtxlxKaNJ65HDE5gzkNa996iLKgmHPZ9e/j6HZlUL pHG5J94urdVaD2Xox6VKXdnEuhKk7tT2xJW9fvFVyglytI7gowI9VkZIeDwdOILmmDOa 5C82bGl1gGp+Ad8pwxJbCNDnuZfFKLXoJy4qYHjmnyc1+tmxRaq13hkukk9MKqYkmAsS QT8gCA8UXxWlXgsLdnBrnTR0nZZY6nYnppllwIsVnXVT5aiEWpr1n1+cNsN5epGPs7Dx FSDVDabyh6se4PEl0fwKcLvJgCnfrhc9qcO+oQAlVqrtB6rDDcg2ITQa1oTQXxo5wAfZ aChg== X-Gm-Message-State: AN3rC/5hnqlSmXJO2q0XSge2FbuFPcRxgUs5/39RW0JhaAaG2kvsrlvm21uA5NP80lZOXoK7xIEEn3YGmWqGPqZ2 X-Received: by 10.37.215.147 with SMTP id o141mr6868078ybg.14.1491835491633; Mon, 10 Apr 2017 07:44:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.109.73 with HTTP; Mon, 10 Apr 2017 07:44:51 -0700 (PDT) In-Reply-To: <20170410093847.GA21654@jurassic> References: <20170410093847.GA21654@jurassic> From: Bob Harold Date: Mon, 10 Apr 2017 10:44:51 -0400 Message-ID: To: Mukund Sivaraman Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary=94eb2c06b7d88ae680054cd10404 Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dnssec-sha3-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:44:56 -0000 --94eb2c06b7d88ae680054cd10404 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 10, 2017 at 5:38 AM, Mukund Sivaraman wrote: > Hi all > > > A new version of I-D, draft-muks-dnsop-dnssec-sha3-01.txt > > has been successfully submitted by Mukund Sivaraman and posted to the > > IETF repository. > > > > Name: draft-muks-dnsop-dnssec-sha3 > > Revision: 01 > > Title: Use of SHA-3 (Keccak) and RSASSA-PSS in DNSSEC > > Document date: 2017-04-08 > > Group: Individual Submission > > Pages: 26 > > URL: https://www.ietf.org/internet-drafts/draft-muks-dnsop- > dnssec-sha3-01.txt > > Status: https://datatracker.ietf.org/ > doc/draft-muks-dnsop-dnssec-sha3/ > > Htmlized: https://tools.ietf.org/html/ > draft-muks-dnsop-dnssec-sha3-01 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-muks-dnsop- > dnssec-sha3-01 > > Diff: https://www.ietf.org/rfcdiff? > url2=draft-muks-dnsop-dnssec-sha3-01 > > > > Abstract: > > This document specifies the use of SHA-3 (Keccak) hash functions in > > DNSSEC. It also specifies the use of the RSASSA-PSS signature scheme > > for RSA keys. > > A new revision of the draft has been uploaded: > > - It now uses the RSASSA-PSS signature scheme (based on comments from > Paul Hoffman & Francis) and adds RSASSA-PSS/SHA3-256, > RSASSA-PSS/SHA3-384 and RSASSA-PSS/SHA3-512 for using SHA-3. > > - It adds algorithms for RSASSA-PSS/SHA2-256 and RSASSA-PSS/SHA2-512 to > use the SHA-2 algorithms with RSASSA-PSS. > > - It adds algorithms for ECDSA/SHA3-256 and ECDSA/SHA3-384. > > - It now has a better problem statement in the introduction (based on > contents of reply from Paul Hoffman) > > - BIND implementation has been updated here: > https://github.com/muks/bind9/tree/sha3 > > - An independently written ldns implementation is here: > https://github.com/tjeb/ldns > > Mukund > Looking at the diff https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dnssec-sha3-01 is difficult because some of the DNSSEC example lines are not wrapped. I don't know if that can be fixed. -- Bob Harold --94eb2c06b7d88ae680054cd10404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 10, 2017 at 5:3= 8 AM, Mukund Sivaraman <muks@isc.org> wrote:
Hi all

> A new version of I-D, draft-muks-dnsop-dnssec-sha3-01.txt
> has been successfully submitted by Mukund Sivaraman and posted to the<= br> > IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-muks-dnsop-dnssec-sha3 > Revision:=C2=A0 =C2=A0 =C2=A001
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Use of S= HA-3 (Keccak) and RSASSA-PSS in DNSSEC
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-04-08
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 26
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-muks= -dnsop-dnssec-sha3-01.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-muks-dnsop-dnssec-= sha3/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://tools.ietf.org/html/draft-muks-dnsop-dnssec-sha3-01 > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dnssec-sha3-01
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-muks-dnsop= -dnssec-sha3-01
>
> Abstract:
>=C2=A0 =C2=A0 This document specifies the use of SHA-3 (Keccak) hash fu= nctions in
>=C2=A0 =C2=A0 DNSSEC.=C2=A0 It also specifies the use of the RSASSA-PSS= signature scheme
>=C2=A0 =C2=A0 for RSA keys.

A new revision of the draft has been uploaded:

- It now uses the RSASSA-PSS signature scheme (based on comments from
=C2=A0 Paul Hoffman & Francis) and adds RSASSA-PSS/SHA3-256,
=C2=A0 RSASSA-PSS/SHA3-384 and RSASSA-PSS/SHA3-512 for using SHA-3.

- It adds algorithms for RSASSA-PSS/SHA2-256 and RSASSA-PSS/SHA2-512 to
=C2=A0 use the SHA-2 algorithms with RSASSA-PSS.

- It adds algorithms for ECDSA/SHA3-256 and ECDSA/SHA3-384.

- It now has a better problem statement in the introduction (based on
=C2=A0 contents of reply from Paul Hoffman)

- BIND implementation has been updated here:
=C2=A0 https://github.com/muks/bind9/tree/sha3

- An independently written ldns implementation is here:
=C2=A0 https://github.com/tjeb/ldns

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mukund

Looking at the diff
https://ww= w.ietf.org/rfcdiff?url2=3Ddraft-muks-dnsop-dnssec-sha3-01
=
is difficult because some of the DNSSEC ex= ample lines are not wrapped.
I don't kn= ow if that can be fixed.

--=C2=A0
Bob Harold


=
--94eb2c06b7d88ae680054cd10404-- From nobody Mon Apr 10 08:09: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 6266E1294F0 for ; Mon, 10 Apr 2017 08:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1F7q_iey1c4q for ; Mon, 10 Apr 2017 08:09:23 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id E9E6E1275C5 for ; Mon, 10 Apr 2017 08:09:22 -0700 (PDT) Received: from jurassic (unknown [115.117.162.37]) (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 08A1A56A0035; Mon, 10 Apr 2017 15:09:20 +0000 (GMT) Date: Mon, 10 Apr 2017 20:39:18 +0530 From: Mukund Sivaraman To: Bob Harold Cc: IETF DNSOP WG Message-ID: <20170410150917.GA22210@jurassic> References: <20170410093847.GA21654@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dnssec-sha3-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 15:09:24 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Bob On Mon, Apr 10, 2017 at 10:44:51AM -0400, Bob Harold wrote: > Looking at the diff > https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dnssec-sha3-01 > is difficult because some of the DNSSEC example lines are not wrapped. > I don't know if that can be fixed. We kind of restarted the draft adopting RSASSA-PSS, so please can you review it this time from scratch without looking at the diff? Many of the examples will need updating once algorithm numbers are assigned for them (as for some calculations, the algorithm number is an input), so we didn't spend time on wrapping the long lines in this revision. Mukund --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY66AcAAoJEB9EXrAiC5LsAtMP/RyD5LV3ZrH+ze5iqCsjeLAv DLUi6Kik1DHCttWGFBYj9fJLaoZCSrLyZxzbK6lVgRLdEeLgZrqI/uiIEE7jVZQU 4Y/Fl6W5EDptQeEaytPPffEp/MUCLKGuqN8YEcIpD5Ch80NfY85z2uvKcmQ8rE+B KkL59TM8xumMw6HbZ8aHsS/jbeOSDoE9S5ni0hUso2CjQE0YS8glHdoWlVHLg56Z 1OE8eYuco7p+++ux60ejvnDG24w7xNox31OvqgjdpybL4rShFN6ia6J05TlfZUs6 ZtJFKYpeAol22DiE7FulibueDKptPZbT+xYzqyKnEfRI4+HE7LyGus2xSIToJYut akeaFs9Y3d7xteEZlUnuMOAMINWp1kAt7AEh+43apTiXfCRXb/DHS+8Uyaq7AQq4 caAGWcX0+SBnneD60O8ulJIQ0R4OIxaTUnJXpHfcyrjbQ/xkvfEDE7+HZQoZ4c5u 7RzWmf132DSb/iV9jkcDYLbUPyku5n7DnQW2+J9Nn9ivKDGXUY6s2mY/ZT0/3Cna SGQV2tBQwQHcvZuDkVwYCwpdoo+JlbrqvoYrLP1qmKoLjE8xLEPlRy3m6uRpblBE j1k++Cn/UuMyp6hLFWC9SN39M5ZXPS4xOFfhc5q2ZCxZRX6Mkd11r8LvP5xXfPE0 JgoHnB/2e8bgc54BLZgT =O5nc -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From nobody Mon Apr 10 08:10: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 8D3BD129533 for ; Mon, 10 Apr 2017 08:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 fCz1OzjtC_9h for ; Mon, 10 Apr 2017 08:10:34 -0700 (PDT) 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 D8A761294F6 for ; Mon, 10 Apr 2017 08:10:30 -0700 (PDT) Received: (qmail 37779 invoked from network); 10 Apr 2017 15:10:29 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Apr 2017 15:10:29 -0000 Date: 10 Apr 2017 15:10:07 -0000 Message-ID: <20170410151007.65659.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: ray@bellis.me.uk In-Reply-To: <44ae341f-0424-14c7-2834-656991d402ac@bellis.me.uk> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 15:10:38 -0000 In article <44ae341f-0424-14c7-2834-656991d402ac@bellis.me.uk> you write: >> Many TLD registries simply don't permit CNAMEs instead of delegations >> for their customer domains. >> >> The only one I've heard of that does is .de > >My real point being that the parent / child relationship can have policy >rules in place that prevent things that are technically completely possible. True, but the most common broken CNAME I see is something like this: example.com MX 0 mail.example.com example.com CNAME www.example.com www.example.com A 1.2.3.4 I agree that if we go ahead with this document, a paragraph pointing to the ways that CNAMEs don't solve the problem would be helpful. R's, John From nobody Mon Apr 10 08:23: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 5D30E1294F0 for ; Mon, 10 Apr 2017 08:23:24 -0700 (PDT) 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 JQvlKcnshlQl for ; Mon, 10 Apr 2017 08:23:23 -0700 (PDT) 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 3284D129501 for ; Mon, 10 Apr 2017 08:23:23 -0700 (PDT) Received: (qmail 39643 invoked from network); 10 Apr 2017 15:23:22 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Apr 2017 15:23:22 -0000 Date: 10 Apr 2017 15:23:00 -0000 Message-ID: <20170410152300.65721.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <88b97201-4a1d-5378-7f8a-907abe0943bc@bbiw.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] Registration requirement (Was: Re: I-D Action: draft-ietf-dnsop-attrleaf-02.txt) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 15:23:24 -0000 >So on reflection, I'm starting to wonder about instead going to the >lesser First Come First Served (Section 4.4 of the IANA draft). This >should encourage early (pre-standards) registration. I agree FCFS makes sense. As you note the supply of names is effectively unlimited, so squatting isn't a big deal. >It also should cover established practice that doesn't provide the level >of documentation one would wish for. Which fact you've nicely >documented next... Right, we can add _spf and the enumservice names with hand waves about the places they're sorta but not very well described. R's, John From nobody Mon Apr 10 10:35: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 BA11F120227 for ; Mon, 10 Apr 2017 10:35:19 -0700 (PDT) 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 UTMQlWu0aJe0 for ; Mon, 10 Apr 2017 10:35:17 -0700 (PDT) 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 81E6B129A9D for ; Mon, 10 Apr 2017 10:35:15 -0700 (PDT) Received: from [169.254.150.39] (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 v3AHYwKI026490 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Apr 2017 10:34:59 -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 [169.254.150.39] From: "Paul Hoffman" To: "Ralph Droms" Cc: dnsop Date: Mon, 10 Apr 2017 10:35:12 -0700 Message-ID: In-Reply-To: <2CB23C57-AB73-483B-AE9F-834A933D3EC6@gmail.com> References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> <2CB23C57-AB73-483B-AE9F-834A933D3EC6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] extended deadline Re: WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:35:20 -0000 On 10 Apr 2017, at 7:38, Ralph Droms wrote: > I see that draft-ietf-dnsop-alt-tld-08 gives the intended status of > the document as Informational, while it is listed in the datatracker > as "In WG Last Call: Proposed Standard". > > There are arguments in favor of each status. The relevant text is in > section 5 of RFC 6761: > > An IETF "Standards Action" or "IESG Approval" document specifying > some new naming behaviour, which requires a Special-Use Domain Name > be reserved to implement this desired new behaviour, needs to > contain > a subsection of the "IANA Considerations" section titled "Domain > Name > Reservation Considerations" giving answers in the seven categories > listed below. > > Publishing draft-ietf-dnsop-alt-tld-08 as Proposed Standard meets the > "Standards Action" requirement. However, Proposed Standard may not be > appropriate for draft-ietf-dnsop-alt-tld-08, as the document does not > specify a new protocol, as such. draft-ietf-dnsop-alt-tld-08 does > specify certain behaviors for components of the Internet, which could > be thought of as providing for interoperability so that Proposed > Standard status would be appropriate. > > On the other hand, publishing draft-ietf-dnsop-alt-tld-08 as > Informational would require an "IESG Approval" document to meet the > requirements of RFC 6761. A short sentence added to > draft-ietf-dnsop-alt-tld-08 is likely all that would be needed, to the > effect of "The IESG has reviewed this document and approves of the > request to add .alt to the Special Use Domain Names registry." > > In any event, in my opinion the WG needs to express its explicit > consensus about its choice of intended status for > draft-ietf-dnsop-alt-tld-08. Given that most people don't understand the difference between levels, it would take less explanation to make this Standards Track to meet "Standards Action" in RFC 6761. But if people want to leave this as Informational, I agree with Ralph that a sentence like he has given (probably at the end of the Introduction) would be needed for clarity. --Paul Hoffman From nobody Mon Apr 10 11:41: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 6C3DD129AAA for ; Mon, 10 Apr 2017 11:41:07 -0700 (PDT) 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=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 Xm2BpRJHRB9c for ; Mon, 10 Apr 2017 11:41:06 -0700 (PDT) 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 D0E93127601 for ; Mon, 10 Apr 2017 11:33:22 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id n46so38780649qta.2 for ; Mon, 10 Apr 2017 11:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=p7nU3WUajHTIctiuo1Imb0ximqa+4vFEs4Em5Hwx7Uw=; b=D7ohSTOu0sFtpvxyaYf5tWUBVRFf7njvF3OQlxMtRQ7RfIPaMQVlE0Lp6L2csIuz+Z hAE1n5BjKgyy5C5abUM9pW5nztot8VLtzJ8BjE9pn8jRLJO3VhiZLV248xzIZkt9zNK8 kBeOOuJVND8IL+hbqaUXo+jn01rYrZu/JRTuNcE/KizGceucWpWtxNGUUQUcGdsBvNR4 x/O0byWaSq+EtmCPzaBUDCGTVBDNPmUC/3fOxoJ6jY9ZQ0Y7ofGBuzjDpOSE6uid6nOb g75hITCfovA1wuwjYFTmWGYQZKrS/y1VKf1E9czSmQDCGpTblacz7Cq4zszbP6z01AsA ZKmQ== 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:subject :message-id:date:to:mime-version; bh=p7nU3WUajHTIctiuo1Imb0ximqa+4vFEs4Em5Hwx7Uw=; b=cGU7QcS6EAAxEdR2InIGDM7buPQyBs33gYzM3KdebEZohkzTX6+h9QlGLl8bEhXcZD CQdg2tPbHapc0bYYPmOJ8kz04seyjm5VhOpekG4qCcP8/ScRxjP9wcJlqWcVWNyzphLv rSwa1Si33shjDEFf4heZmfWwEheAmpM0BEMYGYFhGzQPhBwmPCTNBXngql/VGeZkhG+J hEnFQBvAQLCJYVms2sFJ3IYqMHEft3xJf1omhPQT+BTtVuJe/LjAs7M0gwydzIt0rGlH EYkD7mxQBymjBe2joUfx9F7W9zi8qDp0FwKe+gJxS18gqxJBWFqmlZP00KAS8YLCPIR0 BLPA== X-Gm-Message-State: AN3rC/6gie1pTI+aT13dJardoZfWb+hX9lqrJIttKGETsxVKwA5PLMdDZ8bEeJsvLwPVmA== X-Received: by 10.200.56.194 with SMTP id g2mr7683779qtc.249.1491849201861; Mon, 10 Apr 2017 11:33:21 -0700 (PDT) Received: from ?IPv6:2601:181:c381:c20:719f:9aca:b96e:56bb? ([2601:181:c381:c20:719f:9aca:b96e:56bb]) by smtp.gmail.com with ESMTPSA id z32sm9290583qtg.17.2017.04.10.11.33.21 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Apr 2017 11:33:21 -0700 (PDT) From: Suzanne Woolf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 10 Apr 2017 14:33:19 -0400 To: dnsop Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [DNSOP] WGLC outcome for draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 18:41:07 -0000 Hi all, Thanks to everyone who contributed to the discussion on = draft-ietf-dnsop-sutld-ps. The process of producing it has taken longer = than we initially anticipated and sometimes been painful, but the = resulting document can serve as a basis for further discussion of = issues, tradeoffs, and ways to make things better in the area of the = IETF=E2=80=99s treatment of special use domain names. The chairs have reviewed the document, its history in the WG, and the WG = last call, and we find consensus to advance it to the IESG, intended for = publication as an Informational RFC.=20 As we noted to the WG in Chicago, Warren would normally be the Area = Director responsible for a draft from DNSOP, but as he=E2=80=99s an = editor on this draft, another IESG member will be asked to oversee the = next steps instead. best, Suzanne & Tim From nobody Mon Apr 10 14:44: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 12E50128B38 for ; Mon, 10 Apr 2017 14:44:32 -0700 (PDT) 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 Xg-78IkemNll for ; Mon, 10 Apr 2017 14:44:31 -0700 (PDT) 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 068E8128708 for ; Mon, 10 Apr 2017 14:44:31 -0700 (PDT) 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 B882F3493BB; Mon, 10 Apr 2017 21:44:27 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id A5487216C1E; Mon, 10 Apr 2017 21:44:27 +0000 (UTC) Date: Mon, 10 Apr 2017 21:44:27 +0000 From: Evan Hunt To: Paul Wouters Cc: dnsop@ietf.org Message-ID: <20170410214427.GA91544@isc.org> References: <20170407181139.GB66383@isc.org> <20170407224716.GB33435@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 21:44:32 -0000 On Sat, Apr 08, 2017 at 06:32:12PM -0400, Paul Wouters wrote: > > Resolvers don't ask for ANAME. They ask for A/AAAA, and get an A/AAAA > > answer, along with an ANAME record so they can go directly to the source > > and get a better answer if they support that. > > If these are the premises for ANAME, and its special handling, wouldn't > it be better to generalise asking for multiple records (eg A + AAAA > + ANAME) where ANAME has no special handling on its own? And then do the > generealised multi-query-at-once using one of the previously suggested > proposals? I must have been unclear -- I meant the slash to mean "or". This isn't about getting back multiple records. I did include a MAY in there saying that if you query for an A you can get AAAA in the additional section, and vice versa, but that's not the central point of ANAME at all. This is a mechanism for redirecting address queries. Because it's limited to address types, it can, unlike CNAME, be used at the zone apex. So the initial query is going to be for type A or type AAAA. (If we ever invent a third address family, that would count here as well.) The response is going to be an ANAME record plus the address you asked for. That address has to be looked up by the auth in case the querying resolver doesn't have ANAME support, but if the resolver *does* have ANAME support, then it repeats the lookup on its own behalf, just as it would do if it got back a CNAME. > Then people who want to ask (A + AAAA + TLSA) or (A+AAAA+SSHFP) or > (A+AAAA+IPSECKEY) could use the same mechanism. And ANAME would just be > a regular DNS record without any abnormal processing. Fine idea but not related. ANAME == CNAME for addresses. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Mon Apr 10 15:47: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 623B1126C7A for ; Mon, 10 Apr 2017 15:46:59 -0700 (PDT) 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 lvssN_dqflaH for ; Mon, 10 Apr 2017 15:46:57 -0700 (PDT) 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 4A08E127011 for ; Mon, 10 Apr 2017 15:46:55 -0700 (PDT) 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 B752824AE0A; Mon, 10 Apr 2017 22:46:50 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 13D5D160070; Mon, 10 Apr 2017 22:46:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C167D160086; Mon, 10 Apr 2017 22:46:50 +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 84_yp22jzwmZ; Mon, 10 Apr 2017 22:46:50 +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 4521C160070; Mon, 10 Apr 2017 22:46:50 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 35D406B19639; Tue, 11 Apr 2017 08:46:46 +1000 (AEST) To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Cc: dnsop , knot-dns@labs.nic.cz From: Mark Andrews References: <951801333.6319.1491827382096.JavaMail.zimbra@nic.cz> In-reply-to: Your message of "Mon, 10 Apr 2017 14:29:42 +0200." <951801333.6319.1491827382096.JavaMail.zimbra@nic.cz> Date: Tue, 11 Apr 2017 08:46:46 +1000 Message-Id: <20170410224646.35D406B19639@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Clarification: Complete or not-complete RRSets in AUTHORITY section? (non-DNSSEC) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 22:46:59 -0000 In message <951801333.6319.1491827382096.JavaMail.zimbra@nic.cz>, =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= writes: > Hi there, > > I am seeking clarification on NS RRSet completeness > in AUTHORITY section as we are tackling one particular > RPL test from Unbound (iter_pcname.rpl). > > Imagine a situation where parent (.net/.com NS) gives this glue: > > QUESTION > .example.com. IN A > ANSWER > AUTHORITY > example.com. IN NS ns.example.net. > example.com. IN NS ns.example.com. > ADDITIONAL > ns.example.net. IN A 10.0.0.1 > ns.example.com. IN A 10.0.0.2 > > ~~~ > > ns.example.net. gives > > QUESTION > www.example.com. IN A > ANSWER > www.example.com. IN A 10.10.10.1 > AUTHORITY > example.com. IN NS ns.example.com. > ADDITIONAL > ns.example.com. IN A 10.0.0.2 > > ~~~ > > ns.example.com. just returns SERVFAIL > > ~~~ > > And resolver is asked to resolve: > > Step 1: > www.example.com. -> OK, returns 10.10.10.1 > > Step 2: > mail.example.com. -> SERVFAIL, because the NS RRset has been > overwritten by www.example.com ANSWER data from AUTHORITY > due RFC 2181 5.4.1 Ranking: > > > Data from the authority section of an authoritative answer, > > Thus only ns.example.com. is asked and it SERVFAILs. > > ~~~ > > In my understanding it should be ok to return SERVFAIL, > because there's no way to honor the 5.4.1 Ranking and > not fail. Or am I missing something really obvious? SERVFAIL is fine. Why people expect the DNS to "work" when they do stupidity like this I do not know. The parent zone administrators should be complaining that the delegating NS records do not match those served by the zone. Mark > Ondrej > -- > Ondej Sur -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoe CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- > > _______________________________________________ > 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 Tue Apr 11 04: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 D25DD12945D for ; Tue, 11 Apr 2017 04:43:23 -0700 (PDT) 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 bYuHPMnylP19 for ; Tue, 11 Apr 2017 04:43:22 -0700 (PDT) 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 2B99012945B for ; Tue, 11 Apr 2017 04:43:21 -0700 (PDT) Received: from [192.168.137.1] (unknown [IPv6:2001:470:1f15:86f:51bd:39da:860d:628a]) (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 97E4FC5C23; Tue, 11 Apr 2017 13:43:18 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Tue, 11 Apr 2017 13:43:18 +0200 Message-ID: <112FC3FE-2558-46D6-ADB4-17B8E988F09B@powerdns.com> In-Reply-To: References: <20170407181139.GB66383@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 11:43:24 -0000 Hello Jan, On 10 Apr 2017, at 16:16, Jan Včelák wrote: > On Fri, Apr 7, 2017 at 8:11 PM, Evan Hunt wrote: >> Here's the new ANAME draft I mentioned last week. > > Besides that, The Security Section should warn DNS operators that > ANAME may be misused to leak data from any internal networks the > server is part of. This was so far concern for resolvers, but with > ANAME it may become a concern for authoritative servers as well. Oh good catch, thanks! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Tue Apr 11 08:45: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 25F2212EAD4 for ; Tue, 11 Apr 2017 08:45:25 -0700 (PDT) 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, 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 eoejuWTC4e8j for ; Tue, 11 Apr 2017 08:45:23 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (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 3E4B612EAD2 for ; Tue, 11 Apr 2017 08:45:23 -0700 (PDT) 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]:38020) by ppsw-41.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cxxyn-0001qA-Qm (Exim 4.89) (return-path ); Tue, 11 Apr 2017 16:45:17 +0100 Date: Tue, 11 Apr 2017 16:45:17 +0100 From: Tony Finch To: Florian Weimer cc: Evan Hunt , dnsop@ietf.org In-Reply-To: Message-ID: References: <20170407181139.GB66383@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: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 15:45:25 -0000 Florian Weimer wrote: > > I think the introduction should discuss why it is not possible to push the > CNAME to the parent zone, replacing the entire zone with an alias. You can't replace an entire zone with a CNAME if it has subdomains. ANAME records are not just for zone apexes. There are lots of other cases where address records need a different alias target from MX records, or NAPTR records, etc. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Forties, Cromarty: West 5 to 7, perhaps gale 8 later. Moderate or rough. Rain then showers. Good occasionally poor. From nobody Tue Apr 11 08:52: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 6AE1A12EADF for ; Tue, 11 Apr 2017 08:52:15 -0700 (PDT) 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_DNSWL_NONE=-0.0001, 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 AmYcXpDb0ATi for ; Tue, 11 Apr 2017 08:52:13 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 8593812954B for ; Tue, 11 Apr 2017 08:52:13 -0700 (PDT) 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]:57513) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cxy5S-000oyg-d9 (Exim 4.89) (return-path ); Tue, 11 Apr 2017 16:52:10 +0100 Date: Tue, 11 Apr 2017 16:52:10 +0100 From: Tony Finch To: Evan Hunt cc: Paul Wouters , dnsop@ietf.org In-Reply-To: <20170407224716.GB33435@isc.org> Message-ID: References: <20170407181139.GB66383@isc.org> <20170407224716.GB33435@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: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 15:52:15 -0000 Evan Hunt wrote: > > Expansion of ANAME on the authoritative end is a workaround for the > fact that we can't go back in time and put ANAME support into all > the resolvers. On the authoritative side I think server behaviour should be partitioned into primary and secondary: Primary servers are able to modify zone contents. This might be old skool batch provisioning or dynamic on-demand trickery. Secondary servers just serve what they get via xfer from primaries. ANAME expansion happens on primaries and (in the future) on recursors, but not secondaries nor stubs. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Trafalgar: Easterly or southeasterly 4 or 5, but 6 or 7 in far southeast, becoming variable 4 later except far southeast. Slight or moderate. Fair. Moderate or good. From nobody Tue Apr 11 08:54: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 A655A12954B for ; Tue, 11 Apr 2017 08:54:53 -0700 (PDT) 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, 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 dQsYmSw1rTi7 for ; Tue, 11 Apr 2017 08:54:52 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (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 E548912EAED for ; Tue, 11 Apr 2017 08:54:48 -0700 (PDT) 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]:38744) by ppsw-40.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cxy7y-000zGL-mA (Exim 4.89) (return-path ); Tue, 11 Apr 2017 16:54:46 +0100 Date: Tue, 11 Apr 2017 16:54:46 +0100 From: Tony Finch To: Evan Hunt cc: dnsop@ietf.org In-Reply-To: Message-ID: References: <20170407181139.GB66383@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: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 15:54:54 -0000 When an ANAME record is present at a DNS node and a query is received by an authoritative server for type A or AAAA, the authoritative server returns the ANAME RR in the answer section. Wouldn't it be safer to put the ANAME in the additional section? Do we care about SSHFP? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Trafalgar: Easterly or southeasterly 4 or 5, but 6 or 7 in far southeast, becoming variable 4 later except far southeast. Slight or moderate. Fair. Moderate or good. From nobody Tue Apr 11 11:17: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 C75B412EBB3 for ; Tue, 11 Apr 2017 11:17:07 -0700 (PDT) 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 7qdFtrLTXiCC for ; Tue, 11 Apr 2017 11:17:05 -0700 (PDT) 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 8B4D512EB86 for ; Tue, 11 Apr 2017 11:16:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w2Zxt60T1zD36; Tue, 11 Apr 2017 20:16:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491934594; bh=Wh64X87RnjDEtVHmJCixwPRhw+SP+bjMTiCnjo2UwUw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=HQQNR8P23kzbscM70FF7ixZ7dLdHgW9T7gkCQMCCrFG09x/J1M9ibRtm7O8Mr34CN xchQ/ZSTkLmyI8EdXndDFyKns0Bu8jV+mKEGBsJ23AccPwxnIoZvc6SqAFevoWSF/V sanGI9Mv9Ana7+sV/+FolICfC3xnjRBCmd90AKg0= 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 96_FDTC81Ko3; Tue, 11 Apr 2017 20:16:34 +0200 (CEST) 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, 11 Apr 2017 20:16:34 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 31C1D418516; Tue, 11 Apr 2017 14:16:33 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 31C1D418516 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2A9FE40D3585; Tue, 11 Apr 2017 14:16:33 -0400 (EDT) Date: Tue, 11 Apr 2017 14:16:33 -0400 (EDT) From: Paul Wouters To: Tony Finch cc: dnsop In-Reply-To: Message-ID: References: <20170407181139.GB66383@isc.org> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:17:08 -0000 On Tue, 11 Apr 2017, Tony Finch wrote: > ANAME > records are not just for zone apexes. There are lots of other cases where > address records need a different alias target from MX records, or NAPTR > records, etc. Can you give me an example of deploying ANAME outside the zone APEX that is not solved by allowing a CNAME to point to a CNAME (which most code I think already allows anyway) Paul From nobody Tue Apr 11 11:42: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 0A6EE12EBD2 for ; Tue, 11 Apr 2017 11:42:33 -0700 (PDT) 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, 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 0_tRFi5PbcVL for ; Tue, 11 Apr 2017 11:42:31 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (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 65760129666 for ; Tue, 11 Apr 2017 11:42:31 -0700 (PDT) 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]:52814) by ppsw-40.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cy0kH-0001Yc-jT (Exim 4.89) (return-path ); Tue, 11 Apr 2017 19:42:29 +0100 Date: Tue, 11 Apr 2017 19:42:29 +0100 From: Tony Finch To: Paul Wouters cc: dnsop In-Reply-To: Message-ID: References: <20170407181139.GB66383@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: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:42:33 -0000 Paul Wouters wrote: > > Can you give me an example of deploying ANAME outside the zone APEX that > is not solved by allowing a CNAME to point to a CNAME (which most code I > think already allows anyway) https://www.ietf.org/mail-archive/web/dnsop/current/msg19909.html If you have a subdomain that needs to be a mail domain and a web site, you need an MX pointing at your mail server and address records pointing at your web server. You can't use a CNAME because they are usually different servers. Also, mail domains cannot in practice be CNAMEs because of the disaster of RFC 821 / RFC 1122 mail domain canonicalization. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fitzroy: Easterly or northeasterly 4 or 5, occasionally 6 in south. Slight or moderate, occasionally rough at first in south. Fair. Good. From nobody Tue Apr 11 12:05: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 D349612EC68 for ; Tue, 11 Apr 2017 12:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 FLtdC5owBznO for ; Tue, 11 Apr 2017 12:05:01 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809B612EB72 for ; Tue, 11 Apr 2017 12:05:01 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1EB3F7E9D7; Tue, 11 Apr 2017 19:05:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1EB3F7E9D7 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1EB3F7E9D7 Received: from oldenburg.str.redhat.com (ovpn-116-139.ams2.redhat.com [10.36.116.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3E37B17C0F; Tue, 11 Apr 2017 19:05:00 +0000 (UTC) To: Tony Finch References: <20170407181139.GB66383@isc.org> Cc: Evan Hunt , dnsop@ietf.org From: Florian Weimer Message-ID: Date: Tue, 11 Apr 2017 21:04:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 11 Apr 2017 19:05:01 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:05:03 -0000 On 04/11/2017 05:45 PM, Tony Finch wrote: > Florian Weimer wrote: >> >> I think the introduction should discuss why it is not possible to push the >> CNAME to the parent zone, replacing the entire zone with an alias. > > You can't replace an entire zone with a CNAME if it has subdomains. ANAME > records are not just for zone apexes. There are lots of other cases where > address records need a different alias target from MX records, or NAPTR > records, etc. Sure, but the document should list that. FWIW, I think the real problem is that it is perceived as cheaper to upgrade DNS servers than to support CNAME records in the provisioning infrastructure. Thanks, Florian From nobody Tue Apr 11 12:10: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 99F4A12EC87 for ; Tue, 11 Apr 2017 12:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 mWTrMYOZ6mQt for ; Tue, 11 Apr 2017 12:09:59 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89C112EB72 for ; Tue, 11 Apr 2017 12:09:57 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 448AC80B56; Tue, 11 Apr 2017 19:09:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 448AC80B56 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 448AC80B56 Received: from oldenburg.str.redhat.com (ovpn-116-139.ams2.redhat.com [10.36.116.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7CEDC78DBE; Tue, 11 Apr 2017 19:09:56 +0000 (UTC) To: Tony Finch , Paul Wouters References: <20170407181139.GB66383@isc.org> Cc: dnsop From: Florian Weimer Message-ID: <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> Date: Tue, 11 Apr 2017 21:09:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 11 Apr 2017 19:09:57 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:10:01 -0000 On 04/11/2017 08:42 PM, Tony Finch wrote: > Paul Wouters wrote: >> >> Can you give me an example of deploying ANAME outside the zone APEX that >> is not solved by allowing a CNAME to point to a CNAME (which most code I >> think already allows anyway) > > https://www.ietf.org/mail-archive/web/dnsop/current/msg19909.html > > If you have a subdomain that needs to be a mail domain and a web site, you > need an MX pointing at your mail server and address records pointing at > your web server. You can't use a CNAME because they are usually different > servers. That's not a problem, you can have MX records at the CNAME target. > Also, mail domains cannot in practice be CNAMEs because of the disaster of > RFC 821 / RFC 1122 mail domain canonicalization. I can see why this is a concern, but does current sendmail still rewrite the headers? (The envelope recipient is far less problematic.) Thanks, Florian From nobody Tue Apr 11 12:11: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 AFDAF1294C3 for ; Tue, 11 Apr 2017 12:11:12 -0700 (PDT) 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, 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=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 u1wE4TlzlymB for ; Tue, 11 Apr 2017 12:11:11 -0700 (PDT) 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 239E712EC34 for ; Tue, 11 Apr 2017 12:11:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w2c8q0R1Yz38S; Tue, 11 Apr 2017 21:11:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491937867; bh=qcu4MNSp8cHTKiv1OgiKxV7YybYemAYJCEQFAik0q5M=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Rmys32Ey59W0zFUHuVBPylWY80njOIXa7tsQTA9AMrw+zTVU4qeMTfuld0+J+6VW4 MawzLiGe39O0Q7ShnkcytqqXHBsdwrQwEJCgveMKEhKtknDooeJeJ4SiasY54P5FRh k1dzoWaclRxg3ZuG3zh+KY0lMNTPBXt9p2uD+ahA= 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 Xx6MYQDAEZvR; Tue, 11 Apr 2017 21:11:05 +0200 (CEST) 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, 11 Apr 2017 21:11:04 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1DEF4418516; Tue, 11 Apr 2017 15:11:04 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1DEF4418516 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1345540D3585; Tue, 11 Apr 2017 15:11:04 -0400 (EDT) Date: Tue, 11 Apr 2017 15:11:03 -0400 (EDT) From: Paul Wouters To: Tony Finch cc: dnsop In-Reply-To: Message-ID: References: <20170407181139.GB66383@isc.org> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:11:13 -0000 On Tue, 11 Apr 2017, Tony Finch wrote: > Paul Wouters wrote: >> >> Can you give me an example of deploying ANAME outside the zone APEX that >> is not solved by allowing a CNAME to point to a CNAME (which most code I >> think already allows anyway) > > https://www.ietf.org/mail-archive/web/dnsop/current/msg19909.html > > If you have a subdomain that needs to be a mail domain and a web site, you > need an MX pointing at your mail server and address records pointing at > your web server. You can't use a CNAME because they are usually different > servers. Hmm okay. Although you could just make a real zone cut there and then it becomes the APEX case again :P > Also, mail domains cannot in practice be CNAMEs because of the disaster of > RFC 821 / RFC 1122 mail domain canonicalization. I'm not sure ANAME's make deployment corner cases easier :P I still feel using ANAME without preprocessing by auth nameservers and fixing returning multiple record type to a single query is the more generic and fix for this problem. Paul From nobody Tue Apr 11 12:15: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 941B412EC34 for ; Tue, 11 Apr 2017 12:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (2048-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 goygyXF8V9J2 for ; Tue, 11 Apr 2017 12:15:46 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED73012EC87 for ; Tue, 11 Apr 2017 12:15:45 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 49B1320F66; Tue, 11 Apr 2017 15:15:45 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 11 Apr 2017 15:15:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; 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:x-sasl-enc; s= fm1; bh=Rp8X3mNBea3V/sE1Zb5uOgTAG7UPMJdhJVWdULsrtqk=; b=kB6wdSXy pUwa4obyfdarwMLzRehJHJFxocev+HoZ2IUshCl7UnDcmFUkTK1wA9AFQBA2uSie UES8vxTIsk0xcSbQSAByOATpvl3bzZaujkPBjCvKiPcfCWsPhwWQ7FtdcxIq1oJV E/1kymEhqjfnZboMCEeVK91kwR+Ff3bYf5kH0vzh7TGh8YKrWGIT2jMs87CJdMBI 0rpKEs1/RqzyRLPWzm5u359wroNFB0yulLqCvzOEozluCYlert4LrKaoVh8EBWGx mUV5BkAYrPX3To9phgUa5dHJ3Hl4h/tWCcRLB1J7TXUYVHeJJ2Ti5hSwt/IGf1QA 9ZHMe7GGVWmmFg== X-ME-Sender: X-Sasl-enc: QUnKTbECiTFg9X4sZS/wYf3xPGX3T4uqeaq+rasygCuJ 1491938144 Received: from [10.46.241.198] (188.29.164.8.threembb.co.uk [188.29.164.8]) by mail.messagingengine.com (Postfix) with ESMTPA id ECBA97E602; Tue, 11 Apr 2017 15:15:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Tony Finch X-Mailer: iPhone Mail (14D27) In-Reply-To: <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> Date: Tue, 11 Apr 2017 20:15:43 +0100 Cc: Paul Wouters , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170407181139.GB66383@isc.org> <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> To: Florian Weimer Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:15:47 -0000 > On 11 Apr 2017, at 20:09, Florian Weimer wrote: >=20 >> On 04/11/2017 08:42 PM, Tony Finch wrote: >>=20 >> If you have a subdomain that needs to be a mail domain and a web site, yo= u >> need an MX pointing at your mail server and address records pointing at >> your web server. You can't use a CNAME because they are usually different= >> servers. >=20 > That's not a problem, you can have MX records at the CNAME target. That doesn't work if the web server is at 3rd party provider A but you want p= rovider B's mail service not provider A's. You might also have NAPTR records pointing at providers C and D. Tony. --=20 f.anthony.n.finch http://dotat.at From nobody Tue Apr 11 12:22: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 E39E012EC56 for ; Tue, 11 Apr 2017 12:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0JJoHAzoHUIe for ; Tue, 11 Apr 2017 12:22:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892261296B0 for ; Tue, 11 Apr 2017 12:22:12 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AC97CC04B94E; Tue, 11 Apr 2017 19:11:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AC97CC04B94E Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com AC97CC04B94E Received: from oldenburg.str.redhat.com (ovpn-116-139.ams2.redhat.com [10.36.116.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1E46B77DD1; Tue, 11 Apr 2017 19:11:55 +0000 (UTC) To: Peter van Dijk , dnsop@ietf.org References: <20170407181139.GB66383@isc.org> <86FE867E-E1BE-4427-9FB2-D148B3F9C8C2@powerdns.com> From: Florian Weimer Message-ID: <94f7e821-d3a9-8c12-b17f-01d32c383182@redhat.com> Date: Tue, 11 Apr 2017 21:11:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <86FE867E-E1BE-4427-9FB2-D148B3F9C8C2@powerdns.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 11 Apr 2017 19:11:56 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:22:17 -0000 On 04/10/2017 12:04 PM, Peter van Dijk wrote: >> Section 3 is currently written in such a way that a recursive DNS >> lookup must be performed at the authoritative server side. I don't >> think it is necessary to require that. A recursive DNS lookup of the >> target is just one way to implement this. > > What other ways did you have in mind? Private arrangement with the target zone operator (that is, direct, out of-band access to the zone). >> In particular, the suggested recursive DNS lookup needs some form of >> distributed loop detection. Otherwise, a malicious customer could >> publish two zones with ANAME records and achieve significant traffic >> amplification, potentially taking down the DNS hoster. A hop count in >> an EDNS option or an “ANAME lookup in progress” indicator would be one >> way to implement this. Another approach would impose restrictions on >> the owner name of an ANAME record and its target, and restrict where >> CNAMEs can appear, so that a valid ANAME can never point to another >> valid ANAME. > > I’m not sure it’s feasible to forbid chaining ANAMEs. I do agree there > is a vector for DoS here. Section 6 currently cowardly says “Both > authoritative servers and resolvers that implement ANAME should > carefully check for loops and treat them as an error condition.” but I > am aware that more words are needed. I don't see how you can detect loops without DNS protocol changes. The query that comes back will look like a completely fresh query. Thanks, Florian From cclement@afilias.info Tue Apr 11 12:27: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 2500212ECA9 for ; Tue, 11 Apr 2017 12:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.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 lwFB-YgBR8hf for ; Tue, 11 Apr 2017 12:27:25 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) (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 8EE8B12F24E for ; Tue, 11 Apr 2017 12:27:22 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.88) (envelope-from ) id 1cy1Rh-0009RL-59 for dnsop@ietf.org; Tue, 11 Apr 2017 19:27:21 +0000 Received: from mail-io0-f197.google.com ([209.85.223.197]) by smtp.afilias.info with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1cy1Rh-0007mn-4j for dnsop@ietf.org; Tue, 11 Apr 2017 19:27:21 +0000 Received: by mail-io0-f197.google.com with SMTP id o79so7882956ioo.14 for ; Tue, 11 Apr 2017 12:27:21 -0700 (PDT) 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=ebRlmicV1hlZDOPKckSVvHniwD1ahzKYTv0zG1n8iSA=; b=W1I1a2Ct5OmkP8ndQ8dbpBzOIEtD2YsX/kqsUJB2x6yY4yBT7o+NsJNEkJl8hOB3wH owWzegEdQNoDmwf79IyjdGv3X6v4zhVIGT2MvxbKBx50xZ2DWMxsZQP8Skw7EJU1XUgy AGwzjYtkl1jniMtCZ3duJ9bXyBeBQhtgXvWO3puSD9xA5VeJLPpvPUz5JNS5aZm2C548 Sq6LkjmF6myzhknRYaYvnsy/B3Cz4ChoJcToOYwlc+guAY7aNkbi8Qr5buRHKlkWEWXy v0MpXN81zOvWBGcSIQKnhPUVzXFc/yL1xRZVHncoKR7VhpTZdfS3rgQpUD2puqGXQu0t MCGg== X-Gm-Message-State: AFeK/H2nTkUQs/BwpTUiMnCYXKs1X9s4o+3ZSnpuBCY5nf+pAtv+l2nAhkmxbmXG7j3HmfjnXMMxkFIaLWkLL0fJsNM5Y5xdP9iF6rZndpFyfNMe+tE0UmVFVZWzJyTEuHFwwuKp3mKtsNg+ZjQ= X-Received: by 10.107.39.70 with SMTP id n67mr57647111ion.114.1491938835932; Tue, 11 Apr 2017 12:27:15 -0700 (PDT) X-Received: by 10.107.39.70 with SMTP id n67mr57647094ion.114.1491938835704; Tue, 11 Apr 2017 12:27:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.198 with HTTP; Tue, 11 Apr 2017 12:27:15 -0700 (PDT) In-Reply-To: References: <20160802132253.27847.43026.idtracker@ietfa.amsl.com> From: Carl Clements Date: Tue, 11 Apr 2017 15:27:15 -0400 Message-ID: To: Matthew Pounsett Cc: dnsop Content-Type: multipart/alternative; boundary=001a1140853c5444d8054ce9146c Archived-At: X-Mailman-Approved-At: Tue, 11 Apr 2017 12:46:09 -0700 Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:29:07 -0000 --001a1140853c5444d8054ce9146c Content-Type: text/plain; charset=UTF-8 Thanks for this Matt, My familiarity with IETF I-D best practices is lacking, so I am not sure I can be of any help regarding most of your questions. However, I do have some thoughts on this draft. On 2 August 2016 at 08:38, Matthew Pounsett wrote: > Second, the draft as it currently stands follows the style of 6781 in that > it doesn't spell out TTL waits between steps in the operator change > procedure, and leaves it as an exercise for the reader to incorporate > information from the key roll sections of 6781. I'm of two minds on this, > and think it may be useful to spell out the details of the operator change > procedure even though a thorough reading of the key roll procedures could > provide the necessary information. There is one detail that I feel is not explicit enough in 6781 that is extremely relevant during a DNSSEC operator migration. It is assumed in this document that DNSKEY_*_A and DNSKEY_*_B use the same signature algorithm. That assumption is derived from the implication that this document describes a Double-DS KSK rollover, which is incompatible with an algorithm rollover even with the liberal approach to Section 2.2 of RFC 4035 . I think it would be helpful to at least reference this implication in section 2.1 of your draft. My other thought is regarding the instruction to pre-publish DNSKEY_K_B and post publish DNSKEY_K_A. As far as I can tell, and we have discussed this a little out of band, the only value provided by publishing and signing this KSK is to satisfy any over-conservative DS checks performed by the maintainers of the parent zone. The essential chain of trust "cross pollination" is that both DNSKEY_Z_A and DNSKEY_Z_B are signed by the either KSK. Perhaps there is a reason to publish the other operator's KSK, and so we leave it as is for good measure? Is it best to avoid mention of this detail so as to not unnecessarily complicate the document? In my personal opinion any parent that does not allow addition of DS (for the same algorithm) before the corresponding KSK appears in the child zone should be corrected, and thus the document should not recommend the pre- and post-publish of KSK. Lastly, it looks as though you opted to spell out TTL waits, for example. For what is it worth, I am in favour of this choice. -- Carl Clements --001a1140853c5444d8054ce9146c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for this Matt,
My familiarity with IETF I-D best practices is lacking, so I am no= t sure I can be of any help regarding most of your questions. However, I do= have some thoughts on this draft.

On 2 August 20= 16 at 08:38, Matthew Pounsett=C2=A0<matt@conundrum.com>=C2= =A0wrote:
Second, the = draft as it currently stands follows the style of 6781 in that it doesn'= ;t spell out TTL waits between steps in the operator change procedure, and = leaves it as an exercise for the reader to incorporate information from the= key roll sections of 6781.=C2=A0 I'm of two minds on this, and think i= t may be useful to spell out the details of the operator change procedure e= ven though a thorough reading of the key roll procedures could provide the = necessary information. =C2=A0
=

There is one detail that I feel = is not explicit enough in 6781 that is extremely relevant during a DNSSEC o= perator migration. It is assumed in this document that DNSKEY_*_A and DNSKE= Y_*_B use the same signature algorithm. That assumption is derived from the= implication that this document describes a=C2=A0Double-DS KSK rollover, which is incompatible with an algorithm r= ollover even with the liberal approach to=C2=A0Section=C2=A02.2 of = RFC 4035. I think it would be helpful to at least reference this implic= ation in section 2.1 of your draft.

My other thought is = regarding the instruction to pre-publish DNSKEY_K_B and post publish DNSKEY= _K_A. As far as I can tell, and we have discussed this a little out of band= , the only value provided by publishing and signing this KSK is to satisfy = any over-conservative DS checks performed by the maintainers of the parent = zone. The essential chain of trust "cross pollination" is that bo= th DNSKEY_Z_A and DNSKEY_Z_B are signed by the either KSK.=C2=A0

=
Perhaps there is a reason to publish the other operator's KSK, a= nd so we leave it as is for good measure?=C2=A0Is it best to avoid mention = of this detail so as to not unnecessarily complicate the document? In my pe= rsonal opinion any parent that does not allow addition of DS (for the same = algorithm) before the corresponding KSK appears in the child zone should be= corrected, and thus the document should not recommend the pre- and post-pu= blish of KSK.

Lastly, it looks as though you opted to spel= l out TTL waits, for example. For what is it worth, I am in favour of this = choice.

--
Carl Clements
--001a1140853c5444d8054ce9146c-- From nobody Tue Apr 11 12:47: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 44F5012FEE2 for ; Tue, 11 Apr 2017 12:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 drFaonJCAxsn for ; Tue, 11 Apr 2017 12:47:40 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2C012EC81 for ; Tue, 11 Apr 2017 12:47:40 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6DA5C8F864; Tue, 11 Apr 2017 19:39:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6DA5C8F864 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6DA5C8F864 Received: from oldenburg.str.redhat.com (ovpn-116-139.ams2.redhat.com [10.36.116.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 965E25B81C; Tue, 11 Apr 2017 19:39:57 +0000 (UTC) To: Tony Finch References: <20170407181139.GB66383@isc.org> <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> Cc: Paul Wouters , dnsop From: Florian Weimer Message-ID: Date: Tue, 11 Apr 2017 21:39:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 11 Apr 2017 19:39:58 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:47:41 -0000 On 04/11/2017 09:15 PM, Tony Finch wrote: > >> On 11 Apr 2017, at 20:09, Florian Weimer wrote: >> >>> On 04/11/2017 08:42 PM, Tony Finch wrote: >>> >>> If you have a subdomain that needs to be a mail domain and a web site, you >>> need an MX pointing at your mail server and address records pointing at >>> your web server. You can't use a CNAME because they are usually different >>> servers. >> >> That's not a problem, you can have MX records at the CNAME target. > > That doesn't work if the web server is at 3rd party provider A but you want provider B's mail service not provider A's. I don't understand. I think it boils down to who operates the target DNS zone and how flexible they are. It has nothing to do with who runs the web server. Thanks, Florian From nobody Tue Apr 11 13:15: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 9810F13145E for ; Tue, 11 Apr 2017 13:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (2048-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 JXYyE4JjnPtV for ; Tue, 11 Apr 2017 13:15:29 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BA9131458 for ; Tue, 11 Apr 2017 13:15:29 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C025D20A75; Tue, 11 Apr 2017 16:15:28 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 11 Apr 2017 16:15:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; 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:x-sasl-enc; s= fm1; bh=lNLazPl4gEopSoRu61iPk0b6se2vRujwmx9bs0GKCqI=; b=JSlqaqzz ZO0S0z6mTW+/UrYLkHQeX4dIoOOROo6GtRwqvrsLvDnfuZhJoUCjsd1TYPQWdvWB n9IT9s/uzhLr5tQT/z9uezZb9xbJnkRN4aetcIkdncpqB8HCYCbKPtrenKZsCN7M 3ayINhsnD6LoTILqxtL3OdFgZxxtp/QtXN6Qtle23U/M7Tv7CRlcyqruN0XpXTGw QVUPz0Ud1dZrscrTlYq+BaYoFnjyNbr1eDq7enOsGx3e3EboYhbd7/nuOvK70b+l ARMRA9slJ2AlRAUNpWo64dU5TVcZTw/Oo6gqma59Rq1QZY616vHWkBWFYvd87wDi Jl1+Dlw3/p2+Gw== X-ME-Sender: X-Sasl-enc: 74hkCNJPVLbRMnxyXLfY7wRjPYaLvhluiG13MOmCvrpl 1491941728 Received: from [10.46.241.198] (188.29.164.8.threembb.co.uk [188.29.164.8]) by mail.messagingengine.com (Postfix) with ESMTPA id 2D899240AE; Tue, 11 Apr 2017 16:15:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Tony Finch X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Tue, 11 Apr 2017 21:15:22 +0100 Cc: Paul Wouters , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170407181139.GB66383@isc.org> <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> To: Florian Weimer Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:15:32 -0000 > On 11 Apr 2017, at 20:39, Florian Weimer wrote: >> On 04/11/2017 09:15 PM, Tony Finch wrote: >>=20 >> That doesn't work if the web server is at 3rd party provider A but you wa= nt provider B's mail service not provider A's. >=20 > I don't understand. >=20 > I think it boils down to who operates the target DNS zone and how flexible= they are. It has nothing to do with who runs the web server. In many cases the ANAME target will be a mass web hosting provider which doe= sn't have any flexibility in their DNS setup. And you still don't want CNAME pointing at MX because of the interop problem= s. Having implemented something like this on the provisioning end, it seems sim= pler and more useful to me to make ANAMEs work anywhere. Tony. --=20 f.anthony.n.finch http://dotat.at From nobody Tue Apr 11 13:16: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 658C3131455 for ; Tue, 11 Apr 2017 13:16:20 -0700 (PDT) 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 QY25K8Y02fPu for ; Tue, 11 Apr 2017 13:16:19 -0700 (PDT) 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 2370E12EB22 for ; Tue, 11 Apr 2017 13:16:19 -0700 (PDT) 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 F17B43493E8; Tue, 11 Apr 2017 20:16:16 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id E243E216C1E; Tue, 11 Apr 2017 20:16:16 +0000 (UTC) Date: Tue, 11 Apr 2017 20:16:16 +0000 From: Evan Hunt To: Florian Weimer Cc: Peter van Dijk , dnsop@ietf.org Message-ID: <20170411201616.GC3533@isc.org> References: <20170407181139.GB66383@isc.org> <86FE867E-E1BE-4427-9FB2-D148B3F9C8C2@powerdns.com> <94f7e821-d3a9-8c12-b17f-01d32c383182@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94f7e821-d3a9-8c12-b17f-01d32c383182@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:16:20 -0000 On Tue, Apr 11, 2017 at 09:11:54PM +0200, Florian Weimer wrote: > I don't see how you can detect loops without DNS protocol changes. The > query that comes back will look like a completely fresh query. We can put a limit on the number of hops that are followed in populating the A and AAAA records for the expanded ANAME response. If that limit is exceeded, the ANAME record could be rejected by the auth; either the zone wouldn't load or address queries return SERVFAIL. BIND already has a limit of 16 hops for CNAME loop prevention. I assume other resolver implementations must do something similar. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Tue Apr 11 13:20: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 4CD0113145F for ; Tue, 11 Apr 2017 13:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 d7mne9tLHq3a for ; Tue, 11 Apr 2017 13:20:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE3E129ACD for ; Tue, 11 Apr 2017 13:20:35 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9E6144E35B; Tue, 11 Apr 2017 20:20:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9E6144E35B Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9E6144E35B Received: from oldenburg.str.redhat.com (ovpn-116-139.ams2.redhat.com [10.36.116.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E7CF95DD6F; Tue, 11 Apr 2017 20:20:32 +0000 (UTC) To: Tony Finch References: <20170407181139.GB66383@isc.org> <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> Cc: Paul Wouters , dnsop From: Florian Weimer Message-ID: Date: Tue, 11 Apr 2017 22:20:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 11 Apr 2017 20:20:34 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:20:36 -0000 On 04/11/2017 10:15 PM, Tony Finch wrote: > >> On 11 Apr 2017, at 20:39, Florian Weimer wrote: >>> On 04/11/2017 09:15 PM, Tony Finch wrote: >>> >>> That doesn't work if the web server is at 3rd party provider A but you want provider B's mail service not provider A's. >> >> I don't understand. >> >> I think it boils down to who operates the target DNS zone and how flexible they are. It has nothing to do with who runs the web server. > > In many cases the ANAME target will be a mass web hosting provider which doesn't have any flexibility in their DNS setup. And in order to accommodate them, we upgrade the DNS server infrastructure across the Internet? I understand that's how things work in practice, but I don't kike it. > And you still don't want CNAME pointing at MX because of the interop problems. CNAME to MX is fine. Isn't this what's relevant here? Thanks, Florian From nobody Tue Apr 11 13:31: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 803DA129AB6 for ; Tue, 11 Apr 2017 13:31:37 -0700 (PDT) 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 Lt8j73uJ7K3d for ; Tue, 11 Apr 2017 13:31:36 -0700 (PDT) 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 69E7D127601 for ; Tue, 11 Apr 2017 13:31:36 -0700 (PDT) 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 35ED83493E8; Tue, 11 Apr 2017 20:31:34 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 28E6C216C1E; Tue, 11 Apr 2017 20:31:34 +0000 (UTC) Date: Tue, 11 Apr 2017 20:31:34 +0000 From: Evan Hunt To: Florian Weimer Cc: Peter van Dijk , dnsop@ietf.org Message-ID: <20170411203134.GA6670@isc.org> References: <20170407181139.GB66383@isc.org> <86FE867E-E1BE-4427-9FB2-D148B3F9C8C2@powerdns.com> <94f7e821-d3a9-8c12-b17f-01d32c383182@redhat.com> <20170411201616.GC3533@isc.org> <742429b6-4c96-5ee5-caf4-6785d983ffb6@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <742429b6-4c96-5ee5-caf4-6785d983ffb6@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:31:37 -0000 On Tue, Apr 11, 2017 at 10:21:13PM +0200, Florian Weimer wrote: > But what happens when the target server also performs cache filling at > the same time? If two servers end up being unable to populate their address records because they're depending on each other for answers, then you end up with two servers that both return SERVFAIL on address queries. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Tue Apr 11 13:36: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 0B5A112951B for ; Tue, 11 Apr 2017 13:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 bRZ8pOKQ2Bgc for ; Tue, 11 Apr 2017 13:36:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA971274D2 for ; Tue, 11 Apr 2017 13:27:40 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EB37D80F7B; Tue, 11 Apr 2017 20:21:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com EB37D80F7B Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com EB37D80F7B Received: from oldenburg.str.redhat.com (ovpn-116-139.ams2.redhat.com [10.36.116.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3DE765B81C; Tue, 11 Apr 2017 20:21:14 +0000 (UTC) To: Evan Hunt References: <20170407181139.GB66383@isc.org> <86FE867E-E1BE-4427-9FB2-D148B3F9C8C2@powerdns.com> <94f7e821-d3a9-8c12-b17f-01d32c383182@redhat.com> <20170411201616.GC3533@isc.org> Cc: Peter van Dijk , dnsop@ietf.org From: Florian Weimer Message-ID: <742429b6-4c96-5ee5-caf4-6785d983ffb6@redhat.com> Date: Tue, 11 Apr 2017 22:21:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170411201616.GC3533@isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 11 Apr 2017 20:21:15 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:36:07 -0000 On 04/11/2017 10:16 PM, Evan Hunt wrote: > On Tue, Apr 11, 2017 at 09:11:54PM +0200, Florian Weimer wrote: >> I don't see how you can detect loops without DNS protocol changes. The >> query that comes back will look like a completely fresh query. > > We can put a limit on the number of hops that are followed in populating > the A and AAAA records for the expanded ANAME response. If that limit is > exceeded, the ANAME record could be rejected by the auth; either the zone > wouldn't load or address queries return SERVFAIL. But what happens when the target server also performs cache filling at the same time? Thanks, Florian From nobody Tue Apr 11 13:37: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 6DE451274D2 for ; Tue, 11 Apr 2017 13:37:22 -0700 (PDT) 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 eI1wkqPjY8OG for ; Tue, 11 Apr 2017 13:37:20 -0700 (PDT) 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 CE529129AE5 for ; Tue, 11 Apr 2017 13:37:20 -0700 (PDT) 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 99CDF349420; Tue, 11 Apr 2017 20:37:17 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5399C160048; Tue, 11 Apr 2017 20:37:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2C4CC160070; Tue, 11 Apr 2017 20:37:17 +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 DZkHw7qzK-96; Tue, 11 Apr 2017 20:37:17 +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 A30B1160048; Tue, 11 Apr 2017 20:37:16 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C60FD6B23435; Wed, 12 Apr 2017 06:37:14 +1000 (AEST) To: Florian Weimer Cc: Tony Finch , dnsop , Paul Wouters From: Mark Andrews References: <20170407181139.GB66383@isc.org> <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> In-reply-to: Your message of "Tue, 11 Apr 2017 22:20:31 +0200." Date: Wed, 12 Apr 2017 06:37:14 +1000 Message-Id: <20170411203714.C60FD6B23435@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:37:22 -0000 In message , Florian Weimer writes: > On 04/11/2017 10:15 PM, Tony Finch wrote: > > > >> On 11 Apr 2017, at 20:39, Florian Weimer wrote: > >>> On 04/11/2017 09:15 PM, Tony Finch wrote: > >>> > >>> That doesn't work if the web server is at 3rd party provider A but you want provider B's mail service not provider A's. > >> > >> I don't understand. > >> > >> I think it boils down to who operates the target DNS zone and how flexible they are. It has nothing to do with who runs the > web server. > > > > In many cases the ANAME target will be a mass web hosting provider which doesn't have any flexibility in their DNS setup. > > And in order to accommodate them, we upgrade the DNS server > infrastructure across the Internet? > > I understand that's how things work in practice, but I don't kike it. > > > And you still don't want CNAME pointing at MX because of the interop problems. > > CNAME to MX is fine. Isn't this what's relevant here? > > Thanks, > Florian There are times when you want the MX of the owner of the CNAME to be different to the target of the CNAME. Similarly for every other record type. CNAME has NEVER been the correct record to point to a server for a service. We are here because browser vendors refuse to actually use good practices with the DNS. To follow best practice examples (e.g. MX records). Mark > _______________________________________________ > 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 Tue Apr 11 13:44: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 CB7D2129A9F for ; Tue, 11 Apr 2017 13:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (2048-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 7dxFQb_JXbvW for ; Tue, 11 Apr 2017 13:44:21 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199B2128D6F for ; Tue, 11 Apr 2017 13:44:21 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 890C320CFF; Tue, 11 Apr 2017 16:44:20 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 11 Apr 2017 16:44:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; 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:x-sasl-enc; s= fm1; bh=sKmD0JT+qeVWMwZYuINpvT8yy4aN+VqU7yJ5NM2UpjY=; b=OueKI8tg +Qc8Vi7VMpg6gOgqGI98o+dulJlgSUwxZaHGkp8dLDie4IQb2H1ASoOFM2kaDco/ BSfOfgBZf6Pd5MGuIS0T6PqKpDiW4kyh8zqjQWbp26fY8e09htvFUnLm+oyUBBUt Ta9EzVL3CeBnpxJuk+bUpf31834rL5bD1b0Yci95bihzBXi4biOPPenDwaLhGr8Y lWfJR9dDJEFO6bpT9g0JFIP1J9KtPVBZ6dY+1llQm7z6yxZzrMrzHMvxCdLSxLR8 z/DSbwVfvt2oW1NvNbG+0JfhJcQd5jSDswqc80JYHkwyiIRrxpQBJfOgstMgZbgN NYLq7W1bvPQwmg== X-ME-Sender: X-Sasl-enc: Rdps3zGJhK1hXrBeyoLxjlmwkWb6E6u6c9ezHQzjEu6y 1491943460 Received: from [192.168.1.69] (unknown [195.147.34.210]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D5677E6B1; Tue, 11 Apr 2017 16:44:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Tony Finch X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Tue, 11 Apr 2017 21:44:18 +0100 Cc: Paul Wouters , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: <8676C98D-B369-41C5-AB1E-A7F3F4C871E5@dotat.at> References: <20170407181139.GB66383@isc.org> <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> To: Florian Weimer Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:44:23 -0000 > On 11 Apr 2017, at 21:20, Florian Weimer wrote: >> On 04/11/2017 10:15 PM, Tony Finch wrote: >>=20 >> In many cases the ANAME target will be a mass web hosting provider which d= oesn't have any flexibility in their DNS setup. >=20 > And in order to accommodate them, we upgrade the DNS server infrastructure= across the Internet? No. We are working around a design error in the way CNAMEs work within the DNS. R= ather than making a narrow-minded bodge that only works for one special case= , we should fix the general case. All that is required is to make ANAMEs wor= k anywhere, just like the vast majority of other RRtypes. >> And you still don't want CNAME pointing at MX because of the interop prob= lems. >=20 > CNAME to MX is fine. No it isn't, because it causes mail domain rewrites. Tony. --=20 f.anthony.n.finch http://dotat.at From nobody Tue Apr 11 13:47: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 58749128D6F for ; Tue, 11 Apr 2017 13:47:37 -0700 (PDT) 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 czlbQ6YoTGQQ for ; Tue, 11 Apr 2017 13:47:35 -0700 (PDT) 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 248BA129513 for ; Tue, 11 Apr 2017 13:47:35 -0700 (PDT) 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 AF1FA3493BB; Tue, 11 Apr 2017 20:47:26 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 589C3216C1E; Tue, 11 Apr 2017 20:47:26 +0000 (UTC) Date: Tue, 11 Apr 2017 20:47:26 +0000 From: Evan Hunt To: Florian Weimer Cc: Tony Finch , dnsop , Paul Wouters Message-ID: <20170411204726.GB6670@isc.org> References: <20170407181139.GB66383@isc.org> <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:47:37 -0000 On Tue, Apr 11, 2017 at 10:20:31PM +0200, Florian Weimer wrote: > And in order to accommodate them, we upgrade the DNS server > infrastructure across the Internet? Them, and web browser implementers who just don't want to use SRV. We did the best we could to ensure it can be deployed gradually, though. The domain that wants to redirect apex addresses can implement ANAME, and its clients will get answers. Resolvers that want better answers can do that too. Forklift not required. > I understand that's how things work in practice, but I don't like it. So say we all. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Tue Apr 11 14:09: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 01415126D73 for ; Tue, 11 Apr 2017 14:09:46 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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=conundrum-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 Etx8CFD7cjkl for ; Tue, 11 Apr 2017 14:09:44 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 D49431243F6 for ; Tue, 11 Apr 2017 14:09:42 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id s68so4951785vke.3 for ; Tue, 11 Apr 2017 14:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LCL+EmkeV442XgovrK7vXQ6MJkIUBqGfClIB6I0Y9TY=; b=db/pKhaudscXJFD7XNtjPVbVm25FaEPvuRhPi0Nlg0fOs5oizdUJnwN9LPScP9zc2S WLcibLxrki9Ww0uM4xBsGj2i7sYgYb8syvAwdMyR9b+UvvUcfwHqWosSvltMZKx2k3hD tcjvKCTOHiyJApP639za7UI67DV8EGIl5HZ69uaUoGOVAEYPdSHDXWbUdEEKGh3BD4yo HaMVQFM4UlG1oc5plOzPAF97vGfHsW1seMZU/r9rD6uyHuWvARi+1AakUrhlx7HKyJFa 0pn/s5tatp6saXed2gMiZlYz8xrCOebOPYKj7RVNguGOESwa79vyVjmeTiEp3FInMZ6P nSFg== 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=LCL+EmkeV442XgovrK7vXQ6MJkIUBqGfClIB6I0Y9TY=; b=eR/rkFZVCLjBLEwElc50G85l3MdRpotF64FPi8P0bM7vcPurDBwSLa3mUpEZgXJQ0I NX5EzTwN3TbDTxcd5SE/EogseSF8xEv1EbP/n2oX1AW1NRpQv/XkOIAbt3cnpvHGVq8s 6mou7IzDTLgCuj754QqXDrMXIvNNJOYWA0Ky701wFe39u3dmat9Yc++V9+lFB3wy3vTl U2i/bbELQhSIPALqhHfwiaus3/macoEsWSaSNS5qMclA6bY64dlk/NoCoIux8kjPYHFd APQ+xAUSr3LA8pNnFK7veHdqVAKJxxNM/XdVK2YzW/LVOaj4EZDr+jwt1KIe3nKhuUzE eUXw== X-Gm-Message-State: AN3rC/7XFZpM2NL5ZI+BuYmCoiNCJuUE+ezZMZ07JieZE/3+n4WXuq7xZIKNtvdDu+07mwTVpDZVLSXSY+fbmQ== X-Received: by 10.31.107.89 with SMTP id g86mr9710063vkc.155.1491944981535; Tue, 11 Apr 2017 14:09:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.45.130 with HTTP; Tue, 11 Apr 2017 14:09:41 -0700 (PDT) In-Reply-To: References: <20160802132253.27847.43026.idtracker@ietfa.amsl.com> From: Matthew Pounsett Date: Tue, 11 Apr 2017 17:09:41 -0400 Message-ID: To: Carl Clements Cc: dnsop Content-Type: multipart/alternative; boundary=001a11478678a63cc5054cea8241 Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:09:46 -0000 --001a11478678a63cc5054cea8241 Content-Type: text/plain; charset=UTF-8 On 11 April 2017 at 15:27, Carl Clements wrote: > > There is one detail that I feel is not explicit enough in 6781 that is > extremely relevant during a DNSSEC operator migration. It is assumed in > this document that DNSKEY_*_A and DNSKEY_*_B use the same signature > algorithm. That assumption is derived from the implication that this > document describes a Double-DS KSK rollover, which is incompatible with > an algorithm rollover even with the liberal approach to Section 2.2 of > RFC 4035 . I think it > would be helpful to at least reference this implication in section 2.1 of > your draft. > This is an excellent point, and I'll add that to the doc ... likely in the assumptions for now. More below. > > My other thought is regarding the instruction to pre-publish DNSKEY_K_B > and post publish DNSKEY_K_A. As far as I can tell, and we have discussed > this a little out of band, the only value provided by publishing and > signing this KSK is to satisfy any over-conservative DS checks performed by > the maintainers of the parent zone. The essential chain of trust "cross > pollination" is that both DNSKEY_Z_A and DNSKEY_Z_B are signed by the > either KSK. > Yeah, the procedure as described in the doc currently is a little over-cautious with key handling. It's mainly to simplify the description of requirements, but I'm planning to change the way it's written out. One piece of feedback I've received privately is that the document could benefit from having the *requirements* for a clean transfer spelled out, and that the procedure be included as an example, possibly of the shortest path to meet the requirements. I think that bit of reorganization would help with the explanation of when it's actually important to pre/post-publish keys, and coincidentally provide a good place for your note about algo compatibility to live. I've been working on text, but it's been a busy few months so I'm not quite ready to roll -03. > Lastly, it looks as though you opted to spell out TTL waits, for example. > For what is it worth, I am in favour of this choice. > > I added that in -02 with the long-form description of the procedure. Given that the intended audience is not intended to be able to work out this procedure on their own, I thought it was important to be as explicit as possible. Thanks for the feedback! --001a11478678a63cc5054cea8241 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 11 April 2017 at 15:27, Carl Clements <cclement@afilias.info> wrote:

<= div>This is an excellent point, and I'll add that to the doc ... likely= in the assumptions for now.=C2=A0 More below.
=C2=A0

<= /div>
My other thought is regarding the instruction to pre-publish DNSKEY_K= _B and post publish DNSKEY_K_A. As far as I can tell, and we have discussed= this a little out of band, the only value provided by publishing and signi= ng this KSK is to satisfy any over-conservative DS checks performed by the = maintainers of the parent zone. The essential chain of trust "cross po= llination" is that both DNSKEY_Z_A and DNSKEY_Z_B are signed by the ei= ther KSK.=C2=A0

Yeah, the= procedure as described in the doc currently is a little over-cautious with= key handling.=C2=A0 It's mainly to simplify the description of require= ments, but I'm planning to change the way it's written out.

One piece of feedback I've received privately is that= the document could benefit from having the *requirements* for a clean tran= sfer spelled out, and that the procedure be included as an example, possibl= y of the shortest path to meet the requirements.=C2=A0 I think that bit of = reorganization would help with the explanation of when it's actually im= portant to pre/post-publish keys, and coincidentally provide a good place f= or your note about algo compatibility to live.

I&#= 39;ve been working on text, but it's been a busy few months so I'm = not quite ready to roll -03. =C2=A0
=C2=A0
Lastly, it looks= as though you opted to spell out TTL waits, for example. For what is it wo= rth, I am in favour of this choice.

I added that in -02 with the long-form description of the procedur= e.=C2=A0 Given that the intended audience is not intended to be able to wor= k out this procedure on their own, I thought it was important to be as expl= icit as possible.

Thanks for the feedback!=C2=A0

--001a11478678a63cc5054cea8241-- From nobody Tue Apr 11 16:13: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 80DD91293D8; Tue, 11 Apr 2017 16:13:29 -0700 (PDT) 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_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 C8uWC6S3UyyF; Tue, 11 Apr 2017 16:13:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F2D1287A5; Tue, 11 Apr 2017 16:12:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8CAEFB81150; Tue, 11 Apr 2017 16:12:51 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dnsop@ietf.org Message-Id: <20170411231251.8CAEFB81150@rfc-editor.org> Date: Tue, 11 Apr 2017 16:12:51 -0700 (PDT) Archived-At: Subject: [DNSOP] RFC 8145 on Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 23:13:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8145 Title: Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) Author: D. Wessels, W. Kumari, P. Hoffman Status: Standards Track Stream: IETF Date: April 2017 Mailbox: dwessels@verisign.com, warren@kumari.net, paul.hoffman@icann.org Pages: 13 Characters: 27110 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsop-edns-key-tag-05.txt URL: https://www.rfc-editor.org/info/rfc8145 DOI: 10.17487/RFC8145 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. This document is a product of the Domain Name System Operations Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Apr 12 01: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 8BCE3129ABE for ; Wed, 12 Apr 2017 01:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 95zyXWHOv4p2 for ; Wed, 12 Apr 2017 01:21:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCAA1270AC for ; Wed, 12 Apr 2017 01:21:15 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 67C297F081; Wed, 12 Apr 2017 08:21:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 67C297F081 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 67C297F081 Received: from oldenburg.str.redhat.com (ovpn-116-38.ams2.redhat.com [10.36.116.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6396C189AF; Wed, 12 Apr 2017 08:21:14 +0000 (UTC) To: Evan Hunt References: <20170407181139.GB66383@isc.org> <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> <20170411204726.GB6670@isc.org> Cc: Tony Finch , dnsop , Paul Wouters From: Florian Weimer Message-ID: <03357a4d-74d8-bd97-a00b-9fd833fc3e4a@redhat.com> Date: Wed, 12 Apr 2017 10:21:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170411204726.GB6670@isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 12 Apr 2017 08:21:15 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 08:21:18 -0000 On 04/11/2017 10:47 PM, Evan Hunt wrote: > On Tue, Apr 11, 2017 at 10:20:31PM +0200, Florian Weimer wrote: >> And in order to accommodate them, we upgrade the DNS server >> infrastructure across the Internet? > > Them, and web browser implementers who just don't want to use SRV. SRV wouldn't work anyway because it is incompatible with existing name resolution interfaces anyway. If you do not insist on using SRV, but something that is just an alias (like PTR, ANAME etc.) and processed in the client, it would be quite straightforward to put this into the stub resolver, and then all applications[*] would automatically get the addresses at the substitution name (SNAME). Disallow multiple substitution names per owner name and their chaining (but chaining to CNAME would be okay), and I think it would just work. But then DNS operators will worry about a 50% (from A/AAAA to A/AAAA/SNAME) to 150% (from A/AAAA to A/AAAA/SNAME plus A/AAAA at the SNAME) increase in query load. (SRV would be worse because there could be multiple target names, all needing separate processing.) Would that be acceptable? I don't know. In fact, Firefox already solved the issue in the client: If you enter the zone apex, and no address record exists, it automatically redirects to the www name in the zone. Unfortunately, DNS operators broke that when they started rewriting NODATA responses, injecting ads into existing domains. So you really have to have addresses at the zone apex these days. Thanks, Florian [*] At least all applications which correctly deal with enterprise name lookup, which can involve NIS and LDAP, too, not just DNS. From nobody Wed Apr 12 02:48: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 4481913151E for ; Wed, 12 Apr 2017 02:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 8SJW8HVsPeAU for ; Wed, 12 Apr 2017 02:48:29 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (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 36CD8131512 for ; Wed, 12 Apr 2017 02:48:29 -0700 (PDT) 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]:39616) by ppsw-41.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cyEt0-0005cn-QY (Exim 4.89) (return-path ); Wed, 12 Apr 2017 10:48:26 +0100 Date: Wed, 12 Apr 2017 10:48:26 +0100 From: Tony Finch To: Paul Wouters cc: dnsop In-Reply-To: Message-ID: References: <20170407181139.GB66383@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: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 09:48:31 -0000 Paul Wouters wrote: > > Hmm okay. Although you could just make a real zone cut there and then it > becomes the APEX case again :P Well, this is the kind of "just" that involves a huge co-ordination cost updating the configuration of on-site and off-site secondary servers, and may have billing implications if you exceed your zone quota on a commercial provider. > I'm not sure ANAME's make deployment corner cases easier :P They would greatly simplify things for me. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fitzroy: Easterly or northeasterly 4 or 5, occasionally 6 in southeast. Slight or moderate. Occasional rain later. Good, occasionally moderate later. From nobody Wed Apr 12 04:36: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 A5BA5131672 for ; Wed, 12 Apr 2017 04:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 frhUyN6DD6Eb for ; Wed, 12 Apr 2017 04:36:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DB213166C for ; Wed, 12 Apr 2017 04:36:51 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CB41F6409A for ; Wed, 12 Apr 2017 11:36:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com CB41F6409A Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com CB41F6409A Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 79E9677EA9 for ; Wed, 12 Apr 2017 11:36:50 +0000 (UTC) To: dnsop From: Florian Weimer Message-ID: Date: Wed, 12 Apr 2017 13:36:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 12 Apr 2017 11:36:50 +0000 (UTC) Archived-At: Subject: [DNSOP] Status of IDNA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 11:36:53 -0000 What's the current standardization status of IDNA? As far as I can tell, a lot of vendors are still stuck with the original IDNA standard (IDNA2003). There are three or more competing successors, IDNA2008 as standardized by the IETF (without any tweaks), the Unicode IDNA standard TS46 (, which is configurable and allegedly compatible with IETF IDNA2008, but is not because it yields different results than IETF IDNA2008), and the Mozilla/DENIC IDNA implementation in Firefox/Thunderbird ( and other sources). These aren't compatible. You can see this by visiting in different browsers. Is there an ongoing effort to reconcile application behavior? Different TLDs appear to expect different IDNA implementations. One practical problem with IDNA2003 is that it prevents having Hebrew domain names containing ASCII digits. Any of the IDNA2008 variants mentioned above will fix that, I think, but it's difficult to pick a variant to implement. And I certainly don't want to implement per-TLD policies. Thanks, Florian From nobody Wed Apr 12 08:47: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 1249712950E for ; Wed, 12 Apr 2017 08:47:17 -0700 (PDT) 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 diphRw7dqRwL for ; Wed, 12 Apr 2017 08:47:15 -0700 (PDT) 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 73C8B1294E4 for ; Wed, 12 Apr 2017 08:47:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 44F8C7A3309; Wed, 12 Apr 2017 15:47:14 +0000 (UTC) Date: Wed, 12 Apr 2017 15:47:14 +0000 From: Viktor Dukhovni To: dnsop Message-ID: <20170412154713.GX25754@mournblade.imrryr.org> Reply-To: dnsop@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] Status of IDNA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 15:47:17 -0000 On Wed, Apr 12, 2017 at 01:36:49PM +0200, Florian Weimer wrote: > What's the current standardization status of IDNA? > > in different browsers. Some browsers are still doing "transitional" UTS#46, it is time they move on. In up to date releases: Firefox: Already UTS#46 non-transitional Safari: Already UTS#46 non-transitional Chrome: Still broken: https://bugs.chromium.org/p/chromium/issues/detail?id=505262 https://bugs.chromium.org/p/chromium/issues/detail?id=61328 Postfix and Exim have also moved on to UTS#46 non-transitional. > Any of the IDNA2008 variants mentioned above > will fix that, I think, but it's difficult to pick a variant to implement. > And I certainly don't want to implement per-TLD policies. Just move on to non-transitional UTS#46. -- Viktor. From nobody Wed Apr 12 12: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 9EDBB129649 for ; Wed, 12 Apr 2017 12:07:05 -0700 (PDT) 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 Jw642gUx1FM2 for ; Wed, 12 Apr 2017 12:07:01 -0700 (PDT) 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 8D20212955F for ; Wed, 12 Apr 2017 12:06:59 -0700 (PDT) Received: from [192.168.137.1] (unknown [82.168.30.10]) (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 D1432C1B96; Wed, 12 Apr 2017 21:06:57 +0200 (CEST) From: "Peter van Dijk" To: dnsop Date: Wed, 12 Apr 2017 21:06:56 +0200 Message-ID: <31563125-4123-4A63-873F-65A30D17DE27@powerdns.com> In-Reply-To: <03357a4d-74d8-bd97-a00b-9fd833fc3e4a@redhat.com> References: <20170407181139.GB66383@isc.org> <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> <20170411204726.GB6670@isc.org> <03357a4d-74d8-bd97-a00b-9fd833fc3e4a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:07:06 -0000 On 12 Apr 2017, at 10:21, Florian Weimer wrote: > SRV wouldn't work anyway because it is incompatible with existing name > resolution interfaces anyway. Which browsers tend to avoid as far as I know, but it’s besides the point - browsers are not doing SRV and we have to accept that. > If you do not insist on using SRV, but something that is just an alias > (like PTR, ANAME etc.) and processed in the client, it would be quite > straightforward to put this into the stub resolver, and then all > applications[*] would automatically get the addresses at the > substitution name (SNAME). Disallow multiple substitution names per > owner name and their chaining (but chaining to CNAME would be okay), > and I think it would just work. But that’s a forklift upgrade of -end user stations-. > But then DNS operators will worry about a 50% (from A/AAAA to > A/AAAA/SNAME) to 150% (from A/AAAA to A/AAAA/SNAME plus A/AAAA at the > SNAME) increase in query load. (SRV would be worse because there > could be multiple target names, all needing separate processing.) > Would that be acceptable? I don't know. I don’t know either - I do know the draft does not require anyone (except the auth operator who decides to use ANAME) to do more queries than they are doing now. > In fact, Firefox already solved the issue in the client: If you enter > the zone apex, and no address record exists, it automatically > redirects to the www name in the zone. Unfortunately, DNS operators > broke that when they started rewriting NODATA responses, injecting ads > into existing domains. So you really have to have addresses at the > zone apex these days. They solved the issue for ‘CNAME at apex’, which is not the only use case for ANAME. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Wed Apr 12 12: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 C67F51296CD for ; Wed, 12 Apr 2017 12:08:24 -0700 (PDT) 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 oAs0ZYPMzyL9 for ; Wed, 12 Apr 2017 12:08:23 -0700 (PDT) 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 42B8312EB3A for ; Wed, 12 Apr 2017 12:08:23 -0700 (PDT) Received: from [192.168.137.1] (unknown [82.168.30.10]) (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 11738C1B96; Wed, 12 Apr 2017 21:08:21 +0200 (CEST) From: "Peter van Dijk" To: dnsop Date: Wed, 12 Apr 2017 21:08:20 +0200 Message-ID: In-Reply-To: References: <20170407181139.GB66383@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:08:25 -0000 On 11 Apr 2017, at 21:11, Paul Wouters wrote: > I still feel using ANAME without preprocessing by auth nameservers and > fixing returning multiple record type to a single query is the more > generic and fix for this problem. As Evan said, we would love to go back in time and add ANAME support to all existing resolvers out there, but we can’t. Until then, the auths will have to assist, as many of them are doing today already. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Wed Apr 12 12:10: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 5A027129571 for ; Wed, 12 Apr 2017 12:10:26 -0700 (PDT) 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 TAJEWy1DvVnW for ; Wed, 12 Apr 2017 12:10:25 -0700 (PDT) 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 6809312EB3A for ; Wed, 12 Apr 2017 12:10:22 -0700 (PDT) Received: from [192.168.137.1] (unknown [82.168.30.10]) (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 EFB06C1B96; Wed, 12 Apr 2017 21:10:20 +0200 (CEST) From: "Peter van Dijk" To: dnsop Date: Wed, 12 Apr 2017 21:10:20 +0200 Message-ID: In-Reply-To: References: <20170407181139.GB66383@isc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:10:26 -0000 On 11 Apr 2017, at 20:16, Paul Wouters wrote: > On Tue, 11 Apr 2017, Tony Finch wrote: > >> ANAME >> records are not just for zone apexes. There are lots of other cases >> where >> address records need a different alias target from MX records, or >> NAPTR >> records, etc. > > Can you give me an example of deploying ANAME outside the zone APEX > that > is not solved by allowing a CNAME to point to a CNAME (which most code > I > think already allows anyway) One PowerDNS user is using ALIAS (our ANAME precursor, if you will) because he is by policy not allowed to CNAME into unsigned zones, and his app is hosted on Amazon with ELB which means Route53 is mandatory for him. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Wed Apr 12 12:15: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 9DBFB127843 for ; Wed, 12 Apr 2017 12:15:46 -0700 (PDT) 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, 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 IiH7gXud9fYB for ; Wed, 12 Apr 2017 12:15:44 -0700 (PDT) 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 A0308127077 for ; Wed, 12 Apr 2017 12:15:44 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id p68so31721537qke.1 for ; Wed, 12 Apr 2017 12:15:44 -0700 (PDT) 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=DTX90DyqNHmIdG5Z1OhJWng56sraSLjT/Td++Emmzew=; b=AYWXkqWFVmb1r3kBwG2j2WycxC2FRkgZaZZIZnbLCd3DiCSvVJrEt0ZwUNsPSCEmD5 R0mA56eYBpWoABuYYV4ek23P/zrbHOQmfDH0f14XE/yxVWBcTY9j2c+hBDulpa9ugg/m UxupAl9XeUUdsdDh/BIwKE1LO7p7pk+jjBosLp+l4vjIUbHiEEriRGGdBlG33bV7Y/pp 2VPVYbuVFNGyJDqyClet7i7B6cKobfEiQtqu041JP0lAi3Rb/XycnN0E3bD8CIrqV+4/ +qsoz40yhcA00AsDWqBIWKhZIjoF7JzYHCOTadVT4z0sz6Cl2oGeS/+3KEDKDi571T1w MGbA== 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=DTX90DyqNHmIdG5Z1OhJWng56sraSLjT/Td++Emmzew=; b=Z82g5PueijXIBAqITeCyV5uOWT57katusr9z9Hmr/y5BWuFQP9z0PFOWjBAP6rewd+ 3+H9yEHG3ylvfkQtsq1Ua3lny6Or7aPMQe4uWlcKXEKHRPBEYKcDcDPlLTsk2Ko+/CuL LbPvdBH4v5CnRKXE1ORBqJKqvErTsagfXKwY88NyPM1ExnD0JzMNr/+VHXM1DXk2Y4/U ozPS3CE1XDd0AIorqjt7c6PrMO+to5qzhHmPd7l0HR8VP0x6GjrYL5nMEr3HvfTNniYD urQqCYjvfO+cs8wDWU0i9MENu5z0byJUESLLioJFbempFasRUXK71B0wxR4DlxD+tFoJ MMrA== X-Gm-Message-State: AFeK/H0X2NnW/qFXlEsc1CMuOKpVqXc0yAeZPxyazmSG+91Lgm43n61qQWbPK2wQHC5h2g== X-Received: by 10.55.6.83 with SMTP id 80mr61721497qkg.156.1492024543609; Wed, 12 Apr 2017 12:15:43 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:cd85:180a:9395:36e5? ([2601:18f:801:600:cd85:180a:9395:36e5]) by smtp.gmail.com with ESMTPSA id f203sm10312162qka.11.2017.04.12.12.15.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 12:15:42 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 15:15:39 -0400 References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> <2CB23C57-AB73-483B-AE9F-834A933D3EC6@gmail.com> To: dnsop In-Reply-To: <2CB23C57-AB73-483B-AE9F-834A933D3EC6@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] extended deadline Re: WGLC for draft-ietf-dnsop-alt-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:15:46 -0000 I have some editorial comments on draft-ietf-dnsop-alt-tld-08. I don't = think any of these suggestions would make material changes to the = meaning of the document, but would improve consistency, readability, = etc. Given the multiple meanings of the word "context", the first sentence of = the Abstract might be clearer as: This document reserves a string (ALT) to be used as a TLD label for domain names intended for non-DNS resolution systems. Would it be clearer to use "domain name" and cite RFC 7719 in the second = sentence of section 1, instead of "Names that look like DNS names (a = series of labels separated with dots) [...]" In section 1, s/Special Use Domain/Special Use Domain Name/ to match the = name of the IANA registry. In section 1.2, I suggest citing RFC 7719 for definitions of "domain = name" and "TLD". In section 2, s/looked up/resolved/ Should RFC 2119 terms (e.g., "should not" and "SHOULD NOT") be = capitalized consistently in section 4.1? I don't think an RF 2119 "SHOULD" is appropriate for advice to human = operators of DNS servers. In section 5, I think the parenthetical would be better written without = the parentheses, as the text in parentheses seems to be as important as = the rest of the text. - Ralph > On Apr 10, 2017, at 10:38 AM, Ralph Droms = wrote: >=20 > I see that draft-ietf-dnsop-alt-tld-08 gives the intended status of = the document as Informational, while it is listed in the datatracker as = "In WG Last Call: Proposed Standard". =20 >=20 > There are arguments in favor of each status. The relevant text is in = section 5 of RFC 6761: >=20 > An IETF "Standards Action" or "IESG Approval" document specifying > some new naming behaviour, which requires a Special-Use Domain Name > be reserved to implement this desired new behaviour, needs to = contain > a subsection of the "IANA Considerations" section titled "Domain = Name > Reservation Considerations" giving answers in the seven categories > listed below. >=20 > Publishing draft-ietf-dnsop-alt-tld-08 as Proposed Standard meets the = "Standards Action" requirement. However, Proposed Standard may not be = appropriate for draft-ietf-dnsop-alt-tld-08, as the document does not = specify a new protocol, as such. draft-ietf-dnsop-alt-tld-08 does = specify certain behaviors for components of the Internet, which could be = thought of as providing for interoperability so that Proposed Standard = status would be appropriate. >=20 > On the other hand, publishing draft-ietf-dnsop-alt-tld-08 as = Informational would require an "IESG Approval" document to meet the = requirements of RFC 6761. A short sentence added to = draft-ietf-dnsop-alt-tld-08 is likely all that would be needed, to the = effect of "The IESG has reviewed this document and approves of the = request to add .alt to the Special Use Domain Names registry." >=20 > In any event, in my opinion the WG needs to express its explicit = consensus about its choice of intended status for = draft-ietf-dnsop-alt-tld-08. >=20 > - Ralph >=20 >> On Apr 7, 2017, at 9:38 AM, Suzanne Woolf = wrote: >>=20 >> Hi, >>=20 >> We had initially scheduled the WGLC on this document to be over by = now. However, the flurry of activity around the review we were asked to = do on the homenet-dot draft, and the general traffic level on the list = during IETF 98, suggested to the chairs that we should extend the WGLC. >>=20 >> We=E2=80=99re hereby formally extending it to next Wednesday, April = 12. >>=20 >> As always for WGLC=E2=80=94 we need to hear both support and = opposition for taking this draft to the next step in the process. >>=20 >> thanks, >> Suzanne & TIm >>=20 >>=20 >>> On Apr 1, 2017, at 4:17 PM, Stephane Bortzmeyer = wrote: >>>=20 >>> On Sun, Mar 12, 2017 at 07:20:55PM -0400, >>> Suzanne Woolf wrote=20 >>> a message of 92 lines which said: >>>=20 >>>> This message opens a Working Group Last Call for: >>>>=20 >>>> "The ALT Special Use Top Level Domain" >>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ = >>>=20 >>> I've read -08 and I believe I understand this draft. I'm not = convinced >>> it's useful (most users of alternative resolution systems won't use = it >>> and, anyway, I'm not even sure it will be added in the Special-Use >>> registry, which was wrongly frozen by the IESG) but I don't see big >>> issues with the draft, it seems to me it correctly describes the new >>> TLD. >>>=20 >>> Editorial : >>>=20 >>> Section 1: >>>=20 >>> "and that should not be resolved" I cannot parse it. Missing "it"? >>>=20 >>> Section 5 : >>>=20 >>> After "and anyone watching queries along the path", add a reference = to >>> RFC 7626? >>>=20 >>> Normative references: >>>=20 >>> Why is RFC 6303 a normative reference? It is no longer used. >>>=20 >>> Why is RFC 7686 a normative reference? It is just an example. >>>=20 >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >=20 From nobody Wed Apr 12 16:18: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 5D6811279E5 for ; Wed, 12 Apr 2017 16:18:07 -0700 (PDT) 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=nFyIrZn6; dkim=pass (1024-bit key) header.d=yitter.info header.b=HjXXb54/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK2s-QZjudot for ; Wed, 12 Apr 2017 16:18:05 -0700 (PDT) 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 6A02112786A for ; Wed, 12 Apr 2017 16:18:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 9518EBD996 for ; Wed, 12 Apr 2017 23:18:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492039084; bh=iE5H1UtrL+4e6NCsft6bpodoBQ0PLFv5WXDsiosxS7U=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nFyIrZn6O3j0EXZ48n+vtDey2bp4OheTEeAJxWuSQhIHBLoAP1mfFfcbfa1Y4+WOh kw2QCF2NLo7vK+4+Y7/nb2964yyhm+yWuJW5Wv+b6nQZVHxzJfVwtAWTROWYe0o69I jnbmbnGUOmcm7MbifM2UAnHhtaAPR7OWFZ1BZiR0= 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 Gco8zCdcWstN for ; Wed, 12 Apr 2017 23:18:03 +0000 (UTC) Date: Wed, 12 Apr 2017 19:18:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492039083; bh=iE5H1UtrL+4e6NCsft6bpodoBQ0PLFv5WXDsiosxS7U=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HjXXb54/Rw49uI6svFjV5hP/aD+Y+HWySaZw7TSvtRydFKp9udUqhcKOilEV1DC6s UScHCmT8QbbICD9ghCAP0qU5LXAmJ4fjwCtP5Z5lorys3phGTBSffo1Zg40pWYf6ja RRWZgSdVAKr50qfofc926rG+FhOsgPEbMsF9jDMo= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170412231803.GC6085@anvilwalrusden.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [DNSOP] Status of IDNA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 23:18:07 -0000 Accidentally sent this just to Florian. Fixing that. On Wed, Apr 12, 2017 at 01:36:49PM +0200, Florian Weimer wrote: > What's the current standardization status of IDNA? It's complicated. > As far as I can tell, a lot of vendors are still stuck with the original > IDNA standard (IDNA2003). Well, not exactly. IDNA 2003 is defined only for Unicode 3.2, which nobody has used for a long time. So strictly speaking, what most of those vendors are doing is undefined, since there's no way to know what version of Unicode you have installed. Bur practically, of course, this is what's happening. > There are three or more competing successors, > IDNA2008 as standardized by the IETF (without any tweaks), the Unicode IDNA > standard TS46 (, which is configurable > and allegedly compatible with IETF IDNA2008, but is not because it yields > different results than IETF IDNA2008), and the Mozilla/DENIC IDNA > implementation in Firefox/Thunderbird > ( and other sources). UTS#46 is allegedly a transitional technology that is supposed to do mapping so that things that did work in IDNA2003 but that won't under IDNA2008 will continue to work. As a practical matter, it does not appear to have a mechanism by which the transition can be brought to an end, so it's hard to see it as an actual transition mechanism. It's also hard to understand why it has so many characters marked as "valid" that are not valid under any version of IDNA, including many emojis. > These aren't compatible. You can see this by visiting > in different browsers. Yes. > Is there an ongoing effort to reconcile application behavior? Different > TLDs appear to expect different IDNA implementations. ICANN's rules require IDNA2008. There is a new version of the guidelines out -- I can't recall whether the public comment is closed. Many ccTLDs voluntarily conform to the guidelines also, but ICANN can't compel it. And of course ICANN has no control of other things down the tree. Part of the trouble comes because the WHATWG is apparently opposed to IDNA2008, partly on the grounds that it makes some domain names that were valid under 2003 invalid. > One practical problem with IDNA2003 is that it prevents having Hebrew domain > names containing ASCII digits. Any of the IDNA2008 variants mentioned above > will fix that, I think, but it's difficult to pick a variant to implement. > And I certainly don't want to implement per-TLD policies. Another practical problem with IDNA2003 is that it loses information round trip: Unicode can be sent into the algorithm, turned into Punycode, and when it is turned back into Unicode the result is not the same. ß is mapped, for instance, so you get back "ss" whatever you put in. This issue is one of the main things that IDNA2008 fixes, in my opinion: every valid A-label matches exactly one valid U-label, and anything that does not have this property is not a valid A- or U-label. There are problems with IDNA that have prevented it being updated for recent versions of Unicode. Asmus Freytag, John Klensin, and I are working on a draft to try to fix that. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Apr 12 16:46: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 99D041243FE for ; Wed, 12 Apr 2017 16:46:16 -0700 (PDT) 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=nFwPx3mX; dkim=pass (1024-bit key) header.d=yitter.info header.b=kJvAY8t+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2iiZpVr1kSm for ; Wed, 12 Apr 2017 16:46:15 -0700 (PDT) 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 404FB12786A for ; Wed, 12 Apr 2017 16:46:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 94975BD996 for ; Wed, 12 Apr 2017 23:45:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492040741; bh=qMh/9B1lMdz/LU5sRXrRL0g2sXK7KDtb1Adw2LucfW4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nFwPx3mXrZ+8q8e0SpF2PYIrpQb1rpaE11//fc0qhDaw5xdkt/YzcIaBYBPWz9n9m KbTWqN1Pu+ZRUPcUOWxC/CHyUA8BvgAYgAs2fHoGF9v8jpu37vRKmY7TEa4SeKeW3n VH/PFp3QFDef16irWehHROIR0rFMsu0QYv8eKXjM= 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 U8nwvvpXIOcN for ; Wed, 12 Apr 2017 23:45:40 +0000 (UTC) Date: Wed, 12 Apr 2017 19:45:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492040740; bh=qMh/9B1lMdz/LU5sRXrRL0g2sXK7KDtb1Adw2LucfW4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=kJvAY8t+dpp0sClOHSeRuC4rK6Dhtt46mLQm0GmYzzBKGc9fMM4pzIS2IZgWcysIb bcLC07fyEknp3OVExva2eW/jMELJ3kyIfevJmBI9zASN5kMxNPyJdGr6EcJeghNHVH iHDnc11qbHcLRVU5OB/n9f0xvEQEhM5VdJXrRX7U= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170412234541.GE6085@mx4.yitter.info> References: <20170412154713.GX25754@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170412154713.GX25754@mournblade.imrryr.org> Archived-At: Subject: Re: [DNSOP] Status of IDNA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 23:46:16 -0000 On Wed, Apr 12, 2017 at 03:47:14PM +0000, Viktor Dukhovni wrote: > Just move on to non-transitional UTS#46. Given that its mappings include many emojis, which aren't allowed under either IDNA2003 or IDNA2008, I think there is an apparent problem with UTS#46 too. One might be forgiven for wondering why the UTC decided that it knew something about domain names and the history of how they are used. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Apr 12 18:22: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 B16E6128D19 for ; Wed, 12 Apr 2017 18:22:55 -0700 (PDT) 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 O8Qu1G6zh3OW for ; Wed, 12 Apr 2017 18:22:54 -0700 (PDT) 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 278C3126C7B for ; Wed, 12 Apr 2017 18:22:54 -0700 (PDT) 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, 12 Apr 2017 18:22:52 -0700 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, 12 Apr 2017 18:22:51 -0700 From: Francisco Arias To: Andrew Sullivan , "dnsop@ietf.org" CC: Sarmad Hussain Thread-Topic: [DNSOP] Status of IDNA Thread-Index: AQHSs/R3YXI6VcxUDkOxq+4Fv48OEQ== Date: Thu, 13 Apr 2017 01:22:51 +0000 Message-ID: <66429AE7-8934-437C-8267-943E7C6EED47@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] Status of IDNA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 01:22:56 -0000 VGhlIGRyYWZ0IGd1aWRlbGluZXMgYXJlIHN0aWxsIGluIHB1YmxpYyBjb21tZW50IHVudGlsIDIg TWF5IGF0IGh0dHBzOi8vd3d3LmljYW5uLm9yZy9wdWJsaWMtY29tbWVudHMvaWRuLWd1aWRlbGlu ZXMtMjAxNy0wMy0wMy1lbi4gSSB0aGluayBzaW5jZSwgYXQgbGVhc3QsIHRoZSBjdXJyZW50IHZl cnNpb24gKDMuMCBwdWJsaXNoZWQgaW4gMjAxMSkgSUROQSAyMDA4IGlzIHRoZSBydWxlIGZvciBu ZXcgcmVnaXN0cmF0aW9ucy4gSSBiZWxpZXZlIGJvdGggdGhlIGN1cnJlbnQgdmVyc2lvbiBhbmQg dGhlIGRyYWZ0IHRoYXQgaXMgcHVibGljIGNvbW1lbnQgZ3JhbmRmYXRoZXIgZXhpc3RpbmcgSURO QSAyMDAzIHJlZ2lzdHJhdGlvbnMuDQoNCi0tIA0KRnJhbmNpc2NvDQoNCk9uIDQvMTIvMTcsIDQ6 MTggUE0sICJETlNPUCBvbiBiZWhhbGYgb2YgQW5kcmV3IFN1bGxpdmFuIiA8ZG5zb3AtYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWpzQGFudmlsd2FscnVzZGVuLmNvbT4gd3JvdGU6DQoN CiAgICA+SXMgdGhlcmUgYW4gb25nb2luZyBlZmZvcnQgdG8gcmVjb25jaWxlIGFwcGxpY2F0aW9u IGJlaGF2aW9yPyAgRGlmZmVyZW50DQogICAgPlRMRHMgYXBwZWFyIHRvIGV4cGVjdCBkaWZmZXJl bnQgSUROQSBpbXBsZW1lbnRhdGlvbnMuDQogICAgDQogICAgSUNBTk4ncyBydWxlcyByZXF1aXJl IElETkEyMDA4LiAgVGhlcmUgaXMgYSBuZXcgdmVyc2lvbiBvZiB0aGUNCiAgICBndWlkZWxpbmVz IG91dCAtLSBJIGNhbid0IHJlY2FsbCB3aGV0aGVyIHRoZSBwdWJsaWMgY29tbWVudCBpcyBjbG9z ZWQuDQogICAgTWFueSBjY1RMRHMgdm9sdW50YXJpbHkgY29uZm9ybSB0byB0aGUgZ3VpZGVsaW5l cyBhbHNvLCBidXQgSUNBTk4NCiAgICBjYW4ndCBjb21wZWwgaXQuICBBbmQgb2YgY291cnNlIElD QU5OIGhhcyBubyBjb250cm9sIG9mIG90aGVyIHRoaW5ncw0KICAgIGRvd24gdGhlIHRyZWUuDQoN Cg== From nobody Wed Apr 12 19:39: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 8B2CF126C26 for ; Wed, 12 Apr 2017 19:39:38 -0700 (PDT) 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 W-x6qWxxlrED for ; Wed, 12 Apr 2017 19:39:37 -0700 (PDT) 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 1FE7D12704A for ; Wed, 12 Apr 2017 19:39:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 465967A3309; Thu, 13 Apr 2017 02:39:36 +0000 (UTC) Date: Thu, 13 Apr 2017 02:39:36 +0000 From: Viktor Dukhovni To: dnsop@ietf.org Message-ID: <20170413023935.GA25754@mournblade.imrryr.org> Reply-To: dnsop@ietf.org References: <20170412154713.GX25754@mournblade.imrryr.org> <20170412234541.GE6085@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170412234541.GE6085@mx4.yitter.info> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] Status of IDNA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 02:39:38 -0000 On Wed, Apr 12, 2017 at 07:45:41PM -0400, Andrew Sullivan wrote: > On Wed, Apr 12, 2017 at 03:47:14PM +0000, Viktor Dukhovni wrote: > > > Just move on to non-transitional UTS#46. > > Given that its mappings include many emojis, which aren't allowed > under either IDNA2003 or IDNA2008, I think there is an apparent > problem with UTS#46 too. One might be forgiven for wondering why the > UTC decided that it knew something about domain names and the history > of how they are used. Well, IIRC they sensibly converged on a case-folded normal form that ensures that https://Духовный.org maps to the same underlying wire-form domain as https://духовный.org, i.e. both result in queries for xn--b1adqpd3ao5c.org. AFAIK, those would generally be different domains under IDNA2008. While is true that UTS#46 maps .org to xn--ls8h.org, (see http://www.fileformat.info/info/unicode/char/1f4a9/index.htm) that seems to be a small price to pay for avoing surprising case-sensitive behaviour. -- Viktor. From nobody Thu Apr 13 01: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 45AB2129502 for ; Thu, 13 Apr 2017 01:46:34 -0700 (PDT) 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 H4JOd7MHJ7CB for ; Thu, 13 Apr 2017 01:46:32 -0700 (PDT) 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 7D704128DE7 for ; Thu, 13 Apr 2017 01:46:26 -0700 (PDT) Received: from [192.168.137.1] (unknown [82.168.30.10]) (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 DE6C2C5C4B; Thu, 13 Apr 2017 10:46:24 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Thu, 13 Apr 2017 10:46:23 +0200 Message-ID: <05429B5D-904B-4913-9843-654C917DEA27@powerdns.com> In-Reply-To: References: <20170407181139.GB66383@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 08:46:34 -0000 On 11 Apr 2017, at 17:54, Tony Finch wrote: > When an ANAME record is present at a DNS node and a query is > received > by an authoritative server for type A or AAAA, the authoritative > server returns the ANAME RR in the answer section. > > Wouldn't it be safer to put the ANAME in the additional section? My thinking was that given that DNAME got away with being in ANSWER, so could we. > Do we care about SSHFP? I understand the question but I’m uncomfortable extending ANAME beyond address types. I will put it on the list of things that need more thought. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Thu Apr 13 02:29: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 D637A12EC20 for ; Thu, 13 Apr 2017 02:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 wwVdxr_YPg6N for ; Thu, 13 Apr 2017 02:29:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9692F12EBF7 for ; Thu, 13 Apr 2017 02:29:09 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A991FC04BD4F for ; Thu, 13 Apr 2017 09:29:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A991FC04BD4F Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A991FC04BD4F Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 56EAB7DED4 for ; Thu, 13 Apr 2017 09:29:08 +0000 (UTC) To: dnsop From: Florian Weimer Message-ID: <24869f89-8335-6ad8-667d-300b852957a1@redhat.com> Date: Thu, 13 Apr 2017 11:29:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 13 Apr 2017 09:29:09 +0000 (UTC) Archived-At: Subject: [DNSOP] Redefining name canonicalization X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:29:11 -0000 I would like to propose the restrict name canonicalization (as performed by stub resolvers) to forming a fully-qualified domain name with the help of the search list. With the current rules based on resolving CNAME chains, we end up with the following results: >>> socket.getfqdn('access.redhat.com') 'a23-214-169-56.deploy.static.akamaitechnologies.com' >>> socket.getfqdn('access') 'a23-214-169-56.deploy.static.akamaitechnologies.com' This is pretty much useless. In fact, what is advertised here as the canonical name is just a temporary, location-dependent name which bears no direct relationship to the service being provided. There isn't anything canonical about it. I think both calls should return 'access.redhat.com' (assuming that 'redhat.com' is the search list entry which is used to form the FQDN). This also avoids issues related to insecure name canonicalization (based on spoofable DNS data) which affects the use of some cryptographic libraries, notably Kerberos. Comments? Thanks, Florian From nobody Thu Apr 13 02:54: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 00D8C13148A for ; Thu, 13 Apr 2017 02:54:10 -0700 (PDT) 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 TgqQQK9QspvR for ; Thu, 13 Apr 2017 02:54:08 -0700 (PDT) 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 EA1F2131464 for ; Thu, 13 Apr 2017 02:54:07 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id o21so32367175wrb.2 for ; Thu, 13 Apr 2017 02:54:07 -0700 (PDT) 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=Pyf/HZWBKOuWyqQ+TkvApzeasayluaAxqF4frDFNgQ4=; b=u6f5RptWSZHJwndztti5J/oL5Yvub4E6KzY8/9hJAWRm4y75Zf30x6MH0IPxo7wHFm ZjOvR4ipWiuRSsradSMYekXN4BYf/YvdWg2XZhtPD4ZsZWsTPeR2k3JmHTRaKAq6dIwv +3l+s6/3EvdUhl8emgGYIBzPYkPCnYznmKw6xFw3y8bbRTZPiYtQVVxUrLb7A6kufqRk Qzajax6RbzFfc6PZ7KNcc2/JJ8yop0NvfzXmVO9Rsjf0K46TGsBP2PLUTIWymZ8jk+Ns l/it+yf6DfcLZiIPLTdqoU8a6Rb4YD/jKidT7zYdqh3tGsewRn/KlypP31OZ/48GEWBE 26Yw== 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=Pyf/HZWBKOuWyqQ+TkvApzeasayluaAxqF4frDFNgQ4=; b=OomJ/Q3FUaHBodNq6N2k4y9bDXgTqSxcUF5RTy3t/kjbjHjtXfonfV89tJEd1Kcnhq gkKG3H6fEMn7UWLf7rqyxnqwnT8fc/Y/n0QNxdmMM4v12Ksh5SBw8kPxRZ6u7kviiH+7 T2+LJy+VydanozWq8vBDk13i8SKDLdW6EZPV4IeBjMXrgB0b/+NB5J+U/miT3sSHj7bT /YliC9Ns5h8f+j3d/yrX3YqG5keHNaH7vdhkG5IgSWMwbI+WhOqTqhEnRAxli1NS8IEO W6hCf62QoJn0e7llt9YZrsYhN96iUhFK3kTRRq4ZeoQo/2hSLo6lNOoFeLm9NY093BMF AmpQ== X-Gm-Message-State: AN3rC/4NUHpf2ebmCQMYdydqPMagPTHQMzGXyxxoXhDOpk+QmQne4kwr R4fSRQPVSPCUsAw6y3UMZfndMicxY0mi X-Received: by 10.223.160.87 with SMTP id l23mr2261923wrl.24.1492077246543; Thu, 13 Apr 2017 02:54:06 -0700 (PDT) MIME-Version: 1.0 References: <20170407181139.GB66383@isc.org> In-Reply-To: From: Lanlan Pan Date: Thu, 13 Apr 2017 09:53:55 +0000 Message-ID: To: Peter van Dijk Cc: dnsop Content-Type: multipart/alternative; boundary=94eb2c065c8441fb13054d094ec0 Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:54:10 -0000 --94eb2c065c8441fb13054d094ec0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Peter, one question, will authoritative server return multiple ANAME RRs for the same domain at one dns query ? for example, www.example.com ANAME us.www.example.com www.example.com ANAME cn.www.example.com or return only one selected ANAME RR for one domain ? (based on authoritative's policy, resolver ip/client subnet/...) www.example.com ANAME us.www.example.com thanks Peter van Dijk =E4=BA=8E2017=E5=B9=B44=E6=9C= =8813=E6=97=A5=E5=91=A8=E5=9B=9B =E4=B8=8A=E5=8D=883:10=E5=86=99=E9=81=93= =EF=BC=9A > On 11 Apr 2017, at 20:16, Paul Wouters wrote: > > > On Tue, 11 Apr 2017, Tony Finch wrote: > > > >> ANAME > >> records are not just for zone apexes. There are lots of other cases > >> where > >> address records need a different alias target from MX records, or > >> NAPTR > >> records, etc. > > > > Can you give me an example of deploying ANAME outside the zone APEX > > that > > is not solved by allowing a CNAME to point to a CNAME (which most code > > I > > think already allows anyway) > > One PowerDNS user is using ALIAS (our ANAME precursor, if you will) > because he is by policy not allowed to CNAME into unsigned zones, and > his app is hosted on Amazon with ELB which means Route53 is mandatory > for him. > > Kind regards, > -- > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --94eb2c065c8441fb13054d094ec0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Peter,

one question, w= ill authoritative server return multiple ANAME RRs for the same domain at o= ne dns query ?

for example,

www.example.com=C2=A0 ANAME=C2=A0 us.www.example.com
www.example.com=C2=A0 ANAME=C2=A0 cn.www.example.com

or=C2=A0 return only one s= elected ANAME RR for one domain ? (based on authoritative's policy, res= olver ip/client subnet/...)

www.= example.com=C2=A0 ANAME=C2=A0 us.www= .example.com

thanks

<= div>
Peter van Dijk <peter.van.dijk@powerdns.com>= =E4=BA=8E2017=E5=B9=B44=E6=9C=8813=E6=97=A5=E5=91=A8=E5=9B=9B =E4=B8=8A=E5= =8D=883:10=E5=86=99=E9=81=93=EF=BC=9A
On 11 Apr 2017, at 20:16, Paul Wouters wrote:

> On Tue, 11 Apr 2017, Tony Finch wrote:
>
>> ANAME
>> records are not just for zone apexes. There are lots of other case= s
>> where
>> address records need a different alias target from MX records, or<= br> >> NAPTR
>> records, etc.
>
> Can you give me an example of deploying ANAME outside the zone APEX > that
> is not solved by allowing a CNAME to point to a CNAME (which most code=
> I
> think already allows anyway)

One PowerDNS user is using ALIAS (our ANAME precursor, if you will)
because he is by policy not allowed to CNAME into unsigned zones, and
his app is hosted on Amazon with ELB which means Route53 is mandatory
for him.

Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85= =B0=C2=A0 Pan Lanlan
--94eb2c065c8441fb13054d094ec0-- From nobody Thu Apr 13 03: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 65AE113146D for ; Thu, 13 Apr 2017 03:54:57 -0700 (PDT) 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 kFZpfgKroCoZ for ; Thu, 13 Apr 2017 03:54:55 -0700 (PDT) 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 0D8E11314F6 for ; Thu, 13 Apr 2017 03:54:55 -0700 (PDT) Received: from [192.168.137.1] (unknown [82.168.30.10]) (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 0C6B0C1B96; Thu, 13 Apr 2017 12:54:52 +0200 (CEST) From: "Peter van Dijk" To: dnsop Date: Thu, 13 Apr 2017 12:54:50 +0200 Message-ID: <3DE75A19-455D-4E5C-B0CC-FBB4D42B5D81@powerdns.com> In-Reply-To: References: <20170407181139.GB66383@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 10:54:57 -0000 Hello, On 13 Apr 2017, at 11:53, Lanlan Pan wrote: > Hi Peter, > > one question, will authoritative server return multiple ANAME RRs for > the > same domain at one dns query ? > > for example, > > www.example.com ANAME us.www.example.com > www.example.com ANAME cn.www.example.com > > or return only one selected ANAME RR for one domain ? (based on > authoritative's policy, resolver ip/client subnet/...) > > www.example.com ANAME us.www.example.com Currently the draft explicitly states ‘No more than one ANAME resource record SHALL be present at any DNS node.’, but we have received multiple requests to relax this requirements, and will consider that. That said, nothing prevents your own implementation from choosing the target based on any kind of local policy. So if you want to pick US or CN based on client IP, you can do that. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Thu Apr 13 04:30: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 F2B9713151B for ; Thu, 13 Apr 2017 04:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zcA0d1QeBhyP for ; Thu, 13 Apr 2017 04:30:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3569813151A for ; Thu, 13 Apr 2017 04:30:15 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BA9A9C059752; Thu, 13 Apr 2017 11:30:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BA9A9C059752 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BA9A9C059752 Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2C8E77FB8A; Thu, 13 Apr 2017 11:30:13 +0000 (UTC) To: Peter van Dijk , dnsop References: <20170407181139.GB66383@isc.org> <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> <20170411204726.GB6670@isc.org> <03357a4d-74d8-bd97-a00b-9fd833fc3e4a@redhat.com> <31563125-4123-4A63-873F-65A30D17DE27@powerdns.com> From: Florian Weimer Message-ID: <202c9532-0f08-5f4d-4c9f-01111ef06c33@redhat.com> Date: Thu, 13 Apr 2017 13:30:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <31563125-4123-4A63-873F-65A30D17DE27@powerdns.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 13 Apr 2017 11:30:14 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 11:30:17 -0000 On 04/12/2017 09:06 PM, Peter van Dijk wrote: > On 12 Apr 2017, at 10:21, Florian Weimer wrote: > >> SRV wouldn't work anyway because it is incompatible with existing name >> resolution interfaces anyway. > > Which browsers tend to avoid as far as I know, but it’s besides the > point - browsers are not doing SRV and we have to accept that. If the browser uses DNS directly, it won't be able to use NIS/LDAP, WINS, Bonjour, or LLDNS. Firefox on GNU/Linux uses getaddrinfo, as expected. >> If you do not insist on using SRV, but something that is just an alias >> (like PTR, ANAME etc.) and processed in the client, it would be quite >> straightforward to put this into the stub resolver, and then all >> applications[*] would automatically get the addresses at the >> substitution name (SNAME). Disallow multiple substitution names per >> owner name and their chaining (but chaining to CNAME would be okay), >> and I think it would just work. > > But that’s a forklift upgrade of -end user stations-. It's just about an optimization. I think it's doable, except that we'd receive pushback on the query load issue. >> But then DNS operators will worry about a 50% (from A/AAAA to >> A/AAAA/SNAME) to 150% (from A/AAAA to A/AAAA/SNAME plus A/AAAA at the >> SNAME) increase in query load. (SRV would be worse because there >> could be multiple target names, all needing separate processing.) >> Would that be acceptable? I don't know. > > I don’t know either - I do know the draft does not require anyone > (except the auth operator who decides to use ANAME) to do more queries > than they are doing now. Right, that's one advantage of the ANAME proposal. Florian From nobody Thu Apr 13 04:33: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 3D8D713151B for ; Thu, 13 Apr 2017 04:33:20 -0700 (PDT) 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=E1hXGDQq; dkim=pass (1024-bit key) header.d=yitter.info header.b=i9KNp3vE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEMf-heh0xHS for ; Thu, 13 Apr 2017 04:33:18 -0700 (PDT) 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 0F6E9126C0F for ; Thu, 13 Apr 2017 04:33:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 70608BD996 for ; Thu, 13 Apr 2017 11:33:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492083197; bh=13+JtI44CgrBPv1WnYNTPZptEEECjOCFUWJDQZc3myw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=E1hXGDQqZ3z7iwwv6KJDiNIFWcb9hmpDkFfa6dOhZj9mH72Q+ramz6V6JLe2P+y0x z2NrRt4JYfSqnKVSn80LVvJJwE/GtntFFrvKmGmI4Lg+l1vZ7nn/onIs864pum8z2B T4bxoQ6liMZHsluVTbvEOr92ItpVXRKmpjoF0pf4= 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 z-ngyVLB4Dyx for ; Thu, 13 Apr 2017 11:33:15 +0000 (UTC) Date: Thu, 13 Apr 2017 07:33:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492083195; bh=13+JtI44CgrBPv1WnYNTPZptEEECjOCFUWJDQZc3myw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=i9KNp3vEgWts49EOMCUIeSuw2IMA76pr6qveR3tqhA1UyRvyGL7kZ0MRVANEJmQW8 kgh6qQrvdbGB7Cof/rZwgDWsvbS5j0tO4aRkWsiuArwvn1UPeKzLhuFkY4azaWCk9J 8GiNXZ5H+OATvHmR4Iq7zjXbCbkjK5W/IRE7N+GI= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170413113312.GA6422@mx4.yitter.info> References: <20170412154713.GX25754@mournblade.imrryr.org> <20170412234541.GE6085@mx4.yitter.info> <20170413023935.GA25754@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170413023935.GA25754@mournblade.imrryr.org> Archived-At: Subject: Re: [DNSOP] Status of IDNA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 11:33:20 -0000 On Thu, Apr 13, 2017 at 02:39:36AM +0000, Viktor Dukhovni wrote: > > Well, IIRC they sensibly converged on a case-folded normal form > that ensures that https://Духовный.org maps to the same underlying > wire-form domain as https://духовный.org, i.e. both result in > queries for xn--b1adqpd3ao5c.org. AFAIK, those would generally be > different domains under IDNA2008. They would be different domains because the first of them is DISALLOWED. But everyone knew, when making IDNA2008, that removing the case mapping from the protocol meant that clients needed to do it before starting. That's what https://tools.ietf.org/html/rfc5895 was all about (a document that could have moved faster if some participants had collaborated more enthusiastically instead of, well, going away and making their own protocol). One of the problems we had with IDNA2003 was that the protocol did the caseFold operation. The difficulty there was that there was no way to pay attention to locale or other information that might tell you the right thing to do, because caseFold is not nearly as simple as ASCII always pretended it was. IDNA2008's answer was to kick this problem out of the protocol and into user agents, which were supposed to do this in a sensible way. If UTS#46 had restricted itself to that kind of job, it could well have been an enormous contribution to the practical use of IDNs. Unfortunately, it didn't do just that. > While is true that UTS#46 maps .org to xn--ls8h.org, (see In the way I'm using the term, that's not mapping, that's re-encoding. The idea of "mapping" is to substitute in some more or less predictable way some set of Unicode code points for some other set of Unicode code points. Then you can run the resulting final string through the IDNA2008 algorithm. The problem with treaing U+1F4A9 as an acceptable character for an identifier is not in itself -- maybe it is fine on its own -- but that it is part of a class of characters that do not have normalizations and are not letters or digits. The IETF took seriously the advice from UTC that we should use the stable categories that UTC had invented, and derive our properties from those. We did so, and no emojis are in the categories that we used for the derivation. It is therefore more than a little frustrating to see the same UTC now recommending that such characters be used in identifiers on the network. Such use is particularly bad with emojis because they have no normalization either, and they interact in some ways with ZWNJ. They provide a completely new playground for attackers to use in phishing and so on, and we already have _enough_ trouble with that without inventing new ways to cause ourselves grief. Anyway, I doubt very much that DNSOP is the list where this ought to be discussed (idna-update is still an open list, as is the IAB's i18n-discuss list even though the program is closed, and precis is still an active WG last I checked). But any sentence about internationalization that involves the concept "just do _x_" is, I think, already too naïve. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Apr 13 10:54: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 C89E813146D for ; Thu, 13 Apr 2017 10:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 1nO1smaNP0j2 for ; Thu, 13 Apr 2017 10:54:16 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 1B04212EB09 for ; Thu, 13 Apr 2017 10:54:06 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id t144so33316199lff.1 for ; Thu, 13 Apr 2017 10:54:05 -0700 (PDT) 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=E/GqmkYFWure3mHrRXmIt1AadClFrE/eTkuboeET/Ck=; b=tx4Z3p/rJMsh7s8Q0TAhB+3zkWYaDp21Jn97DwOfjoW9dEq6rewgkUVp2TRI+9eUPz Dps/V0f6ozCUTn6g2EXLakCQODrj04HFMZ81cXJBSGyLEnx4Rp+KOzG+ETkYEV1Nf53h uW0u9ptPHL7GfjRIOWcqo10gb4QvXa7pTS0O6fmaehn0Jcu1yAkudELmcVNYixsTJ0Bp gTkv5yDeWiy9jazvcQr8b4C1W4TUVYHuA6ddOqFfENVgkYocuZqYUeq4tXyQcNJt5aXF 4HIL0uhkn5fuyho9fC2ddxDKTk1FDUzH5TlcPAC9O/xMrAe1ZmJuaaMlmBOBxRW1pIQL MbuA== 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=E/GqmkYFWure3mHrRXmIt1AadClFrE/eTkuboeET/Ck=; b=XUO6oesENH/xbA21c/eOuT0mosRJY9svwJivnlQcI/OEY6w6PP/iOJsc3AQffyr2oY Mg+kuY1JURLGQzcB68zMmVdfqISNJpYCgetK4mZGbAdDjGsmOfr6UHio26+Xs4FSA6P1 4zEmH5++aL/YI3uwE3F8N4OvB0nW5a7fdXLPlwc/gu2hNeEh2NtsHenSCmrgXLiD3J8n Vr0jofORF7bMb5Ky4bQodtMplxoQk0eCOm2PRh6ETh1BLhfLMM1cV0aEoD780HsYCNXD LiIoTdaUfmhjabkuIQfhKYfQcpXbJvLvRmjkFF8sVY3EtiOj6v1f86oqLWwCSqKGCr0T OybA== X-Gm-Message-State: AN3rC/5wTYDYnuiye+cWeUwSpjpnDM1LpiLR1RZBqnGyqZxq7jUG9Zpo qL+rDX0RvsIq6lJ+2dsNy6yjoUjt5A== X-Received: by 10.25.155.145 with SMTP id d139mr1474309lfe.174.1492106044129; Thu, 13 Apr 2017 10:54:04 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Thu, 13 Apr 2017 10:54:03 -0700 (PDT) In-Reply-To: References: <149130746853.30870.8028044269482471265@ietfa.amsl.com> From: Daniel Migault Date: Thu, 13 Apr 2017 13:54:03 -0400 X-Google-Sender-Auth: IX_UBV3ypVPYBnsfbkm7zHzsowk Message-ID: To: Wes Hardaker Cc: Bob Harold , IETF DNSOP WG Content-Type: multipart/alternative; boundary=001a11402298ba47ae054d10021e Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 17:54:20 -0000 --001a11402298ba47ae054d10021e Content-Type: text/plain; charset=UTF-8 Hi, Please find some comments I have quickly written as reading the draft. Yours, Daniel Security Considerations for RFC5011 Publishers draft-ietf-dnsop-rfc5011-security-considerations-00 5. Denial of Service Attack Considerations If an attacker is able to provide a RFC5011 validating engine with past responses, such as when it is in-path or able to otherwise perform any number of cache poisoning attacks, the attacker may be able to leave the RFC5011-compliant validator without an appropriate DNSKEY trust anchor. This scenario will remain until an administrator manually fixes the situation. MGLT: While reading the paragraph above, it is not obvious to the reader that the remaining section will clarify this. I think equivalent o fthe sentence below would be appreciated. The following timeline illustrates this situation. 5.1. Enumerated Attack Example The following example settings are used in the example scenario within this section: MGLT: I think it would be helpful to define variable, that we could easily refer in the text. As time values are expressed in seconds, I would also suggest that time is expressed in seconds even though we should use human readable expressions for the time. More specifically, I would have T-1 be expressed as T-1day and T-1 representing T-1 second. Maybe that would also ease to match the signaling to use Signature Expiration Date instead of DNSKEY RRIG Validation. I was also confused by the Validation of 10 days. My understanding was that data signed at T were valid until T + 10, and in the description below, it seems that data signed at T - 1 are valid until T + 10. In my opinion this is more T + 9. But I might be wrong. I also think that the use case here relies on strong assumption. One of them is that the zone is generated with mostly fields with the same value. In other words, there is no consideration of having TTLS values, Signature Expiration updated during the roll over. As the zone is generated every day, maybe that would help the description by indexing the data for each day, thus making it clear this field generated at this day. OLD: TTL (all records) 1 day DNSKEY RRSIG Signature Validity 10 days Zone resigned every 1 day NEW: TTL designates the minimum TTL value associated the DNSKEY, RRSIG RRsets. According to RFC4034 section 3, the TTL of the DNSKEY and the one of the RRSIG are the same. Signature Expiration Date designates the date after which the signature cannot be used for DNSSEC validation. RFC4034 section 3.1.5 Signature Inception Date designates.... RFC4034 section 3.1.5 OPTIONAL This section provides an illustrative example and assumes: - Only static values are used. In other words, there is no dynamically increaseing, decreasing TTLs or Expiration Date. - A single TTL value is used for both KSKs. In the general case we could have different values of TTL. This value is set here to 1 day. - The zone is signed every day at time T. - Each day the Expiration day is set to T + 10 days Given these settings, the following sequence of events depicts how a Trust Anchor Publisher that waits for only the RFC5011 hold time timer length of 30 days subjects its users to a potential Denial of Service attack. The timing schedule listed below is based on a new trust anchor (a Key Signing Key (KSK)) being published at time T+0. All numbers in this sequence refer to days before and after such an event. Thus, T-1 is the day before the introduction of the new key, and T+15 is the 15th day after the key was introduced into the fictitious zone being discussed. In this dialog, we consider two keys being published: K_old The older KSK being replaced. K_new The new KSK being transitioned into active use, using the RFC5011 process. In this dialog, the following actors are playing roles in this situation: Zone Signer The owner of a zone intending to publish a new Key- Signing-Key (KSK) that will become a trust anchor by validators following the RFC5011 process. RFC5011 Validator A DNSSEC validator that is using the RFC5011 processes to track and update trust anchors. Hardaker & Kumari Expires October 5, 2017 [Page 4] Internet-Draft RFC5011 Security Considerations April 2017 Attacker An attacker intent on foiling the RFC5011 Validator's ability to successfully adopt the Zone Signer's K_new key as a new trust anchor. 5.1.1. Attack Timing Breakdown The following series of steps depicts the timeline in which an attack occurs that foils the adoption of a new DNSKEY by a Trust Anchor Publisher that revokes the old key too quickly. MGLT: T-1, are mostly indexing the zone, maybe that easier to start from this set. T-1 The last signatures are published by the Zone Signer that signs only K_old using K_old. The Attacker queries for, retrieves and caches this keyset and corresponding signatures. MGLT: Maybe we could clarify the state of the cache. This can be done until (T-0day) - 1 seconde, which means RRSIG will be considered valid until Expiration Date = T - 0 days + 10 days while K_old will be considered valid for TTL, that is until T + TTL - 1. T-0 The Zone Signer adds K_new to his zone and signs the zone's key set with K_old. The RFC5011 Validator retrieves the new key set and corresponding signature set and notices the publication of K_new. The RFC5011 Validator starts the (30-day) hold-down timer for K_new. T+5 The RFC5011 Validator queries for the zone's keyset per the Active Refresh schedule, discussed in Section 2.3 of RFC5011. Instead of receiving the intended published keyset, the Attacker successfully replays the keyset and associated signatures that they recorded at T-1. MGLT: The keyset at T-1day is also the keyset at T-0 day - 1 sec. I believe the text should make clear there is an interval. As the expiration time has been set to T - 1 + 10 days. These data are still considered valid at T + 5. Because the signature lifetime is 10 days (in this example), the replayed signature and keyset is accepted as valid (being only 6 days old) and the RFC5011 Validator cancels the hold-down timer for K_new. MGLT: T + 9: Replayed signature at published at T - 1 are not valid any more and cannot be replayed. I believe T + 9 replaces T + 10. T+10 The RFC5011 Validator queries for the zone's keyset and discovers K_new again, signed by K_old (the attacker is unable to replay the records cached at T-1, because they have now expired). The RFC5011 Validator starts (anew) the hold-timer for K_new. MGLT: I think we should explicitly specify that for 30 days, K_new will not be used to validate. I also think it is important to note that the validator can receive any response with Expiration Time greater then T + 9 and Inception Time lower than T + 9. This means that when dynamic parameters are applied, we cannot assume that the response corresponds to the values provided at T + 9. T+15,T+20, and T+25 The RFC5011 Validator continues checking the zone's key set and lets the hold-down timer keep running without resetting it. T+30 The Zone Signer knows that this is the first time at which some validators might accept K_new as a new trust anchor, since the hold-down timer of a RFC5011 Validator not under attack that had queried and retrieved K_new at T+0 would now have reached 30 days. However, the hold-down timer of our attacked RFC5011 Validator is only at 20 days. T+35 The Zone Signer (mistakenly) believes that all validators following the Active Refresh schedule (Section 2.3 of RFC5011) should have accepted K_new as a the new trust anchor (since the Hardaker & Kumari Expires October 5, 2017 [Page 5] Internet-Draft RFC5011 Security Considerations April 2017 hold down time of 30 days + 1/2 the signature validity period would have passed). MGLT: There is a strong assumption that Expiration time is always set to Zone generation + 10 days. However, the hold-down timer of our attacked RFC5011 Validator is only at 25 days; The replay attack at T+5 means its new hold-time timer actually started at T+10, and thus at this time it's real hold-down timer is at T+35 - T+10 = 25 days, which is less than the RFC5011 required 30 days. T+36 The Zone Signer, believing K_new is safe to use, switches their active signing KSK to K_new and publishes a new DNSKEY set signature signed with K_new. Non-attacked RFC5011 validators, with a hold-down timer of at least 30 days, would have accepted K_new into their set of trusted keys. But, because our attacked RFC5011 Validator still has a hold-down timer for K_new at 26 days, it will fail to accept K_new as a trust anchor and since K_old is no longer being used, all the KSK records from the zone signed by K_new will be treated as invalid. Subsequently, all keys in the key set are now unusable, invalidating all records in the zone of any type and name. 6. Minimum RFC5011 Timing Requirements Given the attack description in Section 5, the correct minimum length of time required for the Zone Signer to wait before using K_new is: MGLT: On Thu, Apr 6, 2017 at 6:34 PM, Wes Hardaker wrote: > Bob Harold writes: > > > This one still needs to be fixed: > > Thanks Bob. That was a straight copy; I hope to do a new > version immediately and will certainly make that change. > -- > Wes Hardaker > USC/ISI > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a11402298ba47ae054d10021e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

Please find some comments I have quickly written as reading the draft.
=
Yours,
Daniel

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Security Consi= derations for RFC5011 Publishers
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 draft-ietf-dnsop-rfc5011-security-considerations-00

= 5.=C2=A0 Denial of Service Attack Considerations

=C2=A0=C2=A0 If an = attacker is able to provide a RFC5011 validating engine with
=C2=A0=C2= =A0 past responses, such as when it is in-path or able to otherwise
=C2= =A0=C2=A0 perform any number of cache poisoning attacks, the attacker may b= e
=C2=A0=C2=A0 able to leave the RFC5011-compliant validator without an = appropriate
=C2=A0=C2=A0 DNSKEY trust anchor.=C2=A0 This scenario will r= emain until an
=C2=A0=C2=A0 administrator manually fixes the situation.<= br>

MGLT: While reading the paragraph above, it is not obvious to = the reader that the remaining section will clarify this. I think equivalent= o fthe sentence below would be appreciated.=C2=A0

=C2=A0=C2= =A0 The following timeline illustrates this situation.

=C2=A0=C2=A0 =
5.1.=C2=A0 Enumerated Attack Example

=C2=A0=C2=A0 The following = example settings are used in the example scenario
=C2=A0=C2=A0 within th= is section:

MGLT: I think it would be helpful to define variable, th= at we could easily refer in the text. As time values are expressed in secon= ds, I would also suggest that time is expressed in seconds even though we s= hould use human readable expressions for the time. More specifically, I wou= ld have T-1 be expressed as T-1day and T-1 representing T-1 second.=C2=A0= =C2=A0
Maybe that would also ease to match the signaling to use Signatu= re Expiration Date instead of DNSKEY RRIG Validation.=C2=A0
I was also = confused by the Validation of 10 days. My understanding was that data signe= d at T were valid until T + 10, and in the description below, it seems that= data signed at T - 1 are valid until T + 10. In my opinion this is more T = + 9. But I might be wrong.=C2=A0
I also think that the use case here re= lies on strong assumption. One of them is that the zone is generated with m= ostly fields with the same value. In other words, there is no consideration= of having TTLS values, Signature Expiration updated during the roll over. =
As the zone is generated every day, maybe that would help th= e description by indexing the data for each day, thus making it clear this = field generated at this day.=C2=A0 =C2=A0
=C2=A0
OLD:=C2= =A0=C2=A0
=C2=A0=C2=A0 TTL (all records)=C2=A0 1 day

=C2=A0=C2= =A0 DNSKEY RRSIG Signature Validity=C2=A0 10 days

=C2=A0=C2=A0 Zone = resigned every=C2=A0 1 day
NEW:

=C2=A0=C2=A0 TTL designates the m= inimum TTL value associated the DNSKEY, RRSIG RRsets. According to RFC4034 = section 3, the TTL of the DNSKEY and the one of the RRSIG are the same.
= =C2=A0=C2=A0
=C2=A0=C2=A0 Signature Expiration Date designates the date= after which the signature cannot be used for DNSSEC validation. RFC4034 se= ction 3.1.5
=C2=A0=C2=A0
=C2=A0=C2=A0 Signature Inception Date desig= nates.... RFC4034 section 3.1.5 OPTIONAL
=C2=A0=C2=A0
This section p= rovides an illustrative example and assumes:
=C2=A0=C2=A0=C2=A0 - Only s= tatic values are used. In other words, there is no dynamically increaseing,= decreasing TTLs or Expiration Date.=C2=A0
=C2=A0=C2=A0=C2=A0 - A singl= e TTL value is used for both KSKs. In the general case we could have differ= ent values of TTL. This value is set here to 1 day.
=C2=A0=C2=A0=C2=A0 -= The zone is signed every day at time T.
=C2=A0=C2=A0=C2=A0 - Each day t= he Expiration day is set to T + 10 days =C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=
=C2=A0=C2=A0 Given these settings, the following sequence of events de= picts how a
=C2=A0=C2=A0 Trust Anchor Publisher that waits for only the = RFC5011 hold time
=C2=A0=C2=A0 timer length of 30 days subjects its user= s to a potential Denial of
=C2=A0=C2=A0 Service attack.=C2=A0 The timing= schedule listed below is based on a new
=C2=A0=C2=A0 trust anchor (a Ke= y Signing Key (KSK)) being published at time T+0.
=C2=A0=C2=A0 All numbe= rs in this sequence refer to days before and after such an
=C2=A0=C2=A0 = event.=C2=A0 Thus, T-1 is the day before the introduction of the new key,=C2=A0=C2=A0 and T+15 is the 15th day after the key was introduced into t= he
=C2=A0=C2=A0 fictitious zone being discussed.

=C2=A0=C2=A0 =C2=A0=C2=A0 In this dialog, we consider two keys being published:

= =C2=A0=C2=A0 K_old=C2=A0 The older KSK being replaced.

=C2=A0=C2=A0 = K_new=C2=A0 The new KSK being transitioned into active use, using the
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC5011 process.

=C2=A0=C2=A0 In this= dialog, the following actors are playing roles in this
=C2=A0=C2=A0 sit= uation:

=C2=A0=C2=A0 Zone Signer=C2=A0 The owner of a zone intending= to publish a new Key-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Signing-Key (KSK) = that will become a trust anchor by validators
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 following the RFC5011 process.

=C2=A0=C2=A0 RFC5011 Validator= =C2=A0 A DNSSEC validator that is using the RFC5011
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 processes to track and update trust anchors.



Ha= rdaker & Kumari=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires Octob= er 5, 2017=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=C2=A0=C2=A0 [Page 4]
=0C
Internet-Draft=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 RFC5011 Security Considerations=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 April 2017


=C2=A0=C2=A0 Att= acker=C2=A0 An attacker intent on foiling the RFC5011 Validator's
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ability to successfully adopt the Zone Signe= r's K_new key as a new
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 trust anchor.<= br>
5.1.1.=C2=A0 Attack Timing Breakdown

=C2=A0=C2=A0 The followi= ng series of steps depicts the timeline in which an attack
=C2=A0=C2=A0 = occurs that foils the adoption of a new DNSKEY by a Trust Anchor
=C2=A0= =C2=A0 Publisher that revokes the old key too quickly.

=C2=A0MGLT: T= -1, are mostly indexing the zone, maybe that easier to start from this set.=
=C2=A0
=C2=A0
=C2=A0=C2=A0 T-1=C2=A0 The last signatures are pub= lished by the Zone Signer that signs
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 only= K_old using K_old.=C2=A0 The Attacker queries for, retrieves and
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 caches this keyset and corresponding signatures.
MGLT: Maybe we could clarify the state of the cache. This can be done= until (T-0day) - 1 seconde, which means RRSIG will be considered valid unt= il Expiration Date =3D T - 0 days + 10 days while K_old will be considered = valid for TTL, that is until T + TTL - 1.=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0

=C2=A0=C2=A0 T-0=C2=A0 The Zone Signer adds K_new to his zon= e and signs the zone's key
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 set with K= _old.=C2=A0 The RFC5011 Validator retrieves the new key set
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 and corresponding signature set and notices the publicat= ion of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 K_new.=C2=A0 The RFC5011 Validator= starts the (30-day) hold-down timer
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for = K_new.

=C2=A0=C2=A0 T+5=C2=A0 The RFC5011 Validator queries for the = zone's keyset per the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Active Refresh = schedule, discussed in Section 2.3 of RFC5011.
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Instead of receiving the intended published keyset, the Attacker
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 successfully replays the keyset and associat= ed signatures that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 they recorded at T-1.<= br>
MGLT: The keyset at T-1day is also the keyset at T-0 day - 1 sec. I = believe the text should make clear there is an interval. As the expiration = time has been set to T - 1 + 10 days. These data are still considered valid= at T +=C2=A0 5.
=C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0 Because the signat= ure lifetime is 10 days
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (in this example)= , the replayed signature and keyset is accepted
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 as valid (being only 6 days old) and the RFC5011 Validator cancels=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the hold-down timer for K_new.

MGLT= :
=C2=A0=C2=A0 T + 9: Replayed signature at published at T - 1 are not = valid any more and cannot be replayed. I believe T + 9 replaces T + 10.=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0

=C2=A0=C2=A0 T+10=C2=A0 The RFC= 5011 Validator queries for the zone's keyset and
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 discovers K_new again, signed by K_old (the attacker is unable= to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 replay the records cached at T-1, bec= ause they have now expired).
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The RFC5011 = Validator starts (anew) the hold-timer for K_new.

MGLT: I think we s= hould explicitly specify that for 30 days, K_new will not be used to valida= te. I also think it is important to note that the validator can receive any= response with Expiration Time greater then T + 9 and Inception Time lower = than T + 9. This means that when dynamic parameters are applied, we cannot = assume that the response corresponds to the values provided at T + 9.=C2=A0=
=C2=A0=C2=A0=C2=A0 =C2=A0
=C2=A0=C2=A0 T+15,T+20, and T+25=C2=A0 T= he RFC5011 Validator continues checking the
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 zone's key set and lets the hold-down timer keep running without=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 resetting it.

=C2=A0=C2=A0 T+30=C2= =A0 The Zone Signer knows that this is the first time at which some
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 validators might accept K_new as a new trust an= chor, since the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hold-down timer of a RFC5= 011 Validator not under attack that had
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 q= ueried and retrieved K_new at T+0 would now have reached 30 days.
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 However, the hold-down timer of our attacked RFC50= 11 Validator is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 only at 20 days.

= =C2=A0=C2=A0 T+35=C2=A0 The Zone Signer (mistakenly) believes that all vali= dators
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 following the Active Refresh sched= ule (Section 2.3 of RFC5011)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 should have = accepted K_new as a the new trust anchor (since the



Hardaker= & Kumari=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires October 5, = 2017=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=C2=A0=C2=A0 [Page 5]
=0C
Internet-Draft=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 RFC5011 Security Considerations=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 April 2017


=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 hold down time of 30 days + 1/2 the signature validity period
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 would have passed).
MGLT: There is a stro= ng assumption that Expiration time is always set to Zone generation + 10 da= ys.

=C2=A0=C2=A0=C2=A0 =C2=A0 However, the hold-down timer of our a= ttacked
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC5011 Validator is only at 25 d= ays; The replay attack at T+5
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 means its n= ew hold-time timer actually started at T+10, and thus
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 at this time it's real hold-down timer is at T+35 - T+10 = =3D 25
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 days, which is less than the RFC50= 11 required 30 days.

=C2=A0=C2=A0 T+36=C2=A0 The Zone Signer, believ= ing K_new is safe to use, switches their
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = active signing KSK to K_new and publishes a new DNSKEY set
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 signature signed with K_new.=C2=A0 Non-attacked RFC5011 = validators,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with a hold-down timer of at = least 30 days, would have accepted
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 K_new = into their set of trusted keys.=C2=A0 But, because our attacked
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 RFC5011 Validator still has a hold-down timer for = K_new at 26
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 days, it will fail to accept = K_new as a trust anchor and since
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 K_old i= s no longer being used, all the KSK records from the zone
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 signed by K_new will be treated as invalid.=C2=A0 Subseq= uently, all
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 keys in the key set are now u= nusable, invalidating all records in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the = zone of any type and name.

6.=C2=A0 Minimum RFC5011 Timing Requireme= nts

=C2=A0=C2=A0 Given the attack description in Section 5, the corr= ect minimum length
=C2=A0=C2=A0 of time required for the Zone Signer to = wait before using K_new is:

MGLT:




On Thu, Apr 6,= 2017 at 6:34 PM, Wes Hardaker <wjhns1@hardakers.net> wro= te:
Bob Harold <rharolde@umich.edu> writes:
> This one still needs to be fixed:

Thanks Bob.=C2=A0 That was a straight copy; I hope to do a new
version immediately and will certainly make that change.
= --
Wes Hardaker
USC/ISI

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

--001a11402298ba47ae054d10021e-- From nobody Thu Apr 13 11:32: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 62F3A1315A6 for ; Thu, 13 Apr 2017 11:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 zU6xU2b8RT_e for ; Thu, 13 Apr 2017 11:32:31 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 4C47C1315BF for ; Thu, 13 Apr 2017 11:32:29 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id s141so33638501lfe.3 for ; Thu, 13 Apr 2017 11:32:29 -0700 (PDT) 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=FC5wA7Nmv/m6ixbK89whvB4NF0RwSM4KwRHgd/x3IMk=; b=PDKclXmq1ouxuny9oCoiVN42foyOyVh0FbeAkh3OL5S9tqsdDB3z0IkDE+4X/TdcuK +bd3pWH+eeRuf7Y8tg6AfLxAGsBWvPWaalFvMzNy/ZyOxtwucYVg8GmsEPuBmsBR4BBC IVBTtuYG70BO7Co6RemrTnw0nJ8td6rI1sMs4/tv4cHUy0jiUZjmszBnI7p8ODFQB20e MDz1QcqATyoDTNDObYhIzRjMBUUy3Qh45ctvS9+m9s/aiB0UQH1HvuySOYSfoMvhlWEd rP8387y+4Yzg2m89ZcOcDonWZdXrvebbXaLZFT5ABVUVdCK58q/06afl6nwIKI9KvvSd PS5w== 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=FC5wA7Nmv/m6ixbK89whvB4NF0RwSM4KwRHgd/x3IMk=; b=mg5zn9SkD4UhIzpjs1H+3drlJrqWB7uXHeaATFBkNHm6Zv2ergSwU+GHCp/t3uYqm4 /88EhkzvMXuZZrvEK0WCuuJYakqPN5r8JIASQMVvb0NI7+0629ztZ/t4t36ij8oOda4w U0RTTr8eMSvV98tGEzoexpBxx6p1Kt5ehnjf+h80H8pDqj2ObvKAtCQBH1k0v4O0CyfQ ICIqvfgGAG3Emk8j2WtZ9Un9K4Lf8ADVdYqvPRuHktVokqwCFqVQ7QlalQeHkrQgfvm7 7PpVTlIEGx/oPs1zh9WhLtZhpe0l7t/1KDsFFKAzG74qOwJtrf2nVmfY6ZfI8zWCLYKP /QGQ== X-Gm-Message-State: AN3rC/6dbvpVnH2U8+IMOpOiCOoYsyujh3X4CjSbaI5lYCkTs6zLCSIe RWZHLvSmBynj/L1iLb/tL/NAk1izxw== X-Received: by 10.25.23.32 with SMTP id n32mr1463492lfi.142.1492108347519; Thu, 13 Apr 2017 11:32:27 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Thu, 13 Apr 2017 11:32:26 -0700 (PDT) In-Reply-To: References: <149062396899.30595.6360166634187605799.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB74CA@eusaamb107.ericsson.se> From: Daniel Migault Date: Thu, 13 Apr 2017 14:32:26 -0400 X-Google-Sender-Auth: 0A0EzO_6BxS9GoYeXOWCcX1RqwI Message-ID: To: Bob Harold Cc: dnsop Content-Type: multipart/alternative; boundary=001a114058060576e7054d108c8f Archived-At: Subject: Re: [DNSOP] FW: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 18:32:34 -0000 --001a114058060576e7054d108c8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bob, Thanks you for the clarifications, I have updated my local copy with all your comments. Yours, Daniel [1] https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob= /master/draft-mglt-dnsop-dnssec-validator-requirements.xml On Fri, Apr 7, 2017 at 7:35 PM, Daniel Migault wrote: > Thanks for the review, I will update the copy on the git accordingly. > > Yours, > Daniel > > On Fri, Apr 7, 2017 at 9:51 AM, Bob Harold wrote: > >> >> On Mon, Mar 27, 2017 at 10:16 AM, Daniel Migault < >> daniel.migault@ericsson.com> wrote: >> >>> Hi, >>> >>> Please find an update of our draft on requirements for DNSSEC resolver. >>> >>> DNS resolvers hardly enable DNSSEC as 1) resolvers are not robust too >>> DNS authoritative operations =E2=80=93 like KSK roll over, signing erro= rs=E2=80=A6. =E2=80=93 and >>> 2) network administrators have little control on these resolvers to rec= over >>> such situations. >>> >>> The draft describes how invalid DNSSEC related RRsets may be considered >>> by the resolver. The listed requirements aim at designing mechanisms as >>> well as interactions with network managers can easily solve/avoid these >>> situations. Such mechanisms are expected to encourage DNSSEC deployment= on >>> resolvers. >>> >>> Yours, >>> Daniel >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Monday, March 27, 2017 9:13 AM >>> To: Edward Lewis ; Daniel Migault < >>> daniel.migault@ericsson.com>; Dan York ; york@isoc.org < >>> york@isoc.org> >>> Subject: New Version Notification for draft-mglt-dnsop-dnssec-valida >>> tor-requirements-04.txt >>> >>> >>> A new version of I-D, draft-mglt-dnsop-dnssec-valida >>> tor-requirements-04.txt >>> has been successfully submitted by Daniel Migault and posted to the IET= F >>> repository. >>> >>> Name: draft-mglt-dnsop-dnssec-validator-requirements >>> Revision: 04 >>> Title: DNSSEC Validators Requirements >>> Document date: 2017-03-27 >>> Group: Individual Submission >>> Pages: 10 >>> URL: https://www.ietf.org/internet- >>> drafts/draft-mglt-dnsop-dnssec-validator-requirements-04.txt >>> Status: https://datatracker.ietf.org/ >>> doc/draft-mglt-dnsop-dnssec-validator-requirements/ >>> Htmlized: https://tools.ietf.org/html/d >>> raft-mglt-dnsop-dnssec-validator-requirements-04 >>> Htmlized: https://datatracker.ietf.org/ >>> doc/html/draft-mglt-dnsop-dnssec-validator-requirements-04 >>> Diff: https://www.ietf.org/rfcdiff? >>> url2=3Ddraft-mglt-dnsop-dnssec-validator-requirements-04 >>> >>> Abstract: >>> DNSSEC provides data integrity and authentication for DNSSEC >>> validators. However, without valid trust anchor(s) and an acceptabl= e >>> value for the current time, DNSSEC validation cannot be performed. >>> This document lists the requirements to be addressed so resolvers ca= n >>> have DNSSEC validation can be always-on. >>> >> >> A few minor sugguestions: >> >> The last part of the abstract >> "can have DNSSEC validation can be always-on" >> remove the last 'can' to get: >> "can have DNSSEC validation be always-on" >> >> 2. Introduction Second paragraph ends: "and then most of the >> communications relying on the DNS resolution." I would suggest "thus >> disabling the communications relying on the DNS resolution." >> >> Fourth paragraph starts: >> "The lake of management" >> "lake" -> "lack" >> >> Fourth paragraph near end: >> "these steps are way to small" >> "to" -> "too" >> and suggest >> "these steps are much too small" >> >> Fifth paragraph >> "and additiona mechanism" >> try either >> "and an additional mechanism" >> or >> "and additional mechanisms" >> >> 8. Private KSK/ZSK >> "split-zone" -> "split-view" >> >> -- >> Bob Harold >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> > --001a114058060576e7054d108c8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bob,

Thanks you for the clarifications, I have = updated my local copy with all your comments.=C2=A0

Yours,
Dani= el

[1] https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-require= ments/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.xml

On Fri, Ap= r 7, 2017 at 7:35 PM, Daniel Migault <daniel.migault@ericsson.co= m> wrote:
=
Thanks for the review, I will update the copy on the git accordin= gly.

Yours,
Daniel

On Fri, Apr 7, 20= 17 at 9:51 AM, Bob Harold <rharolde@umich.edu> wrote:

On Mon, Mar 27, 2017 at 10:16 AM, Daniel M= igault <daniel.migault@ericsson.com> wrote:
Hi,

Please find an update of our draft on requirements for DNSSEC resolver.

DNS resolvers hardly enable DNSSEC as 1) resolvers are not robust too DNS a= uthoritative operations =E2=80=93 like KSK roll over, signing errors=E2=80= =A6. =E2=80=93 and 2) network administrators have little control on these r= esolvers to recover such situations.

The draft describes how invalid DNSSEC related RRsets may be considered by = the resolver. The listed requirements aim at designing mechanisms as well a= s interactions with network managers can easily solve/avoid these situation= s. Such mechanisms are expected to encourage DNSSEC deployment on resolvers= .

Yours,
Daniel

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, March 27, 2017 9:13 AM
To: Edward Lewis <edward.lewis@icann.org>; Daniel Migault <daniel.migault@ericsson.com<= /a>>; Dan York <yo= rk@isoc.org>; yor= k@isoc.org <york@= isoc.org>
Subject: New Version Notification for draft-mglt-dnsop-dnssec-validato= r-requirements-04.txt


A new version of I-D, draft-mglt-dnsop-dnssec-validator-requirements-0= 4.txt
has been successfully submitted by Daniel Migault and posted to the IETF re= pository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mglt-dnsop-dnssec-valid= ator-requirements
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNSSEC Validators Requirements
Document date:=C2=A0 2017-03-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-mglt-dnsop-dnssec-validator-requirements-04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mglt-dnsop= -dnssec-validator-requirements/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mglt-dnsop-dnssec-valid= ator-requirements-04
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mgl= t-dnsop-dnssec-validator-requirements-04
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-mglt-dnsop-dnssec-validator-requirements-04

Abstract:
=C2=A0 =C2=A0DNSSEC provides data integrity and authentication for DNSSEC =C2=A0 =C2=A0validators.=C2=A0 However, without valid trust anchor(s) and a= n acceptable
=C2=A0 =C2=A0value for the current time, DNSSEC validation cannot be perfor= med.
=C2=A0 =C2=A0This document lists the requirements to be addressed so resolv= ers can
=C2=A0 =C2=A0have DNSSEC validation can be always-on.
=
A few minor sugguestions:

=C2=A0The last part of the abstract=C2=A0
"can have= DNSSEC validation can be always-on"
remove the last 'can' to get:
"can have DNSSEC validation be always-on"

2. Introduction Second paragraph ends: "and then most of the communications relying on the DNS resolution.&qu= ot; I would suggest "thus disabling the communications relying on the DNS resolution."= ;

Fourth paragraph starts:
"The lake of management"
&quo= t;lake" -> "lack"

Fourth paragraph near end:
"these steps are way to=C2=A0small"
"to" -> "too"
and suggest
"these steps ar= e much too small"

Fifth paragraph
"and = additiona mechanism"
try either
<= div class=3D"gmail_quote">"and an additional mechanism"
or
"and additio= nal mechanisms"

8.=C2=A0 Private KSK/ZSK
"split-zone" -> "split-view"

--=C2=A0
Bob Harold

=
_____________________________________= __________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



--001a114058060576e7054d108c8f-- From nobody Thu Apr 13 11:41: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 153DE129B7E for ; Thu, 13 Apr 2017 11:41:25 -0700 (PDT) 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 OT0EMFShZoIh for ; Thu, 13 Apr 2017 11:41:23 -0700 (PDT) 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 9AD9B129A8B for ; Thu, 13 Apr 2017 11:41:23 -0700 (PDT) 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 D09447A32F1 for ; Thu, 13 Apr 2017 18:41:22 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 13 Apr 2017 14:41:20 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: dnsop@ietf.org Message-Id: <510A6A22-BCC3-45AB-909B-50BF6AF2F02D@dukhovni.org> References: To: dnsop@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 125, Issue 31 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 18:41:25 -0000 > On Apr 13, 2017, at 7:30 AM, dnsop-request@ietf.org wrote: >=20 > Well, IIRC they sensibly converged on a case-folded normal form > that ensures that https://=D0=94=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9= .org maps to the same underlying > wire-form domain as https://=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0= =B9.org, i.e. both result in > queries for xn--b1adqpd3ao5c.org. AFAIK, those would generally be > different domains under IDNA2008. What I should have said is that the variant with the upper case first letter is invalid (as opposed to being "different") in IDNA2008. This is IMHO a poor user interface, so running code will generally go with UTS#46 (increasingly non-transitional) mappings. --=20 Viktor. From nobody Thu Apr 13 12:02: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 60224131610 for ; Thu, 13 Apr 2017 12:02:24 -0700 (PDT) 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=Xkdyd3jd; dkim=pass (1024-bit key) header.d=yitter.info header.b=P7H0mXih Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82BSTMhAgnBC for ; Thu, 13 Apr 2017 12:02:23 -0700 (PDT) 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 D5CDA1315DD for ; Thu, 13 Apr 2017 12:01:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 3384EBD996 for ; Thu, 13 Apr 2017 19:01:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492110087; bh=EfqQsbW1PyYalimFC9Zqb3zQcg5vb8OB6qvCVkpFZ7E=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Xkdyd3jdWV7tjkb3/NFB8atftpx5ouHwMCn9xKOGx+xamErGDzKp1CK1r4An/0sE+ 9b5AURqmFYYpvOxehFyct+wFyHK6U3tLxDzNuLKJ4C6/jX4CoD4xbQPqbRq/da7878 hnpLrIx9xUF63FZUdK7nFcZERrVlvUrQWj+Lkz68= 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 3RZjyqOEx4C3 for ; Thu, 13 Apr 2017 19:01:26 +0000 (UTC) Date: Thu, 13 Apr 2017 15:01:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492110086; bh=EfqQsbW1PyYalimFC9Zqb3zQcg5vb8OB6qvCVkpFZ7E=; h=Date:From:To:Subject:References:In-Reply-To:From; b=P7H0mXihjwYjLM0VN1yvKS0PHVjIZR1fareVwOVQ3/1lEzaRdxH+bs3oqVKKCqWgj 8lAoPLcoFqHLaYoMhrsXesP0gaksnXiCUOjre7RdTLpumb7OxX7nj5afUiAI1PC5Mk IUvSNOj4Wb5zPq8s2PngKYSNuZIKHqYWskTcG/xo= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170413190124.GM6422@mx4.yitter.info> References: <510A6A22-BCC3-45AB-909B-50BF6AF2F02D@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <510A6A22-BCC3-45AB-909B-50BF6AF2F02D@dukhovni.org> Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 125, Issue 31 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 19:02:24 -0000 On Thu, Apr 13, 2017 at 02:41:20PM -0400, Viktor Dukhovni wrote: > What I should have said is that the variant with the upper case > first letter is invalid (as opposed to being "different") in > IDNA2008. This is IMHO a poor user interface, so running code > will generally go with UTS#46 (increasingly non-transitional) > mappings. Yes, everyone _knew_ it was troublesome. But you can do that case folding operation without embracing all of UTS#46 and getting some of the problems, too. The basic problem with UTS#46 is that it contains a number of quite good ideas and some things that are harmful. Worse, the embrace of something like it by WHATWG has caused even more trouble, because the answer that one gets from WHATWG any time one raises any of the issues with their stance is that "nobody uses" the problematic cases, and so they don't count. At least UTS#46 doesn't take that stance about (say) ZWJ and ZWNJ, but I'm entirely sympathetic with Florian's original complaint upthread that the whole situation is a mess because of too many options. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Apr 13 12:16: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 E556C12EB42 for ; Thu, 13 Apr 2017 12:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 cneAIZfXKyj3 for ; Thu, 13 Apr 2017 12:16:32 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BC912960D for ; Thu, 13 Apr 2017 12:16:32 -0700 (PDT) Received: from [10.1.0.226] (unknown [151.84.131.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 0DA0461F9E for ; Thu, 13 Apr 2017 19:16:29 +0000 (UTC) Message-ID: <58EFCE8B.3050905@redbarn.org> Date: Thu, 13 Apr 2017 12:16:27 -0700 From: Paul Vixie User-Agent: Postbox 5.0.12 (Windows/20170323) MIME-Version: 1.0 To: dnsop@ietf.org References: <510A6A22-BCC3-45AB-909B-50BF6AF2F02D@dukhovni.org> <20170413190124.GM6422@mx4.yitter.info> In-Reply-To: <20170413190124.GM6422@mx4.yitter.info> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 125, Issue 31 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 19:16:34 -0000 i think we can't use something in a standard that doesn't have a canonical format. if there is a F(name) that produces a minimal I18N result which is the same as any other F(name) that would look the same or mean the same if written, then we should outlaw on-the-wire strings that are not in that canonical format. if there is no such F(name) then we should not use I18N in DNS, punycode or no. masataka ohta pointed this out 15 years ago and he was entirely correct. vixie From nobody Thu Apr 13 12:59: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 9C23013160C for ; Thu, 13 Apr 2017 12:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 97fywE39S4hc for ; Thu, 13 Apr 2017 12:59:03 -0700 (PDT) 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 E5E94129566 for ; Thu, 13 Apr 2017 12:59:02 -0700 (PDT) Received: from [192.165.72.22] (unknown [IPv6:2a02:80:3ffc::22]) by mail.frobbit.se (Postfix) with ESMTPSA id B08C122A40; Thu, 13 Apr 2017 21:59:00 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Paul Vixie" Cc: dnsop@ietf.org Date: Thu, 13 Apr 2017 21:59:00 +0200 Message-ID: In-Reply-To: <58EFCE8B.3050905@redbarn.org> References: <510A6A22-BCC3-45AB-909B-50BF6AF2F02D@dukhovni.org> <20170413190124.GM6422@mx4.yitter.info> <58EFCE8B.3050905@redbarn.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_5A188019-3D7C-4518-981A-EAE053FB2FFF_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6082) Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 125, Issue 31 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 19:59:05 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_5A188019-3D7C-4518-981A-EAE053FB2FFF_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 13 Apr 2017, at 21:16, Paul Vixie wrote: > i think we can't use something in a standard that doesn't have a > canonical format. if there is a F(name) that produces a minimal I18N > result which is the same as any other F(name) that would look the same > or mean the same if written, then we should outlaw on-the-wire strings > that are not in that canonical format. if there is no such F(name) then= > we should not use I18N in DNS, punycode or no. There are several issues here and I am sorry to say that trying to make I= 18N as simple as one f(x) will fool all of us. IETF tried via IDNA2003 to create this f(x) for any unicode string x. This was problematic for various reasons, and I am not going to go throug= h all arguments again. IETF then developed IDNA2008 which is a function that take any unicode st= ring and say whether the string x is valid or not to be used as a domain = name, given it is in its ACE encoded form, as an A-Label, compared to the= U-Label which is the string in a standard Unicode encoding form. We because of this do not have F(x) but instead three functions: 1. Mapping from what the end user types, copy and pastes etc...to a strin= g that is to be used "as a domain name". This mapping is very locale depe= ndent, and include things like case folding and what not. It is recommend= ed that Unicode normalisation and what not is to be included here. 2. The function that says whether a Unicode string is possible to use as = a domain name or not, and this is the core of IDNA2008. This function jus= t must be, as you say, something we all agree on, or predictability on th= e ability to use a string will be uncertain. It is independent of locale,= independent of Unicode Version. And similar things. 3. The function that convert from a U-label (the string in a standard uni= code encoding, normally UTF-8) to an A-label (the ace encoding of the str= ing, starting with 'xn--') and its inverse. It is very important (we saw with IDNA2003) that (2) is global and (3) is= separate, and that there is a 1:1 mapping between A-label and U-label so= that it is possible to convert between the two forms. Regarding (1), yes, it would be good if we could use one function, but gi= ven for example case mapping is locale dependent, it is very very hard to= come up with one mapping function. We have heard many different examples= of why this is a hard problem. So I claim your F(x) exists for [2] and [3], but not [1]. And that is whe= re I18N is hard. Very hard. Patrik --=_MailMate_5A188019-3D7C-4518-981A-EAE053FB2FFF_= 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 iEYEARECAAYFAljv2IQACgkQrMabGguI183G0gCbBAqrQ8XbZ+WX3iEp0gxLR0rE 8gwAnRz1yJXGCDDDn8FubTieawPNBH5t =IMuL -----END PGP SIGNATURE----- --=_MailMate_5A188019-3D7C-4518-981A-EAE053FB2FFF_=-- From nobody Thu Apr 13 13:19: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 2C8D4124B0A for ; Thu, 13 Apr 2017 13:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 PPAJxVe5fQST for ; Thu, 13 Apr 2017 13:19:02 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 A8A9D129A9B for ; Thu, 13 Apr 2017 13:18:54 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id h125so34788220lfe.0 for ; Thu, 13 Apr 2017 13:18:54 -0700 (PDT) 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=bK70zdmv5v8VH5/UySXBltkK33Qrz1yZsMyaWOhsii0=; b=p3LYmbvKQlGxA5/brTiIXAh+MY+ovEeGaPpSqUB3DF+9Nf5xlaScEH/EMaGEDxt0Lg oaXElxQ8F0iUMCDpGfwpfstucm0D7g4rHVeTltNwR1o9vEefNj4wTLmwHn9eKE1FQC1e AkUX7LBNmM4uxc2ZbHGJ87s+6Jw3ckaEkexTNaWsRX+6QXDJuXI9bjfBi4o526NeonSx xK1DEguU1uv2RfXImY3VBSFZyM7A3P32UJH2m9u/2hDJEq+pdzYdjv1LtLLIoFh1Oun2 zdP/fjE+1tiBk0mu6NMelbpVDyts8ansrdlBFGDg9wXQq1YBgy5JhYVwybE5fCNqZD06 /uwA== 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=bK70zdmv5v8VH5/UySXBltkK33Qrz1yZsMyaWOhsii0=; b=CO+WqJGEG3Ks18lfkc6QsMBPdxyTw+x7/mLCs5j2G2rBOKMosuIUE0jlouvaeVwcFM jGtvTCH1jJ+VU23Y57QPB554RrkoZitL7tZ80rvMyQJrvxPL3GbJXRo0Gp5CmAt+ohis ku7RK3jHHMp9WFx89utli+X/AS7kARIn/79744MZ0yx7BM9wH8sjBCL4ZAH3sdThkfXQ pC/nDnX4DXIrSmMDQ/iqs48kBdM7yO/JnItwQPoPKoqt3HKOy6CoWpJO2NmExuCaiqEo Rjga80lEqbnlVCjSyBKQTxi2tU6lF24kZbGkMXoCiBVOM4P5Rligu7k69c+k4qxfu2hR KkmQ== X-Gm-Message-State: AN3rC/7PV9ZvzKwmIPZu8OiGiiguXbh/S6W/nWeTQDVoLQMbKrfX7dzY yTIRCUsRpi2cGJvPC95VST1IWb5P/Q== X-Received: by 10.25.155.145 with SMTP id d139mr1649298lfe.174.1492114732718; Thu, 13 Apr 2017 13:18:52 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Thu, 13 Apr 2017 13:18:51 -0700 (PDT) In-Reply-To: References: <20170331034800.GD99337@isc.org> From: Daniel Migault Date: Thu, 13 Apr 2017 16:18:51 -0400 X-Google-Sender-Auth: 7z0pS9rQJQ083V4obTR1T68NIII Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: dnsop Content-Type: multipart/alternative; boundary=001a114022989ba18d054d12087b Archived-At: Subject: Re: [DNSOP] DNSSEC validator requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 20:19:04 -0000 --001a114022989ba18d054d12087b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you Evan and Petr fro your comments. I thought I would be able to provide you some text this week... but I am running late. I will send you some text next week. I agree with your comments, and will make my best to address them. I also came with other requirements. Yours, Daniel On Fri, Apr 7, 2017 at 7:25 AM, Petr =C5=A0pa=C4=8Dek = wrote: > On 31.3.2017 05:48, Evan Hunt wrote: > > I have reviewed draft-mglt-dnsop-dnssec-validator-requirements-04.txt > and > > some comments on the substance of it are below. (I'll also send some > > grammatical nitpicks via private mail.) > > > >> However, without valid trust anchor(s) and an acceptable value for the > >> current time, DNSSEC validation cannot be performed. This document > lists > >> the requirements to be addressed so resolvers can have DNSSEC validati= on > >> can be always-on. > > > > This abstract, and the introduction below, both seem to suggest that th= e > > intention of this draft is to list requirements for automatic > bootstrapping > > and recovery of DNSSEC without human intervention. However, several of > the > > requirements actually included in the text describe mechanisms of human > > intervention: for example, insertion of negative trust anchors or the > > ability to flush the cache. > > > > To my mind, any need for human intervention contradicts the idea of > DNSSEC > > being "always-on"; humans can't react instantly. So I suggest revising > > the abstract and the problem statement to say that these are requiremen= ts > > for a DNSSEC validator to be recovered when it fails, rather than for > > it always to be on. > > A document listing what can possibly go wrong with DNSSEC deployment in > real world and what "features/tools" software vendors have to provide to > ease recovery is a good idea. > > Having said that, I support Evan's view that here we are not talking > about "always-on" but more about "human intervention"/recovery. I think > that all other Evan's comments are good ideas as well and improve the > document. > > I'm looking forward to reviewing a new version of the document. > > -- > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a114022989ba18d054d12087b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you Evan and Petr fro your comments. I thought I would be a= ble to provide you some text this week... but I am running late. I will sen= d you some text next week.

I agree with your comments, and will make= my best to address them. I also came with other requirements. =C2=A0
<= /span>
Your= s,
Daniel

On Fri, Apr 7, 2017 at 7:25 AM, Petr =C5=A0pa=C4=8Dek <petr.spacek= @nic.cz> wrote:
On 31.3.2017 05:48, Evan Hunt wrote:
> I have reviewed draft-mglt-dnsop-dnssec-validator-requirements-04= .txt and
> some comments on the substance of it are below. (I'll also send so= me
> grammatical nitpicks via private mail.)
>
>> However, without valid trust anchor(s) and an acceptable value for= the
>> current time, DNSSEC validation cannot be performed.=C2=A0 This do= cument lists
>> the requirements to be addressed so resolvers can have DNSSEC vali= dation
>> can be always-on.
>
> This abstract, and the introduction below, both seem to suggest that t= he
> intention of this draft is to list requirements for automatic bootstra= pping
> and recovery of DNSSEC without human intervention.=C2=A0 However, seve= ral of the
> requirements actually included in the text describe mechanisms of huma= n
> intervention: for example, insertion of negative trust anchors or the<= br> > ability to flush the cache.
>
> To my mind, any need for human intervention contradicts the idea of DN= SSEC
> being "always-on"; humans can't react instantly.=C2=A0 S= o I suggest revising
> the abstract and the problem statement to say that these are requireme= nts
> for a DNSSEC validator to be recovered when it fails, rather than for<= br> > it always to be on.

A document listing what can possibly go wrong with DNSSEC deployment= in
real world and what "features/tools" software vendors have to pro= vide to
ease recovery is a good idea.

Having said that, I support Evan's view that here we are not talking about "always-on" but more about "human intervention"/r= ecovery. I think
that all other Evan's comments are good ideas as well and improve the document.

I'm looking forward to reviewing a new version of the document.

--
Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC

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

--001a114022989ba18d054d12087b-- From nobody Thu Apr 13 13:27: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 08E0412956C for ; Thu, 13 Apr 2017 13:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 8kNB84-z3xuF for ; Thu, 13 Apr 2017 13:27:16 -0700 (PDT) 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 8E244127076 for ; Thu, 13 Apr 2017 13:27:15 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id m36so54578255qtb.0 for ; Thu, 13 Apr 2017 13:27:15 -0700 (PDT) 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=lWXnXZ0Wq88D4OBriVLhLQb4m2OCgpE9wjFhk5jzyfM=; b=l5UCYQ0yep8FmNe0QAtm+NmgVSfNUjht2jFYOo6etJ/K3ig7zqvGQuiHe1zB11qmZi HvtY6MJ7JYMpt57FvOE4uy46uHGA9PN5Pf3Baw1BuLZmSVazXtmD+EC7NwwWBoUrWpU4 i20Tnx32cWFbdkoJf44M0WmhL1IAlbP1VBkyIZYXqQYdD78vCIBpWK3EVkSlQrsKGzAA oqUmN8LjwxT4FOby9DucBhvBzArMSTtLrPdIbPfapDZHR6TG3Oc3fdLCKG/XjlL/Iuz+ 94tOMZCCIjsok0a/2aMevb0MvoLxazHRXPN2lwE2nIWPJx2qlXC4hrsTP1x6slrN8t5C IdaA== 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=lWXnXZ0Wq88D4OBriVLhLQb4m2OCgpE9wjFhk5jzyfM=; b=SS5IXqBRbqht6KyRgQ4WdkuRcRJArMbG/f7FdynZtA6PYdJ70mv3zzSPsnRJzm1xED wnD59URElNsp0/hsiSBEXSOCCl4Ke9M4u80cqOsC/yTaw+ypVNM3EtO7XGdGBHA2Nk4u Dsx45GZrxmVzCtwHyjjwUxDn2dONBa5P/ws2C5VohPG7sO+5prbUXsKhJGBzlJ6Sh56l SN+i/+J59Ug1z0sA46OAoaLpDzkMUWlzHEDbW8ungej9Hw4Z+h4WQrmk0jAkU8svTwNC o6a8zYwYRD2G2XTK8VbzSdfDKu3E6bd/cTLYkUaZaGOcZImCBbB1HFHqhL1+1UCQJ1gs j8XQ== X-Gm-Message-State: AN3rC/7Hafj85djk6Y8xlcj1H/HdMAl4okFzx8yC8eS8NrKpqi+tEtLo KgAG0NyZhRcSx5fW9+qyFOKAS6Mxxg== X-Received: by 10.200.42.151 with SMTP id b23mr4142727qta.163.1492115234453; Thu, 13 Apr 2017 13:27:14 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.208 with HTTP; Thu, 13 Apr 2017 13:27:13 -0700 (PDT) In-Reply-To: <20170407181139.GB66383@isc.org> References: <20170407181139.GB66383@isc.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 13 Apr 2017 13:27:13 -0700 X-Google-Sender-Auth: qp5cNVHMPPJX1hyx1w13jgneFzM Message-ID: To: Evan Hunt Cc: dnsop Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 20:27:17 -0000 At Fri, 7 Apr 2017 18:11:39 +0000, Evan Hunt wrote: > Here's the new ANAME draft I mentioned last week. > > This is similar to existing non-standard approaches (ALIAS records, > CNAME-flattening, etc) but also sends the ANAME record to the resolver so > that, if the resolver understands the ANAME type, it can re-query for the > answer just as it would with a CNAME. I've read draft-hunt-dnsop-aname-00 and have some comments on it. I'm aware that similar comments on some points have been made in this thread, but I'm providing my own version at the risk of repeating as I think these are not necessarily a complete duplicate. Overall I agree this is worth trying to achieve. There is a clear need for the ability of defining an alias at a zone apex, and it will be nicer if we provide a standard-compliant and interoperable way for that. I also agree that a long-term goal (hope) should deploy it in the resolver side even if it will take quite long (if not fail), so that authoritative server implementations can be kept lightweight and simple. I have one high-level concern in terms of the merit of providing a standard/interoperable version of 'alias'. As already noted in the draft there are currently several proprietary mechanisms of 'alias', mainly to allow an alias at a zone apex. In order for the standard version to be successful, it will have to be compatible with these existing ones as much as possible and as long as it doesn't break other DNS standards. In that sense I see some disparity with the ALIAS record of Amazon Route53, one of the earliest (and probably largest) players of the idea: - Supporting other types of records than AAAA and A - Allowing different target names for different types I don't know how critical these are for existing R53 ALIAS users, but depending on that ANAME may not be able to be successful in practice. I also wonder whether it's okay to allow 'AAAA or A' and ANAME to coexist for the same owner name. Shouldn't it be prohibited similar to that CNAME and other types can't coexist? Some specific comments on the draft text follow: - Section 3 If the original query is for type A, and an RRset of type A exists at the final ANAME , then that A RRset (with changed to match that of the ANAME RR), MUST be appended to the answer section after the ANAME RRset. What if the target name of ANAME does not exist (NXDOMAIN)? Returning NXDOMAIN is quite likely to be a bad choice, since the owner name of the query actually does exist. It will be certainly problematic if it's a zone apex. So should it be translated into NOERROR+NODATA? Or something else? Also, if the zone is signed, what kind of proof should be returned? - Section 3.1 Address records cached locally MUST have a limited TTL. The initial TTL for locally-cached address records MUST be set to the lesser of the ANAME TTL and the TTL of the address records retrieved from the ANAME . The local TTL MUST count down, just as it would in a conventional resolver cache.[...] Should the local TTL count down, even if the initial value is from the ANAME TTL? I suspect that's not the intent, and if I'm correct I think the current text is confusing and should clarify it. - Section 3.2 If the zone is configured with an A or AAAA RRset at the same DNS node as ANAME, then the ANAME is considered to have been pre-expanded for zone transfer purposes. When a zone is being transferred to a secondary server, if any address record already exists at the same node as an ANAME RR, then the ANAME RR MUST NOT be further expanded by the authoritative server. (I have a more fundamental concern about the coexistence as stated above, but ignoring it in this context) I'm afraid this text talks about something not explained before this point or not even explained clearly anywhere in the draft. I guess the "pre-expand" means the following behavior described in section 3.3, but not necessarily with RRSIGs: Implementers MAY allow address records associated with the ANAME to be populated and signed by the primary server, then sent along with their RRSIGs to secondaries via zone transfer. If my understanding is correct, the concept of population/pre-expand behavior for zone transfer should be explicitly introduced before the discussion in Section 3.2. -- JINMEI, Tatuya From nobody Fri Apr 14 12:07: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 AE28512954B for ; Fri, 14 Apr 2017 12:07:13 -0700 (PDT) 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 VxnPk25fEOVv for ; Fri, 14 Apr 2017 12:07:12 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E049F12946D for ; Fri, 14 Apr 2017 12:07:12 -0700 (PDT) Received: from [192.168.2.98] (unknown [78.180.239.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4CF8561F9E for ; Fri, 14 Apr 2017 19:07:10 +0000 (UTC) Message-ID: <58F11DDA.9040307@redbarn.org> Date: Fri, 14 Apr 2017 12:07:06 -0700 From: Paul Vixie User-Agent: Postbox 5.0.12 (Windows/20170323) MIME-Version: 1.0 To: "dnsop@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] my comments on draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 19:07:14 -0000 in the current dns terminology rfc, it editorializes and is inaccurate by understatement and overstatement concerning the "passive dns" term. i suggest the following edits, should you decide to retain this text rather than copy from the COF i-d or from florian's original work: Passive DNS: A mechanism to collect large amounts of DNS data by storing DNS responses from servers. Some of these systems also collect the DNS queries associated with the responses; this can raise privacy issues. Passive DNS databases can be used to answer historical questions about DNS zones such as which records were available for them at what times in the past. Passive DNS databases allow searching of the stored records on keys other than just the name, such as "find all names which have A records of a particular value". s/large amounts of// s/responses/transactions/ s/servers/name servers/ s/; this can raise privacy issues/; done correctly, this raises no privacy issues/ s/records/answers/ s/available for them/witnessed/ s/the name/the name and type/ -- P Vixie From nobody Fri Apr 14 12:15: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 C1C66129553 for ; Fri, 14 Apr 2017 12:15:28 -0700 (PDT) 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 EuKhbqfjeqWS for ; Fri, 14 Apr 2017 12:15:27 -0700 (PDT) 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 BB63F12954A for ; Fri, 14 Apr 2017 12:15:27 -0700 (PDT) Received: from [10.32.60.144] (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 v3EJFASu069272 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 14 Apr 2017 12:15:11 -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.144] From: "Paul Hoffman" To: "dnsop@ietf.org" Date: Fri, 14 Apr 2017 12:15:25 -0700 Message-ID: In-Reply-To: <58F11DDA.9040307@redbarn.org> References: <58F11DDA.9040307@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] my comments on draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 19:15:29 -0000 Started as a new issue at https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/21 --Paul Hoffman From nobody Fri Apr 14 12:40: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 C4C50128D69 for ; Fri, 14 Apr 2017 12:40:31 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2t1nqgq5NCXt for ; Fri, 14 Apr 2017 12:40:30 -0700 (PDT) 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 E23551242F7 for ; Fri, 14 Apr 2017 12:40:29 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id n46so70481978qta.2 for ; Fri, 14 Apr 2017 12:40:29 -0700 (PDT) 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=BtUgxPkpHAP9ZKmJKg08froF5iYOuYpL7AMmd0yPPGo=; b=VN/oXFMzJTauO6oqgqz+sQ207MUx6N2tzSZuusbfAyH9xEQSjT29gPWOg8veon2COF T1mFpLVBJNn7QiLbfIsuBMnp5IQQ/DS931g0R+xzPHE1FAoZExQLfypR6xxGPfeQ15EP CXIg73BLQFKe7xf02y0MyRy6tTPBx5xu2x4kmCm9nvreu1S52nM3zKX4fobpY3GFuKmB OaGZLiJ63LmCl9tc6H17bdC3ulUyXR01uDNIc9LJhyvvhqt6ICFaR5WQHT8w17c7uxTy 1aCUJGnUPfuiz61MYq5iiKUb1Aj2PB6Dk5f95kGFGJhQoL2R2hicvyL13iAnbWj1z+VM eLJg== 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=BtUgxPkpHAP9ZKmJKg08froF5iYOuYpL7AMmd0yPPGo=; b=OWLV3PD1gZ48OEM68zYD4KuaeBdg1DZsrIve43KBu5JRx84P0gWEPPZyrw4u8qtGxX BD3BCkrfoe316XopBYqnnpuzFJegYP7XLmyimmmrlY5o2OW4qvWaLwe+tGG2J+GjjcTz czLCt58950C/UHoBVy/UAJbcj+VFAWRnxvGYSRmu32JX0KI4ydLeZQdKApNJ5mBZ6RBB gkJFOiDK71mkrmXxq4WxlXsdnDjyZRPWS5f8Tv+g/fBlBgKMgxcq17/wn9pIYTshsUwd +PUIMCvGPXeGgbP1tUJfISZgnXtuAN18kxrxaYDq7VRtwO45Zo5KjMW/TZ0x6OVPdnl6 90CQ== X-Gm-Message-State: AN3rC/4QwM1VhencyOdbxMRq+vjA1y1oOW6YfXvYDFwJ336UzvyMPTLb 9PzC12tPszb42ODI8Hb6CMuZnjrnZMyCP4l0Gw== X-Received: by 10.200.51.70 with SMTP id u6mr2846970qta.122.1492198828843; Fri, 14 Apr 2017 12:40:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.183.136 with HTTP; Fri, 14 Apr 2017 12:39:42 -0700 (PDT) In-Reply-To: References: <58F11DDA.9040307@redbarn.org> From: Warren Kumari Date: Fri, 14 Apr 2017 15:39:42 -0400 Message-ID: To: Paul Hoffman Cc: "dnsop@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] my comments on draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 19:40:32 -0000 On Fri, Apr 14, 2017 at 3:15 PM, Paul Hoffman wrote: > Started as a new issue at > https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/21 I don't think that I agree with "this raises no privacy issues" -- some folk seem to think that they can store "private" information in the DNS, and if queried for, this may / will expose it. Someone (I think it was Facebook or LinkedIn) creates (or used to create) a per-user DNS name for load-balancing purposes -- scraping passive DNS would allow someone to find many profiles, which could be viewed as a privacy issue. I'd much prefer "done correctly, this raises minimal privacy issues" or "done incorrectly this can raise privacy issues" (or just skip everything after the semi-colon and say nothing). I believe that passive DNS is incredibly useful for security stuff, I just think that saying that it raises no privacy issues could get sticky. Oh, I added the above to the issue. W > > --Paul Hoffman > > > _______________________________________________ > 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 Fri Apr 14 12:54: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 F298B12949B for ; Fri, 14 Apr 2017 12:54:54 -0700 (PDT) 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=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 DEkS6Rkl1Nzm for ; Fri, 14 Apr 2017 12:54:54 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B84B128D69 for ; Fri, 14 Apr 2017 12:54:54 -0700 (PDT) Received: from [192.168.1.157] (unknown [85.99.254.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id CE4C261F9E; Fri, 14 Apr 2017 19:54:51 +0000 (UTC) Date: Fri, 14 Apr 2017 19:54:44 +0000 User-Agent: K-9 Mail for Android In-Reply-To: References: <58F11DDA.9040307@redbarn.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----7UNF7RXRHIXHDF7A8KKSN7Z7I8QT0U" Content-Transfer-Encoding: 7bit To: dnsop@ietf.org, Warren Kumari , Paul Hoffman From: P Vix Message-ID: Archived-At: Subject: Re: [DNSOP] my comments on draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 19:54:55 -0000 ------7UNF7RXRHIXHDF7A8KKSN7Z7I8QT0U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I accept Warren's alternative wording=2E Any of them=2E --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------7UNF7RXRHIXHDF7A8KKSN7Z7I8QT0U Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I accept Warren's alternative wording=2E Any of them=2E
--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------7UNF7RXRHIXHDF7A8KKSN7Z7I8QT0U-- From nobody Fri Apr 14 13:03: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 C8C151289B5 for ; Fri, 14 Apr 2017 13:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, 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 kpOwFrr1n5gu for ; Fri, 14 Apr 2017 13:03:39 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE161277BB for ; Fri, 14 Apr 2017 13:03:39 -0700 (PDT) Received: (qmail 52442 invoked from network); 14 Apr 2017 20:03:38 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Apr 2017 20:03:38 -0000 Date: 14 Apr 2017 20:03:16 -0000 Message-ID: <20170414200316.86192.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: peter.van.dijk@powerdns.com In-Reply-To: <05429B5D-904B-4913-9843-654C917DEA27@powerdns.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 20:03:41 -0000 In article <05429B5D-904B-4913-9843-654C917DEA27@powerdns.com> you write: >> Wouldn't it be safer to put the ANAME in the additional section? > >My thinking was that given that DNAME got away with being in ANSWER, so >could we. Seems to me that it belongs in the answer section, since for aname-aware reasolvers the aname is the answer. >> Do we care about SSHFP? > >I understand the question but I’m uncomfortable extending ANAME beyond >address types. I will put it on the list of things that need more thought. Type bitmaps like the ones in NSEC wouldn't be hard to implement. Add some sanity rules saying that type bits for DNSSEC types and the like are ignored, and it's an error to include any types also present at the same name. R's, John From nobody Fri Apr 14 13:34: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 A13B1126B6D for ; Fri, 14 Apr 2017 13:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 BlZP_Qec3k0h for ; Fri, 14 Apr 2017 13:34:50 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7834129649 for ; Fri, 14 Apr 2017 13:34:47 -0700 (PDT) Received: (qmail 57264 invoked from network); 14 Apr 2017 20:34:46 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Apr 2017 20:34:46 -0000 Date: 14 Apr 2017 20:34:24 -0000 Message-ID: <20170414203424.86276.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: abbypan@gmail.com 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] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 20:34:51 -0000 In article you write: >-=-=-=-=-=- > >Hi Peter, > >one question, will authoritative server return multiple ANAME RRs for the >same domain at one dns query ? We can probably assume that multiple ANAMEs are treated the same as multiple CNAMEs or multiple DNAMEs. Don't Do That. R's, John From nobody Mon Apr 17 16:17:01 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 27B981242F7; Mon, 17 Apr 2017 16:16:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: tjw.ietf@gmail.com, warren@kumari.net, dnsop@ietf.org, dnsop-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149247101906.17751.10433707491985742653.idtracker@ietfa.amsl.com> Date: Mon, 17 Apr 2017 16:16:59 -0700 Archived-At: Subject: [DNSOP] dnsop - New Meeting Session Request for IETF 99 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 23:16:59 -0000 A new meeting session request has just been submitted by Tim Wicinski, a Chair of the dnsop working group. --------------------------------------------------------- Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 160 Conflicts to Avoid: First Priority: dbound dhc apparea appsawg homenet dnssd dprive Second Priority: v6ops intarea trans Third Priority: 6man grow opsarea opsawg pcp saag sidr People who must be present: Suzanne Woolf Joel Jaeggli Warren Kumari Tim Wicinski Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Apr 18 05:55: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 66C4212EB9E for ; Tue, 18 Apr 2017 05:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 LpXfwiaP2q3v for ; Tue, 18 Apr 2017 05:55:01 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (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 EA8E01205F0 for ; Tue, 18 Apr 2017 05:55:00 -0700 (PDT) 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]:60206) by ppsw-41.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1d0Sek-00030u-Qb (Exim 4.89) (return-path ); Tue, 18 Apr 2017 13:54:54 +0100 Date: Tue, 18 Apr 2017 13:54:54 +0100 From: Tony Finch To: =?UTF-8?B?56We5piO6YGU5ZOJ?= cc: Evan Hunt , dnsop In-Reply-To: Message-ID: References: <20170407181139.GB66383@isc.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-984481265-1492520094=:4393" Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 12:55:02 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870841-984481265-1492520094=:4393 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > I also wonder whether it's okay to allow 'AAAA or A' and ANAME to > coexist for the same owner name. Shouldn't it be prohibited similar > to that CNAME and other types can't coexist? From=20the point of view of a provisioning-side implementation of ANAME, th= e A and AAAA records are pre-populated answers from the target name. Tony. --=20 f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Sole: East or northeast 4 or 5. Slight or moderate. Fair. Good. --1870870841-984481265-1492520094=:4393-- From nobody Tue Apr 18 06:06:47 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 6248E12EBAB; Tue, 18 Apr 2017 06:06:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149252079732.16150.17346634909097923532@ietfa.amsl.com> Date: Tue, 18 Apr 2017 06:06:37 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:06:37 -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-02.txt Pages : 48 Date : 2017-04-18 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-02 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 Apr 18 06:13: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 00DE912EBC9 for ; Tue, 18 Apr 2017 06:13:09 -0700 (PDT) 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 jo8dGoBE6EF1 for ; Tue, 18 Apr 2017 06:13:08 -0700 (PDT) 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 9356C12EBC2 for ; Tue, 18 Apr 2017 06:13:08 -0700 (PDT) Received: from [2001:b98:204:102:fff1::11] (port=50661 helo=Jims-iMac.local) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1d0SwM-0001Zx-2B for dnsop@ietf.org; Tue, 18 Apr 2017 14:13:07 +0100 To: dnsop@ietf.org References: <149252079732.16150.17346634909097923532@ietfa.amsl.com> From: Jim Hague Organization: Sinodun Internet Technologies Ltd. Message-ID: Date: Tue, 18 Apr 2017 14:13:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149252079732.16150.17346634909097923532@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:13:10 -0000 Hi All, This update to the draft is a minor update, mainly to fix the images as mentioned in the WG: * Update qr_data_format.png to match CDDL * Editorial clarifications and improvements Jim On 18/04/2017 14:06, 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-02.txt > Pages : 48 > Date : 2017-04-18 > > 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 are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-02 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-02 > > > 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 > -- Jim Hague - jim@sinodun.com Never trust a computer you can't lift. From nobody Tue Apr 18 21:23: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 31E0312942F for ; Tue, 18 Apr 2017 21:23:32 -0700 (PDT) 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 yf8Z1XGFmgoL for ; Tue, 18 Apr 2017 21:23:30 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 460F51200DF for ; Tue, 18 Apr 2017 21:23:30 -0700 (PDT) Received: from dash.isi.edu (vir.isi.edu [128.9.160.91]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3J4NBkD019842 for ; Tue, 18 Apr 2017 21:23:11 -0700 (PDT) Received: from dash.isi.edu (localhost6.localdomain6 [IPv6:::1]) by dash.isi.edu (Postfix) with ESMTP id 772E9280E39 for ; Tue, 18 Apr 2017 21:23:10 -0700 (PDT) To: dnsop From: John Heidemann X-url: http://www.isi.edu/~johnh/ MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Apr 2017 21:23:10 -0700 Message-ID: <8718.1492575790@dash.isi.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: johnh@isi.edu Archived-At: Subject: [DNSOP] b-root begins anycast in May X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 04:23:32 -0000 [This topic is not directly relevant to dnsop working group events, but the WG overlaps with the right set of technical folks, so pardon the distraction.] To improve B-Root DNS service, B-Root will be activating anycast on 2017-05-01, providing service from a new site in Miami in addition to our current site in Los Angeles. We thank Florida International University (https://www.fiu.edu) and Ampath.net (https://ampath.net) for hosting our new hardware there, and USC (https://www.usc.edu) for hardware support for this second site. As part of this deployment, we will be renumbering B-Root's IPv6 address to 2001:500:200::b, effective on 2017-06-01 (pending final coordination with IANA). We also plan renumber our IPv4 address later in 2017; we will announce that date here. Renumbering will help support anycast with more resilient routing. (We will provide service on our old IPv6 and IPv4 addresses for at least one year after renumbering.) Please address any questions about B-Root operations to b-poc (at) isi.edu. From nobody Wed Apr 19 11:29: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 A3D18128708 for ; Wed, 19 Apr 2017 11:29:12 -0700 (PDT) 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 NWKkKpjqofEX for ; Wed, 19 Apr 2017 11:29:08 -0700 (PDT) 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 F2A19129BC4 for ; Wed, 19 Apr 2017 11:29:07 -0700 (PDT) Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:a494:7c0f:1b4e:cca9]) (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 525DFC1B96; Wed, 19 Apr 2017 20:29:04 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Wed, 19 Apr 2017 20:29:07 +0200 Message-ID: In-Reply-To: <20170414200316.86192.qmail@ary.lan> References: <20170414200316.86192.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 18:29:13 -0000 On 14 Apr 2017, at 22:03, John Levine wrote: > In article <05429B5D-904B-4913-9843-654C917DEA27@powerdns.com> you > write: >>> Wouldn't it be safer to put the ANAME in the additional section? >> >> My thinking was that given that DNAME got away with being in ANSWER, >> so >> could we. > > Seems to me that it belongs in the answer section, since for > aname-aware > reasolvers the aname is the answer. > >>> Do we care about SSHFP? >> >> I understand the question but I’m uncomfortable extending ANAME >> beyond >> address types. I will put it on the list of things that need more >> thought. > > Type bitmaps like the ones in NSEC wouldn't be hard to implement. Add > some sanity rules saying that type bits for DNSSEC types and the like > are ignored, and it's an error to include any types also present at > the same name. Type bitmaps would preclude simple implementations that use getaddrinfo to do their business. As much as I think the idea may have merit, I feel this draft should stay close to the long list of existing ALIAS/ANAME implementations if it wants any chance to succeed. If after that (perhaps after some operational experience with ANAME!) you want to draft up a more generic forwarding mechanism, I will happily help you write it all down. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Wed Apr 19 19: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 4923812EAEC for ; Wed, 19 Apr 2017 19:47:32 -0700 (PDT) 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 P9ySHO4Djbxc for ; Wed, 19 Apr 2017 19:47:30 -0700 (PDT) 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 6761C1293FF for ; Wed, 19 Apr 2017 19:47:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w7jvg2DZZz37M for ; Thu, 20 Apr 2017 04:47:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1492656447; bh=AqUkzYbkAbhUV8Fi0zpj2ojpGm6IyWKa7kZssLs4HzE=; h=Date:From:To:Subject:In-Reply-To:References; b=efWs7TWtQnS21GaP9IhqgNeaFCMhNDQSgmCGR1PetRxMafsrAOteQ/XxD8MAVENAq vYY58koL0nZnS3MKa+Gu0Bjzsop/cnx1YvnWSp3kX9CVhUcHWGJh6viBKsfks7+JOk iv/sJqt2Ipy3Z3501ToBeF9oikKzyAo85qWetwJ0= 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 wEHKN2jZEC9k for ; Thu, 20 Apr 2017 04:47:26 +0200 (CEST) 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 for ; Thu, 20 Apr 2017 04:47:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1A1F62648B; Wed, 19 Apr 2017 22:47:25 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1A1F62648B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 026AF40D811F for ; Wed, 19 Apr 2017 22:47:24 -0400 (EDT) Date: Wed, 19 Apr 2017 22:47:24 -0400 (EDT) From: Paul Wouters To: dnsop In-Reply-To: Message-ID: References: <20170414200316.86192.qmail@ary.lan> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 02:47:32 -0000 On Wed, 19 Apr 2017, Peter van Dijk wrote: > Type bitmaps would preclude simple implementations that use getaddrinfo > to do their business. As much as I think the idea may have merit, I feel > this draft should stay close to the long list of existing ALIAS/ANAME > implementations if it wants any chance to succeed. But the implementation really seems to do two things. Bundle A/AAAA with other records and providing a level of indirection. By combining these we are really adding a whole new type of behaviour to the DNS that could be avoided. > If after that (perhaps after some operational experience with ANAME!) > you want to draft up a more generic forwarding mechanism, I will happily > help you write it all down. Which is why I don't agree with this. ANAME could just be a regular RRTYPE without any special handling, meaning "go look there for up to date information on A/AAAA". It could come along A/AAAA records using one of the existing bitmaps multi-type query proposals that have been suggested in the last two years. Prepopulating or updating the A/AAAA records on the auth server should also be a separate issue/draft and ideally not need the auth server to require either recursion or validation. A new type of authenticated XFR query seems to make more logical sense to me. It would also allow much stricter firewalling on the auth server. It seems dnsop is more and more getting these arguments of "but we are just documenting existing behaviour", like with client-subnet and RPZ. It's really not the best way to develop new DNS extensions, as I also argued when we talked about RPZ. Paul From nobody Wed Apr 19 23:36: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 8C95A12EB14 for ; Wed, 19 Apr 2017 23:36:52 -0700 (PDT) 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 APs7Qo7HTB0B for ; Wed, 19 Apr 2017 23:36:51 -0700 (PDT) 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 88D6F1200C1 for ; Wed, 19 Apr 2017 23:36:51 -0700 (PDT) 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 71B513493BC; Thu, 20 Apr 2017 06:36:48 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 64D9E216C1E; Thu, 20 Apr 2017 06:36:48 +0000 (UTC) Date: Thu, 20 Apr 2017 06:36:48 +0000 From: Evan Hunt To: Paul Wouters Cc: dnsop Message-ID: <20170420063648.GA73884@isc.org> References: <20170414200316.86192.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 06:36:52 -0000 On Wed, Apr 19, 2017 at 10:47:24PM -0400, Paul Wouters wrote: > ANAME could just be a regular RRTYPE without any special handling, > meaning "go look there for up to date information on A/AAAA". It could > come along A/AAAA records using one of the existing bitmaps multi-type > query proposals that have been suggested in the last two years. But, because there are always going to be legacy servers, the client would then need to send an ANAME query, and when it got no answer, send another query for A and AAAA. If clients were willing to do that, then they'd have been willing to use SRV, and we'd have standardized on that long since. Which would've been fine, but browser vendors have had years to do it, and they never have. Apparently, what they want is to send address queries and get redirected answers. And if we can't make them do the smart thing, at least we can give them an interoperable and standards-compliant way to do the dumb thing. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Thu Apr 20 02:21: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 5300212EBBB for ; Thu, 20 Apr 2017 02:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 u8w-F33BXtAk for ; Thu, 20 Apr 2017 02:21:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC58512EBA4 for ; Thu, 20 Apr 2017 02:21:40 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 772283DBF2; Thu, 20 Apr 2017 09:21:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 772283DBF2 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 772283DBF2 Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B24DC17AD4; Thu, 20 Apr 2017 09:21:39 +0000 (UTC) To: Evan Hunt , Paul Wouters Cc: dnsop References: <20170414200316.86192.qmail@ary.lan> <20170420063648.GA73884@isc.org> From: Florian Weimer Message-ID: <7c91ee54-4e7f-e26e-88dd-d49703bcc1b0@redhat.com> Date: Thu, 20 Apr 2017 11:21:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170420063648.GA73884@isc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 20 Apr 2017 09:21:40 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 09:21:42 -0000 On 04/20/2017 08:36 AM, Evan Hunt wrote: > On Wed, Apr 19, 2017 at 10:47:24PM -0400, Paul Wouters wrote: >> ANAME could just be a regular RRTYPE without any special handling, >> meaning "go look there for up to date information on A/AAAA". It could >> come along A/AAAA records using one of the existing bitmaps multi-type >> query proposals that have been suggested in the last two years. > > But, because there are always going to be legacy servers, the client would > then need to send an ANAME query, and when it got no answer, send another > query for A and AAAA. > > If clients were willing to do that, then they'd have been willing to use > SRV, and we'd have standardized on that long since. This is simply not true. SRV is broken for almost any purpose, which is why it is only used for protocols which have mandated its use. Most name lookup interfaces only take a name and return an address. With these interfaces, it is technically impossible to synthesize a query name for a SRV lookup, and return the port number in the SRV record to the caller. (This even true for the RFC 3493 interface, which is often used without a service name argument, or a numeric service name.) An ANAME query to find a substitution name does not suffer from this problem. It fits well with existing name lookup interfaces. > Which would've been > fine, but browser vendors have had years to do it, and they never have. Why are you focusing on browsers? This is about the system name resolution service, which browsers still use to perform NIS/WINS/LDAP host name lookups, not just DNS. As I tried to explain above, SRV is incompatible with most of the traditional system name resolution interfaces. A name substitution with an ANAME redirection would not have this problem. > Apparently, what they want is to send address queries and get redirected > answers. And if we can't make them do the smart thing, at least we can > give them an interoperable and standards-compliant way to do the dumb > thing. I have no idea how to map most URI schemes to SRV lookups and resolve conflicts between port numbers, transport protocols in use (e.g., if QUIC is active), and service names (should an XMLRPC request get a different name?). Without that mapping, there is nothing that browser vendors could implement. What I'm trying to say: The SRV failure is not sufficient evidence that client-side name substitution would not see significant uptake because SRV works at the wrong layer(s). Thanks, Florian From nobody Thu Apr 20 11:14: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 B8DDC129B53 for ; Thu, 20 Apr 2017 11:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 k70TKyUZJAl8 for ; Thu, 20 Apr 2017 11:13:58 -0700 (PDT) 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 56068129B5E for ; Thu, 20 Apr 2017 11:13:56 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id h67so53796364qke.0 for ; Thu, 20 Apr 2017 11:13:56 -0700 (PDT) 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=m2LL1oIadI387s99OnjgE0KdSGxwZ2CmOEhon5KXcFo=; b=B8TjLqdeJUy+1IqOZUBcqodphLIYnyMJ0YxOz3bS9DVkWRKRmFcSGRntEJir02aUgv 9ouwjOS36lZSKRNb9Yr+T/4slw9P8QamQEMiOn+EIWxYjHA36ITGQ/BNaSHEEQqoU1ft R21aaS2xo6aljVJjQopf2EK1S5wF2iEy20s+Q2FtQXHCIPiS8mxXaGV5A4G2ZZAGFUHv 3AjP5Sz0dB+0geNCQfLCyo58xBZypD5qgLCn7+NQNf1IOyL9sz/xDvs6bH4aIx9M3033 ja5dRTzQwnpii699DWSncSdj5N0lxqsOlb/8mh6O9tqMhrsNE5fPZ8mp7yI2e+PLyO2+ CJSA== 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=m2LL1oIadI387s99OnjgE0KdSGxwZ2CmOEhon5KXcFo=; b=elRDMQxzJLAedQqEOd3fwJk3BioGvFOt7VYFG29RtXQyuWpeMDf+2piK8cGL/LOf6m nb32EUdUnVJUAk2rnNDwqVU7+04a7GRybI1dbdC7V/KBHNW2GMo7Vapi9EUeObigooEO cdYlvLkEa8QhGs1lbnjEk9i5uWKWKUBEScAdGsVouoRYjBjkdGo8nmxxth6MHfUvJOZA hvet+baBoJ7cfSxVoKUgGhpvo1ao0+iOb0dXFLiZWM/60XXygLe9AwQzZgcj4FnI7CD+ kgAQ++P9/bUkh/YRI+HdlHgGUKJ6gGHB6hxERo1DvIy1R5tCtfYYw8/tBCteAp9W9TzL dfGg== X-Gm-Message-State: AN3rC/6Umyaa0pqmcl6YeZoEzqr9BLqEzmXTxr/ZVUXKqoX9uYaGvt2E 2dTsy+iWBtno0TYHQz4RPiRcO0zF7UQ+AO4= X-Received: by 10.55.143.130 with SMTP id r124mr8355990qkd.19.1492712035414; Thu, 20 Apr 2017 11:13:55 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.208 with HTTP; Thu, 20 Apr 2017 11:13:54 -0700 (PDT) In-Reply-To: References: <20170407181139.GB66383@isc.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 20 Apr 2017 11:13:54 -0700 X-Google-Sender-Auth: LXB-dXGrgtsbDNEIIXqC_6KAb3k Message-ID: To: Tony Finch Cc: Evan Hunt , dnsop Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 18:14:00 -0000 At Tue, 18 Apr 2017 13:54:54 +0100, Tony Finch wrote: > > I also wonder whether it's okay to allow 'AAAA or A' and ANAME to > > coexist for the same owner name. Shouldn't it be prohibited similar > > to that CNAME and other types can't coexist? > > From the point of view of a provisioning-side implementation of ANAME, the > A and AAAA records are pre-populated answers from the target name. As long as those records are generated from the target name that would probably be okay. But the current draft doesn't seem to enforce it, and, (probably unintentionally/implicitly) allows the following setup: aaaa.example.com. ANAME aaaa.example.net. aaaa.example.com. AAAA 2001:db8::aaaa ; not populated from ANAME target aaaa.example.net. AAAA 2001:db8::bbbb This looks more like a prohibited "CNAME + other AAAA for the same name" situation to me. -- JINMEI, Tatuya From nobody Thu Apr 20 13:55: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 971241316BA for ; Thu, 20 Apr 2017 13:55:12 -0700 (PDT) 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 NH9XyIVY2f7B for ; Thu, 20 Apr 2017 13:55:06 -0700 (PDT) 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 C694E1316B3 for ; Thu, 20 Apr 2017 13:55:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w8B2Y1QJqz30Z; Thu, 20 Apr 2017 22:55:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1492721701; bh=lpDTeXXXHaCPokREzHWDrMoXk7xipBL6gaJ2mhGaHHQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ZWgNPWv5Zqj8+Lj9FMD6xjwr/KSu5PhswInXUa2bUe4uXh3+VBEX5eYDSSiXCg2U3 tl6MiSSx7NTm0P4bys8MsJyeYhrIeb9yJSlwdIVAJWXSWweQJ68IhJCEZ5J4ikqNDE OeQXiu+N2ZDbmG6G8InVxBuv3WsG7Nba2I4VObes= 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 wy51o3yuPdSo; Thu, 20 Apr 2017 22:54:58 +0200 (CEST) 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; Thu, 20 Apr 2017 22:54:57 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id EFBFC418565; Thu, 20 Apr 2017 16:54:55 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca EFBFC418565 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D81D740BDBCE; Thu, 20 Apr 2017 16:54:55 -0400 (EDT) Date: Thu, 20 Apr 2017 16:54:55 -0400 (EDT) From: Paul Wouters To: Evan Hunt cc: dnsop In-Reply-To: <20170420063648.GA73884@isc.org> Message-ID: References: <20170414200316.86192.qmail@ary.lan> <20170420063648.GA73884@isc.org> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:55:13 -0000 On Thu, 20 Apr 2017, Evan Hunt wrote: > But, because there are always going to be legacy servers, the client would > then need to send an ANAME query, and when it got no answer, send another > query for A and AAAA. > > If clients were willing to do that, then they'd have been willing to use > SRV, and we'd have standardized on that long since. Which would've been > fine, but browser vendors have had years to do it, and they never have. If that is your use case, I also see no point in ANAME being used by resolvers, and you should just create the new XFR type for this, so that AUTH servers can update their A/AAAA records without needing any recursive DNS protocol changes. Because what you seem to want is a method for updating some information between two AUTH servers. > Apparently, what they want is to send address queries and get redirected > answers. And if we can't make them do the smart thing, at least we can > give them an interoperable and standards-compliant way to do the dumb > thing. Maybe if A and SRV could be returned in the same query they would, so that leads back to generic support for multi-type queries (with I guess _location support) being a better generic solution to the problem compared to this ANAME draft that builds a validating recursive resolver into any authoritative server. Paul From nobody Thu Apr 20 14: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 8FAEF1316ED for ; Thu, 20 Apr 2017 14:52:19 -0700 (PDT) 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 S5MBBnAGZ82Z for ; Thu, 20 Apr 2017 14:52:18 -0700 (PDT) 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 869CB1316E2 for ; Thu, 20 Apr 2017 14:51:58 -0700 (PDT) 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 152B83493A5; Thu, 20 Apr 2017 21:51:56 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 03F96216C1E; Thu, 20 Apr 2017 21:51:56 +0000 (UTC) Date: Thu, 20 Apr 2017 21:51:56 +0000 From: Evan Hunt To: Paul Wouters Cc: dnsop Message-ID: <20170420215155.GB96219@isc.org> References: <20170414200316.86192.qmail@ary.lan> <20170420063648.GA73884@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 21:52:20 -0000 On Thu, Apr 20, 2017 at 04:54:55PM -0400, Paul Wouters wrote: > If that is your use case, I also see no point in ANAME being used by > resolvers, and you should just create the new XFR type for this, so that > AUTH servers can update their A/AAAA records without needing any > recursive DNS protocol changes. Because what you seem to want is a > method for updating some information between two AUTH servers. What I want is for queries for addresses at a zone apex to be redirectable, so that (for example) "www.example.com" and "example.com" have the same degree of flexibility. I'd love it if an authoritative server, configured with an ANAME, returned only the ANAME and let the resolver populate it. However, legacy resolvers won't know what to do with an ANAME answer, so the authority will need to provide addresses too. Several vendors are already doing that part of it. > Maybe if A and SRV could be returned in the same query they would, so > that leads back to generic support for multi-type queries (with I guess > _location support) being a better generic solution to the problem > compared to this ANAME draft that builds a validating recursive resolver > into any authoritative server. Once again, the recursive resolver needn't be built in. It only has to be accessible -- via resolv.conf, for example. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Thu Apr 20 16: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 71AF4129BCE for ; Thu, 20 Apr 2017 16:48:44 -0700 (PDT) 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 l2fRGfh7zSml for ; Thu, 20 Apr 2017 16:48:43 -0700 (PDT) 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 40EED129B66 for ; Thu, 20 Apr 2017 16:48:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w8Ftt41VYzCss; Fri, 21 Apr 2017 01:48:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1492732118; bh=ESdMrglvwO5iZHujqCWj/1DQjn+yEWMdQEHsx53aFIg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=W+RajctiheqCNW2T8yggrc5jMUoSJVuZ0Zax1R8wPb/cCqgjCxLI7KfagNxFcrWRV MzD0VHDaFfTXstARBI+u4wJno1OWT3O2yDJUL0McwTFlZuLOyHpc20RWBAC8FpdHsW dSiNTR+e1TLjlQtM94l+WmbC7Ns3mcOkgZmHBKSY= 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 l-smJBe4D32Z; Fri, 21 Apr 2017 01:48:36 +0200 (CEST) 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; Fri, 21 Apr 2017 01:48:35 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 88FF1418565; Thu, 20 Apr 2017 19:48:34 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 88FF1418565 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 687E140D811F; Thu, 20 Apr 2017 19:48:34 -0400 (EDT) Date: Thu, 20 Apr 2017 19:48:34 -0400 (EDT) From: Paul Wouters To: Evan Hunt cc: dnsop In-Reply-To: <20170420215155.GB96219@isc.org> Message-ID: References: <20170414200316.86192.qmail@ary.lan> <20170420063648.GA73884@isc.org> <20170420215155.GB96219@isc.org> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 23:48:44 -0000 On Thu, 20 Apr 2017, Evan Hunt wrote: > Once again, the recursive resolver needn't be built in. It only has to be > accessible -- via resolv.conf, for example. Mmmm, populating auth servers based on at most an AD bit of something from resolv.conf. Which more and more people are just pointing to 8.8.8.8. I don't think that's a good idea. Maybe some good software and an internal-only ANAME special record with a secure DNS helper app isn't too bad after all. But again, if done well, would not require ANAME to ever go over the wire. I think we've circled sufficiently around now that I'll step back and let others chime in. Paul From nobody Fri Apr 21 02:57: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 8FD11129480 for ; Fri, 21 Apr 2017 02:57:45 -0700 (PDT) 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, 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 V4-Llw8uYsIX for ; Fri, 21 Apr 2017 02:57:43 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (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 C76EB1287A5 for ; Fri, 21 Apr 2017 02:57:43 -0700 (PDT) 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]:36124) by ppsw-41.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1d1VJo-00049N-RJ (Exim 4.89) (return-path ); Fri, 21 Apr 2017 10:57:36 +0100 Date: Fri, 21 Apr 2017 10:57:36 +0100 From: Tony Finch To: =?UTF-8?B?56We5piO6YGU5ZOJ?= cc: Evan Hunt , dnsop In-Reply-To: Message-ID: References: <20170407181139.GB66383@isc.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-1006425529-1492768656=:4393" Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 09:57:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870841-1006425529-1492768656=:4393 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > As long as those records are generated from the target name that would > probably be okay. But the current draft doesn't seem to enforce it, > and, (probably unintentionally/implicitly) allows the following setup: > > aaaa.example.com. ANAME aaaa.example.net. > aaaa.example.com. AAAA 2001:db8::aaaa ; not populated from ANAME target > aaaa.example.net. AAAA 2001:db8::bbbb > > This looks more like a prohibited "CNAME + other AAAA for the same > name" situation to me. From=20an implementation's point of view, it can't tell the difference between this kind of misconfiguration, and legitimate mismatches due to things like stale address records or addresses obtained from different views, etc. In all these cases it can either use the addresses it has been given or replace them with the addresses from the ANAME target. Hostmasters who set up inconsistent ANAME and addresses will suffer the consequences :-) Maybe their suffering could be avoided by a suitably intelligent master file loader or other provisioning thing. Tony. --=20 f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet: Variable 3 or 4. Smooth or slight, occasionally moderate in southwest Fastnet. Fair. Good. --1870870841-1006425529-1492768656=:4393-- From nobody Fri Apr 21 08:08: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 D65C71294CF for ; Fri, 21 Apr 2017 08:08:42 -0700 (PDT) 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 RqPrFj_TW_rR for ; Fri, 21 Apr 2017 08:08:39 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 018CD1294DF for ; Fri, 21 Apr 2017 08:08:38 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id u70so54208899ywe.2 for ; Fri, 21 Apr 2017 08:08:38 -0700 (PDT) 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=K+ggW8q5ctc2kcImLfZEf8OGqlx+ZjGXG/85soBjlLQ=; b=nUM+ZVBsNrE4FVy/6kOSlafLKD/dM9///0iXAGTn2kf6mOHmyPqSeijxcBfiCIoZ69 doSjSY4sZgp91AZdamSA6L+OfUsMIJAYEkABjSA29gCTUyeey1AhASHPCN0kUIMPFGjL SEM7MTLm1SGvg0K9IxiGXTIh60JYQmWGZU6fsGPpbh6l+RaJqBd+RLaVhaakcL0ahpFV IYHn7SwglIcUyqwti+X8Ud9GSbEuvWFxpSejim0YKp/twUnA7ZkttGwnb5UixmaB3ERn cLTzA5liSllzBJopUMbqDvkTjn8TMGBw0qNQ9BGfajdjkS4Jo1WV/h7HWZa850mH8ZPC Ldqg== 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=K+ggW8q5ctc2kcImLfZEf8OGqlx+ZjGXG/85soBjlLQ=; b=LNiJFPFJ/nRQ1cuAoNyUK1JlGwHHbXfGW192KRryrAV0KS5hqiUs3VOjalbAY5jPk8 dlxeCUbJ+vX/1rdWxTiNJEtvcUbL/EWRZkQvHRjVYHxPhuDvfj68u96S0zP5lIQc5Kti TK7zPSpDL4o20crjZnw8MMisv4S/0KgFDFnBPHSe0xF38Asd53wBPxds6weyeJpZVR1d ZiLWbeCLCeDckj3Gh5UKEMWux9YHseifTwxtG1ya+w7MFQ2d+kc0sHt1uDTbn1KE3NPX pk4ehqsKqEluz7i4mlMNEo25HTFr7J8eI7xuUKpnT7P10YYIm9un+DudPGgtDBDSEy+E RVmg== X-Gm-Message-State: AN3rC/4Gy6aWiI3z9D+rycaLdjvEWq6SwWPLBRBiL1MZ/mR4s1NDXbJd 8A0cqVo3/SpceFFvq1sDnMN3NIOU1281S4JZZA== X-Received: by 10.129.75.9 with SMTP id y9mr13296017ywa.102.1492787317672; Fri, 21 Apr 2017 08:08:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.228.135 with HTTP; Fri, 21 Apr 2017 08:08:34 -0700 (PDT) In-Reply-To: <24869f89-8335-6ad8-667d-300b852957a1@redhat.com> References: <24869f89-8335-6ad8-667d-300b852957a1@redhat.com> From: Bob Harold Date: Fri, 21 Apr 2017 11:08:34 -0400 Message-ID: To: Florian Weimer Cc: dnsop Content-Type: multipart/alternative; boundary=001a113f1b0acba80d054daea164 Archived-At: Subject: Re: [DNSOP] Redefining name canonicalization X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:08:43 -0000 --001a113f1b0acba80d054daea164 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 13, 2017 at 5:29 AM, Florian Weimer wrote: > I would like to propose the restrict name canonicalization (as performed > by stub resolvers) to forming a fully-qualified domain name with the help > of the search list. > > With the current rules based on resolving CNAME chains, we end up with the > following results: > > >>> socket.getfqdn('access.redhat.com') > 'a23-214-169-56.deploy.static.akamaitechnologies.com' > >>> socket.getfqdn('access') > 'a23-214-169-56.deploy.static.akamaitechnologies.com' > > This is pretty much useless. In fact, what is advertised here as the > canonical name is just a temporary, location-dependent name which bears no > direct relationship to the service being provided. There isn't anything > canonical about it. > > I think both calls should return 'access.redhat.com' (assuming that ' > redhat.com' is the search list entry which is used to form the FQDN). > > This also avoids issues related to insecure name canonicalization (based > on spoofable DNS data) which affects the use of some cryptographic > libraries, notably Kerberos. > > Comments? > > Thanks, > Florian > > I can understand you wanting a "getfqdn" function to return the FQDN (fully qualified domain name) without doing canonicalization. But just so we are clear on the DNS terms, "access.redhat.com" and "access.redhat.com.edgekey.net" are "aliases" "e133.b.akamaiedge.net" is the canonical name. access.redhat.com is an alias for access.redhat.com.edgekey.net. access.redhat.com.edgekey.net is an alias for e133.b.akamaiedge.net. e133.b.akamaiedge.net has address 104.67.69.246 -- Bob Harold --001a113f1b0acba80d054daea164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Apr 13, 2017 at 5:29 AM, Florian Weimer <fweimer@redhat.com&g= t; wrote:
I wou= ld like to propose the restrict name canonicalization (as performed by stub= resolvers) to forming a fully-qualified domain name with the help of the s= earch list.

With the current rules based on resolving CNAME chains, we end up with the = following results:

>>> socket.getfqdn('access.redhat.com')
'a23-214-169-56.deploy.static.aka= maitechnologies.com'
>>> socket.getfqdn('access')
'a23-214-169-56.deploy.static.aka= maitechnologies.com'

This is pretty much useless.=C2=A0 In fact, what is advertised here as the = canonical name is just a temporary, location-dependent name which bears no = direct relationship to the service being provided.=C2=A0 There isn't an= ything canonical about it.

I think both calls should return 'access.redhat.com' (assuming t= hat 'redhat.com' is the search list entry which is used to form the FQD= N).

This also avoids issues related to insecure name canonicalization (based on= spoofable DNS data) which affects the use of some cryptographic libraries,= notably Kerberos.

Comments?

Thanks,
Florian


I can understand you wantin= g a "getfqdn" function to return the FQDN (fully qualified domain= name) without doing canonicalization.

But just so= we are clear on the DNS terms,=C2=A0
"e= 133.b.akamaiedge.net" is the canonical name.

<= div>
e133.b.akamaiedge.net has address 104.67.69.246

--=C2=A0
Bob Harold


--001a113f1b0acba80d054daea164-- From nobody Mon Apr 24 10:19: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 76AD81318B4 for ; Mon, 24 Apr 2017 10:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, 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 O37wzzZonLY5 for ; Mon, 24 Apr 2017 10:19:17 -0700 (PDT) Received: from atl4mhob22.registeredsite.com (atl4mhob22.registeredsite.com [209.17.115.116]) (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 BEF921318BE for ; Mon, 24 Apr 2017 10:19:17 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob22.registeredsite.com (8.14.4/8.14.4) with ESMTP id v3OHJGHd022166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Apr 2017 13:19:16 -0400 Received: (qmail 2683 invoked by uid 0); 24 Apr 2017 17:19:16 -0000 X-TCPREMOTEIP: 73.251.233.169 X-Authenticated-UID: jw@pcthink.com Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 24 Apr 2017 17:19:16 -0000 Date: Mon, 24 Apr 2017 13:19:13 -0400 Message-ID: Importance: normal From: JW To: dnsop@ietf.org Cc: jw@pcthink.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_268754493290160" Archived-At: Subject: [DNSOP] BULK RR Myth[2] - BULK RRs are only for reverse IPv6 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 17:19:19 -0000 ----_com.samsung.android.email_268754493290160 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QlVMSyBoYXMgbWFueSB1c2VzIGFuZCBpcyBub3QgbGltaXRlZCB0byBJUHY2IG5hbWVzcGFjZS4K QlVMSyBSUnMgYXJlIGludGVuZGVkIHRvIGJvdGg6CgrCoMKgIC0gU2ltcGxpZnkgbWFuYWdlbWVu dCBvZiBwYXR0ZXJuLWJhc2VkIFJScyAoZS5nLiAkR0VORVJBVEUpCsKgwqAgLSBBbGxvdyB0cmFu c2ZlciBvZiBSUiAiaW50ZW50aW9uIiByYXRoZXIgdGhhbiB2ZXJiYXRpbSBSUnMKCldoaWxlIEJV TEsgUlJzIG9mZmVyIGEgbXVjaCBncmVhdGVyIHJhbmdlIG9mIHBhdHRlcm4tYmFzZWQgUlJzCmFs bG93aW5nIHVzZSB0byBtdWx0aXBsZSBxdWludGlsbGlvbnMgKGV2ZW4gYSBmZXcgdW5kZWNpbGxp b25zKQpvZiBJUHY2IHJldmVyc2UsIHRoZWlyIHVzZWZ1bG5lc3MgZG9lc24ndCBzdG9wIHRoZXJl LgoKT25lIGV4YW1wbGUgb2YgdGhpcyBtaWdodCBiZSBjbG91ZCBiYXNlZCBlbnZpcm9ubWVudHMg d2hlcmUKbGl0ZXJhbGx5IGh1bmRyZWRzIG9mIHJlc291cmNlcyAoaVNDU0ksIGNvbXB1dGUgbm9k ZXMsIGV0Yy4pCm1heSBuZWVkIGhvc3RuYW1lcyBhc3NpZ25lZCBmb3IgZWFzeSBtYW5hZ2VtZW50 IGFuZCBmdW5jdGlvbmFsCnN0cnVjdHVyaW5nLgoKQWRkaXRpb25hbGx5LCBzaW5jZSBCVUxLIFJS cyBjYW4gYmUgZWFzaWx5IHRyYW5zZmVycmVkIGJldHdlZW4KbmFtZXNlcnZlcnMgd2l0aG91dCBl eHBhbnNpb24gbXVjaCBzbWFsbGVyIHpvbmUgdHJhbnNmZXJzIGFyZQpwb3NzaWJsZS4KClRoZSBk cmFmdCdzIGF1dGhvcnMgaGF2ZSBzZWVuIHpvbmVzIHdpdGggbW9yZSB0aGFuIDUwTUIgd29ydGgK b2YgZGF0YSAoYmFzZWQgb24gJEdFTkVSQVRFcykgZmFpbCB0byByZWxpYWJseSB0cmFuc2ZlciBi ZXR3ZWVuCm5hbWVzZXJ2ZXJzLsKgIEJVTEsgUlJzIGNvdWxkIG1ha2UgYSB6b25lIGxpa2UgdGhp cyBtdWNoIG1vcmUKbWFuYWdlYWJsZSBhbmQgcmVsaWFibGUgYWNyb3NzIHRoZSBuZXR3b3JrIGFu ZCBlbnN1cmUgYWxsCmNvcGllcyBvZiB0aGUgem9uZSByZW1haW4gaW50YWN0LgoKVGhhbmtzLEpv aG4KCgoKCg== ----_com.samsung.android.email_268754493290160 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2IHN0eWxlPSJmb250LXNpemU6 IDEwMCU7Ij48ZGl2PkJVTEsgaGFzIG1hbnkgdXNlcyBhbmQgaXMgbm90IGxpbWl0ZWQgdG8gSVB2 NiBuYW1lc3BhY2UuPC9kaXY+PC9kaXY+PGJyPkJVTEsgUlJzIGFyZSBpbnRlbmRlZCB0byBib3Ro Ojxicj48YnI+Jm5ic3A7Jm5ic3A7IC0gU2ltcGxpZnkgbWFuYWdlbWVudCBvZiBwYXR0ZXJuLWJh c2VkIFJScyAoZS5nLiAkR0VORVJBVEUpPGJyPiZuYnNwOyZuYnNwOyAtIEFsbG93IHRyYW5zZmVy IG9mIFJSICJpbnRlbnRpb24iIHJhdGhlciB0aGFuIHZlcmJhdGltIFJSczxicj48YnI+V2hpbGUg QlVMSyBSUnMgb2ZmZXIgYSBtdWNoIGdyZWF0ZXIgcmFuZ2Ugb2YgcGF0dGVybi1iYXNlZCBSUnM8 YnI+YWxsb3dpbmcgdXNlIHRvIG11bHRpcGxlIHF1aW50aWxsaW9ucyAoZXZlbiBhIGZldyB1bmRl Y2lsbGlvbnMpPGJyPm9mIElQdjYgcmV2ZXJzZSwgdGhlaXIgdXNlZnVsbmVzcyBkb2Vzbid0IHN0 b3AgdGhlcmUuPGJyPjxicj5PbmUgZXhhbXBsZSBvZiB0aGlzIG1pZ2h0IGJlIGNsb3VkIGJhc2Vk IGVudmlyb25tZW50cyB3aGVyZTxicj5saXRlcmFsbHkgaHVuZHJlZHMgb2YgcmVzb3VyY2VzIChp U0NTSSwgY29tcHV0ZSBub2RlcywgZXRjLik8YnI+bWF5IG5lZWQgaG9zdG5hbWVzIGFzc2lnbmVk IGZvciBlYXN5IG1hbmFnZW1lbnQgYW5kIGZ1bmN0aW9uYWw8YnI+c3RydWN0dXJpbmcuPGJyPjxi cj5BZGRpdGlvbmFsbHksIHNpbmNlIEJVTEsgUlJzIGNhbiBiZSBlYXNpbHkgdHJhbnNmZXJyZWQg YmV0d2Vlbjxicj5uYW1lc2VydmVycyB3aXRob3V0IGV4cGFuc2lvbiBtdWNoIHNtYWxsZXIgem9u ZSB0cmFuc2ZlcnMgYXJlPGJyPnBvc3NpYmxlLjxicj48YnI+VGhlIGRyYWZ0J3MgYXV0aG9ycyBo YXZlIHNlZW4gem9uZXMgd2l0aCBtb3JlIHRoYW4gNTBNQiB3b3J0aDxicj5vZiBkYXRhIChiYXNl ZCBvbiAkR0VORVJBVEVzKSBmYWlsIHRvIHJlbGlhYmx5IHRyYW5zZmVyIGJldHdlZW48YnI+bmFt ZXNlcnZlcnMuJm5ic3A7IEJVTEsgUlJzIGNvdWxkIG1ha2UgYSB6b25lIGxpa2UgdGhpcyBtdWNo IG1vcmU8YnI+bWFuYWdlYWJsZSBhbmQgcmVsaWFibGUgYWNyb3NzIHRoZSBuZXR3b3JrIGFuZCBl bnN1cmUgYWxsPGJyPmNvcGllcyBvZiB0aGUgem9uZSByZW1haW4gaW50YWN0LjxkaXY+PGJyPjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtzLDwvZGl2PjxkaXY+Sm9objxiciBkaXI9ImF1 dG8iPjxiciBkaXI9ImF1dG8iPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQt c2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxkaXY+PGJy PjwvZGl2PjwvZGl2PjxkaXY+PGJyIGRpcj0iYXV0byI+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_268754493290160-- From nobody Mon Apr 24 23:08: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 E2EFC1319CD for ; Mon, 24 Apr 2017 23:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-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 W7mEJbLLZIi5 for ; Mon, 24 Apr 2017 23:08:27 -0700 (PDT) Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (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 118C11319BF for ; Mon, 24 Apr 2017 23:08:26 -0700 (PDT) Received: from off-sendsmg01.osa.jprs.co.jp (off-sendsmg01.osa.jprs.co.jp [172.23.8.61]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id v3P68Pm7002038 for ; Tue, 25 Apr 2017 15:08:25 +0900 Received: from off-sendsmg01.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id C5232180064 for ; Tue, 25 Apr 2017 15:08:24 +0900 (JST) Received: from localhost (off-cpu05.osa.jprs.co.jp [172.23.4.15]) by off-sendsmg01.osa.jprs.co.jp (Postfix) with ESMTP id B08AC180062 for ; Tue, 25 Apr 2017 15:08:24 +0900 (JST) Date: Tue, 25 Apr 2017 15:08:24 +0900 (JST) Message-Id: <20170425.150824.1720421229300692313.fujiwara@jprs.co.jp> To: dnsop@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 6.5 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1690-8.1.0.1062-23028.005 X-TM-AS-Result: No--4.103-5.0-31-10 X-imss-scan-details: No--4.103-5.0-31-10 X-TMASE-MatchedRID: 0LX8gN8YsWdCXIGdsOwlUh5+URxv1WlBNRv92EahEcHSYAzZ6KmqWl/L LazGjsn4SzvKddnUr7Lje4wJCyzaHQ8LKInWUps88pRHzcG+oi1RCMvhjU46LCIorpIqHwlbEWX AmFVxJU4U6jD4KEdMs5GTpe1iiCJqtD9qpBlNF8rP/MyuVlT/C0tIkhusciGXPllU9ZtDDM9YF3 qW3Je6+8eITpvj8egCRVpjurrHzsxD7+U12pi12BlhUZzuC2cIhPsgcfX18ociv0xnuXXyzp1OH y9sBzXAIBbu0q05qPc5zMPflXc7EPZH0AzlcNxIN9NQ8U5Pf2kKuN/9G/KEpjCha/OwPHRBP1tH PdNfDvt+3BndfXUhXQ== Archived-At: Subject: [DNSOP] Term: In-bailiwick and Out-of-bailiwick X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 06:08:29 -0000 There are some types of bailiwicks at delegation. I need separate definitions of each name server name type. (1) [ narrow In-bailiwick ? ] A name server name that require glue records. The name server name is subordinate to or (rarely) the same as the owner name of the NS resource record (at delegation). TLD Registries allow this types of glue records. (2) [ broad In-bailiwick ? ] / In-bailiwick in RFC 7719 A name server name that may have glue records. The name server name is subordinate to or (rarely) the same as the zone origin (RFC 7719 In-Bailiwick (a)). (2) contain (1). (2') [ ????? In-bailiwick ] (2) exclude (1). Recently, TLD Registries do not allow this types of glue record registration. (3) [ Out-of-bailiwick ] # A name server name that must not have glue records. The name server name is not subordinate to or the same as the zone origin. Please show good terms to write papers. Regards, -- Kazunori Fujiwara, JPRS From nobody Wed Apr 26 15: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 9E5B3128DE7 for ; Wed, 26 Apr 2017 15:33:08 -0700 (PDT) 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, 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=fcelda.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 XryQffaT2JMM for ; Wed, 26 Apr 2017 15:33:06 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 B320F128B8D for ; Wed, 26 Apr 2017 15:33:06 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id j59so9612207uad.0 for ; Wed, 26 Apr 2017 15:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/ASZ9DU3EUcI1GgFxtTWxKxqNK256M4rBV7DX2WUau4=; b=LTc0GX1XfzZQjNRSzXSMb9zHRDdXm8H2lslp5XoVTUv/DfMMkowixKIcg/W7/x4wMy 4wcjP1VTto1Li7G6+knI4TbSyGl4YOKFgEs3okqYETNh4RMeiiMxF3k4cMS1lsODyD/c 54OCVEsxz3cYHfpBXecG+yzi8VRpfvjc/I8hM= 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=/ASZ9DU3EUcI1GgFxtTWxKxqNK256M4rBV7DX2WUau4=; b=seEUfYzhgmebO2NvO+bNaNOLwjHlwEqvFXdFADO0Am3KWxsKkge368f+kyOv8h/pJb n5yiT94TOFZDo92jjpef0r6YxvdVSY7+0hSkUuVLU5DpwvCfpSTCxIQjEHHZ8Rwr5WRP 6pdVdWsQUNaFcv0WnrYl0TDmb/IorsrqkHWbBFVv6QGC6Tur/DZEqgoviE81VKRkon3z z3CZ3ZBU2szpZLdFxU1KRT+k6RFcS/Ym1dTL5bKTkIU5PAvf93ItGPILJRBuReiodjc3 i3Xk/yb8QEo4djw6SNK5qxM3dZdOWl+MQKHBXsF+sgXtOqHQwzsnWvamWKM0tFCHYyo8 xqdw== X-Gm-Message-State: AN3rC/5PSEerdUFaMUGG8Yuc3+yH5qIAKU5fuDd1eX/AHvPslqb5SLWU CJPpGJdC5klN2qxXmTrxEjkpC/r1Tz8n X-Received: by 10.176.24.223 with SMTP id d31mr1261073uah.140.1493245985448; Wed, 26 Apr 2017 15:33:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.69 with HTTP; Wed, 26 Apr 2017 15:32:44 -0700 (PDT) X-Originating-IP: [89.103.145.110] In-Reply-To: <73DD364E-12F0-4367-964D-6C18E37BC12B@powerdns.com> References: <20170405054338.GA15831@jurassic> <73DD364E-12F0-4367-964D-6C18E37BC12B@powerdns.com> From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Date: Thu, 27 Apr 2017 00:32:44 +0200 Message-ID: To: Peter van Dijk , muks@isc.org Cc: dnsop@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 22:33:09 -0000 Hello, sorry for resurrecting this thread, but this really caught my attention. On Wed, Apr 5, 2017 at 9:03 AM, Peter van Dijk wrote: > On 5 Apr 2017, at 7:43, Mukund Sivaraman wrote: >> Evan just pointed out a case due to a system test failure that is >> interesting.. it's not clear what the behavior should be in this case, >> so please discuss: >> >> There's a nameserver that's authoritative for 2 zones example.org. and >> example.com. >> >> In the example.org. zone, foo.example.org. is CNAME to bar.example.com. >> >> In the example.com. zone, the name bar.example.com. doesn't exist (NXDOMAIN). >> >> A query for "foo.example.org./A" is answered by the nameserver. It adds >> the foo.example.org. CNAME bar.example.com. in the answer section, and >> then, following RFC 1034 4.3.2. 3.(a.), sets the QNAME to >> "bar.example.com" and looks into the "example.com" zone for >> "bar.example.com.". It is not found. >> >> The question is: what is the expected reply RCODE for this? >> >> 1. Is it NOERROR (0) because there is an answer section with the CNAME? >> >> 2. Is it NXDOMAIN (3) because the CNAME target was not found? > > NXDOMAIN is correct. The text on this on 103x is a bit weak but 2308 2.1 clarifies this. > I actually think NOERROR is correct. The target of the CNAME (bar.example.com) is not in the bailiwick of the zone (example.org). So the authoritative server should stop processing the CNAME chain at this point and send the response with RCODE=NOERROR. Or can we at least agree that both RCODEs are correct? :-) Jan From nobody Wed Apr 26 16:04: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 59BBC128B8F for ; Wed, 26 Apr 2017 16:04:28 -0700 (PDT) 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 NXDNX9G2UWKd for ; Wed, 26 Apr 2017 16:04:26 -0700 (PDT) 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 0C8C71279E5 for ; Wed, 26 Apr 2017 16:04:26 -0700 (PDT) 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 ACC2424AE0D; Wed, 26 Apr 2017 23:04:19 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8D3D216009A; Wed, 26 Apr 2017 23:04:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6BECF16009B; Wed, 26 Apr 2017 23:04:20 +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 cfqG5U05nmW5; Wed, 26 Apr 2017 23:04:20 +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 1C5DE16009A; Wed, 26 Apr 2017 23:04:20 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 096AF6D06C7D; Thu, 27 Apr 2017 09:04:18 +1000 (AEST) To: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Cc: Peter van Dijk , muks@isc.org, dnsop@ietf.org From: Mark Andrews References: <20170405054338.GA15831@jurassic> <73DD364E-12F0-4367-964D-6C18E37BC12B@powerdns.com> In-reply-to: Your message of "Thu, 27 Apr 2017 00:32:44 +0200." Date: Thu, 27 Apr 2017 09:04:17 +1000 Message-Id: <20170426230418.096AF6D06C7D@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 23:04:28 -0000 In message , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= writes: > Hello, > > sorry for resurrecting this thread, but this really caught my attention. > > On Wed, Apr 5, 2017 at 9:03 AM, Peter van Dijk wrote: > > On 5 Apr 2017, at 7:43, Mukund Sivaraman wrote: > >> Evan just pointed out a case due to a system test failure that is > >> interesting.. it's not clear what the behavior should be in this case, > >> so please discuss: > >> > >> There's a nameserver that's authoritative for 2 zones example.org. and > >> example.com. > >> > >> In the example.org. zone, foo.example.org. is CNAME to bar.example.com. > >> > >> In the example.com. zone, the name bar.example.com. doesn't exist > >> (NXDOMAIN). > >> > >> A query for "foo.example.org./A" is answered by the nameserver. It adds > >> the foo.example.org. CNAME bar.example.com. in the answer section, and > >> then, following RFC 1034 4.3.2. 3.(a.), sets the QNAME to > >> "bar.example.com" and looks into the "example.com" zone for > >> "bar.example.com.". It is not found. > >> > >> The question is: what is the expected reply RCODE for this? > >> > >> 1. Is it NOERROR (0) because there is an answer section with the CNAME? > >> > >> 2. Is it NXDOMAIN (3) because the CNAME target was not found? > > > > NXDOMAIN is correct. The text on this on 103x is a bit weak but 2308 2.1 > > clarifies this. > > I actually think NOERROR is correct. The target of the CNAME > (bar.example.com) is not in the bailiwick of the zone (example.org). > So the authoritative server should stop processing the CNAME chain at > this point and send the response with RCODE=NOERROR. Well RFC 1034 doesn't say stop processing the CNAME chain when it points outside the original zone. You go back to step 1 on a CNAME (and DNAME) and look for the target zone of the *new* QNAME. a. If the whole of QNAME is matched, we have found the node. If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. And this whole issue was discussed and debated 2 decades ago. RFC 1034 has a number of errors in it. Other documents update it including RFC 2308. If you get to the end of the CNAME chain and the QNAME as it is at that point does not exist you return NXDOMAIN. If you don't get to the end of the CNAME chain then you return NOERROR and a referral if you have one to return. This introduces ambiguity. We really should allow NXRRSET to be returned for QUERY to remove this ambiguity. This requires that the server knows that the client supports NXRRSET with QUERY. Bumping the EDNS version number would be one way to signal this. Mark > Or can we at least agree that both RCODEs are correct? :-) > > Jan > > _______________________________________________ > 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 Apr 27 00:40: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 2702E128B44 for ; Thu, 27 Apr 2017 00:40:36 -0700 (PDT) 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 6b3nJJY74Qh4 for ; Thu, 27 Apr 2017 00:40:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 C75AB128B37 for ; Thu, 27 Apr 2017 00:40:33 -0700 (PDT) Received: from [IPv6:2001:67c:1220:80c:9059:23a4:1953:3f7a] (unknown [IPv6:2001:67c:1220:80c:9059:23a4:1953:3f7a]) by mail.nic.cz (Postfix) with ESMTPSA id 9DC9B62171 for ; Thu, 27 Apr 2017 09:40:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1493278830; bh=LYL5HuHEPrV+LjioAgZ9mSY3Nz6kQGHZgkSsH2+Cz1U=; h=To:From:Date; b=V4zYfc6Sjin61Yq69h5PZjmpQRnIfRCFFYr0CbFbgCE9sfuJxmYhBcBlhRTFzygYg boRHEQbecPII9b0Bd6ePzDM5zofB1sPFpcoAdePEqY80MCkDhKDPOkoJ/3+XdwBCcd QpcUKhxsmMrN+YshGT3zbH4/ztfQ2n37B4oBwxtY= To: dnsop@ietf.org References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <241ada25-4005-403f-0c1a-ce332a58e901@nic.cz> Date: Thu, 27 Apr 2017 09:40:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 07:40:36 -0000 On 21.3.2017 20:34, Jan Komissar (jkomissa) wrote: > Hi, > > I have one comment for this draft. In Section 3.3 Message Format, I would prefer that if a Session Signaling message is received where any of the section count fields are not zero, the receiver MUST respond with an error code, e.g. FORMERR, but MUST NOT terminate the connection. My reason is that in order to ignore any non-zero count fields, the receiving software must have code to walk all the sections and this code would effectively be useless, but would still have to be properly maintained. The soft error response is required to make it possible for a future client to probe servers for support for a future Session Signaling based feature that uses the RR sections. (Jan, thank you for reminding me to review this version!) Other people already commented on semantics so I will focus on message format: My attempts to find reasoning for the new TLV format in archives did not yield an elaborate explanation. Assuming I did not miss anything, it seems to me that the current TLV format (placed outside of standard DNS RR) is going to require brand new code and logic and makes imlementation harder than necessary. Every DNS server and resolver already has own code to parse DNS RRs do various operations with them but this could cannot be reused for the current TLV format. It would be much easier to implement if we had new RRs like (e.g.) "SSOP" and "SSMOD" and placed them inside additional section. We could get the same semantics by creating a DNS message with all sections empty except "SS*" RRs in additional section. Overhead on wire is negligible and it makes implementation much easier and safer (because the normal RR handling code is battle-tested already). For these reasons I propose to move to standard RR format to enable code re-use. Thank you for considering this. Petr Špaček @ CZ.NIC > Jan. > > > On 3/13/17, 7:44 PM, "DNSOP on behalf of 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 Session Signaling > Authors : Ray Bellis > Stuart Cheshire > John Dickinson > Sara Dickinson > Allison Mankin > Tom Pusateri > Filename : draft-ietf-dnsop-session-signal-02.txt > Pages : 25 > Date : 2017-03-13 > > Abstract: > The EDNS(0) Extension Mechanism for DNS is explicitly defined to only > have "per-message" semantics. This document defines a new Session > Signaling Opcode used to communicate persistent "per-session" > operations, expressed using type-length-value (TLV) syntax, and > defines an initial set of TLVs used to manage session timeouts and > termination. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-02 > > > 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 Apr 27 02:11: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 CB88C1243FE for ; Thu, 27 Apr 2017 02:11:13 -0700 (PDT) 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 GK-JkAuAhvMM for ; Thu, 27 Apr 2017 02:11:12 -0700 (PDT) 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 DAC461204DA for ; Thu, 27 Apr 2017 02:11:11 -0700 (PDT) Received: from [46.227.151.81] (port=55357 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 1d3fS8-0001wf-LB (Exim 4.72) for dnsop@ietf.org (return-path ); Thu, 27 Apr 2017 10:11:08 +0100 To: dnsop@ietf.org References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <241ada25-4005-403f-0c1a-ce332a58e901@nic.cz> From: Ray Bellis Message-ID: <52b94a85-d0af-ca3c-3c52-2255c1aa73b9@bellis.me.uk> Date: Thu, 27 Apr 2017 10:11:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <241ada25-4005-403f-0c1a-ce332a58e901@nic.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 09:11:14 -0000 On 27/04/2017 08:40, Petr Špaček wrote: > Other people already commented on semantics so I will focus on message > format: > > My attempts to find reasoning for the new TLV format in archives did not > yield an elaborate explanation. Assuming I did not miss anything, it > seems to me that the current TLV format (placed outside of standard DNS > RR) is going to require brand new code and logic and makes imlementation > harder than necessary. > > Every DNS server and resolver already has own code to parse DNS RRs do > various operations with them but this could cannot be reused for the > current TLV format. > > It would be much easier to implement if we had new RRs like (e.g.) > "SSOP" and "SSMOD" and placed them inside additional section. We could > get the same semantics by creating a DNS message with all sections empty > except "SS*" RRs in additional section. Overhead on wire is negligible > and it makes implementation much easier and safer (because the normal RR > handling code is battle-tested already). > > For these reasons I propose to move to standard RR format to enable code > re-use. Thank you for considering this. The break from standard RR format is intentional, and in large part to avoid the tendency to overload the existing meaning of RR fields as was done with EDNS (i.e. the use of the CLASS field to carry buffer size, and putting bit fields and extended RCODEs into the TTL field). It also (intentionally) prevents *mixing* of SS* TLVs and normal RRs within a session signalling message (or indeed vice versa, putting SS TLVs into a standard QUERY message). Yes, it'll need some new code, but it's not difficult code (indeed it'd be very similar to the code for parsing the RDATA of an OPT RR). I think the cost of that extra bit of code is outweighed by *not* needing extra code in the standard packet handling path to cope with rejecting mixed packets. Ray From nobody Thu Apr 27 02:14: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 C92EA128896 for ; Thu, 27 Apr 2017 02:14:09 -0700 (PDT) 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, 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=fcelda.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 F8DSX4fhs4oX for ; Thu, 27 Apr 2017 02:14:07 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 8E8611204DA for ; Thu, 27 Apr 2017 02:14:07 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 110so15707116uas.3 for ; Thu, 27 Apr 2017 02:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5W5Cns36n0cyMYxgp7VKAuVmAFhH+P/0DVGcoaziqAA=; b=XSJBLbiP3/FSBZKkUUQMBQ7/kuuGUN9nFNEmdXZDkwRs2fouhMKtjBsQVlxxjus3iJ IbG4VcPVEreNq0qWolvLTKe9Bxxvb9ASM8cMsgW0bD5mCHtqiIgAy3/5udWyrGc5wEtd 3CsLjNQ+F8qKN7jdMsWxktknnNOnQ5NXHufj8= 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=5W5Cns36n0cyMYxgp7VKAuVmAFhH+P/0DVGcoaziqAA=; b=KIZmk3zquIpetu4UJ6tEx2jHXv7TEiOJwRf8dWXStMblogpqMkOxdD81SKDsv9jiz3 clUcB8zRovSk1oxTXw6obxCkbRS+Hh5STd/KD2ApTSyrT2nke2zOs0UYfPu5kAA+U0rW r5APRUnfzS+vpsWZ3IJM9dq2nrHMqll8Fv8ezuBs5IElDHdUlvsRmLUCkMadDIA1HJVR ZV69WG7wVULiOjSn0sFBWU5SFPydju8vqRyahbe4dD3ZX+THpdCbodUbcFxWMFDMOx8d UD+GWNiNCC2Dvigo+cUVNfq316AZl6WFqs2f+mX0AaWcmnj+sHxe9WnISevk/zN58QKW geGQ== X-Gm-Message-State: AN3rC/5s2cQlOSZvjeMRiAKbWcStYqMdETy1F/X6E9MqvIVRiPQpo9cU ODTi1VQz2teSEnNSg9+R1FwE8UbFRLRq X-Received: by 10.159.55.229 with SMTP id q92mr2024514uaq.40.1493284446670; Thu, 27 Apr 2017 02:14:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.69 with HTTP; Thu, 27 Apr 2017 02:13:46 -0700 (PDT) X-Originating-IP: [89.103.145.110] In-Reply-To: <20170426230418.096AF6D06C7D@rock.dv.isc.org> References: <20170405054338.GA15831@jurassic> <73DD364E-12F0-4367-964D-6C18E37BC12B@powerdns.com> <20170426230418.096AF6D06C7D@rock.dv.isc.org> From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Date: Thu, 27 Apr 2017 11:13:46 +0200 Message-ID: To: Mark Andrews Cc: Peter van Dijk , muks@isc.org, dnsop@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 09:14:10 -0000 On Thu, Apr 27, 2017 at 1:04 AM, Mark Andrews wrote: > > In message > , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= writes: >> Hello, >> >> sorry for resurrecting this thread, but this really caught my attention. >> >> On Wed, Apr 5, 2017 at 9:03 AM, Peter van Dijk wrote: >> > On 5 Apr 2017, at 7:43, Mukund Sivaraman wrote: >> >> Evan just pointed out a case due to a system test failure that is >> >> interesting.. it's not clear what the behavior should be in this case, >> >> so please discuss: >> >> >> >> There's a nameserver that's authoritative for 2 zones example.org. and >> >> example.com. >> >> >> >> In the example.org. zone, foo.example.org. is CNAME to bar.example.com. >> >> >> >> In the example.com. zone, the name bar.example.com. doesn't exist >> >> (NXDOMAIN). >> >> >> >> A query for "foo.example.org./A" is answered by the nameserver. It adds >> >> the foo.example.org. CNAME bar.example.com. in the answer section, and >> >> then, following RFC 1034 4.3.2. 3.(a.), sets the QNAME to >> >> "bar.example.com" and looks into the "example.com" zone for >> >> "bar.example.com.". It is not found. >> >> >> >> The question is: what is the expected reply RCODE for this? >> >> >> >> 1. Is it NOERROR (0) because there is an answer section with the CNAME? >> >> >> >> 2. Is it NXDOMAIN (3) because the CNAME target was not found? >> > >> > NXDOMAIN is correct. The text on this on 103x is a bit weak but 2308 2.1 >> > clarifies this. >> >> I actually think NOERROR is correct. The target of the CNAME >> (bar.example.com) is not in the bailiwick of the zone (example.org). >> So the authoritative server should stop processing the CNAME chain at >> this point and send the response with RCODE=NOERROR. > > Well RFC 1034 doesn't say stop processing the CNAME chain when it > points outside the original zone. You go back to step 1 on a CNAME > (and DNAME) and look for the target zone of the *new* QNAME. > > a. If the whole of QNAME is matched, we have found the > node. > > If the data at the node is a CNAME, and QTYPE doesn't > match CNAME, copy the CNAME RR into the answer section > of the response, change QNAME to the canonical name in > the CNAME RR, and go back to step 1. > > And this whole issue was discussed and debated 2 decades ago. RFC > 1034 has a number of errors in it. Other documents update it > including RFC 2308. > > If you get to the end of the CNAME chain and the QNAME as it is at > that point does not exist you return NXDOMAIN. > > If you don't get to the end of the CNAME chain then you return > NOERROR and a referral if you have one to return. This introduces > ambiguity. Mark, you are absolute right if you interpret the RFCs word-for-word. But these documents were written before we knew or cared about cache poisoning attacks. And when the resolvers started to ignore out-of-bailiwick records, authoritative server should have been updated as well and should have stopped sending out-of-bailiwick records. Because anything out-of-bailiwick is potentially dangerous. My advocacy for NOERROR is based on that even though we don't have a document that would specify that. > We really should allow NXRRSET to be returned for QUERY to remove this > ambiguity. This requires that the server knows that the client supports > NXRRSET with QUERY. Bumping the EDNS version number would be one way to > signal this. Yes, that would be more explicit. But I don't think this is worth the effort. Resolvers can deal with this ambiguity already. Jan From nobody Thu Apr 27 02:31: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 B09E212708C for ; Thu, 27 Apr 2017 02:31:58 -0700 (PDT) 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 LCrTjUGP4D42 for ; Thu, 27 Apr 2017 02:31:57 -0700 (PDT) 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 AEB721204DA for ; Thu, 27 Apr 2017 02:31:57 -0700 (PDT) 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 2599934930F; Thu, 27 Apr 2017 09:31:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E7E25160074; Thu, 27 Apr 2017 09:31:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 92A20160067; Thu, 27 Apr 2017 09:31:53 +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 pKDuJ1H8aI2M; Thu, 27 Apr 2017 09:31:53 +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 BCEFD16003A; Thu, 27 Apr 2017 09:31:52 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 59B086D3F5C9; Thu, 27 Apr 2017 19:31:50 +1000 (AEST) To: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Cc: Peter van Dijk , muks@isc.org, dnsop@ietf.org From: Mark Andrews References: <20170405054338.GA15831@jurassic> <73DD364E-12F0-4367-964D-6C18E37BC12B@powerdns.com> <20170426230418.096AF6D06C7D@rock.dv.isc.org> In-reply-to: Your message of "Thu, 27 Apr 2017 11:13:46 +0200." Date: Thu, 27 Apr 2017 19:31:50 +1000 Message-Id: <20170427093150.59B086D3F5C9@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 09:31:58 -0000 In message , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= writes: > On Thu, Apr 27, 2017 at 1:04 AM, Mark Andrews wrote: > > > > In message com> > > , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= writes: > >> Hello, > >> > >> sorry for resurrecting this thread, but this really caught my attention. > >> > >> On Wed, Apr 5, 2017 at 9:03 AM, Peter van Dijk wrote: > >> > On 5 Apr 2017, at 7:43, Mukund Sivaraman wrote: > >> >> Evan just pointed out a case due to a system test failure that is > >> >> interesting.. it's not clear what the behavior should be in this case, > >> >> so please discuss: > >> >> > >> >> There's a nameserver that's authoritative for 2 zones example.org. and > >> >> example.com. > >> >> > >> >> In the example.org. zone, foo.example.org. is CNAME to bar.example.com. > >> >> > >> >> In the example.com. zone, the name bar.example.com. doesn't exist > >> >> (NXDOMAIN). > >> >> > >> >> A query for "foo.example.org./A" is answered by the nameserver. It adds > >> >> the foo.example.org. CNAME bar.example.com. in the answer section, and > >> >> then, following RFC 1034 4.3.2. 3.(a.), sets the QNAME to > >> >> "bar.example.com" and looks into the "example.com" zone for > >> >> "bar.example.com.". It is not found. > >> >> > >> >> The question is: what is the expected reply RCODE for this? > >> >> > >> >> 1. Is it NOERROR (0) because there is an answer section with the CNAME? > >> >> > >> >> 2. Is it NXDOMAIN (3) because the CNAME target was not found? > >> > > >> > NXDOMAIN is correct. The text on this on 103x is a bit weak but 2308 2.1 > >> > clarifies this. > >> > >> I actually think NOERROR is correct. The target of the CNAME > >> (bar.example.com) is not in the bailiwick of the zone (example.org). > >> So the authoritative server should stop processing the CNAME chain at > >> this point and send the response with RCODE=NOERROR. > > > > Well RFC 1034 doesn't say stop processing the CNAME chain when it > > points outside the original zone. You go back to step 1 on a CNAME > > (and DNAME) and look for the target zone of the *new* QNAME. > > > > a. If the whole of QNAME is matched, we have found the > > node. > > > > If the data at the node is a CNAME, and QTYPE doesn't > > match CNAME, copy the CNAME RR into the answer section > > of the response, change QNAME to the canonical name in > > the CNAME RR, and go back to step 1. > > > > And this whole issue was discussed and debated 2 decades ago. RFC > > 1034 has a number of errors in it. Other documents update it > > including RFC 2308. > > > > If you get to the end of the CNAME chain and the QNAME as it is at > > that point does not exist you return NXDOMAIN. > > > > If you don't get to the end of the CNAME chain then you return > > NOERROR and a referral if you have one to return. This introduces > > ambiguity. > > Mark, you are absolute right if you interpret the RFCs word-for-word. > But these documents were written before we knew or cared about cache > poisoning attacks. And when the resolvers started to ignore > out-of-bailiwick records, authoritative server should have been > updated as well and should have stopped sending out-of-bailiwick > records. Because anything out-of-bailiwick is potentially dangerous. > My advocacy for NOERROR is based on that even though we don't have a > document that would specify that. If you want to advocate for changes to behaviour that is fine, but advocate for that. Just saying "shouldn't the rcode be NOERROR" isn't doing that. Then there is DNSSEC. If the target zone is signed and DO=1 is set in the query should you include the data from the target zone? You also have to deal with recursive servers that should always follow the entire chain. Remember there is nothing wrong with recursive server having authorative content. Mark > > We really should allow NXRRSET to be returned for QUERY to remove this > > ambiguity. This requires that the server knows that the client supports > > NXRRSET with QUERY. Bumping the EDNS version number would be one way to > > signal this. > > Yes, that would be more explicit. But I don't think this is worth the > effort. Resolvers can deal with this ambiguity already. > > Jan -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Apr 27 03:53: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 37FAD128B93 for ; Thu, 27 Apr 2017 03:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Y1R98-Y1nl_6 for ; Thu, 27 Apr 2017 03:53:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4210128B8E for ; Thu, 27 Apr 2017 03:53:39 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2A7097E9F2; Thu, 27 Apr 2017 10:53:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2A7097E9F2 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2A7097E9F2 Received: from oldenburg.str.redhat.com (ovpn-117-221.ams2.redhat.com [10.36.117.221]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D47638909B; Thu, 27 Apr 2017 10:53:36 +0000 (UTC) To: Mark Andrews , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Cc: dnsop@ietf.org, Peter van Dijk , muks@isc.org References: <20170405054338.GA15831@jurassic> <73DD364E-12F0-4367-964D-6C18E37BC12B@powerdns.com> <20170426230418.096AF6D06C7D@rock.dv.isc.org> <20170427093150.59B086D3F5C9@rock.dv.isc.org> From: Florian Weimer Message-ID: Date: Thu, 27 Apr 2017 12:53:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170427093150.59B086D3F5C9@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 27 Apr 2017 10:53:39 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 10:53:41 -0000 On 04/27/2017 11:31 AM, Mark Andrews wrote: > If you want to advocate for changes to behaviour that is fine, but > advocate for that. Just saying "shouldn't the rcode be NOERROR" > isn't doing that. Then there is DNSSEC. If the target zone is > signed and DO=1 is set in the query should you include the data > from the target zone? Do you suggest to use data which is impossible to use under the trust rules because it is cryptographically signed? This would mean that many DNSSEC validation bugs turn into critical cache poisoning bugs because they can be used by off-path attackers to poison caches. (Usually, a single query for an attacker-controlled name would be enough, and it could likely be a PTR query.) I'm not sure if saving a server round-trip is worth it. In particular since the recursive resolver already has the infrastructure records for the target in cache if it can do cryptographic validation, it should know exactly where to fetch the target record anyway. In general, cryptography as the single line of defense is a very, very bad idea because it almost never works correctly. Thanks, Florian From nobody Thu Apr 27 04:14: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 29720129329 for ; Thu, 27 Apr 2017 04:13:59 -0700 (PDT) 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 lJF6Eu9nhD0n for ; Thu, 27 Apr 2017 04:13:58 -0700 (PDT) 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 E0780128BB7 for ; Thu, 27 Apr 2017 04:13:57 -0700 (PDT) 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 93EFE24AE08; Thu, 27 Apr 2017 11:12:36 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 67B1016003A; Thu, 27 Apr 2017 11:12:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3ED8E160067; Thu, 27 Apr 2017 11:12: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 cvDLBz_ZRYEb; Thu, 27 Apr 2017 11:12: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 C7D7C16003A; Thu, 27 Apr 2017 11:12:36 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 789C86D3FE60; Thu, 27 Apr 2017 21:12:34 +1000 (AEST) To: Florian Weimer Cc: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= , dnsop@ietf.org, Peter van Dijk , muks@isc.org From: Mark Andrews References: <20170405054338.GA15831@jurassic> <73DD364E-12F0-4367-964D-6C18E37BC12B@powerdns.com> <20170426230418.096AF6D06C7D@rock.dv.isc.org> <20170427093150.59B086D3F5C9@rock.dv.isc.org> In-reply-to: Your message of "Thu, 27 Apr 2017 12:53:35 +0200." Date: Thu, 27 Apr 2017 21:12:34 +1000 Message-Id: <20170427111234.789C86D3FE60@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] RCODE and CNAME chain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 11:13:59 -0000 In message , Florian Weimer writes: > On 04/27/2017 11:31 AM, Mark Andrews wrote: > > If you want to advocate for changes to behaviour that is fine, but > > advocate for that. Just saying "shouldn't the rcode be NOERROR" > > isn't doing that. Then there is DNSSEC. If the target zone is > > signed and DO=1 is set in the query should you include the data > > from the target zone? > > Do you suggest to use data which is impossible to use under the trust > rules because it is cryptographically signed? Yes. DNSSEC validators do it all the time. DNSSEC does not care who supplies the data. > This would mean that many DNSSEC validation bugs turn into critical > cache poisoning bugs because they can be used by off-path attackers to > poison caches. And in the last decade how many DNSSEC validation bugs have there been that have marked answers as secure when they haven't been? B.T.W. named has been returning additional as answer if the RRset validates as secure for about a decade now. I devised the trust rules for named 20+ years ago now. They are designed for dealing with answers that can't be cryptographically verified. > (Usually, a single query for an attacker-controlled name > would be enough, and it could likely be a PTR query.) I'm not sure if > saving a server round-trip is worth it. In particular since the > recursive resolver already has the infrastructure records for the target > in cache if it can do cryptographic validation, it should know exactly > where to fetch the target record anyway. > > In general, cryptography as the single line of defense is a very, very > bad idea because it almost never works correctly. > > Thanks, > Florian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Apr 30 19:44: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 EA0D3127241; Sun, 30 Apr 2017 19:44:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: dnsop@ietf.org, ietf@ietf.org, draft-ietf-dnsop-nsec-aggressiveuse.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149360667193.9876.7534874775326889081@ietfa.amsl.com> Date: Sun, 30 Apr 2017 19:44:31 -0700 Archived-At: Subject: [DNSOP] Genart telechat review of draft-ietf-dnsop-nsec-aggressiveuse-09 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 02:44:32 -0000 Reviewer: Joel Halpern Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-dnsop-nsec-aggressiveuse-09 Reviewer: Joel Halpern Review Date: 2017-04-30 IETF LC End Date: 2017-03-27 IESG Telechat date: 2017-05-25 Summary: This document is almost ready for publication as a Proposed Standard RFC Major issues: Procedural - ID Nits notes that there are normative references to RFCs 7129 and 7719. Those are informational RFCs. The shepherd writeup does not note these downrefs. (I see this was also noted by Jouni Korhonen, but I do not see a resolution.) Minor issues: Nits/editorial comments: