From alex@alex.org.uk Tue Mar 1 01:27:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB103A69CF for ; Tue, 1 Mar 2011 01:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReVptrQUcj42 for ; Tue, 1 Mar 2011 01:27:33 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 4A3EF3A69AD for ; Tue, 1 Mar 2011 01:27:32 -0800 (PST) Received: from [192.168.100.89] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id B0CD1C566C7; Tue, 1 Mar 2011 09:28:32 +0000 (GMT) Date: Tue, 01 Mar 2011 09:28:31 +0000 From: Alex Bligh To: Niall O'Reilly , dnsext@ietf.org Message-ID: <302DAD77E927757D3DEA05DF@nimrod.local> In-Reply-To: <4D6C3FD3.7010801@ucd.ie> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 09:27:34 -0000 --On 1 March 2011 00:37:39 +0000 Niall O'Reilly wrote: > SMTP has MX; others have SRV; HTTP is an outlier in that it > avoids this kind of assistance from the DNS. It's a significant > and pathological outlier because of the way HTTPS works. I'd look at it another way: * SMTP has email forwarding (rewrite envelope TO) * HTTP has 301 Permanent redirect. * SIP has 3xx REFER (from memory) All these make traffic to one place go to another. However in each case in the 'S' variant of the protocol, you need to provide a separate certificate for the alias to the canonical name, which means you can't automatically configure / synthesise the alias config in the same way you can for the non-'S' variant. What MX / SRV are allowing you to do for services that support them is hide this with another level of indirection. For that indirection to be applied to http (e.g. use SRV records) you'd need a change at the client end (to use SRV records or whatever) but also at the server end, so if a.example.com = b.example.com, and both have SRV records to c.example.com, then server c must use the cert for a or b as appropriate. In https that's hard as the cert is chosen before the GET line comes through. As solving this latter problem is enough to solve the entire issue for https, I am not sure the SRV record thing helps if it works like a normal SRV record. I *think* what you need is a REDIR record or similar, which achieves the effect of a redirect/rewrite/refer of the DN part. It's only visible to the application. It doesn't need to specify ports as it could clone whole DNs. For https you could (say) only redirect if the record was signed. I suppose you could make it redirect wildcards. -- Alex Bligh From bortzmeyer@nic.fr Tue Mar 1 01:48:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E76D3A63D2 for ; Tue, 1 Mar 2011 01:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.799 X-Spam-Level: X-Spam-Status: No, score=-109.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz4b2cwybNnV for ; Tue, 1 Mar 2011 01:48:19 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id D83E83A6359 for ; Tue, 1 Mar 2011 01:48:18 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id A9E451C0124; Tue, 1 Mar 2011 10:49:20 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id A44661C010D; Tue, 1 Mar 2011 10:49:20 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id A26DD5680AD; Tue, 1 Mar 2011 10:49:20 +0100 (CET) Date: Tue, 1 Mar 2011 10:49:20 +0100 From: Stephane Bortzmeyer To: Dan Schlitt Message-ID: <20110301094920.GA11956@nic.fr> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 6.0 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 09:48:20 -0000 On Mon, Feb 28, 2011 at 12:40:55PM -0500, Dan Schlitt wrote a message of 38 lines which said: > Weren't we told that we weren't dealing with "words" even though > some things might look like words. This means that we don't have to > deal with things like the difference between american english and > british english. In that case, it has to be said explicitely in the I-D (with explanations of why english/american is less important than simplified/traditional chinese). But I understand the current draft as saying "We will not decide if the difference between color.example and colour.example is significant or not. We will just provide a neutral mechanism to make them 'the same', should someone - typically the registry - decides they are the same." Am I correct in this reading of the I-D? From Niall.oReilly@ucd.ie Tue Mar 1 02:24:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13813A6784 for ; Tue, 1 Mar 2011 02:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoZxyAu7h7AQ for ; Tue, 1 Mar 2011 02:24:43 -0800 (PST) Received: from smtp.ucd.ie (zebra.ucd.ie [137.43.231.111]) by core3.amsl.com (Postfix) with ESMTP id B021E3A6767 for ; Tue, 1 Mar 2011 02:24:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsJAJFYbE2JK2zZ/2dsb2JhbACCQqQIdLsJhWEEj1I X-IronPort-AV: E=Sophos;i="4.62,246,1297036800"; d="scan'208";a="2734578" Received: from dhcp-892b6cd9.ucd.ie ([137.43.108.217]) by smtp.ucd.ie with ESMTP/TLS/AES128-SHA; 01 Mar 2011 10:25:45 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Niall O'Reilly In-Reply-To: <302DAD77E927757D3DEA05DF@nimrod.local> Date: Tue, 1 Mar 2011 10:25:45 +0000 Content-Transfer-Encoding: 7bit Message-Id: <98B2460F-C958-4C52-BF99-B64EEC0637A8@ucd.ie> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> To: Alex Bligh X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 10:24:43 -0000 On 1 Mar 2011, at 09:28, Alex Bligh wrote: > For that indirection to be applied to http (e.g. use SRV records) you'd > need a change at the client end (to use SRV records or whatever) but also > at the server end, so if a.example.com = b.example.com, and both have SRV > records to c.example.com, then server c must use the cert for a or b as > appropriate. I'm thinking of a different way, which appears to avoid this problem. SRV maps a domain name (OK, a service,transport,name triple) to a (set of) host name(s). If this mapping is provably legitimate (DNSSEC), then the browser need only verify that the cert matches the final host name. Matching what I've chosen to call the 'domain-part' of the http URL is no longer useful. Used in this way, SRV gives us aggregation of certificates: one per target host rather than one per secure hosted web site. I may be missing something, but I think this needs only client-side code changes. Service-side, certificate administration becomes different, but not code. ATB Niall From Niall.oReilly@ucd.ie Tue Mar 1 02:26:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A495B3A6767 for ; Tue, 1 Mar 2011 02:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkV17a5HOwMq for ; Tue, 1 Mar 2011 02:26:38 -0800 (PST) Received: from smtp.ucd.ie (smtp.ucd.ie [137.43.231.111]) by core3.amsl.com (Postfix) with ESMTP id A83E93A66B4 for ; Tue, 1 Mar 2011 02:26:37 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsJAJFYbE2JK2zZ/2dsb2JhbACCQqQIdLsJhWEEj1I X-IronPort-AV: E=Sophos;i="4.62,246,1297036800"; d="scan'208";a="2734594" Received: from dhcp-892b6cd9.ucd.ie ([137.43.108.217]) by smtp.ucd.ie with ESMTP/TLS/AES128-SHA; 01 Mar 2011 10:27:39 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Niall O'Reilly In-Reply-To: <98B2460F-C958-4C52-BF99-B64EEC0637A8@ucd.ie> Date: Tue, 1 Mar 2011 10:27:42 +0000 Content-Transfer-Encoding: 7bit Message-Id: <9BE2081A-23EB-4A59-B360-8A565DC02625@ucd.ie> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <98B2460F-C958-4C52-BF99-B64EEC0637A8@ucd.ie> To: Niall O'Reilly X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 10:26:38 -0000 On 1 Mar 2011, at 10:25, Niall O'Reilly wrote: > code changes. Service-side, certificate administration becomes Doh! s/Service/Server/ N From alex@alex.org.uk Tue Mar 1 03:27:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF86A3A67B1 for ; Tue, 1 Mar 2011 03:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krvqdqax8pjx for ; Tue, 1 Mar 2011 03:27:02 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 6CAB03A67B0 for ; Tue, 1 Mar 2011 03:27:00 -0800 (PST) Received: from [192.168.100.89] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id B7871C5640D; Tue, 1 Mar 2011 11:28:01 +0000 (GMT) Date: Tue, 01 Mar 2011 11:28:00 +0000 From: Alex Bligh To: Niall O'Reilly Message-ID: <5B082472C24FF3B3504807CF@nimrod.local> In-Reply-To: <98B2460F-C958-4C52-BF99-B64EEC0637A8@ucd.ie> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <98B2460F-C958-4C52-BF99-B64EEC0637A8@ucd.ie> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 11:27:03 -0000 --On 1 March 2011 10:25:45 +0000 Niall O'Reilly wrote: > SRV maps a domain name (OK, a service,transport,name triple) to > a (set of) host name(s). If this mapping is provably legitimate > (DNSSEC), then the browser need only verify that the cert matches > the final host name. Matching what I've chosen to call the > 'domain-part' of the http URL is no longer useful. Used in this way, > SRV gives us aggregation of certificates: one per target host rather > than one per secure hosted web site. > > I may be missing something, but I think this needs only client-side > code changes. Service-side, certificate administration becomes > different, but not code. So if a.example.com = b.example.com, and both have a SRV record to c.example.com, then the client does an SRV lookup on (say) b.example.com, receives the SRV record, then does an HTTP GET request to c.example.com and (crucially) the GET line is GET http://c.example.com/ not GET http://b.example.com/ I believe that needs to be the case because the server needs to always send back the same HTTP cert (as the decision in what cert to use is prior to the GET line). I'm a bit confused as to what you propose appears in the URL bar. IE does the user know he's been redirected? Do local links on the page appear as links from b.example.com or a.example.com? That's fine, except 1. it appears to be less backwards compatible than what I suggested (where the canonical URL will always work), though perhaps you could use (e.g.) a.example.com as the target of the SRV record and somehow loop detect. 2. It would be a useful property of a solution that it could redirect entire subsections of the tree. Else we are back to manually provisioning. -- Alex Bligh From Niall.oReilly@ucd.ie Tue Mar 1 04:35:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EAF13A67D8 for ; Tue, 1 Mar 2011 04:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8XtvIaW80hX for ; Tue, 1 Mar 2011 04:35:25 -0800 (PST) Received: from mx4.ucd.ie (mx4.ucd.ie [137.43.231.112]) by core3.amsl.com (Postfix) with ESMTP id 1A89A3A67AD for ; Tue, 1 Mar 2011 04:35:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8OADt3bE2JKz11/2dsb2JhbACCQqQJdLs2hWEEj1M X-IronPort-AV: E=Sophos;i="4.62,246,1297036800"; d="scan'208";a="2680354" Received: from dhcp-892b3d75.ucd.ie ([137.43.61.117]) by smtp.ucd.ie with ESMTP/TLS/AES128-SHA; 01 Mar 2011 12:36:27 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Niall O'Reilly In-Reply-To: <5B082472C24FF3B3504807CF@nimrod.local> Date: Tue, 1 Mar 2011 12:36:27 +0000 Content-Transfer-Encoding: 7bit Message-Id: <0D7CE2F6-8854-4E67-AA25-9FCE27B0F1C2@ucd.ie> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <98B2460F-C958-4C52-BF99-B64EEC0637A8@ucd.ie> <5B082472C24FF3B3504807CF@nimrod.local> To: Alex Bligh X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 12:35:26 -0000 I'm inclined to tease this out off-list, and spare the others the blow-by-blow. On 1 Mar 2011, at 11:28, Alex Bligh wrote: > So if a.example.com = b.example.com, and both have a SRV record to > c.example.com, then the client does an SRV lookup on (say) b.example.com, > receives the SRV record, then does an HTTP GET request to c.example.com > and (crucially) the GET line is [...] From hallam@gmail.com Tue Mar 1 08:07:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DFD53A6996 for ; Tue, 1 Mar 2011 08:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0k5AjzkoNpY5 for ; Tue, 1 Mar 2011 08:07:36 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D9DBE3A6992 for ; Tue, 1 Mar 2011 08:07:35 -0800 (PST) Received: by bwz13 with SMTP id 13so5449846bwz.31 for ; Tue, 01 Mar 2011 08:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=L6qiTmSpEehVHxpmDz0G0I5axgzkM/tC7AZzNgVFOSU=; b=SqRdMuDGM6gZBOzLflDqzVMx3/nFBogPKvhZu52kKctCxw6yXBfSYd8p+7AMrW6Fgq B0vwbfbVumQDXPML5bujdw0j7ubnAYR0luxr8ZtAOWccEZlgHl+CBHTbdSDdvBT/u/Zs paR14OsdGfA5sHGTAySf0l6+MiIlFdJkbHU+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i5Lu9zPQeqAvYTVEixM92ojF2pD8rMy5DcQ4g4x7ZFku0zao3zxjwIUmBc+aYT0ys9 srGFjZOFaiH5edTRpsOea47AkX7JZo00FOqkCoIZVOcwnZZds2hkFVoaLQ9YV4Q2xfBu xS250MljMbsO2VaJVqAKePSysc0ZxBx2Eemz0= MIME-Version: 1.0 Received: by 10.204.48.77 with SMTP id q13mr2517775bkf.128.1298995718259; Tue, 01 Mar 2011 08:08:38 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 1 Mar 2011 08:08:38 -0800 (PST) In-Reply-To: <335963D7-3440-45E6-843C-38F419462792@cisco.com> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> Date: Tue, 1 Mar 2011 11:08:38 -0500 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 16:07:37 -0000 2011/2/27 Patrik F=E4ltstr=F6m : > 2. Support of more application layer aliases > > 2.1. In HTTP and a few other protocols, we have the ability to do a redir= ect inside the application layer protocol itself. We do not have that in al= l protocols. In other we have things like the MX records. Do we with IDN et= c need more of these, and do we need a mechanism in DNS that "help" such re= direct in a "lower" layer in the resolution algorithm? > > 2.2. When using HTTP HOST header, and SSL where the DN of the cert is mat= ched with the domain name used, it is kind of problematic to match the appl= ication layer with what originally was entered by the user. Is there some n= eed for DNS layer aliases that changes what later is matched in the applica= tion layer comparisons? I would say not. The legacy HTTP protocol requires that the name presented in the Host header be the name that is present in the URL. There is no provision for rewriting as far as I am aware. Let us imagine we want a mapping a.com =3D b.com and the name a.com is presented. There are two design choices: 1) The client performs the rewrite. The best way to achieve this in my view would be to present a Host header for b.com and add in a new header to tell the server that the original origin was a.com This is compatible with legacy servers but not legacy clients. 2) The Server performs the rewrite. This is really hard to achieve as it requires the server to know that the mapping even exists. Typically a server is responding to hundreds of domains. Even large production servers do this. If a server receives a request for a.com it has no means of knowing that it 'should' map that to b.com unless the DNS configuration is somehow mapped to the Web administration. This is quite straightforward to handle administratively when the mapping is www.b.com to b.com because the source and target are in the same administrative zone. But this is not going to work if the mapping is being controlled by a TLD. 3) Don't support the aliasing requirement. 'nuff said. Note that in both cases the administrative model is only practical if there is a mapping of one name to another. It is futile to attempt to make the names 'the same' without nominating a canonical form. The legacy of Web servers is far more complex and difficult to change than legacy user applications. Web services are a different matter. Writing a Web browser is rather complex and there is a pretty high bar. There is very little demand for Web browsers that are not as good as Firefox or Chrome or IE or Safari or Opera (that is not an exhaustive list but most other browsers out there have a lot of common code with the above) There is a huge demand for Web servers that are smaller and lighter than Apache. To give you an idea of just how embedded these web servers are, you can get an ethernet socket that looks just like a regular socket but interfaces to an RS232/422 port and has a Web server and TCP/IP stack built into the plug. It is a cheap way to add ethernet connectivity to SCADA equipment. There are more brands of that type of connector than major web browser. There are a lot of cruddy Web browsers on phones but I don't think they get used more than a few times and they function so poorly that breaking them worse does not really matter much. The good mobile browsers all come from companies that are actively developing them. Web services are trickier. At one level they are quite easy because people who write mashups are already using pretty unfriendly URLs to identify service endpoints. But I think that has to be a temporary condition. We should be using SRV and other advanced discovery to make these connections. So with this in mind, I think that there is a brief window of opportunity in which we could make this change for Web Services applications. Over the past few weeks I have been discussing my ESRV scheme with principles in the Web Services platform space at major vendors who control and drive the relevant platforms. Since any Web Services support infrastructure would have to be buried deep in the scripting libraries used for making mashups, it would not be difficult to add in an aliasing requirement. But we have to be very quick if that is going to happen. The window is going to close very soon. > 4. How do we ensure skilled apps people manage to work with skilled DNS p= eople so that the end result is optimal? (something IETF is not always very= good at...) Skill in HTTP will probably only provide a better understanding of the range of constraints. There is 18 years of legacy here and a lot more complexity than in DNS. --=20 Website: http://hallambaker.com/ From fanf2@hermes.cam.ac.uk Thu Mar 3 03:17:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9353A6996 for ; Thu, 3 Mar 2011 03:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Unu9THLl8X06 for ; Thu, 3 Mar 2011 03:17:30 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by core3.amsl.com (Postfix) with ESMTP id BEA1C3A677E for ; Thu, 3 Mar 2011 03:17:27 -0800 (PST) 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-1.csi.cam.ac.uk ([131.111.8.51]:32802) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Pv6YD-0006XO-Eq (Exim 4.72) (return-path ); Thu, 03 Mar 2011 11:18:33 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Pv6YD-00047k-J9 (Exim 4.67) (return-path ); Thu, 03 Mar 2011 11:18:33 +0000 Date: Thu, 3 Mar 2011 11:18:33 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alex Bligh In-Reply-To: <302DAD77E927757D3DEA05DF@nimrod.local> Message-ID: References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Niall O'Reilly , dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 11:17:32 -0000 On Tue, 1 Mar 2011, Alex Bligh wrote: > > However in each case in the 'S' variant of the protocol, you need to > provide a separate certificate for the alias to the canonical name, > which means you can't automatically configure / synthesise the alias > config in the same way you can for the non-'S' variant. What MX / SRV > are allowing you to do for services that support them is hide this with > another level of indirection. The situation with TLS and SMTP is a mess. Inter-domain SMTP with TLS does not work with certificate validation. There is no specification for how to validate the TLS certificate for an MX server, and it is not obvious what such a specification should say. In practice the vast majority of deployed MX TLS certificates cannot be validated, neither against the MX owner name nor against the MX target. http://www.imc.org/ietf-smtp/mail-archive/msg05366.html Message submission (RFC 4409) doesn't use MX records and works well with certificate validation, just like POP and IMAP. Note that these three protocols use the DNS in the same way as HTTP (and FTP, and telnet, and ssh, etc.) so I don't think HTTP is an outlier as Niall said - it's just old school. > In https that's hard as the cert is chosen before the GET line comes > through. This is what TLS server name indication is for. Tony. -- f.anthony.n.finch http://dotat.at/ Plymouth, Biscay, FitzRoy: Northeast 5 to 7. Moderate or rough. Showers. Good. From marka@isc.org Thu Mar 3 03:40:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263D13A69C3 for ; Thu, 3 Mar 2011 03:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRQ8bP-V58+m for ; Thu, 3 Mar 2011 03:40:57 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 20D383A69BD for ; Thu, 3 Mar 2011 03:40:57 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id CC8FCC9427; Thu, 3 Mar 2011 11:41:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 0F9AB216C31; Thu, 3 Mar 2011 11:41:52 +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 A360FB98E2E; Thu, 3 Mar 2011 22:41:48 +1100 (EST) To: Tony Finch From: Mark Andrews References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> In-reply-to: Your message of "Thu, 03 Mar 2011 11:18:33 -0000." Date: Thu, 03 Mar 2011 22:41:48 +1100 Message-Id: <20110303114148.A360FB98E2E@drugs.dv.isc.org> Cc: Niall O'Reilly , dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 11:40:59 -0000 In message , Tony F inch writes: > On Tue, 1 Mar 2011, Alex Bligh wrote: > > > > However in each case in the 'S' variant of the protocol, you need to > > provide a separate certificate for the alias to the canonical name, > > which means you can't automatically configure / synthesise the alias > > config in the same way you can for the non-'S' variant. What MX / SRV > > are allowing you to do for services that support them is hide this with > > another level of indirection. > > The situation with TLS and SMTP is a mess. Inter-domain SMTP with TLS does > not work with certificate validation. There is no specification for how to > validate the TLS certificate for an MX server, and it is not obvious what > such a specification should say. In practice the vast majority of deployed > MX TLS certificates cannot be validated, neither against the MX owner name > nor against the MX target. If you read RFC 821 the HELO response should be used to check that you are talking to the machine you are expecting to. 3.5. OPENING AND CLOSING At the time the transmission channel is opened there is an exchange to ensure that the hosts are communicating with the hosts they think they are. The following two commands are used in transmission channel opening and closing: HELO QUIT In the HELO command the host sending the command identifies itself; the command may be interpreted as saying "Hello, I am ". The MX owner name never make sense. The MX target is *suposed* to be the (singular) cannonical name of the machine. The fact that people abuse this doesn't mean that the MX target shouldn't be used. > http://www.imc.org/ietf-smtp/mail-archive/msg05366.html > > Message submission (RFC 4409) doesn't use MX records and works well with > certificate validation, just like POP and IMAP. Note that these three > protocols use the DNS in the same way as HTTP (and FTP, and telnet, and > ssh, etc.) so I don't think HTTP is an outlier as Niall said - it's just > old school. > > > In https that's hard as the cert is chosen before the GET line comes > > through. > > This is what TLS server name indication is for. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Plymouth, Biscay, FitzRoy: Northeast 5 to 7. Moderate or rough. Showers. Good > . > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Thu Mar 3 03:43:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939AF28C0CE for ; Thu, 3 Mar 2011 03:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B85wSq51EpIQ for ; Thu, 3 Mar 2011 03:43:49 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 3EDB828C0CF for ; Thu, 3 Mar 2011 03:43:49 -0800 (PST) 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-1.csi.cam.ac.uk ([131.111.8.51]:40876) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Pv6xi-0000uG-rs (Exim 4.72) (return-path ); Thu, 03 Mar 2011 11:44:54 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Pv6xi-0000wa-MD (Exim 4.67) (return-path ); Thu, 03 Mar 2011 11:44:54 +0000 Date: Thu, 3 Mar 2011 11:44:54 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 11:43:50 -0000 On Tue, 1 Mar 2011, Phillip Hallam-Baker wrote: > > 2) The Server performs the rewrite. > > This is really hard to achieve as it requires the server to know that > the mapping even exists. > > Typically a server is responding to hundreds of domains. Even large > production servers do this. If a server receives a request for a.com > it has no means of knowing that it 'should' map that to b.com unless > the DNS configuration is somehow mapped to the Web administration. > > This is quite straightforward to handle administratively when the > mapping is www.b.com to b.com because the source and target are in the > same administrative zone. But this is not going to work if the mapping > is being controlled by a TLD. On the contrary, this is trivial for the server to do by dynamically looking up a.com and seeing if it is a BNAME pointing at b.com. However the server administrator probably does not want the server to accept requests for arbitrary domains just because they have a BNAME pointer. So there has to be a list of valid aliases somewhere accessible to the server, either in the DNS for b.com (used like "paranoid" reverse DNS checking) or in the server's configuration. Given the existence of HTTP redirects, I'm not entirely sure that it is reasonable to forbid DNS aliasing. But server administrators are free to choose between loose dynamic configurations and tight explicit configurations without affecting clients. The question for this group is if we specify something like BNAME if we should also specify how to put the corresponding back-references in the canonical domain. Tony. -- f.anthony.n.finch http://dotat.at/ Malin: South, veering northwest later, 3 or 4. Moderate or rough. Occasional rain. Moderate or good, occasionally poor. From fanf2@hermes.cam.ac.uk Thu Mar 3 04:23:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C8928C0E0 for ; Thu, 3 Mar 2011 04:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qklop-UxKXB8 for ; Thu, 3 Mar 2011 04:23:31 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id 184683A67A6 for ; Thu, 3 Mar 2011 04:23:31 -0800 (PST) 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-1.csi.cam.ac.uk ([131.111.8.51]:52857) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Pv7a9-0003MD-YJ (Exim 4.72) (return-path ); Thu, 03 Mar 2011 12:24:37 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Pv7a9-0000KL-K6 (Exim 4.67) (return-path ); Thu, 03 Mar 2011 12:24:37 +0000 Date: Thu, 3 Mar 2011 12:24:37 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20110303114148.A360FB98E2E@drugs.dv.isc.org> Message-ID: References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Niall O'Reilly , dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 12:23:33 -0000 On Thu, 3 Mar 2011, Mark Andrews wrote: > Tony Finch writes: > > > > The situation with TLS and SMTP is a mess. Inter-domain SMTP with TLS does > > not work with certificate validation. There is no specification for how to > > validate the TLS certificate for an MX server, and it is not obvious what > > such a specification should say. In practice the vast majority of deployed > > MX TLS certificates cannot be validated, neither against the MX owner name > > nor against the MX target. > > If you read RFC 821 the HELO response should be used to check that > you are talking to the machine you are expecting to. RFC 821 is thorougly obsolete. In particular the canonicalization requirements that existed in the 1980s were relaxed in the 1990s and no longer apply. In any case, the server's host name indicators are useless for secure server authentication, which is the whole point of TLS. If I am sending mail to an address at dotat.at, I need to securely verify that the server I am talking to is supposed to receive mail for dotat.at. So the TLS certificate must authenticate the MX owner name, dotat.at, not the MX target mx.cam.ac.uk, nor the virtual service instance name ppsw-mx-e.csi.cam.ac.uk nor the physical service machine name ppsw-51.csi.cam.ac.uk. If you authenticate the MX target name or the server's claimed canonical host name, you are open to attack. Note that SMTP is able to use one transaction to send a message with multiple recipients at different domains hosted on the same server. So the server needs to be able to present a certificate authenticating all of the mail domains it hosts. The server can't use TLS SNI to select a certificate dynamically because SNI only allows one name of each type which is incompatible with SMTP's multi-domain transaction support. In fact, if the client uses persistent connections it probably does not know at the time it negotiates TLS which mail domains it might encounter that deliver to the server. Now perhaps this mess - both the protocol mess and the deployment mess - can be fixed by using the firmer foundations that DNSSEC provides, but that requires protocol development. Tony. -- f.anthony.n.finch http://dotat.at/ Fisher: Westerly or northwesterly 3 or 4, occasionally 5, increasing 6 later in north. Mainly moderate, occasionally rough later. Fog patches for a time. Moderate or good, occasionally very poor. From marka@isc.org Thu Mar 3 05:34:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C197D3A69DC for ; Thu, 3 Mar 2011 05:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWW5avOnvZBj for ; Thu, 3 Mar 2011 05:34:51 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 1998A3A67DB for ; Thu, 3 Mar 2011 05:34:51 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id DF7EBC941A; Thu, 3 Mar 2011 13:35:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 504A8216C1E; Thu, 3 Mar 2011 13:35:45 +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 C19B6B9E307; Fri, 4 Mar 2011 00:35:41 +1100 (EST) To: Tony Finch From: Mark Andrews References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 03 Mar 2011 12:24:37 -0000." Date: Fri, 04 Mar 2011 00:35:41 +1100 Message-Id: <20110303133541.C19B6B9E307@drugs.dv.isc.org> Cc: Niall O'Reilly , dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 13:34:52 -0000 In message , Tony F inch writes: > On Thu, 3 Mar 2011, Mark Andrews wrote: > > Tony Finch writes: > > > > > > The situation with TLS and SMTP is a mess. Inter-domain SMTP with TLS doe > s > > > not work with certificate validation. There is no specification for how t > o > > > validate the TLS certificate for an MX server, and it is not obvious what > > > such a specification should say. In practice the vast majority of deploye > d > > > MX TLS certificates cannot be validated, neither against the MX owner nam > e > > > nor against the MX target. > > > > If you read RFC 821 the HELO response should be used to check that > > you are talking to the machine you are expecting to. > > RFC 821 is thorougly obsolete. In particular the canonicalization > requirements that existed in the 1980s were relaxed in the 1990s and no > longer apply. > > In any case, the server's host name indicators are useless for secure > server authentication, which is the whole point of TLS. But they show what *should* be checked. The MX record also needs to be checked. > If I am sending mail to an address at dotat.at, I need to securely verify > that the server I am talking to is supposed to receive mail for dotat.at. > So the TLS certificate must authenticate the MX owner name, dotat.at, not > the MX target mx.cam.ac.uk, nor the virtual service instance name > ppsw-mx-e.csi.cam.ac.uk nor the physical service machine name > ppsw-51.csi.cam.ac.uk. If you authenticate the MX target name or the > server's claimed canonical host name, you are open to attack. No. SMTP is store and forward. The MX records (cryptographically verifiable with DNSSEC) say that you should be talking to mx.cam.ac.uk and if you don't get a TLS connection that says you are talking to that machine you should drop the SMTP connection. > Note that SMTP is able to use one transaction to send a message with > multiple recipients at different domains hosted on the same server. So the > server needs to be able to present a certificate authenticating all of the > mail domains it hosts. The server can't use TLS SNI to select a > certificate dynamically because SNI only allows one name of each type > which is incompatible with SMTP's multi-domain transaction support. In > fact, if the client uses persistent connections it probably does not know > at the time it negotiates TLS which mail domains it might encounter that > deliver to the server. No. > Now perhaps this mess - both the protocol mess and the deployment mess - > can be fixed by using the firmer foundations that DNSSEC provides, but > that requires protocol development. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Fisher: Westerly or northwesterly 3 or 4, occasionally 5, increasing 6 later > in north. Mainly moderate, occasionally rough later. Fog patches for a time. > Moderate or good, occasionally very poor. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Thu Mar 3 05:55:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F023A69DC for ; Thu, 3 Mar 2011 05:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xeZxFhWGJwH for ; Thu, 3 Mar 2011 05:55:33 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id DA5A43A6884 for ; Thu, 3 Mar 2011 05:55:32 -0800 (PST) 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-1.csi.cam.ac.uk ([131.111.8.51]:59880) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Pv91D-00049s-py (Exim 4.72) (return-path ); Thu, 03 Mar 2011 13:56:39 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Pv91D-00007z-3J (Exim 4.67) (return-path ); Thu, 03 Mar 2011 13:56:39 +0000 Date: Thu, 3 Mar 2011 13:56:39 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20110303133541.C19B6B9E307@drugs.dv.isc.org> Message-ID: References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <20110303133541.C19B6B9E307@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Niall O'Reilly , dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 13:55:36 -0000 On Fri, 4 Mar 2011, Mark Andrews wrote: > > No. SMTP is store and forward. That makes no difference. Most store-and-forward hops in SMTP are within an organization, and in that situation mail routing is not based on the MX records of the recipients' mail domains. (cf. message submission) The organization can secure its mail transmission using its knowledge of its own setup. The important and difficult case is inter-domain SMTP which does rely on MX records and cannot rely on prior arrangements for authentication. > The MX records (cryptographically verifiable with DNSSEC) say that you > should be talking to mx.cam.ac.uk and if you don't get a TLS connection > that says you are talking to that machine you should drop the SMTP > connection. TLS predates DNSSEC. It security model assumes DNSSEC does not exist. Therefore TLS must authenticate the domain seen by the end user. It makes no sense to authenticate the MX target hostname because that makes you vulnerable to spoofing. Tony. -- f.anthony.n.finch http://dotat.at/ Irish Sea: Variable 3 or 4. Slight. Fog patches. Moderate, occasionally very poor. From marka@isc.org Thu Mar 3 06:45:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0CD3A68AD for ; Thu, 3 Mar 2011 06:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmr-ePn7TzSg for ; Thu, 3 Mar 2011 06:45:05 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 9179F3A67B2 for ; Thu, 3 Mar 2011 06:45:05 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 0C2CAC9423; Thu, 3 Mar 2011 14:46:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 59218216C1E; Thu, 3 Mar 2011 14:46:02 +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 11178B9E772; Fri, 4 Mar 2011 01:46:00 +1100 (EST) To: Tony Finch From: Mark Andrews References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <20110303133541.C19B6B9E307@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 03 Mar 2011 13:56:39 -0000." Date: Fri, 04 Mar 2011 01:45:59 +1100 Message-Id: <20110303144600.11178B9E772@drugs.dv.isc.org> Cc: Niall O'Reilly , dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 14:45:06 -0000 In message , Tony F inch writes: > On Fri, 4 Mar 2011, Mark Andrews wrote: > > > > No. SMTP is store and forward. > > That makes no difference. It makes all the difference in the world. MX records DO NOT AND NEVER HAVE DEFINED FINAL DELIVER they have only ever defined the NEXT HOP. > Most store-and-forward hops in SMTP are within an organization, and in > that situation mail routing is not based on the MX records of the > recipients' mail domains. (cf. message submission) The organization can > secure its mail transmission using its knowledge of its own setup. > > The important and difficult case is inter-domain SMTP which does rely on > MX records and cannot rely on prior arrangements for authentication. And that is done by publishing MX records (secure with DNSSEC) or in their absence (secure with DNSSEC) constructing a MX record from the A/AAAA records (secure with DNSSEC). > > The MX records (cryptographically verifiable with DNSSEC) say that you > > should be talking to mx.cam.ac.uk and if you don't get a TLS connection > > that says you are talking to that machine you should drop the SMTP > > connection. > > TLS predates DNSSEC. Yes and it did not work securely because there was no way to validate the DNS responses. > It security model assumes DNSSEC does not exist. The security model assumed the DNS responses were good. We can now prove they are good. > Therefore TLS must authenticate the domain seen by the end user. It makes > no sense to authenticate the MX target hostname because that makes you > vulnerable to spoofing. Nope. Flawed logic here. > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Irish Sea: Variable 3 or 4. Slight. Fog patches. Moderate, occasionally very > poor. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hallam@gmail.com Thu Mar 3 06:46:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B933A67B2 for ; Thu, 3 Mar 2011 06:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILbKB8mRMnsV for ; Thu, 3 Mar 2011 06:46:33 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D7C783A69DC for ; Thu, 3 Mar 2011 06:46:32 -0800 (PST) Received: by bwz13 with SMTP id 13so1408960bwz.31 for ; Thu, 03 Mar 2011 06:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EQVL4VJXb7aqvJB55L+wN4I3m7S4vkKcmd/8EkOuPoM=; b=SpXxYp2ce8+huHoW7l1jYSdlxz/YIDS0+oTD/B8oD58W8jv/LNXby6J2Hqj2FINK9V N2nbFQ5qBFGMjreVp5XFnv96lGbwm+6fXm5ugZaaBUmnM6jQ2IGFLhd0q0ZJ/cKZF5I9 IidgoQIHgkhuPDCuAr4oaqpRVVlGN+nzS8y+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j6QSP69ERVbKC1bCD9wHeOrGPxxZYjPmqMd/oIvctpXyrdoHnP4yLHO6JN2eMaLcfb CWMjoyFn3p1izDcAyRlbNqS2naCZNY4Bu6334NpXEvC86Th9wflK/0muHxVdv6tjqtIB z28ZrX8uimpNbENHJW6ikCcPlbm+LQmcxRKuM= MIME-Version: 1.0 Received: by 10.204.231.66 with SMTP id jp2mr530713bkb.33.1299163659715; Thu, 03 Mar 2011 06:47:39 -0800 (PST) Received: by 10.204.14.139 with HTTP; Thu, 3 Mar 2011 06:47:39 -0800 (PST) In-Reply-To: References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> Date: Thu, 3 Mar 2011 09:47:39 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=485b393ab62b714caf049d951cfa Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 14:46:34 -0000 --485b393ab62b714caf049d951cfa Content-Type: text/plain; charset=ISO-8859-1 OK, I am not yet convinced that this is acceptably secure, but I withdraw my earlier objection, see below. 2011/3/3 Tony Finch : > On Tue, 1 Mar 2011, Phillip Hallam-Baker wrote: >> >> 2) The Server performs the rewrite. >> >> This is really hard to achieve as it requires the server to know that >> the mapping even exists. >> >> Typically a server is responding to hundreds of domains. Even large >> production servers do this. If a server receives a request for a.com >> it has no means of knowing that it 'should' map that to b.com unless >> the DNS configuration is somehow mapped to the Web administration. >> >> This is quite straightforward to handle administratively when the >> mapping is www.b.com to b.com because the source and target are in the >> same administrative zone. But this is not going to work if the mapping >> is being controlled by a TLD. > > On the contrary, this is trivial for the server to do by dynamically > looking up a.com and seeing if it is a BNAME pointing at b.com. That would not meet my definition of 'straightforward'. From a security point of view, having my server mappings controlled by BNAMES in the TLD... > However the server administrator probably does not want the server to > accept requests for arbitrary domains just because they have a BNAME > pointer. So it is straightforward but stupid, OK we seem to agree here. > So there has to be a list of valid aliases somewhere accessible to the > server, either in the DNS for b.com (used like "paranoid" reverse DNS > checking) or in the server's configuration. > > Given the existence of HTTP redirects, I'm not entirely sure that it is > reasonable to forbid DNS aliasing. But server administrators are free to > choose between loose dynamic configurations and tight explicit > configurations without affecting clients. There is a big difference between a redirect issued by the administrator of the target and a redirect issued by a third party. > The question for this group is if we specify something like BNAME if we > should also specify how to put the corresponding back-references in the > canonical domain. That could help the situation. It could be quite efficiently encoded as a circular list. Each alias would have a link to the canonical name and the next alias in the list. This would also act to prevent an alias being effected without the consent of the target domain since they would have to recognize the list. Consider the following. let canonical.tld be the target and alias.tld and alias.atld be the aliases. An appropriate configuration would be: ! Records maintained by admin for tld and atld canonical.tld NS canonical.tld xlnk alias.tld alias.tld xname canonical.tld alias.tld xlnk alias.atld alias.atld xname canonical.tld alias.atld xlnk canonical.tld ! Records maintained locally canonical.tld A 10.0.0.1 canonical.tld AAAA 1:00:1 canonical.tld clnk www.canonical.tld canonical.tld xx www.canonical.tld cname canonical.tld www.canonical.tld clnk canonical.tld I can see a fairly strong separation of control there. This mechanism could in principle be used by either clients or servers. It could also be used by resolvers synthesizing up a dynamic HTTP response. That would give us a chance of getting a deployment to actually happen. So an aware resolver needs to be able to know if the server is capable of accepting the request or not. If the server accepts this type of alias it can simply return the records and get out of the way. Otherwise an HTTP redirect is going to be required. The resolver could do this by pinging the Web server, but it is better to have that information in the zone. Hence the need for the xx record which is basically a way to say 'this zone handles this extension'. -- Website: http://hallambaker.com/ --485b393ab62b714caf049d951cfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK, I am not yet convinced that this is acceptably = secure, but I withdraw my earlier objection, see below.


2011/3/= 3 Tony Finch <dot@dotat.at>:
&= gt; On Tue, 1 Mar 2011, Phillip Hallam-Baker wrote:
>>
>> 2) The Server performs the rewrite.
>>
>= ;> This is really hard to achieve as it requires the server to know that=
>> the mapping even exists.
>>
>> Typically a s= erver is responding to hundreds of domains. Even large
>> production servers do this. If a server receives a request for a.com
>> it has no means of knowing that= it 'should' map that to b.com unless<= br> >> the DNS configuration is somehow mapped to the Web administration.=
>>
>> This is quite straightforward to handle administra= tively when the
>> mapping is www.b.c= om to b.com because the source and target = are in the
>> same administrative zone. But this is not going to work if the map= ping
>> is being controlled by a TLD.
>
> On the contr= ary, this is trivial for the server to do by dynamically
> looking up= a.com and seeing if it is a BNAME pointing at= b.com.

That would not meet my definition of 'straightforward'. From a = security point of view, having my server mappings controlled by BNAMES in t= he TLD...


> However the server administrator probably does no= t want the server to
> accept requests for arbitrary domains just because they have a BNAME> pointer.

So it is straightforward but stupid, OK we seem to a= gree here.


> So there has to be a list of valid aliases somew= here accessible to the
> server, either in the DNS for b.com (used= like "paranoid" reverse DNS
> checking) or in the server&#= 39;s configuration.
>
> Given the existence of HTTP redirects, = I'm not entirely sure that it is
> reasonable to forbid DNS aliasing. But server administrators are free = to
> choose between loose dynamic configurations and tight explicit> configurations without affecting clients.

There is a big diff= erence between a redirect issued by the administrator of the target and a r= edirect issued by a third party.


> The question for this group is if we specify something like BN= AME if we
> should also specify how to put the corresponding back-ref= erences in the
> canonical domain.

That could help the situati= on. It could be quite efficiently encoded as a circular list. Each alias wo= uld have a link to the canonical name and the next alias in the list.

This would also act to prevent an alias being effected without the cons= ent of the target domain since they would have to recognize the list.
Consider the following.

let canonical.tld be the target and a= lias.tld and alias.atld be the aliases. An appropriate configuration would = be:


! Records maintained by admin for tld and atld

canonical.tld =A0 =A0 =A0 NS =A0 <= blah>
canonical.tld =A0 =A0 =A0 xlnk =A0 alias.tld
alias.tld =A0 =A0 =A0 =A0 =A0 xname =A0canonical.tld
alias.tld =A0 =A0 =A0 =A0 =A0 xlnk =A0 alias.a= tld
alias.atld =A0 =A0 =A0 =A0 =A0xna= me =A0canonical.tld=A0
alias.atld =A0 =A0 =A0 =A0 =A0xlnk =A0 canonic= al.tld


! Records maintained locally=
canoni= cal.tld =A0 =A0 =A0 A =A0 =A0 =A010.0.0.1
canoni= cal.tld =A0 =A0 =A0 AAAA =A0 1:00:1
canonical.tld =A0 =A0 =A0 clnk =A0=A0www.canonical.tld=A0
canonical.tld =A0 =A0 =A0 xx =A0=A0
<= span class=3D"Apple-style-span" style=3D"font-family: 'courier new'= , monospace; ">www.canonical.tld =A0 cname =A0canonical.tld=A0
www.canonical.tld =A0 clnk =A0= =A0canonical.tld


I can see a fairly strong separation of control there.= =A0

This mechanism could in principle be used by e= ither clients or servers. It could also be used by resolvers synthesizing u= p a dynamic HTTP response. That would give us a chance of getting a deploym= ent to actually happen.

So an aware resolver needs to be able to know if the se= rver is capable of accepting the request or not. If the server accepts this= type of alias it can simply return the records and get out of the way. Oth= erwise an HTTP redirect is going to be required.

The resolver could do this by pinging the Web server, b= ut it is better to have that information in the zone. Hence the need for th= e xx record which is basically a way to say 'this zone handles this ext= ension'.
--485b393ab62b714caf049d951cfa-- From fanf2@hermes.cam.ac.uk Thu Mar 3 11:38:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B083A69F4 for ; Thu, 3 Mar 2011 11:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quBP4XR8tPnU for ; Thu, 3 Mar 2011 11:38:19 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by core3.amsl.com (Postfix) with ESMTP id 235C33A690F for ; Thu, 3 Mar 2011 11:38:19 -0800 (PST) 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-1.csi.cam.ac.uk ([131.111.8.51]:59136) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1PvEMw-0006JK-DP (Exim 4.72) (return-path ); Thu, 03 Mar 2011 19:39:26 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PvEMw-0001vP-4e (Exim 4.67) (return-path ); Thu, 03 Mar 2011 19:39:26 +0000 Date: Thu, 3 Mar 2011 19:39:26 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20110303144600.11178B9E772@drugs.dv.isc.org> Message-ID: References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <20110303133541.C19B6B9E307@drugs.dv.isc.org> <20110303144600.11178B9E772@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Niall O'Reilly , dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:38:20 -0000 On Fri, 4 Mar 2011, Mark Andrews wrote: > > It makes all the difference in the world. MX records DO NOT AND NEVER > HAVE DEFINED FINAL DELIVER they have only ever defined the NEXT HOP. MX record define the inter-domain hop, which is where the mail crosses a trust boundary, and where authentication is required. The other store-and-forward hops (from submission to outgoing border relay; and from incoming border MX to final delivery or to alias redirector) are within trust boundaries and so they are easier to authenticate. > > TLS predates DNSSEC. > > Yes and it did not work securely because there was no way to validate > the DNS responses. TLS doesn't try to validate the DNS responses, it verifies that you have successfully connected to a server that can act for the domain you wanted to reach. If TLS validation succeeds the DNS lookup must necessarily have given you the right result. It isn't possible to use DNSSEC to secure a TCP connection to a server because it doesn't verify that no-one has hijacked the IP address. I don't know why you keep bringing it up. Note that these issues are not specific to SMTP: XMPP has similar difficulties with s2s authentication. Tony. -- f.anthony.n.finch http://dotat.at/ Sole, Lundy, Fastnet: Mainly northeasterly 4 or 5, occasionally 6 in Sole. Slight or moderate, occasionally rough in Sole and Fastnet. Mainly fair. Moderate or good. From ogud@ogud.com Thu Mar 3 12:22:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59CC43A6A39 for ; Thu, 3 Mar 2011 12:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sva92V0wfcmR for ; Thu, 3 Mar 2011 12:22:02 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id B5D593A6A1B for ; Thu, 3 Mar 2011 12:22:01 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p23KN84l010376 for ; Thu, 3 Mar 2011 15:23:08 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D6FF8A8.2070500@ogud.com> Date: Thu, 03 Mar 2011 15:23:04 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: dnsext@ietf.org References: <4CC95816-8225-4CAE-897F-3F13F965BCEE@ICSI.Berkeley.EDU> <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] does making names the same NEED protocol changes at all? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 20:22:03 -0000 (sorry for the late answer) On 25/02/2011 12:43 PM, Phillip Hallam-Baker wrote: > Requiring slaves to be signers is a major change to the security model. > Take a look at RFC4470. There is no requirement that the RRSIG for a particular RRSET from server A have be the same as is in the answer from server B for same question at the same time. Only requirement is that in both cases the signatures validate. I.e. the keys generating the signatures are in the DNSKEY for the zone, and that the signatures are temporarily valid. There is nothing in DNSSEC specs that outlaws signing on all authoritative servers. There have been operational arguments, but number of us have envisioned having slaves sign the negative answers on the fly as via schema from RFC4470+RFC4471. There are some that even envision that servers generate dynamically answers for reverse IPv6 lookups and sign the dynamically generated answers. Then there is the case when there is "no zone" and the answer is generated from information in a database and the source address of the query (add to that possibly data in an EDNS0 option in the query). > In the current architecture it is sufficient to have online keys at a > hidden master. The hidden master can be placed behind a firewall that > rejects inbound requests. > You are equating architecture and operating guidance, they are not the same. This is similar to in the original DNS world there was the globally visible holy Q-Trinity and all zone contents was provided by a MASTER server. Load balancers changed that to all names and types exists but contents may differ based on location and the world keeps evolving to more and more localized/personalized answers, and DNSSEC does not in any way prevent that. > In the proposed architecture every DNS server has to have signing > capability. It is not possible to prep the zone at the hidden master and > then push the data out. The keys are not only online, they are reacting > to queries prepared by potential attackers. > > > From a risk analysis point of view these changes are very significant > indeed. Yes the risks in different operating models are quite different. Olafur > > > On Fri, Feb 25, 2011 at 12:09 PM, Tony Finch > wrote: > > On Fri, 25 Feb 2011, Phillip Hallam-Baker wrote: > > > I suspect that the point of these requirements is precisely the > fact that > > they cannot be met within the current architecture. > > A lot of the argument is because we aren't sure that that is true. > Can the > requirements be met with improved provisioning technology and no > protocol > changes? > > > I am seeing people rushing to change the security model of DNSSEC > to support > > this requirement, but I doubt that is going to be sufficient. > > Online signing is not a change to the DNSSEC security model. > > Tony. > -- > f.anthony.n.finch > http://dotat.at/ > Forties, Cromarty, Forth: Southwest 5 to 7 veering northwest 4 or 5. > Moderate > or rough. Occasional rain. Moderate or good, occasionally poor. > > > > > -- > Website: http://hallambaker.com/ > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From alex@alex.org.uk Thu Mar 3 13:29:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6983A6A20 for ; Thu, 3 Mar 2011 13:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-4++-bWjrQx for ; Thu, 3 Mar 2011 13:29:37 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id E6C1D3A6893 for ; Thu, 3 Mar 2011 13:29:36 -0800 (PST) Received: from [192.168.100.89] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 9F82AC566C4; Thu, 3 Mar 2011 21:30:41 +0000 (GMT) Date: Thu, 03 Mar 2011 21:31:23 +0000 From: Alex Bligh To: Tony Finch , Mark Andrews Message-ID: <618355BCA39C2F7544D51832@nimrod.local> In-Reply-To: References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <20110303133541.C19B6B9E307@drugs.dv.isc.org> <20110303144600.11178B9E772@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Niall O'Reilly , dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:29:38 -0000 --On 3 March 2011 19:39:26 +0000 Tony Finch wrote: > TLS doesn't try to validate the DNS responses, it verifies that you have > successfully connected to a server that can act for the domain you wanted > to reach. What does "can act for" mean? Any smarthost "can act for" (in the sense of can deliver mail to" any given domain, but it may require information for the server to determine whether it "can act" at the time of TLS (e.g. it might require authentication). I had thought the purpose of SMTP on TLS was to verify that the server was the server it claimed to be in the HELO line. Whether the sending server uses that as a decision point as to whether to send email on it is pretty much up to the sending server. >From RFC3207 > The decision of whether or not to believe the authenticity of the > other party in a TLS negotiation is a local matter. However, some > general rules for the decisions are: > > - A SMTP client would probably only want to authenticate an SMTP > server whose server certificate has a domain name that is the > domain name that the client thought it was connecting to. > - A publicly-referenced SMTP server would probably want to accept > any verifiable certificate from an SMTP client, and would possibly > want to put distinguishing information about the certificate in > the Received header of messages that were relayed or submitted > from the client. This is a similar degree of usefulness/uselessness to HTTP certs, which in the vast majority of cases (DN validated) simply tell you that the server you are visiting has a certificate purchased by someone who could receive mail at that domain or administer the zone. And before we get on our high horses about the usefulness or otherwise of other cert systems, that's not too much different from DNSSEC. -- Alex Bligh From marka@isc.org Thu Mar 3 13:31:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E589A3A6864 for ; Thu, 3 Mar 2011 13:31:02 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuwXybajMHaC for ; Thu, 3 Mar 2011 13:31:01 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 7E48F3A6893 for ; Thu, 3 Mar 2011 13:31:01 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id DF88D5F98F0; Thu, 3 Mar 2011 21:31:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 B91F0216C31; Thu, 3 Mar 2011 21:31:48 +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 2B252B9FEA4; Fri, 4 Mar 2011 08:31:45 +1100 (EST) To: Tony Finch From: Mark Andrews References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <20110303133541.C19B6B9E307@drugs.dv.isc.org> <20110303144600.11178B9E772@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 03 Mar 2011 19:39:26 -0000." Date: Fri, 04 Mar 2011 08:31:45 +1100 Message-Id: <20110303213145.2B252B9FEA4@drugs.dv.isc.org> Cc: Niall O'Reilly , dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:31:03 -0000 In message , Tony F inch writes: > On Fri, 4 Mar 2011, Mark Andrews wrote: > > > > It makes all the difference in the world. MX records DO NOT AND NEVER > > HAVE DEFINED FINAL DELIVER they have only ever defined the NEXT HOP. > > MX record define the inter-domain hop, which is where the mail crosses a > trust boundary, and where authentication is required. > > The other store-and-forward hops (from submission to outgoing border > relay; and from incoming border MX to final delivery or to alias > redirector) are within trust boundaries and so they are easier to > authenticate. > > > > TLS predates DNSSEC. > > > > Yes and it did not work securely because there was no way to validate > > the DNS responses. > > TLS doesn't try to validate the DNS responses, it verifies that you have > successfully connected to a server that can act for the domain you wanted > to reach. If TLS validation succeeds the DNS lookup must necessarily have > given you the right result. > > It isn't possible to use DNSSEC to secure a TCP connection to a server > because it doesn't verify that no-one has hijacked the IP address. I don't > know why you keep bringing it up. BECAUSE YOU CAN'T SECURE INTER SITE SMTP WITH OUT BOTH SECURING THE MX/A/AAAA LOOKUPS *AND* THE TCP CONNECTION THE SMTP TRANSACTION GOES OVER. > Note that these issues are not specific to SMTP: XMPP has similar > difficulties with s2s authentication. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Sole, Lundy, Fastnet: Mainly northeasterly 4 or 5, occasionally 6 in Sole. > Slight or moderate, occasionally rough in Sole and Fastnet. Mainly fair. > Moderate or good. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dougb@dougbarton.us Thu Mar 3 14:12:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54FC528C0F8 for ; Thu, 3 Mar 2011 14:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gR0wCis50cOn for ; Thu, 3 Mar 2011 14:12:01 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 5B6A628C0F2 for ; Thu, 3 Mar 2011 14:12:01 -0800 (PST) Received: (qmail 16679 invoked by uid 399); 3 Mar 2011 22:13:06 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 3 Mar 2011 22:13:06 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D701271.9040105@dougbarton.us> Date: Thu, 03 Mar 2011 14:13:05 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.14) Gecko/20110301 Thunderbird/3.1.8 MIME-Version: 1.0 To: Ted Hardie References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "John R. Levine" , dnsext@ietf.org Subject: Re: [dnsext] the same in old days, was making names the same NEED protocol changes? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 22:12:03 -0000 On 02/28/2011 09:38, Ted Hardie wrote: > On Mon, Feb 28, 2011 at 7:07 AM, Phillip Hallam-Baker wrote: > > >> So attempting to make two names resolve alike without change at either >> the application client or the application server is a fools errand. > > I'm not sure how you see this split based on the text above. My > personal take is that if you want two names be "treated the same" by > an application, you can do one of three things: > > 1) Make one name refer to the other, transforming the problem of > "treating the same" into "pointing to the canonical name". I'm using some elements of this concept in my idea for CLONE. However the solution I'm going to propose is limited to the DNS layer. > 2) Provide for all the names equally, so that the same resources are > available at each name (this means not just things like > name-to-address mappings but also certificates with the names used on > them etc.). This is expensive and difficult, but there may be some > methods to reduce the pain (subjectAltName, provisioning-based > mirroring of resources, new protocol methods). I think a lot of the > discussion so far has been of the "are there useful DNS mechanisms > that could reduce this pain"? Yes. I've been trying to get across the idea that _on the registrant side_ this problem is really no different than what registrants already deal with, both with the existing "IDN variants" problem and with the pre-existing problem of "aliasing" multiple spellings/TLDs, etc. for "the same" name. In that sense the color/colour problem is (IMO) the same problem space. > 3) Create a method that allows applications to know which names should > be treated as equivalent. The difficulty here is primarily that any > names which are not within the same administrative boundary cannot be > treated as equivalent without the records related to both/N > administrative boundaries confirming the equivalence. So the > application would have to understand how to determine the > administrative boundaries, check for the confirmation of equivalence, > and then correctly apply whatever behaviors result from the two names > being the same. This is far from trivial, as the > applications/protocols may have no defined behavior for "treat these > as the same". Knowing they are to be treated as equivalent doesn't > help a lot for applications with no sense of what behavior should > result. > > >> is not going to work because that is simply not how the applications >> see the world. >> >> >> >> If we decide we can change the application client, this whole problem >> becomes pretty straightforward. Either adopt the 'did you mean' >> pointer style approach or allow domains to nominate mappings of one >> charset to another. >> > Please do not use "mappings of one charset to another" to represent > this problem. At this point, we are all mostly talking about the > Unicode character set and how to map labels derived from sequences of > Unicode characters. Just to be clear, I'm not. I think the requirements document should describe the whole problem space, and then we can decide what problems we can provide DNS solutions for. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From marka@isc.org Thu Mar 3 15:33:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A673A68D9 for ; Thu, 3 Mar 2011 15:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.039 X-Spam-Level: X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=4.560, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMUQhDVjctC4 for ; Thu, 3 Mar 2011 15:32:54 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by core3.amsl.com (Postfix) with ESMTP id 35F8E3A68D4 for ; Thu, 3 Mar 2011 15:32:54 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id A8723C9427; Thu, 3 Mar 2011 23:32:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 02B46216C1E; Thu, 3 Mar 2011 23:32:38 +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 70223BA0FA9; Fri, 4 Mar 2011 10:32:35 +1100 (EST) To: Alex Bligh From: Mark Andrews References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <20110303133541.C19B6B9E307@drugs.dv.isc.org> <20110303144600.11178B9E772@drugs.dv.isc.org> <618355BCA39C2F7544D51832@nimrod.local> In-reply-to: Your message of "Thu, 03 Mar 2011 21:31:23 -0000." <618355BCA39C2F7544D51832@nimrod.local> Date: Fri, 04 Mar 2011 10:32:35 +1100 Message-Id: <20110303233235.70223BA0FA9@drugs.dv.isc.org> Cc: Niall O'Reilly , dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 23:33:14 -0000 In message <618355BCA39C2F7544D51832@nimrod.local>, Alex Bligh writes: > --On 3 March 2011 19:39:26 +0000 Tony Finch wrote: > > > TLS doesn't try to validate the DNS responses, it verifies that you have > > successfully connected to a server that can act for the domain you wanted > > to reach. > > What does "can act for" mean? Any smarthost "can act for" (in the > sense of can deliver mail to" any given domain, but it may require > information for the server to determine whether it "can act" at the > time of TLS (e.g. it might require authentication). > > I had thought the purpose of SMTP on TLS was to verify that the > server was the server it claimed to be in the HELO line. Whether > the sending server uses that as a decision point as to whether > to send email on it is pretty much up to the sending server. > > >From RFC3207 > > The decision of whether or not to believe the authenticity of the > > other party in a TLS negotiation is a local matter. However, some > > general rules for the decisions are: > > > > - A SMTP client would probably only want to authenticate an SMTP > > server whose server certificate has a domain name that is the > > domain name that the client thought it was connecting to. Which is learnt from the MX record (real or synthesised from the A/AAA records) or manually configured in the case of a smart relay. > > - A publicly-referenced SMTP server would probably want to accept > > any verifiable certificate from an SMTP client, and would possibly > > want to put distinguishing information about the certificate in > > the Received header of messages that were relayed or submitted > > from the client. > > This is a similar degree of usefulness/uselessness to HTTP certs, > which in the vast majority of cases (DN validated) simply tell you > that the server you are visiting has a certificate purchased > by someone who could receive mail at that domain or administer > the zone. And before we get on our high horses about the usefulness > or otherwise of other cert systems, that's not too much different > from DNSSEC. > > -- > Alex Bligh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohta@necom830.hpcl.titech.ac.jp Thu Mar 3 17:02:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642C23A684A for ; Thu, 3 Mar 2011 17:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnppzP36QRBS for ; Thu, 3 Mar 2011 17:02:44 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 543333A683F for ; Thu, 3 Mar 2011 17:02:43 -0800 (PST) Received: (qmail 79501 invoked from network); 4 Mar 2011 01:18:27 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 4 Mar 2011 01:18:27 -0000 Message-ID: <4D703A35.9080207@necom830.hpcl.titech.ac.jp> Date: Fri, 04 Mar 2011 10:02:45 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 01:02:45 -0000 Tony Finch wrote: > Note that SMTP is able to use one transaction to send a message with > multiple recipients at different domains hosted on the same server. So the > server needs to be able to present a certificate authenticating all of the > mail domains it hosts. > Now perhaps this mess - both the protocol mess and the deployment mess - > can be fixed by using the firmer foundations that DNSSEC provides, but > that requires protocol development. Just say "another level of indirection" or another CNAME. By making CNAME domain names pointed by MXes different for each mail domain name, and letting SMTP think servers with different CNAME domain names are different servers even if they are aliases of a single server, TLS should work with MX. mail0.example.com MX 0 mail0.example.net mail1.example.com MX 0 mail1.example.net mail0.example.net CNAME mx.example.net mail1.example.net CNAME mx.example.net It's like differentiating name based virtual servers by different CNAMEs pointed from different SVRs, as I pointed out a few weeks ago. A problem is that RFC1034 has a wrong example for reasoning against recursive aliasing. But, it should be fixed. I'll post an errata with a separate subject. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Thu Mar 3 19:15:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7463A6918 for ; Thu, 3 Mar 2011 19:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FnyPEg-jo8L for ; Thu, 3 Mar 2011 19:15:01 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 826A73A6916 for ; Thu, 3 Mar 2011 19:15:00 -0800 (PST) Received: (qmail 81300 invoked from network); 4 Mar 2011 03:30:39 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 4 Mar 2011 03:30:39 -0000 Message-ID: <4D705952.6000409@necom830.hpcl.titech.ac.jp> Date: Fri, 04 Mar 2011 12:15:30 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <4D703A35.9080207@necom830.hpcl.titech.ac.jp> In-Reply-To: <4D703A35.9080207@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 03:15:03 -0000 While RFC1034 says: Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information. For example, the address to name RR for the above host should be: 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU rather than pointing at USC-ISIC.ARPA. Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error. "avoids extra indirections" is not a strong requirement and virtually allowed with the wording of while "CNAME loops signalled as an error" is a strong requirement. Thus, while CNAME (and BNAME) chains should be discouraged, it should be explicitly allowed to use CNAME as a target of PTR, MX, SVR and so on which does not cause recursion loops, which is useful for name based differentiation of a service on a single host. CNAME as a target of NS should also be discouraged, because it may cause recursion loop to be resolved by glue, which requires unnecessarily complex operations. Masataka Ohta From marka@isc.org Thu Mar 3 21:08:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C30DF3A692B for ; Thu, 3 Mar 2011 21:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.703 X-Spam-Level: X-Spam-Status: No, score=-6.703 tagged_above=-999 required=5 tests=[AWL=3.896, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwZUqqfj3euu for ; Thu, 3 Mar 2011 21:08:29 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by core3.amsl.com (Postfix) with ESMTP id 1F0643A68D3 for ; Thu, 3 Mar 2011 21:08:29 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 9B27AC9421; Fri, 4 Mar 2011 05:08:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 3F1E8216C1E; Fri, 4 Mar 2011 05:08:12 +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 E7F09BA7287; Fri, 4 Mar 2011 16:08:09 +1100 (EST) To: Masataka Ohta From: Mark Andrews References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <4D703A35.9080207@necom830.hpcl.titech.ac.jp> <4D705952.6000409@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Fri, 04 Mar 2011 12:15:30 +0900." <4D705952.6000409@necom830.hpcl.titech.ac.jp> Date: Fri, 04 Mar 2011 16:08:09 +1100 Message-Id: <20110304050809.E7F09BA7287@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 05:08:29 -0000 In message <4D705952.6000409@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > CNAME as a target of NS should also be discouraged, because > it may cause recursion loop to be resolved by glue, which > requires unnecessarily complex operations. CNAME as the target of a NS does not work reliably. To make it work reliably you would have to change the additional processing rules in every deployed nameserver. You would also have to change glue to include CNAME records. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jehan.marmottard@gmail.com Thu Mar 3 22:34:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D973A6906 for ; Thu, 3 Mar 2011 22:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EF3sR3Wehk99 for ; Thu, 3 Mar 2011 22:34:19 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 408973A692D for ; Thu, 3 Mar 2011 22:34:19 -0800 (PST) Received: by wyb42 with SMTP id 42so1952734wyb.31 for ; Thu, 03 Mar 2011 22:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=f7qRkp83geeZpwFg3I5tXG0l+GKAIDYmeEdtAaeGgOE=; b=vz/8W+uTrD1meP3bQ+nUxyy33fy226V7kvAdTfdffL260leTRYUCp73iZ5Au+123JR CTgVCtE41bdZ9r65qDAtmdwmMeQlwFXZP8MoP+GUTJ0JRIlLfZf6JuknuTBKgT1p4YhK ST6x3+5uGMOC8iBO6YLrb0BhsIX5WDKLeRABU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=lcbAtAfi6cJG/8Z84LghKgFeNyAK4+V2oUq9wVncDRCV7eMlsDbh1b2l6xpfXTt+qK oUniihFnjrS7MvS2EZt7geeZwbQkbSeZCqIZoSIG4oYDfDtj86vvJ/3axzsZzX9PG3xP e6/2r5rxe5eF0QrB1XpKqnr8loL6PGCaQitV8= MIME-Version: 1.0 Received: by 10.216.230.152 with SMTP id j24mr223218weq.81.1299220527399; Thu, 03 Mar 2011 22:35:27 -0800 (PST) Received: by 10.216.171.131 with HTTP; Thu, 3 Mar 2011 22:35:27 -0800 (PST) Date: Fri, 4 Mar 2011 15:35:27 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [dnsext] RFC3596: A/AAAA records and additional section processing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 06:34:21 -0000 Hi all, I have a small question about the IPv6 resource records extension (RFC3596)= . As section 2.3 states: =AB=A0A type AAAA query does not trigger additional section processing.=A0= =BB. Fine. But I noticed that some DNS servers (like the one installed on my server, a bind 9.7.2) would return the A records in additional section on a AAAA query and AAAA records in additional on A queries. And when I thought about this, I realized it was a pretty good logics. Usually when people will try to contact a server, they will want both A and AAAA records. So the question is: why wouldn't this be standard? Thanks. Jehan From colm@allcosts.net Thu Mar 3 22:49:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F64D3A6843 for ; Thu, 3 Mar 2011 22:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4KriI6mlnQ3 for ; Thu, 3 Mar 2011 22:49:39 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6D1683A672F for ; Thu, 3 Mar 2011 22:49:38 -0800 (PST) Received: by fxm15 with SMTP id 15so1979436fxm.31 for ; Thu, 03 Mar 2011 22:50:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.79.78 with SMTP id o14mr281834fak.110.1299221446232; Thu, 03 Mar 2011 22:50:46 -0800 (PST) Received: by 10.223.95.203 with HTTP; Thu, 3 Mar 2011 22:50:46 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Mar 2011 22:50:46 -0800 Message-ID: From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: =?ISO-8859-1?Q?Jehan_Pag=E8s?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC3596: A/AAAA records and additional section processing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 06:49:41 -0000 The good news is that it is standard - section 3 of the same RFC says; "3. Modifications to existing query types All existing query types that perform type A additional section processing, i.e., name server (NS), location of services (SRV) and mail exchange (MX) query types, must be redefined to perform both type A and type AAAA additional section processing. These definitions mean that a name server must add any relevant IPv4 addresses and any relevant IPv6 addresses available locally to the additional section of a response when processing any one of the above queries." (e.g. dig MX example.stdlib.net @ns-191.awsdns-23.com.) . The section you've quoted is just pointing out that a query for a q-tuple of type AAAA would not normally by itself trigger any additional-section processing. As worded, I think it's actually wrong. A query of type AAAA might trigger additional section processing if the query arrives at the parent of a delegated zone. For example the query; dig AAAA www.google.com @a.root-servers.net. plainly does trigger additional section processing. (though one might argue it was the name, not the type, that pulled the trigger). 2011/3/3 Jehan Pag=E8s : > Hi all, > > I have a small question about the IPv6 resource records extension (RFC359= 6). > As section 2.3 states: > =AB=A0A type AAAA query does not trigger additional section processing.= =A0=BB. Fine. > > But I noticed that some DNS servers (like the one installed on my > server, a bind 9.7.2) would return the A records in additional section > on a AAAA query and AAAA records in additional on A queries. > And when I thought about this, I realized it was a pretty good logics. > Usually when people will try to contact a server, they will want both > A and AAAA records. > So the question is: why wouldn't this be standard? > Thanks. > > Jehan > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --=20 Colm From marka@isc.org Thu Mar 3 23:00:53 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445963A691F for ; Thu, 3 Mar 2011 23:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfaMD2FTNV13 for ; Thu, 3 Mar 2011 23:00:52 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id CF7E03A68B8 for ; Thu, 3 Mar 2011 23:00:51 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 624F05F983B; Fri, 4 Mar 2011 07:01:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 66916216C22; Fri, 4 Mar 2011 07:01:43 +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 55FE0BA8196; Fri, 4 Mar 2011 18:01:41 +1100 (EST) To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= From: Mark Andrews References: In-reply-to: Your message of "Thu, 03 Mar 2011 22:50:46 -0800." Date: Fri, 04 Mar 2011 18:01:41 +1100 Message-Id: <20110304070141.55FE0BA8196@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC3596: A/AAAA records and additional section processing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 07:00:53 -0000 In message , =?IS O-8859-1?Q?Colm_MacC=E1rthaigh?= writes: > The good news is that it is standard - section 3 of the same RFC says; > > "3. Modifications to existing query types > > All existing query types that perform type A additional section > processing, i.e., name server (NS), location of services (SRV) and > mail exchange (MX) query types, must be redefined to perform both > type A and type AAAA additional section processing. These > definitions mean that a name server must add any relevant IPv4 > addresses and any relevant IPv6 addresses available locally to the > additional section of a response when processing any one of the above > queries." > > (e.g. dig MX example.stdlib.net @ns-191.awsdns-23.com.) . > > The section you've quoted is just pointing out that a query for a > q-tuple of type AAAA would not normally by itself trigger any > additional-section processing. As worded, I think it's actually wrong. > A query of type AAAA might trigger additional section processing if > the query arrives at the parent of a delegated zone. For example the > query; > > dig AAAA www.google.com @a.root-servers.net. > > plainly does trigger additional section processing. (though one might > argue it was the name, not the type, that pulled the trigger). No. That is not addition section processing. That is referral processing. Additional section processing would be returning A and AAAA to NS queries. > 2011/3/3 Jehan Pag=E8s : > > Hi all, > > > > I have a small question about the IPv6 resource records extension (RFC359= > 6). > > As section 2.3 states: > > =AB=A0A type AAAA query does not trigger additional section processing.= > =A0=BB. Fine. > > > > But I noticed that some DNS servers (like the one installed on my > > server, a bind 9.7.2) would return the A records in additional section > > on a AAAA query and AAAA records in additional on A queries. > > And when I thought about this, I realized it was a pretty good logics. > > Usually when people will try to contact a server, they will want both > > A and AAAA records. > > So the question is: why wouldn't this be standard? > > Thanks. > > > > Jehan > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > > > > > -- = > > Colm > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jehan.marmottard@gmail.com Thu Mar 3 23:12:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757693A696D for ; Thu, 3 Mar 2011 23:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfSyUPpxXlmi for ; Thu, 3 Mar 2011 23:12:07 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0901B3A697F for ; Thu, 3 Mar 2011 23:11:39 -0800 (PST) Received: by wwb22 with SMTP id 22so1741974wwb.13 for ; Thu, 03 Mar 2011 23:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gqGoOzqQ2IGOGsKRyPtjj7ncWUyB79DkcTbshr5tAbQ=; b=DlGFDhUu6HKv70TobwFC2Ff8bppRw5uzOzoP9gT53ocJ6Pl1fnjnz8QezqEiRw11WJ 2ZiuDjHK4Hj78//LeCO3mR9iXfEEftmqZqeR2w6lFBzUSnT26Ct8QkEioI75HLX/wqTQ xK2BkKXi+R6ET8jGiEJtMiD4UfXB84qvfqDKg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TZPYE0brQ3gIGtGg/l+SrAmccDYb/8f9Gzu6AdozWyIHLx1cgFcOqKNg+BpvcRWVJR sFDca3YSMWajogyLqY6cwOmfQupjrXhbuqYnBUCGJS0QOgx13idac584vyy98Zy8wEk4 nm/+Hfigl5dNxS/FdF1QRjoR5xclyo7CBPu8w= MIME-Version: 1.0 Received: by 10.216.230.21 with SMTP id i21mr245324weq.111.1299222754097; Thu, 03 Mar 2011 23:12:34 -0800 (PST) Received: by 10.216.171.131 with HTTP; Thu, 3 Mar 2011 23:12:34 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Mar 2011 16:12:34 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC3596: A/AAAA records and additional section processing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 07:12:08 -0000 Hi, 2011/3/4 Colm MacC=E1rthaigh : > The good news is that it is standard - section 3 of the same RFC says; > > "3. Modifications to existing query types > > =A0 All existing query types that perform type A additional section > =A0 processing, i.e., name server (NS), location of services (SRV) and > =A0 mail exchange (MX) query types, must be redefined to perform both > =A0 type A and type AAAA additional section processing. =A0These > =A0 definitions mean that a name server must add any relevant IPv4 > =A0 addresses and any relevant IPv6 addresses available locally to the > =A0 additional section of a response when processing any one of the above > =A0 queries." > > (e.g. dig MX example.stdlib.net @ns-191.awsdns-23.com.) . > > The section you've quoted is just pointing out that a query for a > q-tuple of type AAAA would not normally by itself trigger any > additional-section processing. As worded, I think it's actually wrong. > A query of type AAAA might trigger additional section processing if > the query arrives at the parent of a delegated zone. For example the > query; I did read this section you quote but from my understanding this is a different case. It says that if some query already makes *A additional section processing*, then it should do both A and AAAA additional section processing. Hence the examples: NS, SRV, MX which all do A additional section processing. This is not what I am talking about. I am talking about *direct* A query (answer section) and *direct* AAAA query. And I believe the section I quoted is the one answering how it is currently standardized: no additional section processing. > dig AAAA www.google.com @a.root-servers.net. > > plainly does trigger additional section processing. (though one might > argue it was the name, not the type, that pulled the trigger). That's what I say. Some servers out there already do this because that indeed seems so logical. And I agree with this behavior. Simply this is not the standardized recommended behavior. This is why I ask why, and maybe we could make it the default standardized behavior unless someone comes up with good reasons against. Jehan > 2011/3/3 Jehan Pag=E8s : >> Hi all, >> >> I have a small question about the IPv6 resource records extension (RFC35= 96). >> As section 2.3 states: >> =AB=A0A type AAAA query does not trigger additional section processing.= =A0=BB. Fine. >> >> But I noticed that some DNS servers (like the one installed on my >> server, a bind 9.7.2) would return the A records in additional section >> on a AAAA query and AAAA records in additional on A queries. >> And when I thought about this, I realized it was a pretty good logics. >> Usually when people will try to contact a server, they will want both >> A and AAAA records. >> So the question is: why wouldn't this be standard? >> Thanks. >> >> Jehan >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >> > > > > -- > Colm > From colm@allcosts.net Thu Mar 3 23:12:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FAF3A69A4 for ; Thu, 3 Mar 2011 23:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KahrS2efvnhQ for ; Thu, 3 Mar 2011 23:12:08 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 3A81C3A692D for ; Thu, 3 Mar 2011 23:12:07 -0800 (PST) Received: by fxm15 with SMTP id 15so1990790fxm.31 for ; Thu, 03 Mar 2011 23:13:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.15.217 with SMTP id l25mr344854faa.15.1299222789061; Thu, 03 Mar 2011 23:13:09 -0800 (PST) Received: by 10.223.95.203 with HTTP; Thu, 3 Mar 2011 23:13:09 -0800 (PST) In-Reply-To: <20110304070141.55FE0BA8196@drugs.dv.isc.org> References: <20110304070141.55FE0BA8196@drugs.dv.isc.org> Date: Thu, 3 Mar 2011 23:13:09 -0800 Message-ID: From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC3596: A/AAAA records and additional section processing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 07:12:18 -0000 2011/3/3 Mark Andrews : >> dig AAAA www.google.com @a.root-servers.net. >> >> plainly does trigger additional section processing. (though one might >> argue it was the name, not the type, that pulled the trigger). > > No. That is not addition section processing. =A0That is referral > processing. > > Additional section processing would be returning A and AAAA to > NS queries. dig AAAA www.google.com @a.root-servers.net. and dig NS www.google.com @a.root-servers.net. return literally byte-identical responses after the question section. dig NS com @a.root-servers.net. too (with EDNS enabled). I find it hard to reason about what the difference= is. --=20 Colm From bortzmeyer@nic.fr Fri Mar 4 01:14:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE253A68B3 for ; Fri, 4 Mar 2011 01:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.129 X-Spam-Level: X-Spam-Status: No, score=-110.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUcy14hXQ4KO for ; Fri, 4 Mar 2011 01:14:47 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id 74EC13A6933 for ; Fri, 4 Mar 2011 01:14:47 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 47B121C0111; Fri, 4 Mar 2011 10:15:55 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 433ED1C0106; Fri, 4 Mar 2011 10:15:55 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 37F555680AD; Fri, 4 Mar 2011 10:15:55 +0100 (CET) Date: Fri, 4 Mar 2011 10:15:55 +0100 From: Stephane Bortzmeyer To: Tony Finch Message-ID: <20110304091555.GA11147@nic.fr> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 6.0 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 09:14:48 -0000 On Thu, Mar 03, 2011 at 11:18:33AM +0000, Tony Finch wrote a message of 37 lines which said: > There is no specification for how to validate the TLS certificate > for an MX server, and it is not obvious what such a specification > should say. RFC 3207, section 4.1 ? Also, in the RFC editor queue: http://www.rfc-editor.org/queue.html#draft-saintandre-tls-server-id-check From ajs@shinkuro.com Fri Mar 4 04:02:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD673A6994 for ; Fri, 4 Mar 2011 04:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id an7wdDzLpNCQ for ; Fri, 4 Mar 2011 04:02:43 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id AC2163A68A2 for ; Fri, 4 Mar 2011 04:02:43 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E80551ECB41D for ; Fri, 4 Mar 2011 12:03:50 +0000 (UTC) Date: Fri, 4 Mar 2011 07:03:49 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110304120348.GE16012@shinkuro.com> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <4D703A35.9080207@necom830.hpcl.titech.ac.jp> <4D705952.6000409@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D705952.6000409@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 12:02:44 -0000 No hat. On Fri, Mar 04, 2011 at 12:15:30PM +0900, Masataka Ohta wrote: > Thus, while CNAME (and BNAME) chains should be discouraged, > it should be explicitly allowed to use CNAME as a target of > PTR, MX, SVR and so on which does not cause recursion loops, > which is useful for name based differentiation of a service > on a single host. I'm not sure I fully agree (or don't -- I just don't know) with your reasoning, but even if I did I don't believe we could handle this as an erratum. Too many implementations have depended on the "no CNAME target" rule to write off all that history as collective misreading of the spec. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From marka@isc.org Fri Mar 4 04:02:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476593A69BA for ; Fri, 4 Mar 2011 04:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W94wo0uiMsx6 for ; Fri, 4 Mar 2011 04:02:49 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 603523A68A2 for ; Fri, 4 Mar 2011 04:02:49 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0882B5F983B; Fri, 4 Mar 2011 12:03:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 3CE92216C1E; Fri, 4 Mar 2011 12:03:40 +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 83BE5BA8837; Fri, 4 Mar 2011 23:03:36 +1100 (EST) To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= From: Mark Andrews References: <20110304070141.55FE0BA8196@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 03 Mar 2011 23:13:09 -0800." Date: Fri, 04 Mar 2011 23:03:36 +1100 Message-Id: <20110304120336.83BE5BA8837@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC3596: A/AAAA records and additional section processing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 12:02:50 -0000 In message , =?IS O-8859-1?Q?Colm_MacC=E1rthaigh?= writes: > 2011/3/3 Mark Andrews : > >> dig AAAA www.google.com @a.root-servers.net. > >> > >> plainly does trigger additional section processing. (though one might > >> argue it was the name, not the type, that pulled the trigger). > > > > No. That is not addition section processing. =A0That is referral > > processing. > > > > Additional section processing would be returning A and AAAA to > > NS queries. > > dig AAAA www.google.com @a.root-servers.net. > > and > > dig NS www.google.com @a.root-servers.net. > > return literally byte-identical responses after the question section. > > dig NS com @a.root-servers.net. > > too (with EDNS enabled). I find it hard to reason about what the difference= > is. They are all referrals. "dig NS com @a.gtld-servers.net" triggers additional section processing. Yes address records get added in both cases but only in the second are they optional. > --=20 > Colm -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Niall.oReilly@ucd.ie Fri Mar 4 04:35:53 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091343A6994 for ; Fri, 4 Mar 2011 04:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mDcGnM+Qhu5 for ; Fri, 4 Mar 2011 04:35:52 -0800 (PST) Received: from mx4.ucd.ie (angel.ucd.ie [137.43.231.112]) by core3.amsl.com (Postfix) with ESMTP id 02C4A3A6784 for ; Fri, 4 Mar 2011 04:35:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIRAAFscE3BAail/2dsb2JhbACCRZYhjX10vk6FYQSPZg X-IronPort-AV: E=Sophos;i="4.62,263,1297036800"; d="scan'208";a="2701948" Received: from dhcp-c101a8a5.ucd.ie ([193.1.168.165]) by smtp.ucd.ie with ESMTP/TLS/AES128-SHA; 04 Mar 2011 12:37:00 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Niall O'Reilly In-Reply-To: <20110303213145.2B252B9FEA4@drugs.dv.isc.org> Date: Fri, 4 Mar 2011 12:37:01 +0000 Content-Transfer-Encoding: 7bit Message-Id: <8FB693D1-30E2-4A50-B793-6B023B971E16@ucd.ie> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <20110303133541.C19B6B9E307@drugs.dv.isc.org> <20110303144600.11178B9E772@drugs.dv.isc.org> <20110303213145.2B252B9FEA4@drugs.dv.isc.org> To: dnsext@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 12:35:53 -0000 On 3 Mar 2011, at 21:31, Mark Andrews wrote: > BECAUSE YOU CAN'T SECURE INTER SITE SMTP WITH OUT BOTH SECURING THE > MX/A/AAAA LOOKUPS *AND* THE TCP CONNECTION THE SMTP TRANSACTION > GOES OVER. Did you really need to shout, Mark? By the way, I appreciate the courtesy of a personal reply (from quite a few posters, not just MarkA), but would appreciate it even more if I received only the list copy. Thanks all round Niall From mohta@necom830.hpcl.titech.ac.jp Fri Mar 4 05:53:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632523A69D7 for ; Fri, 4 Mar 2011 05:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKu6LFXWjooO for ; Fri, 4 Mar 2011 05:53:38 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 6D00F3A67F0 for ; Fri, 4 Mar 2011 05:53:38 -0800 (PST) Received: (qmail 94901 invoked from network); 4 Mar 2011 14:09:25 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 4 Mar 2011 14:09:25 -0000 Message-ID: <4D70EEF7.8030506@necom830.hpcl.titech.ac.jp> Date: Fri, 04 Mar 2011 22:53:59 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <4D703A35.9080207@necom830.hpcl.titech.ac.jp> <4D705952.6000409@necom830.hpcl.titech.ac.jp> <20110304120348.GE16012@shinkuro.com> In-Reply-To: <20110304120348.GE16012@shinkuro.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 13:53:39 -0000 Andrew Sullivan wrote: > Too many implementations have depended on the "no CNAME > target" rule For example? Masataka Ohta From ajs@shinkuro.com Fri Mar 4 06:43:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C517F3A6864 for ; Fri, 4 Mar 2011 06:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R03Q9PQN4FSZ for ; Fri, 4 Mar 2011 06:43:56 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 131B93A6834 for ; Fri, 4 Mar 2011 06:43:56 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 320BC1ECB41D for ; Fri, 4 Mar 2011 14:45:04 +0000 (UTC) Date: Fri, 4 Mar 2011 09:45:02 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110304144502.GD16703@shinkuro.com> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <4D703A35.9080207@necom830.hpcl.titech.ac.jp> <4D705952.6000409@necom830.hpcl.titech.ac.jp> <20110304120348.GE16012@shinkuro.com> <4D70EEF7.8030506@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D70EEF7.8030506@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 14:43:56 -0000 On Fri, Mar 04, 2011 at 10:53:59PM +0900, Masataka Ohta wrote: > > For example? I've been led to believe, at least, that there are mail servers that are grouchy about this. Certainly, I know mail implementers who are grouchy about it. -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From vixie@isc.org Fri Mar 4 07:27:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2085E3A69BB for ; Fri, 4 Mar 2011 07:27:45 -0800 (PST) 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=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1SvT+CeEKoK for ; Fri, 4 Mar 2011 07:27:22 -0800 (PST) Received: from nsa.vix.com (nsa.vix.com [204.152.187.111]) by core3.amsl.com (Postfix) with ESMTP id 737B83A696C for ; Fri, 4 Mar 2011 07:27:22 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 092F4A1055 for ; Fri, 4 Mar 2011 15:28:00 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Fri, 04 Mar 2011 07:03:49 EST." <20110304120348.GE16012@shinkuro.com> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <4D703A35.9080207@necom830.hpcl.titech.ac.jp> <4D705952.6000409@necom830.hpcl.titech.ac.jp> <20110304120348.GE16012@shinkuro.com> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Fri, 04 Mar 2011 15:27:59 +0000 Message-ID: <91781.1299252479@nsa.vix.com> Subject: Re: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:27:45 -0000 > Date: Fri, 4 Mar 2011 07:03:49 -0500 > From: Andrew Sullivan > > ... I don't believe we could handle this as an erratum. Too many > implementations have depended on the "no CNAME target" rule to write > off all that history as collective misreading of the spec. +1. From nweaver@icsi.berkeley.edu Fri Mar 4 07:36:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 709973A6906 for ; Fri, 4 Mar 2011 07:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSP2+E5-yYm3 for ; Fri, 4 Mar 2011 07:36:28 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id C3EEC3A6893 for ; Fri, 4 Mar 2011 07:36:28 -0800 (PST) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 19B0A36A41A; Fri, 4 Mar 2011 07:37:38 -0800 (PST) Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Content-Type: text/plain; charset=us-ascii Message-Id: Date: Fri, 4 Mar 2011 07:37:37 -0800 To: dnsext List Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [dnsext] Question on characters in DNS lookups? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:36:29 -0000 Just to confirm, although hostnames are restricted, any octet = may be used in a label for lookups of non-hostname records (eg, TXT = records). Correct? If so, which RFC includes this? From bortzmeyer@nic.fr Fri Mar 4 07:41:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD7A3A6A3F for ; Fri, 4 Mar 2011 07:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7w3q+v8ckCE for ; Fri, 4 Mar 2011 07:41:49 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id 262923A6A38 for ; Fri, 4 Mar 2011 07:41:49 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id B8CD21C0117; Fri, 4 Mar 2011 16:42:57 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B401B1C00E7; Fri, 4 Mar 2011 16:42:57 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A81146C0001; Fri, 4 Mar 2011 16:42:57 +0100 (CET) Date: Fri, 4 Mar 2011 16:42:57 +0100 From: Stephane Bortzmeyer To: Nicholas Weaver Message-ID: <20110304154257.GA27387@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 6.0 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext List Subject: Re: [dnsext] Question on characters in DNS lookups? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:41:50 -0000 On Fri, Mar 04, 2011 at 07:37:37AM -0800, Nicholas Weaver wrote a message of 10 lines which said: > Just to confirm, although hostnames are restricted, any octet > may be used in a label for lookups of non-hostname records > (eg, TXT records). > > Correct? Yes. > If so, which RFC includes this? RFC 2181, section 11 RFC 1035, section 2.3.1 From tale@dd.org Fri Mar 4 08:37:53 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655E63A68AF for ; Fri, 4 Mar 2011 08:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k4kvVOqbZKO for ; Fri, 4 Mar 2011 08:37:52 -0800 (PST) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by core3.amsl.com (Postfix) with ESMTP id 62D003A6817 for ; Fri, 4 Mar 2011 08:37:50 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id E58DE3F452; Fri, 4 Mar 2011 11:38:58 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <19825.5538.621538.653927@gro.dd.org> Date: Fri, 4 Mar 2011 11:38:58 -0500 From: Dave Lawrence To: dnsext@ietf.org In-Reply-To: References: <20110304070141.55FE0BA8196@drugs.dv.isc.org> X-Mailman-Approved-At: Fri, 04 Mar 2011 10:29:58 -0800 Subject: Re: [dnsext] RFC3596: A/AAAA records and additional section processing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:41:53 -0000 Colm MacC=E1rthaigh writes: > 2011/3/3 Mark Andrews : > > No. That is not addition section processing. =A0That is referral > > processing. Additional section processing would be returning A > > and AAAA to NS queries. >=20 > dig AAAA www.google.com @a.root-servers.net. > and > dig NS www.google.com @a.root-servers.net. > return literally byte-identical responses after the question section.= >=20 > I find it hard to reason about what the difference is. At a delegating parent there is no meaningful difference because the referral processing will always happen before additional processing can even be considered. There's quite a meaningful difference at the actual authority, however. dig a www.google.com @ns1.google.com dig aaaa www.google.com @ns1.google.com dig ns www.google.com @ns1.google.com From tale@dd.org Fri Mar 4 08:41:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9238F3A6817 for ; Fri, 4 Mar 2011 08:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwsXivps21AR for ; Fri, 4 Mar 2011 08:41:20 -0800 (PST) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by core3.amsl.com (Postfix) with ESMTP id C644C3A67AF for ; Fri, 4 Mar 2011 08:41:20 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id ABCA93F444; Fri, 4 Mar 2011 11:42:29 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19825.5749.587121.304394@gro.dd.org> Date: Fri, 4 Mar 2011 11:42:29 -0500 From: Dave Lawrence To: dnsext@ietf.org In-Reply-To: <19825.5538.621538.653927@gro.dd.org> References: <20110304070141.55FE0BA8196@drugs.dv.isc.org> <19825.5538.621538.653927@gro.dd.org> X-Mailman-Approved-At: Fri, 04 Mar 2011 10:29:58 -0800 Subject: Re: [dnsext] RFC3596: A/AAAA records and additional section processing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:42:09 -0000 Dave Lawrence just sent: > At a delegating parent there is no meaningful difference because the > referral processing will always happen before additional processing > can even be considered. > > There's quite a meaningful difference at the actual authority, > however. > > dig a www.google.com @ns1.google.com > dig aaaa www.google.com @ns1.google.com > dig ns www.google.com @ns1.google.com Or to illustrate the point a bit better by using the actual zone cut, these all have three distinctly different replies: dig a google.com @ns1.google.com dig aaaa google.com @ns1.google.com dig ns google.com @ns1.google.com Neither qtype A nor AAAA triggers additional section processing. NS does. From jehan.marmottard@gmail.com Fri Mar 4 10:47:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC173A687E for ; Fri, 4 Mar 2011 10:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1IwZjkt31nN for ; Fri, 4 Mar 2011 10:47:22 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9B0783A6818 for ; Fri, 4 Mar 2011 10:47:22 -0800 (PST) Received: by wyb42 with SMTP id 42so2584030wyb.31 for ; Fri, 04 Mar 2011 10:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=l0YU42vY5QtLJgBEIj/PWZ+j+8pAqcZQeMp3yBDc08I=; b=tRQvqKoPqQwoO3AE1k/EJ2y5n4zPvw5VPa6w5xXBCW+JwJfFEkIo17/uG9jjdXueZO DLfuNbvvfWb7cSm660t+xa/ihHcNymUJAq1gnpqAzjDr3/CNmcrrT20V2K/cBV7lheyj E7eDBBQqW/N3GQcdtPnvleebWTJNaFTVeXakY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=pXmvRZHGxhQEcuRtfs3wPJzZQEtlNI1bUT3VOTE3SEuGTcMQgpHqrO9YpEVzv27Cly hpKGHhcYO3VwrFTfnG0iusOcnQSsRmr+5bLkhtWgB2QgTmVbW8JrzVKnjehzouEQ0aij plS9My631c7sQb0d8AbnhaHmSwG1WcGbVOVx4= MIME-Version: 1.0 Received: by 10.216.230.21 with SMTP id i21mr904121weq.111.1299264511052; Fri, 04 Mar 2011 10:48:31 -0800 (PST) Received: by 10.216.171.131 with HTTP; Fri, 4 Mar 2011 10:48:31 -0800 (PST) In-Reply-To: <19825.5749.587121.304394@gro.dd.org> References: <20110304070141.55FE0BA8196@drugs.dv.isc.org> <19825.5538.621538.653927@gro.dd.org> <19825.5749.587121.304394@gro.dd.org> Date: Sat, 5 Mar 2011 03:48:31 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] RFC3596: A/AAAA records and additional section processing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 18:47:23 -0000 Hi, On Sat, Mar 5, 2011 at 1:42 AM, Dave Lawrence wrote: > Neither qtype A nor AAAA triggers additional section processing. =A0NS do= es. Indeed. So what about the idea of proposing an update to this? I think that it seems a pretty good and logical idea to trigger an A additional section processing for AAAA and vis-versa. Don't you think? Regards, Jehan From marka@isc.org Fri Mar 4 14:05:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33FF928C0EA for ; Fri, 4 Mar 2011 14:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[AWL=3.596, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToCFq7OEsqvH for ; Fri, 4 Mar 2011 14:05:53 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by core3.amsl.com (Postfix) with ESMTP id 6932C28C0E6 for ; Fri, 4 Mar 2011 14:05:53 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id AD84BC941A; Fri, 4 Mar 2011 22:05:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 4BD7B216C1E; Fri, 4 Mar 2011 22:05:37 +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 4F9BBBAA5ED; Sat, 5 Mar 2011 09:05:31 +1100 (EST) To: Stephane Bortzmeyer From: Mark Andrews References: <20110304154257.GA27387@nic.fr> In-reply-to: Your message of "Fri, 04 Mar 2011 16:42:57 BST." <20110304154257.GA27387@nic.fr> Date: Sat, 05 Mar 2011 09:05:31 +1100 Message-Id: <20110304220531.4F9BBBAA5ED@drugs.dv.isc.org> Cc: dnsext List Subject: Re: [dnsext] Question on characters in DNS lookups? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 22:05:54 -0000 In message <20110304154257.GA27387@nic.fr>, Stephane Bortzmeyer writes: > On Fri, Mar 04, 2011 at 07:37:37AM -0800, > Nicholas Weaver wrote > a message of 10 lines which said: > > > Just to confirm, although hostnames are restricted, any octet > > may be used in a label for lookups of non-hostname records > > (eg, TXT records). > > > > Correct? > > Yes. More correctly the DNS does not place restrictions. The DNS is a storage device. The users of the DNS may place restrictions. Hostnames have restrictions RFC 952. Mail domains have restrictions RFC 822 and its successors. > > If so, which RFC includes this? > > RFC 2181, section 11 > RFC 1035, section 2.3.1 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohta@necom830.hpcl.titech.ac.jp Fri Mar 4 14:21:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FE53A6869 for ; Fri, 4 Mar 2011 14:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8DZjxqsyeRR for ; Fri, 4 Mar 2011 14:21:19 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 8658C3A6784 for ; Fri, 4 Mar 2011 14:21:19 -0800 (PST) Received: (qmail 5352 invoked from network); 4 Mar 2011 22:37:25 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 4 Mar 2011 22:37:25 -0000 Message-ID: <4D7165EC.5090904@necom830.hpcl.titech.ac.jp> Date: Sat, 05 Mar 2011 07:21:32 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <4D703A35.9080207@necom830.hpcl.titech.ac.jp> <4D705952.6000409@necom830.hpcl.titech.ac.jp> <20110304120348.GE16012@shinkuro.com> <4D70EEF7.8030506@necom830.hpcl.titech.ac.jp> <20110304144502.GD16703@shinkuro.com> In-Reply-To: <20110304144502.GD16703@shinkuro.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 22:21:20 -0000 Andrew Sullivan wrote: >> For example? > > I've been led to believe, at least, that there are mail servers that > are grouchy about this. For example? > Certainly, I know mail implementers who are > grouchy about it. It means that they are grouchy because they must support it, as RFC 1034 requires so. The issue is classified merely as a minor issue even at the time when RFC974 was written (mail routing was a lot more complex than today): Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. And the situation today, by Tony Finch, is: > RFC 821 is thorougly obsolete. In particular the canonicalization > requirements that existed in the 1980s were relaxed in the 1990s and no > longer apply. So, my question is: Where is an example for your statement? Masataka Ohta From Ed.Lewis@neustar.biz Sat Mar 5 07:46:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645153A6A8A for ; Sat, 5 Mar 2011 07:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuPum0fQziGB for ; Sat, 5 Mar 2011 07:46:02 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 28B8F3A6A78 for ; Sat, 5 Mar 2011 07:46:02 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p25Fl4Yt004457; Sat, 5 Mar 2011 10:47:04 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.103] by Work-Laptop-2.local (PGP Universal service); Sat, 05 Mar 2011 10:47:11 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Sat, 05 Mar 2011 10:47:11 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110304220531.4F9BBBAA5ED@drugs.dv.isc.org> References: <20110304154257.GA 27387@nic.fr> <20110304220531.4F9BBBAA5ED@drugs.dv.isc.org> Date: Sat, 5 Mar 2011 10:45:54 -0500 To: dnsext List From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-912782471==_ma============" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Question on characters in DNS lookups? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 15:46:03 -0000 --============_-912782471==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:05 +1100 3/5/11, Mark Andrews wrote: >More correctly the DNS does not place restrictions. The DNS is >a storage device. The users of the DNS may place restrictions. > >Hostnames have restrictions RFC 952. >Mail domains have restrictions RFC 822 and its successors. Mark, What's your take on this: In some places an RR's RDATA needs a domain name and in some places it calls for a host name. The value of CNAME record is a domain name. The value of an NS record is a host name. The "target" of an MX record is a host name. The difference in these three cases is - in a CNAME the target is a location in the tree, not a host. For a NS, the target is a host but one that is being accessed by DNS implementations. For the latter, the MX, the target is a host to be contacted by a SMTP implementation - which seem to be quite finicky things when it comes to host syntax. In light of this, I choose to limit the RDATA of MX records to host name rules, and NS too for convenience but let the CNAME be any 8-bit value. The original question mentioned questions - the owner name in a question (and all sections) can have any 8-bit value. I'm asking if you think there should be restrictions on what's in RDATA. I checked STD 13 and found this, this is where I got my idea years ago: # CNAME a domain name. # # MX a 16 bit preference value (lower is # better) followed by a host name willing # to act as a mail exchange for the owner # domain. # # NS a host name. In this case, the NS is said to be a host, not domain, name. From that, I would say that the DNS does place restrictions - but only within some RDATA specifications. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" --============_-912782471==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] Question on characters in DNS lookups?
At 9:05 +1100 3/5/11, Mark Andrews wrote:

>More correctly the DNS does not place restrictions.  The DNS is
>a storage device.  The users of the DNS may place restrictions.
>
>Hostnames have restrictions RFC 952.
>Mail domains have restrictions RFC 822 and its successors.

Mark,

What's your take on this:

In some places an RR's RDATA needs a domain name and in some places it calls for a host name.  The value of CNAME record is a domain name.  The value of an NS record is a host name.  The "target" of an MX record is a host name.

The difference in these three cases is - in a CNAME the target is a location in the tree, not a host.  For a NS, the target is a host but one that is being accessed by DNS implementations.  For the latter, the MX, the target is a host to be contacted by a SMTP implementation - which seem to be quite finicky things when it comes to host syntax.

In light of this, I choose to limit the RDATA of MX records to host name rules, and NS too for convenience but let the CNAME be any 8-bit value.

The original question mentioned questions - the owner name in a question (and all sections) can have any 8-bit value.  I'm asking if you think there should be restrictions on what's in RDATA.

I checked STD 13 and found this, this is where I got my idea years ago:

#                CNAME           a domain name.
#
#                MX              a 16 bit preference value (lower is
#                                better) followed by a host name willing
#                                to act as a mail exchange for the owner
#                                domain.
#
#                NS              a host name.

In this case, the NS is said to be a host, not domain, name. From that, I would say that the DNS does place restrictions - but only within some RDATA specifications.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"
--============_-912782471==_ma============-- From brian.peter.dickson@gmail.com Sat Mar 5 10:40:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27AE43A6AA1 for ; Sat, 5 Mar 2011 10:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPekpQYwj-YZ for ; Sat, 5 Mar 2011 10:40:19 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8AE893A69C0 for ; Sat, 5 Mar 2011 10:40:19 -0800 (PST) Received: by fxm15 with SMTP id 15so3295303fxm.31 for ; Sat, 05 Mar 2011 10:41:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kjCyQOzOmkp6m8taXIikE6ZwjD8nA0JHg4cxRNvP6ME=; b=UeqVBTMwwqkzdYVceJ8oPoSqXpdVucmdTu1gky+qhKorlZ6outckn7Og9wEieDYRE+ bqSAT4LL5kHVUdu7ZfFlyOUpe9IS6NIG9t5jsBEGM1ncSJMcRF1j2/S2giXg1xM2lj7R xSgoL1UhLByC7ThlGYgGgkRpteHtkz3xdCeok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vf8dimz2bZEoGLuvY24aIFtSwos4d1Gg+bY4egefZHwl2qZvBNiD1tAGx89xyghpAA nyeUGAcJ7gOsUKl3KiAMyqkPToBNRVk4BKzYCqTyfXCAyXH9v8R9E9MM5L9gZiDZyvKW aNCxCzaoS9f+u6kbQQib/ii02+4YN0IPsDdw0= MIME-Version: 1.0 Received: by 10.223.127.210 with SMTP id h18mr40680fas.71.1299350489738; Sat, 05 Mar 2011 10:41:29 -0800 (PST) Received: by 10.223.108.1 with HTTP; Sat, 5 Mar 2011 10:41:29 -0800 (PST) In-Reply-To: <20110304050809.E7F09BA7287@drugs.dv.isc.org> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <4D703A35.9080207@necom830.hpcl.titech.ac.jp> <4D705952.6000409@necom830.hpcl.titech.ac.jp> <20110304050809.E7F09BA7287@drugs.dv.isc.org> Date: Sat, 5 Mar 2011 14:41:29 -0400 Message-ID: From: Brian Dickson To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 18:40:21 -0000 On Fri, Mar 4, 2011 at 1:08 AM, Mark Andrews wrote: > > In message <4D705952.6000409@necom830.hpcl.titech.ac.jp>, Masataka Ohta w= rites: >> CNAME as a target of NS should also be discouraged, because >> it may cause recursion loop to be resolved by glue, which >> requires unnecessarily complex operations. > > CNAME as the target of a NS does not work reliably. =A0To make it > work reliably you would have to change the additional processing > rules in every deployed nameserver. =A0You would also have to change > glue to include CNAME records. Given that there are things that you (can't, or) shouldn't use CNAMEs for..= . Let's flip the (implied) question around, then. Are there things that either *require*, or can *only* be done with, CNAMEs? I'll give an example of replacing CNAMEs with something else, and we can use that as a kind of straw man, for these purposes. (Caveat - yes, I know there are DNSSEC implications to the following. Let's set aside DNSSEC for now, and address those issues a bit later.) (BTW - this is from http://tools.ietf.org/html/draft-dickson-dnsext-ds2-01 appendix A.2.1) Instead of having a CNAME: alias.example.com CNAME real.example.com. real.example.com TXT "This is real data, maintained in a single location= ." have a *zone cut* (on both the "CNAME"-wannabe, and on the would-be CNAME target) with all the RR's which would have been found at the target owner name, in the new zone's apex: alias.example.com NS ns1.example.com (on ns1.example.com) named.conf (with implicit $ORIGIN of zone.name): zone alias.example.com { master; file=3D"czone-data.example.com";}; zone real.example.com { master; file=3D"czone-data.example.com";}; file czone-data.example.com: @ SOA ns1.example.com. postmaster ( 42 7200 600 3600000 60 ) NS ns1.example.com TXT "This is real data, maintained in a single location." NB - the exact same mechanism, logic, and format, happens to work for DNAME, so the result is this allows for unified replacement of both CNAME and DNAME with this, and thus implicitly pre-emptively replaces BNAME (!!). There are some real benefits to using this over CNAME. CNAME targets are not necessarily aware that they *are* CNAME targets, and there's no easy way to determine that something is a CNAME target. On the other hand, both the parent and child side of a zone cut are aware of the zone cut, and both sides have mechanisms for validating state (lame delegation checks, and zone loading validation logic for both loading and pre-load checking). This becomes more important, the more aliases get added (esp. for the ongoing aliases requirements) and/or the more aliases point to a single target (e.g. web hosting). Is there anything in the above, that would prevent the use of "alias.example.com" as RDATA in any RR type? (While it would be ambitious to do so, I think maybe it is time to put an effort into depracating both CNAME and DNAME...) Would this alternative to CNAME/DNAME make good material for a proposed BCP? (BCP -- better common practice, in this case)? Brian From johnl@iecc.com Sat Mar 5 11:19:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8DDA3A687E for ; Sat, 5 Mar 2011 11:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.755 X-Spam-Level: X-Spam-Status: No, score=-110.755 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+8ndWbFkpgH for ; Sat, 5 Mar 2011 11:19:16 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id D99DB3A67B1 for ; Sat, 5 Mar 2011 11:19:15 -0800 (PST) Received: (qmail 19264 invoked from network); 5 Mar 2011 19:20:25 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 5 Mar 2011 19:20:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=429a.4d728cf9.k1103; i=johnl@user.iecc.com; bh=s7Ak1UmJ4NklAdT2D9+i3ZnCdMR1t6KwQs/g9YpSiTE=; b=pHWogmNdQJKvMzTUmrlQuM0S4v0c5zFACTSAq+DGJo5Q8UoM+zaEMA4Sm5vtnKv6ccN765gDxiWbebnwxsDE8U55qC3bfF3nwEqV5mmU4mPZcCulZdi0NHXxb3LsGlGSwdeZq2Fq9W5NBGidsPeDRB/3j7nPTEowx/RmUc0avT8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 5 Mar 2011 19:20:25 -0000 Message-ID: <20110305192025.17049.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 19:19:17 -0000 >Instead of having a CNAME: > >alias.example.com CNAME real.example.com. >real.example.com TXT "This is real data, maintained in a single location." >have a *zone cut* You don't have to do anything that complicated. Just copy the records from the target to the address of the CNAME. > zone alias.example.com { master; file="czone-data.example.com";}; > zone real.example.com { master; file="czone-data.example.com";}; And keep in mind that not every DNS server uses BIND format control statements or zone files. In any event, this is not a new idea. We all know that in principle, anything you can do with B/C/DNAME you could do with sufficiently disciplined server management. This confirms my impression that if we're going to do any of this stuff, it's only useful as part of a system where applications can use the info in the DNS to auto-provision and make names equivalent at the application level. R's, John From mohta@necom830.hpcl.titech.ac.jp Sat Mar 5 16:29:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2328E3A6A32 for ; Sat, 5 Mar 2011 16:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaeZzLBavZD8 for ; Sat, 5 Mar 2011 16:29:03 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id DEE643A6A16 for ; Sat, 5 Mar 2011 16:29:02 -0800 (PST) Received: (qmail 31151 invoked from network); 6 Mar 2011 00:45:25 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 6 Mar 2011 00:45:25 -0000 Message-ID: <4D72D555.4060109@necom830.hpcl.titech.ac.jp> Date: Sun, 06 Mar 2011 09:29:09 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Dickson References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <4D703A35.9080207@necom830.hpcl.titech.ac.jp> <4D705952.6000409@necom830.hpcl.titech.ac.jp> <20110304050809.E7F09BA7287@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 00:29:04 -0000 Brian Dickson wrote: > Are there things that either *require*, or can *only* be > done with, CNAMEs? Aliasing. > Instead of having a CNAME: > have a *zone cut* (on both the "CNAME"-wannabe, and on the would-be Often, administrators of a canonical name and an alias are different. When a user of name based virtual hosting rent hosting and DNS service from different providers, neither the user nor the DNS service provider can know when updates occur on the canonical name. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Sat Mar 5 16:57:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC493A692D for ; Sat, 5 Mar 2011 16:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mqn3nIOf-Csi for ; Sat, 5 Mar 2011 16:57:02 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 6EDB43A68A9 for ; Sat, 5 Mar 2011 16:57:02 -0800 (PST) Received: (qmail 31369 invoked from network); 6 Mar 2011 01:13:38 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 6 Mar 2011 01:13:38 -0000 Message-ID: <4D72DBF1.6070501@necom830.hpcl.titech.ac.jp> Date: Sun, 06 Mar 2011 09:57:21 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110304154257.GA 27387@nic.fr> <20110304220531.4F9BBBAA5ED@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Question on characters in DNS lookups? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 00:57:03 -0000 Edward Lewis wrote: > # CNAME a domain name. For an example, see RFC2317, a BCP. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Sat Mar 5 17:17:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8D43A6AA7 for ; Sat, 5 Mar 2011 17:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyLPizt2JNcc for ; Sat, 5 Mar 2011 17:17:10 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 532343A6AA1 for ; Sat, 5 Mar 2011 17:17:10 -0800 (PST) Received: (qmail 31877 invoked from network); 6 Mar 2011 01:33:34 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 6 Mar 2011 01:33:34 -0000 Message-ID: <4D72E09C.4060101@necom830.hpcl.titech.ac.jp> Date: Sun, 06 Mar 2011 10:17:16 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110305192025.17049.qmail@joyce.lan> In-Reply-To: <20110305192025.17049.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [dnsext] pricing for equivalent localized domain names X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 01:17:11 -0000 John Levine wrote: > This confirms my impression that if we're going to do any of this > stuff, it's only useful as part of a system where applications can use > the info in the DNS to auto-provision and make names equivalent at the > application level. It depends. If you are selling domain names and sell several or millions of equivalent domain names at a price of a single ASCII domain name, you don't want your customer resell the domain names for many others. If you charge for each name, let the customers bother. Masataka Ohta From johnl@iecc.com Sat Mar 5 17:34:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF873A6AA1 for ; Sat, 5 Mar 2011 17:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.617 X-Spam-Level: X-Spam-Status: No, score=-110.617 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKa4JN7tjzi2 for ; Sat, 5 Mar 2011 17:34:06 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 24F453A69BE for ; Sat, 5 Mar 2011 17:34:05 -0800 (PST) Received: (qmail 92590 invoked from network); 6 Mar 2011 01:35:16 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 6 Mar 2011 01:35:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=51df.4d72e4d4.k1103; i=johnl@user.iecc.com; bh=Qo21OGW7W3zGCuWJEp157F1SuSEOAeKMYH8ErVJazHI=; b=m8ziKkXIBoE53WLMsJnXA+2cHSTe6cLW5yA5KK82HSisZqReyh5jtR5z4BPOCSVthpSzH7ttT5qK27SR66XIrvELLCl3PMoFeWuGwcO1ROuNR4mxS7aDG4QfJRPSjJjxtI+4JQJsQrAC29g04gn9NTh0F+vBUV77OgUeSbfBjYU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Mar 2011 01:35:16 -0000 Message-ID: <20110306013516.20958.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <4D72E09C.4060101@necom830.hpcl.titech.ac.jp> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] pricing for equivalent localized domain names X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 01:34:08 -0000 >If you are selling domain names and sell several or millions of >equivalent domain names at a price of a single ASCII domain name, you >don't want your customer resell the domain names for many others. That really, really does not strike me as a problem that we should try to address with a technical solution. R's, John From brian.peter.dickson@gmail.com Sat Mar 5 17:55:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5653A3A6AA1 for ; Sat, 5 Mar 2011 17:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOD8P+NmE5zv for ; Sat, 5 Mar 2011 17:55:23 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 4A9733A68CF for ; Sat, 5 Mar 2011 17:55:22 -0800 (PST) Received: by fxm15 with SMTP id 15so3441019fxm.31 for ; Sat, 05 Mar 2011 17:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UbaAlZZ4+GAoCFWCzAwJmJDhIfU1MTAQ8NaD8Hi7sNE=; b=QhN50fsKLLMos+OLngbZIZI+MRUhJUqRzz1qeVvcBCzkYKtSyHz0uOYYVjref7NkE2 CA1gnuQ/7KY3CREJ0H2DhVE2zlBpzBQh4Tln2dzdWNzIgIRwaGaoGkkDwG48i6bBGOU5 yjbTprDTU+bvRD91Iky12P8SwWNAaxDQLhQ1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vm5YLzJTGed3Sb3fQQUMXiJGhGHBxmkzcVPYNkxSxQnGa9BmPzoPn1na+vTotgM0IV lgg74AZJjR/TCRZjDUmg1ysgna5IVjUYvUSblRzCJp4BnTREMrRDFzAE6a7DljQRi2zL fVMmKt3h9jDRKBp6afGX6Jti9+s3IYIM9fLQQ= MIME-Version: 1.0 Received: by 10.223.87.75 with SMTP id v11mr663944fal.28.1299376593829; Sat, 05 Mar 2011 17:56:33 -0800 (PST) Received: by 10.223.38.24 with HTTP; Sat, 5 Mar 2011 17:56:33 -0800 (PST) In-Reply-To: <4D72D555.4060109@necom830.hpcl.titech.ac.jp> References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <4D703A35.9080207@necom830.hpcl.titech.ac.jp> <4D705952.6000409@necom830.hpcl.titech.ac.jp> <20110304050809.E7F09BA7287@drugs.dv.isc.org> <4D72D555.4060109@necom830.hpcl.titech.ac.jp> Date: Sat, 5 Mar 2011 21:56:33 -0400 Message-ID: From: Brian Dickson To: Masataka Ohta Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 01:55:24 -0000 2011/3/5 Masataka Ohta : > Brian Dickson wrote: > >> Are there things that either *require*, or can *only* be >> done with, CNAMEs? > > Aliasing. > >> Instead of having a CNAME: > >> have a *zone cut* (on both the "CNAME"-wannabe, and on the would-be > > Often, administrators of a canonical name and an alias are > different. > > When a user of name based virtual hosting rent hosting and DNS > service from different providers, neither the user nor the DNS > service provider can know when updates occur on the canonical > name. Actually, it makes *more* sense (using zone cuts) in this case. The user has the DNS service provider configured so that the particular FQDN is delegated to the hosting providers' DNS server. (Here, FQDN is the host name by which the virtual hosting for the user is configured, like www.user.example.com.) It is just the single name that is delegated, not the whole domain that the user "owns". The hosting provider then configures all their virtual hosting as needed, and feeds the information on which physical hosts match which FQDNs to their DNS provisioning engine. Each virtual host FQDN includes the zone file for the corresponding physical host, and voila, it just works. Updates to the mappings (virtual->physical) can be managed without requiring the user, or the users' DNS provider, to make any changes. Those changes happen below the corresponding zone cut, on the hosting provider's DNS infrastructure. The hosting provider already has all this information, and already has to maintain the mapping. All that changes is the particular way that gets published in DNS - CNAME vs delegated zones. Brian From mohta@necom830.hpcl.titech.ac.jp Sat Mar 5 18:14:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2C028C0F1 for ; Sat, 5 Mar 2011 18:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id it5Bcjl7ayFs for ; Sat, 5 Mar 2011 18:14:30 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id E997A28C0E4 for ; Sat, 5 Mar 2011 18:14:29 -0800 (PST) Received: (qmail 32517 invoked from network); 6 Mar 2011 02:30:46 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 6 Mar 2011 02:30:46 -0000 Message-ID: <4D72EE01.2040502@necom830.hpcl.titech.ac.jp> Date: Sun, 06 Mar 2011 11:14:25 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Levine References: <20110306013516.20958.qmail@joyce.lan> In-Reply-To: <20110306013516.20958.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] pricing for equivalent localized domain names X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 02:14:31 -0000 John Levine wrote: >> If you are selling domain names and sell several or millions of >> equivalent domain names at a price of a single ASCII domain name, you >> don't want your customer resell the domain names for many others. > > That really, really does not strike me as a problem that we should > try to address with a technical solution. The problem is that we provide a technical solution for users of ASCII domain names purchase millions of equivalent domain names: YYYYYYYYYYYYYYYYYYYYYYY.com . . . yyyyyyyyyyyyyyyyyyyyyyy.com at a price of a single ASCII domain name. Then, how can you say that users can't enjoy the same thing with a domain name containing 'y' with diaeresis, upper case of which is 'Y' *without* diaeresis, or Greek characters? The simplest and, perhaps, the fairest solution is to stick to pure ASCII. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Sat Mar 5 18:30:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ECEB3A6ACC for ; Sat, 5 Mar 2011 18:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.086 X-Spam-Level: X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGHvYIQugCjl for ; Sat, 5 Mar 2011 18:30:27 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id CF07C3A69FB for ; Sat, 5 Mar 2011 18:30:26 -0800 (PST) Received: (qmail 32964 invoked from network); 6 Mar 2011 02:47:04 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 6 Mar 2011 02:47:04 -0000 Message-ID: <4D72F1D1.1030501@necom830.hpcl.titech.ac.jp> Date: Sun, 06 Mar 2011 11:30:41 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Dickson References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <4D703A35.9080207@necom830.hpcl.titech.ac.jp> <4D705952.6000409@necom830.hpcl.titech.ac.jp> <20110304050809.E7F09BA7287@drugs.dv.isc.org> <4D72D555.4060109@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 02:30:30 -0000 Brian Dickson wrote: > The user has the DNS service provider configured so that the > particular FQDN is delegated to the hosting providers' DNS server. That's too complex not acceptable for users nor the DNS/hosting providers. For example, DNS service provider my wife is using (Yahoo Japan, a major provider in Japan) allow *advanced* users set up A, CNAME and MX but nothing else. Masataka Ohta From dougb@dougbarton.us Mon Mar 7 05:55:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66133A6967 for ; Mon, 7 Mar 2011 05:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6P+AaZK7TgK for ; Mon, 7 Mar 2011 05:55:17 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 346B63A67B4 for ; Mon, 7 Mar 2011 05:55:17 -0800 (PST) Received: (qmail 21089 invoked by uid 399); 7 Mar 2011 13:56:26 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 7 Mar 2011 13:56:26 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D74E409.1060409@dougbarton.us> Date: Mon, 07 Mar 2011 05:56:25 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 13:55:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 As promised I've managed to squeak this draft in under the wire. As I say in the Foreword I expect that it will need some polishing, and if the group chooses to adopt the document I look forward to getting lots of help with that. :) Doug http://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit-00 - -------- Original Message -------- Subject: New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 Date: Mon, 7 Mar 2011 05:47:21 -0800 (PST) From: IETF I-D Submission Tool To: dougb@dougbarton.us A new version of I-D, draft-barton-clone-dns-labels-fun-profit-00.txt has been successfully submitted by Douglas Barton and posted to the IETF repository. Filename: draft-barton-clone-dns-labels-fun-profit Revision: 00 Title: Cloning Domain Name System (DNS) Labels for Fun and Profit Creation_date: 2011-03-07 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document describes a method for making one or more Domain Name System (DNS) labels behave in the DNS "as if" they were actually an entirely different label. E.g., the delegee for the example.org zone could define bar.example.org to be a CLONE of foo.example.org. This method is designed to meet the needs of those managing Internationalized Domain Name (IDN) zones that have been determined to be semantically similar, and therefore should be treated "as if" they were identical. This method can also be used more generally to handle situations where currently either CNAME or DNAME Resource Records are being used. A key design goal for the CLONE method is that except for DNSSEC support all of the semantic benefits are available by updating the authoritative servers for the zone. Therefore unless DNSSEC support for the CLONEd zones is required there is no dependency on end users being behind a CLONE-Aware resolving name server. Foreword [RFC Editor, please remove this Section at publication time. Thanks.] This is my first draft, please be gentle. :) I'm definitely open to the possibility that there are better ways to accomplish the concepts presented herein. I'm sure that there are a non-zero number of errors in the formatting, references, etc. Also Sections 2 and 3 may be under-specified, unclear, or unworkable. So please don't be afraid to offer (constructive) criticism. TODO: Update/add/improve references? Add/improve examples? Revision History: 1. -00 Initial version The IETF Secretariat. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJNdOQJAAoJEFzGhvEaGryEBs0H/1OzHZvPwl0v7wDK2KQvNLwI tt/UDJhVZD1TDOjVKXvoApp7sYFdOMgJQG0p0tDWETKs+RK5YYj/FP48G3UZrj6T Ie47cVUwHDRxfJ+MT9So7YoCYFqAeN4/51PGWCFDkogNIcMBs+eMDKgC+95hO11S Rit58laXgTUGJaJCpFIEstj2LS2Fm+uEXjmoOmzilvBj0WnbG80cRgxkXepZZilp 4dKsB2xSBReNODReTBn4GlFETnsquqdq1DRDQpSsOtA5EjoMYxfwPdmiVRJ+v2NT pwWJT2igc4sSCcPlt8+VNQX4aUOT/6evo3U4USe+sgGOzdeZpUAY2w/pfHTTLKI= =Ef+O -----END PGP SIGNATURE----- From Ed.Lewis@neustar.biz Mon Mar 7 06:10:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B1028C0F6 for ; Mon, 7 Mar 2011 06:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZjoY-WbS053 for ; Mon, 7 Mar 2011 06:10:47 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 1807228C0E3 for ; Mon, 7 Mar 2011 06:10:47 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p27EBrhp021683; Mon, 7 Mar 2011 09:11:53 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Mon, 07 Mar 2011 09:12:00 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 07 Mar 2011 09:12:00 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D72DBF1.6070501@necom830.hpcl.titech.ac.jp> References: <20110304154257.GA 27387@nic.fr> <20110304220531.4F9BBBAA5ED@drugs.dv.isc.org> <4D72DBF1.6070501@necom830.hpcl.titech.ac.jp> Date: Mon, 7 Mar 2011 09:11:34 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Question on characters in DNS lookups? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 14:10:48 -0000 At 9:57 +0900 3/6/11, Masataka Ohta wrote: >Edward Lewis wrote: > >> # CNAME a domain name. > >For an example, see RFC2317, a BCP. Hmmph. A case of a BCP recommending actions in "violation" of a standards track document. Interesting catch...;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From Ed.Lewis@neustar.biz Mon Mar 7 06:12:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7A33A69A3 for ; Mon, 7 Mar 2011 06:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olYaLqCLF0Jw for ; Mon, 7 Mar 2011 06:12:29 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 53A913A6998 for ; Mon, 7 Mar 2011 06:12:27 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p27EDY7m021712; Mon, 7 Mar 2011 09:13:34 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Mon, 07 Mar 2011 09:13:40 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 07 Mar 2011 09:13:40 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110304154257.GA 27387@nic.fr> <20110304220531.4F9BBBAA5ED@drugs.dv.isc.org> <4D72DBF1.6070501@necom830.hpcl.titech.ac.jp> Date: Mon, 7 Mar 2011 09:13:32 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Question on characters in DNS lookups? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 14:12:30 -0000 D'oh!!! Not in violation - it's what is recommended. Gotta stop writing email while watching TV. At 9:11 -0500 3/7/11, Edward Lewis wrote: >At 9:57 +0900 3/6/11, Masataka Ohta wrote: >>Edward Lewis wrote: >> >>> # CNAME a domain name. >> >>For an example, see RFC2317, a BCP. > >Hmmph. A case of a BCP recommending actions in "violation" of a >standards track document. > >Interesting catch...;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From Internet-Drafts@ietf.org Mon Mar 7 07:15:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4998D3A67E1; Mon, 7 Mar 2011 07:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDKjLYyc-HFT; Mon, 7 Mar 2011 07:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C213A3A686E; Mon, 7 Mar 2011 07:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110307151501.996.24790.idtracker@localhost> Date: Mon, 07 Mar 2011 07:15:01 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-rfc2671bis-edns0-05.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 15:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Extension Mechanisms for DNS (EDNS0) Author(s) : J. Damas, et al. Filename : draft-ietf-dnsext-rfc2671bis-edns0-05.txt Pages : 13 Date : 2011-03-07 The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS0 specification [RFC2671] based on 10 years of deployment experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2671bis-edns0-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-07071310.I-D@ietf.org> --NextPart-- From nweaver@icsi.berkeley.edu Mon Mar 7 07:46:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FE53A67EC for ; Mon, 7 Mar 2011 07:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEHMDqZEiEeC for ; Mon, 7 Mar 2011 07:46:45 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 453F63A67E1 for ; Mon, 7 Mar 2011 07:46:45 -0800 (PST) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id DBAFE36A036; Mon, 7 Mar 2011 07:47:58 -0800 (PST) References: <4D74E409.1060409@dougbarton.us> In-Reply-To: <4D74E409.1060409@dougbarton.us> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Mon, 7 Mar 2011 07:47:58 -0800 To: Doug Barton X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 15:46:46 -0000 On Mar 7, 2011, at 5:56 AM, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > As promised I've managed to squeak this draft in under the wire. As I > say in the Foreword I expect that it will need some polishing, and if > the group chooses to adopt the document I look forward to getting lots > of help with that. :) Interesting, but a couple of comments: For the non-CLONE aware case (no EDNS0 option in query), I think instead = of returning "as if" its an alias, INSTEAD it should be a CNAME or DNAME = with TTL=3D0 with the part the authority is responsible for = canonicalized. (TTL=3D0 prevents the problems inherent for both CNAME = and DNAME combined). =20 That way, (using ASCII as an example) cLIent.othErS.myTlD DNAME cLIent.othErS.mytld TTL=3D0 otERs.mYtLD CNAME otERs.mytld TTL=3D0 Why? Because this way the systems underneath the authority in the = hierarchy don't have any worry about the canonicalization: its = precanonicalized for their viewpoint, which means if the main authority = and clients have DIFFERENT notions of canonicalization, each level in = the hierarchy does not have to concern itself about other levels in the = hierarchy, just their own. (Note, I don't know what final TTL the client will see, this is = something that needs to be checked) The more important configuration is probably the model of=20 CARNS STUB <----> Non-CARNS Resolver <---> CARNS Auth. As it is far more likely that clients will upgrade (EG, as part of the = browser or OS) rather than resolver authorities in many cases. =20 I do not know if unknown EDNS0 options are likely to be passed from the = stub to the authority through the intermediary resolver, which may = instead require doing a parallel query for a CLONE RR (akin to how A and = AAAA records are looked up in parallel by many hosts, rather than having = a 'Support IPv6' EDNS0 option.) The CLONE RR really needs to be a "canonicalization program", describing = a set of character/word transformations that should be applied, NOT just = a simple pointer.[1] This enables CLONEs to be DNSSEC signed offline. = Otherwise, if you want DNSSEC EVEN FOR CLONE-aware clients, you need = to... Discuss online signing. There is nothing which prevents the slaves from = dynamically signing and caching the results, or dynamically querying a = MASTER and caching the results (so no key distribution to the slave = authorities). The load is more than reasonable WITH caching (~100+ = signatures/cluster node/second should be reasonable to accomplish, and = such nodes should cost on the order of $.20/hr total cost amortized out = over 3 years).=20 More important, the caching can make it NOT 'single point of failure' in = practice (and thus DOS resistant in practice as well), because although = the canonicalization space is near exponential, the canonicalization in = PRACTICE is probably much smaller [2], and that smaller space in = practice could even be prefetched so online signatures are only needed = in the exceptional cases of not-seen-before biZZArO canonicalizations = being required.. [1] I believe that if CLONE is just a simple pointer, it is = unnecessary, because 0 TTL CNAMES and DNAMES can accomplish the same = thing. The value in a CLONE-type new RR and associated EDNS0 signaling = lies in allowing it to work with the offline DNSSEC signature model. [2] How to determine the canonicalization space: For a given language = and canonicalization, take a large corpus of text (probably an email = corpus would be the best, as this represents 'what people type in a = computer'), and pass it through the canonicalization. This gives you an = estimate on how canonicalization needs to happen in practice, how well = signature caching works, etc. =20 EG, (although not needed for ASCII), its clear that for ASCII only a few = canonicalizations are all that happen in practice, even if the input = space possible is huge. People type www.google.com, WWW.google.COM, = www.Google.COM, etc, NOT wWw.goOGLe.COm. From johnl@iecc.com Mon Mar 7 12:36:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F7A3A659C for ; Mon, 7 Mar 2011 12:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.786 X-Spam-Level: X-Spam-Status: No, score=-110.786 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iMRAcWi5opT for ; Mon, 7 Mar 2011 12:36:20 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 8B8ED3A657C for ; Mon, 7 Mar 2011 12:36:20 -0800 (PST) Received: (qmail 12199 invoked from network); 7 Mar 2011 20:37:33 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 7 Mar 2011 20:37:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=14903.4d75420d.k1103; i=johnl@user.iecc.com; bh=dRjL2nolRgMSqkkX7a5pJczWKO23VMvVAjPmyZtuQYw=; b=GkdlHeRT2Sz1EvdXHPhS9ytctUSqHwtPFvgPoNMYY6qiaEb5Bqc1/J11QVmFxtgDHbwa8/IniCcu5G8GAJmAMqjgXv1pbtWepwt2WBjiJ9vIPui77XUSQ0B9Fg2nvcQYZqFQlFJuFIiaeo3thBRqCoJWgHdiwydnbke7HOiV/UE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 Mar 2011 20:37:33 -0000 Message-ID: <20110307203733.84226.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <4D74E409.1060409@dougbarton.us> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 20:36:23 -0000 >Title: Cloning Domain Name System (DNS) Labels for Fun and Profit Looks promising. In section 3, why does a CARNS have to make future queries to the preferred version? Is it to improve cacheing, or is there something else about it that I'm missing? In 1.1, "truly equal" is really an application issue. From a user's point of view, if a web browser changes the name in the displayed URL to the preferred one, the names aren't equal, and if it shows what you entered, they are, regardless of what bits the DNS might have returned, Ditto mail programs changing domains in mail addresses and so forth. With that in mind, I don't see the fact that the application can tell which name is preferred as a significant issue. R's, John From dougb@dougbarton.us Mon Mar 7 17:03:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961773A685B for ; Mon, 7 Mar 2011 17:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SOxltBEoX6n for ; Mon, 7 Mar 2011 17:03:31 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 0D47F3A69BB for ; Mon, 7 Mar 2011 17:03:30 -0800 (PST) Received: (qmail 9361 invoked by uid 399); 8 Mar 2011 01:04:43 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 8 Mar 2011 01:04:43 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D7580A9.3060100@dougbarton.us> Date: Mon, 07 Mar 2011 17:04:41 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Levine References: <20110307203733.84226.qmail@joyce.lan> In-Reply-To: <20110307203733.84226.qmail@joyce.lan> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 01:03:32 -0000 On 03/07/2011 12:37, John Levine wrote: >> Title: Cloning Domain Name System (DNS) Labels for Fun and Profit > > Looks promising. Thanks. :) > In section 3, why does a CARNS have to make future queries to the > preferred version? Is it to improve cacheing, or is there something > else about it that I'm missing? Yes, and to reduce overall traffic, decrease processing power on the authorities, etc. > In 1.1, "truly equal" is really an application issue. The point I was trying to make there was that I'm attempting to provide a DNS solution to equivalence, not enter the debate on what "equal" means. :) If you think I need to clarify that I can add some text, but I'm hoping that the reference to the aliasing draft will help there. > From a user's point of view, if a web browser changes the name in the > displayed URL to the preferred one, the names aren't equal, and if it > shows what you entered, they are, regardless of what bits the DNS > might have returned, Right, I think you're getting the idea of what I'm proposing. Users don't care about DNS. :) > Ditto mail programs changing domains in mail addresses and so forth. > With that in mind, I don't see the fact that the application can tell > which name is preferred as a significant issue. In most cases I think you're right. The idea behind CLONES is to give the application the ability to determine this in case it *is* significant for some reason. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From dougb@dougbarton.us Mon Mar 7 17:32:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299083A69E0 for ; Mon, 7 Mar 2011 17:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QN8rzG97Hct for ; Mon, 7 Mar 2011 17:31:58 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id A68553A69DF for ; Mon, 7 Mar 2011 17:31:58 -0800 (PST) Received: (qmail 13466 invoked by uid 399); 8 Mar 2011 01:33:08 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 8 Mar 2011 01:33:08 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D758753.3090900@dougbarton.us> Date: Mon, 07 Mar 2011 17:33:07 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nicholas Weaver References: <4D74E409.1060409@dougbarton.us> <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> In-Reply-To: <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 01:32:00 -0000 On 03/07/2011 07:47, Nicholas Weaver wrote: > > On Mar 7, 2011, at 5:56 AM, Doug Barton wrote: >> >> As promised I've managed to squeak this draft in under the wire. As >> I say in the Foreword I expect that it will need some polishing, >> and if the group chooses to adopt the document I look forward to >> getting lots of help with that. :) > > Interesting, Thanks. :) > but a couple of comments: > > For the non-CLONE aware case (no EDNS0 option in query), I think > instead of returning "as if" its an alias, INSTEAD it should be a > CNAME or DNAME with TTL=0 with the part the authority is responsible > for canonicalized. All due respect, I think you're missing the whole point. :) Users want to be able to use the variant labels (including things like being on the RHS of NS and MX records) so the idea is to deal with them on a basis that is as equal as possible. > The more important configuration is probably the model of > > CARNS STUB<----> Non-CARNS Resolver<---> CARNS Auth. I hadn't considered the idea of making a stub CLONE-Aware, but I like it. :) > As it is far more likely that clients will upgrade (EG, as part of > the browser or OS) rather than resolver authorities in many cases. > > I do not know if unknown EDNS0 options are likely to be passed from > the stub to the authority through the intermediary resolver, I'm not sure what the default behavior is there, but if the actual resolver is not CLONE-Aware then sending the option wouldn't help since it wouldn't understand any CLONE RRs that it received back. > The CLONE RR really needs to be a "canonicalization program", > describing a set of character/word transformations that should be > applied, NOT just a simple pointer.[1] How would you represent the canonicalization? > This enables CLONEs to be > DNSSEC signed offline. Otherwise, if you want DNSSEC EVEN FOR > CLONE-aware clients, you need to... > > > Discuss online signing. I'm not sure why, but I'm happy to be educated. The idea I have in mind is that the zone for the preferred label can be DNSSEC signed in the regular way, and a CLONE-Aware resolver can validate responses for the CLONE labels "as if" they had been responses for the preferred labels. Thanks again for the comments. :) Doug > [1] I believe that if CLONE is just a simple pointer, it is > unnecessary, because 0 TTL CNAMES and DNAMES can accomplish the same > thing. The value in a CLONE-type new RR and associated EDNS0 > signaling lies in allowing it to work with the offline DNSSEC > signature model. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From johnl@iecc.com Mon Mar 7 18:50:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CDF3A680B for ; Mon, 7 Mar 2011 18:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.502 X-Spam-Level: X-Spam-Status: No, score=-110.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_37=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxL3k0OB5j9r for ; Mon, 7 Mar 2011 18:50:40 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id EDE403A68B7 for ; Mon, 7 Mar 2011 18:50:39 -0800 (PST) Received: (qmail 3894 invoked from network); 8 Mar 2011 02:51:54 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 8 Mar 2011 02:51:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=15b4a.4d7599c9.k1103; i=johnl@user.iecc.com; bh=riVW9S9R3VeBUxVd0VNOwgQCqdYHZIOK1QgfJSST2bw=; b=k185iOij2yYLTJSqrt8XBBjppcE/oCsRGbeuBM4rmtVZ4GnYwO03sM58PbtxinFvg3oHnp+4jwx7Pug3Q8UzYVwDat37YUF5Vi9/9e7S8a2jknF7+I5AH6mIIaVnxvTodz2ehHW7AA+HrrY5ylsWfAzK9YogMewYE4J2QGlrcmA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 8 Mar 2011 02:51:53 -0000 Message-ID: <20110308025153.88905.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <4D758753.3090900@dougbarton.us> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 02:50:42 -0000 >> CARNS STUB<----> Non-CARNS Resolver<---> CARNS Auth. > >I hadn't considered the idea of making a stub CLONE-Aware, but I like >it. :) To me, much of the appeal of CLONE is that it allows me to configure my applications to handle foo.example and all of its clones. So at least on the server side, CLONE-aware queries are likely to be pretty common. >> The CLONE RR really needs to be a "canonicalization program", >> describing a set of character/word transformations that should be >> applied, NOT just a simple pointer.[1] > >How would you represent the canonicalization? The rats at the bottom of that hole have extremely sharp, nasty, Turing-complete teeth. R's, John From alex@alex.org.uk Tue Mar 8 01:22:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32BF03A67AC for ; Tue, 8 Mar 2011 01:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYpxNgc38cUD for ; Tue, 8 Mar 2011 01:22:38 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 2C2B33A67A1 for ; Tue, 8 Mar 2011 01:22:37 -0800 (PST) Received: from [192.168.100.89] (unknown [193.128.116.237]) by mail.avalus.com (Postfix) with ESMTPSA id 4CF4CC562FB; Tue, 8 Mar 2011 09:23:50 +0000 (GMT) Date: Tue, 08 Mar 2011 09:24:17 +0000 From: Alex Bligh To: Doug Barton , Nicholas Weaver Message-ID: <7C043A33C72339E8A1FB6659@nimrod.local> In-Reply-To: <4D758753.3090900@dougbarton.us> References: <4D74E409.1060409@dougbarton.us> <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> <4D758753.3090900@dougbarton.us> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 09:22:39 -0000 --On 7 March 2011 17:33:07 -0800 Doug Barton wrote: > I think you're missing the whole point. :) Users want to be able to use > the variant labels (including things like being on the RHS of NS and MX > records) so the idea is to deal with them on a basis that is as equal as > possible. (I've read the draft but am thinking about it before commenting, so don't take this as a comment on the draft). I am not sure Nick is missing the point. We do not *know* that users want to use the variant labels on the RHS of NS and MX records (beyond the obvious truism that it would be nice to do everything). I am guessing that most users want to use the variant labels in URLs and email addresses, and that's it. Suzanne Woolf is attempting to gather some matrix of requirements and balance them against disruption. Until such point (that might be never), all we've got is different proposed solutions with different functionality. What you're saying is that CLONE (apparently) allows the RHS of an NS record to be a variant too, which differentiates it from (e.g.) a CNAME/DNAME combination. Out of interest, /why/ is a variant being on the RHS of an NS or MX record useful? This is never visible to end users, and in the majority of use cases thus far brought up, the RHS of the NS or the MX record gets to be one user-illegible string beginning "xn--" rather than another illegible string beginning "xn--". -- Alex Bligh From woolf@isc.org Tue Mar 8 02:40:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D83B3A6842 for ; Tue, 8 Mar 2011 02:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjDHy5rRTgEH for ; Tue, 8 Mar 2011 02:40:08 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id F38E13A683B for ; Tue, 8 Mar 2011 02:40:06 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 8A14A5F983B; Tue, 8 Mar 2011 10:41:06 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id 0C310216C22; Tue, 8 Mar 2011 10:41:05 +0000 (UTC) Date: Tue, 8 Mar 2011 10:41:05 +0000 From: Suzanne Woolf To: Alex Bligh Message-ID: <20110308104105.GB88549@bikeshed.isc.org> References: <4D74E409.1060409@dougbarton.us> <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> <4D758753.3090900@dougbarton.us> <7C043A33C72339E8A1FB6659@nimrod.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C043A33C72339E8A1FB6659@nimrod.local> User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 10:40:18 -0000 On Tue, Mar 08, 2011 at 09:24:17AM +0000, Alex Bligh wrote: > --On 7 March 2011 17:33:07 -0800 Doug Barton wrote: > > I am not sure Nick is missing the point. We do not *know* that users want > to use the variant labels on the RHS of NS and MX records (beyond the > obvious truism that it would be nice to do everything). I am guessing that > most users want to use the variant labels in URLs and email addresses, and > that's it. +1 on the point that we don't know. The problem statement draft is the attempt to capture the landscape but if you've read the -00 it's fairly clear we don't know *that* much. > Suzanne Woolf is attempting to gather some matrix of requirements and > balance them against disruption. Until such point (that might be never), > all we've got is different proposed solutions with different functionality. > What you're saying is that CLONE (apparently) allows the RHS of an NS > record to be a variant too, which differentiates it from (e.g.) a > CNAME/DNAME combination. The -00 of the problem statement draft has been out for a couple of weeks and we hope to ship a -01 before the Prague cutoff. I think Alex and Doug have both sent comments, and more are welcome but we need anything for the -01 in the next few days. (I don't think I'll have time to read CLONE and add a description for the -01, but if someone wants it in there alongside the attempts to describe shadow zones and the assorted xNAMEs, send text.) > Out of interest, /why/ is a variant being on the RHS of an NS or MX record > useful? This is never visible to end users, and in the majority of use > cases thus far brought up, the RHS of the NS or the MX record gets to be > one user-illegible string beginning "xn--" rather than another illegible > string beginning "xn--". There have been a couple of comments from apps folks on this, particularly Patrik Faltstrom, suggesting a possible use case in which the alias is part of a resolution chain, i.e. underlying a URI. This argument supposes that some user-illegible strings are nonetheless useful for applications and application-facing services. Suzanne From nweaver@ICSI.Berkeley.EDU Tue Mar 8 07:52:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ACBF3A687A for ; Tue, 8 Mar 2011 07:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl2cvWFn0mvv for ; Tue, 8 Mar 2011 07:52:20 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id E81A33A67AA for ; Tue, 8 Mar 2011 07:52:20 -0800 (PST) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 2DCD2369FE9; Tue, 8 Mar 2011 07:53:36 -0800 (PST) References: <4D74E409.1060409@dougbarton.us> <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> <4D758753.3090900@dougbarton.us> In-Reply-To: <4D758753.3090900@dougbarton.us> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Tue, 8 Mar 2011 07:53:35 -0800 To: Doug Barton X-Mailer: Apple Mail (2.1082) Cc: Nicholas Weaver , dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 15:52:22 -0000 On Mar 7, 2011, at 5:33 PM, Doug Barton wrote: >> The more important configuration is probably the model of >>=20 >> CARNS STUB<----> Non-CARNS Resolver<---> CARNS Auth. >=20 > I hadn't considered the idea of making a stub CLONE-Aware, but I like = it. :) This came up in private discussion when it was clear I had a different = model (resolver change) vs I can't remember who (stub change). The result was I was convinced I was wrong: I was convinced that Stub = change is actually far more likely. =20 EG, take arabic. With a resolver change model, every resolver which has = at least a few arabic clients needs to upgrade, which is effectively = everyone. But most resolvers won't substantially benefit, so why bother = upgrading? But with stub changes, ONLY those who actually benefit substantially = need to change. >> As it is far more likely that clients will upgrade (EG, as part of >> the browser or OS) rather than resolver authorities in many cases. >>=20 >> I do not know if unknown EDNS0 options are likely to be passed from >> the stub to the authority through the intermediary resolver, >=20 > I'm not sure what the default behavior is there, but if the actual = resolver is not CLONE-Aware then sending the option wouldn't help since = it wouldn't understand any CLONE RRs that it received back. Hmmm, which again makes me think the model might need to be more like = how AAAA records are handeled: Do a parallel fetch for CLONE and use the = result if it arrives within X ms of the cached record you were looking = for, as unknown RTYPEs (mostly) work, and when they don't, the stub = should be bypassing the configured recursive resolver anyway. >> The CLONE RR really needs to be a "canonicalization program", >> describing a set of character/word transformations that should be >> applied, NOT just a simple pointer.[1] >=20 > How would you represent the canonicalization? Basically, it boils down to the following requirement space for DNSSEC = to work with CLONE-type operations: 1: If the input space is small, DNSSEC can be done statically. 2: If the input space is huge, but, IN PRACTICE, the used input space = is small, dynamic signatures and caching works without introducing = single-points-of-failure in practice. [1] It can be new RRs (CLONE), it can be abusing existing RRs (0-TTL = CNAME/DNAME), but dynamic DNSSEC signatures are REQUIRED unless you use = new RRs which support many-to-one mappings. 3: If the input space is huge and, in practice, the used input space is = large, the solution space is either: a) Dynamic signatures which ARE a single-point-of-failure and DOS = target b) New RRs which represents MANY-to-one mappings, where only a few such = RRs can cover the entire space for a given name (enables static = signatures) c) "Paint the mountain pink and slap an SEP ('Somebody Else's Problem) = field on it". Its far better than having to try to explain the = suspicious new moon... This is why I believe that a CLONE type record needs to be a = 'canonicalization program' or a pointer to how to do the = canonicalization (namely, a pointer to a program), because in order for = DNSSEC to work without static signatures in case 2 or 3 (which is, I = believe, what is to be addressed), CLONE records need to be many-to-one = mappings and not one-to-one mappings, and the only way to do truly = generic many-to-one mappings is to sign a program that the recipient can = use to compute the mapping. Which is, admittedly, a MUCH harder problem but necessary if dynamic = signatures are off the table (as some in this group have advocated). [1] Dynamically generated signatures, however, are NOT a single point of = failure NOR a DOS opportunity IF the 'in practice' canonicalization = space is small. This can be measured by applying the canonicalization = transformation to a large written corpus (eg, a target-language email = corpus). From wwwrun@core3.amsl.com Tue Mar 8 10:22:18 2011 Return-Path: X-Original-To: dnsext@ietf.org Delivered-To: dnsext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 10D483A6967; Tue, 8 Mar 2011 10:22:16 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110308182217.10D483A6967@core3.amsl.com> Date: Tue, 8 Mar 2011 10:22:16 -0800 (PST) Cc: dnsext@ietf.org, ogud@ogud.com Subject: [dnsext] WG Action: RECHARTER: DNS Extensions (dnsext) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:22:20 -0000 The DNS Extensions (dnsext) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. DNS Extensions (dnsext) --------------------------------------------------- Current Status: Active Working Group Chairs: Olafur Gudmundsson Andrew Sullivan Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: Address: dnsext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dnsext Archive: http://www.ietf.org/mail-archive/web/dnsext/ Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT working group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will consider work in the following areas: * DNSSEC and TSIG/TKEY algorithm maintenance * Mechanisms that complement, or are alternatives to, TSIG and SIG(0) * Hardening DNS protocol and providing guidance to implementers * Advancing existing DNS-related Proposed Standard RFCs to Draft/Full Standard * Obsoleting DNS-related RFCs * Improving DNS zone synchronization mechanisms * Examining transport protocols, possibly adding new ones * Mechanisms to alias DNS trees or parts thereof Before formal adoption of any work item at least 5 working group participants must publicly state that the item is within charter and is a worthwhile item for further study. The DNSEXT WG will conduct the specified RFC5395 review of RR templates as they are posted, and EDNS0 Option templates if EDNS0-bis updates registration requirements. The WG will review DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working group. Goals and Milestones: Apr 2011 RFC3597-bis Unknown RR advanced to IESG for PS Jun 2011 DNSKEY Registry fixes and allocation procedure advanced to IESG Jun 2011 DNAME-bis to IESG Oct 2011 DNSSEC Errata document to IESG Jun 2011 EDNS0-bis update advanced to IESG Aug 2011 Algorithm signaling document to IESG Nov 2011 Requirements and current state survey document to IESG for publication Nov 2011 Decision about new protocol elements, if any Dec 2011 If new protocol elements, recharter Dec 2011 IXFR-only to IESG From roy@nominet.org.uk Tue Mar 8 11:32:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A093A692C for ; Tue, 8 Mar 2011 11:32:14 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij5bCDbN5zRS for ; Tue, 8 Mar 2011 11:32:13 -0800 (PST) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by core3.amsl.com (Postfix) with ESMTP id 793FC3A67F2 for ; Tue, 8 Mar 2011 11:32:11 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=xHMHFfIylT1c2/LV7BHu3J96m8Zjulgm86HsilWLdCbKFV7vQW07bvdj 15q50IErI9yH6mb9YfkM5/6WT3qUROSrsgkgvj+qTfHFEq+8PMJd1+pwp /FuCkBGR48Sk+ij; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1299612808; x=1331148808; 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:=20Roy=20Arends=20|Subject:=20C DS=20RRTYPE=20review=20-=20Comments=20period=20end=20Mar =2029th|Date:=20Tue,=208=20Mar=202011=2019:33:22=20+0000 |Message-ID:=20|To:=20" dnsext@ietf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<2c2ea216-8403-4a6b-ac5d-907d281eb5a5> |In-Reply-To:=20<20101115231159.GA697@shinkuro.com>; bh=a01EQq0TXxUJFN0mtXsekFXNEns6ts1iguRbznnfz8g=; b=j/42GQxRpe+JWE6919hVbx+8J7ol+VlJXXd2cLnb+zPUPzj2f7hIJK2D bhKKOMO7myjM0RUGEesRMCLT+Nx3PiUiaQF6d6mbzzc/GxZz42sW6/76O 3HBeyUZYRPBhZkL; X-IronPort-AV: E=Sophos;i="4.62,285,1297036800"; d="scan'208";a="31416164" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 08 Mar 2011 19:33:25 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Tue, 8 Mar 2011 19:33:24 +0000 From: Roy Arends To: "dnsext@ietf.org" Thread-Topic: CDS RRTYPE review - Comments period end Mar 29th Thread-Index: AQHL3cewrDa2/M5NO0iO/nIAjhSWZw== Date: Tue, 8 Mar 2011 19:33:22 +0000 Message-ID: In-Reply-To: <20101115231159.GA697@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <2c2ea216-8403-4a6b-ac5d-907d281eb5a5> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 19:32:14 -0000 Dear Colleagues, Below is a resubmission of a completed template requesting a new RRTYPE assignment under the procedures of RFC5395. This message starts a 3 weeks period for an expert-review of the DNS RRTYPE parameter allocation for URI specified in http://tools.ietf.org/id/draft-barwood-dnsop-ds-publish-01.txt If you have any new comments regarding this request that have not yet being made, please post them here before Mar 29th 18:00 UTC. Kind Regards, Roy Arends --begin 5395 template URI-- A. Submission Date: 15 November 2010 B. Submission Type: [X] New RRTYPE [ ] Modification to existing RRTYPE C. Contact Information for submitter: Name: George Barwood Email Address: george.barwood@blueyonder.co.uk International telephone number: +44 1452 722670 Other contact handles: N/A D. Motivation for the new RRTYPE application? To allow a copy of the DS RRset [RFC4034] to be published in the child zone, which is used to update the parent DS RRset. It is expected that this will allow the rollover of a key signing key to be automated. E. Description of the proposed RR type. The format is identical to the DS record. However there is no special processing for servers/resolvers. F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? None. G. What mnemonic is requested for the new RRTYPE (optional)? CDS to stand for "Child DS". H. Does the requested RRTYPE make use of any existing IANA Registry or require the creation of a new IANA sub-registry in DNS Parameters? It uses the same registries as the DS record. I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No. J. Comments: An RFC describing in detail how the CDS RRset may be used to update the parent DS RRset is anticipated. The current draft is draft-barwood-dnsop-ds-publish-01. --end 5395 template URI-- From fanf2@hermes.cam.ac.uk Tue Mar 8 12:30:55 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1C03A67B3 for ; Tue, 8 Mar 2011 12:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZIfRCjymW46 for ; Tue, 8 Mar 2011 12:30:52 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id 4A9C93A6806 for ; Tue, 8 Mar 2011 12:30:51 -0800 (PST) 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-1.csi.cam.ac.uk ([131.111.8.51]:49776) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Px3Zd-00023i-Yi (Exim 4.72) (return-path ); Tue, 08 Mar 2011 20:32:05 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Px3Zd-0006qh-OC (Exim 4.67) (return-path ); Tue, 08 Mar 2011 20:32:05 +0000 Date: Tue, 8 Mar 2011 20:32:05 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: george.barwood@blueyonder.co.uk In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dnsext@ietf.org" Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 20:30:55 -0000 On Tue, 8 Mar 2011, Roy Arends wrote: > > D. Motivation for the new RRTYPE application? > > To allow a copy of the DS RRset [RFC4034] to be published > in the child zone, which is used to update the parent DS RRset. > It is expected that this will allow the rollover of a key signing > key to be automated. Why not just use the child zone's SEP DNSKEY RRs for this purpose? Tony. -- f.anthony.n.finch http://dotat.at/ Humber, Thames, Dover: West or southwest 5 to 7, occasionally 4. Slight or moderate, occasionally rough. Occasional rain or showers. Moderate or good. From dougb@dougbarton.us Tue Mar 8 12:46:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD5A3A67B3 for ; Tue, 8 Mar 2011 12:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWJSUwcdQozU for ; Tue, 8 Mar 2011 12:46:08 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id B8D3D3A679C for ; Tue, 8 Mar 2011 12:46:07 -0800 (PST) Received: (qmail 8854 invoked by uid 399); 8 Mar 2011 20:46:59 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 8 Mar 2011 20:46:59 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D7695C1.5000106@dougbarton.us> Date: Tue, 08 Mar 2011 12:46:57 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Levine References: <20110308025153.88905.qmail@joyce.lan> In-Reply-To: <20110308025153.88905.qmail@joyce.lan> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 20:46:09 -0000 On 03/07/2011 18:51, John Levine wrote: >>> CARNS STUB<----> Non-CARNS Resolver<---> CARNS Auth. >> > >> >I hadn't considered the idea of making a stub CLONE-Aware, but I like >> >it.:) > To me, much of the appeal of CLONE is that it allows me to configure > my applications to handle foo.example and all of its clones. So at > least on the server side, CLONE-aware queries are likely to be pretty > common. Fair point. Anyone have good references on stubs setting EDNS options? :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From george.barwood@blueyonder.co.uk Tue Mar 8 12:50:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD28D3A6359 for ; Tue, 8 Mar 2011 12:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.704 X-Spam-Level: X-Spam-Status: No, score=0.704 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiVHA3UMhG-7 for ; Tue, 8 Mar 2011 12:50:03 -0800 (PST) Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by core3.amsl.com (Postfix) with ESMTP id ADF773A635F for ; Tue, 8 Mar 2011 12:50:02 -0800 (PST) Received: from [172.23.170.139] (helo=anti-virus01-10) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Px3sC-0002I4-Hf; Tue, 08 Mar 2011 20:51:16 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1Px3s2-0006M4-N1; Tue, 08 Mar 2011 20:51:06 +0000 Message-ID: <72A22513B1644CFE9023189F93BFDD32@local> From: "George Barwood" To: "Tony Finch" References: Date: Tue, 8 Mar 2011 20:52:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 20:50:03 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJUb255IEZpbmNoIiA8ZG90QGRv dGF0LmF0Pg0KVG86IDxnZW9yZ2UuYmFyd29vZEBibHVleW9uZGVyLmNvLnVrPg0KQ2M6IDxkbnNl eHRAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAwOCwgMjAxMSA4OjMyIFBNDQpTdWJq ZWN0OiBSZTogW2Ruc2V4dF0gQ0RTIFJSVFlQRSByZXZpZXcgLSBDb21tZW50cyBwZXJpb2QgZW5k IE1hciAyOXRoDQoNCg0KPiBPbiBUdWUsIDggTWFyIDIwMTEsIFJveSBBcmVuZHMgd3JvdGU6DQo+ Pg0KPj4gICAgRC4gICAgTW90aXZhdGlvbiBmb3IgdGhlIG5ldyBSUlRZUEUgYXBwbGljYXRpb24/ DQo+Pg0KPj4gICAgICAgICAgVG8gYWxsb3cgYSBjb3B5IG9mIHRoZSBEUyBSUnNldCBbUkZDNDAz NF0gdG8gYmUgcHVibGlzaGVkDQo+PiAgICAgICAgICBpbiB0aGUgY2hpbGQgem9uZSwgd2hpY2gg aXMgdXNlZCB0byB1cGRhdGUgdGhlIHBhcmVudCBEUyBSUnNldC4NCj4+ICAgICAgICAgIEl0IGlz IGV4cGVjdGVkIHRoYXQgdGhpcyB3aWxsIGFsbG93IHRoZSByb2xsb3ZlciBvZiBhIGtleSBzaWdu aW5nDQo+PiAgICAgICAgICBrZXkgdG8gYmUgYXV0b21hdGVkLg0KPiANCj4gV2h5IG5vdCBqdXN0 IHVzZSB0aGUgY2hpbGQgem9uZSdzIFNFUCBETlNLRVkgUlJzIGZvciB0aGlzIHB1cnBvc2U/DQoN CkZyb20gdGhlIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJhcndvb2Qt ZG5zb3AtZHMtcHVibGlzaC0wMQ0KDQogIEEgbmV3IHJlc291cmNlIHJlY29yZCB0eXBlIGlzIHBy ZWZlcnJlZCB0byB1c2luZyBmbGFncyBpbiB0aGUgRE5TS0VZDQogIFJSc2V0LiBJdCBhbGxvd3Mg dGhlIERTIHRvIGJlIHB1Ymxpc2hlZCB3aXRob3V0IHJldmVhbGluZyB0aGUgcHVibGljDQogIGtl eSwgZGVsYXlpbmcgdGhlIHRpbWUgYXQgd2hpY2ggYW4gYXR0YWNrZXIgY2FuIHN0YXJ0IGNyeXB0 YW5hbHlzaXM7DQogIHRoZSBzaXplIG9mIHRoZSBETlNLRVkgUlJzZXQgaXMgbm90IGNoYW5nZWQs IHdoaWNoIGF2b2lkcyBwb3RlbnRpYWwNCiAgdHJhbnNwb3J0IHByb2JsZW1zIHdpdGggbGFyZ2Ug cmVzcG9uc2VzOyBhbmQgaXQgYWxsb3dzIGFyYml0cmFyeSBEUw0KICByZWNvcmRzIHRvIGJlIHB1 Ymxpc2hlZCB3aGljaCBtYXkgaGF2ZSBubyBjb3JyZXNwb25kaW5nIEROU0tFWSwgd2hpY2gNCiAg bWlnaHQgYmUgdXNlZnVsIGluIGZ1dHVyZSBmb3IgZGVmaW5pbmcgdHJhbnNwb3J0IHBhcmFtZXRl cnMuDQoNCkdlb3JnZQ0KIA0KPiBUb255Lg0K From dougb@dougbarton.us Tue Mar 8 13:01:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA4E3A659A for ; Tue, 8 Mar 2011 13:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UewzPuss48iZ for ; Tue, 8 Mar 2011 13:01:49 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id CBF8D3A6359 for ; Tue, 8 Mar 2011 13:01:48 -0800 (PST) Received: (qmail 31626 invoked by uid 399); 8 Mar 2011 21:02:58 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 8 Mar 2011 21:02:58 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D76997F.5010209@dougbarton.us> Date: Tue, 08 Mar 2011 13:02:55 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alex Bligh References: <4D74E409.1060409@dougbarton.us> <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> <4D758753.3090900@dougbarton.us> <7C043A33C72339E8A1FB6659@nimrod.local> In-Reply-To: <7C043A33C72339E8A1FB6659@nimrod.local> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:01:50 -0000 On 03/08/2011 01:24, Alex Bligh wrote: > > > --On 7 March 2011 17:33:07 -0800 Doug Barton wrote: > >> I think you're missing the whole point. :) Users want to be able to use >> the variant labels (including things like being on the RHS of NS and MX >> records) so the idea is to deal with them on a basis that is as equal as >> possible. > > (I've read the draft but am thinking about it before commenting, so don't > take this as a comment on the draft). Ok. > I am not sure Nick is missing the point. We do not *know* that users want > to use the variant labels on the RHS of NS and MX records (beyond the > obvious truism that it would be nice to do everything). I am guessing that > most users want to use the variant labels in URLs and email addresses, and > that's it. What I've heard from that community is that they want the most out of the variants that they can get. Perhaps Vaggelis can say more about that. However in the end I don't think we're going to get a definitive answer that is going to satisfy "us" as technologists. Users don't understand what they want to the level of technical detail that will satisfy us, so I think we need to try and provide as much flexibility as possible. That said, I think that as DNSSEC becomes more widely deployed that using the variants for these purposes is going to be less attractive unless we can provide a solution. Obviously I have a strong feeling that the solution I'm offering is the right one, but I don't claim to be omniscient. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From dougb@dougbarton.us Tue Mar 8 13:20:57 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67CEE3A63CA for ; Tue, 8 Mar 2011 13:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoN1xkG3G2-j for ; Tue, 8 Mar 2011 13:20:56 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id C190E3A63C9 for ; Tue, 8 Mar 2011 13:20:55 -0800 (PST) Received: (qmail 28966 invoked by uid 399); 8 Mar 2011 21:22:06 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 8 Mar 2011 21:22:06 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D769DFD.2070507@dougbarton.us> Date: Tue, 08 Mar 2011 13:22:05 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nicholas Weaver References: <4D74E409.1060409@dougbarton.us> <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> <4D758753.3090900@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:20:57 -0000 On 03/08/2011 07:53, Nicholas Weaver wrote: > > On Mar 7, 2011, at 5:33 PM, Doug Barton wrote: >>> The more important configuration is probably the model of >>> >>> CARNS STUB<----> Non-CARNS Resolver<---> CARNS Auth. >> >> I hadn't considered the idea of making a stub CLONE-Aware, but I >> like it. :) > > This came up in private discussion when it was clear I had a > different model (resolver change) vs I can't remember who (stub > change). > > The result was I was convinced I was wrong: I was convinced that > Stub change is actually far more likely. > > EG, take arabic. With a resolver change model, every resolver which > has at least a few arabic clients needs to upgrade, which is > effectively everyone. But most resolvers won't substantially > benefit, so why bother upgrading? I'm not sure how stub change relates to Arabic, can you please expand on that? Specifically my understanding is that the "hard parts" of dealing with Arabic are located in the application layer so that what gets handed to the stub is the punycode. At the punycode layer what differentiates Arabic from other issues? > But with stub changes, ONLY those who actually benefit substantially > need to change. I think that concept has a lot of validity. OTOH the reason I'm suggesting a method that only requires authoritative server updates for all of the benefit other than DNSSEC. >>> As it is far more likely that clients will upgrade (EG, as part >>> of the browser or OS) rather than resolver authorities in many >>> cases. >>> >>> I do not know if unknown EDNS0 options are likely to be passed >>> from the stub to the authority through the intermediary >>> resolver, >> >> I'm not sure what the default behavior is there, but if the actual >> resolver is not CLONE-Aware then sending the option wouldn't help >> since it wouldn't understand any CLONE RRs that it received back. > > Hmmm, which again makes me think the model might need to be more like > how AAAA records are handeled: Do a parallel fetch for CLONE and use > the result if it arrives within X ms of the cached record you were > looking for, as unknown RTYPEs (mostly) work, and when they don't, > the stub should be bypassing the configured recursive resolver > anyway. This method of operation is very different than what I'm proposing, but I'd be interested in whether other people think that it would be an improvement. >>> The CLONE RR really needs to be a "canonicalization program", >>> describing a set of character/word transformations that should >>> be applied, NOT just a simple pointer.[1] >> >> How would you represent the canonicalization? > > Basically, it boils down to the following requirement space for > DNSSEC to work with CLONE-type operations: I'm sorry, I didn't understand your answer at all. I see dynamic signing as orthogonal to what I'm proposing, but if someone else wants to try and illuminate me, please feel free. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From dougb@dougbarton.us Tue Mar 8 13:30:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BAA43A6765 for ; Tue, 8 Mar 2011 13:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buu0evBXujVa for ; Tue, 8 Mar 2011 13:30:02 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id EF5F83A6774 for ; Tue, 8 Mar 2011 13:30:01 -0800 (PST) Received: (qmail 10883 invoked by uid 399); 8 Mar 2011 21:31:11 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 8 Mar 2011 21:31:11 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D76A01E.5000005@dougbarton.us> Date: Tue, 08 Mar 2011 13:31:10 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dnsext] How well supported are unknown RRs in modern resolvers? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:30:03 -0000 The point Nicholas made about moving the CLONE logic to the stub is something I'm interested in pursuing, but my understanding is that "a lot" of resolving name servers still have problems dealing with RR types they don't understand. Is this still true? Imagine the following scenario: 1. stub requests clone1.example.org A 2. Old resolving name server (RNS) which doesn't understand the CLONE RR does it's thing, and gets back the A record, plus "clone1.example.org CLONE preferred.example.org" in the ANSWER section. Does the RNS pass the unknown RR back to the stub? And sorry for my ignorance, but are there references to this that I can dig into? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From nweaver@icsi.berkeley.edu Tue Mar 8 13:34:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E823A659B for ; Tue, 8 Mar 2011 13:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF1KZj5qxm4u for ; Tue, 8 Mar 2011 13:34:55 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id B9B263A6405 for ; Tue, 8 Mar 2011 13:34:55 -0800 (PST) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 3908536A413; Tue, 8 Mar 2011 13:36:11 -0800 (PST) References: <4D76A01E.5000005@dougbarton.us> In-Reply-To: <4D76A01E.5000005@dougbarton.us> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <3065CCAA-2396-4D13-956D-4FBE1F89D36E@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Tue, 8 Mar 2011 13:36:10 -0800 To: Doug Barton X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] How well supported are unknown RRs in modern resolvers? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:34:57 -0000 On Mar 8, 2011, at 1:31 PM, Doug Barton wrote: > The point Nicholas made about moving the CLONE logic to the stub is = something I'm interested in pursuing, but my understanding is that "a = lot" of resolving name servers still have problems dealing with RR types = they don't understand. Is this still true? >=20 > Imagine the following scenario: >=20 > 1. stub requests clone1.example.org A > 2. Old resolving name server (RNS) which doesn't understand the CLONE = RR does it's thing, and gets back the A record, plus "clone1.example.org = CLONE preferred.example.org" in the ANSWER section. >=20 > Does the RNS pass the unknown RR back to the stub? And sorry for my = ignorance, but are there references to this that I can dig into? I do NOT know about: request clone.examlple.org A return clone1.example.org CLONE preferred.example.org. I DO know that request clone.examlple.org CLONE return clone1.example.org CLONE preferred.example.org. Actually does work, well mostly. =20 Some clients are behind seriously broken resolvers (usually NATs) that = basically barf on anything thats not an A record. =20 But if the client can get a TXT record, they can probably get an unknown = record. (only ~1% can't do TXT XOR UNKNOWN, its almost always you can = do both or you can do neither, and packet loss can inflate that value). =20= And most of THOSE clients can just bypass the borken recursive resolver = and do a direct fetch to the network. From nweaver@ICSI.Berkeley.EDU Tue Mar 8 13:36:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00A823A6452 for ; Tue, 8 Mar 2011 13:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWYkvw2AKvzn for ; Tue, 8 Mar 2011 13:36:17 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 05B283A63C9 for ; Tue, 8 Mar 2011 13:36:17 -0800 (PST) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 9CCA236A413; Tue, 8 Mar 2011 13:37:32 -0800 (PST) References: <4D74E409.1060409@dougbarton.us> <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> <4D758753.3090900@dougbarton.us> <4D769DFD.2070507@dougbarton.us> In-Reply-To: <4D769DFD.2070507@dougbarton.us> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <9A985005-F13E-4165-A008-479FF92F3FFA@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Tue, 8 Mar 2011 13:37:32 -0800 To: Doug Barton X-Mailer: Apple Mail (2.1082) Cc: Nicholas Weaver , dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:36:18 -0000 On Mar 8, 2011, at 1:22 PM, Doug Barton wrote: >> EG, take arabic. With a resolver change model, every resolver which >> has at least a few arabic clients needs to upgrade, which is >> effectively everyone. But most resolvers won't substantially >> benefit, so why bother upgrading? >=20 > I'm not sure how stub change relates to Arabic, can you please expand = on that? Specifically my understanding is that the "hard parts" of = dealing with Arabic are located in the application layer so that what = gets handed to the stub is the punycode. At the punycode layer what = differentiates Arabic from other issues? Its just the incentive issue. The stub is located on the system that = has 100% benefit or none, so those who want the benefit do the upgrade = and get it. The recursive resolver only benefits for the few fraction of the clients = behind it, so less incentive to upgrade. >>>> The CLONE RR really needs to be a "canonicalization program", >>>> describing a set of character/word transformations that should >>>> be applied, NOT just a simple pointer.[1] >>>=20 >>> How would you represent the canonicalization? >>=20 >> Basically, it boils down to the following requirement space for >> DNSSEC to work with CLONE-type operations: >=20 > I'm sorry, I didn't understand your answer at all. I see dynamic = signing as orthogonal to what I'm proposing, but if someone else wants = to try and illuminate me, please feel free. :) I'm of the opinion "If it can't do DNSSEC, we shouldn't do it". Yes, DNSSEC makes life more complicated, but if we believe DNSSEC has = ANY value, we MUST ensure that any proposed extensions to DNS, = especially in how names are resolved, works with DNSSEC. We shouldn't = say "DNSSEC works only for ASCII" or "only for precanonicalized names". Thus by that assumption and the assumption that this is for large-space = canonicalization (so just static aliasing can't work), you MUST either = do dynamic signing or have your CLONE RRs be a canonicalization program, = not just a mapping from A->B.=20 And there are some (NOT ME, but some) who don't like the idea of = anything which requires dynamic signing. And thus, dynamic signing is not orthoginal, as your current proposal = requires dynamic signing for DNSSEC to work. From alex@alex.org.uk Tue Mar 8 13:39:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F8C3A63EC for ; Tue, 8 Mar 2011 13:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLToknJc8Tzk for ; Tue, 8 Mar 2011 13:39:53 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 3BAE23A63C9 for ; Tue, 8 Mar 2011 13:39:53 -0800 (PST) Received: from [172.16.2.233] (lemondeh-adsl.demon.co.uk [83.105.105.209]) by mail.avalus.com (Postfix) with ESMTPSA id 9C6EEC5635E; Tue, 8 Mar 2011 21:41:07 +0000 (GMT) Date: Tue, 08 Mar 2011 21:41:06 +0000 From: Alex Bligh To: Doug Barton , dnsext@ietf.org Message-ID: In-Reply-To: <4D76A01E.5000005@dougbarton.us> References: <4D76A01E.5000005@dougbarton.us> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [dnsext] How well supported are unknown RRs in modern resolvers? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:39:54 -0000 --On 8 March 2011 13:31:10 -0800 Doug Barton wrote: > The point Nicholas made about moving the CLONE logic to the stub is > something I'm interested in pursuing, but my understanding is that "a > lot" of resolving name servers still have problems dealing with RR types > they don't understand. Is this still true? I would expand your worry-space from resolvers to include middleboxen also. Nick should have / could collect some good data on this. I think this is going to push us into EDNS if only for signalling reasons. Ray Bellis's report suggests that serious SOHO CPE problems will arise if the packets get larger than 512 bytes, but I don't think he explicitly tested unknown RRs. -- Alex Bligh From nweaver@icsi.berkeley.edu Tue Mar 8 13:56:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C523A66B4 for ; Tue, 8 Mar 2011 13:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPROs6PMqp7A for ; Tue, 8 Mar 2011 13:56:32 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 7B2653A659B for ; Tue, 8 Mar 2011 13:56:32 -0800 (PST) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 2045F36A413; Tue, 8 Mar 2011 13:57:48 -0800 (PST) References: <4D76A01E.5000005@dougbarton.us> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Tue, 8 Mar 2011 13:57:47 -0800 To: Alex Bligh X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] How well supported are unknown RRs in modern resolvers? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:56:33 -0000 On Mar 8, 2011, at 1:41 PM, Alex Bligh wrote: >=20 >=20 > --On 8 March 2011 13:31:10 -0800 Doug Barton = wrote: >=20 >> The point Nicholas made about moving the CLONE logic to the stub is >> something I'm interested in pursuing, but my understanding is that "a >> lot" of resolving name servers still have problems dealing with RR = types >> they don't understand. Is this still true? >=20 > I would expand your worry-space from resolvers to include middleboxen = also. >=20 > Nick should have / could collect some good data on this. I think this = is > going to push us into EDNS if only for signalling reasons. Ray = Bellis's > report suggests that serious SOHO CPE problems will arise if the = packets > get larger than 512 bytes, but I don't think he explicitly tested = unknown > RRs. We probe the NAT specifically, and its bad but not as bad as you think: OFTEN you can bypass the NAT (we check direct over the wire as well). And if you can get TXT, you can usually get unknown RRs. (Its either = 'get both or get neither', which means 'shove data into a TXT record' is = a bad idea: it doesn't help) We also test EDNS and large responses over the wire (but not all the way = to the client, need to add that in). The 512B limit is less terrifying, = fragmentation is a bigger problem really. (we have a paper in the polish stage, we'll post it here when its done). We don't test unknown EDNS0 options however. From dougb@dougbarton.us Tue Mar 8 14:11:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376023A659B for ; Tue, 8 Mar 2011 14:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCTXEPQO4AmX for ; Tue, 8 Mar 2011 14:11:33 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 30A1F3A672F for ; Tue, 8 Mar 2011 14:11:31 -0800 (PST) Received: (qmail 29337 invoked by uid 399); 8 Mar 2011 22:12:42 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 8 Mar 2011 22:12:42 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D76A9D9.40904@dougbarton.us> Date: Tue, 08 Mar 2011 14:12:41 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nicholas Weaver References: <4D74E409.1060409@dougbarton.us> <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> <4D758753.3090900@dougbarton.us> <4D769DFD.2070507@dougbarton.us> <9A985005-F13E-4165-A008-479FF92F3FFA@ICSI.Berkeley.EDU> In-Reply-To: <9A985005-F13E-4165-A008-479FF92F3FFA@ICSI.Berkeley.EDU> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 22:11:34 -0000 On 03/08/2011 13:37, Nicholas Weaver wrote: > > On Mar 8, 2011, at 1:22 PM, Doug Barton wrote: >>> EG, take arabic. With a resolver change model, every resolver >>> which has at least a few arabic clients needs to upgrade, which >>> is effectively everyone. But most resolvers won't substantially >>> benefit, so why bother upgrading? >> >> I'm not sure how stub change relates to Arabic, can you please >> expand on that? Specifically my understanding is that the "hard >> parts" of dealing with Arabic are located in the application layer >> so that what gets handed to the stub is the punycode. At the >> punycode layer what differentiates Arabic from other issues? > > Its just the incentive issue. The stub is located on the system that > has 100% benefit or none, so those who want the benefit do the > upgrade and get it. I think I understand what you're saying about incentive, I just want to be clear that there is nothing special about Arabic as it directly relates to the stub. > I'm of the opinion "If it can't do DNSSEC, we shouldn't do it". I agree with you, to some extent. > Yes, DNSSEC makes life more complicated, but if we believe DNSSEC has > ANY value, we MUST ensure that any proposed extensions to DNS, > especially in how names are resolved, works with DNSSEC. We > shouldn't say "DNSSEC works only for ASCII" or "only for > precanonicalized names". The solution I'm proposing does allow for validation of the variant labels, but it requires a CLONE-Aware resolver (and/or perhaps stub). I think now I'm seeing more about what you mean in regards to a CLONE method utilizing dynamic signing, but what I don't understand is how you handle the DNSKEY problem for CLONEs at the zone level? > Thus by that assumption and the assumption that this is for > large-space canonicalization (so just static aliasing can't work), > you MUST either do dynamic signing or have your CLONE RRs be a > canonicalization program, not just a mapping from A->B. > > And there are some (NOT ME, but some) who don't like the idea of > anything which requires dynamic signing. > > And thus, dynamic signing is not orthoginal, as your current proposal > requires dynamic signing for DNSSEC to work. We'll have to agree to disagree on this. My proposal provides a mechanism for handling DNSSEC for the variants without dynamic signing, albeit it does require the resolver to be upgraded for it to work. Meanwhile, I'm going to reply to your reply to my other thread here because I think it's relevant. If you're right that a non-CLONE-Aware resolver would pass the unknown RR if it's requested directly, then applications that are concerned about DNSSEC validation for the variants _could_ request the CLONES RR first, then handle the "transformation" to using the preferred version internally itself, or we could put that logic in the stub. If I understand other things you've written correctly you're saying that you don't want the stub/application layer to "pre-canonicalize" which I think what I'm suggesting in this paragraph would be, but I'm wondering why? To take IDNs as an example, we already require a "transformation" for U-label to A-label, so this wouldn't be that much different. So how hard are things going to break if stubs start requesting an RR that the RNS doesn't understand? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From dougb@dougbarton.us Tue Mar 8 14:22:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC023A67AB for ; Tue, 8 Mar 2011 14:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRg0Ux0gYJDH for ; Tue, 8 Mar 2011 14:20:53 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 436753A676A for ; Tue, 8 Mar 2011 14:20:10 -0800 (PST) Received: (qmail 6723 invoked by uid 399); 8 Mar 2011 22:21:13 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 8 Mar 2011 22:21:13 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D76ABD7.2030608@dougbarton.us> Date: Tue, 08 Mar 2011 14:21:11 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alex Bligh References: <4D76A01E.5000005@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] How well supported are unknown RRs in modern resolvers? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 22:22:26 -0000 On 03/08/2011 13:41, Alex Bligh wrote: > > > --On 8 March 2011 13:31:10 -0800 Doug Barton wrote: > >> The point Nicholas made about moving the CLONE logic to the stub is >> something I'm interested in pursuing, but my understanding is that "a >> lot" of resolving name servers still have problems dealing with RR types >> they don't understand. Is this still true? > > I would expand your worry-space from resolvers to include middleboxen also. > > Nick should have / could collect some good data on this. I think this is > going to push us into EDNS if only for signalling reasons. Ray Bellis's > report suggests that serious SOHO CPE problems will arise if the packets > get larger than 512 bytes, but I don't think he explicitly tested unknown > RRs. Yeah, "middleboxes are a hard problem" is one of the reasons that I heavily focused on the resolver for the DNSSEC part of the solution for CLONE, and (admittedly) ignored the stub part of the equation. OTOH, if we're going to get DNSSEC validation pushed down into the stub the middlebox problem really has to be solved. So what are the chances that we're going to be able to reliably deal with stubs passing EDNS _options_ (I'm not talking about just the size of the packet, I'm talking about actually having the stub say "I'd like EDNS option foo please"). Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From george.barwood@blueyonder.co.uk Tue Mar 8 14:57:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452C73A67A8 for ; Tue, 8 Mar 2011 14:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.695 X-Spam-Level: X-Spam-Status: No, score=0.695 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUpVtWk94zsq for ; Tue, 8 Mar 2011 14:57:11 -0800 (PST) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id 2FB423A67A5 for ; Tue, 8 Mar 2011 14:57:10 -0800 (PST) Received: from [172.23.170.139] (helo=anti-virus01-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1Px5rD-00017z-Hk for dnsext@ietf.org; Tue, 08 Mar 2011 22:58:23 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1Px5r1-0003xb-KZ for dnsext@ietf.org; Tue, 08 Mar 2011 22:58:11 +0000 Message-ID: <8E708CF867F54D02825E0E66A9861EB8@local> From: "George Barwood" To: Date: Tue, 8 Mar 2011 22:58:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: [dnsext] Autoconfiguration of variants X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 22:57:12 -0000 SSBoYXZlIG5vdCB5ZXQgcHJvcGVybHkgdW5kZXJzdG9vZCB0aGUgQ0xPTkUgZHJhZnQsIGZvciB3 aGljaCBJIGFwb2xvZ2lzZSwNCmJ1dCBpdCBzZWVtcyB0byBzdWZmZXIgZnJvbSBzb21lIHRlY2hu aWNhbCBpc3N1ZXMuDQoNCkhvdyBhYm91dCB0aGlzIGFwcHJvYWNoOg0KDQooMSkgQSBuZXcgUlJU WVBFIHRoYXQgZGVmaW5lcyB0aGUgYWxpYXNlcyBmb3IgYSBnaXZlbiBkb21haW4uDQoNCnd3dy5t eWJpZ2JhbmsuY29tLiBWQVJJQU5UUyB3d3cubXktYmlnLWJhbmsuY29tLiB8IHd3dy5teS1iaWdi YW5rLmNvbS4gfCB3d3cubXliaWctYmFuay5jb20uDQoNCigyKSBBbiBhcHBsaWNhdGlvbiAoIHNh eSBhIHdlYiBzZXJ2ZXIgKSB0aGF0IGlzIGNvbmZpZ3VyZWQgdG8gaGFuZGxlIHd3dy5teWJpZ2Jh bmsuY29tIHdpbGwgb24gaW5pdGlhbGlzYXRpb24NCmNoZWNrIHRoZSBETlMgZm9yIHZhcmlhbnRz LCBhbmQgaWYgdGhleSBhcmUgZGVmaW5lZCwgd2lsbCBhdXRvbWF0aWNhbGx5IGNvbmZpZ3VyZSB0 aGVtLg0KDQooMykgQXV0aG9yaXRhdGl2ZSBETlMgc2VydmVycyB3aGVuIHRoZXkgc2VlIGEgVkFS SUFOVFMgcmVjb3JkIHdpbGwgYXV0by1jb25maWd1cmUgdGhlIGFwcHJvcHJpYXRlIGNvcHkgem9u ZXMuDQpGb3IgRE5TU0VDIHRoaXMgbmVlZHMgdG8gYmUgaGFuZGxlZCBkdXJpbmcgem9uZSBzaWdu aW5nLiANCg0KKDQpIFBvc3NpYmx5IGZvciBjb25jaXNlIGV4cHJlc3Npb24sIGluc3RlYWQgb2Yg YSBzaW1wbGUgbGlzdCBvZiBkb21haW4gbmFtZXMsIHNvbWUgbGltaXRlZCBwYXR0ZXJuIG1hdGNo aW5nDQptaWdodCBiZSBhbGxvd2VkIGluIHRoZSBSREFUQSBvZiB0aGUgVkFSSUFOVFMgcmVjb3Jk LCBlLmcuDQoNCnd3dy5teWJpZ2JhbmsuY29tLiBWQVJJQU5UUyB3d3cubXlbLV1iaWdbLV1iYW5r LmNvbS4NCg0KKDUpIFJlc29sdmVycyBkbyBub3QgbmVlZCB1cGRhdGluZy4NCg0KR2VvcmdlIChh cG9sb2dpZXMgaWYgdGhpcyBpcyBzdHVwaWQsIG9yIGlzIGVxdWl2YWxlbnQgdG8gYW4gZXhpc3Rp bmcgcHJvcG9zYWwgKQ0K From dougb@dougbarton.us Tue Mar 8 16:17:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69243A67D2 for ; Tue, 8 Mar 2011 16:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X4k6XIfjOtg for ; Tue, 8 Mar 2011 16:17:28 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 6EBD13A67AB for ; Tue, 8 Mar 2011 16:17:27 -0800 (PST) Received: (qmail 25478 invoked by uid 399); 9 Mar 2011 00:18:38 -0000 Received: from router.ka9q.net (HELO ?192.168.2.9?) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 9 Mar 2011 00:18:38 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D76C75E.40503@dougbarton.us> Date: Tue, 08 Mar 2011 16:18:38 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: George Barwood References: <8E708CF867F54D02825E0E66A9861EB8@local> In-Reply-To: <8E708CF867F54D02825E0E66A9861EB8@local> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Autoconfiguration of variants X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 00:17:29 -0000 On 3/8/2011 2:58 PM, George Barwood wrote: > I have not yet properly understood the CLONE draft, for which I > apologise, but it seems to suffer from some technical issues. Questions and/or suggestions for clarification are welcome of course. I tried to keep the explanation of the concept simple, but strike a balance on explaining the protocol elements with sufficient detail to make my meaning clear. I'm certain that improvement is possible in both areas. OTOH, I think one of the nice thing about the CLONE approach is that it *is* simple. Either in the sense that it is too simple-minded to work, or so simply elegant that it is confounding. :) > How about this approach: > > (1) A new RRTYPE that defines the aliases for a given domain. > > www.mybigbank.com. VARIANTS www.my-big-bank.com. | > www.my-bigbank.com. | www.mybig-bank.com. > > (2) An application ( say a web server ) that is configured to handle > www.mybigbank.com will on initialisation check the DNS for variants, > and if they are defined, will automatically configure them. So far you have not described anything that cannot be accomplished with the CLONES RR I'm proposing. > (3) Authoritative DNS servers when they see a VARIANTS record will > auto-configure the appropriate copy zones. For DNSSEC this needs to > be handled during zone signing. This sounds sort of like Paul's SHADOW idea. I have expressed 2 reservations about this concept in the past. First I would prefer that we not limit a possible solution to the zone level. Second, how do you handle DNSKEYs for the variant zones? > (4) Possibly for concise expression, instead of a simple list of > domain names, some limited pattern matching might be allowed in the > RDATA of the VARIANTS record, e.g. > > www.mybigbank.com. VARIANTS www.my[-]big[-]bank.com. Potentially dangerous, but interesting. :) > (5) Resolvers do not need updating. I think your idea is interesting, but perhaps we would both benefit from a more thorough critique of the CLONE idea. I think we're both talking about similar things. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From miekg@atoom.net Tue Mar 8 23:58:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1681F3A6878 for ; Tue, 8 Mar 2011 23:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0rxXmMuwKHB for ; Tue, 8 Mar 2011 23:58:54 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by core3.amsl.com (Postfix) with ESMTP id EF75B3A6850 for ; Tue, 8 Mar 2011 23:58:53 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id E25993FFCA; Wed, 9 Mar 2011 09:00:06 +0100 (CET) Date: Wed, 9 Mar 2011 09:00:06 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20110309080006.GA23957@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <72A22513B1644CFE9023189F93BFDD32@local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <72A22513B1644CFE9023189F93BFDD32@local> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 07:58:58 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting George Barwood in "Re: [dnsext] CDS RRTYPE review - Co"... ] > > Why not just use the child zone's SEP DNSKEY RRs for this purpose? >=20 > From the draft http://tools.ietf.org/html/draft-barwood-dnsop-ds-publish-= 01 >=20 > key, delaying the time at which an attacker can start cryptanalysis; So this is the sole reason for adding this new type? Regards, -- Miek --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk13M4YACgkQJYuFzziA0PbMgwCg8PqEW7RHBau7cwL+lac/hCJu bDYAoLrbF7ZP19pIei/Xlp7VC9VLBbMB =2J4c -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From jelte@isc.org Wed Mar 9 00:33:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5063A689A for ; Wed, 9 Mar 2011 00:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.734 X-Spam-Level: X-Spam-Status: No, score=-99.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HELO_IS_SMALL6=0.556, HELO_MISMATCH_NL=1.448, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSEgdZcutLqn for ; Wed, 9 Mar 2011 00:33:15 -0800 (PST) Received: from tjeb.nl (vps6121.xlshosting.net [178.18.82.80]) by core3.amsl.com (Postfix) with ESMTP id C5FEF3A6857 for ; Wed, 9 Mar 2011 00:33:14 -0800 (PST) Received: from [192.168.8.11] (vhe-520087.sshn.net [195.169.221.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tjeb.nl (Postfix) with ESMTPSA id 1BDD42431C for ; Wed, 9 Mar 2011 09:34:27 +0100 (CET) Message-ID: <4D773B91.40001@isc.org> Date: Wed, 09 Mar 2011 09:34:25 +0100 From: Jelte Jansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: dnsext@ietf.org References: <72A22513B1644CFE9023189F93BFDD32@local> <20110309080006.GA23957@miek.nl> In-Reply-To: <20110309080006.GA23957@miek.nl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 08:33:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/09/2011 09:00 AM, Miek Gieben wrote: > [ Quoting George Barwood in "Re: [dnsext] CDS RRTYPE review - Co"... ] >>> Why not just use the child zone's SEP DNSKEY RRs for this purpose? >> >> From the draft http://tools.ietf.org/html/draft-barwood-dnsop-ds-publish-01 >> >> key, delaying the time at which an attacker can start cryptanalysis; > > So this is the sole reason for adding this new type? > disclaimer: I have not read this draft yet, but one other reason I could imagine is to not have to change your DNSKEY rrset if you want to change what is published at your parent, even if you do publish the dnskeys themselves. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk13O5EACgkQ4nZCKsdOncWWBQCgok9t2bjT5UxtDErWFoBnh9wt 6dsAoMaRIrnh/aBzZJ305mtZN0YlqEvy =ipFt -----END PGP SIGNATURE----- From george.barwood@blueyonder.co.uk Wed Mar 9 00:44:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411CB3A68BC for ; Wed, 9 Mar 2011 00:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.687 X-Spam-Level: X-Spam-Status: No, score=0.687 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQpLXiWbZ7H7 for ; Wed, 9 Mar 2011 00:44:38 -0800 (PST) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id 731103A68AB for ; Wed, 9 Mar 2011 00:44:38 -0800 (PST) Received: from [172.23.170.139] (helo=anti-virus01-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1PxF1l-0004Ri-Ct; Wed, 09 Mar 2011 08:45:53 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PxF1U-0003Ja-Ok; Wed, 09 Mar 2011 08:45:36 +0000 Message-ID: <758260B7B5B34599BA80D9BA5A3840C0@local> From: "George Barwood" To: "Miek Gieben" , References: <72A22513B1644CFE9023189F93BFDD32@local> <20110309080006.GA23957@miek.nl> Date: Wed, 9 Mar 2011 08:45:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 08:44:39 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1pZWsgR2llYmVuIiA8bWll a0BtaWVrLm5sPg0KVG86IDxkbnNleHRAaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIE1hcmNo IDA5LCAyMDExIDg6MDAgQU0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSBDRFMgUlJUWVBFIHJldmll dyAtIENvbW1lbnRzIHBlcmlvZCBlbmQgTWFyIDI5dGgNCg0KDQo+ID4gPiBXaHkgbm90IGp1c3Qg dXNlIHRoZSBjaGlsZCB6b25lJ3MgU0VQIEROU0tFWSBSUnMgZm9yIHRoaXMgcHVycG9zZT8NCj4g PiANCj4gPiBGcm9tIHRoZSBkcmFmdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i YXJ3b29kLWRuc29wLWRzLXB1Ymxpc2gtMDENCj4gPiANCj4gPiAgIGtleSwgZGVsYXlpbmcgdGhl IHRpbWUgYXQgd2hpY2ggYW4gYXR0YWNrZXIgY2FuIHN0YXJ0IGNyeXB0YW5hbHlzaXM7DQoNCj4g U28gdGhpcyBpcyB0aGUgc29sZSByZWFzb24gZm9yIGFkZGluZyB0aGlzIG5ldyB0eXBlPw0KDQpU aGVyZSBhcmUgNCByZWFzb25zIGdpdmVuLCB3aHkgZG8geW91IHF1b3RlIG9ubHkgb25lPw0KUGxl YXNlIGRvbid0IHF1b3RlIHNlbGVjdGl2ZWx5Lg0KDQpPbmUgY291bGQgcHJvYmFibHkgYWRkIHll dCBtb3JlIHJlYXNvbnMsIGUuZy4NCkl0IGdpdmVzIHRoZSBjaGlsZCBjb250cm9sIG92ZXIgd2hp Y2ggRGlnZXN0IFR5cGUgaXMgdXNlZC4NCkl0IGFsbG93cyBuZXcgRGlnZXN0IHR5cGVzIHRvIGJl IGRlcGxveWVkIGVhc2lseS4NCkl0IGFsbG93cyBlYXN5IHZlcmlmaWNhdGlvbiAoYnkgaHVtYW5z KSBhcyB0byB3aGV0aGVyIHRoZSBwYXJlbnQgYW5kIGNoaWxkIHpvbmVzIGFyZSBpbiBzeW5jLg0K QnV0IHRoZXNlIGFyZSByZWFsbHkganVzdCBleGFtcGxlcywgZnVuZGFtZW50YWxseSBpdCdzIGp1 c3QgcHJvcGVyIGRlc2lnbi4NCkl0IGdpdmVzIHRoZSBjaGlsZCB6b25lIHByb3BlciBjb250cm9s IG9mIHRoZSBwYXJlbnQgRFMgUlJzZXQuDQoNCkdlb3JnZQ0K From miekg@atoom.net Wed Mar 9 01:04:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67F23A68AA for ; Wed, 9 Mar 2011 01:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efaZGOgeO+GJ for ; Wed, 9 Mar 2011 01:04:26 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by core3.amsl.com (Postfix) with ESMTP id C23BB3A68C4 for ; Wed, 9 Mar 2011 01:04:25 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id A71FB3FFF3; Wed, 9 Mar 2011 10:05:36 +0100 (CET) Date: Wed, 9 Mar 2011 10:05:36 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20110309090536.GA9578@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <72A22513B1644CFE9023189F93BFDD32@local> <20110309080006.GA23957@miek.nl> <758260B7B5B34599BA80D9BA5A3840C0@local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <758260B7B5B34599BA80D9BA5A3840C0@local> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 09:04:26 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting George Barwood in "Re: [dnsext] CDS RRTYPE review - Co"... ] > > > > Why not just use the child zone's SEP DNSKEY RRs for this purpose? > > >=20 > > > From the draft http://tools.ietf.org/html/draft-barwood-dnsop-ds-publ= ish-01 > > >=20 > > > key, delaying the time at which an attacker can start cryptanalysis; >=20 > > So this is the sole reason for adding this new type? >=20 > There are 4 reasons given, why do you quote only one? > Please don't quote selectively. it is the first reason you give in the introduction in the draft. > One could probably add yet more reasons, e.g. > It gives the child control over which Digest Type is used. > It allows new Digest types to be deployed easily. > It allows easy verification (by humans) as to whether the parent and chil= d zones are in sync. > > But these are really just examples, fundamentally it's just proper design. > It gives the child zone proper control of the parent DS RRset. =2E..if the parent cooperates... Is this proposal aimed at TLDs or at smaller zones? Because for .nl we are just going to use EPP and let the registrar send in a DNSKEY which we will convert to a DS (so you can not even choose your own hash algo). grtz, -- Miek --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk13QuAACgkQJYuFzziA0Pa8UwCdFZrGFuRMvmhqzLLVQ8c/lYUQ WlgAoJ5ChuksLT4WcevV5hNH71gY4GE/ =GXqe -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From george.barwood@blueyonder.co.uk Wed Mar 9 01:32:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE533A67C3 for ; Wed, 9 Mar 2011 01:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.681 X-Spam-Level: X-Spam-Status: No, score=0.681 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCIwSYBp-2OU for ; Wed, 9 Mar 2011 01:32:00 -0800 (PST) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by core3.amsl.com (Postfix) with ESMTP id 9752C3A68D4 for ; Wed, 9 Mar 2011 01:32:00 -0800 (PST) Received: from [172.23.170.144] (helo=anti-virus03-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1PxFlb-0006JI-JQ; Wed, 09 Mar 2011 09:33:15 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PxFlX-0002P1-TJ; Wed, 09 Mar 2011 09:33:11 +0000 Message-ID: <0A557E576E7243CDB712E2B867DEDF6D@local> From: "George Barwood" To: "Miek Gieben" , References: <72A22513B1644CFE9023189F93BFDD32@local><20110309080006.GA23957@miek.nl><758260B7B5B34599BA80D9BA5A3840C0@local> <20110309090536.GA9578@miek.nl> Date: Wed, 9 Mar 2011 09:33:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 09:32:01 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1pZWsgR2llYmVuIiA8bWll a0BtaWVrLm5sPg0KVG86IDxkbnNleHRAaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIE1hcmNo IDA5LCAyMDExIDk6MDUgQU0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSBDRFMgUlJUWVBFIHJldmll dyAtIENvbW1lbnRzIHBlcmlvZCBlbmQgTWFyIDI5dGgNCg0KPiBJcyB0aGlzIHByb3Bvc2FsIGFp bWVkIGF0IFRMRHMgb3IgYXQgc21hbGxlciB6b25lcz8gQmVjYXVzZSBmb3IgLm5sIHdlDQo+IGFy ZSBqdXN0IGdvaW5nIHRvIHVzZSBFUFAgYW5kIGxldCB0aGUgcmVnaXN0cmFyIHNlbmQgaW4gYSBE TlNLRVkgd2hpY2gNCj4gd2Ugd2lsbCBjb252ZXJ0IHRvIGEgRFMgKHNvIHlvdSBjYW4gbm90IGV2 ZW4gY2hvb3NlIHlvdXIgb3duIGhhc2gNCg0KSXQgaXMgbm90IGFpbWVkIGF0IGFueSBwYXJ0aWN1 bGFyIHpvbmVzLCBpdCBpcyBhIGdlbmVyYWwgbWVjaGFuaXNtLg0K From i.grok@comcast.net Wed Mar 9 05:29:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B3A3A69A2 for ; Wed, 9 Mar 2011 05:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.161 X-Spam-Level: X-Spam-Status: No, score=-102.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9oE+wkTeVwE for ; Wed, 9 Mar 2011 05:29:05 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id E56083A696D for ; Wed, 9 Mar 2011 05:29:04 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id GzhQ1g0031uE5Es541WNo5; Wed, 09 Mar 2011 13:30:22 +0000 Received: from olympia.mars.sol ([68.33.77.0]) by omta16.westchester.pa.mail.comcast.net with comcast id H1WL1g01Q00PQ6U3c1WLig; Wed, 09 Mar 2011 13:30:21 +0000 Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id p29DUH0e006331 for ; Wed, 9 Mar 2011 08:30:17 -0500 Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id p29DUHPx006329 for dnsext@ietf.org; Wed, 9 Mar 2011 08:30:17 -0500 Date: Wed, 9 Mar 2011 08:30:17 -0500 From: Scott Schmit To: dnsext@ietf.org Message-ID: <20110309133017.GA19809@odin.mars.sol> Mail-Followup-To: dnsext@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 13:29:06 -0000 On Tue, Mar 08, 2011 at 08:32:05PM +0000, Tony Finch wrote dnsext: > On Tue, 8 Mar 2011, Roy Arends wrote: > > > > D. Motivation for the new RRTYPE application? > > > > To allow a copy of the DS RRset [RFC4034] to be published > > in the child zone, which is used to update the parent DS RRset. > > It is expected that this will allow the rollover of a key signing > > key to be automated. > > Why not just use the child zone's SEP DNSKEY RRs for this purpose? I'm inclined to agree with this, but even if it's decided that the DNSKEY RRs aren't sufficient, why not just use DS on the client side? I see that RFC 3658 forbids it, but I'm not sure I understand why. We don't have CNS in addition to NS, so why should DS be different? I can understand that DS must be ignored by a client unless it's signed by the parent, but if that check doesn't already exist, we're already in trouble. So, maybe they didn't think of the use case this draft is trying to address and forbade it to keep the software implementations simpler? But that could have been accomplished simply by saying that a DS on the child side is ignored for validation purposes (it now becomes pointless (but harmless) to include it, except as a way to securely send DS records from the child to the parent). Even if this language tweak were to be applied after the fact, I don't think there is an interoperability problem. There are 4 cases: 1) the parent has no DS, nor does the child -- the pre-DNSSEC case 2) the parent has no DS, but the child does -- the DS must be regarded as fake and ignored by resolvers already, or we have problems. (Even with the new draft, the parent MUST NOT attempt to use the DS in the child to seed anything -- it needs to be supplied by a secure mechanism, and a child DS signed by an untrusted DNSKEY isn't it) 3) the parent has a DS, but the child doesn't -- the current DNSSEC case 4) the parent has a DS, and so does the child -- this is the new thing that this draft is trying to enable to support KSK rollover. I would argue that case 4 should be harmless, unless I've overlooked something: either nothing is looking for this and should ignore it, or the DS should be regarded as fake by older software and ignored by resolvers (if it's not, the software already has a security hole -- simply DOS a zone with an unsigned parent by sending fake DS records purportedly from the child), or the DS should look valid (because it fits a chain of signatures) and possibly extra DNSKEYs match & are regarded as valid. But since the chain of signatures is valid, it's still secure. If people started writing zone signers to rely on this mechanism to introduce new keys, I could see there being interoperability issues (some resolvers would treat the domain as secure, and others wouldn't), but since this is new behavior, this draft can (and should) explain that this cannot be relied upon (and DNSKEYs should be used instead for this purpose). Alternatively, to keep implementations simple, state that child DS RRs MUST NOT be used as part of authenticating RR contents, but they are allowed to exist and be queried for (and I could almost imagine that the only code this would affect is zone checker tools). The only place where that would be a problem is for people who want to use this mechanism, so that's motivation to update the checkers anyway. I can understand the motivation of introducing a new RRTYPE to avoid needing to alter existing MUST NOTs, but CDS just seems unnecessary. Maybe there's another reason to forbid DS on the child side that I've overlooked? -- Scott Schmit From ajs@shinkuro.com Wed Mar 9 05:56:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6B43A6821 for ; Wed, 9 Mar 2011 05:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2CjegPAx112 for ; Wed, 9 Mar 2011 05:55:46 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 288093A6881 for ; Wed, 9 Mar 2011 05:55:46 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 05FDB1ECB408 for ; Wed, 9 Mar 2011 13:57:01 +0000 (UTC) Date: Wed, 9 Mar 2011 08:57:00 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110309135700.GI32629@shinkuro.com> References: <20110309133017.GA19809@odin.mars.sol> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110309133017.GA19809@odin.mars.sol> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 13:56:02 -0000 No hat. On Wed, Mar 09, 2011 at 08:30:17AM -0500, Scott Schmit wrote: > I'm inclined to agree with this, but even if it's decided that the > DNSKEY RRs aren't sufficient, why not just use DS on the client side? I > see that RFC 3658 forbids it, but I'm not sure I understand why. I do not think this is the time to debate that design decision. The design of DNSSEC uses different RRTYPEs at the parent side of the cut and the child side. It is true that we use the same RRTYPE at the parent and child sides for the NS record. But even if you think that was a good design (though I happen not to), the fact is that DNSSEC did not follow that direction, and it has rules stating that the DS isn't allowed on the child side. We can't unmake that decision, and we can't change it now without introducing a backward incompatible change; so that is not an option open to us. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From george.barwood@blueyonder.co.uk Wed Mar 9 06:03:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65BD3A69DC for ; Wed, 9 Mar 2011 06:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.675 X-Spam-Level: X-Spam-Status: No, score=0.675 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRq7M39aU5fd for ; Wed, 9 Mar 2011 06:03:21 -0800 (PST) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by core3.amsl.com (Postfix) with ESMTP id DCCB63A69DF for ; Wed, 9 Mar 2011 06:03:20 -0800 (PST) Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1PxK0C-0002pZ-BH; Wed, 09 Mar 2011 14:04:36 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PxJzp-0002hC-KC; Wed, 09 Mar 2011 14:04:13 +0000 Message-ID: <9A4DC332DAA14CF799351788B087B714@local> From: "George Barwood" To: "Scott Schmit" , References: <20110309133017.GA19809@odin.mars.sol> Date: Wed, 9 Mar 2011 14:04:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:03:21 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNjb3R0IFNjaG1pdCIgPGku Z3Jva0Bjb21jYXN0Lm5ldD4NClRvOiA8ZG5zZXh0QGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5 LCBNYXJjaCAwOSwgMjAxMSAxOjMwIFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gQ0RTIFJSVFlQ RSByZXZpZXcgLSBDb21tZW50cyBwZXJpb2QgZW5kIE1hciAyOXRoDQoNCj4gTWF5YmUgdGhlcmUn cyBhbm90aGVyIHJlYXNvbiB0byBmb3JiaWQgRFMgb24gdGhlIGNoaWxkIHNpZGUgdGhhdCBJJ3Zl DQo+IG92ZXJsb29rZWQ/DQoNCkJlc2lkZXMgdGhlIGZhY3QgdGhhdCB0aGUgZXhpc3Rpbmcgc3Rh bmRhcmQgZm9yYmlkcyBpdCwgaXQgZG9lcyBub3Qgd29yay4NCg0KV2hlbiB5b3Ugc2VuZCBhIERT IHF1ZXJ5IHRvIGEgcmVzb2x2ZXIsIGl0IHdpbGwgcXVlcnkgdGhlIHBhcmVudCB6b25lLCBzbyB5 b3Ugd2lsbCBub3QgZGlzY292ZXIgdGhlIERTIFJSc2V0IGZvciB0aGUgY2hpbGQuIFRoZXJlIGFy ZSBwcm9iYWJseSBvdGhlciByZWFzb25zIHdoeSBpdCB3b24ndCB3b3JrIC0gZm9yIGV4YW1wbGUg dGhlIEJJTkQgc2lnbmVyIHdvbid0IHNpZ24gYSB6b25lIHdpdGggRFMgcmVjb3JkcyBhdCB0aGUg QXBleC4gSXQgd291bGQgYmUgY2hhb3MuDQoNClRoZSBkYXRhIGlzIHF1aXRlIGRpc3RpbmN0LCBh bmQgeW91IG5lZWQgYSB3YXkgb2YgZXhwcmVzc2luZyB0aGF0IGluIGEgcXVlcnkuDQpUaGUgcHJv cGVyIHdheSBpcyBhIG5ldyBSUnR5cGUgdG8gZXhwcmVzcyB0aGF0IGRpc3RpbmN0aW9uLg0KDQpH ZW9yZ2UNCiANCj4gLS0gDQo+IFNjb3R0IFNjaG1pdA0K From ogud@ogud.com Wed Mar 9 06:18:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53ECB3A69BE for ; Wed, 9 Mar 2011 06:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFBSAYSdd40W for ; Wed, 9 Mar 2011 06:18:41 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 410D23A69C9 for ; Wed, 9 Mar 2011 06:18:41 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p29EJuLD044855 for ; Wed, 9 Mar 2011 09:19:56 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D778C86.4020105@ogud.com> Date: Wed, 09 Mar 2011 09:19:50 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110309133017.GA19809@odin.mars.sol> In-Reply-To: <20110309133017.GA19809@odin.mars.sol> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:18:42 -0000 On 09/03/2011 8:30 AM, Scott Schmit wrote: > On Tue, Mar 08, 2011 at 08:32:05PM +0000, Tony Finch wrote dnsext: >> On Tue, 8 Mar 2011, Roy Arends wrote: >>> >>> D. Motivation for the new RRTYPE application? >>> >>> To allow a copy of the DS RRset [RFC4034] to be published >>> in the child zone, which is used to update the parent DS RRset. >>> It is expected that this will allow the rollover of a key signing >>> key to be automated. >> >> Why not just use the child zone's SEP DNSKEY RRs for this purpose? > > I'm inclined to agree with this, but even if it's decided that the > DNSKEY RRs aren't sufficient, why not just use DS on the client side? I > see that RFC 3658 forbids it, but I'm not sure I understand why. We > don't have CNS in addition to NS, so why should DS be different? I can > understand that DS must be ignored by a client unless it's signed by the > parent, but if that check doesn't already exist, we're already in > trouble. Using SEP bits in DNSKEY records does not work when a zone wants to retire an algorithm, the DS MUST be removed before the corresponding DNSKEY record is removed. > > So, maybe they didn't think of the use case this draft is trying to > address and forbade it to keep the software implementations simpler? But > that could have been accomplished simply by saying that a DS on the > child side is ignored for validation purposes (it now becomes pointless > (but harmless) to include it, except as a way to securely send DS > records from the child to the parent). RFC3658 specified for the first time a record that can only live at the parent and this required major changes to resolution algorithm implementations. If there is anything we have learned in the last 25+ years of DNS is this: "If the same information can appear in two places it will not be the same and you have no idea which version resolvers will use" Just look at what different resolvers do when the parent and child NS records differ. > I can understand the motivation of introducing a new RRTYPE to avoid > needing to alter existing MUST NOTs, but CDS just seems unnecessary. > > Maybe there's another reason to forbid DS on the child side that I've > overlooked? > see above, and new types a cheap, and this gives the child full control over the changes in the DS in parent. Similarly this can be used to update trust anchors for an Island of security. I encouraged George to submit this, as I had the same idea about the same time as he did, in the context of automating DNS operator change/transfer. This record does not change the DNS control plane (resolvers) it is only published for information purposes and to be used by zone content management tools. Olafur PS: I think that original DNS had NS RRset in two places was the biggest design mistake and we have spent lots of time and effort to overcome that. This choice was done for expediency and/or optimization reasons. s From hallam@gmail.com Wed Mar 9 06:26:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687423A69CC for ; Wed, 9 Mar 2011 06:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TE0Dx+LbDDod for ; Wed, 9 Mar 2011 06:26:46 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 784233A69BE for ; Wed, 9 Mar 2011 06:26:42 -0800 (PST) Received: by iwl42 with SMTP id 42so718488iwl.31 for ; Wed, 09 Mar 2011 06:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Qt8EobUQ1nzOeKQYpm+fPaiAJB/eJxzE8nBb89HE3zw=; b=vDG2lj9bpLyjFjjUcSuLRS8xtANhWzixWPpwd83Q5eR+7oaIh/LwSudWVenJopYt6e i0dVtjfAHRqKc6pmkTa172oE0PvDJWhO4CHTtovIwcGLOFsF1irFsaVeKr0QFdjUV0bj hjvHfRNC6cFhIq1fmOeA9UgrQTSzL2Gn5io48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QdaDZwlay3Ykz5HNAv8ZUnvwmdH70osBLYHHxJ7rmpQ1WCuFdKBNxvdE1PvFrB+e1F t8G2JsQ0CrDkrw1Gf6TQpRg73yNdF2IoRIbOTLzGIq1794URV2Hwxqnoc+BJFCYJhl1C 9nSfPE7B0y+ZpqAO46XcjOEh6/DbPiuoAYfTE= MIME-Version: 1.0 Received: by 10.42.108.9 with SMTP id f9mr6183503icp.233.1299680878737; Wed, 09 Mar 2011 06:27:58 -0800 (PST) Received: by 10.43.61.80 with HTTP; Wed, 9 Mar 2011 06:27:58 -0800 (PST) In-Reply-To: <20110309135700.GI32629@shinkuro.com> References: <20110309133017.GA19809@odin.mars.sol> <20110309135700.GI32629@shinkuro.com> Date: Wed, 9 Mar 2011 09:27:58 -0500 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=20cf303bff46193917049e0d895c Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:26:47 -0000 --20cf303bff46193917049e0d895c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 9, 2011 at 8:57 AM, Andrew Sullivan wrote: > No hat. > > On Wed, Mar 09, 2011 at 08:30:17AM -0500, Scott Schmit wrote: > > > I'm inclined to agree with this, but even if it's decided that the > > DNSKEY RRs aren't sufficient, why not just use DS on the client side? I > > see that RFC 3658 forbids it, but I'm not sure I understand why. > > I do not think this is the time to debate that design decision. The > design of DNSSEC uses different RRTYPEs at the parent side of the cut > and the child side. It is true that we use the same RRTYPE at the > parent and child sides for the NS record. But even if you think that > was a good design (though I happen not to), the fact is that DNSSEC > did not follow that direction, and it has rules stating that the DS > isn't allowed on the child side. We can't unmake that decision, and > we can't change it now without introducing a backward incompatible > change; so that is not an option open to us. > I think that a change in mid course here would be worse than merely 'incompatible'. It would work maybe 90% of the time and fail in unpredictable and unexpected ways the rest of the time. We really need a design rule to help determine whether something should be a new RR or not. In my view, the design should attempt to: 1) Ensure that a query returns all the relevant information 2) Does not return irrelevant information Here we have the DS record which gives the hash of key in the zone beneath. I do not see a compelling use case that requires the hash of the subordinate zone key to be returned at the same time as the hash of the zone key. So according to the design rule above, this clearly requires separate records - if there is a compelling use case for the actual record. I have used the above design rules quite extensively in my attempt to untangle the issues that result from the interference that occurs between use of domain prefixes, aliases and wildcards. -- Website: http://hallambaker.com/ --20cf303bff46193917049e0d895c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Mar 9, 2011 at 8:57 AM, Andrew S= ullivan <ajs@shink= uro.com> wrote:
No hat.

On Wed, Mar 09, 2011 at 08:30:17AM -0500, Scott Schmit wrote:

> I'm inclined to agree with this, but even if it's decided that= the
> DNSKEY RRs aren't sufficient, why not just use DS on the client si= de? I
> see that RFC 3658 forbids it, but I'm not sure I understand why.
I do not think this is the time to debate that design decision. =A0Th= e
design of DNSSEC uses different RRTYPEs at the parent side of the cut
and the child side. =A0It is true that we use the same RRTYPE at the
parent and child sides for the NS record. =A0But even if you think that
was a good design (though I happen not to), the fact is that DNSSEC
did not follow that direction, and it has rules stating that the DS
isn't allowed on the child side. =A0We can't unmake that decision, = and
we can't change it now without introducing a backward incompatible
change; so that is not an option open to us.

I think that a change in mid course here would be worse than merely &= #39;incompatible'.

It would work maybe 90% of = the time and fail in unpredictable and unexpected ways the rest of the time= .


We really need a design rule to help det= ermine whether something should be a new RR or not.

In my view, the design should attempt to:

1) Ens= ure that a query returns all the relevant information
2) Does not return irrelevant information

Here we have the DS record which gives the hash of key in the z= one beneath. I do not see a compelling use case that requires the hash of t= he subordinate zone key to be returned at the same time as the hash of the = zone key.=A0

So according to the design rule above, this clearly req= uires separate records - if there is a compelling use case for the actual r= ecord.

=A0
I have used the above design= rules quite extensively in my attempt to untangle the issues that result f= rom the interference that occurs between use of domain prefixes, aliases an= d wildcards.=A0

--20cf303bff46193917049e0d895c-- From fanf2@hermes.cam.ac.uk Wed Mar 9 06:28:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C90E3A69E4 for ; Wed, 9 Mar 2011 06:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koGRD+XKwEqK for ; Wed, 9 Mar 2011 06:28:15 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 70C8F3A69BE for ; Wed, 9 Mar 2011 06:28:15 -0800 (PST) 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-1.csi.cam.ac.uk ([131.111.8.51]:41691) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1PxKOI-0001dk-SA (Exim 4.72) (return-path ); Wed, 09 Mar 2011 14:29:30 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PxKOI-0004fC-MJ (Exim 4.67) (return-path ); Wed, 09 Mar 2011 14:29:30 +0000 Date: Wed, 9 Mar 2011 14:29:30 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: George Barwood In-Reply-To: <758260B7B5B34599BA80D9BA5A3840C0@local> Message-ID: References: <72A22513B1644CFE9023189F93BFDD32@local> <20110309080006.GA23957@miek.nl> <758260B7B5B34599BA80D9BA5A3840C0@local> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:28:17 -0000 On Wed, 9 Mar 2011, George Barwood wrote: > > But these are really just examples, fundamentally it's just proper design. > It gives the child zone proper control of the parent DS RRset. Thanks for pointing out the part of your draft that I missed. I searched for KSK and SEP and didn't find any matches. The reason I asked the question is that there would be a very nice economy in re-using the existing SEP mechanism for this purpose. There's a certain parallel between automatically maintaining trust anchors and automatically maintaining secure delegations. Tony. -- f.anthony.n.finch http://dotat.at/ South-east Iceland: Mainly northerly or northeasterly 5 or 6, occasionally 4. Very rough or high. Wintry showers. Good, occasionally poor. Occasional light icing in north. From fanf2@hermes.cam.ac.uk Wed Mar 9 06:32:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE48F3A6A08 for ; Wed, 9 Mar 2011 06:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7t3S3SkDYTr for ; Wed, 9 Mar 2011 06:32:10 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 3CEA33A69EA for ; Wed, 9 Mar 2011 06:32:10 -0800 (PST) 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-1.csi.cam.ac.uk ([131.111.8.51]:60676) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1PxKS5-00037L-sG (Exim 4.72) (return-path ); Wed, 09 Mar 2011 14:33:25 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PxKS5-0005Rc-P2 (Exim 4.67) (return-path ); Wed, 09 Mar 2011 14:33:25 +0000 Date: Wed, 9 Mar 2011 14:33:25 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Olafur Gudmundsson In-Reply-To: <4D778C86.4020105@ogud.com> Message-ID: References: <20110309133017.GA19809@odin.mars.sol> <4D778C86.4020105@ogud.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:32:12 -0000 On Wed, 9 Mar 2011, Olafur Gudmundsson wrote: > > Using SEP bits in DNSKEY records does not work when a zone wants to retire an > algorithm, the DS MUST be removed before the corresponding DNSKEY record is > removed. Aha! Thanks. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire, South Utsire: Westerly, becoming cyclonic later, 5 to 7, occasionally gale 8 except in North Utsire, becoming variable 4 at times. Rough or very rough. Squally wintry showers, rain or snow later. Good, occasionally very poor. From hallam@gmail.com Wed Mar 9 06:32:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9AF3A69FB for ; Wed, 9 Mar 2011 06:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrf+LzEv+LSS for ; Wed, 9 Mar 2011 06:32:45 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 48A533A69F2 for ; Wed, 9 Mar 2011 06:32:45 -0800 (PST) Received: by iyj8 with SMTP id 8so722014iyj.31 for ; Wed, 09 Mar 2011 06:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vl0Jmp/lz5labxRJOyOEJZWjIlCnLkXfAk66NzPkfdo=; b=U8i3BLGQBxAJ3RTaZ+qeDKPdv+FFCBf+z4pr7I9H8K2CtXPn4bYQdBbvIFRJfwP/z/ oStd6uiW3vSzfxbepYl7hdMiTYVDA+N5h644xQmwYYXCi4fmZH/TCG1ZjfomKL4c0xof GK9kylwglryczRt2PEM2vhXBuICJac3hf5n8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xfr3HkXdpDRJEZn7r3WM/KgAuepANnDnZH2yj0olmix7RgMWJ7nrrrhj7fZaHs7ccX l7sb/GYiH1pLrsrg6dhWSCGQO1Awu9Gu1v97TH4NdZ33aqhFayDzM9m+dn63hlTdIfVa AflaKnXSMosR+3fc13lfA5X4t0ZoQrA9BaFVQ= MIME-Version: 1.0 Received: by 10.42.77.74 with SMTP id h10mr7358202ick.99.1299681241049; Wed, 09 Mar 2011 06:34:01 -0800 (PST) Received: by 10.43.61.80 with HTTP; Wed, 9 Mar 2011 06:34:01 -0800 (PST) In-Reply-To: <4D778C86.4020105@ogud.com> References: <20110309133017.GA19809@odin.mars.sol> <4D778C86.4020105@ogud.com> Date: Wed, 9 Mar 2011 09:34:01 -0500 Message-ID: From: Phillip Hallam-Baker To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=20cf3005dc06b1ab95049e0d9e61 Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:32:47 -0000 --20cf3005dc06b1ab95049e0d9e61 Content-Type: text/plain; charset=ISO-8859-1 Like Olafur, I think that this record may well be useful in the context of automating key management. As such, it seems to me that it is quantitatively different from the URI and CAA proposals for new RRs. In those cases the objective is to support applications that build on top of DNS. So it is probably best to let them rise or fall on their own merits. The alternative being for DNSEXT to get into complicated negotiations and synchronizations with other WGs. In this case the proposal is really one that addresses the DNS infrastructure itself and so it may require a somewhat higher degree of scrutiny. On Wed, Mar 9, 2011 at 9:19 AM, Olafur Gudmundsson wrote: > > > > On 09/03/2011 8:30 AM, Scott Schmit wrote: > >> On Tue, Mar 08, 2011 at 08:32:05PM +0000, Tony Finch wrote dnsext: >> >>> On Tue, 8 Mar 2011, Roy Arends wrote: >>> >>>> >>>> D. Motivation for the new RRTYPE application? >>>> >>>> To allow a copy of the DS RRset [RFC4034] to be published >>>> in the child zone, which is used to update the parent DS RRset. >>>> It is expected that this will allow the rollover of a key >>>> signing >>>> key to be automated. >>>> >>> >>> Why not just use the child zone's SEP DNSKEY RRs for this purpose? >>> >> >> I'm inclined to agree with this, but even if it's decided that the >> DNSKEY RRs aren't sufficient, why not just use DS on the client side? I >> see that RFC 3658 forbids it, but I'm not sure I understand why. We >> don't have CNS in addition to NS, so why should DS be different? I can >> understand that DS must be ignored by a client unless it's signed by the >> parent, but if that check doesn't already exist, we're already in >> trouble. >> > > Using SEP bits in DNSKEY records does not work when a zone wants to retire > an algorithm, the DS MUST be removed before the corresponding DNSKEY record > is removed. > > > >> So, maybe they didn't think of the use case this draft is trying to >> address and forbade it to keep the software implementations simpler? But >> that could have been accomplished simply by saying that a DS on the >> child side is ignored for validation purposes (it now becomes pointless >> (but harmless) to include it, except as a way to securely send DS >> records from the child to the parent). >> > > RFC3658 specified for the first time a record that can only live at the > parent and this required major changes to resolution algorithm > implementations. > If there is anything we have learned in the last 25+ years of DNS is this: > "If the same information can appear in two places it will not be the same > and you have no idea which version resolvers will use" > Just look at what different resolvers do when the parent and child NS > records differ. > > > > I can understand the motivation of introducing a new RRTYPE to avoid >> needing to alter existing MUST NOTs, but CDS just seems unnecessary. >> >> Maybe there's another reason to forbid DS on the child side that I've >> overlooked? >> >> > see above, and new types a cheap, and this gives the child full control > over the changes in the DS in parent. Similarly this can be used to update > trust anchors for an Island of security. > > > I encouraged George to submit this, as I had the same idea about the same > time as he did, in the context of automating DNS operator change/transfer. > > This record does not change the DNS control plane (resolvers) it is only > published for information purposes and to be used by zone content management > tools. > > Olafur > > PS: I think that original DNS had NS RRset in two places was the biggest > design mistake and we have spent lots of time and effort to overcome that. > This choice was done for expediency and/or optimization reasons. s > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --20cf3005dc06b1ab95049e0d9e61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Like Olafur, I think that this record may well be useful in the context of = automating key management.

As such, it seems to me that = it is quantitatively different from the URI and CAA proposals for new RRs. = In those cases the objective is to support applications that build on top o= f DNS. So it is probably best to let them rise or fall on their own merits.= The alternative being for DNSEXT to get into complicated negotiations and = synchronizations with other WGs.


In this case the proposal is really one = that addresses the DNS infrastructure itself and so it may require a somewh= at higher degree of scrutiny.


On Wed, Mar 9, 2011 at 9:19 AM, Olafur Gudmundsson <ogud@ogud.com> wrote:
<hat=3D"RFC3658-editor">


On 09/03/2011 8:30 AM, Scott Schmit wrote:
On Tue, Mar 08, 2011 at 08:32:05PM +0000, Tony Finch wrote dnsext:
On Tue, 8 Mar 2011, Roy Arends wrote:

=A0 =A0D. =A0 =A0Motivation for the new RRTYPE application?

=A0 =A0 =A0 =A0 =A0To allow a copy of the DS RRset [RFC4034] to be publish= ed
=A0 =A0 =A0 =A0 =A0in the child zone, which is used to update the parent D= S RRset.
=A0 =A0 =A0 =A0 =A0It is expected that this will allow the rollover of a k= ey signing
=A0 =A0 =A0 =A0 =A0key to be automated.

Why not just use the child zone's SEP DNSKEY RRs for this purpose?

I'm inclined to agree with this, but even if it's decided that the<= br> DNSKEY RRs aren't sufficient, why not just use DS on the client side? I=
see that RFC 3658 forbids it, but I'm not sure I understand why. =A0We<= br> don't have CNS in addition to NS, so why should DS be different? I can<= br> understand that DS must be ignored by a client unless it's signed by th= e
parent, but if that check doesn't already exist, we're already in trouble.

Using SEP bits in DNSKEY records does not work when a zone wants to retire = an algorithm, the DS MUST be removed before the corresponding DNSKEY record= is removed.



So, maybe they didn't think of the use case this draft is trying to
address and forbade it to keep the software implementations simpler? But that could have been accomplished simply by saying that a DS on the
child side is ignored for validation purposes (it now becomes pointless
(but harmless) to include it, except as a way to securely send DS
records from the child to the parent).

RFC3658 specified for the first time a record that can only live at the par= ent and this required major changes to resolution algorithm implementations= .
If there is anything we have learned in the last 25+ years of DNS is this: = "If the same information can appear in two places it will not be the s= ame and you have no idea which version resolvers will use"
Just look at what different resolvers do when the parent and child NS recor= ds differ.



I can understand the motivation of introducing a new RRTYPE to avoid
needing to alter existing MUST NOTs, but CDS just seems unnecessary.

Maybe there's another reason to forbid DS on the child side that I'= ve
overlooked?


see above, and new types a cheap, and this gives the child full control
over the changes in the DS in parent. Similarly this can be used to update = trust anchors for an Island of security.

<disclaimer>
I encouraged George to submit this, as I had the same idea about the same t= ime as he did, in the context of automating DNS operator change/transfer. </disclaimer>
This record does not change the DNS control plane (resolvers) it is only pu= blished for information purposes and to be used by zone content management = tools.

=A0 =A0 =A0 =A0Olafur

PS: I think that original DNS had NS RRset in two places was the biggest de= sign mistake and we have spent lots of time and effort to overcome that. Th= is choice was done for expediency and/or optimization reasons. s

_______________________________________________
dnsext mailing list
dnsext@ietf.org = https://www.ietf.org/mailman/listinfo/dnsext



--
Website: http://hallambaker.com/

--20cf3005dc06b1ab95049e0d9e61-- From matt@conundrum.com Wed Mar 9 07:47:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77A0D3A6A1A for ; Wed, 9 Mar 2011 07:47:25 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D5G2ydy3qaz for ; Wed, 9 Mar 2011 07:47:24 -0800 (PST) Received: from bawls.conundrum.com (unknown [216.235.8.92]) by core3.amsl.com (Postfix) with ESMTP id 9FBF13A696D for ; Wed, 9 Mar 2011 07:47:24 -0800 (PST) Received: from [216.235.10.34] ([216.235.10.34]) (authenticated bits=0) by bawls.conundrum.com (8.14.3/8.14.3) with ESMTP id p29Fl659000271; Wed, 9 Mar 2011 10:47:08 -0500 (EST) (envelope-from matt@conundrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Pounsett In-Reply-To: <20110309133017.GA19809@odin.mars.sol> Date: Wed, 9 Mar 2011 10:47:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110309133017.GA19809@odin.mars.sol> To: Scott Schmit X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:47:25 -0000 On 2011/03/09, at 08:30, Scott Schmit wrote: > I'm inclined to agree with this, but even if it's decided that the > DNSKEY RRs aren't sufficient, why not just use DS on the client side? = I > see that RFC 3658 forbids it, but I'm not sure I understand why. In addition to the reasons given by others for not reworking a decision = already made, I'll note a difference you've overlooked in your post. = The NS set in the parent zone is non-authoritative data which the NS set = at the apex of the child zone overwrites in a cache. The DS set in the = parent zone is authoritative, and the child zone may not also claim = authority for those records. From hallam@gmail.com Wed Mar 9 09:16:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442463A6765 for ; Wed, 9 Mar 2011 09:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkN9ZiIb+nnf for ; Wed, 9 Mar 2011 09:16:33 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3D0CA3A65A6 for ; Wed, 9 Mar 2011 09:16:32 -0800 (PST) Received: by bwz13 with SMTP id 13so973840bwz.31 for ; Wed, 09 Mar 2011 09:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=q+yoDnwz3NE2k1Dn5wgsgWlRO6ko5qOPUJ0eeU1hZRI=; b=xTiRTWbqNxuQHWeu9OmuB3qRHPYmOZiFVFPY21dItEhLAjo6fmK/pnNJ9gAnhi4Pci mpwIghQl3so0a2V8Rl00nUCydRV4FEJCgreMig1yMQHX4kt6hQqEzCwZCPNyna3aE+tO x9Dzc30CjOqh6tMWmYUnqg5Ka7HrHYvLzZM8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vQ3NJhdQ0pGGx+z1iUxHqzPd7F6MKZRgvIHm8tb4FRHlvqWG3xVdce60jldQ9OybAQ fasuuo0UKKaqvXVNLjvEObMQjOPokpFjLDAWXv/u3vFcXZzYaJHKZFhM2N707IGPpDBS 4Yll/FIf96OU4XOt76ydbpKrcSPaKRxEXuYzE= MIME-Version: 1.0 Received: by 10.204.174.193 with SMTP id u1mr5654678bkz.26.1299691068870; Wed, 09 Mar 2011 09:17:48 -0800 (PST) Received: by 10.204.59.7 with HTTP; Wed, 9 Mar 2011 09:17:48 -0800 (PST) Date: Wed, 9 Mar 2011 12:17:48 -0500 Message-ID: From: Phillip Hallam-Baker To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=bcaec52e601d7a516a049e0fe896 Subject: [dnsext] Revised version of ESRV X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 17:16:35 -0000 --bcaec52e601d7a516a049e0fe896 Content-Type: text/plain; charset=ISO-8859-1 All, Brian and I have produced an updated version of ESRV. We believe it may be of interest to people looking at the problem of how to manage Web Services and Internet Services using the DNS. http://www.ietf.org/id/draft-hallambaker-esrv-01.txt The main purpose of the draft is to support features that are relevant to application space, but it is highly DNS-centric and so relevant to many discussions here. In particular the capabilities described are likely to be useful for attempts to address the tree aliasing problem. This version of the draft is considerably simplified from the -00 edition but still provides the same set of capabilities. The basic idea here is that when writing code to establish a connection to an Internet Service or a Web Service it is best if the platform and the infrastructure do as much work as possible and require the programmer to do as little as possible. The end goal being that the programmer specify only the domain name ( example.com) and the protocol (_http._tcp) they wish to connect to and the application program then provide the 'best' connection according to criteria that would be established at the most appropriate level which is only sometimes going to be in the application code. So the API call can look something like connection = Network.Connect ("example.com", "_http._tcp) When the programmer specifies read and write methods on the connection they are going to be wrapped in TLS or IPSEC accredited to appropriate keys. Unless there is a specific need for the programmer to take control (e.g. specify that TLS is required), everything can be handled automatically. One major concrete benefit here is that it would enable scripting languages to make use of TLS in mashups a lot easier. It also allows 'strict' security to be achieved for any Internet protocol and not just for HTTP. >From a design point of view, the main benefit it brings is to allow use of SRV and URI mechanisms to be made compatible with wildcard records and with aliases and to allow them to be retrofitted to existing Web Services. For example, imagine we have an existing Web Service, the donut shop geolocator protocol (DSGP). Currently we might have a few hundred thousand clients with a Web Service Endpoint (WSE) embedded: http://dsgp.donutinfo.info/webservices/dsgp/1.1/ Now imagine that we want to move to using SRV or URI. This is a choice that in my view should be made by the network administrator of the site. But at present the decision can only be made by the protocol designer and is going to be a matter of personal preference. Or alternatively, what if someone wants to propose an even better discovery mechanism that might make use of network geolocation data to select the most appropriate service. I believe that it is practical difficulties of this type that limit use of SRV. In the GSRV/ESRV mechanism the web service would be identified as simply ' donutinfo.info' All the decoration and detail necessary to turn that into a URI will be retrieved from the DNS. # Domain level information, tell clients that there is service level data available donutinfo.info GSRV 0 service "_dgsp._ws" donutinfo.info GSRV 0 uri "_dgsp._ws" # Service level information, we have two hosts, both offer TLS on port 443 _dgsp._ws.donutinfo.info ESRV 0 tls "optional=443" _dgsp._ws.donutinfo.info URI 1 1 80 " http://host1.donutinfo.info/webservices/dsgp/1.1//" _dgsp._ws.donutinfo.info URI 1 1 80 " http://host2.donutinfo.info/webservices/dsgp/1.1//" The main objection to using prefixed records to date has been that they interact badly with wildcards and aliases. The above scheme is fully compatible with both. The key is that two records are used: Queries for GSRV records NEVER take a prefix. A GSRV record may thus be used with a wildcard or be the target of an alias without causing 'unexpected' results. ESRV records ALWAYS take a prefix and the prefix is ONLY applied to a canonical name (i.e. the target of a CNAME or DNAME). The combination of these rules means that it should never be the case that a query results in a 'not found' situation because the resolution missed the fact that there was a CNAME alias, nor should a query result in extraneous records being returned as a wildcard matches undesired protocol prefixes. -- Website: http://hallambaker.com/ --bcaec52e601d7a516a049e0fe896 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

Brian and I have produced an updated ver= sion of ESRV. We believe it may be of interest to people looking at the pro= blem of how to manage Web Services and Internet Services using the DNS.

http://www.ietf.org/id/draft-hallambaker-esrv-01.txt

The main purpose of the draft is to support features that are relevan= t to application space, but it is highly DNS-centric and so relevant to man= y discussions here. In particular the capabilities described are likely to = be useful for attempts to address the tree aliasing problem.


This version of the draft is considerabl= y simplified from the -00 edition but still provides the same set of capabi= lities.

The basic idea here is that when writing c= ode to establish a connection to an Internet Service or a Web Service it is= best if the platform and the infrastructure do as much work as possible an= d require the programmer to do as little as possible.

The end goal being that the programmer specify only the= domain name (example.com) and the proto= col (_http._tcp) they wish to connect to and the application program then p= rovide the 'best' connection according to criteria that would be es= tablished at the most appropriate level which is only sometimes going to be= in the application code.


So the API call can look something like<= /div>

connection =3D Network.Connect ("example.com", "_http._tcp)

<= /div>
When the programmer specifies read and write methods on the connection= they are going to be wrapped in TLS or IPSEC accredited to appropriate key= s. Unless there is a specific need for the programmer to take control (e.g.= specify that TLS is required), everything can be handled automatically.

One major concrete benefit here is that it would enable= scripting languages to make use of TLS in mashups a lot easier. It also al= lows 'strict' security to be achieved for any Internet protocol and= not just for HTTP.


From a design point of view, the main be= nefit it brings is to allow use of SRV and URI mechanisms to be made compat= ible with wildcard records and with aliases and to allow them to be retrofi= tted to existing Web Services.

For example, imagine we have an existing Web Service, t= he donut shop geolocator protocol (DSGP). Currently we might have a few hun= dred thousand clients with a Web Service Endpoint (WSE) embedded:



Now imagine that we want to move to using SRV or UR= I. This is a choice that in my view should be made by the network administr= ator of the site. But at present the decision can only be made by the proto= col designer and is going to be a matter of personal preference. Or alterna= tively, what if someone wants to propose an even better discovery mechanism= that might make use of network geolocation data to select the most appropr= iate service. I believe that it is practical difficulties of this type that= limit use of SRV.

In the GSRV/ESRV mechanism the web service would be ide= ntified as simply 'donutinfo.info= ' All the decoration and detail necessary to turn that into a URI will = be retrieved from the DNS.

# Domain level information, tell clients that there is = service level data available
do= nutinfo.info =A0GSRV 0 service "_dgsp._ws"
donutinfo.info =A0GSRV 0 uri "_dgsp._ws= "

# Service level information, we have two hosts, both of= fer TLS on port 443
_dgsp._w= s.donutinfo.info =A0ESRV 0 tls "optional=3D443"


The main objection to using prefixed records to d= ate has been that they interact badly with wildcards and aliases. The above= scheme is fully compatible with both. The key is that two records are used= :

Queries for GSRV records NEVER take a prefix. A GSRV re= cord may thus be used with a wildcard or be the target of an alias without = causing 'unexpected' results.

ESRV records= ALWAYS take a prefix and the prefix is ONLY applied to a canonical name (i= .e. the target of a CNAME or DNAME).

The combination of these rules means that it should nev= er be the case that a query results in a 'not found' situation beca= use the resolution missed the fact that there was a CNAME alias, nor should= a query result in extraneous records being returned as a wildcard matches = undesired protocol prefixes.


--bcaec52e601d7a516a049e0fe896-- From kim.davies@icann.org Wed Mar 9 10:09:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 783623A693B for ; Wed, 9 Mar 2011 10:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KYRaYVh7rSW for ; Wed, 9 Mar 2011 10:09:21 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 5209C3A68CF for ; Wed, 9 Mar 2011 10:09:21 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 9 Mar 2011 10:10:37 -0800 From: Kim Davies To: "dnsext@ietf.org" Date: Wed, 9 Mar 2011 10:10:36 -0800 Thread-Topic: BOF on variants for ICANN San Francisco Thread-Index: AcvehUqs/8BuycZgTNup3PdJqWOM4g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EE8A5F5A26CD474AB98332948A06DEBDicannorg_" MIME-Version: 1.0 Cc: Dennis Jennings Subject: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 18:09:28 -0000 --_000_EE8A5F5A26CD474AB98332948A06DEBDicannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear colleagues, We are holding an informal birds-of-a-feather type meeting at the ICANN mee= ting in San Francisco. The idea is to discuss the work ongoing in both ICAN= N and IETF circles, and brainstorm how the work in both groups can benefit = one another. A goal for the discussion is to identify how to best allocate = resources to avoid duplicate work, as well as having ICANN's work help guid= e the IETF's scope of work, and vice versa. Anyone with an interest in the discussions on variant issues within the IET= F and ICANN is welcome to attend. The meeting will be held at 2pm on Thursday 17 March. The room is called El= izabethan D in the meeting venue, the Westin on Union Square. Also note there is a more formal, scheduled meeting on the agenda to discus= s ICANN variant issues, specifically presenting case studies from different= regions that may require variant solutions. This is separate to this BOF a= nd is being held at Wednesday at 3pm (see http://svsf40.icann.org/node/2219= 3). We will recap any relevant discussion from that meeting briefly in the = BOF. kim (On behalf of ICANN's staff variant project team) --_000_EE8A5F5A26CD474AB98332948A06DEBDicannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear colleagues,

<= /div>
We are holding an informal birds-of-a-feather type meeting at the= ICANN meeting in San Francisco. The idea is to discuss the work ongoing in= both ICANN and IETF circles, and brainstorm how the work in both groups ca= n benefit one another. A goal for the discussion is to identify how to best= allocate resources to avoid duplicate work, as well as having ICANN's work= help guide the IETF's scope of work, and vice versa.

<= div>Anyone with an interest in the discussions on variant issues within the= IETF and ICANN is welcome to attend.

The meeting = will be held at 2pm on Thursday 17 March. The room is called Elizabe= than D in the meeting venue, the Westin on Union Square.

Also note there is a more formal, scheduled meeting on the agenda to= discuss ICANN variant issues, specifically presenting case studies from di= fferent regions that may require variant solutions. This is separate to thi= s BOF and is being held at Wednesday at 3pm (see http://svsf40.icann.org/node/22193). We will recap= any relevant discussion from that meeting briefly in the BOF.
kim
(On behalf of ICANN's staff variant project team= )

= --_000_EE8A5F5A26CD474AB98332948A06DEBDicannorg_-- From hallam@gmail.com Wed Mar 9 10:32:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E033A6944 for ; Wed, 9 Mar 2011 10:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=-1.487, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tSiBD6qCsFz for ; Wed, 9 Mar 2011 10:32:35 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 176603A6933 for ; Wed, 9 Mar 2011 10:32:35 -0800 (PST) Received: by iyj8 with SMTP id 8so981334iyj.31 for ; Wed, 09 Mar 2011 10:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gO6QWQJll10LHB5BGn/A8m9USHEy6BEsr+/G10hKesM=; b=vmbV3PC/2nOvJGwIuUO8g0ahs9arCMSVFBjf0ql7zUJXOq9Auus7DBVkpFfQoM/0BU P33dZmrQTXTb5SeqqUHOfeZCCIGRJyoDyQcRe0qpRQSdY1U0VqCoUpkbAM/K8rThfGHx 6YRuYsvvhYMJGO/Fi3vptX3xAXzn2YkI1RMMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PV+My0mxl7GGMRS94xouSNStAeit36TKUn5R6fWplO7TGZSekBObsE+6Nxx2QUpIvF Gfjp3jlBx4nA4yBlDZkcNzWzc91qmBamVoW8JnvGFAzVlb/Nxk5HvMlanb1nsvKWw/eu lp9bePa/D+WMPfkBYguntht6dDBDrvnONibEI= MIME-Version: 1.0 Received: by 10.42.77.74 with SMTP id h10mr7827402ick.99.1299695631386; Wed, 09 Mar 2011 10:33:51 -0800 (PST) Received: by 10.43.61.80 with HTTP; Wed, 9 Mar 2011 10:33:51 -0800 (PST) In-Reply-To: <20110218213453.GB96163@registro.br> References: <20110218213453.GB96163@registro.br> Date: Wed, 9 Mar 2011 13:33:51 -0500 Message-ID: From: Phillip Hallam-Baker To: Frederico A C Neves , Ben Laurie , Rob Stradling Content-Type: multipart/alternative; boundary=20cf3005dc066cc955049e10f8ea Cc: dnsext@ietf.org Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 18:32:37 -0000 --20cf3005dc066cc955049e10f8ea Content-Type: text/plain; charset=ISO-8859-1 Just to be clear here, what is being proposed here is the version of the specification described in the -02 version of the draft which was simplified in response to feedback from the list. In particular we removed a feature from the previous version of the specification that allowed a single CAA RR to contain a list of property entries. That was considered to be confusing Looking through the draft, there is a typo where some text in 3.1 seems to have escaped this change and may be the source of confusion. The CAA data field consists of a sequence of at least one property entry. Each property entry consists of a sequence of: This should read. The CAA data field contains one property entry. A property entry consists of a sequence of: I also note that I did not do a block diagram of the data section. This should be +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| | Flags | Tag Length = n | +----------------+----------------+...+---------------+ | Tag char 0 | Tag Char 1 |...| Tag Char n | +----------------+----------------+...+---------------+ | Data byte 0 | Data byte 1 |...| Data byte m | +----------------+----------------+...+---------------+ Where n is the length specified in the tag length field and m is the remaining octets in the data field (m = l - n - 2) where l is the length of the data section. I will make these corrections to the editing copy of the draft. This does not change the intended semantics of the proposal. On Fri, Feb 18, 2011 at 4:34 PM, Frederico A C Neves wrote: > Dear Colleagues, > > Bellow is a completed template requesting a new RRTYPE assignment > under the procedures of RFC5395. > > This message starts a 3 weeks period for an expert-review of the DNS > RRTYPE parameter allocation for CAA specified in > http://tools.ietf.org/html/draft-hallambaker-donotissue-02 > IANA #412190 > > If you have comments regarding this request please post them here > before Mar 11th 18:00 UTC. > > Best Regards, > Frederico Neves > > --begin 5395 template CAA-- > A. Submission Date: 3 Dec 2010 > > B. Submission Type: > [X] New RRTYPE > [ ] Modification to existing RRTYPE > > C. Contact Information for submitter: > Name: Phillip Hallam-Baker > Email Address: phill@hallambaker.com > International telephone number: +1 617 395 4123 > Other contact handles: > > (Note: This information will be publicly posted.) > > D. Motivation for the new RRTYPE application? > Please keep this part at a high level to inform the Expert and > reviewers about uses of the RRTYPE. Remember most reviewers > will be DNS experts that may have limited knowledge of your > application space. > > The Certification Authority Authorization (CAA) DNS Resource Record > allows a DNS domain name holder to specify the certificate signing > certificate(s) authorized to issue certificates for that domain. CAA > resource records allow a public Certification Authority to implement > additional controls to reduce the risk of unintended certificate mis- > issue. And is designed to be extensible in order to support related > concerns including enforcement of issue restriction in applications. > > E. Description of the proposed RR type. > This description can be provided in-line in the template, as an > attachment, or with a publicly available URL: > > A detailed specification is posted is given in > draft-hallambaker-donotissue: > > https://datatracker.ietf.org/doc/draft-hallambaker-donotissue/ > > > F. What existing RRTYPE or RRTYPEs come closest to filling that > need and why are they unsatisfactory? > > The only current means by which this information can be expressed > in the DNS is via a TXT record which is not differentiated for this > purpose. > > The approach here addfresses purposes that are clearly outside > the purpose of the CERT record and similar 'keys-in-DNS' > approaches. > > > G. What mnemonic is requested for the new RRTYPE (optional)? > Note: This can be left blank and the mnemonic decided after the > template is accepted. > > The proposed mnemonic is CAA standing for Certification Authority > Authorization. > > H. Does the requested RRTYPE make use of any existing IANA > Registry or require the creation of a new IANA sub-registry in > DNS Parameters? > > If so, please indicate which registry is to be used or created. > If a new sub-registry is needed, specify the allocation policy > for it and its initial contents. Also include what the > modification procedures will be. > > Yes, the following registry assignment is requested. > > 5.2. Certification Authority Authorization Properties > > IANA [is requested to create] the Certification Authority > Authorization Properties > registry with the following initial values: > > Meaning Reference > ----------- ----------------------------------------------- --------- > path Authorization Entry by Signature Path [RFCXXXX] > policy Authorization Entry by Certificate Policy [RFCXXXX] > > Addition of tag identifiers requires a public specification and > expert review as set out in RFC5395 [RFC5395] > > Note that information carried in this record addresses application > layer concerns. As such it is highly desirable to employ a tag-value > approach to attribute specification than the code-value approach that > is employed at lower layers in the stack. > > I. Does the proposal require/expect any changes in DNS > servers/resolvers that prevent the new type from being > processed as an unknown RRTYPE (see [RFC3597])? > > No. > > J. Comments: > > While the CAA proposal made in the accompanying Internet Draft > represents a complete technical proposal, development of a full CAA > standard will require further work that cannot be begun until a DNS RR > assignment is made. > > In particular the CAA proposal MAY be proposed as the basis of future > minimum issue guidelines for Domain Validated Certificates published > by CA-Browser Forum. It is hard to see how such a proposal could be > made without first obtaining significant experience of enforcing CAA > issue restrictions. > > The CAA proposal MAY also be relevant to ongoing work in the IETF > Applications area (WEBSEC) and the security area (TLS, IPSEC, Proposed > KIDNS). > > Given the large number of moving parts, the proposal has been crafted > with the intention of minimizing the number of dependencies in the > system. > --end 5395 template CAA-- > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --20cf3005dc066cc955049e10f8ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just to be clear here, what is being proposed here is the version of the sp= ecification described in the -02 version of the draft which was simplified = in response to feedback from the list.

In particular we = removed a feature from the previous version of the specification that allow= ed a single CAA RR to contain a list of property entries. That was consider= ed to be confusing=A0


Looking through the draft, there is a ty= po where some text in 3.1 seems to have escaped this change and may be the = source of confusion.

The CAA data field consi= sts of a sequence of at least one property=A0entry. =A0Each property entry = consists of a sequence of:

This should read.

T= he CAA data field contains one property=A0entry. =A0A property entry consis= ts of a sequence of:


I also note that I = did not do a block diagram of the data section. This should be

+0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-|
| = Flags =A0 =A0 =A0 =A0 =A0| Tag Length =3D n |
+----------------+----------------+...+---------------+
| Tag char 0 =A0 =A0 | Tag Char 1 =A0 =A0 |...|=A0Tag Char n =A0 =A0|
+----------------+----------------+...+---------------= +
| Data byte 0 =A0 =A0|=A0Data byte 1=A0=A0 =A0|...|=A0Data byte m=A0=A0 |
+----------------+----------------+...+---------------= +

Where n is the length specified in the ta= g length field and m is the remaining octets in the data field (m =3D l - n= - 2) where l is the length of the data section.


I will make these corrections to the edi= ting copy of the draft.

This does not change the i= ntended semantics of the proposal.

On Fri, Feb 18, 2011 at 4:34 PM, Frederico A C Neves <= fneves@registro.br> wro= te:
Dear Colleagues,

Bellow is a completed template requesting a new RRTYPE assignment
under the procedures of RFC5395.

This message starts a 3 weeks period for an expert-review of the DNS
RRTYPE parameter allocation for CAA specified in
http://tools.ietf.org/html/draft-hallambaker-donotissue-02
IANA #412190

If you have comments regarding this request please post them here
before Mar 11th 18:00 UTC.

Best Regards,
Frederico Neves

--begin 5395 template CAA--
=A0A. =A0 =A0Submission Date: 3 Dec 2010

=A0B. =A0 =A0Submission Type:
=A0 =A0 =A0 =A0[X] New RRTYPE
=A0 =A0 =A0 =A0[ ] Modification to existing RRTYPE

=A0C. =A0 =A0Contact Information for submitter:
=A0 =A0 =A0 =A0 =A0 Name: Phillip Hallam-Baker
=A0 =A0 =A0 =A0 =A0 Email Address: phill@hallambaker.com
=A0 =A0 =A0 =A0 =A0 International telephone number: +1 617 395 4123
=A0 =A0 =A0 =A0 =A0 Other contact handles:

=A0 =A0 =A0 =A0 =A0 (Note: This information will be publicly posted.)

=A0D. =A0 =A0Motivation for the new RRTYPE application?
=A0 =A0 =A0 =A0Please keep this part at a high level to inform the Expert = and
=A0 =A0 =A0 =A0reviewers about uses of the RRTYPE. =A0Remember most review= ers
=A0 =A0 =A0 =A0will be DNS experts that may have limited knowledge of your=
=A0 =A0 =A0 =A0application space.

=A0The Certification Authority Authorization (CAA) DNS Resource Record
=A0allows a DNS domain name holder to specify the certificate signing
=A0certificate(s) authorized to issue certificates for that domain. =A0CAA=
=A0resource records allow a public Certification Authority to implement =A0additional controls to reduce the risk of unintended certificate mis- =A0issue. And is designed to be extensible in order to support related
=A0concerns including enforcement of issue restriction in applications.
=A0E. =A0 =A0Description of the proposed RR type.
=A0 =A0 =A0 =A0This description can be provided in-line in the template, a= s an
=A0 =A0 =A0 =A0attachment, or with a publicly available URL:

A detailed specification is posted is given in
draft-hallambaker-donotissue:

https://datatracker.ietf.org/doc/draft-hallambaker-donoti= ssue/


=A0F. =A0 =A0What existing RRTYPE or RRTYPEs come closest to filling that<= br> =A0 =A0 =A0 =A0need and why are they unsatisfactory?

The only current means by which this information can be expressed
in the DNS is via a TXT record which is not differentiated for this
purpose.

The approach here addfresses purposes that are clearly outside
the purpose of the CERT record and similar 'keys-in-DNS'
approaches.


=A0G. =A0 =A0What mnemonic is requested for the new RRTYPE (optional)?
=A0 =A0 =A0 =A0Note: This can be left blank and the mnemonic decided after= the
=A0 =A0 =A0 =A0template is accepted.

The proposed mnemonic is CAA standing for Certification Authority
Authorization.

=A0H. =A0 =A0Does the requested RRTYPE make use of any existing IANA
=A0 =A0 =A0 =A0Registry or require the creation of a new IANA sub-registry= in
=A0 =A0 =A0 =A0DNS Parameters?

=A0 =A0 =A0 =A0If so, please indicate which registry is to be used or crea= ted.
=A0 =A0 =A0 =A0If a new sub-registry is needed, specify the allocation pol= icy
=A0 =A0 =A0 =A0for it and its initial contents. =A0Also include what the =A0 =A0 =A0 =A0modification procedures will be.

Yes, the following registry assignment is requested.

5.2. =A0Certification Authority Authorization Properties

=A0IANA [is requested to create] the Certification Authority
Authorization Properties
=A0registry with the following initial values:

=A0 =A0 =A0 =A0 =A0 =A0 Meaning =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Reference
=A0----------- =A0----------------------------------------------- =A0------= ---
=A0path =A0 =A0 =A0 =A0 Authorization Entry by Signature Path =A0 =A0 =A0 = =A0 =A0 =A0[RFCXXXX]
=A0policy =A0 =A0 =A0 Authorization Entry by Certificate Policy =A0 =A0 =A0= =A0[RFCXXXX]

=A0Addition of tag identifiers requires a public specification and
=A0expert review as set out in RFC5395 [RFC5395]

Note that information carried in this record addresses application
layer concerns. As such it is highly desirable to employ a tag-value
approach to attribute specification than the code-value approach that
is employed at lower layers in the stack.

=A0I. =A0 =A0Does the proposal require/expect any changes in DNS
=A0 =A0 =A0 =A0servers/resolvers that prevent the new type from being
=A0 =A0 =A0 =A0processed as an unknown RRTYPE (see [RFC3597])?

No.

=A0J. =A0 =A0Comments:

While the CAA proposal made in the accompanying Internet Draft
represents a complete technical proposal, development of a full CAA
standard will require further work that cannot be begun until a DNS RR
assignment is made.

In particular the CAA proposal MAY be proposed as the basis of future
minimum issue guidelines for Domain Validated Certificates published
by CA-Browser Forum. It is hard to see how such a proposal could be
made without first obtaining significant experience of enforcing CAA
issue restrictions.

The CAA proposal MAY also be relevant to ongoing work in the IETF
Applications area (WEBSEC) and the security area (TLS, IPSEC, Proposed
KIDNS).

Given the large number of moving parts, the proposal has been crafted
with the intention of minimizing the number of dependencies in the
system.
--end 5395 template CAA--
_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



--
Website: http://hallambaker.com/

--20cf3005dc066cc955049e10f8ea-- From ogud@ogud.com Wed Mar 9 10:46:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11CBA3A6928 for ; Wed, 9 Mar 2011 10:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z17RdXHBuDq2 for ; Wed, 9 Mar 2011 10:46:40 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 909A33A692A for ; Wed, 9 Mar 2011 10:46:39 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p29IltDf046842 for ; Wed, 9 Mar 2011 13:47:55 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D77CB55.40407@ogud.com> Date: Wed, 09 Mar 2011 13:47:49 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <72A22513B1644CFE9023189F93BFDD32@local> <20110309080006.GA23957@miek.nl> <758260B7B5B34599BA80D9BA5A3840C0@local> <20110309090536.GA9578@miek.nl> In-Reply-To: <20110309090536.GA9578@miek.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 18:46:42 -0000 On 09/03/2011 4:05 AM, Miek Gieben wrote: > [ Quoting George Barwood in "Re: [dnsext] CDS RRTYPE review - Co"... ] >>>>> Why not just use the child zone's SEP DNSKEY RRs for this purpose? >>>> >>>> From the draft http://tools.ietf.org/html/draft-barwood-dnsop-ds-publish-01 >>>> >>>> key, delaying the time at which an attacker can start cryptanalysis; >> >>> So this is the sole reason for adding this new type? >> >> There are 4 reasons given, why do you quote only one? >> Please don't quote selectively. > > it is the first reason you give in the introduction in the draft. > >> One could probably add yet more reasons, e.g. >> It gives the child control over which Digest Type is used. >> It allows new Digest types to be deployed easily. >> It allows easy verification (by humans) as to whether the parent and child zones are in sync. >> >> But these are really just examples, fundamentally it's just proper design. >> It gives the child zone proper control of the parent DS RRset. > > ...if the parent cooperates... > > Is this proposal aimed at TLDs or at smaller zones? Because for .nl we > are just going to use EPP and let the registrar send in a DNSKEY which > we will convert to a DS (so you can not even choose your own hash > algo). > DNS >> TLD's and even in among your registrars when do you expect the last one to support DNSSEC updating of DS records? This mechanism can be used anywhere in the tree, and all it needs for use is a simple DNS lookup. How the parent is told to perform the lookup or how frequently the parent does the lookup is outside the scope of this application. Olafur PS: From miekg@atoom.net Wed Mar 9 10:53:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CC8A3A6A46 for ; Wed, 9 Mar 2011 10:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pUxy2xkNhIk for ; Wed, 9 Mar 2011 10:52:59 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by core3.amsl.com (Postfix) with ESMTP id 67EBD3A680F for ; Wed, 9 Mar 2011 10:52:58 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 99AC23FF63; Wed, 9 Mar 2011 19:54:13 +0100 (CET) Date: Wed, 9 Mar 2011 19:54:13 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20110309185413.GA1045@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <72A22513B1644CFE9023189F93BFDD32@local> <20110309080006.GA23957@miek.nl> <758260B7B5B34599BA80D9BA5A3840C0@local> <20110309090536.GA9578@miek.nl> <4D77CB55.40407@ogud.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <4D77CB55.40407@ogud.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 18:53:00 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting =EF=BF=BDlafur Gu=EF=BF=BDmundsson in "Re: [dnsext] CDS RRTYPE re= view - Co"... ] > >Is this proposal aimed at TLDs or at smaller zones? Because for .nl we > >are just going to use EPP and let the registrar send in a DNSKEY which > >we will convert to a DS (so you can not even choose your own hash > >algo). > > >=20 > DNS >> TLD's and even in among your registrars when do you expect > the last one to support DNSSEC updating of DS records? That state will probably never be reached. But I agree: "new types are cheap" grtz, -- Miek --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk13zNUACgkQJYuFzziA0PYxkQCg9IeIE0/AiEAfezLDTJAQ/lIM p4wAoNgeTYElR8Si00HA8fWzIATO4aSH =SkKF -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From ebw@abenaki.wabanaki.net Wed Mar 9 11:18:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4AF3A69AD for ; Wed, 9 Mar 2011 11:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=1.159, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izrm9ywBcyFT for ; Wed, 9 Mar 2011 11:18:08 -0800 (PST) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id 6B1673A680F for ; Wed, 9 Mar 2011 11:18:08 -0800 (PST) Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id p29HTW6F082287 for ; Wed, 9 Mar 2011 12:29:32 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4D77D2AF.7010203@abenaki.wabanaki.net> Date: Wed, 09 Mar 2011 14:19:11 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 19:18:09 -0000 I commend ICANN's staff variant project team for communicating (via Kim) a notice to the DNSEXT WG. I can recall no prior ICANN organized "IDN" activity to which an open invitation to the DNS (or IDN) technical community was offered -- every such activity I contributed to was due to accidental discovery on my part, not an invitation by ICANN. So that is an improvement. Unfortunately, the less than useful "variant" nomenclature is used, so one has to guess, assuming one differentiates between the issues presented by two very large character repertoires with a large intersection, character repertoires with sparse sub-repertoires of positionally dependent combining characters, character repertoires with pervasive diacriticals, or character repertoires with sparse or singleton pairs, the actual scope of work to be allocated to ICANN or the IETF. That is a non-improvement. Unfortunately also, the temporal properties of "synchronized domains", the result of some prior, and limited consultation between participants to both the IETF and ICANN, is not noted as very difficult to achieve and not removed from the possible areas of work to be undertaken, at least by an IETF WG. Of course, absence of mention is possibly an improvement. If arrangements for remote participation are made, I will participate. Eric P.S. Leveling both barrels at the innocent civilians presenting their l10n work from home using the i18n framework the IDN/IDNAbis WG's created ("case studies from different regions that may require variant solutions") is not a substitute for communicating policy issues with ICANN or a hard to identify ambiguous requirements author. A co-chair, you know who you are, please take note. From paul@xelerance.com Wed Mar 9 11:18:49 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C593A6A39 for ; Wed, 9 Mar 2011 11:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUS35RkNme2g for ; Wed, 9 Mar 2011 11:18:49 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 051D33A680F for ; Wed, 9 Mar 2011 11:18:49 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 6FB8BC54E; Wed, 9 Mar 2011 14:20:04 -0500 (EST) Date: Wed, 9 Mar 2011 14:20:03 -0500 (EST) From: Paul Wouters To: Miek Gieben In-Reply-To: <20110309090536.GA9578@miek.nl> Message-ID: References: <72A22513B1644CFE9023189F93BFDD32@local> <20110309080006.GA23957@miek.nl> <758260B7B5B34599BA80D9BA5A3840C0@local> <20110309090536.GA9578@miek.nl> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 19:18:50 -0000 On Wed, 9 Mar 2011, Miek Gieben wrote: >> It gives the child zone proper control of the parent DS RRset. > > ...if the parent cooperates... yeah, this is "triggers vs timers" all over again. I did not think there was any broad concensus on that? If the parent needs to do work, it might as well use the SEP flag in combination with the revoke bit. > Is this proposal aimed at TLDs or at smaller zones? I think TLDs because "smaller zones" tend to have other administrative cuts, not neccessarilly on the zone cut. > Because for .nl we > are just going to use EPP and let the registrar send in a DNSKEY which > we will convert to a DS (so you can not even choose your own hash > algo). That is less of a concern then the dnsop <-> Registrar communication, which I have the unfortunate experience of dealing with in non-standard ways precisely for the DS record updating. I don't think this issue is technical. SEP and Revoke is a fine solution, but an administrative one (parent does not want to kill child without a verified authentication of child to keep the lawyers happy. I don't see any method for automating the NS or Glue updates between child and parent. If we'regoing to introduce new RRtypes for this communication, I'd suggest tackling them all. And trust me, I'd love not to have to deal with Registrar APIs in our products :P Paul From dougb@dougbarton.us Wed Mar 9 11:35:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2EDC3A69D1 for ; Wed, 9 Mar 2011 11:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=1.047, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfVnu132P5cP for ; Wed, 9 Mar 2011 11:35:45 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 5231C3A698B for ; Wed, 9 Mar 2011 11:35:45 -0800 (PST) Received: (qmail 11112 invoked by uid 399); 9 Mar 2011 19:36:58 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 9 Mar 2011 19:36:58 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D77D6D8.9070609@dougbarton.us> Date: Wed, 09 Mar 2011 11:36:56 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eric Brunner-Williams References: <4D77D2AF.7010203@abenaki.wabanaki.net> In-Reply-To: <4D77D2AF.7010203@abenaki.wabanaki.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 19:35:46 -0000 On 03/09/2011 11:19, Eric Brunner-Williams wrote: > I commend ICANN's staff variant project team for communicating (via Kim) > a notice to the DNSEXT WG. > > I can recall no prior ICANN organized "IDN" activity to which an open > invitation to the DNS (or IDN) technical community was offered -- every > such activity I contributed to was due to accidental discovery on my > part, not an invitation by ICANN. One can pontificate on length at all the various individuals or groups that need/deserve special invitations to such an event. Or, one could realize that ICANN has been holding regular, public, and well-publicized events on the IDN topic since no later than 2004 (which is the first time I participated as a staff member). > Unfortunately, the less than useful "variant" nomenclature is used, so > one has to guess, assuming one differentiates between the issues > presented by two very large character repertoires with a large > intersection, character repertoires with sparse sub-repertoires of > positionally dependent combining characters, character repertoires with > pervasive diacriticals, or character repertoires with sparse or > singleton pairs, the actual scope of work to be allocated to ICANN or > the IETF. ICANN meetings are primarily populated by policy-focused individuals, not technologists. An expectation that such individuals would develop the level of technical knowledge described above is not rational. Further, the term "variant" has a relatively well understood meaning in the TLD policy context, where it is generally understood to be a simplification of several thorny technical problems. On the other hand, you and I agree that the fact ICANN is continuing to reach out the the technical community on this topic is a good thing. > Unfortunately also, the temporal properties of "synchronized domains", > the result of some prior, and limited consultation between participants > to both the IETF and ICANN, is not noted as very difficult to achieve > and not removed from the possible areas of work to be undertaken, at > least by an IETF WG. I don't think anyone involved thinks it's an easy problem, but maybe it hasn't been removed "from the possible areas of work to be undertaken" because some of us are actually working on it. :) hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From ajs@shinkuro.com Wed Mar 9 11:42:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2493A6A74 for ; Wed, 9 Mar 2011 11:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fK0GdagW7EG for ; Wed, 9 Mar 2011 11:42:58 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7C6B53A6967 for ; Wed, 9 Mar 2011 11:42:58 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 068F11ECB408; Wed, 9 Mar 2011 19:44:13 +0000 (UTC) Date: Wed, 9 Mar 2011 14:44:12 -0500 From: Andrew Sullivan To: Phillip Hallam-Baker Message-ID: <20110309194411.GG32629@shinkuro.com> References: <20110218213453.GB96163@registro.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Ben Laurie , Rob Stradling , dnsext@ietf.org Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 19:42:59 -0000 Hi, With my administrative hat on, I just want to clear up some details. On Wed, Mar 09, 2011 at 01:33:51PM -0500, Phillip Hallam-Baker wrote: > In particular we removed a feature from the previous version of the > specification that allowed a single CAA RR to contain a list of property > entries. That was considered to be confusing Is that a change to the definition of the RR? I.e. is there a difference between the RRTYPE in the original template and the one in the latest draft? If so, it's strictly speaking a new RRTYPE request and it needs a different template. The RRTYPE code that you get is for the particular definition. There isn't a mechanism so far to get a number and then be able to change the RRTYPE substantively, because the idea is that the typecode could be baked into software all over the place. > I will make these corrections to the editing copy of the draft. It would be good, actually, if you could post an update. The review requirements include these criteria for rejection: 1. Was documented in a manner that was not sufficiently clear to evaluate or implement. 3. The documentation of the proposed RRTYPE or RRTYPEs is incomplete. (Additional documentation can be provided during the public comment period or by the Expert.) The block diagram in particular would be helpful. > This does not change the intended semantics of the proposal. The Expert isn't reviewing the semantics of the protocol, so that doesn't matter. The expert is simply reviewing whether the RRTYPE assignment meets the criteria for assignment. These are pretty broad, but the filters are important for interoperability and therefore we need to follow them stringently. It would help, of course, if I also followed the procedures stringently and ensured the reviews got done on time. I'm not trying to be super bureaucratic here. But if there's a change to the RRTYPE as requested, it's important to know that. Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ebw@abenaki.wabanaki.net Wed Mar 9 12:06:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C7D43A6A5E for ; Wed, 9 Mar 2011 12:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgUjBodRVgjV for ; Wed, 9 Mar 2011 12:06:51 -0800 (PST) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id C14A53A696B for ; Wed, 9 Mar 2011 12:06:50 -0800 (PST) Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id p29IIJWN082498; Wed, 9 Mar 2011 13:18:20 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4D77DE1F.5080803@abenaki.wabanaki.net> Date: Wed, 09 Mar 2011 15:07:59 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Doug Barton References: <4D77D2AF.7010203@abenaki.wabanaki.net> <4D77D6D8.9070609@dougbarton.us> In-Reply-To: <4D77D6D8.9070609@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:06:54 -0000 On 3/9/11 2:36 PM, Doug Barton wrote: > One can pontificate on length ... I'm relieved to learn my observations were unnecessary, and that "variant" has a single, clear and unambiguous meaning. I look forward to your prompt solution of problems that have been beyond my poor means, and am grateful for the recovery of next Thursday's 2pm hour. Eric From dougb@dougbarton.us Wed Mar 9 12:12:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFA753A6A91 for ; Wed, 9 Mar 2011 12:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhTxLI9NC2rB for ; Wed, 9 Mar 2011 12:12:14 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 47F093A6A6E for ; Wed, 9 Mar 2011 12:12:11 -0800 (PST) Received: (qmail 3676 invoked by uid 399); 9 Mar 2011 20:13:25 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 9 Mar 2011 20:13:25 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D77DF64.5010709@dougbarton.us> Date: Wed, 09 Mar 2011 12:13:24 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D77D2AF.7010203@abenaki.wabanaki.net> <4D77D6D8.9070609@dougbarton.us> In-Reply-To: <4D77D6D8.9070609@dougbarton.us> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:12:15 -0000 On 03/09/2011 11:36, Doug Barton wrote: > One can pontificate on length at all the various Oy ... I looked at that 3 times before sending and still didn't see that the reason it looked weird was that I'd transposed on/at. Doug (why is dyslexia so hard to spell?) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From dougb@dougbarton.us Wed Mar 9 12:12:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3F3E3A6A87 for ; Wed, 9 Mar 2011 12:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efxc54-uVrtq for ; Wed, 9 Mar 2011 12:12:45 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 9A2383A6A6E for ; Wed, 9 Mar 2011 12:12:45 -0800 (PST) Received: (qmail 4100 invoked by uid 399); 9 Mar 2011 20:13:59 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 9 Mar 2011 20:13:59 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D77DF86.8010001@dougbarton.us> Date: Wed, 09 Mar 2011 12:13:58 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eric Brunner-Williams References: <4D77D2AF.7010203@abenaki.wabanaki.net> <4D77D6D8.9070609@dougbarton.us> <4D77DE1F.5080803@abenaki.wabanaki.net> In-Reply-To: <4D77DE1F.5080803@abenaki.wabanaki.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:12:46 -0000 On 03/09/2011 12:07, Eric Brunner-Williams wrote: > I'm relieved to learn my observations were unnecessary Glad I could help. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From ajs@shinkuro.com Wed Mar 9 12:15:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C477E3A6A80 for ; Wed, 9 Mar 2011 12:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ggwda7RWKd8 for ; Wed, 9 Mar 2011 12:15:33 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id EA0AD3A6A6E for ; Wed, 9 Mar 2011 12:15:32 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 368DF1ECB408 for ; Wed, 9 Mar 2011 20:16:49 +0000 (UTC) Date: Wed, 9 Mar 2011 15:16:47 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110309201647.GJ32629@shinkuro.com> References: <4D77D2AF.7010203@abenaki.wabanaki.net> <4D77D6D8.9070609@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D77D6D8.9070609@dougbarton.us> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:15:33 -0000 No hat. On Wed, Mar 09, 2011 at 11:36:56AM -0800, Doug Barton wrote: > Further, the term "variant" has a relatively well understood meaning in > the TLD policy context, where it is generally understood to be a > simplification of several thorny technical problems. I suspect I disagree with the above claim. Specifically, I think I disagree with "well understood". In my experience, terms that have inherently ambiguous meaning are almost never well understood. It is of course possible to understand ambiguity -- we wouldn't the word if we couldn't -- but in a wide array of cases, I think ambiguous terms are badly understood by their users. I also believe that part of the reason we are struggling with the aliasing discussion is exactly that very careful needs assessment is extremely hard. It is made all the harder by the unfortunate re-use of the term "Variant", which has a well-defined meaning in the context of "Character Variant Table" from RFC 3743. Attempting to simplify such thorny technical problems by lumping them all together under one term seems like a good idea, but it turns out not to be. It is often useful to bundle together a bunch of topics and call them by a more generic name. (Patents and copyrights are vastly different areas of the law, and yet it is sometimes useful to talk about "intellectual property". Philosophers and English scholars can often barely stand to be in the same room with each other, and yet they can all be professors of the Humanities.) For the present discussion about dealing with different labels (which happen to correspond to particular bits of natural language that "mean the same" or something like that), however, I think conflating these cases makes our task much harder. It has caused no small degree of mischief in the TLD policy arena, where in-principle solvable and necessarily unsolvable problems are sometimes spoken of as though they were the same. As perhaps the more technical end of an interchange with policy people at an ICANN meeting, those of us who care about this topic could help (in my opinion) a great deal just by teasing apart these ambiguities and trying to ensure that every time a term is used, it is used univocally. It might be painful, but in anticipation of the conversation we plan to have in Prague, it will no doubt help crystallize which issues are clear (so we can decide whether we know what to do), and which issues we do not yet understand. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ebw@abenaki.wabanaki.net Wed Mar 9 12:16:53 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980463A6A60 for ; Wed, 9 Mar 2011 12:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyvO4LWd222Y for ; Wed, 9 Mar 2011 12:16:52 -0800 (PST) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id BEB1E3A6984 for ; Wed, 9 Mar 2011 12:16:52 -0800 (PST) Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id p29ISMod082552; Wed, 9 Mar 2011 13:28:22 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4D77E07A.40406@abenaki.wabanaki.net> Date: Wed, 09 Mar 2011 15:18:02 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Doug Barton References: <4D77D2AF.7010203@abenaki.wabanaki.net> <4D77D6D8.9070609@dougbarton.us> <4D77DE1F.5080803@abenaki.wabanaki.net> <4D77DF86.8010001@dougbarton.us> In-Reply-To: <4D77DF86.8010001@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:16:53 -0000 On 3/9/11 3:13 PM, Doug Barton wrote: > On 03/09/2011 12:07, Eric Brunner-Williams wrote: >> I'm relieved to learn my observations were unnecessary > > Glad I could help. :) > > Your claim is that you've got clue. Prove it. From bmanning@karoshi.com Wed Mar 9 12:20:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493193A6A90 for ; Wed, 9 Mar 2011 12:20:02 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mmx6AszOek2I for ; Wed, 9 Mar 2011 12:20:00 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 7EF513A6A89 for ; Wed, 9 Mar 2011 12:19:50 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p29K4p7s003514; Wed, 9 Mar 2011 20:05:11 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p29K4UVD003511; Wed, 9 Mar 2011 20:04:30 GMT Date: Wed, 9 Mar 2011 20:04:25 +0000 From: bmanning@vacation.karoshi.com To: Kim Davies Message-ID: <20110309200425.GA1786@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: Dennis Jennings , "dnsext@ietf.org" Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:20:02 -0000 thought the IETF has some rules about holding out of sequence meetings... since you have used the IETF wg ml to announce this mtg, I presume the IETF "Note Well" rules apply? --bill On Wed, Mar 09, 2011 at 10:10:36AM -0800, Kim Davies wrote: > Dear colleagues, > > We are holding an informal birds-of-a-feather type meeting at the ICANN meeting in San Francisco. The idea is to discuss the work ongoing in both ICANN and IETF circles, and brainstorm how the work in both groups can benefit one another. A goal for the discussion is to identify how to best allocate resources to avoid duplicate work, as well as having ICANN's work help guide the IETF's scope of work, and vice versa. > > Anyone with an interest in the discussions on variant issues within the IETF and ICANN is welcome to attend. > > The meeting will be held at 2pm on Thursday 17 March. The room is called Elizabethan D in the meeting venue, the Westin on Union Square. > > Also note there is a more formal, scheduled meeting on the agenda to discuss ICANN variant issues, specifically presenting case studies from different regions that may require variant solutions. This is separate to this BOF and is being held at Wednesday at 3pm (see http://svsf40.icann.org/node/22193). We will recap any relevant discussion from that meeting briefly in the BOF. > > kim > (On behalf of ICANN's staff variant project team) > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From hallam@gmail.com Wed Mar 9 12:31:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4433A6969 for ; Wed, 9 Mar 2011 12:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROwE+3JZw1Fo for ; Wed, 9 Mar 2011 12:31:11 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DAC733A6943 for ; Wed, 9 Mar 2011 12:31:10 -0800 (PST) Received: by iwl42 with SMTP id 42so1102194iwl.31 for ; Wed, 09 Mar 2011 12:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mxsh7K9mQdV4lYx8tOz6bGemsPHcj6M2LTyneJOza60=; b=KMoI1895hlkUiWBO0OXjq3iakscewmhZLeJFvnl1XrZimQxyjBl+Az0ljamRV4zyAN bUAs6OZtIBnuwIsaR4KV5SH+6YUX/9AdGBBz0tQJRNsaFTXQafUoLJx9RcO1/lVEPu2k DMs72aqJtLH2zxUIQw+cck0Seb5OG+NfAeKoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eLmZtq30ZQz87ZfA3aV+n3ftQfSFqb+8DP65jNi4ET5DRK/lerYgAzZ0VbtuR4rCDi hw+zNWV+k63yLeDE/GBtGPcRt5vmxEskaZ5f1yhfi3GwKY42k/FlkmtFGvZX2n59v0JR faS69Tk8jicI6KFwfItyHZXOC5PC2v3JOAUyY= MIME-Version: 1.0 Received: by 10.42.77.74 with SMTP id h10mr8007391ick.99.1299702747140; Wed, 09 Mar 2011 12:32:27 -0800 (PST) Received: by 10.43.61.80 with HTTP; Wed, 9 Mar 2011 12:32:27 -0800 (PST) In-Reply-To: <20110309194411.GG32629@shinkuro.com> References: <20110218213453.GB96163@registro.br> <20110309194411.GG32629@shinkuro.com> Date: Wed, 9 Mar 2011 15:32:27 -0500 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=20cf3005dc068e908d049e12a097 Cc: Ben Laurie , Rob Stradling , dnsext@ietf.org Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:31:13 -0000 --20cf3005dc068e908d049e12a097 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 9, 2011 at 2:44 PM, Andrew Sullivan wrote: > Hi, > > With my administrative hat on, I just want to clear up some details. > > On Wed, Mar 09, 2011 at 01:33:51PM -0500, Phillip Hallam-Baker wrote: > > > In particular we removed a feature from the previous version of the > > specification that allowed a single CAA RR to contain a list of property > > entries. That was considered to be confusing > > Is that a change to the definition of the RR? I.e. is there a > difference between the RRTYPE in the original template and the one in > the latest draft? If so, it's strictly speaking a new RRTYPE request > and it needs a different template. The RRTYPE code that you get is > for the particular definition. There isn't a mechanism so far to get > a number and then be able to change the RRTYPE substantively, because > the idea is that the typecode could be baked into software all over > the place. The change took place in the -02 version of the draft that is specified in the template. I have submitted a new -03 version of the draft that clarify the description of the RRTYPE but do not change the proposal from that described in -02. > I will make these corrections to the editing copy of the draft. > > It would be good, actually, if you could post an update. The review > requirements include these criteria for rejection: > http://www.ietf.org/id/draft-hallambaker-donotissue-03.txt > 1. Was documented in a manner that was not sufficiently clear to > evaluate or implement. > > 3. The documentation of the proposed RRTYPE or RRTYPEs is incomplete. > (Additional documentation can be provided during the public > comment period or by the Expert.) > > The block diagram in particular would be helpful. The -03 draft provides additional documentation but does not modify the -02 RRTYPE definition submitted in January. The template does not specify the version number of the draft. -- Website: http://hallambaker.com/ --20cf3005dc068e908d049e12a097 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Mar 9, 2011 at 2:44 PM, Andrew S= ullivan <ajs@shink= uro.com> wrote:
Hi,

With my administrative hat on, I just want to clear up some details.

On Wed, Mar 09, 2011 at 01:33:51PM -0500, Phillip Hallam-Baker wrote:

> In particular we removed a feature from the previous version of the > specification that allowed a single CAA RR to contain a list of proper= ty
> entries. That was considered to be confusing

Is that a change to the definition of the RR? =A0I.e. is there a
difference between the RRTYPE in the original template and the one in
the latest draft? =A0If so, it's strictly speaking a new RRTYPE request=
and it needs a different template. =A0The RRTYPE code that you get is
for the particular definition. =A0There isn't a mechanism so far to get=
a number and then be able to change the RRTYPE substantively, because
the idea is that the typecode could be baked into software all over
the place.

The change took place in the -02= version of the draft that is specified in the template.=A0

<= /div>
I have submitted a new -03 version of the draft that clarify the = description of the RRTYPE but do not change the proposal from that describe= d in -02.


> I will make these corrections to the editing copy of the draft.

It would be good, actually, if you could post an update. =A0The revie= w
requirements include these criteria for rejection:


=A0
=A0 1. Was documented in a manner that was not sufficiently clear to
=A0 =A0 =A0evaluate or implement.

=A0 3. The documentation of the proposed RRTYPE or RRTYPEs is incomplete.<= br> =A0 =A0 =A0(Additional documentation can be provided during the public
=A0 =A0 =A0comment period or by the Expert.)

The block diagram in particular would be helpful.

The -03 draft provides additional documentation but does not modify = the -02 RRTYPE definition submitted in January.

The template does not specify the version number of the draft.
--
Website: http://ha= llambaker.com/

--20cf3005dc068e908d049e12a097-- From ajs@shinkuro.com Wed Mar 9 12:38:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E573A6A5D for ; Wed, 9 Mar 2011 12:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxkLz9yieFQm for ; Wed, 9 Mar 2011 12:38:12 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 35B663A6989 for ; Wed, 9 Mar 2011 12:38:12 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4D6151ECB408; Wed, 9 Mar 2011 20:39:28 +0000 (UTC) Date: Wed, 9 Mar 2011 15:39:26 -0500 From: Andrew Sullivan To: Phillip Hallam-Baker Message-ID: <20110309203926.GN32629@shinkuro.com> References: <20110218213453.GB96163@registro.br> <20110309194411.GG32629@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Ben Laurie , Rob Stradling , dnsext@ietf.org Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:38:13 -0000 On Wed, Mar 09, 2011 at 03:32:27PM -0500, Phillip Hallam-Baker wrote: > The change took place in the -02 version of the draft that is specified in > the template. > > I have submitted a new -03 version of the draft that clarify the description > of the RRTYPE but do not change the proposal from that described in -02. Gotcha. Thanks. Sorry I was confused. > The -03 draft provides additional documentation but does not modify the -02 > RRTYPE definition submitted in January. > > The template does not specify the version number of the draft. Excellent. Very helpful. Thanks! A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From paul.hoffman@vpnc.org Wed Mar 9 12:38:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244363A6AA1 for ; Wed, 9 Mar 2011 12:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.939 X-Spam-Level: X-Spam-Status: No, score=-101.939 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z50E+WzDCRA0 for ; Wed, 9 Mar 2011 12:38:50 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 123C73A6989 for ; Wed, 9 Mar 2011 12:38:49 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p29Ke5to013978 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 9 Mar 2011 13:40:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D77E5A5.8040005@vpnc.org> Date: Wed, 09 Mar 2011 12:40:05 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D77D2AF.7010203@abenaki.wabanaki.net> <4D77D6D8.9070609@dougbarton.us> <20110309201647.GJ32629@shinkuro.com> In-Reply-To: <20110309201647.GJ32629@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:38:51 -0000 On 3/9/11 12:16 PM, Andrew Sullivan wrote: > No hat. > > On Wed, Mar 09, 2011 at 11:36:56AM -0800, Doug Barton wrote: > >> Further, the term "variant" has a relatively well understood meaning in >> the TLD policy context, where it is generally understood to be a >> simplification of several thorny technical problems. > > I suspect I disagree with the above claim. Specifically, I think I > disagree with "well understood". +1. I would go further to say "people who think they understand it clearly are either thinking that most other people don't share that understanding, or are ignoring the history written on the pages of many IETF mailing lists". I would have much preferred ICANN staff to have chosen a word that reflects the still-rampant lack of a good term. From alex@alex.org.uk Wed Mar 9 12:47:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2FF3A6A92 for ; Wed, 9 Mar 2011 12:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhirYe3P4V1h for ; Wed, 9 Mar 2011 12:47:37 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id F20813A6A47 for ; Wed, 9 Mar 2011 12:47:36 -0800 (PST) Received: from [172.16.2.233] (lemondeh-adsl.demon.co.uk [83.105.105.209]) by mail.avalus.com (Postfix) with ESMTPSA id 79CD0C5635E; Wed, 9 Mar 2011 20:48:51 +0000 (GMT) Date: Wed, 09 Mar 2011 20:48:49 +0000 From: Alex Bligh To: Paul Hoffman , dnsext@ietf.org Message-ID: In-Reply-To: <4D77E5A5.8040005@vpnc.org> References: <4D77D2AF.7010203@abenaki.wabanaki.net> <4D77D6D8.9070609@dougbarton.us> <20110309201647.GJ32629@shinkuro.com> <4D77E5A5.8040005@vpnc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:47:37 -0000 --On 9 March 2011 12:40:05 -0800 Paul Hoffman wrote: > I would have much preferred ICANN staff to have chosen a word that > reflects the still-rampant lack of a good term. I suggest "alias" / "aliases" to mean DNs that broadly "do the same thing" as 1. It's the term used in draft-aliasing-requirements 2. It's not used (as far as I know) by any existing proposed solution and so is not specific 3. As far as I know, it is not an existing term of art in DNS, Unicode, or ICANNalia -- Alex Bligh From marka@isc.org Wed Mar 9 13:45:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546D03A6AC3 for ; Wed, 9 Mar 2011 13:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUf5YAfgErGo for ; Wed, 9 Mar 2011 13:45:30 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 0B3913A6AD9 for ; Wed, 9 Mar 2011 13:45:30 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 894ADC9428; Wed, 9 Mar 2011 21:46:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 0BF59216C22; Wed, 9 Mar 2011 21:46:36 +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 1D01BBFF084; Thu, 10 Mar 2011 08:46:34 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20110309133017.GA19809@odin.mars.sol><20110309135700.GI32629@shinkuro.com> In-reply-to: Your message of "Wed, 09 Mar 2011 08:57:00 CDT." <20110309135700.GI32629@shinkuro.com> Date: Thu, 10 Mar 2011 08:46:34 +1100 Message-Id: <20110309214634.1D01BBFF084@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:45:31 -0000 In message <20110309135700.GI32629@shinkuro.com>, Andrew Sullivan writes: > No hat. > > On Wed, Mar 09, 2011 at 08:30:17AM -0500, Scott Schmit wrote: > > > I'm inclined to agree with this, but even if it's decided that the > > DNSKEY RRs aren't sufficient, why not just use DS on the client side? I > > see that RFC 3658 forbids it, but I'm not sure I understand why. > > I do not think this is the time to debate that design decision. The > design of DNSSEC uses different RRTYPEs at the parent side of the cut > and the child side. It is true that we use the same RRTYPE at the > parent and child sides for the NS record. But even if you think that > was a good design (though I happen not to), the fact is that DNSSEC > did not follow that direction, and it has rules stating that the DS > isn't allowed on the child side. We can't unmake that decision, and > we can't change it now without introducing a backward incompatible > change; so that is not an option open to us. > > A Additionally DLV, which is bit for bit identical to DS like this record is, is a different type for exactly the same reasons this record needs to be a different type. And no re-using DLV is also not apporiate. DLV, CDS and DS can all exist at the same name. > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Wed Mar 9 14:05:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F5D3A6ABD for ; Wed, 9 Mar 2011 14:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syIfYVVH2VDz for ; Wed, 9 Mar 2011 14:05:42 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 342843A6407 for ; Wed, 9 Mar 2011 14:05:42 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 354AB5F984C; Wed, 9 Mar 2011 22:06:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 DF64E216C1E; Wed, 9 Mar 2011 22:06:41 +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 08DDDBFF329; Thu, 10 Mar 2011 09:06:40 +1100 (EST) To: Olafur Gudmundsson From: Mark Andrews References: <20110309133017.GA19809@odin.mars.sol><4D778C86.4020105@ogud.com> In-reply-to: Your message of "Wed, 09 Mar 2011 09:19:50 CDT." <4D778C86.4020105@ogud.com> Date: Thu, 10 Mar 2011 09:06:40 +1100 Message-Id: <20110309220640.08DDDBFF329@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 22:05:43 -0000 In message <4D778C86.4020105@ogud.com>, Olafur Gudmundsson writes: > > > On 09/03/2011 8:30 AM, Scott Schmit wrote: > > On Tue, Mar 08, 2011 at 08:32:05PM +0000, Tony Finch wrote dnsext: > >> On Tue, 8 Mar 2011, Roy Arends wrote: > >>> > >>> D. Motivation for the new RRTYPE application? > >>> > >>> To allow a copy of the DS RRset [RFC4034] to be published > >>> in the child zone, which is used to update the parent DS RRset. > >>> It is expected that this will allow the rollover of a key signi > ng > >>> key to be automated. > >> > >> Why not just use the child zone's SEP DNSKEY RRs for this purpose? > > > > I'm inclined to agree with this, but even if it's decided that the > > DNSKEY RRs aren't sufficient, why not just use DS on the client side? I > > see that RFC 3658 forbids it, but I'm not sure I understand why. We > > don't have CNS in addition to NS, so why should DS be different? I can > > understand that DS must be ignored by a client unless it's signed by the > > parent, but if that check doesn't already exist, we're already in > > trouble. > > Using SEP bits in DNSKEY records does not work when a zone wants to > retire an algorithm, the DS MUST be removed before the corresponding > DNSKEY record is removed. RFC 5011 really doesn't work for trust anchors. We should do something similar with DNSKEY but add fields to the front. However this is not the thread to do this on. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@iecc.com Wed Mar 9 14:12:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0833B3A6778 for ; Wed, 9 Mar 2011 14:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.806 X-Spam-Level: X-Spam-Status: No, score=-110.806 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nK2aYBofpGQ for ; Wed, 9 Mar 2011 14:12:41 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id BB9703A6768 for ; Wed, 9 Mar 2011 14:12:39 -0800 (PST) Received: (qmail 91925 invoked from network); 9 Mar 2011 22:13:55 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 9 Mar 2011 22:13:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=afed.4d77fba3.k1103; i=johnl@user.iecc.com; bh=HQQLN4aH2svZ39X7PydqkV1p/8JTiP24xhi3IKiCfYI=; b=jGNQUmX24TXJSdpLuULZr6OpFDxY1f5+xohdOO3ZagP+q/hp4lje5tBm7ibHL906N+quqBXaHln48+vvy7KQrH+IDlMTMQY1fIRI1SCXKb6CJjxzy2p34UIQaU9RmasT7VrAPkG3Z4SOd87Eyv8iL02AYvcS59ytlQrhmagVn0g= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 9 Mar 2011 22:13:55 -0000 Message-ID: <20110309221355.45036.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <4D77E5A5.8040005@vpnc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 22:12:42 -0000 >> I suspect I disagree with the above claim. Specifically, I think I >> disagree with "well understood". I think we understand our technical options pretty well, but not what problem we're expected to solve. At ICANN you're likely to run into policy types who say (no doubt in more words) "spare me the mumbo-jumbo, we just want {set of names} to work the same." Once you're done gritting your teeth, this is an educational opportunity to help people understand the large number of moving parts that have to be synchonized to get the consistent user experience that is probably the intutive idea of sameness, e.g.: If users type various names into their web browser, what should they expect? Always the same page? How about if some pages are different? How about if one brings up a page, the rest don't? etc. R's, John From mohta@necom830.hpcl.titech.ac.jp Wed Mar 9 14:36:40 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C553A6AD9 for ; Wed, 9 Mar 2011 14:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.086 X-Spam-Level: X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl89pW3ADcL3 for ; Wed, 9 Mar 2011 14:36:40 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 994E93A6765 for ; Wed, 9 Mar 2011 14:36:39 -0800 (PST) Received: (qmail 42101 invoked from network); 9 Mar 2011 22:54:19 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 9 Mar 2011 22:54:19 -0000 Message-ID: <4D7800FB.3010009@necom830.hpcl.titech.ac.jp> Date: Thu, 10 Mar 2011 07:36:43 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Revised version of ESRV X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 22:36:40 -0000 Phillip Hallam-Baker wrote: > The basic idea here is that when writing code to establish a > connection to > an Internet Service or a Web Service it is best if the platform > and the > infrastructure do as much work as possible and require the > programmer to do > as little as possible. Programmers? Then, let users do all the job to locate services. Don't put the infrastructure information for service location only to burden programmers write programs to investigate and process the information. Masataka Ohta From ajs@shinkuro.com Wed Mar 9 14:42:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4384B3A6452 for ; Wed, 9 Mar 2011 14:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqR1hT4lpOWT for ; Wed, 9 Mar 2011 14:42:09 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 394073A672E for ; Wed, 9 Mar 2011 14:42:09 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2CA4E1ECB408 for ; Wed, 9 Mar 2011 22:43:19 +0000 (UTC) Date: Wed, 9 Mar 2011 17:43:07 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110309224250.GR32629@shinkuro.com> References: <4D77E5A5.8040005@vpnc.org> <20110309221355.45036.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110309221355.45036.qmail@joyce.lan> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 22:42:11 -0000 On Wed, Mar 09, 2011 at 10:13:55PM -0000, John Levine wrote: > Once you're done gritting your teeth, this is an educational > opportunity to help people understand the large number of moving parts > that have to be synchonized to get the consistent user experience that > is probably the intutive idea of sameness, e.g.: > > If users type various names into their web browser, what should they > expect? Always the same page? How about if some pages are different? > How about if one brings up a page, the rest don't? etc. I completely agree. I'm very enthusiastic about this opportunity, I'm delighted ICANN is organizing it, and I just changed my travel plans in order to be able to make it. Now I just have to break the news to my wife! A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From stephan.lagerholm@secure64.com Wed Mar 9 16:47:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86AA43A698A for ; Wed, 9 Mar 2011 16:47:04 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js58yirhAXto for ; Wed, 9 Mar 2011 16:47:03 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by core3.amsl.com (Postfix) with ESMTP id 5AC6B3A67D9 for ; Wed, 9 Mar 2011 16:47:03 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 0CC3CB837E; Wed, 9 Mar 2011 17:42:02 -0700 (MST) 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 kBv2Z-YWIOGP; Wed, 9 Mar 2011 17:42:01 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 1693EB8377; Wed, 9 Mar 2011 17:42:01 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1299717721; bh=Y2bbCor6CJ53fZxJR13y7A1k89DllrucPWXCC8kMIdI=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=ucSbDUuH0JwZ8kjcncCJg TAMf9AlbcpsA7ICAH/tMHPJQz1fo+BZkggOvV/gZR6KBmpf/lNJEn3GpysTpgjJx6Yy J9i5UmnuZIQIDS+HgxPPWg0TsrCEsdIpcWRRVhLpK1ku50xAKnMiOtNkAoAncEgZIpV 3N0pfWdc+RLFPFhA= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2011 17:41:25 -0700 Message-ID: In-Reply-To: <4D778C86.4020105@ogud.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] CDS RRTYPE review - Comments period end Mar 29th Thread-Index: AcveZCr4gZyNY42tTme1s+UeMVnddAAVuXxw References: <20110309133017.GA19809@odin.mars.sol> <4D778C86.4020105@ogud.com> From: "Stephan Lagerholm" To: "Olafur Gudmundsson" , Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:47:04 -0000 On Wednesday, March 09, 2011 8:20 AM Olaf Gudmundsson wrote: >>> Why not just use the child zone's SEP DNSKEY RRs for this purpose? >> >> I'm inclined to agree with this, but even if it's decided that the >> DNSKEY RRs aren't sufficient, why not just use DS on the client side? I >> see that RFC 3658 forbids it, but I'm not sure I understand why. We >> don't have CNS in addition to NS, so why should DS be different? I can >> understand that DS must be ignored by a client unless it's signed by the >> parent, but if that check doesn't already exist, we're already in >> trouble. > >Using SEP bits in DNSKEY records does not work when a zone wants to >retire an algorithm, the DS MUST be removed before the corresponding >DNSKEY record is removed. Good point. For the DNSKEY strategy to work, then it would have to be a new flag. >> So, maybe they didn't think of the use case this draft is trying to >> address and forbade it to keep the software implementations simpler? But >> that could have been accomplished simply by saying that a DS on the >> child side is ignored for validation purposes (it now becomes pointless >> (but harmless) to include it, except as a way to securely send DS >> records from the child to the parent). > >RFC3658 specified for the first time a record that can only live at the >parent and this required major changes to resolution algorithm >implementations. >If there is anything we have learned in the last 25+ years of DNS is >this: "If the same information can appear in two places it will not be >the same and you have no idea which version resolvers will use" >Just look at what different resolvers do when the parent and child NS >records differ. I agree. >> I can understand the motivation of introducing a new RRTYPE to avoid >> needing to alter existing MUST NOTs, but CDS just seems unnecessary. >> >> Maybe there's another reason to forbid DS on the child side that I've >> overlooked? >> > >see above, and new types a cheap, and this gives the child full control >over the changes in the DS in parent. Similarly this can be used to >update trust anchors for an Island of security. For whom do you feel that new types are cheap? Any provisioning program that parses/constructs a zone file will have to be rewritten to be able to understand this new type to be able to display/add/edit/remove it in a meaningful way. I disagree that this is cheap. We are just starting to see support in different tools for DNSKEY and DS. Hopefully they made the flag field configurable. Adding a new flag to DNSKEY would be cheaper. /Stephan From marka@isc.org Wed Mar 9 17:12:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06F53A6B20 for ; Wed, 9 Mar 2011 17:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m182wkQG6JYt for ; Wed, 9 Mar 2011 17:12:24 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 56BC03A6A3F for ; Wed, 9 Mar 2011 17:12:24 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id B9C29C9427; Thu, 10 Mar 2011 01:13:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 3A070216C1E; Thu, 10 Mar 2011 01:13:31 +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 2BE0EC03244; Thu, 10 Mar 2011 12:13:28 +1100 (EST) To: "Stephan Lagerholm" From: Mark Andrews References: <20110309133017.GA19809@odin.mars.sol> <4D778C86.4020105@ogud.com> In-reply-to: Your message of "Wed, 09 Mar 2011 17:41:25 PDT." Date: Thu, 10 Mar 2011 12:13:27 +1100 Message-Id: <20110310011328.2BE0EC03244@drugs.dv.isc.org> Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 01:12:26 -0000 In message , "Ste phan Lagerholm" writes: > > On Wednesday, March 09, 2011 8:20 AM Olaf Gudmundsson wrote: > >>> Why not just use the child zone's SEP DNSKEY RRs for this purpose? > >> > >> I'm inclined to agree with this, but even if it's decided that the > >> DNSKEY RRs aren't sufficient, why not just use DS on the client side? > I > >> see that RFC 3658 forbids it, but I'm not sure I understand why. We > >> don't have CNS in addition to NS, so why should DS be different? I > can > >> understand that DS must be ignored by a client unless it's signed by > the > >> parent, but if that check doesn't already exist, we're already in > >> trouble. > > > >Using SEP bits in DNSKEY records does not work when a zone wants to > >retire an algorithm, the DS MUST be removed before the corresponding > >DNSKEY record is removed. > Good point. For the DNSKEY strategy to work, then it would have to be a > new flag. > > >> So, maybe they didn't think of the use case this draft is trying to > >> address and forbade it to keep the software implementations simpler? > But > >> that could have been accomplished simply by saying that a DS on the > >> child side is ignored for validation purposes (it now becomes > pointless > >> (but harmless) to include it, except as a way to securely send DS > >> records from the child to the parent). > > > >RFC3658 specified for the first time a record that can only live at the > >parent and this required major changes to resolution algorithm > >implementations. > >If there is anything we have learned in the last 25+ years of DNS is > >this: "If the same information can appear in two places it will not be > >the same and you have no idea which version resolvers will use" > >Just look at what different resolvers do when the parent and child NS > >records differ. > I agree. > > >> I can understand the motivation of introducing a new RRTYPE to avoid > >> needing to alter existing MUST NOTs, but CDS just seems unnecessary. > >> > >> Maybe there's another reason to forbid DS on the child side that I've > >> overlooked? > >> > > > >see above, and new types a cheap, and this gives the child full control > >over the changes in the DS in parent. Similarly this can be used to > >update trust anchors for an Island of security. > For whom do you feel that new types are cheap? Any provisioning program > that parses/constructs a zone file will have to be rewritten to be able > to understand this new type to be able to display/add/edit/remove it in > a meaningful way. I disagree that this is cheap. Adding new types shouldn't be expensive if you have designed your applications to be extended from the begining and any application dealing with arbitary DNS records should be so designed. > We are just starting to see support in different tools for DNSKEY and > DS. Hopefully they made the flag field configurable. Adding a new flag > to DNSKEY would be cheaper. > > /Stephan > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From george.barwood@blueyonder.co.uk Wed Mar 9 23:08:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE713A67EF for ; Wed, 9 Mar 2011 23:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.67 X-Spam-Level: X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ssq3J7I-OP1G for ; Wed, 9 Mar 2011 23:08:49 -0800 (PST) Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by core3.amsl.com (Postfix) with ESMTP id D90BD3A68BF for ; Wed, 9 Mar 2011 23:08:48 -0800 (PST) Received: from [172.23.170.144] (helo=anti-virus03-07) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Pxa0Q-0003SY-Lv; Thu, 10 Mar 2011 07:09:55 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1Pxa0N-0002wE-Gl; Thu, 10 Mar 2011 07:09:51 +0000 Message-ID: <3D41A425A17444EA8EEE8C78DD18D3E9@local> From: "George Barwood" To: "Stephan Lagerholm" , "Olafur Gudmundsson" , References: <20110309133017.GA19809@odin.mars.sol><4D778C86.4020105@ogud.com> Date: Thu, 10 Mar 2011 07:10:25 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 07:08:50 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlN0ZXBoYW4gTGFnZXJob2xt IiA8c3RlcGhhbi5sYWdlcmhvbG1Ac2VjdXJlNjQuY29tPg0KVG86ICJPbGFmdXIgR3VkbXVuZHNz b24iIDxvZ3VkQG9ndWQuY29tPjsgPGRuc2V4dEBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBN YXJjaCAxMCwgMjAxMSAxMjo0MSBBTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIENEUyBSUlRZUEUg cmV2aWV3IC0gQ29tbWVudHMgcGVyaW9kIGVuZCBNYXIgMjl0aA0KDQoNCj4gV2UgYXJlIGp1c3Qg c3RhcnRpbmcgdG8gc2VlIHN1cHBvcnQgaW4gZGlmZmVyZW50IHRvb2xzIGZvciBETlNLRVkgYW5k DQo+IERTLiBIb3BlZnVsbHkgdGhleSBtYWRlIHRoZSBmbGFnIGZpZWxkIGNvbmZpZ3VyYWJsZS4g QWRkaW5nIGEgbmV3IGZsYWcNCj4gdG8gRE5TS0VZIHdvdWxkIGJlIGNoZWFwZXIuDQoNCk5vdCBy ZWFsbHkuDQoNCkluIGVpdGhlciBjYXNlIHRoZSBzb2Z0d2FyZSB0aGF0IHNpZ25zIHpvbmVzIGhh cyB0byBiZSB1cGRhdGVkLg0KDQpJZiB0aGUgb3V0cHV0IGlzIGluIHRleHQgZm9ybWF0LCB0aGUg Z2VuZXJpYyB0ZXh0IGZvcm1hdCBvZiBSRkMzNTk3IHNlY3Rpb24gNQ0KbWF5IGJlIHVzZWQgaWYg dGhlIHNlcnZpbmcgc29mdHdhcmUgZm9yIHRoZSBtYXN0ZXIgc2VydmVyIGhhcyBub3QgYmVlbiB1 cGRhdGVkLg0KDQpUaGUgc29mdHdhcmUgZm9yIHNlY29uZGFyeSBzZXJ2ZXJzIGRvZXMgbm90IG5l ZWQgdG8gYmUgdXBkYXRlZCBpbiBhbnkgY2FzZSwNCmFzc3VtaW5nIGl0IGltcGxlbWVudHMgUkZD MzU5NyAoIHRoYXQgaXMgaXQgY2FuIGhhbmRsZSB1bmtub3duIHR5cGVzICksDQp3aGljaCBpcyBv ZiBjb3Vyc2UgdGhlIGNhc2UgZm9yIGFsbCBtYWluc3RyZWFtIGltcGxlbWVudGF0aW9ucy4NCg0K From weiler@watson.org Thu Mar 10 04:00:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1B03A6933 for ; Thu, 10 Mar 2011 04:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOu04cKSvDz3 for ; Thu, 10 Mar 2011 04:00:28 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id C24403A6A07 for ; Thu, 10 Mar 2011 04:00:27 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p2AC1hHe059368; Thu, 10 Mar 2011 07:01:43 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p2AC1h3w059365; Thu, 10 Mar 2011 07:01:43 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 10 Mar 2011 07:01:43 -0500 (EST) From: Samuel Weiler To: George Barwood In-Reply-To: <758260B7B5B34599BA80D9BA5A3840C0@local> Message-ID: References: <72A22513B1644CFE9023189F93BFDD32@local> <20110309080006.GA23957@miek.nl> <758260B7B5B34599BA80D9BA5A3840C0@local> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 10 Mar 2011 07:01:43 -0500 (EST) Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 12:00:28 -0000 On Wed, 9 Mar 2011, George Barwood wrote: >> So this is the sole reason for adding this new type? > > There are 4 reasons given, why do you quote only one? Actually, the TEMPLATE provides no reasons at all why the three previously-assigned RR types with the exact same format don't meet the need. Field F in the template needs to include that analysis, whether or not it is also in the draft. I pointed this out in my previous comments on November 16th, and it appears that the template is unchanged. Please update the template. From today's discussion, it looks like it also needs to include analysis of why DNSKEY and all of the other key and hash records won't meet the need, too. (Note that I'm not arguing that we don't need a new type for this, just pointing out that this template hasn't met the minimum bar of saying why we do. There's likely some very short language that would do the trick, but you do need to include it.) -- Sam From weiler@watson.org Thu Mar 10 04:56:40 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946863A699A for ; Thu, 10 Mar 2011 04:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp2-yiHACpsB for ; Thu, 10 Mar 2011 04:56:39 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 49FCC3A6924 for ; Thu, 10 Mar 2011 04:56:35 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p2ACt82h063378; Thu, 10 Mar 2011 07:55:08 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p2ACt80l063375; Thu, 10 Mar 2011 07:55:08 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 10 Mar 2011 07:55:08 -0500 (EST) From: Samuel Weiler To: Frederico A C Neves In-Reply-To: <20110218213453.GB96163@registro.br> Message-ID: References: <20110218213453.GB96163@registro.br> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 10 Mar 2011 07:55:08 -0500 (EST) Cc: iana@iana.org, dnsext@ietf.org Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 12:56:40 -0000 The presentation format definition says: flags Is an unsigned integer between 0 and 15. But the flags field on the wire is a full octet, and bit 0 is defined. Should the presentation format allow 0-255, instead? > H. Does the requested RRTYPE make use of any existing IANA > Registry or require the creation of a new IANA sub-registry in > DNS Parameters? ... > Yes, the following registry assignment is requested. ... > 5.2. Certification Authority Authorization Properties > > IANA [is requested to create] the Certification Authority > Authorization Properties registry with the following initial values: ... > Addition of tag identifiers requires a public specification and > expert review as set out in RFC5395 [RFC5395] Is it really appropriate to allow a template to create IANA registries? It does seem odd to me that a template can create an IANA registry when the i-d it cites can't itself create a registry until published as an RFC. Perhaps IANA should comment on that. In any case, the cite to 5395 suggests that this is attempting to reuse the DNS RRTYPE expert pool for this registry, which seems odd. It also doesn't define the criteria an expert should use. I suggest the proponents of this look at RFC5226 and specific their own criteria, perhaps with their own expert. It might be appropriate to skip the IANA registry for the moment. Resubmit the specificcation with no IANA registry ("here are the two values") and only create the registry in the RFC. Which brings us to the discussion on the list yesterday: the template should really be citing a particular version of the spec. It hardly seems fair to ask the expert to approve an RRTYPE based on a reference to a changing document. -- Sam From ajs@shinkuro.com Thu Mar 10 04:57:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEAEF3A6995 for ; Thu, 10 Mar 2011 04:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7gyC4FD-ZmR for ; Thu, 10 Mar 2011 04:57:37 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 344B43A6936 for ; Thu, 10 Mar 2011 04:57:37 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5DA1A1ECB408 for ; Thu, 10 Mar 2011 12:58:54 +0000 (UTC) Date: Thu, 10 Mar 2011 07:58:52 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110310125852.GJ57756@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dnsext] Draft agenda for Prague X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 12:57:38 -0000 Dear colleagues, There are two items on the agenda for Prague. We have one hour. The first is the discussion around the alias requirements. We want to wind this up very soon. Every open item you have should be considered fodder for this discussion: draft-ietf-dnsext-aliasing-requirements. 35 mins The second is the resimprove draft: draft-vixie-dnsext-resimprove. 25 mins The above were the only two items requested of the chairs prior to the deadline, so we only asked for an hour long slot. There remains the faint possibility that we will be moved to the slot on Friday morning currently occupied by mif. If we have that additional time, we might be willing to entertain additional topics. If you have such topics, please send them to us with a request of the amount of time you want. Note that we do not like or encourage long presentations, and prefer any slot longer than a few minutes to be taken up mostly with focussed discussion that nails down conclusions. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From hallam@gmail.com Thu Mar 10 06:17:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 536353A69B0 for ; Thu, 10 Mar 2011 06:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x595lwXCV1bA for ; Thu, 10 Mar 2011 06:17:00 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E043F3A6996 for ; Thu, 10 Mar 2011 06:16:59 -0800 (PST) Received: by iwl42 with SMTP id 42so1998277iwl.31 for ; Thu, 10 Mar 2011 06:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=brBVdgBT/1Ecg9Sh9Ptltkoe5m/jNKlUtc18lKPATt8=; b=UuKTQ5DYBUikJA1udrVMs3d+w5e/UH1W02ts3f6KTF+BaXwCvl60BPS2khRUBbE+ra lh/oK5Y6eYBlHYC849obxHgAPGezBEPq0QsRFKJexF0y3Akme4PxYRIn4KQFYb0RDrPF oKgWcC/CN+evb1fhuFxg5RF0uP33aPE+ALDJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Srz/GXxO6zSwtUkdXJ92WBSQdz52dTcn0lxCo0bmezKxvSD8zv5cfec8q566kcwBRR jsNFC0PbZ4A7MvQX/uaehjjWRSCBQomKzH/R/+MlQdbZyLGzvAkMHX2pwmAPJvLZALRi Ze4hVVqtSysbv1H+HFhXXJWmONA58IOzyzynQ= MIME-Version: 1.0 Received: by 10.42.108.9 with SMTP id f9mr940730icp.233.1299766696711; Thu, 10 Mar 2011 06:18:16 -0800 (PST) Received: by 10.43.61.80 with HTTP; Thu, 10 Mar 2011 06:18:16 -0800 (PST) In-Reply-To: References: <20110218213453.GB96163@registro.br> Date: Thu, 10 Mar 2011 09:18:16 -0500 Message-ID: From: Phillip Hallam-Baker To: Samuel Weiler Content-Type: multipart/alternative; boundary=20cf303bff463f97c7049e2184a4 Cc: iana@iana.org, dnsext@ietf.org Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 14:17:01 -0000 --20cf303bff463f97c7049e2184a4 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 10, 2011 at 7:55 AM, Samuel Weiler wrote: > The presentation format definition says: > flags Is an unsigned integer between 0 and 15. > > But the flags field on the wire is a full octet, and bit 0 is defined. > Should the presentation format allow 0-255, instead Oops, the statement in the Presentation Format is wrong. We made the flags a full byte after comments received suggested we were over-optimizing. > > > H. Does the requested RRTYPE make use of any existing IANA >> Registry or require the creation of a new IANA sub-registry in >> DNS Parameters? >> > ... > > Yes, the following registry assignment is requested. >> > ... > >> 5.2. Certification Authority Authorization Properties >> >> IANA [is requested to create] the Certification Authority >> Authorization Properties registry with the following initial values: >> > ... > > Addition of tag identifiers requires a public specification and >> expert review as set out in RFC5395 [RFC5395] >> > > Is it really appropriate to allow a template to create IANA registries? It > does seem odd to me that a template can create an IANA registry when the i-d > it cites can't itself create a registry until published as an RFC. Perhaps > IANA should comment on that. > Thats a process issue outside my scope :-) > In any case, the cite to 5395 suggests that this is attempting to reuse the > DNS RRTYPE expert pool for this registry, which seems odd. It also doesn't > define the criteria an expert should use. I suggest the proponents of this > look at RFC5226 and specific their own criteria, perhaps with their own > expert. > OK, I see this as being the start of projects intended to make use of the capabilities of DNSSEC to support application level issues. So I certainly anticipate a need for a separate expert pool at some point. But not so far as the scope of CAA alone is concerned. It might be appropriate to skip the IANA registry for the moment. Resubmit > the specificcation with no IANA registry ("here are the two values") and > only create the registry in the RFC. > That would only change the template, not the draft? I am trying to follow the process as I understand it here and that requires the template to specify the registries the draft proposes to create. Now what may well make more sense as a process would be to have a two phase scheme in which DNS RR codes are marked 'reserved' in response to the expert review and the final allocation is performed when the RFC is issued. This is effectively what has happened with Stuart Cheshire's Bonjour scheme. But that is not the process we have. > Which brings us to the discussion on the list yesterday: the template > should really be citing a particular version of the spec. It hardly seems > fair to ask the expert to approve an RRTYPE based on a reference to a > changing document. > I think that is unhelpful. The draft was changed in response to earlier review comments. I don't think we want to have a process that encourages people to ignore comments lest they incur a penalty of having to wait another 3 months. Documents are changed after WG and even IETF last call all the time. I have made rather more substantial changes in AUTH48. The test normally applied in IETF is not 'has the text changed' but 'has the proposal changed'. The process does allow for clarifications in the comment period. We did change the wire format in January but this particular comment period began 4 weeks later in Feb. The point of a comment period is to give people an opportunity to influence the proposal. This particular proposal is different to most proposals that I have made in that 1) the assignment is the only thing gating deployment and 2) the mechanism provides an effective control over a very significant dollar risk. In most cases deployment is gated on other people writing and distributing code. Here the CA side of the proposal is entirely within the CA's control. These mis-issue events are not frequent but when they do happen the results go on for decades. It is now over a decade since the 2001 mis-issue took place but I still hear about it in every public discussion of CAs followed by an argument which taken to its logical conclusion would require the world to immediately stop all forms of commercial shipping because the Titanic sank almost a century ago. -- Website: http://hallambaker.com/ --20cf303bff463f97c7049e2184a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 10, 2011 at 7:55 AM, Samuel = Weiler <weiler@wa= tson.org> wrote:
The presentation format definition says:
=A0 flags =A0Is an unsigned integer between 0 and 15.

But the flags field on the wire is a full octet, and bit 0 is defined. Shou= ld the presentation format allow 0-255, instead

=
Oops, the statement in the Presentation Format is wrong.

We made the flags a full byte after comments received sugges= ted we were over-optimizing.=A0

=A0


=A0H. =A0 =A0Does the requested RRTYPE make use of any existing IANA
=A0 =A0 =A0 Registry or require the creation of a new IANA sub-registry in=
=A0 =A0 =A0 DNS Parameters?
...

Yes, the following registry assignment is requested.
...
5.2. =A0Certification Authority Authorization Properties

=A0IANA [is requested to create] the Certification Authority
Authorization Properties registry with the following initial values:
...

=A0Addition of tag identifiers requires a public specification and
=A0expert review as set out in RFC5395 [RFC5395]

Is it really appropriate to allow a template to create IANA registries? =A0= It does seem odd to me that a template can create an IANA registry when the= i-d it cites can't itself create a registry until published as an RFC.= =A0Perhaps IANA should comment on that.

Thats a process issue outside my scope :-)=

=A0
In any case, the cite to 5395 suggests that this is attempting to reuse the= DNS RRTYPE expert pool for this registry, which seems odd. It also doesn&#= 39;t define the criteria an expert should use. =A0I suggest the proponents = of this look at RFC5226 and specific their own criteria, perhaps with their= own expert.

OK,=A0

I see this= as being the start of projects intended to make use of the capabilities of= DNSSEC to support application level issues. So I certainly anticipate a ne= ed for a separate expert pool at some point. But not so far as the scope of= CAA alone is concerned.


It might be appropriate to skip the IANA registry for the moment. Resubmit = the specificcation with no IANA registry ("here are the two values&quo= t;) and only create the registry in the RFC.

That would only change the template, not the draft?
I am trying to follow the process as I understand it here and = that requires the template to specify the registries the draft proposes to = create.

Now what may well make more sense as a process would be= to have a two phase scheme in which DNS RR codes are marked 'reserved&= #39; in response to the expert review and the final allocation is performed= when the RFC is issued. This is effectively what has happened with Stuart = Cheshire's Bonjour scheme.

But that is not the process we have.

=A0
Which brings us to the discussion on the list yesterday: the template shoul= d really be citing a particular version of the spec. =A0It hardly seems fai= r to ask the expert to approve an RRTYPE based on a reference to a changing= document.

I think that is unhelpful.

<= /div>
The draft was changed in response to earlier review comments. I d= on't think we want to have a process that encourages people to ignore c= omments lest they incur a penalty of having to wait another 3 months.

Documents are changed after WG and even IETF last call = all the time. I have made rather more substantial changes in AUTH48. The te= st normally applied in IETF is not 'has the text changed' but '= has the proposal changed'. The process does allow for clarifications in= the comment period.

We did change the wire format in January but this parti= cular comment period began 4 weeks later in Feb.

T= he point of a comment period is to give people an opportunity to influence = the proposal.=A0


This particular proposal is different to= most proposals that I have made in that 1) the assignment is the only thin= g gating deployment and 2) the mechanism provides an effective control over= a very significant dollar risk.

In most cases deployment is gated on other people writi= ng and distributing code. Here the CA side of the proposal is entirely with= in the CA's control.

These mis-issue events ar= e not frequent but when they do happen the results go on for decades. It is= now over a decade since the 2001 mis-issue took place but I still hear abo= ut it in every public discussion of CAs followed by an argument which taken= to its logical conclusion would require the world to immediately stop all = forms of commercial shipping because the Titanic sank almost a century ago.=


--
Website: http://hallambaker.com/

--20cf303bff463f97c7049e2184a4-- From weiler@watson.org Thu Mar 10 09:07:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4ACC3A6A3B for ; Thu, 10 Mar 2011 09:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URPZRUNFr05K for ; Thu, 10 Mar 2011 09:07:07 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 4F4C63A6930 for ; Thu, 10 Mar 2011 09:07:07 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p2AH8MCV083942; Thu, 10 Mar 2011 12:08:22 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p2AH8M7i083939; Thu, 10 Mar 2011 12:08:22 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 10 Mar 2011 12:08:22 -0500 (EST) From: Samuel Weiler To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110218213453.GB96163@registro.br> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1019228496-1299769818=:60284" Content-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 10 Mar 2011 12:08:23 -0500 (EST) Cc: dnsext@ietf.org Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:07:09 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1019228496-1299769818=:60284 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: > Thats a process issue outside my scope :-) Heh. Indeed. :-) > It might be appropriate to skip the IANA registry for the moment. Resubmit the specificcation with no IANA registry > ("here are the two values") and only create the registry in the RFC. > > That would only change the template, not the draft? ... > I am trying to follow the process as I understand it here and that > requires the template to specify the registries the draft proposes > to create. I'm sensitive to the "we don't want to start over from square one". I also want to be able to point to a firm "here's the definition of the RRTYPE" document. And I'm concerned that your use of the "Expert Review" IANA assignment metric is underspecified in this case. I was suggesting you take the IANA registry bits out of the draft (for now), point to a static-list version of the draft for purposes of RRTYPE assignment, and later create a registry for that field (in a subsequent revision of the i-d, as it gets closer to publication). I suppose that's inconsistent, in some ways, with wanting a static specification, but it highlights my desire to nail down particular version of the i-d which is the definition. Two alternate ideas are below. > Now what may well make more sense as a process would be to have a > two phase scheme in which DNS RR codes are marked 'reserved' in > response to the expert review and the final allocation is performed > when the RFC is issued. This is effectively what has happened with > Stuart Cheshire's Bonjour scheme. > > But that is not the process we have. You can still do that: 5395 specifically recognizes that RFC can allocate RRTYPES (with no template), including using the RFC420 early allocation process. It sounds like that might be appropriate here, since you plan to publish as an RFC -- skip the template and ask for an early allocation. Another idea: change the IANA assignment metric to one of the more thoroughly defined ones like "First Come First Served" or "RFC Required". Those get you away from needing to tell the expert what to look for, though with First Come First Served you still should put restrictions on the tag field (max length 15 and only numbers and lowercase letters, consistent with section 3.1 of the draft). You can easily change that assignment metric later. > Which brings us to the discussion on the list yesterday: the template should really be citing a particular version of the > spec.  It hardly seems fair to ask the expert to approve an RRTYPE based on a reference to a changing document. > > I think that is unhelpful. I think of it more from the "let's make sure the record is clear" perspective. In two years, how will I know which version of the document is the one that defined this RRTYPE? -- Sam --621616949-1019228496-1299769818=:60284-- From weiler@watson.org Thu Mar 10 11:17:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B643A6A49 for ; Thu, 10 Mar 2011 11:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys2KqG0WCWJo for ; Thu, 10 Mar 2011 11:17:13 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 681D73A6A29 for ; Thu, 10 Mar 2011 11:17:13 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p2AJIUBt093608 for ; Thu, 10 Mar 2011 14:18:31 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p2AJIUxJ093605 for ; Thu, 10 Mar 2011 14:18:30 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 10 Mar 2011 14:18:30 -0500 (EST) From: Samuel Weiler To: dnsext@ietf.org In-Reply-To: <4CF4D54B.5000407@nlnetlabs.nl> Message-ID: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 10 Mar 2011 14:18:31 -0500 (EST) Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:17:14 -0000 On Tue, 30 Nov 2010, W.C.A. Wijngaards wrote: > It is clear that checking the set of algorithms present in the DNSKEY > set is not a good idea, and checking the set of algorithms from the DS > set is the right, more lenient way to go. I apologize for checking out of this discussion last fall. I would like the WG's help understanding where you want to go with this topic. I don't fully understand the argument in favor of not checking the algorithms on the child side of the zone cut (= the ones in the DNSKEY RRset), nor am I sure that was the direction everyone seemed to want to go. Could someone summarize the current state of this? My own inclination is (still) to treat this as a clarification, saying that validators are not required to enforce these rules. (In other words, the extra checks Unbound did were just fine, though unnecessary. BIND's lenient approach was also fine.) Two specific pieces of proposed text can be found in the first message in this thread, dated 18 November 2010. -- Sam From hallam@gmail.com Thu Mar 10 11:50:55 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA963A6811 for ; Thu, 10 Mar 2011 11:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.548 X-Spam-Level: X-Spam-Status: No, score=-4.548 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsRLtrdt+vDm for ; Thu, 10 Mar 2011 11:50:54 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BA6C63A67FF for ; Thu, 10 Mar 2011 11:50:53 -0800 (PST) Received: by iwl42 with SMTP id 42so2368342iwl.31 for ; Thu, 10 Mar 2011 11:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IHxXEFqUUcSHZaB6/mz3RBFBHszBTnPrxd0/YIfM664=; b=WZOdpxK9s47D0qpVwI/YsRZDWAS8Cba3cZw0J/cVOn+VZNQSoFVeN7XbSRvb8hHq+N u2hGPggnzy7ZnvALPu6j7ccSvzlA3SwM+oA/uDd4/u50niePF9ygdlCEMBYTx3poYz0i OJxNUqdPcfCm2yVd5B9ozqsTu6Spy7WD7KN0c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Jcu78al3RnEa10v1Tg6otnXZIadNlaZa4qiSK6+pi02hfxMAdSKyFpSzOWzt9KPFwv 4ErEIoyKoBtYuUVZcDf+m8A+aIo8DN6ZQBeb0j6IdkOL+8tesTS7FskkKGAPEWucgAMf 2hukvg8i5zqIofqYTMMX/ynHEOhVz8a3dNHy8= MIME-Version: 1.0 Received: by 10.43.48.71 with SMTP id uv7mr10511592icb.501.1299786731742; Thu, 10 Mar 2011 11:52:11 -0800 (PST) Received: by 10.43.61.80 with HTTP; Thu, 10 Mar 2011 11:52:11 -0800 (PST) In-Reply-To: References: <20110218213453.GB96163@registro.br> Date: Thu, 10 Mar 2011 14:52:11 -0500 Message-ID: From: Phillip Hallam-Baker To: Samuel Weiler Content-Type: multipart/alternative; boundary=bcaec52e5fb16de54b049e262e7c Cc: dnsext@ietf.org Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:50:56 -0000 --bcaec52e5fb16de54b049e262e7c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 10, 2011 at 12:08 PM, Samuel Weiler wrote: > Thats a process issue outside my scope :-) >> > > Heh. Indeed. :-) > > > It might be appropriate to skip the IANA registry for the moment. >> Resubmit the specificcation with no IANA registry >> ("here are the two values") and only create the registry in the RFC. >> >> That would only change the template, not the draft? >> > ... > >> I am trying to follow the process as I understand it here and that >> requires the template to specify the registries the draft proposes to >> create. >> > > I'm sensitive to the "we don't want to start over from square one". I also > want to be able to point to a firm "here's the definition of the RRTYPE" > document. And I'm concerned that your use of the "Expert Review" IANA > assignment metric is underspecified in this case. > > I was suggesting you take the IANA registry bits out of the draft (for > now), point to a static-list version of the draft for purposes of RRTYPE > assignment, and later create a registry for that field (in a subsequent > revision of the i-d, as it gets closer to publication). > > I suppose that's inconsistent, in some ways, with wanting a static > specification, but it highlights my desire to nail down particular version > of the i-d which is the definition. > > Two alternate ideas are below. > > > Now what may well make more sense as a process would be to have a two >> phase scheme in which DNS RR codes are marked 'reserved' in response to the >> expert review and the final allocation is performed when the RFC is issued. >> This is effectively what has happened with Stuart Cheshire's Bonjour scheme. >> >> But that is not the process we have. >> > > You can still do that: 5395 specifically recognizes that RFC can allocate > RRTYPES (with no template), including using the RFC420 early allocation > process. It sounds like that might be appropriate here, since you plan to > publish as an RFC -- skip the template and ask for an early allocation. > > Another idea: change the IANA assignment metric to one of the more > thoroughly defined ones like "First Come First Served" or "RFC Required". > Those get you away from needing to tell the expert what to look for, though > with First Come First Served you still should put restrictions on the tag > field (max length 15 and only numbers and lowercase letters, consistent with > section 3.1 of the draft). You can easily change that assignment metric > later. Given the size of the tag space, I think either alternative is acceptable as they will converge on the same effect: Anyone can define a new tag with minimal risk of collision but it is rather unlikely that tags will be widely supported or recognized unless they are described in an RFC somewhere. I suggest RFC required. > > > Which brings us to the discussion on the list yesterday: the template >> should really be citing a particular version of the >> spec. It hardly seems fair to ask the expert to approve an RRTYPE >> based on a reference to a changing document. >> >> I think that is unhelpful. >> > > I think of it more from the "let's make sure the record is clear" > perspective. In two years, how will I know which version of the document is > the one that defined this RRTYPE? > Well the hope would be that we replace the document with a published RFC by then. Now in theory the draft could change in ways that are incompatible with the wire format proposed here, but if that happens then either there will have to be a new RR code issued or the RFC should probably not be published. I really want to get this nailed down much sooner because getting the wire format settled and set in concrete is a pre-condition to discussing the lawyer stuff in CABForum. -- Website: http://hallambaker.com/ --bcaec52e5fb16de54b049e262e7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 10, 2011 at 12:08 PM, Samuel= Weiler <weiler@w= atson.org> wrote:
Thats a process issue outside my scope :-)

Heh. =A0Indeed. =A0:-)


=A0 =A0 =A0It might be appropriate to skip the IANA registry for the momen= t. Resubmit the specificcation with no IANA registry
=A0 =A0 =A0("here are the two values") and only create the regis= try in the RFC.

That would only change the template, not the draft?
...
I am trying to follow the process as I understand it here and that requires= the template to specify the registries the draft proposes to create.

I'm sensitive to the "we don't want to start over from square = one". I also want to be able to point to a firm "here's the d= efinition of the RRTYPE" document. =A0And I'm concerned that your = use of the "Expert Review" IANA assignment metric is underspecifi= ed in this case.

I was suggesting you take the IANA registry bits out of the draft (for now)= , point to a static-list version of the draft for purposes of RRTYPE assign= ment, and later create a registry for that field (in a subsequent revision = of the i-d, as it gets closer to publication).

I suppose that's inconsistent, in some ways, with wanting a static spec= ification, but it highlights my desire to nail down particular version of t= he i-d which is the definition.

Two alternate ideas are below.


Now what may well make more sense as a process would be to have a two phase= scheme in which DNS RR codes are marked 'reserved' in response to = the expert review and the final allocation is performed when the RFC is iss= ued. This is effectively what has happened with Stuart Cheshire's Bonjo= ur scheme.

But that is not the process we have.

You can still do that: 5395 specifically recognizes that RFC can allocate R= RTYPES (with no template), including using the RFC420 early allocation proc= ess. =A0It sounds like that might be appropriate here, since you plan to pu= blish as an RFC -- skip the template and ask for an early allocation.

Another idea: change the IANA assignment metric to one of the more thorough= ly defined ones like "First Come First Served" or "RFC Requi= red". =A0Those get you away from needing to tell the expert what to lo= ok for, though with First Come First Served you still should put restrictio= ns on the tag field (max length 15 and only numbers and lowercase letters, = consistent with section 3.1 of the draft). =A0You can easily change that as= signment metric later.


Given the size of the tag space, I think= either alternative is acceptable as they will converge on the same effect:= Anyone can define a new tag with minimal risk of collision but it is rathe= r unlikely that tags will be widely supported or recognized unless they are= described in an RFC somewhere.

I suggest RFC required.


=A0


=A0 =A0 =A0Which brings us to the discussion on the list yesterday: the te= mplate should really be citing a particular version of the
=A0 =A0 =A0spec. =A0It hardly seems fair to ask the expert to approve an R= RTYPE based on a reference to a changing document.

I think that is unhelpful.

I think of it more from the "let's make sure the record is clear&q= uot; perspective. =A0In two years, how will I know which version of the doc= ument is the one that defined this RRTYPE?

Well the hope would be that we replace the document with a published R= FC by then.


Now in theory the draft= could change in ways that are incompatible with the wire format proposed h= ere, but if that happens then either there will have to be a new RR code is= sued or the RFC should probably not be published.=A0

I really want to get this nailed down much sooner becau= se getting the wire format settled and set in concrete is a pre-condition t= o discussing the lawyer stuff in CABForum.

-- Website: http://hallambaker.com/
--bcaec52e5fb16de54b049e262e7c-- From stephan.lagerholm@secure64.com Thu Mar 10 11:54:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525F43A680F for ; Thu, 10 Mar 2011 11:54:15 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe6TNCrSJkyJ for ; Thu, 10 Mar 2011 11:54:14 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by core3.amsl.com (Postfix) with ESMTP id 328273A67FF for ; Thu, 10 Mar 2011 11:54:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 47E1FB8386; Thu, 10 Mar 2011 12:49:13 -0700 (MST) 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 alYJOSBDvngE; Thu, 10 Mar 2011 12:49:10 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id BCE72B8377; Thu, 10 Mar 2011 12:49:10 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1299786550; bh=npUYOMXB69xxvunowTn1Pcn7uVo+3BoKYlI/LM6o0Jw=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=ngBnVhLlNHBOq/xEK569M SNSYBDHc3ReTqAGQQRJL5M/MMmI4rTGSMh1c9SIPmMoHNU5FDBp2M10qF4Ifq8bgdEo COzjbyqvMCatFhIRbolfb3aD9aPsSlZFAQ1p9aU4q6IjuIXX3Qzkc2MRMElzFICzXg1 sMIhaNVSPUjXS2HQ= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2011 12:48:30 -0700 Message-ID: In-Reply-To: <3D41A425A17444EA8EEE8C78DD18D3E9@local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] CDS RRTYPE review - Comments period end Mar 29th Thread-Index: Acve8UHx3Xib/gBNRxqv7Fl+UvAeLwAahOqA References: <20110309133017.GA19809@odin.mars.sol><4D778C86.4020105@ogud.com> <3D41A425A17444EA8EEE8C78DD18D3E9@local> From: "Stephan Lagerholm" To: "George Barwood" , "Olafur Gudmundsson" , , "Mark Andrews" Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:54:15 -0000 George B and Mark A, >In either case the software that signs zones has to be updated. If adding a new flag to DNSKEY and if the software already supports the DNSKEY RR with arbitrary flags, then no update is needed. For example, I could use an old version of ISC dig and still make sense out of the DNSKEY record even if a new flag was added. But I had to upgrade ISC dig if I wanted to figure out details about the CDS record. >If the output is in text format, the generic text format of RFC3597 section 5 >may be used if the serving software for the master server has not been updated. The RDATA field would still just be a "blob". How would I for example be able to verify the Key Tag, Algorithm or Digest Type field unless the software you are using is programmed to understand that the format the same as for the DS record? >The software for secondary servers does not need to be updated in any case, >assuming it implements RFC3597 ( that is it can handle unknown types ), >which is of course the case for all mainstream implementations. Agreed, I'm taking about software that interacts with humans and try to display something meaningful for them (provisioning system, IPAM, debugging tools, etc) (For the record, I'm positive to this draft other than using a new RR type. I would rather like to see an "embryonic" flag to the DNSKEY similar to what the revoked flag is doing for old keys is RFC5011) /S From ajs@shinkuro.com Thu Mar 10 12:06:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1AF3A67FF for ; Thu, 10 Mar 2011 12:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMAhpbGNGTdw for ; Thu, 10 Mar 2011 12:06:33 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9F3373A6941 for ; Thu, 10 Mar 2011 12:06:33 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A70F01ECB408 for ; Thu, 10 Mar 2011 20:07:50 +0000 (UTC) Date: Thu, 10 Mar 2011 15:07:48 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110310200748.GY57756@shinkuro.com> References: <20110218213453.GB96163@registro.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:06:34 -0000 Dear colleagues, I write as the locally-appointed pointy-hair on this subject. I am not the appointed Expert, please note. On Thu, Mar 10, 2011 at 07:55:08AM -0500, Samuel Weiler wrote: > > Is it really appropriate to allow a template to create IANA registries? The template does not actually leave open the possibility of creating an entirely new registry, but it does permit "the creation of a new IANA sub-registry in DNS Parameters?" I've always found this a little odd, but RFC 5395 does not list this as a reason to reject the application. RFC 5395, on my reading, defaults to permissive: as long as section 3.1.1 criteria 1 and 2 are met, then the application should go ahead so long as it does not meet any of the criteria under section 3.1.2. Therefore, I see no reason that subregistries to DNS Parameters can not be created along with an RRTYPE. The registration rules are what make this a little funny. But the template does not require us to specify the registration rules for the subregistry, and RFC 5395 is similarly silent. I think any I-D that actually specifies the RRTYPE and its use should, in the end, also contain rules for the registration in the subregistry. But I am not at all sure that the registry's rules need to be specified at its creation. (I wouldn't be surprised to learn I am wrong about this; if so, I'd like a reference to the rules.) > It might be appropriate to skip the IANA registry for the moment. If the RRTYPE requires a subregistry, then the subregistry is not optional; that would make the template incomplete. > Which brings us to the discussion on the list yesterday: the template > should really be citing a particular version of the spec. I don't believe it should, and I don't think that would be desirable. There are two reasons for that. First, the template says this: E. Description of the proposed RR type. This description can be provided in-line in the template, as an attachment, or with a publicly available URL: The publicly-available URL might well track changes to the use of the RRTYPE. As long as the use does not violate any of the rules, even if the use changes slightly, that appears to be allowable. Moreover, section 3.1.2 of RFC 5395 appears explicitly to allow changing documentation: 3. The documentation of the proposed RRTYPE or RRTYPEs is incomplete. (Additional documentation can be provided during the public comment period or by the Expert.) Finally, the template has room for the case where an existing RRTYPE (presumably, one assigned early on in the review process) is altered: B. Submission Type: [ ] New RRTYPE [ ] Modification to existing RRTYPE This suggests that the WG was prepared for the possibility that RRTYPEs would change slightly in the time between initial conception and assignment, and between assignment and final publication. Small communities of users of an RRTYPE can presumably be expected to tolerate incompatible changes shortly after assignment, when all the implementations in the world are still being used by the developers and nobody else. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From iana-shared@icann.org Thu Mar 10 12:09:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4173A680F for ; Thu, 10 Mar 2011 12:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDxhRfQ6ojvk for ; Thu, 10 Mar 2011 12:09:33 -0800 (PST) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by core3.amsl.com (Postfix) with ESMTP id 14AD53A67FF for ; Thu, 10 Mar 2011 12:09:32 -0800 (PST) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id p2AKAUpv007599; Thu, 10 Mar 2011 12:10:50 -0800 Received: from request1.lax.icann.org (localhost.localdomain [127.0.0.1]) by request1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p2AKAUQ9007778; Thu, 10 Mar 2011 20:10:30 GMT Received: (from apache@localhost) by request1.lax.icann.org (8.13.8/8.13.8/Submit) id p2AKAUiX007775; Thu, 10 Mar 2011 20:10:30 GMT From: "Amanda Baber via RT" In-Reply-To: References: <20110218213453.GB96163@registro.br> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #434639 Managed-by: RT 3.8.HEAD (http://www.bestpractical.com/rt/) RT-Originator: amanda.baber@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Thu, 10 Mar 2011 20:10:30 +0000 X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Thu, 10 Mar 2011 12:10:50 -0800 (PST) X-Mailman-Approved-At: Thu, 10 Mar 2011 12:21:42 -0800 Cc: dnsext@ietf.org Subject: [dnsext] [IANA #434639] Re: CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: iana-questions@iana.org List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:09:34 -0000 Hi, > Is it really appropriate to allow a template to create IANA > registries? It does seem odd to me that a template can create an IANA > registry when the i-d it cites can't itself create a registry until > published as an RFC. Perhaps IANA should comment on that. Requests to create registries should be published in an RFC. thanks, Amanda Baber IANA From paul.hoffman@vpnc.org Thu Mar 10 13:04:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221333A6945 for ; Thu, 10 Mar 2011 13:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.959 X-Spam-Level: X-Spam-Status: No, score=-101.959 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfZanuHV3Jc6 for ; Thu, 10 Mar 2011 13:04:15 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id E11F63A67F8 for ; Thu, 10 Mar 2011 13:04:14 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2AL5V36086500 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 Mar 2011 14:05:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D793D1B.4030202@vpnc.org> Date: Thu, 10 Mar 2011 13:05:31 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110218213453.GB96163@registro.br> <20110310200748.GY57756@shinkuro.com> In-Reply-To: <20110310200748.GY57756@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:04:16 -0000 On 3/10/11 12:07 PM, Andrew Sullivan wrote: > On Thu, Mar 10, 2011 at 07:55:08AM -0500, Samuel Weiler wrote: >> Which brings us to the discussion on the list yesterday: the template >> should really be citing a particular version of the spec. > > I don't believe it should, and I don't think that would be desirable. +1 to Andrew's response and analysis. It is pretty inexcusable to have an IETF-vetted BCP that says how this registry is populated, and then say "we didn't really mean that, we want to be more restrictive". If you really want to have that much control over the registry, please write rfc5395bis and see if others agree. From ajs@shinkuro.com Thu Mar 10 13:09:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B943A6A7D for ; Thu, 10 Mar 2011 13:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4a7-mClf51L for ; Thu, 10 Mar 2011 13:09:08 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id CCBD73A6A5D for ; Thu, 10 Mar 2011 13:09:08 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6569C1ECB408; Thu, 10 Mar 2011 21:10:25 +0000 (UTC) Date: Thu, 10 Mar 2011 16:10:23 -0500 From: Andrew Sullivan To: Amanda Baber via RT Message-ID: <20110310211023.GI57756@shinkuro.com> References: <20110218213453.GB96163@registro.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: dnsext@ietf.org Subject: Re: [dnsext] [IANA #434639] Re: CAA RRTYPE review - Comments period end Mar 11th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:09:09 -0000 On Thu, Mar 10, 2011 at 08:10:30PM +0000, Amanda Baber via RT wrote: > Hi, > > > Is it really appropriate to allow a template to create IANA > > registries? It does seem odd to me that a template can create an IANA > > registry when the i-d it cites can't itself create a registry until > > published as an RFC. Perhaps IANA should comment on that. > > Requests to create registries should be published in an RFC. Creating a completely new registry, yes. But since the template in RFC 5395 explicitly asks whether a new sub-registry to DNS Parameters, surely such a sub-registry can be created as part of the creation of the RRTYPE, no? Otherwise, that ought to be called out as one of the reasons not to approve the RRTYPE, no? Best, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ogud@ogud.com Thu Mar 10 14:16:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B25F3A6ADE for ; Thu, 10 Mar 2011 14:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYw98BzKtkbs for ; Thu, 10 Mar 2011 14:16:14 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 7465E3A6A79 for ; Thu, 10 Mar 2011 14:16:14 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2AMHTrH058686; Thu, 10 Mar 2011 17:17:29 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D794DF2.5030907@ogud.com> Date: Thu, 10 Mar 2011 17:17:22 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Stephan Lagerholm References: <20110309133017.GA19809@odin.mars.sol><4D778C86.4020105@ogud.com> <3D41A425A17444EA8EEE8C78DD18D3E9@local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 22:16:15 -0000 On 10/03/2011 2:48 PM, Stephan Lagerholm wrote: > George B and Mark A, > >> In either case the software that signs zones has to be updated. > > If adding a new flag to DNSKEY and if the software already supports the > DNSKEY RR with arbitrary flags, then no update is needed. For example, I > could use an old version of ISC dig and still make sense out of the > DNSKEY record even if a new flag was added. But I had to upgrade ISC dig > if I wanted to figure out details about the CDS record. > >> If the output is in text format, the generic text format of RFC3597 > section 5 >> may be used if the serving software for the master server has not been > updated. > > The RDATA field would still just be a "blob". How would I for example be > able to verify the Key Tag, Algorithm or Digest Type field unless the > software you are using is programmed to understand that the format the > same as for the DS record? > >> The software for secondary servers does not need to be updated in any > case, >> assuming it implements RFC3597 ( that is it can handle unknown types ), >> which is of course the case for all mainstream implementations. > > Agreed, I'm taking about software that interacts with humans and try to > display something meaningful for them (provisioning system, IPAM, > debugging tools, etc) > > (For the record, I'm positive to this draft other than using a new RR > type. I would rather like to see an "embryonic" flag to the DNSKEY > similar to what the revoked flag is doing for old keys is RFC5011) > > /S > > > Stephan, there is a problem with using a flag as the flag field is covered both by DNSKEY keytag calculation and DS digest calculation. Thus changing the flag will "revoke" the key and/or its signatures, unless validators know how to handle the flag change. For all practical purposes the key flag field is a wasted space I tried to have it killed when we did the type code rollover (KEY ---> DNSKEY) along with the protocol field, but ...... Olafur From marka@isc.org Thu Mar 10 14:33:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C2B3A6ADE for ; Thu, 10 Mar 2011 14:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60yH5pBtqLXe for ; Thu, 10 Mar 2011 14:33:34 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id D1CA73A6866 for ; Thu, 10 Mar 2011 14:33:33 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 581F6C9423; Thu, 10 Mar 2011 22:34:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 E77C2216C1E; Thu, 10 Mar 2011 22:34:40 +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 978E9C0E902; Fri, 11 Mar 2011 09:34:38 +1100 (EST) To: Samuel Weiler From: Mark Andrews References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> In-reply-to: Your message of "Thu, 10 Mar 2011 14:18:30 CDT." Date: Fri, 11 Mar 2011 09:34:38 +1100 Message-Id: <20110310223438.978E9C0E902@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 22:33:35 -0000 In message , Samuel Weil er writes: > On Tue, 30 Nov 2010, W.C.A. Wijngaards wrote: > > > It is clear that checking the set of algorithms present in the DNSKEY > > set is not a good idea, and checking the set of algorithms from the DS > > set is the right, more lenient way to go. > > I apologize for checking out of this discussion last fall. > > I would like the WG's help understanding where you want to go with > this topic. I don't fully understand the argument in favor of not > checking the algorithms on the child side of the zone cut (= the ones > in the DNSKEY RRset), nor am I sure that was the direction everyone > seemed to want to go. Could someone summarize the current state of > this? > > My own inclination is (still) to treat this as a clarification, saying > that validators are not required to enforce these rules. (In other > words, the extra checks Unbound did were just fine, though > unnecessary. BIND's lenient approach was also fine.) Two specific > pieces of proposed text can be found in the first message in this > thread, dated 18 November 2010. While we think about this ISC has also had bug reports claiming that is we don't publish DNSKEY prior to signing with them we are break RFC 4035 because it allows verification of every RRSIG as a policy and the only way to do that is to publish the DNSKEY prior to use. If other RRSIG RRs also cover this RRset, the local resolver security policy determines whether the resolver also has to test these RRSIG RRs and how to resolve conflicts if these RRSIG RRs lead to differing results. > -- Sam > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Thu Mar 10 15:32:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15BB43A67B2 for ; Thu, 10 Mar 2011 15:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTg+iEP42Usx for ; Thu, 10 Mar 2011 15:32:34 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 974F23A67A3 for ; Thu, 10 Mar 2011 15:32:33 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id B99C55F984C; Thu, 10 Mar 2011 23:33:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 CAF4F216C1E; Thu, 10 Mar 2011 23:33:34 +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 C6406C0F4D4; Fri, 11 Mar 2011 10:33:32 +1100 (EST) To: "Stephan Lagerholm" From: Mark Andrews References: <20110309133017.GA19809@odin.mars.sol><4D778C86.4020105@ogud.com> <3D41A425A17444EA8EEE8C78DD18D3E9@local> In-reply-to: Your message of "Thu, 10 Mar 2011 12:48:30 PDT." Date: Fri, 11 Mar 2011 10:33:32 +1100 Message-Id: <20110310233332.C6406C0F4D4@drugs.dv.isc.org> Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 23:32:35 -0000 In message , "Ste phan Lagerholm" writes: > George B and Mark A, > > >In either case the software that signs zones has to be updated. > > If adding a new flag to DNSKEY and if the software already supports the > DNSKEY RR with arbitrary flags, then no update is needed. For example, I > could use an old version of ISC dig and still make sense out of the > DNSKEY record even if a new flag was added. But I had to upgrade ISC dig > if I wanted to figure out details about the CDS record. Running DS throug a really old version of DiG produces this: isc.org. 20h56m50s IN TYPE43 \# 36 ( ; unknown RR type 32 5c 05 02 f1 e1 84 c0 e1 d6 15 d2 0e b3 c2 23 ; 2\.............# ac ed 3b 03 c7 73 dd 95 2d 5f 0e b5 c7 77 58 6d ; ..;..s..-_...wXm e1 8d a6 b5 ) ; .... isc.org. 20h56m50s IN TYPE43 \# 24 ( ; unknown RR type 32 5c 05 01 98 21 13 d0 8b 4c 6a 1d 9f 6a ee 1e ; 2\...!...Lj..j.. 22 37 ae f6 9f 3f 97 59 ) ; "7...?.Y The key id is 0x325c (12892), the algorithm in 5 and the hashs are 2 for the first and 1 for the second. > >If the output is in text format, the generic text format of RFC3597 > section 5 > >may be used if the serving software for the master server has not been > updated. > > The RDATA field would still just be a "blob". How would I for example be > able to verify the Key Tag, Algorithm or Digest Type field unless the > software you are using is programmed to understand that the format the > same as for the DS record? Given the blob is printed in hex you could just read two of those fields directly and the third nearly as easily. Digest type: 01 or 02 (currently in use) Algorithm: 01 ... 0a (currently in use) Keytag: is a little harder but not much. Or you could take the TYPEXXX .... and turn in into TYPE43 ... and put that through any piece of software that understands DS and unknown types. > >The software for secondary servers does not need to be updated in any > case, > >assuming it implements RFC3597 ( that is it can handle unknown types ), > >which is of course the case for all mainstream implementations. > > Agreed, I'm taking about software that interacts with humans and try to > display something meaningful for them (provisioning system, IPAM, > debugging tools, etc) > > (For the record, I'm positive to this draft other than using a new RR > type. I would rather like to see an "embryonic" flag to the DNSKEY > similar to what the revoked flag is doing for old keys is RFC5011) > > /S -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From stephan.lagerholm@secure64.com Thu Mar 10 17:53:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CBBC3A67E3 for ; Thu, 10 Mar 2011 17:53:52 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIV+0I75KxjT for ; Thu, 10 Mar 2011 17:53:51 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by core3.amsl.com (Postfix) with ESMTP id 851C83A67FF for ; Thu, 10 Mar 2011 17:53:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 7358EB8386; Thu, 10 Mar 2011 18:48:49 -0700 (MST) 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 1IjT0Rr7s33P; Thu, 10 Mar 2011 18:48:47 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 336F3B8312; Thu, 10 Mar 2011 18:48:47 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1299808127; bh=tbUXc+Sx/6pXdk9tAZ8p/5ci+JuqAHvzMhU42YBY8iU=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=f6MGU8Wm/uPX0n6CIR NWyXDfhoXYvf6deWlCQ+oLhur72almbqCt+/1YuLR73feDM5Ex7J4QdfWNUj0L48ArB 4qjpWsMEECwPxCrHR7k07JqVeKsJlIaefelsnBLLwFbP1OchDQ9oUwiyKm8yuwHq+fY 2at/17fhRiU/JVaE5kw= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2011 18:48:05 -0700 Message-ID: In-Reply-To: <4D794DF2.5030907@ogud.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] CDS RRTYPE review - Comments period end Mar 29th Thread-Index: AcvfcArU3/tW5eqlRVmYr65X0+by8gAHhwzg References: <20110309133017.GA19809@odin.mars.sol><4D778C86.4020105@ogud.com><3D41A425A17444EA8EEE8C78DD18D3E9@local> <4D794DF2.5030907@ogud.com> From: "Stephan Lagerholm" To: "Olafur Gudmundsson" Cc: dnsext@ietf.org Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 01:53:52 -0000 On Thursday, March 10, 2011 4:17 PM Olafur Gudmundsson wrote: >there is a problem with using a flag as >the flag field is covered both by DNSKEY keytag calculation and DS >digest calculation. >Thus changing the flag will "revoke" the key and/or its signatures, Yes, the keytag would change when a key went from Embryonic to KSK, just like it is doing for RFC5011 revoked (flag 385) keys. The parent would have to take that into accont when creating the DS record. >unless validators know how to handle the flag change. This embryonic key would not be used to sign anything, so validators would not be affected. >For all practical purposes the key flag field is a wasted space >I tried to have it killed when we did the type code rollover >(KEY ---> DNSKEY) along with the protocol field, but ...... It is not wasted space, RFC5011 is using it. There are programs such as autotrust that relies on it, we use it to signal what keys are SEP keys, etc...=20 RFC5011 is using it to signal that a key is "dead". Why can we not use another flag to signal that a key is about to get "born" (prior to the DS is being published at the parent)? /S From stephan.lagerholm@secure64.com Thu Mar 10 18:03:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2F13A6AC2 for ; Thu, 10 Mar 2011 18:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fszosN6pPC0 for ; Thu, 10 Mar 2011 18:03:14 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by core3.amsl.com (Postfix) with ESMTP id A7F663A69B6 for ; Thu, 10 Mar 2011 18:03:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 04DEDB8386; Thu, 10 Mar 2011 18:58:14 -0700 (MST) 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 EvwK4Y+45zKa; Thu, 10 Mar 2011 18:58:13 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 58F91B8312; Thu, 10 Mar 2011 18:58:13 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1299808693; bh=JjOizRI9z2qqyKkzK3RkFWiGF35KQXpDBTsXc9DzSJQ=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=w1BpS2xrdJ179yr9BG bNmKfYXxPWl1nO9WVOKOF0XSkrJLKPmnotGw1Dg6fqdKLeONGKdaaOzCGIMuHO+Vg+b Fzc/UQrk0ig8UkdaEQUMhgeIHx55pe/U/JkGCbz+DvRpUmtyrHkL1DBEF/edsDXwf/o cPb5ycLnEgRtPeLeWiM= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2011 18:57:31 -0700 Message-ID: In-Reply-To: <20110310233332.C6406C0F4D4@drugs.dv.isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] CDS RRTYPE review - Comments period end Mar 29th Thread-Index: AcvfeqpN0B7NkytqTcaYRx8cHKL1RgAFMO/g References: <20110309133017.GA19809@odin.mars.sol><4D778C86.4020105@ogud.com> <3D41A425A17444EA8EEE8C78DD18D3E9@local> <20110310233332.C6406C0F4D4@drugs.dv.isc.org> From: "Stephan Lagerholm" To: "Mark Andrews" Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 02:03:15 -0000 Mark, >Running DS throug a really old version of DiG produces this: > >isc.org. 20h56m50s IN TYPE43 \# 36 ( ; unknown RR type > 32 5c 05 02 f1 e1 84 c0 e1 d6 15 d2 0e b3 c2 23 ; 2\.............# > ac ed 3b 03 c7 73 dd 95 2d 5f 0e b5 c7 77 58 6d ; ..;..s..-_...wXm > e1 8d a6 b5 ) ; .... >isc.org. 20h56m50s IN TYPE43 \# 24 ( ; unknown RR type > 32 5c 05 01 98 21 13 d0 8b 4c 6a 1d 9f 6a ee 1e ; 2\...!...Lj..j.. > 22 37 ae f6 9f 3f 97 59 ) ; "7...?.Y > >The key id is 0x325c (12892), the algorithm in 5 and the hashs are 2 >for the first and 1 for the second. Our definition of what "display it in a meaningful way" differs. If a new flag was used instead, then no changes to dig or any other program would be needed: VVVV VVV isc.org. 5361 IN DNSKEY 512 3 5 BEAAAAO6L6BadeFzvt6J63GD GrFANfJAitCd9Njcj49y6PE1Bv6t33sE yxSVi4KWbjQgViMCxAArxP0IhDLhYFGbsU2ugkQ4UMFCPgY IVxC1yvBw 1Gt7p+SBQU9qX+Il/cqYTJWQkWRdDPHJoaMT1+f7e6YLlntxpl+M7yw3 aOEbCByPzw=3D=3D /S From marka@isc.org Thu Mar 10 20:06:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CB13A6B63 for ; Thu, 10 Mar 2011 20:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYDqhLYiNLya for ; Thu, 10 Mar 2011 20:06:14 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 4E0723A680D for ; Thu, 10 Mar 2011 20:06:14 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id CF1F3C941A; Fri, 11 Mar 2011 04:07:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 690F0216C31; Fri, 11 Mar 2011 04:07:22 +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 E9EC1C36A68; Fri, 11 Mar 2011 15:07:19 +1100 (EST) To: "Stephan Lagerholm" From: Mark Andrews References: <20110309133017.GA19809@odin.mars.sol><4D778C86.4020105@ogud.com> <3D41A425A17444EA8EEE8C78DD18D3E9@local> <20110310233332.C6406C0F4D4@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 10 Mar 2011 18:57:31 PDT." Date: Fri, 11 Mar 2011 15:07:19 +1100 Message-Id: <20110311040719.E9EC1C36A68@drugs.dv.isc.org> Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 04:06:15 -0000 In message , "Ste phan Lagerholm" writes: > Mark, > > >Running DS throug a really old version of DiG produces this: > > > >isc.org. 20h56m50s IN TYPE43 \# 36 ( ; unknown RR > type > > 32 5c 05 02 f1 e1 84 c0 e1 d6 15 d2 0e b3 c2 23 ; > 2\.............# > > ac ed 3b 03 c7 73 dd 95 2d 5f 0e b5 c7 77 58 6d ; > ..;..s..-_...wXm > > e1 8d a6 b5 ) ; .... > >isc.org. 20h56m50s IN TYPE43 \# 24 ( ; unknown RR > type > > 32 5c 05 01 98 21 13 d0 8b 4c 6a 1d 9f 6a ee 1e ; > 2\...!...Lj..j.. > > 22 37 ae f6 9f 3f 97 59 ) ; "7...?.Y > > > >The key id is 0x325c (12892), the algorithm in 5 and the hashs are 2 > >for the first and 1 for the second. > > Our definition of what "display it in a meaningful way" differs. If a > new flag was used instead, then no changes to dig or any other program > would be needed: > > VVVV VVV > isc.org. 5361 IN DNSKEY 512 3 5 > BEAAAAO6L6BadeFzvt6J63GD > GrFANfJAitCd9Njcj49y6PE1Bv6t33sE > yxSVi4KWbjQgViMCxAArxP0IhDLhYFGbsU2ugkQ4UMFCPgY > IVxC1yvBw 1Gt7p+SBQU9qX+Il/cqYTJWQkWRdDPHJoaMT1+f7e6YLlntxpl+M7yw3 > aOEbCByPzw=3D=3D The on going costs of trying to do this with DNSKEY flags completely overwhelms the one off costs of add a new type. DNSKEY flags change key ids. Revoke is already a mess as it changes the keyid. Adding a second changing flag to the mix is just not on. I can add CDS to BIND in 10 minutes once I have the type code. It would be weeks of work to add the key flags as you need to do thinks like compute the signatures with and without the flag in place or fully work out all the timing issues. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From matthijs@nlnetlabs.nl Fri Mar 11 00:31:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0BC3A6BF0 for ; Fri, 11 Mar 2011 00:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NRsjaphoK7z for ; Fri, 11 Mar 2011 00:30:41 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 1B1E53A6BF7 for ; Fri, 11 Mar 2011 00:30:40 -0800 (PST) Received: from [192.168.1.10] (ip123-112-174-82.adsl2.static.versatel.nl [82.174.112.123]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p2B8Vsij055702 for ; Fri, 11 Mar 2011 09:31:54 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4D79DDFA.3010006@nlnetlabs.nl> Date: Fri, 11 Mar 2011 09:31:54 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: dnsext@ietf.org References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> In-Reply-To: <20110310223438.978E9C0E902@drugs.dv.isc.org> X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [213.154.224.1]); Fri, 11 Mar 2011 09:31:55 +0100 (CET) Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 08:31:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On November 30, Wouter acknowledges that changes need to be made to the Unbound implementation and asks for guidance: http://www.ietf.org/mail-archive/web/dnsext/current/msg10115.html Presenting two options: * One signature is enough (the lenient way) * Check the algorithms. But when checking the algorithms, thou should not use the DNSKEY RRset, but the DS RRset. I think the general consensus is that a validator should at least be able to check the algorithms in the DS RRset (Please correct me if I am being to hasty in my conclusion). There is still debate whether the validator SHOULD or MAY do this (Ed Lewis argued the term 'could', I think that translates to the RFC2119 term MAY). Proposed text would then be: "The validator SHOULD or MAY check (choice here) that the algorithms signaled in the DS-set work (but only for algorithms supported by the validator, of course)." Best regards, Matthijs On 03/10/2011 11:34 PM, Mark Andrews wrote: > > In message , Samuel Weil > er writes: >> On Tue, 30 Nov 2010, W.C.A. Wijngaards wrote: >> >>> It is clear that checking the set of algorithms present in the DNSKEY >>> set is not a good idea, and checking the set of algorithms from the DS >>> set is the right, more lenient way to go. >> >> I apologize for checking out of this discussion last fall. >> >> I would like the WG's help understanding where you want to go with >> this topic. I don't fully understand the argument in favor of not >> checking the algorithms on the child side of the zone cut (= the ones >> in the DNSKEY RRset), nor am I sure that was the direction everyone >> seemed to want to go. Could someone summarize the current state of >> this? >> >> My own inclination is (still) to treat this as a clarification, saying >> that validators are not required to enforce these rules. (In other >> words, the extra checks Unbound did were just fine, though >> unnecessary. BIND's lenient approach was also fine.) Two specific >> pieces of proposed text can be found in the first message in this >> thread, dated 18 November 2010. > > While we think about this ISC has also had bug reports claiming > that is we don't publish DNSKEY prior to signing with them we are > break RFC 4035 because it allows verification of every RRSIG as a > policy and the only way to do that is to publish the DNSKEY prior > to use. > > If other RRSIG RRs also cover this RRset, the local resolver security > policy determines whether the resolver also has to test these RRSIG > RRs and how to resolve conflicts if these RRSIG RRs lead to differing > results. > >> -- Sam >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNed35AAoJEA8yVCPsQCW52EcIALwitOh1IOVX6AqV28GNEYYM VSSlPZyVWYxD0LCVTWq5aleh3EAJ3T4BdRio795mlNrc/vLi0VNL8FqRI8U7mYk8 I+acLNJGhoFpEFeVF+rOXpoZ3yfTerUctv1mmeyeO/2iW+PF++BJh67bcUV34h1p UvP3lMZCBqIpbR3uhRITjF5JsZ2yaqwoARMyIw58MM72M2Y0X3IuJCYSKSl3ANzJ nwBdrtZZcRmfmzJAY8PvDO0/mcyws1iK4JtiMMyXPNAfgxyBEeyxIe8YUR1yrQgL tcxHaDyTsaPp1GnqAbqucYWdhr17QZ1b6SUmh9qyYW1leKXZSecFUp0tjdhCYQo= =qOVC -----END PGP SIGNATURE----- From Ed.Lewis@neustar.biz Fri Mar 11 05:40:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B27E3A6BFF for ; Fri, 11 Mar 2011 05:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv8mKoO6Pn0s for ; Fri, 11 Mar 2011 05:40:29 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6D6263A69AE for ; Fri, 11 Mar 2011 05:40:29 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2BDfcfI065151; Fri, 11 Mar 2011 08:41:39 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.112] by Work-Laptop-2.local (PGP Universal service); Fri, 11 Mar 2011 08:41:47 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 11 Mar 2011 08:41:47 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D79DDFA.3010006@nlnetlabs.nl> References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> Date: Fri, 11 Mar 2011 08:34:57 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: edward.lewis@neustar.biz Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 13:40:31 -0000 "Could" as in, SHOULD NOT if I had to choose from the 2119 menu of options. I'd prefer "not recommended" but that isn't on the menu. I would prefer to use this bon mot: "I encourage my competitors to behave this way." ...to be clear, I am talking about the validator actually checking the signatures. Having the ability to, sure, that is important. But "if one chain works, it succeeds" is an important spirit. At 9:31 +0100 3/11/11, Matthijs Mekking wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi, > >On November 30, Wouter acknowledges that changes need to be made to the >Unbound implementation and asks for guidance: > > http://www.ietf.org/mail-archive/web/dnsext/current/msg10115.html > >Presenting two options: >* One signature is enough (the lenient way) >* Check the algorithms. > >But when checking the algorithms, thou should not use the DNSKEY RRset, >but the DS RRset. > >I think the general consensus is that a validator should at least be >able to check the algorithms in the DS RRset (Please correct me if I am >being to hasty in my conclusion). There is still debate whether the >validator SHOULD or MAY do this (Ed Lewis argued the term 'could', I >think that translates to the RFC2119 term MAY). > > Proposed text would then be: > > "The validator SHOULD or MAY check (choice here) that the algorithms > signaled in the DS-set work (but only for algorithms supported by > the validator, of course)." > >Best regards, > >Matthijs > > > > >On 03/10/2011 11:34 PM, Mark Andrews wrote: >> >> In message >>, Samuel Weil >> er writes: >>> On Tue, 30 Nov 2010, W.C.A. Wijngaards wrote: >>> >>>> It is clear that checking the set of algorithms present in the DNSKEY >>>> set is not a good idea, and checking the set of algorithms from the DS >>>> set is the right, more lenient way to go. >>> >>> I apologize for checking out of this discussion last fall. >>> >>> I would like the WG's help understanding where you want to go with >>> this topic. I don't fully understand the argument in favor of not >>> checking the algorithms on the child side of the zone cut (= the ones >>> in the DNSKEY RRset), nor am I sure that was the direction everyone >>> seemed to want to go. Could someone summarize the current state of >>> this? >>> >>> My own inclination is (still) to treat this as a clarification, saying >>> that validators are not required to enforce these rules. (In other >>> words, the extra checks Unbound did were just fine, though >>> unnecessary. BIND's lenient approach was also fine.) Two specific >>> pieces of proposed text can be found in the first message in this >>> thread, dated 18 November 2010. >> >> While we think about this ISC has also had bug reports claiming >> that is we don't publish DNSKEY prior to signing with them we are >> break RFC 4035 because it allows verification of every RRSIG as a >> policy and the only way to do that is to publish the DNSKEY prior >> to use. >> >> If other RRSIG RRs also cover this RRset, the local resolver security >> policy determines whether the resolver also has to test these RRSIG >> RRs and how to resolve conflicts if these RRSIG RRs lead to differing >> results. >> >>> -- Sam >>> _______________________________________________ >>> dnsext mailing list >>> dnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsext >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.10 (GNU/Linux) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >iQEcBAEBAgAGBQJNed35AAoJEA8yVCPsQCW52EcIALwitOh1IOVX6AqV28GNEYYM >VSSlPZyVWYxD0LCVTWq5aleh3EAJ3T4BdRio795mlNrc/vLi0VNL8FqRI8U7mYk8 >I+acLNJGhoFpEFeVF+rOXpoZ3yfTerUctv1mmeyeO/2iW+PF++BJh67bcUV34h1p >UvP3lMZCBqIpbR3uhRITjF5JsZ2yaqwoARMyIw58MM72M2Y0X3IuJCYSKSl3ANzJ >nwBdrtZZcRmfmzJAY8PvDO0/mcyws1iK4JtiMMyXPNAfgxyBEeyxIe8YUR1yrQgL >tcxHaDyTsaPp1GnqAbqucYWdhr17QZ1b6SUmh9qyYW1leKXZSecFUp0tjdhCYQo= >=qOVC >-----END PGP SIGNATURE----- >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From dougb@dougbarton.us Sat Mar 12 14:47:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4FA3A68FD for ; Sat, 12 Mar 2011 14:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4iJ2BLAVcSh for ; Sat, 12 Mar 2011 14:47:05 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 9C2A93A68F3 for ; Sat, 12 Mar 2011 14:47:05 -0800 (PST) Received: (qmail 5739 invoked by uid 399); 12 Mar 2011 22:48:24 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 12 Mar 2011 22:48:24 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D7BF836.1090400@dougbarton.us> Date: Sat, 12 Mar 2011 14:48:22 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Kim Davies References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dennis Jennings , "dnsext@ietf.org" Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 22:47:07 -0000 Kim, I'm looking at the remote participation schedule (http://svsf40.icann.org/svsf40/remote-schedule) and I'm not seeing this meeting on it. Hopefully that will change, and if it does can you let us know? :) I think that there would be a tremendous benefit from having an open door into how the ICANN community looks at this problem. Doug On 03/09/2011 10:10, Kim Davies wrote: > Dear colleagues, > > We are holding an informal birds-of-a-feather type meeting at the ICANN > meeting in San Francisco. The idea is to discuss the work ongoing in > both ICANN and IETF circles, and brainstorm how the work in both groups > can benefit one another. A goal for the discussion is to identify how to > best allocate resources to avoid duplicate work, as well as having > ICANN's work help guide the IETF's scope of work, and vice versa. > > Anyone with an interest in the discussions on variant issues within the > IETF and ICANN is welcome to attend. > > The meeting will be held at *2pm on Thursday 17 March*. The room is > called Elizabethan D in the meeting venue, the Westin on Union Square. > > Also note there is a more formal, scheduled meeting on the agenda to > discuss ICANN variant issues, specifically presenting case studies from > different regions that may require variant solutions. This is separate > to this BOF and is being held at Wednesday at 3pm (see > http://svsf40.icann.org/node/22193). We will recap any relevant > discussion from that meeting briefly in the BOF. > > kim > (On behalf of ICANN's staff variant project team) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From johnl@iecc.com Sat Mar 12 14:57:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938B93A6A28 for ; Sat, 12 Mar 2011 14:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.695 X-Spam-Level: X-Spam-Status: No, score=-110.695 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqH-d7nfNn7B for ; Sat, 12 Mar 2011 14:57:40 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id D15EF3A6A15 for ; Sat, 12 Mar 2011 14:57:39 -0800 (PST) Received: (qmail 8823 invoked from network); 12 Mar 2011 22:58:59 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 12 Mar 2011 22:58:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4714.4d7bfab3.k1103; i=johnl@user.iecc.com; bh=HSQ5zf1VNScsW82jlNTjF9hqS7b9o+SlsZAsbSnIuWg=; b=Y+5oNYL6ANSLm4KPOhPOReVzgRvriTz+y8mHiLpMA+jxdpaxTOJXkmT8uSuqFU7SAd4srF2qUpnVMYp0LOYRjT+H1tHSb1m5qgIqLDFHIusQdDDT4AIZVb/f+DIePfsAaJAtDP7obJX5ltPPY1/KYUzgheDpMeGbXAt2psIGSOg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Mar 2011 22:58:59 -0000 Message-ID: <20110312225859.18195.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <4D7BF836.1090400@dougbarton.us> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 22:57:42 -0000 In article <4D7BF836.1090400@dougbarton.us> you write: >Kim, > >I'm looking at the remote participation schedule >(http://svsf40.icann.org/svsf40/remote-schedule) and I'm not seeing this >meeting on it. Hopefully that will change, and if it does can you let us >know? :) I think that there would be a tremendous benefit from having >an open door into how the ICANN community looks at this problem. Agreed. I can't be in S.F. this week, but I'd be happy to participate remotely. R's, John From dougb@dougbarton.us Sat Mar 12 15:05:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A49E3A6A15 for ; Sat, 12 Mar 2011 15:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6zkFswHwc+E for ; Sat, 12 Mar 2011 15:05:49 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id C57B33A69DA for ; Sat, 12 Mar 2011 15:05:48 -0800 (PST) Received: (qmail 29848 invoked by uid 399); 12 Mar 2011 23:07:04 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 12 Mar 2011 23:07:04 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D7BFC97.8050001@dougbarton.us> Date: Sat, 12 Mar 2011 15:07:03 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D77D2AF.7010203@abenaki.wabanaki.net> <4D77D6D8.9070609@dougbarton.us> <20110309201647.GJ32629@shinkuro.com> In-Reply-To: <20110309201647.GJ32629@shinkuro.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 23:05:50 -0000 On 03/09/2011 12:16, Andrew Sullivan wrote: > No hat. > > On Wed, Mar 09, 2011 at 11:36:56AM -0800, Doug Barton wrote: > >> Further, the term "variant" has a relatively well understood meaning in >> the TLD policy context, where it is generally understood to be a >> simplification of several thorny technical problems. > > I suspect I disagree with the above claim. Specifically, I think I > disagree with "well understood". Specifically, please read what you quoted above again. :) I stand by that statement. > In my experience, terms that have inherently ambiguous meaning are > almost never well understood. It is of course possible to understand > ambiguity -- we wouldn't the word if we couldn't -- but in a wide > array of cases, I think ambiguous terms are badly understood by their > users. I think that a lot of the ambiguity in _this group_ about the term "variants" derives from attempting to define it with a sort of technical rigorousness that people in ICANN do not use (or in many cases, desire). That said, I studiously avoided use of the word "variant" in my CLONE draft because I know that it causes confusion here. OTOH, if you were to sit down with people from the ICANN sphere, particularly those who are familiar with IDNs in the TLD context, you'd get a very consistent definition of the term "variant," whether you felt it was sufficiently technically precise or not. Thus my statement above. > I also believe that part of the reason we are struggling with the > aliasing discussion is exactly that very careful needs assessment is > extremely hard. It is made all the harder by the unfortunate re-use > of the term "Variant", which has a well-defined meaning in the context > of "Character Variant Table" from RFC 3743. Attempting to simplify > such thorny technical problems by lumping them all together under one > term seems like a good idea, but it turns out not to be. And I have argued in the past that while I'm fully supportive of defining requirements as rigorously as possible I think we may need to accept definitions of both "rigorous" and "possible" that may be "less" than what we're used to. OTOH I think that my experience dealing with the ICANN crowd gives me a pretty good understanding of the problems they are trying to solve, and I've already said that I think the new aliasing draft captures them pretty well. > It is often useful to bundle together a bunch of topics and call them > by a more generic name. (Patents and copyrights are vastly different > areas of the law, and yet it is sometimes useful to talk about > "intellectual property". Philosophers and English scholars can often > barely stand to be in the same room with each other, and yet they can > all be professors of the Humanities.) For the present discussion > about dealing with different labels (which happen to correspond to > particular bits of natural language that "mean the same" or something > like that), however, I think conflating these cases makes our task > much harder. It has caused no small degree of mischief in the TLD > policy arena, where in-principle solvable and necessarily unsolvable > problems are sometimes spoken of as though they were the same. If your goal is to get the ICANN community to stop using the term "variant" to refer to the problem that they know to be defined by the term, you're going to fail. It's far better to try and understand what they mean by "variant" and then try to figure out if we can provide a technical solution for it. > As perhaps the more technical end of an interchange with policy people > at an ICANN meeting, those of us who care about this topic could help > (in my opinion) a great deal just by teasing apart these ambiguities > and trying to ensure that every time a term is used, it is used > univocally. It might be painful, but in anticipation of the > conversation we plan to have in Prague, it will no doubt help > crystallize which issues are clear (so we can decide whether we know > what to do), and which issues we do not yet understand. I agree that teasing apart the ambiguities is a good goal, however I hold absolutely no hope that any of "us" are going to get any of "them" to modify their language. It's too well ingrained at this point. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From dougb@dougbarton.us Sat Mar 12 15:10:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1213A6A62 for ; Sat, 12 Mar 2011 15:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe9oCEDrz-5e for ; Sat, 12 Mar 2011 15:10:33 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 1C6A93A6A5B for ; Sat, 12 Mar 2011 15:10:33 -0800 (PST) Received: (qmail 1649 invoked by uid 399); 12 Mar 2011 23:11:50 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 12 Mar 2011 23:11:50 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D7BFDB5.5000907@dougbarton.us> Date: Sat, 12 Mar 2011 15:11:49 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Levine References: <20110309221355.45036.qmail@joyce.lan> In-Reply-To: <20110309221355.45036.qmail@joyce.lan> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 23:10:34 -0000 On 03/09/2011 14:13, John Levine wrote: >>> I suspect I disagree with the above claim. Specifically, I think I >>> disagree with "well understood". > > I think we understand our technical options pretty well, but not what > problem we're expected to solve. > > At ICANN you're likely to run into policy types who say (no doubt in > more words) "spare me the mumbo-jumbo, we just want {set of names} > to work the same." > > Once you're done gritting your teeth, this is an educational > opportunity to help people understand the large number of moving parts > that have to be synchonized to get the consistent user experience that > is probably the intutive idea of sameness ... or, it's an opportunity to ask the question, "What do you mean by 'work the same?'" :) My experience with the "policy types" at ICANN is that generally they are very smart people who are open to discussion about where the technical boundaries are. You just have to be ready for them to push back on why, and where those boundaries can be moved. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From johnl@iecc.com Sat Mar 12 15:37:49 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FC43A69DA for ; Sat, 12 Mar 2011 15:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.711 X-Spam-Level: X-Spam-Status: No, score=-110.711 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dymb65ioNyb for ; Sat, 12 Mar 2011 15:37:47 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 7736C3A6939 for ; Sat, 12 Mar 2011 15:37:47 -0800 (PST) Received: (qmail 17624 invoked from network); 12 Mar 2011 23:39:08 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 12 Mar 2011 23:39:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=6e58.4d7c041c.k1103; i=johnl@user.iecc.com; bh=u0kjli1CISWWgnjG1a3RwxyFxkhZUwQX44+s7ix+AvQ=; b=IZNmbjsFUxjRtEVh4Xw3IzyEhG+5Z/it6wuPzTHmfWKHw/WdxFtrgGisKCPNebowCRB8FAxvZYkkRTmnEr/5Mlr25FzLnHjwTKwd+Z2WWgAku9QjOBZwy6I+eZ+QO9XoyVqqMZ06Rn8UaV0+jW45lhtF3Ot9oVo+NBMT+eHaLrA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Mar 2011 23:39:07 -0000 Message-ID: <20110312233907.28247.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <4D7BFDB5.5000907@dougbarton.us> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 23:37:49 -0000 >... or, it's an opportunity to ask the question, "What do you mean by >'work the same?'" They may well not know. ("I mean the user should see the same thing.") That's why it could be useful to try and tease out what their intuition is, e.g., what appears in a browser and so forth. R's, John From dougb@dougbarton.us Sat Mar 12 16:17:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF97F3A6A63 for ; Sat, 12 Mar 2011 16:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3In-FJoAba7 for ; Sat, 12 Mar 2011 16:17:28 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 8C18B3A695B for ; Sat, 12 Mar 2011 16:17:28 -0800 (PST) Received: (qmail 19712 invoked by uid 399); 13 Mar 2011 00:18:48 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 13 Mar 2011 00:18:48 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D7C0D67.5000306@dougbarton.us> Date: Sat, 12 Mar 2011 16:18:47 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Levine References: <20110312233907.28247.qmail@joyce.lan> In-Reply-To: <20110312233907.28247.qmail@joyce.lan> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 00:17:29 -0000 On 03/12/2011 15:39, John Levine wrote: >> ... or, it's an opportunity to ask the question, "What do you mean by >> 'work the same?'" > > They may well not know. ("I mean the user should see the same > thing.") That's why it could be useful to try and tease out what > their intuition is, e.g., what appears in a browser and so forth. I think we're talking about more or less the same thing. My point is simply that "What do you mean by that?" is likely to get a better response than "Let me tell you why what you just said makes no sense at all." Obviously that's an extreme version, and I'm _not_ implying that this is how you personally would approach the situation. OTOH I have seen others from the technorati approach similar situations in just that manner, to the detriment of all concerned. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From kim.davies@icann.org Sat Mar 12 17:20:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192993A6A80 for ; Sat, 12 Mar 2011 17:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV+vOLS7VSKx for ; Sat, 12 Mar 2011 17:20:52 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id D7CA73A67B6 for ; Sat, 12 Mar 2011 17:20:52 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Sat, 12 Mar 2011 17:22:14 -0800 From: Kim Davies To: Doug Barton Date: Sat, 12 Mar 2011 17:22:12 -0800 Thread-Topic: [dnsext] BOF on variants for ICANN San Francisco Thread-Index: AcvhHRV6GrgFEfnDQzy5BrIyJ944aQ== Message-ID: <3B8574B9-C95B-491E-A074-7F3421C95347@icann.org> References: <4D7BF836.1090400@dougbarton.us> In-Reply-To: <4D7BF836.1090400@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3B8574B9C95B491EA0747F3421C95347icannorg_" MIME-Version: 1.0 Cc: Dennis Jennings , "dnsext@ietf.org" Subject: Re: [dnsext] BOF on variants for ICANN San Francisco X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 01:20:54 -0000 --_000_3B8574B9C95B491EA0747F3421C95347icannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Doug, On 12/03/2011, at 2:48 PM, Doug Barton wrote: I'm looking at the remote participation schedule (http://svsf40.icann.org/svsf40/remote-schedule) and I'm not seeing this meeting on it. Hopefully that will change, and if it does can you let us know? :) I think that there would be a tremendous benefit from having an open door into how the ICANN community looks at this problem. This particular meeting was just designed to be an informal meeting for any= one with an interest that is present. It was conceived after the agenda-set= ting cut-off, and does not have logistics support for remote participation.= Please consider this meeting only slightly more formal than everyone coale= scing in the bar, as another opportunity to make use of folks with a common= interest who happen to be in the same place at the same time. The official ICANN session on variants is on Wednesday and is on the agenda= , and as far as I know will be available remotely. I'd encourage participat= ion in that. Along with this request for remote participation, we've also received sugge= stions that there be a formal agenda, and this meeting be announced more wi= dely and gather broad participation from other groups. To quote a colleague= , "I don't think we should fall over ourselves at short notice to try and m= ake this into a general meeting - we'll fail and mess up!" If there is a need for a better organised meeting on the same topic then I = am sure that is something that can be arranged at a later date. And of cour= se there is the upcoming session in Prague. cheers, kim --_000_3B8574B9C95B491EA0747F3421C95347icannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Doug,

On 12/03/2011, at 2:48 PM, Doug Barton wrote:

<= /font>I'm looking at the remote participation schedule
(http://svsf40.icann.org/svsf40/= remote-schedule) and I'm not seeing this
meeting on it. Hopefully t= hat will change, and if it does can you let us
know? :)  I think t= hat there would be a tremendous benefit from having
an open door into h= ow the ICANN community looks at this problem.
<= br>
This particular meeting was just designed to be an informal m= eeting for anyone with an interest that is present. It was conceived after = the agenda-setting cut-off, and does not have logistics support for remote = participation. Please consider this meeting only slightly more formal = than everyone coalescing in the bar, as another opportunity to make us= e of folks with a common interest who happen to be in the same place at the= same time. 

The official ICANN session on va= riants is on Wednesday and is on the agenda, and as far as I know will be a= vailable remotely. I'd encourage participation in that.

=
Along with this request for remote participation, we've also rec= eived suggestions that there be a formal agenda, and this meeting be announ= ced more widely and gather broad participation from other groups. To quote = a colleague, "I don't think we should fall over ourselves at short notice t= o try and make this into a general meeting - we'll fail and mess up!"
=

If there is a need for a better organised meeting= on the same topic then I am sure that is something that can be arranged at= a later date. And of course there is the upcoming session in Prague.
=

cheers,

kim


= --_000_3B8574B9C95B491EA0747F3421C95347icannorg_-- From dougb@dougbarton.us Sat Mar 12 19:35:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4730C3A6AF7 for ; Sat, 12 Mar 2011 19:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2dlUomH3FC0 for ; Sat, 12 Mar 2011 19:35:07 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id BB8743A6AE6 for ; Sat, 12 Mar 2011 19:35:05 -0800 (PST) Received: (qmail 22490 invoked by uid 399); 13 Mar 2011 03:36:22 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 13 Mar 2011 03:36:22 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D7C3BB5.7090507@dougbarton.us> Date: Sat, 12 Mar 2011 19:36:21 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dnsext] One ICANN perspective on variants X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 03:35:10 -0000 This may be interesting: http://www.icann.org/en/topics/new-gtlds/idn-implementation-working-team-report-final-03dec09-en.pdf -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From brian.peter.dickson@gmail.com Sat Mar 12 20:04:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5BB93A67FC for ; Sat, 12 Mar 2011 20:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS-E1ElKiI9c for ; Sat, 12 Mar 2011 20:04:49 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 298EB3A6AC4 for ; Sat, 12 Mar 2011 20:04:49 -0800 (PST) Received: by fxm15 with SMTP id 15so2272285fxm.31 for ; Sat, 12 Mar 2011 20:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gm/zxE9jpMj12K+SVj8zfgRJSDy+ARU8GY8/Fm6+cwE=; b=m/7bk0qQtEZUCKwxdS3a5TJxdJ2dKMmeWDdfsS4CO3CzFTM+4vJMEWdonlUoarh7v4 1+SVYrFOuAEcExZlLGOQghts4tYHatVQeZ9HdBWSsHz3gWma8zwDk+tRIz2/fCLxHI0b r4SSZHKljQ5eRHM+3CE6XjcVfJKrEzBcuqhg0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SJNvO/iV6k3PsqLY6fHU100KKB1HVjjwvIv36+KjV16VzQLwei8OU7Xye1wmTajRsi V6agy1FLTn1ezV6CsZmOO/vgMjh2Km86Dbw/ppG77QMRCpCrkX51WtLpy6EPFumHIMGQ 6XMKKLWif23WbTSOOx0LY3YBNluQjikTTxLJc= MIME-Version: 1.0 Received: by 10.223.2.2 with SMTP id 2mr2205261fah.47.1299989170137; Sat, 12 Mar 2011 20:06:10 -0800 (PST) Received: by 10.223.38.24 with HTTP; Sat, 12 Mar 2011 20:06:10 -0800 (PST) In-Reply-To: <20110223114720.GA10740@bikeshed.isc.org> References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.isc.org> Date: Sun, 13 Mar 2011 00:06:10 -0400 Message-ID: From: Brian Dickson To: Suzanne Woolf Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 04:04:50 -0000 On Wed, Feb 23, 2011 at 7:47 AM, Suzanne Woolf wrote: > > Colleagues, > > Per the announcement to the list last night, the -00 of the "aliases" > problem statement has been posted to the i-d repository. > > Your comments are sought. It was pushed out this week to keep the > discussion here going. > > It's a working draft and obviously needs a number of refinements on > terminology and details, but the most important thing to establish at > this point is whether it gets the overall landscape right. > > I hope we will have a -01 ready before Prague, so we can have a strong > document by then and focus in the meeting on some decisions. > > > best, > Suzanne (Thank you, Suzanne, and all other commentators, authors of related drafts, and chairs for their diligence in getting this moved forward.) This is definitely a good starting place, and I'll try to limit my comments to proposed text for purposes of clarifying, adding analysis, and including another proposed solution. Comments follow below. Brian In Section 3.1, I think there would be benefit from addressing an operational issue that distinguishes "client-side" from "server-side" mechanisms, with xNAME being the former, and ZONE CLONE, CLONE, and DS2 being examples of the latter. Proposed text: 3.1.3 Aliased Zones Validation In configuring traditional DNS zones, there are a number of tools generally available for verifying that the authority server is configured properly, from both above and below the zone cut. These typically include a "config checker", a "zone checker", and a "delegation checker", which respectively ensure the metadata (causing the zone to load), the data (the zone itself), and the relational logic (delegation consistency and non-lameness) are correct (for some meaning of "correct"). Since the presumption in the requirements document is that there will be nontrivial numbers of "variant" zones, and zones with non-trivial numbers of "variants" themselves, consideration for which mechanism is used, and where, should be given to whether the mechanism supports such checking. For example, the xNAME solutions, as a general rule, do not inherently provide means for non-trivial verification that the "target" of the xNAME is valid. More precisely, that the target exists is something which can only be determined empirically, and that the target might cease to exist subsequent to the validation. And as a counter-example, DS2 (and possibly one or both CLONE proposals), being authority-server based solutions, necessarily include automatic verification of the correctness of the "variants", whenever the zone files or the server configuration files are modified (and applied). --- In section 4, additional text should draw attention to the consequences of particular solutions, in terms of their effectiveness in addressing scaling disparities introduced by the combination of DNSSEC and Variants. Proposed text (bullet point(s)/sub-bullet-points?): While DNSSEC is known already to produce modest additional requirements on DNS operators, the combination of DNSSEC and Variants together could potentially pose a significant cost, if care is not used in making solutions which scale well available. Poor scaling could be a barrier to entry in the use of DNSSEC for DNS users whose locale requires (literally, or figuratively) the use of Variants. --- In section 5, please also include reference to DS2. Proposed text (sentences, paragraphs, and/or new sections): (text modified to read) Names direction[BNAME], "Zone Clone", and "Zone Signature Re-Use [DS2]". (new section) 5.3 Zone Signature Re-Use The proposal of "Zone Signature Re-Use" or "DS2" (the new RRTYPE), is a DNSSEC enhancement for an existing, but underused, alternative solution for providing for "alias" behavior across zones. In this scheme, a new RRtype, DS2, is specified; it exists at a zone cut, and is used to define the "canonical signer" of the zone content so that records in the child zone are validated as if they were in the canonical signer's zone. This mechanism varies fundamentally from CNAME/DNAME/BNAME in that it uses a copy of (or alternatively, a link to) the original zone, reachable by the name specified at the zone cut(s), and signed by the "canonical signer name" of the associated DS2 RR. Its scope is the (variant) zone. Other than the DS2 itself, and the modification to validation of RRSIGs, the idea of using zone cuts, and re-using zone contents or entire zone files, while moderately novel, is already supported by the DNS specifications. Replacing CNAMEs and/or DNAMEs by zone cuts and having the children of both the original name (the target) and the new alias, be the exact same zone file, is something that works today. The entire zone content (RDATA) of the original zone and all the variants are the same, with only the prefix portion (the rightmost labels, or the zone owner name) on the owner names of the zone RRs differing. This extends to include DNSSEC RRTYPEs. The DS2 directs validators to use the "canonical signer name" in place of the "signer name" in the validation process. Since the "signer name" is ALWAYS the zone owner name, this is a 1:1 replacement which introduces no additional security issues per se, and the scope is precisely the child zone. The signer name of grand-children zones are specified either implicitly (via DS) or explicitly (via DS2), and thus do not inherit from the child (i.e. the grand-child's parent) zone's DS2 RR. Like "Zone Clone", this scheme has the advantage that it allows a DS2-signed zone to be used in all the same contexts as the canonical or underlying zone, including contexts where a CNAME or DNAME (or, presumably, a BNAME) cannot appear, such as in the RDATA of certain RRtypes. Of the proposed DNS protocol mechanisms, it probably comes closest to the behavior some have requested as "equivalence," where none of the bundled or SHADOW names is canonical or preferred over the others. The operator effort, and level of skill, are remarkably modest. The zone operator needs to configure the authority server to be authoritative for the variants. The zone signing process is unchanged (once the zone is signed by one of the variants). The registration of the DS in the parent zone(s) is replaced or augmented with the DS2, whose parameters are literal copies of the original DS value, with the addition of the primary variant name as the signer name in the DS2 record. (This is copy/paste level of difficulty.) There are operational benefits to DS2, in that the variants are implemented by means of a zone cut. The authority server explicitly has all variants configured, and thus the standard zone validation mechanisms are supported. The authority server has explicit knowledge of which variants exist on the parent side (unlike xNAME targets). The performance impact of adding variants to a DNSSEC-signed zone, in terms of RRSIG activity, is nil. Validators may optionally short-cut validation of variants RRSIGs, once one of a variants' RRSIGs has been validated - it can be re-used. Since there is no "chaining", compared to xNAME processing, there is no risk of excessive label counts, name lengths, or loops. The performance of all variants of a given number of labels/zones can expect to be comparable, with an upper bound on the time needed for resolution (if resolution succeeds). From dougb@dougbarton.us Sat Mar 12 23:36:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB373A6ADD for ; Sat, 12 Mar 2011 23:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFpuZqk+Z70Q for ; Sat, 12 Mar 2011 23:36:01 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 192803A68C0 for ; Sat, 12 Mar 2011 23:36:00 -0800 (PST) Received: (qmail 22799 invoked by uid 399); 13 Mar 2011 07:37:16 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 13 Mar 2011 07:37:16 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D7C742A.8030400@dougbarton.us> Date: Sat, 12 Mar 2011 23:37:14 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Suzanne Woolf References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.isc.org> In-Reply-To: <20110223114720.GA10740@bikeshed.isc.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------080000070504040609070501" Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 07:36:04 -0000 This is a multi-part message in MIME format. --------------080000070504040609070501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As promised here are my suggestions for various minor changes, plus language for the CLONE method, if you're so inclined. :) I realize that we're close to the deadline for -01 drafts (boy, do I realize it!) but here it is in any case. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------080000070504040609070501 Content-Type: text/plain; name="aliasing.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="aliasing.diff" --- draft-ietf-dnsext-aliasing-requirements-00.txt 2011-02-22 16:08:14.000000000 -0800 +++ draft-ietf-dnsext-aliasing-requirements-00-db.txt 2011-03-12 23:28:14.000000000 -0800 @@ -13,7 +13,7 @@ Abstract - This document attempts to describe a set of issues that arises from + This document attempts to describe a set of issues that arise from the desire to treat a set or group of names as "aliases" of each other, "bundled," "variants," or "the same," which is problematic in terms of corresponding behavior for DNS labels and FQDNs. @@ -23,8 +23,8 @@ having identical meaning may sometimes require corresponding behavior in the underlying infrastructure, possibly in the DNS itself. It's not clear how to accommodate this required behavior of such names in - DNS resolution; in particular, it's not clear when they are best - accommodated in registry practices for generating names for lookup in + DNS resolution. In particular, it's not clear where they are best + accommodated: In registry practices for generating names for lookup in the DNS, existing DNS protocol elements and behavior, existing application-layer mechanisms and practices, or some set of protocol elements or behavior not yet defined. This document attempts to @@ -172,7 +172,7 @@ 1. Introduction As the Internet and the DNS have evolved beyond their original realms - of use, a set of needs and expectations has appeared about how DNS + of use a set of needs and expectations has appeared about how DNS labels behave that is informed significantly by common human assumptions about how "names" or "words" work. One aspect of this is the notion or expectation that multiple sets of names may be similar @@ -190,10 +190,10 @@ zones. In some cases, these labels [RFC3743] are accompanied by the expectation that they are "equivalent" or should behave "the same," often because these labels are derived from names or strings that - users consider "the same" in some languages. Accordingly, Internet + users consider "the same." Accordingly, Internet users hope for such labels to behave in DNS contexts as they expect the corresponding human constructs to behave, regardless of the - specific service (smtp, http, etc.) involved.. + specific service (SMTP, HTTP, etc.) involved. The general issues of what "the same" means, or of defining "variants" in human scripts as codified in Unicode (or anywhere else) @@ -227,7 +227,7 @@ there are also administrative mechanisms available for manipulating databases underlying the generation and resolution of DNS names. - Registry operators have many mechanisms for working around DNS + Registry operators have many mechanisms for working around the DNS protocol in order to get behavior they want for names in DNS zones, and management of "aliases" is no exception. However, it is not clear how much of the user and operator requirements for "aliases" @@ -262,7 +262,7 @@ that might be undertaken. We also review existing constructs (CNAME, DNAME) and proposed new - ones ("BNAME," "zone clones") against the proposed requirements. + ones ("BNAME," "CLONE," "zone clones") against the proposed requirements. 1.2. What this document does not do @@ -354,7 +354,7 @@ A further question arises with respect to how applications should interact with alias-specific DNS behavior. A basic requirement would seem to be "First, do no harm," or in other words, any extensions to - DNS protocol in support of the desired "alias" behavior should not + the DNS protocol in support of the desired "alias" behavior should not interfere with applications that expect to do such interpretation on their own. This concern is based in the expectation that DNS is simple and predictable, operating strictly as infrastructure under @@ -366,8 +366,8 @@ how "variants" might behave as DNS names. It's generally conceded that recognition and careful management of cases where multiple names are associated together as "variants" in the expectation or - preference of users are important; without such management of grouped - domain names, security risks may be increased and the quality of user + preference of users is important. Without such management of grouped + domain names security risks may be increased and the quality of the user experience may be compromised. [RFC3743] developed by JET (Joint Engineering Team) gives one possible solution of how to manage registration of a domain name, intended to be applied to the script @@ -406,7 +406,7 @@ specify such "identical resolution" behavior:CNAME[RFC1034] which maps or redirects itself, and DNAME[RFC2672] which maps or redirects its descendants. In the case of bundles or groups of names, however, - some operators have asserted they need identical DNS resolution at + some operators have asserted that they need identical DNS resolution at all levels' domain names, including the domain name itself and its descendants. As alluded to above, registries are left with ad hoc provisioning and database management mechanisms for managing variant @@ -426,7 +426,7 @@ CJK language/script communities, is roughly this: One conceptual character can be identified with several different Code Points in character sets for computer use. In UNICODE definitions of some - scripts, including Han (chinese), some characters can be identified + scripts, including Han (Chinese), some characters can be identified as "compatibility variants" of another character, which usually implies that the first can be remapped to the second without the loss of any meaning. In this document, variant characters are two or more @@ -458,34 +458,31 @@ be possible to treat the original IDN TLD and its IDN TLD variant as "identical" for purposes of DNS resolution, in a way similar to the case mapping most DNS users take for granted, in which the uppercase - "A" is the variant of lowercase "a". For example, the string ".COM" + "A" is the variant of lowercase "a". By this definition, the string ".COM" can be considered a variant of ".com", and the corresponding DNS labels are treated as identical. However, for the historical reasons already discussed, and technical reasons having to do with the underpinnings of the IDNAbis protocol (ref: IDNAbis rationale), there's no generalization of the "case" mapping available for - situations where it might be useful for IDNs. In addition, it's - perilous because DNS rules around "case insensitivity" and "case - preservation" are not intuitively consistent; for example, case - folding is done for comparison but not for compression. + situations where it might be useful for IDNs. At this writing, four Han script IDN TLDs are in the root, including two pairs comprising a Traditional Chinese name and its Simplified counterpart. These operators will, in an ideal world, be able to share some operational experience around implementation of registry - policy regarding managing multiple DNS trees as "the same" + policy regarding managing multiple DNS trees as "the same." 2.3.2. An example: Greek - In Greek, almost every word has the "tonos" accent sign, but where it + In written Greek almost every word has the "tonos" accent sign, but where it is placed (on which character) can vary. Further, some words end in - a final sigma, which is represented differently to sigma appearing + a terminal sigma which is represented differently to sigma appearing elsewhere in the word. If a registry wishes to be able to enforce the association among all of the domain names that correspond to a "word" in Greek, with all its possible Unicode strings, some mechanism must be used to enumerate the "variant" names and tie them together. This makes sense from the human factors perspective, as - depending on how the user types something, results may include a + depending on how the user types something results may include a different domain to what was expected, although the user may have the firm belief that "the same word" was input in multiple cases. @@ -513,10 +510,10 @@ It's reasonable to pose the question at this point, without necessarily being able to answer it yet, of what is the ideal or - intended impact of solving the issue identified so far for registries - on applications and end users. Ultimately, simplifying the + intended impact of solving the issues identified so far for registries, + applications, and end users. Ultimately, simplifying the provisioning side may result in the same semantics as we have today - for zones maintained in parallel but for less work. However, we + for zones maintained in parallel but with less work. However, we later assert a proposed requirement that synthesizing the same record as a query would have obtained from an enumerated parallel tree isn't enough-- that the property of association or "sameness" we're @@ -547,7 +544,7 @@ 2. The desire for names on the Internet to act like words is often service-independent; users want to be able to use identical strings in the course of invoking multiple services that seem to - be related, such as going to a webpage and then sending email to + be related, such as going to a web page and then sending email to an address in "the same" domain (probably an FQDN). It's been noted that people are very comfortable with a certain amount of fuzziness about "alternative spellings" and assorted other @@ -596,7 +593,7 @@ The most obvious way to provision multiple names as "the same" is to delegate each separately, and then maintain the contents of the - delegated zones together, from the same backend database or by some + delegated zones together, from the same back end database or by some similar mechanism. This has the advantage of requiring no new technology; it can be done, and is done today, entirely with provisioning logic and registry policy. @@ -604,9 +601,9 @@ However, it doubles the work and the number of records required. If provisioning isn't done carefully, errors can arise, leaving inconsistencies. And provisioning multiple trees does nothing to - link the resulting names directly; there is no property of + link the resulting names directly. There is no property of "association" or isomorphism created in the DNS that corresponds to - user or application expectations for "sameness". There is no way to + user or application expectations for "sameness." There is no way to tell, from resolving a name in one tree, that it's part of a set or bundle of related names. @@ -634,8 +631,8 @@ the case of proposed mechanisms, we attempt to describe them below. Existing mechanisms besides the simple, straightforward provisioning - of zones that are identical except for the ownernames of - corresponding records include wildcards, CNAME, and DNAME. See + of zones that are identical except for the owner names of + corresponding records include wild cards, CNAME, and DNAME. See below, but here we note that they require special processing by the authority server in order to synthesize responses that are supposed to be the equivalent of simply providing the parallel zones by one- @@ -717,7 +714,7 @@ infrastructure protocol, for the long tail of deployment of significant protocol features. Again, a feature can be designed to be fairly easy to deploy, but without an incentive such as faster - application development or more secure applications, it stlil may not + application development or more secure applications, it still may not see wide uptake even after it's present in current code bases. @@ -759,6 +756,9 @@ operations, any change undertaken to lower the cost to providers may be useful, but should not simply shift costs to DNS users, whether applications or end users. + 6. A proposed mechanism MUST provide a way to signal whether or + not a label is a "variant," a "preferred" label, or not; and + if it is what the preferred label and all variant labels are. 5. Possible Solutions @@ -775,7 +775,7 @@ In addition, there are new proposals for DNS protocol to support "aliases" in the DNS as part of the desired behavior of "variant" - names: Names direction[BNAME], and "Zone clone". + names: Names direction[BNAME], CLONE, and "Zone clone". @@ -790,7 +790,7 @@ mechanism existing or proposed to support "aliases" in the DNS requires that one name be designated as the "canonical" name ("preferred" in the terminology of the JET variant mechanism) and any - others bundled with it are to be considered "variants" or "aliases". + others bundled with it are to be considered "variants" or "aliases." The only known way to enforce a symmetrical or equivalent association is via careful registry provisioning within and across domains. In addition, the different "alias" mechanisms differ in subtle ways that @@ -867,6 +867,31 @@ compatibility to avoid harm to implementations that expect, and use, the old behavior. +5.1.4. CLONE + +The CLONE method proposes 2 new RRtypes, CLONE and CLONES. The first is +designed to designate a given label as a CLONE of the preferred label. +On the authoritative server side a preferred label can have CLONEs both +within the zone, or as zone cuts. When an authoritative server receives +a query for a label that is a CLONE it will respond "as if" the query +had been for the preferred label. If the resolving name server sends the +EDNS option that indicates it is CLONE-Aware the authoritative server +will also send the CLONE RR which will allow the resolver to send future +queries for the preferred label. This method allows the resolving name +sever to validate DNSSEC signatures for the CLONE "as if" it had been +the preferred label that had been queried for. With the addition of +dynamic DNSSEC signing in the authoritative name server all benefits +of the CLONE method can be derived simply from updating authoritative +servers. The CLONES RRtype can be used to determine whether a given +name is a CLONE, a preferred label, and what the other CLONE labels are. + +The advantages of the CLONE method include the flexibility to use it +both as a zone cut, and within a zone. It also provides the option of +full DNSSEC support without requiring updates to the massive installed +base of resolving name servers. By not requiring copies of the preferred +label/zone it reduces resources necessary for implementation on the +authoritative server. + 5.2. Zone Clone The proposal of "zone clone" or "dns shadow", is an alternative --------------080000070504040609070501-- From dougb@dougbarton.us Mon Mar 14 00:53:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0133C3A693D for ; Mon, 14 Mar 2011 00:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWl8uDLMDu33 for ; Mon, 14 Mar 2011 00:53:04 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id DB17B3A68E9 for ; Mon, 14 Mar 2011 00:53:03 -0700 (PDT) Received: (qmail 20639 invoked by uid 399); 14 Mar 2011 07:54:23 -0000 Received: from router.ka9q.net (HELO ?192.168.2.9?) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 14 Mar 2011 07:54:23 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D7DC9B0.1060202@dougbarton.us> Date: Mon, 14 Mar 2011 00:54:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dnsext] Fwd: New Version Notification for draft-barton-clone-dns-labels-fun-profit-01 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 07:53:05 -0000 http://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit I think this version greatly clarifies how CLONE can provide DNSSEC, including the addition of dynamic signing. Enjoy, Doug -------- Original Message -------- Subject: New Version Notification for draft-barton-clone-dns-labels-fun-profit-01 Date: Mon, 14 Mar 2011 00:45:11 -0700 (PDT) From: IETF I-D Submission Tool To: dougb@dougbarton.us A new version of I-D, draft-barton-clone-dns-labels-fun-profit-01.txt has been successfully submitted by Douglas Barton and posted to the IETF repository. Filename: draft-barton-clone-dns-labels-fun-profit Revision: 01 Title: Cloning Domain Name System (DNS) Labels for Fun and Profit Creation_date: 2011-03-14 WG ID: Independent Submission Number_of_pages: 13 Abstract: This document describes a method for making one or more Domain Name System (DNS) labels behave in the DNS "as if" they were actually an entirely different label. E.g., the delegee for the example.org zone could define bar.example.org to be a CLONE of foo.example.org. This method is designed to meet the needs of those managing Internationalized Domain Name (IDN) zones that have been determined to be semantically similar, and therefore should be treated "as if" they were identical. This method can also be used more generally to handle situations where either CNAME or DNAME Resource Records are currently being used. A key design goal for the CLONE method is that all of the semantic benefits are available by updating only the authoritative servers for the zone. Domain managers who want to support DNSSEC for the CLONEd labels/zones may do so with dynamic signing of the CLONEs, or rely on users being behind a CLONE-Aware resolving name server. Foreword [RFC Editor, please remove this Section at publication time. Thanks.] This is my first draft, please be gentle. :) I'm definitely open to the possibility that there are better ways to accomplish the concepts presented herein. I'm sure that there are a non-zero number of errors in the formatting, references, etc. Also Sections 2 and 3 may be under-specified, unclear, or unworkable. So please don't be afraid to offer (constructive) criticism. TODO: Update/add/improve references? Add/improve examples? Revision History: 1. -00 Initial version 2. -01 Minor textual edits, add support for dynamic signing, clarify CLONE labels that are not zone cuts The IETF Secretariat. From weiler@watson.org Mon Mar 14 06:09:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A043A6D35 for ; Mon, 14 Mar 2011 06:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+PdgyQyMg19 for ; Mon, 14 Mar 2011 06:09:04 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id C4FA23A6D18 for ; Mon, 14 Mar 2011 06:09:04 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p2EDAROm045067; Mon, 14 Mar 2011 09:10:27 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p2EDARnP045064; Mon, 14 Mar 2011 09:10:27 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 14 Mar 2011 09:10:27 -0400 (EDT) From: Samuel Weiler To: Matthijs Mekking In-Reply-To: <4D79DDFA.3010006@nlnetlabs.nl> Message-ID: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 14 Mar 2011 09:10:27 -0400 (EDT) Cc: dnsext@ietf.org Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:09:05 -0000 Thank you very much! > I think the general consensus is that a validator should at least be > able to check the algorithms in the DS RRset (Please correct me if I am > being to hasty in my conclusion). There is still debate whether the > validator SHOULD or MAY do this (Ed Lewis argued the term 'could', I > think that translates to the RFC2119 term MAY). ... > Proposed text would then be: > > "The validator SHOULD or MAY check (choice here) that the algorithms > signaled in the DS-set work (but only for algorithms supported by > the validator, of course)." I understand the desire for MAY check all algorithms, and I'm fine with that. (I tend to agree with Ed on SHOULD NOT, but whatever.) I do not yet understand the reason for looking only at the DS RRset and not also the DNSKEY RRset, and I'd very much like to. If we tell validators to that the DNSKEY RRset isn't being used for signalling, then presumably we're also changing what it means to be a "properly signed zone". What's the new definition? And why that change? -- Sam From Ed.Lewis@neustar.biz Mon Mar 14 06:40:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41EC23A6D18 for ; Mon, 14 Mar 2011 06:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAcFs5L5CvsQ for ; Mon, 14 Mar 2011 06:40:30 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 4A7A33A6958 for ; Mon, 14 Mar 2011 06:40:30 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2EDflig020866; Mon, 14 Mar 2011 09:41:47 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.110] by Work-Laptop-2.local (PGP Universal service); Mon, 14 Mar 2011 09:41:53 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 14 Mar 2011 09:41:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> Date: Mon, 14 Mar 2011 09:41:41 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:40:31 -0000 At 9:10 -0400 3/14/11, Samuel Weiler wrote: >then presumably we're also changing what it means to be a "properly signed >zone". What's the new definition? And why that change? Although Sam wrote this, I'm not assuming this is his opinion. To a validator, whether or not a zone is properly signed should be immaterial. A validator's concern is whether a set of data is properly authenticated. The switch from "signed" to "authenticated" is on purpose, yet subtle. The reason I switched is to switch from a voice of "supply side" to "demand side." As a supply side'r, I'm concerned with how something is accomplished. Signing is one basic unit in DNSSEC. And making sure the zone is properly signed is my goal. "Properly" is relative to the specifications, the role of the specs is to set up expectations on the other side. As a demand side'r, I'm concerned with what has been done. Authenticating the data is what I am achieving. Authenticating involves first setting the expectation of whether I get the data I need (the RRSIG) and then seeing if the expectation is met. What I am cautioning against is the degree to which a demand side'r goes to determine expectations. A paranoid demand side'r almost looks for excuses to declare data unauthentic, and that's bad. A lazy demand side'r avoids looking as much as possible, and that's just as bad. A happy medium is needed. A happy medium to me is one where the focus is goal-oriented. If the data has a valid signature and I can use a chain of keys up to a trusted anchor, then I declare victory. There's no security problem with that. So, when it comes to validation, we should not even have a definition of "properly signed zone." That is in the domain of the signer. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From brian.peter.dickson@gmail.com Mon Mar 14 08:08:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C863A6DAC for ; Mon, 14 Mar 2011 08:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHcg1fQhBLhM for ; Mon, 14 Mar 2011 08:08:35 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id AA4353A6DCC for ; Mon, 14 Mar 2011 08:08:34 -0700 (PDT) Received: by fxm15 with SMTP id 15so3307928fxm.31 for ; Mon, 14 Mar 2011 08:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f6JhGPzwAhphehx4wkv2Sqyynso6BtTI2iD6k4e6sd0=; b=TbXOSwiaPZzvMu/wV/OPhhhD05MSJBYz3uUf6lBOq0yv+Qs/cFOmfxUxfEapdVUbm7 C+83+d9U2q1zFOBcK+B8fNFt4+zg+gqYjSHyUvx76X5rR6GKzM/X5VN6fDII6/Qqgsds nGoqMtrbrfYfRGMdUOzzbzsMYhhmMwe2vo6Sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Bd0KWtL3OM4bLDSEYpGX1zXSTmn7Rr01flf3YOHAlZSWJ8pTfvcZS/0d3WH9v47DYV ikyQzUntXvICG7dYApdG12XpziWXAwDacOkNH6utskE0sGpg6DK2K7FWE3n80oeLxjVn iBOR2yLIYmvS62tpj2cqGU+PB3fSxnBc8NfpI= MIME-Version: 1.0 Received: by 10.223.87.75 with SMTP id v11mr7790882fal.28.1300115367407; Mon, 14 Mar 2011 08:09:27 -0700 (PDT) Received: by 10.223.38.24 with HTTP; Mon, 14 Mar 2011 08:09:27 -0700 (PDT) In-Reply-To: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> Date: Mon, 14 Mar 2011 12:09:27 -0300 Message-ID: From: Brian Dickson To: Edward Lewis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:08:38 -0000 On Mon, Mar 14, 2011 at 10:41 AM, Edward Lewis wrote= : > At 9:10 -0400 3/14/11, Samuel Weiler wrote: > >> then presumably we're also changing what it means to be a "properly sign= ed >> zone". =A0What's the new definition? =A0And why that change? > > Although Sam wrote this, I'm not assuming this is his opinion. > > To a validator, whether or not a zone is properly signed should be > immaterial. =A0A validator's concern is whether a set of data is properly > authenticated. > > The switch from "signed" to "authenticated" is on purpose, yet subtle. = =A0The > reason I switched is to switch from a voice of "supply side" to "demand > side." > > As a supply side'r, I'm concerned with how something is accomplished. > Signing is one basic unit in DNSSEC. =A0And making sure the zone is prope= rly > signed is my goal. =A0"Properly" is relative to the specifications, the r= ole > of the specs is to set up expectations on the other side. > > As a demand side'r, I'm concerned with what has been done. Authenticating > the data is what I am achieving. =A0Authenticating involves first setting= the > expectation of whether I get the data I need (the RRSIG) and then seeing = if > the expectation is met. > > What I am cautioning against is the degree to which a demand side'r goes = to > determine expectations. =A0A paranoid demand side'r almost looks for excu= ses > to declare data unauthentic, and that's bad. =A0A lazy demand side'r avoi= ds > looking as much as possible, and that's just as bad. =A0A happy medium is > needed. > > A happy medium to me is one where the focus is goal-oriented. =A0If the d= ata > has a valid signature and I can use a chain of keys up to a trusted ancho= r, > then I declare victory. =A0There's no security problem with that. > > So, when it comes to validation, we should not even have a definition of > "properly signed zone." =A0That is in the domain of the signer. While technically correct, I think there is a holistic concern. All who use DNSSEC, have a vested interest in ensuring that it is, on the whole, as secure as possible. One facet of this is, maximizing the risk of detection of both successful attacks, and unsuccessful attacks, on the validation side. Observation The beauty of DNSSEC is, the data is secured (protected by crypto signatures), so the particular source of the data (direct from authority servers, or indirect from arbitrary caches) is irrelevant, and so the transport doesn't need to be protected. This already presumes that the data source (i.e. whatever server answers a query, e.g. iterative resolver) isn't trusted per se. The presumption has to be, that answers may be modified or replaced, somehow, by someone, and that we are protecting ourselves from trusting those modified/replaced answers by the protections afforded by DNSSEC. The basic problem is, a validator cannot distinguish between incorrectly signed data (where not all the promised algorithms have been used, "promised" =3D=3D present in the DS), and answers which have been selectively modified by an attacker. An attacker can either strip all but one signature, and replace that signature with a forged signature, which matches the forged data; or the attacker can leave now-invalid signatures along with the forged signature and forged data. The first level of defense, the most trivial, is the downgrade prevention. There needs to be a proof of an answer being from an insecure zone, before we believe an answer which has no RRSIG. The second level of defense, the one which is not universally agreed as necessary, is the protection against a limited substitution with a single forged signature. This is where the holistic approach may be a good compromise between the believers and unbelievers (of the risk of such a signature ever being possible): (The following presumes more than one algorithm is in use, and thus, that one or more algorithms now no longer has a valid signature.) If the validation process is driven by the processing of RRSIGs, and only indirectly checks algorithms, the first form of substitution will go unnoticed. IMHO, this is unwise. If the validation process is driven by first determining the algorithms, and then checking signatures, the first form of substitution will be detected. (See below for "what to do".) In both cases, the second form of substitution *may* be detected, depending on which RRSIG is checked first, and/or whether all algorithms need to have an RRSIG successfully validated. (Also see "what to do".) Randomizing among the algorithms in the intersection set of "known by the validator" and "present in the DS RRSET", ensures the probability of detection is non-zero. Non-zero detection is the goal -- noticing that something is up, either because of an erroneous zone signing, or because of an attack. What To Do This is a question balancing the issue of false positives, with true positives. The choices are, report "bogus", and log, or report "valid" but log. For sure, logging on the validator is practically mandatory, or at least should be supported by implementers. Alerting back to the authority server operator may or may not be appropriate to automate. Logging by stub resolvers is not likely to be useful. IMHO, the best choices are: randomize on algorithms, validate but log, and have validator operators support folks (where appropriate) investigate issues as they arise. It is probably too early to know the rate of false positives, but that is something that operators should likely be tracking. The main thing is, to be able to assure would-be attackers that *someone* will notice if/when they decide to try, and that that should hopefully be enough of a deterrent to provide value to the whole of the consumers of DNSSEC to justify its use. Brian From Ed.Lewis@neustar.biz Mon Mar 14 12:12:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118463A6E06 for ; Mon, 14 Mar 2011 12:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP61LuLz923h for ; Mon, 14 Mar 2011 12:12:03 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D5E933A6B5A for ; Mon, 14 Mar 2011 12:12:02 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2EJDJe2024300; Mon, 14 Mar 2011 15:13:19 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.110] by Work-Laptop-2.local (PGP Universal service); Mon, 14 Mar 2011 15:13:26 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 14 Mar 2011 15:13:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> Date: Mon, 14 Mar 2011 15:13:07 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:12:04 -0000 At 12:09 -0300 3/14/11, Brian Dickson wrote: >While technically correct, I think there is a holistic concern. > >All who use DNSSEC, have a vested interest in ensuring that it is, on >the whole, as secure as possible. The goal is not "as secure as possible." Begin with DNS as it was defined before DNSSEC. It emphasized speed, reliability, and most importantly scaleable management. DNSSEC came along to address the architectural vulnerability of the need for caches. DNSSEC's target was to lower the gullable nature of the architecture while having as little impact on the original DNS as possible. Security is never the end goal. It is a means to an end. The end, in the DNS service model, is the delivery of the answer given a question. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From marka@isc.org Mon Mar 14 14:32:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241DC3A6F40 for ; Mon, 14 Mar 2011 14:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrBeGsgP343N for ; Mon, 14 Mar 2011 14:32:27 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 1F8233A6BB9 for ; Mon, 14 Mar 2011 14:32:17 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id F2EB75F9863; Mon, 14 Mar 2011 21:33:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 ADEA5216C22; Mon, 14 Mar 2011 21:33:22 +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 A2799C8CA0B; Tue, 15 Mar 2011 08:33:19 +1100 (EST) To: Samuel Weiler From: Mark Andrews References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> In-reply-to: Your message of "Mon, 14 Mar 2011 09:10:27 EDT." Date: Tue, 15 Mar 2011 08:33:19 +1100 Message-Id: <20110314213319.A2799C8CA0B@drugs.dv.isc.org> Cc: dnsext@ietf.org, Matthijs Mekking Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:32:28 -0000 In message , Samuel Wei ler writes: > Thank you very much! > > > I think the general consensus is that a validator should at least be > > able to check the algorithms in the DS RRset (Please correct me if I am > > being to hasty in my conclusion). There is still debate whether the > > validator SHOULD or MAY do this (Ed Lewis argued the term 'could', I > > think that translates to the RFC2119 term MAY). > ... > > Proposed text would then be: > > > > "The validator SHOULD or MAY check (choice here) that the algorithms > > signaled in the DS-set work (but only for algorithms supported by > > the validator, of course)." > > I understand the desire for MAY check all algorithms, and I'm fine > with that. (I tend to agree with Ed on SHOULD NOT, but > whatever.) > > I do not yet understand the reason for looking only at the DS RRset > and not also the DNSKEY RRset, and I'd very much like to. The rule was put in there to ensure that a signer generated a zone which had the information required for the validator to validate the records in the zone. > If we tell validators to that the DNSKEY RRset isn't being used for > signalling, then presumably we're also changing what it means to be a > "properly signed zone". What's the new definition? And why that > change? > > -- Sam > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From weiler@watson.org Mon Mar 14 14:50:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9743A6F6F for ; Mon, 14 Mar 2011 14:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYMv5bYVIDsZ for ; Mon, 14 Mar 2011 14:50:10 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id C71783A6F75 for ; Mon, 14 Mar 2011 14:50:05 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p2ELpT1j076263; Mon, 14 Mar 2011 17:51:29 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p2ELpTVx076260; Mon, 14 Mar 2011 17:51:29 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 14 Mar 2011 17:51:29 -0400 (EDT) From: Samuel Weiler To: Mark Andrews In-Reply-To: <20110314213319.A2799C8CA0B@drugs.dv.isc.org> Message-ID: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 14 Mar 2011 17:51:29 -0400 (EDT) Cc: dnsext@ietf.org, Matthijs Mekking Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:50:12 -0000 >> I do not yet understand the reason for looking only at the DS RRset >> and not also the DNSKEY RRset, and I'd very much like to. > > The rule was put in there to ensure that a signer generated a zone > which had the information required for the validator to validate > the records in the zone. I'm lost. Try again? Use more words and fewer pronouns. :-) -- Sam From Internet-Drafts@ietf.org Mon Mar 14 15:15:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90AC43A6B24; Mon, 14 Mar 2011 15:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96fSNr8rJiBj; Mon, 14 Mar 2011 15:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2223A6BC2; Mon, 14 Mar 2011 15:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314221502.9641.83886.idtracker@localhost> Date: Mon, 14 Mar 2011 15:15:02 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-01.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 22:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Problem Statement: DNS Resolution of Aliased Names Author(s) : S. Woolf, et al. Filename : draft-ietf-dnsext-aliasing-requirements-01.txt Pages : 22 Date : 2011-03-14 This document attempts to describe a set of issues that arises from the desire to treat a set or group of names as "aliases" of each other, "bundled," "variants," or "the same," which is problematic in terms of corresponding behavior for DNS labels and FQDNs. With the emergence of internationalized domain names, among other potential use cases, two or more names that users will regard as having identical meaning may sometimes require corresponding behavior in the underlying infrastructure, possibly in the DNS itself. It's not clear how to accommodate this required behavior of such names in DNS resolution; in particular, it's not clear when they are best accommodated in registry practices for generating names for lookup in the DNS, existing DNS protocol elements and behavior, existing application-layer mechanisms and practices, or some set of protocol elements or behavior not yet defined. This document attempts to describe some of these cases and the behavior of some of the possible solutions discussed to date. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aliasing-requirements-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-aliasing-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14150603.I-D@ietf.org> --NextPart-- From marka@isc.org Mon Mar 14 16:18:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642EA3A6EF3 for ; Mon, 14 Mar 2011 16:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4m-Pp9OQDrp for ; Mon, 14 Mar 2011 16:18:41 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id DCA0F3A6B8B for ; Mon, 14 Mar 2011 16:18:40 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7684C5F985D; Mon, 14 Mar 2011 23:19:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 44251216C1E; Mon, 14 Mar 2011 23:19:47 +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 57DA6C8D90F; Tue, 15 Mar 2011 10:19:45 +1100 (EST) To: Brian Dickson From: Mark Andrews References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> In-reply-to: Your message of "Mon, 14 Mar 2011 12:09:27 -0300." Date: Tue, 15 Mar 2011 10:19:45 +1100 Message-Id: <20110314231945.57DA6C8D90F@drugs.dv.isc.org> Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:18:42 -0000 In message , Bri an Dickson writes: > On Mon, Mar 14, 2011 at 10:41 AM, Edward Lewis wrote: > > At 9:10 -0400 3/14/11, Samuel Weiler wrote: > > > >> then presumably we're also changing what it means to be a "properly sign= > ed > >> zone". =A0What's the new definition? =A0And why that change? > > > > Although Sam wrote this, I'm not assuming this is his opinion. > > > > To a validator, whether or not a zone is properly signed should be > > immaterial. =A0A validator's concern is whether a set of data is properly > > authenticated. > > > > The switch from "signed" to "authenticated" is on purpose, yet subtle. = > =A0The > > reason I switched is to switch from a voice of "supply side" to "demand > > side." > > > > As a supply side'r, I'm concerned with how something is accomplished. > > Signing is one basic unit in DNSSEC. =A0And making sure the zone is prope= > rly > > signed is my goal. =A0"Properly" is relative to the specifications, the r= > ole > > of the specs is to set up expectations on the other side. > > > > As a demand side'r, I'm concerned with what has been done. Authenticating > > the data is what I am achieving. =A0Authenticating involves first setting= > the > > expectation of whether I get the data I need (the RRSIG) and then seeing = > if > > the expectation is met. > > > > What I am cautioning against is the degree to which a demand side'r goes = > to > > determine expectations. =A0A paranoid demand side'r almost looks for excu= > ses > > to declare data unauthentic, and that's bad. =A0A lazy demand side'r avoi= > ds > > looking as much as possible, and that's just as bad. =A0A happy medium is > > needed. > > > > A happy medium to me is one where the focus is goal-oriented. =A0If the d= > ata > > has a valid signature and I can use a chain of keys up to a trusted ancho= > r, > > then I declare victory. =A0There's no security problem with that. > > > > So, when it comes to validation, we should not even have a definition of > > "properly signed zone." =A0That is in the domain of the signer. > > While technically correct, I think there is a holistic concern. > > All who use DNSSEC, have a vested interest in ensuring that it is, on > the whole, as secure as possible. There is secure as possible and to strict. > One facet of this is, maximizing the risk of detection of both > successful attacks, and unsuccessful attacks, on the validation side. > > Observation The beauty of DNSSEC is, the data is secured (protected by > crypto signatures), so the particular source of the data (direct from > authority servers, or indirect from arbitrary caches) is irrelevant, > and so the transport doesn't need to be protected. This already > presumes that the data source (i.e. whatever server answers a query, > e.g. iterative resolver) isn't trusted per se. The presumption has to > be, that answers may be modified or replaced, somehow, by someone, and > that we are protecting ourselves from trusting those modified/replaced > answers by the protections afforded by DNSSEC. The basic problem is, a > validator cannot distinguish between incorrectly signed data (where > not all the promised algorithms have been used, "promised" =3D=3D present > in the DS), and answers which have been selectively modified by an > attacker. > > An attacker can either strip all but one signature, and replace that > signature with a forged signature, which matches the forged data; or > the attacker can leave now-invalid signatures along with the forged > signature and forged data. Which requires the zone to be signed with a incredibly weak key or the private key to be compromised. > The first level of defense, the most trivial, is the downgrade > prevention. There needs to be a proof of an answer being from an > insecure zone, before we believe an answer which has no RRSIG. Which the validators all do. > The second level of defense, the one which is not universally agreed > as necessary, is the protection against a limited substitution with a > single forged signature. Which provably cannot be done with seperate DNSKEY and DATA lookups. The only way to achieve that reliably is to return the DNSKEY RRset along with every DATA lookup and cache the combined answer so that the correct DNSKEY RRset can be returned with the DATA. > This is where the holistic approach may be a good compromise between > the believers and unbelievers (of the risk of such a signature ever > being possible): > > (The following presumes more than one algorithm is in use, and thus, > that one or more algorithms now no longer has a valid signature.) > > If the validation process is driven by the processing of RRSIGs, and > only indirectly checks algorithms, the first form of substitution will > go unnoticed. IMHO, this is unwise. > > If the validation process is driven by first determining the > algorithms, and then checking signatures, the first form of > substitution will be detected. (See below for "what to do".) > > In both cases, the second form of substitution *may* be detected, > depending on which RRSIG is checked first, and/or whether all > algorithms need to have an RRSIG successfully validated. (Also see > "what to do".) > > Randomizing among the algorithms in the intersection set of "known by > the validator" and "present in the DS RRSET", ensures the probability > of detection is non-zero. > > Non-zero detection is the goal -- noticing that something is up, > either because of an erroneous zone signing, or because of an attack. > > What To Do > > This is a question balancing the issue of false positives, with true > positives. The choices are, report "bogus", and log, or report "valid" > but log. > > For sure, logging on the validator is practically mandatory, or at > least should be supported by implementers. Alerting back to the > authority server operator may or may not be appropriate to automate. > > Logging by stub resolvers is not likely to be useful. > > IMHO, the best choices are: randomize on algorithms, validate but log, > and have validator operators support folks (where appropriate) > investigate issues as they arise. It is probably too early to know the > rate of false positives, but that is something that operators should > likely be tracking. > > The main thing is, to be able to assure would-be attackers that > *someone* will notice if/when they decide to try, and that that should > hopefully be enough of a deterrent to provide value to the whole of > the consumers of DNSSEC to justify its use. > > Brian > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ed.Lewis@neustar.biz Tue Mar 15 05:44:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB9B3A6D10 for ; Tue, 15 Mar 2011 05:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T314AmbtfOr for ; Tue, 15 Mar 2011 05:44:29 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id F25613A6BC3 for ; Tue, 15 Mar 2011 05:44:28 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2FCjijR033192; Tue, 15 Mar 2011 08:45:46 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.110] by Work-Laptop-2.local (PGP Universal service); Tue, 15 Mar 2011 08:45:52 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 15 Mar 2011 08:45:52 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> Date: Tue, 15 Mar 2011 08:45:42 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 12:44:30 -0000 At 17:51 -0400 3/14/11, Samuel Weiler wrote: >>> I do not yet understand the reason for looking only at the DS RRset >>> and not also the DNSKEY RRset, and I'd very much like to. >> >> The rule was put in there to ensure that a signer generated a zone >> which had the information required for the validator to validate >> the records in the zone. > >I'm lost. Try again? Use more words and fewer pronouns. :-) I'll take a stab at it. The specification requires the generation of a signature of each algorithm in the DS record to set the expectation of the validator (remote end). The expectation is that if the DS record set indicates that algorithm X is in use, there will be a signature of algorithm X to be had. If this expectation is not met, then the validator is to declare a protocol failure. The assumption is that, while matching down the tree (in this case zone by zone, not necessarily label by label), a validator is assessing whether there is a secure chain from a trust anchor point towards the target. (In reality, this direction is in use only if there was no signature received. If there was a signature, only the chain back is examined, no need to judge the algorithms.) If for zone X there is a secure chain and the delegation to zone Y indicates there is a chain via an algorithm the validator understands, then there is the possibility of the chain extending across to Y. If no algorithm in the DS set is understandable to the validator, or there is no DS set at all, then there is no expectation of a useable signature in Y, thus zone Y can be treated as unsigned. By contradiction, let's say there was no specification of a signature per algorithm at each set. In this case, the signer could sign half the set with one alorithm and the other half with a second. If the validator only understands one of the two algorithms, a missing signature could be either a case of stripped data or a case or omission in the signing process. Distinction between the two cases would be "undecidable." ... So, we have to set a concrete expectation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From casey@deccio.net Wed Mar 16 11:17:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4E13A6A33 for ; Wed, 16 Mar 2011 11:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+vLJpAsAJX5 for ; Wed, 16 Mar 2011 11:17:01 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id C88023A6A27 for ; Wed, 16 Mar 2011 11:17:00 -0700 (PDT) Received: by qyk7 with SMTP id 7so1649993qyk.10 for ; Wed, 16 Mar 2011 11:18:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.18.9 with SMTP id u9mr347716qaa.126.1300299506839; Wed, 16 Mar 2011 11:18:26 -0700 (PDT) Received: by 10.229.227.203 with HTTP; Wed, 16 Mar 2011 11:18:26 -0700 (PDT) In-Reply-To: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> Date: Wed, 16 Mar 2011 11:18:26 -0700 Message-ID: From: Casey Deccio To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=bcaec51a870e34f06a049e9d9266 Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 18:17:01 -0000 --bcaec51a870e34f06a049e9d9266 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 15, 2011 at 5:45 AM, Edward Lewis wrote: > The specification requires the generation of a signature of each algorithm > in the DS record to set the expectation of the validator (remote end). The > expectation is that if the DS record set indicates that algorithm X is in > use, there will be a signature of algorithm X to be had. If this > expectation is not met, then the validator is to declare a protocol failure. > > For further clarification... It seems like you are favorable towards the validator verifying an RRSIG for every algorithm (which it understands, of course) that exists in the DS RRset. Is this verification just for the RRSIGs made by SEP (i.e., corresponding to DS RRs) DNSKEYs covering the DNSKEY RRset, or for any arbitrary RRSIG in the zone? If the former, once you have authenticated the DNSKEY RRset (with all the algorithms in the DS), then an RRSIG may be verified by any DNSKEY in the DNSKEY RRset, regardless of algorithm; if the latter, then the algorithms must play a part in validating any RRset in the zone. The former seems more reasonable to me. It seems like perhaps your view has changed from SHOULD NOT to SHOULD in one of these regards? In either case, I think that a bit more wording should be added to the proposed text to make it clear what is expected of the the validator, in terms of which RRSIG to check algorithms for, depending on what consensus is. Casey --bcaec51a870e34f06a049e9d9266 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 15, 2011 at 5:45 AM, Edward Lewis <Ed.Lewis@neustar.biz> wrote:=
The specification requires the generation of a signature of each algorithm = in the DS record to set the expectation of the validator (remote end). =A0T= he expectation is that if the DS record set indicates that algorithm X is i= n use, there will be a signature of algorithm X to be had. =A0If this expec= tation is not met, then the validator is to declare a protocol failure.


For further clarification...=A0 It seems like you= are favorable towards the validator verifying an RRSIG for every algorithm= (which it understands, of course) that exists in the DS RRset.=A0 Is this = verification just for the RRSIGs made by SEP (i.e., corresponding to DS RRs= ) DNSKEYs covering the DNSKEY RRset, or for any arbitrary RRSIG in the zone= ?=A0 If the former, once you have authenticated the DNSKEY RRset (with all = the algorithms in the DS), then an RRSIG may be verified by any DNSKEY in t= he DNSKEY RRset, regardless of algorithm; if the latter, then the algorithm= s must play a part in validating any RRset in the zone.=A0 The former seems= more reasonable to me.=A0 It seems like perhaps your view has changed from= SHOULD NOT to SHOULD in one of these regards?

In either case, I think that a bit more wording should be added to the = proposed text to make it clear what is expected of the the validator, in te= rms of which RRSIG to check algorithms for, depending on what consensus is.=

Casey
--bcaec51a870e34f06a049e9d9266-- From Ed.Lewis@neustar.biz Thu Mar 17 06:22:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E353A68AD for ; Thu, 17 Mar 2011 06:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofndT-TcSDeu for ; Thu, 17 Mar 2011 06:22:10 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 544BE3A695E for ; Thu, 17 Mar 2011 06:22:09 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2HDNRKY051678; Thu, 17 Mar 2011 09:23:28 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.117] by Work-Laptop-2.local (PGP Universal service); Thu, 17 Mar 2011 09:23:35 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 17 Mar 2011 09:23:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> Date: Thu, 17 Mar 2011 09:19:42 -0400 To: From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-911754286==_ma============" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 13:22:12 -0000 --============_-911754286==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >"It seems like you are favorable towards the validator verifying an RRSIG >for every algorithm (which it understands, of course) that exists in the >DS RRset." No, no, no, quite the opposite. For any given resource record set, a validator ought to try algorithms until any one works. Same for signatures and keys. I can't think of any situation in which DNS should do "everything". It is a "do something" protocol, not a "do everything" protocol. The goal is "get the answer to the client" not "ensure security is followed." Maybe the situation is unclear. First, when obtaining an answer, DNS is mostly done as it was without DNSSEC, i.e., depth-first to the answer. The "mostly" means that in addition to this depth-first plunge, DNSSEC records are also held. If the answer has a signature and the answer is below a trust anchor, then walk backwards from the answer to the trust anchor. That means starting with the answer's RRSIG's signer identifier. Then validate the signer identifier and so on. If there is ever a choice, again, default to a depth-first strategy to find the first chain that can be built. If no chain can be built, the reason will determine if the situation is a service failure or an explicitly broken chain. If the answer has no signature, then you need to first determine if there is a need to find one. Starting with the appropriate trust anchor, go depth first towards the answer. The dive is from zone to zone, looking for an unbroken chain. If a delegation as no DS record set, then DNSSEC "stops." If a delegation has a DS record set but no algorithm is understood by the validator, then DNSSEC "stops." If the delegation has a DS record set with one algorithm that is understood, the next zone is signed in just that algorithm and is why each set has to have each algorithm. If the delegation has a DS record set has a number of useable algorithms...just pick one, try it, if not, try another, and so on. DNS/SEC has to have a depth-first, goal-oriented search. It is not a navel-gazing, breadth-first search. There's nothing wrong in pre-fetching, fleshing out the tree's trustworthiness, and other activity, but that shouldn't be critical path when answering a question. At 11:18 -0700 3/16/11, Casey Deccio wrote: On Tue, Mar 15, 2011 at 5:45 AM, Edward Lewis <Ed.Lewis@neustar.biz> wrote: The specification requires the generation of a signature of each algorithm in the DS record to set the expectation of the validator (remote end). The expectation is that if the DS record set indicates that algorithm X is in use, there will be a signature of algorithm X to be had. If this expectation is not met, then the validator is to declare a protocol failure. For further clarification... It seems like you are favorable towards the validator verifying an RRSIG for every algorithm (which it understands, of course) that exists in the DS RRset. Is this verification just for the RRSIGs made by SEP (i.e., corresponding to DS RRs) DNSKEYs covering the DNSKEY RRset, or for any arbitrary RRSIG in the zone? If the former, once you have authenticated the DNSKEY RRset (with all the algorithms in the DS), then an RRSIG may be verified by any DNSKEY in the DNSKEY RRset, regardless of algorithm; if the latter, then the algorithms must play a part in validating any RRset in the zone. The former seems more reasonable to me. It seems like perhaps your view has changed from SHOULD NOT to SHOULD in one of these regards? In either case, I think that a bit more wording should be added to the proposed text to make it clear what is expected of the the validator, in terms of which RRSIG to check algorithms for, depending on what consensus is. Casey _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" --============_-911754286==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] Clarifying the mandatory algorithm rules
>"It seems like you are favorable towards the validator verifying an RRSIG
>for every algorithm (which it understands, of course) that exists in the
>DS RRset."

No, no, no, quite the opposite.  For any given resource record set, a validator ought to try algorithms until any one works. Same for signatures and keys.

I can't think of any situation in which DNS should do "everything".  It is a "do something" protocol, not a "do everything" protocol.

The goal is "get the answer to the client" not "ensure security is followed."

Maybe the situation is unclear.

First, when obtaining an answer, DNS is mostly done as it was without DNSSEC, i.e., depth-first to the answer.  The "mostly" means that in addition to this depth-first plunge, DNSSEC records are also held.

If the answer has a signature and the answer is below a trust anchor, then walk backwards from the answer to the trust anchor.  That means starting with the answer's RRSIG's signer identifier.  Then validate the signer identifier and so on.  If there is ever a choice, again, default to a depth-first strategy to find the first chain that can be built.  If no chain can be built, the reason will determine if the situation is a service failure or an explicitly broken chain.

If the answer has no signature, then you need to first determine if there is a need to find one.  Starting with the appropriate trust anchor, go depth first towards the answer.  The dive is from zone to zone, looking for an unbroken chain.  If a delegation as no DS record set, then DNSSEC "stops."  If a delegation has a DS record set but no algorithm is understood by the validator, then DNSSEC "stops."  If the delegation has a DS record set with one algorithm that is understood, the next zone is signed in just that algorithm and is why each set has to have each algorithm.  If the delegation has a DS record set has a number of useable algorithms...just pick one, try it, if not, try another, and so on.

DNS/SEC has to have a depth-first, goal-oriented search.  It is not a navel-gazing, breadth-first search.  There's nothing wrong in pre-fetching, fleshing out the tree's trustworthiness, and other activity, but that shouldn't be critical path when answering a question.


At 11:18 -0700 3/16/11, Casey Deccio wrote:
On Tue, Mar 15, 2011 at 5:45 AM, Edward Lewis <Ed.Lewis@neustar.biz> wrote:
The specification requires the generation of a signature of each algorithm in the DS record to set the expectation of the validator (remote end).  The expectation is that if the DS record set indicates that algorithm X is in use, there will be a signature of algorithm X to be had.  If this expectation is not met, then the validator is to declare a protocol failure.

For further clarification...  It seems like you are favorable towards the validator verifying an RRSIG for every algorithm (which it understands, of course) that exists in the DS RRset.  Is this verification just for the RRSIGs made by SEP (i.e., corresponding to DS RRs) DNSKEYs covering the DNSKEY RRset, or for any arbitrary RRSIG in the zone?  If the former, once you have authenticated the DNSKEY RRset (with all the algorithms in the DS), then an RRSIG may be verified by any DNSKEY in the DNSKEY RRset, regardless of algorithm; if the latter, then the algorithms must play a part in validating any RRset in the zone.  The former seems more reasonable to me.  It seems like perhaps your view has changed from SHOULD NOT to SHOULD in one of these regards?

In either case, I think that a bit more wording should be added to the proposed text to make it clear what is expected of the the validator, in terms of which RRSIG to check algorithms for, depending on what consensus is.

Casey

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


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"
--============_-911754286==_ma============-- From casey@deccio.net Thu Mar 17 08:45:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852B53A6968 for ; Thu, 17 Mar 2011 08:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP-h+J1tmtIO for ; Thu, 17 Mar 2011 08:45:07 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id AFEB83A6983 for ; Thu, 17 Mar 2011 08:45:07 -0700 (PDT) Received: by qyk29 with SMTP id 29so16275qyk.10 for ; Thu, 17 Mar 2011 08:46:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.18.9 with SMTP id u9mr1291495qaa.126.1300376795133; Thu, 17 Mar 2011 08:46:35 -0700 (PDT) Received: by 10.229.227.203 with HTTP; Thu, 17 Mar 2011 08:46:35 -0700 (PDT) In-Reply-To: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> Date: Thu, 17 Mar 2011 08:46:35 -0700 Message-ID: From: Casey Deccio To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=bcaec51a870ef2b5bb049eaf90cf Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 15:45:08 -0000 --bcaec51a870ef2b5bb049eaf90cf Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 17, 2011 at 6:19 AM, Edward Lewis wrote: > >"It seems like you are favorable towards the validator verifying an > RRSIG > >for every algorithm (which it understands, of course) that exists in the > >DS RRset." > > No, no, no, quite the opposite. For any given resource record set, a > validator ought to try algorithms until any one works. Same for signatures > and keys. > > My apologies for the misinterpretation. Even with the clear context of your opinion, I somehow got lost with your opening paragraph of your example. Casey --bcaec51a870ef2b5bb049eaf90cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 17, 2011 at 6:19 AM, Edward Lewis <Ed.Lewis@neustar.biz> wrote:=
>"It seems like you are favorable towards the validator verifying an RRSIG
>for every algorithm (which it understands, of course) that exists in the
>DS RRset."

No, no, no, quite the opposite.=A0 For any given resource record set, a validator ought to try algorithms until any one works. Same for signatures and keys.


My apologies for the misinterpre= tation.=A0 Even with the clear context of your opinion, I somehow got lost = with your opening paragraph of your example.

Casey
--bcaec51a870ef2b5bb049eaf90cf-- From Ed.Lewis@neustar.biz Thu Mar 17 09:37:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04EB3A6A9D for ; Thu, 17 Mar 2011 09:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY20rw-LQyqU for ; Thu, 17 Mar 2011 09:37:15 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 46CAE3A6A9B for ; Thu, 17 Mar 2011 09:22:50 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2HGNoix053056; Thu, 17 Mar 2011 12:23:51 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.117] by Work-Laptop-2.local (PGP Universal service); Thu, 17 Mar 2011 12:23:59 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 17 Mar 2011 12:23:59 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> Date: Thu, 17 Mar 2011 12:19:07 -0400 To: Casey Deccio From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:37:16 -0000 At 8:46 -0700 3/17/11, Casey Deccio wrote: >My apologies for the misinterpretation. Even with the clear context of >your opinion, I somehow got lost with your opening paragraph of your example. Ok, again...(not frustrated that you misinterpreted, frustrated that I didn't remove enough pronouns) The reason for the specification is to set the expectation of the validator (the receiving end). The specification requires the signer (the sending end) to generate and publish at least one signature of each algorithm listed in the zone's DS record set. Because of this rule the validator can expect that a signature by a specific algorithm the validator wants to use for a set of data in the zone will be available if listed in the DS record set. With this expectation, if the validator receives a data set from the zone and cannot obtain a signature, then the validator is to declare a protocol failure. The validator does not need the other signatures, therefore should not waste time evaluating them. These other signatures might be important to other validators. What I didn't explain this time is why the DS record set is important to all of this. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From vixie@isc.org Fri Mar 18 08:49:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA1C3A6950 for ; Fri, 18 Mar 2011 08:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+0t+Y0H5cpM for ; Fri, 18 Mar 2011 08:49:02 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 16E373A694E for ; Fri, 18 Mar 2011 08:49:02 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 70655A1055 for ; Fri, 18 Mar 2011 15:50:30 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Date: Fri, 18 Mar 2011 15:50:30 +0000 Message-ID: <65454.1300463430@nsa.vix.com> Subject: [dnsext] googlebot to the rescue X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:49:03 -0000 --=-=-= i think the 0x20 draft was going nowhere in any case so cancelling it is fine. 148.68.249.66.in-addr.arpa domain name pointer crawl-66-249-68-148.googlebot.com. crawl-66-249-68-148.googlebot.com has address 66.249.68.148 it's interesting that it can be done by a web crawler, though. re: --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=7241 Content-Description: forwarded message Return-Path: X-Original-To: vixie@vix.com Delivered-To: vixie@nsa.vix.com Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ams1.isc.org", Issuer "ISC CA" (not verified)) by nsa.vix.com (Postfix) with ESMTPS id D9953A1031 for ; Fri, 18 Mar 2011 11:38:13 +0000 (UTC) (envelope-from wwwrun@core3.amsl.com) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by mx.ams1.isc.org (Postfix) with ESMTP id 4EF185F98E4 for ; Fri, 18 Mar 2011 11:38:03 +0000 (UTC) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id 400F13A68AA; Fri, 18 Mar 2011 04:36:25 -0700 (PDT) From: IETF I-D Submission Tool To: ipr@ietf.org, dagon@cc.gatech.edu, vixie@isc.org Subject: Submission of draft-vixie-dnsext-dns0x20-00 has been Cancelled Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110318113628.400F13A68AA@core3.amsl.com> Date: Fri, 18 Mar 2011 04:36:25 -0700 (PDT) X-Spam-Status: No, score=-101.9 required=5.0 tests=AWL,BAYES_00, USER_IN_ALL_SPAM_TO autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.ams1.isc.org This message is to notify you that submission of an Internet-Draft, draft-vixie-dnsext-dns0x20-00, has just been cancelled by a user whose computer has an IP address of 66.249.68.148. The IETF Secretariat. --=-=-=-- From dwing@cisco.com Fri Mar 18 08:56:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD0E3A691B for ; Fri, 18 Mar 2011 08:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usE3r-8ikZGC for ; Fri, 18 Mar 2011 08:56:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 308C53A691C for ; Fri, 18 Mar 2011 08:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=683; q=dns/txt; s=iport; t=1300463896; x=1301673496; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=6SzTwJLDUWNxja5kAaxY8ri01cDDEeokGg+FWCB17LA=; b=dJlJ/ue1IEn5vzl+ydAd618x53b/5j8V3q6ujJzBWQRbwW8moiz4k6Vs KLAwwQa83GYMrxX/p8JYTzFEKlyFf4FJ4YY+JVI26xaoWuPw2TSCe4wT1 /gTfzh3DncVRKmbsP48DlHtiFQ1npgX8IMT7KcMzh0KfDBEMpg+hscVgE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoAACIeg02Q/khNgWdsb2JhbACYN4FkiyExFQEWJiWmR45rAY0khWMEhTE X-IronPort-AV: E=Sophos;i="4.63,205,1299456000"; d="scan'208";a="79830136" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2011 15:58:14 +0000 Received: from dwingWS ([10.32.240.196]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2IFwDlU011898; Fri, 18 Mar 2011 15:58:13 GMT From: "Dan Wing" To: "'Paul Vixie'" , References: <65454.1300463430@nsa.vix.com> In-Reply-To: <65454.1300463430@nsa.vix.com> Date: Fri, 18 Mar 2011 08:58:12 -0700 Message-ID: <0a1f01cbe585$49c41770$dd4c4650$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvlhD15dDtoKm06TQiGJj176MJoqgAAOW6g Content-language: en-us Subject: Re: [dnsext] googlebot to the rescue X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:56:48 -0000 > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On > Behalf Of Paul Vixie > Sent: Friday, March 18, 2011 8:51 AM > To: dnsext@ietf.org > Subject: [dnsext] googlebot to the rescue > > i think the 0x20 draft was going nowhere in any case so cancelling it > is fine. > > 148.68.249.66.in-addr.arpa domain name pointer > crawl-66-249-68-148.googlebot.com. > > crawl-66-249-68-148.googlebot.com has address 66.249.68.148 > > it's interesting that it can be done by a web crawler, though. The IETF's Internet Draft Submission Tool ("IDST") does a state change on GET, counter to HTTP recommendations for GET. -d From warren@kumari.net Fri Mar 18 09:15:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1503A6975 for ; Fri, 18 Mar 2011 09:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGs6p82SPhxf for ; Fri, 18 Mar 2011 09:15:22 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 527CB3A691C for ; Fri, 18 Mar 2011 09:15:22 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 836771B411F0; Fri, 18 Mar 2011 12:16:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <65454.1300463430@nsa.vix.com> Date: Fri, 18 Mar 2011 12:16:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <65454.1300463430@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] googlebot to the rescue X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:15:24 -0000 On Mar 18, 2011, at 11:50 AM, Paul Vixie wrote: > i think the 0x20 draft was going nowhere in any case so cancelling it = is fine. >=20 > 148.68.249.66.in-addr.arpa domain name pointer > crawl-66-249-68-148.googlebot.com. >=20 > crawl-66-249-68-148.googlebot.com has address 66.249.68.148 >=20 > it's interesting that it can be done by a web crawler, though. Haha.... [ Points, giggles, runs away.... ] W >=20 > re: >=20 >=20 > From: IETF I-D Submission Tool > Date: March 18, 2011 7:36:25 AM EDT > To: ipr@ietf.org, dagon@cc.gatech.edu, vixie@isc.org > Subject: Submission of draft-vixie-dnsext-dns0x20-00 has been = Cancelled=20 >=20 >=20 > This message is to notify you that submission of an Internet-Draft, = draft-vixie-dnsext-dns0x20-00, has just been cancelled by a user whose = computer has an IP address of 66.249.68.148. >=20 > The IETF Secretariat. >=20 >=20 >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From casey@deccio.net Fri Mar 18 09:35:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A413A6955 for ; Fri, 18 Mar 2011 09:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PExYQdrjsa0 for ; Fri, 18 Mar 2011 09:35:22 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 6F1663A6954 for ; Fri, 18 Mar 2011 09:35:22 -0700 (PDT) Received: by qyk7 with SMTP id 7so3182538qyk.10 for ; Fri, 18 Mar 2011 09:36:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.123.211 with SMTP id q19mr1154534qcr.128.1300466211596; Fri, 18 Mar 2011 09:36:51 -0700 (PDT) Received: by 10.229.227.203 with HTTP; Fri, 18 Mar 2011 09:36:51 -0700 (PDT) In-Reply-To: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> Date: Fri, 18 Mar 2011 09:36:51 -0700 Message-ID: From: Casey Deccio To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=000e0cd23d1295abff049ec46223 Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:35:26 -0000 --000e0cd23d1295abff049ec46223 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 17, 2011 at 9:19 AM, Edward Lewis wrote: > The reason for the specification is to set the expectation of the validator > (the receiving end). The specification requires the signer (the sending > end) to generate and publish at least one signature of each algorithm listed > in the zone's DS record set. Because of this rule the validator can expect > that a signature by a specific algorithm the validator wants to use for a > set of data in the zone will be available if listed in the DS record set. > With this expectation, if the validator receives a data set from the zone > and cannot obtain a signature, then the validator is to declare a protocol > failure. Okay, so the signer sets the expectation of the validator using the algorithms in the DS RRset. Now, does this expectation hold for simply authenticating the DNSKEY RRset or for all zone data? For example: - DS RRset has only algorithm 5 - DNSKEY RRset signed by a DNSKEY matching the DS (alg 5) - DNSKEY RRset contains DNSKEYs with algs 5 and 3 - DNSKEY with alg 3 signs A RRset. Is there a valid chain to the A RRset, or is it a protocol failure? Following the principle of "if one chain works, it succeeds", I would say that it is valid. But it's unclear whether this is part of the expectation of the signer for the validator, and even the paragraph quoted above seems to declare it a protocol failure--although I well understand your position on principle. Whether it is valid or not, I believe it should be worded explicitly to avoid ambiguity and accurately convey principle. Casey --000e0cd23d1295abff049ec46223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 17, 2011 at 9:19 AM, Edward Lewis <Ed.Lewis@neustar.biz= > wrote:
The reason for the specification is to set the expectation of the validator= (the receiving end). =A0The specification requires the signer (the sending= end) to generate and publish at least one signature of each algorithm list= ed in the zone's DS record set. =A0Because of this rule the validator c= an expect that a signature by a specific algorithm the validator wants to u= se for a set of data in the zone will be available if listed in the DS reco= rd set. =A0With this expectation, if the validator receives a data set from= the zone and cannot obtain a signature, then the validator is to declare a= protocol failure.

Okay, so the signer sets the expectation of the validator using th= e algorithms in the DS RRset.=A0 Now, does this expectation hold for simply= authenticating the DNSKEY RRset or for all zone data?

For example:=

- DS RRset has only algorithm 5
- DNSKEY RRset signed by a DNSKEY ma= tching the DS (alg 5)
- DNSKEY RRset contains DNSKEYs with algs 5 and 3<= br>- DNSKEY with alg 3 signs A RRset.

Is there a valid chain to the = A RRset, or is it a protocol failure?=A0 Following the principle of "i= f one chain works, it succeeds", I would say that it is valid.=A0 But = it's unclear whether this is part of the expectation of the signer for = the validator, and even the paragraph quoted above seems to declare it a pr= otocol failure--although I well understand your position on principle.=A0 W= hether it is valid or not, I believe it should be worded explicitly to avoi= d ambiguity and accurately convey principle.

Casey
--000e0cd23d1295abff049ec46223-- From Ed.Lewis@neustar.biz Fri Mar 18 09:58:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445C83A6995 for ; Fri, 18 Mar 2011 09:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMgGJsk+5v7e for ; Fri, 18 Mar 2011 09:58:02 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 472213A696F for ; Fri, 18 Mar 2011 09:58:02 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2IGxLnW062400; Fri, 18 Mar 2011 12:59:21 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.112] by Work-Laptop-2.local (PGP Universal service); Fri, 18 Mar 2011 12:59:26 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 18 Mar 2011 12:59:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> Date: Fri, 18 Mar 2011 12:59:17 -0400 To: Casey Deccio From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:58:03 -0000 At 9:36 -0700 3/18/11, Casey Deccio wrote: >Okay, so the signer sets the expectation of the validator using the >algorithms in the DS RRset. Now, does this expectation hold for >simply authenticating the DNSKEY RRset or for all zone data? No, the specification sets expectations. I don't mean to be a pain, but the first words say this: "The reason for the specification is to set the expectation." I mean that in the strictest sense. The validator knows there's supposed to be X because the spec says so. >For example: > >- DS RRset has only algorithm 5 >- DNSKEY RRset signed by a DNSKEY matching the DS (alg 5) >- DNSKEY RRset contains DNSKEYs with algs 5 and 3 >- DNSKEY with alg 3 signs A RRset. > >Is there a valid chain to the A RRset, or is it a protocol failure? Depends. If the validator knows both 3 and 5, then it can build a chain and it's cool. If the validator only knows 5, then there's a missing piece. If the validator only knows 3, there's no chain to the data. In summary: Validator knows 3 & 5 - validates Validator knows only 3 - data is accepted as not-signed. Validator knows only 5 - service failure as *expected* signature is not found* Validator doesn't to 3 & 5 - accepted as not-signed Validator doesn't do DNSSEC - accepted as not-signed *not found = not obtainable, can't get it, ... >Following the principle of "if one chain works, it succeeds", I would say >that it is valid. But it's unclear whether this is part of the expectation >of the signer for the validator, and even the paragraph quoted above seems >to declare it a protocol failure--although I well understand your position >on principle. Whether it is valid or not, I believe it should be >worded explicitly to avoid ambiguity and accurately convey principle. It is always up to the validator to decide if it accepts the data. Local policy and DNSSEC is about protecting the cache. DNSSEC is NOT designed to enforce proper operations, it is NOT to force the zone admin into doing anything. Remember, DNSSEC is optional to the protocol, it's the validators that want to pull the data for protection. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From Ed.Lewis@neustar.biz Fri Mar 18 10:06:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC683A696F for ; Fri, 18 Mar 2011 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8Gfvm13nDYy for ; Fri, 18 Mar 2011 10:06:27 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 5002C3A6955 for ; Fri, 18 Mar 2011 10:06:27 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2IH7kx3062482; Fri, 18 Mar 2011 13:07:46 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.112] by Work-Laptop-2.local (PGP Universal service); Fri, 18 Mar 2011 13:07:55 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 18 Mar 2011 13:07:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> Date: Fri, 18 Mar 2011 13:07:44 -0400 To: Edward Lewis From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 17:06:28 -0000 I should add...just because "there's supposed to be X" doesn't mean X has to be there. If I'm looking for X and it's not there, we have a failure. If I'm not looking for X and it is not there, "no harm, no foul." (The latter is the same as not needing X and it's there anyway.) At 12:59 -0400 3/18/11, Edward Lewis wrote: >At 9:36 -0700 3/18/11, Casey Deccio wrote: > > >>Okay, so the signer sets the expectation of the validator using the >>algorithms in the DS RRset. Now, does this expectation hold for >>simply authenticating the DNSKEY RRset or for all zone data? > >No, the specification sets expectations. I don't mean to be a pain, >but the first words say this: "The reason for the specification is >to set the expectation." I mean that in the strictest sense. The >validator knows there's supposed to be X because the spec says so. > >>For example: >> >>- DS RRset has only algorithm 5 >>- DNSKEY RRset signed by a DNSKEY matching the DS (alg 5) >>- DNSKEY RRset contains DNSKEYs with algs 5 and 3 >>- DNSKEY with alg 3 signs A RRset. >> >>Is there a valid chain to the A RRset, or is it a protocol failure? > >Depends. If the validator knows both 3 and 5, then it can build a >chain and it's cool. If the validator only knows 5, then there's a >missing piece. If the validator only knows 3, there's no chain to >the data. > >In summary: >Validator knows 3 & 5 - validates >Validator knows only 3 - data is accepted as not-signed. >Validator knows only 5 - service failure as *expected* signature is not found* >Validator doesn't to 3 & 5 - accepted as not-signed >Validator doesn't do DNSSEC - accepted as not-signed > >*not found = not obtainable, can't get it, ... > >>Following the principle of "if one chain works, it succeeds", I would say >>that it is valid. But it's unclear whether this is part of the expectation >>of the signer for the validator, and even the paragraph quoted above seems >>to declare it a protocol failure--although I well understand your position >>on principle. Whether it is valid or not, I believe it should be >>worded explicitly to avoid ambiguity and accurately convey principle. > >It is always up to the validator to decide if it accepts the data. >Local policy and DNSSEC is about protecting the cache. DNSSEC is >NOT designed to enforce proper operations, it is NOT to force the >zone admin into doing anything. Remember, DNSSEC is optional to the >protocol, it's the validators that want to pull the data for >protection. > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis >NeuStar You can leave a voice message at +1-571-434-5468 > >Me to infant son: "Waah! Waah! Is that all you can say? Waah?" >Son: "Waah!" >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From george.barwood@blueyonder.co.uk Mon Mar 21 14:23:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDCB3A68D7 for ; Mon, 21 Mar 2011 14:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.873 X-Spam-Level: * X-Spam-Status: No, score=1.873 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_40=-0.185, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRLeHlYqbfJi for ; Mon, 21 Mar 2011 14:23:43 -0700 (PDT) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id B6AC33A68D6 for ; Mon, 21 Mar 2011 14:23:43 -0700 (PDT) Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1Q1mbD-0000G1-8q for dnsext@ietf.org; Mon, 21 Mar 2011 21:25:15 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1Q1mb2-0008SV-Rq for dnsext@ietf.org; Mon, 21 Mar 2011 21:25:04 +0000 Message-ID: From: "George Barwood" To: Date: Mon, 21 Mar 2011 21:25:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 21:23:44 -0000 VmlhIHRoZSBkYW5lIGdyb3VwLCBJIGp1c3QgcmVhbGlzZWQgdGhhdCBpZiBEUyByZWNvcmRzIGFy ZSBwcm92aWRlZCBmb3IgYm90aCBTSEExIGFuZCBTSEEyNTYsIG5vIGV4dHJhIHNlY3VyaXR5IGlz IG9idGFpbmVkIG92ZXIgdXNpbmcganVzdCBTSEExLg0KDQpUaGF0J3MgYmVjYXVzZSB0aGUgU0hB MjU2IERTIHJlY29yZCBjb3VsZCBiZSBmb3IgYW4gdW5wdWJsaXNoZWQgRE5TS0VZIGluIHRoZSBj aGlsZCB0aGF0IGhhcHBlbnMgdG8gaGF2ZSB0aGUgc2FtZSBLZXkgVGFnLCBzbyB0aGUgdmVyaWZp ZXIgaGFzIHRvIHRyeSB0aGUgU0hBMSBkaWdlc3QgaWYgdGhlIFNIQTI1NiB2ZXJpZmljYXRpb24g ZmFpbHMuDQoNClRoaXMgc2VlbXMgdW5mb3J0dW5hdGUuIFlvdSBjb3VsZCBoYXZlIGEgcnVsZSB0 aGF0IHN0YXRlcyB0aGF0IGlmIFNIQTI1NiBpcyB1c2VkLCBpdCBtdXN0IGJlIHVzZWQgInVuaWZv cm1seSIgKCBvciBhdCBsZWFzdCBmb3IgYWxsIGtleXMgd2l0aCB0aGUgc2FtZSBhbGdvcml0aG0g YW5kIEtleSBUYWcgKS4NCg0KVGhlIGFsdGVybmF0aXZlIGlzIHRvIGp1c3Qgbm90IHVzZSBTSEEx IEkgc3VwcG9zZS4NCg0KQnV0IHRoaXMgZG9lcyBzZWVtIGxpa2UgYSBkZXNpZ24gZmxhdywgaXQn cyBhbiBvYnN0YWNsZSBmb3IgdXBncmFkaW5nIHRvIGJldHRlciBkaWdlc3QgYWxnb3JpdGhtcyAo U0hBMz8pIGlmL3doZW4gdGhlIGN1cnJlbnQgb25lcyBwcm92ZSB3ZWFrLg0KDQpXYXMgdGhpcyBl dmVyIGRpc2N1c3NlZD8NCg0KR2VvcmdlDQo= From marka@isc.org Mon Mar 21 15:24:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71843A68D6 for ; Mon, 21 Mar 2011 15:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.362 X-Spam-Level: X-Spam-Status: No, score=-1.362 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, MANGLED_BETTER=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnW+m8tlFRpI for ; Mon, 21 Mar 2011 15:24:10 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 7C8103A68F5 for ; Mon, 21 Mar 2011 15:24:10 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7A6A95F9863; Mon, 21 Mar 2011 22:25:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 1CE85216C22; Mon, 21 Mar 2011 22:25:24 +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 83729D084D9; Tue, 22 Mar 2011 09:25:21 +1100 (EST) To: "George Barwood" From: Mark Andrews References: In-reply-to: Your message of "Mon, 21 Mar 2011 21:25:28 -0000." Date: Tue, 22 Mar 2011 09:25:21 +1100 Message-Id: <20110321222521.83729D084D9@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 22:24:18 -0000 In message , "George Barwood" writes: > Via the dane group, I just realised that if DS records are provided for both > SHA1 and SHA256, no extra security is obtained over using just SHA1. > > That's because the SHA256 DS record could be for an unpublished DNSKEY in the > child that happens to have the same Key Tag, so the verifier has to try the > SHA1 digest if the SHA256 verification fails. > > This seems unfortunate. You could have a rule that states that if SHA256 is u > sed, it must be used "uniformly" ( or at least for all keys with the same alg > orithm and Key Tag ). > > The alternative is to just not use SHA1 I suppose. > > But this does seem like a design flaw, it's an obstacle for upgrading to bett > er digest algorithms (SHA3?) if/when the current ones prove weak. > > Was this ever discussed? I sugest that you go re-read RFC 4509. SHA1 DS should be ignored if there are SHA256 DS records. > George > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From george.barwood@blueyonder.co.uk Mon Mar 21 16:11:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D12C28C0FE for ; Mon, 21 Mar 2011 16:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.729 X-Spam-Level: X-Spam-Status: No, score=0.729 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLuggr0F9Re6 for ; Mon, 21 Mar 2011 16:11:13 -0700 (PDT) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id A662828C105 for ; Mon, 21 Mar 2011 16:11:13 -0700 (PDT) Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1Q1oHF-0006LP-Aj; Mon, 21 Mar 2011 23:12:45 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1Q1oH5-0002s3-4H; Mon, 21 Mar 2011 23:12:35 +0000 Message-ID: <51C21B4C57014630B72B50B919271C89@local> From: "George Barwood" To: "Mark Andrews" References: <20110321222521.83729D084D9@drugs.dv.isc.org> Date: Mon, 21 Mar 2011 23:13:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 23:11:25 -0000 PiBJIHN1Z2VzdCB0aGF0IHlvdSBnbyByZS1yZWFkIFJGQyA0NTA5LiAgIFNIQTEgRFMgc2hvdWxk IGJlIGlnbm9yZWQgaWYgdGhlcmUNCj4gYXJlIFNIQTI1NiBEUyByZWNvcmRzLg0KDQpPaywgSSBz ZWUgaXQgbm93LCBzZWN0aW9uIDMNCg0KICAgVmFsaWRhdG9yIGltcGxlbWVudGF0aW9ucyBTSE9V TEQgaWdub3JlIERTIFJScyBjb250YWluaW5nIFNIQS0xDQogICBkaWdlc3RzIGlmIERTIFJScyB3 aXRoIFNIQS0yNTYgZGlnZXN0cyBhcmUgcHJlc2VudCBpbiB0aGUgRFMgUlJzZXQuDQoNClRoYXQg aXMgYWN0dWFsbHkgd2hhdCBJIGltcGxlbWVudGVkLCB0aGUgZGFuZSBwb3N0IGdvdCBtZSBjb25m dXNlZA0KKCBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIva2V5YXNzdXJlL2N1 cnJlbnQvbXNnMDIwOTMuaHRtbCApDQoNCkkgdGhpbmsgdGhhdCBSRkMgNDUwOSBjb3VsZCBoYXZl IHBvaW50ZWQgb3V0IHRoZSBzdWJ0bGUgaW1wbGljYXRpb25zIGZvciB0aGUgdW5pZm9ybQ0KZ2Vu ZXJhdGlvbiBvZiBEUyByZWNvcmRzLiBUaGVyZSBtaWdodCBiZSBzb21lIHJpc2sgdGhhdCBhbiBh ZG1pbmlzdHJhdG9yDQpmYWlscyB0byBwdWJsaXNoIGEgcmVxdWlyZWQgRFMgcmVjb3JkICggcG9z c2libHkgZHVlIHRvIHNvbWUgcGFyZW50IGNvbnN0cmFpbnQgb24gdGhlDQp0b3RhbCBzaXplIG9m IHRoZSBEUyBSUnNldCApLg0KDQppLmUuIHRoZSB6b25lIGlzIHVzaW5nIFNIQTEgRFMgcmVjb3Jk cywgYWRtaW4gZ2VuZXJhdGVzIG5ldyBLU0ssIHB1Ymxpc2hlcyBTSEEyNTYgRFMNCmZvciB0aGUg bmV3IEtTSyBidXQgZG9lc24ndCBwdWJsaXNoIFNIQTI1NiBEUyBmb3IgdGhlIG9sZCBLU0ssIGxl YWRpbmcgdG8gdmFsaWRhdGlvbiBmYWlsdXJlcy4NCg0KR2VvcmdlDQoNCg== From Francis.Dupont@fdupont.fr Mon Mar 21 16:37:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4CA128C0FD for ; Mon, 21 Mar 2011 16:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMPbDrKh+wlL for ; Mon, 21 Mar 2011 16:37:39 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 402F73A6912 for ; Mon, 21 Mar 2011 16:37:08 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2LNceH6051081; Tue, 22 Mar 2011 00:38:40 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103212338.p2LNceH6051081@givry.fdupont.fr> From: Francis Dupont To: "George Barwood" In-reply-to: Your message of Mon, 21 Mar 2011 23:13:00 GMT. <51C21B4C57014630B72B50B919271C89@local> Date: Tue, 22 Mar 2011 00:38:40 +0100 Sender: Francis.Dupont@fdupont.fr Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 23:37:39 -0000 In your previous mail you wrote: i.e. the zone is using SHA1 DS records, admin generates new KSK, publishes SHA256 DS for the new KSK but doesn't publish SHA256 DS for the old KSK, leading to validat ion failures. => this should never happen as the rule is in fact for the replacement of SHA1 by SHA256 as the DS digest algorithm. But don't believe we are saved: there are other DS digest algos (and even more to come) and the mixed algo case is dangerously under-specified... Regards Francis.Dupont@fdupont.fr From Ed.Lewis@neustar.biz Tue Mar 22 05:10:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC31528C113 for ; Tue, 22 Mar 2011 05:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j14NOdKBXdbQ for ; Tue, 22 Mar 2011 05:10:33 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 914AB28C10A for ; Tue, 22 Mar 2011 05:10:31 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2MCBtbs094590; Tue, 22 Mar 2011 08:11:55 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.115] by Work-Laptop-2.local (PGP Universal service); Tue, 22 Mar 2011 08:12:05 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 22 Mar 2011 08:12:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 22 Mar 2011 08:11:53 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 12:10:33 -0000 At 21:25 +0000 3/21/11, George Barwood wrote: >Was this ever discussed? In the 90's, at the dawn of all this we considered downgrade situations. DNSSEC is not there to protect the zone, it exists to protect the cache. The cache is the element tha decides what to trust or not. Local policy and all that. A zone only makes data available to the cache. The more the merrier. Caches should be liberal in what they trust - but also firm in what they don't. If SHA-1 is at risk, never use it, remove it from consideration. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From derek@ihtfp.com Tue Mar 22 05:59:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B66E28C117 for ; Tue, 22 Mar 2011 05:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.388 X-Spam-Level: X-Spam-Status: No, score=-101.388 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eme0odACB2ue for ; Tue, 22 Mar 2011 05:59:12 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by core3.amsl.com (Postfix) with ESMTP id 564F828C113 for ; Tue, 22 Mar 2011 05:59:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A010A26036E; Tue, 22 Mar 2011 09:00:44 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 30516-02; Tue, 22 Mar 2011 09:00:43 -0400 (EDT) Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 9410B2602A4; Tue, 22 Mar 2011 09:00:42 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id p2MD0aaD012890; Tue, 22 Mar 2011 09:00:36 -0400 From: Derek Atkins To: Francis Dupont References: <201103212338.p2LNceH6051081@givry.fdupont.fr> Date: Tue, 22 Mar 2011 09:00:36 -0400 In-Reply-To: <201103212338.p2LNceH6051081@givry.fdupont.fr> (Francis Dupont's message of "Tue, 22 Mar 2011 00:38:40 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 12:59:13 -0000 Francis Dupont writes: > In your previous mail you wrote: > > i.e. the zone is using SHA1 DS records, admin generates new KSK, > publishes SHA256 DS for the new KSK but doesn't publish SHA256 DS > for the old KSK, leading to validat ion failures. > > => this should never happen as the rule is in fact for the > replacement of SHA1 by SHA256 as the DS digest algorithm. > But don't believe we are saved: there are other DS digest algos > (and even more to come) and the mixed algo case is dangerously > under-specified... It also doesn't help protect against an active man-in-the-middle who can make sure that the validator never receives the SHA256 DS RR. Unfortunately the validator can only validate what it receives; there's often not a way for it to know what it should expect to receive. > Regards > > Francis.Dupont@fdupont.fr -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From marka@isc.org Tue Mar 22 07:02:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3053928C0F4 for ; Tue, 22 Mar 2011 07:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSGxIrEzqlhO for ; Tue, 22 Mar 2011 07:01:54 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 9F27328C0D0 for ; Tue, 22 Mar 2011 07:01:53 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id D664F5F9865; Tue, 22 Mar 2011 14:03:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 C5FB4216C33; Tue, 22 Mar 2011 14:03:08 +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 72E8DD15DFB; Wed, 23 Mar 2011 01:03:06 +1100 (EST) To: Derek Atkins From: Mark Andrews References: <201103212338.p2LNceH6051081@givry.fdupont.fr> In-reply-to: Your message of "Tue, 22 Mar 2011 09:00:36 EDT." Date: Wed, 23 Mar 2011 01:03:06 +1100 Message-Id: <20110322140306.72E8DD15DFB@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 14:02:11 -0000 In message , Derek Atkins writes: > Francis Dupont writes: > > > In your previous mail you wrote: > > > > i.e. the zone is using SHA1 DS records, admin generates new KSK, > > publishes SHA256 DS for the new KSK but doesn't publish SHA256 DS > > for the old KSK, leading to validat ion failures. > > > > => this should never happen as the rule is in fact for the > > replacement of SHA1 by SHA256 as the DS digest algorithm. > > But don't believe we are saved: there are other DS digest algos > > (and even more to come) and the mixed algo case is dangerously > > under-specified... > > It also doesn't help protect against an active man-in-the-middle who can > make sure that the validator never receives the SHA256 DS RR. > Unfortunately the validator can only validate what it receives; there's > often not a way for it to know what it should expect to receive. This attack is not possible. > > Regards > > > > Francis.Dupont@fdupont.fr > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From george.barwood@blueyonder.co.uk Tue Mar 22 07:08:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6414728C0EC for ; Tue, 22 Mar 2011 07:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, J_CHICKENPOX_13=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mayecBYw3eY for ; Tue, 22 Mar 2011 07:08:09 -0700 (PDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by core3.amsl.com (Postfix) with ESMTP id BFC0A28C0D0 for ; Tue, 22 Mar 2011 07:08:08 -0700 (PDT) Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1Q22HE-0007uD-Fk; Tue, 22 Mar 2011 14:09:40 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1Q22H9-0006uM-Af; Tue, 22 Mar 2011 14:09:35 +0000 Message-ID: <2E179CBE6E604685965A33359402EFD8@local> From: "George Barwood" To: "Derek Atkins" , "Francis Dupont" References: <201103212338.p2LNceH6051081@givry.fdupont.fr> Date: Tue, 22 Mar 2011 14:10:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 14:08:10 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRlcmVrIEF0a2lucyIgPHdh cmxvcmRATUlULkVEVT4NClRvOiAiRnJhbmNpcyBEdXBvbnQiIDxGcmFuY2lzLkR1cG9udEBmZHVw b250LmZyPg0KQ2M6ICJHZW9yZ2UgQmFyd29vZCIgPGdlb3JnZS5iYXJ3b29kQGJsdWV5b25kZXIu Y28udWs+OyA8ZG5zZXh0QGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgTWFyY2ggMjIsIDIwMTEg MTowMCBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIERTIGRpZ2VzdCBkb3duZ3JhZGUNCg0KDQo+ IEZyYW5jaXMgRHVwb250IDxGcmFuY2lzLkR1cG9udEBmZHVwb250LmZyPiB3cml0ZXM6DQo+IA0K Pj4gIEluIHlvdXIgcHJldmlvdXMgbWFpbCB5b3Ugd3JvdGU6DQo+Pg0KPj4gICAgaS5lLiB0aGUg em9uZSBpcyB1c2luZyBTSEExIERTIHJlY29yZHMsIGFkbWluIGdlbmVyYXRlcyBuZXcgS1NLLA0K Pj4gICAgcHVibGlzaGVzIFNIQTI1NiBEUyBmb3IgdGhlIG5ldyBLU0sgYnV0IGRvZXNuJ3QgcHVi bGlzaCBTSEEyNTYgRFMNCj4+ICAgIGZvciB0aGUgb2xkIEtTSywgbGVhZGluZyB0byB2YWxpZGF0 IGlvbiBmYWlsdXJlcy4NCj4+ICAgIA0KPj4gPT4gdGhpcyBzaG91bGQgbmV2ZXIgaGFwcGVuIGFz IHRoZSBydWxlIGlzIGluIGZhY3QgZm9yIHRoZQ0KPj4gcmVwbGFjZW1lbnQgb2YgU0hBMSBieSBT SEEyNTYgYXMgdGhlIERTIGRpZ2VzdCBhbGdvcml0aG0uDQo+PiAgQnV0IGRvbid0IGJlbGlldmUg d2UgYXJlIHNhdmVkOiB0aGVyZSBhcmUgb3RoZXIgRFMgZGlnZXN0IGFsZ29zDQo+PiAoYW5kIGV2 ZW4gbW9yZSB0byBjb21lKSBhbmQgdGhlIG1peGVkIGFsZ28gY2FzZSBpcyBkYW5nZXJvdXNseQ0K Pj4gdW5kZXItc3BlY2lmaWVkLi4uDQo+IA0KPiBJdCBhbHNvIGRvZXNuJ3QgaGVscCBwcm90ZWN0 IGFnYWluc3QgYW4gYWN0aXZlIG1hbi1pbi10aGUtbWlkZGxlIHdobyBjYW4NCj4gbWFrZSBzdXJl IHRoYXQgdGhlIHZhbGlkYXRvciBuZXZlciByZWNlaXZlcyB0aGUgU0hBMjU2IERTIFJSLg0KPiBV bmZvcnR1bmF0ZWx5IHRoZSB2YWxpZGF0b3IgY2FuIG9ubHkgdmFsaWRhdGUgd2hhdCBpdCByZWNl aXZlczsgdGhlcmUncw0KPiBvZnRlbiBub3QgYSB3YXkgZm9yIGl0IHRvIGtub3cgd2hhdCBpdCBz aG91bGQgZXhwZWN0IHRvIHJlY2VpdmUuDQoNCk5vLCB0aGF0J3MgdGhlIHdob2xlIHBvaW50IGhl cmUuDQpUaGUgdmFsaWRhdG9ycyBnZXRzIHRoZSAoc2lnbmVkLHZhbGlkYXRlZCkgRFMgZnJvbSB0 aGUgcGFyZW50IHpvbmUuDQpXaGVuIGl0IHNlZXMgYW4gYWxnb3JpdGhtIGluIHRoZSBEUyBSUnNl dCBpdCBleHBlY3RzIHRoZSBjaGlsZCB6b25lIHRvIGJlIHNpZ25lZCB3aXRoIHRoYXQgYWxnb3Jp dGhtDQphbmQgaWYgaXQgaXNuJ3QgdGhlbiB0aGUgcmVzdWx0IGlzIGJvZ3VzLg0KU2ltaWxhcmx5 ICggYXMgaW1wbGllZCBieSBSRkMgNDUwOSApIGlmIGl0IHNlZXMgU0hBMjU2IGluIHRoZSBEUyBS UnNldCBhcyBhIGRpZ2VzdCB0eXBlLCBpdCBleHBlY3RzIHRvDQpiZSBhYmxlIHRvIHZhbGlkYXRl IHRoZSBETlNLRVkgUlJzZXQgZnJvbSB0aGUgY2hpbGQgdXNpbmcgdGhhdCBkaWdlc3QgdHlwZS4g DQpJZiB0aGF0J3Mgbm90IHBvc3NpYmxlIHRoZW4gYWdhaW4gdGhlIHJlc3VsdCBpcyBib2d1cy4N ClNvIHRoZXJlIGlzIG5vIHByb2JsZW0sIGRvd25ncmFkZSBhdHRhY2tzIGFyZSBwcmV2ZW50ZWQs IGV2ZXJ5dGhpbmcgaXMgZ29vZC4NCkkgd2FzIGp1c3QgY29uZnVzZWQgbW9tZW50YXJpbHkgYnkg dGhlIERhbmUgbWVzc2FnZSBmcm9tIE1hdHQuDQoNCkdlb3JnZQ0KDQo+PiBSZWdhcmRzDQo+Pg0K Pj4gRnJhbmNpcy5EdXBvbnRAZmR1cG9udC5mcg0KPiANCj4gLWRlcmVrDQo+IA0KPiAtLSANCj4g ICAgICAgRGVyZWsgQXRraW5zLCBTQiAnOTMgTUlUIEVFLCBTTSAnOTUgTUlUIE1lZGlhIExhYm9y YXRvcnkNCj4gICAgICAgTWVtYmVyLCBNSVQgU3R1ZGVudCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5n IEJvYXJkICAoU0lQQikNCj4gICAgICAgVVJMOiBodHRwOi8vd2ViLm1pdC5lZHUvd2FybG9yZC8g ICAgUFAtQVNFTC1JQSAgICAgTjFOV0gNCj4gICAgICAgd2FybG9yZEBNSVQuRURVICAgICAgICAg ICAgICAgICAgICAgICAgUEdQIGtleSBhdmFpbGFibGU= From wjhns1@hardakers.net Tue Mar 22 07:12:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CDA928C0EC for ; Tue, 22 Mar 2011 07:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYwClFW4vtMK for ; Tue, 22 Mar 2011 07:12:43 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id BB26928C0D0 for ; Tue, 22 Mar 2011 07:12:43 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id D806B218D8; Tue, 22 Mar 2011 07:13:55 -0700 (PDT) From: Wes Hardaker To: Derek Atkins References: <201103212338.p2LNceH6051081@givry.fdupont.fr> Date: Tue, 22 Mar 2011 07:13:54 -0700 In-Reply-To: (Derek Atkins's message of "Tue, 22 Mar 2011 09:00:36 -0400") Message-ID: User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 14:12:44 -0000 >>>>> On Tue, 22 Mar 2011 09:00:36 -0400, Derek Atkins said: DA> It also doesn't help protect against an active man-in-the-middle who can DA> make sure that the validator never receives the SHA256 DS RR. DA> Unfortunately the validator can only validate what it receives; there's DA> often not a way for it to know what it should expect to receive. The DS record will be signed by the RRSIG for the entire type, not just a particular DS algorithm. So if a man-in-the-middle removes the SHA256 DS record the validation of the entire DS set will fail. -- Wes Hardaker Cobham Analytic Solutions From mgraff@isc.org Tue Mar 22 07:13:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E1028C128 for ; Tue, 22 Mar 2011 07:13:09 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOw0R+5GIe0R for ; Tue, 22 Mar 2011 07:13:01 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id DEFA128C0D0 for ; Tue, 22 Mar 2011 07:13:00 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 1C5A9C9465 for ; Tue, 22 Mar 2011 14:14:05 +0000 (UTC) (envelope-from mgraff@isc.org) Received: from WhiteDragon.local (81.5.broadband6.iol.cz [88.101.5.81]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A623E216C22 for ; Tue, 22 Mar 2011 14:14:04 +0000 (UTC) (envelope-from mgraff@isc.org) Message-ID: <4D88AEAA.9090605@isc.org> Date: Tue, 22 Mar 2011 15:14:02 +0100 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <201103212338.p2LNceH6051081@givry.fdupont.fr> <20110322140306.72E8DD15DFB@drugs.dv.isc.org> In-Reply-To: <20110322140306.72E8DD15DFB@drugs.dv.isc.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 14:13:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/22/11 3:03 PM, Mark Andrews wrote: >> It also doesn't help protect against an active man-in-the-middle who can >> make sure that the validator never receives the SHA256 DS RR. >> Unfortunately the validator can only validate what it receives; there's >> often not a way for it to know what it should expect to receive. > > This attack is not possible. To expand on this... The DS records are signed by the parent, so a MITM attack against them to modify them in flight would cause a signature failure. Unless I'm really confused about what Mark meant. So, while it can cause validation failure (which makes the domain dark) it can't be fooled into accepting something not intended by the publisher. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNiK6qAAoJEDRzoY2A7tzbUr8IAJF8nV8eF3d7JD5GB4HL3uwZ 5pSIWTADRxFI1lbZ5XvU1a0e5TKjI0YqEi7Nt0sE4kD6Y46Ggi6ERUDV8u1h/she YchRizYB6LM8kO6Z1fvNxNW2Fp1QPdjmm4hRyEpGF8HZtrW0D272E7jFWZGSya4B 6JeZri/00+ezcXFyR23FV/lunZPR1UJd6Yl3iHRp1OHFZX9e9AIfr2a80xxudt4x HJgma7CGxvstfh4uZJJYP9XQi6A7uuVg4hGwj5DMUrFAo2nfzvVStT+COawQQCT4 30kfkwK20G4C/21Ms6ZhJJC4ESxkINYWZDJSuCm+b/8h+d2NrnxKJb4L1pQeJvo= =D/GN -----END PGP SIGNATURE----- From wjhns1@hardakers.net Tue Mar 22 07:21:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5370A28C12B for ; Tue, 22 Mar 2011 07:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uplE4RNs9Kau for ; Tue, 22 Mar 2011 07:20:56 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 4200428C11D for ; Tue, 22 Mar 2011 07:20:56 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 5F06C21901; Tue, 22 Mar 2011 07:22:08 -0700 (PDT) From: Wes Hardaker To: "George Barwood" References: <20110321222521.83729D084D9@drugs.dv.isc.org> <51C21B4C57014630B72B50B919271C89@local> Date: Tue, 22 Mar 2011 07:22:02 -0700 In-Reply-To: <51C21B4C57014630B72B50B919271C89@local> (George Barwood's message of "Mon, 21 Mar 2011 23:13:00 -0000") Message-ID: User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 14:21:08 -0000 >>>>> On Mon, 21 Mar 2011 23:13:00 -0000, "George Barwood" said: GB> I think that RFC 4509 could have pointed out the subtle implications GB> for the uniform generation of DS records. There might be some risk GB> that an administrator fails to publish a required DS record ( GB> possibly due to some parent constraint on the total size of the DS GB> RRset ). We deliberately stayed away from best-practices in the text because if we went down that road it never would have been published :-/ You're right that this sort of discussion is needed somewhere, but as others have pointed out there will/could be more and more algorthims for more and more parts of the protocol and this situation (and transitions) should be discussed in a single document, not in each individual one. [though it would have been nice to refer to one] What's worse, it takes careful coordination with your parent. Consider the case where: T+0: example.tld adds a new key T+1: example.tld sends a SHA1 DS record to the parent T+2: tld publishes the new DS T+3: someone queries for the example.tld DS and gets a DS record set with the SHA1 DS for the new key. And a TTL picked by ??? [multiple options exist here]. T+4: example.tld sends a SHA256 DS record to the parent T+5: tld publishes the new DS If a parent only allows updating of a single DS record at a time, the time between T+1 and T+5 could actually be on the order of seconds even, but there is a time gap. The whole process needs to document parent/child relationships too, and the fact that the recommended interface between the parent and child SHOULD accept multiple algorithms simultaneously to prevent situations like the above. So the advice to the child gets even longer and more winded: if your parent only accepts one record at a time, please publish the SHA256 first if you value security. Or SHA1 first if you value widest-interoperability (which I actually doubt as I suspect everything? works with SHA256 now or won't work at all in the first place, since SHA256 predates the NSEC3 records which are now in such wide-spread use that you're chances of being highly successful on the internet with SHA256 but no NSEC3 is unlikely). As you can see... it isn't a short bit of text that is needed. -- Wes Hardaker Cobham Analytic Solutions From ajs@shinkuro.com Tue Mar 22 07:30:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F8F28C128 for ; Tue, 22 Mar 2011 07:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc+ptJzL1KW6 for ; Tue, 22 Mar 2011 07:30:42 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id CEA9C28C127 for ; Tue, 22 Mar 2011 07:30:42 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 878771ECB408 for ; Tue, 22 Mar 2011 14:32:15 +0000 (UTC) Date: Tue, 22 Mar 2011 10:32:13 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110322143213.GU87529@shinkuro.com> References: <20110321222521.83729D084D9@drugs.dv.isc.org> <51C21B4C57014630B72B50B919271C89@local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 14:30:43 -0000 No hat. On Tue, Mar 22, 2011 at 07:22:02AM -0700, Wes Hardaker wrote: > T+3: someone queries for the example.tld DS and gets a DS record set > with the SHA1 DS for the new key. And a TTL picked by ??? > [multiple options exist here]. I don't see why multiple options exist there. The DS record is authoritative data at the parent, and nowhere else. Therefore, it is the job of the parent and nobody else to set the TTL. It might be that the parent has policies about how it sets the TTL based on other factors, such as hints from the sponsor of the name about the planned effective use period of the corresponding DNSKEY. Certainly, if I ran the circus, that's how I'd do it. But we need to be quite careful in stating who has control of which data. > If a parent only allows updating of a single DS record at a time, It does seem to me that it would be a wise idea to provide operational advice to DNS operators that accepting only one DS at a time is not a good idea, precisely because the child side might have more than one DNSKEY used as a KSK. That would be operational advice, however, not protocol. If I were to put my hat back on, I'd note that such advice would be the purview of another working group. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Francis.Dupont@fdupont.fr Tue Mar 22 08:50:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4210F28C146 for ; Tue, 22 Mar 2011 08:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecYMtpTKNQio for ; Tue, 22 Mar 2011 08:50:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 9A4DD28C0CF for ; Tue, 22 Mar 2011 08:50:09 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2MFpgEY010280; Tue, 22 Mar 2011 16:51:42 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103221551.p2MFpgEY010280@givry.fdupont.fr> From: Francis Dupont To: Derek Atkins In-reply-to: Your message of Tue, 22 Mar 2011 09:00:36 -0400. Date: Tue, 22 Mar 2011 16:51:42 +0100 Sender: Francis.Dupont@fdupont.fr Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 15:50:23 -0000 In your previous mail you wrote: It also doesn't help protect against an active man-in-the-middle who can make sure that the validator never receives the SHA256 DS RR. => if the DS RRset is signed this is not possible. Unfortunately the validator can only validate what it receives; there's often not a way for it to know what it should expect to receive. => this opens the door to DoS attacks but as far as I know no more. Regards Francis.Dupont@fdupont.fr From jabley@hopcount.ca Tue Mar 22 09:50:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336B328C13D for ; Tue, 22 Mar 2011 09:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsqVKmEmBD2L for ; Tue, 22 Mar 2011 09:50:37 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by core3.amsl.com (Postfix) with ESMTP id DF88728C12E for ; Tue, 22 Mar 2011 09:50:36 -0700 (PDT) Received: from [199.212.90.17] (helo=dh17.r1.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q24oR-0006jH-2P; Tue, 22 Mar 2011 16:52:07 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <201103221551.p2MFpgEY010280@givry.fdupont.fr> Date: Tue, 22 Mar 2011 12:52:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6AD2683C-BC01-4AC9-BF9C-3FC03EC93DC7@hopcount.ca> References: <201103221551.p2MFpgEY010280@givry.fdupont.fr> To: Francis Dupont X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 199.212.90.17 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: Derek Atkins , dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 16:50:38 -0000 On 2011-03-22, at 11:51, Francis Dupont wrote: > In your previous mail you wrote: >=20 > Unfortunately the validator can only validate what it receives; = there's > often not a way for it to know what it should expect to receive. >=20 > =3D> this opens the door to DoS attacks but as far as I know > no more. I think that door was already open. If you can spoof a secure delegation = response to a client, surely you can also spoof an NXDOMAIN or a = SERVFAIL. Joe From ajs@shinkuro.com Tue Mar 22 12:40:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2403D3A68D2 for ; Tue, 22 Mar 2011 12:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAmIKHtd1DTJ for ; Tue, 22 Mar 2011 12:40:05 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 6E1033A68CB for ; Tue, 22 Mar 2011 12:40:05 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DCEC11ECB408 for ; Tue, 22 Mar 2011 19:41:37 +0000 (UTC) Date: Tue, 22 Mar 2011 15:41:36 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110322194135.GL87529@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dnsext] Reminder: Meeting at IETF 80 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 19:40:06 -0000 Dear colleagues, A reminder that we will be having a meeting at IETF 80 in Prague. Our session is one hour, next Monday afternoon (local time). We will be discussing only two items: draft-ietf-dnsext-aliasing-requirements-01 draft-vixie-dnsext-resimprove-00 The chairs were expecting a -01 of the latter when the session was planned, but it appears not to have been uploaded. We'll proceed with the plan anyway. There has been extensive discussion of both of these items in the past little while, and we encourage you to review that discussion in anticipation of the meeting. We are aiming primarily for a working session in which issues are worked out, so if you have particular proposals (especially for text) prior to the meeting, please post them to the list. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From woolf@isc.org Tue Mar 22 15:09:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EC23A67D9 for ; Tue, 22 Mar 2011 15:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwt4Fyyp1DJz for ; Tue, 22 Mar 2011 15:09:37 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 3DBE53A67B6 for ; Tue, 22 Mar 2011 15:09:37 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id E07F1C94A6 for ; Tue, 22 Mar 2011 22:10:38 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id D4689216C33; Tue, 22 Mar 2011 22:10:38 +0000 (UTC) Date: Tue, 22 Mar 2011 22:10:38 +0000 From: Suzanne Woolf To: dnsext@ietf.org Message-ID: <20110322221038.GA85247@bikeshed.isc.org> References: <20110322194135.GL87529@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110322194135.GL87529@shinkuro.com> User-Agent: Mutt/1.4.2.3i Subject: Re: [dnsext] Reminder: Meeting at IETF 80 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 22:09:38 -0000 On Tue, Mar 22, 2011 at 03:41:36PM -0400, Andrew Sullivan wrote: > We will be discussing only two items: > > draft-ietf-dnsext-aliasing-requirements-01 > We are aiming primarily for a working session in which issues are > worked out, so if you have particular proposals (especially for text) > prior to the meeting, please post them to the list. This is particularly critical on the aliasing draft because we need to resolve what we can so we know what are still open questions ("Does anyone actually have this problem? If you do, tell us if this mechanism solves it. If you don't, we may have to keep looking, or decide no one really has it.") Not all comments on the -00 are in the -01, but many are. If you have new comments on the -01, please send text. Suzanne (as draft editor) From wjhns1@hardakers.net Wed Mar 23 07:05:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8683A691A for ; Wed, 23 Mar 2011 07:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld1cU4rv8wxj for ; Wed, 23 Mar 2011 07:05:37 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D003A3A6915 for ; Wed, 23 Mar 2011 07:05:37 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 77F122096A; Wed, 23 Mar 2011 07:06:50 -0700 (PDT) From: Wes Hardaker To: Andrew Sullivan References: <20110321222521.83729D084D9@drugs.dv.isc.org> <51C21B4C57014630B72B50B919271C89@local> <20110322143213.GU87529@shinkuro.com> Date: Wed, 23 Mar 2011 07:06:50 -0700 In-Reply-To: <20110322143213.GU87529@shinkuro.com> (Andrew Sullivan's message of "Tue, 22 Mar 2011 10:32:13 -0400") Message-ID: User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 14:05:38 -0000 >>>>> On Tue, 22 Mar 2011 10:32:13 -0400, Andrew Sullivan said: >> T+3: someone queries for the example.tld DS and gets a DS record set >> with the SHA1 DS for the new key. And a TTL picked by ??? >> [multiple options exist here]. AS> I don't see why multiple options exist there. The DS record is AS> authoritative data at the parent, and nowhere else. Therefore, it is AS> the job of the parent and nobody else to set the TTL. Because some upstreams let the user pick the TTL of the DS, wise or not. Now, you're right it is the parent's responsibility... But some outsource that to the child. AS> Certainly, if I ran the circus, that's how I'd do it. I think you'd run a fine circus Andrew. >> If a parent only allows updating of a single DS record at a time, AS> It does seem to me that it would be a wise idea to provide operational AS> advice I agree, it would. -- Wes Hardaker Cobham Analytic Solutions From ajs@shinkuro.com Wed Mar 23 07:21:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3743928C0DF for ; Wed, 23 Mar 2011 07:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0Io73U4Mctf for ; Wed, 23 Mar 2011 07:21:33 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 5C55728C0CE for ; Wed, 23 Mar 2011 07:21:33 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 967D21ECB408 for ; Wed, 23 Mar 2011 14:23:06 +0000 (UTC) Date: Wed, 23 Mar 2011 10:23:04 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110323142304.GF45735@shinkuro.com> References: <20110321222521.83729D084D9@drugs.dv.isc.org> <51C21B4C57014630B72B50B919271C89@local> <20110322143213.GU87529@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 14:21:34 -0000 On Wed, Mar 23, 2011 at 07:06:50AM -0700, Wes Hardaker wrote: > AS> I don't see why multiple options exist there. The DS record is > AS> authoritative data at the parent, and nowhere else. Therefore, it is > AS> the job of the parent and nobody else to set the TTL. > > Because some upstreams let the user pick the TTL of the DS, wise or not. I think we're saying the same thing. I just want to be careful about how we state it. "The user" isn't picking the TTL: only the authority server (i.e. the parent) can do that, in the strict sense. What is of course true is that the repository that generates the parent zone could accept requests from its client for a TTL value on that data. What I'm trying to be precise about is the difference between in-DNS-protocol data (and whose responsibility that is) versus data that arrives as part of the provisioning actions that cause the DNS data to be generated. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From wjhns1@hardakers.net Wed Mar 23 14:03:55 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834D63A6949 for ; Wed, 23 Mar 2011 14:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWQtIee22OFl for ; Wed, 23 Mar 2011 14:03:54 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id CEF153A68D6 for ; Wed, 23 Mar 2011 14:03:54 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id D755D20A04; Wed, 23 Mar 2011 14:05:07 -0700 (PDT) From: Wes Hardaker To: Andrew Sullivan References: <20110321222521.83729D084D9@drugs.dv.isc.org> <51C21B4C57014630B72B50B919271C89@local> <20110322143213.GU87529@shinkuro.com> <20110323142304.GF45735@shinkuro.com> Date: Wed, 23 Mar 2011 14:05:07 -0700 In-Reply-To: <20110323142304.GF45735@shinkuro.com> (Andrew Sullivan's message of "Wed, 23 Mar 2011 10:23:04 -0400") Message-ID: User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 21:03:55 -0000 >>>>> On Wed, 23 Mar 2011 10:23:04 -0400, Andrew Sullivan said: AS> I think we're saying the same thing. I just want to be careful about AS> how we state it. I agree. -- Wes Hardaker Cobham Analytic Solutions From wwwrun@rfc-editor.org Wed Mar 23 19:32:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2FCF3A67C0 for ; Wed, 23 Mar 2011 19:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayh6X4KeNpji for ; Wed, 23 Mar 2011 19:32:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id E53C83A67B2 for ; Wed, 23 Mar 2011 19:32:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 89176E0733; Wed, 23 Mar 2011 19:34:10 -0700 (PDT) To: hardaker@tislabs.com, rdroms.ietf@gmail.com, jari.arkko@piuha.net, ogud@ogud.com, ajs@shinkuro.com From: RFC Errata System Message-Id: <20110324023410.89176E0733@rfc-editor.org> Date: Wed, 23 Mar 2011 19:34:10 -0700 (PDT) Cc: matt@mattmccutchen.net, dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] [Technical Errata Reported] RFC4509 (2752) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 02:32:37 -0000 The following errata report has been submitted for RFC4509, "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4509&eid=2752 -------------------------------------- Type: Technical Reported by: Matt McCutchen Section: RFC header Original Text ------------- Corrected Text -------------- Updates: 4035 Notes ----- This document should update RFC 4035 because the statement in section 3, "Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset", modifies the rules for authenticating referrals in RFC 4035 section 5.2. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4509 (draft-ietf-dnsext-ds-sha256-05) -------------------------------------- Title : Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) Publication Date : May 2006 Author(s) : W. Hardaker Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From matt@mattmccutchen.net Wed Mar 23 19:46:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EFF53A67B7 for ; Wed, 23 Mar 2011 19:46:33 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K75rwsVuLT2w for ; Wed, 23 Mar 2011 19:46:32 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 599943A67B6 for ; Wed, 23 Mar 2011 19:46:32 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id D46C0280065 for ; Wed, 23 Mar 2011 19:48:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns; s=mattmccutchen.net; b=FTQHaas CS6uEw5OC8IoLbtsSoxi2YOyB9ATKfElytFEughTultvYF3M0avEwq1Len6jyPtJ wIuz7sE8AcvMMUirf13f3c3RuOx1NUzwFuw3Wzdb3xbTDmLeekvCrVMNm93YCH/+ 1o5Q+iiwCl5xHRAg36KJXbexGP/isWcWTGj8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:content-type:date:message-id :mime-version:content-transfer-encoding; s=mattmccutchen.net; bh=xa5IpJjk7ArOX9HiBYF1iOpbDA0=; b=tANxQ6yj99MRYL3/OWr+X4cUpaHj zSnRkHUiQmFX01zeFJeMhKXvRn7tlYw+bIB+CFnbCGzJ6O/gm8+VRVY0KAGghweY Sy5er2947CoH+PnNtkzdb9M/673Y4vnWYgtGBNfLn7bphj0RuEklclHCg3iga/8Z dKC9zNZdhtB/Fb8= Received: from [192.168.1.40] (pool-96-231-2-98.washdc.east.verizon.net [96.231.2.98]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPA id 84CC6280063 for ; Wed, 23 Mar 2011 19:48:06 -0700 (PDT) From: Matt McCutchen To: dnsext@ietf.org In-Reply-To: <51C21B4C57014630B72B50B919271C89@local> Content-Type: text/plain; charset="UTF-8" Date: Wed, 23 Mar 2011 22:48:05 -0400 Message-ID: <1300934885.2117.219.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 02:46:33 -0000 [Note, I made the initial allegation of this issue in the dane/keyassure group.] On Mon, 2011-23-21 at 23:13 -0000, George Barwood wrote: > Ok, I see it now, section 3 > > Validator implementations SHOULD ignore DS RRs containing SHA-1 > digests if DS RRs with SHA-256 digests are present in the DS RRset. I wasn't aware of this. I did not think to check the specifications of individual algorithms; I would have expected a specification that modifies the validation requirements like this to update RFC 4035. I have submitted an erratum to this effect. Ad-hoc SHOULD-level statements for validators are no way to achieve a fundamental security property, and leaving the implications for the DNS administrator as an exercise to the reader is no way to achieve interoperability. In my view, the issue cannot be considered resolved until there is a single document that states the uniformity requirement for DS records and a MUST-level requirement for validators in an algorithm-general way. -- Matt From ogud@ogud.com Wed Mar 23 19:54:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BD63A67D4 for ; Wed, 23 Mar 2011 19:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UxjfisKi4W6 for ; Wed, 23 Mar 2011 19:54:04 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A6BF43A67B6 for ; Wed, 23 Mar 2011 19:54:04 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2O2tZC8009179; Wed, 23 Mar 2011 22:55:35 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4D8AB2A3.6020500@ogud.com> Date: Wed, 23 Mar 2011 22:55:31 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: RFC Errata System References: <20110324023410.89176E0733@rfc-editor.org> In-Reply-To: <20110324023410.89176E0733@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com Subject: Re: [dnsext] [Technical Errata Reported] RFC4509 (2752) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 02:54:05 -0000 This errata is correct Olafur On 23/03/2011 10:34 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC4509, > "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4509&eid=2752 > > -------------------------------------- > Type: Technical > Reported by: Matt McCutchen > > Section: RFC header > > Original Text > ------------- > > > Corrected Text > -------------- > Updates: 4035 > > Notes > ----- > This document should update RFC 4035 because the statement in section 3, "Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset", modifies the rules for authenticating referrals in RFC 4035 section 5.2. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4509 (draft-ietf-dnsext-ds-sha256-05) > -------------------------------------- > Title : Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) > Publication Date : May 2006 > Author(s) : W. Hardaker > Category : PROPOSED STANDARD > Source : DNS Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG > > > From marka@isc.org Wed Mar 23 20:50:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564823A67E1 for ; Wed, 23 Mar 2011 20:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIUajC3KnI27 for ; Wed, 23 Mar 2011 20:50:06 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 2482A3A67DF for ; Wed, 23 Mar 2011 20:50: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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7665CC9423; Thu, 24 Mar 2011 03:51:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 ED058216C22; Thu, 24 Mar 2011 03:51:32 +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 50B9AD2F6ED; Thu, 24 Mar 2011 14:51:28 +1100 (EST) To: Matt McCutchen From: Mark Andrews References: <1300934885.2117.219.camel@localhost> In-reply-to: Your message of "Wed, 23 Mar 2011 22:48:05 EDT." <1300934885.2117.219.camel@localhost> Date: Thu, 24 Mar 2011 14:51:28 +1100 Message-Id: <20110324035128.50B9AD2F6ED@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 03:50:16 -0000 In message <1300934885.2117.219.camel@localhost>, Matt McCutchen writes: > [Note, I made the initial allegation of this issue in the dane/keyassure > group.] > > On Mon, 2011-23-21 at 23:13 -0000, George Barwood wrote: > > Ok, I see it now, section 3 > > > > Validator implementations SHOULD ignore DS RRs containing SHA-1 > > digests if DS RRs with SHA-256 digests are present in the DS RRset. > > I wasn't aware of this. I did not think to check the specifications of > individual algorithms; I would have expected a specification that > modifies the validation requirements like this to update RFC 4035. I > have submitted an erratum to this effect. > > Ad-hoc SHOULD-level statements for validators are no way to achieve a > fundamental security property, and leaving the implications for the DNS > administrator as an exercise to the reader is no way to achieve > interoperability. In my view, the issue cannot be considered resolved > until there is a single document that states the uniformity requirement > for DS records and a MUST-level requirement for validators in an > algorithm-general way. The time you get a failure is if there are differing DS algorithm sets for the same DNSKEY algorithm and you are pre-publishing DS and the pre-published DS has a SHA256 DS when the current DS for that algorithm doesn't have a SHA256 DS but has a SHA1 DS. This will leave you with a SHA256 DS pointing to a non-existing DNSKEY. If one is not pre-publishing DS records I don't see a failure case. Treating the zone as insecure is not a failure. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From matt@mattmccutchen.net Wed Mar 23 21:17:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4464C3A67C2 for ; Wed, 23 Mar 2011 21:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FP-uRsQZ2NRR for ; Wed, 23 Mar 2011 21:17:13 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 50E5C3A67B2 for ; Wed, 23 Mar 2011 21:17:13 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id B83533BC06A; Wed, 23 Mar 2011 21:18:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=uM78u0DlqTxRHGNFyAd9h4aK/JOuyaASh/eRqLSJYBX amDOWxmLkuhfKnXiT/Wc5JaQSj6mbfnf1Hg5aPkGaa1NfuhWtxSBAouY+LMH6HPJ 6poOLhh+XuBFv1r9PByY20Rv1A+q07XGv0UhViBLKlnIiWBSNlh+OUkYVcu74joo = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=GIrhHI7F4bDS+G4ZALS3EvYYV2A=; b=LdWhVr9XLh +32R07WyOfB24GNMUBPYVNGIAAB4dIOd7hsN+fUR+xu0YwWdWR6FKOi4omoItuom PY8XefIKSA2EFFVPxt0A1lahGjsP7QEjgFemrV7PDgsotk6eYdBA5RAb4oKoZC6x JTXo0Et8gGi2EbzF1hiiNAKc4tedmI3OQ= Received: from [192.168.1.40] (pool-96-231-2-98.washdc.east.verizon.net [96.231.2.98]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPA id E74A13BC062; Wed, 23 Mar 2011 21:18:46 -0700 (PDT) From: Matt McCutchen To: Mark Andrews In-Reply-To: <20110324035128.50B9AD2F6ED@drugs.dv.isc.org> References: <1300934885.2117.219.camel@localhost> <20110324035128.50B9AD2F6ED@drugs.dv.isc.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 Mar 2011 00:18:44 -0400 Message-ID: <1300940324.2117.247.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 04:17:14 -0000 On Thu, 2011-03-24 at 14:51 +1100, Mark Andrews wrote: > The time you get a failure is if there are differing DS algorithm > sets for the same DNSKEY algorithm and you are pre-publishing DS > and the pre-published DS has a SHA256 DS when the current DS for > that algorithm doesn't have a SHA256 DS but has a SHA1 DS. This > will leave you with a SHA256 DS pointing to a non-existing DNSKEY. > > If one is not pre-publishing DS records I don't see a failure case. Right. Since an entire set of DNSKEYs is published, there are more chances for things to work correctly, compared to DANE where the TLS server presents just one of the designated certificates. > Treating the zone as insecure is not a failure. I disagree. People are beginning to use DNSSEC to store opt-in indications for application-level security mechanisms associated with DNS names, such that treating the zone as insecure and allowing the indication to be removed would be a security failure. You might think this is a bad idea, but the benefits of these mechanisms are compelling and I think it would make more sense to beef up DNSSEC to support them than to set up a parallel system. What case are you thinking of in which the zone would show up as insecure? -- Matt From marka@isc.org Wed Mar 23 23:33:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA54C3A6808 for ; Wed, 23 Mar 2011 23:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjYsKaY6L0-q for ; Wed, 23 Mar 2011 23:33:45 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id CF2573A67EE for ; Wed, 23 Mar 2011 23:33: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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id BDE7B5F985D; Thu, 24 Mar 2011 06:35:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 592B2216C22; Thu, 24 Mar 2011 06:35:01 +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 8DC31D342F5; Thu, 24 Mar 2011 17:34:57 +1100 (EST) To: Matt McCutchen From: Mark Andrews References: <1300934885.2117.219.camel@localhost> <20110324035128.50B9AD2F6ED@drugs.dv.isc.org><1300940324.2117.247.camel@localhost> In-reply-to: Your message of "Thu, 24 Mar 2011 00:18:44 EDT." <1300940324.2117.247.camel@localhost> Date: Thu, 24 Mar 2011 17:34:57 +1100 Message-Id: <20110324063457.8DC31D342F5@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] DS digest downgrade X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 06:33:45 -0000 In message <1300940324.2117.247.camel@localhost>, Matt McCutchen writes: > On Thu, 2011-03-24 at 14:51 +1100, Mark Andrews wrote: > > The time you get a failure is if there are differing DS algorithm > > sets for the same DNSKEY algorithm and you are pre-publishing DS > > and the pre-published DS has a SHA256 DS when the current DS for > > that algorithm doesn't have a SHA256 DS but has a SHA1 DS. This > > will leave you with a SHA256 DS pointing to a non-existing DNSKEY. > > > > If one is not pre-publishing DS records I don't see a failure case. > > Right. Since an entire set of DNSKEYs is published, there are more > chances for things to work correctly, compared to DANE where the TLS > server presents just one of the designated certificates. > > > Treating the zone as insecure is not a failure. > > I disagree. People are beginning to use DNSSEC to store opt-in > indications for application-level security mechanisms associated with > DNS names, such that treating the zone as insecure and allowing the > indication to be removed would be a security failure. You might think > this is a bad idea, but the benefits of these mechanisms are compelling > and I think it would make more sense to beef up DNSSEC to support them > than to set up a parallel system. > > What case are you thinking of in which the zone would show up as > insecure? Alg A has SHA1, ALG B has SHA1 + SHA256. Once you filter the SHA1 DS out you are left with just ALG B. > -- > Matt > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ogud@ogud.com Wed Mar 23 19:56:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A7D3A67B6 for ; Wed, 23 Mar 2011 19:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.059 X-Spam-Level: X-Spam-Status: No, score=-100.059 tagged_above=-999 required=5 tests=[AWL=-2.460, BAYES_00=-2.599, GB_SUMOF=5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMNrGdsN4mYs for ; Wed, 23 Mar 2011 19:56:26 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 906D23A67D9 for ; Wed, 23 Mar 2011 19:56:26 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2O2vtmr009215; Wed, 23 Mar 2011 22:57:55 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4D8AB330.5090504@ogud.com> Date: Wed, 23 Mar 2011 22:57:52 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: RFC Errata System References: <20110105221815.A7E0FE0701@rfc-editor.org> In-Reply-To: <20110105221815.A7E0FE0701@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 X-Mailman-Approved-At: Fri, 25 Mar 2011 08:15:13 -0700 Cc: sra@isc.org, gubailey@microsoft.com, dnsext@ietf.org, rdroms.ietf@gmail.com, jari.arkko@piuha.net, massey@cs.colostate.edu, roy.arends@telin.nl Subject: Re: [dnsext] [Technical Errata Reported] RFC4034 (2681) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 02:56:28 -0000 This errata is also correct, I ran into this same issue myself. Olafur On 05/01/2011 5:18 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC4034, > "Resource Records for the DNS Security Extensions". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4034&eid=2681 > > -------------------------------------- > Type: Technical > Reported by: Guillaume Bailey > > Section: B > > Original Text > ------------- > The key tag is the same for all DNSKEY algorithm types except > algorithm 1 (please see Appendix B.1 for the definition of the key > tag for algorithm 1). The key tag algorithm is the sum of the wire > format of the DNSKEY RDATA broken into 2 octet groups. First, the > RDATA (in wire format) is treated as a series of 2 octet groups. > These groups are then added together, ignoring any carry bits. > > > Corrected Text > -------------- > The key tag is the same for all DNSKEY algorithm types except > algorithm 1 (please see Appendix B.1 for the definition of the key > tag for algorithm 1). The key tag algorithm is the sum of the wire > format of the DNSKEY RDATA broken into 2 octet groups. First, the > RDATA (in wire format) is treated as a series of 2 octet groups. > These groups are then added together with at least 32-bit precision, > retaining any carry bits. The carry bits are then added to the result, > and finally, only the lower 16 bits of the result are used as the key > tag. > > > > Notes > ----- > This change comes from the example implementation. The accumulator, ac, is required ("assumed") to be 32-bits or larger, and the carry bits are added to the accumulator before returning: > > ac += (ac>> 16)& 0xFFFF; > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4034 (draft-ietf-dnsext-dnssec-records-11) > -------------------------------------- > Title : Resource Records for the DNS Security Extensions > Publication Date : March 2005 > Author(s) : R. Arends, R. Austein, M. Larson, D. Massey, S. Rose > Category : PROPOSED STANDARD > Source : DNS Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG > > > From paul.hoffman@vpnc.org Fri Mar 25 10:00:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027943A67D4 for ; Fri, 25 Mar 2011 10:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drmzhX8SKsrx for ; Fri, 25 Mar 2011 10:00:06 -0700 (PDT) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id B781E3A67B7 for ; Fri, 25 Mar 2011 10:00:05 -0700 (PDT) Received: from [10.0.2.202] ([212.47.23.197]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2PH1VdH060707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Mar 2011 10:01:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4D8AB330.5090504@ogud.com> Date: Fri, 25 Mar 2011 18:01:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7306D60F-AE42-466F-AED9-51C58E32299E@vpnc.org> References: <20110105221815.A7E0FE0701@rfc-editor.org> <4D8AB330.5090504@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1084) Cc: sra@isc.org, gubailey@microsoft.com, dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com, massey@cs.colostate.edu, roy.arends@telin.nl, RFC Errata System Subject: Re: [dnsext] [Technical Errata Reported] RFC4034 (2681) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 17:00:07 -0000 On Mar 24, 2011, at 3:57 AM, Olafur Gudmundsson wrote: > This errata is also correct, > I ran into this same issue myself. I am not an implementer, so I am not sure that what I say here is = correct. It sounds like the normative text in Appendix B does not match = the presumably normative "reference implementation" in C a few = paragraphs later. If so, why does the "reference implementation" win = over the C code? --Paul Hoffman From cet1@hermes.cam.ac.uk Fri Mar 25 12:43:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D673A682D for ; Fri, 25 Mar 2011 12:43:58 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifY4hSgYd0Iw for ; Fri, 25 Mar 2011 12:43:57 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id B35743A6774 for ; Fri, 25 Mar 2011 12:43:57 -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-1.csi.cam.ac.uk ([131.111.8.51]:49441) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1Q3Cwa-0008Vq-pf (Exim 4.72) (return-path ); Fri, 25 Mar 2011 19:45:12 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1Q3Cwa-0003we-06 (Exim 4.67) (return-path ); Fri, 25 Mar 2011 19:45:12 +0000 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.3); 25 Mar 2011 19:45:11 +0000 Date: 25 Mar 2011 19:45:11 +0000 From: Chris Thompson To: Paul Hoffman Message-ID: In-Reply-To: <7306D60F-AE42-466F-AED9-51C58E32299E@vpnc.org> References: <20110105221815.A7E0FE0701@rfc-editor.org> <4D8AB330.5090504@ogud.com> <7306D60F-AE42-466F-AED9-51C58E32299E@vpnc.org> X-Mailer: Prayer v1.3.3 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson X-Mailman-Approved-At: Fri, 25 Mar 2011 14:06:44 -0700 Cc: sra@isc.org, gubailey@microsoft.com, dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com, RFC Errata System , roy.arends@telin.nl, Olafur Gudmundsson , massey@cs.colostate.edu Subject: Re: [dnsext] [Technical Errata Reported] RFC4034 (2681) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 19:43:58 -0000 On Mar 25 2011, Paul Hoffman wrote: >On Mar 24, 2011, at 3:57 AM, Olafur Gudmundsson wrote: > >> This errata is also correct, >> I ran into this same issue myself. > >I am not an implementer, so I am not sure that what I say here is correct. >It sounds like the normative text in Appendix B does not match the presumably >normative "reference implementation" in C a few paragraphs later. If so, why >does the "reference implementation" win over the C code? Because it is what everyone has actually implemented? And it's not really clear which is more "normative", given text like * It is not necessary to use the following reference code verbatim, but * the numerical value of the Key Tag MUST be identical to what the reference * implementation would generate for the same input. It's bad enough that the tag calculation is a botched version of the ones-complement checksum in the first place, without trying to change it at this stage. -- 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 d3e3e3@gmail.com Fri Mar 25 10:49:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B51028C0CE for ; Fri, 25 Mar 2011 10:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.173 X-Spam-Level: X-Spam-Status: No, score=-104.173 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzSwyfJEoyhO for ; Fri, 25 Mar 2011 10:49:15 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B623D3A680D for ; Fri, 25 Mar 2011 10:49:14 -0700 (PDT) Received: by wyb29 with SMTP id 29so856148wyb.31 for ; Fri, 25 Mar 2011 10:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=MEqIJrACnHxqKs3tNplSK6qXSFnlqUsUlrRv2XrKwqs=; b=ceUS3WhpyTtMBD95v3gLZp5jLPHgbPRF+/UP3mDuX1IJbXikPrtZq1VIFLrkTjzfSt W0OtTZtctPAUgQo+ZFbAfzKsro98SywCl37rkvaSVAHcRiH1FfhLRBBk0wiuUAVGJpiT vQV2QsrDXdVBl+VzY/lQhB31epqlW3gGlJRxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=PC5sIBp6n/ZVF17FOQYFwqAcnhOjJ+XQBnKoNbhsVkfuFWsvfve3m1yWUoXUkeEfE7 N10uVoMD3swR8Ew49S3NSRbrvFvt7hCn4f5pN/94y0RKKa2V+Fh24tLz/yeT5L0ewUfe bwz+672NW9FcPQnc9p/L6NkMqiX1ApCLVYWbU= Received: by 10.227.139.89 with SMTP id d25mr1056252wbu.58.1301075449587; Fri, 25 Mar 2011 10:50:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.55.146 with HTTP; Fri, 25 Mar 2011 10:50:29 -0700 (PDT) In-Reply-To: <7306D60F-AE42-466F-AED9-51C58E32299E@vpnc.org> References: <20110105221815.A7E0FE0701@rfc-editor.org> <4D8AB330.5090504@ogud.com> <7306D60F-AE42-466F-AED9-51C58E32299E@vpnc.org> From: Donald Eastlake Date: Fri, 25 Mar 2011 13:50:29 -0400 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 25 Mar 2011 14:07:03 -0700 Cc: sra@isc.org, gubailey@microsoft.com, dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com, RFC Errata System , roy.arends@telin.nl, Olafur Gudmundsson , massey@cs.colostate.edu Subject: Re: [dnsext] [Technical Errata Reported] RFC4034 (2681) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 17:49:18 -0000 Perhaps because the reference code is unchanged from RFC 2535 and the newly synthesized text for RFC 4034 is therefore probably where the error is? Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Fri, Mar 25, 2011 at 1:01 PM, Paul Hoffman wrote= : > On Mar 24, 2011, at 3:57 AM, Olafur Gudmundsson wrote: > >> This errata is also correct, >> I ran into this same issue myself. > > I am not an implementer, so I am not sure that what I say here is correct= . It sounds like the normative text in Appendix B does not match the presum= ably normative "reference implementation" in C a few paragraphs later. If s= o, why does the "reference implementation" win over the C code? > > --Paul Hoffman > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From ogud@ogud.com Sat Mar 26 02:15:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2648C3A6904 for ; Sat, 26 Mar 2011 02:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6EDWBPWsxJs for ; Sat, 26 Mar 2011 02:15:31 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 28B0D3A6903 for ; Sat, 26 Mar 2011 02:15:31 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2Q9H5Os030285 for ; Sat, 26 Mar 2011 05:17:06 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4D8DAF0D.3000007@ogud.com> Date: Sat, 26 Mar 2011 05:17:01 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dnsext] CDN BOF Re: Uploaded: edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 09:15:32 -0000 On 17/02/2011 3:26 PM, Wilmer van der Gaast wrote: > On 9 February 2011 13:01, Wilmer van der Gaast wrote: >> Also, since the release of the last draft we have: >> There are also some drafts related to the "CDN" problem in general that have been published lately and there is going to be a BOF (see below) on the topic in Prague. I'm not sure exactly how this draft will play with that proposed work, update appreciated by someone that has read all the drafts. > Transport > > CDNI - Content Distribution Network Interconnection > > Description: There is an emerging requirement for interconnecting content delivery networks (CDNs) so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. This BOF is to discuss the proposed development of IETF standards to facilitate such CDN interconnection. These standards might include protocols for 1) exchange of metadata between CDNs, 2) exchange of transaction logs & monitoring information, 3) exchange of request-routing information, 4) exchange of policies & capabilities, and 5) content management/flushing. > BoF Chairs: TBD > BOF Proponents: Francois Le Faucheur ( flefauch@cisco.com), Ben Niven-Jenkins ( ben@niven-jenkins.co.uk), Emile Stephan ( emile.stephan@orange-ftgroup.com) > People expected: 50 > Length of session: 90-120 minutes > Conflicts to avoid: DECADE, NFSv4, STORM, ALTO, TSVWG, TSVAREA, APPSAREA, httpbis > WebEX: Yes > Responsible AD: David Harrington' > Goal: Charter a WG > Agenda: agenda > Drafts: draft-jenkins-cdni-problem-statement, draft-watson-cdni-use-cases, draft-bertrand-cdni-use-cases, draft-lefaucheur-cdni-requirements > Draft Charter: TBD > Mailing List: cdni@ietf.org > Mailing List Archive: http://www.ietf.org/mail-archive/web/cdni/ > Status: Approved here are links to documents: http://tools.ietf.org/html/draft-jenkins-cdni-problem-statement http://tools.ietf.org/html/draft-lefaucheur-cdni-requirements http://tools.ietf.org/html/draft-bertrand-cdni-use-cases http://tools.ietf.org/html/draft-watson-cdni-use-cases Olafur Ps: New feature of the tools website is that draft name w/o version number will bring up the latest version. From ben@niven-jenkins.co.uk Sat Mar 26 07:58:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C913D3A693D for ; Sat, 26 Mar 2011 07:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.568 X-Spam-Level: X-Spam-Status: No, score=-103.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6FQ-rosgH2P for ; Sat, 26 Mar 2011 07:58:10 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 83E193A693B for ; Sat, 26 Mar 2011 07:58:10 -0700 (PDT) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.202]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Q3Uxs-0006Ky-So; Sat, 26 Mar 2011 14:59:45 +0000 References: <4D8DAF0D.3000007@ogud.com> In-Reply-To: <4D8DAF0D.3000007@ogud.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <48977F6B-1D8D-478C-9984-585CBFC93453@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Sat, 26 Mar 2011 14:59:41 +0000 To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: dnsext@ietf.org Subject: Re: [dnsext] CDN BOF Re: Uploaded: edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 14:58:11 -0000 Olafur, Colleagues, On 26 Mar 2011, at 09:17, Olafur Gudmundsson wrote: > >=20 > On 17/02/2011 3:26 PM, Wilmer van der Gaast wrote: >> On 9 February 2011 13:01, Wilmer van der Gaast = wrote: >>> Also, since the release of the last draft we have: >>>=20 > >=20 >=20 > There are also some drafts related to the "CDN" problem in general = that have been published lately and there is going to be a BOF (see = below) on the topic in Prague. I'm not sure exactly how this draft will = play with that proposed work, update appreciated by someone that has = read all the drafts. >=20 The edns-client-subnet draft is complementary but not directly related = to the CDNI BoF. edns-client-subnet provides a mechanism to pass the subnet of the client = through to the authoritative DNS server to allow that server to return = more targetted responses. It could be useful, for example, for CDNs = deployed within ISP networks where the CDN caches are deployed closer to = the end users than the DNS infrastructure therefore enabling cache = selection to be performed based on the client's subnet rather than the = client's DNS server's subnet. The CDNI BoF is about interconnecting CDNs so that, for example, a CDN = with a limited geographical footprint can "hand over" delivery to a = different CDN for end users outside of its footprint. HTH Ben (CDNI BoF protagonist & co-author = draft-jenkins-cdni-problem-statement) > =09 >> Transport >>=20 >> CDNI - Content Distribution Network Interconnection >>=20 >> Description: There is an emerging requirement for interconnecting = content delivery networks (CDNs) so they can interoperate as an open = content delivery infrastructure for the end-to-end delivery of content = from Content Service Providers (CSPs) to end users. This BOF is to = discuss the proposed development of IETF standards to facilitate such = CDN interconnection. These standards might include protocols for 1) = exchange of metadata between CDNs, 2) exchange of transaction logs & = monitoring information, 3) exchange of request-routing information, 4) = exchange of policies & capabilities, and 5) content management/flushing. >> BoF Chairs: TBD >> BOF Proponents: Francois Le Faucheur ( flefauch@cisco.com), Ben = Niven-Jenkins ( ben@niven-jenkins.co.uk), Emile Stephan ( = emile.stephan@orange-ftgroup.com) >> People expected: 50 >> Length of session: 90-120 minutes >> Conflicts to avoid: DECADE, NFSv4, STORM, ALTO, TSVWG, TSVAREA, = APPSAREA, httpbis >> WebEX: Yes >> Responsible AD: David Harrington' >> Goal: Charter a WG >> Agenda: agenda >> Drafts: draft-jenkins-cdni-problem-statement, = draft-watson-cdni-use-cases, draft-bertrand-cdni-use-cases, = draft-lefaucheur-cdni-requirements >> Draft Charter: TBD >> Mailing List: cdni@ietf.org >> Mailing List Archive: http://www.ietf.org/mail-archive/web/cdni/ >> Status: Approved >=20 > here are links to documents: >=20 > http://tools.ietf.org/html/draft-jenkins-cdni-problem-statement > http://tools.ietf.org/html/draft-lefaucheur-cdni-requirements > http://tools.ietf.org/html/draft-bertrand-cdni-use-cases > http://tools.ietf.org/html/draft-watson-cdni-use-cases >=20 > Olafur >=20 > Ps: New feature of the tools website is that draft name w/o version = number will bring up the latest version. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From paul.hoffman@vpnc.org Sat Mar 26 00:04:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049643A68E7 for ; Sat, 26 Mar 2011 00:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlMwTz9qg0S6 for ; Sat, 26 Mar 2011 00:04:44 -0700 (PDT) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id E14623A68E2 for ; Sat, 26 Mar 2011 00:04:43 -0700 (PDT) Received: from [10.0.2.202] ([212.47.23.197]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2Q767qh099156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 26 Mar 2011 00:06:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sat, 26 Mar 2011 08:06:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0CB2DEE6-511A-48FA-9BEF-4560D28EBB0F@vpnc.org> References: <20110105221815.A7E0FE0701@rfc-editor.org> <4D8AB330.5090504@ogud.com> <7306D60F-AE42-466F-AED9-51C58E32299E@vpnc.org> To: cet1@cam.ac.uk X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sat, 26 Mar 2011 09:57:59 -0700 Cc: sra@isc.org, gubailey@microsoft.com, dnsext@ietf.org, jari.arkko@piuha.net, rdroms.ietf@gmail.com, massey@cs.colostate.edu, roy.arends@telin.nl, Olafur Gudmundsson , RFC Errata System Subject: Re: [dnsext] [Technical Errata Reported] RFC4034 (2681) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 07:04:45 -0000 On Mar 25, 2011, at 8:45 PM, Chris Thompson wrote: > Because it is what everyone has actually implemented? That works for me. If it is the case, it should be stated in the Errata = report. --Paul Hoffman From ted.ietf@gmail.com Sat Mar 26 10:50:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E1B3A6955 for ; Sat, 26 Mar 2011 10:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04S49vdzmOf8 for ; Sat, 26 Mar 2011 10:50:22 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2F9D63A67EC for ; Sat, 26 Mar 2011 10:50:15 -0700 (PDT) Received: by iwn39 with SMTP id 39so1872318iwn.31 for ; Sat, 26 Mar 2011 10:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=DVJlOCqugNQEtpGN4hFqDdYjTm2P4zFGF+qGZfnH9wk=; b=map8/EhFHfQBbsM5bmcCNaVtuVP75fp1AeVE6meGCsxLv2oWk3AVHVydf1dacvKp3q eWOxv1mfPkrBOiofGZyBTyzZnYckZmjvHSXB3IFSL8S9B93qk4ezRTRoUlJqOvmcF8No rOxQAz+t0bIxRSgRZH+YM4hO1PdY2PEoroPJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=h1MWFfx6jw+05jb/bkaRo/iwjV/kkOMfBISQGeCg7TAKnG8ETGEp3CZ0Cc1xnR5k/3 K6TkMLYtqBFGEfXeCLS191dItVc4EXkA6kBgje66E/mQgJCO0rD9nS4w/fFjSj8o8UYd YiaC6E8RMdkQ7rXvFH6o6ELlyqO7EHt8+67Zk= MIME-Version: 1.0 Received: by 10.231.177.193 with SMTP id bj1mr2079205ibb.145.1301161911251; Sat, 26 Mar 2011 10:51:51 -0700 (PDT) Received: by 10.231.39.76 with HTTP; Sat, 26 Mar 2011 10:51:51 -0700 (PDT) Date: Sat, 26 Mar 2011 10:51:51 -0700 Message-ID: From: Ted Hardie To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=001636e0b90b83f466049f665d09 Subject: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 17:50:24 -0000 --001636e0b90b83f466049f665d09 Content-Type: text/plain; charset=ISO-8859-1 The draft under discussion was updated just before the meeting, and it has some useful updates. I think, however, it is anxious to scope the problem in ways that leave out what I believe is a well-recognized aspect of the basic desire of those who brought the work forward. The draft says: To some extent, the desired behavior can be described: "identical DNS resolution" means that the process of resolving two domain names will end with the same result, in most cases the same IP address. In the history of DNS protocol development, there have been two attempts to specify such "identical resolution" behavior:CNAME[RFC1034] which maps or redirects itself, and DNAME[RFC2672] which maps or redirects its descendants. In the case of bundles or groups of names, however, some operators have asserted they need identical DNS resolution at all levels' domain names, including the domain name itself and its descendants. But the reality is that the operators actually want the applications to treat two domain names as the same. That's a lot harder than simply having the same IP returned when looking up an A record at each one. Especially in the case of secured zones, it involves issuing multiple certificates or certs that cover both, and otherwise ensuring that whatever services are present at that IP can effectively handle either name. It's moderately obvious that this is a tougher job than putting in a CNAME or DNAME. It is possible to store additional data in the DNS that asserts X=Y for some values of X, Y, and equals, and we could, theoretically, mint records that had appropriately scoped forward knowledge about other equivalent domains. Where apparent administrative domains are crossed, it may take additional work to check that all parties concur. It gets ugly fast, but it may be better than the alternate of brute-force registration. The real trouble, though, is getting applications to check for the existence of such records. The DNS is a known-item lookup protocol, and it basically has to return the information that corresponds to the question that was asked. It can return additional data, but if it does so, there is a fairly serious risk that only the answer to the question asked will be stored and forwarded to the consuming application. The only way around that that I can see at the moment is to either declare one record to be canonical (forcing applications to "correct" any names they are currently using to the canonical name) or use an additional layer of indirection so that all of the records that are the same point to some meta-target. That might work--it's the same basic use of pointers that's already present in CNAME, but it requires a pointer from all the "same" domain names to some target that's not in the set. The structure of that record might be the same as the normal targets, using something like prefix addressing to signal its use; it might also have a different structure. But the problem remains daunting. Even if DNSEXT creates the perfect record for sameness, we still have to get apps to check it--and that suggests to me designing the system for that goal should be a primary consideration in the design space. --001636e0b90b83f466049f665d09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The draft under discussion=A0 was updated just before the meeting, and it h= as some useful updates. =A0I think, however, it is anxious to scope the pro= blem in ways that leave out what I believe is a well-recognized aspect of t= he basic desire of those who brought the work forward. =A0The draft says:

=A0 To some extent, the desired behavior can be described: "i= dentical DNS
=A0 resolution" means that the process of resolving t= wo domain names will
=A0 end with the same result, in most cases the sa= me IP address. =A0In the
=A0 history of DNS protocol development, there have been two attempts to =A0 specify such "identical resolution" behavior:CNAME[RFC1034= ] which
=A0 maps or redirects itself, and DNAME[RFC2672] which maps or = redirects
=A0 its descendants. =A0In the case of bundles or groups of names, however= ,
=A0 some operators have asserted they need identical DNS resolution a= t
=A0 all levels' domain names, including the domain name itself an= d its
=A0 descendants.

But the reality is that the operators actually wa= nt the applications to treat two domain names as the same. =A0That's a = lot harder than simply having the same IP returned when looking up an A rec= ord at each one. =A0Especially in the case of secured zones, it involves is= suing multiple certificates or certs that cover both, and otherwise ensurin= g that whatever services are present at that IP can effectively handle eith= er name. =A0It's moderately obvious that this is a tougher job than put= ting in a CNAME or DNAME. =A0

It is possible to store additional data in the DNS that asserts X=3DY f= or some values of X, Y, and equals, and we could, theoretically, mint recor= ds that had appropriately scoped forward knowledge about other equivalent d= omains. Where apparent administrative domains are crossed, it may take addi= tional work to check that all parties concur. =A0It gets ugly fast, but it = may be better than the alternate of brute-force registration.

The real trouble, though, is getting applications to check for the exis= tence of such records. =A0The DNS is a known-item lookup protocol, and it b= asically has to return the information that corresponds to the question tha= t was asked. =A0It can return additional data, but if it does so, there is = a fairly serious risk that only the answer to the question asked will be st= ored and forwarded to the consuming application.

The only way around that that I can see at the moment is to either decl= are one record to be canonical (forcing applications to "correct"= any names they are currently using to the canonical name) or use an additi= onal layer of indirection so that all of the records that are the same poin= t to some meta-target. =A0That might work--it's the same basic use of p= ointers that's already present in CNAME, but it requires a pointer from= all the "same" domain names to some target that's not in the= set. =A0The structure of that record might be the same as the normal targe= ts, using something like prefix addressing to signal its use; it might also= have a different structure. =A0

But the problem remains daunting. =A0Even if DNSEXT creates the perfect= record for sameness, we still have to get apps to check it--and that sugge= sts to me designing the system for that goal should be a primary considerat= ion in the design space.
--001636e0b90b83f466049f665d09-- From johnl@iecc.com Sat Mar 26 13:32:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139453A6821 for ; Sat, 26 Mar 2011 13:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.742 X-Spam-Level: X-Spam-Status: No, score=-110.742 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4dOmtqzaNUN for ; Sat, 26 Mar 2011 13:32:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id B7F4B3A6811 for ; Sat, 26 Mar 2011 13:32:23 -0700 (PDT) Received: (qmail 95686 invoked from network); 26 Mar 2011 20:33:58 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 26 Mar 2011 20:33:58 -0000 Date: 26 Mar 2011 20:33:36 -0000 Message-ID: <20110326203336.44885.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 20:32:25 -0000 >But the reality is that the operators actually want the applications >to treat two domain names as the same. That's a lot harder than >simply having the same IP returned when looking up an A record at >each one. This seems blindingly obvious to me, but I get the impression that there is still a faction that thinks that if they can arrange for matching A records, they're done. >The only way around that that I can see at the moment is to either >declare one record to be canonical (forcing applications to "correct" >any names they are currently using to the canonical name) or use an >additional layer of indirection so that all of the records that are >the same point to some meta-target. Agreed. One point that I think is not well understood is that the structure in the DNS and what the users see need not be perfectly matched. In particular, it's quite possible for the DNS to have one canonical record with everything else pointing to it, but at the application level all the names look the same. If I were hacking on my web or mail servers to handle this stuff, a simple way to do the configuration would be to configure in the canonical name, and then set a flag saying also to handle all of the aliases. R's, John From vixie@isc.org Sat Mar 26 22:28:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270383A698E for ; Sat, 26 Mar 2011 22:28:20 -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.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOttyy6EoNbI for ; Sat, 26 Mar 2011 22:28:18 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 4E6883A68D7 for ; Sat, 26 Mar 2011 22:28:18 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D0D83A1037 for ; Sun, 27 Mar 2011 05:29:52 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "26 Mar 2011 20:33:36 GMT." <20110326203336.44885.qmail@joyce.lan> References: <20110326203336.44885.qmail@joyce.lan> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Sun, 27 Mar 2011 05:29:52 +0000 Message-ID: <92099.1301203792@nsa.vix.com> Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 05:28:20 -0000 > Date: 26 Mar 2011 20:33:36 -0000 > From: "John Levine" > > ... In particular, it's quite possible for the DNS to have one > canonical record with everything else pointing to it, but at the > application level all the names look the same. If I were hacking on > my web or mail servers to handle this stuff, a simple way to do the > configuration would be to configure in the canonical name, and then > set a flag saying also to handle all of the aliases. if we're allowed by the people asking for this to require dns client libraries and applications to have to be changed to handle a new kind of canonicalization before they'll be able to handle the new definition of "sameness" then this is a practical approach. 'dns client libraries and applications' means the whole internet, so i naturally assumed that this approach was out of scope. From woolf@isc.org Sun Mar 27 02:12:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA6A3A68F9 for ; Sun, 27 Mar 2011 02:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8B0Ktai4+6B for ; Sun, 27 Mar 2011 02:12:27 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id D1FFA3A68F5 for ; Sun, 27 Mar 2011 02:12:26 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 61FD9C9423; Sun, 27 Mar 2011 09:14:00 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id 492A4216C33; Sun, 27 Mar 2011 09:14:00 +0000 (UTC) Date: Sun, 27 Mar 2011 09:14:00 +0000 From: Suzanne Woolf To: Paul Vixie Message-ID: <20110327091400.GA1318@bikeshed.isc.org> References: <20110326203336.44885.qmail@joyce.lan> <92099.1301203792@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92099.1301203792@nsa.vix.com> User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 09:12:28 -0000 On Sun, Mar 27, 2011 at 05:29:52AM +0000, Paul Vixie wrote: > > Date: 26 Mar 2011 20:33:36 -0000 > > From: "John Levine" > > > > ... In particular, it's quite possible for the DNS to have one > > canonical record with everything else pointing to it, but at the > > application level all the names look the same. If I were hacking on > > my web or mail servers to handle this stuff, a simple way to do the > > configuration would be to configure in the canonical name, and then > > set a flag saying also to handle all of the aliases. In terms of where we are with the problem statement: I think we've determined that we can assume a canonical or base name, with others pointing to it, is not only OK but the only practical approach, since a more complete isomorphism is hard to describe and may be impossible in the current DNS. Where we still have some thinking to do (IMHO, but as doc editor) is in chracterizing the need, if any, for some property of "sameness" or "aliases-of" amongst a group of names such that the application doesn't just get what it would have gotten if the alias was the canonical name in the first place. >From the registry provisioning side, what seems to be wanted is "the applicaton can get an identical result but for less work on the part of the provisioning registry/registries (and maybe more work on the part of the API/resolver) to simply provisioning all of the names in parallel." This may also be what applications want, but it doesn't include visibility to the application of other associated names, or the fact that there are any. Creating such a property and giving the applicaton access to it is a different requirement, and at the moment is hard to see clearly as an application issue, an API/interface issue, or a DNS protocol issue (in any combination). > if we're allowed by the people asking for this to require dns client > libraries and applications to have to be changed to handle a new kind > of canonicalization before they'll be able to handle the new definition > of "sameness" then this is a practical approach. > > 'dns client libraries and applications' means the whole internet, so i > naturally assumed that this approach was out of scope. It would be useful to document where we think this line is. Send text. thx, Suzanne From ted.ietf@gmail.com Sun Mar 27 02:34:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484C528C0F0 for ; Sun, 27 Mar 2011 02:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdSaQUhbSBQr for ; Sun, 27 Mar 2011 02:34:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3DEC83A68F4 for ; Sun, 27 Mar 2011 02:34:23 -0700 (PDT) Received: by iwn39 with SMTP id 39so2359041iwn.31 for ; Sun, 27 Mar 2011 02:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4nzrBAUW9ziWRmieeQRAIG2bUEJJxjlsAJuze8GdQM4=; b=Jeqn2VI9Ih4ueTQVfV1h7aT4yeqJ6eEl1WSDvhfAXZgvzyDZn73uviU1ysYlQGUfrN vymDV8F3D1wsP5qtQGhYY+SnBbfARHmYRzd1tzZF6JsX6wkx8HSnKiJThjXKJhpmCed0 CHzAG0gYv94WGtEGcXEwRTI1x5ANNdAgQpbFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tKGoZ9lc52g7DRL9ErA68BTGvcXLWXhe/2UuDaRCangCzHNR0eDbMbwE7EoFG0yiKB pVd5U63oPpgzd+KX8waQ9TtZQcbrWNSfDVqIhvAyPxMGzg4eUimG8qasAnvgyVsIL6XV SRnvw6EeI9XiEaO5vC+fCp9q2EprnyMJrvBl4= MIME-Version: 1.0 Received: by 10.231.61.65 with SMTP id s1mr2807401ibh.120.1301218559855; Sun, 27 Mar 2011 02:35:59 -0700 (PDT) Received: by 10.231.39.76 with HTTP; Sun, 27 Mar 2011 02:35:59 -0700 (PDT) In-Reply-To: <20110327091400.GA1318@bikeshed.isc.org> References: <20110326203336.44885.qmail@joyce.lan> <92099.1301203792@nsa.vix.com> <20110327091400.GA1318@bikeshed.isc.org> Date: Sun, 27 Mar 2011 11:35:59 +0200 Message-ID: From: Ted Hardie To: Suzanne Woolf Content-Type: multipart/alternative; boundary=001517741202090cbf049f738e48 Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 09:34:25 -0000 --001517741202090cbf049f738e48 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 27, 2011 at 11:14 AM, Suzanne Woolf wrote: > On Sun, Mar 27, 2011 at 05:29:52AM +0000, Paul Vixie wrote: > > > Date: 26 Mar 2011 20:33:36 -0000 > > > From: "John Levine" > > > > > > ... In particular, it's quite possible for the DNS to have one > > > canonical record with everything else pointing to it, but at the > > > application level all the names look the same. If I were hacking on > > > my web or mail servers to handle this stuff, a simple way to do the > > > configuration would be to configure in the canonical name, and then > > > set a flag saying also to handle all of the aliases. > > In terms of where we are with the problem statement: I think we've > determined that we can assume a canonical or base name, with others > pointing to it, is not only OK but the only practical approach, since > a more complete isomorphism is hard to describe and may be impossible > in the current DNS. > > Where we still have some thinking to do (IMHO, but as doc editor) is > in chracterizing the need, if any, for some property of "sameness" or > "aliases-of" amongst a group of names such that the application > doesn't just get what it would have gotten if the alias was the > canonical name in the first place. > > I thought I was with you until this. Presumably what it gets at the alias is a pointer to the canonical name, rather than what it would have gotten if the alias *was* the canonical name. The advantage of this synthesized CNAME-style approach is that the client libraries learn that what they originally handed the DNS was a pointer. In the ideal case, they can use that information to update their handling as well (within limits, of course) > From the registry provisioning side, what seems to be wanted is "the > applicaton can get an identical result but for less work on the part > of the provisioning registry/registries (and maybe more work on the > part of the API/resolver) to simply provisioning all of the names in > parallel." > > To put this another way, you don't have to provision everything to provide a complete set of pointers, as the first pointer tells the client how to synthesize them. > This may also be what applications want, but it doesn't include > visibility to the application of other associated names, or the fact > that there are any. Creating such a property and giving the applicaton > access to it is a different requirement, and at the moment is hard to > see clearly as an application issue, an API/interface issue, or a DNS > protocol issue (in any combination). > > So, just to restate this for my own jet-lagged benefit: the client hands a name to the DNS and gets back the information that it's a pointer to a canonical name, along with the data required to synthesize other names ("You asked for "blue.color.example.co.uk. All names under and including color.example.co.uk are cannonically at or under colour.example.co.uk"). So the application could get back "Here's the data for blue.colour.example.co.uk; the requested you handed me returned a pointer to here". If it doesn't understand that , it gets the data at the record stored at blue.colour.example.co.uk. Does this match what you're thinking? Ted > > if we're allowed by the people asking for this to require dns client > > libraries and applications to have to be changed to handle a new kind > > of canonicalization before they'll be able to handle the new definition > > of "sameness" then this is a practical approach. > > > > 'dns client libraries and applications' means the whole internet, so i > > naturally assumed that this approach was out of scope. > > It would be useful to document where we think this line is. Send text. > > > thx, > Suzanne > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --001517741202090cbf049f738e48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Mar 27, 2011 at 11:14 AM, Suzanne Woolf <woolf@isc.org> wrote:
On Sun, Mar 27, 2011 at 05:29:52AM +0000, Paul Vixie wrot= e:
> > Date: 26 Mar 2011 20:33:36 -0000
> > From: "John Levine" <johnl@iecc.com>
> >
> > ... =A0In particular, it's quite possible for the DNS to have= one
> > canonical record with everything else pointing to it, but at the<= br> > > application level all the names look the same. =A0If I were hacki= ng on
> > my web or mail servers to handle this stuff, a simple way to do t= he
> > configuration would be to configure in the canonical name, and th= en
> > set a flag saying also to handle all of the aliases.

In terms of where we are with the problem statement: I think we'v= e
determined that we can assume a canonical or base name, with others
pointing to it, is not only OK but the only practical approach, since
a more complete isomorphism is hard to describe and may be impossible
in the current DNS.

Where we still have some thinking to do (IMHO, but as doc editor) is
in chracterizing the need, if any, for some property of "sameness"= ; or
"aliases-of" amongst a group of names such that the application doesn't just get what it would have gotten if the alias was the
canonical name in the first place.


= I thought I was with you until this. =A0Presumably what it gets at the alia= s is a pointer to the canonical name, rather than what it would have gotten= if the alias *was* the canonical name. =A0The advantage of this synthesize= d CNAME-style approach is that the client libraries learn that what they or= iginally handed the DNS was a pointer. =A0In the ideal case, they can use t= hat information to update their handling as well (within limits, of course)=
=A0
>From the registry provisioning side, what seems to be wanted is "the applicaton can get an identical result but for less work on the part
of the provisioning registry/registries (and maybe more work on the
part of the API/resolver) to simply provisioning all of the names in
parallel."


To put this another way, you don't= have to provision everything to provide a complete set of pointers, as the= first pointer tells the client how to synthesize them.
=A0
This may also be what applications want, but it doesn't include
visibility to the application of other associated names, or the fact
that there are any. Creating such a property and giving the applicaton
access to it is a different requirement, and at the moment is hard to
see clearly as an application issue, an API/interface issue, or a DNS
protocol issue (in any combination).


So, just to re= state this for my own jet-lagged benefit: =A0the client hands a name to the= DNS and gets back the information that it's a pointer to a canonical n= ame, along with the data required to synthesize other names ("You aske= d for "blue.color.example.= co.uk. =A0All names under and including color.example.co.uk are cannonically at or under colour.example.co.uk"). =A0So the applic= ation could get back "Here's the data for blue.colour.example.co.uk; the requested you hande= d me returned a pointer to here". =A0If it doesn't understand that= , it gets the data at the record stored at blue.colour.example.co.uk.

Does this match what you're thinking?
Ted=A0
> if we're allowed by the people asking for this to require dns clie= nt
> libraries and applications to have to be changed to handle a new kind<= br> > of canonicalization before they'll be able to handle the new defin= ition
> of "sameness" then this is a practical approach.
>
> 'dns client libraries and applications' means the whole intern= et, so i
> naturally assumed that this approach was out of scope.

It would be useful to document where we think this line is. Send text= .


=A0
thx,
Suzanne
__________________________________= _____________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext

--001517741202090cbf049f738e48-- From johnl@iecc.com Sun Mar 27 12:24:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8C03A691D for ; Sun, 27 Mar 2011 12:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.754 X-Spam-Level: X-Spam-Status: No, score=-110.754 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izd9RtAbisUH for ; Sun, 27 Mar 2011 12:23:59 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id B98A43A681D for ; Sun, 27 Mar 2011 12:23:58 -0700 (PDT) Received: (qmail 94686 invoked from network); 27 Mar 2011 19:25:34 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Mar 2011 19:25:34 -0000 Date: 27 Mar 2011 19:25:12 -0000 Message-ID: <20110327192512.90424.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <92099.1301203792@nsa.vix.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 19:24:00 -0000 >if we're allowed by the people asking for this to require dns client >libraries and applications to have to be changed to handle a new kind >of canonicalization before they'll be able to handle the new >definition of "sameness" then this is a practical approach. It seems to me that we can divide applications into two groups. In one group, the client uses the name to find a server, but the name never appears in the data stream or only appears as a comment. This includes FTP, SSH, POP, and IMAP. Something like BNAME would be adequate to make names look the same to users. I'd say these applications don't know what their names are. In the other group, the domain name appears in the data stream, and the server does something with it beyond resolving it to an A or AAAA record. The standard examples are SMTP and HTTP. These apps do know what their names are, and the only alternatives I see are a great deal of manual provisioning, or else they learn how to check the DNS to see whether a hitherto unknown name in the data stream is an alias of a canonical name that it does know. So, yeah, the applications will eventually have to change. >From the point of view of DNS design, I'd want something that returns an appropriate A or AAAA for the first group, and offers a straightforward way for the second group to see what's an alias of what. For a transition, it's still possible to configure the second group manually, but it'd be a lot easier if they got smarter so people didn't have to do so. R's, John From vixie@isc.org Sun Mar 27 14:35:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADFC3A696D for ; Sun, 27 Mar 2011 14:35:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id febq1EMihIvt for ; Sun, 27 Mar 2011 14:35:31 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id AEC873A696C for ; Sun, 27 Mar 2011 14:35:30 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 64982A1067 for ; Sun, 27 Mar 2011 21:37:06 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "27 Mar 2011 19:25:12 GMT." <20110327192512.90424.qmail@joyce.lan> References: <20110327192512.90424.qmail@joyce.lan> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Sun, 27 Mar 2011 21:37:06 +0000 Message-ID: <47131.1301261826@nsa.vix.com> Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 21:35:31 -0000 > Date: 27 Mar 2011 19:25:12 -0000 > From: "John Levine" > > It seems to me that we can divide applications into two groups. In one > group, the client uses the name to find a server, but the name never > appears in the data stream or only appears as a comment. This includes > FTP, SSH, POP, and IMAP. Something like BNAME would be adequate to make > names look the same to users. I'd say these applications don't know > what their names are. > > In the other group, the domain name appears in the data stream, and > the server does something with it beyond resolving it to an A or AAAA > record. The standard examples are SMTP and HTTP. These apps do know > what their names are, and the only alternatives I see are a great deal > of manual provisioning, or else they learn how to check the DNS to see > whether a hitherto unknown name in the data stream is an alias of a > canonical name that it does know. So, yeah, the applications will > eventually have to change. > > From the point of view of DNS design, I'd want something that returns > an appropriate A or AAAA for the first group, and offers a > straightforward way for the second group to see what's an alias of > what. > > For a transition, it's still possible to configure the second group > manually, but it'd be a lot easier if they got smarter so people > didn't have to do so. these would be, in the parlance used when this topic was first introduced, "second class names". they can't be used as the target of MX or NS RRs, and they won't work for services whose servers have not been upgraded. if we're allowed to produce second class names as our answer to the problem then this is news to me but it massively simplifies the work. and we will have the burden of explaining to all of the IDN people that these "second class names" will have precisely zero value for the first few years and very little value for the first few decades. and, making them believe us. From woolf@isc.org Sun Mar 27 15:11:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4BC28C0CF for ; Sun, 27 Mar 2011 15:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SqIeIqlGNhM for ; Sun, 27 Mar 2011 15:11:44 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 270B93A6977 for ; Sun, 27 Mar 2011 15:11: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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 12E9BC941E; Sun, 27 Mar 2011 22:13:19 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id 06BCC216C33; Sun, 27 Mar 2011 22:13:19 +0000 (UTC) Date: Sun, 27 Mar 2011 22:13:19 +0000 From: Suzanne Woolf To: Ted Hardie Message-ID: <20110327221319.GA10959@bikeshed.isc.org> References: <20110326203336.44885.qmail@joyce.lan> <92099.1301203792@nsa.vix.com> <20110327091400.GA1318@bikeshed.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 22:11:45 -0000 On Sun, Mar 27, 2011 at 11:35:59AM +0200, Ted Hardie wrote: > So, just to restate this for my own jet-lagged benefit: the client hands a > name to the DNS and gets back the information that it's a pointer to a > canonical name, along with the data required to synthesize other names ("You > asked for "blue.color.example.co.uk. All names under and including > color.example.co.uk are cannonically at or under colour.example.co.uk"). So > the application could get back "Here's the data for > blue.colour.example.co.uk; the requested you handed me returned a pointer to > here". If it doesn't understand that , it gets the data at the record > stored at blue.colour.example.co.uk. > > Does this match what you're thinking? I think so, but I may well not be quite this smart :-) The two cases are "I understand the pointer and can do my own synthesis, give me all you got" and "I can't understand the pointer" and the server does the synthesis. In the first case, the application sees that the name it asked for was a pointer, and gets the rest of the set of associated names; in the second, it doesn't know and presumably doesn't care, but has no access to the rest of the names or the knowledge that they're associated together. The question I think I was asking was whether the application might sometimes prefer the simple answer, and not see the pointer or the other names. I'd like an answer along the lines of "Nope, it's always OK and sometimes preferred to expose the full complexity and let the application sort it out." But, you tell me. Suzanne From johnl@iecc.com Sun Mar 27 15:30:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3B828C173 for ; Sun, 27 Mar 2011 15:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.615 X-Spam-Level: X-Spam-Status: No, score=-110.615 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92eULkbLbT9r for ; Sun, 27 Mar 2011 15:30:00 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 88BDC28C16A for ; Sun, 27 Mar 2011 15:30:00 -0700 (PDT) Received: (qmail 18786 invoked from network); 27 Mar 2011 22:31:36 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Mar 2011 22:31:36 -0000 Date: 27 Mar 2011 22:31:14 -0000 Message-ID: <20110327223114.95877.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <47131.1301261826@nsa.vix.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 22:30:01 -0000 >these would be, in the parlance used when this topic was first >introduced, "second class names". they can't be used as the target >of MX or NS RRs, and they won't work for services whose servers have >not been upgraded. Seems to me we can do some process of elimination here. What people would like is a magic DNS hack so that you can tell your DNS server that a bunch of names are equivalent, and all the other software on the net treats those names just the same. Sorry, no pony. You can't have that. If it's an absolute requirement that no software outside the DNS can change, then our answer is clear: manual name bundling, with manual configuration of applications, we're done, so long. I don't hear much support for that. So what can we offer? If it's something like CLONE or BNAME, we offer an upgrade path. You're no worse off than you'd be with manual bundling and manual application configuration, and to the extent you upgrade your applications to know about the new DNS stuff, your configuration job gets easier. That's not as cool as the mythical magic hack. Will people find it useful? Having done my share of SMTP server hackery, I would. If it's as important to handle variant names as people say it is, they'll upgrade. If not, well, that's OK too. R's, John From woolf@isc.org Sun Mar 27 15:46:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0607B28C0EE for ; Sun, 27 Mar 2011 15:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KscgLWqp-6ia for ; Sun, 27 Mar 2011 15:46:14 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id D913028C0E7 for ; Sun, 27 Mar 2011 15:46:13 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 249E1C941E; Sun, 27 Mar 2011 22:47:49 +0000 (UTC) (envelope-from woolf@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10265) id 1B717216C36; Sun, 27 Mar 2011 22:47:49 +0000 (UTC) Date: Sun, 27 Mar 2011 22:47:49 +0000 From: Suzanne Woolf To: Paul Vixie Message-ID: <20110327224749.GB10959@bikeshed.isc.org> References: <20110327192512.90424.qmail@joyce.lan> <47131.1301261826@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47131.1301261826@nsa.vix.com> User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 22:46:15 -0000 On Sun, Mar 27, 2011 at 09:37:06PM +0000, Paul Vixie wrote: > if we're allowed to produce second class names as our answer to the problem > then this is news to me but it massively simplifies the work. and we will > have the burden of explaining to all of the IDN people that these "second > class names" will have precisely zero value for the first few years and > very little value for the first few decades. and, making them believe us. Well....I hope they will speak for themselves, but I think at this point that what "the IDN people" want from the DNS people is some real sense of what's possible, with roughly what tradeoffs. I think they want any news we can give them, even if it's bad (and I'm not even sure this is bad news). We can go into this a little more (briefly) in the session Monday afternoon-- Andrew and anyone else who was in the ICANN IDN meetings in San Francisco can probably shed some light. Suzanne From marka@isc.org Sun Mar 27 18:46:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB58B3A6765 for ; Sun, 27 Mar 2011 18:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgWD9kOyaShR for ; Sun, 27 Mar 2011 18:45:47 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 519A83A6452 for ; Sun, 27 Mar 2011 18:45:47 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 0E9B8C941E; Mon, 28 Mar 2011 01:47:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [77.78.82.82]) (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 61951216C22; Mon, 28 Mar 2011 01:47:20 +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 6F0F9D8E7E9; Mon, 28 Mar 2011 12:47:17 +1100 (EST) To: "John Levine" From: Mark Andrews References: <20110327192512.90424.qmail@joyce.lan> In-reply-to: Your message of "27 Mar 2011 19:25:12 -0000." <20110327192512.90424.qmail@joyce.lan> Date: Mon, 28 Mar 2011 12:47:17 +1100 Message-Id: <20110328014717.6F0F9D8E7E9@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 01:46:22 -0000 In message <20110327192512.90424.qmail@joyce.lan>, "John Levine" writes: > >if we're allowed by the people asking for this to require dns client > >libraries and applications to have to be changed to handle a new kind > >of canonicalization before they'll be able to handle the new > >definition of "sameness" then this is a practical approach. > > It seems to me that we can divide applications into two groups. In one > group, the client uses the name to find a server, but the name never > appears in the data stream or only appears as a comment. This includes > FTP, SSH, POP, and IMAP. Something like BNAME would be adequate to make > names look the same to users. I'd say these applications don't know > what their names are. > > In the other group, the domain name appears in the data stream, and > the server does something with it beyond resolving it to an A or AAAA > record. The standard examples are SMTP and HTTP. These apps do know > what their names are, and the only alternatives I see are a great deal > of manual provisioning, or else they learn how to check the DNS to see > whether a hitherto unknown name in the data stream is an alias of a > canonical name that it does know. So, yeah, the applications will > eventually have to change. And SMTP had it correct for the second group. If the SMTP client sees the CNAME it re-writes the names in the SMTP exchange to use the cannonical host name. The SMTP server never see the alias. HTTP administrators often miss use CNAME. "www.example.net CNAME example.net" where the same content is returned regardless of the the presense of www in the HTTP stream is correct usage of CNAME. If you use CNAME and you get different content then you are miss using CNAME. It's not being using to find the cannonical name for the host. Whether it is a virtual host or a name virtual host, the target of the CNAME record is not the cannonical host name of the (named) virtual host. It is the hosting server for that site and that is a very different thing. > >From the point of view of DNS design, I'd want something that returns > an appropriate A or AAAA for the first group, and offers a > straightforward way for the second group to see what's an alias of > what. > > For a transition, it's still possible to configure the second group > manually, but it'd be a lot easier if they got smarter so people > didn't have to do so. > > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohta@necom830.hpcl.titech.ac.jp Sun Mar 27 19:44:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3B73A67A6 for ; Sun, 27 Mar 2011 19:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.086 X-Spam-Level: X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HONmKKZahgi for ; Sun, 27 Mar 2011 19:44:02 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 9255F3A67A4 for ; Sun, 27 Mar 2011 19:44:01 -0700 (PDT) Received: (qmail 87438 invoked from network); 28 Mar 2011 03:07:30 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 28 Mar 2011 03:07:30 -0000 Message-ID: <4D8FF63E.9000802@necom830.hpcl.titech.ac.jp> Date: Mon, 28 Mar 2011 11:45:18 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110327192512.90424.qmail@joyce.lan> <20110328014717.6F0F9D8E7E9@drugs.dv.isc.org> In-Reply-To: <20110328014717.6F0F9D8E7E9@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 02:44:02 -0000 Mark Andrews wrote: > And SMTP had it correct for the second group. If the SMTP client > sees the CNAME it re-writes the names in the SMTP exchange to use > the cannonical host name. The SMTP server never see the alias. It does not forbid RFC822 headers contain aliases. E-mail recipients may change their behavior based on the domain names of senders in RFC822 headers. > If you use CNAME and you get different content then you are miss > using CNAME. It's not being using to find the cannonical name for > the host. Not at all. Masataka Ohta From johnl@iecc.com Sun Mar 27 19:48:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416CF3A67AA for ; Sun, 27 Mar 2011 19:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.772 X-Spam-Level: X-Spam-Status: No, score=-110.772 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbXO2q6WkNf2 for ; Sun, 27 Mar 2011 19:48:34 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 12C5A3A67A6 for ; Sun, 27 Mar 2011 19:48:33 -0700 (PDT) Received: (qmail 53907 invoked from network); 28 Mar 2011 02:50:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=d292.4d8ff762.k1103; i=johnl@submit.iecc.com; bh=AuSjV+fTz9Q2r0dyqZAqZH/njBjtNGxWsgxvVIqMpG8=; b=EidhxfN6ZE7INidunLJS49vlgSsDCnHtnq571wgdHnsNLKUkwkJ6IHSaWFHvIswcQ5vkelCLnPdvtm/ZKAEb1ZBFIcLsCpnffih5nMzAO2okn4+PceF8bXd5sYn/Aa/ZiinBz6/xnVzHMT8JPF46b5yhkhqkffpCKhM9gh18LMo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 28 Mar 2011 02:49:48 -0000 Date: 27 Mar 2011 22:50:10 -0400 Message-ID: From: "John R. Levine" To: "Mark Andrews" In-Reply-To: <20110328014717.6F0F9D8E7E9@drugs.dv.isc.org> References: <20110327192512.90424.qmail@joyce.lan> <20110328014717.6F0F9D8E7E9@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 02:48:37 -0000 > And SMTP had it correct for the second group. If the SMTP client > sees the CNAME it re-writes the names in the SMTP exchange to use > the cannonical host name. The SMTP server never see the alias. Yes and no. That works OK if you expect the CNAME to be a nickname for the real name, and the user is happy to see his message headers rewriten to use the canonical name. It fails in the situation where the names are all equivalent, and you don't want the messages rewritten. It also doesn't address the security issue, if you want the owner of the canoninical name to have control over what can be aliased to it. > HTTP administrators often misuse CNAME. True, but the horse is dead, and the carcass was long ago sold for dogfood, so I don't see the point of dredging it up again. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From ck@nic.museum Sun Mar 27 23:09:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E8C3A6816 for ; Sun, 27 Mar 2011 23:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7eNeSGBqgIn for ; Sun, 27 Mar 2011 23:09:16 -0700 (PDT) Received: from nic.frd.net (nic.frd.net [83.145.59.99]) by core3.amsl.com (Postfix) with ESMTP id C8FCA3A67D0 for ; Sun, 27 Mar 2011 23:09:15 -0700 (PDT) Received: from [192.168.1.10] (h47n6-hy-d6.ias.bredband.telia.com [217.210.140.47]) (authenticated bits=0) by nic.frd.net (8.13.8/8.13.8) with ESMTP id p2S6AgOE001476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Mar 2011 08:10:42 +0200 Message-ID: <4D902663.5030107@nic.museum> Date: Mon, 28 Mar 2011 08:10:43 +0200 From: Cary Karp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Suzanne Woolf References: <20110327192512.90424.qmail@joyce.lan> <47131.1301261826@nsa.vix.com> <20110327224749.GB10959@bikeshed.isc.org> In-Reply-To: <20110327224749.GB10959@bikeshed.isc.org> X-Enigmail-Version: 1.1.1 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.5 (nic.frd.net [83.145.59.99]); Mon, 28 Mar 2011 08:10:42 +0200 (CEST) X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner-ID: p2S6AgOE001476 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: ck@nic.museum Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 06:09:17 -0000 Quoting Suzanne > Well....I hope they will speak for themselves, but I think at this > point that what "the IDN people" want from the DNS people is some real > sense of what's possible, with roughly what tradeoffs. I think they > want any news we can give them, even if it's bad (and I'm not even > sure this is bad news). > > We can go into this a little more (briefly) in the session Monday > afternoon-- Andrew and anyone else who was in the ICANN IDN meetings > in San Francisco can probably shed some light. The impression I got from the ICANN IDN meetings in San Francisco was that the people who frequent such events have a strong qualitative sense of there being a problem but haven't yet managed to articulate it clearly, much less solve it. What might constitute a solution from their perspective is similarly elusive, but in ICANN terms would mean something that can serve as a basis for "consensus policies" (the sidestepping of which caused the present headache, in the first place). The expectation on the ICANN side has always been that the technical community, by virtue of its superior understanding of the quantifiable intricacies of the DNS, would be able to extrapolate whatever it needs to know about "the problem" from the discussion as it is being conducted in the ICANN venue. There is no basis for assuming that the potential insufficiency of that belief can be successfully communicated, so the best we're going to be able to do here is second guess something that might actually help. If that were an unequivocal statement of bad news, I have no idea how it would be received, but suspect that it's unsafe to make any assumptions about its potential for bringing the discussion to an end. /Cary From lee@cnnic.cn Sun Mar 27 23:48:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B363A6876 for ; Sun, 27 Mar 2011 23:48:36 -0700 (PDT) X-Quarantine-ID: <7oOv1jvE91Ba> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oOv1jvE91Ba for ; Sun, 27 Mar 2011 23:48:35 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id A90FC3A686C for ; Sun, 27 Mar 2011 23:48:34 -0700 (PDT) Received: (eyou send program); Mon, 28 Mar 2011 14:50:11 +0800 Message-ID: <501295011.05442@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [130.129.68.30]) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 28 Mar 2011 14:50:11 +0800 Message-ID: <4D902F9E.8050208@cnnic.cn> Date: Mon, 28 Mar 2011 14:50:06 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Cary Karp References: <20110327192512.90424.qmail@joyce.lan> <47131.1301261826@nsa.vix.com> <20110327224749.GB10959@bikeshed.isc.org> <501292684.25091@cnnic.cn> In-Reply-To: <501292684.25091@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lee@cnnic.cn List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 06:48:36 -0000 From my impression in ICANN meeting in SF, people with IDN variant issues want IETF give a perfect solution or give a answer if having solution or not, but actually even IETF give solution, it's impossible to solve issues that ICANN people concerns, to develop the standard and deploy the software is a very long term solution. For this draft, we try to define the problem statement, but how to solve, and if we should solve it with adding new RR, is to be discussed. Regards, -- Xiaodong Lee, CNNIC On 2011/3/28 14:10, Cary Karp wrote: > Quoting Suzanne > >> Well....I hope they will speak for themselves, but I think at this >> point that what "the IDN people" want from the DNS people is some real >> sense of what's possible, with roughly what tradeoffs. I think they >> want any news we can give them, even if it's bad (and I'm not even >> sure this is bad news). >> >> We can go into this a little more (briefly) in the session Monday >> afternoon-- Andrew and anyone else who was in the ICANN IDN meetings >> in San Francisco can probably shed some light. > The impression I got from the ICANN IDN meetings in San Francisco was > that the people who frequent such events have a strong qualitative sense > of there being a problem but haven't yet managed to articulate it > clearly, much less solve it. What might constitute a solution from their > perspective is similarly elusive, but in ICANN terms would mean > something that can serve as a basis for "consensus policies" (the > sidestepping of which caused the present headache, in the first place). > > The expectation on the ICANN side has always been that the technical > community, by virtue of its superior understanding of the quantifiable > intricacies of the DNS, would be able to extrapolate whatever it needs > to know about "the problem" from the discussion as it is being conducted > in the ICANN venue. There is no basis for assuming that the potential > insufficiency of that belief can be successfully communicated, so the > best we're going to be able to do here is second guess something that > might actually help. If that were an unequivocal statement of bad news, > I have no idea how it would be received, but suspect that it's unsafe to > make any assumptions about its potential for bringing the discussion to > an end. > > /Cary > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From vixie@isc.org Sun Mar 27 23:49:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2101A3A6875 for ; Sun, 27 Mar 2011 23:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxuJQ9wy+uYp for ; Sun, 27 Mar 2011 23:49:47 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 2175D3A686C for ; Sun, 27 Mar 2011 23:49:47 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 21DD2A106B for ; Mon, 28 Mar 2011 06:51:22 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "27 Mar 2011 22:31:14 GMT." <20110327223114.95877.qmail@joyce.lan> References: <20110327223114.95877.qmail@joyce.lan> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 28 Mar 2011 06:51:22 +0000 Message-ID: <78351.1301295082@nsa.vix.com> Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 06:49:48 -0000 > Date: 27 Mar 2011 22:31:14 -0000 > From: "John Levine" > ... > If it's an absolute requirement that no software outside the DNS can > change, then our answer is clear: manual name bundling, with manual > configuration of applications, we're done, so long. I don't hear much > support for that. let's get consensus around these as our only alternatives and if so publish the finding and ask for instructions. right now the fact that all we can offer is second class names is private dnsext-only opinion and needs to be upgraded to public knowledge so as to inform a decision. > So what can we offer? If it's something like CLONE or BNAME, we offer > an upgrade path. You're no worse off than you'd be with manual > bundling and manual application configuration, and to the extent you > upgrade your applications to know about the new DNS stuff, your > configuration job gets easier. > > That's not as cool as the mythical magic hack. Will people find it > useful? Having done my share of SMTP server hackery, I would. If > it's as important to handle variant names as people say it is, they'll > upgrade. If not, well, that's OK too. i believe have unsligned (assymetric in fact) incentives here. the folks who would have to upgrade are those providing services (internet wide). the folks who want this upgrade to happen are the name producers/sellers. we did the same thing in EDNS0 and that's why i predict a very long tail. From ogud@ogud.com Mon Mar 28 01:10:40 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69A73A6893 for ; Mon, 28 Mar 2011 01:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnXfw4Yx3b+f for ; Mon, 28 Mar 2011 01:10:40 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id CDF533A68E4 for ; Mon, 28 Mar 2011 01:10:39 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2S8CFiG048000 for ; Mon, 28 Mar 2011 04:12:16 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4D9042DA.30002@ogud.com> Date: Mon, 28 Mar 2011 04:12:10 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:10:41 -0000 Dear colleagues, The following is a result of a side conversation on the interpretation of RFC403x with number of DNS colleagues. Any mistakes in the questions are mine. The questions are: 1) What is the valid order of signed RRsets? 2) How many times SHOULD/MUST RRSIG(SOA) appear in an AXFR? 3) What RRSIG(SOA)'s MUST appear on the wire in an IXFR transaction? Q1) A: In RFC403x there is no order requirement on an signed RRset thus implementations should be ready to handle any combination Following Examples should be treated as the same RRset RR1 RR3 RRSIG2 RR2 RRSIG1 RR2 RR3 RR1 RR3 RRSIG1 RR2 RRSIG1 RRSIG2 RRSIG2 RR1 Q2) In AXFR the SOA record is used as a marker record to signal the beginning of a zone transfer and the end of the zone transfer. The open question is how many times should RRSIG(SOA) appear in the AXFR stream ? a) Only once b) Both times c) Does not matter both are ok. if the answer is a) then the question is when should it appear, i) in the beginning after the SOA ii) at any time in the AXFR iii) just before the final one. iv) after the final one. Q3) In IXFR there are multiple SOA records used as maker both on the overall transaction and on each delta. The questions here are: Which RRSIG(SOA) i.e. for each serial number, are needed ? a) All of them once b) all of them each time SOA appears b) only the final one, all the other ones are immaterial (open question is how often and where) c) The first and last one and each only once, the first one is needed to identify what to delete from the zone, the final one is what is going to be in the zone after the IXFR is applied. Is there need put this information in dnssec-bis (the answer to the AXFR question may update RFC5936) and in IXFR-bis document ? Olafur From mohta@necom830.hpcl.titech.ac.jp Mon Mar 28 01:15:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851463A6912 for ; Mon, 28 Mar 2011 01:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.086 X-Spam-Level: X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fADt1V8Z3FDV for ; Mon, 28 Mar 2011 01:15:41 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id A4FD73A6921 for ; Mon, 28 Mar 2011 01:15:40 -0700 (PDT) Received: (qmail 91310 invoked from network); 28 Mar 2011 08:39:02 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 28 Mar 2011 08:39:02 -0000 Message-ID: <4D9043E1.1010102@necom830.hpcl.titech.ac.jp> Date: Mon, 28 Mar 2011 17:16:33 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D9042DA.30002@ogud.com> In-Reply-To: <4D9042DA.30002@ogud.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:15:41 -0000 Olafur Gudmundsson wrote: > The following is a result of a side conversation on the interpretation > of RFC403x with number of DNS colleagues. If you are talking about bis, DNSbis with 32 or 64 bit message ID is the way to go. Masataka Ohta From ajs@shinkuro.com Mon Mar 28 01:49:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 036783A6917 for ; Mon, 28 Mar 2011 01:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vzzDEr81laa for ; Mon, 28 Mar 2011 01:49:34 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id BB9F13A690B for ; Mon, 28 Mar 2011 01:49:34 -0700 (PDT) Received: from shinkuro.com (unknown [130.129.37.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EE8211ECB41D for ; Mon, 28 Mar 2011 08:51:10 +0000 (UTC) Date: Mon, 28 Mar 2011 04:51:05 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110328085104.GJ85412@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] Report from the chairs for IETF 80 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:49:36 -0000 Dear colleagues, This is the DNSEXT Working Group status report from the chairs. As we did for previous meetings, we are undertaking this report on the mailing list rather than at the meeting. Items not addressed in this report but that you think need discussing should be part of the DNSEXT meeting at IETF 80, or should be raised here on the list. Please be aware that, if there are issues you want to have addressed at the meeting and you feel they're not being addressed in this mail, you should not hesitate to raise them. Reminder: contributions to the WG are covered by the "Note Well" statement, which can be found at http://www.ietf.org/about/note-well.html. The current WG chairs can always be reached at . The ADs for the WG can be reached at . 1. DRAFTS PUBLISHED Cryptographic Algorithm Identifier Allocation for DNSSEC, RFC 6014. 2. DRAFTS IN OR PAST WG LAST CALL The chairs regret that we have not done a very good job -- one could say, in fact, that we've done a rather bad job -- at dealing with drafts since IETF 79. More on this below. a. RFC-Editor's queue draft-ietf-dnsext-5395bis. This draft is, you may recall, the emergency change we thought we could get published "quickly" as a result of the difficulties with mailing list operation contemporary with IETF 79. It has not yet been published. b. IESG processing draft-ietf-dnsext-rfc3597-bis The editor and the shepherd have some work to do on language before this is sent along. The status is actually false: this was sent back to the WG. This status is unchanged since IETF 79. 3. ACTIVE DRAFTS draft-ietf-dnsext-dnssec-registry-fixes - This draft went through a last call and was, as far as the shepherd (Andrew) understands matters, successful. He has not prepared his report, however. Andrew apologized to the WG for his delinquency. draft-ietf-dnsext-rfc2672bis-dname - Contemporary with IETF 79, the chairs committed to running a last call on this draft. They failed to do so. draft-ietf-dnsext-dnssec-bis-updates - A couple outstanding issues were rectified, and the editors have received instructions on how to update the text to reflect the consensus about CD bit handling. We expect a new issue soon. There is a new issue that has come up recently, having to do with how many RRSIGs should be sent with the SOA record in both AXFR and IXFR. Please see the discussion on the list. draft-ietf-dnsext-rfc2671bis-edns0 - There was little discussion in response to recent postings. Does this indicate lack of interest? draft-ietf-dnsext-ecdsa - This draft needs registry-fixes to go on, so we have been neglecting it. The editor has sent quite justifiable notices of annoyance to the chairs. draft-ietf-dnsext-dnssec-algo-signal - This draft is being shepherded by Patrik Fältström. It has not engendered much discussion since the -00 was uploaded. Does that mean people think it is ready? draft-ietf-dnsext-aliasing-requirements - Major subject of IETF 80 meeting. 4. EXPIRED DRAFTS draft-vixie-dnsext-resimprove-00 - Major subject of IETF 80 meeting. This draft is not strictly a WG document, but we were planning to move directly to WGLC except that when we started to, several objections were raised. 5. Other WG work and issues a. Expert reviews We have failed, quite spectacularly, in our duties to complete expert reviews for two RRTYPE requests. The responsibility for this lies with the chair who is supposed to be managing that process (Andrew). This is not the first time, however, that we have had trouble meeting our responsibilities in this area. At the same time, the process of publishing draft-ietf-dnsext-5395bis has exposed widespread and rather serious confusion about the procedures. Some of these are due to differences between the documents and the actual operation. If you have suggestions about how things can be improved, please speak to (or send mail to) the chairs. We will need to undertake yet another revision of draft-ietf-dnsext-5395bis in order to address IANA concerns, so we might as well try to nail this. b. Mailing list move The mailing list moved to the IETF infrastructure. As far as we can tell, this was successful. If you have evidence otherwise, please bring it to our attention. c. Chair performance The chairs have not adequately discharged their responsibilities in respect of WG operation -- especially in respect of review and managing WG document workflow. Some have complained also that we have allowed discussion of certain topics to ramble and to return repeatedly to already-considered (and rejected) topics. The chairs must admit that part of the reason for this inadequate attention is that each chair does a significant amount of work for the same (rather small) company. The IETF is a volunteer activity, and for any WG, there is a risk to the WG if both chairs get busy at the same time. In the present case, of course, there may be a greater than normal chance that both chairs get busy at the same time. While this problem might solve itself, we are unsure whether the WG as a whole wants us to take action to head of this increased risk. Your thoughts are solicited. While we are loathe to increase the work on our AD, if you feel uncomfortable sending your views to the chairs and believe your views should be heard, you ought to make your observations to our AD. -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From alex@alex.org.uk Mon Mar 28 01:50:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1008A3A6917 for ; Mon, 28 Mar 2011 01:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnyjSnzmPyvN for ; Mon, 28 Mar 2011 01:50:30 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 371C23A6940 for ; Mon, 28 Mar 2011 01:50:30 -0700 (PDT) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 6E03BC560BF; Mon, 28 Mar 2011 09:52:05 +0100 (BST) Date: Mon, 28 Mar 2011 09:52:04 +0000 From: Alex Bligh To: Paul Vixie , dnsext@ietf.org Message-ID: <6E759B49A7EC572D118230FB@Ximines.local> In-Reply-To: <47131.1301261826@nsa.vix.com> References: <20110327192512.90424.qmail@joyce.lan> <47131.1301261826@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:50:31 -0000 --On 27 March 2011 21:37:06 +0000 Paul Vixie wrote: > these would be, in the parlance used when this topic was first introduced, > "second class names". they can't be used as the target of MX or NS RRs, > and they won't work for services whose servers have not been upgraded. NS records perhaps, but I'm not sure MX is as big a deal as all that. Assume the worst happens, and a CNAME is synthesized. This works in (say) 99% of cases already, and a draft modifying the appropriate SMTP RFC would legitimise it. I suspect most of the usage for such names would be IDN related, and that you'd get more breakage from old SMTP speakers with config files that don't like IDN / new TLDs than CNAME MXes (I seem to remember my sendmail/uucp config in 93 had all the TLDs hardwired in - it would not be a tragedy if this ceased to work). -- Alex Bligh From george.barwood@blueyonder.co.uk Mon Mar 28 01:57:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965AF3A696A for ; Mon, 28 Mar 2011 01:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=0.856, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zTo1QuYZUXz for ; Mon, 28 Mar 2011 01:57:38 -0700 (PDT) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by core3.amsl.com (Postfix) with ESMTP id 4B2533A695A for ; Mon, 28 Mar 2011 01:57:37 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.3]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110328085907.VMBO18231.mtaout01-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Mon, 28 Mar 2011 09:59:07 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1Q48Hz-0000kV-FB; Mon, 28 Mar 2011 09:59:07 +0100 Message-ID: From: "George Barwood" To: "Olafur Gudmundsson" , References: <4D9042DA.30002@ogud.com> Date: Mon, 28 Mar 2011 09:59:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=F1NOll8JUcwA:10 a=8nJEP1OIZ-IA:10 a=5DHTYsOjAAAA:8 a=48vgC7mUAAAA:8 a=Tcq4zHyceHOgtvVFY6sA:9 a=mhyPiA7n3xpxJavXUenra3Om-tYA:4 a=wPNLvfGTeEIA:10 a=8ie3zQVgER4A:10 a=lZB815dzVvQA:10 a=vghTk32N3AhTqR0a:21 a=aukgVSn-w9ynva9d:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:57:39 -0000 TXkgdW5kZXJzdGFuZGluZyBvbiB0aGVzZSBxdWVzdGlvbnMuLi4NCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCkZyb206ICJPbGFmdXIgR3VkbXVuZHNzb24iIDxvZ3VkQG9ndWQuY29t Pg0KVG86IDxkbnNleHRAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIE1hcmNoIDI4LCAyMDExIDk6 MTIgQU0NClN1YmplY3Q6IFtkbnNleHRdIFBvc3NpYmxlIEROU1NFQ2JpcyBjbGFyaWZpY2F0aW9u cw0KDQoNCj4gDQo+IERlYXIgY29sbGVhZ3VlcywNCj4gDQo+IFRoZSBmb2xsb3dpbmcgaXMgYSBy ZXN1bHQgb2YgYSBzaWRlIGNvbnZlcnNhdGlvbiBvbiB0aGUgaW50ZXJwcmV0YXRpb24NCj4gb2Yg UkZDNDAzeCB3aXRoIG51bWJlciBvZiBETlMgY29sbGVhZ3Vlcy4NCj4gQW55IG1pc3Rha2VzIGlu IHRoZSBxdWVzdGlvbnMgYXJlIG1pbmUuDQo+IA0KPiBUaGUgcXVlc3Rpb25zIGFyZToNCj4gMSkg V2hhdCBpcyB0aGUgdmFsaWQgb3JkZXIgb2Ygc2lnbmVkIFJSc2V0cz8NCj4gMikgSG93IG1hbnkg dGltZXMgU0hPVUxEL01VU1QgUlJTSUcoU09BKSBhcHBlYXIgaW4gYW4gQVhGUj8NCj4gMykgV2hh dCBSUlNJRyhTT0EpJ3MgTVVTVCBhcHBlYXIgb24gdGhlIHdpcmUgaW4gYW4gSVhGUiB0cmFuc2Fj dGlvbj8NCj4gDQo+IA0KPiBRMSkgQTogSW4gUkZDNDAzeCB0aGVyZSBpcyBubyBvcmRlciByZXF1 aXJlbWVudCBvbiBhbiBzaWduZWQgUlJzZXQgdGh1cyANCj4gaW1wbGVtZW50YXRpb25zIHNob3Vs ZCBiZSByZWFkeSB0byBoYW5kbGUgYW55IGNvbWJpbmF0aW9uDQo+IEZvbGxvd2luZyBFeGFtcGxl cyBzaG91bGQgYmUgdHJlYXRlZCBhcyB0aGUgc2FtZSBSUnNldA0KPiBSUjEgUlIzIFJSU0lHMg0K PiBSUjIgUlJTSUcxIFJSMg0KPiBSUjMgUlIxIFJSMw0KPiBSUlNJRzEgUlIyIFJSU0lHMQ0KPiBS UlNJRzIgUlJTSUcyIFJSMQ0KPiANCg0KQWdyZWVkLiBXaXRoaW4gYSBzZWN0aW9uLCByZWNvcmRz IG1heSBiZSBpbiBhbnkgb3JkZXIuDQpUaGUgbm9ybWFsIGFwcm9hY2ggaXMgdG8gaGF2ZSBSUlNJ R3MgaW1tZWRpYXRlbHkgZm9sbG93IHRoYXQgcmVjb3JkcyB0aGF0DQp0aGV5IHNpZ24sIGJ1dCB0 aGlzIGlzIG5vdCByZXF1aXJlZCBieSB0aGUgc3RhbmRhcmQuDQoNCj4gDQo+IFEyKSBJbiBBWEZS IHRoZSBTT0EgcmVjb3JkIGlzIHVzZWQgYXMgYSBtYXJrZXIgcmVjb3JkIHRvIHNpZ25hbCB0aGUg DQo+IGJlZ2lubmluZyBvZiBhIHpvbmUgdHJhbnNmZXIgYW5kIHRoZSBlbmQgb2YgdGhlIHpvbmUg dHJhbnNmZXIuDQo+IFRoZSBvcGVuIHF1ZXN0aW9uIGlzIGhvdyBtYW55IHRpbWVzIHNob3VsZCBS UlNJRyhTT0EpIGFwcGVhciBpbiB0aGUNCj4gQVhGUiBzdHJlYW0gPw0KPiBhKSBPbmx5IG9uY2UN Cj4gYikgQm90aCB0aW1lcw0KPiBjKSBEb2VzIG5vdCBtYXR0ZXIgYm90aCBhcmUgb2suDQo+IA0K PiBpZiB0aGUgYW5zd2VyIGlzIGEpIHRoZW4gdGhlIHF1ZXN0aW9uIGlzIHdoZW4gc2hvdWxkIGl0 IGFwcGVhciwNCj4gaSkgaW4gdGhlIGJlZ2lubmluZyBhZnRlciB0aGUgU09BDQo+IGlpKSBhdCBh bnkgdGltZSBpbiB0aGUgQVhGUg0KPiBpaWkpIGp1c3QgYmVmb3JlIHRoZSBmaW5hbCBvbmUuDQo+ IGl2KSBhZnRlciB0aGUgZmluYWwgb25lLg0KDQpSUlNJRyhTT0EpIHJlY29yZHMgc2hvdWxkIGJl IGFueXdoZXJlIGFmdGVyIGluaXRpYWwgU09BIGFuZCBiZWZvcmUgdGhlIGZpbmFsIFNPQSByZWNv cmQuDQogDQo+IFEzKSBJbiBJWEZSIHRoZXJlIGFyZSBtdWx0aXBsZSBTT0EgcmVjb3JkcyB1c2Vk IGFzIG1ha2VyIGJvdGggb24gdGhlIA0KPiBvdmVyYWxsIHRyYW5zYWN0aW9uIGFuZCBvbiBlYWNo IGRlbHRhLg0KPiBUaGUgcXVlc3Rpb25zIGhlcmUgYXJlOg0KPiBXaGljaCBSUlNJRyhTT0EpIGku ZS4gZm9yIGVhY2ggc2VyaWFsIG51bWJlciwgYXJlIG5lZWRlZCA/DQo+IGEpIEFsbCBvZiB0aGVt IG9uY2UNCj4gYikgYWxsIG9mIHRoZW0gZWFjaCB0aW1lIFNPQSBhcHBlYXJzDQo+IGIpIG9ubHkg dGhlIGZpbmFsIG9uZSwgYWxsIHRoZSBvdGhlciBvbmVzIGFyZSBpbW1hdGVyaWFsDQo+ICAgKG9w ZW4gcXVlc3Rpb24gaXMgaG93IG9mdGVuIGFuZCB3aGVyZSkNCj4gYykgVGhlIGZpcnN0IGFuZCBs YXN0IG9uZSBhbmQgZWFjaCBvbmx5IG9uY2UsDQo+ICAgIHRoZSBmaXJzdCBvbmUgaXMgbmVlZGVk IHRvIGlkZW50aWZ5IHdoYXQgdG8gZGVsZXRlIGZyb20NCj4gICAgdGhlIHpvbmUsIHRoZSBmaW5h bCBvbmUgaXMgd2hhdCBpcyBnb2luZyB0byBiZSBpbiB0aGUNCj4gICAgICAgICAgICB6b25lIGFm dGVyIHRoZSBJWEZSIGlzIGFwcGxpZWQuDQo+IA0KDQpJJ20gbm90IGZhbWlsaWFyIHdpdGggSVhG Uiwgc28gbm8gb3BpbmlvbiBvbiB0aGlzIG9uZS4NCg0KR2VvcmdlDQogDQo+IElzIHRoZXJlIG5l ZWQgcHV0IHRoaXMgaW5mb3JtYXRpb24gaW4gZG5zc2VjLWJpcyAodGhlIGFuc3dlciB0byB0aGUg QVhGUiANCj4gcXVlc3Rpb24gbWF5IHVwZGF0ZSBSRkM1OTM2KSBhbmQgaW4gSVhGUi1iaXMgZG9j dW1lbnQgPw0KPiANCj4gT2xhZnVyDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBkbnNleHQgbWFpbGluZyBsaXN0DQo+IGRuc2V4dEBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ruc2V4dA== From marc.lampo@eurid.eu Mon Mar 28 02:11:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0393A690A for ; Mon, 28 Mar 2011 02:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUmft7c5o9tS for ; Mon, 28 Mar 2011 02:11:34 -0700 (PDT) Received: from cuda.eurid.eu (mx.eurid.eu [77.67.53.136]) by core3.amsl.com (Postfix) with ESMTP id 497603A683D for ; Mon, 28 Mar 2011 02:11:32 -0700 (PDT) X-ASG-Debug-ID: 1301303583-46c953290001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id jZHwciYOTHwPyo2z; Mon, 28 Mar 2011 11:13:03 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id C8150E407A; Mon, 28 Mar 2011 11:07:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GyowWM3WRoS; Mon, 28 Mar 2011 11:07:41 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id B53BFE4050; Mon, 28 Mar 2011 11:07:41 +0200 (CEST) From: "Marc Lampo" To: "'Olafur Gudmundsson'" , References: <4D9042DA.30002@ogud.com> In-Reply-To: <4D9042DA.30002@ogud.com> Date: Mon, 28 Mar 2011 11:07:41 +0200 (CEST) X-ASG-Orig-Subj: RE: [dnsext] Possible DNSSECbis clarifications Message-ID: <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcvtH9X7xkzgbJN5S2CDk9IFp0cCAAAB5daw Content-Language: en-za X-Originating-IP: [172.20.5.39] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1301303583 X-Barracuda-URL: http://77.67.53.136:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 09:11:36 -0000 Hello, Only a feedback on Q2) # times the RRSIG(SOA) should appear in zone transfer. I think "b) both times". Motivation. While the second SOA might serve as an indicator of "end of zone transfer", it also indicates that the transferred zone was not changed (at sender side) during the time it took to send the zone file. Because, if it did change (at sender side) the serial number in the final SOA would change. Consequently, since there is a possibility that the second SOA might be different from the first SOA, it's RRSIG will be different as well : so, each SOA should be accompanied by its (own) RRSIG. Perhaps this brings an additional challenge : ? how to link a RRSIG(SOA) with the proper SOA record ? --> make it mandatory to have the RRSIG(SOA) immediately follow the SOA record it signs ? Kind regards, Marc Lampo -----Original Message----- From: Olafur Gudmundsson [mailto:ogud@ogud.com] Sent: 28 March 2011 10:12 AM To: dnsext@ietf.org Subject: [dnsext] Possible DNSSECbis clarifications Dear colleagues, The following is a result of a side conversation on the interpretation of RFC403x with number of DNS colleagues. Any mistakes in the questions are mine. The questions are: 1) What is the valid order of signed RRsets? 2) How many times SHOULD/MUST RRSIG(SOA) appear in an AXFR? 3) What RRSIG(SOA)'s MUST appear on the wire in an IXFR transaction? Q1) A: In RFC403x there is no order requirement on an signed RRset thus implementations should be ready to handle any combination Following Examples should be treated as the same RRset RR1 RR3 RRSIG2 RR2 RRSIG1 RR2 RR3 RR1 RR3 RRSIG1 RR2 RRSIG1 RRSIG2 RRSIG2 RR1 Q2) In AXFR the SOA record is used as a marker record to signal the beginning of a zone transfer and the end of the zone transfer. The open question is how many times should RRSIG(SOA) appear in the AXFR stream ? a) Only once b) Both times c) Does not matter both are ok. if the answer is a) then the question is when should it appear, i) in the beginning after the SOA ii) at any time in the AXFR iii) just before the final one. iv) after the final one. Q3) In IXFR there are multiple SOA records used as maker both on the overall transaction and on each delta. The questions here are: Which RRSIG(SOA) i.e. for each serial number, are needed ? a) All of them once b) all of them each time SOA appears b) only the final one, all the other ones are immaterial (open question is how often and where) c) The first and last one and each only once, the first one is needed to identify what to delete from the zone, the final one is what is going to be in the zone after the IXFR is applied. Is there need put this information in dnssec-bis (the answer to the AXFR question may update RFC5936) and in IXFR-bis document ? Olafur From ajs@shinkuro.com Mon Mar 28 02:15:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5EA43A6A27 for ; Mon, 28 Mar 2011 02:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD7zmoeMfUwc for ; Mon, 28 Mar 2011 02:15:35 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D6B483A6917 for ; Mon, 28 Mar 2011 02:15:32 -0700 (PDT) Received: from shinkuro.com (dhcp-250f.meeting.ietf.org [130.129.37.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B37491ECB41D for ; Mon, 28 Mar 2011 09:17:09 +0000 (UTC) Date: Mon, 28 Mar 2011 05:17:06 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110328091706.GN85412@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] Scribe volunteers? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 09:15:36 -0000 Dear colleagues, We have a meeting this afternoon. We haven't had any scribe volunters. If you are willing, please contact the chairs and let us know. BTW, if you are a newcomer to meetings, this is actually an excellent way to get to understand what's going on. You're forced to pay attention to the session! A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From marka@isc.org Mon Mar 28 02:27:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753093A68B0 for ; Mon, 28 Mar 2011 02:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH2h1nD6Hmkx for ; Mon, 28 Mar 2011 02:27:16 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 185F73A686C for ; Mon, 28 Mar 2011 02:27:16 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 4A51BC9423; Mon, 28 Mar 2011 09:28:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:6233:4bff:fe01:7585]) (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 CA9ED216C22; Mon, 28 Mar 2011 09:28:48 +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 02E5BD97013; Mon, 28 Mar 2011 20:28:46 +1100 (EST) To: Olafur Gudmundsson From: Mark Andrews References: <4D9042DA.30002@ogud.com> In-reply-to: Your message of "Mon, 28 Mar 2011 04:12:10 EDT." <4D9042DA.30002@ogud.com> Date: Mon, 28 Mar 2011 20:28:46 +1100 Message-Id: <20110328092847.02E5BD97013@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 09:27:17 -0000 In message <4D9042DA.30002@ogud.com>, Olafur Gudmundsson writes: > > Dear colleagues, > > The following is a result of a side conversation on the interpretation > of RFC403x with number of DNS colleagues. > Any mistakes in the questions are mine. > > The questions are: > 1) What is the valid order of signed RRsets? > 2) How many times SHOULD/MUST RRSIG(SOA) appear in an AXFR? > 3) What RRSIG(SOA)'s MUST appear on the wire in an IXFR transaction? > > > Q1) A: In RFC403x there is no order requirement on an signed RRset thus > implementations should be ready to handle any combination > Following Examples should be treated as the same RRset > RR1 RR3 RRSIG2 > RR2 RRSIG1 RR2 > RR3 RR1 RR3 > RRSIG1 RR2 RRSIG1 > RRSIG2 RRSIG2 RR1 > > > Q2) In AXFR the SOA record is used as a marker record to signal the > beginning of a zone transfer and the end of the zone transfer. > The open question is how many times should RRSIG(SOA) appear in the > AXFR stream ? > a) Only once > b) Both times > c) Does not matter both are ok. > > if the answer is a) then the question is when should it appear, > i) in the beginning after the SOA > ii) at any time in the AXFR > iii) just before the final one. > iv) after the final one. All records with the exception of the SOA should appear once but multiple should be handled. This is covered in AXFR clarify. The record should be between the SOA records. The SOA records bookend the zone transfer. > Q3) In IXFR there are multiple SOA records used as maker both on the > overall transaction and on each delta. > The questions here are: > Which RRSIG(SOA) i.e. for each serial number, are needed ? > a) All of them once > b) all of them each time SOA appears > b) only the final one, all the other ones are immaterial > (open question is how often and where) > c) The first and last one and each only once, > the first one is needed to identify what to delete from > the zone, the final one is what is going to be in the > zone after the IXFR is applied. IXFR contains sets of deltas which consist of the *records* that have changed in the zone. Assuming a properly signed zone you will have the final SOA, the starting SOA, RRSIGs of the starting SOA + any other changes, the next (possibly final) SOA, the RRSIGs of the SOA that apply to that and any other changes, possibly the next delta, .... then the final SOA. > Is there need put this information in dnssec-bis (the answer to the AXFR > question may update RFC5936) and in IXFR-bis document ? No. > Olafur > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Antoin.Verschuren@sidn.nl Mon Mar 28 02:33:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6A43A6A36 for ; Mon, 28 Mar 2011 02:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB2U-D17t9Ys for ; Mon, 28 Mar 2011 02:33:07 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by core3.amsl.com (Postfix) with ESMTP id 7E3EC3A6A3E for ; Mon, 28 Mar 2011 02:32:59 -0700 (PDT) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p2S9YaLn025505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Mon, 28 Mar 2011 11:34:36 +0200 Received: from [192.168.192.222] (192.168.192.222) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Mon, 28 Mar 2011 11:34:35 +0200 Message-ID: <4D90564A.8010001@sidn.nl> Date: Mon, 28 Mar 2011 11:35:06 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: References: <4D9042DA.30002@ogud.com> <20110328092847.02E5BD97013@drugs.dv.isc.org> In-Reply-To: <20110328092847.02E5BD97013@drugs.dv.isc.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 09:33:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nice thought: Should an SOA record be signed anyway ? The SOA is only a signaling record, and the result is never going to be used by any application. The header (including the ad bit) is also not signed, and the DNSKEY record does not need to be signed with a ZSK. On 28-03-11 11:28, Mark Andrews wrote: > > In message <4D9042DA.30002@ogud.com>, Olafur Gudmundsson writes: >> >> Dear colleagues, >> >> The following is a result of a side conversation on the interpretation >> of RFC403x with number of DNS colleagues. >> Any mistakes in the questions are mine. >> >> The questions are: >> 1) What is the valid order of signed RRsets? >> 2) How many times SHOULD/MUST RRSIG(SOA) appear in an AXFR? >> 3) What RRSIG(SOA)'s MUST appear on the wire in an IXFR transaction? >> >> >> Q1) A: In RFC403x there is no order requirement on an signed RRset thus >> implementations should be ready to handle any combination >> Following Examples should be treated as the same RRset >> RR1 RR3 RRSIG2 >> RR2 RRSIG1 RR2 >> RR3 RR1 RR3 >> RRSIG1 RR2 RRSIG1 >> RRSIG2 RRSIG2 RR1 >> >> >> Q2) In AXFR the SOA record is used as a marker record to signal the >> beginning of a zone transfer and the end of the zone transfer. >> The open question is how many times should RRSIG(SOA) appear in the >> AXFR stream ? >> a) Only once >> b) Both times >> c) Does not matter both are ok. >> >> if the answer is a) then the question is when should it appear, >> i) in the beginning after the SOA >> ii) at any time in the AXFR >> iii) just before the final one. >> iv) after the final one. > > All records with the exception of the SOA should appear once but > multiple should be handled. This is covered in AXFR clarify. The > record should be between the SOA records. The SOA records bookend > the zone transfer. > >> Q3) In IXFR there are multiple SOA records used as maker both on the >> overall transaction and on each delta. >> The questions here are: >> Which RRSIG(SOA) i.e. for each serial number, are needed ? >> a) All of them once >> b) all of them each time SOA appears >> b) only the final one, all the other ones are immaterial >> (open question is how often and where) >> c) The first and last one and each only once, >> the first one is needed to identify what to delete from >> the zone, the final one is what is going to be in the >> zone after the IXFR is applied. > > IXFR contains sets of deltas which consist of the *records* that > have changed in the zone. Assuming a properly signed zone you > will have the final SOA, the starting SOA, RRSIGs of the starting SOA + any > other changes, the next (possibly final) SOA, the RRSIGs of the SOA > that apply to that and any other changes, possibly the next delta, > .... then the final SOA. > >> Is there need put this information in dnssec-bis (the answer to the AXFR >> question may update RFC5936) and in IXFR-bis document ? > > No. > >> Olafur >> >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNkFY/AAoJEDqHrM883Agn8BoH/0b2dC+h7H6rMJaYqv7NabEv jC61tUM41XCBN9K71H1ZTT0JUkMGjpLdqbSrqRNoGQSPqRR9ZlUg+pSe44v1t6X4 0ZvyPtXfVA/9AESwmzS+HztOwShsvhYyp2fWvlAkFcnP/8mNHkHCuuzAi8LFubx+ 8QdE1bqRSeiByTn4GZ1vaSRTxt2aKcHM5CJ6VrgERTCjt6hEd7xxrIqUqxOiR4+Q ecRbX5D+i0x3GEal1W4Xgqa5jLwQfaNN1Euog4ftNWBIpFa+e+/pgjXTbDVGz8Zv 1hSzXdyguIAsICu0WKdEd8J11TNj5XYKitO2JXXjUKAQmsFN75s6ETTQIYZv4Ps= =SEF+ -----END PGP SIGNATURE----- From jabley@hopcount.ca Mon Mar 28 04:52:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B323A68BF for ; Mon, 28 Mar 2011 04:52:41 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khatU4OiEApc for ; Mon, 28 Mar 2011 04:52:40 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by core3.amsl.com (Postfix) with ESMTP id 39B7B3A685B for ; Mon, 28 Mar 2011 04:52:38 -0700 (PDT) Received: from [2001:df8:0:64:5a55:caff:feec:96bf] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4B1C-000FsE-MV; Mon, 28 Mar 2011 11:54:02 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> Date: Mon, 28 Mar 2011 13:53:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> To: Marc Lampo X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 2001:df8:0:64:5a55:caff:feec:96bf X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org, 'Olafur Gudmundsson' Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 11:52:41 -0000 On 2011-03-28, at 11:07, Marc Lampo wrote: > I think "b) both times". > Motivation. > While the second SOA might serve as an indicator of "end of zone > transfer", It's not the end of the transferred zone if there's an RRSIG following = it, surely. Joe From jabley@hopcount.ca Mon Mar 28 04:59:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151EF3A6825 for ; Mon, 28 Mar 2011 04:59:03 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DHyo3OTTZJJ for ; Mon, 28 Mar 2011 04:59:02 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by core3.amsl.com (Postfix) with ESMTP id 1E9F13A67AD for ; Mon, 28 Mar 2011 04:59:00 -0700 (PDT) Received: from [2001:df8:0:64:5a55:caff:feec:96bf] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4B7c-000G9s-ER; Mon, 28 Mar 2011 12:00:37 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <4D90564A.8010001@sidn.nl> Date: Mon, 28 Mar 2011 14:00:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8003B067-6142-440D-9967-DED1EBCF9524@hopcount.ca> References: <4D9042DA.30002@ogud.com> <20110328092847.02E5BD97013@drugs.dv.isc.org> <4D90564A.8010001@sidn.nl> To: Antoin Verschuren X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 2001:df8:0:64:5a55:caff:feec:96bf X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 11:59:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-03-28, at 11:35, Antoin Verschuren wrote: > Nice thought: > Should an SOA record be signed anyway ? Yes. > The SOA is only a signaling record, and the result is never going to = be > used by any application. SOA RDATA is used by two important classes of application -- DNS = authority-only servers (REFRESH, RETRY, EXPIRE) and DNS resolvers = (MINIMUM, negative cache TTL). Further, the MNAME field is used by DNS = UPDATE clients. The utility of the MNAME field in the real world is = debatable, but I have seen no data which suggests it is irrelevant. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2QeF0ACgkQNI8MvYZSOizRxgCfTVAgG0rGC6oz67CpK2wmOpei p44AnRkyxQK7Q71fBVNgq2g7s19qIS7i =3DdN2t -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Mon Mar 28 05:10:49 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480623A690C for ; Mon, 28 Mar 2011 05:10:49 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFXho6JhcLbW for ; Mon, 28 Mar 2011 05:10:48 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id BD5A93A68D5 for ; Mon, 28 Mar 2011 05:10:47 -0700 (PDT) Received: from [IPv6:2001:df8:0:64:215:afff:fed2:e121] ([IPv6:2001:df8:0:64:215:afff:fed2:e121]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p2SCCN1F020480 for ; Mon, 28 Mar 2011 14:12:23 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4D907B27.9000301@nlnetlabs.nl> Date: Mon, 28 Mar 2011 14:12:23 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110328085104.GJ85412@crankycanuck.ca> In-Reply-To: <20110328085104.GJ85412@crankycanuck.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 28 Mar 2011 14:12:24 +0200 (CEST) Subject: Re: [dnsext] Report from the chairs for IETF 80 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:10:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 03/28/2011 10:51 AM, Andrew Sullivan wrote: > draft-ietf-dnsext-dnssec-bis-updates > > - A couple outstanding issues were rectified, and the editors > have received instructions on how to update the text to > reflect the consensus about CD bit handling. We expect a > new issue soon. > > There is a new issue that has come up recently, having to do > with how many RRSIGs should be sent with the SOA record in > both AXFR and IXFR. Please see the discussion on the list. I think it would also be good if we could come to a consensus on clarifying how the resolver should interpret section 2.2 (RFC 4035) (see the discussion on 'Clarifying the mandatory algorithm rules'). Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNkHsnAAoJEA8yVCPsQCW5uwEIAKTJvJUeXHwihcw6heh+pJN5 v8Nqge9cBOHedheiqR2Qv9PwyCRveO6k4/cdO7j6uUYp/txVqhHvwxc2yjI5S7H1 gumYlo4TBsk3aEHpOfroisXrCGCn/ILTsJtI/JRDjXNXHb31pLS59IvF4QNdLqlp oFoIbgLWVD1RECLF4t1ZdGC7iMYfyXUxB+DwQ+cvyhRSzJXhKEYYvHBY7X5Ng9tR 27WhJsLeXbZl4APekpwYJvBoA6WXc3rYaa1jquWiuuQ4IXNSoLkytdTGQ8IKAE8u b1fkJyFDyqFZIg5KhZbzujoAtUF/WqOTM6dYtIjurPO9Q/E0+nL81h/a70n9fjM= =4yKd -----END PGP SIGNATURE----- From fanf2@hermes.cam.ac.uk Mon Mar 28 05:38:57 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7763A68F0 for ; Mon, 28 Mar 2011 05:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuYB1rx269up for ; Mon, 28 Mar 2011 05:38:56 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id E18BB3A6817 for ; Mon, 28 Mar 2011 05:38:55 -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-1.csi.cam.ac.uk ([131.111.8.51]:50043) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Q4BkD-0002SX-Xh (Exim 4.72) (return-path ); Mon, 28 Mar 2011 13:40:29 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Q4BkD-00043x-E2 (Exim 4.67) (return-path ); Mon, 28 Mar 2011 13:40:29 +0100 Date: Mon, 28 Mar 2011 13:40:29 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20110328014717.6F0F9D8E7E9@drugs.dv.isc.org> Message-ID: References: <20110327192512.90424.qmail@joyce.lan> <20110328014717.6F0F9D8E7E9@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:38:57 -0000 Mark Andrews wrote: > > And SMTP had it correct for the second group. If the SMTP client > sees the CNAME it re-writes the names in the SMTP exchange to use > the cannonical host name. The SMTP server never see the alias. That has not been true for over ten years. Tony. -- f.anthony.n.finch http://dotat.at/ Tyne, Dogger: Variable, mainly south or southwest 3 or 4, occasionally 5. Slight or moderate. Fair. Good, occasionally poor. From fanf2@hermes.cam.ac.uk Mon Mar 28 05:50:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1333A68EA for ; Mon, 28 Mar 2011 05:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.361 X-Spam-Level: X-Spam-Status: No, score=-6.361 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVfHT8xJu4Yb for ; Mon, 28 Mar 2011 05:50:26 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 45D5F3A6817 for ; Mon, 28 Mar 2011 05:50:26 -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-1.csi.cam.ac.uk ([131.111.8.51]:33350) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Q4BvO-0001xI-qk (Exim 4.72) (return-path ); Mon, 28 Mar 2011 13:52:02 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Q4BvO-0005yR-Az (Exim 4.67) (return-path ); Mon, 28 Mar 2011 13:52:02 +0100 Date: Mon, 28 Mar 2011 13:52:02 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John Levine In-Reply-To: <20110327223114.95877.qmail@joyce.lan> Message-ID: References: <20110327223114.95877.qmail@joyce.lan> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:50:31 -0000 John Levine wrote: > > So what can we offer? If it's something like CLONE or BNAME, we offer > an upgrade path. You're no worse off than you'd be with manual > bundling and manual application configuration, and to the extent you > upgrade your applications to know about the new DNS stuff, your > configuration job gets easier. > > That's not as cool as the mythical magic hack. Will people find it > useful? Having done my share of SMTP server hackery, I would. If > it's as important to handle variant names as people say it is, they'll > upgrade. If not, well, that's OK too. Yes. I think it's worth splitting the feature into forward and reverse parts. The forward direction is alias -> canonical, as in CNAME and DNAME. We can use CNAME synthesis to support old clients, and perhaps a DNSSEC algorithm bump to avoid validator problems. Old servers can work with the new BNAME (or whatever) aliases using their existing support for aliases, which typically means explicit per-alias configuration. The reverse direction is canonical name -> alias list, which is for the server to automatically configure its aliases from a trusted part of the DNS. (Does the client have any use for this information?) Servers that understand this feature are easier to configure. This feature is also useful if the aliases no not use BNAME, e.g. if they are CNAMEs or A or AAAA records. Both the new forward and reverse features will be useful independently of each other. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Westerly or southwesterly, becoming cyclonic at times, 4 or 5, occasionally 6 in Biscay and Fitzroy. Moderate or rough. Rain or showers, fog patches in north Biscay. Good to poor, occasionally very poor in north Biscay. From johnl@iecc.com Mon Mar 28 05:50:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B653A6A55 for ; Mon, 28 Mar 2011 05:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.782 X-Spam-Level: X-Spam-Status: No, score=-110.782 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ap3TP-T4nOeK for ; Mon, 28 Mar 2011 05:50:33 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 6D07A3A68EA for ; Mon, 28 Mar 2011 05:50:33 -0700 (PDT) Received: (qmail 43906 invoked from network); 28 Mar 2011 12:52:10 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 28 Mar 2011 12:52:10 -0000 Date: 28 Mar 2011 12:51:48 -0000 Message-ID: <20110328125148.64192.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <78351.1301295082@nsa.vix.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:50:35 -0000 >i believe have unsligned (assymetric in fact) incentives here. the folks >who would have to upgrade are those providing services (internet wide). >the folks who want this upgrade to happen are the name producers/sellers. >we did the same thing in EDNS0 and that's why i predict a very long tail. You may be right. I don't have any insight to what extent the actual users who speak Greek, Chinese, et al. care about making multiple spellings work the same in their mail and web applications. R's, John From marc.lampo@eurid.eu Mon Mar 28 05:58:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DDC3A681A for ; Mon, 28 Mar 2011 05:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3xa9Kj6n-FX for ; Mon, 28 Mar 2011 05:58:01 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by core3.amsl.com (Postfix) with ESMTP id 891D93A67DA for ; Mon, 28 Mar 2011 05:58:01 -0700 (PDT) X-ASG-Debug-ID: 1301317177-5cfb54bc0001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id A0lIFdwuTCd3mtoz; Mon, 28 Mar 2011 14:59:37 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 68C48E4060; Mon, 28 Mar 2011 14:54:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V19PPTqCbqAL; Mon, 28 Mar 2011 14:54:15 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 554D9E4050; Mon, 28 Mar 2011 14:54:15 +0200 (CEST) From: "Marc Lampo" To: "'Joe Abley'" References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> In-Reply-To: Date: Mon, 28 Mar 2011 14:54:15 +0200 (CEST) X-ASG-Orig-Subj: RE: [dnsext] Possible DNSSECbis clarifications Message-ID: <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcvtPtD6teqbaHhBQEqC732QxR3qIAACK17g Content-Language: en-za X-Originating-IP: [172.20.5.39] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1301317177 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsext@ietf.org, 'Olafur Gudmundsson' Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:58:02 -0000 In my opinion, the use of the second SOA to indicate the zone did not change (at sender side) since the zone transfer started is more important (then the indication of the end of the zone transfert). I agree that, if there is a record following that "last SOA", that SOA is obviously not the last one of the zone transfert. Which brings us to the question : Where to put that RRSIG(SOA), knowing that potentially the SOA may change between start and end of AXFR. (in which case the receiving name server must refuse just downloaded zone and attempt AXFR again) Marc -----Original Message----- From: Joe Abley [mailto:jabley@hopcount.ca] Sent: 28 March 2011 01:54 PM To: Marc Lampo Cc: dnsext@ietf.org; 'Olafur Gudmundsson' Subject: Re: [dnsext] Possible DNSSECbis clarifications On 2011-03-28, at 11:07, Marc Lampo wrote: > I think "b) both times". > Motivation. > While the second SOA might serve as an indicator of "end of zone > transfer", It's not the end of the transferred zone if there's an RRSIG following it, surely. Joe From jabley@hopcount.ca Mon Mar 28 06:07:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453EF3A680A for ; Mon, 28 Mar 2011 06:07:41 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSXx5dglLuNE for ; Mon, 28 Mar 2011 06:07:40 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by core3.amsl.com (Postfix) with ESMTP id 20A843A6803 for ; Mon, 28 Mar 2011 06:07:40 -0700 (PDT) Received: from [2001:df8:0:64:5a55:caff:feec:96bf] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4CC4-000IN6-Sv; Mon, 28 Mar 2011 13:09:17 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> Date: Mon, 28 Mar 2011 15:09:14 +0200 Content-Transfer-Encoding: 7bit Message-Id: <22FD4CD1-4EFB-412A-A307-485DEBE815CE@hopcount.ca> References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> To: Marc Lampo X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 2001:df8:0:64:5a55:caff:feec:96bf X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org, 'Olafur Gudmundsson' Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:07:41 -0000 On 2011-03-28, at 14:54, Marc Lampo wrote: > I agree that, if there is a record following that "last SOA", that SOA is > obviously not the last one of the zone transfert. > Which brings us to the question : > Where to put that RRSIG(SOA), knowing that potentially the SOA may change > between start and end of AXFR. > (in which case the receiving name server must refuse just downloaded zone > and attempt AXFR again) Anywhere between the two SOA records seems sensible to me. Joe From mgraff@isc.org Mon Mar 28 06:18:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06FA53A6839 for ; Mon, 28 Mar 2011 06:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4Jt1MREIrqK for ; Mon, 28 Mar 2011 06:18:30 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id DCC7E3A67E4 for ; Mon, 28 Mar 2011 06:18:29 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 665BCC9423 for ; Mon, 28 Mar 2011 13:20:05 +0000 (UTC) (envelope-from mgraff@isc.org) Received: from dhcp-5329.meeting.ietf.org (unknown [IPv6:2001:df8:0:80:61e:64ff:fef5:5604]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0372B216C36 for ; Mon, 28 Mar 2011 13:20:04 +0000 (UTC) (envelope-from mgraff@isc.org) Message-ID: <4D908B03.80408@isc.org> Date: Mon, 28 Mar 2011 15:20:03 +0200 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> In-Reply-To: <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:18:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/28/11 2:54 PM, Marc Lampo wrote: > In my opinion, the use of the second SOA to indicate the zone did not > change (at sender side) since the zone transfer started is more important > (then the indication of the end of the zone transfert). The AXFR (and IXFR) specs bracket the parts by SOA record, not by other records. The purpose is to ensure that the transfer is complete and was not closed early by the sender. If you then allow other records on the end, you will lose that confirmation. Think of the SOA records as brackets. That they are also data is the mistake, but it's one that is in place and can't be changed. The marker could have been an empty DNS packet (just header) but unfortunately, it wasn't. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNkIsCAAoJEDRzoY2A7tzbLZAIAIUMGwBDiHAeKdRJYENRvQES zptiLgt13vKMR1X2Y2yOLwhCcTpX4Hg0h2/bU8QkYLJKf63NdizNB71GuTCvo6h8 N002eh12E5QM3HuDETANc8k9WdfAWAPuENH55gvFlXFQJCG+1IrMA2C1pwhpq6wN dc3WCWRQdD9uYCI/7Psbdie9ePPaOcC3RU1V5+yTA3nDYYKZRhYtjTkVqmy85xqb ukst8+FIDiV3CbEo710YYeocLniGJCRm+omHIxPNt4Jw2Zb/qIH4OYs1tnIZz49V RnD9kAzjKN3fiI32cwb11RvBDXM9T0FEDTm5/YS2kywV3BiNAl7t9O9eq4dBuBQ= =ljlX -----END PGP SIGNATURE----- From fanf2@hermes.cam.ac.uk Mon Mar 28 07:22:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09353A6810 for ; Mon, 28 Mar 2011 07:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCltDLJV9WiD for ; Mon, 28 Mar 2011 07:22:31 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id E8DEF3A684A for ; Mon, 28 Mar 2011 07:22:30 -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-1.csi.cam.ac.uk ([131.111.8.51]:36772) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Q4DMW-0004lD-WN (Exim 4.72) for dnsext@ietf.org (return-path ); Mon, 28 Mar 2011 15:24:08 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Q4DMW-0004i8-0t (Exim 4.67) for dnsext@ietf.org (return-path ); Mon, 28 Mar 2011 15:24:08 +0100 Date: Mon, 28 Mar 2011 15:24:08 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dnsext@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for empty non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 14:22:32 -0000 Arising from the discussion at the meeting about treating a cached NXDOMAIN as applying to all child domains... The main concern about this clarificationin is buggy implementations that give an NXDOMAIN for empty non-terminal names that have non-empty child domains. The examples cited were DJBDNS and in particular rbldnsd. (I presume there are others that we don't know about.) We care about rbldnsd because it is widely deployed and there are a lot of empty non-terminals in RBL zones. However the bug will not normally be triggered by a mail server since mail servers don't query for the non-terminal domains. But there is a serious risk if the mail server is sharing a cache with untrusted clients, since they can make a query that gets an NXDOMAIN response and thereby make the cache think that vast sections of the DNSBL are empty. This is of course a special case of the general problem with this clarification. I don't know if it affects how much we care about it or if it just means we should worry more about the buggy DNS servers that we don't know about. Tony. -- f.anthony.n.finch http://dotat.at/ Southwest Forties, Cromarty, Forth: Southwesterly 4 or 5, occasionally 6, becoming variable 3 later. Slight or moderate. Occasional rain. Good, occasionally poor. From marc.lampo@eurid.eu Mon Mar 28 07:22:55 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390FC3A6900 for ; Mon, 28 Mar 2011 07:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccnrsTo9HVod for ; Mon, 28 Mar 2011 07:22:54 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by core3.amsl.com (Postfix) with ESMTP id 633A33A6810 for ; Mon, 28 Mar 2011 07:22:53 -0700 (PDT) X-ASG-Debug-ID: 1301322270-5cfc54d00001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id K5Qy1C9yv6o2Ytmu; Mon, 28 Mar 2011 16:24:30 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id E074EE4076; Mon, 28 Mar 2011 16:19:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jGn-2j4ZR5Y; Mon, 28 Mar 2011 16:19:07 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id CD0EBE4054; Mon, 28 Mar 2011 16:19:07 +0200 (CEST) From: "Marc Lampo" To: "'Joe Abley'" References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> <22FD4CD1-4EFB-412A-A307-485DEBE815CE@hopcount.ca> In-Reply-To: <22FD4CD1-4EFB-412A-A307-485DEBE815CE@hopcount.ca> Date: Mon, 28 Mar 2011 16:19:07 +0200 (CEST) X-ASG-Orig-Subj: RE: [dnsext] Possible DNSSECbis clarifications Message-ID: <01a901cbed53$e744b7e0$b5ce27a0$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcvtSK+ebzOaPYYFQKOMpnAF480gZgACu1iA Content-Language: en-za X-Originating-IP: [172.20.5.39] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1301322270 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsext@ietf.org, 'Olafur Gudmundsson' Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 14:22:55 -0000 But then, how to link a RRSIG(SOA) with *its* SOA ? Or simply : "try" all available RRSIG(SOA)'s, if at least one validates the SOA being looked at, then accept it. (where "validates" includes not only the signature is valid and within validity period, but also : chain-of-trust is OK) Marc -----Original Message----- From: Joe Abley [mailto:jabley@hopcount.ca] Sent: 28 March 2011 03:09 PM To: Marc Lampo Cc: dnsext@ietf.org; 'Olafur Gudmundsson' Subject: Re: [dnsext] Possible DNSSECbis clarifications On 2011-03-28, at 14:54, Marc Lampo wrote: > I agree that, if there is a record following that "last SOA", that SOA is > obviously not the last one of the zone transfert. > Which brings us to the question : > Where to put that RRSIG(SOA), knowing that potentially the SOA may change > between start and end of AXFR. > (in which case the receiving name server must refuse just downloaded zone > and attempt AXFR again) Anywhere between the two SOA records seems sensible to me. Joe From mgraff@isc.org Mon Mar 28 07:51:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629833A6A1E for ; Mon, 28 Mar 2011 07:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+CAsWEcmy6Z for ; Mon, 28 Mar 2011 07:51:45 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 7FB743A6989 for ; Mon, 28 Mar 2011 07:51:45 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 0A26DC941E for ; Mon, 28 Mar 2011 14:53:20 +0000 (UTC) (envelope-from mgraff@isc.org) Received: from dhcp-5329.meeting.ietf.org (unknown [IPv6:2001:df8:0:80:61e:64ff:fef5:5604]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E7FE6216C33 for ; Mon, 28 Mar 2011 14:53:18 +0000 (UTC) (envelope-from mgraff@isc.org) Message-ID: <4D90A0D4.2080002@isc.org> Date: Mon, 28 Mar 2011 16:53:08 +0200 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> <22FD4CD1-4EFB-412A-A307-485DEBE815CE@hopcount.ca> <01a901cbed53$e744b7e0$b5ce27a0$@lampo@eurid.eu> In-Reply-To: <01a901cbed53$e744b7e0$b5ce27a0$@lampo@eurid.eu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 14:51:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/28/11 4:19 PM, Marc Lampo wrote: > But then, how to link a RRSIG(SOA) with *its* SOA ? They are the same SOA in an AXFR. Identical in every way. In an IXFR, the delta change IS the data as well, with each section delimited by an SOA. So, you have the removed RRSIG(SOA) in the delete section and the new RRSIG(SIG) in the add section. There is no guarantee on record order in an AXFR other than the delimiters. You could receive: example.com SOA example.com A asdasd.example.com A example.com MX asdasd.example.com AAAA example.com SOA IMHO, the first SOA could be followed by its RRSIG(SOA), but this is not required. The final SOA cannot have any data after it, as per AXFR spec. Don't treat the RRSIG as special; for an AXFR or IXFR they are just records. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNkKDUAAoJEDRzoY2A7tzbahEH/R7oxD0WzxQmgH3pSwh3b3Fn MpZ0ItbN9bpTVUmYwTpXHFYYw9IZRIaymOnxIRIvnsWKEZEktfYdZp1dnlCBfexQ u/RUHC4tPYkAAHHVZj2Iecape0bFRBMoSku4Rd7BgJKGPTDWRY86ufqEK0f8bRR7 rW2W0EcjganyMe+4fK2tnUBCwhIefmrnL9MNHoWEYLcKDnzK7d5ZzArg30d7iARw vy/gYQUYwIX45aaPijOs3siDEBp1vOMeS5MsYASA0qu71bDNIPebNayt0bXs3fhH EirpaMDrJtwpEPe0P/WGhJx/mX724euXoQbRAi2PKlMiXwe3xu0vphle+CnxfyQ= =3uvB -----END PGP SIGNATURE----- From jabley@hopcount.ca Mon Mar 28 08:19:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA1D3A684A for ; Mon, 28 Mar 2011 08:19:09 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYXTtCi6IEEo for ; Mon, 28 Mar 2011 08:19:08 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by core3.amsl.com (Postfix) with ESMTP id B67BD3A67D6 for ; Mon, 28 Mar 2011 08:19:08 -0700 (PDT) Received: from [2001:df8:0:16:5a55:caff:feec:96bf] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4EFI-000Mhq-6N; Mon, 28 Mar 2011 15:20:45 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <01a901cbed53$e744b7e0$b5ce27a0$@lampo@eurid.eu> Date: Mon, 28 Mar 2011 17:20:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> <22FD4CD1-4EFB-412A-A307-485DEBE815CE@hopcount.ca> <01a901cbed53$e744b7e0$b5ce27a0$@lampo@eurid.eu> To: Marc Lampo X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 2001:df8:0:16:5a55:caff:feec:96bf X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org, 'Olafur Gudmundsson' Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:19:09 -0000 On 2011-03-28, at 16:19, Marc Lampo wrote: > But then, how to link a RRSIG(SOA) with *its* SOA ? If there are multiple, different SOAs found in an AXFR response then you = throw that response away. RFC 1034 seems fairly clear on that. When the poll shows that the zone has changed, then the secondary = server must request a zone transfer via an AXFR request for the zone. The = AXFR may cause an error, such as refused, but normally is answered by a sequence of response messages. The first and last messages must = contain the data for the top authoritative node of the zone. Intermediate messages carry all of the other RRs from the zone, including both authoritative and non-authoritative RRs. The stream of messages = allows the secondary to construct a copy of the zone. Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests. > Or simply : "try" all available RRSIG(SOA)'s, if at least one = validates > the SOA being looked at, then accept it. Zero or one RRSIG RRSets over the SOA, one SOA RR and one identical copy = of the same SOA record. I don't see a validation problem. Joe From marc.lampo@eurid.eu Mon Mar 28 08:59:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C610D3A6870 for ; Mon, 28 Mar 2011 08:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFTIknbhntKt for ; Mon, 28 Mar 2011 08:59:23 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by core3.amsl.com (Postfix) with ESMTP id AC76728C0CF for ; Mon, 28 Mar 2011 08:59:22 -0700 (PDT) X-ASG-Debug-ID: 1301328059-5cfc55220001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id WsxUGnPIyOECSA38; Mon, 28 Mar 2011 18:00:59 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id D8482E406A; Mon, 28 Mar 2011 17:55:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JChYb6oQzSo; Mon, 28 Mar 2011 17:55:36 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id C4B38E4053; Mon, 28 Mar 2011 17:55:36 +0200 (CEST) From: "Marc Lampo" To: "'Joe Abley'" References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> <22FD4CD1-4EFB-412A-A307-485DEBE815CE@hopcount.ca> <01a901cbed53$e744b7e0$b5ce27a0$@lampo@eurid.eu> In-Reply-To: Date: Mon, 28 Mar 2011 17:55:36 +0200 (CEST) X-ASG-Orig-Subj: RE: [dnsext] Possible DNSSECbis clarifications Message-ID: <01b701cbed61$61cd3480$25679d80$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcvtWwh2O+iF8A7nSbOhfw6FrDnD9QABWJnQ Content-Language: en-za X-Originating-IP: [172.20.5.39] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1301328059 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsext@ietf.org, 'Olafur Gudmundsson' Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:59:23 -0000 A "theorical" attack would be a "man-in-the-middle" change the trailing SOA, thus causing the secondary server to throw away each zone transfer it attempts (if it "believes" the second SOA is correct, in the absence of a valid RRSIG for it - that trailing SOA). If a secondary name server is prevented from downloaded update of the true zone data, this is a security issue, I would say. It may not be that easy to set up this kind of attack, but then again, perhaps in some time somebody might show it can be done. My feeling is that, with DNSSEC, both SOA's in a zone transfer should be signed in a proper way (that they can be validated) even if the SOA's differ. Which leaves us with another "hole" : Suppose potential attacker does indeed change trailing SOA, and fails to produce a validatable RRSIG, then what should the recipient do with the zone it downloaded ? Since it can no longer verify if the content of the zone did not change, at the master, since the start of the zone transfer. Marc -----Original Message----- From: Joe Abley [mailto:jabley@hopcount.ca] Sent: 28 March 2011 05:21 PM To: Marc Lampo Cc: dnsext@ietf.org; 'Olafur Gudmundsson' Subject: Re: [dnsext] Possible DNSSECbis clarifications On 2011-03-28, at 16:19, Marc Lampo wrote: > But then, how to link a RRSIG(SOA) with *its* SOA ? If there are multiple, different SOAs found in an AXFR response then you throw that response away. RFC 1034 seems fairly clear on that. When the poll shows that the zone has changed, then the secondary server must request a zone transfer via an AXFR request for the zone. The AXFR may cause an error, such as refused, but normally is answered by a sequence of response messages. The first and last messages must contain the data for the top authoritative node of the zone. Intermediate messages carry all of the other RRs from the zone, including both authoritative and non-authoritative RRs. The stream of messages allows the secondary to construct a copy of the zone. Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests. > Or simply : "try" all available RRSIG(SOA)'s, if at least one validates > the SOA being looked at, then accept it. Zero or one RRSIG RRSets over the SOA, one SOA RR and one identical copy of the same SOA record. I don't see a validation problem. Joe From miekg@atoom.net Mon Mar 28 09:12:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BFDD28C0D9 for ; Mon, 28 Mar 2011 09:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4djAf97UjVf3 for ; Mon, 28 Mar 2011 09:12:00 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by core3.amsl.com (Postfix) with ESMTP id 16B9F28C0D7 for ; Mon, 28 Mar 2011 09:12:00 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 0FA4340067; Mon, 28 Mar 2011 18:13:35 +0200 (CEST) Date: Mon, 28 Mar 2011 18:13:35 +0200 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20110328161335.GB11536@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> <22FD4CD1-4EFB-412A-A307-485DEBE815CE@hopcount.ca> <01a901cbed53$e744b7e0$b5ce27a0$@lampo@eurid.eu> <01b701cbed61$61cd3480$25679d80$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline In-Reply-To: <01b701cbed61$61cd3480$25679d80$@lampo@eurid.eu> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:12:01 -0000 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [ Quoting Marc Lampo at 17:55 on March 28 in "Re: [dnsext] Possible DNSSECbis cl"... ] > A "theorical" attack would be a "man-in-the-middle" change the trailing > SOA, thus causing the secondary server to throw away each zone transfer it > attempts (if it "believes" the second SOA is correct, in the absence of a > valid RRSIG for it - that trailing SOA). If you are scared of mitm attacks you should use tsig to secure the transfer IMO. grtz Miek --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk2Qs68ACgkQJYuFzziA0PbGAACg6H70VwMfW15d2Ab8k1ct+Mb2 lBsAnjYM7EhMVEBx4l4d6J9AZIULH5IH =86gH -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- From marka@isc.org Mon Mar 28 09:20:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461913A6A66 for ; Mon, 28 Mar 2011 09:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgrN576r2Da4 for ; Mon, 28 Mar 2011 09:19:58 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 29E273A6A61 for ; Mon, 28 Mar 2011 09:19:58 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 2789DC9423; Mon, 28 Mar 2011 16:21:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (dhcp-2606.meeting.ietf.org [130.129.38.6]) (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 7D63C216C22; Mon, 28 Mar 2011 16:21:32 +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 59CF9DA0471; Tue, 29 Mar 2011 03:21:20 +1100 (EST) To: "Marc Lampo" From: Mark Andrews References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> <22FD4CD1-4EFB-412A-A307-485DEBE815CE@hopcount.ca> <01a901cbed53$e744b7e0$b5ce27a0$@lampo@eurid.eu> <01b701cbed61$61cd3480$25679d80$@lampo@eurid.eu> In-reply-to: Your message of "Mon, 28 Mar 2011 17:55:36 +0200." <01b701cbed61$61cd3480$25679d80$@lampo@eurid.eu> Date: Tue, 29 Mar 2011 03:21:20 +1100 Message-Id: <20110328162120.59CF9DA0471@drugs.dv.isc.org> Cc: 'Olafur Gudmundsson' , dnsext@ietf.org Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:20:08 -0000 In message <01b701cbed61$61cd3480$25679d80$@lampo@eurid.eu>, "Marc Lampo" write s: > A "theorical" attack would be a "man-in-the-middle" change the trailing > SOA, thus causing the secondary server to throw away each zone transfer it > attempts (if it "believes" the second SOA is correct, in the absence of a > valid RRSIG for it - that trailing SOA). > > If a secondary name server is prevented from downloaded update of the true > zone data, this is a security issue, I would say. And we have solutions a solution to this. It's called TSIG and has been deployed for years with both signed and unsigned zones. > It may not be that easy to set up this kind of attack, but then again, > perhaps in some time somebody might show it can be done. > My feeling is that, with DNSSEC, both SOA's in a zone transfer should be > signed in a proper way (that they can be validated) even if the SOA's > differ. DNSSEC as currently deployed cannot do this as RRSIG's are not signed. Early DNSSEC specs had the concept of a zone SIG. This covered the signatures. > Which leaves us with another "hole" : > Suppose potential attacker does indeed change trailing SOA, and fails to > produce a validatable RRSIG, then what should the recipient do with the > zone it downloaded ? Since it can no longer verify if the content of the > zone did not change, at the master, since the start of the zone transfer. > > Marc -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mgraff@isc.org Mon Mar 28 09:23:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4143A6A64 for ; Mon, 28 Mar 2011 09:23:20 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW2oGgGK4vpK for ; Mon, 28 Mar 2011 09:23:09 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 9E4F83A6A63 for ; Mon, 28 Mar 2011 09:23:09 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id EAB225F985D for ; Mon, 28 Mar 2011 16:24:32 +0000 (UTC) (envelope-from mgraff@isc.org) Received: from dhcp-5329.meeting.ietf.org (dhcp-5329.meeting.ietf.org [130.129.83.41]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DE68C216C33 for ; Mon, 28 Mar 2011 16:24:29 +0000 (UTC) (envelope-from mgraff@isc.org) Message-ID: <4D90B63A.8050405@isc.org> Date: Mon, 28 Mar 2011 18:24:26 +0200 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> <22FD4CD1-4EFB-412A-A307-485DEBE815CE@hopcount.ca> <01a901cbed53$e744b7e0$b5ce27a0$@lampo@eurid.eu> <01b701cbed61$61cd3480$25679d80$@lampo@eurid.eu> <20110328161335.GB11536@miek.nl> In-Reply-To: <20110328161335.GB11536@miek.nl> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Possible DNSSECbis clarifications X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:23:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/28/11 6:13 PM, Miek Gieben wrote: > [ Quoting Marc Lampo at 17:55 on March 28 in "Re: [dnsext] Possible DNSSECbis cl"... ] >> A "theorical" attack would be a "man-in-the-middle" change the trailing >> SOA, thus causing the secondary server to throw away each zone transfer it >> attempts (if it "believes" the second SOA is correct, in the absence of a >> valid RRSIG for it - that trailing SOA). > > If you are scared of mitm attacks you should use tsig to secure the > transfer IMO. +1 DNSSEC is a query thing to me. I don't know of any servers that validate the transfer on load, but I am most familiar with BIND 9. But, suppose there was a MITM attack and data was changed, the server validated the data during transfer, and the data failed validation. It would then reject the transfer, just like if the SOAs don't match. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNkLY6AAoJEDRzoY2A7tzbNKAH/24AgRvdQZP14Bq5pJRM9MAk C7YUXaCaHCHS0W7ZX/r1idcqwFDQIAvMojPSRPfy7Tky+XXcNQ2OuctARaDKC41W MxhCy70T9KFLBI+mlIt543chxyibRQqJ9q/2d9TTu8NTqanUnm0PhX1TZdZruZUd 4A02K44iRKQpOPN1dJHbQ+zrG/JeG2K8tFGkOqm6h9ZDvWQLQnoWExUB2O/ufRsr kKaoLuUcIDXc5Q9ci3Ayf0DlD/77Hkbnuge6MI4cLc/wT8mzEJizeG3aawP/pJOE aU3mTw5w1PJxqj9D62hxhVBe9Qo+qlFLB8wYmzva8ns/QkprVUH+ZSGj+SLK8uQ= =7YMA -----END PGP SIGNATURE----- From kim.davies@icann.org Mon Mar 28 10:22:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9600728C0F7 for ; Mon, 28 Mar 2011 10:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALRfz2K6Ny5w for ; Mon, 28 Mar 2011 10:22:04 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 0A1C53A6842 for ; Mon, 28 Mar 2011 10:22:04 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 28 Mar 2011 10:23:41 -0700 From: Kim Davies To: "dnsext@ietf.org" Date: Mon, 28 Mar 2011 10:23:40 -0700 Thread-Topic: Short summary of ICANN ad-hoc meeting on variants Thread-Index: AcvtbOHJrTs7+UjxQOG6pwmO5YAa0A== Message-ID: <84A736AC-F70A-43D8-A2B1-13C29473026B@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_84A736ACF70A43D8A2B113C29473026Bicannorg_" MIME-Version: 1.0 Subject: [dnsext] Short summary of ICANN ad-hoc meeting on variants X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:22:06 -0000 --_000_84A736ACF70A43D8A2B113C29473026Bicannorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Here is a short summary of some of the key comments during the discussion f= rom the ad-hoc meeting held a little over a week ago in San Francisco regar= ding "variants". It was a freeform discussion so sorry the notes lack much = structure. =97 ICANN's project is to undertake a number of case studies of 5 different= scripts/cases in the IDN space, to try and establish problem statements re= garding what the end user expectation is on how IDNs should function. ICANN= is aware the IETF needs a careful statement of what problems need to be so= lved, and we don't have that right now. =97 What sort of statement of requirements would be useful for the IETF? IC= ANN is looking for assistance, so it asks the right questions, so that it c= omes up with a statement of requirement that is useful for the IETF. Commen= ts heard: 1. Back-and-forth is useful, rather than a statement; 2. The iter= ation process of creating the problem statement which starts to look at the= solution space, which in turn frames the problem space; 3. Important to fo= cus on the issues/impact further down the DNS tree, not just at the first l= evel of delegation. =97 3 separate issues could be defined. One that has no impact on IETF is w= hat registry policy is. Second is "user experience and sameness", but have = to define what "same" means to different people, but for certain subset of = same that can already be done in the DNS today. Third is other variant issu= es like final-form versus medial-form. Comments heard: when we talk about u= ser experience, it is not just end user but system admins etc. If you solve= the problem in the DNS but it means the admin has to configure lots of var= iants in mail/web/etc. configs, you've just shifted the work to a different= place, not solved it. If it is a requirement that configuring different va= riants for administrators goes away, it needs to solve the problem beyond t= he DNS space. =97 Need to be careful about false positives: it is probably worse to recei= ve a "the website is not configured" to a variant domain on a web site, tha= n to get an NXDOMAIN. If you delegate a bunch of variants to point to the o= ne place and the target machine can't cope, it is not useful. =97 .GR had to register variants from day 1, often register 4-5 names as bu= ndles, and use the DNAME in the DNS. Soon found out DNAME was not the right= way to deal with it, because there are specific things are not supported. = FIrstly, the first level were not the same. e.g. cnn.com a= nd www.cnn.com, because of the server; but if it is ID= N, www.cnn.com would work, cnn.com wo= uld go nowhere. DNAME starts one level below. There needs to be some kind o= f mechanism to take 3 different TLDs and turn them into 1. Recognise there = are DNSSEC issues to be considered. =97 One of the arguments is the users can manage variants, others say it is= n't. It is useful to know if that is a consideration to help make the trade= offs. Another thing to recognise is there are things we simply won't do, an= xious to communicate there are some things that can't be changed. e.g. Not = going to make an RR type that makes DNSSEC deployment impractical, Not goi= ng to do something that solves problems that make things easy at the top-le= vel, but make life hard for those further down the tree. Need to be consist= ent throughout the DNS. One of the proposals works only for leaf zones only= , maybe that is an OK tradeoff, but suspicious of that. =97 Concern that talk is around trying to resolve 2 domains names resolve t= o 1 IP address, particular the focus of those with already have 2 strings. = As soon as you make those domains look the same, we'll run into the next pr= oblem, whatever that is. Just solving that small problem, without looking a= t the other potential problems, is being naive and need to look to the bigg= er problems, so that any solution doesn't make other problems worse/bigger/= difficult to solve. =97 There are end user expectations, wide range of end users, not just the = user who uses a web browser; its the web developer that codes a web page; t= he guy that runs the website; guy that manages the DNS throughout the tree; de= velopers that build software; pretty sure we'll invent security problems we= havent thought of before. Concerned that being dangerous by assming the an= swer to the is in the DNS. (Disagree, we're not) Pretty sure we could get H= TTP/SMTP/etc people here. Need to work out what the use cases are, and not = just assume they are DNS solutions. Lets identify the use cases we know of.= People ave tried before, you'll be able to help us. Can we try and focus o= n identifying the use cases first, and go from there? =97 Linguistic scope is up to policy to come up. Dont care how you decide w= hich strings are considered equivalent. Do care if there is a difference be= tween whether they are universal or zone-by-zone equivelance, as it dictate= s solution. cross site scripting issues, mail configuration, etc. are issue= s that are in the middle and the ones that need to be gone through. Who are= the appropriate people to help solve these problems. =97 See the criticial piece that is missing is "How do you mean, the user n= eeds these things to work the same way?" Dont know how else to do that but = to talk about the use case of the users, not in specifics - not to survey t= he world - but can talk to linguistic people, UI / human interaction people= , and understand "What happens to an Arabic user that is confronted with th= is string? What will the user do?" Last time we faced this problem, made th= e decision in the DNS "color" and "colour" are not the same label. User com= munity may be different when DNS first invented, than a new iPhone user who= types in an IDN. New users dont have a theory on how the computer works. D= ont know if it OK to have one canonical label, and the rest are second clas= s. If we agree on that a bunch of solutions can be taken off the table. Tha= ts the kind of information wanted from this effort. This effort will be hop= eless unless get the feedback on sameness. It is a lousy tradeoff in config= urations balloon. =97 Regarding use cases: Non-technical end user who uses an iPhone. Describ= ing a context, and a user of the context, so the discussion is not merely b= etween 2 strings, but rather the role of the confusion to a particular user= . Could come up with, for example, a use case once a year that doesn't matt= er very much. Probably not a problem to solve. On the other hand, happens f= requently and consequence is really bad. That is a higher priority. Compari= ng errors in context of other problems in use, makes it easier to understan= d importance and alternatives. =97 Conclusion: Meeting wasnt to solve problems, but to share a sense of th= e enormity of the task. Not saying that ICANN's project will come up with a= ny case that requires a technical or DNS solution, but there may be some th= at are best solved with one. Would like to keep that option open. This has = been an informal meeting, taking advantage of people that were available he= re. Some complaint it wasn't scheduled in time, no proper agenda, not open = to all. That wasnt the intent. If there is need for a formal meeting, ICANN= can help organise a meeting. Leave that to you to decide. Clearly ICANN ne= eds help in identifying the use cases, help in looking at those, considerin= g the implications of any possible solution, like configuration problems, a= buse problems, whatever. Have as much input that is appropriate. ps. The formal meeting that was on the agenda was recorded, you can view it= athttp://icann.adobeconnect.com/p73581095/ kim --_000_84A736ACF70A43D8A2B113C29473026Bicannorg_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Here is a short summary of some o= f the key comments during the discussion from the ad-hoc meeting held a lit= tle over a week ago in San Francisco regarding "variants". It was a freefor= m discussion so sorry the notes lack much structure.

=97 ICANN's pr= oject is to undertake a number of case studies of 5 different scripts/cases= in the IDN space, to try and establish problem statements regarding what t= he end user expectation is on how IDNs should function. ICANN is aware the = IETF needs a careful statement of what problems need to be solved, and we d= on't have that right now.

=97 What sort of statement of requirement= s would be useful for the IETF? ICANN is looking for assistance, so it asks= the right questions, so that it comes up with a statement of requirement t= hat is useful for the IETF. Comments heard: 1. Back-and-forth is useful, ra= ther than a statement; 2. The iteration process of creating the problem sta= tement which starts to look at the solution space, which in turn frames the= problem space; 3. Important to focus on the issues/impact further down the= DNS tree, not just at the first level of delegation.

=97 3 separate= issues could be defined. One that has no impact on IETF is what registry p= olicy is. Second is "user experience and sameness", but have to define what= "same" means to different people, but for certain subset of same that can = already be done in the DNS today. Third is other variant issues like final-= form versus medial-form. Comments heard: when we talk about user experience= , it is not just end user but system admins etc. If you solve the problem i= n the DNS but it means the admin has to configure lots of variants in mail/= web/etc. configs, you've just shifted the work to a different place, not so= lved it. If it is a requirement that configuring different variants for adm= inistrators goes away, it needs to solve the problem beyond the DNS space.<= /span><= br>=97 Need to be careful about false positives: it is probably worse t= o receive a "the website is not configured" to a variant domain on a web si= te, than to get an NXDOMAIN. If you delegate a bunch of variants to point t= o the one place and the target machine can't cope, it is not useful.=
=97 .GR had to register variants from day 1, often register 4-5 names as b= undles, and use the DNAME in the DNS. Soon found out DNAME was not the righ= t way to deal with it, because there are specific things are not supported.= FIrstly, the first level were not the same. e.g. cnn.com and www.cnn= .com, because of the server; but if it is IDN, www.cnn.com would work, cnn.com would go nowhere. DNAME starts one level below. Ther= e needs to be some kind of mechanism to take 3 different TLDs and turn them= into 1. Recognise there are DNSSEC issues to be considered.

= =97 One= of the arguments is the users can manage variants, others say it isn't. It= is useful to know if that is a consideration to help make the tradeoffs. A= nother thing to recognise is there are things we simply won't do, anxious t= o communicate there are some things that can't be changed. e.g. Not going t= o make an RR type that makes DNSSEC deployment impractical,  Not going= to do something that solves problems that make things easy at the top-leve= l, but make life hard for those further down the tree. Need to be consisten= t throughout the DNS. One of the proposals works only for leaf zones only, = maybe that is an OK tradeoff, but suspicious of that.

=97 Concern th= at talk is around trying to resolve 2 domains names resolve to 1 IP address= , particular the focus of those with already have 2 strings. As soon as you= make those domains look the same, we'll run into the next problem, whateve= r that is. Just solving that small problem, without looking at the other po= tential problems, is being naive and need to look to the bigger problems, s= o that any solution doesn't make other problems worse/bigger/difficult to s= olve. 

=97 There are end user expectations, wide range of end u= sers, not just the user who uses a web browser; its the web developer that = codes a web page; the 
guy that runs the website; guy that manages = the DNS throughout the tree; developers that build software; pretty sure we= 'll invent security problems we havent thought of before. Concerned that be= ing dangerous by assming the answer to the is in the DNS. (Disagree, we're = not) Pretty sure we could get HTTP/SMTP/etc people here. Need to work out w= hat the use cases are, and not just assume they are DNS solutions. Lets ide= ntify the use cases we know of. People ave tried before, you'll be able to = help us. Can we try and focus on identifying the use cases first, and go fr= om there?

=97 Linguistic scope is up to policy to come up. Dont care= how you decide which strings are considered equivalent. Do care if there i= s a difference between whether they are universal or zone-by-zone equivelan= ce, as it dictates solution. cross site scripting issues, mail configuratio= n, etc. are issues that are in the middle and the ones that need to be gone= through. Who are the appropriate people to help solve these problems.
<= /span><= br>

=97 Regarding use cases: Non-technical end us= er who uses an iPhone. Describing a context, and a user of the context, so = the discussion is not merely between 2 strings, but rather the role of the = confusion to a particular user. Could come up with, for example, a use case= once a year that doesn't matter very much. Probably not a problem to solve= . On the other hand, happens frequently and consequence is really bad. That= is a higher priority. Comparing errors in context of other problems in use= , makes it easier to understand importance and alternatives.

= =97 Con= clusion: Meeting wasnt to solve problems, but to share a sense of the enorm= ity of the task. Not saying that ICANN's project will come up with any case= that requires a technical or DNS solution, but there may be some that are = best solved with one. Would like to keep that option open. This has been an= informal meeting, taking advantage of people that were available here. Som= e complaint it wasn't scheduled in time, no proper agenda, not open to all.= That wasnt the intent. If there is need for a formal meeting, ICANN can he= lp organise a meeting. Leave that to you to decide. Clearly ICANN needs hel= p in identifying the use cases, help in looking at those, considering the i= mplications of any possible solution, like configuration problems, abuse pr= oblems, whatever. Have as much input that is appropriate.

ps. The fo= rmal meeting that was on the agenda was recorded, you can view it at= http://icann.adobeconnect.com= /p73581095/

kim


= --_000_84A736ACF70A43D8A2B113C29473026Bicannorg_-- From ogud@ogud.com Mon Mar 28 10:35:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197CA28C104 for ; Mon, 28 Mar 2011 10:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiXhuJFohwUJ for ; Mon, 28 Mar 2011 10:35:35 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A3A3F28B56A for ; Mon, 28 Mar 2011 10:35:35 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2SHbBgH054364 for ; Mon, 28 Mar 2011 13:37:12 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4D90C747.2000703@ogud.com> Date: Mon, 28 Mar 2011 13:37:11 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dnsext] WG Document adoption: Resimprove X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:35:37 -0000 As discussed in the WG meeting today, this is a formal request for people to say that they support the adoption of the following document: http://tools.ietf.org/html/draft-vixie-dnsext-resimprove This documents goals are: state explicitly things that RFC1034/1035 is not clear enough. recommend behaviors that are beneficial for resolution In the current draft there are 3 recommendations, some more may be added. Note: supporting this document for adoption does not imply you support all the ideas in the document. Under the working rules of the WG we need at least 5 members to say that they support this work and commit to perform reviews of this document. If we do not have 5 people step forward by April 8'th the document will not be adopted. Olafur & Andrew From scott.rose@nist.gov Mon Mar 28 11:02:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776B13A6A59 for ; Mon, 28 Mar 2011 11:02:48 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tqRg-0uQ91i for ; Mon, 28 Mar 2011 11:02:47 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 9B7133A67D1 for ; Mon, 28 Mar 2011 11:02:46 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p2SI4BQZ011798 for ; Mon, 28 Mar 2011 14:04:11 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 28 Mar 2011 14:03:35 -0400 From: "Rose, Scott W." To: "dnsext@ietf.org" Date: Mon, 28 Mar 2011 14:04:10 -0400 Thread-Topic: [dnsext] Report from the chairs for IETF 80 Thread-Index: AcvtcnRyStw6yZW+SqepOTeAPIm+Dg== Message-ID: References: <20110328085104.GJ85412@crankycanuck.ca> In-Reply-To: <20110328085104.GJ85412@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Subject: Re: [dnsext] Report from the chairs for IETF 80 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 18:02:48 -0000 On Mar 28, 2011, at 4:51 AM, Andrew Sullivan wrote: >=20 >=20 > draft-ietf-dnsext-rfc2672bis-dname >=20 > - Contemporary with IETF 79, the chairs committed to running a > last call on this draft. They failed to do so. >=20 There was still this open issue: http://www.ietf.org/mail-archive/web/dnsext/current/msg10339.html Not a lot of discussion, still accepting input if there are any dissenting = views. >=20 > draft-ietf-dnsext-dnssec-algo-signal >=20 > - This draft is being shepherded by Patrik F=E4ltstr=F6m. It has > not engendered much discussion since the -00 was uploaded. > Does that mean people think it is ready? >=20 There were some comments. Will post -01 version of the draft before expira= tion (~2 weeks). Scott =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From george.barwood@blueyonder.co.uk Mon Mar 28 14:27:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811093A6A74 for ; Mon, 28 Mar 2011 14:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-YJwiCNlUo3 for ; Mon, 28 Mar 2011 14:27:46 -0700 (PDT) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by core3.amsl.com (Postfix) with ESMTP id 6A6C23A688B for ; Mon, 28 Mar 2011 14:27:46 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.2]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110328212918.GNZZ6199.mtaout02-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Mon, 28 Mar 2011 22:29:18 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1Q4Jzx-0006Z1-V7; Mon, 28 Mar 2011 22:29:18 +0100 Message-ID: <8EA8D1A36B8F4968ABE973C39CA5E0E0@local> From: "George Barwood" To: "Tony Finch" , References: Date: Mon, 28 Mar 2011 22:29:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=WnkCSP1BjtsA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=mhM0g1CRYoov56rjHWgA:9 a=fSaDPs04n90Qeiyn_32jZs4IQtEA:4 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 21:27:47 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRvbnkgRmluY2giIDxkb3RA ZG90YXQuYXQ+DQpUbzogPGRuc2V4dEBpZXRmLm9yZz4NClNlbnQ6IE1vbmRheSwgTWFyY2ggMjgs IDIwMTEgMzoyNCBQTQ0KU3ViamVjdDogW2Ruc2V4dF0gZHJhZnQtdml4aWUtZG5zZXh0LXJlc2lt cHJvdmUgLSBOWERPTUFJTiBmb3IgZW1wdHlub24tdGVybWluYWxzDQoNCg0KPiBBcmlzaW5nIGZy b20gdGhlIGRpc2N1c3Npb24gYXQgdGhlIG1lZXRpbmcgYWJvdXQgdHJlYXRpbmcgYSBjYWNoZWQN Cj4gTlhET01BSU4gYXMgYXBwbHlpbmcgdG8gYWxsIGNoaWxkIGRvbWFpbnMuLi4NCj4gDQo+IFRo ZSBtYWluIGNvbmNlcm4gYWJvdXQgdGhpcyBjbGFyaWZpY2F0aW9uaW4gaXMgYnVnZ3kgaW1wbGVt ZW50YXRpb25zIHRoYXQNCj4gZ2l2ZSBhbiBOWERPTUFJTiBmb3IgZW1wdHkgbm9uLXRlcm1pbmFs IG5hbWVzIHRoYXQgaGF2ZSBub24tZW1wdHkgY2hpbGQNCj4gZG9tYWlucy4gVGhlIGV4YW1wbGVz IGNpdGVkIHdlcmUgREpCRE5TIGFuZCBpbiBwYXJ0aWN1bGFyIHJibGRuc2QuIChJDQo+IHByZXN1 bWUgdGhlcmUgYXJlIG90aGVycyB0aGF0IHdlIGRvbid0IGtub3cgYWJvdXQuKQ0KDQpDb3VsZCB0 aGUgbmV3IGludGVycHJldGF0aW9uIGJlIHJlc3RyaWN0ZWQgdG8gY2FzZXMgd2hlcmUgdGhlcmUg YXJlIE5TRUMgb3IgTlNFQzMgcmVjb3Jkcw0KdGhhdCBzaG93IHRoYXQgdGhlcmUgYXJlIG5vIGNo aWxkIHN1Yi1kb21haW5zPw0KDQpUaGF0IHdvdWxkIHNlZW0gdG8gYXZvaWQgYW55IGNvbXBhdGli aWxpdHkgcHJvYmxlbXMuDQoNCkknZCBhbHNvIGxpa2UgdG8gc2VlIHRoZSBzdGFuZGFyZCB1cGRh dGVkIHRvIGFsbG93IHJlc29sdmVycyB0byBpbmZlciBOb0RhdGEgY29uZGl0aW9ucw0KZnJvbSBO U0VDL05TRUMzIHJlY29yZHMgKCB0aGUgc3RhbmRhcmQgZG9lcyBub3QgZXhhY3RseSBmb3JiaWQg dGhpcyBhdCBwcmVzZW50LCBidXQNCnRoZXJlIGlzIGRpc2NvdXJhZ2luZyBsYW5ndWFnZSApLg0K DQpGaW5hbGx5LCBJJ20gaGFwcHkgdG8gc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgZHJhZnQtdml4 aWUtZG5zZXh0LXJlc2ltcHJvdmUNCg0KR2VvcmdlDQo= From colm@allcosts.net Mon Mar 28 15:22:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4D33A679F for ; Mon, 28 Mar 2011 15:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNk2QECXjUIZ for ; Mon, 28 Mar 2011 15:22:16 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id CBF8D3A68DF for ; Mon, 28 Mar 2011 15:22:12 -0700 (PDT) Received: by fxm15 with SMTP id 15so3352498fxm.31 for ; Mon, 28 Mar 2011 15:23:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.14.22 with SMTP id e22mr5154863faa.64.1301351029291; Mon, 28 Mar 2011 15:23:49 -0700 (PDT) Received: by 10.223.96.8 with HTTP; Mon, 28 Mar 2011 15:23:49 -0700 (PDT) Date: Mon, 28 Mar 2011 15:23:49 -0700 Message-ID: From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:22:17 -0000 Forwarding due to relevancy ... ---------- Forwarded message ---------- From: D. J. Bernstein Date: Mon, Mar 28, 2011 at 3:13 PM Subject: Re: Fixing the NXDOMAIN/NODATA bug in tinydns To: dns@list.cr.yp.to Returning NXDOMAIN for empty nonterminals is not a bug. It is perfectly interoperable behavior that has been used and continues to be used by many different pieces of DNS software, including many versions of BIND. The behavior has never caused problems for DNS users. Fun historical fact: This behavior was put into the first version of tinydns after a public statement by BIND maintainer Paul Vixie saying that this behavior is _required_. Here's the exact Vixie quote: =A0 RFC 2308 implicitly outlawed BIND's behaviour, which is to return =A0 NOERROR/ANCOUNT=3D0 for empty nonterminals. After RFC 2308, empty =A0 nonterminals are signalled with NXDOMAIN. A much more recent statement from Vixie claims that BIND never actually did this--- =A0 i don't think bind or nominum or microsoft's or american internet's =A0 (now cisco's) authority servers have ever sent nxdomain on an empty =A0 non-terminal, and for a long time that was 100% of the market. ---but that's totally wrong. At least five consecutive years of BIND releases returned NXDOMAIN for empty nonterminals, contrary to Vixie's statement. (The behavior was suddenly changed in BIND 9.2.3, RT #4715.) Here's a more detailed message that I tried to send to namedroppers (the IETF dnsext mailing list) on this topic a month ago. I say "tried" because this message didn't show up on the mailing list even after I sent it to the list, sent it again to the "moderator", and sent it once again to the list. ---D. J. Bernstein =A0 Research Professor, Computer Science, University of Illinois at Chicago Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, =A0 =A0 =A0 =A0for Resiliency, Robustness, and Responsiveness From: "D. J. Bernstein" Date: 23 Feb 2011 22:32:37 -0000 To: dnsext@ietf.org Message-ID: <20110223223237.15451.qmail@cr.yp.to> Here's a Paul Vixie quote from a message here dated 8 December 1999 (http://groups.google.com/group/comp.protocols.dns.std/msg/69e4500e7b7d73c8= ): =A0 RFC 2308 implicitly outlawed BIND's behaviour, which is to return =A0 NOERROR/ANCOUNT=3D0 for empty nonterminals. After RFC 2308, empty =A0 nonterminals are signalled with NXDOMAIN. This use of NXDOMAIN has obvious benefits for some server-side database structures. My DNS server software, tinydns, =A0 * was released a few weeks later, =A0 * signals empty nonterminals with NXDOMAIN, =A0 * has become increasingly popular among DNS administrators, and =A0 * now publishes the DNS records for millions of second-level domains. Many versions of BIND, and many other DNS servers currently deployed on the Internet, also signal empty nonterminals with NXDOMAIN. If a cache misinterprets NXDOMAIN as applying to subdomains, the cache doesn't work correctly on the Internet today. Here's a concrete example to make clear what this means: =A0 * The NS records for citysearch.com today are d.ns.citysearch.com and =A0 =A0 e.ns.citysearch.com. =A0 * ns.citysearch.com today returns NXDOMAIN. =A0 * If a cache follows the citysearch.com NS records to d.ns... and =A0 =A0 e.ns..., but then misinterprets the ns... NXDOMAIN as applying to =A0 =A0 d.ns... and e.ns..., then it will incorrectly conclude that =A0 =A0 citysearch.com has broken glue, and it will respond SERVFAIL for =A0 =A0 www.citysearch.com, completely screwing the user who wanted to see =A0 =A0 the www.citysearch.com web page. Caches have to, and as far as I know do, apply NXDOMAIN only to "the same " (RFC 2308, Section 5), easily avoiding this type of interoperability problem. Anyone who believes the IETF mission statement in RFC 3935 would expect IETF to promote interoperability by issuing a warning saying that cache implementors MUST NOT misinterpret NXDOMAIN as applying to subdomains---if this isn't already sufficiently clear from the existing IETF documents such as RFC 2308. Years after his 1999 "After RFC 2308, empty nonterminals are signalled with NXDOMAIN" statement, Vixie suddenly changed his view and started issuing highly irresponsible documents (such as "wcard-clarify" in 2003 and "dnsext-resimprove" in 2010) encouraging cache implementors to misinterpret NXDOMAIN as applying to subdomains---creating exactly the type of failures described above. At least two cache implementors have spoken up here to say that this cache behavior _doesn't_ work, _can't_ be turned on, and _isn't_ current practice, so how can it possibly be labelled "best current practice"? This has been extensively discussed here before, and nowhere in any of the discussions has there been any explanation of how this clumsy, non-interoperable, user-antagonistic change in cache behavior would provide any benefits for the Internet. Does someone think that the Internet's bandwidth is being saturated by DNS queries for nonexistent subdomains of nonexistent domains, or that users are spending noticeable amounts of time waiting for the answers? Bottom line: On behalf of the millions of users who rely on my DNS software (and other deployed software that signals empty nonterminals with NXDOMAIN), I object to any attempt to change the definition of NXDOMAIN from the RFC 2308/Vixie 1999/BIND 9/tinydns/etc. definition into something that applies to subdomains. In particular, I object to the dnsext-reimprove document. ---D. J. Bernstein =A0 Research Professor, Computer Science, University of Illinois at Chicago --=20 Colm From vixie@isc.org Mon Mar 28 15:29:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A12A3A6A2B for ; Mon, 28 Mar 2011 15:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZrXQ9HU7kfU for ; Mon, 28 Mar 2011 15:29:41 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 96D773A65A5 for ; Mon, 28 Mar 2011 15:29:41 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 934A6A1019; Mon, 28 Mar 2011 22:31:18 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= In-Reply-To: Your message of "Mon, 28 Mar 2011 15:23:49 MST." References: X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 28 Mar 2011 22:31:18 +0000 Message-ID: <34319.1301351478@nsa.vix.com> Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:29:42 -0000 thanks colm. i don't think "but bind used to do it this way" or "but paul once said it was ok" are acceptable input to this discussion -- does anyone? From wwwrun@rfc-editor.org Mon Mar 28 15:35:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422AD3A6A90; Mon, 28 Mar 2011 15:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+3rwetmZSO8; Mon, 28 Mar 2011 15:35:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 4CAE73A6A8F; Mon, 28 Mar 2011 15:35:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 46FF3E073A; Mon, 28 Mar 2011 15:37:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110328223727.46FF3E073A@rfc-editor.org> Date: Mon, 28 Mar 2011 15:37:27 -0700 (PDT) Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] BCP 42, RFC 6195 on Domain Name System (DNS) IANA Considerations X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:35:56 -0000 A new Request for Comments is now available in online RFC libraries. BCP 42 RFC 6195 Title: Domain Name System (DNS) IANA Considerations Author: D. Eastlake 3rd Status: Best Current Practice Stream: IETF Date: March 2011 Mailbox: d3e3e3@gmail.com Pages: 17 Characters: 33790 Obsoletes: RFC5395 Updates: RFC1183, RFC3597 See Also: BCP0042 I-D Tag: draft-ietf-dnsext-5395bis-03.txt URL: http://www.rfc-editor.org/rfc/rfc6195.txt This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This memo documents an Internet Best Current Practice. This document is a product of the DNS Extensions Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From matthew@dempsky.org Mon Mar 28 15:43:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF483A6A83 for ; Mon, 28 Mar 2011 15:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz4LYqBsPRef for ; Mon, 28 Mar 2011 15:43:13 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 01BD23A6948 for ; Mon, 28 Mar 2011 15:43:12 -0700 (PDT) Received: by iwn39 with SMTP id 39so4127389iwn.31 for ; Mon, 28 Mar 2011 15:44:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.122.199 with SMTP id m7mr4659267ibr.192.1301352290568; Mon, 28 Mar 2011 15:44:50 -0700 (PDT) Received: by 10.231.171.15 with HTTP; Mon, 28 Mar 2011 15:44:50 -0700 (PDT) In-Reply-To: <34319.1301351478@nsa.vix.com> References: <34319.1301351478@nsa.vix.com> Date: Mon, 28 Mar 2011 15:44:50 -0700 Message-ID: From: Matthew Dempsky To: Paul Vixie Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:43:13 -0000 2011/3/28 Paul Vixie : > thanks colm. i don't think "but bind used to do it this way" or "but paul > once said it was ok" are acceptable input to this discussion -- does anyone? You're mischaracterizing the argument. The concern is that servers that follow the old behavior are still in widespread use, and suddenly changing the interpretation will cause massive backwards compatibility problems. Just tie the new behavior to an EDNS option or something. No one's going to protest that. From colm@allcosts.net Mon Mar 28 15:44:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40D43A6A87 for ; Mon, 28 Mar 2011 15:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OA-MlyePJjnp for ; Mon, 28 Mar 2011 15:44:36 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id D95293A6948 for ; Mon, 28 Mar 2011 15:44:35 -0700 (PDT) Received: by fxm15 with SMTP id 15so3362832fxm.31 for ; Mon, 28 Mar 2011 15:46:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.143.12 with SMTP id s12mr5169615fau.121.1301352373068; Mon, 28 Mar 2011 15:46:13 -0700 (PDT) Received: by 10.223.96.8 with HTTP; Mon, 28 Mar 2011 15:46:13 -0700 (PDT) In-Reply-To: <34319.1301351478@nsa.vix.com> References: <34319.1301351478@nsa.vix.com> Date: Mon, 28 Mar 2011 15:46:13 -0700 Message-ID: From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Paul Vixie Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:44:36 -0000 2011/3/28 Paul Vixie : > thanks colm. i don't think "but bind used to do it this way" or "but paul > once said it was ok" are acceptable input to this discussion -- does anyone? The first part; yes. Compatibility with implementations, legacy or otherwise, is definitely on-topic. -- Colm From dougb@dougbarton.us Mon Mar 28 16:33:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479E43A6A9A for ; Mon, 28 Mar 2011 16:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thAcBi72JCpm for ; Mon, 28 Mar 2011 16:33:20 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id E89F63A6A74 for ; Mon, 28 Mar 2011 16:33:19 -0700 (PDT) Received: (qmail 28944 invoked by uid 399); 28 Mar 2011 23:34:52 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 28 Mar 2011 23:34:52 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4D911B1B.1050409@dougbarton.us> Date: Mon, 28 Mar 2011 16:34:51 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Kim Davies References: <84A736AC-F70A-43D8-A2B1-13C29473026B@icann.org> In-Reply-To: <84A736AC-F70A-43D8-A2B1-13C29473026B@icann.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Short summary of ICANN ad-hoc meeting on variants X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:33:21 -0000 On 03/28/2011 10:23, Kim Davies wrote: > 2. The iteration process of creating the problem statement which starts > to look at the solution space, which in turn frames the problem space Kim, Thanks for your write-up of this, I found it very helpful. My only (major) concern is the bit above, which aside from being tautological is not what I personally was hoping to see. IMO we are much better served if the people asking for "sameness" could tell us, in simple terms, what it is that they mean by that, without limitation. Then the technologists can do our best to break the desired solution into manageable problems to solve. Otherwise I think we are needlessly restricting ourselves to "inside the box" thinking which I fear will eliminate the possibility of some truly clever solutions. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From dotis@mail-abuse.org Mon Mar 28 18:17:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A6528C0F1 for ; Mon, 28 Mar 2011 18:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq0JdkY1n0gi for ; Mon, 28 Mar 2011 18:17:32 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id D478C3A6833 for ; Mon, 28 Mar 2011 18:17:32 -0700 (PDT) Received: from us-dougo-mac.us.trendnet.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 74002A94442 for ; Tue, 29 Mar 2011 01:20:00 +0000 (UTC) Message-ID: <4D913386.3090002@mail-abuse.org> Date: Mon, 28 Mar 2011 18:19:02 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 01:17:34 -0000 On 3/26/11 10:51 AM, Ted Hardie wrote: > The draft under discussion was updated just before the meeting, and > it has some useful updates. I think, however, it is anxious to scope > the problem in ways that leave out what I believe is a well-recognized > aspect of the basic desire of those who brought the work forward. The > draft says: > > > To some extent, the desired behavior can be described: "identical DNS > resolution" means that the process of resolving two domain names will > end with the same result, in most cases the same IP address. In the > history of DNS protocol development, there have been two attempts to > specify such "identical resolution" behavior:CNAME[RFC1034] which > maps or redirects itself, and DNAME[RFC2672] which maps or redirects > its descendants. In the case of bundles or groups of names, however, > some operators have asserted they need identical DNS resolution at > all levels' domain names, including the domain name itself and its > descendants. > > But the reality is that the operators actually want the applications > to treat two domain names as the same. That's a lot harder than > simply having the same IP returned when looking up an A record at each > one. Especially in the case of secured zones, it involves issuing > multiple certificates or certs that cover both, and otherwise ensuring > that whatever services are present at that IP can effectively handle > either name. It's moderately obvious that this is a tougher job than > putting in a CNAME or DNAME. DNAME does not offer a practical solution when implemented at the roots, since it lacks the meta information that would be needed to synchronize different zones. It seems possible to use this scheme to construct the resources to convey which domains are replicated, such as as placing this under some label, like "xn--lba" or "._®--". Any alias scheme will cause unwanted delays. With two different encoding for A-labels, 2003 or 2008, dropping A-labels and using U-labels reduces the number of domains to be replicated. See http://tools.ietf.org/html/rfc6055 While it is clear A-labels are needed by e-mail applications, the wording about what is legal is less clear when aliased resources are employed. Are A-labels really needed and would http://tools.ietf.org/id/draft-vixie-dnsext-dnsshadow-00.txt provide a means to register domain name-sets? -Doug From vixie@isc.org Tue Mar 29 00:19:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA713A685D for ; Tue, 29 Mar 2011 00:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBrsbD-LkGup for ; Tue, 29 Mar 2011 00:19:03 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id DC13C3A67AC for ; Tue, 29 Mar 2011 00:19:02 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 76F04A1059 for ; Tue, 29 Mar 2011 07:20:38 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Mon, 28 Mar 2011 15:44:50 MST." References: <34319.1301351478@nsa.vix.com> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Tue, 29 Mar 2011 07:20:38 +0000 Message-ID: <65033.1301383238@nsa.vix.com> Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:19:03 -0000 > Date: Mon, 28 Mar 2011 15:44:50 -0700 > From: Matthew Dempsky > > You're mischaracterizing the argument. The concern is that servers > that follow the old behavior are still in widespread use, and suddenly > changing the interpretation will cause massive backwards compatibility > problems. i don't think so. nobody is querying intersticial names from an rbl so even if there were millions of rbldnsd servers running on autopilot it would not have an operational effect. but there are at best thousands of rbldnsd servers and none of them are on autopilot. tinydns may have a larger installed base, but there are very few empty nonterminals in the tinydns datasets i have seen. there just is no "widespread use" of the "old behaviour". > Just tie the new behavior to an EDNS option or something. No one's > going to protest that. if it would take a wire protocol change then it's not a clarification and i don't think anybody would say it was worth adding complexity for. (not even me.) From ajs@shinkuro.com Tue Mar 29 01:54:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B0E3A687E for ; Tue, 29 Mar 2011 01:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iab9PFuCUPLb for ; Tue, 29 Mar 2011 01:54:45 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A61313A683C for ; Tue, 29 Mar 2011 01:54:45 -0700 (PDT) Received: from shinkuro.com (dhcp-414f.meeting.ietf.org [130.129.65.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 80A531ECB41D for ; Tue, 29 Mar 2011 08:56:08 +0000 (UTC) Date: Tue, 29 Mar 2011 04:56:00 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110329085558.GA87566@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] list-meta: moderation (was: Fwd: djb on NXDOMAIN/NODATA for non-terminals) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:54:46 -0000 This is a meta notice about list moderation, for the record. I normally wouldn't bother, but I want to make sure that nobody is under the mistaken impression that we are suppressing legitimate comment. On Mon, Mar 28, 2011 at 03:23:49PM -0700, Colm MacCárthaigh wrote: > Forwarding due to relevancy ... > > ---------- Forwarded message ---------- > From: D. J. Bernstein > Date: Mon, Mar 28, 2011 at 3:13 PM > Subject: Re: Fixing the NXDOMAIN/NODATA bug in tinydns > To: dns@list.cr.yp.to > Here's a more detailed message that I tried to send to namedroppers (the > IETF dnsext mailing list) on this topic a month ago. I say "tried" > because this message didn't show up on the mailing list even after I > sent it to the list, sent it again to the "moderator", and sent it once > again to the list. I do have, still in my INBOX in fact, a message from Dr Bernstein about his message not getting posted. I also have my response, saying "please send me the message if you're unable to get it posted", along with a lot of detail of what the mailing list software is, where it is located and by whom it is operated, what I found when I tried to find his message, and so on. I called attention specifically to the fact that namedroppers was no longer the WG's mailing list and that mail to the old address seemed to drop from the face of the earth. I asked him whether he had mail logs that showed his message was in fact accepted for delivery, because I was unable to find his message anywhere. What I do not have is the original message that Dr Bernstein refers to in his comments. As far as I can tell, I never received that. Now, it would not completely surprise me to learn that I had somehow managed to delete not once, but three times, the same text that came to me via three different channels. But I would be at least mildly surprised. If Dr Bernstein has further difficulties, I invite him (again) to contact me, Olafur, or both of us. We are the moderators (or, I guess, "moderators") of the list. The address for the current chairs (whoever they may be, as long as there's a WG) is dnsext-chairs@tools.ietf.org. If Dr Bernstein believes he was ill treated by me (I take full responsibility -- Olafur was not involved in the conversation to my knowledge), I regret it, and would like to know what he wishes I would do to make this less difficult for him. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From fweimer@bfk.de Tue Mar 29 02:23:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2373A692D for ; Tue, 29 Mar 2011 02:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ona+YurRdvs5 for ; Tue, 29 Mar 2011 02:23:29 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id F01903A68B7 for ; Tue, 29 Mar 2011 02:23:28 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Q4VAf-0001fV-PD; Tue, 29 Mar 2011 09:25:05 +0000 Received: by bfk.de with local id 1Q4VAf-0003od-JF; Tue, 29 Mar 2011 09:25:05 +0000 To: Paul Vixie References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> From: Florian Weimer Date: Tue, 29 Mar 2011 09:25:05 +0000 In-Reply-To: <65033.1301383238@nsa.vix.com> (Paul Vixie's message of "Tue\, 29 Mar 2011 07\:20\:38 +0000") Message-ID: <82ei5qz3bi.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 09:23:30 -0000 * Paul Vixie: > i don't think so. nobody is querying intersticial names from an rbl so > even if there were millions of rbldnsd servers running on autopilot it > would not have an operational effect. Will this remain true if ISC changes BIND to synthesize NXDOMAIN responses for children of names already known to not exist? In many cases, it will not be too difficult to reflect a query for the non-terminal through the MTA, and after that, the blacklist is partially bypassed. So I wouldn't be surprised if such queries turned somewhat popular, suddenly. And regarding the idea of a new EDNS option---we already have plenty of NXDOMAIN signalling in the form of NSEC(3) records. We just have to agree to use it. What's worse, it seems to me that past experience shows that EDNS options cause interoperability issues, too. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Tue Mar 29 02:31:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C2613A690E for ; Tue, 29 Mar 2011 02:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4vysCgiP0Nl for ; Tue, 29 Mar 2011 02:31:22 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id B21B33A6906 for ; Tue, 29 Mar 2011 02:31:22 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Q4VIK-0002Ir-FX; Tue, 29 Mar 2011 09:33:00 +0000 Received: by bfk.de with local id 1Q4VIK-0006Yp-Ag; Tue, 29 Mar 2011 09:33:00 +0000 To: Paul Vixie References: <4D622624.90303@ogud.com> <4D63907A.8010700@nlnetlabs.nl> <82zkpnyt3z.fsf@mid.bfk.de> <22348.1298455916@nsa.vix.com> <82ei6zyqqz.fsf@mid.bfk.de> <39328.1298474414@nsa.vix.com> <82y656u4zb.fsf@mid.bfk.de> <99663.1298535473@nsa.vix.com> From: Florian Weimer Date: Tue, 29 Mar 2011 09:33:00 +0000 In-Reply-To: <99663.1298535473@nsa.vix.com> (Paul Vixie's message of "Thu\, 24 Feb 2011 08\:17\:53 +0000") Message-ID: <82aagez2yb.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 09:31:24 -0000 * Paul Vixie: >> From: Florian Weimer >> Date: Wed, 23 Feb 2011 15:48:24 +0000 >>=20 >> > who is everyone? i don't think bind or nominum or microsoft's or >> > american internet's (now cisco's) authority servers have ever sent >> > nxdomain on an empty non-terminal, and for a long time that was 100% >> > of the market. >>=20 >> The handling of empty non-terminals was changed in BIND 9.2.3, >> probably prompted by the standardization work on DNSSECbis. According >> to the CHANGES file, this is RT #4715 in your bug tracker. > > as marka has explained, this was a dnssec protocol bug, which bind9 track= ed. It is at odds with your ex-cathedra statement (partially quoted above). > either way this is unrelated to empty nonterminals, which atlas never had > to deal with anyway, i should not have mentioned it. Of course, ATLAS had to deal with them. COM and NET were not delegation-only at the time (even with Sitefinder switched off). The existance of authoritative child nodes in the zone looked like an artefact in the way the zone was provisioned, but it still meant that the particular authoritative server code paths existed, were exposed and testable from the outside. I don't know what else is hosted on the ATLAS infrastructure, so I don't know if it's behavior in this corner cases is relevant. In any case, behavior has been changed (or has to be changed) for DNSSEC-enabled zones, so it is slowly fading away, I guess. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Tue Mar 29 02:53:40 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD773A6906 for ; Tue, 29 Mar 2011 02:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5CBdKhkdoaT for ; Tue, 29 Mar 2011 02:53:39 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 1020E3A6836 for ; Tue, 29 Mar 2011 02:53:37 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Q4Vdq-0003eK-G8; Tue, 29 Mar 2011 09:55:14 +0000 Received: by bfk.de with local id 1Q4Vdq-0005A9-BW; Tue, 29 Mar 2011 09:55:14 +0000 To: Ted Hardie References: From: Florian Weimer Date: Tue, 29 Mar 2011 09:55:14 +0000 In-Reply-To: (Ted Hardie's message of "Sat\, 26 Mar 2011 10\:51\:51 -0700") Message-ID: <8239m6z1x9.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 09:53:40 -0000 * Ted Hardie: > But the problem remains daunting. Even if DNSEXT creates the perfect rec= ord > for sameness, we still have to get apps to check it--and that suggests to= me > designing the system for that goal should be a primary consideration in t= he > design space. The problem is worse: applications routinely do not have access to the public DNS when the proposed sameness or normalization step would have to be performed. For example, I'm writing this message on an IDNA-capable mail client (it will use Punycode for the domain part during submission if necessary), but the system it runs on lacks access to the public DNS. While our network is probably not representative at all, I'm sure that the phenomenon (lack of DNS access) is common on corporate networks. There is something that borders on willful ignorance of this fact. But it is pretty clear to me that you cannot use DNS for protocol version signalling (this is what the IDNA folks really need, it just got perverted to aliasing because an IDNA-specific kludge was not received favorably) when you haven't got access to the DNS at the point where you need the information. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From hallam@gmail.com Tue Mar 29 03:11:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B653A693E for ; Tue, 29 Mar 2011 03:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPMI93GVyZVQ for ; Tue, 29 Mar 2011 03:11:13 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id C65E73A690B for ; Tue, 29 Mar 2011 03:11:08 -0700 (PDT) Received: by vxg33 with SMTP id 33so3502645vxg.31 for ; Tue, 29 Mar 2011 03:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=k7FRc7xXUM4C5ZIvnbl1zRH0X+iulVvW9QA0lwhgu8U=; b=c+Wwa/C3l5YHuv+MofIGDwisZpvGa8Bu6kW9BUNiysHpOTPTClv4WNzS+j3zKVZmLl 915reuh6aXYGNfYC/rHPOsM3vjh0qlxGWEONwtSiVWKshNnSpCflNLxnCvMXpPBjdHJ+ SZJ059zzKQeySqgmVOiRIb3nJAjqAAJNAv7tc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Vq6lsIQCNzeLxg0QcXLdj9p+d6Bddvfpmw2dHz7OTJPT5iSVK+1pYIyFaLyvVbp6UI 7JwXE9dnp9+bYcBGsIiJWNpfeIukfmoLfu78Tw6WVzUZFAfcKl8Leb5XunUDiIfHzczj wWVt1xmiSaesP1pWazi1dlYhaRQrd/r8TBmlM= MIME-Version: 1.0 Received: by 10.52.0.74 with SMTP id 10mr7094568vdc.18.1301393566727; Tue, 29 Mar 2011 03:12:46 -0700 (PDT) Received: by 10.52.167.135 with HTTP; Tue, 29 Mar 2011 03:12:46 -0700 (PDT) In-Reply-To: <20110329085558.GA87566@shinkuro.com> References: <20110329085558.GA87566@shinkuro.com> Date: Tue, 29 Mar 2011 12:12:46 +0200 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=20cf3054a13341fdb8049f9c4df7 Cc: dnsext@ietf.org Subject: Re: [dnsext] list-meta: moderation (was: Fwd: djb on NXDOMAIN/NODATA for non-terminals) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 10:11:25 -0000 --20cf3054a13341fdb8049f9c4df7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Could this be a result of Bernstein's use of the most obonxious[*] mail confirmation loop tool on the planet? [*] OK I mistyped it, but I prefer the new word, consider it defined by the context in which it is used. On Tue, Mar 29, 2011 at 10:56 AM, Andrew Sullivan wrote: > This is a meta notice about list moderation, for the record. I > normally wouldn't bother, but I want to make sure that nobody is under > the mistaken impression that we are suppressing legitimate comment. > > On Mon, Mar 28, 2011 at 03:23:49PM -0700, Colm MacC=E1rthaigh wrote: > > Forwarding due to relevancy ... > > > > ---------- Forwarded message ---------- > > From: D. J. Bernstein > > Date: Mon, Mar 28, 2011 at 3:13 PM > > Subject: Re: Fixing the NXDOMAIN/NODATA bug in tinydns > > To: dns@list.cr.yp.to > > > Here's a more detailed message that I tried to send to namedroppers (th= e > > IETF dnsext mailing list) on this topic a month ago. I say "tried" > > because this message didn't show up on the mailing list even after I > > sent it to the list, sent it again to the "moderator", and sent it once > > again to the list. > > I do have, still in my INBOX in fact, a message from Dr Bernstein > about his message not getting posted. I also have my response, saying > "please send me the message if you're unable to get it posted", along > with a lot of detail of what the mailing list software is, where it is > located and by whom it is operated, what I found when I tried to find > his message, and so on. I called attention specifically to the fact > that namedroppers was no longer the WG's mailing list and that mail to > the old address seemed to drop from the face of the earth. I asked > him whether he had mail logs that showed his message was in fact > accepted for delivery, because I was unable to find his message > anywhere. > > What I do not have is the original message that Dr Bernstein refers to > in his comments. As far as I can tell, I never received that. > > Now, it would not completely surprise me to learn that I had somehow > managed to delete not once, but three times, the same text that came > to me via three different channels. But I would be at least mildly > surprised. > > If Dr Bernstein has further difficulties, I invite him (again) to > contact me, Olafur, or both of us. We are the moderators (or, I > guess, "moderators") of the list. The address for the current chairs > (whoever they may be, as long as there's a WG) is > dnsext-chairs@tools.ietf.org. > > If Dr Bernstein believes he was ill treated by me (I take full > responsibility -- Olafur was not involved in the conversation to my > knowledge), I regret it, and would like to know what he wishes I would > do to make this less difficult for him. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --=20 Website: http://hallambaker.com/ --20cf3054a13341fdb8049f9c4df7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Could this be a result of Bernstein's use of the most obonxious[*] mail= confirmation loop tool on the planet?



[*] OK I mistyped it, but I prefer the new word= , consider it defined by the context in which it is used.


On Tue, Mar 29, 2011 at 10:56 AM, A= ndrew Sullivan <aj= s@shinkuro.com> wrote:
This is a meta notice about list moderation, for the record. =A0I
normally wouldn't bother, but I want to make sure that nobody is under<= br> the mistaken impression that we are suppressing legitimate comment.

On Mon, Mar 28, 2011 at 03:23:49PM -0700, Colm MacC=E1rthaigh wrote:
> Forwarding due to relevancy ...
>
> ---------- Forwarded message ----------
> From: D. J. Bernstein <djb@cr.yp.to= >
> Date: Mon, Mar 28, 2011 at 3:13 PM
> Subject: Re: Fixing the NXDOMAIN/NODATA bug in tinydns
> To: dns@list.cr.yp.to

> Here's a more detailed message that I tried to send to namedropper= s (the
> IETF dnsext mailing list) on this topic a month ago. I say "tried= "
> because this message didn't show up on the mailing list even after= I
> sent it to the list, sent it again to the "moderator", and s= ent it once
> again to the list.

I do have, still in my INBOX in fact, a message from Dr Bernstein
about his message not getting posted. =A0I also have my response, saying "please send me the message if you're unable to get it posted"= ;, along
with a lot of detail of what the mailing list software is, where it is
located and by whom it is operated, what I found when I tried to find
his message, and so on. =A0I called attention specifically to the fact
that namedroppers was no longer the WG's mailing list and that mail to<= br> the old address seemed to drop from the face of the earth. =A0I asked
him whether he had mail logs that showed his message was in fact
accepted for delivery, because I was unable to find his message
anywhere.

What I do not have is the original message that Dr Bernstein refers to
in his comments. =A0As far as I can tell, I never received that.

Now, it would not completely surprise me to learn that I had somehow
managed to delete not once, but three times, the same text that came
to me via three different channels. =A0But I would be at least mildly
surprised.

If Dr Bernstein has further difficulties, I invite him (again) to
contact me, Olafur, or both of us. =A0We are the moderators (or, I
guess, "moderators") of the list. =A0The address for the current = chairs
(whoever they may be, as long as there's a WG) is
dnsext-chairs@tools.ietf.or= g.

If Dr Bernstein believes he was ill treated by me (I take full
responsibility -- Olafur was not involved in the conversation to my
knowledge), I regret it, and would like to know what he wishes I would
do to make this less difficult for him.

Best regards,

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



--
Website: http://hallambaker.com/

--20cf3054a13341fdb8049f9c4df7-- From ajs@shinkuro.com Tue Mar 29 04:39:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4F53A693E for ; Tue, 29 Mar 2011 04:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PRqB9J5NpdC for ; Tue, 29 Mar 2011 04:39:23 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id AED3B3A6914 for ; Tue, 29 Mar 2011 04:39:23 -0700 (PDT) Received: from shinkuro.com (unknown [130.129.99.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4CD561ECB41D for ; Tue, 29 Mar 2011 11:41:00 +0000 (UTC) Date: Tue, 29 Mar 2011 07:40:50 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110329114050.GA88058@crankycanuck.ca> References: <20110329085558.GA87566@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] list-meta: moderation (was: Fwd: djb on NXDOMAIN/NODATA for non-terminals) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:39:25 -0000 On Tue, Mar 29, 2011 at 12:12:46PM +0200, Phillip Hallam-Baker wrote: > Could this be a result of Bernstein's use of the most obonxious[*] mail > confirmation loop tool on the planet? I would prefer not to speculate why we were unable to work out what happened. I merely wanted to assure the WG participants that we are not neglecting our duty to ensure that relevant comments are brought to the attention of the WG, regardless of their source. There are plenty of ways we have fallen down as chairs (see the recent report); but this is, I am confident in asserting, not one of them. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ray.Bellis@nominet.org.uk Tue Mar 29 05:02:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E946B28C156 for ; Tue, 29 Mar 2011 05:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.024 X-Spam-Level: X-Spam-Status: No, score=-10.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moAnBkFZ8UYm for ; Tue, 29 Mar 2011 05:02:51 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id A65993A68F5 for ; Tue, 29 Mar 2011 05:02:50 -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: Content-ID:Content-Transfer-Encoding:MIME-Version; b=KlvlpoiutFT+PcqLDCt8w7LQ+vgvBQDUK9zb8CLDHBzglkbNSm5gf76F tzxDQ+iPnk3KurvgQoq9SRk1iSsohhnPFf6prVtvB3babsTa8P3P3MHOX /pNhXVb7lhLlUyw; 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=1301400269; x=1332936269; 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[dnsext]=20WG=20Document=20adoption:=20 =20Resimprove|Date:=20Tue,=2029=20Mar=202011=2012:04:25 =20+0000|Message-ID:=20|To:=20Olafur=20Gudmundsson=20|CC:=20""=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<1d74c3c3-afea-47af-bcac-1378e4d3 70e8>|In-Reply-To:=20<4D90C747.2000703@ogud.com> |References:=20<4D90C747.2000703@ogud.com>; bh=F696JJ676Ck8Jxal782aPlBg5f2vh68ODyDyxxN99ME=; b=s5dTByCBmEZne3cfUrsj4u9TEOQj5LgIPJN5jvh6wsEfDLlc1k1NO31m UhZEIyyhVUqE6XQFZwiKjniiZRVmlFmtb2fug7Hxj1oJKVuWqoco2LTJr JcBCoERTGNhsjL1; X-IronPort-AV: E=Sophos;i="4.63,262,1299456000"; d="scan'208";a="25413485" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 29 Mar 2011 13:04:27 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Tue, 29 Mar 2011 13:04:27 +0100 From: Ray Bellis To: Olafur Gudmundsson Thread-Topic: [dnsext] WG Document adoption: Resimprove Thread-Index: AQHL7W7TYlqH5aTii0epX1fLWhKNVpREJ0OA Date: Tue, 29 Mar 2011 12:04:25 +0000 Message-ID: References: <4D90C747.2000703@ogud.com> In-Reply-To: <4D90C747.2000703@ogud.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <1d74c3c3-afea-47af-bcac-1378e4d370e8> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dnsext] WG Document adoption: Resimprove X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:02:52 -0000 On 28 Mar 2011, at 19:37, Olafur Gudmundsson wrote: > Under the working rules of the WG we need at least 5 members to say that = they support this work and commit to perform reviews of this document. Count me in, please. Ray From fanf2@hermes.cam.ac.uk Tue Mar 29 05:03:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A78A3A683D for ; Tue, 29 Mar 2011 05:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C30yVLjmA9nz for ; Tue, 29 Mar 2011 05:03:09 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id E26753A6784 for ; Tue, 29 Mar 2011 05:03:08 -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-1.csi.cam.ac.uk ([131.111.8.51]:41956) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Q4XfB-0001vn-Y1 (Exim 4.72) (return-path ); Tue, 29 Mar 2011 13:04:45 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Q4XfB-00021e-HL (Exim 4.67) (return-path ); Tue, 29 Mar 2011 13:04:45 +0100 Date: Tue, 29 Mar 2011 13:04:45 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Florian Weimer In-Reply-To: <8239m6z1x9.fsf@mid.bfk.de> Message-ID: References: <8239m6z1x9.fsf@mid.bfk.de> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:03:10 -0000 Florian Weimer wrote: > > The problem is worse: applications routinely do not have access to the > public DNS when the proposed sameness or normalization step would have > to be performed. I think we should be clear whether we are talking about a server being provisioned or a client making a request. I find it hard to believe a client has no access to the DNS when making a request, though it might be indirectly, and possibly via an interface that only provides access to a limited set of RR types. But any solution we come up with has to work with existing clients or it will never be deployable. A server does not have to get its list of aliases from the DNS. Being able to do so is a convenience but it is likely to be undesirable in some situations or impossible if the server software doesn't support it. Tony. -- f.anthony.n.finch http://dotat.at/ Wight, Portland, Plymouth: Southeast 3 or 4 veering southwest 4 or 5, occasionally 6 in Plymouth later. Slight in Wight, otherwise slight or moderate. Showers, fog patches. Moderate, occasionally very poor. From vixie@isc.org Tue Mar 29 06:02:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281233A67B3 for ; Tue, 29 Mar 2011 06:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5RSP-uM-iSq for ; Tue, 29 Mar 2011 06:02:10 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 676813A67A6 for ; Tue, 29 Mar 2011 06:02:10 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4BF73A1031 for ; Tue, 29 Mar 2011 13:03:47 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Tue, 29 Mar 2011 09:25:05 GMT." <82ei5qz3bi.fsf@mid.bfk.de> References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Tue, 29 Mar 2011 13:03:47 +0000 Message-ID: <84978.1301403827@nsa.vix.com> Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:02:12 -0000 > From: Florian Weimer > Date: Tue, 29 Mar 2011 09:25:05 +0000 > > > ... nobody is querying intersticial names from an rbl so even if > > there were millions of rbldnsd servers running on autopilot it would > > not have an operational effect. > > Will this remain true if ISC changes BIND to synthesize NXDOMAIN > responses for children of names already known to not exist? let's assume that if reimprove passes to rfc as-is that everybody will implement it (not just ISC for BIND) and that if it does not than nobody will implement it (not even ISC for BIND). as to "remain true", probably it will, since if spammers actually cared enough to pollute caches with negative elements -- which they don't since the RBL's aren't stopping them and they won't make more money by bypassing them even if it was easier than this -- ... > In many cases, it will not be too difficult to reflect a query for the > non-terminal through the MTA, and after that, the blacklist is > partially bypassed. So I wouldn't be surprised if such queries turned > somewhat popular, suddenly. i'm trying to guess what you mean by "not too difficult". the RBL logic i know about is in sendmail and postfix, which always asks for the full name. how would you go about getting the MTA to request something like 187.152.204.rbl.mail-abuse.org assuming that trend was using rbldnsd and would answer with nxdomain so that one could then spam less impededly from 204.152.187.111 ? > And regarding the idea of a new EDNS option---we already have plenty > of NXDOMAIN signalling in the form of NSEC(3) records. We just have > to agree to use it. What's worse, it seems to me that past experience > shows that EDNS options cause interoperability issues, too. this sounds like a veiled suggestion that we remove this from resimprove and that someone get working on an aggressive negative caching proposal? From fanf2@hermes.cam.ac.uk Tue Mar 29 06:28:55 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512883A682D for ; Tue, 29 Mar 2011 06:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3fTnOvUKxLv for ; Tue, 29 Mar 2011 06:28:53 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id 8A5BE3A6824 for ; Tue, 29 Mar 2011 06:28:52 -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-1.csi.cam.ac.uk ([131.111.8.51]:54522) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Q4Z0A-0001nI-Y3 (Exim 4.72) (return-path ); Tue, 29 Mar 2011 14:30:30 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Q4Z0A-0007S7-Hh (Exim 4.67) (return-path ); Tue, 29 Mar 2011 14:30:30 +0100 Date: Tue, 29 Mar 2011 14:30:30 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Vixie In-Reply-To: <84978.1301403827@nsa.vix.com> Message-ID: References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:28:55 -0000 Paul Vixie wrote: > > how would you go about getting the MTA to request something like > 187.152.204.rbl.mail-abuse.org ehlo 187.152.204.rbl.mail-abuse.org mail from: etc. Tony. -- f.anthony.n.finch http://dotat.at/ Fair Isle, Faeroes, South-east Iceland: Mainly southeasterly 4 or 5, increasing 6 at times, but cyclonic at first in Southeast Iceland. Moderate or rough. Rain or showers. Moderate or good, occasionally poor in Southeast Iceland. From Ed.Lewis@neustar.biz Tue Mar 29 06:35:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94FEA3A6916 for ; Tue, 29 Mar 2011 06:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl00D-Q9JZ6z for ; Tue, 29 Mar 2011 06:35:32 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 5B6353A6917 for ; Tue, 29 Mar 2011 06:35:32 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2TDb6iv063973; Tue, 29 Mar 2011 09:37:06 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Tue, 29 Mar 2011 09:37:07 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 29 Mar 2011 09:37:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <8EA8D1A36B8F4968ABE973C39CA5E0E0@local> References: <8EA8D1A36B8F4968ABE973C39CA5E0E0@local> Date: Tue, 29 Mar 2011 09:27:12 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:35:33 -0000 At 22:29 +0100 3/28/11, George Barwood wrote: >I'd also like to see the standard updated to allow resolvers to infer >NoData conditions from NSEC/NSEC3 records ( the standard does not exactly >forbid this at present, but there is discouraging language ). http://www.ietf.org/mail-archive/web/dnsext/current/msg10820.html One motivation is to pursue "tricks" like RFC 4470 but applied to the type bitmap. A signer may decide not to include all types in the NSEC it hands out. Or the answering server will be synthesizing the answer dependent on the query. By enlarging the role of caches, the authoritative server choices are shrunk. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From Ed.Lewis@neustar.biz Tue Mar 29 06:35:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4923A6917 for ; Tue, 29 Mar 2011 06:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeFwwYZ04ra3 for ; Tue, 29 Mar 2011 06:35:34 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 177443A6916 for ; Tue, 29 Mar 2011 06:35:33 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2TDb6ix063973; Tue, 29 Mar 2011 09:37:10 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Tue, 29 Mar 2011 09:37:11 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 29 Mar 2011 09:37:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D90C747.2000703@ogud.com> References: <4D90C747.2000703@ogud.com> Date: Tue, 29 Mar 2011 09:35:57 -0400 To: Olafur Gudmundsson From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] WG Document adoption: Resimprove X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:35:35 -0000 At 13:37 -0400 3/28/11, Olafur Gudmundsson wrote: >As discussed in the WG meeting today, this is a formal request for >people to say that they support the adoption of the following >document: > http://tools.ietf.org/html/draft-vixie-dnsext-resimprove My comments are here: http://www.ietf.org/mail-archive/web/dnsext/current/msg10739.html The WG should discuss this draft. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From george.barwood@blueyonder.co.uk Tue Mar 29 07:02:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB78D3A682D for ; Tue, 29 Mar 2011 07:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.068 X-Spam-Level: X-Spam-Status: No, score=-0.068 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK-GrQrQ0Ccb for ; Tue, 29 Mar 2011 07:02:03 -0700 (PDT) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by core3.amsl.com (Postfix) with ESMTP id 9297B3A693E for ; Tue, 29 Mar 2011 07:02:02 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.4]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110329140334.WCLS13167.mtaout03-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Tue, 29 Mar 2011 15:03:34 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1Q4ZWA-0004Py-5e; Tue, 29 Mar 2011 15:03:34 +0100 Message-ID: From: "George Barwood" To: , "Edward Lewis" References: <8EA8D1A36B8F4968ABE973C39CA5E0E0@local> Date: Tue, 29 Mar 2011 15:03:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=WnkCSP1BjtsA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=CIE4dlYyxOFyP2u2CAIA:9 a=3VXdAdOfH_TkwBtwIJoF9vaM0-UA:4 a=wPNLvfGTeEIA:10 a=Fw9EzWXUJMYA:10 a=lZB815dzVvQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:02:03 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVkd2FyZCBMZXdpcyIgPEVk Lkxld2lzQG5ldXN0YXIuYml6Pg0KVG86IDxkbnNleHRAaWV0Zi5vcmc+DQpDYzogPGVkLmxld2lz QG5ldXN0YXIuYml6Pg0KU2VudDogVHVlc2RheSwgTWFyY2ggMjksIDIwMTEgMjoyNyBQTQ0KU3Vi amVjdDogUmU6IFtkbnNleHRdIGRyYWZ0LXZpeGllLWRuc2V4dC1yZXNpbXByb3ZlIC0gTlhET01B SU4gZm9yIGVtcHR5bm9uLXRlcm1pbmFscw0KDQoNCj4gQXQgMjI6MjkgKzAxMDAgMy8yOC8xMSwg R2VvcmdlIEJhcndvb2Qgd3JvdGU6DQo+IA0KPj5JJ2QgYWxzbyBsaWtlIHRvIHNlZSB0aGUgc3Rh bmRhcmQgdXBkYXRlZCB0byBhbGxvdyByZXNvbHZlcnMgdG8gaW5mZXINCj4+Tm9EYXRhIGNvbmRp dGlvbnMgZnJvbSBOU0VDL05TRUMzIHJlY29yZHMgKCB0aGUgc3RhbmRhcmQgZG9lcyBub3QgZXhh Y3RseQ0KPj5mb3JiaWQgdGhpcyBhdCBwcmVzZW50LCBidXQgdGhlcmUgaXMgZGlzY291cmFnaW5n IGxhbmd1YWdlICkuDQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv ZG5zZXh0L2N1cnJlbnQvbXNnMTA4MjAuaHRtbA0KPiANCj4gT25lIG1vdGl2YXRpb24gaXMgdG8g cHVyc3VlICJ0cmlja3MiIGxpa2UgUkZDIDQ0NzAgYnV0IGFwcGxpZWQgdG8gdGhlIA0KPiB0eXBl IGJpdG1hcC4gIEEgc2lnbmVyIG1heSBkZWNpZGUgbm90IHRvIGluY2x1ZGUgYWxsIHR5cGVzIGlu IHRoZSANCj4gTlNFQyBpdCBoYW5kcyBvdXQuICBPciB0aGUgYW5zd2VyaW5nIHNlcnZlciB3aWxs IGJlIHN5bnRoZXNpemluZyB0aGUgDQo+IGFuc3dlciBkZXBlbmRlbnQgb24gdGhlIHF1ZXJ5Lg0K DQpJZiBhIHNpZ25lciBvciBzZXJ2ZXIgZG9lcyB0aGlzLCBhbGwgc2VjdXJpdHkgaXMgbG9zdCwg YmVjYXVzZSBhbiBhdHRhY2tlciBjYW4gdXNlDQp0aGUgaW5jb21wbGV0ZSBOU0VDIHJlY29yZHMg dG8gZGVueSB0aGUgZXhpc3RlbmNlIG9mIFJSc2V0cy4NCg0KU28gYWxsb3dpbmcgdGhpcyAoc3Rh bmRhcmQgYnJlYWtpbmcpIHBvc3NpYmlsaXR5IGRvZXMgbm90IHNlZW0gYXQgYWxsIHVzZWZ1bC4N Cg0KV2hhdCBpcyB0aGUgbW90aXZlIGZvciB0aGlzICJ0cmljayI/IFNhdmluZyBiYW5kd2lkdGg/ Pw0KDQpHZW9yZ2UNCg0KPiBCeSBlbmxhcmdpbmcgdGhlIHJvbGUgb2YgY2FjaGVzLCB0aGUgYXV0 aG9yaXRhdGl2ZSBzZXJ2ZXIgY2hvaWNlcyBhcmUgc2hydW5rLg0K From fanf2@hermes.cam.ac.uk Tue Mar 29 07:02:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46EA73A6824 for ; Tue, 29 Mar 2011 07:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43eJsfFgZ7wQ for ; Tue, 29 Mar 2011 07:02:33 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 40C5F3A682D for ; Tue, 29 Mar 2011 07:02:33 -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-1.csi.cam.ac.uk ([131.111.8.51]:58372) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Q4ZWk-0006gD-SC (Exim 4.72) (return-path ); Tue, 29 Mar 2011 15:04:10 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Q4ZWk-0004kT-NN (Exim 4.67) (return-path ); Tue, 29 Mar 2011 15:04:10 +0100 Date: Tue, 29 Mar 2011 15:04:10 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Edward Lewis In-Reply-To: Message-ID: References: <8EA8D1A36B8F4968ABE973C39CA5E0E0@local> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:02:34 -0000 Edward Lewis wrote: > > One motivation is to pursue "tricks" like RFC 4470 but applied to the type > bitmap. A signer may decide not to include all types in the NSEC it hands > out. I think that would be an outright lie, not a white lie. Tony. -- f.anthony.n.finch http://dotat.at/ North Utsire, South Utsire: Northwesterly 4 or 5, occasionally 6 in South Utsire, veering easterly 3 or 4 later. Moderate or rough. Occasional rain. Moderate or good. From vixie@isc.org Tue Mar 29 07:13:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81033A6824 for ; Tue, 29 Mar 2011 07:13:46 -0700 (PDT) X-Quarantine-ID: <3c10BQS2mzWy> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c10BQS2mzWy for ; Tue, 29 Mar 2011 07:13:45 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id B19033A68DA for ; Tue, 29 Mar 2011 07:13:45 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 49745A1019; Tue, 29 Mar 2011 14:15:22 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: Tony Finch In-Reply-To: Your message of "Tue, 29 Mar 2011 14:30:30 +0100." References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Tue, 29 Mar 2011 14:15:22 +0000 Message-ID: <88993.1301408122@nsa.vix.com> Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:13:46 -0000 > Date: Tue, 29 Mar 2011 14:30:30 +0100 > From: Tony Finch > > Paul Vixie wrote: > > how would you go about getting the MTA to request something like > > 187.152.204.rbl.mail-abuse.org > > ehlo 187.152.204.rbl.mail-abuse.org > mail from: neat! thanks. From Ed.Lewis@neustar.biz Tue Mar 29 07:15:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4229528C0FB for ; Tue, 29 Mar 2011 07:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgQy885eNnU7 for ; Tue, 29 Mar 2011 07:15:32 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id F24D328B797 for ; Tue, 29 Mar 2011 07:15:31 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2TEH6qv064482; Tue, 29 Mar 2011 10:17:06 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Tue, 29 Mar 2011 10:17:07 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 29 Mar 2011 10:17:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8EA8D1A36B8F4968ABE973C39CA5E0E0@local> Date: Tue, 29 Mar 2011 10:14:18 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:15:33 -0000 At 15:04 +0100 3/29/11, Tony Finch wrote: >I think that would be an outright lie, not a white lie. Define "truth." Seriously, keeping this engineering, what is the difference between "crafting replies" to queries (which some call lying) and rapidly updating the zone? Would cache operators prefer that the TTL is dropped to nearly zero to force more cache misses? The goal here is to retain the authority of the authority servers and still make use of caching. If you increase the synthesis of answers in caches, you are removing authority from the authoritative servers and placing that in the caches. Debating the utility of rapidly changing zones, alternate forms of answer synthesis, and "lying", if taken up, should happen in a different form than this subject line. For now, if we empower caches, we stifle exploration in the authority server space. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From Ed.Lewis@neustar.biz Tue Mar 29 07:44:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A14C3A682D for ; Tue, 29 Mar 2011 07:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7VV1nW4MvRt for ; Tue, 29 Mar 2011 07:43:59 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 8DD673A6882 for ; Tue, 29 Mar 2011 07:43:57 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2TEjYiq064719; Tue, 29 Mar 2011 10:45:35 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Tue, 29 Mar 2011 10:45:35 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 29 Mar 2011 10:45:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8EA8D1A36B8F49 68ABE973C39CA5E0E0@local> Date: Tue, 29 Mar 2011 10:45:22 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:44:00 -0000 At 15:03 +0100 3/29/11, George Barwood wrote: >What is the motive for this "trick"? Saving bandwidth?? There are zones which do not exist in total at any given point in time. These are zones that do not conform to a zone "file" and cannot be represented in an AXFR. For these zones, a statement of what exists can be made "locally" but generating a "universal" list would be impossible. Answering only the query at hand is the concern because the current protocol rules say caches don't synthesize answers from what they cache. (They can repeat answers in the cache, not synthesize them.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From fweimer@bfk.de Tue Mar 29 08:37:19 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8848A3A6989 for ; Tue, 29 Mar 2011 08:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJsHvn6s4Q-Z for ; Tue, 29 Mar 2011 08:37:18 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id B23C93A687E for ; Tue, 29 Mar 2011 08:37:18 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Q4b0S-0006UN-2y; Tue, 29 Mar 2011 15:38:56 +0000 Received: by bfk.de with local id 1Q4b0S-0005Ae-0I; Tue, 29 Mar 2011 15:38:56 +0000 To: Paul Vixie References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> From: Florian Weimer Date: Tue, 29 Mar 2011 15:38:55 +0000 In-Reply-To: <84978.1301403827@nsa.vix.com> (Paul Vixie's message of "Tue\, 29 Mar 2011 13\:03\:47 +0000") Message-ID: <82fwq6vsvk.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:37:19 -0000 * Paul Vixie: >> And regarding the idea of a new EDNS option---we already have plenty >> of NXDOMAIN signalling in the form of NSEC(3) records. We just have >> to agree to use it. What's worse, it seems to me that past experience >> shows that EDNS options cause interoperability issues, too. > > this sounds like a veiled suggestion that we remove this from resimprove I strongly believe that this would improve the quality of the document (in terms of reflecting existing practice), so yes. 8-) > and that someone get working on an aggressive negative caching proposal? I'm not sure if it is worth the effort. But if better negative caching is the goal, DNSSEC data seems a reasonable candidate for further information. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From vixie@isc.org Tue Mar 29 08:54:55 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150183A690E for ; Tue, 29 Mar 2011 08:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZPdqLmS7TBG for ; Tue, 29 Mar 2011 08:54:54 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id E54243A67E4 for ; Tue, 29 Mar 2011 08:54:53 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A79D0A1064 for ; Tue, 29 Mar 2011 15:56:30 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Tue, 29 Mar 2011 15:38:55 GMT." <82fwq6vsvk.fsf@mid.bfk.de> References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Tue, 29 Mar 2011 15:56:30 +0000 Message-ID: <94669.1301414190@nsa.vix.com> Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:54:55 -0000 > From: Florian Weimer > Date: Tue, 29 Mar 2011 15:38:55 +0000 > > > this sounds like a veiled suggestion that we remove this from resimprove > > I strongly believe that this would improve the quality of the document > (in terms of reflecting existing practice), so yes. 8-) is there any opposition to this change? > > and that someone get working on an aggressive negative caching proposal? > > I'm not sure if it is worth the effort. But if better negative > caching is the goal, DNSSEC data seems a reasonable candidate for > further information. whether using dnssec or not, aggressive negative caching would need a document. From Ed.Lewis@neustar.biz Tue Mar 29 09:05:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03A83A68BF for ; Tue, 29 Mar 2011 09:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D59-Ced70qni for ; Tue, 29 Mar 2011 09:05:30 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id C884A3A6862 for ; Tue, 29 Mar 2011 09:05:29 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2TG74ZZ065605; Tue, 29 Mar 2011 12:07:04 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Tue, 29 Mar 2011 12:07:05 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 29 Mar 2011 12:07:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <84978.1301403827@nsa.vix.com> References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> Date: Tue, 29 Mar 2011 11:57:43 -0400 To: Paul Vixie From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:05:30 -0000 At 13:03 +0000 3/29/11, Paul Vixie wrote: >and that someone get working on an aggressive negative caching proposal? In other threads I've made statements that lead me to say "no" because I've come to believe aggressive negative caching is in general not a good idea. I think being aggressive with NXDOMAIN is workable, though. Even if the NSEC/3's "clip" down the ranges they cover, there is no harm to the authority. This is nothing different from what we already have in RFC 2308 though. There are plenty of things caches can do to be more aggressive in the positive space, like pre-fetching, being more energetic in trying to validate a response, etc. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From Ed.Lewis@neustar.biz Tue Mar 29 09:05:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083F33A6A32 for ; Tue, 29 Mar 2011 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJQZ9DwOZOtP for ; Tue, 29 Mar 2011 09:05:31 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 2C2983A6862 for ; Tue, 29 Mar 2011 09:05:31 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2TG74Zb065605; Tue, 29 Mar 2011 12:07:08 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Tue, 29 Mar 2011 12:07:09 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 29 Mar 2011 12:07:09 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <94669.1301414190@nsa.vix.com> References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> Date: Tue, 29 Mar 2011 11:58:29 -0400 To: Paul Vixie From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:05:32 -0000 At 15:56 +0000 3/29/11, Paul Vixie wrote: >is there any opposition to this change? Given the back and forth, can you summarize what "this change" refers to? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From vixie@isc.org Tue Mar 29 09:07:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2383A6981 for ; Tue, 29 Mar 2011 09:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTMc8Sh4hFUV for ; Tue, 29 Mar 2011 09:07:50 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 3FF653A6862 for ; Tue, 29 Mar 2011 09:07:50 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 213CBA1021 for ; Tue, 29 Mar 2011 16:09:28 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Tue, 29 Mar 2011 11:58:29 -0400." References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Tue, 29 Mar 2011 16:09:28 +0000 Message-ID: <95465.1301414968@nsa.vix.com> Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:07:51 -0000 > Date: Tue, 29 Mar 2011 11:58:29 -0400 > From: Edward Lewis > > >is there any opposition to this change? > > Given the back and forth, can you summarize what "this change" refers to? this one: > > > this sounds like a veiled suggestion that we remove this from resimprove > > > > I strongly believe that this would improve the quality of the document > > (in terms of reflecting existing practice), so yes. 8-) referring to $subject which is "NXDOMAIN/NODATA for non-terminals". From george.barwood@blueyonder.co.uk Tue Mar 29 09:14:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A793A6863 for ; Tue, 29 Mar 2011 09:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v1U3hpRq+2R for ; Tue, 29 Mar 2011 09:14:42 -0700 (PDT) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by core3.amsl.com (Postfix) with ESMTP id 275FE3A6812 for ; Tue, 29 Mar 2011 09:14:41 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.2]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110329161619.UKQY18231.mtaout01-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Tue, 29 Mar 2011 17:16:19 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1Q4bad-0000s4-6L; Tue, 29 Mar 2011 17:16:19 +0100 Message-ID: <55128075215341BD92DCAAD00450FA85@local> From: "George Barwood" To: , "Edward Lewis" References: <8EA8D1A36B8F4968ABE973C39CA5E0E0@local> Date: Tue, 29 Mar 2011 17:16:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=WnkCSP1BjtsA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=Hg250VQvSfo_yTMucxsA:9 a=4fw7feh-btEuAnLF7_M146_oUKkA:4 a=wPNLvfGTeEIA:10 a=9k6G2--EmesA:10 a=lZB815dzVvQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: Edward Lewis Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:14:43 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVkd2FyZCBMZXdpcyIgPEVk Lkxld2lzQG5ldXN0YXIuYml6Pg0KVG86IDxkbnNleHRAaWV0Zi5vcmc+DQpDYzogIkVkd2FyZCBM ZXdpcyIgPEVkLkxld2lzQG5ldXN0YXIuYml6Pg0KU2VudDogVHVlc2RheSwgTWFyY2ggMjksIDIw MTEgMzo0NSBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIGRyYWZ0LXZpeGllLWRuc2V4dC1yZXNp bXByb3ZlIC0gTlhET01BSU4gZm9yIGVtcHR5bm9uLXRlcm1pbmFscw0KDQoNCj4gQXQgMTU6MDMg KzAxMDAgMy8yOS8xMSwgR2VvcmdlIEJhcndvb2Qgd3JvdGU6DQo+IA0KPj5XaGF0IGlzIHRoZSBt b3RpdmUgZm9yIHRoaXMgInRyaWNrIj8gU2F2aW5nIGJhbmR3aWR0aD8/DQo+IA0KPiBUaGVyZSBh cmUgem9uZXMgd2hpY2ggZG8gbm90IGV4aXN0IGluIHRvdGFsIGF0IGFueSBnaXZlbiBwb2ludCBp biANCj4gdGltZS4gIFRoZXNlIGFyZSB6b25lcyB0aGF0IGRvIG5vdCBjb25mb3JtIHRvIGEgem9u ZSAiZmlsZSIgYW5kIA0KPiBjYW5ub3QgYmUgcmVwcmVzZW50ZWQgaW4gYW4gQVhGUi4gIEZvciB0 aGVzZSB6b25lcywgYSBzdGF0ZW1lbnQgb2YgDQo+IHdoYXQgZXhpc3RzIGNhbiBiZSBtYWRlICJs b2NhbGx5IiBidXQgZ2VuZXJhdGluZyBhICJ1bml2ZXJzYWwiIGxpc3QgDQo+IHdvdWxkIGJlIGlt cG9zc2libGUuICBBbnN3ZXJpbmcgb25seSB0aGUgcXVlcnkgYXQgaGFuZCBpcyB0aGUgY29uY2Vy biANCj4gYmVjYXVzZSB0aGUgY3VycmVudCBwcm90b2NvbCBydWxlcyBzYXkgY2FjaGVzIGRvbid0 IHN5bnRoZXNpemUgDQo+IGFuc3dlcnMgZnJvbSB3aGF0IHRoZXkgY2FjaGUuICAoVGhleSBjYW4g cmVwZWF0IGFuc3dlcnMgaW4gdGhlIGNhY2hlLCANCj4gbm90IHN5bnRoZXNpemUgdGhlbS4pDQoN CkkgYWdyZWUgaXQncyBxdWl0ZSBjb21tb24gZm9yIHpvbmVzIHRvIGdpdmUgbm9uLWRldGVybWlu aXN0aWMgcG9zaXRpdmUgYW5zd2Vycw0KYXMgYSBmb3JtIG9mIGxvYWQtYmFsYW5jaW5nLCB3aGVy ZSBhIGxpbWl0ZWQgc2V0IG9mIEEgcmVjb3JkcyBpcyByYW5kb21seSANCihvciBvdGhlcndpc2Up IHNlbGVjdGVkIGZyb20gYSBsYXJnZSBzZXQuIFRoaXMgaXMgbm90IGFmZmVjdGVkLg0KDQpJdCdz IHF1aXRlIGhhcmQgdG8gc2VlIGhvdyBpdCBjb3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBpbmNvbnNp c3RlbnQgTlNFQyBiaXRtYXBzIHRob3VnaC4NCkNhbiB5b3UgZ2l2ZSBhbnkga2luZCBvZiBoeXBv dGhldGljYWwgdXNlIGNhc2U/DQoNCkdlb3JnZQ0KDQo+IC0tIA0KPiAtPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0t PS0NCj4gRWR3YXJkIExld2lzDQo+IE5ldVN0YXIgICAgICAgICAgICAgICAgICAgIFlvdSBjYW4g bGVhdmUgYSB2b2ljZSBtZXNzYWdlIGF0ICsxLTU3MS00MzQtNTQ2OA0KPiANCj4gTWUgdG8gaW5m YW50IHNvbjogIldhYWghIFdhYWghIElzIHRoYXQgYWxsIHlvdSBjYW4gc2F5PyAgV2FhaD8iDQo+ IFNvbjogIldhYWghIg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBkbnNleHQgbWFpbGluZyBsaXN0DQo+IGRuc2V4dEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ruc2V4dA== From Ed.Lewis@neustar.biz Tue Mar 29 09:25:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47103A6975 for ; Tue, 29 Mar 2011 09:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry1pLZqVG5la for ; Tue, 29 Mar 2011 09:25:31 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id EA4EA3A695D for ; Tue, 29 Mar 2011 09:25:30 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2TGR2Nc065868; Tue, 29 Mar 2011 12:27:05 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Tue, 29 Mar 2011 12:27:08 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 29 Mar 2011 12:27:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <95465.1301414968@nsa.vix.com> References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> <95465.1301414968@nsa.vix.com> Date: Tue, 29 Mar 2011 12:18:52 -0400 To: Paul Vixie From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:25:32 -0000 At 16:09 +0000 3/29/11, Paul Vixie wrote: >> Date: Tue, 29 Mar 2011 11:58:29 -0400 >> From: Edward Lewis >> >> >is there any opposition to this change? >> >> Given the back and forth, can you summarize what "this change" refers to? > >this one: > >> > > this sounds like a veiled suggestion that we remove this from resimprove "remove this" -> remove what? Trying to find the messages on this, it seems there was some mention of an EDNS option, but in http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 I don't see any mention of EDNS. >> > I strongly believe that this would improve the quality of the document >> > (in terms of reflecting existing practice), so yes. 8-) > >referring to $subject which is "NXDOMAIN/NODATA for non-terminals". -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From Ed.Lewis@neustar.biz Tue Mar 29 09:28:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B2E3A695D for ; Tue, 29 Mar 2011 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8BpF1FK9lOL for ; Tue, 29 Mar 2011 09:28:21 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 1E2BA3A68FD for ; Tue, 29 Mar 2011 09:28:21 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2TGTw6l065903; Tue, 29 Mar 2011 12:29:58 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Tue, 29 Mar 2011 12:29:58 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 29 Mar 2011 12:29:58 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <55128075215341BD92DCAAD00450FA85@local> References: <8EA8D1A36B8F49 68ABE973C39CA5E0E0@local> <55128075215341BD92DCAAD00450FA85@local> Date: Tue, 29 Mar 2011 12:29:23 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:28:22 -0000 At 17:16 +0100 3/29/11, George Barwood wrote: >I agree it's quite common for zones to give non-deterministic positive answers >as a form of load-balancing, where a limited set of A records is randomly >(or otherwise) selected from a large set. This is not affected. Using that...when you have A, AAAA, and fallback answers like DNAME and CNAME, for example. It might not be just which A to return, but whether to withhold the AAAA and or use a query redirection tool. Consider that ANY queries may come. With IPv6 whitelisting (http://tools.ietf.org/html/draft-livingood-dns-whitelisting-implications-01) as an example, I might want to withhold the existence of a AAAA record from some queriers but not others. The way the standards read now, it's possible to generate NSEC/3's owning a private type for all names that warrant one (NSEC does not represent empty non-terminals, NSEC3 does) claiming just a private type and things would work. That's because you don't get a NSEC/3 in a positive answer (other than ANY). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From george.barwood@blueyonder.co.uk Tue Mar 29 10:14:40 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2C63A6A68 for ; Tue, 29 Mar 2011 10:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBehkBBzIo6f for ; Tue, 29 Mar 2011 10:14:39 -0700 (PDT) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by core3.amsl.com (Postfix) with ESMTP id 3AA923A6986 for ; Tue, 29 Mar 2011 10:14:38 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.2]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110329171614.NWRP13167.mtaout03-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Tue, 29 Mar 2011 18:16:14 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1Q4cWc-0003gv-7p; Tue, 29 Mar 2011 18:16:14 +0100 Message-ID: <3B987BF13718424BBA818C248C428E64@local> From: "George Barwood" To: , "Edward Lewis" References: <8EA8D1A36B8F4968ABE973C39CA5E0E0@local> <55128075215341BD92DCAAD00450FA85@local> Date: Tue, 29 Mar 2011 18:16:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=WnkCSP1BjtsA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=6sno7dGO8SZgrV0BxOgA:9 a=SUgiFT2ZV0-XSrb1_4IA:7 a=QQon0dDSOR_pfGcXQxOxwWWEp9AA:4 a=wPNLvfGTeEIA:10 a=9k6G2--EmesA:10 a=lZB815dzVvQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: Edward Lewis Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 17:14:40 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVkd2FyZCBMZXdpcyIgPEVk Lkxld2lzQG5ldXN0YXIuYml6Pg0KVG86IDxkbnNleHRAaWV0Zi5vcmc+DQpDYzogIkVkd2FyZCBM ZXdpcyIgPEVkLkxld2lzQG5ldXN0YXIuYml6Pg0KU2VudDogVHVlc2RheSwgTWFyY2ggMjksIDIw MTEgNToyOSBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIGRyYWZ0LXZpeGllLWRuc2V4dC1yZXNp bXByb3ZlIC0gTlhET01BSU4gZm9yIGVtcHR5bm9uLXRlcm1pbmFscw0KDQoNCj4gQXQgMTc6MTYg KzAxMDAgMy8yOS8xMSwgR2VvcmdlIEJhcndvb2Qgd3JvdGU6DQo+IA0KPj5JIGFncmVlIGl0J3Mg cXVpdGUgY29tbW9uIGZvciB6b25lcyB0byBnaXZlIG5vbi1kZXRlcm1pbmlzdGljIHBvc2l0aXZl IGFuc3dlcnMNCj4+YXMgYSBmb3JtIG9mIGxvYWQtYmFsYW5jaW5nLCB3aGVyZSBhIGxpbWl0ZWQg c2V0IG9mIEEgcmVjb3JkcyBpcyByYW5kb21seQ0KPj4ob3Igb3RoZXJ3aXNlKSBzZWxlY3RlZCBm cm9tIGEgbGFyZ2Ugc2V0LiBUaGlzIGlzIG5vdCBhZmZlY3RlZC4NCj4gDQo+IFVzaW5nIHRoYXQu Li53aGVuIHlvdSBoYXZlIEEsIEFBQUEsIGFuZCBmYWxsYmFjayBhbnN3ZXJzIGxpa2UgRE5BTUUg DQo+IGFuZCBDTkFNRSwgZm9yIGV4YW1wbGUuICBJdCBtaWdodCBub3QgYmUganVzdCB3aGljaCBB IHRvIHJldHVybiwgYnV0IA0KPiB3aGV0aGVyIHRvIHdpdGhob2xkIHRoZSBBQUFBIGFuZCBvciB1 c2UgYSBxdWVyeSByZWRpcmVjdGlvbiB0b29sLiANCj4gQ29uc2lkZXIgdGhhdCBBTlkgcXVlcmll cyBtYXkgY29tZS4NCj4gDQo+IFdpdGggSVB2NiB3aGl0ZWxpc3RpbmcgDQo+IChodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXZpbmdvb2QtZG5zLXdoaXRlbGlzdGluZy1pbXBsaWNh dGlvbnMtMDEpIA0KPiBhcyBhbiBleGFtcGxlLCBJIG1pZ2h0IHdhbnQgdG8gd2l0aGhvbGQgdGhl IGV4aXN0ZW5jZSBvZiBhIEFBQUEgDQo+IHJlY29yZCBmcm9tIHNvbWUgcXVlcmllcnMgYnV0IG5v dCBvdGhlcnMuDQoNClRoYXQncyBhZGp1c3RpbmcgdGhlIHJlc3BvbnNlIGJhc2VkIG9uIHRoZSBp ZGVudGl0eSBvZiB0aGUgY2xpZW50Lg0KQnV0IHdoYXQgSSdtIGFza2luZyBmb3IgaXMgYSB1c2Ug Y2FzZSBmb3Igc2VuZGluZyBpbmNvbnNpc3RlbnQgTlNFQyBiaXRtYXBzDQp0byB0aGUgc2FtZSBj bGllbnQuIEkgdGhpbmsgdGhhdCdzIGhhcmQgdG8gZW52aXNhZ2UuDQogDQo+IFRoZSB3YXkgdGhl IHN0YW5kYXJkcyByZWFkIG5vdywgaXQncyBwb3NzaWJsZSB0byBnZW5lcmF0ZSBOU0VDLzMncyAN Cj4gb3duaW5nIGEgcHJpdmF0ZSB0eXBlIGZvciBhbGwgbmFtZXMgdGhhdCB3YXJyYW50IG9uZSAo TlNFQyBkb2VzIG5vdCANCj4gcmVwcmVzZW50IGVtcHR5IG5vbi10ZXJtaW5hbHMsIE5TRUMzIGRv ZXMpIGNsYWltaW5nIGp1c3QgYSBwcml2YXRlIA0KPiB0eXBlIGFuZCB0aGluZ3Mgd291bGQgd29y ay4gIFRoYXQncyBiZWNhdXNlIHlvdSBkb24ndCBnZXQgYSBOU0VDLzMgaW4gDQo+IGEgcG9zaXRp dmUgYW5zd2VyIChvdGhlciB0aGFuIEFOWSkuDQoNClJpZ2h0LiBXaGF0IEknbSBzYXlpbmcgaXMg dGhhdCBhbiBOU0VDIGJpdG1hcCB0ZWxscyBhIGNsaWVudCB0aGUgY29tcGxldGUgc2V0DQpvZiB0 eXBlcyB0aGF0IGRvbid0IGV4aXN0IGZvciBhIGRvbWFpbiwgYW5kIGl0J3MgcmVhc29uYWJsZSBm b3IgYSBjbGllbnQgdG8NCnVzZSBhbGwgb2YgdGhhdCBpbmZvcm1hdGlvbiAoIHJhdGhlciB0aGFu IGp1c3QgZm9yIHRoZSB0eXBlIHJlcXVlc3RlZCApLg0KWW91IGRvbid0IHNlZW0gdG8gaGF2ZSBj b21lIHVwIHdpdGggYSBwbGF1c2libGUgZXhhbXBsZSB3aGVyZSB0aGF0DQpjb3VsZCBiZSBhIHBy b2JsZW0sIGFuZCBJIGNhbm5vdCBzZWUgb25lIGVpdGhlci4NCg0KR2VvcmdlDQoNCj4gLS0gDQo+ IC09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LQ0KPiBFZHdhcmQgTGV3aXMNCj4gTmV1U3RhciAgICAgICAgICAg ICAgICAgICAgWW91IGNhbiBsZWF2ZSBhIHZvaWNlIG1lc3NhZ2UgYXQgKzEtNTcxLTQzNC01NDY4 DQo+IA0KPiBNZSB0byBpbmZhbnQgc29uOiAiV2FhaCEgV2FhaCEgSXMgdGhhdCBhbGwgeW91IGNh biBzYXk/ICBXYWFoPyINCj4gU29uOiAiV2FhaCEiDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRuc2V4dCBtYWlsaW5nIGxpc3QNCj4gZG5zZXh0 QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0 From Ed.Lewis@neustar.biz Tue Mar 29 10:36:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543B93A6943 for ; Tue, 29 Mar 2011 10:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K5fVeBCMeTg for ; Tue, 29 Mar 2011 10:36:03 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 8B3E63A683A for ; Tue, 29 Mar 2011 10:36:03 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2THbZWV066496; Tue, 29 Mar 2011 13:37:36 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Tue, 29 Mar 2011 13:37:36 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 29 Mar 2011 13:37:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <3B987BF13718424BBA818C248C428E64@local> References: <8EA8D1A36B8F49 68ABE973C39CA5E0E0@local> <55128075215341BD92DCAAD00450FA85@l ocal> <3B987BF13718424BBA818C248C428E64@local> Date: Tue, 29 Mar 2011 13:28:26 -0400 To: George Barwood From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 17:36:05 -0000 At 18:16 +0100 3/29/11, George Barwood wrote: >What I'm saying is that an NSEC bitmap tells a client the complete set >of types that don't exist for a domain, That's wrong. The bitmap presents information signed by the authority demonstrating that the type you requested does not exist at the name. The way it is supposed to work is - you ask for fqdn.tld. A record. The response comes back with an empty answer section and an SOA and NSEC/3 in the authority demonstrating that the requested type is not there. The tradeoff here is that the NSEC can be replayed to deny the existence of another type to save having to manage multiple NSEC records for a name. I'm not going to debate the tradeoff. Obviously there are two sides to the story, and whether there is a gain in reducing the number of NSEC/3's to manage. But I am against changing the specification to close off the debate. If the specifications are changed, the net result is giving more authority to the caches and taking the debate away from the authoritative portion of the system. That is why I resist extending the inferences based on NSEC/3 bitmaps. The subject line was NXDOMAIN. I'm not talking about that. We already carefully considered that in the development of DNSSEC and have the results documented. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From george.barwood@blueyonder.co.uk Tue Mar 29 11:12:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9543A6A7F for ; Tue, 29 Mar 2011 11:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZIl9w-KZixz for ; Tue, 29 Mar 2011 11:12:36 -0700 (PDT) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by core3.amsl.com (Postfix) with ESMTP id 112063A6A76 for ; Tue, 29 Mar 2011 11:12:35 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.1]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110329181411.TONK13167.mtaout03-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Tue, 29 Mar 2011 19:14:11 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1Q4dQg-00043t-V9; Tue, 29 Mar 2011 19:14:11 +0100 Message-ID: From: "George Barwood" To: "Edward Lewis" References: <8EA8D1A36B8F49 68ABE973C39CA5E0E0@local> <55128075215341BD92DCAAD00450FA85@l ocal> <3B987BF13718424BBA818C248C428E64@local> Date: Tue, 29 Mar 2011 19:14:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=dSD2fgld_FcA:10 a=8nJEP1OIZ-IA:10 a=a5Gf7U6LAAAA:8 a=48vgC7mUAAAA:8 a=bgHunIh9sCw15xUeD04A:9 a=pVe9PNzGAL91H791Ws9FEKGebxcA:4 a=wPNLvfGTeEIA:10 a=yHIqe9kG5mgA:10 a=lZB815dzVvQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 18:12:37 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVkd2FyZCBMZXdpcyIgPEVk Lkxld2lzQG5ldXN0YXIuYml6Pg0KVG86ICJHZW9yZ2UgQmFyd29vZCIgPGdlb3JnZS5iYXJ3b29k QGJsdWV5b25kZXIuY28udWs+DQpDYzogPGRuc2V4dEBpZXRmLm9yZz47ICJFZHdhcmQgTGV3aXMi IDxFZC5MZXdpc0BuZXVzdGFyLmJpej4NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI5LCAyMDExIDY6 MjggUE0NClN1YmplY3Q6IGJpdG1hcCBpbmZlcmVuY2Ugd2FzIFJlOiAuLi4gLSBOWERPTUFJTiBm b3IgZW1wdHlub24tdGVybWluYWxzDQoNCg0KPiBBdCAxODoxNiArMDEwMCAzLzI5LzExLCBHZW9y Z2UgQmFyd29vZCB3cm90ZToNCj4gDQo+PldoYXQgSSdtIHNheWluZyBpcyB0aGF0IGFuIE5TRUMg Yml0bWFwIHRlbGxzIGEgY2xpZW50IHRoZSBjb21wbGV0ZSBzZXQNCj4+b2YgdHlwZXMgdGhhdCBk b24ndCBleGlzdCBmb3IgYSBkb21haW4sDQo+IA0KPiBUaGF0J3Mgd3JvbmcuICBUaGUgYml0bWFw IHByZXNlbnRzIGluZm9ybWF0aW9uIHNpZ25lZCBieSB0aGUgDQo+IGF1dGhvcml0eSBkZW1vbnN0 cmF0aW5nIHRoYXQgdGhlIHR5cGUgeW91IHJlcXVlc3RlZCBkb2VzIG5vdCBleGlzdCBhdCANCj4g dGhlIG5hbWUuDQoNClRoZSBzdGFuZGFyZCAoIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzQwMzQjc2VjdGlvbi00LjEuMiApIHNheXMNCg0KICAgVGhlIFR5cGUgQml0IE1hcHMgZmllbGQg aWRlbnRpZmllcyB0aGUgUlJzZXQgdHlwZXMgdGhhdCBleGlzdCBhdCB0aGUNCiAgIE5TRUMgUlIn cyBvd25lciBuYW1lLg0KDQpUaGF0J3MgY2xlYXIgYW5kIHVuYW1iaWd1b3VzLCBJIGNhbm5vdCBz ZWUgaG93IHlvdSBjYW4gcmVhZCB0aGF0IGFueSBvdGhlciB3YXkuDQpCdXQgSSdtIGdvaW5nIHRv IHN0b3AgaGVyZSBhbmQgc2VlIGlmIG90aGVycyBoYXZlIHZpZXdzIG9uIHRoaXMuDQoNCkdlb3Jn ZQ0K From Ed.Lewis@neustar.biz Tue Mar 29 11:32:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5841C3A6A82 for ; Tue, 29 Mar 2011 11:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgCJ9i6Ta67E for ; Tue, 29 Mar 2011 11:32:22 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 873D03A6A7F for ; Tue, 29 Mar 2011 11:32:22 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2TIXuMB066942; Tue, 29 Mar 2011 14:33:57 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.119] by Work-Laptop-2.local (PGP Universal service); Tue, 29 Mar 2011 14:33:57 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 29 Mar 2011 14:33:57 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8EA8D1A36B8F49 68ABE973C39CA5E0E0@local> <55128075215341BD92DCAAD00450FA85@l ocal> <3B987BF13718424BBA818C248C428E64@local> Date: Tue, 29 Mar 2011 14:33:35 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 18:32:24 -0000 At 19:14 +0100 3/29/11, George Barwood wrote: >The standard ( http://tools.ietf.org/html/rfc4034#section-4.1.2 ) says > The Type Bit Maps field identifies the RRset types that exist at the > NSEC RR's owner name. It doesn't say "MUST". That's giving the semantic meaning of the field. And it doesn't say "when" existence is tested. >That's clear and unambiguous, I cannot see how you can read that any >other way. >But I'm going to stop here and see if others have views on this. The problem is determining a if there is a protocol violation. If you get this: t=0 (Q:fqdn.tld./IN/AAAA): fqdn.tld. 3600 IN NSEC other.tld. priv_type t=5 (Q:fqdn.tld./IN/A): fqdn.tld. 3600 IN A 127.0.0.1 How can you tell if I generated the NSEC regardless of the A record or just before the A record was added to the zone? In the latter case, if you asked for the A you don't get the would-be-new NSEC. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From marka@isc.org Tue Mar 29 23:22:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABB13A6A9A for ; Tue, 29 Mar 2011 23:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_NO_MORE_ADS=1.174] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp1jivj+Zmyi for ; Tue, 29 Mar 2011 23:22:02 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 11D673A6A87 for ; Tue, 29 Mar 2011 23:22:02 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 074A2C9423 for ; Wed, 30 Mar 2011 06:23:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [77.78.82.82]) (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 C69BA216C33 for ; Wed, 30 Mar 2011 06:23:37 +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 BA8C9DAC3C4 for ; Wed, 30 Mar 2011 17:23:35 +1100 (EST) To: dnsext@ietf.org From: Mark Andrews Date: Wed, 30 Mar 2011 17:23:35 +1100 Message-Id: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> Subject: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 06:22:06 -0000 I don't think we have the sematics of these bits quite right yet. In normal operations a validating resolver taking to a cache should just set DO. This will result in DNSSEC records being returned and in most cases these will validate. This also permits caches to do their jobs correctly. When these do not validate or SERVFAIL is returned, the validating resolver should then re-issue the query with CD set and a EDNS option indicating which upstream servers have been tried. This option is initially empty. The cache will then behave as a proxy for this query (excluding the EDNS option) adding the responding server's address to the EDNS option. If there are no more addresses to try, SERVFAIL (new rcode?) is returned along with the EDNS option from the query. If the cache is using another cache the entire query/response is proxied. The intent is for the validating client to talk through intermediate caches to the cache talk directly to the authoritative servers. The EDNS option maintains a list of authoritative server addresses for the zone that have been tried. This list is passed back and forth between the validating resolver and the cache talking to the authoritative server. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From alex@alex.org.uk Tue Mar 29 23:40:57 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2FF28C0D7 for ; Tue, 29 Mar 2011 23:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbmkC9Z8S5u1 for ; Tue, 29 Mar 2011 23:40:56 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 6C0B23A6B11 for ; Tue, 29 Mar 2011 23:40:56 -0700 (PDT) Received: from [172.20.10.2] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id A3F16C560C5; Wed, 30 Mar 2011 07:42:33 +0100 (BST) Date: Wed, 30 Mar 2011 07:42:32 +0000 From: Alex Bligh To: Mark Andrews , dnsext@ietf.org Message-ID: <0CAE569785C163CFE87B957E@nimrod.local> In-Reply-To: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 06:40:57 -0000 --On 30 March 2011 17:23:35 +1100 Mark Andrews wrote: > When these do not validate or SERVFAIL is returned, the validating > resolver should then re-issue the query with CD set and a EDNS > option indicating which upstream servers have been tried. Why "should"? Effectively the validating resolver is handing off DNSSEC validation to the upstream server here isn't it? It might not want to trust the upstream server, particularly if it's already got records that don't validate. -- Alex Bligh From vixie@isc.org Wed Mar 30 00:01:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C2C28C0DD for ; Wed, 30 Mar 2011 00:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPW6-SawP3xu for ; Wed, 30 Mar 2011 00:01:17 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 1DC9028C0F0 for ; Wed, 30 Mar 2011 00:01:16 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 01260A1031 for ; Wed, 30 Mar 2011 07:02:52 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Wed, 30 Mar 2011 17:23:35 +1100." <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Wed, 30 Mar 2011 07:02:51 +0000 Message-ID: <46219.1301468571@nsa.vix.com> Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 07:01:18 -0000 > From: Mark Andrews > Date: Wed, 30 Mar 2011 17:23:35 +1100 > ... > When these do not validate or SERVFAIL is returned, the validating > resolver should then re-issue the query with CD set and a EDNS option > indicating which upstream servers have been tried. This option is > initially empty. The cache will then behave as a proxy for this query > (excluding the EDNS option) adding the responding server's address to > the EDNS option. If there are no more addresses to try, SERVFAIL (new > rcode?) is returned along with the EDNS option from the query. objection. this assumes that the reason for servfail is upstream (which it may not be), assumes that the upstream server identities are unambiguous from the client's point of view (which in the case of nat may not be true), and assumes that the client knows better than the server how to avoid failure. since your proposal assumes new protocol elements to be implemented in all servers and some clients, i think it would be better to add something that solves the actual problem. the server in this case should consider using michael graff's hybrid blast protocol, send the query to the first upstream, and if it fails then resend it to all upstreams in parallel. this would get the upstream transaction timeout down into the downstream client's timeout window. the wire change i would like is wholly different. since clients should not need to add caches when they add validation, i'd like the chain of rrsig and dnskey to be sent from the recursive server to the stub, everything it takes to validate the answer. to do this, a new EDNS option would allow the client to express its closest trust point. so if the client already knows (in a current-transaction cache that is not shared with other applications or transactions on the client host) it has a valid dnskey for google.com and it's asking for www.google.com then the only RRSIGs or DS/DNSKEY's it needs are for www.google.com and www.l.google.com. > If the cache is using another cache the entire query/response is > proxied. The intent is for the validating client to talk through > intermediate caches to the cache talk directly to the authoritative > servers. The EDNS option maintains a list of authoritative server > addresses for the zone that have been tried. This list is passed > back and forth between the validating resolver and the cache talking > to the authoritative server. again, if we're going to change the servers by adding support for some new wire element, let's just make the server do the right kind of failure avoidance. and if we're going to add a new wire element let's have it be one that lets cacheless stub validation work. From vixie@isc.org Wed Mar 30 00:03:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF5E3A6B18 for ; Wed, 30 Mar 2011 00:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlxrOGoqIwLg for ; Wed, 30 Mar 2011 00:03:55 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 704D23A6B0F for ; Wed, 30 Mar 2011 00:03:55 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4F947A1019 for ; Wed, 30 Mar 2011 07:05:33 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Wed, 30 Mar 2011 07:42:32 GMT." <0CAE569785C163CFE87B957E@nimrod.local> References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Wed, 30 Mar 2011 07:05:33 +0000 Message-ID: <46410.1301468733@nsa.vix.com> Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 07:03:56 -0000 > Date: Wed, 30 Mar 2011 07:42:32 +0000 > From: Alex Bligh > ... > Why "should"? Effectively the validating resolver is handing off > DNSSEC validation to the upstream server here isn't it? ... i loved it when dan kaminsky said, i'm not going to trust the starbucks resolver to introduce me to my bank. so, to the above, no. a validating resolver has a trust anchor (probably the root key and RFC5011 support) and is going to be setting CD and doing its own crypto. From marka@isc.org Wed Mar 30 00:09:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04253A6B20 for ; Wed, 30 Mar 2011 00:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVlpbmT-HPd3 for ; Wed, 30 Mar 2011 00:09:47 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id B0C793A6B1D for ; Wed, 30 Mar 2011 00:09:47 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id AE1CE5F984C; Wed, 30 Mar 2011 07:11:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:32:6233:4bff:fe01:7585]) (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 E1DF9216C22; Wed, 30 Mar 2011 07:11:08 +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 72604DAC915; Wed, 30 Mar 2011 18:11:05 +1100 (EST) To: Alex Bligh From: Mark Andrews References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org><0CAE569785C163CFE87B957E@nimrod.local> In-reply-to: Your message of "Wed, 30 Mar 2011 07:42:32 -0000." <0CAE569785C163CFE87B957E@nimrod.local> Date: Wed, 30 Mar 2011 18:11:05 +1100 Message-Id: <20110330071105.72604DAC915@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 07:09:48 -0000 In message <0CAE569785C163CFE87B957E@nimrod.local>, Alex Bligh writes: > > > --On 30 March 2011 17:23:35 +1100 Mark Andrews wrote: > > > When these do not validate or SERVFAIL is returned, the validating > > resolver should then re-issue the query with CD set and a EDNS > > option indicating which upstream servers have been tried. > > Why "should"? Effectively the validating resolver is handing off > DNSSEC validation to the upstream server here isn't it? It might not > want to trust the upstream server, particularly if it's already > got records that don't validate. You can have different clocks and different sets of trust anchors. The upstream could be treating a zone as insecure but you have a trust anchor. The upstream won't filter stale responses for you so it won't cope with a authoritative server with stale data and a number of other operational errors that you can work around with direct access to the authoritative servers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ietf-namedroppers@m.gmane.org Wed Mar 30 00:32:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2733A6B23 for ; Wed, 30 Mar 2011 00:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=1.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeGNROIUTmAN for ; Wed, 30 Mar 2011 00:32:53 -0700 (PDT) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by core3.amsl.com (Postfix) with ESMTP id 7040A3A6B15 for ; Wed, 30 Mar 2011 00:32:53 -0700 (PDT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q4pvC-0006YZ-Qu for dnsext@ietf.org; Wed, 30 Mar 2011 09:34:31 +0200 Received: from dhcp-164d.meeting.ietf.org ([130.129.22.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2011 09:34:30 +0200 Received: from mcr by dhcp-164d.meeting.ietf.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2011 09:34:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: dnsext@ietf.org From: Michael Richardson Date: Wed, 30 Mar 2011 07:34:20 +0000 (UTC) Lines: 21 Message-ID: References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <46219.1301468571@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 130.129.22.77 (Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.237 Safari/534.10) Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 07:32:54 -0000 Paul Vixie isc.org> writes: > the wire change i would like is wholly different. since clients should > not need to add caches when they add validation, i'd like the chain of > rrsig and dnskey to be sent from the recursive server to the stub, > everything it takes to validate the answer. to do this, a new EDNS > option would allow the client to express its closest trust point. so if > the client already knows (in a current-transaction cache that is not > shared with other applications or transactions on the client host) it > has a valid dnskey for google.com and it's asking for www.google.com > then the only RRSIGs or DS/DNSKEY's it needs are for www.google.com > and www.l.google.com. I'd like to see this too. A place where I think this is super useful with is lldns/bonjour, for the adhoc disconnected case. I claim to be bob.exaqmple.com on the wire, and when I do that I include the chain of rrsig/dnskey from . (or whatever anchor point you say you already have). From marka@isc.org Wed Mar 30 01:09:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4980C3A6AFD for ; Wed, 30 Mar 2011 01:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRmc4FwxKNaM for ; Wed, 30 Mar 2011 01:09:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 647183A6886 for ; Wed, 30 Mar 2011 01:09:03 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 3482FC9432; Wed, 30 Mar 2011 08:10:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:6233:4bff:fe01:7585]) (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 B5934216C33; Wed, 30 Mar 2011 08:10:32 +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 867FDDAD484; Wed, 30 Mar 2011 19:10:29 +1100 (EST) To: Paul Vixie From: Mark Andrews References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> In-reply-to: Your message of "Wed, 30 Mar 2011 07:05:33 -0000." <46410.1301468733@nsa.vix.com> Date: Wed, 30 Mar 2011 19:10:29 +1100 Message-Id: <20110330081029.867FDDAD484@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:09:04 -0000 In message <46410.1301468733@nsa.vix.com>, Paul Vixie writes: > > Date: Wed, 30 Mar 2011 07:42:32 +0000 > > From: Alex Bligh > > ... > > Why "should"? Effectively the validating resolver is handing off > > DNSSEC validation to the upstream server here isn't it? ... > > i loved it when dan kaminsky said, i'm not going to trust the starbucks > resolver to introduce me to my bank. so, to the above, no. a validating > resolver has a trust anchor (probably the root key and RFC5011 support) > and is going to be setting CD and doing its own crypto. DO=1 is ALL you require to do your own authentication 99.99999999% of the time. CD=1 is ONLY needed when the upsteam is doing DNSSEC and its concept of the current time and/or its set of trust anchors differ to yours. CD=1 doesn't help you when the upstream is treating the zone the answer comes from as insecure. CD=0 DOES NOT mean you are not authenticating. A validating resolver with direct access to the athoritative servers can work around a number of operational errors by being able to retry the query with different servers. A validating resolver behind a cache does not have this recovery path. The EDNS option is designed to give it that recovery path. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From alex@alex.org.uk Wed Mar 30 01:33:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808263A6A2B for ; Wed, 30 Mar 2011 01:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DldEbCge5Y+h for ; Wed, 30 Mar 2011 01:32:59 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 8473F3A6AF5 for ; Wed, 30 Mar 2011 01:32:59 -0700 (PDT) Received: from [172.20.10.2] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 63E55C560B5; Wed, 30 Mar 2011 09:34:37 +0100 (BST) Date: Wed, 30 Mar 2011 09:34:36 +0000 From: Alex Bligh To: Mark Andrews Message-ID: <1CA2585509A7CF3EC32560F8@nimrod.local> In-Reply-To: <20110330071105.72604DAC915@drugs.dv.isc.org> References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local> <20110330071105.72604DAC915@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:33:00 -0000 --On 30 March 2011 18:11:05 +1100 Mark Andrews wrote: > You can have different clocks and different sets of trust anchors. > The upstream could be treating a zone as insecure but you have a > trust anchor. The upstream won't filter stale responses for you > so it won't cope with a authoritative server with stale data and a > number of other operational errors that you can work around with > direct access to the authoritative servers. Hmmm. I think I understand. And none of these errors that you can work around with "direct" access to the authoritative servers are ones that will end up in the BAD cache? As you'll still see these I think. RFC4035 s3.2.2 > If the CD bit is set, > the name server side SHOULD return the data from the BAD cache; Isn't the real answer here just to be a full recursive resolver and *really* access the authoritative nameservers directly? I take it you are suggesting that the reissued query should always have DO set as well as CD. -- Alex Bligh From marka@isc.org Wed Mar 30 01:44:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92973A6AFB for ; Wed, 30 Mar 2011 01:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1y3QU8SkYUFC for ; Wed, 30 Mar 2011 01:44:41 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id DAA6E3A6919 for ; Wed, 30 Mar 2011 01:44:40 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 3404D5F984C; Wed, 30 Mar 2011 08:46:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:6233:4bff:fe01:7585]) (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 2B2E9216C22; Wed, 30 Mar 2011 08:46:02 +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 401CADAD6B8; Wed, 30 Mar 2011 19:46:00 +1100 (EST) To: Alex Bligh From: Mark Andrews References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local> <20110330071105.72604DAC915@drugs.dv.isc.org><1CA2585509A7CF3EC32560F8@nimrod.local> In-reply-to: Your message of "Wed, 30 Mar 2011 09:34:36 -0000." <1CA2585509A7CF3EC32560F8@nimrod.local> Date: Wed, 30 Mar 2011 19:46:00 +1100 Message-Id: <20110330084600.401CADAD6B8@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:44:41 -0000 In message <1CA2585509A7CF3EC32560F8@nimrod.local>, Alex Bligh writes: > > > --On 30 March 2011 18:11:05 +1100 Mark Andrews wrote: > > > You can have different clocks and different sets of trust anchors. > > The upstream could be treating a zone as insecure but you have a > > trust anchor. The upstream won't filter stale responses for you > > so it won't cope with a authoritative server with stale data and a > > number of other operational errors that you can work around with > > direct access to the authoritative servers. > > Hmmm. I think I understand. > > And none of these errors that you can work around with "direct" > access to the authoritative servers are ones that > will end up in the BAD cache? As you'll still see these I think. > RFC4035 s3.2.2 > > If the CD bit is set, > > the name server side SHOULD return the data from the BAD cache; > > Isn't the real answer here just to be a full recursive resolver > and *really* access the authoritative nameservers directly? There are plenty of sites that only allow the recursive server talk to the world. As much as I would like to say "go direct to the source" it is not practical. As for the "bad cache" the only reason for that is we provided bad advice of "set the CD if you intend to validate". CD really needs to be set less often. > I take it you are suggesting that the reissued query should always > have DO set as well as CD. > > -- > Alex Bligh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From vixie@isc.org Wed Mar 30 01:55:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA9C28C0E5 for ; Wed, 30 Mar 2011 01:55:26 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNWwJvAuNEdG for ; Wed, 30 Mar 2011 01:55:25 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id A1F6628C0CE for ; Wed, 30 Mar 2011 01:55:25 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D84B4A1055 for ; Wed, 30 Mar 2011 08:57:02 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Wed, 30 Mar 2011 19:10:29 +1100." <20110330081029.867FDDAD484@drugs.dv.isc.org> References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Wed, 30 Mar 2011 08:57:02 +0000 Message-ID: <52718.1301475422@nsa.vix.com> Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:55:27 -0000 > From: Mark Andrews > Date: Wed, 30 Mar 2011 19:10:29 +1100 > > DO=1 is ALL you require to do your own authentication 99.99999999% > of the time. as long as you're planning to ignore the AD bit, sure. but i still think that we should be able to ask the recursive validator for a longer chain since the transaction-level cache will otherwise have to be built up over many round trips. > CD=0 DOES NOT mean you are not authenticating. so noted. > A validating resolver with direct access to the athoritative servers > can work around a number of operational errors by being able to retry > the query with different servers. i'd like to consider the validating nonrecursive noncaching case first, since that's the closest analogue to how dns works today. if i'm in a hotel room or coffee shop behind NAT and/or firewall and the only UDP/53 destination i can reach is the isp's recursive caching dnssec-aware name server then i'd like to be able to get everything i need for trustworthiness of an answer (www.yourbankhere.com IN AAAA) in a single round trip. > A validating resolver behind a cache does not have this recovery > path. The EDNS option is designed to give it that recovery path. i think that any state held in the validating nonrecursive noncaching initiator that has to do with the authority servers would be a mistake. From fanf2@hermes.cam.ac.uk Wed Mar 30 04:17:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C8528C14C for ; Wed, 30 Mar 2011 04:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFHIraoeF4ir for ; Wed, 30 Mar 2011 04:17:40 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 3B6A828C137 for ; Wed, 30 Mar 2011 04:17:40 -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-1.csi.cam.ac.uk ([131.111.8.51]:45007) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Q4tQk-0006av-RD (Exim 4.72) (return-path ); Wed, 30 Mar 2011 12:19:18 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Q4tQk-0005l5-DY (Exim 4.67) (return-path ); Wed, 30 Mar 2011 12:19:18 +0100 Date: Wed, 30 Mar 2011 12:19:18 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20110330081029.867FDDAD484@drugs.dv.isc.org> Message-ID: References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:17:41 -0000 Mark Andrews wrote: > > A validating resolver with direct access to the athoritative servers > can work around a number of operational errors by being able to > retry the query with different servers. Is this the kind of thing you'd implement in an every-day stub resolver or is it just for dig jockeys? Tony. -- f.anthony.n.finch http://dotat.at/ Biscay: Southwest 5 or 6. Moderate or rough, occasionally very rough later in north. Occasional rain. Moderate or good. From marka@isc.org Wed Mar 30 04:37:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81C728C172 for ; Wed, 30 Mar 2011 04:37:54 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2ciOCM1Zj5r for ; Wed, 30 Mar 2011 04:37:54 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 907D328C171 for ; Wed, 30 Mar 2011 04:37:53 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id A386DC9465; Wed, 30 Mar 2011 11:39:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:6233:4bff:fe01:7585]) (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 712CF216C33; Wed, 30 Mar 2011 11:39:29 +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 7F67BDADDFE; Wed, 30 Mar 2011 22:39:27 +1100 (EST) To: Tony Finch From: Mark Andrews References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 30 Mar 2011 12:19:18 BST." Date: Wed, 30 Mar 2011 22:39:27 +1100 Message-Id: <20110330113927.7F67BDADDFE@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:37:54 -0000 In message , Tony Fi nch writes: > Mark Andrews wrote: > > > > A validating resolver with direct access to the athoritative servers > > can work around a number of operational errors by being able to > > retry the query with different servers. > > Is this the kind of thing you'd implement in an every-day stub resolver or > is it just for dig jockeys? Every day validating stub resolver. Dig is a diagnotic tool and would only implement this if it was explicitly told to. You want dig to see the errors. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jelte@isc.org Wed Mar 30 04:37:57 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B1928C0DB for ; Wed, 30 Mar 2011 04:37:57 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKqyGqMV6JHD for ; Wed, 30 Mar 2011 04:37:55 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id EE62928C171 for ; Wed, 30 Mar 2011 04:37:54 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id E4D575F98B6; Wed, 30 Mar 2011 11:39:18 +0000 (UTC) (envelope-from jelte@isc.org) Received: from [IPv6:2001:df8:0:16:222:43ff:fe24:8028] (unknown [IPv6:2001:df8:0:16:222:43ff:fe24:8028]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 01FF6216C22; Wed, 30 Mar 2011 11:39:15 +0000 (UTC) (envelope-from jelte@isc.org) Message-ID: <4D931660.1000004@isc.org> Date: Wed, 30 Mar 2011 13:39:12 +0200 From: Jelte Jansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Edward Lewis References: <8EA8D1A36B8F49 68ABE973C39CA5E0E0@local> <55128075215341BD92DCAAD00450FA85@l ocal> <3B987BF13718424BBA818C248C428E64@local> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:37:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/29/2011 08:33 PM, Edward Lewis wrote: > At 19:14 +0100 3/29/11, George Barwood wrote: > >> The standard ( http://tools.ietf.org/html/rfc4034#section-4.1.2 ) says >> The Type Bit Maps field identifies the RRset types that exist at the >> NSEC RR's owner name. > > It doesn't say "MUST". That's giving the semantic meaning of the > field. And it doesn't say "when" existence is tested. > It does not say 'MAY depend on type' either :) > The problem is determining a if there is a protocol violation. > > If you get this: > > t=0 (Q:fqdn.tld./IN/AAAA): > fqdn.tld. 3600 IN NSEC other.tld. priv_type > t=5 (Q:fqdn.tld./IN/A): > fqdn.tld. 3600 IN A 127.0.0.1 > > How can you tell if I generated the NSEC regardless of the A record or > just before the A record was added to the zone? In the latter case, if > you asked for the A you don't get the would-be-new NSEC. > as with another example you used in a previous discussion, it would seem you are arguing for not doing negative caching at all (i.e. if an A record is queried, does not exist, is then added, and queried again it would show the same behavior as when you ask for a different type and derive data from the nsec bitmap). Taking that further, what if something is removed between t=0 and t=5, should we also not do positive caching? :) IMO whether or not aggressive caching should be done or allowed, giving different answers where one would expect the same (i.e. different NSECs depending on the qtype, in this case) makes me slightly nauseous :p But that is probably not much of a protocol qualification. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2TFmAACgkQ4nZCKsdOncWNfwCfQl7zOdcS8jue8L3wv6G9KApc fwcAoLlIQlvsQSpRuWRrmIOHmzjBuPT9 =ut5O -----END PGP SIGNATURE----- From marka@isc.org Wed Mar 30 04:53:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8A828C11A for ; Wed, 30 Mar 2011 04:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPglorjfZ58V for ; Wed, 30 Mar 2011 04:53:14 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 37C2028C126 for ; Wed, 30 Mar 2011 04:53:14 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 24258C9423; Wed, 30 Mar 2011 11:54:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:6233:4bff:fe01:7585]) (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 A498D216C33; Wed, 30 Mar 2011 11:54:48 +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 A5A18DAE0F0; Wed, 30 Mar 2011 22:54:46 +1100 (EST) To: Paul Vixie From: Mark Andrews References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org><52718.1301475422@nsa.vix.com> In-reply-to: Your message of "Wed, 30 Mar 2011 08:57:02 -0000." <52718.1301475422@nsa.vix.com> Date: Wed, 30 Mar 2011 22:54:46 +1100 Message-Id: <20110330115446.A5A18DAE0F0@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:53:16 -0000 In message <52718.1301475422@nsa.vix.com>, Paul Vixie writes: > > From: Mark Andrews > > Date: Wed, 30 Mar 2011 19:10:29 +1100 > > > > DO=1 is ALL you require to do your own authentication 99.99999999% > > of the time. > > as long as you're planning to ignore the AD bit, sure. And in the general case you do ignore the AD bit. If you are trusting the AD but you don't need to set DO, AD=1 in the query is enough assuming the server understands AD=1 which you should know if you are going to trust AD. > but i still think > that we should be able to ask the recursive validator for a longer chain > since the transaction-level cache will otherwise have to be built up over > many round trips. Which is orthogal to this issue. > > CD=0 DOES NOT mean you are not authenticating. > > so noted. > > > A validating resolver with direct access to the athoritative servers > > can work around a number of operational errors by being able to retry > > the query with different servers. > > i'd like to consider the validating nonrecursive noncaching case first, > since that's the closest analogue to how dns works today. if i'm in a > hotel room or coffee shop behind NAT and/or firewall and the only UDP/53 > destination i can reach is the isp's recursive caching dnssec-aware name > server then i'd like to be able to get everything i need for trustworthiness > of an answer (www.yourbankhere.com IN AAAA) in a single round trip. Which is a seperate issue. > > A validating resolver behind a cache does not have this recovery > > path. The EDNS option is designed to give it that recovery path. > > i think that any state held in the validating nonrecursive noncaching > initiator that has to do with the authority servers would be a mistake. The state is not held anywhere. It's passed back and forward. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jelte@isc.org Wed Mar 30 04:59:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBD428C126 for ; Wed, 30 Mar 2011 04:59:50 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPM9imgfL2eE for ; Wed, 30 Mar 2011 04:59:49 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id E36F828C12F for ; Wed, 30 Mar 2011 04:59:48 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 5981A5F9891; Wed, 30 Mar 2011 12:01:13 +0000 (UTC) (envelope-from jelte@isc.org) Received: from [IPv6:2001:df8:0:16:222:43ff:fe24:8028] (unknown [IPv6:2001:df8:0:16:222:43ff:fe24:8028]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2B923216C33; Wed, 30 Mar 2011 12:01:09 +0000 (UTC) (envelope-from jelte@isc.org) Message-ID: <4D931B80.2040407@isc.org> Date: Wed, 30 Mar 2011 14:01:04 +0200 From: Jelte Jansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Paul Vixie References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <46219.1301468571@nsa.vix.com> In-Reply-To: <46219.1301468571@nsa.vix.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:59:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > the wire change i would like is wholly different. since clients should > not need to add caches when they add validation, i'd like the chain of > rrsig and dnskey to be sent from the recursive server to the stub, > everything it takes to validate the answer. to do this, a new EDNS > option would allow the client to express its closest trust point. so if > the client already knows (in a current-transaction cache that is not > shared with other applications or transactions on the client host) it > has a valid dnskey for google.com and it's asking for www.google.com > then the only RRSIGs or DS/DNSKEY's it needs are for www.google.com > and www.l.google.com. > Note that this makes the assumption that that is actually the trust point that has a validatable chain, and not a failing one while there is a higher trust point that would lead to succesful validation (yes yes, this may or may not be good or bad or local policy or whatever, cue discussion for multiple chains where some fail). > again, if we're going to change the servers by adding support for some > new wire element, let's just make the server do the right kind of failure > avoidance. and if we're going to add a new wire element let's have it be > one that lets cacheless stub validation work. i would also like to see something like this, btw. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2TG4AACgkQ4nZCKsdOncUpvACcCshacCAQx+GnU/+NXAnRUL/n hbkAn34dNBZuvqHubIIhKlcS9WtASj21 =jnsf -----END PGP SIGNATURE----- From fweimer@bfk.de Wed Mar 30 05:03:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB8E3A6B42 for ; Wed, 30 Mar 2011 05:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R41VTOB+Cvwm for ; Wed, 30 Mar 2011 05:03:15 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id B52693A6947 for ; Wed, 30 Mar 2011 05:03:15 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Q4u8p-0002a5-EW; Wed, 30 Mar 2011 12:04:51 +0000 Received: by bfk.de with local id 1Q4u8p-00074U-At; Wed, 30 Mar 2011 12:04:51 +0000 To: Edward Lewis References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> <95465.1301414968@nsa.vix.com> From: Florian Weimer Date: Wed, 30 Mar 2011 12:04:51 +0000 In-Reply-To: (Edward Lewis's message of "Tue\, 29 Mar 2011 12\:18\:52 -0400") Message-ID: <82vcz0n7a4.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:03:16 -0000 * Edward Lewis: > At 16:09 +0000 3/29/11, Paul Vixie wrote: >>> Date: Tue, 29 Mar 2011 11:58:29 -0400 >>> From: Edward Lewis >>> >>> >is there any opposition to this change? >>> >>> Given the back and forth, can you summarize what "this change" refers = to? >> >>this one: >> >>> > > this sounds like a veiled suggestion that we remove this from resi= mprove > > "remove this" -> remove what? Trying to find the messages on this, it > seems there was some mention of an EDNS option, but in > > http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 I was referring to section 3. I think it is misleading and would lead to poorer service from resolvers if implemented. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From marka@isc.org Wed Mar 30 05:08:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0EA83A67CC for ; Wed, 30 Mar 2011 05:08:12 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFv-o79uIyzH for ; Wed, 30 Mar 2011 05:08:12 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 2169D3A697B for ; Wed, 30 Mar 2011 05:08:12 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 11204C944E for ; Wed, 30 Mar 2011 12:09:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:6233:4bff:fe01:7585]) (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 D403F216C56 for ; Wed, 30 Mar 2011 12:09:48 +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 D7F33DAE8BE for ; Wed, 30 Mar 2011 23:09:46 +1100 (EST) To: dnsext@ietf.org From: Mark Andrews Date: Wed, 30 Mar 2011 23:09:46 +1100 Message-Id: <20110330120946.D7F33DAE8BE@drugs.dv.isc.org> Subject: Re: [dnsext] Design team report on dnssec-bis-updates and CD bit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:08:13 -0000 There is a fourth model not described. CD F/C line conditions action ================================================================== 1 F D1 Set CD=1 0 F D2 no trust anchor Set CD=0 0 F D3 trust anchor CD=0 initially, CD=1 on validation failure/RCODE=2 1 C D4 behave as D1 0 C D5 return cache -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ed.Lewis@neustar.biz Wed Mar 30 05:11:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909FD28C15F for ; Wed, 30 Mar 2011 05:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI8s82i0rVoy for ; Wed, 30 Mar 2011 05:11:09 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 0C3BB28C108 for ; Wed, 30 Mar 2011 05:11:07 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2UCCgtX075642; Wed, 30 Mar 2011 08:12:42 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.115] by Work-Laptop-2.local (PGP Universal service); Wed, 30 Mar 2011 08:12:43 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 30 Mar 2011 08:12:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D931660.1000004@isc.org> References: <8EA8D1A36B8F49 68ABE973C39CA5E0E0@local> <55128075215341BD92DCAAD00450FA85@l ocal> <3B987BF13718424BBA818C248C428E64@local> <4D931660.1000004@isc.org> Date: Wed, 30 Mar 2011 08:10:02 -0400 To: Jelte Jansen From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:11:14 -0000 At 13:39 +0200 3/30/11, Jelte Jansen wrote: >as with another example you used in a previous discussion, it would seem >you are arguing for not doing negative caching at all (i.e. if an A >record is queried, does not exist, is then added, and queried again it >would show the same behavior as when you ask for a different type and >derive data from the nsec bitmap). Taking that further, what if >something is removed between t=0 and t=5, should we also not do positive >caching? :) Caching is a pain, it complicates the work at the authority server. Without caching we wouldn't need the complicated key rollovers and such. However, caching is an integral part of the DNS protocol. Not to say we are stuck with it, it also boosts performance and lets the system achieve the stated goals of scaling, reliability, low latency. I'm not advocating the removal of caching. I'm advocating the status quo. With caching being good and bad, the optimum position is a balance. If we push it in one direction too far, pressure is put on other parts of the architecture. If changing caching improved the lot of a authority servers, I'd be for it. Change is good too, but it's not free of concerns. >IMO whether or not aggressive caching should be done or allowed, giving >different answers where one would expect the same (i.e. different NSECs >depending on the qtype, in this case) makes me slightly nauseous :p But >that is probably not much of a protocol qualification. It's going to happen. Even if we throw out the "tailored responses" issue, there's the element of time. Although the DNS protocol does not integrate time into the data model, there's the real world that does. Zones get updated and reloaded, so a cache will have to deal with inconsistent NSEC/3 bitmaps. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From marc.lampo@eurid.eu Wed Mar 30 06:16:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA1128C12F for ; Wed, 30 Mar 2011 06:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTpwwolIvFvB for ; Wed, 30 Mar 2011 06:16:10 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by core3.amsl.com (Postfix) with ESMTP id 5F0D128C108 for ; Wed, 30 Mar 2011 06:16:09 -0700 (PDT) X-ASG-Debug-ID: 1301491065-5cfc5dd60001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id KSqcwyt6hqOd7sbH; Wed, 30 Mar 2011 15:17:45 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id D245DE408C; Wed, 30 Mar 2011 15:12:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqSbE69pYX8Z; Wed, 30 Mar 2011 15:12:16 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id BF5DBE407F; Wed, 30 Mar 2011 15:12:16 +0200 (CEST) From: "Marc Lampo" To: "'Tony Finch'" , "'Mark Andrews'" References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> In-Reply-To: Date: Wed, 30 Mar 2011 15:12:16 +0200 (CEST) X-ASG-Orig-Subj: RE: [dnsext] caches, validating resolvers, CD and DO Message-ID: <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcvuzE83ld9tw24tRnuDBEGu1E+sfwAEENiw Content-Language: en-za X-Originating-IP: [172.20.5.39] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1301491065 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 13:16:11 -0000 Mark Andrews wrote: > > A validating resolver with direct access to the athoritative servers > can work around a number of operational errors by being able to > retry the query with different servers. >From the security point of view, letting "resolvers" (on end-user PC's) have access to authoritative servers is not a good idea. End-users should forward there queries to (internal ?) forwarding or caching name servers (only). Only then one can implement security on DNS traffic flows. Otherwise the firewall rule is : "any(internal)" to "any(external)" for port 53 : allow Which I'd disrecommend ... sorry. Marc Lampo From marka@isc.org Wed Mar 30 06:46:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAF03A6B59 for ; Wed, 30 Mar 2011 06:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRvasVA+Csrx for ; Wed, 30 Mar 2011 06:46:26 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id E9A963A6B57 for ; Wed, 30 Mar 2011 06:46:25 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 987AAC9432; Wed, 30 Mar 2011 13:47:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:6233:4bff:fe01:7585]) (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 642FC216C22; Wed, 30 Mar 2011 13:47:57 +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 7FEDEDAF316; Thu, 31 Mar 2011 00:47:55 +1100 (EST) To: "Marc Lampo" From: Mark Andrews References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> In-reply-to: Your message of "Wed, 30 Mar 2011 15:12:16 +0200." <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> Date: Thu, 31 Mar 2011 00:47:55 +1100 Message-Id: <20110330134755.7FEDEDAF316@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 13:46:26 -0000 In message <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu>, "Marc Lampo" write s: > > Mark Andrews wrote: > > > > A validating resolver with direct access to the athoritative servers > > can work around a number of operational errors by being able to > > retry the query with different servers. > > >From the security point of view, letting "resolvers" (on end-user PC's) > have access to authoritative servers is not a good idea. > End-users should forward there queries to (internal ?) forwarding or > caching name servers (only). > Only then one can implement security on DNS traffic flows. > Otherwise the firewall rule is : "any(internal)" to "any(external)" for > port 53 : allow > Which I'd disrecommend ... sorry. > > Marc Lampo Please go re-read the proposal. You have not understood it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ed.Lewis@neustar.biz Wed Mar 30 07:01:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985A328C177 for ; Wed, 30 Mar 2011 07:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.994 X-Spam-Level: X-Spam-Status: No, score=-101.994 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA95NEzZTeGK for ; Wed, 30 Mar 2011 07:01:09 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A3B5B28C144 for ; Wed, 30 Mar 2011 07:01:09 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2UE2iPd076967; Wed, 30 Mar 2011 10:02:44 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.115] by Work-Laptop-2.local (PGP Universal service); Wed, 30 Mar 2011 10:02:45 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 30 Mar 2011 10:02:45 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> Date: Wed, 30 Mar 2011 09:53:01 -0400 To: Mark Andrews From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 14:01:10 -0000 For those only reading the mail list (i.e., not attending the in-person meeting), can you give some context to this? I suspect this is a follow on to a meeting discussion. At 17:23 +1100 3/30/11, Mark Andrews wrote: >I don't think we have the sematics of these bits quite right >yet. In normal operations a validating resolver taking to >a cache should just set DO. This will result in DNSSEC records >being returned and in most cases these will validate. This >also permits caches to do their jobs correctly. > >When these do not validate or SERVFAIL is returned, the validating >resolver should then re-issue the query with CD set and a EDNS >option indicating which upstream servers have been tried. This >option is initially empty. The cache will then behave as a proxy >for this query (excluding the EDNS option) adding the responding >server's address to the EDNS option. If there are no more addresses >to try, SERVFAIL (new rcode?) is returned along with the EDNS option >from the query. > >If the cache is using another cache the entire query/response is >proxied. The intent is for the validating client to talk through >intermediate caches to the cache talk directly to the authoritative >servers. The EDNS option maintains a list of authoritative server >addresses for the zone that have been tried. This list is passed >back and forth between the validating resolver and the cache talking >to the authoritative server. > >Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From Ed.Lewis@neustar.biz Wed Mar 30 07:01:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685C928C17F for ; Wed, 30 Mar 2011 07:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znc5VfN9KR5r for ; Wed, 30 Mar 2011 07:01:12 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id EEFBC3A6B5B for ; Wed, 30 Mar 2011 07:01:11 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2UE2iPf076967; Wed, 30 Mar 2011 10:02:49 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.115] by Work-Laptop-2.local (PGP Universal service); Wed, 30 Mar 2011 10:02:50 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 30 Mar 2011 10:02:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110330120946.D7F33DAE8BE@drugs.dv.isc.org> References: <20110330120946.D7F33DAE8BE@drugs.dv.isc.org> Date: Wed, 30 Mar 2011 09:53:17 -0400 To: Mark Andrews From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Design team report on dnssec-bis-updates and CD bit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 14:01:13 -0000 For those only reading the mail list (i.e., not attending the in-person meeting), can you give some context to this? I suspect this is a follow on to a meeting discussion. At 23:09 +1100 3/30/11, Mark Andrews wrote: >There is a fourth model not described. > >CD F/C line conditions action >================================================================== >1 F D1 Set CD=1 >0 F D2 no trust anchor Set CD=0 >0 F D3 trust anchor CD=0 initially, > CD=1 on validation failure/RCODE=2 >1 C D4 behave as D1 >0 C D5 return cache > >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From nweaver@icsi.berkeley.edu Wed Mar 30 07:36:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA703A6936 for ; Wed, 30 Mar 2011 07:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfjOOIEi-F9I for ; Wed, 30 Mar 2011 07:36:14 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id F224A3A687D for ; Wed, 30 Mar 2011 07:36:13 -0700 (PDT) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 28FF436A00D; Wed, 30 Mar 2011 07:37:53 -0700 (PDT) References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> In-Reply-To: <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 30 Mar 2011 07:37:52 -0700 To: "Marc Lampo" X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 14:36:15 -0000 On Mar 30, 2011, at 6:12 AM, Marc Lampo wrote: >=20 > Mark Andrews wrote: >>=20 >> A validating resolver with direct access to the athoritative servers >> can work around a number of operational errors by being able to >> retry the query with different servers. >=20 > =46rom the security point of view, letting "resolvers" (on end-user = PC's) > have access to authoritative servers is not a good idea. > End-users should forward there queries to (internal ?) forwarding or > caching name servers (only). OH GOD NO! The problem is that the forwarding or caching nameservers are a security = disaster. They lie, cheat, and manipulate results with reckless = abandon. =20 Its not just NXDOMAIN wildcarding, we now have multiple ISPs which use = DNS to man-in-the-middle search properties (google, yahoo, bing), = redirecting traffic to a unknown THIRD party, for unknown reasons! Thus end systems should be prepared to bypass these cesspools at the = drop of a hat whenever necessary. The caching/forwarding architecture = in DNS has proven itself to be a security disaster, as its has proven to = be an active man in the middle on DNS but can not be a MitM on normal = traffic. Thus probably the best default policy for DNSSEC validation is: Validate on the client (sending all requests with DO and CD! Don't let = the resolver in between validate, you can't trust it anyway so why have = it waste cycles?). =20 If local validation successful, accept. If failed (For any reason, including no DNSSEC information at all [1]), = the client MUST contact the authorities directly (NOT through the = intermediary systems) and accept the results without validation [2]. This way, DNS is on the same security level as the rest of the traffic: = controllable only by a direct MitM. =20 And mandating that it still be used in cases of DNSSEC failure is a bad = idea: When DNSSEC fails, and its due to adversarial action, its that = caching/forwarding service that is most likely to be responsible. [1] The "security" policy you desire however can be maintained if the = following rule is added on client validation: IF No DNSSEC information AND Can not contact ANY authority THEN: Accept the results from the configured recursive resolver blindly,=20 Because you have no choice in the matter as your network is controlled = by a direct MitM who's blocking all DNS except through the configured = resolvers. [2] Except for things like key material or other new RRs which are not = used to determine which host to contact.= From marka@isc.org Wed Mar 30 08:21:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DB23A6B68 for ; Wed, 30 Mar 2011 08:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2noNFt4dnIj for ; Wed, 30 Mar 2011 08:21:24 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 5B8783A6A20 for ; Wed, 30 Mar 2011 08:21:23 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0B2665F9891; Wed, 30 Mar 2011 15:22:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:6233:4bff:fe01:7585]) (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 0ED5E216C33; Wed, 30 Mar 2011 15:22:44 +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 CAA97DB0215; Thu, 31 Mar 2011 02:22:41 +1100 (EST) To: Nicholas Weaver From: Mark Andrews References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> In-reply-to: Your message of "Wed, 30 Mar 2011 07:37:52 PDT." Date: Thu, 31 Mar 2011 02:22:41 +1100 Message-Id: <20110330152241.CAA97DB0215@drugs.dv.isc.org> Cc: Marc Lampo , dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:21:26 -0000 In message , Nicholas W eaver writes: > > On Mar 30, 2011, at 6:12 AM, Marc Lampo wrote: > > >=20 > > Mark Andrews wrote: > >>=20 > >> A validating resolver with direct access to the athoritative servers > >> can work around a number of operational errors by being able to > >> retry the query with different servers. > >=20 > > =46rom the security point of view, letting "resolvers" (on end-user = > PC's) > > have access to authoritative servers is not a good idea. > > End-users should forward there queries to (internal ?) forwarding or > > caching name servers (only). > > OH GOD NO! > > The problem is that the forwarding or caching nameservers are a security = > disaster. They lie, cheat, and manipulate results with reckless = > abandon. =20 And w/ dnssec you detect this. > Its not just NXDOMAIN wildcarding, we now have multiple ISPs which use = > DNS to man-in-the-middle search properties (google, yahoo, bing), = > redirecting traffic to a unknown THIRD party, for unknown reasons! And w/ dnssec you detect this. > Thus end systems should be prepared to bypass these cesspools at the = > drop of a hat whenever necessary. The caching/forwarding architecture = > in DNS has proven itself to be a security disaster, as its has proven to = > be an active man in the middle on DNS but can not be a MitM on normal = > traffic. > > > Thus probably the best default policy for DNSSEC validation is: > > Validate on the client (sending all requests with DO and CD! You don't need CD to validate. > Don't let = > the resolver in between validate, you can't trust it anyway so why have = > it waste cycles?). Because you want it to sort out when a authoritative server has stale DNSSEC data, authoritative servers that are not dnssec enabled, ..... It's much easier for the recursive server handle this directly and give the stub resolver answers that have been successfully validated. > If local validation successful, accept. > > If failed (For any reason, including no DNSSEC information at all [1]), = > the client MUST contact the authorities directly (NOT through the = > intermediary systems) and accept the results without validation [2]. That's nice when you can do it, but there are lots of enviroments where you can't. We need to make those deployment senarios work. Failures are not alway malicious. > This way, DNS is on the same security level as the rest of the traffic: = > controllable only by a direct MitM. =20 > > And mandating that it still be used in cases of DNSSEC failure is a bad = > idea: When DNSSEC fails, and its due to adversarial action, its that = > caching/forwarding service that is most likely to be responsible. > [1] The "security" policy you desire however can be maintained if the = > following rule is added on client validation: > > IF No DNSSEC information AND Can not contact ANY authority > THEN: > Accept the results from the configured recursive resolver blindly,=20 > > Because you have no choice in the matter as your network is controlled = > by a direct MitM who's blocking all DNS except through the configured = > resolvers. > > > [2] Except for things like key material or other new RRs which are not = > used to determine which host to contact.= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marc.lampo@eurid.eu Wed Mar 30 08:27:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD2C3A69C0 for ; Wed, 30 Mar 2011 08:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZda8TZgyb1J for ; Wed, 30 Mar 2011 08:27:10 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by core3.amsl.com (Postfix) with ESMTP id DF1943A68B8 for ; Wed, 30 Mar 2011 08:27:09 -0700 (PDT) X-ASG-Debug-ID: 1301498928-5cfb5edf0001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id hx1FM1t9m0GqkG79; Wed, 30 Mar 2011 17:28:48 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 3CA7BE4059; Wed, 30 Mar 2011 17:23:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vUQb9iE-Jsv; Wed, 30 Mar 2011 17:23:19 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 273CEE4050; Wed, 30 Mar 2011 17:23:19 +0200 (CEST) From: "Marc Lampo" To: "'Mark Andrews'" , "'Nicholas Weaver'" References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> <20110330152241.CAA97DB0215@drugs.dv.isc.org> In-Reply-To: <20110330152241.CAA97DB0215@drugs.dv.isc.org> Date: Wed, 30 Mar 2011 17:23:19 +0200 (CEST) X-ASG-Orig-Subj: RE: [dnsext] caches, validating resolvers, CD and DO Message-ID: <009d01cbeeef$37c394b0$a74abe10$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Acvu7aouU3J9ZmlyTwy4QXye5P0OmQAAQeQg Content-Language: en-za X-Originating-IP: [172.20.5.39] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1301498928 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:27:10 -0000 -----Original Message----- From: Mark Andrews [mailto:marka@isc.org] Sent: 30 March 2011 05:23 PM To: Nicholas Weaver Cc: Marc Lampo; 'Tony Finch'; dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO ... > That's nice when you can do it, but there are lots of enviroments > where you can't. We need to make those deployment senarios work. > Failures are not alway malicious. Most (if not : all) (DNSSEC validation) failures I have seen myself, up till now, were indeed *not* malicious. They were because of failing management on the authoritative NS side ... This being said : contacting them directly would simply yield the same validation error. Marc From ogud@ogud.com Wed Mar 30 08:55:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5424F3A6B81 for ; Wed, 30 Mar 2011 08:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3H0Xngv1lA7 for ; Wed, 30 Mar 2011 08:55:06 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 52AAE3A6B72 for ; Wed, 30 Mar 2011 08:55:06 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2UFuiCE078070 for ; Wed, 30 Mar 2011 11:56:44 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4D9352BA.4000208@ogud.com> Date: Wed, 30 Mar 2011 11:56:42 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110330120946.D7F33DAE8BE@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] Design team report on dnssec-bis-updates and CD bit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:55:07 -0000 See this thread from last year: http://www.ietf.org/mail-archive/web/dnsext/current/msg08864.html Olafur On 30/03/2011 9:53 AM, Edward Lewis wrote: > For those only reading the mail list (i.e., not attending the in-person > meeting), can you give some context to this? I suspect this is a follow > on to a meeting discussion. > > At 23:09 +1100 3/30/11, Mark Andrews wrote: >> There is a fourth model not described. >> >> CD F/C line conditions action >> ================================================================== >> 1 F D1 Set CD=1 >> 0 F D2 no trust anchor Set CD=0 >> 0 F D3 trust anchor CD=0 initially, >> CD=1 on validation failure/RCODE=2 >> 1 C D4 behave as D1 >> 0 C D5 return cache >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > As I failed in my task to bring up the archiv From Internet-Drafts@ietf.org Wed Mar 30 09:00:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E04F3A6B01; Wed, 30 Mar 2011 09:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWYw52w2WaY8; Wed, 30 Mar 2011 09:00:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5883A6A48; Wed, 30 Mar 2011 09:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110330160001.11866.49970.idtracker@localhost> Date: Wed, 30 Mar 2011 09:00:01 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-algo-signal-01.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Signaling Cryptographic Algorithm Understanding in DNSSEC Author(s) : S. Crocker, S. Rose Filename : draft-ietf-dnsext-dnssec-algo-signal-01.txt Pages : 8 Date : 2011-03-30 The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-algo-signal-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-30085352.I-D@ietf.org> --NextPart-- From scott.rose@nist.gov Wed Mar 30 09:05:53 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF22D3A6A48 for ; Wed, 30 Mar 2011 09:05:53 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLldXdDCqjDy for ; Wed, 30 Mar 2011 09:05:51 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 0F0373A6AA0 for ; Wed, 30 Mar 2011 09:05:50 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p2UG7Kqm019443 for ; Wed, 30 Mar 2011 12:07:20 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 30 Mar 2011 12:07:20 -0400 From: "Rose, Scott W." To: "dnsext@ietf.org" Date: Wed, 30 Mar 2011 12:07:20 -0400 Thread-Topic: New version of algo-signal draft posted Thread-Index: Acvu9HEt8Eav9W43Q4ylYLVnPDmYzQ== Message-ID: <71345070-0575-40E5-BC99-865A6791D5AD@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Subject: [dnsext] New version of algo-signal draft posted X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 16:05:53 -0000 The -01 version of the algo-signal draft was just submitted and will be posted soon. This was first to prevent it expiring and to address comments from the -00 draft. Including, but not limited to: - The option is no DAU (DNSSEC Algorithm Understood) - updates to how validating recursive resolvers should interpret the DAU option - spelling/grammer corrections Comments and corrections welcome. We realize this probably isn't complete as it is now. Scott =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From brian.peter.dickson@gmail.com Wed Mar 30 09:19:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9E03A6B8F for ; Wed, 30 Mar 2011 09:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWGPaPFrQhHI for ; Wed, 30 Mar 2011 09:19:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 14ECC3A6B8B for ; Wed, 30 Mar 2011 09:19:30 -0700 (PDT) Received: by fxm15 with SMTP id 15so1318649fxm.31 for ; Wed, 30 Mar 2011 09:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GXM1piMtopdnpRs2I8cf+GXo9n6D43IfPP+JYue3gmw=; b=LTcPQgPIddhuEJHywssCk7cwlqkj5gvULgBg8Ol2TRZP2C4D4rkIkG0KNytEzJduAp mA34hmSASJbZ0YCpNBIqn98iCteh/T33833cYpfO0m34xYI+TcTlIIvXc/khIrEEI45G n14O+KYYel1LW1uMFiFjnllQb8oO2OY26k2wg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=F0rFAV492+o+/bf0ODku5K8iH6u7PeE2JhR0tOkvxnQp1GAoUjPeR6czXjt7rePB3u 145tGY4ENWYOnsRx+vZzDQ+1Aw5fBGJ5gXkjM6zeo++/eVEkFQY0QkxrWA1bIRna07jV sXqr9/tIf4V2MZ6v99+kMXgRHubLGXQY0FRkI= MIME-Version: 1.0 Received: by 10.223.9.137 with SMTP id l9mr1528304fal.25.1301502069504; Wed, 30 Mar 2011 09:21:09 -0700 (PDT) Received: by 10.223.126.6 with HTTP; Wed, 30 Mar 2011 09:21:09 -0700 (PDT) In-Reply-To: References: <3B987BF13718424BBA818C248C428E64@local> <4D931660.1000004@isc.org> Date: Wed, 30 Mar 2011 12:21:09 -0400 Message-ID: From: Brian Dickson To: Edward Lewis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 16:19:32 -0000 On Wed, Mar 30, 2011 at 8:10 AM, Edward Lewis wrote: > It's going to happen. =A0Even if we throw out the "tailored responses" is= sue, > there's the element of time. =A0Although the DNS protocol does not integr= ate > time into the data model, there's the real world that does. =A0Zones get > updated and reloaded, so a cache will have to deal with inconsistent NSEC= /3 > bitmaps. It might be worth discussing how caches could/should handle NSEC/3 responses when time and/or bitmaps change. The idea is, to find a happy balance between caching NSEC/3 responses, associating those with bitmap bits, and limiting cache bloat. When a cache has no entry for a given tuple (name, class, type), obviously it has to then query the auth server. If it gets an answer where the name exists but type doesn't, it should get an NSEC/3 record as well. The cache should only return that cached NSEC/3 when it sees queries that match already-answered (by the auth server) queries, and new types should result in new queries to the auth server. The questions that arise are: - What if the same NSEC/3 answer is returned for the new type? - What if a different NSEC/3 answer is returned, but which is consistent with previous NSEC/3 answer(s) already cached for other types? - What if a different NSEC/3 answer is returned, but which is not consistent with previous NSEC/3 answer(s) already cached for other type(s)? My suspicion is that: - It would be reasonable to keep a bitmap of queries/answers for which a given NSEC/3 has been returned. E.g. If the NSEC/3 has bits clear on, for example, SOA and NS, and has been returned along with empty data on queries for SOA and NS for a given name and class, then it would be reasonable to associate the same NSEC/3 with those types, and return it for subsequent queries for those tuples. - It would be reasonable to replace older NSEC/3 answers with newer NSEC/3 answers, if the type associations (of previous queries/answers that generated the cached entry) and bitmap of the newer NSEC/3 were consistent (and thus also implicitly consistent with the bitmap of the older NSEC/3) - It would be necessary to retain multiple NSEC/3 answers if there were inconsistencies between types and bitmaps across those answers The benefit is, even if the time changes, if the bitmap doesn't change, or doesn't change in a manner that is inconsistent, that the number of NSEC/3 records doesn't have to increase, even if additional queries to the auth server are needed because the particular type's NSEC/3 hasn't been cached (or associated with the cached entry yet). A secondary benefit is that a rolling window of TTLs resulting in refreshing of NSEC/3's rather than expiry of NSEC/3's, can have some beneficial effect on the auth server(s) without introducing inconsistencies. A newer NSEC/3 (with newer signature) essentially restarts the TTL clock when it replaces the older NSEC/3. Or, the cache could decide to re-query candidate NSEC/3 records for the types with the older NSEC/3 entries, and only if the new NSEC/3 is returned, do the replacement. It is a time/space/bandwidth trade-off. Brian From nweaver@ICSI.Berkeley.EDU Wed Mar 30 11:16:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB033A6BB2 for ; Wed, 30 Mar 2011 11:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nquXK8GPh8C1 for ; Wed, 30 Mar 2011 11:16:35 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 41E8F3A6BAB for ; Wed, 30 Mar 2011 11:16:35 -0700 (PDT) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 43F0136A032; Wed, 30 Mar 2011 11:18:14 -0700 (PDT) References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> <20110330152241.CAA97DB0215@drugs.dv.isc.org> In-Reply-To: <20110330152241.CAA97DB0215@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 30 Mar 2011 11:18:13 -0700 To: Mark Andrews X-Mailer: Apple Mail (2.1084) Cc: Marc Lampo , Nicholas Weaver , dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 18:16:37 -0000 On Mar 30, 2011, at 8:22 AM, Mark Andrews wrote: >> OH GOD NO! >>=20 >> The problem is that the forwarding or caching nameservers are a = security =3D >> disaster. They lie, cheat, and manipulate results with reckless =3D >> abandon. =3D20 >=20 > And w/ dnssec you detect this. Until they strip DNSSEC information. You MUST validate locally.... >> Thus probably the best default policy for DNSSEC validation is: >>=20 >> Validate on the client (sending all requests with DO and CD! >=20 > You don't need CD to validate. >=20 >> Don't let =3D >> the resolver in between validate, you can't trust it anyway so why = have =3D >> it waste cycles?).=20 >=20 > Because you want it to sort out when a authoritative server has stale > DNSSEC data, authoritative servers that are not dnssec enabled, ..... > It's much easier for the recursive server handle this directly and > give the stub resolver answers that have been successfully validated. You want the end client to have its own policy on what to do on DNSSEC = failure, not be dependent on the resolver's policy, and thus validating = clients really should use CD with every request. EG, I'd WANT clients to be able to visit www.dnssec-failed.org IFF the = client is able to contact the root, .org, and Comcast's DNS servers = directly. That way, the client knows that it can trust the DNS information to = exactly the same degree that it can trust the rest of its network = traffic. >> If local validation successful, accept. >>=20 >> If failed (For any reason, including no DNSSEC information at all = [1]), =3D >> the client MUST contact the authorities directly (NOT through the =3D >> intermediary systems) and accept the results without validation [2]. >=20 > That's nice when you can do it, but there are lots of enviroments > where you can't. We need to make those deployment senarios work. > Failures are not alway malicious. You notice that the proposed policy ONLY causes a failure IFF: a) There is an actual DNSSEC failure-to-validate (not simply "no = DNSSEC"). =20 AND b) The client is prohibited from contacting authoritative DNS servers = directly. From matthijs@nlnetlabs.nl Wed Mar 30 13:02:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4953E28C0DE for ; Wed, 30 Mar 2011 13:02:44 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJgZ5J0J4YPu for ; Wed, 30 Mar 2011 13:02:43 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 223913A6BBE for ; Wed, 30 Mar 2011 13:02:41 -0700 (PDT) Received: from [IPv6:2001:df8:0:64:215:afff:fed2:e121] ([IPv6:2001:df8:0:64:215:afff:fed2:e121]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p2UK4JRx088067; Wed, 30 Mar 2011 22:04:19 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4D938CC3.1020103@nlnetlabs.nl> Date: Wed, 30 Mar 2011 22:04:19 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Edward Lewis References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Wed, 30 Mar 2011 22:04:20 +0200 (CEST) Cc: dnsext@ietf.org Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:02:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, so let's try to come to a reasonable clarifying text: - ------------------------------------------------------------------------- Section ?.? Clarifying the validators interpretation regarding multiple algorithms. RFC 4035, section 2.2 talks about Zone Signing. It mentions that "There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset". This is a requirement at the server side, not the client side. In other words, when a validating resolvers is in the process of validating a RRset, it SHOULD NOT expect a RRSIG of each algorithm that is in the zone apex DNSKEY RRset. - ------------------------------------------------------------------------- This only fixes the misinterpretation on the expectation a validator may have. It does not deal with algorithm downgrade protection at all (as some may believe does not exist in DNSSEC). If there is need for clarifying algorithm downgrade protection, or its non-existence, I suggest something in the line of: - ------------------------------------------------------------------------- Section ?.? Algorithm downgrade protection. The validator could check that there are RRSIG records for each RRset using at least one DNSKEY of each algorithm in the DS RRset, published in the parent zone. This *** *** Choice here - - is however NOT RECOMMENDED. ['the one signature is enough approach'] - - is OPTIONAL. ['leave the choice to the implementation' approach] - - is RECOMMENDED behavior. ['algorithm downgrade protection' apprpach] - ------------------------------------------------------------------------- Best regards, Matthijs On 03/18/2011 06:07 PM, Edward Lewis wrote: > I should add...just because "there's supposed to be X" doesn't mean X > has to be there. If I'm looking for X and it's not there, we have a > failure. If I'm not looking for X and it is not there, "no harm, no > foul." (The latter is the same as not needing X and it's there anyway.) > > At 12:59 -0400 3/18/11, Edward Lewis wrote: >> At 9:36 -0700 3/18/11, Casey Deccio wrote: >> >> >>> Okay, so the signer sets the expectation of the validator using the >>> algorithms in the DS RRset. Now, does this expectation hold for >>> simply authenticating the DNSKEY RRset or for all zone data? >> >> No, the specification sets expectations. I don't mean to be a pain, >> but the first words say this: "The reason for the specification is to >> set the expectation." I mean that in the strictest sense. The >> validator knows there's supposed to be X because the spec says so. >> >>> For example: >>> >>> - DS RRset has only algorithm 5 >>> - DNSKEY RRset signed by a DNSKEY matching the DS (alg 5) >>> - DNSKEY RRset contains DNSKEYs with algs 5 and 3 >>> - DNSKEY with alg 3 signs A RRset. >>> >>> Is there a valid chain to the A RRset, or is it a protocol failure? >> >> Depends. If the validator knows both 3 and 5, then it can build a >> chain and it's cool. If the validator only knows 5, then there's a >> missing piece. If the validator only knows 3, there's no chain to the >> data. >> >> In summary: >> Validator knows 3 & 5 - validates >> Validator knows only 3 - data is accepted as not-signed. >> Validator knows only 5 - service failure as *expected* signature is >> not found* >> Validator doesn't to 3 & 5 - accepted as not-signed >> Validator doesn't do DNSSEC - accepted as not-signed >> >> *not found = not obtainable, can't get it, ... >> >>> Following the principle of "if one chain works, it succeeds", I would >>> say >>> that it is valid. But it's unclear whether this is part of the >>> expectation >>> of the signer for the validator, and even the paragraph quoted above >>> seems >>> to declare it a protocol failure--although I well understand your >>> position >>> on principle. Whether it is valid or not, I believe it should be >>> worded explicitly to avoid ambiguity and accurately convey principle. >> >> It is always up to the validator to decide if it accepts the data. >> Local policy and DNSSEC is about protecting the cache. DNSSEC is NOT >> designed to enforce proper operations, it is NOT to force the zone >> admin into doing anything. Remember, DNSSEC is optional to the >> protocol, it's the validators that want to pull the data for protection. >> >> -- >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> >> Edward Lewis >> NeuStar You can leave a voice message at >> +1-571-434-5468 >> >> Me to infant son: "Waah! Waah! Is that all you can say? Waah?" >> Son: "Waah!" >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNk4zDAAoJEA8yVCPsQCW502MH/0unZXAo8KqLpwDrXbBBaGps 5rm7eA6rgipU1y99QOMZOggzu5XsI3VVZq8LiTIzKgBB69iufN392v/4afWiEgcW LGdETtYwQmaif+Rj7+3UhjbSFJj7h2yPUlDvFoT66YOr7HaV+Ow9niYSnTbxmZgV L/AWNjdpMsfmFoxk9OfJZlYnfgPA2gK4UyUG5YduwybeW1REcqyoQ3V73HnkhZod SZ5QDHp/mRj4JjlACwSPSg5cQO1hURfp4r43oad0mO2Y1p2cjknp/cF9kcgI2VQu bBSQ+0oEz55N/8yqzKznfY9tsUWwfsnBmjkMyA8mKD9BuzstScCvXs71K1Dz3SM= =vrOn -----END PGP SIGNATURE----- From Ed.Lewis@neustar.biz Wed Mar 30 13:25:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A803228C0DE for ; Wed, 30 Mar 2011 13:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GVVtx3EUvGi for ; Wed, 30 Mar 2011 13:25:41 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 740E53A69AB for ; Wed, 30 Mar 2011 13:25:41 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2UKRGU8080129; Wed, 30 Mar 2011 16:27:16 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.115] by Work-Laptop-2.local (PGP Universal service); Wed, 30 Mar 2011 16:27:16 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 30 Mar 2011 16:27:16 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <82vcz0n7a4.fsf@mid.bfk.de> References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> <95465.1301414968@nsa.vix.com> <82vcz0n7a4.fsf@mid.bfk.de> Date: Wed, 30 Mar 2011 16:27:14 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:25:42 -0000 At 12:04 +0000 3/30/11, Florian Weimer wrote: >> >> http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 > >I was referring to section 3. I think it is misleading and would lead >to poorer service from resolvers if implemented. Florian, thanks for the pointer. I really had lost track of the thread. In section 3, it mentions an ambiguity in RFC 1034. Question: what ambiguity (there are a lot of them), like what section or page. I'm asking out of curiosity. Still, the point of section 3 is right. If there were no bad code out there and if the data never changed then I'd say it is good. But there is bad code out there. Dan Bernstein's statement (as found in [0]) that returning NXDOMAIN for empty non-terminals is acceptable because buggy code did this in the past is an interesting point. While technically wrong to do so, this code is out there and to accommodate (work around the bug), optimizing according what is in section 3 would be sub-optimal. I would never say that NXDOMAIN for empty non-terminals is correct as a protocol analyst. But if I was dealing with buggy code, I'd play the "be liberal in what you accept" card. Secondly, because of the fact that things change, it might be wrong for a cache to synthesize, based on a cached NXDOMAIN what may now be in a subdomain of the zone authoritative for the NXDOMAIN. To me, this is a secondary concern because we've long recognized that the DNS protocol is pretty much agnostic about time. It is true that RFC's in the past have said an NXDOMAIN can be used by caches to declare data of any type at a name as non-existing - but this pertains to the same name, not descendents. So, while I think in theory section 3 is correct, in practice it seems to be an over-optimization given an imperfect world. [0] - http://www.ietf.org/mail-archive/web/dnsext/current/msg11084.html (I don't see a message "directly" from him, just this forward. In case the forward was a forgery my point is directed at the real source of the comment, not Dan Bernstein.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From vixie@isc.org Wed Mar 30 15:46:49 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAACC3A6B70 for ; Wed, 30 Mar 2011 15:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J1i1d96l7oq for ; Wed, 30 Mar 2011 15:46:49 -0700 (PDT) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id F08513A6B28 for ; Wed, 30 Mar 2011 15:46:48 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 234B8A1037 for ; Wed, 30 Mar 2011 22:48:25 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Wed, 30 Mar 2011 16:27:14 -0400." References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> <95465.1301414968@nsa.vix.com> <82vcz0n7a4.fsf@mid.bfk.de> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Wed, 30 Mar 2011 22:48:25 +0000 Message-ID: <1330.1301525305@nsa.vix.com> Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 22:46:50 -0000 > Date: Wed, 30 Mar 2011 16:27:14 -0400 > From: Edward Lewis > ... > Dan Bernstein's statement (as found in [0]) that returning NXDOMAIN for > empty non-terminals is acceptable because buggy code did this in the past > is an interesting point. While technically wrong to do so, this code is > out there and to accommodate (work around the bug), optimizing according > what is in section 3 would be sub-optimal. I would never say that NXDOMAIN > for empty non-terminals is correct as a protocol analyst. But if I was > dealing with buggy code, I'd play the "be liberal in what you accept" card. when the buggy code was bind4 and we had a 100% market share and the bug was that all axfr's coming toward us had to have one rr per header, we did not ask for a spec change, we declared the code bad and fixed it. if we don't want to do that with rbldnsd given its 0.00005% market share and that really is the consensus of the working group, we can remove the text. i'd like to hear from different voices to help judge consensus. From dougb@dougbarton.us Wed Mar 30 16:30:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433263A69AE for ; Wed, 30 Mar 2011 16:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWqfwIIFkTrh for ; Wed, 30 Mar 2011 16:30:58 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id E52A63A6B70 for ; Wed, 30 Mar 2011 16:30:57 -0700 (PDT) Received: (qmail 10887 invoked by uid 399); 30 Mar 2011 23:32:31 -0000 Received: from unknown (HELO ?65.241.43.5?) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 30 Mar 2011 23:32:31 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4D93BD8D.9040009@dougbarton.us> Date: Wed, 30 Mar 2011 16:32:29 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Tony Finch References: <8239m6z1x9.fsf@mid.bfk.de> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Some thoughts on the updated aliasing draft X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 23:30:59 -0000 If I may do so without seeming immodest, I believe that the CLONE draft adequately addresses all of the concerns raised in this thread so far. I haven't had any feedback on the -01 version yet, so hopefully this is an opportune time for a gentle prod (because I know that those of you in Prague don't have enough to do already). :) Doug http://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit-01 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From colm@allcosts.net Wed Mar 30 19:23:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFDF3A6874 for ; Wed, 30 Mar 2011 19:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZhenofoMdUb for ; Wed, 30 Mar 2011 19:23:50 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6E5213A6BF1 for ; Wed, 30 Mar 2011 19:23:49 -0700 (PDT) Received: by fxm15 with SMTP id 15so1678474fxm.31 for ; Wed, 30 Mar 2011 19:25:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.64.201 with SMTP id f9mr2145044fai.102.1301538328710; Wed, 30 Mar 2011 19:25:28 -0700 (PDT) Received: by 10.223.96.8 with HTTP; Wed, 30 Mar 2011 19:25:28 -0700 (PDT) In-Reply-To: <1330.1301525305@nsa.vix.com> References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> <95465.1301414968@nsa.vix.com> <82vcz0n7a4.fsf@mid.bfk.de> <1330.1301525305@nsa.vix.com> Date: Wed, 30 Mar 2011 19:25:28 -0700 Message-ID: From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Paul Vixie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 02:23:52 -0000 On Wed, Mar 30, 2011 at 3:48 PM, Paul Vixie wrote: > if we don't want to do that with rbldnsd given its 0.00005% market share > and that really is the consensus of the working group, we can remove the > text. =A0i'd like to hear from different voices to help judge consensus. The behavior isn't limited to rbldnsd. It is also manifest in TinyDNS, and probably other non-tree-indexed implementations. These implementations may not have a plurality of domain names on them, but I think they do meet the "widely deployed" bar. Given that, it seems imprudent for resolvers to make inferences about empty sub-trees based merely on NXDOMAIN. At least one EDNS0 capable implementation exists that exhibits this behavior [1] . So for the moment, making inferences on EDNS0 also seems unwise. Making inferences based on returning DNSSEC data may be safe, I haven't yet found any counter-examples. I wouldn't be surprised to find one though. My vote would be for; Recommending that authoritative servers implementing DNSSEC SHOULD NOT return NXDOMAIN for non-terminal labels. Recommending that caches SHOULD NOT infer empty sub-trees based on NXDOMA= IN. My reason for saying "implementing DNSSEC" is that inferring sub-tree emptiness is another dangerous poisoning case (along with spoofed DNAME and NS responses) that can poison a very large name-space in a cache for very low effort. DNSSEC is a reasonable mitigation against that problem. On the historical point, I don't agree with djb's interpretation of RFC2308. That RFC says; "A negative answer that resulted from a name error (NXDOMAIN) should be cached such that it can be retrieved and returned in response to another query for the same that resulted in the cached negative response." It doesn't say "only returned". To say that inferences about empty sub-tree= s is "outlawed" goes too far. But I think there's so little clarity in the standards, that no particular "side" has great support there. Greater clarity from now on will definitely help! [1] dig +edns=3D0 terminal-label.non-terminal.notesfromthesound.com @ns-431.awsdns-53.com dig +edns=3D0 non-terminal.notesfromthesound.com @ns-431.awsdns-53.c= om --=20 Colm From mail@sabahattin-gucukoglu.com Thu Mar 31 03:51:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CA828C11D for ; Thu, 31 Mar 2011 03:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.962 X-Spam-Level: X-Spam-Status: No, score=0.962 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HOST_MISMATCH_COM=0.311, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfB85oxQEBni for ; Thu, 31 Mar 2011 03:51:33 -0700 (PDT) Received: from Mintaka.sabahattin-gucukoglu.com (sgucukoglu-2-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:7ef::2]) by core3.amsl.com (Postfix) with ESMTP id 3E46328C113 for ; Thu, 31 Mar 2011 03:51:32 -0700 (PDT) Received: from Mintaka.sabahattin-gucukoglu.com ([::ffff:127.0.0.1]:60172) by Mintaka.sabahattin-gucukoglu.com with [XMail 1.27 ESMTP Server] id for from ; Thu, 31 Mar 2011 11:53:10 +0100 Received: from [192.168.1.13] (cpc2-dals7-0-0-cust570.hari.cable.virginmedia.com [82.35.114.59]) (using SMTP over TLS) by Mintaka.sabahattin-gucukoglu.com (tmda-ofmipd) with ESMTP; Thu, 31 Mar 2011 11:53:08 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) In-Reply-To: Date: Thu, 31 Mar 2011 11:53:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <271F1E6D-202D-4BD8-9436-31BC217AA830@sabahattin-gucukoglu.com> References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> <95465.1301414968@nsa.vix.com> <82vcz0n7a4.fsf@mid.bfk.de> To: dnsext@ietf.org X-Mailer: Apple Mail (2.1084) X-Delivery-Agent: TMDA/1.1.12-kg2 (Pluto) From: Sabahattin Gucukoglu X-Primary-Address: mail@sabahattin-gucukoglu.com Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Sabahattin Gucukoglu List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 10:51:34 -0000 On 30 Mar 2011, at 21:27, Edward Lewis wrote: > Dan Bernstein's statement (as found in [0]) that returning NXDOMAIN = for empty non-terminals is acceptable because buggy code did this in the = past is an interesting point. While technically wrong to do so, this = code is out there and to accommodate (work around the bug), optimizing = according what is in section 3 would be sub-optimal. I would never say = that NXDOMAIN for empty non-terminals is correct as a protocol analyst. = But if I was dealing with buggy code, I'd play the "be liberal in what = you accept" card. I have to admit, I can't even understand the question, and after so much = discussion I'm starting to feel that I never will. I could not imagine = any other behaviour than the one manifest in pretty much every DNS = server I can get my hands on (BIND 9, Tinydns, MaraDNS, NSD, ...) and = could not see how it would even make sense or be possible to implement = the suggestion to return 0 records for non-terminal labels. What would = the authority for such a query name be? You could hardly synthesise = one, and using the SOA from the next highest delegation doesn't work, = unless you also don't mind making the case of no data at query name = exclusively indistinct from no data at query name except for the = possibility of terminating labels. How could you distinguish components = of query names which are naturally entered and used with dots in their = textual representations, without providing misleading responses to = questions about the right-hand sides of such names? And doesn't it = follow that a non-terminal name isn't a name, so that it doesn't exist, = rather than that it does only because it happens to use more than the = usual number of labels between delegations? And then there's all the existing points raised about the feasibility of = *trusting* NXDOMAIN responses, based on the idea that the authoritative = servers will distinguish terminals from non-terminals in this way, which = as has been discussed before is problematic for a number of good, solid = reasons (RBLs, increased work for caches with non-tree structures, etc). If somebody could help me to understand which bit of RFC 1034-5 or = succeeding documents says (or even hints at) the fallibility of = multi-label names, I'd be especially interested, since so far I haven't = been able to do it. It would help me decide that much more firmly one = way or the other; for now, I don't like the suggestion. Maybe it's all = about semantics, but I like things the way they are (in this regard). = It's clearer and, for me, more logical and sensible, with no added = gotchas. Cheers, Sabahattin PS: Dan did in fact post that referenced message to his = dns@list.cr.yp.to list. I use tinydns, primarily, but am thinking about = shuffling along to NSD. From Ed.Lewis@neustar.biz Thu Mar 31 04:57:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445E428C14F for ; Thu, 31 Mar 2011 04:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t5HFScOyOhv for ; Thu, 31 Mar 2011 04:57:12 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 35F4B3A6B33 for ; Thu, 31 Mar 2011 04:57:11 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2VBwnUj086616; Thu, 31 Mar 2011 07:58:49 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.112] by Work-Laptop-2.local (PGP Universal service); Thu, 31 Mar 2011 07:58:51 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 31 Mar 2011 07:58:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <271F1E6D-202D-4BD8-9436-31BC217AA830@sabahattin-gucukoglu.com> References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> <95465.1301414968@nsa.vix.com> <82vcz0n7a4.fsf@mid.bfk.de> <271F1E6D-202D-4BD8-9436-31BC217AA830@sabahattin-gucukoglu.com> Date: Thu, 31 Mar 2011 07:58:47 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:57:13 -0000 At 11:53 +0100 3/31/11, Sabahattin Gucukoglu wrote: >If somebody could help me to understand which bit of RFC 1034-5 or succeeding >documents says (or even hints at) the fallibility of multi-label names, I'd be >especially interested, since so far I haven't been able to do it. It would >help me decide that much more firmly one way or the other; for now, I don't >like the suggestion. Maybe it's all about semantics, but I like things the >way they are (in this regard). It's clearer and, for me, more logical and >sensible, with no added gotchas. Try reading RFC 4592. It has a definition of what constitutes "existence." I can see how all this is confusing and absurd. It's all very Seinfeldian [0]. It's true, what does it matter you get in a response if there's no data to be had? Nothing is nothing. But the reason folks are so passionate about NXDOMAIN vs. NoError/0 anwer records is that other parts of the protocol are impacted. The definition of the wildcard mechanism for one (that's what RFC 4592 refers to). And the inference of caches on what exists is another (RFC 2308 & RFC 4304/5). [0] From http://en.wikipedia.org/wiki/Seinfeld: "The show, often described as being about "nothing"..." >PS: Dan did in fact post that referenced message to his dns@list.cr.yp.to >list. I use tinydns, primarily, but am thinking about shuffling along to NSD. Ahh, thanks. I am not on that list. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From derek@ihtfp.com Thu Mar 31 06:55:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A7E3A6B0E for ; Thu, 31 Mar 2011 06:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.388 X-Spam-Level: X-Spam-Status: No, score=-101.388 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIb7wxvNjH1e for ; Thu, 31 Mar 2011 06:55:15 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by core3.amsl.com (Postfix) with ESMTP id 8DA5A28C16A for ; Thu, 31 Mar 2011 06:55:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 382122602C3; Thu, 31 Mar 2011 09:56:51 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06630-07; Thu, 31 Mar 2011 09:56:47 -0400 (EDT) Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 08E8B260024; Thu, 31 Mar 2011 09:56:47 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id p2VDuhbt024049; Thu, 31 Mar 2011 09:56:43 -0400 From: Derek Atkins To: Nicholas Weaver References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local> <46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> <20110330152241.CAA97DB0215@drugs.dv.isc.org> Date: Thu, 31 Mar 2011 09:56:43 -0400 In-Reply-To: (Nicholas Weaver's message of "Wed, 30 Mar 2011 11:18:13 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: Marc Lampo , dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:55:15 -0000 Nicholas Weaver writes: > On Mar 30, 2011, at 8:22 AM, Mark Andrews wrote: >>> OH GOD NO! >>> >>> The problem is that the forwarding or caching nameservers are a security = >>> disaster. They lie, cheat, and manipulate results with reckless = >>> abandon. =20 >> >> And w/ dnssec you detect this. > > Until they strip DNSSEC information. You MUST validate locally.... I disagree. I run a local network in my house and run local caching recursive resolvers. I have all my hosts on my network resolve through my local caches. I run all my machines, therefore I trust my cache. I see no reason to *require* all my machines to bypass the local cache. Moreover, in my case I see no reason to require all my machines to perform local validation. I trust myself. Therefore, calling it a MUST is wrong. > You want the end client to have its own policy on what to do on DNSSEC > failure, not be dependent on the resolver's policy, and thus > validating clients really should use CD with every request. I agree in principle, however that policy can also be "trust the caching recursive resolver." Saying that the client MUST validate does not allow for this trusting policy. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From ogud@ogud.com Thu Mar 31 07:00:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953D73A6C11 for ; Thu, 31 Mar 2011 07:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb18F-NhdQZT for ; Thu, 31 Mar 2011 07:00:03 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id EF7D728C0F7 for ; Thu, 31 Mar 2011 07:00:02 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2VE1ecN087667 for ; Thu, 31 Mar 2011 10:01:41 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4D948943.8010906@ogud.com> Date: Thu, 31 Mar 2011 10:01:39 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: multipart/mixed; boundary="------------060508050701020205010503" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dnsext] Draft minutes from IETF-80 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:00:04 -0000 This is a multi-part message in MIME format. --------------060508050701020205010503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks to Paul Hoffman for doing the minutes and submitting them in almost real time. All mistakes and errors are mine, Attached are the draft minutes. Current minutes are available at http://www.ietf.org/proceedings/80/minutes/dnsext.txt (will update if there are suggestions for improvements, or fixing mistakes) . If there is no feedback on minutes by April 10'th we will make them final. Olafur --------------060508050701020205010503 Content-Type: text/plain; name="DNSEXT-80-minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="DNSEXT-80-minutes.txt" Draft Minutes: 2011-03-31 15:57 DNSEXT WG Monday afternoon, 2011-03-28 Chairs: Andrew Sullivan and Olafur Gudmundsson Minutes taken by Paul Hoffman Start: 15:21 Summary since last meeting was sent to the mailing list Action Items: from meeting: work hard on "finish" Aliased Names Requirements, soon. ask for WG to adopt Resimprove Discussions: Problem Statement: DNS Resolution of Aliased Names http://tools.ietf.org/html/draft-ietf-dnsext-aliasing-requirements-01 slides: http://tools.ietf.org/agenda/80/slides/dnsext-1.pdf Presenter: Suzanne Woolf The requirements list is not lengthy, but we have to be sure that they are the right ones Andrew: ICANN had a meeting two weeks ago Goal was to increase communication between the policy folks and the "technical geeks over there" Both sides understand that there are open policy and technical issues The meeting was "not unsuccessful" Big news from the meeting: ICANN is seriously persuing their policy for IDN variants We should have potential input to what they will do We should ready for last call; is there pretty good consensus "Does this sound like a reasonable set of limitations?" Then we put it on the back burner while the ICANN style of working goes on Phill Hallam-Baker: There are ways to deploy things quickly Could add web redirects with interstitials People will do this anyway even if we don't want it Will cause middleboxes to make decisions to kill you Think about the interstitials when you design the long-term solution Suzanne: The "long term to deploy" is not about deployment but protocol development Ted Hardie: Mailing list discussion converging on how to know what the canonicalized form would be Has a niggling fear: what they get out of their provisioning is that all are the same Not getting the canonical version from it Worry is that we will asked to give a presentation layer for the entire Internet Might have variants point to a meta-record, and none of the variants are any more important than the other Peter Koch: Is it acceptable to have an aliasing method? Suzanne: Did people want equivalence or just a correspondence? Should we be exposing to applications that there is a canonical version? If the requirement exists for strict equivalent in a real-world use case, we haven't seen it yet. Niall O'Reily: Ted: the IRI WG could use some energy Harald Alvestrand: Worried that we are not deploying into a greenfield Is worried that the term "canonical name" is not well-defined CNAME is used in many odd places What do the proposed mechanisms do to the current mechanisms? Worried that we haven't figured out all of the harms Suzanne: a requirement is that all things can be optionally deployed Andrew: Are you suggesting that people are using CNAME in a way that are not defined? Harald: Web hosting turns out to be a complex business Paul Vixie: Generally in support of moving the draft forward Asked why MX and NS records could not point to CNAME? Considered to be a lightweight, temporary copy of the "old name" for redirections If we layer our solutions on top of CNAME, we will be constrained by CNAME's limitations Andrew: Lots of people have read the draft Small number thing it is close to ready to go Small number think that there things deeply wrong in the draft Medium number think there are gaps in the text Few think that Andrew's idea of putting it into stasis Ted: If our answer is "no magic here", we should tell ICANN sooner Suzanne: if we don't get additional input, we should wait Jaap Akkerhuis: ICANN is going to do a five-phase(?) study on specific language variants The study is pretty undefined Not optimistic that we will get anything useful from the discussions Harald: Waiting for ICANN to finish is not a good move Paul Hoffman: Now that he heard Jaap's description, would say "don't wait" Thomas Narten (IETF liaison to ICANN): Both should go on in parallel We need to think about the best way to communicate with ICANN Suzanne: We are making good progress and we need more input Resolver Improvements http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 slides: http://tools.ietf.org/agenda/80/slides/dnsext-1.pdf Presenter: Paul Vixie Intended to be non-controversial and non-wire-effecting Got input that turned out to be editorial -01 coming soon There are counterexamples Mailing list thread is inconclusive Thinks it is a restatement of clarification John Levine: RBLDNSD will be fixed TinyDNS should be fixed John will start a mailing list to update Peter: 1034/1035/2308 didn't have any idea of aggressive negative caching Need to make the operational side-effect Paul: used for spamming Mark Andrews: there were DNSSEC RFCs that got it wrong Duane Wessels: wants lists how current implementations work with the other sections Paul: no operational experience Tony Finch: risk of DoS if you co-host mail server with DNS server Phill: suggest EDNS extenstion for conformance validation Peter: worries about the accumulated resolver behavior Wants the same level of care here as we applied to IDN Olafur: Lots of people have read this draft Will ask whether to make this an WG doc Will be listed as udpating 1034 End: 16:19 --------------060508050701020205010503-- From fanf2@hermes.cam.ac.uk Thu Mar 31 07:25:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73CCE3A6B33 for ; Thu, 31 Mar 2011 07:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz8qlvpYCQ+C for ; Thu, 31 Mar 2011 07:25:43 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id 591EA3A6A92 for ; Thu, 31 Mar 2011 07:25:43 -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-1.csi.cam.ac.uk ([131.111.8.51]:40205) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Q5IqH-0001QK-Xx (Exim 4.72) (return-path ); Thu, 31 Mar 2011 15:27:21 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Q5IqH-0004oi-Gd (Exim 4.67) (return-path ); Thu, 31 Mar 2011 15:27:21 +0100 Date: Thu, 31 Mar 2011 15:27:21 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: =?ISO-8859-15?Q?Colm_MacC=E1rthaigh?= In-Reply-To: Message-ID: References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> <95465.1301414968@nsa.vix.com> <82vcz0n7a4.fsf@mid.bfk.de> <1330.1301525305@nsa.vix.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870869256-1336274178-1301581641=:5244" Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:25:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870869256-1336274178-1301581641=:5244 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Colm MacC=E1rthaigh wrote: > > My vote would be for; > > Recommending that authoritative servers implementing DNSSEC SHOULD > NOT return NXDOMAIN for non-terminal labels. I believe that requirement already exists as a MUST NOT. Tony. --=20 f.anthony.n.finch http://dotat.at/ Forth, Tyne, Dogger: West or southwest 7 to severe gale 9 backing south or southwest 4 or 5, increasing 6 or 7 later. Moderate or rough. Rain or showe= rs. Good, occasionally poor. --1870869256-1336274178-1301581641=:5244-- From nweaver@ICSI.Berkeley.EDU Thu Mar 31 07:26:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10283A6AD7 for ; Thu, 31 Mar 2011 07:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk-ReYSn-F51 for ; Thu, 31 Mar 2011 07:26:04 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 053BA3A6A92 for ; Thu, 31 Mar 2011 07:26:04 -0700 (PDT) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id DCE5736A367; Thu, 31 Mar 2011 07:27:43 -0700 (PDT) References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local> <46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> <20110330152241.CAA97DB0215@drugs.dv.isc.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Thu, 31 Mar 2011 07:27:42 -0700 To: Derek Atkins X-Mailer: Apple Mail (2.1084) Cc: Marc Lampo , Nicholas Weaver , dnsext@ietf.org Subject: Re: [dnsext] caches, validating resolvers, CD and DO X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:26:04 -0000 >> Until they strip DNSSEC information. You MUST validate locally.... >=20 > I disagree. I run a local network in my house and run local caching > recursive resolvers. I have all my hosts on my network resolve = through > my local caches. I run all my machines, therefore I trust my cache. = I > see no reason to *require* all my machines to bypass the local cache. > Moreover, in my case I see no reason to require all my machines to > perform local validation. I trust myself. >=20 > Therefore, calling it a MUST is wrong. >=20 >> You want the end client to have its own policy on what to do on = DNSSEC >> failure, not be dependent on the resolver's policy, and thus >> validating clients really should use CD with every request. >=20 > I agree in principle, however that policy can also be "trust the = caching > recursive resolver." Saying that the client MUST validate does not > allow for this trusting policy. >=20 > -derek Good point, however, the default policy should still be a must, since = your configuration is rather unusual: DNSSEC enables DNS to not trust = the recursive resolver, and the default policy should take advantage of = this. Defaults should provide maximum safety and maximum interoperability for = the majority of the clients. From johnl@iecc.com Thu Mar 31 07:34:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294973A6A27 for ; Thu, 31 Mar 2011 07:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.566 X-Spam-Level: X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIEmkXBgR7Hg for ; Thu, 31 Mar 2011 07:34:51 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 4BA363A6A92 for ; Thu, 31 Mar 2011 07:34:51 -0700 (PDT) Received: (qmail 28406 invoked from network); 31 Mar 2011 14:36:29 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 31 Mar 2011 14:36:29 -0000 Date: 31 Mar 2011 14:36:07 -0000 Message-ID: <20110331143607.16901.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <4D948943.8010906@ogud.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ogud@ogud.com Subject: Re: [dnsext] Draft minutes from IETF-80 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:34:52 -0000 > John Levine: RBLDNSD will be fixed > TinyDNS should be fixed > John will start a mailing list to update I don't recall offering to start a mailing list, but I suppose I could if people think there is stuff to discuss beyond what gets discussed on the existing rbldnsd developers' list. R's, John From Ed.Lewis@neustar.biz Thu Mar 31 09:08:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E7628C118 for ; Thu, 31 Mar 2011 09:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.87 X-Spam-Level: X-Spam-Status: No, score=-101.87 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMxFLXsiF1wY for ; Thu, 31 Mar 2011 09:08:04 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 2FF6D3A6B3C for ; Thu, 31 Mar 2011 09:08:04 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2VG9gjM088749; Thu, 31 Mar 2011 12:09:42 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.112] by Work-Laptop-2.local (PGP Universal service); Thu, 31 Mar 2011 12:09:43 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 31 Mar 2011 12:09:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <34319.1301351478@nsa.vix.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> <95465.1301414968@nsa.vix.com> <82vcz0n7a4.fsf@mid.bfk.de> <1330.1301525305@nsa.vix.com> Date: Thu, 31 Mar 2011 12:07:45 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:08:05 -0000 At 15:27 +0100 3/31/11, Tony Finch wrote: >Colm MacC=E1rthaigh wrote: >> >> My vote would be for; >> >> Recommending that authoritative servers implementing DNSSEC SHOULD >> NOT return NXDOMAIN for non-terminal labels. > >I believe that requirement already exists as a MUST NOT. Although I agree that sending a NXDOMAIN for an=20 empty non-terminal is a protocol error[0], I'll=20 note that in the resimprove document it says: # This is due to an ambiguity in RFC 1034 that failed to distinguish # empty nonterminal domain names from nonexistent names. To convert "I believe" to something more=20 fact-based, it would be helpful if the ambiguity=20 were identified. [0] from this in RFC 1034, section 4.3.2: # 3. Start matching down, label by label, in the zone. The # matching process can terminate several ways: # # a. If the whole of QNAME is matched, we have found the # node. That is, the name/node exists, whether it has a type match remains to be see= n. # ...skipping CNAME stuff... # # Otherwise, copy all RRs which match QTYPE into the # answer section and go to step 6. If there are no RRs to match (and empty=20 non-terminal), none match, hence no data is put=20 into the answer section. On the other hand, of the name isn't there, here=20 is the instruction for Name Error (aka NXDOMAIN): # c. If at some label, a match is impossible (i.e., the # corresponding label does not exist), look to see if a # the "*" label exists. # # If the "*" label does not exist, check whether the name # we are looking for is the original QNAME in the query # or a name we have followed due to a CNAME. If the name # is original, set an authoritative name error in the # response and exit. Otherwise just exit. RFC 2308, section 2.1 shows NXDOMAINs where the=20 name is not original. Reducing the logic that=20 would mean the above reads as: If the "*" label does not exist, set an authoritative name error in the response and exit. Otherwise just exit. -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From Ed.Lewis@neustar.biz Thu Mar 31 12:17:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0034C3A6B94 for ; Thu, 31 Mar 2011 12:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJmVI0kvjFbb for ; Thu, 31 Mar 2011 12:17:00 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id DDCEB3A6873 for ; Thu, 31 Mar 2011 12:16:59 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2VJIZBE089922; Thu, 31 Mar 2011 15:18:35 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.112] by Work-Laptop-2.local (PGP Universal service); Thu, 31 Mar 2011 15:18:36 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 31 Mar 2011 15:18:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D938CC3.1020103@nlnetlabs.nl> References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> <4D938CC3.1020103@nlnetlabs.nl> Date: Thu, 31 Mar 2011 15:03:32 -0400 To: Matthijs Mekking From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 19:17:02 -0000 Ironically, I was thinking about this issue when the mail came in yesterday. At 22:04 +0200 3/30/11, Matthijs Mekking wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Ok, so let's try to come to a reasonable clarifying text: > >- ------------------------------------------------------------------------- >Section ?.? Clarifying the validators interpretation regarding multiple >algorithms. > >RFC 4035, section 2.2 talks about Zone Signing. It mentions that > > "There MUST be an RRSIG for each RRset using at least one DNSKEY of > each algorithm in the zone apex DNSKEY RRset". > >This is a requirement at the server side, not the client side. In other >words, when a validating resolvers is in the process of validating a >RRset, it SHOULD NOT expect a RRSIG of each algorithm that is in the >zone apex DNSKEY RRset. >- ------------------------------------------------------------------------- That's not right either, unfortunately, I want to avoid "SHOULD NOT expect" in the text. How about trying this for the last part of the last sentence. ...it SHOULD expect to find an RRSIG of *any* algorithm that is in the zone apex DNSKEY RRset. As a validator ought to be satisfied in building one chain of trust acceptable to local policy, a validator SHOULD NOT check that all signatures are received. Doing so represents a distraction from the goal of returning an answer swiftly. A validator MAY have a configuration option to perform a signature completeness test to support troubleshooting. The *any* there is important, but not the *'s. I added them to stress the "any." >This only fixes the misinterpretation on the expectation a validator may >have. It does not deal with algorithm downgrade protection at all (as >some may believe does not exist in DNSSEC). If there is need for >clarifying algorithm downgrade protection, or its non-existence, I >suggest something in the line of: > >- ------------------------------------------------------------------------- >Section ?.? Algorithm downgrade protection. > >The validator could check that there are RRSIG records for each RRset >using at least one DNSKEY of each algorithm in the DS RRset, published >in the parent zone. This *** > >*** Choice here >- - is however NOT RECOMMENDED. ['the one signature is enough approach'] >- - is OPTIONAL. ['leave the choice to the implementation' approach] >- - is RECOMMENDED behavior. ['algorithm downgrade protection' apprpach] >- ------------------------------------------------------------------------- NOT RECOMMENDED, I consider it unnecessary work towards the goal of finding what the client asked for. That is, in a default setting. The principle that I am pinning this on is that one of the strengths of the DNS protocol is a fast response. > >Best regards, > >Matthijs > > > >On 03/18/2011 06:07 PM, Edward Lewis wrote: >> I should add...just because "there's supposed to be X" doesn't mean X >> has to be there. If I'm looking for X and it's not there, we have a >> failure. If I'm not looking for X and it is not there, "no harm, no >> foul." (The latter is the same as not needing X and it's there anyway.) >> >> At 12:59 -0400 3/18/11, Edward Lewis wrote: >>> At 9:36 -0700 3/18/11, Casey Deccio wrote: >>> >>> >>>> Okay, so the signer sets the expectation of the validator using the >>>> algorithms in the DS RRset. Now, does this expectation hold for >>>> simply authenticating the DNSKEY RRset or for all zone data? >>> >>> No, the specification sets expectations. I don't mean to be a pain, >>> but the first words say this: "The reason for the specification is to >>> set the expectation." I mean that in the strictest sense. The >>> validator knows there's supposed to be X because the spec says so. >>> >>>> For example: >>>> >>>> - DS RRset has only algorithm 5 >>>> - DNSKEY RRset signed by a DNSKEY matching the DS (alg 5) >>>> - DNSKEY RRset contains DNSKEYs with algs 5 and 3 >>>> - DNSKEY with alg 3 signs A RRset. >>>> >>>> Is there a valid chain to the A RRset, or is it a protocol failure? >>> >>> Depends. If the validator knows both 3 and 5, then it can build a >>> chain and it's cool. If the validator only knows 5, then there's a >>> missing piece. If the validator only knows 3, there's no chain to the >>> data. >>> >>> In summary: >>> Validator knows 3 & 5 - validates >>> Validator knows only 3 - data is accepted as not-signed. >>> Validator knows only 5 - service failure as *expected* signature is >>> not found* >>> Validator doesn't to 3 & 5 - accepted as not-signed >>> Validator doesn't do DNSSEC - accepted as not-signed >>> >>> *not found = not obtainable, can't get it, ... >>> >>>> Following the principle of "if one chain works, it succeeds", I would >>>> say >>>> that it is valid. But it's unclear whether this is part of the >>>> expectation >>>> of the signer for the validator, and even the paragraph quoted above >>>> seems >>>> to declare it a protocol failure--although I well understand your >>>> position >>>> on principle. Whether it is valid or not, I believe it should be >>>> worded explicitly to avoid ambiguity and accurately convey principle. >>> >>> It is always up to the validator to decide if it accepts the data. >>> Local policy and DNSSEC is about protecting the cache. DNSSEC is NOT >>> designed to enforce proper operations, it is NOT to force the zone >>> admin into doing anything. Remember, DNSSEC is optional to the >>> protocol, it's the validators that want to pull the data for protection. >>> >>> -- >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> >>> Edward Lewis >>> NeuStar You can leave a voice message at >>> +1-571-434-5468 >>> >>> Me to infant son: "Waah! Waah! Is that all you can say? Waah?" >>> Son: "Waah!" >>> _______________________________________________ >>> dnsext mailing list >>> dnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsext >> >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.10 (GNU/Linux) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >iQEcBAEBAgAGBQJNk4zDAAoJEA8yVCPsQCW502MH/0unZXAo8KqLpwDrXbBBaGps >5rm7eA6rgipU1y99QOMZOggzu5XsI3VVZq8LiTIzKgBB69iufN392v/4afWiEgcW >LGdETtYwQmaif+Rj7+3UhjbSFJj7h2yPUlDvFoT66YOr7HaV+Ow9niYSnTbxmZgV >L/AWNjdpMsfmFoxk9OfJZlYnfgPA2gK4UyUG5YduwybeW1REcqyoQ3V73HnkhZod >SZ5QDHp/mRj4JjlACwSPSg5cQO1hURfp4r43oad0mO2Y1p2cjknp/cF9kcgI2VQu >bBSQ+0oEz55N/8yqzKznfY9tsUWwfsnBmjkMyA8mKD9BuzstScCvXs71K1Dz3SM= >=vrOn >-----END PGP SIGNATURE----- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From matthijs@nlnetlabs.nl Thu Mar 31 13:06:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6673A6BAC for ; Thu, 31 Mar 2011 13:06:36 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX-SeUBdOOBa for ; Thu, 31 Mar 2011 13:06:35 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 3CEEC3A6AA4 for ; Thu, 31 Mar 2011 13:06:33 -0700 (PDT) Received: from [IPv6:2001:df8:0:64:215:afff:fed2:e121] ([IPv6:2001:df8:0:64:215:afff:fed2:e121]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p2VK8BGE064349; Thu, 31 Mar 2011 22:08:11 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4D94DF2B.1040407@nlnetlabs.nl> Date: Thu, 31 Mar 2011 22:08:11 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Edward Lewis References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> <4D938CC3.1020103@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 31 Mar 2011 22:08:12 +0200 (CEST) Cc: dnsext@ietf.org Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 20:06:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/31/2011 09:03 PM, Edward Lewis wrote: > Ironically, I was thinking about this issue when the mail came in > yesterday. > > At 22:04 +0200 3/30/11, Matthijs Mekking wrote: > Ok, so let's try to come to a reasonable clarifying text: > > - > ------------------------------------------------------------------------- > Section ?.? Clarifying the validators interpretation regarding multiple > algorithms. > > RFC 4035, section 2.2 talks about Zone Signing. It mentions that > > "There MUST be an RRSIG for each RRset using at least one DNSKEY of > each algorithm in the zone apex DNSKEY RRset". > > This is a requirement at the server side, not the client side. In other > words, when a validating resolvers is in the process of validating a > RRset, it SHOULD NOT expect a RRSIG of each algorithm that is in the > zone apex DNSKEY RRset. > - > ------------------------------------------------------------------------- > >> That's not right either, unfortunately, I want to avoid "SHOULD NOT >> expect" in the text. How about trying this for the last part of the >> last sentence. > >> ...it SHOULD expect to find an RRSIG of *any* algorithm that is in the >> zone apex DNSKEY RRset. As a validator ought to be satisfied in >> building one chain of trust acceptable to local policy, a validator >> SHOULD NOT check that all signatures are received. Doing so represents >> a distraction from the goal of returning an answer swiftly. A validator >> MAY have a configuration option to perform a signature completeness test >> to support troubleshooting. I would than say "it can expect to find" (not make it a rfc 2119 term) > >> The *any* there is important, but not the *'s. I added them to stress >> the "any." > > This only fixes the misinterpretation on the expectation a validator may > have. It does not deal with algorithm downgrade protection at all (as > some may believe does not exist in DNSSEC). If there is need for > clarifying algorithm downgrade protection, or its non-existence, I > suggest something in the line of: > > - > ------------------------------------------------------------------------- > Section ?.? Algorithm downgrade protection. > > The validator could check that there are RRSIG records for each RRset > using at least one DNSKEY of each algorithm in the DS RRset, published > in the parent zone. This *** > > *** Choice here > - is however NOT RECOMMENDED. ['the one signature is enough approach'] > - is OPTIONAL. ['leave the choice to the implementation' approach] > - is RECOMMENDED behavior. ['algorithm downgrade protection' apprpach] > - > ------------------------------------------------------------------------- > > >> NOT RECOMMENDED, I consider it unnecessary work towards the goal of >> finding what the client asked for. That is, in a default setting. The >> principle that I am pinning this on is that one of the strengths of the >> DNS protocol is a fast response. > > > Best regards, > > Matthijs > > > > On 03/18/2011 06:07 PM, Edward Lewis wrote: >>>> I should add...just because "there's supposed to be X" doesn't mean X >>>> has to be there. If I'm looking for X and it's not there, we have a >>>> failure. If I'm not looking for X and it is not there, "no harm, no >>>> foul." (The latter is the same as not needing X and it's there >>>> anyway.) >>>> >>>> At 12:59 -0400 3/18/11, Edward Lewis wrote: >>>>> At 9:36 -0700 3/18/11, Casey Deccio wrote: >>>>> >>>>> >>>>>> Okay, so the signer sets the expectation of the validator using the >>>>>> algorithms in the DS RRset. Now, does this expectation hold for >>>>>> simply authenticating the DNSKEY RRset or for all zone data? >>>>> >>>>> No, the specification sets expectations. I don't mean to be a pain, >>>>> but the first words say this: "The reason for the specification is to >>>>> set the expectation." I mean that in the strictest sense. The >>>>> validator knows there's supposed to be X because the spec says so. >>>>> >>>>>> For example: >>>>>> >>>>>> - DS RRset has only algorithm 5 >>>>>> - DNSKEY RRset signed by a DNSKEY matching the DS (alg 5) >>>>>> - DNSKEY RRset contains DNSKEYs with algs 5 and 3 >>>>>> - DNSKEY with alg 3 signs A RRset. >>>>>> >>>>>> Is there a valid chain to the A RRset, or is it a protocol failure? >>>>> >>>>> Depends. If the validator knows both 3 and 5, then it can build a >>>>> chain and it's cool. If the validator only knows 5, then there's a >>>>> missing piece. If the validator only knows 3, there's no chain to the >>>>> data. >>>>> >>>>> In summary: >>>>> Validator knows 3 & 5 - validates >>>>> Validator knows only 3 - data is accepted as not-signed. >>>>> Validator knows only 5 - service failure as *expected* signature is >>>>> not found* >>>>> Validator doesn't to 3 & 5 - accepted as not-signed >>>>> Validator doesn't do DNSSEC - accepted as not-signed >>>>> >>>>> *not found = not obtainable, can't get it, ... >>>>> >>>>>> Following the principle of "if one chain works, it succeeds", I would >>>>>> say >>>>>> that it is valid. But it's unclear whether this is part of the >>>>>> expectation >>>>>> of the signer for the validator, and even the paragraph quoted above >>>>>> seems >>>>>> to declare it a protocol failure--although I well understand your >>>>>> position >>>>>> on principle. Whether it is valid or not, I believe it should be >>>>>> worded explicitly to avoid ambiguity and accurately convey principle. >>>>> >>>>> It is always up to the validator to decide if it accepts the data. >>>>> Local policy and DNSSEC is about protecting the cache. DNSSEC is NOT >>>>> designed to enforce proper operations, it is NOT to force the zone >>>>> admin into doing anything. Remember, DNSSEC is optional to the >>>>> protocol, it's the validators that want to pull the data for >>>>> protection. >>>>> >>>>> -- >>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>>>> >>>>> >>>>> Edward Lewis >>>>> NeuStar You can leave a voice message at >>>>> +1-571-434-5468 >>>>> >>>>> Me to infant son: "Waah! Waah! Is that all you can say? Waah?" >>>>> Son: "Waah!" >>>>> _______________________________________________ >>>>> dnsext mailing list >>>>> dnsext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnsext >>>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNlN8qAAoJEA8yVCPsQCW5g9gIAJzi7c+Ix9Woyf+iwWAuVGYL 6+K4eHbAxibFCs1qimGTC4kV8CWCwdZL5c1+cZ6lZzLSH6TePw9LUTtivxRQhk8i DMgRt8wgOZ4LJB4y3M10BUaPQh0xnG1HtPiRJtd1EVrW4b4wSLFEEXUFZtVPIZwe 7RqC7YCPL8bK9U4wJU+4THn1x3hWpOgywgi+DKdk66uCzBnxMcZpzIcgkmRaAzGn 6MAcBTu77nqTz6LwOCT59fLwI1KnOzvR5eFXUjQvnCaEwBnyMmJztK5suId587hC dYVtDvMik8cs4egZEEPjlJviHIcvdW4ZjOf0gngn9xCWmcCDH8m8368TShtveEA= =zdlJ -----END PGP SIGNATURE-----