From shane@isc.org Tue May 1 08:38:45 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2A621E804A for ; Tue, 1 May 2012 08:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.743 X-Spam-Level: X-Spam-Status: No, score=-2.743 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLBSnRTegFvk for ; Tue, 1 May 2012 08:38:45 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D463C21E8049 for ; Tue, 1 May 2012 08:38:44 -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)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id D6658C972E; Tue, 1 May 2012 15:38:33 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-eeepc.home.time-travellers.org (unknown [IPv6:2001:610:719:1:4a5d:60ff:fe2a:dd50]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B1AC3216C33; Tue, 1 May 2012 15:38:32 +0000 (UTC) (envelope-from shane@isc.org) Date: Tue, 1 May 2012 17:38:16 +0200 From: Shane Kerr To: Jim Reid Message-ID: <20120501173816.297db698@shane-eeepc.home.time-travellers.org> In-Reply-To: <888B37DE-66E5-46F7-8F33-B5B8EDC987E1@rfc1035.com> References: <20120417115125.4a966c81@shane-eeepc.home.time-travellers.org> <4F8F0321.5040307@redbarn.org> <188F19B4-FD25-45C3-9A92-E8D47EF1651B@virtualized.org> <888B37DE-66E5-46F7-8F33-B5B8EDC987E1@rfc1035.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dnsop Subject: Re: [DNSOP] NTA... the new NAT? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 15:38:45 -0000 Jim, (Sorry for the late reply, I've been busy.) On Wednesday, 2012-04-18 19:52:14 +0100, Jim Reid wrote: > On 18 Apr 2012, at 19:28, David Conrad wrote: > > > If you don't like the policy of your validator operator, change to > > a validator operator whose policy you agree with (or, better yet, > > run your own validator -- it is the only way to be sure). If you > > are not permitted to do this, you have other issues. > > +1 > > Though you've not explained how someone would be able to find out > what was the flavour-of-the-month policy of the validator operator > they were using that day. Assuming the current network's validation > policy was broken (for some definition of broken) would of course be > a wise approach. That probably means everyone runs their own > validator to avoid sucky hotel nets and the like. Which just moves > where NTAs get (mis)configured. Well, there is perhaps an idea here. If we make NTA something that can be queried, then you would have this ability. Full transparency seems good, although in practice I'm not sure anyone would actually use the facility if it was available. -- Shane From cet1@hermes.cam.ac.uk Tue May 1 09:34:28 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9EE21E8299 for ; Tue, 1 May 2012 09:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpHE12zd5BDD for ; Tue, 1 May 2012 09:34:27 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 45D9021E828D for ; Tue, 1 May 2012 09:34:27 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35491) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:cet1) id 1SPG1j-0002Vx-Xb (Exim 4.72) (return-path ); Tue, 01 May 2012 17:34:11 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1SPG1j-0005Kz-Ch (Exim 4.67) (return-path ); Tue, 01 May 2012 17:34:11 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 01 May 2012 17:34:11 +0100 Date: 01 May 2012 17:34:11 +0100 From: Chris Thompson To: Shane Kerr Message-ID: In-Reply-To: <20120501173816.297db698@shane-eeepc.home.time-travellers.org> References: <20120417115125.4a966c81@shane-eeepc.home.time-travellers.org> <4F8F0321.5040307@redbarn.org> <188F19B4-FD25-45C3-9A92-E8D47EF1651B@virtualized.org> <888B37DE-66E5-46F7-8F33-B5B8EDC987E1@rfc1035.com> <20120501173816.297db698@shane-eeepc.home.time-travellers.org> X-Mailer: Prayer v1.3.4 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: dnsop Subject: Re: [DNSOP] NTA... the new NAT? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 16:34:28 -0000 On May 1 2012, Shane Kerr wrote: [...] >On Wednesday, 2012-04-18 19:52:14 +0100, >Jim Reid wrote: >> On 18 Apr 2012, at 19:28, David Conrad wrote: >> >> > If you don't like the policy of your validator operator, change to >> > a validator operator whose policy you agree with (or, better yet, >> > run your own validator -- it is the only way to be sure). If you >> > are not permitted to do this, you have other issues. >> >> +1 >> >> Though you've not explained how someone would be able to find out >> what was the flavour-of-the-month policy of the validator operator >> they were using that day. Assuming the current network's validation >> policy was broken (for some definition of broken) would of course be >> a wise approach. That probably means everyone runs their own >> validator to avoid sucky hotel nets and the like. Which just moves >> where NTAs get (mis)configured. > >Well, there is perhaps an idea here. If we make NTA something that can >be queried, then you would have this ability. Full transparency seems >good, although in practice I'm not sure anyone would actually use the >facility if it was available. What would be needed would be a method of finding out about *all* DNSSEC trust anchors being used, both positive and negative. And what about DLV? (sorry, Jim) -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From paul@redbarn.org Tue May 1 10:06:21 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F023C21E8188 for ; Tue, 1 May 2012 10:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKlCmEP4g8-Y for ; Tue, 1 May 2012 10:06:20 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id 84EC321E8034 for ; Tue, 1 May 2012 10:06:20 -0700 (PDT) Received: from [172.16.6.154] (unknown [8.28.216.199]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 86066EBC8D; Tue, 1 May 2012 17:06:16 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4FA01803.3010708@redbarn.org> Date: Tue, 01 May 2012 17:06:11 +0000 From: paul vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: cet1@cam.ac.uk References: <20120417115125.4a966c81@shane-eeepc.home.time-travellers.org> <4F8F0321.5040307@redbarn.org> <188F19B4-FD25-45C3-9A92-E8D47EF1651B@virtualized.org> <888B37DE-66E5-46F7-8F33-B5B8EDC987E1@rfc1035.com> <20120501173816.297db698@shane-eeepc.home.time-travellers.org> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsop , Shane Kerr Subject: Re: [DNSOP] NTA... the new NAT? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 17:06:21 -0000 On 5/1/2012 4:34 PM, Chris Thompson wrote: > What would be needed would be a method of finding out about *all* > DNSSEC trust anchors being used, both positive and negative. +1. > > And what about DLV? (sorry, Jim) > dlv is probably wrong for this, for two reasons. first, it only engages when normal validation fails. i think there are nta use cases where validation succeeds. second, dlv is only implementable in a recursive server. we need to take seriously stub validation and dnssec-enabled apps (like dane). -- "But I'm not done complaining." --Dagon, 2012 From bortzmeyer@nic.fr Wed May 2 04:02:30 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9A821F89A8 for ; Wed, 2 May 2012 04:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.983 X-Spam-Level: X-Spam-Status: No, score=-101.983 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqY+8D6a31lY for ; Wed, 2 May 2012 04:02:28 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA5821F89A2 for ; Wed, 2 May 2012 04:02:28 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2665028053E for ; Wed, 2 May 2012 13:02:05 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 15935280549; Wed, 2 May 2012 13:02:05 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [IPv6:2001:67c:2218:9::4:162]) by mx4.nic.fr (Postfix) with ESMTP id 100B428053E for ; Wed, 2 May 2012 13:02:05 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id 050484C007B for ; Wed, 2 May 2012 13:02:05 +0200 (CEST) Date: Wed, 2 May 2012 13:02:05 +0200 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20120502110204.GA21826@nic.fr> References: <20120424124644.4369.15665.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120424124644.4369.15665.idtracker@ietfa.amsl.com> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.2.0-2-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2012.5.2.104225 X-PerlMx-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_300_399 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' Subject: Re: [DNSOP] I-D Action: draft-perreault-dnsop-stats-mib-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 11:02:30 -0000 On Tue, Apr 24, 2012 at 05:46:44AM -0700, internet-drafts@ietf.org wrote a message of 33 lines which said: > Title : DNS Server Statistics Management Information Base (MIB) A mention of RFC 3197, and an explicit answer to the questions it raises, seems necessary to me. From simon.perreault@viagenie.ca Wed May 2 04:34:46 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6696C21F8AF4 for ; Wed, 2 May 2012 04:34:46 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca6QOrapV+Kf for ; Wed, 2 May 2012 04:34:42 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 7D67821F8AEB for ; Wed, 2 May 2012 04:34:42 -0700 (PDT) Received: from [192.168.0.100] (modemcable010.192-131-66.mc.videotron.ca [66.131.192.10]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 96F7F41364 for ; Wed, 2 May 2012 07:34:41 -0400 (EDT) Message-ID: <4FA11BCD.8020808@viagenie.ca> Date: Wed, 02 May 2012 07:34:37 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120424124644.4369.15665.idtracker@ietfa.amsl.com> <20120502110204.GA21826@nic.fr> In-Reply-To: <20120502110204.GA21826@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] I-D Action: draft-perreault-dnsop-stats-mib-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 11:34:46 -0000 On 2012-05-02 07:02, Stephane Bortzmeyer wrote: > A mention of RFC 3197, and an explicit answer to the questions it > raises, seems necessary to me. Will be added in the next revision. It will be along the lines of "what we're doing is much more simple and focused". This MIB is about simple read-only counters of which many servers already provide at least a subset, and for which home-grown bindings into SNMP agents (using Perl scripts and such) already exist in various forms. So to some extent we're standardizing existing practice, which wasn't the case for RFCs 1611 and 1612. And there are already plans and preliminary code for such a DNS MIB in Bind 10. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From joe.gersch@secure64.com Wed May 2 09:24:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE39921E803C for ; Wed, 2 May 2012 09:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKMZHfTB2pSG for ; Wed, 2 May 2012 09:24:41 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 04DC821E801E for ; Wed, 2 May 2012 09:24:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id DE3FCB8504 for ; Wed, 2 May 2012 10:24:39 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6V8eVh1JDJt; Wed, 2 May 2012 10:24:39 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id C3253B84D6 for ; Wed, 2 May 2012 10:24:38 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1335975878; bh=cDUfsB9PCJRGvcKRSu5MpoTg2LzvBLxeVnE7aQkyq+w=; h=Subject:Date:MIME-Version:Content-Type:Message-ID:References:From: To; b=UnTPdMtKbDKg36J2AYnANd+hVLua1jGDpKfR6auSP1Oi/LvFdJfp60rSj2fG pR8lIN/EZHllKMbohnjTl9K5TyyV+TujBCxblhPhFh0GktvCmVKSOoTjarK2Qvispes +pdA7hEPlcG26Q8kRgenSSuYE37bV4IS0pPfiJEoYksQ= Content-class: urn:content-classes:message Date: Wed, 2 May 2012 10:22:18 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD287F.BE681624" Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: New Version Notification for draft-gersch-dnsop-revdns-cidr-02.txt Thread-Index: Ac0ofrohQ8nytccbQJqPeGGkn7TO4AAADCY3 References: <20120502161713.4352.16872.idtracker@ietfa.amsl.com> From: "Joe Gersch" To: Subject: [DNSOP] FW: New Version Notification for draft-gersch-dnsop-revdns-cidr-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 16:24:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD287F.BE681624 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DNSOP reviewers, We have submitted a new revision of draft-gersch-dnsop-revdns-cidr = which defines a method for naming CIDR address blocks in the reverse = DNS. This revision addresses the concerns and suggestions raised at the = IETF Paris meeting and from the mailing list. In particular (from the = change log): Changes from version 01 to 02 Concerns were raised at the IETF 83 meeting that the document appeared to specific to the routing application. Several other applications were mentioned. We clarified the introduction to show that the naming convention is application agnostic. Expanded the related work discussion to include RFC 1101. The "m" label is now added even when on an octet boundary. Moved all other discussion into the Additional Considerations section; removing the alternate naming and replacing it with a discussion of existing delegations, adding a section on separating prefix and PTR records, added a section on enumerating prefixes and finding longest matches. All these changes reflect comments from the mailing list, IETF 83 discussions, and other comments. They do not change the naming scheme itself. To emphasize the approach is application agnostic, the appendix examples were changed from using routing security records to LOC records. Any record type could be used, but LOC records were chosen as they were viewed as easy to understand. Thank you for your comments and ideas, - Joe Gersch, Dan Massey and Eric Osterweil -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Wed 5/2/2012 10:17 AM To: Joe Gersch Cc: eosterweil@verisign.com; massey@cs.colostate.edu Subject: New Version Notification for = draft-gersch-dnsop-revdns-cidr-02.txt =20 A new version of I-D, draft-gersch-dnsop-revdns-cidr-02.txt has been = successfully submitted by Joe Gersch and posted to the IETF repository. Filename: draft-gersch-dnsop-revdns-cidr Revision: 02 Title: Reverse DNS Naming Convention for CIDR Address Blocks Creation date: 2012-05-01 WG ID: Individual Submission Number of pages: 24 Abstract: The reverse DNS naming method is used to specify a complete IP address. At present there is no standard way for the reverse DNS to handle address ranges. As an example, there is no formal mechanism to define a reverse DNS name for the block of addresses specified by the IPv4 prefix 129.82.0.0/16. Defining such a reverse DNS naming convention would be useful for a number of applications. This draft proposes a naming convention for encoding CIDR address blocks into the reverse DNS namespace. = =20 The IETF Secretariat ------_=_NextPart_001_01CD287F.BE681624 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: New Version Notification for = draft-gersch-dnsop-revdns-cidr-02.txt

DNSOP reviewers,

   We have submitted a new revision of = draft-gersch-dnsop-revdns-cidr which defines a method for naming CIDR = address blocks in the reverse DNS.

   This revision addresses the concerns and suggestions raised = at the IETF Paris meeting and from the mailing list.  In particular = (from the change log):

   Changes from version 01 to 02

      Concerns were raised at the IETF 83 = meeting that the document
      appeared to specific to the routing = application.  Several other
      applications were mentioned.  We = clarified the introduction to
      show that the naming convention is = application agnostic.

      Expanded the related work discussion to = include RFC 1101.

      The "m" label is now added even = when on an octet boundary.

      Moved all other discussion into the = Additional Considerations
      section; removing the alternate naming = and replacing it with a
      discussion of existing delegations, = adding a section on separating
      prefix and PTR records, added a section = on enumerating prefixes
      and finding longest matches.  All = these changes reflect comments
      from the mailing list, IETF 83 = discussions, and other comments.
      They do not change the naming scheme = itself.

      To emphasize the approach is application = agnostic, the appendix
      examples were changed from using routing = security records to LOC
      records.  Any record type could be = used, but LOC records were
      chosen as they were viewed as easy to = understand.

Thank you for your comments and ideas,
  - Joe Gersch, Dan Massey and Eric Osterweil





-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org<= /A>]
Sent: Wed 5/2/2012 10:17 AM
To: Joe Gersch
Cc: eosterweil@verisign.com; massey@cs.colostate.edu
Subject: New Version Notification for = draft-gersch-dnsop-revdns-cidr-02.txt

A new version of I-D, draft-gersch-dnsop-revdns-cidr-02.txt has been = successfully submitted by Joe Gersch and posted to the IETF = repository.

Filename:        = draft-gersch-dnsop-revdns-cidr
Revision:        02
Title:           Reverse = DNS Naming Convention for CIDR Address Blocks
Creation date:   2012-05-01
WG ID:           Individual = Submission
Number of pages: 24

Abstract:
   The reverse DNS naming method is used to specify a complete = IP
   address.  At present there is no standard way for the = reverse DNS to
   handle address ranges.  As an example, there is no = formal mechanism
   to define a reverse DNS name for the block of addresses = specified by
   the IPv4 prefix 129.82.0.0/16.  Defining such a = reverse DNS naming
   convention would be useful for a number of = applications.  This draft
   proposes a naming convention for encoding CIDR address = blocks into
   the reverse DNS namespace.

            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =         


The IETF Secretariat

------_=_NextPart_001_01CD287F.BE681624-- From Ray.Bellis@nominet.org.uk Wed May 9 08:31:46 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4199711E809F for ; Wed, 9 May 2012 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PTlUSq-7bOs for ; Wed, 9 May 2012 08:31:45 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id F094F11E8097 for ; Wed, 9 May 2012 08:31:43 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=VWryCkCILbzkj3BjKGaH3ptJlYmLu8P+qKFX+okGOIBTBTQFXJs3U2EK bgMbe03BzukPHeRFh+5zSghPqNQV7sxjA/1UsB0WgxiUzsr56GV428LkL 85fXUimBQaggAcu; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1336577505; x=1368113505; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[DNSOP]=20New=20Version=20Notification =20for=0D=0A=09draft-gersch-dnsop-revdns-cidr-02.txt |Date:=20Wed,=209=20May=202012=2015:31:41=20+0000 |Message-ID:=20<25020126-A23C-4FC2-BF21-3B685DD2A489@nomi net.org.uk>|To:=20Joe=20Gersch=20|CC:=20"dnsop@ietf.org"=20|MIME-Version: =201.0|In-Reply-To:=20|References:=20<20120502161713 .4352.16872.idtracker@ietfa.amsl.com>=0D=0A=20; bh=xr+0e7PAq5uzJatTohrDNABAhzmECTdOM5mZf0W8C0M=; b=f72KRkt98NHxkzNezdI7cnGSyQdEA2GG/5sYw3G1hSN5ww5tRVgt8fwN EP/KcjTD/E/nDZpf3R94GFUeyhq1kXJnJgHrA44ggHpIV8i3CjFAUn8NP 7tUksg8Z1zFn4u+; X-IronPort-AV: E=Sophos;i="4.75,558,1330905600"; d="scan'208,217";a="32976979" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 09 May 2012 16:31:42 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Wed, 9 May 2012 16:31:41 +0100 From: Ray Bellis To: Joe Gersch Thread-Topic: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-02.txt Thread-Index: AQHNLfjVRYMghp3JEUijiqSzGF20rQ== Date: Wed, 9 May 2012 15:31:41 +0000 Message-ID: <25020126-A23C-4FC2-BF21-3B685DD2A489@nominet.org.uk> References: <20120502161713.4352.16872.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_25020126A23C4FC2BF213B685DD2A489nominetorguk_" MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:31:46 -0000 --_000_25020126A23C4FC2BF213B685DD2A489nominetorguk_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe, The draft says: "The challenge is to preserve this alignment even when even when CIDR prefixes do not fall on octet boundaries. For example, 129.82.128.0/19 is a subprefix of 129.82.128.0/18. The DNS name for 129.82.128.0/19 should be logically below the DNS name for 129.82.128.0/18. This document introduces a naming convention for CIDR prefixes that preserves this alignment" Whilst you've made some changes in -02 relating to the octet boundaries, as= far as I can see this assertion is still not true. The draft shows 129.82/16 mapping to m.82.129.in-addr.arpa, and 129.82.64/1= 8 mapping to 1.0.m.82.129.in-addr.arpa, so that's OK. However 129/8 would map to m.129.in-addr.arpa, but m.82.129.in-addr.arpa (1= 29.82/16) is _not_ a subdomain of that, even though it is a sub-prefix of t= he /8. It seems to be that your scheme works when considering prefixes which are s= plit _within_ an octet, but does not work when considering splits _across_ = an octet boundary. Or have I misunderstood? kind regards, Ray --_000_25020126A23C4FC2BF213B685DD2A489nominetorguk_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <565c091d-4a0b-407f-8171-1a522feb3d4e> Content-Transfer-Encoding: quoted-printable Joe,

The draft s= ays:

"The challe= nge is to preserve this alignment even when even when CIDR
prefixes do not fall on octet boundari= es. For example, 129.82.128.0/19 is a subprefix of 129.82.128.0/18. The DNS name for 129.82.128.0/19 should be logically below the DNS name for 129.82.128.0/18. This document introduces a naming convention for CIDR prefixes that preserves this alignment"

Whil=
st you've made some changes in -02 relating to the octet boundaries, as far=
 as I can see this assertion is still not true.

The dra=
ft shows 129.82/16 mapping to m.82.129.in-addr.arpa, and 129.82.64/18 mappi=
ng to 1.0.m.82.129.in-addr.arpa, so that's OK.

However =
129/8 would map to m.129.in-addr.=
arpa, but m.82.129.in-addr.arpa (129.82/16) is _not_ a subdomain of that, e=
ven though it is a sub-prefix of the /8.

It= seems to be that your scheme works when considering prefixes which are spl= it _within_ an octet, but does not work when considering splits _across_ an= octet boundary.

Or have I misunderstood?

kind regards,

Ray

<= /div>= --_000_25020126A23C4FC2BF213B685DD2A489nominetorguk_-- From internet-drafts@ietf.org Wed May 9 15:25:04 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C7911E80BB; Wed, 9 May 2012 15:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ib2iCqiuc8fP; Wed, 9 May 2012 15:25:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9952A11E8086; Wed, 9 May 2012 15:25:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120509222503.12175.33951.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2012 15:25:03 -0700 Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-respsize-14.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 22:25:04 -0000 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 Working= Group of the IETF. Title : DNS Referral Response Size Issues Author(s) : Paul Vixie Akira Kato Filename : draft-ietf-dnsop-respsize-14.txt Pages : 14 Date : 2012-05-09 With a mandated default minimum maximum UDP message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit, and suggests ways to optimize the use of this limited space. Guidance is offered to DNS server implementors and to DNS zone operators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-14.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-respsize/ From Ed.Lewis@neustar.biz Thu May 10 10:55:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F392811E8096 for ; Thu, 10 May 2012 10:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.442 X-Spam-Level: X-Spam-Status: No, score=-104.442 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_40=-0.185, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xkzxxsn0o9su for ; Thu, 10 May 2012 10:55:07 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4292121F86CB for ; Thu, 10 May 2012 10:55:07 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q4AHt5VP066919; Thu, 10 May 2012 13:55:05 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.234] by Work-Laptop-2.local (PGP Universal service); Thu, 10 May 2012 13:55:05 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 10 May 2012 13:55:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120509222503.12175.33951.idtracker@ietfa.amsl.com> References: <20120509222503.12175.33951.idtracker@ietfa.amsl.com> Date: Thu, 10 May 2012 13:55:02 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-respsize-14.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 17:55:15 -0000 >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-14.txt For kicks I ran the included perl code against the 313 delegations from the root zone (313 does not include "root" and does include the 11 test TLDs). ...I'll leave it to the draft to explain the headings and rankings below. I did this just to measure the draft's assessments against the TLD settings. Not that the TLDs are the only audience of this draft, but it's a convenient data set. Measured in %'ages of 313: Max length domain name || Average length domain name Color A-only A+AAAA A-preferred || A-only A+AAAA A-preferred || Green 59% 19% 19% || 99% 69% 69% Yellow 35% 41% 18% || 1% 31% 28% Orange 4% 21% 9% || 1% Red 2% 11% 53% || 2% The left matrix is more important (operationally). That's about the only commentary I'll add, just to head off the concern of "red"s in the right matrix. To Paul and Akira, here's more or less what I did with the results of the pl: looping through the names in the root zone: server_set=`dig @127.0.0.1 +short $name ns` size_estimate=`perl respsize.pl $server_set` results=`echo $size_estimate | sed "getting '()'s#$name \2 \3 \4 \6 \7 \8#"` echo "$results" and then used a spreadsheet to do the percentages. (Shown in case I messed up something.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From jtk@cymru.com Mon May 14 15:29:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C519E21F847D for ; Mon, 14 May 2012 15:29:54 -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=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QpIet2a+O9z for ; Mon, 14 May 2012 15:29:53 -0700 (PDT) Received: from mailout.cymru.com (mailout.cymru.com [38.229.36.8]) by ietfa.amsl.com (Postfix) with ESMTP id C43F321F843E for ; Mon, 14 May 2012 15:29:53 -0700 (PDT) Received: from localhost (vpn-72-39.svcs.ord07.cymru.com [172.16.72.39]) by mailout.cymru.com (Postfix) with ESMTP id 3B15346F02B for ; Mon, 14 May 2012 22:29:47 +0000 (GMT) Date: Mon, 14 May 2012 17:29:46 -0500 From: John Kristoff To: dnsop@ietf.org Message-ID: <20120514172946.48f4ed01@localhost> In-Reply-To: References: <20120223155730.20754.45643.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Fwd: I-D Action: draft-pappas-dnsop-long-ttl-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 22:29:54 -0000 On Fri, 2 Mar 2012 09:56:40 -0800 Eric Osterweil wrote: > We have resurrected our draft Improving DNS Service Availability by > Using Long TTL Values, and added some new polish to it. We've taken > some feedback from various people and would love to hear any thoughts > other people have. Hi Eric, I remember this draft from years ago so I'll resurrect and update my comments on the subject as well. I'm not convinced these long TTLs are for everyone , though of course I'm not opposed to it, from an operational perspective I would need to be convinced this is worthwhile. I think ultimately it depends on the operator. There doesn't seem to be much critical analysis in why this might not be desirable. I'll try to offer some. Practically speaking, while caching to avoid transient issues may be highly desirable, you may find that many operators would prefer to build their network to get as many queries as possible even if that leaves that part of the hierarchy at risk when transient issues arise. Queries, even and often especially if unnecessary, have intrinsic intelligence value. In the Introduction there is this sentence: Furthermore, the use of shared unicast introduces one entry in the global BGP routing for every shared unicast enabled server. This is misleading. There may be many unique announcements from each each anycast instance, but each router's global table will use only one as long as the prefix is consistent. Does the deployment of DNSSEC change any of the underlying assumptions? The references used in section two are now quite old. Updated measurement results to ensure they support the recommendations would be nice. After reading section 3.3, I wrote to myself "Such as?" What sorts of changes are you alluding to? This is designed specifically for the root and TLDs, yes? It might be helpful to make this stipulation more clear in the Recommendations section. It seems to me that this may be a useful document to help folks design their own strategy for "infrastructure RRs". I would approach it that way, as an informational guide demonstrating how to do it and why you might want to. I'm not convinced everyone should. At least you've not convinced me yet. :-) For background, this is related: https://lists.dns-oarc.net/pipermail/dns-operations/2006-April/000503.html Note, the concern about uncooperative authoritative DNS servers. Lixia sought comments from the DNS operations community on this topic in 2007 and I followed up offline. I'll include that follow up here for posterity and since it may never have made it to you since it includes the concern mentioned above. Date: Thu, 22 Mar 2007 17:54:05 -0500 From: John Kristoff To: Lixia Zhang Cc: Daniel Massey , Vasileios Pappas , Steve Crocker Subject: Re: [dns-operations] Seeking input regarding TTL value for infrastructure RRs On Wed, 21 Mar 2007 15:13:32 -0700 Lixia Zhang wrote: > Note that in this talk we separate out infrastructure RRs from all > other RRs. > Some people might argue that they dont want long TTL values because > their hosts move around a lot, but we have not directly heard from > anyone saying they moving their DNS servers around on a daily or even > weekly basis. And in fact that might be pretty hard to fully accomplish quickly anyway if there are glue records in some parent zone they don't control. > But as Vasilis reasoned above, if child zone's response overwrites > whatever one learned from the parent zone, then what I said on > slide-9 still holds true, right? i.e. a zone can choose to set long > TTL for its NS+A RRs to make itself more available. There is that damage problem, which I think is going to be a point of contention long term. If a zone owner wants to move their zone and the zone server administrator decides to set a TTL really high, the server administrator can effectively hijack the domain for a long time. This doesn't seem to happen in practice much today, but it could easily become a "lock-in" problem we'd want to avoid. > What John meant here is to be able to move one's DNS servers around > quickly to get around the attack traffic. > > But wouldn't this also require that one have to update the parent > quickly? Can people actually coordinate that well in short time scale? For some parents it should be do-able. > (Vasilis also did a massive measurement on lame delegations, people > don't even seem to be able to fix long term inconsistencies between > parent and child zones :-) Oh yeah, that's a big problem too. Here are a few other areas Of interest I've been looking at. If you want to collaborate on some of this stuff, let me know, I'd love to: open resolvers (fully open, caching only and auth only) EDNS0 max size discrepancies reserved, special and private name leaks cache poisoning vulnerabilities NS RRset size and diversity non-DNS accessible services on nameservers IPv6 records TCP support CNAME RRs used for NS RRs commonly filtered ports blocking queries/responses > and even in this case, long TTL seems still a good way out---one can > extend the concept to host RRs, so the host addresses can be cached > for extended period which mask off the DNS server's unavailability > (as Paul M said 20 years ago) While I think in typical usage this all may be well and good, I think the inability to be flexible in times of stress is again the potential problem. > or if I say in slightly different word: we want to know why people > want short TTL for infrastructure RRs. This I don't know. I suspect laziness or something to do with defaults. > PS: John, I just want to thank you again for your comments on our > PHAS paper last time. We are preparing another talk for next NANOG > on prefix origin checking, a complementary piece to PHAS. Great, will look forward to it. John John From suresh@tislabs.com Fri May 18 11:30:30 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDFD21F87D4 for ; Fri, 18 May 2012 11:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhylgwgszqAM for ; Fri, 18 May 2012 11:30:29 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD2821F87D3 for ; Fri, 18 May 2012 11:30:26 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3355F28B003C for ; Fri, 18 May 2012 14:30:26 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 1FDA01F8032; Fri, 18 May 2012 14:30:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Suresh Krishnaswamy In-Reply-To: <20120413071133.3506.32267.idtracker@ietfa.amsl.com> Date: Fri, 18 May 2012 14:30:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <808B7781-10EB-4CAA-8270-F643D397E745@tislabs.com> References: <20120413071133.3506.32267.idtracker@ietfa.amsl.com> To: dnsop@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 18:30:30 -0000 I'm reading 4641bis after a really long time and the current version = appears useful and very well done. So I'd like to applaud the editors = and working group for bringing this document into such good shape. Leaving aside the nits, here are some of my comments on -11. 3.2.1. Rolling a KSK that is not a trust anchor There are 3 schools of thought on rolling a KSK that is not a trust anchor: o It should be done frequently and regularly (possibly every few months) so that a key rollover remains an operational routine. o It should be done frequently but irregularly. Frequently meaning every few months, again based on the argument that a rollover is a practiced and common operational routine, and irregular meaning with a large jitter, so that 3rd parties do not start to rely on the key and will not be tempted to configure it as a trust anchor. o It should only be done when it is known or strongly suspected that the key can be or has been compromised, or when a new algorithm or key storage is required. SK> I'd add a fourth: o It should be done in conjunction with operator change policies and procedures so that new operators are adequately prepared to = conduct unscheduled key rollover operations should the need arise. ----------------------------- 3.2.2. Rolling a KSK that is a trust anchor ... It is therefore preferred to roll KSKs that are likely to be used as trust anchors on a regular basis if and only if those rollovers can be tracked using standardized (e.g. RFC 5011) mechanisms. SK> The problem with this the above para is that there is no way to verify that the rollovers are being tracked by automated mechanisms. Perhaps the guidance ought to be: Thus, if a KSK is intended to be used as a trust anchor it is advantageous to use an aggressive rolling schedule initially, in order to build confidence in the validating client's ability to track these rollovers on an ongoing basis. ----------------------------- 3.2.3. The use of the SEP flag ... anchor. Therefore, it is suggested that the SEP flag is set on keys that are used as KSKs and not on keys that are used as ZSKs, while in those cases where a distinction between KSK and ZSK is not made (i.e. for a Single Type signing scheme), it is suggested that the SEP flag is set on all keys.=20 Note that signing tools may assume a KSK/ZSK split and use the (non) presence of the SEP flag to determine which key is to be used for signing zone data; these tools may get confused when a single type signing scheme is used. SK> Suggest deleting the second para above and adding the following text = at the end of the first para instead. Similarly, it is suggested that validators configure Trust Anchors for only those keys that have the SEP flag set. Signing tools should not merely use the absence of the SEP flag as the sole discriminator while identifying the Zone Signing Keys within a keyset. ----------------------------- 3.3. Key Effectivity Period ... The motivation for having the ZSK's effectivity period shorter than the KSK's effectivity period is rooted in the operational consideration that it is more likely that operators have more frequent read access to the ZSK than to the KSK. If ZSKs are maintained on cryptographic Hardware Security Modules (HSM), then = the motivation to have different key effectivity periods is weakened. SK> I don't understand the rationale for the above. The effectivity period of the ZSK should have no relation to the number of times it is read (and not even on the number of signatures created using it, as I think I read on this list). Maybe what we want to say here is that In cases where the ZSK cannot be afforded the same level of protection as the KSK (such as when zone keys are kept online), and where the risk of unauthorized disclosure of the ZSK's private key is not negligible (e.g. when HSMs are not in use), the ZSK's effectivity period should be kept shorter than the KSK's effectivity period. ----------------------------- 4.1.2. Key Signing Key Rollovers ... Since only the key set is signed with a KSK, zone size considerations do not apply. SK> However, the number of signatures in the keyset will increase. That is, the response size for the DNSKEY rrset will be slightly larger. ----------------------------- 4.1.3. Difference Between ZSK and KSK Rollovers ... The drawbacks of this scheme are that, during the "new DS" phase, = the parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2 using the DNS -- as DNSKEY_K_2 is not yet published. Besides, we introduce a "security lame" key (see Section 4.3.3). Finally, the child-parent interaction consists of two steps. The "Double Signature" method only needs one interaction. SK> Section 4.2.2 talks about the security lameness "condition" and security lame "zones". What is a security lame "key"? Why is the introduction of a DS record that has no matching KSK in the child zone considered bad (as the above text suggests), given that we have another valid DS->KSK link between the parent and child zones? ----------------------------- 5.3.3. NSEC3 Salt ... However, unlike Zone Signing Key changes, NSEC3 salt changes do not need special rollover procedures. It is possible to change the salt each time the zone is updated. SK> There was a recent suggestion that NSEC3 salt changes also had certain timing dependencies because of the need to keep the NSEC3PARAM record consistent during this process. Is that a valid concern, and one = that must be reflected in this document? Thanks! Suresh From paul.hoffman@vpnc.org Fri May 18 11:59:30 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E7A21F8710 for ; Fri, 18 May 2012 11:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.7 X-Spam-Level: X-Spam-Status: No, score=-99.7 tagged_above=-999 required=5 tests=[AWL=-0.300, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSHjI9Lgqy93 for ; Fri, 18 May 2012 11:59:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BEA3321F86E5 for ; Fri, 18 May 2012 11:59:22 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4IIxLbc059315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 18 May 2012 11:59:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: <808B7781-10EB-4CAA-8270-F643D397E745@tislabs.com> Date: Fri, 18 May 2012 11:59:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120413071133.3506.32267.idtracker@ietfa.amsl.com> <808B7781-10EB-4CAA-8270-F643D397E745@tislabs.com> To: "dnsop@ietf.org WG" X-Mailer: Apple Mail (2.1278) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 18:59:30 -0000 On May 18, 2012, at 11:30 AM, Suresh Krishnaswamy wrote: > I'm reading 4641bis after a really long time and the current version = appears useful and very well done. So I'd like to applaud the editors = and working group for bringing this document into such good shape. >=20 > Leaving aside the nits, here are some of my comments on -11. >=20 >=20 > 3.2.1. Rolling a KSK that is not a trust anchor > There are 3 schools of thought on rolling a KSK that is not a trust > anchor: >=20 > o It should be done frequently and regularly (possibly every few > months) so that a key rollover remains an operational routine. >=20 > o It should be done frequently but irregularly. Frequently meaning > every few months, again based on the argument that a rollover is = a > practiced and common operational routine, and irregular meaning > with a large jitter, so that 3rd parties do not start to rely on > the key and will not be tempted to configure it as a trust = anchor. >=20 > o It should only be done when it is known or strongly suspected = that > the key can be or has been compromised, or when a new algorithm = or > key storage is required. >=20 >=20 > SK> I'd add a fourth: >=20 > o It should be done in conjunction with operator change policies = and > procedures so that new operators are adequately prepared to = conduct > unscheduled key rollover operations should the need arise. This seems like a good addition. It incorporates the ideas that key = rollover procedures need to passed forward to new operators. > ----------------------------- >=20 > 3.2.2. Rolling a KSK that is a trust anchor >=20 > ... >=20 > It is therefore preferred to roll KSKs that are likely to be used = as > trust anchors on a regular basis if and only if those rollovers can > be tracked using standardized (e.g. RFC 5011) mechanisms. >=20 >=20 > SK> The problem with this the above para is that there is no way to > verify that the rollovers are being tracked by automated mechanisms. > Perhaps the guidance ought to be: >=20 > Thus, if a KSK is intended to be used as a trust anchor it is > advantageous to use an aggressive rolling schedule initially, in > order to build confidence in the validating client's ability to = track > these rollovers on an ongoing basis. +1 to this idea. >=20 >=20 > ----------------------------- >=20 >=20 > 3.2.3. The use of the SEP flag >=20 > ... >=20 > anchor. Therefore, it is suggested that the SEP flag is set on keys > that are used as KSKs and not on keys that are used as ZSKs, while = in > those cases where a distinction between KSK and ZSK is not made = (i.e. > for a Single Type signing scheme), it is suggested that the SEP flag > is set on all keys.=20 >=20 > Note that signing tools may assume a KSK/ZSK split and use the (non) > presence of the SEP flag to determine which key is to be used for > signing zone data; these tools may get confused when a single type > signing scheme is used. >=20 >=20 > SK> Suggest deleting the second para above and adding the following = text at the end of the first para instead. >=20 > Similarly, it is suggested that validators configure Trust Anchors > for only those keys that have the SEP flag set. Signing tools = should > not merely use the absence of the SEP flag as the sole discriminator > while identifying the Zone Signing Keys within a keyset. >=20 >=20 > ----------------------------- >=20 >=20 > 3.3. Key Effectivity Period >=20 > ... >=20 > The motivation for having the ZSK's effectivity period shorter than > the KSK's effectivity period is rooted in the operational > consideration that it is more likely that operators have more > frequent read access to the ZSK than to the KSK. If ZSKs are > maintained on cryptographic Hardware Security Modules (HSM), then = the > motivation to have different key effectivity periods is weakened. >=20 > SK> I don't understand the rationale for the above. The effectivity > period of the ZSK should have no relation to the number of times it is > read (and not even on the number of signatures created using it, > as I think I read on this list). Maybe what we want to say here is = that >=20 > In cases where the ZSK cannot be afforded the same level of > protection as the KSK (such as when zone keys are kept online), and > where the risk of unauthorized disclosure of the ZSK's private key > is not negligible (e.g. when HSMs are not in use), the ZSK's > effectivity period should be kept shorter than the KSK's effectivity > period. This circles back to the permathread on why even have a split between = the two types. If an operator needs to read a key, they need to read a = key. If doing so is dangerous to the sanctity of the key, the operator = has really crappy policies. There is no conceptual reason that reading a = key is dangerous. > ----------------------------- >=20 >=20 > 4.1.2. Key Signing Key Rollovers >=20 > ... >=20 > Since only the key set is signed with a KSK, zone size = considerations > do not apply. >=20 > SK> However, the number of signatures in the keyset will increase. = That > is, the response size for the DNSKEY rrset will be slightly larger. Good point. > ----------------------------- >=20 >=20 > 4.1.3. Difference Between ZSK and KSK Rollovers >=20 > ... >=20 > The drawbacks of this scheme are that, during the "new DS" phase, = the > parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2 > using the DNS -- as DNSKEY_K_2 is not yet published. Besides, we > introduce a "security lame" key (see Section 4.3.3). Finally, the > child-parent interaction consists of two steps. The "Double > Signature" method only needs one interaction. >=20 >=20 > SK> Section 4.2.2 talks about the security lameness "condition" and > security lame "zones". What is a security lame "key"? Why is the > introduction of a DS record that has no matching KSK in the child zone > considered bad (as the above text suggests), given that we have = another > valid DS->KSK link between the parent and child zones? >=20 > ----------------------------- >=20 >=20 > 5.3.3. NSEC3 Salt >=20 > ... >=20 > However, unlike Zone Signing > Key changes, NSEC3 salt changes do not need special rollover > procedures. It is possible to change the salt each time the zone = is > updated. >=20 > SK> There was a recent suggestion that NSEC3 salt changes also had > certain timing dependencies because of the need to keep the NSEC3PARAM > record consistent during this process. Is that a valid concern, and = one that > must be reflected in this document? Given the lack of discussion, NSEC3 salt should be considered outside = this document. --Paul Hoffman From olaf@NLnetLabs.nl Mon May 21 02:41:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC66921F85C3 for ; Mon, 21 May 2012 02:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.109 X-Spam-Level: X-Spam-Status: No, score=-101.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-aRgJb397Zd for ; Mon, 21 May 2012 02:41:15 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3D621F8546 for ; Mon, 21 May 2012 02:41:14 -0700 (PDT) Received: from ip212-238-54-225.hotspotsvankpn.com (ip212-238-54-225.hotspotsvankpn.com [212.238.54.225]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q4L9ed7C074705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 May 2012 11:40:40 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1337593273; bh=SJEbr8NYoXzjGBwXKf5Qs1yKEIvbZHc+8/Wu8qIXOHI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=SiK2t9EOSPrnHSSIZ1JcnPOjQ9d5QuP64QvhUu7/Nc1316IT+B0+jssfZ1OBO9a79 HfpATq6jkxqDZAPx5/keWZqa3SyrRH7w03MItvXXlmlmZ/AGRQnHTYbckmG+z3edGg hwThzTsjoeKVGEaDOzJQNBSSMVkwUWxdFgQnm83M= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_EDF92B47-9D5E-4E13-BCAA-5906738BD212"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Olaf Kolkman In-Reply-To: <808B7781-10EB-4CAA-8270-F643D397E745@tislabs.com> Date: Mon, 21 May 2012 11:40:23 +0200 Message-Id: References: <20120413071133.3506.32267.idtracker@ietfa.amsl.com> <808B7781-10EB-4CAA-8270-F643D397E745@tislabs.com> To: Suresh Krishnaswamy X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Mon, 21 May 2012 11:40:41 +0200 (CEST) Cc: "dnsop@ietf.org WG" , Matthijs Mekking Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 09:41:16 -0000 --Apple-Mail=_EDF92B47-9D5E-4E13-BCAA-5906738BD212 Content-Type: multipart/alternative; boundary="Apple-Mail=_6023B808-1C5A-434A-9122-3E048BC528AF" --Apple-Mail=_6023B808-1C5A-434A-9122-3E048BC528AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 18, 2012, at 8:30 PM, Suresh Krishnaswamy wrote: > I'm reading 4641bis after a really long time and the current version = appears useful and very well done. So I'd like to applaud the editors = and working group for bringing this document into such good shape. >=20 > Leaving aside the nits, here are some of my comments on -11. Suresh, Thanks you for the comments, and Paul for the followup.=20 They are very timely since the DNSOP chairs are currently scheduling = time to review the document after the last call for this document closed = about a year ago. Chairs, would you like us to incorporate (some of, see comments from = Paul H.) the suggestions in the document _now_ or after you have done = your review? Can you please make sure this document is at the IESG before June?=20 --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_6023B808-1C5A-434A-9122-3E048BC528AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I'm reading 4641bis after a really long time and the = current version appears useful and very well done. So I'd like to = applaud the editors and working group for bringing this document into = such good shape.

