From dnsext-bounces@ietf.org Wed Feb 1 04:27:12 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8329721F85E5; Wed, 1 Feb 2012 04:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328099232; bh=72RoYQZR1LkQ7MgNyodZVL4KL6Ae0R0k85T0dO5qhkA=; h=Date:From:To:Message-ID:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=DUOqalxTkwDxDuaeXHAl3ll/GhFYdWbU/Hu7kjOtqVu9oIdg3V/NAOV1a/pHnexMS mwcEQ7KKUTYDyDGt0gIR8FFn6S3SVZxwhDkd/ggMjeWBD+7eqIO4I2EXpRnkKjf4/Q OalFGf711qTN1ADN0GFjFdvuMV9Egfd52UrxURWs= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 dnsext-bounces@ietf.org Wed Feb 1 06:17:41 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FDC11E886B; Wed, 1 Feb 2012 06:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328105861; bh=wxb6ubctLISoQ++qM4MaG4KyN5miDnerxXgvcutG3Eg=; h=Message-ID:From:To:References:Date:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=LnXwoW4z/iU+maS8ZV4OP1DlB9vpBeGJ77S2qzqftPJ636GrCziEdtHQ6XM7jI/J8 rKGbdAiWEV3HG0Iax0YLs+GLH9+UKl2Zc4hK6o6jhUfmSx/HFWqfq9dfdiMbN+ZOrw 7Aj0kGfdsN3AfrFMWkaRNNT9CTAyeLhtEJ6wz1eQ= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 1 06:42:50 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E6411E832D; Wed, 1 Feb 2012 06:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328107370; bh=101eOZ/7TC5jL8ukeNrq5vt1eF6B9WFxi9hXO25BVxc=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=RyHKx/yE050BOC2CPJSyp6oib2DQ9oBkDDZ9phLgjQIR84rjjlu1zTuVQ5zBFexTZ fC0EnMYnKTlqh3d4t5tI6URNOU7YT0nytV3egNYOOqw8g8HlzRVkhkaVGC9Y56Dvhp hy2tHY2KXglLUhELB8w226jQPk5tBWkv2Yo8uZiA= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 1 06:57:12 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7F411E8089; Wed, 1 Feb 2012 06:57:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328108232; bh=Mi9hl/XyeyacUou2q1ysn8TFYfF+B6smUY3XTC84TZU=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=g/rupFxTjls/19ROGdlbeNVDKHVWEGRfln55s4ItYx25y/bQ8auE4RNwbLricrBJI +WX1xH3pXJAe/lwiOIRNTvflmp60pZuujZ0XPUVf9VNRAXpaE+VXvSEpVuB8yqVZx4 JcVoW7v4duq2b9Gf08W5uipIlZsfONBU2+DlGapQ= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 1 07:11:25 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C349611E80E8; Wed, 1 Feb 2012 07:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328109085; bh=kOr5P5JRKgs039S04CnP/kghRZRhpDhdaXixkOeM+Vo=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=DYCmeDBTfF0ZJMcwmEUBSNgE7Ewf2WJO41a7k8MOPG5SfONYBSefXbaVe8k7WbDVg oY8+vXXcJRBGpnDmpnr8dKDh9iRm3FFsQUwA+/+AkJTxJsGpFGekM5TKoiYXGBQbVF ALXPnbbJw3mNkTCAQo1BmDicXkVNQ5zuHKhdWxYk= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 1 07:16:17 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B002911E8073; Wed, 1 Feb 2012 07:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328109377; bh=gHdMfPvRZRhiXMr9E7sQZYVgdSUPObnDsJH9PwxYMmM=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=jm4lqzRWWeybJB9qFfBiDSUOS3a7krFkPljb+0h76b3A+312Nlz9rLUpIN7GpnUBg n0s6p12PWfWd2q23BTuh3qk2RX4YtQZgPgMQ80nT372AfnHBbvBDUycZeMjs+6Yd3b XGM0dL1aH2aTzxM+YwdlNaskCP8QhOLri5WTbAEk= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 1 08:05:12 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F40C11E8093; Wed, 1 Feb 2012 08:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328112312; bh=9xSsVeghIyf1ID3J3MXRM08S96SjzFujHOfgrXDY5Rc=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=gTUrDlUQyMNrJrm95erTKUfrqv8RdqSdb4O2iM7Ry3YyjseRbzR8ahNvBEA+IQcbe iSn/PkkhGbgibnrcrLl/0O+eWnr8qUWMm1xuJzsDU2NBrNVbAOVSew/IfxAVowBc6E 7zaqL3OBzRqVZ01xcvXJdsUtT1tpw/xwmKgh3Omg= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 1 08:27:33 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E0021F88E3; Wed, 1 Feb 2012 08:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328113653; bh=hAMG93PrBW2AtJ4DtAKcQpaAZiHGnuf9ZUvOi/Bc+PE=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=draWjb/bWOlvw0kh5qynGbJttSRB5bz5TnU6oEnpw9stPQiUcW80FfcmFE24YhqHp X8NoUkxJBbVXZBjYx/DW3tF+ZU0O3zsph2UPgEW2jRLYo1m+K3ioHbuWqoulZ6x8Wn SqJWfWjnAx8vbaerRtcHSbpZ9SySIeAhe/CFTJnQ= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org -----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----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 1 10:56:00 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A8F11E8080; Wed, 1 Feb 2012 10:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328122560; bh=Wrv/kGUR1wtKEaa+4dslEZmT+ybrBwXLhza0Do31ccY=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=q5+NTnZK4UWeAea8+MNqqsPtaAp0qX/yY8VBULeQatS6LQXoxZRJHjWmcYVlza4L5 kmU0w/Mi2YuDHB3p0W5O/sivLwSe47FoAUJFUOjp1GZ0iWuY1tRX5DH6IrNVXT0baV A/RgCkqlqV53ffPAqT8gBm8KL/Rpr25BOmbiONA0= 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) 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 1 17:46:16 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4207911E80B0; Wed, 1 Feb 2012 17:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328147176; bh=L4p76V1NEOnlm0BSztpuetBAYk4nHQcK5/+hQtxEptI=; h=Message-ID:From:To:References:Date:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=V7uXrxk5xBCRQk6I0hQCfKgWbcjGHcElSg1rdqx1B/VywgKP9fU9HUqySVJOb/ynk EJ5nZgT91i0J96CZIixnJY/SrWYhWibZ3GvBiQbAdOnu2lAs8bftiEVGzCWoY8bU+O EYaqNqAbpH//NpDhxYh9UTFCEdr2uEtuHmsXl9c4= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org ----- 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 > _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 2 09:46:30 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47C321F8609; Thu, 2 Feb 2012 09:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328204790; bh=J7V8/Eity4iq98XhVGm9UB0MSPQ1cuNsK1As4fU+vC8=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=mB/Ig+uFgu6x6bm4dQM9Khouap42njrB74WTSpc2bZLoUW+xyY2q1DMew2xI5as0G S46x5LRq5qkBlcchAzQz+HPQJzL/rz7VLKBgbNhVgwMsTMf6Rd5I1jHtRz8cdG/pkP o38GkYWgefF0rDsFF5E+1sNc5OIyuihZvsINYnHo= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 3 12:47:59 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C095A21F85DA; Fri, 3 Feb 2012 12:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328302079; bh=TggINBBYSm22IXGFBiO+HWBICDV+ue30KJvRScWFXto=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=rkC9Hkkunv9ljMma7VHUwj5XeFiikqX1nPlJHINKtR8fMI56yXWAJts5FwuKQPfma 7XwFpE8Z3tUrwT2VQMnb0AjIBSCQdGLq29pZKoRjDgU+fkoNK3xkf4KvGVzpcOMXQ0 7HZIyCTcv1nM8FylYHRHWjSa8wEVZASkqlLDyz6A= 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 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 in > 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 to > 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 > _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 7 05:01:39 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D86221F87BE; Tue, 7 Feb 2012 05:01:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328619699; bh=QIhcskied4Paw0ULvuI2zwpRKyZY984/C8X12fowfrc=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=SkSP9GlpGQSiVEJ6eqsSPQ58HZfdvOkJfCSKAndm6KJFjM9aYhoc8uT7OxsDjUwbn TW+HtbtIsy6XrwIBxR713MCa7RLJrIv4qsQ8iz0hTKN/Hg3KdZtZrkGxJgjKwsPjQi VOXL9qGJ/IXHB3ZF/lj7J9JzBL4eTAYYIUqpgbhU= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 dnsext-bounces@ietf.org Tue Feb 7 07:18:25 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA31521F870A; Tue, 7 Feb 2012 07:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328627905; bh=edB7vTVuhI59HSIRpvP3542/c+wzXRwFUulN37mcXmc=; h=Date:From:To:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=IjKLqID6ygRu95SHi9DZeAxEPB6AKr/6GFzQcbTMNwjjehVU93zOLdH5KARxF1YeV OI89UplmwrnwLXfwp89uONyLXc3stdFVDFgCxoyeTWz2glR/89jvSCS5sqH1SXXJDk k5Z7K4VlHHlRUVz6GThoqKgj423R+8vFzIhpod5M= 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-Disposition: inline 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org RGVhciBjb2xsZWFndWVzLAoKV2UncmUgc3RpbGwgaW4gdGhlIFdHTEMgb24gZG5zc2VjLWJpcy11 cGRhdGVzLCBidXQgd2UgaGF2ZSBzb21lCnBlbmRpbmcgaXNzdWVzIHRvIHNvcnQgb3V0LgoKQXQg dGhlIG1vbWVudCwgd2UgaGF2ZSBzZXZlcmFsIGlzc3VlcyB0aGF0IGhhdmUgYmVlbiByYWlzZWQg aW4gdGhlCldHTEMsIGJ1dCBub3QgbXVjaCBpbiB0aGUgd2F5IG9mIHByb3Bvc2VkIHJlc29sdXRp b24uICBTYW0gV2VpbGVyIHNheXMKaGUgaXMgdHJhY2tpbmcgdGhlbTsgYW5kIG1hbnkgb2YgdGhl IGlzc3VlcyBoYXZlIGJlZW4gZmFpcmx5IG1pbm9yLApidXQgSSB3YW50IHRvIG1ha2Ugc3VyZSB0 aGF0IHdlIGRvbid0IGdvIGJhY2sgaW50byBhIGxvbmcgcGVyaW9kIG9mCmJlbmlnbiBuZWdsZWN0 IG9mIHRoaXMgZG9jdW1lbnQsIHNvIEknZCBsaWtlIHRvIGhlYXIgc29tZSByZXNwb25zZXMuCgpU aGUgZm9sbG93aW5nIGFyZSBzdWJzdGFudGl2ZSBpc3N1ZXMgdGhhdCByZXF1aXJlIG1vcmUgdGhh biBtaW5vcgpjaGFuZ2VzIHRvIHRoZSBkb2N1bWVudCwgYW5kIGZvciB3aGljaCB3ZSBuZWVkIHNv bWUgYW5zd2Vycy4gIEknbQpyYWlzaW5nIHRoZW0gbm93IGluIHRoZSBob3BlcyB0aGF0IHdlIGNh biBnZXQgdGhlbSBjbG9zZWQgYmVmb3JlIFdHTEMKZW5kcy4KCkEgcmVtaW5kZXIgdGhhdCBXR0xD IGVuZHMgYXQgdGhlIHNhbWUgdGltZSAodGhpcykgRnJpZGF5IGVuZHMuCgpJU1NVRSAxOiBJbmRl dGVybWluYWN5IG9mIEluZGV0ZXJtaW5hdGUKCkluIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9kbnNleHQvY3VycmVudC9tc2cxMjE3Ni5odG1sLApNb2hhbiBQYXJ0aGFzYXJh dGh5IGFyZ3VlcyB0aGF0IFJGQyA0MDMzIGFuZCBSRkMgNDAzNSBoYXZlCmluY29uc2lzdGVudCBk ZWZpbml0aW9ucyBvZiAiSW5kZXRlcm1pbmF0ZSIuICBSRkMgNDAzMyBzYXlzIHRoaXMgaXMKd2hh dCBJbmRldGVybWluYXRlIG1lYW5zLCBpbiBzZWN0aW9uIDU6CgogICBJbmRldGVybWluYXRlOiBU aGVyZSBpcyBubyB0cnVzdCBhbmNob3IgdGhhdCB3b3VsZCBpbmRpY2F0ZSB0aGF0IGEKICAgICAg c3BlY2lmaWMgcG9ydGlvbiBvZiB0aGUgdHJlZSBpcyBzZWN1cmUuICBUaGlzIGlzIHRoZSBkZWZh dWx0CiAgICAgIG9wZXJhdGlvbiBtb2RlLgoKUkZDIDQwMzUgaGFzIHRoaXMgZGVmaW5pdGlvbiBp biBzZWN0aW9uIDQuMzogCgogICBJbmRldGVybWluYXRlOiBBbiBSUnNldCBmb3Igd2hpY2ggdGhl IHJlc29sdmVyIGlzIG5vdCBhYmxlIHRvCiAgICAgIGRldGVybWluZSB3aGV0aGVyIHRoZSBSUnNl dCBzaG91bGQgYmUgc2lnbmVkLCBhcyB0aGUgcmVzb2x2ZXIgaXMKICAgICAgbm90IGFibGUgdG8g b2J0YWluIHRoZSBuZWNlc3NhcnkgRE5TU0VDIFJScy4gIFRoaXMgY2FuIG9jY3VyIHdoZW4KICAg ICAgdGhlIHNlY3VyaXR5LWF3YXJlIHJlc29sdmVyIGlzIG5vdCBhYmxlIHRvIGNvbnRhY3Qgc2Vj dXJpdHktYXdhcmUKICAgICAgbmFtZSBzZXJ2ZXJzIGZvciB0aGUgcmVsZXZhbnQgem9uZXMuCgpU aGVzZSB0d28gZG8gc2VlbSB0byBiZSBpbmNvbnNpc3RlbnQuICBJbiBwYXJ0aWN1bGFyLCB0aGUg bGF0dGVyCmFwcGFyZW50bHkgY2FuIGhhcHBlbiB3aGVuIGEgc2VjdXJpdHktYXdhcmUgcmVzb2x2 ZXIgd2l0aCBhbgphcHByb3ByaWF0ZSB0cnVzdCBhbmNob3IgY2FuJ3QgZmluZCBhbiB1cHN0cmVh bSB0aGF0IGNhbiBoYW5kbGUgdGhlIERPCmJpdC4gIERvZXMgYW55b25lIGhhdmUgYW4gb3Bpbmlv biBvbiB3aGF0IHRvIGRvIGFib3V0IHRoaXM/ICBXZSB3aWxsCm5lZWQgdG8gY29tZSB0byBzb21l IHZlcnkgc3Ryb25nIGFncmVlbWVudCBxdWlja2x5LCBvciBpdCB3aWxsIG5vdCBiZQphZGRyZXNz ZWQgaW4gdGhpcyBkb2N1bWVudC4KCiAgICBERUZBVUxUIEFDVElPTjogbm9uZS4gIFdpdGhvdXQg cHJvcG9zZWQgdGV4dCB0aGF0IGZpbmRzIHN0cm9uZwogICAgc3VwcG9ydCwgdGhpcyBpc3N1ZSB3 aWxsIGJlIGxlZnQgb3V0IG9mIHRoZSBkb2N1bWVudC4gIAoKSVNTVUUgMjogSWdub3JpbmcgQ05B TUUgc2lnbmF0dXJlcwoKSmlhbmthbmcgWWFvIGhhcyBzdWdnZXN0ZWQgaW4KaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Ruc2V4dC9jdXJyZW50L21zZzEyMTY2Lmh0bWwgdGhh dApsYW5ndWFnZSBiZSBhZGRlZCB0byBwZXJtaXQgaWdub3JpbmcgdW5zaWduZWQgQ05BTUUgcmVj b3JkcyB1bmRlciBzb21lCmNpcmN1bXN0YW5jZXMuICBJIGFtIGFscmVhZHkgb24gdGhlIHJlY29y ZCBhcyBwZXJzb25hbGx5IG9wcG9zaW5nIHRoaXMKY2hhbmdlLCBidXQgc3VyZWx5IEknbSBub3Qg dGhlIG9ubHkgdm9pY2UgaGVyZS4gIERvZXMgYW55b25lIGhhdmUgYW4Kb3BpbmlvbiBhYm91dCB0 aGlzPwoKICAgIERFRkFVTFQgQUNUSU9OOiBub25lLiAgV2l0aG91dCBwcm9wb3NlZCB0ZXh0IHRo YXQgZmluZHMgdmVyeQogICAgc3Ryb25nIHN1cHBvcnQsIHRoaXMgcHJvcG9zZWQgY2hhbmdlIHdp bGwgbm90IGJlIGluY2x1ZGVkLiAgSWYgYQogICAgY2hhbmdlIGlzIHRvIGJlIGFkZGVkIGFsb25n IHRoZXNlIGxpbmVzLCBpdCB3aWxsIHJlcXVpcmUgYQogICAgc2VwYXJhdGUgbGFzdCBjYWxsIG9u IGl0cyBvd24sIGJlY2F1c2UgaXQgaXMgYSBtYWpvciBjaGFuZ2UgdG8gdGhlCiAgICBwcm90b2Nv bC4KCklTU1VFIDM6IEFsdGVyIHNlY3Rpb24gNS4xMAoKUGF1bCBIb2ZmbWFuIHJlcXVlc3RzIGEg Y2hhbmdlIHRvIHNlY3Rpb24gNS4xMCBpbgpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvZG5zZXh0L2N1cnJlbnQvbXNnMTIxNzMuaHRtbC4KU3BlYWtpbmcgb25seSBwZXJzb25h bGx5LCBJIGNhbm5vdCBzZWUgYW55IG9iamVjdGlvbiB0byB0aGUgcHJvcG9zZWQKc2VudGVuY2Us ICJJZiBhIHNpdGUgaGFzIG9ubHkgYSBzaW5nbGUgdHJ1c3QgYW5jaG9yLCB0aGUgaW5mb3JtYXRp b24KaW4gdGhpcyBlbnRpcmUgc2VjdGlvbiBjYW4gc2FmZWx5IGJlIHNraXBwZWQuIiAgSSdtIGxl c3Mgc3VyZSBhYm91dAp0aGUgbW90aXZhdGlvbmFsIHNlbnRlbmNlczsgSSdtIG5vdCBldmVuIHN1 cmUgdGhleSdyZSB0cnVlLiAgRG9lcwphbnlvbmUgaGF2ZSBhbnkgdGhvdWdodHM/CgogICAgREVG QVVMVCBBQ1RJT046IEluY2x1ZGUgdGhlICJJZiBhIHNpdGUgaGFzIG9ubHkgYSBzaW5nbGUgdHJ1 c3QKICAgIGFuY2hvciDigKYiIHNlbnRlbmNlLCBhbmQgZXhjbHVkZSB0aGUgb3RoZXIgcHJvcG9z ZWQgc2VudGVuY2VzLgoKSVNTVUUgNDogUmVxdWVzdCB0byBjaGFuZ2UgdGhlIGxhbmd1YWdlIGlu IDUuNgoKVGhpcyBpcyBhbHNvIGEgcmVxdWVzdCBmcm9tIFBhdWwgSG9mZm1hbiwgaW4gdGhlIHNh bWUgcmV2aWV3LiAgSXMKdGhlcmUgYW55IG9iamVjdGlvbiB0byBoaXMgZmlyc3QgZm9ybXVsYXRp b24/ICBJIGJlbGlldmUgaGlzIHNlY29uZApmb3JtdWxhdGlvbiB3b3VsZCBhY3R1YWxseSBiZSBh IHNpZ25pZmljYW50IGNoYW5nZSB0byB0aGUgcHJvdG9jb2wsCmFuZCBhcyBzaGVwaGVyZCBJIGNh bm5vdCBhY2NlcHQgaXQgd2l0aG91dCBhIGZhaXJseSBzdHJvbmcgc2lnbmFsIGZyb20KdGhlIFdH LgoKICAgIERFRkFVTFQgQUNUSU9OOiBVc2UgdGhlIGZpcnN0IGZvcm11bGF0aW9uIHByb3Bvc2Vk ICgiSW4gb3JkZXIgdG8KICAgIGludGVyb3BlcmF0ZSB3aXRoIGltcGxlbWVudGF0aW9ucyB0aGF0 IGlnbm9yZSB0aGlzIHJ1bGUgb24KICAgIHNlbmRpbmcsIHJlc29sdmVycyBuZWVkIHRvIGFsbG93 IGVpdGhlciB0aGUgRE8gYml0IHRvIGJlIHNldCBvcgogICAgdW5zZXQgd2hlbiByZWNlaXZpbmcg cmVzcG9uc2VzLiIpCgpJU1NVRSA1OiBUaGUgQ0QgYml0IHJlZHV4CgpNYXJrIEFuZHJld3MgYXJn dWVzIGluCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kbnNleHQvY3VycmVu dC9tc2cxMjEzMy5odG1sIHRoYXQKdGhlIGFkdmljZSBhbHdheXMgdG8gc2V0IHRoZSBDRCBiaXQg aXMgYmFkIGFkdmljZS4gIERvZXMgYW55b25lIGVsc2UKd2FudCB0byB0YWtlIHVwIGhpcyBsaW5l IG9mIGFyZ3VtZW50PyAgSWYgbm90LCBJJ2xsIHJ1bGUgdGhhdCBoZSdzIGluCnRoZSByb3VnaCBv biB0aGlzLgoKV291dGVyIFdpam5nYWFyZHMgc3VnZ2VzdHMgdGhhdCB0aGUgZGlzY3Vzc2lvbiBh cm91bmQgdGhpcyBpcyB0b28KbG9uZywgYW5kIG9uZSBvZiB0aGUgZWRpdG9ycyBhZ3JlZXMuICBU byBmaW5kIGZhdWx0IHdoZXJlIGl0IGJlbG9uZ3MsCnRoZSBsb25nIGFwcGVuZGl4IG9uIHRoaXMg aXMgdGhlcmUgYXQgbXkgaW5zaXN0ZW5jZSwgYmVjYXVzZSBzZXZlcmFsCnBlb3BsZSBwcmV2aW91 c2x5IGFyZ3VlZCB0aGF0IGl0IHdhcyBuZWNlc3NhcnkgdG8gZXhwb3NlIHRoZQpjb25zZXF1ZW5j ZXMgb2YgZGlmZmVyZW50IGFwcHJvYWNoZXMgdG8gc2V0dGluZyB0aGUgQ0QgYml0LCBhbmQgeWV0 IG15CmZpbmRpbmcgd2FzIHRoYXQgdGhlcmUgd2FzIHJvdWdoIGNvbnNlbnN1cyBpbiBmYXZvdXIg b2YgdGhlICJhbHdheXMKc2V0IiBhcHByb2FjaC4gIEluIHRoZSBhYnNlbmNlIG9mIG92ZXJ3aGVs bWluZyBzdXBwb3J0IGluIGZhdm91ciBvZgpyZW1vdmluZyB0aGUgZGlzY3Vzc2lvbiwgSSB0aGlu ayBpdCBzaG91bGQgc3RheS4gIElmIHlvdSB0aGluayBpdApzaG91bGQgYmUgYWx0ZXJlZCwgdGhl biB5b3UgbmVlZCB0byBvZmZlciByZXBsYWNlbWVudCB0ZXh0IGFuZCBub3QgYXNrCnRoYXQgc29t ZW9uZSBjb21lIHVwIHdpdGggaXQuICBLZWVwIGluIG1pbmQgdGhhdCB0aGUgdGV4dCwgbG9uZyBh cyBpdAppcywgd2FzIHRoZSBzdWJqZWN0IG9mIHByb3RyYWN0ZWQgZGlzY3Vzc2lvbi4KCiAgICBE RUZBVUxUIEFDVElPTjogbm9uZS4KCkJlc3QgcmVnYXJkcywKCkFuZHJldwoKLS0gCkFuZHJldyBT dWxsaXZhbgphanNAYW52aWx3YWxydXNkZW4uY29tCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCmRuc2V4dCBtYWlsaW5nIGxpc3QKZG5zZXh0QGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0Cg== From dnsext-bounces@ietf.org Tue Feb 7 07:35:04 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8817321F87DD; Tue, 7 Feb 2012 07:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328628904; bh=be+jBzBbnr39h9hcpMgf/+RAcDhWpiHevIVh/QSQuw0=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ebUZyD82XBQkZHnHWRBnbvoCBF86HcYw1pWkHSbVDfaaMPO+uWNCP1IkS+DFJ0aYJ 6Nn39tWLnrsTXcXkDj2cxKxgPuBYST/ZE6ZUD29QeA7+w26uevDdxtsfTL9VluyMYx 8PqmIxsQicIl4xLcH6SNxo0WR53SOtKuJfv1ZRu8= 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 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQpIYXNoOiBTSEExCgpIaSBBbmRyZXcs CgpJIHN1cHBvcnQgdGhlIGRlZmF1bHQgYWN0aW9ucyB5b3UgZGVzY3JpYmUuICBCZWxvdyBhcmUg cmVhc29ucyBmb3IKdGhpbmdzIEkgZmVlbCBtb3JlIHN0cm9uZ2x5IGFib3V0LgoKPiBJU1NVRSAx OiBJbmRldGVybWluYWN5IG9mIEluZGV0ZXJtaW5hdGUKCkkgZmVlbCB0aGUgZmlyc3QgKDQwMzMp IGlzIGEgYmV0dGVyIGRlc2NyaXB0aW9uLiAgSSBwZXJzb25hbGx5IHVzZSBhCmRlZmluaXRpb24g Zm9yIHRoaXMgYXM6IHRoaXMgcG9ydGlvbiBvZiB0aGUgdHJlZSBkb2VzIG5vdCBoYXZlIGEgdHJ1 c3QKYW5jaG9yIGFib3ZlIGl0IChoaWdoZXIgdXAgdGhlIGhpZXJhcmNoeSksIGFuZCB0aGVyZWZv cmUgaXMgbm90IHNlY3VyZSwKaW5zZWN1cmUsIG9yIGJvZ3VzLiAgTm90ZSB0aGF0IHdpdGggdGhl IHJvb3QgdHJ1c3QgYW5jaG9yIHRoZQppbmRldGVybWluYXRlIHN0YXRlIG5vIGxvbmdlciBvY2N1 cnMsIHNpbmNlIHdlIGtub3cgZXZlcnl0aGluZyBpcwpjb3ZlcmVkIGJ5IHRoYXQgdHJ1c3QgYW5j aG9yLgoKPiBJU1NVRSAyOiBJZ25vcmluZyBDTkFNRSBzaWduYXR1cmVzCgpUaGUgY2hhbmdlIHJl cXVlc3RlZCBzZWVtcyBpbXBvc3NpYmxlIChub3QgY29tcGF0aWJsZSB3aXRoIGRlcGxveWVkCmNv ZGUsIGFuZCBub3QgZnV0dXJlIGNvbXBhdGlibGUgd2l0aCBpbnRlbmRlZCBmZWF0dXJlIHRvbykg dG8gbWUsIHRodXMgSQpzdXBwb3J0IG5vIGNoYW5nZS4KCkJlc3QgcmVnYXJkcywKICAgV291dGVy CgpPbiAwMi8wNy8yMDEyIDA0OjE4IFBNLCBBbmRyZXcgU3VsbGl2YW4gd3JvdGU6Cj4gRGVhciBj b2xsZWFndWVzLAo+IAo+IFdlJ3JlIHN0aWxsIGluIHRoZSBXR0xDIG9uIGRuc3NlYy1iaXMtdXBk YXRlcywgYnV0IHdlIGhhdmUgc29tZQo+IHBlbmRpbmcgaXNzdWVzIHRvIHNvcnQgb3V0Lgo+IAo+ IEF0IHRoZSBtb21lbnQsIHdlIGhhdmUgc2V2ZXJhbCBpc3N1ZXMgdGhhdCBoYXZlIGJlZW4gcmFp c2VkIGluIHRoZQo+IFdHTEMsIGJ1dCBub3QgbXVjaCBpbiB0aGUgd2F5IG9mIHByb3Bvc2VkIHJl c29sdXRpb24uICBTYW0gV2VpbGVyIHNheXMKPiBoZSBpcyB0cmFja2luZyB0aGVtOyBhbmQgbWFu eSBvZiB0aGUgaXNzdWVzIGhhdmUgYmVlbiBmYWlybHkgbWlub3IsCj4gYnV0IEkgd2FudCB0byBt YWtlIHN1cmUgdGhhdCB3ZSBkb24ndCBnbyBiYWNrIGludG8gYSBsb25nIHBlcmlvZCBvZgo+IGJl bmlnbiBuZWdsZWN0IG9mIHRoaXMgZG9jdW1lbnQsIHNvIEknZCBsaWtlIHRvIGhlYXIgc29tZSBy ZXNwb25zZXMuCj4gCj4gVGhlIGZvbGxvd2luZyBhcmUgc3Vic3RhbnRpdmUgaXNzdWVzIHRoYXQg cmVxdWlyZSBtb3JlIHRoYW4gbWlub3IKPiBjaGFuZ2VzIHRvIHRoZSBkb2N1bWVudCwgYW5kIGZv ciB3aGljaCB3ZSBuZWVkIHNvbWUgYW5zd2Vycy4gIEknbQo+IHJhaXNpbmcgdGhlbSBub3cgaW4g dGhlIGhvcGVzIHRoYXQgd2UgY2FuIGdldCB0aGVtIGNsb3NlZCBiZWZvcmUgV0dMQwo+IGVuZHMu Cj4gCj4gQSByZW1pbmRlciB0aGF0IFdHTEMgZW5kcyBhdCB0aGUgc2FtZSB0aW1lICh0aGlzKSBG cmlkYXkgZW5kcy4KPiAKPiBJU1NVRSAxOiBJbmRldGVybWluYWN5IG9mIEluZGV0ZXJtaW5hdGUK PiAKPiBJbiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG5zZXh0L2N1cnJl bnQvbXNnMTIxNzYuaHRtbCwKPiBNb2hhbiBQYXJ0aGFzYXJhdGh5IGFyZ3VlcyB0aGF0IFJGQyA0 MDMzIGFuZCBSRkMgNDAzNSBoYXZlCj4gaW5jb25zaXN0ZW50IGRlZmluaXRpb25zIG9mICJJbmRl dGVybWluYXRlIi4gIFJGQyA0MDMzIHNheXMgdGhpcyBpcwo+IHdoYXQgSW5kZXRlcm1pbmF0ZSBt ZWFucywgaW4gc2VjdGlvbiA1Ogo+IAo+ICAgIEluZGV0ZXJtaW5hdGU6IFRoZXJlIGlzIG5vIHRy dXN0IGFuY2hvciB0aGF0IHdvdWxkIGluZGljYXRlIHRoYXQgYQo+ICAgICAgIHNwZWNpZmljIHBv cnRpb24gb2YgdGhlIHRyZWUgaXMgc2VjdXJlLiAgVGhpcyBpcyB0aGUgZGVmYXVsdAo+ICAgICAg IG9wZXJhdGlvbiBtb2RlLgo+IAo+IFJGQyA0MDM1IGhhcyB0aGlzIGRlZmluaXRpb24gaW4gc2Vj dGlvbiA0LjM6IAo+IAo+ICAgIEluZGV0ZXJtaW5hdGU6IEFuIFJSc2V0IGZvciB3aGljaCB0aGUg cmVzb2x2ZXIgaXMgbm90IGFibGUgdG8KPiAgICAgICBkZXRlcm1pbmUgd2hldGhlciB0aGUgUlJz ZXQgc2hvdWxkIGJlIHNpZ25lZCwgYXMgdGhlIHJlc29sdmVyIGlzCj4gICAgICAgbm90IGFibGUg dG8gb2J0YWluIHRoZSBuZWNlc3NhcnkgRE5TU0VDIFJScy4gIFRoaXMgY2FuIG9jY3VyIHdoZW4K PiAgICAgICB0aGUgc2VjdXJpdHktYXdhcmUgcmVzb2x2ZXIgaXMgbm90IGFibGUgdG8gY29udGFj dCBzZWN1cml0eS1hd2FyZQo+ICAgICAgIG5hbWUgc2VydmVycyBmb3IgdGhlIHJlbGV2YW50IHpv bmVzLgo+IAo+IFRoZXNlIHR3byBkbyBzZWVtIHRvIGJlIGluY29uc2lzdGVudC4gIEluIHBhcnRp Y3VsYXIsIHRoZSBsYXR0ZXIKPiBhcHBhcmVudGx5IGNhbiBoYXBwZW4gd2hlbiBhIHNlY3VyaXR5 LWF3YXJlIHJlc29sdmVyIHdpdGggYW4KPiBhcHByb3ByaWF0ZSB0cnVzdCBhbmNob3IgY2FuJ3Qg ZmluZCBhbiB1cHN0cmVhbSB0aGF0IGNhbiBoYW5kbGUgdGhlIERPCj4gYml0LiAgRG9lcyBhbnlv bmUgaGF2ZSBhbiBvcGluaW9uIG9uIHdoYXQgdG8gZG8gYWJvdXQgdGhpcz8gIFdlIHdpbGwKPiBu ZWVkIHRvIGNvbWUgdG8gc29tZSB2ZXJ5IHN0cm9uZyBhZ3JlZW1lbnQgcXVpY2tseSwgb3IgaXQg d2lsbCBub3QgYmUKPiBhZGRyZXNzZWQgaW4gdGhpcyBkb2N1bWVudC4KPiAKPiAgICAgREVGQVVM VCBBQ1RJT046IG5vbmUuICBXaXRob3V0IHByb3Bvc2VkIHRleHQgdGhhdCBmaW5kcyBzdHJvbmcK PiAgICAgc3VwcG9ydCwgdGhpcyBpc3N1ZSB3aWxsIGJlIGxlZnQgb3V0IG9mIHRoZSBkb2N1bWVu dC4gIAo+IAo+IElTU1VFIDI6IElnbm9yaW5nIENOQU1FIHNpZ25hdHVyZXMKPiAKPiBKaWFua2Fu ZyBZYW8gaGFzIHN1Z2dlc3RlZCBpbgo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9kbnNleHQvY3VycmVudC9tc2cxMjE2Ni5odG1sIHRoYXQKPiBsYW5ndWFnZSBiZSBhZGRl ZCB0byBwZXJtaXQgaWdub3JpbmcgdW5zaWduZWQgQ05BTUUgcmVjb3JkcyB1bmRlciBzb21lCj4g Y2lyY3Vtc3RhbmNlcy4gIEkgYW0gYWxyZWFkeSBvbiB0aGUgcmVjb3JkIGFzIHBlcnNvbmFsbHkg b3Bwb3NpbmcgdGhpcwo+IGNoYW5nZSwgYnV0IHN1cmVseSBJJ20gbm90IHRoZSBvbmx5IHZvaWNl IGhlcmUuICBEb2VzIGFueW9uZSBoYXZlIGFuCj4gb3BpbmlvbiBhYm91dCB0aGlzPwo+IAo+ICAg ICBERUZBVUxUIEFDVElPTjogbm9uZS4gIFdpdGhvdXQgcHJvcG9zZWQgdGV4dCB0aGF0IGZpbmRz IHZlcnkKPiAgICAgc3Ryb25nIHN1cHBvcnQsIHRoaXMgcHJvcG9zZWQgY2hhbmdlIHdpbGwgbm90 IGJlIGluY2x1ZGVkLiAgSWYgYQo+ICAgICBjaGFuZ2UgaXMgdG8gYmUgYWRkZWQgYWxvbmcgdGhl c2UgbGluZXMsIGl0IHdpbGwgcmVxdWlyZSBhCj4gICAgIHNlcGFyYXRlIGxhc3QgY2FsbCBvbiBp dHMgb3duLCBiZWNhdXNlIGl0IGlzIGEgbWFqb3IgY2hhbmdlIHRvIHRoZQo+ICAgICBwcm90b2Nv bC4KPiAKPiBJU1NVRSAzOiBBbHRlciBzZWN0aW9uIDUuMTAKPiAKPiBQYXVsIEhvZmZtYW4gcmVx dWVzdHMgYSBjaGFuZ2UgdG8gc2VjdGlvbiA1LjEwIGluCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2Ruc2V4dC9jdXJyZW50L21zZzEyMTczLmh0bWwuCj4gU3BlYWtpbmcg b25seSBwZXJzb25hbGx5LCBJIGNhbm5vdCBzZWUgYW55IG9iamVjdGlvbiB0byB0aGUgcHJvcG9z ZWQKPiBzZW50ZW5jZSwgIklmIGEgc2l0ZSBoYXMgb25seSBhIHNpbmdsZSB0cnVzdCBhbmNob3Is IHRoZSBpbmZvcm1hdGlvbgo+IGluIHRoaXMgZW50aXJlIHNlY3Rpb24gY2FuIHNhZmVseSBiZSBz a2lwcGVkLiIgIEknbSBsZXNzIHN1cmUgYWJvdXQKPiB0aGUgbW90aXZhdGlvbmFsIHNlbnRlbmNl czsgSSdtIG5vdCBldmVuIHN1cmUgdGhleSdyZSB0cnVlLiAgRG9lcwo+IGFueW9uZSBoYXZlIGFu eSB0aG91Z2h0cz8KPiAKPiAgICAgREVGQVVMVCBBQ1RJT046IEluY2x1ZGUgdGhlICJJZiBhIHNp dGUgaGFzIG9ubHkgYSBzaW5nbGUgdHJ1c3QKPiAgICAgYW5jaG9yIOKApiIgc2VudGVuY2UsIGFu ZCBleGNsdWRlIHRoZSBvdGhlciBwcm9wb3NlZCBzZW50ZW5jZXMuCj4gCj4gSVNTVUUgNDogUmVx dWVzdCB0byBjaGFuZ2UgdGhlIGxhbmd1YWdlIGluIDUuNgo+IAo+IFRoaXMgaXMgYWxzbyBhIHJl cXVlc3QgZnJvbSBQYXVsIEhvZmZtYW4sIGluIHRoZSBzYW1lIHJldmlldy4gIElzCj4gdGhlcmUg YW55IG9iamVjdGlvbiB0byBoaXMgZmlyc3QgZm9ybXVsYXRpb24/ICBJIGJlbGlldmUgaGlzIHNl Y29uZAo+IGZvcm11bGF0aW9uIHdvdWxkIGFjdHVhbGx5IGJlIGEgc2lnbmlmaWNhbnQgY2hhbmdl IHRvIHRoZSBwcm90b2NvbCwKPiBhbmQgYXMgc2hlcGhlcmQgSSBjYW5ub3QgYWNjZXB0IGl0IHdp dGhvdXQgYSBmYWlybHkgc3Ryb25nIHNpZ25hbCBmcm9tCj4gdGhlIFdHLgo+IAo+ICAgICBERUZB VUxUIEFDVElPTjogVXNlIHRoZSBmaXJzdCBmb3JtdWxhdGlvbiBwcm9wb3NlZCAoIkluIG9yZGVy IHRvCj4gICAgIGludGVyb3BlcmF0ZSB3aXRoIGltcGxlbWVudGF0aW9ucyB0aGF0IGlnbm9yZSB0 aGlzIHJ1bGUgb24KPiAgICAgc2VuZGluZywgcmVzb2x2ZXJzIG5lZWQgdG8gYWxsb3cgZWl0aGVy IHRoZSBETyBiaXQgdG8gYmUgc2V0IG9yCj4gICAgIHVuc2V0IHdoZW4gcmVjZWl2aW5nIHJlc3Bv bnNlcy4iKQo+IAo+IElTU1VFIDU6IFRoZSBDRCBiaXQgcmVkdXgKPiAKPiBNYXJrIEFuZHJld3Mg YXJndWVzIGluCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Ruc2V4dC9j dXJyZW50L21zZzEyMTMzLmh0bWwgdGhhdAo+IHRoZSBhZHZpY2UgYWx3YXlzIHRvIHNldCB0aGUg Q0QgYml0IGlzIGJhZCBhZHZpY2UuICBEb2VzIGFueW9uZSBlbHNlCj4gd2FudCB0byB0YWtlIHVw IGhpcyBsaW5lIG9mIGFyZ3VtZW50PyAgSWYgbm90LCBJJ2xsIHJ1bGUgdGhhdCBoZSdzIGluCj4g dGhlIHJvdWdoIG9uIHRoaXMuCj4gCj4gV291dGVyIFdpam5nYWFyZHMgc3VnZ2VzdHMgdGhhdCB0 aGUgZGlzY3Vzc2lvbiBhcm91bmQgdGhpcyBpcyB0b28KPiBsb25nLCBhbmQgb25lIG9mIHRoZSBl ZGl0b3JzIGFncmVlcy4gIFRvIGZpbmQgZmF1bHQgd2hlcmUgaXQgYmVsb25ncywKPiB0aGUgbG9u ZyBhcHBlbmRpeCBvbiB0aGlzIGlzIHRoZXJlIGF0IG15IGluc2lzdGVuY2UsIGJlY2F1c2Ugc2V2 ZXJhbAo+IHBlb3BsZSBwcmV2aW91c2x5IGFyZ3VlZCB0aGF0IGl0IHdhcyBuZWNlc3NhcnkgdG8g ZXhwb3NlIHRoZQo+IGNvbnNlcXVlbmNlcyBvZiBkaWZmZXJlbnQgYXBwcm9hY2hlcyB0byBzZXR0 aW5nIHRoZSBDRCBiaXQsIGFuZCB5ZXQgbXkKPiBmaW5kaW5nIHdhcyB0aGF0IHRoZXJlIHdhcyBy b3VnaCBjb25zZW5zdXMgaW4gZmF2b3VyIG9mIHRoZSAiYWx3YXlzCj4gc2V0IiBhcHByb2FjaC4g IEluIHRoZSBhYnNlbmNlIG9mIG92ZXJ3aGVsbWluZyBzdXBwb3J0IGluIGZhdm91ciBvZgo+IHJl bW92aW5nIHRoZSBkaXNjdXNzaW9uLCBJIHRoaW5rIGl0IHNob3VsZCBzdGF5LiAgSWYgeW91IHRo aW5rIGl0Cj4gc2hvdWxkIGJlIGFsdGVyZWQsIHRoZW4geW91IG5lZWQgdG8gb2ZmZXIgcmVwbGFj ZW1lbnQgdGV4dCBhbmQgbm90IGFzawo+IHRoYXQgc29tZW9uZSBjb21lIHVwIHdpdGggaXQuICBL ZWVwIGluIG1pbmQgdGhhdCB0aGUgdGV4dCwgbG9uZyBhcyBpdAo+IGlzLCB3YXMgdGhlIHN1Ympl Y3Qgb2YgcHJvdHJhY3RlZCBkaXNjdXNzaW9uLgo+IAo+ICAgICBERUZBVUxUIEFDVElPTjogbm9u ZS4KPiAKPiBCZXN0IHJlZ2FyZHMsCj4gCj4gQW5kcmV3Cj4gCgotLS0tLUJFR0lOIFBHUCBTSUdO QVRVUkUtLS0tLQpWZXJzaW9uOiBHbnVQRyB2Mi4wLjE1IChHTlUvTGludXgpCkNvbW1lbnQ6IFVz aW5nIEdudVBHIHdpdGggU1VTRSAtIGh0dHA6Ly9lbmlnbWFpbC5tb3pkZXYub3JnLwoKaVFJY0JB RUJBZ0FHQlFKUE1VU2NBQW9KRUo5dkhDMStCRitOOEVvUC8wdG1DSmZFMW11dnFQYVRUMWYzZmEz Mgo3Rm4zLzdwQnFsVjh5UEdCazAwVCtudERDZXAvRUhrL3lVMVlrMW5EUkxJbHR1ZlNQRmM1TERl VSswNHAyTmtxClpPVE8zVzh1VHU4WlFtSE02OE9sODR6RmxvZzBERmU0MlYwWE9Zdjl3VUk2Q05Y Q2lhVHlDOXE0cGpUWnc4ZFIKSG5vUFJQamRJcGhRdXVEV09XQW5PL3cvZ09ES3FrLy9DaUFITUhv c24ySDJ5UUJCdWpsMTRBcmQzaVFLYnowcQp5dG9JUHVhMHo0RVlyTDlnQWwwQmtPY3RWemh0bUU0 bUdFYW42QU9jdkd3eHhsRFZJUkR2Z0xHdk43YnZGeGU3CjNmYVVWYUxINndHaFltQ0hvUFlkMUt4 bS96TFVNaFhLa1l0THVKL0lDWkd5aDNocVg2aEkxN2ZCdEtZY2NLR2YKWlBZSy9DUTBZTFdoS1ZG bC9xVHVLWE16Y1UyQTNPbWNCY3NMV05uY0lsUzJ6TWpqdTlOc3ZyOHFrV1hRaVA2eApscnU4NzRM NjVEaHlGdWsyL0NKejR2Zk8yc2JabXlKaW5GNVAyVFZ5S3o2bUtISDdjV2o2cis3RTZkbktDcmMy Clc1N0wwY2xEbWw1a29OZnpRbHNXb011QlpHdTVYayt4YmhiMzVDY2FMYWJmeDlIMUVTcVRWRGU5 dy9jT3VmUFYKdzNPSklUUGQxU3llZ2xTYzF6QWhlRjF5ZGFta0dPZjQwajRZT3d6TEovQThZT1RF anhqbUlNRWJYK1ZnNklJVgpHcGk1WHJoNFdldUp4UkJSVnlUemcrNjlkRUhkZ3BxdHErV1lWVEtn eXB6WnZnTzFTV09qKzVtM2JCK3VNMGJIClRvTVRLRlgwSzRUdXF2T0MyVUR5Cj1KdnJaCi0tLS0t RU5EIFBHUCBTSUdOQVRVUkUtLS0tLQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpkbnNleHQgbWFpbGluZyBsaXN0CmRuc2V4dEBpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ruc2V4dAo= From dnsext-bounces@ietf.org Tue Feb 7 08:23:55 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1AD21F86A5; Tue, 7 Feb 2012 08:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328631835; bh=Wzz3IJyJym8cyDm6BuNAdWRqM9kn3mPhjQ04sTVLYkQ=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=cEwDzHEvcBysxsxU6+tk9iPFAvBpWHX8RF9R47vkgJJvKvbxB+Prvdnm8rrB96sfE HtvsJBO8Z00i8Q7St/y6FzOvS525UmXyyd60gvM6nfGCMqgUJ6ifEzlHXOxXa02Vhk 4zayA+w1vMXvgBy4yg1s3T3W0767g4xOekkcSKfE= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 7 08:54:06 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE7E21F884E; Tue, 7 Feb 2012 08:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328633646; bh=EOuQmNHw9PfwWTFfqOF484RzELnlS6oXbhnNUSdN0z8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ls4Ka+x75sDZOOod3aDRCZhUqrSj5dHBUT0L/Nt2XdBGHEFuMixQV88OFWE0PJuWJ aFyybqUADE1dbFZ/7HmtQy2ra8FGJfPlsIuPIMtWX+VVBIyKAdQLyGUGgiIFwn+T6q eJtQeyqNmSEECOn/kR8tLJc0IAedzgQgvfLvksOw= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org -----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----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 7 09:15:00 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FF321F885B; Tue, 7 Feb 2012 09:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328634900; bh=Vn2sTacWSmUY3NaqWGf4SZ/ymGDkqgyTvS1ZkJnwHP4=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=AMSc+sYgf65zd71qnNo9WQtHeC+bIImGCS0X70pD6CpdCyZFEjB2oHOfIRkvw141h JQ6naFm30n4YlvCUJ8cS43xJT+yAD73YBlXYjQhTr4Ufe6NdmtmaZj7yrMnJaCLlze LVsmd0jcY5zskqOB1dqu9khxVIB+VS0SYLULl0WA= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 7 10:09:03 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E66221F86B1; Tue, 7 Feb 2012 10:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328638143; bh=aO1FsIqBfqUdykmR6bW0bC+c2VQWB2Vz1V2+Jk7V4NA=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=EzKnpYnxUAvT0QxrAuNQu/8sCmTzx4ufeELz8MMPhBxhGsclP8U70VAMuW2VMdBaK nJxJowodJ/Mz10ixkLHEkkh5GnY7NZP22B8NBiJx6UsedcuzsIJRrqHHnwYiVv3YVD EVKNA4qDQHIX8G5OFttIMbiABBv/CEmwN+b5tOHs= 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) 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 do resolve this somehow. It affected the development of DANE, and will probably nail others later. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 7 11:51:33 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490E121F873B; Tue, 7 Feb 2012 11:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328644293; bh=aONZGII8fyu9woPvwQTGc32NHDpmRJxeTWGQbp2dWv8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=tw/GhHSfRQWbX3IeKXILqIxgGa0I1U5cWFAbyuR42flc4d0kbQ1SlIYO1zJvDk2wm M9n6sIqt9ZHBYo79YJhxT44LeRIKsaL3LPXtOkuMPVSdZocua0/H8Pae6TvzgFZEJG uNd7HW/hRW8u1nXi2r+8TjMS++cELiML6qAL7SHw= 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 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 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. =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 global > 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 7 14:22:17 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611EE21F86C1; Tue, 7 Feb 2012 14:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328653337; bh=S15RBRcB+2sQwCAIyabuYZUaOLfqnefAGRtc7tVBDoQ=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=mXkqS1SUCP/qXqXO6aaTRSC5YrwzzOLuldKZttE6HRLi0OSIJmjnlUgTTWHyvhrj+ /mSgnqSjLzFBZadENcPaBT2RTWfZYiCkf6dAe60F2hdKW/4rmB7u8IJYVOLejO+ubm O0oQhhtXkGFH8CiRQrvxu6Cg/ub5iQDreIG1yLQc= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 7 15:31:26 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC9821F87B7; Tue, 7 Feb 2012 15:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328657486; bh=Yyt40SNQiqcxN0zfC1A8OMsDO5v46W6JemDLPYSa+I4=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=XCqQ7BryzL1snaBIhiNqWGESZhc4c59OvlEbAr96imhGlewrkNeLh4TB5ZouxUOyM 5FLnGAvlUITE5umoiMY1g9up98xTzIC4j3GOEypdUHvWLDtoogZ0kUAOzfg9TCpoqj BvKUGc4SFsZhPYj2yUSIuWsX4brZbjjeCGbhGgBM= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 7 16:55:51 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1D411E8098; Tue, 7 Feb 2012 16:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328662551; bh=HoJwu9NA05u95njC+A/wRpkw2lC9WaWI/mC1Kp27nz0=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=cksA/tbMwxAtukeBIYL9p+UoMYnTR950nhNdxmT6nDA936tZuUuBjmCgJ0gcHq21w VzYzaPHZt/9+BTM3BhZXlsdPQprEZFFy4En2tAiGrNLHpqlogqbpavEqgneHhJHR9r 0OVYcm4ooGGTIHl09eqqbPkpwdMSAapwfLrGfU0I= 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) From: Paul Hoffman In-Reply-To: <20120207233108.1A38B1CF75E6@drugs.dv.isc.org> Date: Tue, 7 Feb 2012 16:55:44 -0800 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 7 17:54:31 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD91B11E8073; Tue, 7 Feb 2012 17:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328666071; bh=+gxl6r3+tOPRbDJa+Hvd/WiPd0k1l6DjloBfBJiKKZU=; h=To:From:Date:Message-Id:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:MIME-Version: Content-Type:Content-Transfer-Encoding:Sender; b=iiBp18YrzHCzML+sA4h1MmlzeLwN01M2xz71jfuftSm0vm2kGMXhJD/uEnna+1tIh XN5ohWvlBfvS/eZUa+8fszHr0wx005G0BDNH0Sv2rktJXDUunBBXC0a1mJ3UJAeMvk 9JZ4SvIXIJYKn/ZX9ZmJNK+oO/OwBW8EHckApsHc= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 00:31:05 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3725A21F8718; Wed, 8 Feb 2012 00:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328689865; bh=1q6U1C+io0aCTi3NkbH1Htg6DNnvriDyJW8ljoMKrCo=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=DBXZNvbel9Hb1kO/HrrMbW1QG86zoFX3gtVaCQjdnWXTbwjBMrGZlPKVSKTj/OXOb Rk3SVV6530WjMLia9EBby4aD80NugSYXqi7hwoeGsrehjpwmhyxiol3j5gv6A7wd3V oxKuIGKRPxNI6NPXNEx08CZetCzxvfFfSrSQaOx8= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org -----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----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 02:08:50 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD2D21F84DA; Wed, 8 Feb 2012 02:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328695729; bh=LKiLaGlbgy/VsFZHtIyuyDl3fDZRUeUkXAvtS+4GkO4=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=FRETu8QW5WpFlgRPz3c5BGMzcOKhxt/uFEd/3GKF8MxHFkONY8aRzhq5tL1Nj0Zar KGV9nqpREHyqN7Co4gVqNWHgBbXgQ1I6x8X+Zxpw5mmOs/ZRlU8VHWeTJjLYDCmwZP X2Ir5uJm9Rplp6VrJpmnDo6L0ZuCLdSzdEQB+wwk= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 02:40:04 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE4221F85D7; Wed, 8 Feb 2012 02:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328697603; bh=TCHS8bNGHQrp6tHTzotgV28x4EHh4L1WYNQEY0t+hFo=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=AOPioroUVbmCHv07wzl7y4Y/nTGiUBcUHnqs0BJqah+lXm6bJJm7BLSgs2jlt18/T 5jD47WbOyEQc45MKkNaEDQIuAixx0ro90OcXTpNMfVatwirp4BztJp4Qiy/2Zipaxu b2jXtRK54pLv84Smujjb2M7dvYono8LlnGUCsw+g= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org -----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----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 04:32:20 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687B621F864E; Wed, 8 Feb 2012 04:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328704340; bh=6vq9m/npI/b2IxCcY7MdPPVw0THznV6l5Zw5QUq5Yxg=; h=Date:From:To:Message-ID:References:Mime-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=fE7LAlMmZHC3IZ8MayQavxvY4zSEDRygwA0j36KTs51i1rzRo8mfjxA+rc+iKSLAQ RjnispLXt0XFSa8NPX3XWDH2ZCaNfi8yXC1e5v7Sovhp89LGwphn3OQPHYvtX65YDC iAJg0AE5qVBqpAFRvVZdVnc8E8MSFtbMHhpxrWJo= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 06:48:01 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C69221F85EE; Wed, 8 Feb 2012 06:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328712481; bh=XgvSscUgJisTgwetuFjJxMRjJwoG68a2j6M3CpPHC2Q=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:Reply-To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Content-Type:Content-Transfer-Encoding: Sender; b=rSPsbBbywOFBnnm8UWH5ggMGMlYFau/wyZwbIBCJsUDsKmf6RlxZMwI/B1n/HZX6G n96HDHssuDp26oMXe9wNysKQntVHhYp88wRsGDAS1SQbLGpW/ed/WF34T6nzOqHlBv Cm+yUa3PEPOe4tNS+ukeoIYwk/qq2+Fc8eXrefl0= 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.> 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 10:45:49 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0FF21F85F7; Wed, 8 Feb 2012 10:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328726749; bh=yu1rKdoCEJNgpOu9NwoMj1DMa2vhThkWIFzFmUaGO3c=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=iGVdp74l/z0S8pKua8CAPXC+kLtZMYBiozIWR1EZRe30jnOED9ZxuSmPX4KndLczJ M6S7rFpP4ZmP1nFQA2Wrq61+jlBgGxt2XpCbA7dOcTTb3kre/IwN49vSZtf/nAyjIQ BmKvx9lqtuccIYW6YTZymGJd5fWZ9zb2AJuM+4m8= 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" 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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. >> >> 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 From dnsext-bounces@ietf.org Wed Feb 8 10:56:23 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F81921F8635; Wed, 8 Feb 2012 10:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328727383; bh=9T7G/CtTi7P78v5f+CcVR35IJaL0lLhW0xPYft7btnQ=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=A5G2PAWRPIMU6zpEla9Onm40PkewyltQSA3gS7oFZNt/+1pNMoL426r+yNl5KC0zK 23jwGxcZfU7/KgEF7BmwaFevxXP7H1f+EO7ZtD+HPN4zOJVRYhoOSz7feieW3svoEd YSVZHbzF9dTWSaO32yVBCPpsRKXdwBipj64it9R8= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 11:49:01 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4153D11E808E; Wed, 8 Feb 2012 11:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328730541; bh=/2R/D8bp39uWgbjgAwOn5XlJ6MbImnT7hubKbf9luhk=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Pp510ow3WrU3MDqwb5J5eHpZqHvLfR5x4IKLiIqh54xvkYhnX5fePvtGA3q0J0OON nSkVndVlcoruyolsGd1mjLaTYcQEF4qgvu7cjDID7GhN1iVGirBg9w91zZHVNxJVBU I4ffOO3UdNBfR/t+YVGcHrGSlBimPMjv5LZfp88M= 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) From: Paul Hoffman In-Reply-To: <20120208185617.GH11475@mail.yitter.info> Date: Wed, 8 Feb 2012 11:48:57 -0800 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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*. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 15:05:42 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A2111E8080; Wed, 8 Feb 2012 15:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328742342; bh=L4wLQd/+h9qV4bCP23mhAq/dP4yajQ01uMBOyoCvUn4=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=IhLAXN05eIziW4FMrcORmB4vzVC5fDfywA//nn6RqqG2LKB8XitvI1nrU3rF721rC lSta4cfz/+IaM/itlmSolA3rmLKbaLmI1Fi1ZLHdmBtjC1CNOfd4H3OhlBiLiWIS4y hyj03g6a11J4hO+3+C6VFjOWj6mKd5bUb/CC9HPg= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 15:27:49 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF97A11E809B; Wed, 8 Feb 2012 15:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328743669; bh=E7Bx1cURqxftQ+4Y191WBi1Wi3FEoyTwf+G1mzXEdaM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=FlAOB9slGwMkE3gCHe2dGQ86H1WxduIwb7cIJRv9Whwg3DIZxOtwnCr/bYfj/4HRv Ft7Xu1l2Kd2rfZrRJ6lFvnLJJFI0Ci7n5xuXlYkJ4T4//OVFT/7DTXG7CR3oYEtAk1 fbytiG05wEDaKJ15NbLszlPjvZzi6ridzBLE/sYI= 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 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 the >> >> error status for the different cases. >> > >> > Why data cannot be fetched is not a factor in the end result. =3DA0This >> > 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 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 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 but >> > 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 conclude >> > 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 17:16:01 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7581B21F85EA; Wed, 8 Feb 2012 17:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328750161; bh=7ocxjCcF9Cj5OHMMpVq2oTEjM6j0ffQ17I5sOQ+7MrM=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=UnD8rWsIQOvyEejf/VsgyV43hDoycO0VtheLEVPY2rI4GrzQSbvaQ5jx2uH9Ab+L7 isPZSn72Ok83p5vWTRkSPF5xVzi+2T48xBi6XgQN0zASY+5Qv1Y6T8jGZx2kKnyg0u 25P/HeHCLBNEzbzbxVJyDSKzD0/ywLLyuW6trR6I= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 18:22:53 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A0D21F8609; Wed, 8 Feb 2012 18:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328754173; bh=OC37LLaljl6+hAthT8AXKhmn+NyLAzQOOARBKSiIuX8=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=ej30MYMKflfeS2iSgdZYa1mAD1+YjJ+XEFJ0y3WyINmzNpTn0paq4qJdP5ZAFkZM+ 1iSWNv0YklpgiMeLaESkuCSbDyQs2bMo0SHD3pE6Qz0b+DVpVCl3PEZwNjMO4w3eDG YLO6qLg8MJXuVdnSdPIlXqTZ0MhxeeNJynZWDIlw= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 8 18:41:12 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F170321F856D; Wed, 8 Feb 2012 18:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328755272; bh=/1uah4XUpUTMDn8Rrir1++wmzCfabdDUOqT2jFOudoI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=OCgmrNFLvxTJ1QzeP35jrd2WMWZbZZ+7ZWF3C/OzxPy50zuRLrXQLt4AjIoJXlNpn uU48BBjGH9lL+/JiegxQhfoXpGqWE7dVkjzJuUZzJ8SsvMRt5HDj4FvAubrGKDP4uJ sHVJuMHSJDw4pCrENpVQTQXqJ6d1UHBgLTaBQFRM= 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 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 9 01:25:54 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840F921F86C2; Thu, 9 Feb 2012 01:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328779554; bh=COBGRFRWiKHlAB/xooJ6+2sXm8ki5oJsn/2gOOHSqD0=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=m1rONHKO2U2iEbO97Ws8TT6jzMSJZ4wuozf32zDp5if9+dd2fOGhHeAtMqQXE/2yi Bc/ZCYx+l8ImjjCuranv0+uVUwTPjRcnut2IRRynnOav7b9iTRrN+GSlpk0OBOehqc t247WVh8Axf9RVNxEYCs10marSatDivCP/TYG0JI= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org -----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----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 9 07:12:34 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F5621F864E; Thu, 9 Feb 2012 07:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328800353; bh=il5Tx0spKxWcCUUm5BxQSCQrQLxWOqk20BomIFwIEbk=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=VMH2daZbixY85hGzf8kuQ9C3pIt1RfVH++o+4R/RbuM6dxO8o4JtAYyk9UxN1V8cF x6wWhcfi5yNJnweftNJVpndNRuxEjjh/rL7a0XTY+owe759jdcXlHxcln/z4uArm8o gha9Lgzw7fJh+8blWvmk0DlAxgfg1MSsKbroLD2E= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 9 09:23:25 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACA221F861F; Thu, 9 Feb 2012 09:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328808204; bh=Zyt2zsS5RdJrCdfzAgfsJda74eYNGzMmyCvUlkzSHOg=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=H46jGpuvXP2KlXIRHnPq82qxezZvXm14g196JU3SQQIwZRVhx8d1jJzf8jYbxAzYN 5nO9yUVdGz1AQgi5CxuH9fLofzd+ibeXIz8OoOYXtD8UzbiUqSzTFu4uuDfxjrU2kn c75xbJ33UKtBtlWapkgIKihuE1bh9Rv0xlZXdfbU= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 9 10:02:05 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5081A21F85C3; Thu, 9 Feb 2012 10:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328810525; bh=YmX7pxVLwpKX0W0x/yYXpoRgsF/7HUZREqdt9WIRHjU=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=SY4NSI7aYMYyvEIhPyU+e+4MQguFrNOUfJMQsUlB3b6YRkfWx8dcj6TfEedG+lyAS pOsDe6zcC3aQ8Fqil2V1TPXX9bBjAOHLkGSRAQJjdFXtY0+UE6emnrIGeAscd7Woh+ J/VZrZQb4Wjv+ouWklrfHnhjT2B0Kr5yXGd7+xFc= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 9 10:54:19 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA79021F8664; Thu, 9 Feb 2012 10:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328813658; bh=mBKkVG6CfJ6y0Unrg+bWagMK9xKBkx6JVGWHUg/Wa5k=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=snZF6gIUAxwJPdBAOcvO0OiGoIzZXH0nk6aERtBKicm1OVbG1xYrsZQClCJ3JFMxw qSq7gxn52DgwQfm5xe69HwSSgHO5l9UnnAfgQOrOaMiP7oXoqTU3qJtAw0xpB+vXoB R/jYjXVyIb5sHYyMQ3afH6XvQd4IbfY7id3FzgZ0= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 9 12:31:09 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B4D21F860D; Thu, 9 Feb 2012 12:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328819469; bh=0DggT1r1WRV+dIhpspOgqr7YgxVnXBYOwGDXSifFcHM=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lfPWtWgQkhgxluGgW+aRkx/M6EkcSuOZKpT12RkQZIX3NaMEvQuQIJGelRRJHkiqY NAsdINrwx/0PjFbvJ/0Xr1JRFK9C9WBuLWkftUk+pUq+4PyQpXnlydZ6Eg0txtj4II EMd5HDgg0ntSp+Osj6/LGCGpjPt6Xx+i37yXB5Qk= 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) From: Joe Abley In-Reply-To: <20496A7D-C79D-4A82-BCA7-0E0F721AB4D8@nominet.org.uk> Date: Thu, 9 Feb 2012 15:31:00 -0500 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 9 12:53:59 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C15021E8020; Thu, 9 Feb 2012 12:53:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328820839; bh=WVowHzzCnDPUMSv4YXQn4rQnLqgC654lyM51y4WTNGQ=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=LPJ8OMkOtHS3NEnRhjGQa0Sj1S+PNcsjMAlml7n2i5+6aYMeGiioRG17LMU6MzoeP oE7qfXbathjQE6Qnk6d6JyaV27/xKV34ayc27Q6XSdXprLiYSddKI9iiGnbKY6TiLL Jqy+yq1DURH4JmyK069736ImhSGBQV0M2H7iijOk= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 9 14:38:13 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B97821E8050; Thu, 9 Feb 2012 14:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328827093; bh=QgXmxYy9ypYqdZmGbFN7elJjc0doBf4dh+VqLuzz1Dw=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=GbrfTI84garCVNkJR7gzME7yjU2QqM91Zfhp5OcbPBgvkEqcpP+ea4ujuaGV5XB0t HyGRcMpS2IrlJG2mbDJzrMsw+nMioqjAktdYuhC+aOMD+c+gtMJvco7XLcShyb7DAO dH+vh1Wb4byrq/nd4JcRtGohBv3yEZSE+ZGAe55I= 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> 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 > > > _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 9 19:20:38 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC6611E809D; Thu, 9 Feb 2012 19:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328844036; bh=BPXyq65tS/Si//7afRuO+yzeEsjnfgyZTgF4wUtPvB8=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=kwOY1nUuUXw1fi89L5Cuma6JK+kwy+NDjCpvgBALQZwhImviAZm7VgJ2LpDseMs86 ITA+NDkJFFWd1V4UpsrWiWGZ436/7KSiEsz7VT5OsOjVx6qx09r7KRPPv7fa6K65dc NCDOqE3BoEEeJpC8616OsvHnEIfscWC/8a01DZmA= 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) From: Warren Kumari In-Reply-To: <4F33E1A6.4030902@isc.org> Date: Thu, 9 Feb 2012 19:20:28 -0800 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: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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: > = > 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. I am no longer sure who the five were, but I was not one of them, you now h= ave 6. I would be more than happy to contribute / edit / review / whatever is need= ed to progress it. I think this is a very useful draft=85 W > = > paul > = > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > = -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 10 00:51:22 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C3621F875A; Fri, 10 Feb 2012 00:51:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328863882; bh=bdqJ3LEGFXe8f0me2tMc/hNn65IWyxcQtpZwkJb/chU=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ldp1kojyRhHQkikmvE3a+5cj+TmMhYDCncJHeBRx2UwwdiEFx5ApRU7i+lVS3hfOI n+G9rM6+chZ82FHF+3iaUNUmvOzNHnPgeEeJC5Uon4vi38D1O2/iptnSOTWavN4hgr r5kEpbMQ7hWTHhMwz1CLZXX1kX4aXlb+gLXBVeiQ= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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.) _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 10 01:01:29 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC2921F8790; Fri, 10 Feb 2012 01:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328864489; bh=IOmmojKysQL64ZQgVp6DnDUScF1oi+vedtKqyCI5d4w=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=eIVGnLpnCb+JLbTIpFfGEvlNItFNR6FOU/P4i2Y4kMAr4c2pcxO0W4/EiDP8vau+d s6kCPGISZhToYHXJRmSLOm4lNSUJBEg8OuA8cwM+oTni8RhZJqxggJtEqDcTqt+EHL g9gwgne1litkpMBeuHXhyHdHfJDx7Z1iUjGU1Eeo= 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> 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 10 01:17:57 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F71121F8663; Fri, 10 Feb 2012 01:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328865477; bh=AIuQfh4Zkh8e1qZVkn9xkgFHTzkMbP7QIQXFE9QukSw=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Ftrcr1CsGjOUQctEa2mL8nMk9AJVWjJZjZRV5toyjg/NxSi6xmtKsOmaea1P6Ncaw 6Mzq+f+dMUrFBy/ym3258RuSBvCVJnr/Ah0ZVkV5ncVUHxQspK3e68a5Ed+lUIovsb DoqGinfp0W6o0dlzTIViW4VWThPnZJpcH3F/Mj/4= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org -----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----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 10 06:50:21 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD8321F86B6; Fri, 10 Feb 2012 06:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328885419; bh=KAgRYdjfMkPSewPrw3mYQ/nL4bBQdvaTkHaAglEM9O4=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ehp9EarsVfOO57Ox1UqO+lc6adFdVYBNE+GZGpRWfuAFf/qrEOdcARkxcO4hl8tqE y3xQrHb1GOyBGKEMLnf8vMuE8THOkXw8zqPN76R16j1uSLJ5Xdv+YTAXmZEGEMunGD RqZl48lgIKSRrmcTBQbjtyVQWYpk/UoukQHd3v9c= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org * 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. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 10 07:23:55 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD5A21F855B; Fri, 10 Feb 2012 07:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328887434; bh=HM7CvQW/u7Vc26hXyd0BWZrAB3Mt4S3O0Bqba4ne+4E=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=MJ4uCOXzkft6lXw/x9RXBIO/m6LoH/KjOdlnVciW3xwDEb4t8tBmQjxfMDKbLi+3e O7Lj/DnvXpk9UTL8cNZRdrKwDSI+r1+Z3lfpLnIQIQm/sFJSKAKLsLZEEog661BlXz hBxOARGtrU9lKHIVB0VPTv9IQRoPzxp5qfhkm+rE= 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> 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 10 07:58:11 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA3921F869D; Fri, 10 Feb 2012 07:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328889490; bh=RQe/XvwBJEWgINKiEWSJ1dT463e8kE1l5ayZaGiPnt0=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=TgPBQNYwyDaQKn43T4vSI1N5nW9c2elMwS9P32lDoAEMM3kIXLv9pXCmdGuQd+bWW 4+1/9TyLqLOJ1T/9V/6/sHSJz5GthiTdxD6hClmg8dPHFMeNA83Q0yvbNmaf5+kS5+ Ufh3jZWnUDY8OZNbA3kqK3KPZqVuHIS01LW4s2xw= 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) From: Nicholas Weaver In-Reply-To: <4F353676.6090702@ogud.com> Date: Fri, 10 Feb 2012 07:58:11 -0800 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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)? 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. 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. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 10 08:25:09 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CEE21F8759; Fri, 10 Feb 2012 08:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328891109; bh=HaK/JnfKXY3M8sKDEzkN49GMe8+MS0pW1UAHBNuWJek=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lti9N9wfBbMk13IiBDgP8T1jdpHNWn3Qdet2/4U+upRc/JBCgsnTynmQkJxIWxbi3 BPNdqwSSReaFn81s/UywbkjyxAobmh1hDe7b7G2Kmni2WLLYr2ifOh/ux3rUWCCOJ/ MwBXVsEb51SnUKVpmY59kQGkdcNUj/FtE8JdcesQ= 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) From: Paul Hoffman In-Reply-To: <4F33E1A6.4030902@isc.org> Date: Fri, 10 Feb 2012 08:25:05 -0800 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 10 11:27:42 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087A921F86DE; Fri, 10 Feb 2012 11:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328902062; bh=YTXJg16fvfdtrd3Ska48lDCi4LHIbux9K2ryc2jIU5Y=; h=Date:From:To:Message-ID:References:Mime-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=QQ6BJJwKj7A1vRkvTQI+HVy68b8IBgNLKGNqV7qPYbU4W6z2lnbaBGrFRIBzg9SaL yHDMEjlQORmsITuldnF2ftY8ZA57XkFwXBNHHeMHstZsD/2M0BysccIjEzyPUJuy2K CGar0DxwDhUkxJNTNUMUVKJ+CZHC9lKGs8M3JrwU= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org > 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. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 10 12:08:06 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E176C21F884A; Fri, 10 Feb 2012 12:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328904486; bh=5yziWg7nm+QaV09CLnWZXjpG83qaWknNjtHARi02iIo=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=qlAtt+SrSpLhE8Niyy0lB+vR7jjqSZRdflo1EIZmI+VH8XiydNan7Y90V+BpP+pz3 ZruxABypGX86026eWPoy6mDlPCUQC79syH6t5wAp/eP3Hl23lkaXbcMOW6S/HTp0Je 9bMho3MKAJk4MSzmZ1YagneRKBiKgrnkjkXcoNgU= 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> 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 10 14:58:51 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C11521F8527; Fri, 10 Feb 2012 14:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328914731; bh=lWImp2FJ4+Tbo1reemf37usA+uJLG79zWI8WsttmhF8=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=B+Amo+ATg9rRKg/ujEuFAofl+gLZtKYP3+7qQ9LrJ8jN47K+apEbU69O+0djdTsdV irI4THkYlZSq0iOlYOk5InrNh7Payz1gnBM0htHoSKUpOLOHw9mD69Ce5UIuCnWJh9 Ql7eqbs1FktwkWztLxMtzNzNArMuI9YzRdaUwoTY= 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] 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: , Content-Type: multipart/mixed; boundary="===============4176301783086953973==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============4176301783086953973== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_776FF2E8-9369-4D78-B884-92B70847C711"; protocol="application/pkcs7-signature"; micalg=sha1 --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-- --===============4176301783086953973== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============4176301783086953973==-- From dnsext-bounces@ietf.org Mon Feb 13 05:05:27 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91B621F854F; Mon, 13 Feb 2012 05:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329138327; bh=rKb3xAbm3uK7o2rPilpTSHmPypp3UoP0c0lmRReuEw8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ScZK+Aa+gzQFEXxYQWCZrYvA20aEqrBBoYiGkgqsfsaNWfA02lWJKwQyen33VvE9a Qc4bC2C610UcKzlIt7dfGWUYNkyPM/daqymdd/QU5zcbsD9lXx7+1EQGH6PqhI1+Yq wvmXPqsNYzTIsCz43Y1X4ZIR2gMWY+2HWu3Q/3Cc= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org -----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----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 13 07:06:07 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCEB21F8552; Mon, 13 Feb 2012 07:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329145567; bh=8A6bqrws2vtFL7QIvL4CdLHaQCHsUWf1bfClYG2a/Lk=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=QdhWXt/ImWse9WHNIR+4LkG3ljDqWOOJ+H/lPN4p1wtu0zumkJHnFeGKVRP3S7Vj3 GRqApPTmW7Li7oLeY0cGErYPsENMYuV0Gd3k3BE4Hn4h3TAMaZPCt2ma0X725KcKsM EoDsXgyscKZI+EHc7rzHKVdDkdJZsLxfdVD810HA= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org * 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 dnsext-bounces@ietf.org Mon Feb 13 08:57:33 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A38121F8489; Mon, 13 Feb 2012 08:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329152253; bh=hnRDmdODvCwPhE8W1esCQEwruFcqNb1zlfLyh5GxdAE=; h=From:Date:References:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=rVm1Dgt0EVxxyRero1gN+i4ulvHd5IgS0tAQVUz/FMc3JWvC6FChuGItvHa4aPWF6 ySP3j0JVNM3JKbWAW5Bpq0NkNrmsjeWcztE3q9Zh4YgelqbyjPdQmxkynUNaUHfYMR J4RKwFYV1WQPes8/gAa0LzSkeJJJISEZcCq7knig= 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 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: , Content-Type: multipart/mixed; boundary="===============3150390802239418188==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============3150390802239418188== Content-Type: multipart/alternative; boundary="Apple-Mail=_B88C01A1-C173-42E3-96F0-F2B0E4D1B8AC" --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-- --===============3150390802239418188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============3150390802239418188==-- From dnsext-bounces@ietf.org Mon Feb 13 09:18:42 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736A221F854F; Mon, 13 Feb 2012 09:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329153522; bh=SgWNKmxP6Rgn8Bxq+BToMhuHJgX1++UiwGpSm1i9g6k=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=CaQizL6sZbpr6Dpdtg5TAt28dkhy56OOsB12dLFo27xY+MdGVa29t02OHQQmTg4gd i6VvNpHvDWZbZnye4TiB5esjw7tMbjvBoYUt8Tq31DBLzAJagIQrZwIJ8Ot8UbBaCD 9PorlXutlFJOX++FA4qUGl7vqV3L6EfGZpUGsyzE= 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> 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 13 10:31:29 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3351C21F879D; Mon, 13 Feb 2012 10:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329157889; bh=GXsLbMq+uqLUd8k0AapfRsF+zM+OFAPghl80ZzlaGi8=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=Hnk2ZGiZJEUX47OWT4XBK6SnB/u3ivP8LM6DU75s3F5NqG61FvYPj3Hz1Rh0QM4nW d0TYXaDmRBWUuEd9n1pwpJpQlJT7x4zPubDTKafZZ+32XQGNohLsVGV5FJxCgmD8Lg seBBy9Hn6tmFHfkFNnPT74/0TAY3UuuETm8ixqSo= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 13 10:58:57 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C5221F866A; Mon, 13 Feb 2012 10:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329159536; bh=MnOfxFKAM8Oca4CSTDP1YzY7XDWh6Vx9ltmfKYMYvQA=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=gnTv/ZheVg9nyY/HH55nLdksuacDCfm/nbyzLAU4ivUL+mk9Kk3Am7d7mfKZB3E8T K71hxxpzvSuNb7AjJqz+RkXloCRMMtSyELAbQZdQnH8huXY0HXCqdxya0IoAaRrk5O DIXYU/KtybCvbwTeta5HveKSiAG40LZ5Ok0GvkkE= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 13 10:59:37 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E0621F8671; Mon, 13 Feb 2012 10:59:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329159577; bh=QRS47QFhi20e9xNTNiPaYkor7OZXpiWZRSc7lopT9Lo=; h=From:To:Date:Message-ID:References:In-Reply-To:Content-ID: MIME-Version:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type: Content-Transfer-Encoding:Sender; b=x87KFuKO45gCkSOd+LYA26ZWCk26ul6qLPaAlDt1/LxFn/bbvKFf+Dx8/ZsZ6ji3K 4uCxCi3FDgGcHKPXeJ5NYlppwmFlGIkZQ2bIdgo9orBCYyxG5omvKOIDStEDdj9/hz PLr80aXKHn1xw05z4kcS/isnPCv0SvCS44V7RCTw= 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-ID: <0CF9BDD90524C446BAE0B8062D4F85C5@verisign.com> 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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"? > 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 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. >>> 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?? >>> 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? > 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. -- David Blacka Principal Verisign Infrastructure Engineering _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 13 11:24:23 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3757121F84F1; Mon, 13 Feb 2012 11:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329161060; bh=XnqG0ihqr1c8p3sNOUWeJA0w5FFzX/0qCIBnJiut7Ak=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=p4AvR8NzOzWcy/RQ2pD67RSCt5CR1Pf6goDZ3ClBYGZiVMrVt9cw9Z1QL0VC6M9wq 9CmZ8xYoH9wEn/fBBZh1HrE3G84aXLm/Q/WbTECUnRESdzus3P8NaLPHYFhuIyT1cD PmTpxdjbt99Qh65jP14hfrK1cws0H3axHLWcAbLU= 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> 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 13 14:04:26 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E15221E8023; Mon, 13 Feb 2012 14:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329170666; bh=drfDvQe3fqAV2eLSyIgOVAxXW7QTYVRu+buLE7Y/HEM=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=yYWRaWKkWK+jd/y+1LM2keBS57tTfaC8IhEUnCe1QQ5FBNaoadyP+ugYMHB0TgTgZ tAYbrc2du7G5R20PbCh01/Va9sk1q6p8P4qaOH++WBm0IHTqUXxHXcJpCgquJxp/A2 +Pl0Buz5Q+Chd7HtqKrvWwGxWq/3hanajKY3SFXs= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org * 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.) _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 13 15:16:13 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941C521E8034; Mon, 13 Feb 2012 15:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329174973; bh=Hjd+KL77aPZH7o3rEz4aI9tNKR+3J0FWPMV0vmwKBI8=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=M5KfCHuDQucxXzBVS7QfeZWa6jUCpcmMIxyAUczoa+kEh4DxFqxEkbUYNQJdMFQKk yyG9+Mj08UGOOKo7T+Hk0P3oJBIWnxwkVRY2G2W/G6wRhL38qHAe4d9uWCKYHlXcpr VgeTCJx1gT7aFAk8TU8Ok4Sj/g2pYfoIk1EVk40Q= 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) From: Joao Damas In-Reply-To: Date: Mon, 13 Feb 2012 15:16:00 -0800 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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: > >> 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! > _______________________________________________ > 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 From dnsext-bounces@ietf.org Mon Feb 13 17:42:10 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD37A21E8044; Mon, 13 Feb 2012 17:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329183729; bh=pHTp/n0Oa5uik0O4lwaj7ezYioInvZNNCVwfpL7kvzE=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=osFTvy2y4lEraXsk9fiKZRPpzgIXRNKxVstwCb3K66bCYn+2KCfQ10SxDIs3A5XFy z6AMLf37Ha+bDpsKApDdVuzggA9SCF2a+wz9yyDqX/P+GsHaL45zKY/0PAEuNijbKi pE15p3NLkiMUcfJhtO6Gp1fqRjMnBcIWu7cc92GE= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 : 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 13 17:48:18 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A012F21F8584; Mon, 13 Feb 2012 17:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329184098; bh=2rKZiMWS0cQhGtgPHpxJ34v5UyMNxa4cuy2iWAU/3KA=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=QfdEXGDnVylfxaA41S9kGTn0Q30gbRt2R5eOS4MknAfXfXYXj4X2IQag8lq6Lz8re U7Q20FhkH/TvV37DWNiPgePD86aIy3o6v37R0h2gV3a1j5erXTEvQmkA8JOXDbTMM/ W4Rv14qYMRqA1I5jxmzzco46wM+6yP+7jmACkCo0= 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) 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org FWIW, this version was to assuage some ADs' concerns and make the (needed) correction to the front page. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 13 19:33:40 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B51C21E804F; Mon, 13 Feb 2012 19:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329190420; bh=8p5X0zz2UzlliiWmtaIPOG6Yv3I7660lYnyNN2vL+JI=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=hN8Aix50Vkwa8wcBX8BCYECBd1uY7iviICeau5QZX6fuxHsKGsPufvEwNAcnZPupd 9kMNNtCIv1gLkNQUHldLFYn5gGR5/JSK8xX/jnftOwPDQvIGGGLwfYurkaw5vKUTS0 ZR8AxUlFtpQUtyKtTLHRK7jsJIA2WXnarPwhDFRI= 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) From: Joao Damas In-Reply-To: <871upyept1.fsf@mid.deneb.enyo.de> Date: Mon, 13 Feb 2012 19:33:21 -0800 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 14 00:35:29 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A0F21F86A6; Tue, 14 Feb 2012 00:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329208529; bh=7rnmDfZGjir4zyVIvt8fGYlX00U82YPI0DfzjMcF8FU=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=AIkN13Jrj18UCaUIaTlVYMbzk9woV10wMxciVEuoU6jUxYQekfRblev9upJyX1thP z/pEnrOeH8KsoT9YS2vREy+i9nuU3Z4pICPBFmYlp6sokW1ybebXnk9adoJT+fyEEk JeoSZZaFYdoCKyNHzGC5HB8JweicJ+c5HsPi+rUA= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org * 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. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 14 07:30:20 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A66D21F87B1; Tue, 14 Feb 2012 07:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329233420; bh=f/UgkvkIS64JKQpAVeeTh5DZ+K5hYxTs8/EDwZgjm4g=; h=From:Date:References:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=dMeUvWWCfSEa1oma/WkfytTx/Re37scbbCr2BX52t4MGqjVqvsa+PBhFcIe08IgvM GiCP+4SOKIybjyf4/Wn+PhuhjKoI+5C806NYMp2iil1qUwulFv5da7USgaKnw4opeH pgIo9OCrc0yDVlhRuk6Utl5P6DRjhwzJWojdVPYk= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 > > This is a GEOPRIV Working Group Last Call for comments on > draft-ietf-geopriv-res-gw-lis-discovery-02 > > 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 > _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 14 09:12:33 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3AB21F85CE; Tue, 14 Feb 2012 09:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329239553; bh=lhYBKK3QOdLthCKD16I9RBZwCR63y7moHMCJAFJwv4o=; h=Mime-Version:From:Date:Message-Id:References:To:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=iYu2rR8LQuEvOdJRkNHEcr2/L3hVyPrxJU3T5dGwq71ukSsaB7PpKs4jsEVBtHbhI RzUCqHLQLtzQ3L9H8oR/O5k8dwPO6kLwfnguk4BxVKUbTSUyGdXi89oCSyopcuGQfY isRHsG3tyJXWfIVhxo8Reu1WtYK8jMMyD2cuc3nU= 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 Mime-Version: 1.0 (Apple Message framework v1084) From: "Richard L. Barnes" Date: Tue, 14 Feb 2012 12:12:27 -0500 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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). 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 > > This is a GEOPRIV Working Group Last Call for comments on > draft-ietf-geopriv-res-gw-lis-discovery-02 > > 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 15 08:29:57 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788C921E8087; Wed, 15 Feb 2012 08:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329323396; bh=G5Ru2zcDNI3eYl3idSu1znBlHP/YuUD8wgmVuZBRXn4=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=uezKf9x+WSwoRvil8SeNszmEvM1m2rgF0Krct7ZHErvhR3XLpz51agzc8SOaDXwPo TlEVAhbo1rDSyI6CWqjhDS6sGAZV9YyMjgNFi5E2LhRC7Tx7ikh8q0rD93bRp7rLsi YTHLh5phTJcfcOcbuY2GzW9qSRoasCmWkTt43TPU= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 : 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 15 08:34:22 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD9B21F8691; Wed, 15 Feb 2012 08:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329323662; bh=ch0UzyXcAE9kY7C42TXHzrYj2MJ/WlN5JeUiAoW/njI=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=T5jey74WceSe1sqg/senI4rECh6NYppyba1OMbSEbLua2HrFpkRkkERvwS2vqX6eF DJqwLvk5waZ94+S+8JQNQr2lrswZViPk6Cdt7K2IeUYh/qxTkwKrJvdOZx0EsRMjRo 7sr7lOBq44F0q4MtAIyRVMf9u7+XKcWfzWGsp6mo= 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) 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org At Olafur's request, we made explicit that we want IANA to use the values we used in the examples. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 15 12:11:53 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AAF21F862A; Wed, 15 Feb 2012 12:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329336713; bh=C83IbLPN+yO5/klXRf7yXTQmOsrGAsKTxddwKg1fc3U=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lIhJ+NL2V/9bZ24+q+aFov86Kd7Ncl1jXdzQdm96TaYVmDDQkJqhmrX8724V13gPS cewFa5A1GqLmkwEClAjCi+eEnxg/C7QfV0r35+qz00baIOfVxmMmOgK8iFQ//r9XxF 6JtvBEZklbQv/fHUDN/y4po0ICis4fGIBwYK4+WM= 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 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 15 13:55:05 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41CE21E80B8; Wed, 15 Feb 2012 13:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329342905; bh=tzqEsmId++HeC4jWVil1XXkztwlzfCZ/RddM2mbBAaU=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=Yu3OOOpRpULHYgc5CgEFqCjfC2+YRC8MACmhmlLLUPCppuym+zrWwXMFFD27JT7fW r9yZUfnxTASn/gJTw/lNWAMsYtUxwsseGmtIvPNp4ZQsVuz3eOmJYO967QJum6lII8 HfzlFX2zUznThkXuAhQSMbVOt2BPJ1zpR7ZUuwEo= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 15 14:00:17 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4086621F85E1; Wed, 15 Feb 2012 14:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329343217; bh=43W7jNpxcGJfI8ihfXbC3jmczJtQENWmiFfWTcKOn8A=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=aRwhbNWyT4770aITeSw1faCUTCQ0v6ewYU/n9fDJnFI1Nfdu772EPkN7EDUix912A p3AQ4xAsJ7mvYKIiuH9+SG8PDr7Ta0Zs379f3axQuWCo2Yuay60CoE3g6TqsiywpIq sYLDKpexsb+FkF3ox1D1ZPylQLp5+usu4PjTRrr8= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 15 16:28:23 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6EF21E807B; Wed, 15 Feb 2012 16:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329352103; bh=sCjVhuGnz9iccOwCRRsPBf1JojA/K4Lneq/s4qjDgh0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=dxFQmBHGDvCaFjRTiEIKIVq4venVaF7ibWR5RKwIMtrc5Kmd2oLkspCYiWWeYa9yq Q4DK1exvg9T6tCoOBaK3SoDuT++jqw45okFo3aBYNH94yKtQhzFXJjEL3TaC9x1nI7 R/MOyfhvsoJw2EJKwwtKRNn4+GJuuxVdE+h0yJrI= 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 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 From dnsext-bounces@ietf.org Wed Feb 15 17:24:36 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2A621E8033; Wed, 15 Feb 2012 17:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329355476; bh=/eOZCAzNnvk4zej13GeV2+p+eoU5Xr5By7aV5PXgiNo=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=XQ1Ij9pXBNsGTH39gQcA4pmcDeSmgITnm+CkyyMvXOgjzNyxMVu0APD5cBpDwO1OF E8lOgFEWWRxZuUnmFTRDSZaKfNPv8XBNpZgKipgcN7vfNjJsp7H+khim3gNEEwgLGV V9ahFgncsVOhU/D8KhrPLaREJwgdqeBulcXxVU1w= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 16 07:08:10 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADB321F866A; Thu, 16 Feb 2012 07:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329404890; bh=NZ81xoCO2Zj9Y8rHnTQeXwIe3j9qeTcyeB1R4wIxegQ=; h=Message-ID:Date:From:MIME-Version:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=Ei2pEm3IjEfb3hmlpjayOS9b93BiM/x9qIXM+SUbiryWumQijND56RRdhOjdfCYlf N3H/ipd2Ya0b85YEXtXGF1PfLkYdKe9ExOXJpkpMJx9P4qnbVCFar6jcQfftsBkVQR rw6hlplhX2+7XOcf0O+jpsZRqjnUbgAOtA/zKaWQ= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 16 10:27:35 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9FC21F8656; Thu, 16 Feb 2012 10:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329416854; bh=R/47VP68oPKNdOlwSBhzfqPaM45dpc1OqZFWePwF0ho=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=PyJo6G4FVXhQFhd7poz0n8xGNejGyNND8XOPgKHcpV3K37hK9JRJukv82ltLaGnUB d4O4CooD2AzOP7cDR5XNd/VsDHFgkOv1ZAsTgRErKAW/tnn6zhQzYhkdtPZUOOAXxw 2cKSC8sE0mfdL2q9eNR82rQlNyt1BuktLS7hG0sU= 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) MIME-Version: 1.0 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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/ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 16 10:59:25 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAC921F8566; Thu, 16 Feb 2012 10:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329418765; bh=uQj0/N9gWh2y/3d3017Gz69/bAEjKENtwSGP1OYYBPM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=DyYY6v5Z8TTJI9ohvs1bhR3SeG+OQlBGZrVg9KRR+OkMfPiC+oGCYZutOwdc33UAK nzNFhHgmhy+vIOo4k2yuiVIBwSYzlIHK+WwfXWMvbpIGiLYhgv9qfrn7tdKjc71RYd M62thfGrI4neutQdtld9wM2GIzoxXrmghmN21W+8= 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 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From owner-namedroppers@ops.ietf.org Sat Feb 18 08:58:27 2012 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4843321F8597 for ; Sat, 18 Feb 2012 08:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 UCYqupzil3Ms for ; Sat, 18 Feb 2012 08:58:26 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE8721F8593 for ; Sat, 18 Feb 2012 08:58:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RynVI-000333-NM for namedroppers-data0@psg.com; Sat, 18 Feb 2012 16:51:20 +0000 Received: from mail-qw0-f45.google.com ([209.85.216.45]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RynVC-00032m-Ry for namedroppers@ops.ietf.org; Sat, 18 Feb 2012 16:51:14 +0000 Received: by qabg40 with SMTP id g40so2043029qab.11 for ; Sat, 18 Feb 2012 08:51:12 -0800 (PST) Received-SPF: pass (google.com: domain of juvix88@gmail.com designates 10.229.137.80 as permitted sender) client-ip=10.229.137.80; Authentication-Results: mr.google.com; spf=pass (google.com: domain of juvix88@gmail.com designates 10.229.137.80 as permitted sender) smtp.mail=juvix88@gmail.com; dkim=pass header.i=juvix88@gmail.com Received: from mr.google.com ([10.229.137.80]) by 10.229.137.80 with SMTP id v16mr3084616qct.31.1329583872203 (num_hops = 1); Sat, 18 Feb 2012 08:51:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=lkBSbKIz8TH+CiQaeFCjRNik4QR5MZhqUtuL3vzkr6w=; b=PMkvNrNV9bs6AJKWlMv19ZNGykmDOpI9dfjPGiDh9nFVH6izwnFfPSp77pVbQF80iI 60HbjKOjkFqSUO72pbzHwt4v7o4XZTtqNmD1v0rLgSxrlQkm46u6PNDDf2/zZLbg7QRf TNenkFijC+w8J+3zy1/M7M/pRAcLgImt3C99o= Received: by 10.229.137.80 with SMTP id v16mr2689005qct.31.1329583870365; Sat, 18 Feb 2012 08:51:10 -0800 (PST) Received: from [192.168.0.199] (ool-18ba4338.dyn.optonline.net. [24.186.67.56]) by mx.google.com with ESMTPS id ec5sm28121928qab.21.2012.02.18.08.51.09 (version=SSLv3 cipher=OTHER); Sat, 18 Feb 2012 08:51:09 -0800 (PST) Message-ID: <4F3FD704.4050108@gmail.com> Date: Sat, 18 Feb 2012 11:51:16 -0500 From: Jonathan Vomacka User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Assistance with SPF Records for BIND Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: BIND Community Support, I am inquiring about how to setup a proper SPF record? I know there are SPF wizards/generators available but each seem to have a different "opinion" of what should be included and what should not be included. Let me give you a scenario of my setup, and hopefully someone can help me out. My domain is: test.com My mailserver hostname is: mail.host.com which also has a MATCHING PTR record mail.host.com (for example) resolves to 50.1.1.1 and 50.1.1.1 resolves to mail.host.com This is a STANDALONE mail server without any VIP's or load balancing. There is however one additional host that will send out mail from the domain but it wont be receiving mail, it will only be used as an SMTP server attached to a website automailer... It only generates error reports and sends them out... so technically it isn't a full mail server but it will be sending (outbound only) mail on behalf of the domain. The additional host is: mail2.test.com which resolves to 50.2.2.2 and there is a Matching PTR. These are the ONLY mail servers and IP addresses that will be sending out mail from the test.com domain. Some websites say I should use -all and others say -all will cause some MTA's to reject and ~all is better to use even if those are the only two hosts sending out mail. Would you be able to assist with a solid SPF record? From dnsext-bounces@ietf.org Tue Feb 21 14:19:16 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6D321F85D4; Tue, 21 Feb 2012 14:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329862756; bh=LTfvWPcwRX1JMO35QosWd2iL1tMF0pxTUg4FprSfnug=; h=Date:From:To:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=NoqezuYlwoN9zpkiHtBvaYMRq2YSp7cZMAgnGgPqIZzpQl/qjW5W1sUU3a+aucuws 4NZHiwfYk6Gttf3n0xV6yO4OKPU5Agviny0jS5ZPfqxG3RaT/rBx9ge3t57jK7yKzy Bw6JBbiRQyiDMu6Lp4cmGvRumf8bUpMm4SNgHZwk= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 22 07:46:36 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF64B21F87BA; Wed, 22 Feb 2012 07:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329925595; bh=uM8cxaSLAFLnsHsfZCl9CMf/LZtw3AEkZaj7K9Cobts=; h=Date:Message-Id:From:To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:MIME-Version: Content-Type:Content-Transfer-Encoding:Sender; b=iUqEFZFiYDulSbWCLyK1KUGWMJCSzh9oFjVnEx4kN84wD9N/wPswf5g8AbG08MPdC w0gb7MoVWibFHVSmYP4IdyXdU62votvrLk4B0iBD3EDMKzA1/9YBtg6MBVT9ZJYu+I 7GdbVkYHDktyX2X4KkSVZvgRuTOnG2TxdDMGBDl4= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org ------- 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 23 02:39:08 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2943F21F8672; Thu, 23 Feb 2012 02:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329993548; bh=VnZgc94J2z2rzV94X50E/Xch+jrL/ZO8HEFRXt1MmvI=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Qxo1N2oQHn5dTyl8TvhAZf6ni1j2vXvitcWkqY2RM5u7HT/Zgtw4nlE2okyxpN/X2 5B4NLaqufROdYt/w6IG/ke4iMoDT1DAczk8z1ygPAVCFQoOkarOeKWZLiHXd+SJeMd sGOMD+/hJnAceLXrKK13lZgw63sf26NryRUR8sVI= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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. 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 23 03:19:13 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A0421F8549; Thu, 23 Feb 2012 03:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329995953; bh=PibsQ78uZizlls/4IiG5JLmnpjSHrqQplgk1WFqHE7M=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=dh2mh0AXIZnV0VHArEmc5fRym1oqrbHSIzAluLildCpuyl8xI7qnqPvog7MynGiQp vv6pQehSj9JuXMfOQC23sd1HrXyABst9DJ9ao+vI2GXAToXFYkca7Oip/UcIpBMun3 UDEcK1tGF1382g4vsxlOJygwb7wZSTDGyuU60gZE= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 23 05:53:51 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17AA21F87FB; Thu, 23 Feb 2012 05:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330005231; bh=cXCG1yGLv9dtdTlXji5iKV2lZPsoa/EEELNt8n4XIZk=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=YGuaux2NcU+JrojcCR0L9hMxosgEQXqf53IwrZeHKq+Hx2zbnHPgAIgZECgLGaSAa H8ewlARYCKhzLM+T8RqF4IDn3IPzXjJEe8VPnP7QHBO3EgwYmjqENIQ8qD+I5sVPQ6 CkM/R9zS3wysuNLBjkvbybN5DpWnrjfLxt74/taA= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 23 08:53:06 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9841C21F871D; Thu, 23 Feb 2012 08:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330015986; bh=7D0df9w63IUuGZnbdFLu3CM6r3CZibHYUx8b9Zu1GgU=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=aOO9aXR2Lj1GKD1vkqNQOJ+XpDi0urqCoHXI3RXXZODHrrrAbgtPIIRv93mD7QZP6 HVy56jQFUMjHPwk1tNjbBs4Qs2TwmqJphkpsbmuP3iR4GwsbxZlDnIhDIGTqSULzc/ JJay4IKxiGOclFmzwuDGMF9pUVfOFJ/TaKNq6aZ0= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Feb 23 14:18:41 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C48C21F87E2; Thu, 23 Feb 2012 14:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330035521; bh=aXUQVpTqO1RGCXvosWhAnjIMYaXwKOUcq0+aK8sWrRE=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=me3rlr0dnLesjvL1kXBzp9OC5yOrufkXjHS9h+L3ThgEB7k95r44lx+eQRKKs1j8h 8+2mv+m8Fy12N/CWzVAmuD4em59qhoHmyW/wqfWG1r+9xRscBbRkd2t2dAkXQdixng qwoprMUc1AI6JsqGzT9blfj2Chv3RE1yBSD7/GqI= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 24 07:10:50 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7F521F86B1; Fri, 24 Feb 2012 07:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330096250; bh=uPZv+xhC6/6UhJTRO8L/5HxZEwy0LKM8fFORcjm+pK8=; h=MIME-Version:Message-ID:Date:From:To:In-Reply-To:References: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=L+FBYNozqWpI+64o+KsNaFjdhwz0sCyYwneGnsUx09DMMo7r2Pq7hHU4Tr1ggf54O CglLg5iLsZSD4judcjazX+37LmcNeemTR6N+AJ8eoto72DhQvptoXCK42mozA21AN2 0ooTXSiCLsoXt5M2s9HTK1R0BGms6J+ivB7wwyus= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 24 07:49:34 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CBD21F866E; Fri, 24 Feb 2012 07:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330098574; bh=hiBT2JDU8kFCLTxtE0Y60lTI0Lm7Mhg4Q2JfNs8Y6CI=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=TZy5cDHrBagrX1EqUhOdbM70zMPi8xr4nPPmdf+aO0E9XvZLSALvu4xf/AosNCbqC UNuk4rwBbToYP33jh8hUZu89v7ODv9h33KzO39JcEvYE61eY2QfeQGZsTkdLYFcuZC /j3PHzQhgyuI2oGIw7ajrsDwaJnlaLBXtJ7rtQLk= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org -----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----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 24 08:03:12 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DB321F8875; Fri, 24 Feb 2012 08:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330099392; bh=+4xi75mbLXM9Y7iZcciwc69bUICf091gjohBuyLSsXY=; h=MIME-Version:Message-ID:Date:From:To:In-Reply-To:References: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=LqiKJb+cBsA9QGbGzrL9D/qhzD81D6SO7wZyUUDaC/yMUMitJqhOhzjSLUvoHpD9l jLULuYLzYZf/rZhLBY/skkVh8b54k7bUACgB4ReGoP4Bq2f/iTrB9RaIJacGtyHemK 8hfxlKot5hG2WkFXRTMVhkZZj/XOROTENHBy6Wik= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org W.C.A. Wijngaards writes: > I do not think [putting the OPT] 'first' is backwards compatible. What is broken by it? _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 24 08:10:48 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E704B21F862B; Fri, 24 Feb 2012 08:10:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330099847; bh=CV6ZSXMKYvyitYKDF/FXfT+roCdA1RV5bZuxUHLmeXM=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lZ0ajmqGVx5zm5V2LzKmRy1l3ebQWwcXXbipFdZkRi3pjnO6+yQR54/MQnAX6UCL0 oEGKtosKjKboC30A+1HJNxqg++1G/PdeNwPjrbyJoacZAm9iYn6TABGAgMhUMxcTXm o4uzHSUZKFTY+NuromCBxVrruPWN8mRm5YIUed2M= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org -----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----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Feb 24 15:13:56 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A5321F864C; Fri, 24 Feb 2012 15:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330125235; bh=+7pJiZUUyAbF8sOtZS6ponf40RSs8K+ltFXtunk+V2o=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=ZafQ0hGNbn4HCtG58YV5IAv5gEkfZAqatHzxtFXmucbaV9qAe+6iVoGM3zEnCNWef 0Gs6tfsHWd8LnY0n7ZXxBOVI4w/4gW0lwczd9NE6a8wxsiAAWKfDBHpBrLIRgnJhpr 7zNgRG8uLT21IZQTt+rRc2MAmhD++6iKu+f4kyPo= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 27 10:04:49 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEA721F84E4; Mon, 27 Feb 2012 10:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330365888; bh=AWRsGze1M6Bcc142U/TpEa72PpBumdKTPg8JEZIPL5o=; h=Date:From:To:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=mt6d9vFlENh/BlRZko4KaA71cnVq8Ef+JaLUk+xVJZtkORd57TtbTDisHq8Pi9R1S BT/rcKEF4FmvnhJlMN/bmbiSrGpYkz74g7d7DY+sYER2byRpFPrieDS6Wzq5LfdTeQ lNLJ95MOj99n2wKkfqvkMldC5veX4s78ovHT70lM= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 27 10:10:26 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B260F21F8702; Mon, 27 Feb 2012 10:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330366226; bh=F30hyN04prgsh0CHchQwgyPYniQifN24dWBy8efq20M=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=SJxOZ7S7M41+3ZpWShLG4kMv/bdUErQCzmu6MLi8fDRiMkqwwprvPNxhO+09XXBEK vxE9oSKMAeUJelMfXEr5fIVOWOma7GNqbRbhqHYUyrdOBWnij3Cx3/SNR3ge8Gr+sR pSDNf8u9l1taGbEa27dkcSfnk4Hc5eiSt6uhbBLs= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Feb 27 10:50:17 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A9621F87C9; Mon, 27 Feb 2012 10:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330368616; bh=mczdBf0zqdLIYgegbT+sqklao7LPFa3IxQ0EssSSqk4=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ytTc0+4Grptkoycgf9AUrDa627h4dj/gt8NTvoIwxnjWZWL5FLf4NH8cXplBDYRKZ vPkW3ZUoYA3i3NJ0IFRiAY/U8hl0wyWaElryW3Y7h8pcJlCaHqWRF2wJzbxt621tkR vIjSfgWBEDvNPQsrho7Z5Aptnj5DisNvjbjSDPIw= 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) From: Paul Hoffman In-Reply-To: <20120227181021.GS48576@mail.yitter.info> Date: Mon, 27 Feb 2012 10:50:09 -0800 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Feb 28 13:43:56 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71E121F8574; Tue, 28 Feb 2012 13:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330465436; bh=1q3iTgXxevfJwns5oR/jI1unye40tESP8R6HW7AKh5A=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=LDlJhk+mlK88z+LLvOOKf1XusUmhqN/fJ9w7Ff/Y1zZseMRUIgWMU5yFEei6mw3fP OURK343XK7WILKVkOjWT4INf2A5tORojKry4QGY1NlbexGN1nA5hqifephVuVmzYfB Ax+jxXzZkWL2hRpW9LjhSAOKR6c4JzkVyhFtfdd4= 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-Disposition: inline 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org RGVhciBjb2xsZWFndWVzLAoKT24gNyBGZWIgSSBub3RlZCBzb21lIG91dHN0YW5kaW5nIGlzc3Vl cyB0aGF0IHdlcmUgcGVuZGluZyBwcmlvciB0bwp0aGUgZW5kIG9mIFdHTEMuICBJIHdhbnQgdG8g Z28gdGhyb3VnaCB0aGUgcmVzdWx0cyBvZiB0aGUgZGlzY3Vzc2lvbiBJCnNhdy4KCk9uIFR1ZSwg RmViIDA3LCAyMDEyIGF0IDEwOjE4OjIwQU0gLTA1MDAsIEFuZHJldyBTdWxsaXZhbiB3cm90ZToK Cj4gSVNTVUUgMTogSW5kZXRlcm1pbmFjeSBvZiBJbmRldGVybWluYXRlCgo+ICAgICBERUZBVUxU IEFDVElPTjogbm9uZS4gIFdpdGhvdXQgcHJvcG9zZWQgdGV4dCB0aGF0IGZpbmRzIHN0cm9uZwo+ ICAgICBzdXBwb3J0LCB0aGlzIGlzc3VlIHdpbGwgYmUgbGVmdCBvdXQgb2YgdGhlIGRvY3VtZW50 LiAgCgpUaGVyZSB3YXMgbm90IHByb3Bvc2VkIHRleHQgYW5kIHN0cm9uZyBzdXBwb3J0LCBzbyB0 aGUgaXNzdWUgaXMgbm90CnRha2VuIHVwLiAgVG8gbXkgZXllcywgdGhlIGRpc2N1c3Npb24gbW9z dGx5IHJldmVhbGVkIHRoYXQgdGhlcmUgYXJlCnN1YnRsZSBpbmNvbnNpc3RlbmNpZXMgYnV0IHRo YXQgaXQgZG9lc24ndCBzZWVtIHRvIGhhdmUgYSBwcmFjdGljYWwKZGlmZmVyZW5jZS4KCj4gSVNT VUUgMjogSWdub3JpbmcgQ05BTUUgc2lnbmF0dXJlcwoKPiAgICAgREVGQVVMVCBBQ1RJT046IG5v bmUuICAKClRoaXMgaXMgdGhlIHBsYW4uCgo+IElTU1VFIDM6IEFsdGVyIHNlY3Rpb24gNS4xMAog Cj4gICAgIERFRkFVTFQgQUNUSU9OOiBJbmNsdWRlIHRoZSAiSWYgYSBzaXRlIGhhcyBvbmx5IGEg c2luZ2xlIHRydXN0Cj4gICAgIGFuY2hvciDigKYiIHNlbnRlbmNlLCBhbmQgZXhjbHVkZSB0aGUg b3RoZXIgcHJvcG9zZWQgc2VudGVuY2VzLgoKVGhpcyBpcyB0aGUgcGxhbi4gIEVkaXRvcnMsIHBs ZWFzZSBtYWtlIHRoYXQgYWRqdXN0bWVudC4KCj4gSVNTVUUgNDogUmVxdWVzdCB0byBjaGFuZ2Ug dGhlIGxhbmd1YWdlIGluIDUuNgoKPiAgICAgREVGQVVMVCBBQ1RJT046IFVzZSB0aGUgZmlyc3Qg Zm9ybXVsYXRpb24gcHJvcG9zZWQgKCJJbiBvcmRlciB0bwo+ICAgICBpbnRlcm9wZXJhdGUgd2l0 aCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBpZ25vcmUgdGhpcyBydWxlIG9uCj4gICAgIHNlbmRpbmcs IHJlc29sdmVycyBuZWVkIHRvIGFsbG93IGVpdGhlciB0aGUgRE8gYml0IHRvIGJlIHNldCBvcgo+ ICAgICB1bnNldCB3aGVuIHJlY2VpdmluZyByZXNwb25zZXMuIikKClRoaXMgaXMgdGhlIHBsYW4u ICBFZGl0b3JzLCBwbGVhc2UgbWFrZSB0aGF0IGFkanVzdG1lbnQuCgo+IElTU1VFIDU6IFRoZSBD RCBiaXQgcmVkdXgKCj4gICAgIERFRkFVTFQgQUNUSU9OOiBub25lLgoKVGhlcmUgd2FzIG5vIGZv bGxvdyB1cCBkaXNjdXNzaW9uIG9uIHRoaXMsIGFuZCBJIGRpZCBub3Qgc2VlIGV4cHJlc3NlZApz dXBwb3J0IGZvciBNYXJrIEFuZHJld3MncyBwcm9wb3NlZCBjaGFuZ2UsIHNvIHRoYXQncyB0aGUg cGxhbi4KClNhbSwgYXMgZWRpdG9yIHlvdSBzYWlkIHlvdSdkIHRyYWNrZWQgc29tZSBvdGhlciBp dGVtcyBhbmQgd2VyZQpwbGFubmluZyB0byBmb2xsb3cgdXAuICBXaWxsIHlvdSBkbyB0aGF0IGFz IHNvb24gYXMgcG9zc2libGUgb24gdGhlCmxpc3QsIHBsZWFzZT8gIAoKQXBhcnQgZnJvbSB0aG9z ZSBpc3N1ZXMsIEkgYmVsaWV2ZSB0aGUgZG9jdW1lbnQgaGFzIHJlY2VpdmVkIGVub3VnaApyZXZp ZXcgdGhhdCBpdCBjYW4gYmUgc2VudCB0byB0aGUgSUVTRy4gCgpUaGFua3MsCgpBCgotLSAKQW5k cmV3IFN1bGxpdmFuCmFqc0BhbnZpbHdhbHJ1c2Rlbi5jb20KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KZG5zZXh0IG1haWxpbmcgbGlzdApkbnNleHRAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNleHQK From dnsext-bounces@ietf.org Wed Feb 29 07:28:18 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3360E21F8685; Wed, 29 Feb 2012 07:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330529298; bh=fSF/TC3/phimBmehHKlMjSJDyxKrifuC33pQoWL4Qrs=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Za/rkyHiHhDvPUAQBiilLcjFcJm68k+v7vI9jelrTSAoFHcpCXGn8/P38xZxPjyqm H4p7l1kwSkef8fp/0Zqgfs/sXGj7jgFMn1YjO+xDnwTiFsplme003t3qHnjTLYpSZe 3TSl2QCx0qkVWE5qxyqHHPPeWWOb+C4K1MiQ36sM= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 : 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Feb 29 10:03:44 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1805E21F8752; Wed, 29 Feb 2012 10:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330538624; bh=/VlHtzuWitGI59PXhZ3soxnuPeUFZUEdRyTBqKzAR0w=; h=From:Date:References:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=WSFcTtFcBDAxswiXpZ/68CRHcGzwlWWHAOLMhmL/2b83HPZzIqxi69/2HvBS/FcDE eKib/cp+YZVrwXBC2I28Mm1JxGNZ2MM3YqMYTs4r72LneBDzyfWMK2JXr6wnXXNMOy rlDH1G2gofZWW7zMmIby/YKJTT7TRc8uFOkW4Q/k= 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?= 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org SGkgYWxsLAoKSSB3b3VsZG4ndCBub3JtYWxseSBjcm9zc3Bvc3QgdGhpcywgYnV0IHNpbmNlIGl0 J3Mgb3VyIDEuMC4wIHZlcnNpb24uLi4KClNvIHNvcnJ5IGZvciBkdXBsaWNhdGVzIGFuZCBwbGVh c2UgZG93bmxvYWQsIGVuam95LCBhd2UsIHRlc3QgYW5kIHJlcG9ydCBidWdzIDopLgoKVGhhbmtz LApPbmRyZWoKCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOgoKPiBGcm9tOiBMdWJvcyBTbG92YWsg PGx1Ym9zLnNsb3Zha0BuaWMuY3o+Cj4gU3ViamVjdDogW2tub3QtZG5zLXVzZXJzXSBLbm90IERO UyB2MS4wLjAgcmVsZWFzZWQhCj4gRGF0ZTogMjkuIMO6bm9yYSAyMDEyIDE3OjEzOjQ3IEdNVCsw MTowMAo+IFRvOiBrbm90LWRucy11c2Vyc0BsaXN0cy5uaWMuY3oKPiAKPiBEZWFyIEtub3QgRE5T IHVzZXJzLAo+IAo+IHNwZWNpYWwgZGF5cyBkZXNlcnZlIHNwZWNpYWwgZXZlbnRzIGFuZCB0aGlz IGRheSB3aWxsIHN1cmVseSBiZSBleHRyYW9yZGluYXJ5IG5vdCBvbmx5IGZvciB1cywgYnV0IGZv ciB0aGUgd2hvbGUgRE5TIGNvbW11bml0eS4gQ1ouTklDIExhYnMgcmVsZWFzZWQgZmlyc3Qgc3Rh YmxlIHZlcnNpb24gb2YgS25vdCBETlMhCj4gCj4gUGxlYXNlIHZpc2l0IG91ciB3ZWJzaXRlIGh0 dHA6Ly93d3cua25vdC1kbnMuY3ogZm9yIG1vcmUgaW5mb3JtYXRpb24gYW5kIGFsbCByZWxldmFu dCBsaW5rcy4KPiAKPiBTb3VyY2UgZmlsZXMgYXJlIGF2YWlsYWJsZSBoZXJlOiBodHRwOi8vcHVi bGljLm5pYy5jei9maWxlcy9rbm90LWRucy9rbm90LTEuMC4wLnRhci5nego+IChTSEEyNTY6IGFi OTQ3ZmYwOTY1NWY0NGJkNDEwNmRhNjU3NjQ4MTBmZjc2MGI2NDZiODNlOWIwOTM5ZWU5OTRmOTQz MzcyYTYpCj4gUGFja2FnZXMgd2lsbCBiZSBhdmFpbGFibGUgc2hvcnRseSBmcm9tIHVzdWFsIHJl cG9zaXRvcmllcy4gSW5zdHJ1Y3Rpb25zIG9uIGhvdyB0byBzZXR1cCB0aGVtIGFyZSBhdmFpbGFi bGUgYXQgaHR0cDovL3d3dy5rbm90LWRucy5jei4KPiAKPiBMb3RzIG9mIHRlc3RpbmcgaGFzIGJl ZW4gZG9uZSBpbiB0aGUgcGFzdCBmZXcgd2Vla3MgYW5kIHdlIGJlbGlldmUgS25vdCBETlMgaXMg YXMgc3RhYmxlIGFuZCBidWdmcmVlIGFzIHBvc3NpYmxlLiBUaGFuayB5b3UgYWxsIGZvciBzdXBw b3J0IGFuZCBmZWVkYmFjayEKPiAKPiBXZSB3aWxsIGNvbnRpbnVlIGRldmVsb3BpbmcgS25vdCBE TlMgLSB0aGVyZSBpcyBzdGlsbCBwbGFjZSBmb3IgYSBsb3Qgb2Ygb3B0aW1pemF0aW9ucywgbWlu b3IgdHdlYWtzIG9yIG5ldyBmZWF0dXJlcywgc28gc3RheSB0dW5lZCBmb3IgbmV4dCByZWxlYXNl cy4KPiAKPiBUaGFuayB5b3UgYWdhaW4gZm9yIHVzaW5nIEtub3QgRE5TIQoKLS0KIE9uZMWZZWog U3Vyw70KIHZlZG91Y8OtIHbDvXprdW11L0hlYWQgb2YgUiZEIGRlcGFydG1lbnQKIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIENaLk5JQywgei5zLnAuby4gICAg LS0gICAgTGFib3JhdG/FmWUgQ1ouTklDCiBBbWVyaWNrYSAyMywgMTIwIDAwIFByYWhhIDIsIEN6 ZWNoIFJlcHVibGljCiBtYWlsdG86b25kcmVqLnN1cnlAbmljLmN6ICAgIGh0dHA6Ly9uaWMuY3ov CiB0ZWw6KzQyMC4yMjI3NDUxMTAgICAgICAgZmF4Ois0MjAuMjIyNzQ1MTEyCiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpkbnNleHQgbWFpbGluZyBsaXN0CmRuc2V4dEBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ruc2V4dAo=