From bmanning@karoshi.com Wed Feb 1 04:27:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A45E21F85E6 for ; Wed, 1 Feb 2012 04:27:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LF27D-bt+oy for ; Wed, 1 Feb 2012 04:27:10 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7B05221F85E5 for ; Wed, 1 Feb 2012 04:27:10 -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 q11CRAFB009124 for ; Wed, 1 Feb 2012 12:27:10 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q11CRAdQ009123 for dnsext@ietf.org; Wed, 1 Feb 2012 12:27:10 GMT Date: Wed, 1 Feb 2012 12:27:10 +0000 From: bmanning@vacation.karoshi.com To: dnsext@ietf.org Message-ID: <20120201122710.GA9117@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [dnsext] [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2012 12:27:11 -0000 I have read the document and support its publication. /bill At 12:49 AM 1/20/2012, Andrew Sullivan wrote: >Dear colleagues, > >This message initiates a three week Working Group Last Call on the >document draft-ietf-dnsext-dnssec-bis-updates-16. LC will close on >2012-01-11 at 00:00 UTC. > >The WG's standard conventions, which require five reviewers who state >that they have read the draft and support its publication as a >necessary but not sufficient determinant of rough consensus, are in >force. Please review the document and post to the list any comments >you have before the close of LC. If you cannot meet that deadline, >but are willing to commit to completing a review and can give me a >firm date for it (and that date is within a reasonable horizon), I >will announce an extension of the LC deadline. I'd appreciate it if >you'd tell me of this need sooner rather than later. Specific >comments are much better than generic ones, and specific comments with >suggested text (if you find some text wanting) are particularly >encouraged. > >Speaking only personally, this draft is the product of several years >of WG work: the -00 of the draft was submitted in 2005. Moreover, it >is the product of a lot of heated discussion and careful teasing out >of the issues involved. I would be sad to discover that we could not >find (rather) more than five reviewers for this document. > >I will be the shepherd for this document if it is sent to the IESG. > >Best regards, > >Andrew From yaojk@cnnic.cn Wed Feb 1 05:50:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C6811E81B4 for ; Wed, 1 Feb 2012 05:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.604 X-Spam-Level: X-Spam-Status: No, score=-99.604 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_40=-0.185, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxqW7eeXq2Dk for ; Wed, 1 Feb 2012 05:50:38 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 92E6311E8395 for ; Wed, 1 Feb 2012 05:50:31 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO computer) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 01 Feb 2012 21:50:25 +0800 Message-ID: <002101cce0e8$71676de0$cb01a8c0@computer> From: "Yao Jiankang" To: , References: <4f292fa5.a874ec0a.330e.28b4SMTPIN_ADDED@mx.google.com> Date: Wed, 1 Feb 2012 21:50:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3664 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Subject: [dnsext] CNAME check Re: [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2012 13:50:39 -0000 For Section 4.3. "Check for CNAME", In order to accommade the possible CNAME synthesis extension, how about adding the following sentence or sentence with the similar meaning in the section 4.3? " When validating the CNAME, if the CNAME has not matching RRSIG and the validator can not decide whether the CNAME is the synthesis of other names such as the DNAME, this CNAME should be neglected." Jiankang Yao ----- Original Message ----- From: To: Sent: Wednesday, February 01, 2012 8:27 PM Subject: [dnsext] [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16] > > I have read the document and support its publication. > > /bill > > At 12:49 AM 1/20/2012, Andrew Sullivan wrote: >>Dear colleagues, >> >>This message initiates a three week Working Group Last Call on the >>document draft-ietf-dnsext-dnssec-bis-updates-16. LC will close on >>2012-01-11 at 00:00 UTC. >> >>The WG's standard conventions, which require five reviewers who state >>that they have read the draft and support its publication as a >>necessary but not sufficient determinant of rough consensus, are in >>force. Please review the document and post to the list any comments >>you have before the close of LC. If you cannot meet that deadline, >>but are willing to commit to completing a review and can give me a >>firm date for it (and that date is within a reasonable horizon), I >>will announce an extension of the LC deadline. I'd appreciate it if >>you'd tell me of this need sooner rather than later. Specific >>comments are much better than generic ones, and specific comments with >>suggested text (if you find some text wanting) are particularly >>encouraged. >> >>Speaking only personally, this draft is the product of several years >>of WG work: the -00 of the draft was submitted in 2005. Moreover, it >>is the product of a lot of heated discussion and careful teasing out >>of the issues involved. I would be sad to discover that we could not >>find (rather) more than five reviewers for this document. >> >>I will be the shepherd for this document if it is sent to the IESG. >> >>Best regards, >> >>Andrew > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From weiler@watson.org Wed Feb 1 06:42:48 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3434B11E8393 for ; Wed, 1 Feb 2012 06:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW-4SnSfB3C8 for ; Wed, 1 Feb 2012 06:42:46 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id D916E21F8885 for ; Wed, 1 Feb 2012 06:42:18 -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 q11EgH2R071567; Wed, 1 Feb 2012 09:42:17 -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 q11EgG6Z071560; Wed, 1 Feb 2012 09:42:16 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 1 Feb 2012 09:42:16 -0500 (EST) From: Samuel Weiler To: Edward Lewis In-Reply-To: Message-ID: References: <20120130180338.27331.28809.idtracker@ietfa.amsl.com> 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]); Wed, 01 Feb 2012 09:42:17 -0500 (EST) Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2012 14:42:48 -0000 On Tue, 31 Jan 2012, Edward Lewis wrote: > Not really. We only needed an NSEC3-ized RSA/SHA-1 to deal with backward > compatibility issues at the time. From here out, any "new" DNSSEC > "algorithm" will be defined for NSEC3 and NSEC. > > And - for RSASHA1-NSEC3-SHA1, the -SHA1 is there twice! The trailing -SHA1 refers to the NSEC3 name hashing algorithm. That could be different from the hash algorithm used in signing (and, in the case of RSASHA256 and RSASHA512, they are indeed different). I think there's a plausible arugment that the mnemonics defined in RFC5702 should have been RSASHA256-SHA1 and RSASHA512-SHA1. -- Sam From weiler@watson.org Wed Feb 1 06:57:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DD311E8089 for ; Wed, 1 Feb 2012 06:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaidETbeHU-b for ; Wed, 1 Feb 2012 06:57:10 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id BBF8411E8071 for ; Wed, 1 Feb 2012 06:57:10 -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 q11EvA2G078511 for ; Wed, 1 Feb 2012 09:57:10 -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 q11Ev9dx078505 for ; Wed, 1 Feb 2012 09:57:10 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 1 Feb 2012 09:57:09 -0500 (EST) From: Samuel Weiler To: dnsext@ietf.org In-Reply-To: Message-ID: References: <20120109222905.GW1820@crankycanuck.ca> 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]); Wed, 01 Feb 2012 09:57:10 -0500 (EST) Subject: Re: [dnsext] draft-srose-dnssec-algo-imp-status-00 (was: Re: Follow up on draft-ietf-dnsext-dnssec-registry-fixes) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2012 14:57:11 -0000 To save everyone else the time of diff'ing them, since the tools site did not flag one as a replacement for the other: the recently-posted WG-named version of this doc (draft-ietf-dnsext-dnssec-algo-imp-status-00.txt) appears to make no substantive changes from the -srose version. -- Sam From weiler@watson.org Wed Feb 1 07:11:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7066911E80EB for ; Wed, 1 Feb 2012 07:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHvBK4QZJ2WZ for ; Wed, 1 Feb 2012 07:11:22 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id E57A911E80DB for ; Wed, 1 Feb 2012 07:11:20 -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 q11FBEiA084973; Wed, 1 Feb 2012 10:11:14 -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 q11FBEPj084970; Wed, 1 Feb 2012 10:11:14 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 1 Feb 2012 10:11:14 -0500 (EST) From: Samuel Weiler To: "W.C.A. Wijngaards" In-Reply-To: <4F1FEB8D.1080703@nlnetlabs.nl> Message-ID: References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> <4F1FEB8D.1080703@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]); Wed, 01 Feb 2012 10:11:14 -0500 (EST) Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2012 15:11:23 -0000 Thanks to all who have reviewed this doc during the WGLC (Mark, Wouter, Ed, Mike, Mohan, Warren, and Bill). I want to assure you that your comments are not being ignored -- I plan to respond to most of them in bulk at the end of the WGLC. I'm responding to this one now since it may require some more discussion. On Wed, 25 Jan 2012, W.C.A. Wijngaards wrote: > The section and appendix on CD bits are long. Not wrong, but long. I know, and I concur. The chairs directed the editors to add this text, which is the result of a design team meeting reported on this list (well, on namedroppers). I didn't feel strongly enough about it to refuse. Feel free to make a stronger case for leaving some of it (e.g. the whole appendix) out. > Section 6.2 is correct. But its tone is loose. It is about lenient > acceptance of the SEP flag. Please say that, or say that the proper > setting of the SEP flag is defined in its RFC. I'll try to improve this when making the changes at the end of WGLC. -- Sam From ajs@anvilwalrusden.com Wed Feb 1 07:16:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD29C11E80D3 for ; Wed, 1 Feb 2012 07:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1R742vkdzo9 for ; Wed, 1 Feb 2012 07:16:16 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2974111E8073 for ; Wed, 1 Feb 2012 07:16:16 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2EA431ECB41C for ; Wed, 1 Feb 2012 15:16:15 +0000 (UTC) Date: Wed, 1 Feb 2012 10:16:13 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120201151613.GE22825@crankycanuck.ca> References: <4f292fa5.a874ec0a.330e.28b4SMTPIN_ADDED@mx.google.com> <002101cce0e8$71676de0$cb01a8c0@computer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002101cce0e8$71676de0$cb01a8c0@computer> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] CNAME check Re: [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2012 15:16:16 -0000 Hi, No hat. > " > When validating the CNAME, if the CNAME has not matching RRSIG and > the validator can not decide whether the CNAME is the synthesis of > other names such as the DNAME, this CNAME should be neglected." In the case of DNAME, you shouldn't need to worry about the synthetic CNAME because if you are validating you already know about DNSSEC. Therefore, you can validate the DNAME and know that the CNAME is synthetic. So I don't think this text is necessary. If you're talking about some future example, then I don't think it will work. Suppose that we invented RRTYPE FOO that was an xNAME. FOO did backward compatibility by synthesizing CNAMEs for FOO-unaware resolvers of some type (let's pretend we signalled awareness using EDNS0). Now, imagine a FOO-unaware validating resolver that follows the advice you suggest. It queries a signed zone with a FOO record. The resolver doesn't know about FOO. Therefore, it doesn't know that there could be a synthetic CNAME at that name, resulting from the FOO record. Therefore, it will treat the unsigned CNAME as bogus, and the backwards compatibility doesn't happen. Ok, so let's suppose we went further than you did, and said any time you see a CNAME in a signed zone that is not signed, you should assume that the unsigned CNAME is synthetic rather than bogus. This of course would be a massive hole in DNSSEC: anyone who could convince you to accept a CNAME any time could undermine your validation. Therefore, it wouldn't be acceptable. Is there some other scenario you can see that I haven't outlined above? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Wed Feb 1 08:05:09 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED74111E8076 for ; Wed, 1 Feb 2012 08:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5ilEhT+OhKp for ; Wed, 1 Feb 2012 08:05:09 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7C13311E8080 for ; Wed, 1 Feb 2012 08:05:09 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8BF851ECB41C for ; Wed, 1 Feb 2012 16:05:08 +0000 (UTC) Date: Wed, 1 Feb 2012 11:05:01 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120201160500.GA23020@mail.yitter.info> References: <4f292fa5.a874ec0a.330e.28b4SMTPIN_ADDED@mx.google.com> <002101cce0e8$71676de0$cb01a8c0@computer> <20120201151613.GE22825@crankycanuck.ca> <006c01cce0f7$d22250f0$cb01a8c0@computer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006c01cce0f7$d22250f0$cb01a8c0@computer> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] CNAME check Re: [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2012 16:05:10 -0000 Hi, No hat. On Wed, Feb 01, 2012 at 11:40:23PM +0800, Yao Jiankang wrote: > >Now, imagine a FOO-unaware validating resolver that follows the advice > >you suggest. It queries a signed zone with a FOO record. The > >resolver doesn't know about FOO. Therefore, it doesn't know that > >there could be a synthetic CNAME at that name, resulting from the FOO > >record. Therefore, it will treat the unsigned CNAME as bogus, and the > >backwards compatibility doesn't happen. > > My suggested word is that "this CNAME should be neglected". It means > that the FOO-unaware validating resolver(when doing DNSSEC checking) > will see this unsigned CNAME as nothing, not accept it, and also not > report it as bogus. When a unsigned CNAME appears, the FOO-unaware > validating resolver(when doing DNSSEC checking) just sees nothing > and negelcts this CNAME. So I do not think that it will cause any > hole in DNSSEC. Ok, so the resolver ignores the unsigned CNAME (i.e. it's as though it wasn't received), and returns what to the initiator of the query (i.e. the originating resolver or the application or whatever)? NOERROR with an empty answer? I don't understand how this is any better than treating the result as bogus; the originator of the query still can't get to the destination it was querying for, right? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From matthijs@nlnetlabs.nl Wed Feb 1 08:27:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C1421F8893 for ; Wed, 1 Feb 2012 08:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI+sacVrx995 for ; Wed, 1 Feb 2012 08:27:30 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE5921F88E3 for ; Wed, 1 Feb 2012 08:27:30 -0800 (PST) Received: from [192.168.178.23] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q11GRRbN011979 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 1 Feb 2012 17:27:28 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1328113649; bh=u71upagdCjGlnEOtDcVSD2OO/W3UdTinRgGcSNdHh9s=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MAbUicfJH589DSn2QTCnoPoxjV1Zb6ZeLNXAq8A2CfYLADnS/COK6/e2NvxLii9fe UYLU48VF6zccsZV8UzxBEsOWGmMjMzaUB/u6wAXZf/oo+Tu3fgvf55CdOYyh9oNoHN uW6mkmlFjaiqiMYYM9Vy+saX1zlLFdwhuUONvA6I= Message-ID: <4F2967EF.8070502@nlnetlabs.nl> Date: Wed, 01 Feb 2012 17:27:27 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> In-Reply-To: <20120120142243.GE4944@mail.yitter.info> 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.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 01 Feb 2012 17:27:28 +0100 (CET) Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2012 16:27:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have reviewed and support publication. Here are my comments. 1. Section 5.4. Caution About Local Policy and Multiple RRSIGs 1a. Nit The second paragraph raises concerns when a resolver adopts a more restrictive security policy. On the first read, it is not immediately obvious why there can be unnecessary validation failures. Perhaps a small explanation is needed, that the restrictive policy is requiring all signatures to validate? 2. Section 5.11. Mandatory Algorithm Rules 2a. Nit Typo: pressence -> presence 2b. The section states that a signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone. I argue if MUST is too strong, and would vote for SHOULD, for the reason that the expected trust anchors and DS RRset are being maintained outside the administrative boundaries of the zone owner. 3. Section 6.4. Erros in RFC 5155 I would like to see some clarifying or guiding text about the contradiction in this RFC on the Flags field I posted earlier to this list: Section 8.2 of RFC 5155 states that a validator MUST ignore NSEC3 RRs with a Flag fields value other than zero or one. But in the IANA Considerations section, bits 0-6 are available for assignment. However, assigning a meaning to one of the bits 0-6 would break NSEC3 conformance because that would allow for Flag fields value larger than one and that conflicts with the rule in Section 8.2 . As a result, assigning a meaning to one of the bits 0-6 in the NSEC3 Flag fields would require an update at the resolver side to ignore the bits it does not implement, regardless of the total outcome value of the Flag fields. Such a requirement allows for a more flexible approach for future updates of the NSEC3 Flag fields, with a nice backwards compatibility property. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPKWfvAAoJEA8yVCPsQCW5XUEH/2IbCyR84dhWWp9qX5zI9tJ3 7YF9wwgd4i9a3IEtESQvyaFPWpvwTy0RnLOdG7XbataQcnf7URfJOQjIhjmuq+Lj 9Yk7DCIxyH6WNlGuAPaX7Lxq86HFO8BZDn5cdwHJtBljrZAN91HvHuazBuPw1xzc 3bf5+B9R/TfNO4shQw9sIdjNDgwm4lpW9P62X8MATk0P7tDnkLHgFbP8dug1kxes yzMhoHO8CB/uwS6VrB1tIjoHaw1+QLYO99xXKWQ2778SuQobmASvz4iq4GE/FV/0 mQFuyy5eb5ilVerYGUQChRaHDlz7BsmzNZI17zSH8UW0/oEF/Sc3boOKiX3MrC8= =xD3b -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Wed Feb 1 10:55:59 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E572811E8080 for ; Wed, 1 Feb 2012 10:55:59 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aANF+QwtH91t for ; Wed, 1 Feb 2012 10:55:59 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C020111E8071 for ; Wed, 1 Feb 2012 10:55:53 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q11Ito2c022173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 1 Feb 2012 11:55:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <4F2967EF.8070502@nlnetlabs.nl> Date: Wed, 1 Feb 2012 10:55:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4A30B716-F051-41F5-B237-29C6397289A5@vpnc.org> References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> <4F2967EF.8070502@nlnetlabs.nl> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2012 18:56:00 -0000 Big: 5.10 is long, scary, and useless for most environments because most = environments will have just one trust anchor. Please add the following = after the first paragraph of the section: When DNSSEC was first published, many sites had multiple (and sometimes = nested) trust anchors. Now, it is believed that very few do. If a site = has a single trust anchor, the information in this entire section can = safely be skipped. Medium: 5.6 (setting the DO bit in replies) suggests resolvers should "be = liberal in what they accept". That's a bit vague. Instead, say what you = mean "In order to interoperate with implementations that ignore this = rule on sending, resolvers need to allow either the DO bit to be set or = unset when receiving responses". However, that's still not as honest as = I would like. "Because some implementations ignore this rule on sending, = the rule for receivers is now that they MUST NOT expect the DO bit to be = set as it was sent." In 5.8, it is unclear what "protect" means. Either clarify what is being = protected or use a different word. Small: 1.1 should start "The clarifications and changes to ..." --Paul Hoffman From yaojk@cnnic.cn Wed Feb 1 17:46:14 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB3B11E80B0 for ; Wed, 1 Feb 2012 17:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.584 X-Spam-Level: X-Spam-Status: No, score=-100.584 tagged_above=-999 required=5 tests=[AWL=1.414, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgL9vBHfb8ZY for ; Wed, 1 Feb 2012 17:46:14 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 8833611E808A for ; Wed, 1 Feb 2012 17:46:11 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO computer) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 02 Feb 2012 09:46:04 +0800 Message-ID: <002c01cce14c$6c0e91c0$cb01a8c0@computer> From: "Yao Jiankang" To: References: <4f292fa5.a874ec0a.330e.28b4SMTPIN_ADDED@mx.google.com><002101cce0e8$71676de0$cb01a8c0@computer><20120201151613.GE22825@crankycanuck.ca><006c01cce0f7$d22250f0$cb01a8c0@computer> <20120201160500.GA23020@mail.yitter.info> Date: Thu, 2 Feb 2012 09:46:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3664 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Subject: Re: [dnsext] CNAME check Re: [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 02 Feb 2012 01:46:14 -0000 ----- Original Message ----- From: "Andrew Sullivan" To: Sent: Thursday, February 02, 2012 12:05 AM Subject: Re: [dnsext] CNAME check Re: [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16] > Hi, > > No hat. > > On Wed, Feb 01, 2012 at 11:40:23PM +0800, Yao Jiankang wrote: > >> >Now, imagine a FOO-unaware validating resolver that follows the advice >> >you suggest. It queries a signed zone with a FOO record. The >> >resolver doesn't know about FOO. Therefore, it doesn't know that >> >there could be a synthetic CNAME at that name, resulting from the FOO >> >record. Therefore, it will treat the unsigned CNAME as bogus, and the >> >backwards compatibility doesn't happen. >> >> My suggested word is that "this CNAME should be neglected". It means >> that the FOO-unaware validating resolver(when doing DNSSEC checking) >> will see this unsigned CNAME as nothing, not accept it, and also not >> report it as bogus. When a unsigned CNAME appears, the FOO-unaware >> validating resolver(when doing DNSSEC checking) just sees nothing >> and negelcts this CNAME. So I do not think that it will cause any >> hole in DNSSEC. > > Ok, so the resolver ignores the unsigned CNAME (i.e. it's as though it > wasn't received), and returns what to the initiator of the query > (i.e. the originating resolver or the application or whatever)? > NOERROR with an empty answer? I don't understand how this is any > better than treating the result as bogus; the originator of the query > still can't get to the destination it was querying for, right? > For example, Assume that the DNSEXT supports BNAME in the future. the FOO-unaware validating resolver(when doing DNSSEC checking) will not regard the BNAME's CNAME synthesis as bogus. So the section 5.2. " BNAME alias algorithm identifiers" is not needed. the FOO-unaware validating resolver(when DNSSEC check is not enabled) can use the CNAME.(unsigned CNAME is only neglected when DNSSEC check is enabled) Jiankang Yao Otherwise, the > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From ajs@anvilwalrusden.com Thu Feb 2 09:46:29 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1250A21F8609 for ; Thu, 2 Feb 2012 09:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRAi3nE4s89d for ; Thu, 2 Feb 2012 09:46:28 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8D91721F85F4 for ; Thu, 2 Feb 2012 09:46:28 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 37D9D1ECB41C for ; Thu, 2 Feb 2012 17:46:27 +0000 (UTC) Date: Thu, 2 Feb 2012 12:46:25 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120202174625.GN388@mail.yitter.info> References: <20120127213928.GI17728@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120127213928.GI17728@mail.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] WG state reminder X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 02 Feb 2012 17:46:29 -0000 Dear colleagues, On Fri, Jan 27, 2012 at 04:39:28PM -0500, Andrew Sullivan wrote: > draft-ietf-dnsext-dnssec-algo-signal completed a WGLC under its > (apponted, non-WG chair) shepherd some time ago, but there have been > comments since. The shepherd was appointed because both of the WG > co-chairs, in their employment, reported to one of the document > authors. The appointed shephed is busy. Given that I am no longer > reporting to the author in question in my employment, I wonder whether > people still have a concern here. Comments are welcome. I have received (off-list) an objection to taking this on as shepherd, so we will maintain our strategy of using the appointed shepherd. I will ask him when he might have time for this. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From suruti94@gmail.com Fri Feb 3 12:47:58 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2757F21F85A3 for ; Fri, 3 Feb 2012 12:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNYtB20e3ypH for ; Fri, 3 Feb 2012 12:47:57 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7521F85DA for ; Fri, 3 Feb 2012 12:47:57 -0800 (PST) Received: by qan41 with SMTP id 41so2527049qan.10 for ; Fri, 03 Feb 2012 12:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1/tRD0swqEap9IxBKMu9bbj8Ctl71IFreAgNqL+mFzw=; b=BBaU6h76v43oV/xfVl61zP63tGX38kEQX/ZsTZfJd9S2Q101QssF3mgvYqhEfPfvls NrT35OS7E1plBNl6ByMIfyFZATk6lcnBoWn01B/s+/TCXZadz91HtT+MXnb7WmS6OSa1 gQNTZwsaf+oIe+cUl5G0nfD1Buv7YMKcuL2bo= MIME-Version: 1.0 Received: by 10.224.198.3 with SMTP id em3mr10687476qab.23.1328302076706; Fri, 03 Feb 2012 12:47:56 -0800 (PST) Received: by 10.229.20.193 with HTTP; Fri, 3 Feb 2012 12:47:56 -0800 (PST) In-Reply-To: References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> <20111121211312.6692917DB0E8@drugs.dv.isc.org> <1321935016.1657.19.camel@mattlaptop2.local> Date: Fri, 3 Feb 2012 12:47:56 -0800 Message-ID: From: Mohan Parthasarathy To: Edward Lewis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] [dane] Aiming towards some specific wording X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 03 Feb 2012 20:47:58 -0000 On Tue, Nov 22, 2011 at 5:55 AM, Edward Lewis wrote: > (Took DANE off because I'm not on the list.) > > At 20:10 -0800 11/21/11, Matt McCutchen wrote: > >>That's great, RFC 4035 has a totally different definition of >>"indeterminate" than RFC 4033. > > You're right.=A0 When I answered I went to 4035 because it is the "protoc= ol > mod" and not 4034 because it was "records".=A0 I usually ignore 4033 beca= use > it's "intro" and has no requirements language in it.=A0 That's just to ex= plain > why I quoted 4035 (because these kind of terminology things run rampant i= n > RFCs) and why I didn't quote 4033. > > Not that 4033 is any less wrong than 4035.=A0 I just ordinarily look at > 4034/4035 more. > > Here's what '33 says: > > #=A0=A0 Indeterminate: There is no trust anchor that would indicate that = a > #=A0=A0 specific portion of the tree is secure.=A0 This is the default > #=A0=A0 operation mode. > > Certainly different from 4035 and what I would assume was the right way t= o > define indeterminate. > This is an old thread but may be relevant now. As we are in the last call of dnssec-bis updates, we should clarify this. Even the definition of Insecure is different. 4033 says that you have the signed proof of the non-existence of a DS record where as 4035 says you declare insecure if you can't construct the chain which could be because of the missing DNSKEY/DS RRs. I may not be able to obtain them because of the bad CPE device. Can it not be Bogus as per the definition in 4035 ? If the application is going to be sensitive and react differently based on these status codes, then this should either be simplified or clarified in the dnssec-bis updates. -mohan > -- > > -=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=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 You can = leave a voice message at +1-571-434-5468 > > Vote for the word of the day: > "Papa"razzi - father that constantly takes photos of the baby > Corpureaucracy - The institution of corporate "red tape" > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From internet-drafts@ietf.org Tue Feb 7 05:01:34 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12CE21F87C8; Tue, 7 Feb 2012 05:01:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezgHqL+BrRWW; Tue, 7 Feb 2012 05:01:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D233021F87BE; Tue, 7 Feb 2012 05:01:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2012 05:01:16 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2012 13:01:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : Extension Mechanisms for DNS (EDNS0) Author(s) : Joao Damas Michael Graff Paul Vixie Filename : draft-ietf-dnsext-rfc2671bis-edns0-08.txt Pages : 15 Date : 2012-02-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 (RFC 2671) based on feedback from deployment experience in several implementations. It also closes the IANA registry for extended labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name System") which depends on the existence of extended labels. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-08.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-08.txt From ajs@anvilwalrusden.com Tue Feb 7 07:18:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8CF21F870A for ; Tue, 7 Feb 2012 07:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH6Ue42SSbSJ for ; Tue, 7 Feb 2012 07:18:23 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 50AD021F85B5 for ; Tue, 7 Feb 2012 07:18:23 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 40A901ECB41D for ; Tue, 7 Feb 2012 15:18:22 +0000 (UTC) Date: Tue, 7 Feb 2012 10:18:20 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120207151820.GE9478@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] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2012 15:18:24 -0000 Dear colleagues, We're still in the WGLC on dnssec-bis-updates, but we have some pending issues to sort out. At the moment, we have several issues that have been raised in the WGLC, but not much in the way of proposed resolution. Sam Weiler says he is tracking them; and many of the issues have been fairly minor, but I want to make sure that we don't go back into a long period of benign neglect of this document, so I'd like to hear some responses. The following are substantive issues that require more than minor changes to the document, and for which we need some answers. I'm raising them now in the hopes that we can get them closed before WGLC ends. A reminder that WGLC ends at the same time (this) Friday ends. ISSUE 1: Indeterminacy of Indeterminate In http://www.ietf.org/mail-archive/web/dnsext/current/msg12176.html, Mohan Parthasarathy argues that RFC 4033 and RFC 4035 have inconsistent definitions of "Indeterminate". RFC 4033 says this is what Indeterminate means, in section 5: Indeterminate: There is no trust anchor that would indicate that a specific portion of the tree is secure. This is the default operation mode. RFC 4035 has this definition in section 4.3: Indeterminate: An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones. These two do seem to be inconsistent. In particular, the latter apparently can happen when a security-aware resolver with an appropriate trust anchor can't find an upstream that can handle the DO bit. Does anyone have an opinion on what to do about this? We will need to come to some very strong agreement quickly, or it will not be addressed in this document. DEFAULT ACTION: none. Without proposed text that finds strong support, this issue will be left out of the document. ISSUE 2: Ignoring CNAME signatures Jiankang Yao has suggested in http://www.ietf.org/mail-archive/web/dnsext/current/msg12166.html that language be added to permit ignoring unsigned CNAME records under some circumstances. I am already on the record as personally opposing this change, but surely I'm not the only voice here. Does anyone have an opinion about this? DEFAULT ACTION: none. Without proposed text that finds very strong support, this proposed change will not be included. If a change is to be added along these lines, it will require a separate last call on its own, because it is a major change to the protocol. ISSUE 3: Alter section 5.10 Paul Hoffman requests a change to section 5.10 in http://www.ietf.org/mail-archive/web/dnsext/current/msg12173.html. Speaking only personally, I cannot see any objection to the proposed sentence, "If a site has only a single trust anchor, the information in this entire section can safely be skipped." I'm less sure about the motivational sentences; I'm not even sure they're true. Does anyone have any thoughts? DEFAULT ACTION: Include the "If a site has only a single trust anchor …" sentence, and exclude the other proposed sentences. ISSUE 4: Request to change the language in 5.6 This is also a request from Paul Hoffman, in the same review. Is there any objection to his first formulation? I believe his second formulation would actually be a significant change to the protocol, and as shepherd I cannot accept it without a fairly strong signal from the WG. DEFAULT ACTION: Use the first formulation proposed ("In order to interoperate with implementations that ignore this rule on sending, resolvers need to allow either the DO bit to be set or unset when receiving responses.") ISSUE 5: The CD bit redux Mark Andrews argues in http://www.ietf.org/mail-archive/web/dnsext/current/msg12133.html that the advice always to set the CD bit is bad advice. Does anyone else want to take up his line of argument? If not, I'll rule that he's in the rough on this. Wouter Wijngaards suggests that the discussion around this is too long, and one of the editors agrees. To find fault where it belongs, the long appendix on this is there at my insistence, because several people previously argued that it was necessary to expose the consequences of different approaches to setting the CD bit, and yet my finding was that there was rough consensus in favour of the "always set" approach. In the absence of overwhelming support in favour of removing the discussion, I think it should stay. If you think it should be altered, then you need to offer replacement text and not ask that someone come up with it. Keep in mind that the text, long as it is, was the subject of protracted discussion. DEFAULT ACTION: none. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From wouter@nlnetlabs.nl Tue Feb 7 07:35:03 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4993421F8816 for ; Tue, 7 Feb 2012 07:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRfSIpLhPRku for ; Tue, 7 Feb 2012 07:35:02 -0800 (PST) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by ietfa.amsl.com (Postfix) with ESMTP id D3F9421F87F5 for ; Tue, 7 Feb 2012 07:35:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id EA4F358CFB for ; Tue, 7 Feb 2012 16:34:59 +0100 (CET) Received: from [192.168.254.3] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id C394258CEF for ; Tue, 7 Feb 2012 16:34:53 +0100 (CET) Message-ID: <4F31449C.9040604@nlnetlabs.nl> Date: Tue, 07 Feb 2012 16:34:52 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120207151820.GE9478@crankycanuck.ca> In-Reply-To: <20120207151820.GE9478@crankycanuck.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at rotring X-Virus-Status: Clean Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2012 15:35:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Andrew, I support the default actions you describe. Below are reasons for things I feel more strongly about. > ISSUE 1: Indeterminacy of Indeterminate I feel the first (4033) is a better description. I personally use a definition for this as: this portion of the tree does not have a trust anchor above it (higher up the hierarchy), and therefore is not secure, insecure, or bogus. Note that with the root trust anchor the indeterminate state no longer occurs, since we know everything is covered by that trust anchor. > ISSUE 2: Ignoring CNAME signatures The change requested seems impossible (not compatible with deployed code, and not future compatible with intended feature too) to me, thus I support no change. Best regards, Wouter On 02/07/2012 04:18 PM, Andrew Sullivan wrote: > Dear colleagues, > > We're still in the WGLC on dnssec-bis-updates, but we have some > pending issues to sort out. > > At the moment, we have several issues that have been raised in the > WGLC, but not much in the way of proposed resolution. Sam Weiler says > he is tracking them; and many of the issues have been fairly minor, > but I want to make sure that we don't go back into a long period of > benign neglect of this document, so I'd like to hear some responses. > > The following are substantive issues that require more than minor > changes to the document, and for which we need some answers. I'm > raising them now in the hopes that we can get them closed before WGLC > ends. > > A reminder that WGLC ends at the same time (this) Friday ends. > > ISSUE 1: Indeterminacy of Indeterminate > > In http://www.ietf.org/mail-archive/web/dnsext/current/msg12176.html, > Mohan Parthasarathy argues that RFC 4033 and RFC 4035 have > inconsistent definitions of "Indeterminate". RFC 4033 says this is > what Indeterminate means, in section 5: > > Indeterminate: There is no trust anchor that would indicate that a > specific portion of the tree is secure. This is the default > operation mode. > > RFC 4035 has this definition in section 4.3: > > Indeterminate: An RRset for which the resolver is not able to > determine whether the RRset should be signed, as the resolver is > not able to obtain the necessary DNSSEC RRs. This can occur when > the security-aware resolver is not able to contact security-aware > name servers for the relevant zones. > > These two do seem to be inconsistent. In particular, the latter > apparently can happen when a security-aware resolver with an > appropriate trust anchor can't find an upstream that can handle the DO > bit. Does anyone have an opinion on what to do about this? We will > need to come to some very strong agreement quickly, or it will not be > addressed in this document. > > DEFAULT ACTION: none. Without proposed text that finds strong > support, this issue will be left out of the document. > > ISSUE 2: Ignoring CNAME signatures > > Jiankang Yao has suggested in > http://www.ietf.org/mail-archive/web/dnsext/current/msg12166.html that > language be added to permit ignoring unsigned CNAME records under some > circumstances. I am already on the record as personally opposing this > change, but surely I'm not the only voice here. Does anyone have an > opinion about this? > > DEFAULT ACTION: none. Without proposed text that finds very > strong support, this proposed change will not be included. If a > change is to be added along these lines, it will require a > separate last call on its own, because it is a major change to the > protocol. > > ISSUE 3: Alter section 5.10 > > Paul Hoffman requests a change to section 5.10 in > http://www.ietf.org/mail-archive/web/dnsext/current/msg12173.html. > Speaking only personally, I cannot see any objection to the proposed > sentence, "If a site has only a single trust anchor, the information > in this entire section can safely be skipped." I'm less sure about > the motivational sentences; I'm not even sure they're true. Does > anyone have any thoughts? > > DEFAULT ACTION: Include the "If a site has only a single trust > anchor …" sentence, and exclude the other proposed sentences. > > ISSUE 4: Request to change the language in 5.6 > > This is also a request from Paul Hoffman, in the same review. Is > there any objection to his first formulation? I believe his second > formulation would actually be a significant change to the protocol, > and as shepherd I cannot accept it without a fairly strong signal from > the WG. > > DEFAULT ACTION: Use the first formulation proposed ("In order to > interoperate with implementations that ignore this rule on > sending, resolvers need to allow either the DO bit to be set or > unset when receiving responses.") > > ISSUE 5: The CD bit redux > > Mark Andrews argues in > http://www.ietf.org/mail-archive/web/dnsext/current/msg12133.html that > the advice always to set the CD bit is bad advice. Does anyone else > want to take up his line of argument? If not, I'll rule that he's in > the rough on this. > > Wouter Wijngaards suggests that the discussion around this is too > long, and one of the editors agrees. To find fault where it belongs, > the long appendix on this is there at my insistence, because several > people previously argued that it was necessary to expose the > consequences of different approaches to setting the CD bit, and yet my > finding was that there was rough consensus in favour of the "always > set" approach. In the absence of overwhelming support in favour of > removing the discussion, I think it should stay. If you think it > should be altered, then you need to offer replacement text and not ask > that someone come up with it. Keep in mind that the text, long as it > is, was the subject of protracted discussion. > > DEFAULT ACTION: none. > > Best regards, > > Andrew > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPMUScAAoJEJ9vHC1+BF+N8EoP/0tmCJfE1muvqPaTT1f3fa32 7Fn3/7pBqlV8yPGBk00T+ntDCep/EHk/yU1Yk1nDRLIltufSPFc5LDeU+04p2Nkq ZOTO3W8uTu8ZQmHM68Ol84zFlog0DFe42V0XOYv9wUI6CNXCiaTyC9q4pjTZw8dR HnoPRPjdIphQuuDWOWAnO/w/gODKqk//CiAHMHosn2H2yQBBujl14Ard3iQKbz0q ytoIPua0z4EYrL9gAl0BkOctVzhtmE4mGEan6AOcvGwxxlDVIRDvgLGvN7bvFxe7 3faUVaLH6wGhYmCHoPYd1Kxm/zLUMhXKkYtLuJ/ICZGyh3hqX6hI17fBtKYccKGf ZPYK/CQ0YLWhKVFl/qTuKXMzcU2A3OmcBcsLWNncIlS2zMjju9Nsvr8qkWXQiP6x lru874L65DhyFuk2/CJz4vfO2sbZmyJinF5P2TVyKz6mKHH7cWj6r+7E6dnKCrc2 W57L0clDml5koNfzQlsWoMuBZGu5Xk+xbhb35CcaLabfx9H1ESqTVDe9w/cOufPV w3OJITPd1SyeglSc1zAheF1ydamkGOf40j4YOwzLJ/A8YOTEjxjmIMEbX+Vg6IIV Gpi5Xrh4WeuJxRBRVyTzg+69dEHdgpqtq+WYVTKgypzZvgO1SWOj+5m3bB+uM0bH ToMTKFX0K4TuqvOC2UDy =JvrZ -----END PGP SIGNATURE----- From ajs@anvilwalrusden.com Tue Feb 7 08:23:54 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2288621F86A5 for ; Tue, 7 Feb 2012 08:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3E1b5nHd1uU for ; Tue, 7 Feb 2012 08:23:53 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 51EE121F869C for ; Tue, 7 Feb 2012 08:23:47 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A4D4A1ECB41D for ; Tue, 7 Feb 2012 16:23:46 +0000 (UTC) Date: Tue, 7 Feb 2012 11:23:44 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120207162344.GH9478@mail.yitter.info> References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F31449C.9040604@nlnetlabs.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2012 16:23:54 -0000 Hi, On Tue, Feb 07, 2012 at 04:34:52PM +0100, W.C.A. Wijngaards wrote: > > I feel the first (4033) is a better description. I personally use a > definition for this as: this portion of the tree does not have a trust > anchor above it (higher up the hierarchy), and therefore is not secure, > insecure, or bogus. Note that with the root trust anchor the > indeterminate state no longer occurs, since we know everything is > covered by that trust anchor. This is extremely interesting and helpful; thanks. I wonder about something, though. What should we call the state you get when you have a validating resolver that can only speak to upstream resolvers that all respond NOTIMP (or similar) to the DO bit? That case appears to be covered by the 4035 definition and not the 4033 one. Is this "unvalidatable" rather than "indeterminate"? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From wouter@nlnetlabs.nl Tue Feb 7 08:54:05 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C7121F8855 for ; Tue, 7 Feb 2012 08:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvt13lic6Gvq for ; Tue, 7 Feb 2012 08:54:04 -0800 (PST) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by ietfa.amsl.com (Postfix) with ESMTP id A871021F884E for ; Tue, 7 Feb 2012 08:54:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id BA2AF58B80 for ; Tue, 7 Feb 2012 17:54:03 +0100 (CET) Received: from [192.168.254.3] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id C593558498 for ; Tue, 7 Feb 2012 17:53:58 +0100 (CET) Message-ID: <4F315725.4010705@nlnetlabs.nl> Date: Tue, 07 Feb 2012 17:53:57 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <20120207162344.GH9478@mail.yitter.info> In-Reply-To: <20120207162344.GH9478@mail.yitter.info> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at rotring X-Virus-Status: Clean Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2012 16:54:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Andrew, On 02/07/2012 05:23 PM, Andrew Sullivan wrote: > On Tue, Feb 07, 2012 at 04:34:52PM +0100, W.C.A. Wijngaards wrote: >> >> I feel the first (4033) is a better description. I personally use a >> definition for this as: this portion of the tree does not have a trust >> anchor above it (higher up the hierarchy), and therefore is not secure, >> insecure, or bogus. Note that with the root trust anchor the >> indeterminate state no longer occurs, since we know everything is >> covered by that trust anchor. > > This is extremely interesting and helpful; thanks. I wonder about > something, though. What should we call the state you get when you > have a validating resolver that can only speak to upstream resolvers > that all respond NOTIMP (or similar) to the DO bit? That case appears > to be covered by the 4035 definition and not the 4033 one. Is this > "unvalidatable" rather than "indeterminate"? This would make data that is not covered by a trust anchor indeterminate (like it was before, you have no anchor that covers it so can check no signatures). Data covered by a trust anchor becomes bogus, because you cannot get the DNSSEC data for zone of the trust anchor, and its delegations need to tell you if the data covered by it is secure or insecure; these signatures are withheld, and this makes the result bogus. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPMVckAAoJEJ9vHC1+BF+NRoYP/A+wlagWZORkKRV6MsSc7gwh yKxg7uRRDizkiVyA9cvpW8HeRAWIhPpZIseraUWG1aAM6pnuUuwHOWvpHtPvvg8S Jtf2EvYx+mUxgnoloxplTAJsDzoWNcIv1CVaQbxXl3FAdJ1HcT10ETduRXBhE6KI 11yyv+knqsFL4bv2yiNXUrumH41J7VYYC2LYTTexohMO3+kXPbCybR0hKE+7+P1T rbwbpBPTwPCaILTaLzAKML3LAM3f+DfvNTX+WFpAehhVvjOVndtkgcBw6n/2LzVu qP3YyB4N0Hwp/o94hlcsRbnitCfcQ7EGUkd9+knc1ZMMOWBaIABtYagN+fcspKNI oIYKjBAkJoCBMFh9oveCQ3qiGYdtqHsaKaF/I15AZ6Zz0+S2zXoRlTQulxo2oclx jsu5CZDMC7SuyYYkHPjndbDFTZgt0Mgi7n+peQGMoy2DeWI+7HEta0nizUVJwofT QJI8Wx9WaI4Q+n+exm2EhwD6e6vFX+zytEbaFpTq0NABYlAq87IclGwcG4scgqaL XwwNN8F/2z8ia194uGF5k57orqYOsA5qYlx/XDmpSK8zZuOYX+/7td//oj0Z5aY2 z7mV5+3E59uI/wspMcMNChrD6bKsYqwx51TD/mODspa8t2mOTbvbmO6TCIXtofnh 8mQerDa0DoV3MNbHI/LO =VZI5 -----END PGP SIGNATURE----- From Ed.Lewis@neustar.biz Tue Feb 7 09:14:58 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F2021F885B for ; Tue, 7 Feb 2012 09:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.142 X-Spam-Level: X-Spam-Status: No, score=-106.142 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXaYWvmpK4Cz for ; Tue, 7 Feb 2012 09:14:58 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4241A21F8800 for ; Tue, 7 Feb 2012 09:14:58 -0800 (PST) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q17HEt05056341; Tue, 7 Feb 2012 12:14:56 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [172.17.20.117] by Work-Laptop-2.local (PGP Universal service); Tue, 07 Feb 2012 09:14:56 -0800 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 07 Feb 2012 09:14:56 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F31449C.9040604@nlnetlabs.nl> References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> Date: Tue, 7 Feb 2012 09:14:53 -0800 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2012 17:14:59 -0000 At 16:34 +0100 2/7/12, W.C.A. Wijngaards wrote: >insecure, or bogus. Note that with the root trust anchor the >indeterminate state no longer occurs, since we know everything is >covered by that trust anchor. I disagree with that. The Internet that we usually think about as being the only one is what I call the "global public Internet". For the global public Internet, the DNS in common use does have a trust anchor for it's root zone so the assertion holds for the majority of cases, but then again only for recursive servers that have the trust anchor. There are other inter-networks that use the DNS protocol. In at least one of these, DNSSEC has not been deployed. And, you can stretch this to the case of a recursive server, on the global public Internet, that does not have the root anchor configured - and may have another anchor. To such a server, validating some DNS data is impossible (incalculable). The protocol cannot be defined assuming one particular mode of operation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From paul.hoffman@vpnc.org Tue Feb 7 10:09:01 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E4521F8694 for ; Tue, 7 Feb 2012 10:09:01 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTt+HDLRpEwq for ; Tue, 7 Feb 2012 10:09:01 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 97A1D21F8616 for ; Tue, 7 Feb 2012 10:08:58 -0800 (PST) Received: from [10.224.138.41] (m180f36d0.tmodns.net [208.54.15.24]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q17I8thX083719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 7 Feb 2012 11:08:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <20120207151820.GE9478@crankycanuck.ca> Date: Tue, 7 Feb 2012 13:08:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120207151820.GE9478@crankycanuck.ca> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1251.1) Subject: [dnsext] What is indeterminate X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2012 18:09:01 -0000 On Feb 7, 2012, at 10:18 AM, Andrew Sullivan wrote: > ISSUE 1: Indeterminacy of Indeterminate >=20 > In http://www.ietf.org/mail-archive/web/dnsext/current/msg12176.html, > Mohan Parthasarathy argues that RFC 4033 and RFC 4035 have > inconsistent definitions of "Indeterminate". RFC 4033 says this is > what Indeterminate means, in section 5: >=20 > Indeterminate: There is no trust anchor that would indicate that a > specific portion of the tree is secure. This is the default > operation mode. >=20 > RFC 4035 has this definition in section 4.3:=20 >=20 > Indeterminate: An RRset for which the resolver is not able to > determine whether the RRset should be signed, as the resolver is > not able to obtain the necessary DNSSEC RRs. This can occur when > the security-aware resolver is not able to contact security-aware > name servers for the relevant zones. >=20 > These two do seem to be inconsistent. In particular, the latter > apparently can happen when a security-aware resolver with an > appropriate trust anchor can't find an upstream that can handle the DO > bit. Does anyone have an opinion on what to do about this? We will > need to come to some very strong agreement quickly, or it will not be > addressed in this document. >=20 > DEFAULT ACTION: none. Without proposed text that finds strong > support, this issue will be left out of the document. =20 A request to the folks who have done DNSSEC much longer than I have: = please do resolve this somehow. It affected the development of DANE, and = will probably nail others later. --Paul Hoffman From suruti94@gmail.com Tue Feb 7 11:51:30 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6459221F873B for ; Tue, 7 Feb 2012 11:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByHLXXLkquzm for ; Tue, 7 Feb 2012 11:51:29 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE7B21F8638 for ; Tue, 7 Feb 2012 11:51:29 -0800 (PST) Received: by qafi29 with SMTP id i29so2938435qaf.10 for ; Tue, 07 Feb 2012 11:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kdBSC4WunUJnocG7QqlUBjSuUhvmd052x8mkqRwh7XA=; b=TxZAaEDCBoHayGmzfv+p3L7rgYYtpHifT0D8OvccpYV0xRZ5ElqJPp3OT3ZSogg8y0 cBXqGK3lYhPC5trNJS97TmLhJQsMU+GU66RmAqzeBt3LXS3dX9OhRuQl5d6THLKu7dTj gOCJKo/lGNwg1Y917vxBDxEKB6QzyoNTWCLZg= MIME-Version: 1.0 Received: by 10.224.188.140 with SMTP id da12mr23817816qab.49.1328644288533; Tue, 07 Feb 2012 11:51:28 -0800 (PST) Received: by 10.229.20.193 with HTTP; Tue, 7 Feb 2012 11:51:28 -0800 (PST) In-Reply-To: References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> Date: Tue, 7 Feb 2012 11:51:28 -0800 Message-ID: From: Mohan Parthasarathy To: Edward Lewis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2012 19:51:30 -0000 On Tue, Feb 7, 2012 at 9:14 AM, Edward Lewis wrote: > At 16:34 +0100 2/7/12, W.C.A. Wijngaards wrote: > >> insecure, or bogus. =A0Note that with the root trust anchor the >> indeterminate state no longer occurs, since we know everything is >> covered by that trust anchor. > > > I disagree with that. > > The Internet that we usually think about as being the only one is what I > call the "global public Internet". =A0For the global public Internet, the= DNS > in common use does have a trust anchor for it's root zone so the assertio= n > holds for the majority of cases, but then again only for recursive server= s > that have the trust anchor. > > There are other inter-networks that use the DNS protocol. =A0In at least = one > of these, DNSSEC has not been deployed. > > And, you can stretch this to the case of a recursive server, on the globa= l > public Internet, that does not have the root anchor configured - and may > have another anchor. =A0To such a server, validating some DNS data is > impossible (incalculable). > > The protocol cannot be defined assuming one particular mode of operation. > Before getting to define this precisely, we should try to understand the different cases that can occur and see whether we all agree on the error status for the different cases. Some RRSet needs to be validated. The RRSet was fetched with the DO bit set= . - We are able to get the RRSIGs back for the RRset. But unable to validate completely because we are not able to get the DNSKEY RRSET or not able to fetch the DS record. Going by 4035, this is Insecure. Two problems here. First, it is also possible that you talked to the DNSSEC-unaware server which does not know how to fetch the DS record. Secondly, this could be a fake signature for which you can never establish the trust. Do we want to declare Insecure in both these cases ? - We are able to get the RRSIGs back for the RRSet. But unable to validate the signatures because it is expired. This is Bogus as per 4035. - We are unable to get the RRSIGs back, but we got some response from the server i.e., the main RRSet itself. Missing signatures. As per 4035, this is Bogus. But then this could be a bad CPE. Do we want to declare this Bogus ? We can create more examples, but it looks to me that there are only two error cases. 1) We get some DNSSEC RRs back but can't validate. Just being able to partially validate without tracing back to the trust anchor is equally bad as not being able to validate the signatures. 2) We get no DNSSEC RRs back. This could be a problem in the path or the zone is not signed. We can't tell the difference without some extra configuration. How does it help the application to make this more fine grained ? -mohan > -- > -=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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice mess= age at +1-571-434-5468 > > 2012...time to reuse those 1984 calendars! > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From marka@isc.org Tue Feb 7 14:22:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC4121F86C2 for ; Tue, 7 Feb 2012 14:22:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC5On8BAH9uu for ; Tue, 7 Feb 2012 14:22:15 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2202721F86C1 for ; Tue, 7 Feb 2012 14:22:15 -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 9D4CFC942D; Tue, 7 Feb 2012 22:22:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b866:ffc:24d5:68f1]) (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 45D83216C6B; Tue, 7 Feb 2012 22:22: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 47F671CF6C8B; Wed, 8 Feb 2012 09:21:59 +1100 (EST) To: "W.C.A. Wijngaards" From: Mark Andrews References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <20120207162344.GH9478@mail.yitter.info> <4F315725.4010705@nlnetlabs.nl> In-reply-to: Your message of "Tue, 07 Feb 2012 17:53:57 BST." <4F315725.4010705@nlnetlabs.nl> Date: Wed, 08 Feb 2012 09:21:59 +1100 Message-Id: <20120207222159.47F671CF6C8B@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2012 22:22:15 -0000 In message <4F315725.4010705@nlnetlabs.nl>, "W.C.A. Wijngaards" writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Andrew, > > On 02/07/2012 05:23 PM, Andrew Sullivan wrote: > > On Tue, Feb 07, 2012 at 04:34:52PM +0100, W.C.A. Wijngaards wrote: > >> > >> I feel the first (4033) is a better description. I personally use a > >> definition for this as: this portion of the tree does not have a trust > >> anchor above it (higher up the hierarchy), and therefore is not secure, > >> insecure, or bogus. Note that with the root trust anchor the > >> indeterminate state no longer occurs, since we know everything is > >> covered by that trust anchor. > > > > This is extremely interesting and helpful; thanks. I wonder about > > something, though. What should we call the state you get when you > > have a validating resolver that can only speak to upstream resolvers > > that all respond NOTIMP (or similar) to the DO bit? That case appears > > to be covered by the 4035 definition and not the 4033 one. Is this > > "unvalidatable" rather than "indeterminate"? > > This would make data that is not covered by a trust anchor indeterminate > (like it was before, you have no anchor that covers it so can check no > signatures). Data covered by a trust anchor becomes bogus, because you > cannot get the DNSSEC data for zone of the trust anchor, and its > delegations need to tell you if the data covered by it is secure or > insecure; these signatures are withheld, and this makes the result bogus. The delegation is secure or insecure. The data is secure, bogus or indeterminate. When you follow a insecure delegation the data is no longer under the trust anchor, i.e. there is no chain from a trust anchor to it. > Best regards, > Wouter -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Tue Feb 7 15:31:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5075821F87A7 for ; Tue, 7 Feb 2012 15:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g416ZjJoGIqz for ; Tue, 7 Feb 2012 15:31:24 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B3FF021F87B7 for ; Tue, 7 Feb 2012 15:31: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 B1CC7C942B; Tue, 7 Feb 2012 23:31:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b866:ffc:24d5:68f1]) (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 576A8216C6A; Tue, 7 Feb 2012 23:31:10 +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 1A38B1CF75E6; Wed, 8 Feb 2012 10:31:08 +1100 (EST) To: Paul Hoffman From: Mark Andrews References: <20120207151820.GE9478@crankycanuck.ca> In-reply-to: Your message of "Tue, 07 Feb 2012 13:08:56 CDT." Date: Wed, 08 Feb 2012 10:31:08 +1100 Message-Id: <20120207233108.1A38B1CF75E6@drugs.dv.isc.org> Cc: DNSEXT Working Group Subject: Re: [dnsext] What is indeterminate X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2012 23:31:25 -0000 In message , Paul Hoffman writes : > On Feb 7, 2012, at 10:18 AM, Andrew Sullivan wrote: > > > ISSUE 1: Indeterminacy of Indeterminate > > > > In http://www.ietf.org/mail-archive/web/dnsext/current/msg12176.html, > > Mohan Parthasarathy argues that RFC 4033 and RFC 4035 have > > inconsistent definitions of "Indeterminate". RFC 4033 says this is > > what Indeterminate means, in section 5: > > > > Indeterminate: There is no trust anchor that would indicate that a > > specific portion of the tree is secure. This is the default > > operation mode. > > > > RFC 4035 has this definition in section 4.3: > > > > Indeterminate: An RRset for which the resolver is not able to > > determine whether the RRset should be signed, as the resolver is > > not able to obtain the necessary DNSSEC RRs. This can occur when > > the security-aware resolver is not able to contact security-aware > > name servers for the relevant zones. > > > > These two do seem to be inconsistent. In particular, the latter > > apparently can happen when a security-aware resolver with an > > appropriate trust anchor can't find an upstream that can handle the DO > > bit. Does anyone have an opinion on what to do about this? We will > > need to come to some very strong agreement quickly, or it will not be > > addressed in this document. > > > > DEFAULT ACTION: none. Without proposed text that finds strong > > support, this issue will be left out of the document. > > A request to the folks who have done DNSSEC much longer than I have: please d > o resolve this somehow. It affected the development of DANE, and will probabl > y nail others later. This really is a "how many angels can you fit on a pin head" argument. You can prove a answer is secure with respect to the trust anchors you have. You can determine that you can't validate as secure with the trust anchors you have. Everything else is indeterminate/insecure as far as the application is concerned. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul.hoffman@vpnc.org Tue Feb 7 16:55:49 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01EB11E8098 for ; Tue, 7 Feb 2012 16:55:49 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkfEckXfIIxZ for ; Tue, 7 Feb 2012 16:55:49 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 37AB911E8089 for ; Tue, 7 Feb 2012 16:55:49 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q180tjni002574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Feb 2012 17:55:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120207233108.1A38B1CF75E6@drugs.dv.isc.org> Date: Tue, 7 Feb 2012 16:55:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <69BA3AE6-AB79-4AE1-A054-35BC172CAFC8@vpnc.org> References: <20120207151820.GE9478@crankycanuck.ca> <20120207233108.1A38B1CF75E6@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1251.1) Cc: DNSEXT Working Group Subject: Re: [dnsext] What is indeterminate X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2012 00:55:49 -0000 On Feb 7, 2012, at 3:31 PM, Mark Andrews wrote: > This really is a "how many angels can you fit on a pin head" argument. No, it is not, and please don't try to dissuade people from answering. = There are two different definitions in the respective RFCs. You may not = care which is right, but the rest of us do. > You can prove a answer is secure with respect to the trust anchors you = have. > You can determine that you can't validate as secure with the trust = anchors > you have. > Everything else is indeterminate/insecure as far as the application is > concerned. Is that proposed text for the dnssec-bis document? --Paul Hoffman From marka@isc.org Tue Feb 7 17:54:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E7821F860D for ; Tue, 7 Feb 2012 17:54:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIOiZbcZBO7U for ; Tue, 7 Feb 2012 17:54:30 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2530621F8602 for ; Tue, 7 Feb 2012 17:54:15 -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 339D0C941E for ; Wed, 8 Feb 2012 01:54:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b866:ffc:24d5:68f1]) (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 EAC60216C6A for ; Wed, 8 Feb 2012 01:54:03 +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 EC7BD1CF9568 for ; Wed, 8 Feb 2012 12:54:01 +1100 (EST) To: dnsext@ietf.org From: Mark Andrews Date: Wed, 08 Feb 2012 12:54:01 +1100 Message-Id: <20120208015401.EC7BD1CF9568@drugs.dv.isc.org> Subject: [dnsext] some words X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2012 01:54:31 -0000 CD bit handling is in a couple of places in 4035. The alternative to this is defining a way to pass trust anchors and time from the stub to the recursive server to be used to find answers which will pass validation on the stub resolver. I'll see if I can come up with similar words for the recursive server that is talking to another recursive server. Section 4.9.2 of RFC 4035 is hereby replaced with the following: Old: 4.9.2. Handling of the CD Bit A non-validating security-aware stub resolver SHOULD NOT set the CD bit when sending queries unless it is requested by the application layer, as by definition, a non-validating stub resolver depends on the security-aware recursive name server to perform validation on its behalf. A validating security-aware stub resolver SHOULD set the CD bit, because otherwise the security-aware recursive name server will answer the query using the name server's local policy, which may prevent the stub resolver from receiving data that would be acceptable to the stub resolver's local policy. New: 4.9.2. Handling of the CD Bit A non-validating security-aware stub resolver SHOULD NOT set the CD bit when sending queries unless it is requested by the application layer, as by definition, a non-validating stub resolver depends on the security-aware recursive name server to perform validation on its behalf. A validating security-aware stub resolver SHOULD first try queries with the CD bit clear, then if SERVFAIL is returned, retry the query with the CD bit set. The CD=0 query allow the recursive server to reject answers from misconfigured / stale authorititative servers. The CD=1 query allows the stub resolver to talk though a recursive server with stale trust anchors or a misconfigured clock. In either case it validates the answer it receives from the recursive server prior to passing it to the application. It is RECOMMENDED that the recursive server be configured with a super-set of the trust anchors used by its clients. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From wouter@nlnetlabs.nl Wed Feb 8 00:31:03 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC20521F8718 for ; Wed, 8 Feb 2012 00:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAwVCnC93E3E for ; Wed, 8 Feb 2012 00:31:03 -0800 (PST) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by ietfa.amsl.com (Postfix) with ESMTP id B2CCC21F8714 for ; Wed, 8 Feb 2012 00:31:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 39D2358CED for ; Wed, 8 Feb 2012 09:31:01 +0100 (CET) Received: from [192.168.254.3] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id B0AE558CD6 for ; Wed, 8 Feb 2012 09:30:51 +0100 (CET) Message-ID: <4F3232B6.3060505@nlnetlabs.nl> Date: Wed, 08 Feb 2012 09:30:46 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at rotring X-Virus-Status: Clean Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2012 08:31:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mohan, The definition of indeterminate was wrong in RFC4035, and you now seem to think DNSSEC is riddled with downgrade. There is no downgrade, because the security-states are the outcome of the chain-of-trust algorithm, not implemented from its definitions in RFC4035. At any step, if the algorithm, that is validating the chain of trust from a trust anchor to the data, knows that it must have DNSSEC data, but this is not available, the result becomes bogus. Why the data is not available does not matter. The algorithm knows if DNSSEC data must be available, because this is what NSEC and DS records tell at delegation points. DNSSEC has the interesting property that it can tell if a zone is signed or not. And it can do so securely. This is very nice for backwards compatibility. And it solves all of the things you ask for. On 02/07/2012 08:51 PM, Mohan Parthasarathy wrote: > On Tue, Feb 7, 2012 at 9:14 AM, Edward Lewis wrote: >> At 16:34 +0100 2/7/12, W.C.A. Wijngaards wrote: >> >>> insecure, or bogus. Note that with the root trust anchor the >>> indeterminate state no longer occurs, since we know everything is >>> covered by that trust anchor. >> >> >> I disagree with that. >> >> The Internet that we usually think about as being the only one is what I >> call the "global public Internet". For the global public Internet, the DNS >> in common use does have a trust anchor for it's root zone so the assertion >> holds for the majority of cases, but then again only for recursive servers >> that have the trust anchor. >> >> There are other inter-networks that use the DNS protocol. In at least one >> of these, DNSSEC has not been deployed. >> >> And, you can stretch this to the case of a recursive server, on the global >> public Internet, that does not have the root anchor configured - and may >> have another anchor. To such a server, validating some DNS data is >> impossible (incalculable). >> >> The protocol cannot be defined assuming one particular mode of operation. >> > Before getting to define this precisely, we should try to understand > the different cases that can occur and see whether we all agree on the > error status for the different cases. Why data cannot be fetched is not a factor in the end result. This simplifies the cases to: cannot get the proper DNSSEC data, can get proper DNSSEC data but it's invalid, can get proper DNSSEC data and it's ok. And the results are bogus, bogus, secure. If you find an insecure delegation it is insecure. If there is no applicable trust anchor, the result is indeterminate (that is effectively just like insecure). > Some RRSet needs to be validated. The RRSet was fetched with the DO bit set. > > - We are able to get the RRSIGs back for the RRset. But unable to > validate completely because we are not able to get the DNSKEY RRSET or > not able to fetch the DS record. Going by 4035, this is Insecure. Two No, it is bogus. If you cannot get the DS and DNSKEY records, the result is bogus. > problems here. First, it is also possible that you talked to the > DNSSEC-unaware server which does not know how to fetch the DS record. > Secondly, this could be a fake signature for which you can never > establish the trust. Do we want to declare Insecure in both these > cases ? It is not important if the upstream server is DNSSEC unaware or if it is lying. If you cannot get the proper DNSSEC data the result is bogus. > - We are able to get the RRSIGs back for the RRSet. But unable to > validate the signatures because it is expired. This is Bogus as per > 4035. Yes, expired is bogus. > - We are unable to get the RRSIGs back, but we got some response from > the server i.e., the main RRSet itself. Missing signatures. As per > 4035, this is Bogus. But then this could be a bad CPE. Do we want to > declare this Bogus ? Yes it is bogus. I understand the definition of Indeterminate is wrong in 4035; but no, downgrade attacks by the removal of DNSSEC data result in bogus. There are no excuses (i.e. being a CPE, being old, or being unaware) that would make the result non-bogus. > We can create more examples, but it looks to me that there are only > two error cases. > > 1) We get some DNSSEC RRs back but can't validate. Just being able to > partially validate without tracing back to the trust anchor is equally > bad as not being able to validate the signatures. Yes, that is bogus in today's implementations. > 2) We get no DNSSEC RRs back. This could be a problem in the path or > the zone is not signed. We can't tell the difference without some > extra configuration. You can tell the difference because the chain-of-trust is signed itself, and this extends from the trust anchor to the data you just got, and thus you know if this zone is signed or not. And thus in your question, the unsigned zone is ok(insecure), and the signed-zone-missing-DNSSEC RRs is not ok(bogus). > How does it help the application to make this more fine grained ? No, the application just wants all bogus data to be removed. Data that is secure and data that is not DNSSEC signed is what it wants. Because of the chain-of-trust the validator knows which parts of the space below a trust anchor is signed (and must have DNSSEC available) and which part is unsigned. This property could be the cause that made insecure and indeterminate terms exist, as indeterminate is not really processed but simply the absence of a covering trust anchor, just like in the case where you had no trust anchors at all. But then insecure needs processing: you have to validate the chain of trust from the trust anchor to the insecure-delegation point, and only then can you conclude that the data is insecure. This is something internal to the DNSSEC validator, and not particularly impressive to the application, that likely just wants to know if the data was DNSSEC-signed (if so: secure or bogus) or if the data was not DNSSEC-signed (as determined with the configured set of trust anchors). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPMjK2AAoJEJ9vHC1+BF+NxVUQAIyQ4nPk7Syogn9uh4z890yJ kmPxslbpvHru47OxKd0tYvozldnP32z1+JToGSZR8qRU+w9SAQLutnFkqCU28x95 QUAot8G157kxZT95zhdjVqpbyUYDYwKKUY4jqplq4IuyIm1ewEOcwAS8Sak1o9Gr 17Xs4aCpl55QmTCZAlP+r6SwCDY738Py9I51BJhifAB9HdkT6XK1+bsbMSiFhG+o koICUhKaLDthmFvBrHBVCiW4xD5uk8ww2jlMNXv2LaRT05tfVjLC0EfboFn3kEkg +c39M8Bm4GlkQvB1Wr37AEPn/m0PYbsC2lOEQL/04QRGiAcDTtjo4bzzsKb6yFFi cWg8mUsldcSikZB+YFVS0RRLGcKCWhOVHxxMqKlA/IdzBU02JiGaYqZU9SKaakkc 8AEFJkQdUYerh4BPeiwlzpy4uS3kiJU7A8hKnQSIuRR1xo7r28NKuvrxLnw5b3es kExf4pyb5zitBPx6c0ERQ1SJrw9VU3DipJb6dY/QW5uceHvfJlYQiXN6nGGKUkvw FlupnGef8TvHvgnHieiD9t3WRh+7WNKdMCs627U/Ym8VC0gcTXK3WORMdwrAVq7j I7wEkXH4ms9sJD09ZGysNjlRylKvMzHlxxIjl3kpFmvGwus//BxMq8GCT+08cJ9Z 5AOnYo5AWqWqa8nipilZ =dpSm -----END PGP SIGNATURE----- From marka@isc.org Wed Feb 8 02:08:48 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A8821F84E0 for ; Wed, 8 Feb 2012 02:08:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQQ0Pvj-g4iV for ; Wed, 8 Feb 2012 02:08:47 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A1B2321F84DA for ; Wed, 8 Feb 2012 02:08:47 -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 88A61C942D; Wed, 8 Feb 2012 10:08:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:fce7:bd7:5736:f19f]) (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 31895216C6A; Wed, 8 Feb 2012 10:08: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 B904D1D02863; Wed, 8 Feb 2012 21:08:34 +1100 (EST) To: "W.C.A. Wijngaards" From: Mark Andrews References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <4F3232B6.3060505@nlnetlabs.nl> In-reply-to: Your message of "Wed, 08 Feb 2012 09:30:46 BST." <4F3232B6.3060505@nlnetlabs.nl> Date: Wed, 08 Feb 2012 21:08:34 +1100 Message-Id: <20120208100834.B904D1D02863@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2012 10:08:48 -0000 In message <4F3232B6.3060505@nlnetlabs.nl>, "W.C.A. Wijngaards" writes: > No, the application just wants all bogus data to be removed. Data that > is secure and data that is not DNSSEC signed is what it wants. Because > of the chain-of-trust the validator knows which parts of the space below > a trust anchor is signed (and must have DNSSEC available) and which part > is unsigned. More correctly it knows if it should be able to get a signed answer with signatures it is capable of verifying or not. A zone can be insecure, as far as the validator is concerned, even if there are DS records in the parent zone and the validator treats the parent zone as secure. > This property could be the cause that made insecure and > indeterminate terms exist, as indeterminate is not really processed but > simply the absence of a covering trust anchor, just like in the case > where you had no trust anchors at all. But then insecure needs > processing: you have to validate the chain of trust from the trust > anchor to the insecure-delegation point, and only then can you conclude > that the data is insecure. No, you can conclude that you don't expect to be able to validate it. The break point may or may not be at a insecure delegation (no DS records in parent zone). In reality the first step of validation is determining if there is a trust anchor that is could potentially result in the data being declared secure. From the application's perspective there is no difference if the data came from a zone that was not under a configured trust anchor or from a zone to which there is not a trust chain supported by the validator. > This is something internal to the DNSSEC > validator, and not particularly impressive to the application, that > likely just wants to know if the data was DNSSEC-signed (if so: secure > or bogus) or if the data was not DNSSEC-signed (as determined with the > configured set of trust anchors). No, it want to know if it is secure or insecure (insecure data can still be signed data). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From wouter@nlnetlabs.nl Wed Feb 8 02:40:03 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0840721F85D7 for ; Wed, 8 Feb 2012 02:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYc9N3ii0w5k for ; Wed, 8 Feb 2012 02:40:02 -0800 (PST) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by ietfa.amsl.com (Postfix) with ESMTP id 6433121F85D2 for ; Wed, 8 Feb 2012 02:40:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 8060458498; Wed, 8 Feb 2012 11:40:01 +0100 (CET) Received: from [192.168.254.3] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id A7B2D58CEF; Wed, 8 Feb 2012 11:39:55 +0100 (CET) Message-ID: <4F3250FA.5020709@nlnetlabs.nl> Date: Wed, 08 Feb 2012 11:39:54 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Mark Andrews References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <4F3232B6.3060505@nlnetlabs.nl> <20120208100834.B904D1D02863@drugs.dv.isc.org> In-Reply-To: <20120208100834.B904D1D02863@drugs.dv.isc.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at rotring X-Virus-Status: Clean Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2012 10:40:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, On 02/08/2012 11:08 AM, Mark Andrews wrote: > More correctly it knows if it should be able to get a signed answer > with signatures it is capable of verifying or not. A zone can be > insecure, as far as the validator is concerned, even if there are > DS records in the parent zone and the validator treats the parent > zone as secure. You are more correct in applying the validation implementation support rules. > No, you can conclude that you don't expect to be able to validate > it. The break point may or may not be at a insecure delegation (no > DS records in parent zone). Thus the set of trust anchors that is configured, and their chains of trust, determine a number of zones that the validator can securely determine that are signed and it has the implementation for to dnssec-validate it. If dnssec data needed to securely determine this is unavailable or invalid then the result is bogus Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPMlD6AAoJEJ9vHC1+BF+NJ+kP/jT8sktzUbrrQwWAFw3fpRqm ePWDlBFew3f+pS43Zp206ETae/64vVcDMd2KNOtF5lhEOKZZlx9tu6V8Xx+ZT7hZ OPuuhC/z4JyQ4FL7WF1zQaXgpwXhhOgyLMo1VtyxxUz1eJnsJLNGUWEm3CH7JBT1 Cb6FaDftQ3q1ca/sq+gqFQCfwSyOOpfegDTwLUv8ja8zCg2Z30DMnWCjEwJGdppC +tYBV3w6gitDW7wIlheyfcFdbIpxr/zwo3Afvs51KDFLt5ybV9A3VeoEEvbagr+d mz+VPSR8lD5H/M0/gzRIof7kIJhkIh7nE8lGyH4m5QATltREbRluNH3SpXv97ZaJ i7+cumiCp+B6iR84r7YWqEcmpcOBNk5uglUEdVS2J91APjkunPMK+tVzXk+bocXY USS7ze88ZexZkdFKIMM1dd2Ui0ttjfpdJ2LAg64cDzLtBHw3JtyXxKNfvsSEOd5h v3Cm+JfDfpo7nNGTL/G86lpVi222zsB49lPlg2TnjRS2q4Q60O7uPNpUJpd6EMbf MPabfnTbnOic37+N11BFPo6bDFZHsVGjxxgLPxiIF6yPYZsMxeZR/1cI2qb1x+mC 3ejfPa2ibffN1RKhtnut/+0QJ3R16Jlal189/ZMMSwRe3BMncAuCgMgYkJDEg1hT GVVdJl5qv5/efTX1mec8 =bWgT -----END PGP SIGNATURE----- From bmanning@karoshi.com Wed Feb 8 04:32:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45F921F864E for ; Wed, 8 Feb 2012 04:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.35 X-Spam-Level: X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJNwcnRarrDi for ; Wed, 8 Feb 2012 04:32:15 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id A673B21F8635 for ; Wed, 8 Feb 2012 04:32:14 -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 q18CW3aB027668; Wed, 8 Feb 2012 12:32:03 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q18CW2bl027667; Wed, 8 Feb 2012 12:32:02 GMT Date: Wed, 8 Feb 2012 12:32:02 +0000 From: bmanning@vacation.karoshi.com To: "W.C.A. Wijngaards" Message-ID: <20120208123202.GC25766@vacation.karoshi.com.> References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F31449C.9040604@nlnetlabs.nl> User-Agent: Mutt/1.4.1i Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2012 12:32:16 -0000 On Tue, Feb 07, 2012 at 04:34:52PM +0100, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1 > Hi Andrew, > I support the default actions you describe. Below are reasons forthings I feel more strongly about. > > ISSUE 1: Indeterminacy of Indeterminate > I feel the first (4033) is a better description. I personally use adefinition for this as: this portion of the tree does not have a trustanchor above it (higher up the hierarchy), and therefore is not secure,insecure, or bogus. Note that with the root trust anchor theindeterminate state no longer occurs, since we know everything iscovered by that trust anchor. Which root? The ICANN root? My corporate root? Folks use IP and DNS in networks that may not be connected to the "public" Internet and thus to the ICANN root key. So I would say that there is existence proof that you can find the ICANN root trust anchor in an indeterminate state. I would hope your code is agile enough to cope. > > ISSUE 2: Ignoring CNAME signatures > The change requested seems impossible (not compatible with deployedcode, and not future compatible with intended feature too) to me, thus Isupport no change. > Best regards, Wouter /bill From ebw@abenaki.wabanaki.net Wed Feb 8 06:47:59 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773DC21F85EE for ; Wed, 8 Feb 2012 06:47:59 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF4Cz7jqShQI for ; Wed, 8 Feb 2012 06:47:59 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9B42D21F85EC for ; Wed, 8 Feb 2012 06:47:57 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q18C4SVK057683 for ; Wed, 8 Feb 2012 07:04:28 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4F328B16.7030006@abenaki.wabanaki.net> Date: Wed, 08 Feb 2012 09:47:50 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <20120208123202.GC25766@vacation.karoshi.com.> In-Reply-To: <20120208123202.GC25766@vacation.karoshi.com.> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 14:47:59 -0000 On 2/8/12 7:32 AM, bmanning@vacation.karoshi.com wrote: >> I feel the first (4033) is a better description. I personally use adefinition for this as: this portion of the tree does not have a trustanchor above it (higher up the hierarchy), and therefore is not secure,insecure, or bogus. Note that with the root trust anchor theindeterminate state no longer occurs, since we know everything iscovered by that trust anchor. > Which root? The ICANN root? My corporate root? > Folks use IP and DNS in networks that may not be connected to the > "public" Internet and thus to the ICANN root key. Futher, there exists one or more networks connected to the "public" Internet (non-locally routed prefixes) for which the IANA root zone does not completely determine the root zone, and for which one or more zone-restricted trust anchors would be insufficient. > So I would say that there is existence proof that you can find > the ICANN root trust anchor in an indeterminate state. Agree. Eric From suruti94@gmail.com Wed Feb 8 10:45:48 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43C721F85FB for ; Wed, 8 Feb 2012 10:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOK7BjCPh3cL for ; Wed, 8 Feb 2012 10:45:47 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7607721F85F7 for ; Wed, 8 Feb 2012 10:45:47 -0800 (PST) Received: by qcsg13 with SMTP id g13so573048qcs.31 for ; Wed, 08 Feb 2012 10:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gT+q8yVahPfoLXKtWAb9GCAS3V5QxlFvJnTwR7HIj9A=; b=iuGe86+e2h8l4PzD0dUGdi+cCkOQgOQ4EU3+mt2O1UQTGGuX/DkZwt8EJEqt5Q+iN+ KR8vjYsUmqUA39xyzaG8A+C/Ub0LsJzI/u72ez+9MV7sRielJXhE9W9ilfnfNy8hK6Cb V8YoTV2v/q+aCXVIs6w8u1b0BCh9Lc0utErxY= MIME-Version: 1.0 Received: by 10.224.33.14 with SMTP id f14mr4590973qad.49.1328726747027; Wed, 08 Feb 2012 10:45:47 -0800 (PST) Received: by 10.229.20.193 with HTTP; Wed, 8 Feb 2012 10:45:46 -0800 (PST) In-Reply-To: <4F3232B6.3060505@nlnetlabs.nl> References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <4F3232B6.3060505@nlnetlabs.nl> Date: Wed, 8 Feb 2012 10:45:46 -0800 Message-ID: From: Mohan Parthasarathy To: "W.C.A. Wijngaards" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2012 18:45:48 -0000 On Wed, Feb 8, 2012 at 12:30 AM, W.C.A. Wijngaards wr= ote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Mohan, > > The definition of indeterminate was wrong in RFC4035, and you now seem > to think DNSSEC is riddled with downgrade. =A0There is no downgrade, > because the security-states are the outcome of the chain-of-trust > algorithm, not implemented from its definitions in RFC4035. > Okay, after reading your response and re-reading 4035 and 4033, I think 4033 definitions for Bogus, Insecure and Indeterminate capture the discussion below more clearly. > On 02/07/2012 08:51 PM, Mohan Parthasarathy wrote: >> On Tue, Feb 7, 2012 at 9:14 AM, Edward Lewis wrot= e: >>> At 16:34 +0100 2/7/12, W.C.A. Wijngaards wrote: >>> >>>> insecure, or bogus. =A0Note that with the root trust anchor the >>>> indeterminate state no longer occurs, since we know everything is >>>> covered by that trust anchor. >>> >>> >>> I disagree with that. >>> >>> The Internet that we usually think about as being the only one is what = I >>> call the "global public Internet". =A0For the global public Internet, t= he DNS >>> in common use does have a trust anchor for it's root zone so the assert= ion >>> holds for the majority of cases, but then again only for recursive serv= ers >>> that have the trust anchor. >>> >>> There are other inter-networks that use the DNS protocol. =A0In at leas= t one >>> of these, DNSSEC has not been deployed. >>> >>> And, you can stretch this to the case of a recursive server, on the glo= bal >>> public Internet, that does not have the root anchor configured - and ma= y >>> have another anchor. =A0To such a server, validating some DNS data is >>> impossible (incalculable). >>> >>> The protocol cannot be defined assuming one particular mode of operatio= n. >>> >> Before getting to define this precisely, we should try to understand >> the different cases that can occur and see whether we all agree on the >> error status for the different cases. > > Why data cannot be fetched is not a factor in the end result. =A0This > simplifies the cases to: cannot get the proper DNSSEC data, can get > proper DNSSEC data but it's invalid, can get proper DNSSEC data and it's > ok. =A0And the results are bogus, bogus, secure. =A0If you find an insecu= re > delegation it is insecure. =A0If there is no applicable trust anchor, the > result is indeterminate (that is effectively just like insecure). > Ok, Bogus, Secure and Insecure applies only when there is an applicable trust anchor. When it is absent, it is indeterminate. That simplifies a lot. >> >> 1) We get some DNSSEC RRs back but can't validate. Just being able to >> partially validate without tracing back to the trust anchor is equally >> bad as not being able to validate the signatures. > > Yes, that is bogus in today's implementations. > >> 2) We get no DNSSEC RRs back. This could be a problem in the path or >> the zone is not signed. We can't tell the difference without some >> extra configuration. > > You can tell the difference because the chain-of-trust is signed itself, > and this extends from the trust anchor to the data you just got, and > thus you know if this zone is signed or not. =A0And thus in your question= , > the unsigned zone is ok(insecure), and the signed-zone-missing-DNSSEC > RRs is not ok(bogus). > >> How does it help the application to make this more fine grained ? > > No, the application just wants all bogus data to be removed. =A0Data that > is secure and data that is not DNSSEC signed is what it wants. =A0Because > of the chain-of-trust the validator knows which parts of the space below > a trust anchor is signed (and must have DNSSEC available) and which part > is unsigned. =A0This property could be the cause that made insecure and > indeterminate terms exist, as indeterminate is not really processed but > simply the absence of a covering trust anchor, just like in the case > where you had no trust anchors at all. =A0But then insecure needs > processing: you have to validate the chain of trust from the trust > anchor to the insecure-delegation point, and only then can you conclude > that the data is insecure. =A0This is something internal to the DNSSEC > validator, and not particularly impressive to the application, that > likely just wants to know if the data was DNSSEC-signed (if so: secure > or bogus) or if the data was not DNSSEC-signed (as determined with the > configured set of trust anchors). > That was very useful discussion. regards mohan > Best regards, > =A0 Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.15 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPMjK2AAoJEJ9vHC1+BF+NxVUQAIyQ4nPk7Syogn9uh4z890yJ > kmPxslbpvHru47OxKd0tYvozldnP32z1+JToGSZR8qRU+w9SAQLutnFkqCU28x95 > QUAot8G157kxZT95zhdjVqpbyUYDYwKKUY4jqplq4IuyIm1ewEOcwAS8Sak1o9Gr > 17Xs4aCpl55QmTCZAlP+r6SwCDY738Py9I51BJhifAB9HdkT6XK1+bsbMSiFhG+o > koICUhKaLDthmFvBrHBVCiW4xD5uk8ww2jlMNXv2LaRT05tfVjLC0EfboFn3kEkg > +c39M8Bm4GlkQvB1Wr37AEPn/m0PYbsC2lOEQL/04QRGiAcDTtjo4bzzsKb6yFFi > cWg8mUsldcSikZB+YFVS0RRLGcKCWhOVHxxMqKlA/IdzBU02JiGaYqZU9SKaakkc > 8AEFJkQdUYerh4BPeiwlzpy4uS3kiJU7A8hKnQSIuRR1xo7r28NKuvrxLnw5b3es > kExf4pyb5zitBPx6c0ERQ1SJrw9VU3DipJb6dY/QW5uceHvfJlYQiXN6nGGKUkvw > FlupnGef8TvHvgnHieiD9t3WRh+7WNKdMCs627U/Ym8VC0gcTXK3WORMdwrAVq7j > I7wEkXH4ms9sJD09ZGysNjlRylKvMzHlxxIjl3kpFmvGwus//BxMq8GCT+08cJ9Z > 5AOnYo5AWqWqa8nipilZ > =3DdpSm > -----END PGP SIGNATURE----- > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From ajs@anvilwalrusden.com Wed Feb 8 10:56:21 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2A821F8636 for ; Wed, 8 Feb 2012 10:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWZP2lk5J+Xj for ; Wed, 8 Feb 2012 10:56:20 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD3721F8635 for ; Wed, 8 Feb 2012 10:56:20 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BC1A31ECB41D for ; Wed, 8 Feb 2012 18:56:19 +0000 (UTC) Date: Wed, 8 Feb 2012 13:56:17 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120208185617.GH11475@mail.yitter.info> References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <4F3232B6.3060505@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3232B6.3060505@nlnetlabs.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2012 18:56:21 -0000 No hat. On Wed, Feb 08, 2012 at 09:30:46AM +0100, W.C.A. Wijngaards wrote: > > On 02/07/2012 08:51 PM, Mohan Parthasarathy wrote: > > > How does it help the application to make this more fine grained ? > > No, the application just wants all bogus data to be removed. Data that > is secure and data that is not DNSSEC signed is what it wants. It seems to me that the above is either a matter of policy or a matter of implementation. That is, some applications will surely only want data that they can know for sure is valid, and in particular will not want any unsigned data no matter what. This could be implemented in more than one way. One is to hand the application everything that is validated and unsigned, and let the application work out which it wants. But another would be for the application to be able to signal this choice to the resolver. No? A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Wed Feb 8 11:49:00 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333FB11E808E for ; Wed, 8 Feb 2012 11:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPASM1E9gaR4 for ; Wed, 8 Feb 2012 11:48:59 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B6A0711E8080 for ; Wed, 8 Feb 2012 11:48:59 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q18JmvmW047397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Feb 2012 12:48:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120208185617.GH11475@mail.yitter.info> Date: Wed, 8 Feb 2012 11:48:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <4F3232B6.3060505@nlnetlabs.nl> <20120208185617.GH11475@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2012 19:49:00 -0000 On Feb 8, 2012, at 10:56 AM, Andrew Sullivan wrote: > No hat. >=20 > On Wed, Feb 08, 2012 at 09:30:46AM +0100, W.C.A. Wijngaards wrote: >>=20 >> On 02/07/2012 08:51 PM, Mohan Parthasarathy wrote: >>=20 >>> How does it help the application to make this more fine grained ? >>=20 >> No, the application just wants all bogus data to be removed. Data = that >> is secure and data that is not DNSSEC signed is what it wants.=20 >=20 > It seems to me that the above is either a matter of policy or a matter > of implementation. That is, some applications will surely only want > data that they can know for sure is valid, and in particular will not > want any unsigned data no matter what. >=20 > This could be implemented in more than one way. One is to hand the > application everything that is validated and unsigned, and let the > application work out which it wants. But another would be for the > application to be able to signal this choice to the resolver. No? In specific, the current proposal for DANE wants to know if it is = getting bogus data. It treats bogus data as quite different than "no = record received". See the bulleted list in section 5 of = draft-ietf-dane-protocol-16.txt. If the DNSEXT WG thinks that it is going to change dnssec-bis to make = the change Wouter suggests, the DANE WG needs to hear about it *very = soon*. --Paul Hoffman From marka@isc.org Wed Feb 8 15:05:41 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F224211E8080 for ; Wed, 8 Feb 2012 15:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YO1K5nx82eL for ; Wed, 8 Feb 2012 15:05:40 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFB121F8562 for ; Wed, 8 Feb 2012 15:05:32 -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 84E2C5F98E5; Wed, 8 Feb 2012 23:05:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3981:7370:f4ed:515c]) (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 486D3216C6A; Wed, 8 Feb 2012 23:05:14 +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 2440F1D0601B; Thu, 9 Feb 2012 10:05:11 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <4F3232B6.3060505@nlnetlabs.nl> In-reply-to: Your message of "Wed, 08 Feb 2012 10:45:46 -0800." Date: Thu, 09 Feb 2012 10:05:10 +1100 Message-Id: <20120208230511.2440F1D0601B@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2012 23:05:41 -0000 In message , Mohan Parthasarathy writes: > On Wed, Feb 8, 2012 at 12:30 AM, W.C.A. Wijngaards wr= > ote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi Mohan, > > > > The definition of indeterminate was wrong in RFC4035, and you now seem > > to think DNSSEC is riddled with downgrade. =A0There is no downgrade, > > because the security-states are the outcome of the chain-of-trust > > algorithm, not implemented from its definitions in RFC4035. > > > Okay, after reading your response and re-reading 4035 and 4033, I > think 4033 definitions for Bogus, Insecure and Indeterminate capture > the discussion below more clearly. > > > > > On 02/07/2012 08:51 PM, Mohan Parthasarathy wrote: > >> On Tue, Feb 7, 2012 at 9:14 AM, Edward Lewis wrot= > e: > >>> At 16:34 +0100 2/7/12, W.C.A. Wijngaards wrote: > >>> > >>>> insecure, or bogus. =A0Note that with the root trust anchor the > >>>> indeterminate state no longer occurs, since we know everything is > >>>> covered by that trust anchor. > >>> > >>> > >>> I disagree with that. > >>> > >>> The Internet that we usually think about as being the only one is what I > >>> call the "global public Internet". =A0For the global public Internet, t= > he DNS > >>> in common use does have a trust anchor for it's root zone so the assert= > ion > >>> holds for the majority of cases, but then again only for recursive serv= > ers > >>> that have the trust anchor. > >>> > >>> There are other inter-networks that use the DNS protocol. =A0In at leas= > t one > >>> of these, DNSSEC has not been deployed. > >>> > >>> And, you can stretch this to the case of a recursive server, on the glo= > bal > >>> public Internet, that does not have the root anchor configured - and may > >>> have another anchor. =A0To such a server, validating some DNS data is > >>> impossible (incalculable). > >>> > >>> The protocol cannot be defined assuming one particular mode of operatio= > n. > >>> > >> Before getting to define this precisely, we should try to understand > >> the different cases that can occur and see whether we all agree on the > >> error status for the different cases. > > > > Why data cannot be fetched is not a factor in the end result. =A0This > > simplifies the cases to: cannot get the proper DNSSEC data, can get > > proper DNSSEC data but it's invalid, can get proper DNSSEC data and it's > > ok. =A0And the results are bogus, bogus, secure. =A0If you find an insecu= > re > > delegation it is insecure. =A0If there is no applicable trust anchor, the > > result is indeterminate (that is effectively just like insecure). > > > > Ok, Bogus, Secure and Insecure applies only when there is an > applicable trust anchor. When it is absent, it is indeterminate. That > simplifies a lot. Absolutely wrong. Step 1 of validation. Is there a potential covering trust anchor? Yes. Goto step 2. No. Mark as insecure. Step 2 .... > > >> > >> 1) We get some DNSSEC RRs back but can't validate. Just being able to > >> partially validate without tracing back to the trust anchor is equally > >> bad as not being able to validate the signatures. > > > > Yes, that is bogus in today's implementations. > > > >> 2) We get no DNSSEC RRs back. This could be a problem in the path or > >> the zone is not signed. We can't tell the difference without some > >> extra configuration. > > > > You can tell the difference because the chain-of-trust is signed itself, > > and this extends from the trust anchor to the data you just got, and > > thus you know if this zone is signed or not. =A0And thus in your question, > > the unsigned zone is ok(insecure), and the signed-zone-missing-DNSSEC > > RRs is not ok(bogus). > > > >> How does it help the application to make this more fine grained ? > > > > No, the application just wants all bogus data to be removed. =A0Data that > > is secure and data that is not DNSSEC signed is what it wants. =A0Because > > of the chain-of-trust the validator knows which parts of the space below > > a trust anchor is signed (and must have DNSSEC available) and which part > > is unsigned. =A0This property could be the cause that made insecure and > > indeterminate terms exist, as indeterminate is not really processed but > > simply the absence of a covering trust anchor, just like in the case > > where you had no trust anchors at all. =A0But then insecure needs > > processing: you have to validate the chain of trust from the trust > > anchor to the insecure-delegation point, and only then can you conclude > > that the data is insecure. =A0This is something internal to the DNSSEC > > validator, and not particularly impressive to the application, that > > likely just wants to know if the data was DNSSEC-signed (if so: secure > > or bogus) or if the data was not DNSSEC-signed (as determined with the > > configured set of trust anchors). > > > That was very useful discussion. > > regards > mohan > > > Best regards, > > =A0 Wouter > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.15 (GNU/Linux) > > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ > > > > iQIcBAEBAgAGBQJPMjK2AAoJEJ9vHC1+BF+NxVUQAIyQ4nPk7Syogn9uh4z890yJ > > kmPxslbpvHru47OxKd0tYvozldnP32z1+JToGSZR8qRU+w9SAQLutnFkqCU28x95 > > QUAot8G157kxZT95zhdjVqpbyUYDYwKKUY4jqplq4IuyIm1ewEOcwAS8Sak1o9Gr > > 17Xs4aCpl55QmTCZAlP+r6SwCDY738Py9I51BJhifAB9HdkT6XK1+bsbMSiFhG+o > > koICUhKaLDthmFvBrHBVCiW4xD5uk8ww2jlMNXv2LaRT05tfVjLC0EfboFn3kEkg > > +c39M8Bm4GlkQvB1Wr37AEPn/m0PYbsC2lOEQL/04QRGiAcDTtjo4bzzsKb6yFFi > > cWg8mUsldcSikZB+YFVS0RRLGcKCWhOVHxxMqKlA/IdzBU02JiGaYqZU9SKaakkc > > 8AEFJkQdUYerh4BPeiwlzpy4uS3kiJU7A8hKnQSIuRR1xo7r28NKuvrxLnw5b3es > > kExf4pyb5zitBPx6c0ERQ1SJrw9VU3DipJb6dY/QW5uceHvfJlYQiXN6nGGKUkvw > > FlupnGef8TvHvgnHieiD9t3WRh+7WNKdMCs627U/Ym8VC0gcTXK3WORMdwrAVq7j > > I7wEkXH4ms9sJD09ZGysNjlRylKvMzHlxxIjl3kpFmvGwus//BxMq8GCT+08cJ9Z > > 5AOnYo5AWqWqa8nipilZ > > =3DdpSm > > -----END PGP SIGNATURE----- > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > _______________________________________________ > 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 suruti94@gmail.com Wed Feb 8 15:27:48 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E6E21F84E4 for ; Wed, 8 Feb 2012 15:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Phw10GVuI-qF for ; Wed, 8 Feb 2012 15:27:47 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 790EB21F84DF for ; Wed, 8 Feb 2012 15:27:47 -0800 (PST) Received: by obbwd15 with SMTP id wd15so1737655obb.31 for ; Wed, 08 Feb 2012 15:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IMzyD+RrAqA3niP5r1TGitTOf+dYjE72TzBSbeIn4Yc=; b=HB+tQ6nS2IJmkAgq+oTITfO8r68oZx7l2zoVIJv6dtjBxxwdGZpD/517oXd3cAT8K/ oyo6ilvihsHQGa7F/Cp05wwOOswGgT0DksTJQ0lOywKNQgeV91j1zuR5D84Cxlsu3BPU LTDm84WneALSQI3ILcr5CqHO2E+05zK9FYCYc= MIME-Version: 1.0 Received: by 10.182.119.73 with SMTP id ks9mr27902006obb.45.1328743667065; Wed, 08 Feb 2012 15:27:47 -0800 (PST) Received: by 10.182.147.105 with HTTP; Wed, 8 Feb 2012 15:27:47 -0800 (PST) In-Reply-To: <20120208230511.2440F1D0601B@drugs.dv.isc.org> References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <4F3232B6.3060505@nlnetlabs.nl> <20120208230511.2440F1D0601B@drugs.dv.isc.org> Date: Wed, 8 Feb 2012 15:27:47 -0800 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2012 23:27:48 -0000 On Wed, Feb 8, 2012 at 3:05 PM, Mark Andrews wrote: > > In message , > =A0Mohan Parthasarathy writes: >> On Wed, Feb 8, 2012 at 12:30 AM, W.C.A. Wijngaards = wr=3D >> ote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > Hi Mohan, >> > >> > The definition of indeterminate was wrong in RFC4035, and you now seem >> > to think DNSSEC is riddled with downgrade. =3DA0There is no downgrade, >> > because the security-states are the outcome of the chain-of-trust >> > algorithm, not implemented from its definitions in RFC4035. >> > >> Okay, after reading your response and re-reading 4035 and 4033, I >> think 4033 definitions for Bogus, Insecure and Indeterminate capture >> the discussion below more clearly. >> >> =A0 >> >> > On 02/07/2012 08:51 PM, Mohan Parthasarathy wrote: >> >> On Tue, Feb 7, 2012 at 9:14 AM, Edward Lewis w= rot=3D >> e: >> >>> At 16:34 +0100 2/7/12, W.C.A. Wijngaards wrote: >> >>> >> >>>> insecure, or bogus. =3DA0Note that with the root trust anchor the >> >>>> indeterminate state no longer occurs, since we know everything is >> >>>> covered by that trust anchor. >> >>> >> >>> >> >>> I disagree with that. >> >>> >> >>> The Internet that we usually think about as being the only one is wh= at I >> >>> call the "global public Internet". =3DA0For the global public Intern= et, t=3D >> he DNS >> >>> in common use does have a trust anchor for it's root zone so the ass= ert=3D >> ion >> >>> holds for the majority of cases, but then again only for recursive s= erv=3D >> ers >> >>> that have the trust anchor. >> >>> >> >>> There are other inter-networks that use the DNS protocol. =3DA0In at= leas=3D >> t one >> >>> of these, DNSSEC has not been deployed. >> >>> >> >>> And, you can stretch this to the case of a recursive server, on the = glo=3D >> bal >> >>> public Internet, that does not have the root anchor configured - and= may >> >>> have another anchor. =3DA0To such a server, validating some DNS data= is >> >>> impossible (incalculable). >> >>> >> >>> The protocol cannot be defined assuming one particular mode of opera= tio=3D >> n. >> >>> >> >> Before getting to define this precisely, we should try to understand >> >> the different cases that can occur and see whether we all agree on th= e >> >> error status for the different cases. >> > >> > Why data cannot be fetched is not a factor in the end result. =3DA0Thi= s >> > simplifies the cases to: cannot get the proper DNSSEC data, can get >> > proper DNSSEC data but it's invalid, can get proper DNSSEC data and it= 's >> > ok. =3DA0And the results are bogus, bogus, secure. =3DA0If you find an= insecu=3D >> re >> > delegation it is insecure. =3DA0If there is no applicable trust anchor= , the >> > result is indeterminate (that is effectively just like insecure). >> > >> >> Ok, Bogus, Secure and Insecure applies only when there is an >> applicable trust anchor. When it is absent, it is indeterminate. That >> simplifies a lot. > > Absolutely wrong. > > Step 1 of validation. > Is there a potential covering trust anchor? > =A0 =A0 =A0 =A0Yes. =A0Goto step 2. > =A0 =A0 =A0 =A0No. =A0Mark as insecure. > > Step 2 .... > >From RFC 4033: Insecure: The validating resolver has a trust anchor, a chain of trust, and, at some delegation point, signed proof of the non-existence of a DS record. This indicates that subsequent branches in the tree are provably insecure. A validating resolver may have a local policy to mark parts of the domain space as insecure. So, I don't understand what you mean. -mohan >> =A0 >> >> >> >> 1) We get some DNSSEC RRs back but can't validate. Just being able to >> >> partially validate without tracing back to the trust anchor is equall= y >> >> bad as not being able to validate the signatures. >> > >> > Yes, that is bogus in today's implementations. >> > >> >> 2) We get no DNSSEC RRs back. This could be a problem in the path or >> >> the zone is not signed. We can't tell the difference without some >> >> extra configuration. >> > >> > You can tell the difference because the chain-of-trust is signed itsel= f, >> > and this extends from the trust anchor to the data you just got, and >> > thus you know if this zone is signed or not. =3DA0And thus in your que= stion, >> > the unsigned zone is ok(insecure), and the signed-zone-missing-DNSSEC >> > RRs is not ok(bogus). >> > >> >> How does it help the application to make this more fine grained ? >> > >> > No, the application just wants all bogus data to be removed. =3DA0Data= that >> > is secure and data that is not DNSSEC signed is what it wants. =3DA0Be= cause >> > of the chain-of-trust the validator knows which parts of the space bel= ow >> > a trust anchor is signed (and must have DNSSEC available) and which pa= rt >> > is unsigned. =3DA0This property could be the cause that made insecure = and >> > indeterminate terms exist, as indeterminate is not really processed bu= t >> > simply the absence of a covering trust anchor, just like in the case >> > where you had no trust anchors at all. =3DA0But then insecure needs >> > processing: you have to validate the chain of trust from the trust >> > anchor to the insecure-delegation point, and only then can you conclud= e >> > that the data is insecure. =3DA0This is something internal to the DNSS= EC >> > validator, and not particularly impressive to the application, that >> > likely just wants to know if the data was DNSSEC-signed (if so: secure >> > or bogus) or if the data was not DNSSEC-signed (as determined with the >> > configured set of trust anchors). >> > >> That was very useful discussion. >> >> regards >> mohan >> >> > Best regards, >> > =3DA0 Wouter >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v2.0.15 (GNU/Linux) >> > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ >> > >> > iQIcBAEBAgAGBQJPMjK2AAoJEJ9vHC1+BF+NxVUQAIyQ4nPk7Syogn9uh4z890yJ >> > kmPxslbpvHru47OxKd0tYvozldnP32z1+JToGSZR8qRU+w9SAQLutnFkqCU28x95 >> > QUAot8G157kxZT95zhdjVqpbyUYDYwKKUY4jqplq4IuyIm1ewEOcwAS8Sak1o9Gr >> > 17Xs4aCpl55QmTCZAlP+r6SwCDY738Py9I51BJhifAB9HdkT6XK1+bsbMSiFhG+o >> > koICUhKaLDthmFvBrHBVCiW4xD5uk8ww2jlMNXv2LaRT05tfVjLC0EfboFn3kEkg >> > +c39M8Bm4GlkQvB1Wr37AEPn/m0PYbsC2lOEQL/04QRGiAcDTtjo4bzzsKb6yFFi >> > cWg8mUsldcSikZB+YFVS0RRLGcKCWhOVHxxMqKlA/IdzBU02JiGaYqZU9SKaakkc >> > 8AEFJkQdUYerh4BPeiwlzpy4uS3kiJU7A8hKnQSIuRR1xo7r28NKuvrxLnw5b3es >> > kExf4pyb5zitBPx6c0ERQ1SJrw9VU3DipJb6dY/QW5uceHvfJlYQiXN6nGGKUkvw >> > FlupnGef8TvHvgnHieiD9t3WRh+7WNKdMCs627U/Ym8VC0gcTXK3WORMdwrAVq7j >> > I7wEkXH4ms9sJD09ZGysNjlRylKvMzHlxxIjl3kpFmvGwus//BxMq8GCT+08cJ9Z >> > 5AOnYo5AWqWqa8nipilZ >> > =3D3DdpSm >> > -----END PGP SIGNATURE----- >> > _______________________________________________ >> > dnsext mailing list >> > dnsext@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsext >> _______________________________________________ >> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org From Ed.Lewis@neustar.biz Wed Feb 8 17:15:59 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EE921F85EA for ; Wed, 8 Feb 2012 17:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.877 X-Spam-Level: X-Spam-Status: No, score=-105.877 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxAYrnjW5427 for ; Wed, 8 Feb 2012 17:15:59 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 71C0921F85E6 for ; Wed, 8 Feb 2012 17:15:58 -0800 (PST) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q191FecU069407; Wed, 8 Feb 2012 20:15:41 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.21] by Work-Laptop-2.local (PGP Universal service); Wed, 08 Feb 2012 17:15:44 -0800 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 08 Feb 2012 17:15:44 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <4F3232B6.3060505@nlnetlabs.nl> <20120208230511.2440F1D0601B@drugs.dv.isc.org> Date: Wed, 8 Feb 2012 17:15:35 -0800 To: Mohan Parthasarathy From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 01:15:59 -0000 At 15:27 -0800 2/8/12, Mohan Parthasarathy wrote: >On Wed, Feb 8, 2012 at 3:05 PM, Mark Andrews wrote: >> >> Step 1 of validation. >> Is there a potential covering trust anchor? >> Yes. Goto step 2. >> No. Mark as insecure. >> >> Step 2 .... >> >From RFC 4033: > >Insecure: The validating resolver has a trust anchor, a chain of > trust, and, at some delegation point, signed proof of the > non-existence of a DS record. This indicates that subsequent > branches in the tree are provably insecure. A validating resolver > may have a local policy to mark parts of the domain space as > insecure. > >So, I don't understand what you mean. What Mark wrote is consistent with that paragraph. Not complete, but consistent. Look at a path through the namespace: o = root | o = tld | o = example | o = www Let's say that "tld." is a cut point. Case 1 - if there are no trust anchors at all, then everything is "insecure." Case 2 - if there is a root trust anchor and there is provably no DS record for tld., then all names in the tld. domain (not just the zone) are provably insecure. Case 3 - (as in case 2 up to the BUT) if there is a root trust anchor and there is provably no DS record for tld., BUT there is a trust anchor for example.tld. and www is not a cut point. In this case you can validate sets owned by www.example.tld. "Insecure" is never an outcome. The possible outcomes are "bogus", "valid" (or whatever "good" is called), and a service failure if some record cannot be retrieved. Case 4 - trust anchors at root and tld.root and no cutpoints without a DS, then you'll never see insecure. (I hope I have this right.) And only "Bogus" is bad, no data is returned for Bogus and Service Failure. Data is returned for Insecure and Valid. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From marka@isc.org Wed Feb 8 18:22:51 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1860021F85C3 for ; Wed, 8 Feb 2012 18:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9W32TSBm-PA for ; Wed, 8 Feb 2012 18:22:50 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE5C21F84F2 for ; Wed, 8 Feb 2012 18:22:50 -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 04E39C9463; Thu, 9 Feb 2012 02:22:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3981:7370:f4ed:515c]) (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 BC400216C6B; Thu, 9 Feb 2012 02:22: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 975221D072A1; Thu, 9 Feb 2012 13:22:31 +1100 (EST) To: Edward Lewis From: Mark Andrews References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <4F3232B6.3060505@nlnetlabs.nl> <20120208230511.2440F1D0601B@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 08 Feb 2012 17:15:35 -0800." Date: Thu, 09 Feb 2012 13:22:31 +1100 Message-Id: <20120209022231.975221D072A1@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 02:22:51 -0000 In message , Edward Lewis writes: > At 15:27 -0800 2/8/12, Mohan Parthasarathy wrote: > >On Wed, Feb 8, 2012 at 3:05 PM, Mark Andrews wrote: > > >> > >> Step 1 of validation. > >> Is there a potential covering trust anchor? > >> Yes. Goto step 2. > >> No. Mark as insecure. > >> > >> Step 2 .... > >> > >From RFC 4033: > > > >Insecure: The validating resolver has a trust anchor, a chain of > > trust, and, at some delegation point, signed proof of the > > non-existence of a DS record. This indicates that subsequent > > branches in the tree are provably insecure. A validating resolver > > may have a local policy to mark parts of the domain space as > > insecure. > > > >So, I don't understand what you mean. > > What Mark wrote is consistent with that paragraph. Not complete, but > consistent. > > Look at a path through the namespace: > > o = root > | > o = tld > | > o = example > | > o = www > > Let's say that "tld." is a cut point. > > Case 1 - if there are no trust anchors at all, then everything is "insecure." > > Case 2 - if there is a root trust anchor and there is provably no DS > record for tld., then all names in the tld. domain (not just the > zone) are provably insecure. > > Case 3 - (as in case 2 up to the BUT) if there is a root trust anchor > and there is provably no DS record for tld., BUT there is a trust > anchor for example.tld. and www is not a cut point. In this case you > can validate sets owned by www.example.tld. "Insecure" is never an > outcome. The possible outcomes are "bogus", "valid" (or whatever > "good" is called), and a service failure if some record cannot be > retrieved. > > Case 4 - trust anchors at root and tld.root and no cutpoints without > a DS, then you'll never see insecure. > > (I hope I have this right.) > > And only "Bogus" is bad, no data is returned for Bogus and Service > Failure. Data is returned for Insecure and Valid. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > 2012...time to reuse those 1984 calendars! Insecure is data that validator *knows* is cannot cryptographically verify. This may be because: * there are no suitable trust anchors to attempt to verify with. * there is a insecure delegation (provable no DS record) in the path. * there is a secure delegation but no algorithm support in the path. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From suruti94@gmail.com Wed Feb 8 18:41:10 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A248321F856D for ; Wed, 8 Feb 2012 18:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lT6tIbqVsuL for ; Wed, 8 Feb 2012 18:41:10 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C40721F8569 for ; Wed, 8 Feb 2012 18:41:07 -0800 (PST) Received: by qcsg13 with SMTP id g13so820060qcs.31 for ; Wed, 08 Feb 2012 18:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kADbrV69uj0WFxZ156sMPHcdMqQeMFrr6rAaFysPV2E=; b=PdKkqdiMu6+4v6AEPTd1GWa+ZEpASFv8T0IX8EgiHLgtFUmJeypVdOXA73t4Fzyjeb ROfq0PKYaVvqCqxdgxIU27BPnXl7UErSmZs4K2A8eRBFu7rNnhRKl2gZk/WNZy77PMyl 9dE65eN5AaCRjs0rHke/aJytynDb4O/RZCT9o= MIME-Version: 1.0 Received: by 10.224.96.9 with SMTP id f9mr293887qan.36.1328755267070; Wed, 08 Feb 2012 18:41:07 -0800 (PST) Received: by 10.229.136.130 with HTTP; Wed, 8 Feb 2012 18:41:06 -0800 (PST) In-Reply-To: <20120209022231.975221D072A1@drugs.dv.isc.org> References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <4F3232B6.3060505@nlnetlabs.nl> <20120208230511.2440F1D0601B@drugs.dv.isc.org> <20120209022231.975221D072A1@drugs.dv.isc.org> Date: Wed, 8 Feb 2012 18:41:06 -0800 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 02:41:10 -0000 On Wed, Feb 8, 2012 at 6:22 PM, Mark Andrews wrote: > > In message , Edward Lewis writes: >> At 15:27 -0800 2/8/12, Mohan Parthasarathy wrote: >> >On Wed, Feb 8, 2012 at 3:05 PM, Mark Andrews wrote: >> >> >> >> >> =A0Step 1 of validation. >> >> =A0Is there a potential covering trust anchor? >> >> =A0 =A0 =A0 =A0 Yes. =A0Goto step 2. >> >> =A0 =A0 =A0 =A0 No. =A0Mark as insecure. >> >> >> >> =A0Step 2 .... >> >> >> >From RFC 4033: >> > >> >Insecure: The validating resolver has a trust anchor, a chain of >> > =A0 =A0 =A0 trust, and, at some delegation point, signed proof of the >> > =A0 =A0 =A0 non-existence of a DS record. =A0This indicates that subse= quent >> > =A0 =A0 =A0 branches in the tree are provably insecure. =A0A validatin= g resolver >> > =A0 =A0 =A0 may have a local policy to mark parts of the domain space = as >> > =A0 =A0 =A0 insecure. >> > >> >So, I don't understand what you mean. >> >> What Mark wrote is consistent with that paragraph. =A0Not complete, but >> consistent. >> >> Look at a path through the namespace: >> >> =A0 =A0 =A0o =A0 =A0 =A0=3D root >> =A0 =A0 =A0| >> =A0 =A0 =A0o =A0 =A0 =A0=3D tld >> =A0 =A0 =A0| >> =A0 =A0 =A0o =A0 =A0 =A0=3D example >> =A0 =A0 =A0| >> =A0 =A0 =A0o =A0 =A0 =A0=3D www >> >> Let's say that "tld." is a cut point. >> >> Case 1 - if there are no trust anchors at all, then everything is "insec= ure." >> >> Case 2 - if there is a root trust anchor and there is provably no DS >> record for tld., then all names in the tld. domain (not just the >> zone) are provably insecure. >> >> Case 3 - (as in case 2 up to the BUT) if there is a root trust anchor >> and there is provably no DS record for tld., BUT there is a trust >> anchor for example.tld. and www is not a cut point. =A0In this case you >> can validate sets owned by www.example.tld. =A0"Insecure" is never an >> outcome. =A0The possible outcomes are "bogus", "valid" (or whatever >> "good" is called), and a service failure if some record cannot be >> retrieved. >> >> Case 4 - trust anchors at root and tld.root and no cutpoints without >> a DS, then you'll never see insecure. >> >> (I hope I have this right.) >> >> And only "Bogus" is bad, no data is returned for Bogus and Service >> Failure. =A0Data is returned for Insecure and Valid. >> >> -- >> -=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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice mes= sage at +1-571-434-5468 >> >> 2012...time to reuse those 1984 calendars! > > Insecure is data that validator *knows* is cannot cryptographically verif= y. > This may be because: > * there are no suitable trust anchors to attempt to verify with. > * there is a insecure delegation (provable no DS record) in the path. > * there is a secure delegation but no algorithm support in the path. > Right, but what I wrote was not Absolutely wrong, if you assume that there will at least be a root trust anchor configured, But it might be worth clarifying the first and third bullet above for Insecure. -mohan > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org From wouter@nlnetlabs.nl Thu Feb 9 01:25:52 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E748821F86C3 for ; Thu, 9 Feb 2012 01:25:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiCBZQLiQXWD for ; Thu, 9 Feb 2012 01:25:52 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9621F86C1 for ; Thu, 9 Feb 2012 01:25:51 -0800 (PST) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q199PmfY040349 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 9 Feb 2012 10:25:49 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1328779550; bh=sX5Nnt3nHkQydpgKFF2IZjom/HRHTKS5sAij5ABoSLE=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=omM6ElWjKIiCenzK858NVG7AzhP7o48rPDXZjmkd3P7jkGzoYvpsCDTt28VD3oldk 1x0qpSIXTsV7sfjCG2/iyjj4Z9EtubNyHS4aY40wB7vuCT4hwOZK6hM4pjeH3gsvks IH7fVV4+UGA4wpHV6Z9Zv+CX1qoZEau+2jePUIpA= Message-ID: <4F33911C.2080601@nlnetlabs.nl> Date: Thu, 09 Feb 2012 10:25:48 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <4F3232B6.3060505@nlnetlabs.nl> <20120208185617.GH11475@mail.yitter.info> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 09 Feb 2012 10:25:49 +0100 (CET) Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 09:25:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, Andrew, On 02/08/2012 08:48 PM, Paul Hoffman wrote: > On Feb 8, 2012, at 10:56 AM, Andrew Sullivan wrote: > >> No hat. >> >> On Wed, Feb 08, 2012 at 09:30:46AM +0100, W.C.A. Wijngaards >> wrote: >>> >>> On 02/07/2012 08:51 PM, Mohan Parthasarathy wrote: >>> >>>> How does it help the application to make this more fine >>>> grained ? >>> >>> No, the application just wants all bogus data to be removed. >>> Data that is secure and data that is not DNSSEC signed is what >>> it wants. >> >> It seems to me that the above is either a matter of policy or a >> matter of implementation. That is, some applications will surely >> only want data that they can know for sure is valid, and in >> particular will not want any unsigned data no matter what. >> >> This could be implemented in more than one way. One is to hand >> the application everything that is validated and unsigned, and >> let the application work out which it wants. But another would >> be for the application to be able to signal this choice to the >> resolver. No? > > > In specific, the current proposal for DANE wants to know if it is > getting bogus data. It treats bogus data as quite different than > "no record received". See the bulleted list in section 5 of > draft-ietf-dane-protocol-16.txt. > > If the DNSEXT WG thinks that it is going to change dnssec-bis to > make the change Wouter suggests, the DANE WG needs to hear about it > *very soon*. Let me state that I do not want to make such a change. For backwards compatibility DNSSEC has this facility to figure out which zones are signed and validatable by the validator, and this backwards compatibility can be used for DANE too. Thus it wants to know the precise secure, insecure and bogus validation results. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPM5EcAAoJEJ9vHC1+BF+NZZ8P/A1qquwHtxibDeRAAoDOZm6m pO8/n1wiO7JeTf8RlU5aWrLOCv0oejwOtzp68kV2Xgb+G+yJtgWrhMWizxhnDWxR NY+FJeHrNGGs8GATPjT6j9t079k+VlCdp5lxrdLV7k05tpkbCHOAWmnrBvSqC7AC Uicf78Iwt3aailho4UawrCiWkWCZTZliXbWQtVqlXis51i4I4g1WScc+Dbwz2xHZ GWvWBZpZce5XuyprBeZKlzuQCGcBHMc+mcJ5crdaFF5M/m0QIRThpzGEyPDhPPUR 3YXBXBM4cxUZUxbg3mOlbzdcIgQR3vNOSMbP470cVdc10e3304kmKP9IvHCWqnEY TauAteTRusowRFOFDIVzguocC+tfz/7V2Q0+VWay2qT2BhnnS75LXUYZ4JjHIxJh 3dzQjyMBDqZldChXcDJq08KZNMsJjdrgnDOSZfzZB2ii4n/DJ09jha2AkN4QS5tD 0G4VCDt/IGOYva4XLdi+qHZ843Skj3sP5BZyJ52TQ1yKjIfJ0pfVa7xPtdoXXRzD 5ctkJqNkIHKjkeGie7OACtwWRBgggRJgEnQXj569GZxWSUevTZ2Pv5BRmCI8aodL y1yx6cvPFiXJSfHg+rEWgHWMZqI9QgoJIkVU+AX3n5ph3dvfL5lDuMvC8KRQHpL2 7Zd//f4hL3W3Ay6JpT0G =70uC -----END PGP SIGNATURE----- From vixie@isc.org Thu Feb 9 07:10:03 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC4721F8729 for ; Thu, 9 Feb 2012 07:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmV-X2LdrtYm for ; Thu, 9 Feb 2012 07:10:03 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id E3F1E21F8726 for ; Thu, 9 Feb 2012 07:09:59 -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 06EF75F989F for ; Thu, 9 Feb 2012 15:09:38 +0000 (UTC) (envelope-from vixie@isc.org) Received: from [192.168.2.143] (APuteaux-553-1-60-230.w92-151.abo.wanadoo.fr [92.151.75.230]) (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 1F78E216C6D for ; Thu, 9 Feb 2012 15:09:30 +0000 (UTC) (envelope-from vixie@isc.org) Message-ID: <4F33E1A6.4030902@isc.org> Date: Thu, 09 Feb 2012 15:09:26 +0000 From: paul vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 15:12:32 -0000 based on the renewed interest in the delegation and glue ttl problem caused by the "ghost domains" paper, i looked again at: http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 ...which i presented in prague about a year ago. the sticking point was: B. Stopping a downward cache search when an NXDOMAIN is encountered. and all of section 3. this proposal was considered controversial since two existing implementation (rbldnsd and tinydns) currently send nxdomain when queried for an empty nonterminal domain name. i did not agree that this was a problem since RBL DNS queries are always full length (that is, for all octets or all nybbles of an inverted host address) and since the DNSSEC specification clarified non-terminal names as existing but empty. i now propose that we dust off this draft, remove (B) and section 3, and progress it not as an improvement but as a security and resiliency requirement (so, a proposed standard) in the face of the "ghost domain" problem. i may yet reintroduce the NXDOMAIN matter but i don't think that we should logjam on it any further. with five shows of support i would consider the editorial work involved here to be worth doing. paul From ajs@anvilwalrusden.com Thu Feb 9 09:23:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D1521F85DF for ; Thu, 9 Feb 2012 09:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX232m3n9r3u for ; Thu, 9 Feb 2012 09:23:21 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B902D21F85DD for ; Thu, 9 Feb 2012 09:23:21 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9F44F1ECB41D for ; Thu, 9 Feb 2012 17:23:20 +0000 (UTC) Date: Thu, 9 Feb 2012 12:23:18 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120209172318.GI15698@mail.yitter.info> References: <4F33E1A6.4030902@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F33E1A6.4030902@isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 17:23:22 -0000 On Thu, Feb 09, 2012 at 03:09:26PM +0000, paul vixie wrote: > > i now propose that we dust off this draft, remove (B) and section 3, and > progress it not as an improvement but as a security and resiliency > requirement (so, a proposed standard) in the face of the "ghost domain" > problem. > with five shows of support i would consider the editorial work involved > here to be worth doing. Do you consider it possible to get done and through WGLC before Paris? (FWIW, no hat, I do not.) A -- Andrew Sullivan ajs@anvilwalrusden.com From fneves@registro.br Thu Feb 9 10:02:03 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A35421F85C3 for ; Thu, 9 Feb 2012 10:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o8FqMzeoUvo for ; Thu, 9 Feb 2012 10:02:03 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id D196021F85C0 for ; Thu, 9 Feb 2012 10:02:02 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id E909EE04A7; Thu, 9 Feb 2012 16:02:01 -0200 (BRST) Date: Thu, 9 Feb 2012 16:02:01 -0200 From: Frederico A C Neves To: Andrew Sullivan Message-ID: <20120209180201.GF86405@registro.br> References: <4F33E1A6.4030902@isc.org> <20120209172318.GI15698@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120209172318.GI15698@mail.yitter.info> Cc: dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 18:02:03 -0000 On Thu, Feb 09, 2012 at 12:23:18PM -0500, Andrew Sullivan wrote: > On Thu, Feb 09, 2012 at 03:09:26PM +0000, paul vixie wrote: > > > > i now propose that we dust off this draft, remove (B) and section 3, and > > progress it not as an improvement but as a security and resiliency > > requirement (so, a proposed standard) in the face of the "ghost domain" > > problem. > > > with five shows of support i would consider the editorial work involved > > here to be worth doing. > > Do you consider it possible to get done and through WGLC before Paris? > (FWIW, no hat, I do not.) Don't You think we should treat this orthogonally to the dnsext shutdown ? Clarifications and corrections will continue to show regardless of the existence of dnsext. Fred From ajs@anvilwalrusden.com Thu Feb 9 10:54:17 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CFF21F8664 for ; Thu, 9 Feb 2012 10:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hw2glLq-Uzh for ; Thu, 9 Feb 2012 10:54:16 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D13F121F8653 for ; Thu, 9 Feb 2012 10:54:16 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 031A11ECB41D for ; Thu, 9 Feb 2012 18:54:15 +0000 (UTC) Date: Thu, 9 Feb 2012 13:54:14 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120209185413.GM15698@mail.yitter.info> References: <4F33E1A6.4030902@isc.org> <20120209172318.GI15698@mail.yitter.info> <20120209180201.GF86405@registro.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120209180201.GF86405@registro.br> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 18:54:17 -0000 On Thu, Feb 09, 2012 at 04:02:01PM -0200, Frederico A C Neves wrote: > > Don't You think we should treat this orthogonally to the dnsext > shutdown ? Yes; that's why the "what do you mean 'we'"? I was just trying to be clear that the five reviewers, &c., is not a WG work item requirement in this case, because DNSEXT isn't going to add this work to the WG list. I enthusiastically encourage people to use this mailing list to co-ordinate additional work. A -- Andrew Sullivan ajs@anvilwalrusden.com From jabley@hopcount.ca Thu Feb 9 12:31:07 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E1321F860D for ; Thu, 9 Feb 2012 12:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqZkfxJrOwwQ for ; Thu, 9 Feb 2012 12:31:07 -0800 (PST) Received: from mail.hopcount.ca (mail.hopcount.ca [IPv6:2001:4900:1:392::37]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0A921F85BE for ; Thu, 9 Feb 2012 12:31:07 -0800 (PST) Received: from [2001:4900:1042:100:9dea:a717:c1b4:edee] by mail.hopcount.ca with esmtpa (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rvae0-000Otg-Oe; Thu, 09 Feb 2012 20:31:05 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <20496A7D-C79D-4A82-BCA7-0E0F721AB4D8@nominet.org.uk> Date: Thu, 9 Feb 2012 15:31:00 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <20120127213928.GI17728@mail.yitter.info> <20496A7D-C79D-4A82-BCA7-0E0F721AB4D8@nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1257) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] algo-sig shepherd was Re: WG state reminder X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 20:31:07 -0000 On 2012-01-31, at 04:36, Ray Bellis wrote: > On 30 Jan 2012, at 20:17, Edward Lewis wrote: > >> Frankly I've never been a fan of that document (...) but >> I don't have a problem with Andrew taking this on. > > +1 on both counts. Late to this party, but +1 from me too. Joe From ajs@anvilwalrusden.com Thu Feb 9 12:53:53 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5991421E8020 for ; Thu, 9 Feb 2012 12:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khQgM8FuP-OC for ; Thu, 9 Feb 2012 12:53:51 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6C31921E8011 for ; Thu, 9 Feb 2012 12:53:51 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 43FFC1ECB41D for ; Thu, 9 Feb 2012 20:53:48 +0000 (UTC) Date: Thu, 9 Feb 2012 15:53:46 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120209205346.GQ15698@mail.yitter.info> References: <4F33E1A6.4030902@isc.org> <20120209172318.GI15698@mail.yitter.info> <20120209180201.GF86405@registro.br> <20120209185413.GM15698@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120209185413.GM15698@mail.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 20:53:53 -0000 On Thu, Feb 09, 2012 at 01:54:14PM -0500, Andrew Sullivan wrote: > Yes; that's why the "what do you mean 'we'"? I was just trying to be > clear that the five reviewers, &c., is not a WG work item requirement > in this case, because DNSEXT isn't going to add this work to the WG > list. I note from my INBOX, though he's been too polite to say it, that Olafur doesn't agree with me. I personally find it hard to believe this work could happen that fast, and I seem to recall that we had previous negative reactions to it, but I'm not going to stand in the way. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ogud@ogud.com Thu Feb 9 14:38:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDC721E8050 for ; Thu, 9 Feb 2012 14:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEphpDmeoZqi for ; Thu, 9 Feb 2012 14:38:11 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id B8C4021E8036 for ; Thu, 9 Feb 2012 14:38:10 -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 q19Mc9IT078188 for ; Thu, 9 Feb 2012 17:38:09 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F344AD0.9040607@ogud.com> Date: Thu, 09 Feb 2012 17:38:08 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> In-Reply-To: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 22:38:11 -0000 This draft closes all issues identified so far. The draft also addresses all Id-nits in prior version There is one change that was not included in the WGLC version but may have been inferred: The document Obsoletes RFC2673 Binary labels. If anyone objects to this version being forwarded to the IESG please speak up now and we will start a short WGLC on that one issue. thanks Olafur On 07/02/2012 08:01, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : Extension Mechanisms for DNS (EDNS0) > Author(s) : Joao Damas > Michael Graff > Paul Vixie > Filename : draft-ietf-dnsext-rfc2671bis-edns0-08.txt > Pages : 15 > Date : 2012-02-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 (RFC 2671) based on > feedback from deployment experience in several implementations. It > also closes the IANA registry for extended labels created as part of > RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name > System") which depends on the existence of extended labels. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-08.txt > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > > From warren@kumari.net Thu Feb 9 19:20:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000C211E809D for ; Thu, 9 Feb 2012 19:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rToIGLr0TEOk for ; Thu, 9 Feb 2012 19:20:30 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD5B11E8075 for ; Thu, 9 Feb 2012 19:20:30 -0800 (PST) Received: from [192.168.1.3] (unknown [38.96.24.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 562831B4191F; Thu, 9 Feb 2012 22:20:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <4F33E1A6.4030902@isc.org> Date: Thu, 9 Feb 2012 19:20:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5A3ECDEC-D22C-4014-A784-F2954368BFE6@kumari.net> References: <4F33E1A6.4030902@isc.org> To: paul vixie X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 03:20:31 -0000 On Feb 9, 2012, at 7:09 AM, paul vixie wrote: > based on the renewed interest in the delegation and glue ttl problem > caused by the "ghost domains" paper, i looked again at: >=20 > http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 >=20 > ...which i presented in prague about a year ago. the sticking point = was: >=20 > B. Stopping a downward cache search when an NXDOMAIN is = encountered. >=20 > and all of section 3. this proposal was considered controversial since > two existing implementation (rbldnsd and tinydns) currently send > nxdomain when queried for an empty nonterminal domain name. i did not > agree that this was a problem since RBL DNS queries are always full > length (that is, for all octets or all nybbles of an inverted host > address) and since the DNSSEC specification clarified non-terminal = names > as existing but empty. >=20 > i now propose that we dust off this draft, remove (B) and section 3, = and > progress it not as an improvement but as a security and resiliency > requirement (so, a proposed standard) in the face of the "ghost = domain" > problem. >=20 > i may yet reintroduce the NXDOMAIN matter but i don't think that we > should logjam on it any further. >=20 > with five shows of support i would consider the editorial work = involved > here to be worth doing. I am no longer sure who the five were, but I was not one of them, you = now have 6. I would be more than happy to contribute / edit / review / whatever is = needed to progress it. I think this is a very useful draft=85 W >=20 > paul >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From bortzmeyer@nic.fr Fri Feb 10 00:51:20 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5105621F875A for ; Fri, 10 Feb 2012 00:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RldAxuGuxSVQ for ; Fri, 10 Feb 2012 00:51:19 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 9012321F85B4 for ; Fri, 10 Feb 2012 00:51:19 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 99E183B393; Fri, 10 Feb 2012 08:51:17 +0000 (UTC) Received: by tyrion (Postfix, from userid 1000) id 349CCF005D5; Fri, 10 Feb 2012 09:44:39 +0100 (CET) Date: Fri, 10 Feb 2012 09:44:39 +0100 From: Stephane Bortzmeyer To: paul vixie Message-ID: <20120210084439.GB7284@laperouse.bortzmeyer.org> References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 11.10 (oneiric) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 08:51:20 -0000 On Thu, Feb 09, 2012 at 03:09:26PM +0000, paul vixie wrote a message of 34 lines which said: > remove (B) and section 3, Why? It seems fine to me (even if He-Who-Must-Not-Be-Named disagrees). > progress it not as an improvement but as a security and resiliency > requirement (so, a proposed standard) in the face of the "ghost domain" > problem. It seems to me that this draft does not currently address the ghost domain problem. It mandates revalidation at the parent when the records expire, but it does not say anything about the rules that allow an authoritative server to overwrite the old TTL with a new value, thus preventing expiration. Would it be a better idea to use this draft as a starting point to work on the issues proposed by the ghost domains paper? (Replacing >= by > in the credibility rules and other measures.) From vixie@isc.org Fri Feb 10 01:01:27 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8149B21F8790 for ; Fri, 10 Feb 2012 01:01:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI60MpU9kEBL for ; Fri, 10 Feb 2012 01:01:27 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id A2DE421F878B for ; Fri, 10 Feb 2012 01:01:26 -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 50DEB5F989F; Fri, 10 Feb 2012 09:01:14 +0000 (UTC) (envelope-from vixie@isc.org) Received: from [IPv6:2001:920:7000:1:e0e7:1f79:fa7b:447c] (unknown [IPv6:2001:920:7000:1:e0e7:1f79:fa7b:447c]) (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 E8A5D216C6E; Fri, 10 Feb 2012 09:01:11 +0000 (UTC) (envelope-from vixie@isc.org) Message-ID: <4F34DCD0.2000500@isc.org> Date: Fri, 10 Feb 2012 09:01:04 +0000 From: paul vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> In-Reply-To: <20120210084439.GB7284@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 09:01:27 -0000 On 2/10/2012 8:44 AM, Stephane Bortzmeyer wrote: > On Thu, Feb 09, 2012 at 03:09:26PM +0000, > paul vixie wrote > a message of 34 lines which said: > >> remove (B) and section 3, > Why? It seems fine to me (even if He-Who-Must-Not-Be-Named disagrees). because arguing those merits will take time, and the other parts of the proposal which are less controversial should not have to wait while those arguments complete. >> progress it not as an improvement but as a security and resiliency >> requirement (so, a proposed standard) in the face of the "ghost domain" >> problem. > It seems to me that this draft does not currently address the ghost > domain problem. It mandates revalidation at the parent when the > records expire, but it does not say anything about the rules that > allow an authoritative server to overwrite the old TTL with a new > value, thus preventing expiration. > > Would it be a better idea to use this draft as a starting point to > work on the issues proposed by the ghost domains paper? (Replacing >= > by > in the credibility rules and other measures.) i think there's some editorial flaw that leads to the above observation. perhaps an explicit reference to RFC 2181 and some examples about how NS replacement will work in light of credibility rules, would help explain why this draft obviates the ghost domain problem. for example the ghost problem appears to be about glue names (A/AAAA RRsets referred to by NS RRs) whereas the resimprove solution set seems to be only about the NS RRsets. but the effect of removing the NS RRsets due to revalidation will be to purge the cache of any glue names which were subdomains of those zone apexes. paul From wouter@nlnetlabs.nl Fri Feb 10 01:17:55 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9F721F8663 for ; Fri, 10 Feb 2012 01:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Jb83rhBp-Yn for ; Fri, 10 Feb 2012 01:17:54 -0800 (PST) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by ietfa.amsl.com (Postfix) with ESMTP id 82E6121F864F for ; Fri, 10 Feb 2012 01:17:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 0A92458D20 for ; Fri, 10 Feb 2012 10:17:53 +0100 (CET) Received: from [192.168.254.3] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 0EE8158D13 for ; Fri, 10 Feb 2012 10:17:47 +0100 (CET) Message-ID: <4F34E0BF.9060305@nlnetlabs.nl> Date: Fri, 10 Feb 2012 10:17:51 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: dnsext@ietf.org References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> In-Reply-To: <20120210084439.GB7284@laperouse.bortzmeyer.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at rotring X-Virus-Status: Clean Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 09:17:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Stephane, On 02/10/2012 09:44 AM, Stephane Bortzmeyer wrote: > It seems to me that this draft does not currently address the ghost > domain problem. It mandates revalidation at the parent when the > records expire, but it does not say anything about the rules that > allow an authoritative server to overwrite the old TTL with a new > value, thus preventing expiration. > > Would it be a better idea to use this draft as a starting point to > work on the issues proposed by the ghost domains paper? (Replacing >= > by > in the credibility rules and other measures.) This replacement is wrong. We must have '=' in >= to pick up zone changes from the same server. We must have revalidation at the parent for the ghost-domain problem, it is simply a case of having the NS TTL expire (i.e. meaning, the NS RRset can be replaced with a newer one but the NS TTL does not increase). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPNOC/AAoJEJ9vHC1+BF+NkM0P/2nD+lSLsjAF0lf1gFEJpUh5 w2GUOFeGbPnuLdz/ohf3b/da50/H3va8XjXFZfgbo+4C1A8nawmMc1IGn6SRIJ+0 50WVZ7la5Yi8v1Ud88UWAeqZohp4dvB4jUcY7exe+5/o7UFNPt7OFdUjQHVjT3ua IH2AEoy78W4/cBurwcUe2mS5SQ+ihUeNyLhAXmsZiZK9DJDXkPhJQwCJqEvjy8AO /tpD2jn/dNncbM09UMBCxVaBvB0VBsywG9HoY4Q3vpCbc0/21CxhqtS2FSoTgtJK a6afKcJ1TNBWSlXqSg3JwGdVsTABzrlh8JIdd7cKBf6uyzQzK+BhsEra9CcTmYjG MQ2KdZsxCKdfuTWFpsdZKDTCnMuCp3PBK582zzOIv/+HxI9nAR4+QYHec9+l5faI YWcsQb/zaf+l6TFJg1nB0DoieGqLO+zwO+o5wJ3M2wrr+FIuKgVs8pyw1q8hVRou w4uCwOEfV5cuL9+IivzC5w/RM58TKNihcHLqQ0fyeBpQd5ZKjwgo5AYmMMr+n5Jg MszACzTzDHfb01S23FFgxzFfMw4zq6M9LOKrrxVOPZ73CVQYbuHsEpxgona04srD oFe8UDdb2O478JkmAO7y6H+ZKVXxCzbM9oSGlEFVZWZbmtMYAlxa1cmhW5GwRuM1 Bc8M+hKwKiiqPgEtSC2e =Ir1l -----END PGP SIGNATURE----- From fw@deneb.enyo.de Fri Feb 10 06:50:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7921F86B6 for ; Fri, 10 Feb 2012 06:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeCOU6E32siD for ; Fri, 10 Feb 2012 06:50:15 -0800 (PST) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id B72C921F86B5 for ; Fri, 10 Feb 2012 06:50:10 -0800 (PST) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Rvrnb-0000zB-67; Fri, 10 Feb 2012 15:50:07 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.72) (envelope-from ) id 1Rvrna-0004D9-Uo; Fri, 10 Feb 2012 15:50:07 +0100 From: Florian Weimer To: "W.C.A. Wijngaards" References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl> Date: Fri, 10 Feb 2012 15:50:06 +0100 In-Reply-To: <4F34E0BF.9060305@nlnetlabs.nl> (W. C. A. Wijngaards's message of "Fri, 10 Feb 2012 10:17:51 +0100") Message-ID: <87lioayc81.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 14:50:17 -0000 * W. C. A. Wijngaards: > This replacement is wrong. We must have '=' in >= to pick up zone > changes from the same server. We must have revalidation at the parent > for the ghost-domain problem, it is simply a case of having the NS TTL > expire (i.e. meaning, the NS RRset can be replaced with a newer one but > the NS TTL does not increase). This is correct for the immediate delegation. However, it does not help if there is yet another delegation. This one would have attacker-controlled TTLs in the parent (child) and child (grandchild). Therefore, I fear that an approach which just picks up the data from the child while keeping the TTL from the parent does not actually address the issue of crafted TTLs. Some sort of recursive, tree-dependent approach appears to be required. From ogud@ogud.com Fri Feb 10 07:23:42 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E96121F86A8 for ; Fri, 10 Feb 2012 07:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.469 X-Spam-Level: X-Spam-Status: No, score=-106.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLoFfny3TzY9 for ; Fri, 10 Feb 2012 07:23:38 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2153A21F8554 for ; Fri, 10 Feb 2012 07:23:37 -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 q1AFNYrT084428 for ; Fri, 10 Feb 2012 10:23:34 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F353676.6090702@ogud.com> Date: Fri, 10 Feb 2012 10:23:34 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl> In-Reply-To: <4F34E0BF.9060305@nlnetlabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 15:23:42 -0000 On 10/02/2012 04:17, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Stephane, > > On 02/10/2012 09:44 AM, Stephane Bortzmeyer wrote: >> It seems to me that this draft does not currently address the ghost >> domain problem. It mandates revalidation at the parent when the >> records expire, but it does not say anything about the rules that >> allow an authoritative server to overwrite the old TTL with a new >> value, thus preventing expiration. >> >> Would it be a better idea to use this draft as a starting point to >> work on the issues proposed by the ghost domains paper? (Replacing>= >> by> in the credibility rules and other measures.) > > This replacement is wrong. We must have '=' in>= to pick up zone > changes from the same server. We must have revalidation at the parent > for the ghost-domain problem, it is simply a case of having the NS TTL > expire (i.e. meaning, the NS RRset can be replaced with a newer one but > the NS TTL does not increase). > > Best regards, > Wouter > Strictly speaking when a resolver gets a RRset there are 4 different actions it can take: Store: Applicable when the RRset does not exist Replace: Applicable when there is a prior set Ignore: always an option Delete: This says that the resolver has lost confidence in the cached. For Credibility Greater ">" the following options make sense Store, Replace For Credibility Equal "=" the following options make sense Ignore, Delete For Credibility Less "<" Ignore If you do Replace on NS on "=" you get ghost domains, because NS set and Glue are the only data that resolver will see in an answer that it potentially has in cache. If you insist on allowing "Replace" on equal then you MUST implement "Fetch NS from child" and "Fetch all glue" to combat the ghost domains and still have Kaminsky defense. Olafur From nweaver@icsi.berkeley.edu Fri Feb 10 07:58:09 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC31D21E800E for ; Fri, 10 Feb 2012 07:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEfGVIFPuefs for ; Fri, 10 Feb 2012 07:58:09 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0821521F8697 for ; Fri, 10 Feb 2012 07:58:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id B70872C4010; Fri, 10 Feb 2012 07:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ha5+56kbtA8j; Fri, 10 Feb 2012 07:58:08 -0800 (PST) Received: from d8-a2-5e-94-ef-80.dynamic.ucsd.edu (d8-a2-5e-94-ef-80.dynamic.ucsd.edu [128.54.10.56]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 638832C4002; Fri, 10 Feb 2012 07:58:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <4F353676.6090702@ogud.com> Date: Fri, 10 Feb 2012 07:58:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <161E2DAB-4355-4ED8-826A-6C5A0F74CE52@icsi.berkeley.edu> References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl> <4F353676.6090702@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1251.1) Cc: dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 15:58:10 -0000 On Feb 10, 2012, at 7:23 AM, Olafur Gudmundsson wrote: > For Credibility Greater ">" the following options make sense > Store, Replace >=20 > For Credibility Equal "=3D" the following options make sense > Ignore, Delete >=20 > For Credibility Less "<" > Ignore >=20 > If you do Replace on NS on "=3D" you get ghost domains, because > NS set and Glue are the only data that resolver will see in an answer = that it potentially has in cache. > If you insist on allowing "Replace" on equal then you MUST implement = "Fetch NS from child" and "Fetch all glue" to combat the ghost domains = and still have Kaminsky defense. One other option: replace-with-min-TTL: A replacement cache entry's new TTL is = min(current TTL on the entry, new TTL). The problem with ghosted domains is not changing the NS RRSET, its that = changing the NS RRSET is also resetting the TTL. Yet given "Newer vs = older data of the same credibility", isn't newer more meaningful (apart = from the stickyness problem)? But changing "replace" with "replace-with-min-ttl" means you're = conservative on timeout in the case of disagreement between old and new. And overall, I think replace-with-min-TTL should be standardized. = Because even "Credibility > replace" can have a problem: The parent = wants a deliberate shorter TTL for the NS set, but the child can = override it. =20 For example, .com wants a 2 day TTL, but the child overrides it with a 7 = day TTL, which still gives a 7-day 'no-revocation' window for any = preseeded domains. This could be even worse for various dynamic DNS = services which allow delegation. From paul.hoffman@vpnc.org Fri Feb 10 08:25:08 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52C921F8767 for ; Fri, 10 Feb 2012 08:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuML4iQodAbm for ; Fri, 10 Feb 2012 08:25:07 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3326F21F8759 for ; Fri, 10 Feb 2012 08:25:07 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1AGP5FN048566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Feb 2012 09:25:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F33E1A6.4030902@isc.org> Date: Fri, 10 Feb 2012 08:25:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F33E1A6.4030902@isc.org> To: paul vixie X-Mailer: Apple Mail (2.1257) Cc: dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 16:25:08 -0000 This does not seem like it is a quick fix that can be done in the next = few weeks. Why is there hesitation on making this an individual submission for = standards track that would happen after the WG shuts down? --Paul Hoffman From each@isc.org Fri Feb 10 11:27:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2886921F86DE for ; Fri, 10 Feb 2012 11:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYHoMzDPYYKq for ; Fri, 10 Feb 2012 11:27:39 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id BD79621F86D8 for ; Fri, 10 Feb 2012 11:27:39 -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 23320C9427; Fri, 10 Feb 2012 19:27:29 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id D501A216C6E; Fri, 10 Feb 2012 19:27:28 +0000 (UTC) Date: Fri, 10 Feb 2012 19:27:28 +0000 From: Evan Hunt To: Nicholas Weaver Message-ID: <20120210192728.GC90680@isc.org> References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl> <4F353676.6090702@ogud.com> <161E2DAB-4355-4ED8-826A-6C5A0F74CE52@icsi.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161E2DAB-4355-4ED8-826A-6C5A0F74CE52@icsi.berkeley.edu> User-Agent: Mutt/1.4.2.3i Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 19:27:40 -0000 > One other option: replace-with-min-TTL: A replacement cache entry's new > TTL is min(current TTL on the entry, new TTL). This is the approach we're taking in BIND 9, at present. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From ogud@ogud.com Fri Feb 10 12:08:04 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7C521F884A for ; Fri, 10 Feb 2012 12:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.184 X-Spam-Level: X-Spam-Status: No, score=-106.184 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8EijQ-32l0e for ; Fri, 10 Feb 2012 12:08:03 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 678E521F882D for ; Fri, 10 Feb 2012 12:08:03 -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 q1AK818N086745 for ; Fri, 10 Feb 2012 15:08:02 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F357920.2000008@ogud.com> Date: Fri, 10 Feb 2012 15:08:00 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl> <4F353676.6090702@ogud.com> <161E2DAB-4355-4ED8-826A-6C5A0F74CE52@icsi.berkeley.edu> In-Reply-To: <161E2DAB-4355-4ED8-826A-6C5A0F74CE52@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 20:08:04 -0000 On 10/02/2012 10:58, Nicholas Weaver wrote: > > On Feb 10, 2012, at 7:23 AM, Olafur Gudmundsson wrote: >> For Credibility Greater ">" the following options make sense >> Store, Replace >> >> For Credibility Equal "=" the following options make sense >> Ignore, Delete >> >> For Credibility Less "<" >> Ignore >> >> If you do Replace on NS on "=" you get ghost domains, because >> NS set and Glue are the only data that resolver will see in an answer that it potentially has in cache. >> If you insist on allowing "Replace" on equal then you MUST implement "Fetch NS from child" and "Fetch all glue" to combat the ghost domains and still have Kaminsky defense. > > One other option: > replace-with-min-TTL: A replacement cache entry's new TTL is min(current TTL on the entry, new TTL). > > > The problem with ghosted domains is not changing the NS RRSET, its that changing the NS RRSET is also resetting the TTL. Yet given "Newer vs older data of the same credibility", isn't newer more meaningful (apart from the stickyness problem)? > TTL stretching was a REAL BAD idea, and must be stamped out. > But changing "replace" with "replace-with-min-ttl" means you're conservative on timeout in the case of disagreement between old and new. I prefer that resolver perform Delete rather than this, that forces the resolver to reevaluate the delegation. In the case of resolver that does "Fetch NS" upon seeing the referral and adheres to RFC2181 credibility rules, it will always ignore NS set in authority section. If a zone wants changes to propagate quickly it should use a smaller TTL. Resolvers should implement a MAX TTL both to purge old data faster, and to adopt faster to changes. > > > And overall, I think replace-with-min-TTL should be standardized. Because even "Credibility> replace" can have a problem: The parent wants a deliberate shorter TTL for the NS set, but the child can override it. > > For example, .com wants a 2 day TTL, but the child overrides it with a 7 day TTL, which still gives a 7-day 'no-revocation' window for any preseeded domains. This could be even worse for various dynamic DNS services which allow delegation. > > well in the case of TLD's the TTL on referrals ranges from 600 (10min) to 345600 (4 days) with 1 day as the median value and most common one. Based on a sample of 180 google. domains out of 310 TLD's. Do you want everyone that has a parent with 600-3600 TTL on parent side NS records to force that policy on all their children? Olafur From davidb@verisign.com Fri Feb 10 14:58:49 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A38121F8522 for ; Fri, 10 Feb 2012 14:58:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksrmxEpZIxWP for ; Fri, 10 Feb 2012 14:58:48 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id A6DF921F8527 for ; Fri, 10 Feb 2012 14:58:45 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTzWhJGScdOD4MyxkYyjhW8kvHplLUUG9@postini.com; Fri, 10 Feb 2012 14:58:47 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q1AMwfuG022569; Fri, 10 Feb 2012 17:58:41 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 17:58:42 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 17:58:41 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Fri, 10 Feb 2012 17:58:40 -0500 From: "Blacka, David" To: Olafur Gudmundsson Thread-Topic: [dnsext] perhaps we should reintroduce "resimprove" Thread-Index: AQHM59A5eDlRDuocp0+Gh3hClcI8pJY2LeqAgABmLgCAAAmsgIAARc0AgAAvrwA= Date: Fri, 10 Feb 2012 22:58:40 +0000 Message-ID: <6EEB712F-42B8-4318-ABAD-C11A94F61CC6@verisign.com> References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl> <4F353676.6090702@ogud.com> <161E2DAB-4355-4ED8-826A-6C5A0F74CE52@icsi.berkeley.edu> <4F357920.2000008@ogud.com> In-Reply-To: <4F357920.2000008@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_776FF2E8-9369-4D78-B884-92B70847C711"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2012 22:58:41.0249 (UTC) FILETIME=[88366510:01CCE847] Cc: "" Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 22:58:49 -0000 --Apple-Mail=_776FF2E8-9369-4D78-B884-92B70847C711 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 10, 2012, at 3:08 PM, Olafur Gudmundsson wrote: >>=20 >>=20 >> The problem with ghosted domains is not changing the NS RRSET, its = that changing the NS RRSET is also resetting the TTL. Yet given "Newer = vs older data of the same credibility", isn't newer more meaningful = (apart from the stickyness problem)? >>=20 > TTL stretching was a REAL BAD idea, and must be stamped out. What do you mean by "TTL stretching"? Are you inventing new DNS terms? >=20 >> But changing "replace" with "replace-with-min-ttl" means you're = conservative on timeout in the case of disagreement between old and new. >=20 > I prefer that resolver perform Delete rather than this, that forces = the resolver to reevaluate the delegation. So, every time a zone operator modifies the apex NS RRset, resolvers = around the world instantly (as they query the zone for positive answers) = invalidate the cached NSs and go back to the parent. That seems like = suboptimal behavior to me. > In the case of resolver that does "Fetch NS" upon seeing the referral = and adheres to RFC2181 credibility rules, it will always ignore NS set = in authority section. Fair enough, but why do I have to do that extra query in order to solve = this problem? > If a zone wants changes to propagate quickly it should use a smaller = TTL. Resolvers should implement a MAX TTL both to purge old data faster, = and to adopt faster to changes. Agreed. However, I don't think there is any advice what a good max TTL = value should be. 2 days? 7 days? >> And overall, I think replace-with-min-TTL should be standardized. = Because even "Credibility> replace" can have a problem: The parent = wants a deliberate shorter TTL for the NS set, but the child can = override it. >>=20 >> For example, .com wants a 2 day TTL, but the child overrides it with = a 7 day TTL, which still gives a 7-day 'no-revocation' window for any = preseeded domains. This could be even worse for various dynamic DNS = services which allow delegation. >>=20 >>=20 > well in the case of TLD's the TTL on referrals ranges from 600 (10min) = to 345600 (4 days) with 1 day as the median value and most common one. > Based on a sample of 180 google. domains out of 310 TLD's. >=20 > Do you want everyone that has a parent with 600-3600 TTL on parent = side NS records to force that policy on all their children? I don't, at least. I'd like to preserve as much of the current DNS = behavior here as we can (thus, I really don't like the bailiwick rule = that the paper authors recommend, since it will force all zones to be = parent-centric, which is a major change to current behavior.) I would think that if the rule was: Credibility > Replace, update TTL Credibility =3D=3D Replace, keeping existing TTL then you would get the desired behavior. That is, the first NS RRset = from the child would update the RRset as normal, allowing the child to = have a different NS RRset and whatever TTL they choose. And when the = child changes their NS RRset, it propagates at the same speed it does = today (faster than the TTL expiration). But the resolver will always = revaluate the parent delegation after at most 2 TTL intervals. -- David Blacka =20 Principal Verisign Infrastructure Engineering --Apple-Mail=_776FF2E8-9369-4D78-B884-92B70847C711 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMpzCCBhow ggUCoAMCAQICEBc0Avppt6vT9KJWAKLsKTAwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDMwMzAwMDAwMFoXDTE5MDMwMjIzNTk1OVowgbAxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZBVVIHbQdG81jb1cp+jOE4D5vUIaST JqKfkRcKNC8Q7l/sEuBplO3NRos9MRwdagtQtfeTiZC8NwQ1IfbPIAtd3BO4u5WRzWdD2G4BRTbK C/nkXDtJYGVgFD2m+OXsS31p4ryXlZo2OhbKQvXZof0qUWI/79smv37sOG9jRsPHUPVeMVtqtuHf YoG0PBNOfyu0Qq2W4a2RzYToKLekE4cJejlMLIsq8fk5J3Vb/hicWuNA9nVS8K5OZJ7dmNVxiqA6 yvWTt5u0lDLCRjYBUWuQ95AIG3yyTnCP8A39k3jlP24fYcIe1r1By2Fk7uzH/L9sOnrSFL8Aq9WS zws+u0UCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMHAGA1Ud IARpMGcwZQYLYIZIAYb4RQEHFwIwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTA3MB0GA1UdDgQWBBTVH5Sm O27W26S0sXCieoiKViFvFTCB8AYDVR0jBIHoMIHloYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IQYXDLSYxfmEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAFTXCpaBB Rq5kc0XwUen7u5EsOzy7iiwvAHrsd7PKLCHg0NSbZKWg4Tzk/Yl5HRl59esmG7e6avTxiEaDG7OV 2+BX5sEfFvKQmtTFyiI3sozDNs+nCFQ+ksSzNVS0msKRSX22qik6AH6diXmQvcb0PIM4QuZadhb+ qwxac5AvA8IKgfPkaXdnIpcotuqtKaqHe60qUw7hnCpN9gamcUoNDVx0Gu1nObq2usSjCVvXWiYY ohDin9MHLkmJ1uYOoRzsQA4WXVAa11UpMXsnd6JotLVKLnrjgZEdK0id0RTBpVbcI9VgxP1LCEaw rYgwfjsT08wUtdampqUUPcljHG4SzDCCBoUwggVtoAMCAQICECvwr+5g4ykMmRdZyEk9APUwDQYJ KoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNz IDIgRW1wbG95ZWUgQ0EgLSBHMzAeFw0xMTA1MTEwMDAwMDBaFw0xMjA1MTAwMDAwMDBaMGsxaTAQ BgNVBAsUCVZDT1JQIFVBUzAUBgNVBAMTDUJsYWNrYSwgRGF2aWQwHQYDVQQKFBZWZXJpU2lnbiBJ bmMuIFZDT1JQVUFTMCAGCSqGSIb3DQEJARYTZGF2aWRiQHZlcmlzaWduLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOFr4D6qtYX78Fwj5I+EKxkemPlg5PON2FAMElOxon6vuLv7 yRUPr7FdNu1RDd0QYni5EMQ/2cNpjQVRSrfrCNqoWkJ9y3iUHnQH+/29uOuafcxjZ11BaUo1AwpB ifMJD4PgPv4aP3kuusxY0lI3rVXJKnezejgRRGO+6n68VYQnbunJ0P0cdJvU+ZNpOkKj9y8eTG0h ynFnBP0UAgQ2f+E0c3u67ie54rHbdDNVMGECvjXjWs5KhXMR68tGCE2K7roer2v27N8VIWq5jrIU q9PLx8zjI6FThbu9ZzQCoToc7UGmeHV/oUiWKheAavj/D4iVupdZ07SPYUEnGGd5wYsCAwEAAaOC At0wggLZMAkGA1UdEwQCMAAwSAYDVR0RBEEwP4ETZGF2aWRiQHZlcmlzaWduLmNvbaAoBgorBgEE AYI3FAIDoBoMGGRhdmlkYkB2Y29ycC5hZC52cnNuLmNvbTAmBgkrBgEEAYI3FQcEGTAXBg9ghkgB hvhFAQ0EiGeB6AUCAWQCAQMwYQYDVR0fBFowWDBWoFSgUoZQaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vY2FfMzBlMmNkOGJhMjkzMDljYTAyMDJkMTVkNGJjZGYzZjAvTGF0ZXN0Q1JMLmNy bAAwggEGBgNVHSMEgf4wgfuAFNUflKY7btbbpLSxcKJ6iIpWIW8VoYHQpIHNMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQFzQC+mm3q9P0olYAouwpMDBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgkqhkiG9w0BCQ8EbjBs MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAHBgUrDgMCGjAKBggqhkiG9w0C AjAKBggqhkiG9w0CBDAKBggqhkiG9w0CBTALBgkqhkiG9w0BAQUwCwYJKoZIhvcNAQEEMA0GCSqG SIb3DQEBBQUAA4IBAQBFpX/mFvxKbdeTruA4rSlIv9JREutn5/MiOpRqhvuuAEnei3ltZ2AdURZ/ 2dvNTfEeQphSCD/l9+rVxbZKEcaKxBYeV3sSAEsOVhsc+ruZKFLnwAzEm7u/rTfkyO+qYV2zWjqA Bq9UoIDTQ9ogjYZ7A0JWnYwj8VpTA2gqBqe6ya+k9/l/GuWyVm2PW/b8OGBzi4VsQYy2WE8KGHr1 nn5znY3KZswuyRQLnzlhSdwowUFDg/yaqolSWgP1HyJGs4Ek1ZL/9DGyH/QmfxCURP2Q7CIJSUYn yDNus5pZbifQbIOBA399fc0ASqM5lKbmIrAln3FQNIoX2P0RB+Hqg1HvMYIEAjCCA/4CAQEwgcUw gbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUg Q0EgLSBHMwIQK/Cv7mDjKQyZF1nIST0A9TAJBgUrDgMCGgUAoIICETAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMTAyMjU4NDBaMCMGCSqGSIb3DQEJBDEWBBTo Tha8Pqx/82HLLgF35X8nL+o2JzCB1gYJKwYBBAGCNxAEMYHIMIHFMIGwMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MSowKAYDVQQDEyFWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCECvwr+5g4ykM mRdZyEk9APUwgdgGCyqGSIb3DQEJEAILMYHIoIHFMIGwMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MSowKAYD VQQDEyFWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCECvwr+5g4ykMmRdZyEk9APUw DQYJKoZIhvcNAQEBBQAEggEAhi7JwGExqcTszBspUd53CW6936Wi3+DEgQ/LTHq8WyV3RxkQbUqH Cdt744Bi636TzWewSvoeaZhi0oIS+77CqIkqPS8oVaP5i3LdCnalEEId9o2oIqTLzsV0tfelosZa ZgqZR6+6J2ItCYg09Z9naEJFgKVP1ikNlrVBxme3J8OVmoFm0nzf05JySQXIx7Wx9kgnL50IJFkX d9tmH9RlvSqUl3r2p8WRpJ2Gtx3RGm2T3Y2/3LIQoLtWHo12YPb9kcSHtAwpNZv4x/0ruRGHuQB2 BnZ29Rs5oxUDJ8D58/GcZKO3ldS2hEz51lNqYL/yBDVYiKHwbGpYlJ+ghzO79gAAAAAAAA== --Apple-Mail=_776FF2E8-9369-4D78-B884-92B70847C711-- From wouter@nlnetlabs.nl Mon Feb 13 05:05:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F40621F854F for ; Mon, 13 Feb 2012 05:05:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBypf1NND2k2 for ; Mon, 13 Feb 2012 05:05:23 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA9521F854D for ; Mon, 13 Feb 2012 05:05:22 -0800 (PST) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q1DD5Ij0019355 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 13 Feb 2012 14:05:20 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1329138321; bh=B2l/asUaJOOYBuWQtF/VweL4dCTpsPi0Jg9TENHoE64=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=W14JHoc9zcvPff/4iMXzZVl3HcoIxwIQJVNmGonV+WZJyu/A7ziBiRv44S2qcault 92++VOQ8RGc0jngPgVPOyef3CHniRrYbiNpqlJdZi8BS+iSvLmtHuu6Ji+DX3o/kqJ asXAR4+ph2pBDATgYS9kZfy5PoByq9NFS96lU8js= Message-ID: <4F390A8E.5050200@nlnetlabs.nl> Date: Mon, 13 Feb 2012 14:05:18 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> <4F344AD0.9040607@ogud.com> In-Reply-To: <4F344AD0.9040607@ogud.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 13 Feb 2012 14:05:20 +0100 (CET) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 13:05:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Olafur, I have reviewed the document, and endorse it. Could the authors put text in 6.1.1: The OPT record is normally placed near the end of the additional section. Because then there is guidance for the 'normal case'. Why is: udpsize < 512 MUST be treated as 512 size? s/udpates/updates/ Best regards, Wouter On 02/09/2012 11:38 PM, Olafur Gudmundsson wrote: > This draft closes all issues identified so far. The draft also > addresses all Id-nits in prior version There is one change that was > not included in the WGLC version but may have been inferred: The > document Obsoletes RFC2673 Binary labels. > > If anyone objects to this version being forwarded to the IESG > please speak up now and we will start a short WGLC on that one > issue. > > thanks Olafur > > On 07/02/2012 08:01, internet-drafts@ietf.org wrote: >> Title : Extension Mechanisms for DNS (EDNS0) Author(s) >> : Joao Damas Michael Graff Paul Vixie Filename : >> draft-ietf-dnsext-rfc2671bis-edns0-08.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPOQqOAAoJEJ9vHC1+BF+NjEcP/30l277JQ8pkxTzs708I1mYI eCdVAzd2p1QBLp9vmSQf99lXVhoZ2PZEM9/EjTuz6ttT/+GPACSacF8e6AZ8F0aP vtMPCVxVEHsY8KnAcD3PRiyKVOc57+zfOZfcDjRWdp9SEcaY6gKmaymCSnKhGVXk Z432xc8SjQnenYXdGOLTXVs1SFer7XRHcgkPmz559nO4xwZT0hy+mh69Ogqnu0r1 Q32di+ypdkN5RMuriMWy78sq7qLN3HPH3ScAYqT6aqweWzHxbuO17tfQUst06q+j dfiOwg2VDftzxmp97ck7WQTARkoHldJqCUPlFjtSCkBrCt6Kejn1hriQklkwQV4v TKOSq6Ql/JUTZfulA+sb5wO0ZtjPPqZDSJrq2uivQWEhSGuDfwaB2Er8P9EjojCc dUMSEHv8IlVBrXnMXHe/81i8e5kSmiLIBkES81BzUzvmDTE+ZZ+j7WiLVHdeg9Rh z2pbV8DmkW1KSTPEbCF9hNseA4OGzJTV/XUITChrfuxAuAf4ek0Q2aKyP6k1kuDp aWZoxC4oaS5PISSwDX8BdQBgHvKxRX/tJI7xmaK3uko/mPfZ4u4USDQ2CMjJJ25/ G6IgBoN8g4JnLlrVXRd5Zf9D8NTGHcR8DqvG357TwKKx1ffwJ9S8XvfWxZvwJOI7 o14g55OGZ+NvGLrF9/uf =bHP4 -----END PGP SIGNATURE----- From fw@deneb.enyo.de Mon Feb 13 07:06:05 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D9821F84A6 for ; Mon, 13 Feb 2012 07:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VTvFVUw2yj8 for ; Mon, 13 Feb 2012 07:06:05 -0800 (PST) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4095D21F8552 for ; Mon, 13 Feb 2012 07:06:05 -0800 (PST) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RwxTf-0000yo-6I; Mon, 13 Feb 2012 16:06:03 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.72) (envelope-from ) id 1RwxTe-0008PA-Ts; Mon, 13 Feb 2012 16:06:02 +0100 From: Florian Weimer To: Olafur Gudmundsson References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> <4F344AD0.9040607@ogud.com> Date: Mon, 13 Feb 2012 16:06:02 +0100 In-Reply-To: <4F344AD0.9040607@ogud.com> (Olafur Gudmundsson's message of "Thu, 09 Feb 2012 17:38:08 -0500") Message-ID: <871upyept1.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 15:06:06 -0000 * Olafur Gudmundsson: > This draft closes all issues identified so far. I'm still worried that this specification does not provide much guidance how to determine whether an authoritative server supports EDNS. This requirement Responders which choose not to implement the protocol extensions defined in this document MUST respond with a return code (RCODE) of FORMERR to messages containing an OPT RR in the additional section and MUST NOT include an OPT record in the response. (section 8) updates RFC 1035. This should be reflected in the document header. I think this paragraph is too strict, the actual requirement is "MUST respond with FORMERR or process the query as if no OPT RR was present". The "MUST NOT include an OPT record in the response" part is still a (minor) update to RFC 1035. Originally, it was possible to generate FORMERR responses by flipping the QR bit and sending back the question packet. Section 9 should mention that mistakenly disabling EDNS might lead to a denial of service. Such a failure could be caused by a query which results in a FORMERR response, while other queries to the same server would not. From joao@bondis.org Mon Feb 13 08:57:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCF821F848C for ; Mon, 13 Feb 2012 08:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXmDXafg5dDs for ; Mon, 13 Feb 2012 08:57:30 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id BF28921F8486 for ; Mon, 13 Feb 2012 08:57: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.ams1.isc.org (Postfix) with ESMTPS id AD7185F9887 for ; Mon, 13 Feb 2012 16:57:06 +0000 (UTC) (envelope-from joao@bondis.org) Received: from dhcp-wifi-243.sql1.isc.org (unknown [149.20.50.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8346B216C6A for ; Mon, 13 Feb 2012 16:57:04 +0000 (UTC) (envelope-from joao@bondis.org) From: Joao Damas Content-Type: multipart/alternative; boundary="Apple-Mail=_B88C01A1-C173-42E3-96F0-F2B0E4D1B8AC" Date: Mon, 13 Feb 2012 08:57:04 -0800 References: <20120212132336.7D61E62047C@smtp1.bondis.org> To: dnsext@ietf.org Message-Id: <74470642-8004-4AD1-99DD-8DEA3B3B3BA1@bondis.org> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dnsext] Fwd: Undelivered Mail Returned to Sender X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 16:57:31 -0000 --Apple-Mail=_B88C01A1-C173-42E3-96F0-F2B0E4D1B8AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 resending as this apparently never made it through to the list Joao Begin forwarded message: >=20 > From: Jo=E3o Damas > Subject: Re: [dnsext] I-D Action: = draft-ietf-dnsext-rfc2671bis-edns0-08.txt > Date: 7 February 2012 05:05:19 PST > To: dnsext@ietf.org >=20 >=20 > Most edits in this version are for typo-like stuff. >=20 > One item worth noting is that this i-d now explicitly obsoletes = RFC2673 (binary labels) as they depend on extended labels which are all = also wrapped-up as part of this update to RFC2671. >=20 > Also, given the age of RFC2671 the boilerplate has been updated. >=20 > I believe all other comments had been addressed on the previous = version of the i-d. >=20 > Joao >=20 > On 7 Feb 2012, at 14:01, Internet-Drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the DNS Extensions Working = Group of the IETF. >>=20 >> Title : Extension Mechanisms for DNS (EDNS0) >> Author(s) : Joao Damas >> Michael Graff >> Paul Vixie >> Filename : draft-ietf-dnsext-rfc2671bis-edns0-08.txt >> Pages : 15 >> Date : 2012-02-07 >>=20 >> 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. >>=20 >> This document updates the EDNS0 specification (RFC 2671) based on >> feedback from deployment experience in several implementations. It >> also closes the IANA registry for extended labels created as part of >> RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name >> System") which depends on the existence of extended labels. >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-08.= txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-08.t= xt >>=20 >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >=20 >=20 >=20 --Apple-Mail=_B88C01A1-C173-42E3-96F0-F2B0E4D1B8AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
From: Jo=E3o Damas <joao@bondis.org>
Subject: = Re: [dnsext] I-D Action: = draft-ietf-dnsext-rfc2671bis-edns0-08.txt
Date: = 7 = February 2012 05:05:19 PST