Leaving aside the nits, here are some of my = comments on = -11.

Suresh,
<serious>
Thanks you for the comments, and = Paul for the = followup. 
</serious>

<sa= rcasm>
They are very timely since the DNSOP chairs are = currently scheduling time to review the document after the last call for = this document closed about a year = ago.
</sarcasm>

<se= rious>
Chairs, would you like us to incorporate (some of, = see comments from Paul H.) the suggestions in the document _now_ or = after you have done your review?

Can you please = make sure this document is at the IESG before = June? 

</serious>

=

--Olaf





Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_6023B808-1C5A-434A-9122-3E048BC528AF-- --Apple-Mail=_EDF92B47-9D5E-4E13-BCAA-5906738BD212 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJPug2HAAoJEFRqER47aqpknxYP/ihgQeKedyUr6921h6C8auxV fq2XdHVm6o5pXghtMOl0ygsMLRQF9xDX6MS53IS+oqDUeBmHM5nZalc4q7kYxf7h Hc6vKcAR/BYV2f+eWKClB/a3tnn/iJgFJTYIArL/rYJsp81ZzOeyEK8Kh/VjcZiH +mJ7irpMhBRNqvyK7rZpDb1xD5fTlEVgW/IWQp+g1IL+27T1KvjSAj1lE8aq3oOo V85RGpRYDDoJnKgsUf33+h1O60dySedEVzNF01K9FfgW4BDNK+wD/a8tuK1lugAY Am1l5WWJeS3RsAY0/gVo8u3sdjm1Xu4dcG/WEWROaKv0aH0GMKDORlCuH+E6TkUu 4oNMW3xYwvjbG/Zt63umqrIqvZhnc45hGy8l+URoircDoEZYwhXVCNB6R2bd650f EEvp/Q9tMliJCEsYQ/E46hr+PRi58bTBq2G17m78SUhiTKtDzAl56cLpCyfN1/c/ D6PYqpCoFGOpRuIwJr6D2iLVNGsR3uXu594ErYoxv0zyc+JdMAuQp0HBUiq7wkI4 kDexGFcFGjxI3F+jSzXz3zAdWGJfShVhGHPyfj4O8G9WOuReqTSOesrVLXV3wvgJ PPqasgDz2ozx5FDC4OE1yxxBux8Mzwh/lHZEfc8xvvblO0qfgak6NTQvS/WUkgdn XFYl8rA1gPKApoAWKaTg =AWSJ -----END PGP SIGNATURE----- --Apple-Mail=_EDF92B47-9D5E-4E13-BCAA-5906738BD212-- From matthijs@nlnetlabs.nl Mon May 21 02:44:02 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A76321F8622 for ; Mon, 21 May 2012 02:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.986 X-Spam-Level: X-Spam-Status: No, score=-98.986 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_41=0.6, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymtbPiwIl7tN for ; Mon, 21 May 2012 02:44:01 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 070A921F8623 for ; Mon, 21 May 2012 02:44:00 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:ecf3:55f:59b3:876f] ([IPv6:2001:7b8:206:1:ecf3:55f:59b3:876f]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q4L9hwtf081831; Mon, 21 May 2012 11:43:59 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1337593440; bh=wlw/dDXNB62x2wasQZUyeBKACGqO4w1BsGAdufFizrQ=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=UOnthxxzm8tFMt1+Yoz43whwlBdl0mo0DIIp+ofCSRKDvOYt36L8bm2faG3AiqsWM XWQxckQHmHCdh3GbJJINk8OAGlQNTstW0x/Y08WhY3Ptf9Yxucze0NQON4L4GwK4jc W/K78DTXfMWvlr6fQ3f9lUFlqrpbn4A/Tph/61nE= Message-ID: <4FBA0E5E.6080007@nlnetlabs.nl> Date: Mon, 21 May 2012 11:43:58 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Suresh Krishnaswamy References: <20120413071133.3506.32267.idtracker@ietfa.amsl.com> <808B7781-10EB-4CAA-8270-F643D397E745@tislabs.com> In-Reply-To: <808B7781-10EB-4CAA-8270-F643D397E745@tislabs.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 21 May 2012 11:43:59 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 09:44:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Suresh, Thanks for your review. I have commented on your feedback in between lines. However, I am not planning on any action now. I have lost confidence in that this document will ever move forward. The WGLC for this document was June 2011, should this really take so long? So I like to see some action that gives me some confidence that I am not working on an abide document. Best regards, Matthijs On 05/18/2012 08:30 PM, Suresh Krishnaswamy wrote: > I'm reading 4641bis after a really long time and the current > version appears useful and very well done. So I'd like to applaud > the editors and working group for bringing this document into such > good shape. > > Leaving aside the nits, here are some of my comments on -11. > > > 3.2.1. Rolling a KSK that is not a trust anchor There are 3 > schools of thought on rolling a KSK that is not a trust anchor: > > o It should be done frequently and regularly (possibly every few > months) so that a key rollover remains an operational routine. > > o It should be done frequently but irregularly. Frequently > meaning every few months, again based on the argument that a > rollover is a practiced and common operational routine, and > irregular meaning with a large jitter, so that 3rd parties do not > start to rely on the key and will not be tempted to configure it > as a trust anchor. > > o It should only be done when it is known or strongly suspected > that the key can be or has been compromised, or when a new > algorithm or key storage is required. > > > SK> I'd add a fourth: > > o It should be done in conjunction with operator change policies > and procedures so that new operators are adequately prepared to > conduct unscheduled key rollover operations should the need arise. This paragraph (3.2.1) is to summarize the two camps in the discussion whether to roll a key because of operational concerns or to roll a key because of cryptographically concerns. The second bullet point already is somewhat a compromise between the two, taking into account that (new) operators are prepared for unscheduled key rollovers. The third bullet point also covers changing policies and procedures ("when a new algorithm or key storage is required"). I am not in favor of adding the fourth bullet point. The first two bullet points already cover the methods to prepare (new) operators to conduct key rollovers, unscheduled or scheduled. The third bullet point covers changes in policies and procedures, but maybe we could change its text to: o It should only be done when it is known or strongly suspected that the key can be or has been compromised, or in conjunction with operator change policies and procedures, like when a new algorithm or key storage is required. > ----------------------------- > > 3.2.2. Rolling a KSK that is a trust anchor > > ... > > It is therefore preferred to roll KSKs that are likely to be used > as trust anchors on a regular basis if and only if those rollovers > can be tracked using standardized (e.g. RFC 5011) mechanisms. > > > SK> The problem with this the above para is that there is no way to > verify that the rollovers are being tracked by automated > mechanisms. Perhaps the guidance ought to be: > > Thus, if a KSK is intended to be used as a trust anchor it is > advantageous to use an aggressive rolling schedule initially, in > order to build confidence in the validating client's ability to > track these rollovers on an ongoing basis. > In the second paragraph of this section, the document states that "it is expected that the zone administrators are aware of such circumstances." Such circumstances being the zone's keys are used as trust anchor. So I think the current text is okay. We could clarify it by replacing likely with expected: vvvvvvvv It is therefore preferred to roll KSKs that are expected to be used as trust anchors on a regular basis if and only if those rollovers can be tracked using standardized (e.g. RFC 5011) mechanisms. > > ----------------------------- > > > 3.2.3. The use of the SEP flag > > ... > > anchor. Therefore, it is suggested that the SEP flag is set on > keys that are used as KSKs and not on keys that are used as ZSKs, > while in those cases where a distinction between KSK and ZSK is > not made (i.e. for a Single Type signing scheme), it is suggested > that the SEP flag is set on all keys. > > Note that signing tools may assume a KSK/ZSK split and use the > (non) presence of the SEP flag to determine which key is to be > used for signing zone data; these tools may get confused when a > single type signing scheme is used. > > > SK> Suggest deleting the second para above and adding the > following text at the end of the first para instead. > > Similarly, it is suggested that validators configure Trust Anchors > for only those keys that have the SEP flag set. Signing tools > should not merely use the absence of the SEP flag as the sole > discriminator while identifying the Zone Signing Keys within a > keyset. While I agree with the paragraph, I don't think it is appropriate to include into 4641bis. First, the document is targeted at the zone administrators, not resolver operators. In other words, I think it should not make considerations regarding validators. Second, the text about signing tools is not that different from the text in -11. Only your text makes a recommendation for signing tools developers, while the text in -11 warns about the assumptions signing tools make with respect to the SEP bit. I think, given the targeted audience of the document, the latter is more appropriate. > ----------------------------- > > > 3.3. Key Effectivity Period > > ... > > The motivation for having the ZSK's effectivity period shorter than > the KSK's effectivity period is rooted in the operational > consideration that it is more likely that operators have more > frequent read access to the ZSK than to the KSK. If ZSKs are > maintained on cryptographic Hardware Security Modules (HSM), then > the motivation to have different key effectivity periods is > weakened. > > SK> I don't understand the rationale for the above. The effectivity > period of the ZSK should have no relation to the number of times it > is read (and not even on the number of signatures created using it, > as I think I read on this list). Maybe what we want to say here is > that > > In cases where the ZSK cannot be afforded the same level of > protection as the KSK (such as when zone keys are kept online), and > where the risk of unauthorized disclosure of the ZSK's private key > is not negligible (e.g. when HSMs are not in use), the ZSK's > effectivity period should be kept shorter than the KSK's > effectivity period. > I think we say the same here, but to be honest: I think your text is more precise (although it neglects the rooted motivation for the different effectivity periods between ZSK and KSK, I don't think that is an issue). > ----------------------------- > > > 4.1.2. Key Signing Key Rollovers > > ... > > Since only the key set is signed with a KSK, zone size > considerations do not apply. > > SK> However, the number of signatures in the keyset will increase. > That is, the response size for the DNSKEY rrset will be slightly > larger. True. > ----------------------------- > > > 4.1.3. Difference Between ZSK and KSK Rollovers > > ... > > The drawbacks of this scheme are that, during the "new DS" phase, > the parent cannot verify the match between the DS_K_2 RR and > DNSKEY_K_2 using the DNS -- as DNSKEY_K_2 is not yet published. > Besides, we introduce a "security lame" key (see Section 4.3.3). > Finally, the child-parent interaction consists of two steps. The > "Double Signature" method only needs one interaction. > > > SK> Section 4.2.2 talks about the security lameness "condition" and > security lame "zones". What is a security lame "key"? Why is the > introduction of a DS record that has no matching KSK in the child > zone considered bad (as the above text suggests), given that we > have another valid DS->KSK link between the parent and child > zones? I assume you mean Section 4.3.3. A key is security lame, if the corresponding DS is published, but its DNSKEY record not. Security lameness is not necessarily bad, only if all keys are security lame (as said in the text and as you also suggest). It happens if you conduct a Double-DS rollover. However, you do not benefit from security lameness, and validators have more options to try to build the chain of trust and if they try the lame keys first, the do more work. > > ----------------------------- > > > 5.3.3. NSEC3 Salt > > ... > > However, unlike Zone Signing Key changes, NSEC3 salt changes do > not need special rollover procedures. It is possible to change > the salt each time the zone is updated. > > SK> There was a recent suggestion that NSEC3 salt changes also had > certain timing dependencies because of the need to keep the > NSEC3PARAM record consistent during this process. Is that a valid > concern, and one that must be reflected in this document? I don't understand 'this process'. What process? The way I see it, they are tight to the serial. Each version of a zone needs to have a complete chain of NSEC3s and corresponding NSEC3PARAM. So they are consistent with the serial. So you could change it every zone change and secondaries are able to construct valid NSEC3 responses, regardless if they are in sync with the master or not. > > > > Thanks! Suresh > > > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPug5eAAoJEA8yVCPsQCW5n48IAJ7xIgRBIqHUGnAx8eZkkeo1 nu/UFjnw19Swk46Yp9qn/M5YBFSvQ+WWh1SqooJWVApyCk3+chZTlRGw3DOp2TO/ z1KNTAwncA+cQFjPyV/eEXC8cOoviXr3BKSVgsXpr03nsQPFWkY5n54fPUmJlRBa PeU6ZBOiKxIzBjd2AiOIWd/WUvpcvM79m7d2Uk3mVYaEB6kVBK6/9xit7JE4S92A njgRMkyMVYAUYGYErLBaOXulckmdR/UWxZihQ66qfVg0RQcb1TvpUvH4Xm78XEBY RQLQZJQlC0ZrNOPsnumRtlsImLM6E2qCTwA3z09eGwEKJ7JGFR17B0ALbI6cuB0= =HKUX -----END PGP SIGNATURE----- From sa.morris7@googlemail.com Mon May 21 07:52:10 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03E721F8597 for ; Mon, 21 May 2012 07:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdI8sOMt84IL for ; Mon, 21 May 2012 07:52:10 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED2D321F84D8 for ; Mon, 21 May 2012 07:52:09 -0700 (PDT) Received: by bkty8 with SMTP id y8so4896111bkt.31 for ; Mon, 21 May 2012 07:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=+t6qxElBynS4aEeszwBMRRs0hcApUFQvWsa73+r+m/o=; b=WfWFTfr8fkuNFkuqXzTyTOcevL4aym6vefFdJDdsstmvBKaS1evm8hDp3UNW/I/Huk x3CrbS3zTsb4zVdmclDkF7tISeNFSFRTmrP1GUSp7UmypUXOKcKhBp+ela7kpY7pMuiz D4DJQmYDEqZB2v88AffedXM1/8juEMUrGYXXyPaduis//rOP3UAybT//Ws/5X7QPr7Ya N/9WYGAMxt42v3eG5RJo7yWyoMrg1bAevC0ksNGhu7KnSpyh4hlb4WUPa64sl55Q6oF2 Rtk4LqvBHYma7EZBmDDfkwkkqtlf6PiBU7nPJUe7PkyCrKGLPD3yUunR2E6xqvtuXoWj Mh/A== Received: by 10.204.157.144 with SMTP id b16mr8168679bkx.12.1337611928974; Mon, 21 May 2012 07:52:08 -0700 (PDT) Received: from [192.168.1.101] ([217.155.47.50]) by mx.google.com with ESMTPS id n19sm27729799bkv.14.2012.05.21.07.52.07 (version=SSLv3 cipher=OTHER); Mon, 21 May 2012 07:52:08 -0700 (PDT) Message-ID: <4FBA5696.60908@googlemail.com> Date: Mon, 21 May 2012 15:52:06 +0100 From: Stephen Morris User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: dnsop@ietf.org X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [DNSOP] draft-ietf-dnsop-dnssec-dps-framework-07 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 14:52:10 -0000 I've been doing a final nits review of the DPS framework document while doing the proto write-up. There is nothing major - mainly typos/missing commas and minor change of wording: these I've passed to editors directly. The only significant issue is the definition of "relying parties" in 1.1 either "users of the DNS" (at the beginning of the section) or "all entities relying on signed responses from the DNS" (at the end, and in the glossary). This needs clarification as "relying party" is used in the middle of that section. Stephen From olaf@NLnetLabs.nl Mon May 21 16:35:20 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76F121F84DD for ; Mon, 21 May 2012 16:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.606 X-Spam-Level: X-Spam-Status: No, score=-101.606 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THLl9dibuI4J for ; Mon, 21 May 2012 16:35:20 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DC621F8554 for ; Mon, 21 May 2012 16:35:19 -0700 (PDT) Received: from [192.168.10.243] (static-76-160-17-94.dsl.cavtel.net [76.160.17.94]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q4LNYbEc060085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 May 2012 01:34:41 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1337643318; bh=SJEbr8NYoXzjGBwXKf5Qs1yKEIvbZHc+8/Wu8qIXOHI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=fQkBzDfkiIudxQU+L5+sTTEtU2GrRVtGgvpjs36GyVER2If8No2nEzCf+elnhjwIP S+1Oz21m78hJGk0qF3pF3mTBpq8k+oSG73U7LO7jyVhNDVD1PCqs4XreuMZoVSD8Ui mgQ9Na/l1TpH+xhsdHs+Zv1ZaA9lCUe/dtdRJ4Lg= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_EDF92B47-9D5E-4E13-BCAA-5906738BD212"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Olaf Kolkman In-Reply-To: <808B7781-10EB-4CAA-8270-F643D397E745@tislabs.com> Date: Mon, 21 May 2012 11:40:23 +0200 Message-Id: References: <20120413071133.3506.32267.idtracker@ietfa.amsl.com> <808B7781-10EB-4CAA-8270-F643D397E745@tislabs.com> To: Suresh Krishnaswamy X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Tue, 22 May 2012 01:34:42 +0200 (CEST) Cc: "dnsop@ietf.org WG" , Matthijs Mekking Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 23:35:21 -0000 --Apple-Mail=_EDF92B47-9D5E-4E13-BCAA-5906738BD212 Content-Type: multipart/alternative; boundary="Apple-Mail=_6023B808-1C5A-434A-9122-3E048BC528AF" --Apple-Mail=_6023B808-1C5A-434A-9122-3E048BC528AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 18, 2012, at 8:30 PM, Suresh Krishnaswamy wrote: > I'm reading 4641bis after a really long time and the current version = appears useful and very well done. So I'd like to applaud the editors = and working group for bringing this document into such good shape. >=20 > Leaving aside the nits, here are some of my comments on -11. Suresh, Thanks you for the comments, and Paul for the followup.=20 They are very timely since the DNSOP chairs are currently scheduling = time to review the document after the last call for this document closed = about a year ago. Chairs, would you like us to incorporate (some of, see comments from = Paul H.) the suggestions in the document _now_ or after you have done = your review? Can you please make sure this document is at the IESG before June?=20 --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_6023B808-1C5A-434A-9122-3E048BC528AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I'm reading 4641bis after a really long time and the = current version appears useful and very well done. So I'd like to = applaud the editors and working group for bringing this document into = such good shape.

Leaving aside the nits, here are some of my = comments on = -11.

Suresh,
<serious>
Thanks you for the comments, and = Paul for the = followup. 
</serious>

<sa= rcasm>
They are very timely since the DNSOP chairs are = currently scheduling time to review the document after the last call for = this document closed about a year = ago.
</sarcasm>

<se= rious>
Chairs, would you like us to incorporate (some of, = see comments from Paul H.) the suggestions in the document _now_ or = after you have done your review?

Can you please = make sure this document is at the IESG before = June? 

</serious>

=

--Olaf





Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_6023B808-1C5A-434A-9122-3E048BC528AF-- --Apple-Mail=_EDF92B47-9D5E-4E13-BCAA-5906738BD212 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJPug2HAAoJEFRqER47aqpknxYP/ihgQeKedyUr6921h6C8auxV fq2XdHVm6o5pXghtMOl0ygsMLRQF9xDX6MS53IS+oqDUeBmHM5nZalc4q7kYxf7h Hc6vKcAR/BYV2f+eWKClB/a3tnn/iJgFJTYIArL/rYJsp81ZzOeyEK8Kh/VjcZiH +mJ7irpMhBRNqvyK7rZpDb1xD5fTlEVgW/IWQp+g1IL+27T1KvjSAj1lE8aq3oOo V85RGpRYDDoJnKgsUf33+h1O60dySedEVzNF01K9FfgW4BDNK+wD/a8tuK1lugAY Am1l5WWJeS3RsAY0/gVo8u3sdjm1Xu4dcG/WEWROaKv0aH0GMKDORlCuH+E6TkUu 4oNMW3xYwvjbG/Zt63umqrIqvZhnc45hGy8l+URoircDoEZYwhXVCNB6R2bd650f EEvp/Q9tMliJCEsYQ/E46hr+PRi58bTBq2G17m78SUhiTKtDzAl56cLpCyfN1/c/ D6PYqpCoFGOpRuIwJr6D2iLVNGsR3uXu594ErYoxv0zyc+JdMAuQp0HBUiq7wkI4 kDexGFcFGjxI3F+jSzXz3zAdWGJfShVhGHPyfj4O8G9WOuReqTSOesrVLXV3wvgJ PPqasgDz2ozx5FDC4OE1yxxBux8Mzwh/lHZEfc8xvvblO0qfgak6NTQvS/WUkgdn XFYl8rA1gPKApoAWKaTg =AWSJ -----END PGP SIGNATURE----- --Apple-Mail=_EDF92B47-9D5E-4E13-BCAA-5906738BD212-- From Ed.Lewis@neustar.biz Tue May 22 08:00:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222E221F85E5 for ; Tue, 22 May 2012 08:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.14 X-Spam-Level: X-Spam-Status: No, score=-104.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIKajlIdKzB6 for ; Tue, 22 May 2012 08:00:07 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4933821F85F9 for ; Tue, 22 May 2012 08:00:07 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q4MF03bh065903; Tue, 22 May 2012 11:00:04 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.132] by Work-Laptop-2.local (PGP Universal service); Tue, 22 May 2012 10:00:04 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 22 May 2012 10:00:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120509222503.12175.33951.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2012 10:00:00 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-respsize-14.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 15:00:08 -0000 I looked back at this and noticed I should have said "the right matrix" is more important. Still, I'm a little surprised there's been no response from a comparison of a DNS Operations WG document to real-world measurements. Are we okay with a document that issues criteria that only 70% of TLDs fall into "green?" Are the grades overly harsh? Should the TLDs be urged to work on getting to green? At 13:55 -0400 5/10/12, Edward Lewis wrote: >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-14.txt > >For kicks I ran the included perl code against the 313 delegations >from the root zone (313 does not include "root" and does include the >11 test TLDs). > >...I'll leave it to the draft to explain the headings and rankings >below. I did this just to measure the draft's assessments against >the TLD settings. Not that the TLDs are the only audience of this >draft, but it's a convenient data set. > >Measured in %'ages of 313: > > Max length domain name || Average length domain name >Color A-only A+AAAA A-preferred || A-only A+AAAA A-preferred > || >Green 59% 19% 19% || 99% 69% 69% >Yellow 35% 41% 18% || 1% 31% 28% >Orange 4% 21% 9% || 1% >Red 2% 11% 53% || 2% > >The left matrix is more important (operationally). That's about >the only commentary I'll add, just to head off the concern of "red"s >in the right matrix. > >To Paul and Akira, here's more or less what I did with the results of the pl: > >looping through the names in the root zone: > server_set=`dig @127.0.0.1 +short $name ns` > size_estimate=`perl respsize.pl $server_set` > results=`echo $size_estimate | sed "getting '()'s#$name \2 \3 \4 >\6 \7 \8#"` > echo "$results" >and then used a spreadsheet to do the percentages. (Shown in case I >messed up something.) >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis >NeuStar You can leave a voice message at +1-571-434-5468 > >2012...time to reuse those 1984 calendars! >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From warren@kumari.net Wed May 30 13:41:10 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22ED21F871A for ; Wed, 30 May 2012 13:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pQ19BeZNuqC for ; Wed, 30 May 2012 13:41:10 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 158EA21F8718 for ; Wed, 30 May 2012 13:41:10 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [72.14.227.1]) by vimes.kumari.net (Postfix) with ESMTPSA id B35711B40653 for ; Wed, 30 May 2012 16:41:09 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 30 May 2012 16:41:08 -0400 References: <20120530190859.14954.46105.idtracker@ietfa.amsl.com> To: dnsop@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-omniscient-as112-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 20:41:10 -0000 Hi there all, A while back there was a bunch of discussion around how to delegate / = undelegate space to as112 nodes, and the issues with co-ordination. This draft provides a mechanism for making this process less painful -- = any feedback would be greatly appreciated=85 This is also being discussed on the as112 lists=85 W Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-wkumari-dnsop-omniscient-as112-00.txt > Date: May 30, 2012 3:08:59 PM EDT > To: warren@kumari.net > Cc: wfms@ryouko.imsb.nrc.ca, joe.abley@icann.org >=20 > A new version of I-D, draft-wkumari-dnsop-omniscient-as112-00.txt has = been successfully submitted by Warren Kumari and posted to the IETF = repository. >=20 > Filename: draft-wkumari-dnsop-omniscient-as112 > Revision: 00 > Title: Omniscient AS112 Servers > Creation date: 2012-05-30 > WG ID: Individual Submission > Number of pages: 12 >=20 > Abstract: > The AS112 Project loosely coordinates Domain Name System (DNS) > servers to which DNS zones corresponding to private use addresses = are > delegated. Queries for names within those zones have no useful > responses in a global context. The purpose of the project is to > reduce the load of such junk queries on the authoritative name > servers that would otherwise receive them, directing the load = instead > to name servers operated within the AS112 project. >=20 > Adding and dropping zones from the AS112 servers is difficult, due = to > the loosely-coordinated nature of the project. This document > proposes a mechanism by which AS112 name servers could answer > authoritatively for all possible zones, reducing the add/drop = problem > to one of delegation within the DNS without operational impact on = the > servers themselves. >=20 > This document updates RFC 6304. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From bortzmeyer@nic.fr Wed May 30 23:51:38 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EE121F85CE for ; Wed, 30 May 2012 23:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2iav3rDlbaJ for ; Wed, 30 May 2012 23:51:37 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 3A81A21F85CC for ; Wed, 30 May 2012 23:51:36 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 8EA123B43B; Thu, 31 May 2012 06:51:35 +0000 (UTC) Received: by tyrion (Postfix, from userid 1000) id F079EF00579; Thu, 31 May 2012 08:12:12 +0200 (CEST) Date: Thu, 31 May 2012 08:12:12 +0200 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20120531061212.GA11308@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Ubuntu 12.04 (precise) User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [DNSOP] MIME type for zone files? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 06:51:38 -0000 I have a REST application which sends zone files (master zone file format, RFC 1035). Is there a MIME type for this? I do not find it in IANA registry. text/plain is too... plain. text/x-zonefile is deprecated by the RFC-to-be "draft-ietf-appsawg-xdash", which suggests something like text/afnic-fr-zonefile. From marka@isc.org Thu May 31 00:41:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6535921F85CF for ; Thu, 31 May 2012 00:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwKqS6+hn8sP for ; Thu, 31 May 2012 00:41:07 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id CADC021F85CE for ; Thu, 31 May 2012 00:41:06 -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)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 95DB35F99EF; Thu, 31 May 2012 07:40:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b1d0:6c12:e098:f5d4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 452BC216C33; Thu, 31 May 2012 07:40:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6A072211AFC7; Thu, 31 May 2012 17:40:44 +1000 (EST) To: Stephane Bortzmeyer From: Mark Andrews References: <20120531061212.GA11308@laperouse.bortzmeyer.org> In-reply-to: Your message of "Thu, 31 May 2012 08:12:12 +0200." <20120531061212.GA11308@laperouse.bortzmeyer.org> Date: Thu, 31 May 2012 17:40:43 +1000 Message-Id: <20120531074044.6A072211AFC7@drugs.dv.isc.org> Cc: dnsop@ietf.org Subject: Re: [DNSOP] MIME type for zone files? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 07:41:07 -0000 In message <20120531061212.GA11308@laperouse.bortzmeyer.org>, Stephane Bortzmey er writes: > I have a REST application which sends zone files (master zone file > format, RFC 1035). Is there a MIME type for this? I do not find it in > IANA registry. text/plain is too... plain. text/x-zonefile is > deprecated by the RFC-to-be "draft-ietf-appsawg-xdash", which suggests > something like text/afnic-fr-zonefile. Not that I'm aware of. You could always apply for a mime type. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@resistor.net Thu May 31 07:50:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8635321F86A0 for ; Thu, 31 May 2012 07:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec2b5uUzTLtK for ; Thu, 31 May 2012 07:50:07 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F06321F863B for ; Thu, 31 May 2012 07:50:07 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4VEnx13023045; Thu, 31 May 2012 07:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338475805; i=@resistor.net; bh=39qDB/KUThiffYJNj26PzadQY2xUk9sNshSXL7w/zQc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1Vt4gfL6LO5DKMot14P1OoKSMDcV0r1N0dbXRvDOqGD2vHwD6/ukMP6AAJEOXHwC4 KUpU4J1BUnxQD9YWpxuRp4qAFw8wxXkKDcVgokX2QsPx4QhO2xM9APZ1wz7htpyfq0 ePKroTm7F028+yNU56HOJk8hRdDIKjzbH/bqxuLY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1338475805; i=@resistor.net; bh=39qDB/KUThiffYJNj26PzadQY2xUk9sNshSXL7w/zQc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=i54jC4HTcqMic/jxqmRRDUdiF63YI/0cQL/OA4Ph8F83fwa82G1lPFYiBrm9vflG0 oZ1dTR4MY24ASGr+4sEpdkpUXXPLHVVOg/P0Dhsw4VzJq/FukpTmkEsxUTIEQVV5AE P5zFmlbpOI1+eMVJGhUvmCrbA3AuxDn6Ij4WS8Og= Message-Id: <6.2.5.6.2.20120531074546.098849d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 31 May 2012 07:48:49 -0700 To: Stephane Bortzmeyer From: SM In-Reply-To: <20120531061212.GA11308@laperouse.bortzmeyer.org> References: <20120531061212.GA11308@laperouse.bortzmeyer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] MIME type for zone files? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:50:09 -0000 Hi Stephane, At 23:12 30-05-2012, Stephane Bortzmeyer wrote: >I have a REST application which sends zone files (master zone file >format, RFC 1035). Is there a MIME type for this? I do not find it in >IANA registry. text/plain is too... plain. text/x-zonefile is See RFC 4027 for application/dns and text/dns. Regards, -sm From joe.gersch@secure64.com Thu May 31 14:51:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3842321F864C for ; Thu, 31 May 2012 14:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYuyrkhl96lu for ; Thu, 31 May 2012 14:51:07 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 23C0E21F864A for ; Thu, 31 May 2012 14:51:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 8F04EB8652; Thu, 31 May 2012 15:51:06 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KjDhxsKQEGb; Thu, 31 May 2012 15:51:05 -0600 (MDT) Received: from [129.82.138.211] (unknown [129.82.138.211]) by zimbra.secure64.com (Postfix) with ESMTPSA id 128C2B84E2; Thu, 31 May 2012 15:51:05 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1338501065; bh=KQvrhEFnt1+k7+CjGZVIBlshb/ecInaghsWsqxbKZJw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Us7eHTh9kTR9 xYWTsPS2J5wkXBZCRj4ZmhArBaYWJJ6QTi5ak5+nRkc9GwbCE3+v6l18ezIxblDOKTc 4vaevYKE57XtK180b+xOTe74akHM7U+TuhQuu7Urb0lffh4dlBqnnO7r+S9a/Q8RE/Y FIDTQs3kd7kboIKRWxCUxG8+Y= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Joseph Gersch In-Reply-To: <2C012FE1-A40D-473F-89D8-52673182A581@nominet.org.uk> Date: Thu, 31 May 2012 15:51:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120217000918.22307.43753.idtracker@ietfa.amsl.com> <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> <017101ccefd5$51790560$f46b1020$@lampo@eurid.eu> <2C012FE1-A40D-473F-89D8-52673182A581@nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1257) Cc: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= , "dnsop@ietf.org" Subject: Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 21:51:08 -0000 Ray and Ondrej,=20 Dan Massey and I have been busy putting together a presentation for = NANOG which is in Vancouver next week. We plan on having many = discussions with operators and designers there. After we get enough = feedback, we will get back to you. I know this is later than you = wanted, but we want to get good discussion first.=20 - Joe On Mar 30, 2012, at 4:19 AM, Ray Bellis wrote: >=20 > On 30 Mar 2012, at 12:09, Ond=C5=99ej Sur=C3=BD wrote: >=20 >> Hi Joseph, >>=20 >> since I am not sure if you understood my point (I am not sure if I = was able >> to understand it myself :), I am summarizing it to the mailing list. >>=20 >> I like the direction of your work, but I miss a way how to put more = stuff under >> the named prefix. >>=20 >> I would like you to update RFC2317 together with your document, so = the end >> customers don't have two distinct trees in their DNS infrastructure. >=20 > +1 >=20 >> F.e. if I have 1.0.m.82.129.in-addr.arpa prefix in the DNS and I have = delegate >> it to the customer, how do I put my PTRs in? The block owner would = still have >> to delegate another "dummy" prefix with CNAMEs and you have to handle = it in >> separate zone. >>=20 >> BTW one more observation. Since you don't have to do any zone cuts = in the binary >> part, why not merge them into just one label? E.g. something like = 10.m.82.129.in-addr.arpa or 10001101.m.82.129.in-addr.arpa. >=20 > With the current scheme it's possible to delegate longer prefixes, and = this is a necessary feature. >=20 > The stuff Dan was saying about two alternate representations concerns = me, though. As written, by default: >=20 > 192.168.64/18 is 1.0.m.168.192 >=20 > but >=20 > 192.168.64/24 is 64.168.192 >=20 > which is not a sub-domain of the enclosing /18 representation. >=20 > This way lies dragons, I think... >=20 > Ray >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop Joseph Gersch Chief Operating Officer Secure64 Software Corporation