Most edits in this version are for typo-like stuff.

One item = worth noting is that this i-d now explicitly obsoletes RFC2673 (binary = labels) as they depend on extended labels which are all also wrapped-up = as part of this update to RFC2671.

Also, given the age of RFC2671 = the boilerplate has been updated.

I believe all other comments = had been addressed on the previous version of the = i-d.

Joao

On 7 Feb 2012, at 14:01, Internet-Drafts@ietf.org = wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories. This draft is a work item of the DNS = Extensions Working Group of the IETF.

Title =           : Extension = Mechanisms for DNS (EDNS0)
Author(s) =       : Joao = Damas
=             &n= bsp;           Mich= ael Graff
=             &n= bsp;           Paul= Vixie
Filename =        : = draft-ietf-dnsext-rfc2671bis-edns0-08.txt
= Pages =           : = 15
Date =            : = 2012-02-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 (RFC 2671) based = on
 feedback from = deployment experience in several implementations. =  It
 also closes = the IANA registry for extended labels created as part = of
 RFC 2671 and = obsoletes RFC 2673 ("Binary Labels in the Domain = Name
 System") which = depends on the existence of extended labels.


A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671= bis-edns0-08.txt

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

This = Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bi= s-edns0-08.txt

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




= --Apple-Mail=_B88C01A1-C173-42E3-96F0-F2B0E4D1B8AC-- From ogud@ogud.com Mon Feb 13 09:18:41 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F2A21F854F for ; Mon, 13 Feb 2012 09:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKVEb-tN10lU for ; Mon, 13 Feb 2012 09:18:41 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id D914E21F8523 for ; Mon, 13 Feb 2012 09:18:40 -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 q1DHIcNU011148 for ; Mon, 13 Feb 2012 12:18:38 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F3945EE.6070008@ogud.com> Date: Mon, 13 Feb 2012 12:18:38 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl> <4F353676.6090702@ogud.com> <161E2DAB-4355-4ED8-826A-6C5A0F74CE52@icsi.berkeley.edu> <4F357920.2000008@ogud.com> <6EEB712F-42B8-4318-ABAD-C11A94F61CC6@verisign.com> In-Reply-To: <6EEB712F-42B8-4318-ABAD-C11A94F61CC6@verisign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 17:18:42 -0000 On 10/02/2012 17:58, Blacka, David wrote: > > On Feb 10, 2012, at 3:08 PM, Olafur Gudmundsson wrote: >>> >>> >>> The problem with ghosted domains is not changing the NS RRSET, its that changing the NS RRSET is also resetting the TTL. Yet given "Newer vs older data of the same credibility", isn't newer more meaningful (apart from the stickyness problem)? >>> >> TTL stretching was a REAL BAD idea, and must be stamped out. > > What do you mean by "TTL stretching"? Are you inventing new DNS terms? > Well I have been using this for a while, and I do recall where the definition originated. The issue this term is describing: When a resolver sees an RRset in an response, that it has in its cache, it compares the RRset's and if identical it updates the TTL to reflect the RRset in the response. >> >>> But changing "replace" with "replace-with-min-ttl" means you're conservative on timeout in the case of disagreement between old and new. >> >> I prefer that resolver perform Delete rather than this, that forces the resolver to reevaluate the delegation. > > So, every time a zone operator modifies the apex NS RRset, resolvers around the world instantly (as they query the zone for positive answers) invalidate the cached NSs and go back to the parent. That seems like suboptimal behavior to me. I wish you would not use the word: optimal as that is setting a value judgment without explicitly saying what you are optimizing. In the past trying to do the optimal (packet count) thing vs the safest thing has got us in problems and I do not want to see that again. What happens depends both on the behavior of the resolver and the authoritative server that is asked. For example if the authoritative server is using Minimal-answer (i.e. no authority section on positive answers). Then the resolver does not see a new version of the NS set and is denied the opportunity to following ``optimizations'' - discover that the NS set has changed - Stretch the TTL on the NS set > >> In the case of resolver that does "Fetch NS" upon seeing the referral and adheres to RFC2181 credibility rules, it will always ignore NS set in authority section. > > Fair enough, but why do I have to do that extra query in order to solve this problem? Again here you are using value judgment as what is better: fewer queries vs safety If all resolvers in 2007 had implemented "Fetch NS" and applied credibility rules Kaminsky attack would never have become an issue. Similarly when authoritative severs use minimal answers the resolver only has the parent side NS set, what should the resolver do? keep the parent side NS or lookup the Childs NS set. > >> If a zone wants changes to propagate quickly it should use a smaller TTL. Resolvers should implement a MAX TTL both to purge old data faster, and to adopt faster to changes. > > Agreed. However, I don't think there is any advice what a good max TTL value should be. 2 days? 7 days? > Personally I think 1 day if a fine upper bound. >>> And overall, I think replace-with-min-TTL should be standardized. Because even "Credibility> replace" can have a problem: The parent wants a deliberate shorter TTL for the NS set, but the child can override it. >>> >>> For example, .com wants a 2 day TTL, but the child overrides it with a 7 day TTL, which still gives a 7-day 'no-revocation' window for any preseeded domains. This could be even worse for various dynamic DNS services which allow delegation. >>> >>> >> well in the case of TLD's the TTL on referrals ranges from 600 (10min) to 345600 (4 days) with 1 day as the median value and most common one. >> Based on a sample of 180 google. domains out of 310 TLD's. >> >> Do you want everyone that has a parent with 600-3600 TTL on parent side NS records to force that policy on all their children? > > I don't, at least. I'd like to preserve as much of the current DNS behavior here as we can (thus, I really don't like the bailiwick rule that the paper authors recommend, since it will force all zones to be parent-centric, which is a major change to current behavior.) > > I would think that if the rule was: > > Credibility> > Replace, update TTL > Credibility == > Replace, keeping existing TTL > > then you would get the desired behavior. That is, the first NS RRset from the child would update the RRset as normal, allowing the child to have a different NS RRset and whatever TTL they choose. And when the child changes their NS RRset, it propagates at the same speed it does today (faster than the TTL expiration). But the resolver will always revaluate the parent delegation after at most 2 TTL intervals. > Of the two alternatives, I like "Fetch NS" much better than the logic above. Having said that I also like "Minimal answers" for authoritative servers as that forces resolvers to act more predictably :-) Olafur From Ed.Lewis@neustar.biz Mon Feb 13 10:31:28 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB3A21F879D for ; Mon, 13 Feb 2012 10:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.186 X-Spam-Level: X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjAjcWwcP1Ff for ; Mon, 13 Feb 2012 10:31:28 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id EE03E21F879C for ; Mon, 13 Feb 2012 10:31:27 -0800 (PST) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q1DIVP4j011651; Mon, 13 Feb 2012 13:31:26 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.246] by Work-Laptop-2.local (PGP Universal service); Mon, 13 Feb 2012 13:31:26 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 13 Feb 2012 13:31:26 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F390A8E.5050200@nlnetlabs.nl> References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> <4F344AD0.9040607@ogud.com> <4F390A8E.5050200@nlnetlabs.nl> Date: Mon, 13 Feb 2012 13:27:51 -0500 To: "W.C.A. Wijngaards" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 18:31:28 -0000 At 14:05 +0100 2/13/12, W.C.A. Wijngaards wrote: >Why is: udpsize < 512 MUST be treated as 512 size? My assumption: 1) For ease of implementation 2) Because if the bufsize is too small, the header might not fit. ;) There's a need to set a lower bound for bufsize large enough to allow for even a FORMERR response. That's, what 12 bytes give or take, way less than 512, but the protocol is used to 512 as hard size limit. Do you want/need to see 512 lowered? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From Ed.Lewis@neustar.biz Mon Feb 13 10:58:55 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6121F850D for ; Mon, 13 Feb 2012 10:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDCGqP9eQJh3 for ; Mon, 13 Feb 2012 10:58:54 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4993021F849C for ; Mon, 13 Feb 2012 10:58:54 -0800 (PST) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q1DIwqCT011952; Mon, 13 Feb 2012 13:58:52 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.246] by Work-Laptop-2.local (PGP Universal service); Mon, 13 Feb 2012 13:58:53 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 13 Feb 2012 13:58:53 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F3945EE.6070008@ogud.com> References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl> <4F353676.6090702@ogud.com> <161E2DAB-4355-4ED8-826A-6C5A0F74CE52@icsi.berkeley.edu> <4F357920.2000008@ogud.com> <6EEB712F-42B8-4318-ABAD-C11A94F61CC6@verisign.com> <4F3945EE.6070008@ogud.com> Date: Mon, 13 Feb 2012 13:58:50 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [dnsext] Ghost domain names X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 18:58:55 -0000 I looked briefly at the paper (http://www.isc.org/files/imce/ghostdomain_camera.pdf) and don't see this as a "vulnerability" but rather a result of a lack of revocation in the protocol. (The paper says as much.) Adding revocation isn't going to be easy. The IETF has never published a detailed document on how a cache should be managed. It's never been an "interoperability issue." (This came up at NANOG 54 again, as a result of http://www.nanog.org/meetings/nanog54/abstracts.php?pt=MTkwOCZuYW5vZzU0&nm=nanog54.) My assumption, and perhaps this is just an assumption, is that caches clip the TTL to be 1 week. At least that is what BIND was measured as doing at some time in the past. With this, anyone can then assume about a 1 week "fuzz" in the deletion of a domain name. Beyond that, it's going to get complicated. When this issue has come up in the path, it eventually goes into - what do you do about applications that persist in use of the data that has expired. Like an open SSH connection that lasts days and days when the AAAA record used to start it had a TTL of an hour? Or an open web page from which links are clicked. DNS-based data will get stale, the one control element we have is the TTL. I'd just write this: A general purpose DNS cache SHOULD limit the TTL of any record set it accepts to 1 week. An application using DNS data is RECOMMENDED to refresh the DNS data at least once per week. Why a week? It's convenient to write. A better time span would be to ask the TLD's what they are willing to accept as a "fuzz" factor when deactivating a domain name - and how long are they willing to retain historical registration records. But a week, otherwise, just seems good. I don't think this is a DNSEXT issue, I don't think a protocol change looms. Oh, and as far as TTL "stretching" aka, refreshing the set in the cache, this is a toss up. If a recursor is reacting to a referral, it won't have to look at any NS set unless it does not find the set in the cache. Maybe here the TTL of what's in the cache matters - I'd only consider fetching the NS set again if I think I'll need it before the currently held set TTLs out. With DNSSEC, I'd want to pre-fetch long enough I that I have a newly validated set in time to plop on top of the old set. I guess I'd never "stretch" a TTL, I'd get ready to bring on a new copy before losing the previous one. (Analogous to the process of re-freshing signatures in DNSSEC.) The issue seems to be - traceability and replaceability. Once a delegation is removed we need to continue to tie the delegation to the source until no cache has it around anymore. And we need to see all of the old delegation for a name to "go away" before reviving the name. I think that's the ultimately the goal. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From davidb@verisign.com Mon Feb 13 10:59:36 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AF521F850D for ; Mon, 13 Feb 2012 10:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr1KtgIMDtxD for ; Mon, 13 Feb 2012 10:59:35 -0800 (PST) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 61C8721F86B9 for ; Mon, 13 Feb 2012 10:59:34 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKTzldleFj05VPDev4sEKcXoZFf1wEfgNg@postini.com; Mon, 13 Feb 2012 10:59:35 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q1DIxTG7029531; Mon, 13 Feb 2012 13:59:29 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Feb 2012 13:59:29 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Feb 2012 13:59:28 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 13 Feb 2012 13:59:27 -0500 From: "Blacka, David" To: Olafur Gudmundsson Thread-Topic: [dnsext] perhaps we should reintroduce "resimprove" Thread-Index: AQHM59A5eDlRDuocp0+Gh3hClcI8pJY2LeqAgABmLgCAAAmsgIAARc0AgAAvrwCABFf9AIAAHCuA Date: Mon, 13 Feb 2012 18:59:27 +0000 Message-ID: <09D5B1C3-8A61-438B-94F1-B948D2A83706@verisign.com> References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl> <4F353676.6090702@ogud.com> <161E2DAB-4355-4ED8-826A-6C5A0F74CE52@icsi.berkeley.edu> <4F357920.2000008@ogud.com> <6EEB712F-42B8-4318-ABAD-C11A94F61CC6@verisign.com> <4F3945EE.6070008@ogud.com> In-Reply-To: <4F3945EE.6070008@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <0CF9BDD90524C446BAE0B8062D4F85C5@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Feb 2012 18:59:28.0433 (UTC) FILETIME=[9C81BA10:01CCEA81] Cc: "" Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 18:59:36 -0000 On Feb 13, 2012, at 12:18 PM, Olafur Gudmundsson wrote: > >>=20 >>> TTL stretching was a REAL BAD idea, and must be stamped out. >>=20 >> What do you mean by "TTL stretching"? Are you inventing new DNS terms? >>=20 > Well I have been using this for a while, and I do recall where the defini= tion originated. The issue this term is describing: Did you mean "I don't recall"? > When a resolver sees an RRset in an response, that it has in its cache, > it compares the RRset's and if identical it updates the TTL to reflect th= e RRset in the response. OK. I agree this is a bad idea. Although, in various implementation's def= ense, *why* it is a bad idea isn't necessarily obvious. If you are thinkin= g about improving the cache efficiency of your implementation, and not thin= king about "cache pinning" problems, TTL stretching seems like a good idea. >>>> But changing "replace" with "replace-with-min-ttl" means you're conser= vative on timeout in the case of disagreement between old and new. >>>=20 >>> I prefer that resolver perform Delete rather than this, that forces the= resolver to reevaluate the delegation. >>=20 >> So, every time a zone operator modifies the apex NS RRset, resolvers aro= und the world instantly (as they query the zone for positive answers) inval= idate the cached NSs and go back to the parent. That seems like suboptimal= behavior to me. >=20 > I wish you would not use the word: optimal > as that is setting a value judgment without explicitly saying what you ar= e optimizing. > In the past trying to do the optimal (packet count) thing vs the safest t= hing has got us in problems and I do not want to see that again. In the past, doing overly aggressive things have caused serious problem, to= o. My concern with the use of "Delete" it that is has the potential for cr= eating packet storms when a busy zone changes its apex NS RRset. > What happens depends both on the behavior of the resolver and the authori= tative server that is asked. > For example if the authoritative server is using Minimal-answer (i.e. no = authority section on positive answers). > Then the resolver does not see a new version of the NS set and is denied = the opportunity to following ``optimizations'' > - discover that the NS set has changed > - Stretch the TTL on the NS set Sure, minimal-answer does solve a set of problems, but I don't understand t= he consequences of widespread use of that feature. >>> In the case of resolver that does "Fetch NS" upon seeing the referral a= nd adheres to RFC2181 credibility rules, it will always ignore NS set in au= thority section. >>=20 >> Fair enough, but why do I have to do that extra query in order to solve = this problem? >=20 > Again here you are using value judgment as what is better: > fewer queries vs safety No, I'm suggesting that both are important. > If all resolvers in 2007 had implemented "Fetch NS" and applied credibili= ty rules Kaminsky attack would never have become an issue. >=20 > Similarly when authoritative severs use minimal answers the resolver only= has the parent side NS set, what should the resolver do? > keep the parent side NS or lookup the Childs NS set. I don't know what they "should" do. I suspect they keep the parent side NS= , as that it what the resolution algorithm will naturally lead. >>> If a zone wants changes to propagate quickly it should use a smaller TT= L. Resolvers should implement a MAX TTL both to purge old data faster, and = to adopt faster to changes. >>=20 >> Agreed. However, I don't think there is any advice what a good max TTL = value should be. 2 days? 7 days? >>=20 >=20 > Personally I think 1 day if a fine upper bound. What??? And disenfranchise the millions of 2 day TTLs?? >>> Do you want everyone that has a parent with 600-3600 TTL on parent side= NS records to force that policy on all their children? >>=20 >> I don't, at least. I'd like to preserve as much of the current DNS beha= vior here as we can (thus, I really don't like the bailiwick rule that the = paper authors recommend, since it will force all zones to be parent-centric= , which is a major change to current behavior.) >>=20 >> I would think that if the rule was: >>=20 >> Credibility> >> Replace, update TTL >> Credibility =3D=3D >> Replace, keeping existing TTL >>=20 >> then you would get the desired behavior. That is, the first NS RRset fr= om the child would update the RRset as normal, allowing the child to have a= different NS RRset and whatever TTL they choose. And when the child chang= es their NS RRset, it propagates at the same speed it does today (faster th= an the TTL expiration). But the resolver will always revaluate the parent = delegation after at most 2 TTL intervals. >>=20 >=20 > Of the two alternatives, I like "Fetch NS" much better than the logic abo= ve. Why? I'll admit to not really understanding exactly what "Fetch NS" entail= s. When does the resolver decide to issue the NS queries? > Having said that I also like "Minimal answers" for authoritative servers = as that forces resolvers to act more predictably :-) Clearly, you think that the current DNS behavior of returning the apex NS R= Rset in the authority section provides no value. My position is that I don= 't know that it doesn't, and thus would not like to throw that protocol fea= ture away unnecessarily. -- David Blacka =20 Principal Verisign Infrastructure Engineering From ogud@ogud.com Mon Feb 13 11:24:09 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DEC21F84E7 for ; Mon, 13 Feb 2012 11:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.329 X-Spam-Level: X-Spam-Status: No, score=-106.329 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mnt+UqzgkV-J for ; Mon, 13 Feb 2012 11:24:04 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5349A21F86E8 for ; Mon, 13 Feb 2012 11:24:03 -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 q1DJO1DA012153; Mon, 13 Feb 2012 14:24:01 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F396350.4090608@ogud.com> Date: Mon, 13 Feb 2012 14:24:00 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Blacka, David" References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl> <4F353676.6090702@ogud.com> <161E2DAB-4355-4ED8-826A-6C5A0F74CE52@icsi.berkeley.edu> <4F357920.2000008@ogud.com> <6EEB712F-42B8-4318-ABAD-C11A94F61CC6@verisign.com> <4F3945EE.6070008@ogud.com> <09D5B1C3-8A61-438B-94F1-B948D2A83706@verisign.com> In-Reply-To: <09D5B1C3-8A61-438B-94F1-B948D2A83706@verisign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: "" Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 19:24:09 -0000 On 13/02/2012 13:59, Blacka, David wrote: > > On Feb 13, 2012, at 12:18 PM, Olafur Gudmundsson wrote: > >> >>> >>>> TTL stretching was a REAL BAD idea, and must be stamped out. >>> >>> What do you mean by "TTL stretching"? Are you inventing new DNS terms? >>> >> Well I have been using this for a while, and I do recall where the definition originated. The issue this term is describing: > > Did you mean "I don't recall"? > Yes I meant "don't Recall" >> When a resolver sees an RRset in an response, that it has in its cache, >> it compares the RRset's and if identical it updates the TTL to reflect the RRset in the response. > > OK. I agree this is a bad idea. Although, in various implementation's defense, *why* it is a bad idea isn't necessarily obvious. If you are thinking about improving the cache efficiency of your implementation, and not thinking about "cache pinning" problems, TTL stretching seems like a good idea. > >>>>> But changing "replace" with "replace-with-min-ttl" means you're conservative on timeout in the case of disagreement between old and new. >>>> >>>> I prefer that resolver perform Delete rather than this, that forces the resolver to reevaluate the delegation. >>> >>> So, every time a zone operator modifies the apex NS RRset, resolvers around the world instantly (as they query the zone for positive answers) invalidate the cached NSs and go back to the parent. That seems like suboptimal behavior to me. >> >> I wish you would not use the word: optimal >> as that is setting a value judgment without explicitly saying what you are optimizing. >> In the past trying to do the optimal (packet count) thing vs the safest thing has got us in problems and I do not want to see that again. > > In the past, doing overly aggressive things have caused serious problem, too. My concern with the use of "Delete" it that is has the potential for creating packet storms when a busy zone changes its apex NS RRset. > What I wrote originally was the resolver could do one of two things: Ignore or Delete. If it does ignore the NS RRset will time out and at some point after that the resolver will find out about the change. >> What happens depends both on the behavior of the resolver and the authoritative server that is asked. >> For example if the authoritative server is using Minimal-answer (i.e. no authority section on positive answers). >> Then the resolver does not see a new version of the NS set and is denied the opportunity to following ``optimizations'' >> - discover that the NS set has changed >> - Stretch the TTL on the NS set > > Sure, minimal-answer does solve a set of problems, but I don't understand the consequences of widespread use of that feature. > The main consequence is that large set of resolvers will use the Parent side NS record. >>>> In the case of resolver that does "Fetch NS" upon seeing the referral and adheres to RFC2181 credibility rules, it will always ignore NS set in authority section. >>> >>> Fair enough, but why do I have to do that extra query in order to solve this problem? >> >> Again here you are using value judgment as what is better: >> fewer queries vs safety > > No, I'm suggesting that both are important. > >> If all resolvers in 2007 had implemented "Fetch NS" and applied credibility rules Kaminsky attack would never have become an issue. >> >> Similarly when authoritative severs use minimal answers the resolver only has the parent side NS set, what should the resolver do? >> keep the parent side NS or lookup the Childs NS set. > > I don't know what they "should" do. I suspect they keep the parent side NS, as that it what the resolution algorithm will naturally lead. > >>>> If a zone wants changes to propagate quickly it should use a smaller TTL. Resolvers should implement a MAX TTL both to purge old data faster, and to adopt faster to changes. >>> >>> Agreed. However, I don't think there is any advice what a good max TTL value should be. 2 days? 7 days? >>> >> >> Personally I think 1 day if a fine upper bound. > > What??? And disenfranchise the millions of 2 day TTLs?? > Number is up for discussion and should be configurable, but for the record this is what the current version of Unbound does. I suspect that most TTL decisions consist of pulling numbers out of a hat or looking at what someone else is doing because they know better :-) >>>> Do you want everyone that has a parent with 600-3600 TTL on parent side NS records to force that policy on all their children? >>> >>> I don't, at least. I'd like to preserve as much of the current DNS behavior here as we can (thus, I really don't like the bailiwick rule that the paper authors recommend, since it will force all zones to be parent-centric, which is a major change to current behavior.) >>> >>> I would think that if the rule was: >>> >>> Credibility> >>> Replace, update TTL >>> Credibility == >>> Replace, keeping existing TTL >>> >>> then you would get the desired behavior. That is, the first NS RRset from the child would update the RRset as normal, allowing the child to have a different NS RRset and whatever TTL they choose. And when the child changes their NS RRset, it propagates at the same speed it does today (faster than the TTL expiration). But the resolver will always revaluate the parent delegation after at most 2 TTL intervals. >>> >> >> Of the two alternatives, I like "Fetch NS" much better than the logic above. > > Why? I'll admit to not really understanding exactly what "Fetch NS" entails. When does the resolver decide to issue the NS queries? > The only time Resolver is required to do "Fetch NS" is when it discovers the existence of the delegations by getting a referral from the parent. >> Having said that I also like "Minimal answers" for authoritative servers as that forces resolvers to act more predictably :-) > > Clearly, you think that the current DNS behavior of returning the apex NS RRset in the authority section provides no value. My position is that I don't know that it doesn't, and thus would not like to throw that protocol feature away unnecessarily. > I would phrase it differently "Currently having the apex NS RRset included in authority section of positive answers provides ability for badly written resolvers to misbehave to the determent of the Internet" Background: I have been researching how to do Domain Name Transfers when DNSSEC is enabled on the domain. In doing that I realized that not all resolvers are following the protocol. The first thing I needed to educate myself was that using the word "Transfer" was a bad idea. So I now call it "changing the DNS operator". One of the questions to answer was when can the old operator turn off service ? everyone's first guess is "NS TTL" To that the followup question: which NS ? second guess is "max of the two NS's TTL" but that fails for the resolvers that stretch the TTL and have strong affinity for the domain going through the operator change, except when the old operator is doing "minimal answers" and the resolvers can not cheat. Olafur From fw@deneb.enyo.de Mon Feb 13 14:04:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9B21E8024 for ; Mon, 13 Feb 2012 14:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEn-Br9PXUIe for ; Mon, 13 Feb 2012 14:04:24 -0800 (PST) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 411A421E8020 for ; Mon, 13 Feb 2012 14:04:24 -0800 (PST) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Rx40U-0003lc-Lu; Mon, 13 Feb 2012 23:04:22 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.72) (envelope-from ) id 1Rx40U-0003Od-ER; Mon, 13 Feb 2012 23:04:22 +0100 From: Florian Weimer To: Edward Lewis References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl> <4F353676.6090702@ogud.com> <161E2DAB-4355-4ED8-826A-6C5A0F74CE52@icsi.berkeley.edu> <4F357920.2000008@ogud.com> <6EEB712F-42B8-4318-ABAD-C11A94F61CC6@verisign.com> <4F3945EE.6070008@ogud.com> Date: Mon, 13 Feb 2012 23:04:22 +0100 In-Reply-To: (Edward Lewis's message of "Mon\, 13 Feb 2012 13\:58\:50 -0500") Message-ID: <87bop28k61.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dnsext@ietf.org Subject: Re: [dnsext] Ghost domain names X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 22:04:25 -0000 * Edward Lewis: > I looked briefly at the paper > (http://www.isc.org/files/imce/ghostdomain_camera.pdf) and don't see > this as a "vulnerability" but rather a result of a lack of revocation > in the protocol. (The paper says as much.) Adding revocation isn't > going to be easy. I think before we could do that, we'd need to know how quickly the revocation needs to take effect. If the time period is rather short, this rules out many potential approaches. I'm also not sure if this is an actual problem. For a couple of years, we had unremovable names in COM & NET due to the way those zones were provisioned, and while this was abused, very likely not even intentionally, the world didn't end. (Verisign fixed this prior to the introduction of DNSSEC.) From joao@bondis.org Mon Feb 13 15:16:12 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AD321E8020 for ; Mon, 13 Feb 2012 15:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3FCl79hD5Ov for ; Mon, 13 Feb 2012 15:16:11 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 0953C21E8037 for ; Mon, 13 Feb 2012 15:16:10 -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 9A95EC9498; Mon, 13 Feb 2012 23:16:00 +0000 (UTC) (envelope-from joao@bondis.org) Received: from [IPv6:2001:4f8:3:65:81dc:4d4:27cf:75ba] (unknown [IPv6:2001:4f8:3:65:81dc:4d4:27cf:75ba]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7230D216C6D; Mon, 13 Feb 2012 23:16:00 +0000 (UTC) (envelope-from joao@bondis.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Joao Damas In-Reply-To: Date: Mon, 13 Feb 2012 15:16:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> <4F344AD0.9040607@ogud.com> <4F390A8E.5050200@nlnetlabs.nl> To: Edward Lewis X-Mailer: Apple Mail (2.1257) Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 23:16:12 -0000 That's exactly it. It could be less but that would mean you would be *almost* better off = without EDNS (you still would get the additional flag field). You would = be adding overhead to the DNS packet while limiting the packet size to a = smaller amount than plain DNS creating an increased potential for = fallback to TCP Joao On 13 Feb 2012, at 10:27, Edward Lewis wrote: > At 14:05 +0100 2/13/12, W.C.A. Wijngaards wrote: >=20 >> Why is: udpsize < 512 MUST be treated as 512 size? >=20 > My assumption: >=20 > 1) For ease of implementation > 2) Because if the bufsize is too small, the header might not fit. ;) >=20 > There's a need to set a lower bound for bufsize large enough to allow = for even a FORMERR response. That's, what 12 bytes give or take, way = less than 512, but the protocol is used to 512 as hard size limit. >=20 > Do you want/need to see 512 lowered? > --=20 > = -=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 >=20 > 2012...time to reuse those 1984 calendars! > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From internet-drafts@ietf.org Mon Feb 13 17:42:05 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1321E8043; Mon, 13 Feb 2012 17:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONYHcUeb0-Dt; Mon, 13 Feb 2012 17:42:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A5B21E801E; Mon, 13 Feb 2012 17:41:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214014148.25186.35970.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 17:41:48 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-ecdsa-05.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 01:42:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : Elliptic Curve DSA for DNSSEC Author(s) : Paul Hoffman Wouter Wijngaards Filename : draft-ietf-dnsext-ecdsa-05.txt Pages : 8 Date : 2012-02-13 This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-05.txt From paul.hoffman@vpnc.org Mon Feb 13 17:48:17 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC0F21F8584 for ; Mon, 13 Feb 2012 17:48:17 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdkJvtgiQM5d for ; Mon, 13 Feb 2012 17:48:17 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 072E021F8575 for ; Mon, 13 Feb 2012 17:48:16 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1E1mF27026566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 13 Feb 2012 18:48:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <20120214014148.25186.35970.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 17:48:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <74D29D87-FA70-46D6-B8E2-4FDFD9EFDA58@vpnc.org> References: <20120214014148.25186.35970.idtracker@ietfa.amsl.com> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1257) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-ecdsa-05.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 01:48:17 -0000 FWIW, this version was to assuage some ADs' concerns and make the = (needed) correction to the front page. --Paul Hoffman From joao@bondis.org Mon Feb 13 19:33:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAA321E804F for ; Mon, 13 Feb 2012 19:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8g7hsVtLTOq for ; Mon, 13 Feb 2012 19:33:38 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id ADEA121E804A for ; Mon, 13 Feb 2012 19:33:38 -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 0BA5FC9422; Tue, 14 Feb 2012 03:33:23 +0000 (UTC) (envelope-from joao@bondis.org) Received: from [IPv6:2001:4f8:3:65:81dc:4d4:27cf:75ba] (unknown [IPv6:2001:4f8:3:65:81dc:4d4:27cf:75ba]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CF584216C6A; Tue, 14 Feb 2012 03:33:22 +0000 (UTC) (envelope-from joao@bondis.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Joao Damas In-Reply-To: <871upyept1.fsf@mid.deneb.enyo.de> Date: Mon, 13 Feb 2012 19:33:21 -0800 Content-Transfer-Encoding: 7bit Message-Id: <82D39247-19E7-4CC9-A847-574D69B808E6@bondis.org> References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> <4F344AD0.9040607@ogud.com> <871upyept1.fsf@mid.deneb.enyo.de> To: Florian Weimer X-Mailer: Apple Mail (2.1257) Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 03:33:39 -0000 i don't think we could introduce that feature and still call this EDNS(0) Joao On 13 Feb 2012, at 07:06, Florian Weimer wrote: > * Olafur Gudmundsson: > >> This draft closes all issues identified so far. > > I'm still worried that this specification does not provide much > guidance how to determine whether an authoritative server supports > EDNS. > > This requirement > > Responders which choose not to implement the protocol extensions > defined in this document MUST respond with a return code (RCODE) of > FORMERR to messages containing an OPT RR in the additional section > and MUST NOT include an OPT record in the response. > > (section 8) updates RFC 1035. This should be reflected in the > document header. I think this paragraph is too strict, the actual > requirement is "MUST respond with FORMERR or process the query as if > no OPT RR was present". The "MUST NOT include an OPT record in the > response" part is still a (minor) update to RFC 1035. Originally, it > was possible to generate FORMERR responses by flipping the QR bit and > sending back the question packet. > > Section 9 should mention that mistakenly disabling EDNS might lead to > a denial of service. Such a failure could be caused by a query which > results in a FORMERR response, while other queries to the same server > would not. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From fw@deneb.enyo.de Tue Feb 14 00:35:28 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBFF21F8680 for ; Tue, 14 Feb 2012 00:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADJNmpO5M57U for ; Tue, 14 Feb 2012 00:35:27 -0800 (PST) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 85FCD21F867F for ; Tue, 14 Feb 2012 00:35:27 -0800 (PST) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RxDr9-0003E9-J1; Tue, 14 Feb 2012 09:35:23 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.72) (envelope-from ) id 1RxDr9-0002QC-AQ; Tue, 14 Feb 2012 09:35:23 +0100 From: Florian Weimer To: Joao Damas References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> <4F344AD0.9040607@ogud.com> <871upyept1.fsf@mid.deneb.enyo.de> <82D39247-19E7-4CC9-A847-574D69B808E6@bondis.org> Date: Tue, 14 Feb 2012 09:35:23 +0100 In-Reply-To: <82D39247-19E7-4CC9-A847-574D69B808E6@bondis.org> (Joao Damas's message of "Mon, 13 Feb 2012 19:33:21 -0800") Message-ID: <87pqdh4xtg.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 08:35:28 -0000 * Joao Damas: > i don't think we could introduce that feature and still call this EDNS(0) Which feature? With the draft, when queried with an OPT RR, you either have to answer with an OPT RR, or produce a FORMERR. This answer wouldn't be allowed anymore: ; <<>> DiG 9.7.3 <<>> @ns3.schlund.de. quantenblog.net. +dnssec +norecurse ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41252 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;quantenblog.net. IN A ;; ANSWER SECTION: quantenblog.net. 86400 IN A 212.227.229.215 ;; Query time: 34 msec ;; SERVER: 217.160.80.131#53(217.160.80.131) ;; WHEN: Tue Feb 14 09:33:21 2012 ;; MSG SIZE rcvd: 49 This definitely looks like an error in the draft to me. From acooper@cdt.org Tue Feb 14 07:24:20 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9365E21F8733 for ; Tue, 14 Feb 2012 07:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amkbOTf2vV-9 for ; Tue, 14 Feb 2012 07:24:19 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 33F4721F8487 for ; Tue, 14 Feb 2012 07:24:19 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for dnsext@ietf.org; Tue, 14 Feb 2012 10:24:17 -0500 From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Feb 2012 10:24:11 -0500 References: <8A9F06B9-5486-4D63-99A8-B5CA5C278553@cdt.org> To: dnsext@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 14 Feb 2012 07:30:19 -0800 Subject: [dnsext] Fwd: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 15:24:20 -0000 Folks on this list might be interested in this draft that is in WGLC in = GEOPRIV. Please send comments to the GEOPRIV list if you have them. Thanks, Alissa Begin forwarded message: > From: Alissa Cooper > Date: February 14, 2012 10:20:28 AM EST > To: GEOPRIV WG > Subject: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02 >=20 > This is a GEOPRIV Working Group Last Call for comments on > draft-ietf-geopriv-res-gw-lis-discovery-02 >=20 > Please send your comments to the GEOPRIV list by 27 February 2012. As = always, please remember to send a note in if you've read the document = and have no other comments other than "its ready to go" - we need those = as much as we need "I found a problem." > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv >=20 From rbarnes@bbn.com Tue Feb 14 09:12:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E0821F85CE; Tue, 14 Feb 2012 09:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.302 X-Spam-Level: X-Spam-Status: No, score=-106.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NrimWZ6X3Pe; Tue, 14 Feb 2012 09:12:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 55A0E21F8596; Tue, 14 Feb 2012 09:12:30 -0800 (PST) Received: from ros-dhcp192-1-51-43.bbn.com ([192.1.51.43]:61524) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RxLvY-000FHo-52; Tue, 14 Feb 2012 12:12:28 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "Richard L. Barnes" Date: Tue, 14 Feb 2012 12:12:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0F6D0103-8837-4AC1-AA94-AD73F80FE09B@bbn.com> References: <8A9F06B9-5486-4D63-99A8-B5CA5C278553@cdt.org> To: dnsop@ietf.org, dnsext@ietf.org X-Mailer: Apple Mail (2.1084) Cc: geopriv-ads@tools.ietf.org, geopriv-chairs@tools.ietf.org, draft-ietf-geopriv-res-gw-lis-discovery@tools.ietf.org Subject: [dnsext] Fwd: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 17:12:31 -0000 Dear DNS community, FYI: There is currently a document in GEOPRIV WGLC that makes use of = NAPTR records in the reverse DNS hierarchy, and employs a "tree-walking" = algorithm to locate records at points other than terminal points in the = hierarchy (e.g., /32 and /48 instead of /128).=20 If you have comments on this draft, please reply to geopriv@ietf.org by = 27 Feb 2012. Thanks a lot, --Richard Begin forwarded message: > From: Alissa Cooper > Date: February 14, 2012 10:20:28 AM EST > To: GEOPRIV WG > Subject: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02 >=20 > This is a GEOPRIV Working Group Last Call for comments on > draft-ietf-geopriv-res-gw-lis-discovery-02 >=20 > Please send your comments to the GEOPRIV list by 27 February 2012. As = always, please remember to send a note in if you've read the document = and have no other comments other than "its ready to go" - we need those = as much as we need "I found a problem." > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From internet-drafts@ietf.org Wed Feb 15 08:29:44 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F60521E8065; Wed, 15 Feb 2012 08:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMJvxlPtGt7m; Wed, 15 Feb 2012 08:29:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1949C21F84D7; Wed, 15 Feb 2012 08:29:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120215162919.3457.38485.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2012 08:29:19 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-ecdsa-06.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Feb 2012 16:29:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : Elliptic Curve DSA for DNSSEC Author(s) : Paul Hoffman Wouter Wijngaards Filename : draft-ietf-dnsext-ecdsa-06.txt Pages : 8 Date : 2012-02-15 This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-06.txt From paul.hoffman@vpnc.org Wed Feb 15 08:34:20 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DF721F8691 for ; Wed, 15 Feb 2012 08:34:20 -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.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYI4wdh8-6tF for ; Wed, 15 Feb 2012 08:34:19 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AE0A521F8684 for ; Wed, 15 Feb 2012 08:34:19 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1FGYIYE026196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 15 Feb 2012 09:34:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <20120215162919.3457.38485.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2012 08:34:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <58A6E00E-554B-4494-BF94-A17A2B40935F@vpnc.org> References: <20120215162919.3457.38485.idtracker@ietfa.amsl.com> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1257) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-ecdsa-06.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Feb 2012 16:34:20 -0000 At Olafur's request, we made explicit that we want IANA to use the = values we used in the examples. --Paul Hoffman From suruti94@gmail.com Wed Feb 15 12:11:49 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24B221F85ED for ; Wed, 15 Feb 2012 12:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSxgopaNYT8B for ; Wed, 15 Feb 2012 12:11:45 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 281D321F8631 for ; Wed, 15 Feb 2012 12:11:45 -0800 (PST) Received: by qafi29 with SMTP id i29so3474228qaf.10 for ; Wed, 15 Feb 2012 12:11:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xR+dSAIPkGlx6aCph1cJ84WClzXaPyfZWDqMKaH1SqM=; b=RiocB6PlIuwOzeX9d2ofmqcdsc7qmw9OV0QqnBrjW2cLjlqYBnkbg7BXza27Uu4yNW vPmpltGciln6iQa8HBPGZaAc1ArzhjtXTDUUI8JARFo2k/12z356c6BRCGTaMsCWU/wj jU/VBxHDIlakVMiL7CCUmtAdu+glCTpn1QznI= MIME-Version: 1.0 Received: by 10.229.78.215 with SMTP id m23mr16247043qck.93.1329336688428; Wed, 15 Feb 2012 12:11:28 -0800 (PST) Received: by 10.229.159.17 with HTTP; Wed, 15 Feb 2012 12:11:28 -0800 (PST) In-Reply-To: <4F33E1A6.4030902@isc.org> References: <4F33E1A6.4030902@isc.org> Date: Wed, 15 Feb 2012 12:11:28 -0800 Message-ID: From: Mohan Parthasarathy To: paul vixie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Feb 2012 20:11:49 -0000 On Thu, Feb 9, 2012 at 7:09 AM, paul vixie wrote: > based on the renewed interest in the delegation and glue ttl problem > caused by the "ghost domains" paper, i looked again at: > > http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 > > ...which i presented in prague about a year ago. the sticking point was: > > =A0 =A0B. Stopping a downward cache search when an NXDOMAIN is encountere= d. > > and all of section 3. this proposal was considered controversial since > two existing implementation (rbldnsd and tinydns) currently send > nxdomain when queried for an empty nonterminal domain name. i did not > agree that this was a problem since RBL DNS queries are always full > length (that is, for all octets or all nybbles of an inverted host > address) and since the DNSSEC specification clarified non-terminal names > as existing but empty. > RFC 4035, "3.1.3.2. Including NSEC RRs: Name Error Response" has the following text towards the end: Note that this form of response includes cases in which SNAME corresponds to an empty non-terminal name within the zone (a name that is not the owner name for any RRset but that is the parent name of one or more RRsets). I don't see anything clarified in the dnssec-bis-updates document regarding this. Could you clarify what you meant by "DNSSEC specification clarified non-terminal names as existing but empty" ? thanks mohan > i now propose that we dust off this draft, remove (B) and section 3, and > progress it not as an improvement but as a security and resiliency > requirement (so, a proposed standard) in the face of the "ghost domain" > problem. > > i may yet reintroduce the NXDOMAIN matter but i don't think that we > should logjam on it any further. > > with five shows of support i would consider the editorial work involved > here to be worth doing. > > paul > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From Ed.Lewis@neustar.biz Wed Feb 15 13:55:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569DD21E80AC for ; Wed, 15 Feb 2012 13:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.259 X-Spam-Level: X-Spam-Status: No, score=-106.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzog8E+6aZC8 for ; Wed, 15 Feb 2012 13:55:01 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id BD64F21E8032 for ; Wed, 15 Feb 2012 13:55:00 -0800 (PST) Received: from gdun-e4300.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q1FLsxSU035543; Wed, 15 Feb 2012 16:54:59 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.129.195] by gdun-e4300.cis.neustar.com (PGP Universal service); Wed, 15 Feb 2012 16:54:59 -0500 X-PGP-Universal: processed; by gdun-e4300.cis.neustar.com on Wed, 15 Feb 2012 16:54:59 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4F33E1A6.4030902@isc.org> Date: Wed, 15 Feb 2012 16:48:58 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Feb 2012 21:55:02 -0000 At 12:11 -0800 2/15/12, Mohan Parthasarathy wrote: >RFC 4035, "3.1.3.2. Including NSEC RRs: Name Error Response" has the >following text towards the end: > > Note that this form of response includes cases in which SNAME > corresponds to an empty non-terminal name within the zone (a name > that is not the owner name for any RRset but that is the parent name > of one or more RRsets). > >I don't see anything clarified in the dnssec-bis-updates document >regarding this. Could you clarify what you meant by "DNSSEC >specification clarified non-terminal names as existing but empty" ? Does RFC 4592, section 2.2 help? Probably what was meant was that DNSSEC forced a clearer understanding of empty non-terminals among other issues, which spawned RFC 4592 and the words there updating what is meant by "existence." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From vixie@isc.org Wed Feb 15 14:00:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F7B21F85C4 for ; Wed, 15 Feb 2012 14:00:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPOsWytYbLrp for ; Wed, 15 Feb 2012 14:00:15 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAB121F85E1 for ; Wed, 15 Feb 2012 14:00:15 -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 95B415F98B6; Wed, 15 Feb 2012 21:59:55 +0000 (UTC) (envelope-from vixie@isc.org) Received: from [IPv6:2001:4f8:3:30:2997:4bba:713:8fae] (unknown [IPv6:2001:4f8:3:30:2997:4bba:713:8fae]) (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 A2B63216C6D; Wed, 15 Feb 2012 21:59:53 +0000 (UTC) (envelope-from vixie@isc.org) Message-ID: <4F3C2AD6.900@isc.org> Date: Wed, 15 Feb 2012 21:59:50 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mohan Parthasarathy References: <4F33E1A6.4030902@isc.org> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Feb 2012 22:00:15 -0000 On 2/15/2012 8:11 PM, Mohan Parthasarathy wrote: > On Thu, Feb 9, 2012 at 7:09 AM, paul vixie wrote: >> ... i did not >> agree that this was a problem since RBL DNS queries are always full >> length (that is, for all octets or all nybbles of an inverted host >> address) and since the DNSSEC specification clarified non-terminal names >> as existing but empty. >> > RFC 4035, "3.1.3.2. Including NSEC RRs: Name Error Response" has the > following text towards the end: > > Note that this form of response includes cases in which SNAME > corresponds to an empty non-terminal name within the zone (a name > that is not the owner name for any RRset but that is the parent name > of one or more RRsets). > > I don't see anything clarified in the dnssec-bis-updates document > regarding this. Could you clarify what you meant by "DNSSEC > specification clarified non-terminal names as existing but empty" ? what i mean is hard to quote a chapter and verse for, but in dnssec if an authority server receives a query for a domain name which is empty of rrsets but has children, then the answer is NOERROR not NXDOMAIN, and there is no need to provide the usual proofs (of no wild card and so on) that would accompany an NXDOMAIN response. some dns implementations have been behaving this way for decades (BIND for example). others have been returning NXDOMAIN under these conditions. the original DNS spec didn't make either behaviour wrong. in DNSSEC one way is right and the other way is wrong. paul From suruti94@gmail.com Wed Feb 15 16:28:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F70D21E807B for ; Wed, 15 Feb 2012 16:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKVPEqEfthpV for ; Wed, 15 Feb 2012 16:28:21 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 37F7821E801D for ; Wed, 15 Feb 2012 16:28:13 -0800 (PST) Received: by qan41 with SMTP id 41so1752762qan.10 for ; Wed, 15 Feb 2012 16:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uZcCH8a0cr/daoQ6qrYutuOhyWCcRD6JtPzHy5PmAKw=; b=ZnNU0bkeagK90vKog8irZiry82rSUUCuSC7SQRp7J7TAgPLh5+PMqOyGmQWUfdjfKU Exak+XUQuAHJttz1b3XpRN4MUwANfZyiH9oMyxViRxTqDi00ZMuT+f3zYBomk7YlMHMa KuOCixCJZJrgZhoNRghQm2dR6RHxLbCc9PDr8= MIME-Version: 1.0 Received: by 10.229.77.134 with SMTP id g6mr212590qck.33.1329352092762; Wed, 15 Feb 2012 16:28:12 -0800 (PST) Received: by 10.229.159.17 with HTTP; Wed, 15 Feb 2012 16:28:12 -0800 (PST) In-Reply-To: <4F3C2AD6.900@isc.org> References: <4F33E1A6.4030902@isc.org> <4F3C2AD6.900@isc.org> Date: Wed, 15 Feb 2012 16:28:12 -0800 Message-ID: From: Mohan Parthasarathy To: Paul Vixie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 00:28:22 -0000 On Wed, Feb 15, 2012 at 1:59 PM, Paul Vixie wrote: > On 2/15/2012 8:11 PM, Mohan Parthasarathy wrote: >> On Thu, Feb 9, 2012 at 7:09 AM, paul vixie wrote: >>> ... i did not >>> agree that this was a problem since RBL DNS queries are always full >>> length (that is, for all octets or all nybbles of an inverted host >>> address) and since the DNSSEC specification clarified non-terminal name= s >>> as existing but empty. >>> >> RFC 4035, "3.1.3.2. =A0Including NSEC RRs: Name Error Response" has the >> following text towards the end: >> >> =A0 =A0Note that this form of response includes cases in which SNAME >> =A0 =A0corresponds to an empty non-terminal name within the zone (a name >> =A0 =A0that is not the owner name for any RRset but that is the parent n= ame >> =A0 =A0of one or more RRsets). >> >> I don't see anything clarified in the dnssec-bis-updates document >> regarding this. Could you clarify what you meant by "DNSSEC >> specification clarified non-terminal names as existing but empty" ? > > what i mean is hard to quote a chapter and verse for, but in dnssec if > an authority server receives a query for a domain name which is empty of > rrsets but has children, then the answer is NOERROR not NXDOMAIN, and > there is no need to provide the usual proofs (of no wild card and so on) > that would accompany an NXDOMAIN response. > > some dns implementations have been behaving this way for decades (BIND > for example). others have been returning NXDOMAIN under these > conditions. the original DNS spec didn't make either behaviour wrong. in > DNSSEC one way is right and the other way is wrong. > Ok. The problem is that RFC 4035, section 3.1.3.2, mentions about ENT under the name error response. That should be clarified in the dnssec-bis-updates document then. -mohan > > paul From marka@isc.org Wed Feb 15 17:24:35 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED07821E8033 for ; Wed, 15 Feb 2012 17:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgucvXY+mE77 for ; Wed, 15 Feb 2012 17:24:31 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3AD21E800E for ; Wed, 15 Feb 2012 17:24:31 -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 AF7945F98B7; Thu, 16 Feb 2012 01:24:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:15e4:7811:3ea0:7a7]) (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 95078216C6A; Thu, 16 Feb 2012 01:24:14 +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 45BEF1D66273; Thu, 16 Feb 2012 12:24:10 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <4F33E1A6.4030902@isc.org> <4F3C2AD6.900@isc.org> In-reply-to: Your message of "Wed, 15 Feb 2012 16:28:12 -0800." Date: Thu, 16 Feb 2012 12:24:10 +1100 Message-Id: <20120216012410.45BEF1D66273@drugs.dv.isc.org> Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 01:24:36 -0000 In message , Mohan Parthasarathy writes: > On Wed, Feb 15, 2012 at 1:59 PM, Paul Vixie wrote: > > On 2/15/2012 8:11 PM, Mohan Parthasarathy wrote: > >> On Thu, Feb 9, 2012 at 7:09 AM, paul vixie wrote: > >>> ... i did not > >>> agree that this was a problem since RBL DNS queries are always full > >>> length (that is, for all octets or all nybbles of an inverted host > >>> address) and since the DNSSEC specification clarified non-terminal names > >>> as existing but empty. > >>> > >> RFC 4035, "3.1.3.2. =A0Including NSEC RRs: Name Error Response" has the > >> following text towards the end: > >> > >> =A0 =A0Note that this form of response includes cases in which SNAME > >> =A0 =A0corresponds to an empty non-terminal name within the zone (a name > >> =A0 =A0that is not the owner name for any RRset but that is the parent n= > ame > >> =A0 =A0of one or more RRsets). > >> > >> I don't see anything clarified in the dnssec-bis-updates document > >> regarding this. Could you clarify what you meant by "DNSSEC > >> specification clarified non-terminal names as existing but empty" ? > > > > what i mean is hard to quote a chapter and verse for, but in dnssec if > > an authority server receives a query for a domain name which is empty of > > rrsets but has children, then the answer is NOERROR not NXDOMAIN, and > > there is no need to provide the usual proofs (of no wild card and so on) > > that would accompany an NXDOMAIN response. > > > > some dns implementations have been behaving this way for decades (BIND > > for example). others have been returning NXDOMAIN under these > > conditions. the original DNS spec didn't make either behaviour wrong. in > > DNSSEC one way is right and the other way is wrong. > > > Ok. The problem is that RFC 4035, section 3.1.3.2, mentions about ENT > under the name error response. That should be clarified in the > dnssec-bis-updates document then. > > -mohan > > > > > paul > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext ENT exists in 1035. The early DNSSEC RFC turned ENT into NXD by say there were no *names* between the end points of the NSEC record. 4035 repaired that defect by saying there were no *records* between the end points of the NSEC record. As for the paragraph in question is is warning the ENT may exist in the range covered by the NSEC record. i.e. you can't assume that because a name is in the range that NXD is correct. You need to do additional checks. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ogud@ogud.com Thu Feb 16 07:08:09 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5BA21F8648; Thu, 16 Feb 2012 07:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.506 X-Spam-Level: X-Spam-Status: No, score=-106.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUfze0DQoRVe; Thu, 16 Feb 2012 07:08:04 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 48E7221F855F; Thu, 16 Feb 2012 07:08:04 -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 q1GF81Jw042422; Thu, 16 Feb 2012 10:08:02 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F3D1BD0.3060007@ogud.com> Date: Thu, 16 Feb 2012 10:08:00 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: int-ads@tools.ietf.org, iesg-secretary@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: "" Subject: [dnsext] Publication request: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 15:08:09 -0000 Ralph, please start IETF LC for this document, requested status is: INTERNET STANDARD if that is not possible Proposed Standard is OK. thanks Olafur Changes are expected over time. This version is dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Olafur Gudmundsson ogud at ogud.com is the document shepherd I have personally reviewed this and prior versions, this document is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has had extensive review and comments over its lifetime as well as during the lifetime of its precursor RFC2671. There are no concerns with the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No IPR disclosure, this is a real important document. The precursor document was written in pre-RFC2119 style that made it sometimes hard to nail down exact intent of text, this document attempts to adress the issues with RFC2671 and various deployment issues we have run into over the years. All Normative refernecs are "Full Standard", being obsolted or "Proposed Standard". (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Quite solid there are some people that want stronger languague in certain places and others that want weaker. The WG understands the document and is overall happy with it. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes the references are split. If this document is published as Internet Standard one normative reference is a downref RFC3225 that is only included here due to the fact that a registry requested by RFC2671 was not created by IANA but backfilled much later and this document fills out the current values of the registry. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes IANA considerations section is present and actionable by IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Does not apply (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. ---- 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 (RFC 2671) based on feedback from deployment experience in several implementations. It also closes the IANA registry for extended labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name System") which depends on the existence of extended labels. The main contribution of RFC2671 was to allow larger DNS messages over UDP, beween cooperating parties, this is crucial for DNSSEC and other modern DNS uses. ---- Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? ----- Working group is solidly behind this document. ---- Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are many implemenations of this specification, the working group wish is that this be published as Internet Standard. This document is the cummulation of fair ammount of work and experience. During the WG process most of the changes in the document were stylistic and presentation ones rather than technical. From iesg-secretary@ietf.org Thu Feb 16 10:27:33 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533EC11E80A4; Thu, 16 Feb 2012 10:27:33 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h-JvSMGHoGf; Thu, 16 Feb 2012 10:27:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98D211E8094; Thu, 16 Feb 2012 10:27:28 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120216182728.12340.17697.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2012 10:27:28 -0800 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: (Elliptic Curve DSA for DNSSEC) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:27:33 -0000 The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Elliptic Curve DSA for DNSSEC' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that the intended status of this document is "Proposed Standard." The document previously went through an IETF last call with intended status of "Informational." The document is to be published as "Proposed Standard" to meet the requirements of the IANA registries to be updated. Abstract This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-ecdsa/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-ecdsa/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1597/ From suruti94@gmail.com Thu Feb 16 10:59:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B1B21F8552 for ; Thu, 16 Feb 2012 10:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vI2Jvvtq9cO for ; Thu, 16 Feb 2012 10:59:19 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C12A21F8566 for ; Thu, 16 Feb 2012 10:59:19 -0800 (PST) Received: by qafi29 with SMTP id i29so4709368qaf.10 for ; Thu, 16 Feb 2012 10:59:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Y1aRVFcPYmhqLgg/Jl8M38ouwfZjuq0YhLUXWo0MblM=; b=GBcsse11oKrqmDQMSsxWq/VBxpeeVH6PNoOle1G0XAnhPqe4TT38Mpj8xjVpepqqeo wkvAZP6bjU29WNRuv7nq8LeZtSu4idRiEPjhqerFFQ4CJDwtcnEC4AgsW4IVgNr5aDL+ YyoD7QNlvhXgicwY5/mjjMLfsO3bVNHXFlxm8= MIME-Version: 1.0 Received: by 10.229.114.222 with SMTP id f30mr2581012qcq.13.1329418758849; Thu, 16 Feb 2012 10:59:18 -0800 (PST) Received: by 10.229.159.17 with HTTP; Thu, 16 Feb 2012 10:59:18 -0800 (PST) In-Reply-To: <20120216012410.45BEF1D66273@drugs.dv.isc.org> References: <4F33E1A6.4030902@isc.org> <4F3C2AD6.900@isc.org> <20120216012410.45BEF1D66273@drugs.dv.isc.org> Date: Thu, 16 Feb 2012 10:59:18 -0800 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] perhaps we should reintroduce "resimprove" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 18:59:24 -0000 On Wed, Feb 15, 2012 at 5:24 PM, Mark Andrews wrote: > > In message , > =A0Mohan Parthasarathy writes: >> On Wed, Feb 15, 2012 at 1:59 PM, Paul Vixie wrote: >> > On 2/15/2012 8:11 PM, Mohan Parthasarathy wrote: >> >> On Thu, Feb 9, 2012 at 7:09 AM, paul vixie wrote: >> >>> ... i did not >> >>> agree that this was a problem since RBL DNS queries are always full >> >>> length (that is, for all octets or all nybbles of an inverted host >> >>> address) and since the DNSSEC specification clarified non-terminal n= ames >> >>> as existing but empty. >> >>> >> >> RFC 4035, "3.1.3.2. =3DA0Including NSEC RRs: Name Error Response" has= the >> >> following text towards the end: >> >> >> >> =3DA0 =3DA0Note that this form of response includes cases in which SN= AME >> >> =3DA0 =3DA0corresponds to an empty non-terminal name within the zone = (a name >> >> =3DA0 =3DA0that is not the owner name for any RRset but that is the p= arent n=3D >> ame >> >> =3DA0 =3DA0of one or more RRsets). >> >> >> >> I don't see anything clarified in the dnssec-bis-updates document >> >> regarding this. Could you clarify what you meant by "DNSSEC >> >> specification clarified non-terminal names as existing but empty" ? >> > >> > what i mean is hard to quote a chapter and verse for, but in dnssec if >> > an authority server receives a query for a domain name which is empty = of >> > rrsets but has children, then the answer is NOERROR not NXDOMAIN, and >> > there is no need to provide the usual proofs (of no wild card and so o= n) >> > that would accompany an NXDOMAIN response. >> > >> > some dns implementations have been behaving this way for decades (BIND >> > for example). others have been returning NXDOMAIN under these >> > conditions. the original DNS spec didn't make either behaviour wrong. = in >> > DNSSEC one way is right and the other way is wrong. >> > >> Ok. The problem is that RFC 4035, section 3.1.3.2, mentions about ENT >> under the name error response. That should be clarified in the >> dnssec-bis-updates document then. >> >> -mohan >> >> > >> > paul >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > > ENT exists in 1035. =A0The early DNSSEC RFC turned ENT into NXD by > say there were no *names* between the end points of the NSEC record. > 4035 repaired that defect by saying there were no *records* between > the end points of the NSEC record. > > As for the paragraph in question is is warning the ENT may exist > in the range covered by the NSEC record. =A0i.e. you can't assume > that because a name is in the range that NXD is correct. =A0You need > to do additional checks. > Ok, but I can't see how the text that I quoted translates to this. I would have expected to see some text for the NOERROR case. It looks like someone proposed text for this case longtime back and it did not make it to the draft. http://fixunix.com/dns/57177-rfc4035-missing-text-empty-non-terminal-proof.= html Can't tell where this was proposed. -mohan > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org From ajs@anvilwalrusden.com Tue Feb 21 14:19:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A203F21F85C6 for ; Tue, 21 Feb 2012 14:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps6KvhIWSTMy for ; Tue, 21 Feb 2012 14:19:12 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5C921F8575 for ; Tue, 21 Feb 2012 14:19:06 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CDABB1ECB41D for ; Tue, 21 Feb 2012 22:19:05 +0000 (UTC) Date: Tue, 21 Feb 2012 17:19:04 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120221221903.GR34608@mail.yitter.info> 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] ICANN variant project update X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2012 22:19:13 -0000 Dear colleagues, Apologies if you see this more than once. Because of prior interest here, I'm posting this message here, but not cross-posting. ICANN has published the final version of the Variant Issues Project report, and has published a project plan for next steps. You may read about these developments on the following pages: http://www.icann.org/en/announcements/announcement-20feb12-en.htm http://www.icann.org/en/public-comment/idn-vip-proposed-project-plan-20feb12-en.htm Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Tue Feb 21 14:26:55 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2938121F88EA for ; Tue, 21 Feb 2012 14:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yrWclvZStC5 for ; Tue, 21 Feb 2012 14:26:54 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAD411E809D for ; Tue, 21 Feb 2012 14:26: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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id C517D5F98A2 for ; Tue, 21 Feb 2012 22:26:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3991:6a11:92e9:5d76]) (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 A8918216C31 for ; Tue, 21 Feb 2012 22:26: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 C8F3F1DA58B4 for ; Wed, 22 Feb 2012 09:26:31 +1100 (EST) Date: Wed, 22 Feb 2012 09:26:30 +1100 Message-Id: <20120221222631.C8F3F1DA58B4@drugs.dv.isc.org> From: marka@isc.org To: undisclosed-recipients:; X-Mailman-Approved-At: Wed, 22 Feb 2012 07:46:34 -0800 Subject: Re: [dnsext] [dane] End of TTL during TLS setup X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2012 22:26:55 -0000 ------- Blind-Carbon-Copy To: Andrew Sullivan Cc: dane@ietf.org From: Mark Andrews References: <20120216215821.GQ29243@mail.yitter.info> <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <20120221170058.GE34608@mail.yitter.info> Subject: Re: [dane] End of TTL during TLS setup In-reply-to: Your message of "Tue, 21 Feb 2012 12:00:58 CDT." <20120221170058.GE34608@mail.yitter.info> Date: Wed, 22 Feb 2012 09:26:30 +1100 In message <20120221170058.GE34608@mail.yitter.info>, Andrew Sullivan writes: > On Tue, Feb 21, 2012 at 05:38:17PM +0100, Martin Rex wrote: > > > > To me that sounds _much_ too complicated. The TTL on a DNS record > > is not a security feature anyway, so I do not see a justification to > > treat TTLs of TLSA records any different than TTLs on other DNS > > records > > I'd actually agree with this but for the text that was already there, > which says that the negotiation has to complete before the TTL > expires. Your suggested alternative will not in some cases meet that > requirement. I presumed the WG had a reason to phrase it this way; if > not, then your suggestion is better. > > A The important time is the RRSIG's expiration time of the RRSIG that validated the RRset (i.e. you have to choose the correct one). TTL is a cache refresh parameter. You will get TTL's of zero seconds which means "use for this transaction" not "use within 0 seconds". [TTL trimming is also something that is not well specified in RFC 4035 but that is dnsext fodder for as long as dnsext exists. Personally I thing it is too early to shutdown dnsext as DNSSEC is just begining to be used widely enough for specification problems to start to surface from applications. Bcc: dnsext@ietf.org] - -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org ------- End of Blind-Carbon-Copy From peter.van.dijk@netherlabs.nl Thu Feb 23 02:39:06 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9508621F8671 for ; Thu, 23 Feb 2012 02:39:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlfZn3X2nUu8 for ; Thu, 23 Feb 2012 02:39:06 -0800 (PST) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) by ietfa.amsl.com (Postfix) with ESMTP id 017B721F8670 for ; Thu, 23 Feb 2012 02:39:04 -0800 (PST) Received: from tesla.fritz.box (a80-101-233-235.adsl.xs4all.nl [80.101.233.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 6D79DC1B78; Thu, 23 Feb 2012 11:39:02 +0100 (CET) From: Peter van Dijk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2012 11:39:01 +0100 To: dnsext@ietf.org Message-Id: <7D06DD86-7FF8-467E-B320-32B525C72B9C@netherlabs.nl> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dnsext] downcasing of names in IPSECKEY and HIP? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 10:39:06 -0000 Dear colleagues, working from dnssec-bis-updates-16 section 5.1, and 6.2 of 4034, I = gather that the rule for downcasing names in RDATA is not simply = "downcase everything that is a name", but that the RRtypes listed have = been selected for a reason. I am also under the impression that new = RRtypes are excluded from the downcasing rules. Now, types like IPSECKEY and HIP have appeared during , and their RFCs = do not explicitly state whether the names appearing in their RDATA = should be lowercased in their canonical form for DNSSEC.=20 My questions: - is the exclusion of newer types from these rules intentional? (I could = think of a few reasons) - shouldn't we expect RFCs/drafts for new RRtypes to be explicit about = downcasing and perhaps other aspects of canonicalisation? My apologies if answers to these questions are in the archives; I did a = cursory search but did not find anything. Kind regards, Peter van Dijk From marka@isc.org Thu Feb 23 03:19:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70DA21F8532 for ; Thu, 23 Feb 2012 03:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zERv6EpjM39v for ; Thu, 23 Feb 2012 03:19:11 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E1E1B21F8528 for ; Thu, 23 Feb 2012 03:19:10 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 80EDCC9427; Thu, 23 Feb 2012 11:18:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:40e7:ce67:65b9:bb72]) (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 23431216C31; Thu, 23 Feb 2012 11:18:56 +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 DFDA81DC1B7B; Thu, 23 Feb 2012 22:18:47 +1100 (EST) To: Peter van Dijk From: Mark Andrews References: <7D06DD86-7FF8-467E-B320-32B525C72B9C@netherlabs.nl> In-reply-to: Your message of "Thu, 23 Feb 2012 11:39:01 BST." <7D06DD86-7FF8-467E-B320-32B525C72B9C@netherlabs.nl> Date: Thu, 23 Feb 2012 22:18:47 +1100 Message-Id: <20120223111847.DFDA81DC1B7B@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] downcasing of names in IPSECKEY and HIP? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 11:19:12 -0000 In message <7D06DD86-7FF8-467E-B320-32B525C72B9C@netherlabs.nl>, Peter van Dijk writes: > Dear colleagues, > > working from dnssec-bis-updates-16 section 5.1, and 6.2 of 4034, I gather tha > t the rule for downcasing names in RDATA is not simply "downcase everything t > hat is a name", but that the RRtypes listed have been selected for a reason. To make those types work as the rdata can be compressed and there is no requirement for the compression to preserve case. > I am also under the impression that new RRtypes are excluded from the downcas > ing rules. > > Now, types like IPSECKEY and HIP have appeared during , and their RFCs do not > explicitly state whether the names appearing in their RDATA should be lowerc > ased in their canonical form for DNSSEC. > > My questions: > - is the exclusion of newer types from these rules intentional? (I could thin > k of a few reasons) > - shouldn't we expect RFCs/drafts for new RRtypes to be explicit about downca > sing and perhaps other aspects of canonicalisation? No. We have rules for how to validate data that you don't know the internal structure of. All new RR 's need to be compatible with those rules. That is the *entire* system needs to preserve case of domain names in all new records. If compression is used it MUST be done in a case preserving manner. It would also require signaling that the client understands the internal structure of the record. This could be done with EDNS. > My apologies if answers to these questions are in the archives; I did a curso > ry search but did not find anything. The answers are in the RFCs. http://www.ietf.org/rfc/rfc3597.txt The discussion about downcasing was triggered because the new rules were not followed and as they were DNSSEC records it wasn't noticed. > Kind regards, > Peter van Dijk > > _______________________________________________ > 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 Thu Feb 23 05:53:49 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A517521F87FB for ; Thu, 23 Feb 2012 05:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.278 X-Spam-Level: X-Spam-Status: No, score=-106.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwaJo0L41T3R for ; Thu, 23 Feb 2012 05:53:49 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9696E21F87F9 for ; Thu, 23 Feb 2012 05:53:48 -0800 (PST) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q1NDrjBk022692; Thu, 23 Feb 2012 08:53:45 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.212] by Work-Laptop-2.local (PGP Universal service); Thu, 23 Feb 2012 08:53:46 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 23 Feb 2012 08:53:46 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120223111847.DFDA81DC1B7B@drugs.dv.isc.org> References: <7D06DD86-7FF8-467E-B320-32B525C72B9C@netherlabs.nl> <20120223111847.DFDA81DC1B7B@drugs.dv.isc.org> Date: Thu, 23 Feb 2012 08:53:42 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] downcasing of names in IPSECKEY and HIP? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 13:53:49 -0000 At 22:18 +1100 2/23/12, Mark Andrews wrote: > Peter van Dijk writes: >> Dear colleagues, >> >> working from dnssec-bis-updates-16 section 5.1, and 6.2 of 4034, I >>gather tha >> t the rule for downcasing names in RDATA is not simply "downcase >>everything t >> hat is a name", but that the RRtypes listed have been selected for a reason. ... >> My apologies if answers to these questions are in the archives; I >>did a curso >> ry search but did not find anything. > >The answers are in the RFCs. http://www.ietf.org/rfc/rfc3597.txt Except that the RFCs aren't clear and contradict themselves. I'm responding because I spent a non-trivial amount of time on this very topic sometime last year. The general rule is supposed to be: if the type is compressible any domain name in the RDATA has to be downcased when doing DNSSEC operations (signing, validating). That is because the case of the domain name might change due to the order of the response packet and the extent to which the sender tries to maintain case. But, mistakes were made. Compression was defined early. A problem arose when new types, those in 1183 and later, were defined and implementers assumed that these new types should be compressed. The reason they shouldn't was related to backwards compatibility, but that wasn't seen as a crucial design goal at the time. Because some implementations of types defined in this "era" compressed the names, today we say "be prepared to see these compressed but don't compress them anymore." Hence, down casing is needed. And then there's the most frustrating case of the RRSIG. Although it was defined after the new enlightenment that new types should not be compressed, the leading implementation continued to down case the type by mistake. Kind of illustrating that code beats specification, other implementations followed the leading implementation and not the specification. To this day, if you don't down case RRSIG there will likely be interoperability problems with your implementation. From my spreadsheet, the following type codes are to be down cased for DNSSEC: 2-9,12,14,15,17,18,21,24,26,30,33,35,36,38,39,46. (Some of those are obsolete.) The types that are to be compressed on sending and might (will) be on receiving: 2-9,12,14,15. These are in the "well-known" range, those defined in STD 13 documents. Types not to be compressed when sending but might be on receiving: 17,18,21,24,26,30,33,35. The other types, 36, 38, 39, 46 are KX, A6, DNAME, and RRSIG. Except for RRSIG, these were simply erroneously defined as needing to be down cased from the start. As far as I can tell... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From Ed.Lewis@neustar.biz Thu Feb 23 08:53:05 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB8021F871D for ; Thu, 23 Feb 2012 08:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.295 X-Spam-Level: X-Spam-Status: No, score=-106.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD-AcCiRYb2r for ; Thu, 23 Feb 2012 08:53:01 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB8621F86CE for ; Thu, 23 Feb 2012 08:52:59 -0800 (PST) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q1NGqv7B024146; Thu, 23 Feb 2012 11:52:58 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.212] by Work-Laptop-2.local (PGP Universal service); Thu, 23 Feb 2012 11:52:58 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 23 Feb 2012 11:52:58 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120221222631.C8F3F1DA58B4@drugs.dv.isc.org> References: <20120221222631.C8F3F1DA58B4@drugs.dv.isc.org> Date: Thu, 23 Feb 2012 11:50:24 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] [dane] End of TTL during TLS setup X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 16:53:05 -0000 At 9:26 +1100 2/22/12, wrote: >------- Blind-Carbon-Copy ?, Well, I don't think this was meant to be private. >The important time is the RRSIG's expiration time of the RRSIG that >validated the RRset (i.e. you have to choose the correct one). TTL >is a cache refresh parameter. You will get TTL's of zero seconds >which means "use for this transaction" not "use within 0 seconds". > >[TTL trimming is also something that is not well specified in RFC 4035 >but that is dnsext fodder for as long as dnsext exists. Personally I >thing it is too early to shutdown dnsext as DNSSEC is just begining to >be used widely enough for specification problems to start to surface >from applications. Bcc: dnsext@ietf.org] Before using the value in any field (of any protocol) you need to know what it is there. The TTL is there to keep DNS cache contents fresh. It's an estimate of how long the authority server thinks the data will remain constant. The RRSIG expiry is the time at which the signature is no longer valid as proof of source authenticity and data integrity of the set it "covers." In addition, the time fields in RRSIG are providing a defense against replay attacks and a rudimentary means of dealing with the need to revoke cryptographic-based credentials. Neither of these address the correctness of the data, the timeliness of the data, the sequence of the data, etc. The TTL is there solely to enable the caching mechanism and the RRSIG dates are there solely to protect the DNSSEC validation process. Any other uses of those fields may engender unintended consequences. Have we ever ended a Telnet session because the A record TTL'd out? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From marka@isc.org Thu Feb 23 14:18:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10A621F87DC for ; Thu, 23 Feb 2012 14:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB4eLjZwxyzC for ; Thu, 23 Feb 2012 14:18:38 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id B413C21E801A for ; Thu, 23 Feb 2012 14:18:37 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0E57F5F98B6; Thu, 23 Feb 2012 22:18:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:968:e107:e473:6b83]) (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 84606216C3B; Thu, 23 Feb 2012 22:18:19 +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 B00C61DC3C81; Fri, 24 Feb 2012 09:18:16 +1100 (EST) To: Edward Lewis From: Mark Andrews References: <7D06DD86-7FF8-467E-B320-32B525C72B9C@netherlabs.nl> <20120223111847.DFDA81DC1B7B@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 23 Feb 2012 08:53:42 CDT." Date: Fri, 24 Feb 2012 09:18:16 +1100 Message-Id: <20120223221816.B00C61DC3C81@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] downcasing of names in IPSECKEY and HIP? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 22:18:39 -0000 In message , Edward Lewis writes: > At 22:18 +1100 2/23/12, Mark Andrews wrote: > > Peter van Dijk writes: > >> Dear colleagues, > >> > >> working from dnssec-bis-updates-16 section 5.1, and 6.2 of 4034, I > >>gather tha > >> t the rule for downcasing names in RDATA is not simply "downcase > >>everything t > >> hat is a name", but that the RRtypes listed have been selected for a reas > on. > ... > >> My apologies if answers to these questions are in the archives; I > >>did a curso > >> ry search but did not find anything. > > > >The answers are in the RFCs. http://www.ietf.org/rfc/rfc3597.txt > > Except that the RFCs aren't clear and contradict themselves. I'm > responding because I spent a non-trivial amount of time on this very > topic sometime last year. > > The general rule is supposed to be: if the type is compressible any > domain name in the RDATA has to be downcased when doing DNSSEC > operations (signing, validating). That is because the case of the > domain name might change due to the order of the response packet and > the extent to which the sender tries to maintain case. > > But, mistakes were made. Compression was defined early. A problem > arose when new types, those in 1183 and later, were defined and > implementers assumed that these new types should be compressed. The > reason they shouldn't was related to backwards compatibility, but > that wasn't seen as a crucial design goal at the time. Because some > implementations of types defined in this "era" compressed the names, > today we say "be prepared to see these compressed but don't compress > them anymore." Hence, down casing is needed. To compress of not is more a matter of signaling understanding of records internals. No such signaling has been defined so we don't compress as we don't now if the receiver can expand the compression. We could add a EDNS option with a bit map similar to NSEC's bitmap that signaled understanding of the type's internals. This would allow us to compress any type identified by the bit map. We would still need to do lossless compression rather than the lossy compression currently used so that DNSSEC signatures do not break. New AXFR implementations are supposed to use lossless compression, rather than lossy compression, so that the case of compressed rdata is preserved. This is done by using compression pointers that point to label sequences that have the correct case. Case preservation was one of the design goals of the DNS, it just not been well implemented. RFC 1035, 2.3.3. Character Case For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. At present, this rule is in force throughout the domain system without exception. However, future additions beyond current usage may need to use the full binary octet capabilities in names, so attempts to store domain names in 7-bit ASCII or use of special bytes to terminate labels, etc., should be avoided. > And then there's the most frustrating case of the RRSIG. Although it > was defined after the new enlightenment that new types should not be > compressed, the leading implementation continued to down case the > type by mistake. Kind of illustrating that code beats specification, > other implementations followed the leading implementation and not the > specification. To this day, if you don't down case RRSIG there will > likely be interoperability problems with your implementation. > > From my spreadsheet, the following type codes are to be down cased for DNSSE > C: > > 2-9,12,14,15,17,18,21,24,26,30,33,35,36,38,39,46. > (Some of those are obsolete.) > > The types that are to be compressed on sending and might (will) be on > receiving: > > 2-9,12,14,15. > > These are in the "well-known" range, those defined in STD 13 documents. > > Types not to be compressed when sending but might be on receiving: > > 17,18,21,24,26,30,33,35. > > The other types, 36, 38, 39, 46 are KX, A6, DNAME, and RRSIG. Except > for RRSIG, these were simply erroneously defined as needing to be > down cased from the start. > > As far as I can tell... > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > 2012...time to reuse those 1984 calendars! > _______________________________________________ > 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 tale@dd.org Fri Feb 24 07:10:47 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442D621F87E9 for ; Fri, 24 Feb 2012 07:10:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQkIRDEsC8GH for ; Fri, 24 Feb 2012 07:10:46 -0800 (PST) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id 42C2321F8770 for ; Fri, 24 Feb 2012 07:10:44 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 2A6D23F465; Fri, 24 Feb 2012 10:10:43 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20295.43122.988885.227069@gro.dd.org> Date: Fri, 24 Feb 2012 10:10:42 -0500 From: Dave Lawrence To: dnsext@ietf.org In-Reply-To: <4F390A8E.5050200@nlnetlabs.nl> References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> <4F344AD0.9040607@ogud.com> <4F390A8E.5050200@nlnetlabs.nl> Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2012 15:10:47 -0000 W.C.A. Wijngaards writes: > Could the authors put text in 6.1.1: > The OPT record is normally placed near the end of the additional section. > > Because then there is guidance for the 'normal case'. Given the interest in trying to have an EDNS-capable server include the OPT whenever possible, I'd recommend that the guidance be for the record to be first. I'd actually thought that was what earlier drafts said, but going back to them I see they didn't do it explicitly and I only inferred it because the simplest algorithm for building the reply would be "add the OPT if it fits, then add any other records until you run out of room." There are, of course, other ways of doing it, but providing guidance that it be first emphasizes the idea that the OPT is the one Additional RR that we really want to be present if at all possible. From wouter@nlnetlabs.nl Fri Feb 24 07:49:33 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F368321F866E for ; Fri, 24 Feb 2012 07:49:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siXcyNtRjJso for ; Fri, 24 Feb 2012 07:49:32 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D604021F865F for ; Fri, 24 Feb 2012 07:49:31 -0800 (PST) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q1OFnTTM059652 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 24 Feb 2012 16:49:29 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1330098570; bh=PFZb9693JNU4wiAeHWOMouzVKmssVCVjN3Yma8aGr7Q=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EwYBPZdHbmhg3T+8HfTeMmx7KIozmPnaxFYpk9H1O7pN6+7jCzjwsZv/TDdlQM9Is dt5U6uX0IcsXP+e2nlLnb9Dsydxh1UaY0mOC9h70vlGFEY6iiYwa8S4BIMH2dPUhC0 fX1Tc2kEbDel7yKtd3iTl7QkxoGqTwfn+01QXqnM= Message-ID: <4F47B189.8050407@nlnetlabs.nl> Date: Fri, 24 Feb 2012 16:49:29 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> <4F344AD0.9040607@ogud.com> <4F390A8E.5050200@nlnetlabs.nl> <20295.43122.988885.227069@gro.dd.org> In-Reply-To: <20295.43122.988885.227069@gro.dd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 24 Feb 2012 16:49:29 +0100 (CET) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2012 15:49:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dave, On 02/24/2012 04:10 PM, Dave Lawrence wrote: > W.C.A. Wijngaards writes: >> Could the authors put text in 6.1.1: The OPT record is normally >> placed near the end of the additional section. >> >> Because then there is guidance for the 'normal case'. > > Given the interest in trying to have an EDNS-capable server > include the OPT whenever possible, I'd recommend that the guidance > be for the record to be first. > > I'd actually thought that was what earlier drafts said, but going > back to them I see they didn't do it explicitly and I only inferred > it because the simplest algorithm for building the reply would be > "add the OPT if it fits, then add any other records until you run > out of room." There are, of course, other ways of doing it, but > providing guidance that it be first emphasizes the idea that the > OPT is the one Additional RR that we really want to be present if > at all possible. Yes, you want EDNS OPT to be present if at all possible. No, not at the start of the additional section, it is near the end of the additional section. The idea is that you reserve some space at the end of the packet for the EDNS OPT record. Then, you try to fit as much additional-section data and so forth as you want into the remaining space that is available. I do not think 'first' is backwards compatible. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPR7GJAAoJEJ9vHC1+BF+NZy8QALA2oUGr5AczjTSZjGpxc2QY MrSdthfcKg/qBeM9eCY+3uCUdIgqxFfy7RTETVBqv1rhiztcAlaYe6Qrj9XEQufq 7FBktDRuJO8rphFyN1VtKYxSch2UCP9nN6pAULOp4snIKbzVzVLGzziVX/O8ckK6 v37BIvxZDfPt2kf7Y0+6+q1De18JW2bCpFhLfdM46IFff9/G8DYp9trTrv6G1lc7 WKhFsuVZMVE8ING1I81+1PbO4BBEswL3TUlVUeC4uxOOhxSgkv9gV/BXMZckKbxx OparFF8BBIXvNk6pRs6JKOLB2IMiEfy2gwQYOtTipXRopuGG05K4QVh+l2IxvM8v uu39PM24vm+A9atYQUxb6TnZ936wvuVQOcYP9B5ckYr0kiwNQs8l7jrQEO3hF8Kd 3tAsSt0/WISZqVBRavnuRNupkMILS/306BFJcghFmnJwkpS9n1UyxwQjJdiKMKKN 1maDHl+IpqFaxZkC+DIHQgh5H/MLmuXKTMG1/7HPm4dAho10GfRd4Rlh8VxcjOYV HSpJmW8Qt+ztiGMopTOXfYwr4WD94aoQfBXrn/1WvXpBZ87G++H8xqzz923d08tl /+/5Bd3wMw7ny+RK3kd8KfkpDtiaFgybac00tIHNUxYUpzBjnQqSOMwF37QTuhbZ /ZPfm0SYDlnE4oq+Kgvw =24oQ -----END PGP SIGNATURE----- From tale@dd.org Fri Feb 24 08:03:10 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4FE21F8871 for ; Fri, 24 Feb 2012 08:03:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpN0cNqWSYTc for ; Fri, 24 Feb 2012 08:03:10 -0800 (PST) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id 75C9F21F87EB for ; Fri, 24 Feb 2012 08:03:10 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id E8D333F468; Fri, 24 Feb 2012 11:03:09 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20295.46269.445854.387208@gro.dd.org> Date: Fri, 24 Feb 2012 11:03:09 -0500 From: Dave Lawrence To: dnsext@ietf.org In-Reply-To: <4F47B189.8050407@nlnetlabs.nl> References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> <4F344AD0.9040607@ogud.com> <4F390A8E.5050200@nlnetlabs.nl> <20295.43122.988885.227069@gro.dd.org> <4F47B189.8050407@nlnetlabs.nl> Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2012 16:03:11 -0000 W.C.A. Wijngaards writes: > I do not think [putting the OPT] 'first' is backwards compatible. What is broken by it? From wouter@nlnetlabs.nl Fri Feb 24 08:10:42 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2344921F862B for ; Fri, 24 Feb 2012 08:10:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNiZEU4txeDJ for ; Fri, 24 Feb 2012 08:10:40 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E5421F8636 for ; Fri, 24 Feb 2012 08:10:39 -0800 (PST) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q1OGAc9Y080374 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 24 Feb 2012 17:10:38 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1330099839; bh=e6nl8uapEGIm5pLDLYLFYBHuuHFzqnMqgcuLAl/0VEE=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=BVb1xZGPR5Mplxp3zBsjVkv8byvEbyEQ9c0NUMpfnNL8kauY2+5AMqFLRzox0LA2e 2We7MZQ0QI5qk080zvHH66EdOBhcd3DkqAUSfaUaxR/0oVv8SjAWVGM13bpJttfadd BUTq0bzxtF6VtUAtLJ7Mfml9TPHOsFFoWa8SlT9o= Message-ID: <4F47B67E.1090801@nlnetlabs.nl> Date: Fri, 24 Feb 2012 17:10:38 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> <4F344AD0.9040607@ogud.com> <4F390A8E.5050200@nlnetlabs.nl> <20295.43122.988885.227069@gro.dd.org> <4F47B189.8050407@nlnetlabs.nl> <20295.46269.445854.387208@gro.dd.org> In-Reply-To: <20295.46269.445854.387208@gro.dd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 24 Feb 2012 17:10:38 +0100 (CET) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2012 16:10:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dave, On 02/24/2012 05:03 PM, Dave Lawrence wrote: > W.C.A. Wijngaards writes: >> I do not think [putting the OPT] 'first' is backwards >> compatible. > > What is broken by it? Today's custom in creating the packets puts the EDNS OPT at the end. I do not know of any code that fails, I thought mine would, but a quick scan into the code reveals it works fine. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPR7Z+AAoJEJ9vHC1+BF+NplgP/3A50guoFyzb4PlZveZAEc5Q JELypNhyHI+OySm2C3AHRafuvvA5GGsYcofqQmWXPsp7UDesGMd1I9dPKND2WUAn E74FfED9En4Zc6zuDHzaGPnsB2LYBnnJfeNei0j4835uph/QzvXgRIK2K4lfB5yM 3fODAkZge2HobnoiKZzhI9D5mUbU9bKz/Azk0T0kRItJndvxu0upx8ECI1prD8zl 0VqJsd+FHaRWhJrBAG1XsfGFLxoYjzb+0gyxcYdTV3BEw54j+yi0EIZCuF0jDVVJ ItfTWXIPbpzf4zERyDmPNcEjkhqyv6yn1Ss8giaCwYuWhfTZ5q79Ygwp+8vBNKd8 OR606yo9tG4l2J/R8TRSbp7G+BJPJI2pVgYJv9JWRI49S1lr3GOa3RksChQ6PCaL 20hdTtp2po4ZOPlTPbCqQwdXBNypqrFGOKidat9/+vvmrf2zWApxGrMp8iDAuAHK UuoewCdNVzhznP7AhnFkmGXncVzX6SiQfy60YiIIVlSrTTrYCMfXlp2uVU4zYKJw ytnHvYvI7Ua0JS0+V8+crHUpSnC/dUqv7y4OkuztCwzBQL3OIR1g/27KEGYKpomX oEBa3JqhbHgCD/Z0J9KcrGaJF4QmAmF9p2V8wk3sfsDxjmZtnzyZ77oj6B3BgqZ+ 7iXC2tNljNywoPq2y7Zm =JeKK -----END PGP SIGNATURE----- From marka@isc.org Fri Feb 24 15:13:54 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA6121F864C for ; Fri, 24 Feb 2012 15:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9MxU-TE8E3C for ; Fri, 24 Feb 2012 15:13:54 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id DEC6521F863D for ; Fri, 24 Feb 2012 15:13: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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7F90A5F98E3; Fri, 24 Feb 2012 23:13:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:19cd:13a9:7603:7c9e]) (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 A0C5B216C31; Fri, 24 Feb 2012 23:13:07 +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 423BF1DCEE77; Sat, 25 Feb 2012 10:13:00 +1100 (EST) To: "W.C.A. Wijngaards" From: Mark Andrews References: <20120207130116.22821.43383.idtracker@ietfa.amsl.com> <4F344AD0.9040607@ogud.com> <4F390A8E.5050200@nlnetlabs.nl> <20295.43122.988885.227069@gro.dd.org> <4F47B189.8050407@nlnetlabs.nl> <20295.46269.445854.387208@gro.dd.org> <4F47B67E.1090801@nlnetlabs.nl> In-reply-to: Your message of "Fri, 24 Feb 2012 17:10:38 BST." <4F47B67E.1090801@nlnetlabs.nl> Date: Sat, 25 Feb 2012 10:12:59 +1100 Message-Id: <20120224231300.423BF1DCEE77@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2012 23:13:54 -0000 You always need to reserve the space. The OPT record is a extension of the DNS header. OPT takes precedence over answers. Once you have reserved the space putting it at the end is easy. If I was doing EDNS again I would have used opcode "EDNS" and added the extra fields immediately after the existing header before the question. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Mon Feb 27 10:04:47 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E091D21F84E4 for ; Mon, 27 Feb 2012 10:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj72QrI-LGef for ; Mon, 27 Feb 2012 10:04:45 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 54B8021F84E2 for ; Mon, 27 Feb 2012 10:04:45 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5E76F1ECB41C for ; Mon, 27 Feb 2012 18:04:44 +0000 (UTC) Date: Mon, 27 Feb 2012 13:04:42 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120227180441.GQ48576@mail.yitter.info> 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] Session scheduled for Paris X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2012 18:04:48 -0000 Dear colleagues, The DNSEXT session for Paris has been scheduled. 2011-03-27 at 17:10 Paris time. Conflicts: marf, iccrg, netconf, sipcore, isis, mile. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon Feb 27 10:10:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EC421F85AA for ; Mon, 27 Feb 2012 10:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOAkQGmUsp-8 for ; Mon, 27 Feb 2012 10:10:24 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 50DAB21F8702 for ; Mon, 27 Feb 2012 10:10:24 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A860E1ECB41C for ; Mon, 27 Feb 2012 18:10:23 +0000 (UTC) Date: Mon, 27 Feb 2012 13:10:21 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120227181021.GS48576@mail.yitter.info> References: <20120227180441.GQ48576@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120227180441.GQ48576@mail.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Session scheduled for Paris X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2012 18:10:25 -0000 On Mon, Feb 27, 2012 at 01:04:42PM -0500, Andrew Sullivan wrote: > Dear colleagues, > > The DNSEXT session for Paris has been scheduled. > > 2011-03-27 at 17:10 Paris time. Because, of course, we're the timetravel WG. Sorry about that, it'll be 2012-03-27. A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Mon Feb 27 10:50:14 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054D221F87C9 for ; Mon, 27 Feb 2012 10:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwjHxSUzl4Ot for ; Mon, 27 Feb 2012 10:50:13 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC1421F87A3 for ; Mon, 27 Feb 2012 10:50:13 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1RIoARc044845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Feb 2012 11:50:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120227181021.GS48576@mail.yitter.info> Date: Mon, 27 Feb 2012 10:50:09 -0800 Content-Transfer-Encoding: 7bit Message-Id: <77B516CD-A0B5-4A5E-BA01-B2192FEC6645@vpnc.org> References: <20120227180441.GQ48576@mail.yitter.info> <20120227181021.GS48576@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dnsext@ietf.org Subject: Re: [dnsext] Session scheduled for Paris X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2012 18:50:14 -0000 On Feb 27, 2012, at 10:10 AM, Andrew Sullivan wrote: > On Mon, Feb 27, 2012 at 01:04:42PM -0500, Andrew Sullivan wrote: >> Dear colleagues, >> >> The DNSEXT session for Paris has been scheduled. >> >> 2011-03-27 at 17:10 Paris time. > > Because, of course, we're the timetravel WG. RFC 1035 says that TTLs are positive integers, but there is no "MUST" there. --Paul Hoffman From ajs@anvilwalrusden.com Tue Feb 28 13:43:56 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AD421F8574 for ; Tue, 28 Feb 2012 13:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogDRUQgLrIA0 for ; Tue, 28 Feb 2012 13:43:55 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D770D21F8533 for ; Tue, 28 Feb 2012 13:43:55 -0800 (PST) Received: from mail.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id AE2FD1ECB41C for ; Tue, 28 Feb 2012 21:43:54 +0000 (UTC) Date: Tue, 28 Feb 2012 16:43:53 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120228214352.GQ51122@mail.yitter.info> References: <20120207151820.GE9478@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120207151820.GE9478@crankycanuck.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 21:43:56 -0000 Dear colleagues, On 7 Feb I noted some outstanding issues that were pending prior to the end of WGLC. I want to go through the results of the discussion I saw. On Tue, Feb 07, 2012 at 10:18:20AM -0500, Andrew Sullivan wrote: > ISSUE 1: Indeterminacy of Indeterminate > DEFAULT ACTION: none. Without proposed text that finds strong > support, this issue will be left out of the document. There was not proposed text and strong support, so the issue is not taken up. To my eyes, the discussion mostly revealed that there are subtle inconsistencies but that it doesn't seem to have a practical difference. > ISSUE 2: Ignoring CNAME signatures > DEFAULT ACTION: none. This is the plan. > ISSUE 3: Alter section 5.10 > DEFAULT ACTION: Include the "If a site has only a single trust > anchor …" sentence, and exclude the other proposed sentences. This is the plan. Editors, please make that adjustment. > ISSUE 4: Request to change the language in 5.6 > DEFAULT ACTION: Use the first formulation proposed ("In order to > interoperate with implementations that ignore this rule on > sending, resolvers need to allow either the DO bit to be set or > unset when receiving responses.") This is the plan. Editors, please make that adjustment. > ISSUE 5: The CD bit redux > DEFAULT ACTION: none. There was no follow up discussion on this, and I did not see expressed support for Mark Andrews's proposed change, so that's the plan. Sam, as editor you said you'd tracked some other items and were planning to follow up. Will you do that as soon as possible on the list, please? Apart from those issues, I believe the document has received enough review that it can be sent to the IESG. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From internet-drafts@ietf.org Wed Feb 29 07:28:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B46921F8685; Wed, 29 Feb 2012 07:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im6PkjvcyKEB; Wed, 29 Feb 2012 07:28:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B98F21F866B; Wed, 29 Feb 2012 07:28:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120229152815.11476.69439.idtracker@ietfa.amsl.com> Date: Wed, 29 Feb 2012 07:28:15 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-ecdsa-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 15:28:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : Elliptic Curve DSA for DNSSEC Author(s) : Paul Hoffman Wouter Wijngaards Filename : draft-ietf-dnsext-ecdsa-07.txt Pages : 8 Date : 2012-02-29 This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-07.txt From ondrej.sury@nic.cz Wed Feb 29 10:03:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5A21F86F6; Wed, 29 Feb 2012 10:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, GB_VISITOURSITE=2, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixYJFigWgBvh; Wed, 29 Feb 2012 10:03:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 13C7121F86D3; Wed, 29 Feb 2012 10:03:39 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id A96522A2EF1; Wed, 29 Feb 2012 19:03:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330538618; bh=WsQiALbBkt8d3NrSACG9Ia0qtpCgP6lRZLpHRExqaIs=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=WxuCOe9D6DKXgnQTLXoeUAv86C5RE+qiyaAnTfOJr+YfekgAnVfP/vtZCga2y9fYi f5ufWHVMQoPTADW322fX+4ZWYm/RENYNltySh484VZ4lj+HtoYP7iFdenwq4kGRCvI 0dWcTQ5i11FYGNvWpKxH5jYED0hWfFMv6D/jq5ik= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 19:03:37 +0100 References: <4F4E4EBB.8010307@nic.cz> To: dns-operations@lists.dns-oarc.net, tech@centr.org, dns-wg@ripe.net, members@dns-oarc.net, dnsop@ietf.org, dnsext@ietf.org Message-Id: <1B14614E-0C92-4E6A-8EF5-C569686DEF4C@nic.cz> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dnsext] Knot DNS v1.0.0 released X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 18:03:40 -0000 Hi all, I wouldn't normally crosspost this, but since it's our 1.0.0 version... So sorry for duplicates and please download, enjoy, awe, test and report = bugs :). Thanks, Ondrej Begin forwarded message: > From: Lubos Slovak > Subject: [knot-dns-users] Knot DNS v1.0.0 released! > Date: 29. =C3=BAnora 2012 17:13:47 GMT+01:00 > To: knot-dns-users@lists.nic.cz >=20 > Dear Knot DNS users, >=20 > special days deserve special events and this day will surely be = extraordinary not only for us, but for the whole DNS community. CZ.NIC = Labs released first stable version of Knot DNS! >=20 > Please visit our website http://www.knot-dns.cz for more information = and all relevant links. >=20 > Source files are available here: = http://public.nic.cz/files/knot-dns/knot-1.0.0.tar.gz > (SHA256: = ab947ff09655f44bd4106da65764810ff760b646b83e9b0939ee994f943372a6) > Packages will be available shortly from usual repositories. = Instructions on how to setup them are available at = http://www.knot-dns.cz. >=20 > Lots of testing has been done in the past few weeks and we believe = Knot DNS is as stable and bugfree as possible. Thank you all for support = and feedback! >=20 > We will continue developing Knot DNS - there is still place for a lot = of optimizations, minor tweaks or new features, so stay tuned for next = releases. >=20 > Thank you again for using Knot DNS! -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------