From peter@denic.de Thu Feb 7 03:14:47 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FC921F85D6 for ; Thu, 7 Feb 2013 03:14: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1Hq+RYreOjS for ; Thu, 7 Feb 2013 03:14:47 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id CF1F621F85CE for ; Thu, 7 Feb 2013 03:14:46 -0800 (PST) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1U3PRG-0004FZ-6E; Thu, 07 Feb 2013 12:14:46 +0100 Received: from localhost by x27.adm.denic.de with local id 1U3PRG-0000i7-2j; Thu, 07 Feb 2013 12:14:46 +0100 Date: Thu, 7 Feb 2013 12:14:46 +0100 From: Peter Koch To: dnsop@ietf.org Message-ID: <20130207111446.GM1320@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] DNSOP Meeting in Orlando/IETF86 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 11:14:47 -0000 Dear WG, your chairs have requested a one hour slot for the Orlando meeting. We have a set of things to discuss, which we will present in the draft agenda soon, but we would also like to solicit suggestions for agenda items from you. Please direct your ideas to . -Stephen & Peter From peter@denic.de Sat Feb 9 12:46:16 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9750021F875F for ; Sat, 9 Feb 2013 12:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DSq3hFzBIr4 for ; Sat, 9 Feb 2013 12:46:16 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id E0A4521F873B for ; Sat, 9 Feb 2013 12:46:10 -0800 (PST) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1U4HJ9-0002nr-45; Sat, 09 Feb 2013 21:45:59 +0100 Received: from localhost by x27.adm.denic.de with local id 1U4HJ9-00070I-0K; Sat, 09 Feb 2013 21:45:59 +0100 Date: Sat, 9 Feb 2013 21:45:58 +0100 From: Peter Koch To: IETF DNSOP WG Message-ID: <20130209204558.GA12175@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 20:46:16 -0000 Dear WG, the topic of AS112 has been addresses in the DNSOP WG resulting in RFCs 6304 and 6305 and is also related to 'local zones' as described in RFC 6303. The question of extending AS112 service to IPv6 (as in "transport") as well as the maintainability of the list of zones served by AS112 systems has been discussed before. We have a proposal in draft-wkumari-dnsop-omniscient-as112-01.txt to make the AS112 served zone set extendable in the future. Please read the draft and state whether you think this is something the WG - and you in particular - would want to work on. We'd like to find five volunteers for thorough document reviews to support the draft going forward - provided the overall response is positive. It is always very helpful if people could identify open questions in/w.r.t. the draft, but please don't forget to also state your opinion on adoption. Please respond by the end of next week, so that we could ask future editors to submit a renamed -00 version by Monday, Feb 18. Thanks, Peter & Stephen From ggm@algebras.org Sun Feb 10 14:42:00 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B8521F8CCB for ; Sun, 10 Feb 2013 14:42:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYI5OPNwzDc9 for ; Sun, 10 Feb 2013 14:42:00 -0800 (PST) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 41B2A21F8C51 for ; Sun, 10 Feb 2013 14:42:00 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id ma3so439829pbc.25 for ; Sun, 10 Feb 2013 14:42:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=1CMZOP55VstM/NUj/8EPCBRvFxMwpqR1FvTgq0oQf6g=; b=dGCNGOLgcchlA6mar8Lw+zEtWk+bYb+FGcVnU3msFJyC84kdEXx8IciKLx3d8CL9Xg ZJM0JCMMMIQv33Va34dTDW6AJK3yG7fssXDjOTykiaosfsZF6iRdniOnWK4UHE6OJFcz RT+niVnUZrYIXetE/25utOOZlltsnJOMzBfTfj36kyEl7DQP1gUA2g16qNwKVlQhzRpN dDPQeKpjrrUCrDwubn/Amcz5qpa7hzydPJAK0nbMZ+VoG/FCIGqsg6okcyWkUYC398Ld j3OtTu5zE8YAwR4JOR2DwwK5PtiHDzL/u/ZU8JpHAVPVrA3O86BC9B+49i5s9puyriI4 CUeA== X-Received: by 10.68.38.101 with SMTP id f5mr13956250pbk.131.1360536119889; Sun, 10 Feb 2013 14:41:59 -0800 (PST) Received: from dynamic172.apnic.net (dynamic172.apnic.net. [203.119.42.172]) by mx.google.com with ESMTPS id kr9sm5570597pbc.2.2013.02.10.14.41.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Feb 2013 14:41:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: George Michaelson In-Reply-To: <20130209204558.GA12175@x28.adm.denic.de> Date: Mon, 11 Feb 2013 08:42:01 +1000 Content-Transfer-Encoding: 7bit Message-Id: <99C4E126-E394-4F6B-A800-2E837F827A92@algebras.org> References: <20130209204558.GA12175@x28.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkcmnwfQoEy8EQAHV0j/onXumqg0GidyesyQgKOI6eNrFN6ySSR4HJ6qDGf1ff3Ko+ttF5H Cc: IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 22:42:01 -0000 I support adoption. I am volunteering for document review. -G On 10/02/2013, at 6:45 AM, Peter Koch wrote: > Dear WG, > > the topic of AS112 has been addresses in the DNSOP WG resulting in > RFCs 6304 and 6305 and is also related to 'local zones' as described in > RFC 6303. > > The question of extending AS112 service to IPv6 (as in "transport") > as well as the maintainability of the list of zones served by AS112 > systems has been discussed before. We have a proposal in > > draft-wkumari-dnsop-omniscient-as112-01.txt > > to make the AS112 served zone set extendable in the future. > Please read the draft and state whether you think this is something > the WG - and you in particular - would want to work on. We'd like to > find five volunteers for thorough document reviews to support the > draft going forward - provided the overall response is positive. > > It is always very helpful if people could identify open questions in/w.r.t. > the draft, but please don't forget to also state your opinion on adoption. > > Please respond by the end of next week, so that we could ask future > editors to submit a renamed -00 version by Monday, Feb 18. > > Thanks, > Peter & Stephen > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From peter@denic.de Sun Feb 10 23:27:29 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6919621F8940 for ; Sun, 10 Feb 2013 23:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq9e1Qc9y2pU for ; Sun, 10 Feb 2013 23:27:29 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id CA35A21F88B2 for ; Sun, 10 Feb 2013 23:27:28 -0800 (PST) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1U4nnR-0007Zv-Vr; Mon, 11 Feb 2013 08:27:26 +0100 Received: from localhost by x27.adm.denic.de with local id 1U4nnR-0002aK-SG; Mon, 11 Feb 2013 08:27:25 +0100 Date: Mon, 11 Feb 2013 08:27:25 +0100 From: Peter Koch To: IETF DNSOP WG Message-ID: <20130211072725.GD12175@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] DNSOP slot scheduled for Orlando X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 07:27:29 -0000 Dear WG, we have been assigned a one hour slot, as requested, for Orlando. Thursday afternoon, 1740-1840: Boca 1 SEC oauth Web Authorization Protocol Caribbean 6 RTG isis IS-IS for IP Internets Caribbean 1 INT dhc Dynamic Host Configuration Caribbean 2 TSV tsvwg Transport Area Working Group Caribbean 5 RAI avtcore Audio/Video Transport Core Maintenance Caribbean 4 OPS dnsop Domain Name System Operations Caribbean 3 IAB iab-wcit IAB-sponsored Discussion of WCIT BOF Our scheduling-conflicts-to-avoid list is already rather long and scheduling is never easy and thus rarely ever perfect, so please let Stephen and me know if this is an issue for you this time. We'll collect responses privately to gauge the need for a change request. Thanks, Peter From warren@kumari.net Wed Feb 13 09:34:14 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8294921F87F6 for ; Wed, 13 Feb 2013 09:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.725 X-Spam-Level: X-Spam-Status: No, score=-102.725 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyF+tHttDvvS for ; Wed, 13 Feb 2013 09:34:14 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DC321F87E1 for ; Wed, 13 Feb 2013 09:34:10 -0800 (PST) Received: from [192.168.1.136] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id DCECF1B40402; Wed, 13 Feb 2013 12:34:09 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <20130209204558.GA12175@x28.adm.denic.de> Date: Wed, 13 Feb 2013 12:34:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130209204558.GA12175@x28.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1499) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:34:14 -0000 On Feb 9, 2013, at 3:45 PM, Peter Koch wrote: > Dear WG, >=20 > the topic of AS112 has been addresses in the DNSOP WG resulting in > RFCs 6304 and 6305 and is also related to 'local zones' as described = in > RFC 6303. >=20 > The question of extending AS112 service to IPv6 (as in "transport") > as well as the maintainability of the list of zones served by AS112 > systems has been discussed before. We have a proposal in >=20 > draft-wkumari-dnsop-omniscient-as112-01.txt >=20 > to make the AS112 served zone set extendable in the future. > Please read the draft and state whether you think this is something > the WG - and you in particular - would want to work on. We'd like to > find five volunteers for thorough document reviews to support the > draft going forward - provided the overall response is positive. >=20 > It is always very helpful if people could identify open questions = in/w.r.t. > the draft, but please don't forget to also state your opinion on = adoption. >=20 > Please respond by the end of next week, so that we could ask future > editors to submit a renamed -00 version by Monday, Feb 18. And just a note: The last day for submission of a -00 is Feb18th, but the last day for = adoption was the 11th. So, if this is adopted, the authors can resubmit with a new name, but it = approved till the cycle restarts=85 =95 2013-02-11 (Monday): Working Group Chair approval for = initial document (Version -00) submissions appreciated by UTC 24:00. =95 2013-02-18 (Monday): Internet Draft Cut-off for initial = document (-00) submission by UTC 24:00, upload using IETF ID Submission = Tool. W >=20 > Thanks, > Peter & Stephen > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 -- What our ancestors would really be thinking, if they were alive today, = is: "Why is it so dark in here?" -- (Terry Pratchett, Pyramids) From peter@denic.de Wed Feb 13 09:42:53 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12DA21F8888 for ; Wed, 13 Feb 2013 09:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o4Uug3ejx+7 for ; Wed, 13 Feb 2013 09:42:53 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id CE07921F8877 for ; Wed, 13 Feb 2013 09:42:52 -0800 (PST) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1U5gM7-0007Ry-N8; Wed, 13 Feb 2013 18:42:51 +0100 Received: from localhost by x27.adm.denic.de with local id 1U5gM7-0001cC-JK; Wed, 13 Feb 2013 18:42:51 +0100 Date: Wed, 13 Feb 2013 18:42:51 +0100 From: Peter Koch To: IETF DNSOP WG Message-ID: <20130213174251.GL27968@x28.adm.denic.de> References: <20130209204558.GA12175@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:42:54 -0000 On Wed, Feb 13, 2013 at 12:34:09PM -0500, Warren Kumari wrote: > The last day for submission of a -00 is Feb18th, but the last day for adoption was the 11th. > So, if this is adopted, the authors can resubmit with a new name, but it approved till the cycle restarts? > > ? 2013-02-11 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00. > ? 2013-02-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload using IETF ID Submission Tool. the time difference appears to be a leftover from pre-automation times. WG chairs can use automated tools to approve or even pre-approve a WG -00 submission, i.e., this will not be a process road block. -Peter From nick@inex.ie Thu Feb 14 03:32:08 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D06B21F869C for ; Thu, 14 Feb 2013 03:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2710kBYWuJZH for ; Thu, 14 Feb 2013 03:32:08 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id AD9F021F8480 for ; Thu, 14 Feb 2013 03:32:07 -0800 (PST) X-Envelope-To: Received: from crumpet.local ([IPv6:2001:1bb8:2004:200::180]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r1EBTSNL097229 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 14 Feb 2013 11:29:28 GMT (envelope-from nick@inex.ie) Message-ID: <511CCB34.7040000@inex.ie> Date: Thu, 14 Feb 2013 11:32:04 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: dnsop@ietf.org X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 11:32:08 -0000 > The question of extending AS112 service to IPv6 (as in "transport") > as well as the maintainability of the list of zones served by AS112 > systems has been discussed before. We have a proposal in > > draft-wkumari-dnsop-omniscient-as112-01.txt > > to make the AS112 served zone set extendable in the future. > Please read the draft and state whether you think this is something > the WG - and you in particular - would want to work on. We'd like to > find five volunteers for thorough document reviews to support the > draft going forward - provided the overall response is positive. I like this and think it should be adopted as a WG doc. Am not going to volunteer for formal document review, but would be happy to run + provide feedback for this sort of code in a live environment. Nick From list-dnsop@dragon.net Fri Feb 15 14:05:44 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7F521F8464 for ; Fri, 15 Feb 2013 14:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbyEW6S4qrGm for ; Fri, 15 Feb 2013 14:05:43 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) by ietfa.amsl.com (Postfix) with ESMTP id F0FD521F85D0 for ; Fri, 15 Feb 2013 14:05:42 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by mail.dragon.net (Postfix) with ESMTP id 21A5A37403EA for ; Fri, 15 Feb 2013 14:05:41 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 9A63419E01D5; Fri, 15 Feb 2013 14:05:41 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 963FF19E01CC for ; Fri, 15 Feb 2013 14:05:41 -0800 (PST) To: dnsop@ietf.org From: Paul Ebersman In-reply-to: <511CCB34.7040000@inex.ie> References: <511CCB34.7040000@inex.ie> Comments: In-reply-to Nick Hilliard message dated "Thu, 14 Feb 2013 11:32:04 +0000." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Fri, 15 Feb 2013 14:05:41 -0800 Message-Id: <20130215220541.9A63419E01D5@fafnir.remote.dragon.net> Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 22:05:44 -0000 nick> I like this and think it should be adopted as a WG doc. Am not nick> going to volunteer for formal document review, but would be happy nick> to run + provide feedback for this sort of code in a live nick> environment. I also support this being adopted as a WG document. From christopher.morrow@gmail.com Fri Feb 15 14:57:48 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394B721F84D8 for ; Fri, 15 Feb 2013 14:57:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnPe-GiErro7 for ; Fri, 15 Feb 2013 14:57:47 -0800 (PST) Received: from mail-la0-x22b.google.com (la-in-x022b.1e100.net [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 80F5A21F846B for ; Fri, 15 Feb 2013 14:57:47 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id ek20so3971927lab.30 for ; Fri, 15 Feb 2013 14:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tOy3eBX7hsfS3oZD3doTuyTuL/aEf8IKlWNxe1lH+F8=; b=o4TCDbjBfVmtYsNXefigfu9CHP4On6fV4FsLahacj4SmKqqyInVDsTssK1m6UitG5F fO1NNsSmHGRT2Br1XD1ou4SkVhIMB8WmgobmmwIc/FJIOpe6RtnMYslvW4ZhfS17h6t6 q6mOfDrx+wFvbf+yjmoQ+fPaaqOqgtDYqwxGMHQoD3uHWEs2foFOgekxdpVpNfJ3DnjJ KBUquiOZAH7sR3rELqyr43tnDa34O5XPiMqGfiatW67heqlStuY3s8Tbc37XrlF7eePv 1FP9qlQlUrtOm40Dl6ZX93rZA4OWjx+XyiuWo0ABQ5J0eLrivgz4N2+nOrgdlBLAADEx 886Q== MIME-Version: 1.0 X-Received: by 10.152.144.138 with SMTP id sm10mr3607007lab.53.1360969066474; Fri, 15 Feb 2013 14:57:46 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.152.27.163 with HTTP; Fri, 15 Feb 2013 14:57:46 -0800 (PST) In-Reply-To: <20130215220541.9A63419E01D5@fafnir.remote.dragon.net> References: <511CCB34.7040000@inex.ie> <20130215220541.9A63419E01D5@fafnir.remote.dragon.net> Date: Fri, 15 Feb 2013 17:57:46 -0500 X-Google-Sender-Auth: 2yXouMyis7HSRh3fLgM1J0h0keg Message-ID: From: Christopher Morrow To: Paul Ebersman Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsop@ietf.org Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 22:57:48 -0000 On Fri, Feb 15, 2013 at 5:05 PM, Paul Ebersman wrote: > > nick> I like this and think it should be adopted as a WG doc. Am not > nick> going to volunteer for formal document review, but would be happy > nick> to run + provide feedback for this sort of code in a live > nick> environment. > > I also support this being adopted as a WG document. me too! seems like a great start. From paul.hoffman@vpnc.org Fri Feb 15 15:37:11 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EF821F8522 for ; Fri, 15 Feb 2013 15:37:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFMrhL8pqBh4 for ; Fri, 15 Feb 2013 15:37:11 -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 E1A9321F84F9 for ; Fri, 15 Feb 2013 15:37:10 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1FNb2fd093364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Feb 2013 16:37:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20130209204558.GA12175@x28.adm.denic.de> Date: Fri, 15 Feb 2013 15:37:02 -0800 Content-Transfer-Encoding: 7bit Message-Id: <161323FD-70F3-400E-8777-1E471F1CFD2C@vpnc.org> References: <20130209204558.GA12175@x28.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1499) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 23:37:11 -0000 Sure, looks good. I'll review drafts. --Paul Hoffman From jason_livingood@cable.comcast.com Sat Feb 16 14:20:28 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC92E21F8970 for ; Sat, 16 Feb 2013 14:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.147 X-Spam-Level: X-Spam-Status: No, score=-104.147 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD6PnWkslu-5 for ; Sat, 16 Feb 2013 14:20:26 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id F31F921F86A2 for ; Sat, 16 Feb 2013 14:20:25 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.56586762; Sat, 16 Feb 2013 14:50:24 -0700 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Sat, 16 Feb 2013 17:20:22 -0500 From: "Livingood, Jason" Thread-Topic: Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJg== Date: Sat, 16 Feb 2013 22:20:22 +0000 Message-ID: <10229F86C86EB444898E629583FD4171616521A5@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_10229F86C86EB444898E629583FD4171616521A5PACDCEXMB06cabl_" MIME-Version: 1.0 To: "dnsop@ietf.org" Subject: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 22:20:28 -0000 --_000_10229F86C86EB444898E629583FD4171616521A5PACDCEXMB06cabl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I just posted (finally, I know) an update to draft-livingood-negative-trust= -anchors, which you can find at https://datatracker.ietf.org/doc/draft-livi= ngood-negative-trust-anchors/. This update incorporates feedback from Paul Vixie, Antoin Verschuren, Patri= k Wallstrom, Patrik Falstrom, Marc Lampo, Ralf Weber, Wes Hardaker, Nick We= aver, Tony Finch, Shane Kerr, Joe Abley, Murray Kucherawy, and Olafur Gudmu= ndsson. The are six critical open issues documented at the end of the I-D. But the most important questions for this WG are: 1 =96 Is this worth consideration as a WG I-D or should it continue only as= an individual I-D? 2 =96 If the answer to #1 is that it should be a WG I-D, would you like a b= rief discussion of the open issues at IETF 86? Thanks! Jason --_000_10229F86C86EB444898E629583FD4171616521A5PACDCEXMB06cabl_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I just posted (finally, I know) an update to draft-livingood-nega= tive-trust-anchors, which you can find at https://datatracke= r.ietf.org/doc/draft-livingood-negative-trust-anchors/.

This update incorporates feedback from Paul Vixie, Antoin Verschuren, = Patrik Wallstrom, Patrik Falstrom, Marc Lampo, Ralf Weber, Wes Hardaker, Ni= ck Weaver, Tony Finch, Shane Kerr, Joe Abley, Murray Kucherawy, and Olafur = Gudmundsson.

The are six critical open issues documented at the end of the I-D.&nbs= p;

But the most important questions for this WG are:
1 =96 Is this worth consideration as a WG I-D or should it continue on= ly as an individual I-D?
2 =96 If the answer to #1 is that it should be a WG I-D, would you lik= e a brief discussion of the open issues at IETF 86?

Thanks!
Jason


--_000_10229F86C86EB444898E629583FD4171616521A5PACDCEXMB06cabl_-- From Ted.Lemon@nominum.com Sat Feb 16 15:04:35 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24C121F8A66 for ; Sat, 16 Feb 2013 15:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kI-WWr2Gd6I8 for ; Sat, 16 Feb 2013 15:04:34 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 69A9521F8206 for ; Sat, 16 Feb 2013 15:04:34 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUSAQgYxWTO67SB4hIReeFOx0WyZZlzBH@postini.com; Sat, 16 Feb 2013 15:04:34 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A905A1B8610 for ; Sat, 16 Feb 2013 15:04:33 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8885E190043; Sat, 16 Feb 2013 15:04:33 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sat, 16 Feb 2013 15:04:33 -0800 From: Ted Lemon To: "Livingood, Jason" Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9oOoA Date: Sat, 16 Feb 2013 23:04:32 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474917DB@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD4171616521A5@PACDCEXMB06.cable.comcast.com> In-Reply-To: <10229F86C86EB444898E629583FD4171616521A5@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <018AE987285CBF4CA7A82E5D6D663938@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 23:04:35 -0000 I think this is important work. I have to confess that I haven't followed= the development of this draft, so this may be an observation that's alread= y been addressed, but I'm concerned that there's nothing in this document a= bout ensuring that the negative trust anchor is trustworthy through validat= ion other than through the X.509 CA infrastructure currently used for TLS. The problem with this is that it means that a compromised CA (of which ther= e have been a number recently) can be used as an attack on the DNSSEC valid= ation chain. In addition, some CAs have been known to issue Certs for the= express purpose of circumventing privacy and authentication features of X.= 509 certs. DANE has recently published documents that leverage the DNSSEC infrastructu= re to protect organizations that have implemented DNSSEC from X.509 PKI att= acks. If you use that same PKI to validate negative trust anchors, you're= effectively invalidating the security model of those RFCs. I think therefore that using X.509 certs as negative trust anchors is a rea= lly bad idea, and I would suggest that it might be worth proposing a mechan= ism in your draft that does not rely on such trust anchors. I would suggest that the right solution is to rely on the DNSSEC security i= nfrastructure to publish negative trust anchors, rather than relying on RFC= 5280. I realize that this means more work, probably for DNSEXT, the chair= s of which were hoping for a vacation after completing their current work, = but I think this would be a much better option nevertheless. Again, sorry if I'm misunderstanding what you're proposing. From joe.abley@icann.org Sat Feb 16 15:21:44 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C6721F8A6B for ; Sat, 16 Feb 2013 15:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7ovW1vcMZjI for ; Sat, 16 Feb 2013 15:21:44 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id EABC321F8A66 for ; Sat, 16 Feb 2013 15:21:43 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Sat, 16 Feb 2013 15:21:43 -0800 From: Joe Abley To: Ted Lemon Date: Sat, 16 Feb 2013 15:21:43 -0800 Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: Ac4MnGE2M4o3ZwPzT5aOAbTD1H9MoQ== Message-ID: <50F0DCC6-C4D7-44E6-8C2F-4A2E17DE33A1@icann.org> References: <10229F86C86EB444898E629583FD4171616521A5@PACDCEXMB06.cable.comcast.com> <8D23D4052ABE7A4490E77B1A012B6307474917DB@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474917DB@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org" , "Livingood, Jason" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 23:21:44 -0000 On 2013-02-16, at 18:04, Ted Lemon wrote: > I would suggest that the right solution is to rely on the DNSSEC security= infrastructure to publish negative trust anchors, rather than relying on R= FC5280. I realize that this means more work, probably for DNSEXT, the cha= irs of which were hoping for a vacation after completing their current work= , but I think this would be a much better option nevertheless. I'm confused where you drew the reference to 5280 from (or X.509). I don't = see anything in the draft that concerns publication or automatic retrieval = of NTAs from elsewhere; which section did I miss? I do quite like the idea of being able to publish a policy for a family of = validators, however. I like the idea of being able to bring up a validator = and subscribe consciously to the policy in such a zone, along the lines of = "I'll disable validation for anything I've noticed needs to be handled that= way, plus anything that Comcast is willing to tell me about their current = validation policy because they know what they are doing". This has advantag= es for me as a validator operator, and advantages for others who might want= to debug the output of my validator with reference to my current validatio= n policy. I like the idea of such a policy being published in the DNS, also. Given that validators already have hooks to disable validation for particul= ar domains, and assuming we don't necessarily need to invent new RRTypes to= encapsulate that policy in the DNS, I don't necessarily see dnsext work in= here. A convention about how to represent this kind of policy in the DNS s= eems like it could be dnsop work, though. Jason: you didn't ask directly, but if the working group was polled to dete= rmine support for adopting this document, I would say yes and volunteer to = review it. Joe= From Ted.Lemon@nominum.com Sat Feb 16 15:32:29 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73CF21F8828 for ; Sat, 16 Feb 2013 15:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKsote1MBPgG for ; Sat, 16 Feb 2013 15:32:29 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACD121F86BB for ; Sat, 16 Feb 2013 15:32:29 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUSAXDFD8QhFlysVQgbKQZo5HQoMiLqG/@postini.com; Sat, 16 Feb 2013 15:32:29 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AC7501B8483 for ; Sat, 16 Feb 2013 15:32:28 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 957C3190043; Sat, 16 Feb 2013 15:32:28 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sat, 16 Feb 2013 15:32:28 -0800 From: Ted Lemon To: Joe Abley Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9oOoAgAAEzYCAAAMAgA== Date: Sat, 16 Feb 2013 23:32:28 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474918B2@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD4171616521A5@PACDCEXMB06.cable.comcast.com> <8D23D4052ABE7A4490E77B1A012B6307474917DB@mbx-01.win.nominum.com> <50F0DCC6-C4D7-44E6-8C2F-4A2E17DE33A1@icann.org> In-Reply-To: <50F0DCC6-C4D7-44E6-8C2F-4A2E17DE33A1@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <4E349127B9BC0E4BA845C38E55439DA4@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org" , "Livingood, Jason" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 23:32:29 -0000 > I'm confused where you drew the reference to 5280 from (or X.509). I don'= t see anything in the draft that concerns publication or automatic retrieva= l of NTAs from elsewhere; which section did I miss? Sorry, I was one RFC deeper in the reference tree than I thought. The dra= ft that Jason's draft references is RFC5914, not RFC5280, in Section 7. R= FC5914 in turn references RFC5280. :) > I do quite like the idea of being able to publish a policy for a family o= f validators, however. I like the idea of being able to bring up a validato= r and subscribe consciously to the policy in such a zone, along the lines o= f "I'll disable validation for anything I've noticed needs to be handled th= at way, plus anything that Comcast is willing to tell me about their curren= t validation policy because they know what they are doing". This has advant= ages for me as a validator operator, and advantages for others who might wa= nt to debug the output of my validator with reference to my current validat= ion policy. Yes, this does have advantages, although Comcast's security infrastructure = may be much less secure than the infrastructure of the zones it could inval= idate. > Given that validators already have hooks to disable validation for partic= ular domains, and assuming we don't necessarily need to invent new RRTypes = to encapsulate that policy in the DNS, I don't necessarily see dnsext work = in here. A convention about how to represent this kind of policy in the DNS= seems like it could be dnsop work, though. If it's represented in the DNS, we need to talk about the security model. = I guess we do anyway, but the point is that merely having an ops doc that = stashes it in the DNS somewhere isn't going to be enough. > Jason: you didn't ask directly, but if the working group was polled to de= termine support for adopting this document, I would say yes and volunteer t= o review it. I want to hear Jason's response to my possibly out-from-left-field comments= before making any such commitment. :) From paul.hoffman@vpnc.org Sat Feb 16 16:43:54 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D73621F86BB for ; Sat, 16 Feb 2013 16:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFo27W2ofyTL for ; Sat, 16 Feb 2013 16:43:53 -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 98D3321F85A0 for ; Sat, 16 Feb 2013 16:43:53 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1H0ho1L027177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Feb 2013 17:43:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <10229F86C86EB444898E629583FD4171616521A5@PACDCEXMB06.cable.comcast.com> Date: Sat, 16 Feb 2013 16:43:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10229F86C86EB444898E629583FD4171616521A5@PACDCEXMB06.cable.comcast.com> To: "Livingood, Jason" X-Mailer: Apple Mail (2.1499) Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 00:43:54 -0000 Ted's misunderstanding of what you are proposing is a valid one. You = don't actually say what a negative trust anchor is, and what it is a = trust anchor for, until section 7. Readers such as Ted (and myself!) = will have strong prejudices by then. I would want to see something in the Introduction saying something like: This document discusses trust anchors for DNSSEC. A "negative trust = anchor" is equivalent to a "regular" DNSSEC trust anchor for a = particular instance of a recursive validating resolver. A negative trust = anchor is quite different from regular DNSSEC trust anchors in that they = are local, temporary, and definitely not distributed by IANA. They are = trust anchors only for DNSSEC, not for PKIX. That should help set the tone for the following sections that say how to = use them, and then the much later sections on what they actually are. --Paul Hoffman= From jason_livingood@cable.comcast.com Sun Feb 17 06:57:51 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C28621F8A71 for ; Sun, 17 Feb 2013 06:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+BxuFTaRfMY for ; Sun, 17 Feb 2013 06:57:51 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 16B7021F85D0 for ; Sun, 17 Feb 2013 06:57:50 -0800 (PST) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.43727886; Sun, 17 Feb 2013 09:45:17 -0500 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Sun, 17 Feb 2013 09:57:26 -0500 From: "Livingood, Jason" Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9oOoA///SgoCAAAMBAIAArp0A Date: Sun, 17 Feb 2013 14:57:26 +0000 Message-ID: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474918B2@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Ted Lemon , Joe Abley Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 14:57:51 -0000 On 2/16/13 6:32 PM, "Ted Lemon" wrote: >> I'm confused where you drew the reference to 5280 from (or X.509). I >>don't see anything in the draft that concerns publication or automatic >>retrieval of NTAs from elsewhere; which section did I miss? > >Sorry, I was one RFC deeper in the reference tree than I thought. The >draft that Jason's draft references is RFC5914, not RFC5280, in Section >7. RFC5914 in turn references RFC5280. :) A Negative Trust Anchor should IMO be locally configured and not rely upon any external validation or sourcing for the Negative Trust Anchor(s). It basically tells the recursive resolver to not perform (skip) DNSSEC validation on a specific domain name for which a Negative Trust Anchor has been locally configured. Since it would be locally configured it should not rely on the CA infrastructure at all, and all of the inherent issues of that - or need to rely on certificate revocations and whatnot. Also, if a domain has already messed up their DNSSEC signing operations, it is unlikely they'd figure out a way to properly sign a Negative Trust Anchor or anything else for that matter. I hope that helps, assuming of course that I understood the question relating RFC5280 to this I-D. :-) Jason From jason_livingood@cable.comcast.com Sun Feb 17 07:01:19 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505AF21F8A8B for ; Sun, 17 Feb 2013 07:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.147 X-Spam-Level: X-Spam-Status: No, score=-104.147 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq4nRQuhqodW for ; Sun, 17 Feb 2013 07:01:18 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id C8FC421F8A89 for ; Sun, 17 Feb 2013 07:01:18 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.56636066; Sun, 17 Feb 2013 07:30:53 -0700 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Sun, 17 Feb 2013 10:00:54 -0500 From: "Livingood, Jason" Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9oOoA///SgoCAALKWAA== Date: Sun, 17 Feb 2013 15:00:53 +0000 Message-ID: <10229F86C86EB444898E629583FD417161653528@PACDCEXMB06.cable.comcast.com> In-Reply-To: <50F0DCC6-C4D7-44E6-8C2F-4A2E17DE33A1@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: <67E34F10E831624191BDEB9E256FC405@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Joe Abley , Ted Lemon Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:01:19 -0000 On 2/16/13 6:21 PM, "Joe Abley" wrote: >Jason: you didn't ask directly, but if the working group was polled to >determine support for adopting this document, I would say yes and >volunteer to review it. Thanks, Joe, for prodding me to be more explicit! ;-) Yes, that is indeed one of my questions: is this an interesting doc to the WG. I also listed the following open issues in the draft: 1. Determine whether RFC 2119 language should be used or not when describing things like the duration of a NTA. 2. Determine whether this is an individual I-D or a DNSOP WG I-D. 3. Determine whether this is Informational or a BCP. 4. The DNSOP WG should discuss whether a 1 day limit is reasonable, whether a different time (more or less than 1 day, such as 1 hour or 1 week) should be specified, or whether no time should be specified (just a recommendation that it SHOULD generally be limited to X). 5. The DNSOP WG should discuss how to assess when critical DNSSEC deployment mass has been achieved so that this is no longer a common practice. 6. Olafur Gudmundsson has suggested that we may want to consider whether a non validatable RRSIG should be returned or not when a NTA is in place. This was raised in the context of NLnet Labs' DNSSEC-Trigger, which apparently acts like forwarding stub-validator. He said, "The reason for this is if NTA strips signatures the stub-validator thinks it is under attack and may a) go into recursive mode to try to resolve the domain, getting to the right answer the long way. b) Give the wrong error "Missing signatures" instead of the real error. If all the validator does is not to set the AD bit for RRsets at and below the NTA, stub-resolvers (and cascading resolvers) should be happy." - Jason From jason_livingood@cable.comcast.com Sun Feb 17 07:18:25 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA08B21F86CD for ; Sun, 17 Feb 2013 07:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.302 X-Spam-Level: X-Spam-Status: No, score=-104.302 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkL58f7BjRVl for ; Sun, 17 Feb 2013 07:18:25 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 36D7C21F868D for ; Sun, 17 Feb 2013 07:18:25 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.56637020; Sun, 17 Feb 2013 07:48:20 -0700 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Sun, 17 Feb 2013 10:18:22 -0500 From: "Livingood, Jason" To: Paul Hoffman Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9il2AgACghoA= Date: Sun, 17 Feb 2013 15:18:21 +0000 Message-ID: <10229F86C86EB444898E629583FD417161653595@PACDCEXMB06.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:18:25 -0000 On 2/16/13 7:43 PM, "Paul Hoffman" wrote: >Ted's misunderstanding of what you are proposing is a valid one. You >don't actually say what a negative trust anchor is, and what it is a >trust anchor for, until section 7. Readers such as Ted (and myself!) will >have strong prejudices by then. Yeah, I can see why you would say that! I will move Section 7 up in the doc so that I define a NTA at the top. >I would want to see something in the Introduction saying something like: > >This document discusses trust anchors for DNSSEC. A "negative trust >anchor" is equivalent to a "regular" DNSSEC trust anchor for a particular >instance of a recursive validating resolver. A negative trust anchor is >quite different from regular DNSSEC trust anchors in that they are local, >temporary, and definitely not distributed by IANA. They are trust anchors >only for DNSSEC, not for PKIX. Great feedback! Adding text to the abstract and introduction, and used much of the text above with a few tweaks (so advise if I've gotten it wrong once you see it in -04). Thanks! Jason > >That should help set the tone for the following sections that say how to >use them, and then the much later sections on what they actually are. > >--Paul Hoffman From Ted.Lemon@nominum.com Sun Feb 17 07:20:00 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9A721F8AAD for ; Sun, 17 Feb 2013 07:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVdLm+XI4aOL for ; Sun, 17 Feb 2013 07:20:00 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 00D7B21F8AAC for ; Sun, 17 Feb 2013 07:19:59 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUSD1H9OCaDmwBz+6/tOzPUrQlNGwaIIC@postini.com; Sun, 17 Feb 2013 07:20:00 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9B3711B8457 for ; Sun, 17 Feb 2013 07:19:59 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8AF3F190043; Sun, 17 Feb 2013 07:19:59 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 07:19:59 -0800 From: Ted Lemon To: "Livingood, Jason" Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9oOoAgAAEzYCAAAMAgIABAnAAgAAGSwA= Date: Sun, 17 Feb 2013 15:19:59 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747492240@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> In-Reply-To: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:20:00 -0000 On Feb 17, 2013, at 9:57 AM, "Livingood, Jason" wrote: > A Negative Trust Anchor should IMO be locally configured and not rely upo= n > any external validation or sourcing for the Negative Trust Anchor(s). What's local? How does the local authority know to set a negative trust a= nchor? This seems very labor-intensive and failure-prone. Generally spe= aking, from what I've heard, when bad DNSSEC configurations happen, there's= a back-and-forth with the administrator of the broken zone. But this is = all third-hand, at best--if your experience has been different I would like= to hear about it. > It basically tells the recursive resolver to not perform (skip) DNSSEC > validation on a specific domain name for which a Negative Trust Anchor ha= s > been locally configured. Since it would be locally configured it should > not rely on the CA infrastructure at all, and all of the inherent issues > of that - or need to rely on certificate revocations and whatnot. So this is assuming that validation is occurring on a caching resolver run = by the provider, and that negative trust anchors simply won't have any effe= ct for hosts that do their own validation? > Also, if a domain has already messed up their DNSSEC signing operations, > it is unlikely they'd figure out a way to properly sign a Negative Trust > Anchor or anything else for that matter. I think this is wrong: the incidents I've heard of were mistakes, which res= ulted in teaching moments for the people who made them, which resulted in t= hem learning how to do it right. It's not like you're going to get a brok= en zone signature if you are completely ignorant, because if you are comple= tely ignorant you're not going to try to sign the zone. > I hope that helps, assuming of course that I understood the question > relating RFC5280 to this I-D. :-) It does help--thanks! On to your response to Joe: > 5. The DNSOP WG should discuss how to assess when critical DNSSEC > deployment mass has been achieved so that this is no longer a common > practice. Who cares? If you publish this, you have to assume that whatever you reco= mmend here is going to continue to be used well beyond its intended lifetim= e. Of course, e.g. Comcast will do the right thing, but this won't just b= e used by Comcast. I think that if you acknowledge that host-resident validating resolvers are= not going to support negative trust anchors, this is a non-problem, since = the rise of host-resident validating resolvers, which I think is inevitable= in the long run, will automatically obsolete this work. However, if you do decide to rely on this, it's probably worth talking abou= t what that obsolescence path will look like, since an NTA in the provider = caching resolver may produce different results on the host-resident validat= ing resolver, as you mention in point 6. From jason_livingood@cable.comcast.com Sun Feb 17 07:22:32 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1175321F86AB for ; Sun, 17 Feb 2013 07:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.418 X-Spam-Level: X-Spam-Status: No, score=-104.418 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2W40lBztCjx for ; Sun, 17 Feb 2013 07:22:31 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF1721F86A8 for ; Sun, 17 Feb 2013 07:22:31 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.56637201; Sun, 17 Feb 2013 07:52:28 -0700 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Sun, 17 Feb 2013 10:22:29 -0500 From: "Livingood, Jason" To: "dnsop@ietf.org" Thread-Topic: New draft-livingood-negative-trust-anchors-04 Thread-Index: AQHODSKYanCs4foReEyzUdtSJHXGsA== Date: Sun, 17 Feb 2013 15:22:28 +0000 Message-ID: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> In-Reply-To: <10229F86C86EB444898E629583FD4171616521A5@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_10229F86C86EB444898E629583FD417161653607PACDCEXMB06cabl_" MIME-Version: 1.0 Subject: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:22:32 -0000 --_000_10229F86C86EB444898E629583FD417161653607PACDCEXMB06cabl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Based on feedback yesterday on the list, I did a quick =9604 update, which = is now at https://datatracker.ietf.org/doc/draft-livingood-negative-trust-a= nchors/. The are seven open issues documented at the end of the I-D. But the most im= portant questions for this WG are: 1 =96 Is this worth consideration as a WG I-D or should it continue only as= an individual I-D? 2 =96 If the answer to #1 is that it should be a WG I-D, would you like a b= rief discussion of the open issues at IETF 86? Thanks! Jason --_000_10229F86C86EB444898E629583FD417161653607PACDCEXMB06cabl_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Based on feedback yesterday on the list, I did a quick =9604 update, w= hich is now at https://datatracker.ietf.org/doc/draft-living= ood-negative-trust-anchors/. 


The are seven open issues documented at the end of the I-D. But t= he most important questions for this WG are:
1 =96 Is this worth consideration as a WG I-D or should it continue on= ly as an individual I-D?
2 =96 If the answer to #1 is that it should be a WG I-D, would you lik= e a brief discussion of the open issues at IETF 86?

Thanks!
Jason


 --_000_10229F86C86EB444898E629583FD417161653607PACDCEXMB06cabl_-- From Ted.Lemon@nominum.com Sun Feb 17 07:25:48 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669C421F8A3E for ; Sun, 17 Feb 2013 07:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm9vPXfEADzS for ; Sun, 17 Feb 2013 07:25:48 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id A62B121F86A8 for ; Sun, 17 Feb 2013 07:25:47 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUSD2e7ZJ4prZkJl0wX4VSBLKnl4SyB5G@postini.com; Sun, 17 Feb 2013 07:25:47 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3B8931B8458 for ; Sun, 17 Feb 2013 07:25:47 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 32394190043; Sun, 17 Feb 2013 07:25:47 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 07:25:41 -0800 From: Ted Lemon To: "Livingood, Jason" Thread-Topic: [DNSOP] New draft-livingood-negative-trust-anchors-04 Thread-Index: AQHODSKfwYaT2g1xK0KMTwrNyoT7fZh+se0A Date: Sun, 17 Feb 2013 15:25:41 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747492287@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> In-Reply-To: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:25:48 -0000 On Feb 17, 2013, at 10:22 AM, "Livingood, Jason" wrote: > 1 =96 Is this worth consideration as a WG I-D or should it continue only = as an individual I-D? Yes, wg i-d. > 2 =96 If the answer to #1 is that it should be a WG I-D, would you like a= brief discussion of the open issues at IETF 86? No preference, since I have a conflicting session... :} From paul.hoffman@vpnc.org Sun Feb 17 07:31:35 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7816A21F8AD8 for ; Sun, 17 Feb 2013 07:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5sj6Xh+FPdZ for ; Sun, 17 Feb 2013 07:31:35 -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 F2DF321F8A50 for ; Sun, 17 Feb 2013 07:31:34 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1HFVTdw046681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Feb 2013 08:31:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <10229F86C86EB444898E629583FD417161653528@PACDCEXMB06.cable.comcast.com> Date: Sun, 17 Feb 2013 07:31:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0661DAC7-B084-41D9-8DE9-D5B0C8808970@vpnc.org> References: <10229F86C86EB444898E629583FD417161653528@PACDCEXMB06.cable.comcast.com> To: "Livingood, Jason" X-Mailer: Apple Mail (2.1499) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:31:35 -0000 On Feb 17, 2013, at 7:00 AM, "Livingood, Jason" = wrote: > 1. Determine whether RFC 2119 language should be used or not when > describing things like the duration of a NTA. I never understood why one would have 2119 language in an operational = document that says "here's a good idea for how to help your operations". = Well, other than "people have used that language before", which is kinda = an addictive response. > 2. Determine whether this is an individual I-D or a DNSOP WG I-D. It definitely seems related to DNS operations. > 3. Determine whether this is Informational or a BCP. Informational. Given that it is a new proposal, where's the "C"? > 4. The DNSOP WG should discuss whether a 1 day limit is reasonable, > whether a different time (more or less than 1 day, such as 1 hour or 1 > week) should be specified, or whether no time should be specified = (just a > recommendation that it SHOULD generally be limited to X). Or a different proposal: "Your operations staff needs to determine how = long is too long to allow a broken zone that could be also under attack, = and how short is too quick for your operations staff to reassess the = problem and remove the NTA; pick a value between those two".=20 > 5. The DNSOP WG should discuss how to assess when critical DNSSEC > deployment mass has been achieved so that this is no longer a common > practice. Start by saying "three years" and see what people think. > 6. Olafur Gudmundsson has suggested that we may want to consider = whether a > non validatable RRSIG should be returned or not when a NTA is in = place. > This was raised in the context of NLnet Labs' DNSSEC-Trigger, which > apparently acts like forwarding stub-validator. He said, "The reason = for > this is if NTA strips signatures the stub-validator thinks it is under > attack and may a) go into recursive mode to try to resolve the domain, > getting to the right answer the long way. b) Give the wrong error = "Missing > signatures" instead of the real error. If all the validator does is = not to > set the AD bit for RRsets at and below the NTA, stub-resolvers (and > cascading resolvers) should be happy." That sounds right. --Paul Hoffman= From jabley@hopcount.ca Sun Feb 17 07:35:50 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1092D21F8AA3 for ; Sun, 17 Feb 2013 07:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52KkbI5jAhHP for ; Sun, 17 Feb 2013 07:35:49 -0800 (PST) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2041E21F84D5 for ; Sun, 17 Feb 2013 07:35:49 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id 6so2078156qea.24 for ; Sun, 17 Feb 2013 07:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=k9UThxDIIRN6mU3Hpqo5OagkGT2OOvFJrkGWiSyW2Lc=; b=fjSlRAqdRo0a1lLBca6rn5AjzLN2JmtVSP4KLqUne4mtPLQdaO2JBFsww9FsGBI1lS QwOb+f9ZY8pmh8ihrUuCCqo5ZzjsXY453eewZWE7fN6e9d5Bl8q5KqkmjV3MFfE9hGlv 4ylPvIEtgvGghFE+k1MnfxRsRL5O3DWaMBxZg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=k9UThxDIIRN6mU3Hpqo5OagkGT2OOvFJrkGWiSyW2Lc=; b=Em0ivOMjBL0ZLjo2gE/stAxXDc0nJw3wc1YYAfTszKraK5i0ePfgTAeNDOUkXpYRcn XTWQoRujpVLI7+pJrNuVYnZdjqaMQh4gSD7fCffj/8nBOh5jfSq0NHIy6e/KlFIE6AuF nkPb3AT5M8Csrd02+2co7lqTTlWtf5P4861ITLCK3JsH59c7VQU4+/xYSzpYIFjnMxq7 Kj0QRu2QZP/QEtC23gH0AGDTAPiwAZOUjaOnyHroCHZLMhIqb3hYc7RZ6p+JgRK7IbfF 3uFMVX4mzvk81pOkN28oYRD3QgReNhhQgVTcwt5/6bUXGLB4id7ETdZGebGA/C+BfH+3 dGZQ== X-Received: by 10.49.62.42 with SMTP id v10mr3793410qer.2.1361115348582; Sun, 17 Feb 2013 07:35:48 -0800 (PST) Received: from ?IPv6:2001:4900:1042:100:2ce4:b9c3:632:4fd? ([2001:4900:1042:100:2ce4:b9c3:632:4fd]) by mx.google.com with ESMTPS id ec9sm240516qab.9.2013.02.17.07.35.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 07:35:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> Date: Sun, 17 Feb 2013 10:35:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <853770FE-4D9E-46B5-9420-1D4334942796@hopcount.ca> References: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> To: "Livingood, Jason" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmCvd+EvxdjqEZ8OsFr7nLYKVbtYik2NIAHDf5E3EbCQKwS7M51aXDVdci5n6GTgHxN7I2H Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:35:50 -0000 On 2013-02-17, at 09:57, "Livingood, Jason" = wrote: > A Negative Trust Anchor should IMO be locally configured and not rely = upon > any external validation or sourcing for the Negative Trust Anchor(s). I hear you, but I'm not sure why you think so. If I was running a farm of validators inside an ISP network and I didn't = already have my configuration control centralised and automated, being = able to publish a single zone for internal use which encapsulated the = policy does not seem like a bad option for keeping them all consistent. > Also, if a domain has already messed up their DNSSEC signing = operations, > it is unlikely they'd figure out a way to properly sign a Negative = Trust > Anchor or anything else for that matter. The use case here is not people who have messed up signing their zones = publishing an NTA; it's validator operators who need a convenient way to = share their validation policy. So, to spell it out: - hopcount.ca's signer explodes (or something else happens such that = hopcount.ca is badly signed) - since hopcount.ca is such a popular domain for Comcast customers, = Comcast DNS engineers take the time to discover that the validation = failure for that zone is in fact due to an operational problem and not = an attack - Comcast adds a hopcount.ca.nta.comcast.com zone, which is signed - Comcast's validators pick up the NTA from that zone and configure = themselves accordingly Precisely what mechanism is used for that last part needs discussion, if = people think that this kind of NTA distribution mechanism is worth = exploring. It could be a crude mechanism like "tail the validation = failure log, look up hopcount.ca.nta.comcast.com, if there's something = there reconfigure unbound accordingly" or it could be something more = integrated with the validator, so that unbound does the same work = internally. Thinking ahead (and making assumptions about how much disgust people are = feeling right now at this idea) I'd be in favour of an NTA being encoded = with some timers to help ensure that NTAs are temporary. Joe= From jason_livingood@cable.comcast.com Sun Feb 17 07:37:39 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD7921F865B for ; Sun, 17 Feb 2013 07:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=-1.444, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruAJAU3t+UiK for ; Sun, 17 Feb 2013 07:37:38 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 869DA21F8653 for ; Sun, 17 Feb 2013 07:37:38 -0800 (PST) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.43729134; Sun, 17 Feb 2013 10:25:26 -0500 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Sun, 17 Feb 2013 10:37:36 -0500 From: "Livingood, Jason" Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9oOoA///SgoCAAAMBAIAArp0AgABaH4D//7EZgA== Date: Sun, 17 Feb 2013 15:37:34 +0000 Message-ID: <10229F86C86EB444898E629583FD41716165368E@PACDCEXMB06.cable.comcast.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747492240@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: <1295E7ECA381B54A975AE633816E3040@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Ted Lemon Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:37:39 -0000 Inline below (and some proposed text for you to give feedback on). - Jason On 2/17/13 10:19 AM, "Ted Lemon" wrote: >On Feb 17, 2013, at 9:57 AM, "Livingood, Jason" > > wrote: >> A Negative Trust Anchor should IMO be locally configured and not rely >>upon >> any external validation or sourcing for the Negative Trust Anchor(s). > >What's local? How does the local authority know to set a negative trust >anchor? =20 The operator of a recursive resolver that is performing DNSSEC validation configures this on the local recursive resolver(s) they control/administer. >This seems very labor-intensive and failure-prone. It can be labor intensive, but failures in the configuration of the resolver carries the same risks as any other configuration change. We partially scripted it since we have found a need to configure NTAs more than a few times (meaning we don't manually touch each resolver but setting up and removing the NTA is not automatic based on validation failures). >Generally speaking, from what I've heard, when bad DNSSEC configurations >happen, there's a back-and-forth with the administrator of the broken >zone. But this is all third-hand, at best--if your experience has been >different I would like to hear about it. Yes, that's pretty much the case. It is a good learning experience for authoritative administrators. Only in a subset of such failures have we used a NTA, depending on the circumstances. >> It basically tells the recursive resolver to not perform (skip) DNSSEC >> validation on a specific domain name for which a Negative Trust Anchor >>has >> been locally configured. Since it would be locally configured it should >> not rely on the CA infrastructure at all, and all of the inherent issues >> of that - or need to rely on certificate revocations and whatnot. > >So this is assuming that validation is occurring on a caching resolver >run by the provider, and that negative trust anchors simply won't have >any effect for hosts that do their own validation? I suppose so - it is a policy on a caching resolver, though that could be operated by an ISP, DNS ASP, or enterprise. So if you have your own resolver and you are validating then it should not have any effect on you. >> Also, if a domain has already messed up their DNSSEC signing operations, >> it is unlikely they'd figure out a way to properly sign a Negative Trust >> Anchor or anything else for that matter. > >I think this is wrong: the incidents I've heard of were mistakes, which >resulted in teaching moments for the people who made them, which resulted >in them learning how to do it right. It's not like you're going to get >a broken zone signature if you are completely ignorant, because if you >are completely ignorant you're not going to try to sign the zone. They are definitely teachable moments. But a key concern is for the end users of a validating resolver, who may not know or care about what validation is and just know that they cannot access some domain. They blame the operator of the validating resolver (and impose costs upon them), rather that the authoritative domain. I hope that changes over time. >> I hope that helps, assuming of course that I understood the question >> relating RFC5280 to this I-D. :-) > >It does help--thanks! > >On to your response to Joe: > >> 5. The DNSOP WG should discuss how to assess when critical DNSSEC >> deployment mass has been achieved so that this is no longer a common >> practice. > >Who cares? =20 It was a question I received from a few folks in response to earlier versions, so I thought it worthy of flagging it for a discussion. >If you publish this, you have to assume that whatever you recommend here >is going to continue to be used well beyond its intended lifetime. >Of course, e.g. Comcast will do the right thing, but this won't just be >used by Comcast. Understood. >I think that if you acknowledge that host-resident validating resolvers >are not going to support negative trust anchors, this is a non-problem, >since the rise of host-resident validating resolvers, which I think is >inevitable in the long run, will automatically obsolete this work. Makes sense to me. So if I added very explicit text to the effect that "Negative Trust Anchors MUST NOT be used by host-based DNSSEC validating DNS resolvers; this practice only pertains to network-based DNS recursive resolvers that multiple hosts query." would that do it? - Jason >However, if you do decide to rely on this, it's probably worth talking >about what that obsolescence path will look like, since an NTA in the >provider caching resolver may produce different results on the >host-resident validating resolver, as you mention in point 6. > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop From joe.abley@icann.org Sun Feb 17 07:44:21 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C3721F8AD6 for ; Sun, 17 Feb 2013 07:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbblLmYJjF-4 for ; Sun, 17 Feb 2013 07:44:21 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDAE21F8AC3 for ; Sun, 17 Feb 2013 07:44:21 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Sun, 17 Feb 2013 07:44:20 -0800 From: Joe Abley To: "Livingood, Jason" Date: Sun, 17 Feb 2013 07:44:20 -0800 Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: Ac4NJaZ7UsG3ONOtRKyfLfkAPYvLqQ== Message-ID: <1685D5E2-E5DD-47D8-B267-54FCCDE8F613@icann.org> References: <10229F86C86EB444898E629583FD41716165368E@PACDCEXMB06.cable.comcast.com> In-Reply-To: <10229F86C86EB444898E629583FD41716165368E@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:44:21 -0000 On 2013-02-17, at 10:37, "Livingood, Jason" wrote: > Makes sense to me. So if I added very explicit text to the effect that > "Negative Trust Anchors MUST NOT be used by host-based DNSSEC validating > DNS resolvers; this practice only pertains to network-based DNS recursive > resolvers that multiple hosts query." would that do it? If there was a way to publish NTAs in the DNS, I would think unbound runnin= g on my laptop could behave the same way as unbound running on a stack of s= ervers in a data centre. Whether or not I configure my laptop-resident unbo= und to look for such NTAs is surely up to me. I don't really understand the motivation for the MUST NOT above. Joe= From Ted.Lemon@nominum.com Sun Feb 17 07:49:08 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B822721F8B04 for ; Sun, 17 Feb 2013 07:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnG76nhQFYOX for ; Sun, 17 Feb 2013 07:49:08 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id DB2D821F8AC3 for ; Sun, 17 Feb 2013 07:49:04 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUSD78IXdGKeEFiAl83QyFKRp5DFX+5ft@postini.com; Sun, 17 Feb 2013 07:49:04 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 43B61F8030 for ; Sun, 17 Feb 2013 07:49:04 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 39E80190043; Sun, 17 Feb 2013 07:49:04 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 07:48:52 -0800 From: Ted Lemon To: Joe Abley Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9oOoAgAAEzYCAAAMAgIABAnAAgAAKt4CAAAOmgA== Date: Sun, 17 Feb 2013 15:48:51 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074749235A@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> <853770FE-4D9E-46B5-9420-1D4334942796@hopcount.ca> In-Reply-To: <853770FE-4D9E-46B5-9420-1D4334942796@hopcount.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <1FA334638FCF854D8E286E5EF08D0F91@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" , "Livingood, Jason" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:49:08 -0000 On Feb 17, 2013, at 10:35 AM, Joe Abley wrote: > - hopcount.ca's signer explodes (or something else happens such that hopc= ount.ca is badly signed) > - since hopcount.ca is such a popular domain for Comcast customers, Comca= st DNS engineers take the time to discover that the validation failure for = that zone is in fact due to an operational problem and not an attack > - Comcast adds a hopcount.ca.nta.comcast.com zone, which is signed > - Comcast's validators pick up the NTA from that zone and configure thems= elves accordingly Yes. Although I think you can just sign nta.comcast.com, and have hopcoun= t.ca.nta.comcast.com be some record in that zone, rather than making it an = SOA. For extra credit, you could even make it a ZSK that could be used to v= alidate the zone, in cases where the ZSK rollover was flubbed, but the zone= is in fact signed and the ZSK it was signed with is known, and known to be= good. From Ted.Lemon@nominum.com Sun Feb 17 07:54:10 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CF121F86B3 for ; Sun, 17 Feb 2013 07:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpz60lHQCM7J for ; Sun, 17 Feb 2013 07:54:09 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 3A91721F8A45 for ; Sun, 17 Feb 2013 07:54:09 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUSD9IPIjsfmNKvHK8C4HOc1eE5H8qosa@postini.com; Sun, 17 Feb 2013 07:54:09 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CA8F1F8031 for ; Sun, 17 Feb 2013 07:54:08 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C07C2190043; Sun, 17 Feb 2013 07:54:08 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 07:54:03 -0800 From: Ted Lemon To: "Livingood, Jason" Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9oOoAgAAEzYCAAAMAgIABAnAAgAAGSwCAAATrAIAABJoA Date: Sun, 17 Feb 2013 15:54:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474923B4@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD41716165368E@PACDCEXMB06.cable.comcast.com> In-Reply-To: <10229F86C86EB444898E629583FD41716165368E@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <0914FDE82B79184EA28864C8BE1542FF@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:54:10 -0000 On Feb 17, 2013, at 10:37 AM, "Livingood, Jason" wrote: >>> Also, if a domain has already messed up their DNSSEC signing operations= , >>> it is unlikely they'd figure out a way to properly sign a Negative Trus= t >>> Anchor or anything else for that matter. >>=20 >> I think this is wrong: the incidents I've heard of were mistakes, which >> resulted in teaching moments for the people who made them, which resulte= d >> in them learning how to do it right. It's not like you're going to get >> a broken zone signature if you are completely ignorant, because if you >> are completely ignorant you're not going to try to sign the zone. >=20 > They are definitely teachable moments. But a key concern is for the end > users of a validating resolver, who may not know or care about what > validation is and just know that they cannot access some domain. They > blame the operator of the validating resolver (and impose costs upon > them), rather that the authoritative domain. I hope that changes over tim= e. So maybe a better way to state your point at the top would be that setting = up the NTA is something that validating resolver operators do, possibly in = cooperation with the operators of the zones requiring the NTA, because this= is what's expedient, and NTAs are all about what's expedient. :) > Makes sense to me. So if I added very explicit text to the effect that > "Negative Trust Anchors MUST NOT be used by host-based DNSSEC validating > DNS resolvers; this practice only pertains to network-based DNS recursive > resolvers that multiple hosts query." would that do it? I think that's a valid thing to say, but what I'm more concerned about is s= pecifically saying what would be different in a response from a validating = resolver that implements NTAs in the case of a zone with an NTA, versus a c= aching resolver that does not validate, for the same broken zone. From jabley@hopcount.ca Sun Feb 17 08:04:16 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C0421F8B0B for ; Sun, 17 Feb 2013 08:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.929 X-Spam-Level: X-Spam-Status: No, score=-99.929 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNJaAz-tT7bv for ; Sun, 17 Feb 2013 08:04:15 -0800 (PST) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6564C21F8AEA for ; Sun, 17 Feb 2013 08:04:15 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id l29so2524288iag.17 for ; Sun, 17 Feb 2013 08:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=4zbL51o2Za/cTrxdXq0OxtGcwXf5EHqwq/7FqfrMr9c=; b=XfD9LYgWgqIx8nJNQz+pzPZshAyTTVZFIumGiFNKLF5+3SL3a0sl4z9HpJ7IOHNdW/ WtmOf4PkAThj13zlWMdZkwE8V2yKs30ibmhcUC3Yg6teSet/ZtNa6wom8IM4MeRfztKT U7RSlmDBoilwDpwLST4uTF+igd4VXROjt+uq8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=4zbL51o2Za/cTrxdXq0OxtGcwXf5EHqwq/7FqfrMr9c=; b=l1aqfHjPdRnJ2EuoXzv8KVMTN9AiY9sSihfIf+49La3uKvSy0NAHZAV9Kei8bgAq2+ ngIF1DWRDo25NIabeWUw3fxek0zTsCHtrlnDbmCfpqipgVAeeKp3mftIJosiCINEH+PB mCM4DvkORRpH9USDZVJ6+5Io2s8g/2lwTfUPN5+l7kNfkACZapDiqb6M6TAzdsEDe3L6 1ofek4WfO6zOlPMNKlQXDIiggMNzLZzykq4qiZm1V2uptvTNnXQErH6EPDmbYHZqfFgE JB4+OwlMJvkAgAROb8rwR9po0geETIcos4zzDK5+55hu02fSj/MdgA/7N8GNykM2+QML VWiw== X-Received: by 10.50.212.74 with SMTP id ni10mr5286315igc.60.1361117054082; Sun, 17 Feb 2013 08:04:14 -0800 (PST) Received: from [199.212.90.61] ([199.212.90.61]) by mx.google.com with ESMTPS id z1sm7418542igc.1.2013.02.17.08.04.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 08:04:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074749235A@mbx-01.win.nominum.com> Date: Sun, 17 Feb 2013 11:04:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> <853770FE-4D9E-46B5-9420-1D4334942796@hopcount.ca> <8D23D4052ABE7A4490E77B1A012B63074749235A@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlgJVgSOc3VG6CStV3SE6AnLGmzF8N1zc9fuRTFR87Ir0VbmZi1w3VyGgSdQeqIm74k9xA3 Cc: "dnsop@ietf.org WG" , "Livingood, Jason" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 16:04:16 -0000 On 2013-02-17, at 10:48, Ted Lemon wrote: > On Feb 17, 2013, at 10:35 AM, Joe Abley wrote: >> - hopcount.ca's signer explodes (or something else happens such that = hopcount.ca is badly signed) >> - since hopcount.ca is such a popular domain for Comcast customers, = Comcast DNS engineers take the time to discover that the validation = failure for that zone is in fact due to an operational problem and not = an attack >> - Comcast adds a hopcount.ca.nta.comcast.com zone, which is signed >> - Comcast's validators pick up the NTA from that zone and configure = themselves accordingly >=20 > Yes. Although I think you can just sign nta.comcast.com, and have = hopcount.ca.nta.comcast.com be some record in that zone, rather than = making it an SOA. Yes, that's the kind of thing I had in mind. > For extra credit, you could even make it a ZSK that could be used to = validate the zone, in cases where the ZSK rollover was flubbed, but the = zone is in fact signed and the ZSK it was signed with is known, and = known to be good. That sounds fancy! Joe= From Ted.Lemon@nominum.com Sun Feb 17 08:07:08 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C2C21F8B1A for ; Sun, 17 Feb 2013 08:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDP3pSrblkTl for ; Sun, 17 Feb 2013 08:07:06 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 61B8721F8AEA for ; Sun, 17 Feb 2013 08:07:01 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUSEAIwJeWdKmYYVdv0SZ1JwbuP4JjYf0@postini.com; Sun, 17 Feb 2013 08:07:01 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 75D00F803B for ; Sun, 17 Feb 2013 08:06:59 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6D139190043; Sun, 17 Feb 2013 08:06:59 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 08:06:59 -0800 From: Ted Lemon To: Joe Abley Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9oOoAgAAEzYCAAAMAgIABAnAAgAAGSwCAAATrAIAAAeQAgAAGUoA= Date: Sun, 17 Feb 2013 16:06:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747492437@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD41716165368E@PACDCEXMB06.cable.comcast.com> <1685D5E2-E5DD-47D8-B267-54FCCDE8F613@icann.org> In-Reply-To: <1685D5E2-E5DD-47D8-B267-54FCCDE8F613@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <10B157F21424DA48BD45FE0C607EC36B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" , "Livingood, Jason" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 16:07:08 -0000 On Feb 17, 2013, at 10:44 AM, Joe Abley wrote: > If there was a way to publish NTAs in the DNS, I would think unbound runn= ing on my laptop could behave the same way as unbound running on a stack of= servers in a data centre. Whether or not I configure my laptop-resident un= bound to look for such NTAs is surely up to me. >=20 > I don't really understand the motivation for the MUST NOT above. If this is informational, then it doesn't make sense to say MUST NOT anyway= . I think there could be a debate: is there a way to subscribe my resolve= r to the ISP's NTA zone, or not? The advantage of subscribing is that I get information that helps me to dea= l with brokenness. The disadvantage is that I am configuring my validatin= g resolver so that a bad guy who works for my ISP could arrange to send me = bad data. I think it would be perfectly fine to just document this issue = in the security considerations section. It's going to require a positive = action to configure my host's validating resolver to do this anyway, which = most users will not know how to do. It's also possibly worth mentioning s= ocial engineering attacks on the end user as a risk if such a capability is= present in a host-based validating resolver. From paul.hoffman@vpnc.org Sun Feb 17 11:32:25 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C39921F845E for ; Sun, 17 Feb 2013 11:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a9pDW+l-XhL for ; Sun, 17 Feb 2013 11:32:24 -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 D055421F8235 for ; Sun, 17 Feb 2013 11:32:24 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1HJWJ62052157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Feb 2013 12:32:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <10229F86C86EB444898E629583FD41716165368E@PACDCEXMB06.cable.comcast.com> Date: Sun, 17 Feb 2013 11:32:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <45249D96-CC70-4C75-9DFB-A250B2AEB796@vpnc.org> References: <10229F86C86EB444898E629583FD41716165368E@PACDCEXMB06.cable.comcast.com> To: "Livingood, Jason" X-Mailer: Apple Mail (2.1499) Cc: "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 19:32:25 -0000 On Feb 17, 2013, at 7:37 AM, "Livingood, Jason" = wrote: > Makes sense to me. So if I added very explicit text to the effect that > "Negative Trust Anchors MUST NOT be used by host-based DNSSEC = validating > DNS resolvers; this practice only pertains to network-based DNS = recursive > resolvers that multiple hosts query." would that do it? Please: no. If I have local validation turned on for my own host, and = there is a site I need to get to but it has broken signatures, I would = like a GUI that says "this zone has broken signatures; ignore validation = failures for 60 minutes?". There is no operational difference between a host that validates and a = validating recursive resolver that has exactly one customer that is = looking at the one broken zone. --Paul Hoffman= From Ted.Lemon@nominum.com Sun Feb 17 11:51:11 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95BF21F8AA6 for ; Sun, 17 Feb 2013 11:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGQ2S8RLSYI3 for ; Sun, 17 Feb 2013 11:51:10 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACB121F8A8A for ; Sun, 17 Feb 2013 11:51:10 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUSE0qPSsMOL8NGACyjmJe1JKoKLt2kL+@postini.com; Sun, 17 Feb 2013 11:51:10 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 37DFC1B8582 for ; Sun, 17 Feb 2013 11:51:04 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2C66B190043; Sun, 17 Feb 2013 11:51:04 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 11:50:58 -0800 From: Ted Lemon To: Paul Hoffman Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9oOoAgAAEzYCAAAMAgIABAnAAgAAGSwCAAATrAIAAQZeAgAAFNAA= Date: Sun, 17 Feb 2013 19:50:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747492824@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD41716165368E@PACDCEXMB06.cable.comcast.com> <45249D96-CC70-4C75-9DFB-A250B2AEB796@vpnc.org> In-Reply-To: <45249D96-CC70-4C75-9DFB-A250B2AEB796@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" , "Livingood, Jason" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 19:51:11 -0000 On Feb 17, 2013, at 2:32 PM, Paul Hoffman wrote: > Please: no. If I have local validation turned on for my own host, and the= re is a site I need to get to but it has broken signatures, I would like a = GUI that says "this zone has broken signatures; ignore validation failures = for 60 minutes?". Training users to bypass security. This is extremely bad security UI desi= gn. MUST NOT level bad. How does the user distinguish between "attack" = and "mistake"? I don't even know how I would do it, and I have at least s= ome vague understanding of the security model of DNSSEC, which is a genuine= rarity. What's the point of having a validating resolver if validation c= an be skipped with a click? Having a configurable negative trust anchor zone isn't as good as having DN= SSEC that can be counted on to always be configured correctly, but it's a l= ot better than a UI like this. From paul.hoffman@vpnc.org Sun Feb 17 12:34:27 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8C521F89CC for ; Sun, 17 Feb 2013 12:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CODUASq3UxkK for ; Sun, 17 Feb 2013 12:34:27 -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 DF87221F8996 for ; Sun, 17 Feb 2013 12:34:26 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1HKYMhG053517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Feb 2013 13:34:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747492824@mbx-01.win.nominum.com> Date: Sun, 17 Feb 2013 12:34:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <469DCADA-83FA-4A1F-AC66-EC3E217A3759@vpnc.org> References: <10229F86C86EB444898E629583FD41716165368E@PACDCEXMB06.cable.comcast.com> <45249D96-CC70-4C75-9DFB-A250B2AEB796@vpnc.org> <8D23D4052ABE7A4490E77B1A012B630747492824@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: "dnsop@ietf.org WG" , "Livingood, Jason" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 20:34:27 -0000 On Feb 17, 2013, at 11:50 AM, Ted Lemon wrote: > On Feb 17, 2013, at 2:32 PM, Paul Hoffman > wrote: >> Please: no. If I have local validation turned on for my own host, and = there is a site I need to get to but it has broken signatures, I would = like a GUI that says "this zone has broken signatures; ignore validation = failures for 60 minutes?". >=20 > Training users to bypass security. This is extremely bad security UI = design. MUST NOT level bad. How does the user distinguish between = "attack" and "mistake"? I don't even know how I would do it, and I = have at least some vague understanding of the security model of DNSSEC, = which is a genuine rarity. What's the point of having a validating = resolver if validation can be skipped with a click? Because I am my own operator. Yes, you want to be my nanny; no, I didn't = ask you to be. > Having a configurable negative trust anchor zone isn't as good as = having DNSSEC that can be counted on to always be configured correctly, = but it's a lot better than a UI like this. That would work for me too, but not "you're a host, so you cannot use = negative trust anchors", which is what Jason's proposed text said.= From kurtis@kurtis.pp.se Sun Feb 17 14:38:06 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B091321F8B6D for ; Sun, 17 Feb 2013 14:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ygazeu-pHJ8H for ; Sun, 17 Feb 2013 14:38:01 -0800 (PST) Received: from eckero.kurtis.pp.se (eckero.kurtis.pp.se [194.15.141.107]) by ietfa.amsl.com (Postfix) with ESMTP id 25FF621F8233 for ; Sun, 17 Feb 2013 14:38:01 -0800 (PST) Received: from [10.71.15.176] (unknown [111.223.96.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by eckero.kurtis.pp.se (Postfix) with ESMTPSA id 6B09D2E03B; Sun, 17 Feb 2013 23:37:29 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_A432A39E-E1AC-4D11-A3BC-5074C0C9C29C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Lindqvist Kurt Erik In-Reply-To: <20130209204558.GA12175@x28.adm.denic.de> Date: Sun, 17 Feb 2013 23:37:20 +0100 Message-Id: <66F0C06D-6560-4F96-9F76-6B0851235AA0@kurtis.pp.se> References: <20130209204558.GA12175@x28.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1499) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 22:38:06 -0000 --Apple-Mail=_A432A39E-E1AC-4D11-A3BC-5074C0C9C29C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 9 feb 2013, at 21:45, Peter Koch wrote: > the topic of AS112 has been addresses in the DNSOP WG resulting in > RFCs 6304 and 6305 and is also related to 'local zones' as described in > RFC 6303. > > The question of extending AS112 service to IPv6 (as in "transport") > as well as the maintainability of the list of zones served by AS112 > systems has been discussed before. We have a proposal in > > draft-wkumari-dnsop-omniscient-as112-01.txt > > to make the AS112 served zone set extendable in the future. > Please read the draft and state whether you think this is something > the WG - and you in particular - would want to work on. We'd like to > find five volunteers for thorough document reviews to support the > draft going forward - provided the overall response is positive. Me too supports adoption! Best regards, - kurtis - Best regards, - kurtis - --Apple-Mail=_A432A39E-E1AC-4D11-A3BC-5074C0C9C29C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iEYEARECAAYFAlEhW6UACgkQAFdZ6xrc/t6UIACdGgYR9vnXHa2Ni8LI4R2I9DK9 j2AAn2O2YyHTkE3sPWn7jdsaGTB2MTpw =DNQi -----END PGP SIGNATURE----- --Apple-Mail=_A432A39E-E1AC-4D11-A3BC-5074C0C9C29C-- From Ted.Lemon@nominum.com Sun Feb 17 14:51:54 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A234321F8849 for ; Sun, 17 Feb 2013 14:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qlz7sYbO-lN for ; Sun, 17 Feb 2013 14:51:53 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 15C7321F868B for ; Sun, 17 Feb 2013 14:51:52 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUSFfCGqvNQAaCuHbRGdHkkjmE4VB0GmR@postini.com; Sun, 17 Feb 2013 14:51:53 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 916C31B82B5 for ; Sun, 17 Feb 2013 14:51:52 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8646B190043; Sun, 17 Feb 2013 14:51:52 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 14:51:40 -0800 From: Ted Lemon To: Paul Hoffman Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9oOoAgAAEzYCAAAMAgIABAnAAgAAGSwCAAATrAIAAQZeAgAAFNACAAAwhgIAAJlyA Date: Sun, 17 Feb 2013 22:51:40 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747492991@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD41716165368E@PACDCEXMB06.cable.comcast.com> <45249D96-CC70-4C75-9DFB-A250B2AEB796@vpnc.org> <8D23D4052ABE7A4490E77B1A012B630747492824@mbx-01.win.nominum.com> <469DCADA-83FA-4A1F-AC66-EC3E217A3759@vpnc.org> In-Reply-To: <469DCADA-83FA-4A1F-AC66-EC3E217A3759@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" , "Livingood, Jason" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 22:51:54 -0000 On Feb 17, 2013, at 3:34 PM, Paul Hoffman wrote: > Because I am my own operator. Yes, you want to be my nanny; no, I didn't = ask you to be. I don't want to be _your_ nanny. But you are one of the other two dozen p= eople in the world with some inkling of how DNSSEC works. You aren't the = person that I mean to protect when I say this UI MUST NOT happen. > That would work for me too, but not "you're a host, so you cannot use neg= ative trust anchors", which is what Jason's proposed text said. Hence the discussion. But it is worth paying attention to the way that th= is solution breaks the assumptions of the DNSSEC security model. In the c= ase of a validating resolver at the ISP level, it doesn't, because if you'r= e trusting a validating resolver without a secure path to it, you're basica= lly just looking for protection against cache spoofing. If you have a validating resolver on your host, this gives you much stronge= r security guarantees; if you then enable negative trust anchors from an IS= P list, you are back to the external validator level of security, which is = a potentially _substantial_ downgrade, depending on what kind of security y= our provider offers. From Ralf.Weber@nominum.com Sun Feb 17 18:59:39 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBD321F8B14 for ; Sun, 17 Feb 2013 18:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rw0-xXEiySQ for ; Sun, 17 Feb 2013 18:59:38 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 75FE921F8B11 for ; Sun, 17 Feb 2013 18:59:38 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUSGZGuIJbTaGArjdSnh0G0zmGwGr/twx@postini.com; Sun, 17 Feb 2013 18:59:38 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F1608F8041 for ; Sun, 17 Feb 2013 18:59:37 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DDDB9190043; Sun, 17 Feb 2013 18:59:37 -0800 (PST) (envelope-from Ralf.Weber@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 18:59:31 -0800 From: Ralf Weber To: Joe Abley Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODYP4XsFDN6doMkKUwS0vL/BrZw== Date: Mon, 18 Feb 2013 02:59:30 +0000 Message-ID: <4359B40FE8E82C4BA840D73427B8A45847F064F2@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> <853770FE-4D9E-46B5-9420-1D4334942796@hopcount.ca> In-Reply-To: <853770FE-4D9E-46B5-9420-1D4334942796@hopcount.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" , "Livingood, Jason" , Ted Lemon Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 02:59:39 -0000 Moin! On 17.02.2013, at 16:35, Joe Abley wrote: > The use case here is not people who have messed up signing their zones pu= blishing an NTA; it's validator operators who need a convenient way to shar= e their validation policy. >=20 > So, to spell it out: >=20 > - hopcount.ca's signer explodes (or something else happens such that hopc= ount.ca is badly signed) > - since hopcount.ca is such a popular domain for Comcast customers, Comca= st DNS engineers take the time to discover that the validation failure for = that zone is in fact due to an operational problem and not an attack > - Comcast adds a hopcount.ca.nta.comcast.com zone, which is signed > - Comcast's validators pick up the NTA from that zone and configure thems= elves accordingly That sounds like a negative DLV to me. I think DLV was a bad idea and I don= 't think this is a good idea either when you are crossing organization boun= daries. I guess it is ok when used inside a provider as mechanism to distri= bute NTA, but then it doesn't need be in that document. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400=20 Redwood City, California 94063 ralf.weber@nominum.com From jabley@hopcount.ca Sun Feb 17 19:04:05 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046E521F8B1E for ; Sun, 17 Feb 2013 19:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkm8aEdcJ9S6 for ; Sun, 17 Feb 2013 19:04:01 -0800 (PST) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 65A0521F8B11 for ; Sun, 17 Feb 2013 19:04:01 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id e16so4459836iaa.40 for ; Sun, 17 Feb 2013 19:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=8HbJ86cjx+uHQg2+wD+8LBKerDQKoOaHytrpHtlhONw=; b=RrljoI2Dq5NIqierOskHiajTs/QzHGHMTw2ToxqMFlueOvsDnEX9+kBVqSfSvVEOmJ orkscQyxKX90xliLEA8yIgyyqryw3eItrE6OcTSE/Z0zLCY09/5t687G8AEN2btoX4tJ 0NEAfdIb/jL355sgaKpyvnd96N8rCgbWv6jgs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8HbJ86cjx+uHQg2+wD+8LBKerDQKoOaHytrpHtlhONw=; b=XmFXF0v5TR53hjGXz+XHelg4/lBLC7uYPZqoqdvtpzAwA3kC0Sa4fJzwREM8TJMRvm lBtXv0y+Tp01NvMGHj1c73dyeb7IvYACXMC0aH6wmqF9vXF9yJ43ZRkUOeo00YPL1IPK ZqvDtTtoRT4xFnmI662MNi4MED8T7qnJfk0YIFtbKsdgb1bLdLe5KS1FtBF6Y8vqk/ip H9iPUIKYLjr3WlrbyM0/DXE9WRemyQzzhCVj0PYHjsb0sv8gTzmpUlB95AYs0781h+9v VLEQlKjcMDcvDQqkd2pK0ZzhwTyFg/a+/9jjOaGE0Pcq/0Ja/Ya/F9lnrhV8KvYxhF2x P51Q== X-Received: by 10.50.56.141 with SMTP id a13mr6099667igq.24.1361156640952; Sun, 17 Feb 2013 19:04:00 -0800 (PST) Received: from [10.203.136.120] ([209.226.201.228]) by mx.google.com with ESMTPS id dm10sm7517976igb.3.2013.02.17.19.03.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 19:04:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <4359B40FE8E82C4BA840D73427B8A45847F064F2@mbx-01.win.nominum.com> Date: Sun, 17 Feb 2013 22:03:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> <853770FE-4D9E-46B5-9420-1D4334942796@hopcount.ca> <4359B40FE8E82C4BA840D73427B8A45847F064F2@mbx-01.win.nominum.com> To: Ralf Weber X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkH6Fn6TGJwzwhf2KEPQ0CqRBL5HNqwJLgJ1k/VdK79GM7e2xsG94058TSwMf0+uGqZMiJF Cc: "dnsop@ietf.org WG" , Jason Livingood , Ted Lemon Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 03:04:05 -0000 On 2013-02-17, at 21:59, Ralf Weber wrote: > That sounds like a negative DLV to me. I think DLV was a bad idea and = I don't think this is a good idea either when you are crossing = organization boundaries. I guess it is ok when used inside a provider as = mechanism to distribute NTA, but then it doesn't need be in that = document. You could compare it to DNS RBLs, too. You don't have to like it for it = to exist (you don't have to use it.) It doesn't need to be universally = liked to be useful. I think the problem that validation is expensive to turn on for ISPs = (and has value which is difficult to explain to customers) is a real = one. I think we want more validation to happen. Making it cheaper to = turn on validation seems important. Joe From Ralf.Weber@nominum.com Sun Feb 17 19:19:05 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC88D21F8B64 for ; Sun, 17 Feb 2013 19:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOV17wNXhbPX for ; Sun, 17 Feb 2013 19:19:05 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id EE3AE21F8B78 for ; Sun, 17 Feb 2013 19:19:04 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUSGdqMJq/nKoTzImZoTUqlg5F4xx5pdD@postini.com; Sun, 17 Feb 2013 19:19:05 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 982E01B8491 for ; Sun, 17 Feb 2013 19:19:04 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8E3DE190043; Sun, 17 Feb 2013 19:19:04 -0800 (PST) (envelope-from Ralf.Weber@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 19:19:04 -0800 From: Ralf Weber To: Joe Abley Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODYP4XsFDN6doMkKUwS0vL/BrZ5h/dEWAgAAEMYA= Date: Mon, 18 Feb 2013 03:19:04 +0000 Message-ID: <4359B40FE8E82C4BA840D73427B8A45847F0667A@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> <853770FE-4D9E-46B5-9420-1D4334942796@hopcount.ca> <4359B40FE8E82C4BA840D73427B8A45847F064F2@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" , Jason Livingood , Ted Lemon Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 03:19:06 -0000 Moin! On 18.02.2013, at 04:03, Joe Abley wrote: > I think the problem that validation is expensive to turn on for ISPs (and= has value which is difficult to explain to customers) is a real one. I thi= nk we want more validation to happen. Making it cheaper to turn on validati= on seems important. I fully agree on this, which is why I support this draft. However to achiev= e that goal (making it easier for ISPs to implement DNSSEC) I don't think i= t is necessary to specify how NTA will be distributed. If you think it is i= mportant to have a vendor independent way of distributing NTA this might be= a second step, however it's usage should be very limited and not crossing = organizational boundaries. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400=20 Redwood City, California 94063 ralf.weber@nominum.com From jabley@hopcount.ca Sun Feb 17 19:29:04 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB35E21F8B71 for ; Sun, 17 Feb 2013 19:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZxdzCMyMVTR for ; Sun, 17 Feb 2013 19:29:04 -0800 (PST) Received: from mail-ia0-x22f.google.com (ia-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF0821F8B46 for ; Sun, 17 Feb 2013 19:29:04 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id r4so4771910iaj.6 for ; Sun, 17 Feb 2013 19:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=eO7E8ZspruFT8wtHi7QsClH7Lc7IdWlxEaxe1DHKja0=; b=oFyuBQB1HeoIeCFYsI2VlW6rcRuPjw7vepFGZmPvxucnepaQzAy/7EPuhqd3fv42Jf QP7eQo7pD5iqRLYc2xf801qp4QcneSxDeBvQ33D+/xnWVmNEwl2VvbOf+VwyE0iCa1+E dbdruQFcbEmGeeQRU2tiBcfzczGxIN2BZGLeQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=eO7E8ZspruFT8wtHi7QsClH7Lc7IdWlxEaxe1DHKja0=; b=Izr1JpP1q8ebAPxfyGpeR9LhwnkWQfE72f3eZwQZQfnWbgFQpDh3um7jpHZvTIlVd/ MG6faVC/Q/060qR4BPfRmxvZLCImPhcVdI24mlXNtGzVMXgadvyND04eJUMqYYQ2u9Ov I1SV7LofA3srd9BaRPzA6hd6sE/0c+pKaUjcx0Xc5d3jimMPcZkR1BDRmezKG2Ttj3RH P17LqvGIfEpbysZKVGyvR2PRcAQQDkCp00KtRlicIczF8JnT5MqgEdHtUOX0UTExGdyk BAv7YbPVlMpk8C5TwyS2E2PbCmJjKqMWON+rUv01eR2yZ4So1FmCbWPk2o9otmvxuiEo ghkQ== X-Received: by 10.50.12.201 with SMTP id a9mr5970149igc.10.1361158143722; Sun, 17 Feb 2013 19:29:03 -0800 (PST) Received: from [10.203.136.120] ([209.226.201.228]) by mx.google.com with ESMTPS id bp7sm7532651igb.4.2013.02.17.19.29.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 19:29:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <4359B40FE8E82C4BA840D73427B8A45847F0667A@mbx-01.win.nominum.com> Date: Sun, 17 Feb 2013 22:29:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> <853770FE-4D9E-46B5-9420-1D4334942796@hopcount.ca> <4359B40FE8E82C4BA840D73427B8A45847F064F2@mbx-01.win.nominum.com> <4359B40FE8E82C4BA840D73427B8A45847F0667A@mbx-01.win.nominum.com> To: Ralf Weber X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlSSV+nOV4RvAu/dBWCDcQ3HEepydqzwAnWh1noWaXyj+zZbWCjygo4e/E6nR7PCDa1vQPt Cc: "dnsop@ietf.org WG" , Jason Livingood , Ted Lemon Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 03:29:04 -0000 Hi Ralf, On 2013-02-17, at 22:19, Ralf Weber wrote: > I fully agree on this, which is why I support this draft. However to = achieve that goal (making it easier for ISPs to implement DNSSEC) I = don't think it is necessary to specify how NTA will be distributed. If = you think it is important to have a vendor independent way of = distributing NTA this might be a second step, however it's usage should = be very limited and not crossing organizational boundaries. This is getting a bit tangential, but why is it important for NTA = distribution not to cross organisational boundaries? If a standard distribution mechanism existed, how do you imagine a = limited scope could be enforced? Joe= From Ralf.Weber@nominum.com Sun Feb 17 19:49:07 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEB421F8B2B for ; Sun, 17 Feb 2013 19:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIBmFH5prVsN for ; Sun, 17 Feb 2013 19:49:06 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 87DD321F8B11 for ; Sun, 17 Feb 2013 19:49:03 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUSGkr7xzqw71vTK+X5wm0dxXBXt1xCR7@postini.com; Sun, 17 Feb 2013 19:49:03 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CF9FDF8040 for ; Sun, 17 Feb 2013 19:49:02 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C2E94190043; Sun, 17 Feb 2013 19:49:02 -0800 (PST) (envelope-from Ralf.Weber@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 19:48:56 -0800 From: Ralf Weber To: Joe Abley Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODYP4XsFDN6doMkKUwS0vL/BrZ5h/dEWAgAAEMYCAAALPAIAABYsA Date: Mon, 18 Feb 2013 03:48:55 +0000 Message-ID: <4359B40FE8E82C4BA840D73427B8A45847F0681D@mbx-01.win.nominum.com> References: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> <853770FE-4D9E-46B5-9420-1D4334942796@hopcount.ca> <4359B40FE8E82C4BA840D73427B8A45847F064F2@mbx-01.win.nominum.com> <4359B40FE8E82C4BA840D73427B8A45847F0667A@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <3CA8BC509B5ABF4AA89A0EC2C8DB8488@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" , Jason Livingood , Ted Lemon Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 03:49:07 -0000 Moin! On 18.02.2013, at 04:29, Joe Abley wrote: > This is getting a bit tangential, but why is it important for NTA distrib= ution not to cross organisational boundaries? Because I and guess ISPs also don't want somebody to mess with the resoluti= on answers of their resolver. If I screw up I am responsible, but if anothe= r third party that probably I don't have a contract with screws up who is r= esponsible. As an admin of DNS Services at an ISP you will get that questio= n if something goes bad, and that is why I didn't like the DLV approach. =20 > If a standard distribution mechanism existed, how do you imagine a limite= d scope could be enforced? It probably couldn't as people tend to ignore advices no matter how often y= ou write them down. That's why I think we shouldn't include them in this dr= aft. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400=20 Redwood City, California 94063 ralf.weber@nominum.com From bortzmeyer@nic.fr Mon Feb 18 02:06:23 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB68421F882C; Mon, 18 Feb 2013 02:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.1 X-Spam-Level: X-Spam-Status: No, score=-102.1 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDo-AAVKxtQo; Mon, 18 Feb 2013 02:06:23 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3D44A21F8825; Mon, 18 Feb 2013 02:06:20 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 18F9128015E; Mon, 18 Feb 2013 11:05:48 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 148F32800F3; Mon, 18 Feb 2013 11:05:48 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay1.nic.fr (Postfix) with ESMTP id 097684C007C; Mon, 18 Feb 2013 11:05:18 +0100 (CET) Date: Mon, 18 Feb 2013 11:05:17 +0100 From: Stephane Bortzmeyer To: dnsop-chairs@ietf.org Message-ID: <20130218100517.GA12211@nic.fr> References: <20130207111446.GM1320@x28.adm.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130207111446.GM1320@x28.adm.denic.de> X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsop@ietf.org Subject: [DNSOP] DNS in JSON (Was: DNSOP Meeting in Orlando/IETF86 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 10:06:24 -0000 On Thu, Feb 07, 2013 at 12:14:46PM +0100, Peter Koch wrote a message of 12 lines which said: > we would also like to solicit suggestions for agenda items from you. A few minutes to discuss draft-bortzmeyer-dns-json, "JSON format to represent DNS data"? I'm specially interested by feedback about the open questions listed in section 3.6 of -00 From ogud@ogud.com Mon Feb 18 07:52:14 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B46521F8AD8 for ; Mon, 18 Feb 2013 07:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0Njw7Enj9LQ for ; Mon, 18 Feb 2013 07:52:13 -0800 (PST) Received: from smtp195.iad.emailsrvr.com (smtp195.iad.emailsrvr.com [207.97.245.195]) by ietfa.amsl.com (Postfix) with ESMTP id 57BB221F8A3E for ; Mon, 18 Feb 2013 07:52:13 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp49.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 9F060190332; Mon, 18 Feb 2013 10:52:12 -0500 (EST) X-Virus-Scanned: OK Received: by smtp49.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 752AA19030E; Mon, 18 Feb 2013 10:52:12 -0500 (EST) Message-ID: <51224E29.70301@ogud.com> Date: Mon, 18 Feb 2013 10:52:09 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: dnsop@ietf.org References: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> In-Reply-To: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 15:52:14 -0000 On 17/02/2013 10:22, Livingood, Jason wrote: > Based on feedback yesterday on the list, I did a quick –04 update, which > is now at > https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/. > > > The are seven open issues documented at the end of the I-D. But the most > important questions for this WG are: > 1 – Is this worth consideration as a WG I-D or should it continue only > as an individual I-D? If we think this going to be used by many and over a "long" time then the answer is yes If they is just a hack to prevent few DNS resolver operators from getting bad press because their operations are slandered by the mistakes of a publisher of DNS information the answer is no. I'm in the first camp, we should document this as BCP. > 2 – If the answer to #1 is that it should be a WG I-D, would you like a > brief discussion of the open issues at IETF 86? > Yes. > Thanks! > Jason > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From Marco.Davids@sidn.nl Mon Feb 18 07:57:50 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9414A21F86F8 for ; Mon, 18 Feb 2013 07:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0jya75vaOOK for ; Mon, 18 Feb 2013 07:57:50 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id D8A4721F86F7 for ; Mon, 18 Feb 2013 07:57:49 -0800 (PST) Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id r1IFvhLI018838-r1IFvhLK018838 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Mon, 18 Feb 2013 16:57:43 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 18 Feb 2013 16:57:43 +0100 Received: from [94.198.152.219] (94.198.152.219) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server id 14.2.328.9; Mon, 18 Feb 2013 16:57:42 +0100 Message-ID: <51224F76.50504@sidn.nl> Date: Mon, 18 Feb 2013 16:57:42 +0100 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> <51224E29.70301@ogud.com> In-Reply-To: <51224E29.70301@ogud.com> X-Enigmail-Version: 1.5 OpenPGP: id=9F781B52 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.152.219] Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 15:57:50 -0000 Jason, On 17/02/2013 10:22, Livingood, Jason wrote: >> Based on feedback yesterday on the list, I did a quick –04 update Personally I would also have changed all references to RFC4641 into RFC6781. Regards, -- Marco From paul.hoffman@vpnc.org Mon Feb 18 08:22:49 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BFB21F8BDE for ; Mon, 18 Feb 2013 08:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Hv9IaDBsiJE for ; Mon, 18 Feb 2013 08:22:48 -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 96B3C21F8A84 for ; Mon, 18 Feb 2013 08:22:48 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1IGMllY087834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 18 Feb 2013 09:22:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20130218100517.GA12211@nic.fr> Date: Mon, 18 Feb 2013 08:22:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130207111446.GM1320@x28.adm.denic.de> <20130218100517.GA12211@nic.fr> To: "dnsop@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: Re: [DNSOP] DNS in JSON (Was: DNSOP Meeting in Orlando/IETF86 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 16:22:49 -0000 On Feb 18, 2013, at 2:05 AM, Stephane Bortzmeyer = wrote: > On Thu, Feb 07, 2013 at 12:14:46PM +0100, > Peter Koch wrote=20 > a message of 12 lines which said: >=20 >> we would also like to solicit suggestions for agenda items from you. >=20 > A few minutes to discuss draft-bortzmeyer-dns-json, "JSON format to > represent DNS data"? I'm specially interested by feedback about the > open questions listed in section 3.6 of -00 +1 to this being an agenda item. There are some other DNS operational = things that would much simpler if there was a single format like this, = and I would like to see the WG take this up. --Paul Hoffman= From warren@kumari.net Mon Feb 18 08:27:16 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E73B21F8C07 for ; Mon, 18 Feb 2013 08:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.641 X-Spam-Level: X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnnW3CAbVQpF for ; Mon, 18 Feb 2013 08:27:16 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBE121F8C1E for ; Mon, 18 Feb 2013 08:27:15 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 9C6A81B4030C; Mon, 18 Feb 2013 11:27:14 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Mon, 18 Feb 2013 11:27:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8E5333D3-B1C5-41C1-A28B-1DA722809626@kumari.net> References: <20130207111446.GM1320@x28.adm.denic.de> <20130218100517.GA12211@nic.fr> To: Paul Hoffman X-Mailer: Apple Mail (2.1499) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] DNS in JSON (Was: DNSOP Meeting in Orlando/IETF86 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 16:27:16 -0000 On Feb 18, 2013, at 11:22 AM, Paul Hoffman = wrote: > On Feb 18, 2013, at 2:05 AM, Stephane Bortzmeyer = wrote: >=20 >> On Thu, Feb 07, 2013 at 12:14:46PM +0100, >> Peter Koch wrote=20 >> a message of 12 lines which said: >>=20 >>> we would also like to solicit suggestions for agenda items from you. >>=20 >> A few minutes to discuss draft-bortzmeyer-dns-json, "JSON format to >> represent DNS data"? I'm specially interested by feedback about the >> open questions listed in section 3.6 of -00 >=20 > +1 to this being an agenda item. There are some other DNS operational = things that would much simpler if there was a single format like this, = and I would like to see the WG take this up. Plus another one=85 W >=20 > --Paul Hoffman > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 --=20 Militant Agnostic -- I don't know and you don't either... From warren@kumari.net Mon Feb 18 08:28:18 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C070E21F8C0C for ; Mon, 18 Feb 2013 08:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.939 X-Spam-Level: X-Spam-Status: No, score=-101.939 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w36vSkicLU2a for ; Mon, 18 Feb 2013 08:28:18 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7EA21F8C45 for ; Mon, 18 Feb 2013 08:28:17 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 65BD81B4044C; Mon, 18 Feb 2013 11:28:17 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> Date: Mon, 18 Feb 2013 11:28:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> To: "Livingood, Jason" X-Mailer: Apple Mail (2.1499) Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 16:28:18 -0000 On Feb 17, 2013, at 10:22 AM, "Livingood, Jason" = wrote: > Based on feedback yesterday on the list, I did a quick =9604 update, = which is now at = https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/.=20= >=20 >=20 > The are seven open issues documented at the end of the I-D. But the = most important questions for this WG are: > 1 =96 Is this worth consideration as a WG I-D or should it continue = only as an individual I-D? > 2 =96 If the answer to #1 is that it should be a WG I-D, would you = like a brief discussion of the open issues at IETF 86? Yes please, to both. W >=20 > Thanks! > Jason >=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- It's a mistake trying to cheer up camels. You might as well drop = meringues into a black hole. -- Terry Prachett From peter@denic.de Mon Feb 18 09:16:43 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE22421F8C45 for ; Mon, 18 Feb 2013 09:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn0G5IpOu6SL for ; Mon, 18 Feb 2013 09:16:43 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 11BAA21F8C3C for ; Mon, 18 Feb 2013 09:16:43 -0800 (PST) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1U7UKW-0006fQ-3K; Mon, 18 Feb 2013 18:16:40 +0100 Received: from localhost by x27.adm.denic.de with local id 1U7UKW-0000q5-05; Mon, 18 Feb 2013 18:16:40 +0100 Date: Mon, 18 Feb 2013 18:16:39 +0100 From: Peter Koch To: IETF DNSOP WG Message-ID: <20130218171639.GC27968@x28.adm.denic.de> References: <20130209204558.GA12175@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130209204558.GA12175@x28.adm.denic.de> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 17:16:44 -0000 Dear WG, > Please respond by the end of next week, so that we could ask future > editors to submit a renamed -00 version by Monday, Feb 18. thanks to all who responded and especially to those three volunteer reviewers. However, we've not met the 5 reviewer threshold, so your chairs agreed the WG might want to spend a bit more time given that interest was signalled. The current authors are encouraged to fold in comments they received on this list and also we'd like to see discussion on content so that there might be a broader base next time. We will be going to start negotiating goals and milestones with our new AD in Orlando and will keep this topic in mind, but we also need a strong WG commitment to work on a draft. This means we'll not have a draft-ietf-dnsop-as112-omniscient this time, but no more, no less: nobody should be discouraged from making comments on this draft, the floor remains open. Best regards, Peter (as DNSOP co-chair) From jason_livingood@cable.comcast.com Mon Feb 18 11:36:32 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0A021F8B07 for ; Mon, 18 Feb 2013 11:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVzVjjLRbgPm for ; Mon, 18 Feb 2013 11:36:31 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 88C0321F8B02 for ; Mon, 18 Feb 2013 11:36:31 -0800 (PST) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.43824509; Mon, 18 Feb 2013 14:24:17 -0500 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Mon, 18 Feb 2013 14:36:30 -0500 From: "Livingood, Jason" To: "Marco Davids (SIDN)" , "dnsop@ietf.org" Thread-Topic: [DNSOP] New draft-livingood-negative-trust-anchors-04 Thread-Index: AQHODSKYanCs4foReEyzUdtSJHXGsJiAGV2AgAABjQD//+lOAA== Date: Mon, 18 Feb 2013 19:36:29 +0000 Message-ID: <10229F86C86EB444898E629583FD41716165680C@PACDCEXMB06.cable.comcast.com> In-Reply-To: <51224F76.50504@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0D0398682000C044A6A778856EBAF620@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:36:32 -0000 Thanks for catching that - will correct this in -05. Jason On 2/18/13 10:57 AM, "Marco Davids (SIDN)" wrote: >Jason, > >On 17/02/2013 10:22, Livingood, Jason wrote: >>> Based on feedback yesterday on the list, I did a quick =AD04 update > >Personally I would also have changed all references to RFC4641 into >RFC6781. > >Regards, > >-- >Marco > > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop From ogud@ogud.com Mon Feb 18 12:24:31 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03FC21F8CB6 for ; Mon, 18 Feb 2013 12:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAmSHMPhRSEU for ; Mon, 18 Feb 2013 12:24:31 -0800 (PST) Received: from smtp195.iad.emailsrvr.com (smtp195.iad.emailsrvr.com [207.97.245.195]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6D21F8C56 for ; Mon, 18 Feb 2013 12:24:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp39.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 7BA1698305; Mon, 18 Feb 2013 15:24:30 -0500 (EST) X-Virus-Scanned: OK Received: by smtp39.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5A0B8982F5; Mon, 18 Feb 2013 15:24:30 -0500 (EST) Message-ID: <51228DFB.3070005@ogud.com> Date: Mon, 18 Feb 2013 15:24:27 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: dnsop@ietf.org References: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> In-Reply-To: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "Livingood, Jason" Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 20:24:31 -0000 Jason, in section 10 you talk about possible early removal the NTA when validation succeeds but there may be instances where validation succeeds when using a sub-set of the authoritative servers thus NTA should only be removed if all servers are providing "good" signatures. Furthermore what to do if some names work but others do not, for example I remember a case where the records at the apex worked but all names below the apex were signed by a key not in the DNSKEY RRset, thus it is possible that either human or automated checks may assume there is no problem when there actually is one. What this is bringing to my mind is maybe you want a new section with guidelines on how to test for failures and in what cases failure justifies NTA and what tests MUST pass before preemttive removal of an NTA. Also should there be guidance that removal of NTA should include cleaning the caches of all RRsets below the name? Olafur On 17/02/2013 10:22, Livingood, Jason wrote: > Based on feedback yesterday on the list, I did a quick –04 update, which > is now at > https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/. > > > The are seven open issues documented at the end of the I-D. But the most > important questions for this WG are: > 1 – Is this worth consideration as a WG I-D or should it continue only > as an individual I-D? > 2 – If the answer to #1 is that it should be a WG I-D, would you like a > brief discussion of the open issues at IETF 86? > > Thanks! > Jason > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From marka@isc.org Mon Feb 18 13:56:50 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5FB21F8CFA for ; Mon, 18 Feb 2013 13:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLwuxf7ZwZta for ; Mon, 18 Feb 2013 13:56:44 -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 36C0B21F8CEB for ; Mon, 18 Feb 2013 13:56:44 -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 507B65F9B89; Mon, 18 Feb 2013 21:56:33 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361224603; bh=cYbChELOeN1d+rOeSeQbbpzOBnJMup8yi3kctSc34Fo=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=SDcr9sNPiITjC0lY6KHogDOkfz+ojDQ0XjkD/WKyTptguW6eHa/xysH56F5JQtfHt Xo2TCGqTpqQUs1tJARXoSiAUqFKZFbWd+CTk67gqTXgovbvpwW9unKHmBOshwvGuiE ZPjPE6H2coOFGdYC9IoRLSVzAYr8E1De02GmgTP8= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 338FA216C3B; Mon, 18 Feb 2013 21:56:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 425852FCB39B; Tue, 19 Feb 2013 08:56:27 +1100 (EST) To: Olafur Gudmundsson From: Mark Andrews References: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> <51228DFB.3070005@ogud.com> In-reply-to: Your message of "Mon, 18 Feb 2013 15:24:27 CDT." <51228DFB.3070005@ogud.com> Date: Tue, 19 Feb 2013 08:56:27 +1100 Message-Id: <20130218215627.425852FCB39B@drugs.dv.isc.org> Cc: dnsop@ietf.org, "Livingood, Jason" Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 21:56:50 -0000 In message <51228DFB.3070005@ogud.com>, Olafur Gudmundsson writes: > Jason, in section 10 you talk about possible early removal the NTA when > validation succeeds but there may be instances where validation succeeds > when using a sub-set of the authoritative servers thus NTA should only > be removed if all servers are providing "good" signatures. Why? This is no different to a server being down. Validators are expected to ignore bad answers so a conforming resolver will find the working copies of the zone. > Furthermore what to do if some names work but others do not, for example > I remember a case where the records at the apex worked but all names > below the apex were signed by a key not in the DNSKEY RRset, thus it is > possible that either human or automated checks may assume there is no > problem when there actually is one. This is no different than making the decision to add a NTA or not. > What this is bringing to my mind is maybe you want a new section with > guidelines on how to test for failures and in what cases failure > justifies NTA and what tests MUST pass before preemttive removal of an > NTA. > > Also should there be guidance that removal of NTA should include > cleaning the caches of all RRsets below the name? > > Olafur There are lots of ways to stuff up DNSSEC. There are different steps that can be taken to cleanup after such stuff ups. We don't need to describe those steps. > On 17/02/2013 10:22, Livingood, Jason wrote: > > Based on feedback yesterday on the list, I did a quick update, which > > is now at > > > https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/. > > > > > > The are seven open issues documented at the end of the I-D. But the most > > important questions for this WG are: > > 1 * Is this worth consideration as a WG I-D or should it continue only > > as an individual I-D? > > 2 * If the answer to #1 is that it should be a WG I-D, would you like a > > brief discussion of the open issues at IETF 86? > > > > Thanks! > > Jason > > > > > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From warren@kumari.net Mon Feb 18 14:36:13 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF30621F8C9F for ; Mon, 18 Feb 2013 14:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzxa4VHSKx19 for ; Mon, 18 Feb 2013 14:36:13 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1578121F8C8C for ; Mon, 18 Feb 2013 14:35:59 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id E20C51B40706; Mon, 18 Feb 2013 17:35:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari Date: Mon, 18 Feb 2013 17:35:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> To: "dnsop@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: [DNSOP] Fwd: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 22:36:14 -0000 Hi all, This is a compilation of two earlier drafts, = draft-barwood-dnsop-ds-publish and draft-wkumari-dnsop-ezkeyroll. The basic idea remains the same -- allow operators to publish new (and = standby) DS records at the parent by publishing them in their zone, = signed with their current key. This new draft explains the problem a little better, and also that, in = the "registries shouldn't talk to registrars" model the registrar can do = the magic instead. We believe that there is a need / desire for this -- apart from the fact = that *I* hate having to click all over the GoDaddy web site to change = keys, we have heard a number of registrars and registrars asking for = it... W Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-kumari-ogud-dnsop-cds-00.txt > Date: February 18, 2013 4:06:00 PM EST > To: warren@kumari.net > Cc: warren@kumari.net, ogud@ogud.com >=20 >=20 > A new version of I-D, draft-kumari-ogud-dnsop-cds-00.txt > has been successfully submitted by Warren Kumari and posted to the > IETF repository. >=20 > Filename: draft-kumari-ogud-dnsop-cds > Revision: 00 > Title: Easy DNSSEC Key Publish > Creation date: 2013-02-18 > Group: Individual Submission > Number of pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-00.txt > Status: = http://datatracker.ietf.org/doc/draft-kumari-ogud-dnsop-cds > Htmlized: = http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-00 >=20 >=20 > Abstract: > This document describes a method to allow DNS operators to more > easily publish updated DNSSEC Key Signing Keys. This document does > not address the initial configuration of trust anchors for a domain. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 -- Life is a concentration camp. You're stuck here and there's no way out = and you can only rage impotently against your persecutors. -- Woody Allen From stephan.lagerholm@secure64.com Mon Feb 18 16:05:53 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C2521E8051 for ; Mon, 18 Feb 2013 16:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiFkx0njYfHr for ; Mon, 18 Feb 2013 16:05:53 -0800 (PST) Received: from zimbra.secure64.com (mail.secure64.com [64.92.221.180]) by ietfa.amsl.com (Postfix) with ESMTP id E1DFF21E8090 for ; Mon, 18 Feb 2013 16:05:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id E9698B86EC; Mon, 18 Feb 2013 17:05:45 -0700 (MST) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-ny5EggpulY; Mon, 18 Feb 2013 17:05:22 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 27041B86EF; Mon, 18 Feb 2013 17:05:22 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1361232322; bh=9mGTNwdNM9ti9JsK3yME375NmLHPCLz3ApH0CAcWNMM=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=m1TcHUCfSvqJtdXBm7wdm fliUhZVFfxeFlo3CSrF0wJQ/FNm9dB2u9Kan1E1lSfkQiAapFnFzkCApIJZ4bu1b4U6 loJtFDloGtjycFMSR0zB0gxSOhf+UAiXiGlTqb3vlWn5dMnYl78JOumMP8gfOOLrjh8 sDwjbhrVV3Pskcek= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Feb 2013 17:05:21 -0700 Message-ID: In-Reply-To: <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DNSOP] Fwd: New Version Notification fordraft-kumari-ogud-dnsop-cds-00.txt Thread-Index: Ac4OKGRuPODn6zVLSV+6i5NschQXnwACxd5w References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> From: "Stephan Lagerholm" To: "Warren Kumari" , Subject: Re: [DNSOP] Fwd: New Version Notification fordraft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 00:05:53 -0000 Warren Kumari, Monday, February 18, 2013 4:36 PM: > Hi all, >=20 > This is a compilation of two earlier drafts, draft-barwood-dnsop-ds- > publish and draft-wkumari-dnsop-ezkeyroll. > > The basic idea remains the same -- allow operators to publish new (and > standby) DS records at the parent by publishing them in their zone, > signed with their current key. >=20 > This new draft explains the problem a little better, and also that, in > the "registries shouldn't talk to registrars" model the registrar can > do the magic instead. I support this effort and think it would be very useful. However there are a few areas that I think needs additional work. I think you need to better explain how old DS records are removed. Would it be possible to make the 'going unsigned' method more granular so that you can use it to specify individual DS records? Thanks, Stephan=20 From fanf2@hermes.cam.ac.uk Mon Feb 18 16:37:35 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FE321E8063 for ; Mon, 18 Feb 2013 16:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.031 X-Spam-Level: X-Spam-Status: No, score=-4.031 tagged_above=-999 required=5 tests=[AWL=-1.432, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11oLW3XtqJlx for ; Mon, 18 Feb 2013 16:37:35 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0521E8051 for ; Mon, 18 Feb 2013 16:37:35 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46064) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1U7bDA-0006ga-6i (Exim 4.80_167-5a66dd3) (return-path ); Tue, 19 Feb 2013 00:37:32 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1U7bDA-0008L0-1x (Exim 4.72) (return-path ); Tue, 19 Feb 2013 00:37:32 +0000 Date: Tue, 19 Feb 2013 00:37:32 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Joe Abley In-Reply-To: Message-ID: References: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> <853770FE-4D9E-46B5-9420-1D4334942796@hopcount.ca> <4359B40FE8E82C4BA840D73427B8A45847F064F2@mbx-01.win.nominum.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Ralf Weber , Jason Livingood , "dnsop@ietf.org WG" , Ted Lemon Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 00:37:35 -0000 Joe Abley wrote: > > You could compare it to DNS RBLs, too. You don't have to like it for it > to exist (you don't have to use it.) It doesn't need to be universally > liked to be useful. I agree with your point but there is also a difference. RBLs (and DNS response policy zones) create breakage in order to protect users. NTAs hide breakage in order to placate users. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From fanf2@hermes.cam.ac.uk Mon Feb 18 16:48:27 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F48D21F8D83 for ; Mon, 18 Feb 2013 16:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.872 X-Spam-Level: X-Spam-Status: No, score=-3.872 tagged_above=-999 required=5 tests=[AWL=-1.273, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5ON5-tOIlPH for ; Mon, 18 Feb 2013 16:48:26 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2F121F8D7F for ; Mon, 18 Feb 2013 16:48:26 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46716) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1U7bNh-0000DL-7c (Exim 4.80_167-5a66dd3) (return-path ); Tue, 19 Feb 2013 00:48:25 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1U7bNh-0000j7-Au (Exim 4.72) (return-path ); Tue, 19 Feb 2013 00:48:25 +0000 Date: Tue, 19 Feb 2013 00:48:25 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Stephane Bortzmeyer In-Reply-To: <20130218100517.GA12211@nic.fr> Message-ID: References: <20130207111446.GM1320@x28.adm.denic.de> <20130218100517.GA12211@nic.fr> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop@ietf.org Subject: Re: [DNSOP] DNS in JSON (Was: DNSOP Meeting in Orlando/IETF86 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 00:48:27 -0000 Stephane Bortzmeyer wrote: > > A few minutes to discuss draft-bortzmeyer-dns-json, "JSON format to > represent DNS data"? I'm specially interested by feedback about the > open questions listed in section 3.6 of -00 I think your first question, about a formal mechanism for documenting the field names of DNS RDATA, ought to be answered by draft-levine-dnsextlang. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From ogud@ogud.com Mon Feb 18 17:30:39 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD4121E8064 for ; Mon, 18 Feb 2013 17:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0d7qn7NeP1IG for ; Mon, 18 Feb 2013 17:30:39 -0800 (PST) Received: from smtp125.iad.emailsrvr.com (smtp125.iad.emailsrvr.com [207.97.245.125]) by ietfa.amsl.com (Postfix) with ESMTP id 141FB21E8044 for ; Mon, 18 Feb 2013 17:30:39 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp42.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 32D4F148658 for ; Mon, 18 Feb 2013 20:30:32 -0500 (EST) X-Virus-Scanned: OK Received: by smtp42.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 17B21148633 for ; Mon, 18 Feb 2013 20:30:32 -0500 (EST) Message-ID: <5122D5B8.3020106@ogud.com> Date: Mon, 18 Feb 2013 20:30:32 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: dnsop@ietf.org References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Fwd: New Version Notification fordraft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 01:30:39 -0000 On 18/02/2013 19:05, Stephan Lagerholm wrote: > > > Warren Kumari, Monday, February 18, 2013 4:36 PM: >> Hi all, >> >> This is a compilation of two earlier drafts, draft-barwood-dnsop-ds- >> publish and draft-wkumari-dnsop-ezkeyroll. >> >> The basic idea remains the same -- allow operators to publish new (and >> standby) DS records at the parent by publishing them in their zone, >> signed with their current key. >> >> This new draft explains the problem a little better, and also that, in >> the "registries shouldn't talk to registrars" model the registrar can >> do the magic instead. > > I support this effort and think it would be very useful. However there > are a few areas that I think needs additional work. I think you need to > better explain how old DS records are removed. Would it be possible to > make the 'going unsigned' method more granular so that you can use it to > specify individual DS records? > Stephan, Basically the @parental agent@ copies the contents of the CDS RRset and replaces the existing DS set with the new one. . So if you want to delete a particular DS record you remove it from the CDS set. Going Unsigned is to delete all the DS records no exceptions, we can not use No CDS present as the semantics of that state is no changes to current DS set. Olafur > Thanks, Stephan > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > From ek@google.com Tue Feb 19 07:50:34 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE3721F8881 for ; Tue, 19 Feb 2013 07:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDaNnIEdhWyA for ; Tue, 19 Feb 2013 07:50:34 -0800 (PST) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id DCEE921F8878 for ; Tue, 19 Feb 2013 07:50:33 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i18so7110301oag.15 for ; Tue, 19 Feb 2013 07:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=E7B0owpbQbKdKgR5w6EzWQukt94rH1K/JVnX7Gcwr8w=; b=ZQFQuZ6/rjb6/4Y6sqrTQ28BWwCk7yErL33A7CeCUtt3q5dGjB7RZcnBv4QnZLI2fA S5BG3j/veP2dPBk2Wl+KhlWk/jarkxIz5Go92C3IVE/3ZhfCpJ8K/6gYvBoTS4mqbuN1 bKU7sHca5T396nQRBdoAP/DAmvRaNreso4CA/NoCdLLaDFSoZiHTZy2Sjk+gY4vXaVDR RrAw2TFoYvfs+OrwDx2AA21I2tPfaWvgmoiVnmbg0r39pmGxjyB25VtQvycyb14IVq+L 7OtijYiXMbG3aoyr4ELPD48r5X2Ir37qoUselG/43gr0yU5I5dudqih5+l1nF3xaWgS4 akMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=E7B0owpbQbKdKgR5w6EzWQukt94rH1K/JVnX7Gcwr8w=; b=DUwJ/k3qDXfIlC/euhMGRb1rjFqiFOvNo5BdAKMcvtbBUHbBRGlH9l2wqOrT+1/Tuq 0bo0H5v1NOndlmHBe3SwHSRSAAwsVsdXZZHK9i+vtTu4usKyS/YFVgiP+Om7hbdiJ0ru B4dvOEEBAa1MxKpGH6VpaNO5Qp0kEyac/TuQHo2ZKSyx+1wkeQjz/aQTqH7UOAHRgS0D lJtPmrLmF8qYU2ufSUNVcjQ+hQIbJtlFqH2r2WO6wcE1Mf8BWm0MtTHBt0JSDyPqtqgt qhSQniDOk6uW8djWj4ILJo1snf2FF8YlNuZmP6CiZCtnfhV44apJEPhqJPeZvRp0bifC 4rbw== X-Received: by 10.182.221.4 with SMTP id qa4mr7841589obc.100.1361289033283; Tue, 19 Feb 2013 07:50:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.50.227 with HTTP; Tue, 19 Feb 2013 07:50:13 -0800 (PST) In-Reply-To: <20130218171639.GC27968@x28.adm.denic.de> References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> From: Erik Kline Date: Wed, 20 Feb 2013 00:50:13 +0900 Message-ID: To: Peter Koch Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlg7HAvIPRKGe2YI+dloKRvgwYNXzdW2Ww4HVI2yitk8O6RsTQHdDr2lh//Paot3c92Nxjjj1PVGJ7mTTT69fB1EQwadEPVMtx6OCQL5Q57GKZ26+rq8CNyu4hQVwfDAve7n7NPv6LkdCDWorvVsaQmLKDIbDFKOyqblSQhM8fUvGEYJwSk0GQe6C8GmWaH9q/4Qo7l Cc: IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 15:50:34 -0000 I know I'm late, but for what it's worth I'd support this. I'm happy to help, if possible. Perhaps I can sync with Warren et alia in person in Orlando. From paul@cypherpunks.ca Tue Feb 19 08:07:28 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4839F21F8E02 for ; Tue, 19 Feb 2013 08:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTxKchku5SSb for ; Tue, 19 Feb 2013 08:07:27 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0187821F8C3E for ; Tue, 19 Feb 2013 08:07:25 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 02063805AC; Tue, 19 Feb 2013 11:07:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E7F598053A; Tue, 19 Feb 2013 11:07:14 -0500 (EST) Date: Tue, 19 Feb 2013 11:07:14 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Warren Kumari In-Reply-To: <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> Message-ID: References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] Fwd: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 16:07:28 -0000 On Mon, 18 Feb 2013, Warren Kumari wrote: > The basic idea remains the same -- allow operators to publish new (and standby) DS records at the parent by publishing them in their zone, signed with their current key. I of course hope this draft or something similar will go through. The fact that the older CDS draft got stuck was for me the motivation behind draft-wouters-dnsop-secure-update-use-cases but that seems stalled by people being ver nervous about the RRR model. I had to carefully not mention any technology I prefered in that draft, but this kind of mechanism always had my preference, as it requires no direct parent-child port 53 access, and signaling between parent and child an be done my helpers that are not in the actual path of serving DNS data, so it is also the most secure method of doing it. What is missing in this draft doing the same for other parent-child data, such as NS and glue records. Since we have an authenticated parent-child relationship now, why not extend this draft to include CNS/GLUEA/GLUEAAAA ? To me it makes sense to integrate it here, because the mechanism will be basically identical, although perhaps some more prevention for shooting one's foot might be required. In many environments (for example, gTLDs) the parent will be a registry, and is expected to not have direct contact with the child (registrant). I recommend removing ANY kind of language that ties anything to the RRR model, as just mentioning it is what more or less killed the use-cases draft. That includes mentioning TLDs or "Registry interface". Specify the protocol, leave out the administration/politics and don't tell people how to integrate the implementation. In this case the parental agent will query each child zone that has a DS RRset, looking for CDS RRset That's a good mechanism to leave the initial auth specification (tied to RRR or not) out of the spec! Bravo! If the validation succeeds with a DNSKEY that is represented in the current DS RRset in parent. You have to be more strict then just "validation succeeds". You MUST ensure the proper DNSKEY's matching the CDS records exist on ALL secondary servers, and must wait AT LEAST a TTL time before being willing to update the DS record. The parenteral agent should submit a request to the registry to publish the contents of the CDS RR(s) as the new a DS record(s) for that zone. But here you go wrong. Rewrite it to not mention "registry". Just talk about the parent zone manager. You could be talking about an inline bind, a cron job, some perl code, a database ...whatever the parent is. The registry should log if possible the source of the update, user interface/CDS etc. Same here. IN CDS 0 0 0 I really dislike this idea. An attacker that has no access to the keys, but does have access to unsigned zone data could put such a record in the zone to fully remove the security added by the DNSSEC signer to which they might not have access (yet). This can cause an escalation from "needing a still-compromised server" to "only need to compromise a server briefly and then leave without a trace". I believe you should stick to out of band communication for both secure-> insecure and insecure -> secure. Paul From paul.hoffman@vpnc.org Tue Feb 19 08:36:51 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F00421F8DFB for ; Tue, 19 Feb 2013 08:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1rE7chGpnxG for ; Tue, 19 Feb 2013 08:36:50 -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 D2B9D21F8DF0 for ; Tue, 19 Feb 2013 08:36:50 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1JGanHC038793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 19 Feb 2013 09:36:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Tue, 19 Feb 2013 08:36:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> To: "dnsop@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 16:36:51 -0000 On Feb 19, 2013, at 8:07 AM, Paul Wouters wrote: > What is missing in this draft doing the same for other parent-child > data, such as NS and glue records. Since we have an authenticated > parent-child relationship now, why not extend this draft to include > CNS/GLUEA/GLUEAAAA ? To me it makes sense to integrate it here, = because > the mechanism will be basically identical, although perhaps some more > prevention for shooting one's foot might be required. +1. The operational implications of NS record changes are the same as = for DS, even though the DNS protocol ramifications are different. And, before someone suggests it, I am *not* in favor of a kitchen-sink = approach that defines some record of a random type as being for the = parent. It is fine for us to specify as many of these records now that = we know about (DS and NS and glue being mentioned so far), and if = someone comes up with one later, they can update the RFC with a new type = for the new record. --Paul Hoffman= From jacques.latour@cira.ca Tue Feb 19 09:20:27 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8E21F8E10 for ; Tue, 19 Feb 2013 09:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2DUe4TJnM+n for ; Tue, 19 Feb 2013 09:20:26 -0800 (PST) Received: from office-mx.cira.ca (office-smtp.cira.ca [192.228.22.119]) by ietfa.amsl.com (Postfix) with ESMTP id DFBF321F8E67 for ; Tue, 19 Feb 2013 09:20:25 -0800 (PST) Received: from office-mx0 (office-mx0 [127.0.0.1]) by office-mx.cira.ca (Postfix) with SMTP id 80F09F2227; Tue, 19 Feb 2013 12:20:20 -0500 (EST) Received: from mbxhub.cira.ca (mbxhub.cira.ca [192.228.22.115]) by office-mx.cira.ca (Postfix) with ESMTP id DF85CF2227; Tue, 19 Feb 2013 12:20:19 -0500 (EST) Received: from MBX01.cira1.cira.ca ([10.2.16.30]) by exch-hub.cira1.cira.ca ([10.2.16.28]) with mapi; Tue, 19 Feb 2013 12:21:21 -0500 From: Jacques Latour To: Paul Hoffman , "dnsop@ietf.org WG" , "Antoin Verschuren (antoin.verschuren@sidn.nl)" Date: Tue, 19 Feb 2013 12:20:19 -0500 Thread-Topic: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt Thread-Index: Ac4Ov1RCFlWlhvNITjaIDGQX9/ZnCgABNH3w Message-ID: References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VAMS: NONE Subject: Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 17:20:28 -0000 Another "what if scenario" for bypassing the EPP keyrelay with automation, = what if there was a CKEYRELAY record pointing to the gaining DNS operator n= ame servers, where the parent zone operator can grab the new DS record to b= e pre-published prior DNS operator transfer?=20 Potentially, parent zone can manage add/delete/transfers automatically, exc= ept for the initial DNSSEC setup which needs to be authenticated. Jack =20 > -----Original Message----- > From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf > Of Paul Hoffman > Sent: February-19-13 11:37 AM > To: dnsop@ietf.org WG > Subject: Re: [DNSOP] New Version Notification for draft-kumari-ogud- > dnsop-cds-00.txt >=20 > On Feb 19, 2013, at 8:07 AM, Paul Wouters wrote: >=20 > > What is missing in this draft doing the same for other parent-child > > data, such as NS and glue records. Since we have an authenticated > > parent-child relationship now, why not extend this draft to include > > CNS/GLUEA/GLUEAAAA ? To me it makes sense to integrate it here, > > because the mechanism will be basically identical, although perhaps > > some more prevention for shooting one's foot might be required. >=20 > +1. The operational implications of NS record changes are the same as for= DS, > even though the DNS protocol ramifications are different. >=20 > And, before someone suggests it, I am *not* in favor of a kitchen-sink > approach that defines some record of a random type as being for the paren= t. > It is fine for us to specify as many of these records now that we know ab= out > (DS and NS and glue being mentioned so far), and if someone comes up with > one later, they can update the RFC with a new type for the new record. >=20 > --Paul Hoffman > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From marc.lampo.ietf@gmail.com Tue Feb 19 11:50:43 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C70A21F8E38 for ; Tue, 19 Feb 2013 11:50:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDAqUqsMeD-A for ; Tue, 19 Feb 2013 11:50:42 -0800 (PST) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1B921F8E20 for ; Tue, 19 Feb 2013 11:50:41 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id s24so4441027vbi.8 for ; Tue, 19 Feb 2013 11:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tLYv2n9KgDkkLwtLuE+Lm21yFE36QyaTmNZDnzFf4XE=; b=ngPDy8gjgLuY4+PZz65zgflsyxjbNyERUCe5ZxdG8d0MeZsOFoQ0/Hq3BdmWs/NBU8 FrncBQcCeJYqePUz+Pc1JFbxraFHZW6D6oWMjDdg6uN0yIgTkn2n01LJSJbtoayCAL+N C0gZXzeny5Tggy5I7bPT9SeodZDVC95OfJdcwVdTliEpTVNiOhibYxqxXxs+vDH6Yzkd ZCucRC/jjxvcLMNcOJPQ2yiHdGSmmM28tEyDiPTqtW4EmpmD2GBnKMhvJtr6FZvQbZSJ u8ycy7BN/EToII/nZ32CmDGuA04g1CUSu37FajqRgyyCqXMrAA2TSWTn4nfdlHV77Ftn JYfQ== MIME-Version: 1.0 X-Received: by 10.58.233.210 with SMTP id ty18mr22602957vec.46.1361303441385; Tue, 19 Feb 2013 11:50:41 -0800 (PST) Received: by 10.58.163.100 with HTTP; Tue, 19 Feb 2013 11:50:41 -0800 (PST) In-Reply-To: <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> Date: Tue, 19 Feb 2013 20:50:41 +0100 Message-ID: From: Marc Lampo To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] Fwd: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 19:50:43 -0000 Hello, a couple of constructive remarks : 1) Should the CDS RR have the same fields as the DS ? Or : is there any benefit in adding a field with some "operation code" (failing a better name) Suppose a code is added : 0 could mean : corresponding KSK created - this will be the DS - don't publish yet 1 could mean : I'm hold data for a DS to be published 2 could mean : IKSK is retiring - no longer publish this data in a DS Might help for troubleshooting : like - why is the DS no longer there --> look at CDS records. In the present draft : no CDS records <-> no corresponding DS (but there is no history info) Also, the present draft suggest "@ IN CDS 0 0 0" to go unsigned. But the situation where "@ IN CDS 0 0 0" appearrs *together* with another CDS that does hold data is not described. If there will be no "operation code", handling of above error case should be in the draft, I think. 2) "SIgned with a DNSKEY that has the SEP bit flag set" ? Why ? If there is chain-of-trust up till and including the ZSK of the zone, why not "trust" that information. On one side : some name server implementations use KSK's only to sign DNSKEY RRset's. It requires extra arguments or change in the code to consider CDS's as well. On the other side : would it be an error to publish 2 KSK's, but sign CDS RRset with only one of them ? I think this point needs more motivation - or there should be no insisting on signing with KSK's. 3) Periodic check by parental agent I think this should be extended by stating that logging of "somehow rejected" CDS RRset should be done. At what time, from with authoritative NS, wich CDS RRset received and why it was not used for publishing. 4) Should the parental agent check all authoritative name servers of a domain for a consistent CDS RRset ? Perhaps just mention, in the draft, what the expected behavior is. I remember from previous contributions I made - while still at a top-level-domain myself - that some reactions might/will be : "not our responsibility". I'm OK with that, but I'd suggest the draft states what is to be expected. 5) (this is tricky !) Security section states : "not for initial enrollment" Why not ? If it is "not our responsibility" (if a DNS operator messes up the signed zone) anyway, why not "detect" the presence of : DNSKEY RRset valid RRsig's CDS RRset (properly signed with a published DNSKEY) (for validation, use the DNSKEY the RRSIG refers to, "believe" it without chain-of-trust being in place) (if there is no CDS RRset - or there is with some "operation code" == 0, then, don't publish) This would overcome the initial 12 steps to bootstrap a zone with DNSSEC. 6) Please correct the address of author George Barwood (or you get too much email, Warren ;-) Kind regards, Marc On Mon, Feb 18, 2013 at 11:35 PM, Warren Kumari wrote: > Hi all, > > This is a compilation of two earlier drafts, draft-barwood-dnsop-ds-publish and draft-wkumari-dnsop-ezkeyroll. > > The basic idea remains the same -- allow operators to publish new (and standby) DS records at the parent by publishing them in their zone, signed with their current key. > > This new draft explains the problem a little better, and also that, in the "registries shouldn't talk to registrars" model the registrar can do the magic instead. > > We believe that there is a need / desire for this -- apart from the fact that *I* hate having to click all over the GoDaddy web site to change keys, we have heard a number of registrars and registrars asking for it... > > W > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt >> Date: February 18, 2013 4:06:00 PM EST >> To: warren@kumari.net >> Cc: warren@kumari.net, ogud@ogud.com >> >> >> A new version of I-D, draft-kumari-ogud-dnsop-cds-00.txt >> has been successfully submitted by Warren Kumari and posted to the >> IETF repository. >> >> Filename: draft-kumari-ogud-dnsop-cds >> Revision: 00 >> Title: Easy DNSSEC Key Publish >> Creation date: 2013-02-18 >> Group: Individual Submission >> Number of pages: 8 >> URL: http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-00.txt >> Status: http://datatracker.ietf.org/doc/draft-kumari-ogud-dnsop-cds >> Htmlized: http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-00 >> >> >> Abstract: >> This document describes a method to allow DNS operators to more >> easily publish updated DNSSEC Key Signing Keys. This document does >> not address the initial configuration of trust anchors for a domain. >> >> >> >> >> The IETF Secretariat >> > > -- > Life is a concentration camp. You're stuck here and there's no way out and you can only rage impotently against your persecutors. > -- Woody Allen > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From paul@cypherpunks.ca Tue Feb 19 13:00:32 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7CD21F8A51 for ; Tue, 19 Feb 2013 13:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAJtIMxMghGW for ; Tue, 19 Feb 2013 13:00:32 -0800 (PST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 676F821F8A4F for ; Tue, 19 Feb 2013 13:00:31 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 4E84E804CC; Tue, 19 Feb 2013 16:00:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3DAEE8046A; Tue, 19 Feb 2013 16:00:28 -0500 (EST) Date: Tue, 19 Feb 2013 16:00:28 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Marc Lampo In-Reply-To: Message-ID: References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] Fwd: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:00:33 -0000 On Tue, 19 Feb 2013, Marc Lampo wrote: > a couple of constructive remarks : > 1) Should the CDS RR have the same fields as the DS ? > Or : is there any benefit in adding a field with some "operation > code" (failing a better name) > > Suppose a code is added : > 0 could mean : corresponding KSK created - this will be the DS - > don't publish yet > 1 could mean : I'm hold data for a DS to be published > 2 could mean : IKSK is retiring - no longer publish this data in a DS > > Might help for troubleshooting : > like - why is the DS no longer there --> look at CDS records. > In the present draft : no CDS records <-> no corresponding DS (but > there is no history info) I don't think these are worth the complexity. > 2) "SIgned with a DNSKEY that has the SEP bit flag set" ? > Why ? > > If there is chain-of-trust up till and including the ZSK of the zone, > why not "trust" that information. Because ZSK might be online, and KSK might be offline. It should come from the KSK, not the ZSK, or else the ZSK can change an offline KSK. > 3) Periodic check by parental agent > > I think this should be extended by stating that logging of "somehow > rejected" CDS RRset should be done. > At what time, > from with authoritative NS, > wich CDS RRset received > and why it was not used for publishing. IMHO, al ofthat is implementation and does not belong in a protocol specification. > 4) Should the parental agent check all authoritative name servers of a > domain for a consistent CDS RRset ? Yes, as I said in my previous email. > 5) (this is tricky !) Security section states : "not for initial enrollment" > Why not ? There is no path of trust! Paul From warren@kumari.net Tue Feb 19 13:21:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B77A21F886A for ; Tue, 19 Feb 2013 13:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlhsclVAlM6X for ; Tue, 19 Feb 2013 13:21:43 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897A021F8810 for ; Tue, 19 Feb 2013 13:21:41 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id EF0F51B40706; Tue, 19 Feb 2013 16:21:40 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Tue, 19 Feb 2013 16:21:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10229F86C86EB444898E629583FD4171616521A5@PACDCEXMB06.cable.comcast.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1499) Cc: "Livingood, Jason" , "dnsop@ietf.org" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:21:46 -0000 On Feb 16, 2013, at 7:43 PM, Paul Hoffman wrote: > Ted's misunderstanding of what you are proposing is a valid one. You = don't actually say what a negative trust anchor is, and what it is a = trust anchor for, until section 7. Readers such as Ted (and myself!) = will have strong prejudices by then. >=20 > I would want to see something in the Introduction saying something = like: >=20 > This document discusses trust anchors for DNSSEC. A "negative trust = anchor" is equivalent to a "regular" DNSSEC trust anchor for a = particular instance of a recursive validating resolver. A negative trust = anchor is quite different from regular DNSSEC trust anchors in that they = are local, temporary, and definitely not distributed by IANA. They are = trust anchors only for DNSSEC, not for PKIX. >=20 > That should help set the tone for the following sections that say how = to use them, and then the much later sections on what they actually are. I also think that it would be very helpful to actually show *how* this = is used, with e.g and example in an Appendix, for . The document contains a lot of really useful content about why you might = use one, how to minimize damage, etc but (IMO) does't do a great job of = explaining *how* to actually do so=85 But yes, I think it should be considered for adoption / if this is a CfA = I support it :-P I'd also like to see it presented / discussed at the meeting... W >=20 > --Paul Hoffman > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 -- "Build a man a fire, and he'll be warm for a day. Set a man on fire, and = he'll be warm for the rest of his life." -- Terry Pratchett From miekg@atoom.net Wed Feb 20 00:36:52 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CDF21F85CC for ; Wed, 20 Feb 2013 00:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.496 X-Spam-Level: * X-Spam-Status: No, score=1.496 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s80HFwCgfvOG for ; Wed, 20 Feb 2013 00:36:52 -0800 (PST) Received: from elektron.atoom.net (37-251-95-53.FTTH.ispfabriek.nl [37.251.95.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD9B21F85C2 for ; Wed, 20 Feb 2013 00:36:51 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id E11564001D; Wed, 20 Feb 2013 09:36:47 +0100 (CET) Date: Wed, 20 Feb 2013 09:36:47 +0100 From: Miek Gieben To: Erik Kline Message-ID: <20130220083647.GA8527@miek.nl> Mail-Followup-To: Erik Kline , Peter Koch , IETF DNSOP WG References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 08:36:53 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [ Quoting in "Re: [DNSOP] Adoption of I know I'm late, but for what it's worth I'd support this. +1 I've skimmed the document and support it being a wg doc. I also volunteer as a reviewer. Kind regards, Miek Gieben --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlEkix8ACgkQJYuFzziA0PYRrQCfSoM/gTcDcbtiIb+5A+oPqkgk 86wAoMoZUIui/uT51z5UeJJ0RspkkVTb =ixNj -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From richard.lamb@icann.org Wed Feb 20 10:50:34 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1B521F88EF for ; Wed, 20 Feb 2013 10:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T75H1EZzhGPn for ; Wed, 20 Feb 2013 10:50:32 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6F02421F880B for ; Wed, 20 Feb 2013 10:50:31 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 20 Feb 2013 10:50:30 -0800 From: Richard Lamb To: "Livingood, Jason" , "dnsop@ietf.org" Date: Wed, 20 Feb 2013 10:50:40 -0800 Thread-Topic: New draft-livingood-negative-trust-anchors-04 Thread-Index: AQHODSKYanCs4foReEyzUdtSJHXGsJiDFSJQ Message-ID: <5648A8908CCB564EBF46E2BC904A75B15EFE3B5477@EXVPMBX100-1.exc.icann.org> References: <10229F86C86EB444898E629583FD4171616521A5@PACDCEXMB06.cable.comcast.com> <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> In-Reply-To: <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5648A8908CCB564EBF46E2BC904A75B15EFE3B5477EXVPMBX1001ex_" MIME-Version: 1.0 Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:50:34 -0000 --_000_5648A8908CCB564EBF46E2BC904A75B15EFE3B5477EXVPMBX1001ex_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jason- FWIW: The -04 draft looks good. It is clear and well written and I think i= t is a valuable resource. As I am late to looking at this draft please take this only as a comment fr= om a narrow minded engineer ;-) After the rationale, explanations and cav= eats I kept looking for how to implement a NTA. After initially thinking t= his would be the introduction of some new functionality and RRset manipulat= ion, I only found a reference to how Unbound implements it. So it might be useful to have section 2 "Definition .." make that clear for= slow people like me - that the NTA is not an RR and is more of a configura= tion. Maybe simply replacing "placed" with "implemented" in section 2? "T= his NTA can potentially be [placed][implemented] at any level within the ch= ain of trust..." Feel free to ignore of this thread has already been covered. Regardless o= f whether my comment makes sense, I do this this is a useful draft to have. -Rick From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf Of L= ivingood, Jason Sent: Sunday, February 17, 2013 7:22 AM To: dnsop@ietf.org Subject: [DNSOP] New draft-livingood-negative-trust-anchors-04 Based on feedback yesterday on the list, I did a quick -04 update, which is= now at https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anc= hors/. The are seven open issues documented at the end of the I-D. But the most im= portant questions for this WG are: 1 - Is this worth consideration as a WG I-D or should it continue only as a= n individual I-D? 2 - If the answer to #1 is that it should be a WG I-D, would you like a bri= ef discussion of the open issues at IETF 86? Thanks! Jason --_000_5648A8908CCB564EBF46E2BC904A75B15EFE3B5477EXVPMBX1001ex_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jason-

 

=

FWIW: The -04 draft looks good.  It is cle= ar and well written and I think it is a valuable resource. 

As I am late to looking at this dra= ft please take this only as a comment from a narrow minded engineer ;-)&nbs= p;  After the rationale, explanations and caveats I kept looking for h= ow to implement a NTA.  After initially thinking this would be the int= roduction of some new functionality and RRset manipulation, I only found a = reference to how Unbound implements it.

So it might be useful to have section 2 “Definition ..&= #8221; make that clear for slow people like me - that the NTA is not an RR = and is more of a configuration.  Maybe simply replacing “placed&= #8221; with “implemented” in section 2?  “This NTA c= an potentially be [placed][implemented] at any level within the chain of tr= ust…”

Feel fre= e to ignore of this thread has already been covered.   Regardless= of whether my comment makes sense, I do this this is a useful draft to hav= e.

 

-Rick

 

 

 

From: dnsop-bounces@ietf.org [mailto:= dnsop-bounces@ietf.org] On Behalf Of Livingood, Jason
Sent: Sunday, February 17, 2013 7:22 AM
To: dnsop@ietf.org
Subj= ect: [DNSOP] New draft-livingood-negative-trust-anchors-04

 

Based on feedback yesterday on the list, I did a quick –04 upd= ate, which is now at https://datatracker.ietf.org/doc/draft-= livingood-negative-trust-anchors/. 

 

 = ;

The are seven open issues docume= nted at the end of the I-D. But the most important questions for this = WG are:

1 – Is this worth co= nsideration as a WG I-D or should it continue only as an individual I-D?

2 – If the answer to #1 is tha= t it should be a WG I-D, would you like a brief discussion of the open issu= es at IETF 86?

 

Thanks!

Jason

 

 

<= /div>= --_000_5648A8908CCB564EBF46E2BC904A75B15EFE3B5477EXVPMBX1001ex_-- From jabley@hopcount.ca Wed Feb 20 10:52:35 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3992021F8991 for ; Wed, 20 Feb 2013 10:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.429 X-Spam-Level: X-Spam-Status: No, score=-100.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLfozEx6PQWf for ; Wed, 20 Feb 2013 10:52:34 -0800 (PST) Received: from mail-yh0-x234.google.com (yh-in-x0234.1e100.net [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7F64121F88EF for ; Wed, 20 Feb 2013 10:52:19 -0800 (PST) Received: by mail-yh0-f52.google.com with SMTP id q46so1503068yhf.11 for ; Wed, 20 Feb 2013 10:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=gWwpjIyfqGVU4LZiwrdR3EuZi2M8etvqAZFtO7ckN1s=; b=BxrD1U2yikzdnb+ajUlZNsuSbdf/oT8f5wBuO0PGBb8MKv/i0AIjfaOiWvI0LWnOvW BT+JmhLIjAkMzCX5dl4TALAO8J4z3Bw0wyTP83WjJe8jWjcuiMzzchLxpPQ11SmeDD2Y 7l7rcIQCbb1mRSr0lGieMnCDG1govtrw6cIAI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=gWwpjIyfqGVU4LZiwrdR3EuZi2M8etvqAZFtO7ckN1s=; b=dxBiBLobNmapPM8rULBUUgPgxiHt9QK6tarqRRU/tP/aTmvH5lwRW0SfrKQq74j30p D34K2WXgrvssW006LG6KIg7mSUnXlbzTr0XfgjqodVG46SMe+EktXPKNbNzyo8BlFUwq zA2x/5/68jX7WtABLY8Z3mJlURNE5KkX9Qqt47tJmdWCSWhuGEV3PaxSj1NpLUSrDVcW /9ORSpyCZ3nMjUZNnNUApdYVLtAjHOmjkaPoCDp5iNZczp8LtQt8FwReOuYL6jTNybNo cWgEPI3Cj3NJAxSlcdbYxukFFWfZwzoOeC/0BngSJKMjp6mUev18h7peB32zLKxZ/QRN Y+UA== X-Received: by 10.236.137.107 with SMTP id x71mr39442160yhi.2.1361386338647; Wed, 20 Feb 2013 10:52:18 -0800 (PST) Received: from [10.10.0.105] ([190.213.2.61]) by mx.google.com with ESMTPS id x16sm134665887yhj.6.2013.02.20.10.52.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 10:52:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B15EFE3B5477@EXVPMBX100-1.exc.icann.org> Date: Wed, 20 Feb 2013 14:52:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E50A016-54F0-473A-B1C9-9C1111275C96@hopcount.ca> References: <10229F86C86EB444898E629583FD4171616521A5@PACDCEXMB06.cable.comcast.com> <10229F86C86EB444898E629583FD417161653607@PACDCEXMB06.cable.comcast.com> <5648A8908CCB564EBF46E2BC904A75B15EFE3B5477@EXVPMBX100-1.exc.icann.org> To: Richard Lamb X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQk2pTyuU7+pc6VktbHXVxXIN0wmvNG99L9hS6ilv+yin2XuYWHZvuObFYcOdvYjsjRSM9Ux Cc: "dnsop@ietf.org" , "Livingood, Jason" Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:52:35 -0000 On 2013-02-20, at 14:50, Richard Lamb wrote: > FWIW: The -04 draft looks good. It is clear and well written and I = think it is a valuable resource.=20 > As I am late to looking at this draft please take this only as a = comment from a narrow minded engineer ;-) After the rationale, = explanations and caveats I kept looking for how to implement a NTA. +1 The text seems to lead in that direction, and then end abruptly leaving = the reader wondering what happened. Leaving room for a sequel? :-) Joe From scott.rose@nist.gov Wed Feb 20 10:54:42 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5738221F88EF for ; Wed, 20 Feb 2013 10:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seFyxNGLIRML for ; Wed, 20 Feb 2013 10:54:41 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDB021F8886 for ; Wed, 20 Feb 2013 10:54:41 -0800 (PST) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 20 Feb 2013 13:54:36 -0500 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.123.3; Wed, 20 Feb 2013 13:54:40 -0500 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id r1KIsd70018093 for ; Wed, 20 Feb 2013 13:54:40 -0500 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1283) From: Scott Rose In-Reply-To: Date: Wed, 20 Feb 2013 13:54:39 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6BEDC468-4A06-466F-B933-6FFF0D6B6E0D@nist.gov> References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> To: "dnsop@ietf.org WG" X-Mailer: Apple Mail (2.1283) Subject: Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:54:42 -0000 On Feb 19, 2013, at 4:00 PM, Paul Wouters wrote: >=20 >=20 >> 5) (this is tricky !) Security section states : "not for initial = enrollment" >> Why not ? >=20 > There is no path of trust! >=20 +1, I think the draft should keep the recommendation that this is not = for initial enrollment. =20 One other comment in Section 5.1, last paragraph: If the child zone = does go unsigned, the parental agent should not (or SHOULD NOT) treat = that as intent to go unsigned since that could be an attack. An = attacker could spoof unsigned responses to queries from the parental = agent in an attempt to force a break in the DNSSEC chain. We had this = discussion on how to respond to signed .gov zones that erred and = stripped their own RRSIGs/DNSKEYs. =20 Minor quip: Section 4: 'It is conceivable that this could be a "value added" = service"' Really doesn't belong in a protocol spec and really doesn't = add anything. Suggest dropping it. Registrars/service providers can = figure that out on their own (if they haven't already).=20 Scott > Paul > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From marka@isc.org Wed Feb 20 12:47:00 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A191B21E803A for ; Wed, 20 Feb 2013 12:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knNL4GRr3gjB for ; Wed, 20 Feb 2013 12:46:59 -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 BF85B21E8039 for ; Wed, 20 Feb 2013 12:46:59 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5F7D1C9480; Wed, 20 Feb 2013 20:46:57 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361393219; bh=RUT4as9K2cgRXqj+6UlqKj0STJx360WxvYBop+gN4wo=; h=To:From:References:Subject:In-reply-to:Date; b=BKCjFN8Z4LovsoqMLWKNONxFKlB9Wpt9r2ush0VtXmhx2qxV4pkUHKGZ31sM4iXnG HZ+xJoAM6j1qy2APWeI8skyf0ESSt6N8wCUlezWBr+TyBPJKGJL+uzGiWWXPK3CKek BwMuvIDFJ+QJ9ViB4U3FZ5C6YJVm6a4k0E5Y5yBY= 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; Wed, 20 Feb 2013 20:46:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c1c8:e29:43a6:6de]) (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 1EF66216C40; Wed, 20 Feb 2013 20:46:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8ABD02FEA123; Thu, 21 Feb 2013 07:46:54 +1100 (EST) To: Erik Kline , Peter Koch , IETF DNSOP WG From: Mark Andrews References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> Mail-Followup-To: Erik Kline , Peter Koch , IETF DNSOP WG In-reply-to: Your message of "Wed, 20 Feb 2013 09:36:47 BST." <20130220083647.GA8527@miek.nl> Date: Thu, 21 Feb 2013 07:46:54 +1100 Message-Id: <20130220204654.8ABD02FEA123@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:47:00 -0000 While I think we should adopt the document I have grave concerns about it. * there is no demonstrated need for it. * it is likely to interact badly with validating resolvers especially when there are lots of labels in the qname below the delegation to these servers. * it changes the response from NXDOMAIN to NOERROR NODATA. If we have to build special servers can't they periodically transfer a list of zones they need to serve rather than return what is essentially the wrong answer? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ggm@algebras.org Thu Feb 21 14:58:56 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CD721E8041 for ; Thu, 21 Feb 2013 14:58:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B97EpLnrgZTZ for ; Thu, 21 Feb 2013 14:58:55 -0800 (PST) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by ietfa.amsl.com (Postfix) with ESMTP id B1D2D21E803D for ; Thu, 21 Feb 2013 14:58:55 -0800 (PST) Received: by mail-da0-f41.google.com with SMTP id e20so25931dak.28 for ; Thu, 21 Feb 2013 14:58:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=0cVc39qsTRy8xnNEGMUki+2DXnmxNMy7qLcAT905UHg=; b=FCMUnEFHbHiRLQ4pBK2bE9Fuqq+BM8Jr4FoVAkvej4NkYKXfkzqv1mtMIjb4reLBEK K6SJZo2FzVZ97DQgIwtCI2SBQrxbk4ad6NqJESEkiJXL4fgpgUoEpg/qMnRVyo0zh0Uo QBBcg0/XNGptHDcCl42jfthGkykUvYgiRT+I6dqSVnxt+w7S3r62zJDJR1gC2NakmTzN CULNx0EiNHUoazVtV0PSokVobWfTRyuoHUkjVtzE6VKyIXCOSQl+2pjRmJY284k/jSEs vrgKbioFCv6mYw9qfhaxegt8SjcmUtNAVrJPAusq7z0vC4QPd1OjVBQ5YpqSYLBF742I G+Yg== X-Received: by 10.68.189.99 with SMTP id gh3mr10729339pbc.203.1361487535519; Thu, 21 Feb 2013 14:58:55 -0800 (PST) Received: from ?IPv6:2001:dc0:a000:4:a13b:59a9:55fd:98ea? ([2001:dc0:a000:4:a13b:59a9:55fd:98ea]) by mx.google.com with ESMTPS id w2sm512665pax.22.2013.02.21.14.58.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 14:58:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: George Michaelson In-Reply-To: <20130220204654.8ABD02FEA123@drugs.dv.isc.org> Date: Fri, 22 Feb 2013 08:58:55 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmvyBZAQylkJWhR9vLdCF3XAwhxLzLvREHLVviRjxxUlS/HAsWjscFuT/IBVNQLtF5t8KU/ Cc: Erik Kline , Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:58:56 -0000 On 21/02/2013, at 6:46 AM, Mark Andrews wrote: >=20 > While I think we should adopt the document I have grave concerns > about it. >=20 > * there is no demonstrated need for it. thats opinion, not fact Mark. 'demonstrated need' stems from other = people's desires. you might as well come out and say you think AS112 has no demonstrated = need, as say this draft has no role in administration of AS112. I tend to another opinion. I think this draft identifies a sensible path = to making AS112 servers respond the way we want. > * it is likely to interact badly with validating resolvers especially > when there are lots of labels in the qname below the delegation to > these servers. AS112 is designed to offer a quick termination of query hunting to a = non-value. Can you explain how this fails to be satisfied by a wildcard = response, when we are seeking to divert a query WHICH CANNOT BE ANSWERED = IN THE WIDER NET to a 'not' answer?=20 the internal side of anyone who has valid delegation of a domain which = has hit an AS112 can have as much DNSSEC as they want. its everyone = else, who sees the sideblow queries who needs this. I am probably being thick. can you do an illustrative instance of what = you mean here? > * it changes the response from NXDOMAIN to NOERROR NODATA. And why is that "wrong" ? I dont understand what you see as the = outcomes. more query? bad DNS? load? >=20 > If we have to build special servers can't they periodically transfer > a list of zones they need to serve rather than return what is > essentially the wrong answer? the back-end administration has proved fraught. btw, I continue to collect data on the volume of ULA, link-local, teredo = traffic in reverse, and it continues to grow.. -George >=20 > Mark > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From marka@isc.org Thu Feb 21 21:47:15 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F60921F8A33 for ; Thu, 21 Feb 2013 21:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqYp45cHSWdD for ; Thu, 21 Feb 2013 21:47:14 -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 C23D521F8A18 for ; Thu, 21 Feb 2013 21:47:13 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id EBC25C9518; Fri, 22 Feb 2013 05:47:04 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361512033; bh=yKegv1ZLj+XU8Fr9KdZ63OEE/fk7LeZNJ+fN7eyaZnM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=DZ7pGY81a7LEWU4kqsunY1ZxZ+J+Gx2LWz4o5MqP5h/g8WVmB/YzeW2AAY1DfkfVG oC73dpjQkqccyrYsmpcyEnA3jEBAQz2A3cwvk3752rmksC+R07J8BshQKDwLzd7dc9 6da1135gQA23MfnAas2pO+1FJZtRF+M2P38GDKYc= 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; Fri, 22 Feb 2013 05:47:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8EA67216C40; Fri, 22 Feb 2013 05:47:04 +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 2A7232FF489B; Fri, 22 Feb 2013 16:47:00 +1100 (EST) To: George Michaelson From: Mark Andrews References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> In-reply-to: Your message of "Fri, 22 Feb 2013 08:58:55 +1000." Date: Fri, 22 Feb 2013 16:47:00 +1100 Message-Id: <20130222054700.2A7232FF489B@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Erik Kline , Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 05:47:15 -0000 In message , George Michaels on writes: > > On 21/02/2013, at 6:46 AM, Mark Andrews wrote: > > > > > While I think we should adopt the document I have grave concerns > > about it. > > > > * there is no demonstrated need for it. > > thats opinion, not fact Mark. 'demonstrated need' stems from other > people's desires. > > > you might as well come out and say you think AS112 has no demonstrated > need, as say this draft has no role in administration of AS112. > > I tend to another opinion. I think this draft identifies a sensible path > to making AS112 servers respond the way we want. > > > * it is likely to interact badly with validating resolvers especially > > when there are lots of labels in the qname below the delegation to > > these servers. > > AS112 is designed to offer a quick termination of query hunting to a > non-value. > Can you explain how this fails to be satisfied by a wildcard response, > when we are seeking to divert a query WHICH CANNOT BE ANSWERED IN THE > WIDER NET to a 'not' answer? It's not a wild card response. > the internal side of anyone who has valid delegation of a domain which = > has hit an AS112 can have as much DNSSEC as they want. its everyone = > else, who sees the sideblow queries who needs this. It's the impact on those that are validating but don't have default local zones of equivalent. There a 30 delegations between d.f.ip6.arpa and the full reverse of a ULA under this proposal. Hunting for missing DS records will hit every one of them. > I am probably being thick. can you do an illustrative instance of what > you mean here? > > > > * it changes the response from NXDOMAIN to NOERROR NODATA. > > And why is that "wrong" ? I dont understand what you see as the outcomes. > more query? bad DNS? load? For much the same reason that *.COM was bad. You *will* break things that you are unaware of. > > If we have to build special servers can't they periodically transfer > > a list of zones they need to serve rather than return what is > > essentially the wrong answer? > > the back-end administration has proved fraught. > > btw, I continue to collect data on the volume of ULA, link-local, teredo > traffic in reverse, and it continues to grow.. And the traffic stats are where? The analysis of the recursive servers that are sending this traffic is where? Vendor, version, isp. Is it worth adding the terado prefix to locally served zones registry? > -George > > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nick@inex.ie Fri Feb 22 02:23:40 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4D721F8E40 for ; Fri, 22 Feb 2013 02:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJrRyXox-1JX for ; Fri, 22 Feb 2013 02:23:36 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAB421F847C for ; Fri, 22 Feb 2013 02:23:31 -0800 (PST) X-Envelope-To: dnsop@ietf.org Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r1MAKjHx060070 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Feb 2013 10:20:45 GMT (envelope-from nick@inex.ie) Message-ID: <51274721.1030308@inex.ie> Date: Fri, 22 Feb 2013 10:23:29 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mark Andrews References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> In-Reply-To: <20130222054700.2A7232FF489B@drugs.dv.isc.org> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 10:23:40 -0000 On 22/02/2013 05:47, Mark Andrews wrote: > For much the same reason that *.COM was bad. *.com was certainly evil, but I don't think it's necessarily fair to compare the two, given the different usage scope of forward and reverse domains. > You *will* break things that you are unaware of. can you quantify / clarify any things which you think it will break? Nick From jabley@hopcount.ca Fri Feb 22 03:01:36 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDBA21F8E51 for ; Fri, 22 Feb 2013 03:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.014 X-Spam-Level: X-Spam-Status: No, score=-102.014 tagged_above=-999 required=5 tests=[AWL=1.585, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yp2eHOonTzi for ; Fri, 22 Feb 2013 03:01:35 -0800 (PST) Received: from mail-gh0-f169.google.com (mail-gh0-f169.google.com [209.85.160.169]) by ietfa.amsl.com (Postfix) with ESMTP id ED75821F8E47 for ; Fri, 22 Feb 2013 03:01:33 -0800 (PST) Received: by mail-gh0-f169.google.com with SMTP id r18so84838ghr.28 for ; Fri, 22 Feb 2013 03:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=LjvH83348cOHyyatH70AXluVNVH/TGEa9V99YI0bgos=; b=fDBLUIsqcoEGv914528k1Lhi8HIMJS9b63+7T+44F3G2dc3MCnu7yjH+jrXOBtM/Us jZDLtHWBK/7O5Cdhh5pOZL6GgIx5gUx1R5kyYfxpSvMq1XQDTGcOt7yVHXA/52g7/+Zs JBhKDegN/bHGt7GjLZcftTDEYvW61Kocll/Mo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=LjvH83348cOHyyatH70AXluVNVH/TGEa9V99YI0bgos=; b=ZAIcuM4XGldvbtpuob1Ac61UK/kjOMQQUqTR6VGyT1BvWUGLRnXQeNzkpdM6I9hbxh aWzwgkifnbu4JaPj1BI55+YDjZnFkpfZhXIQtBZeUtNF4QLZWsUTVCjuAd3KR/yU3PeV mWGJZqtDY7qXHRmWyuapUL0e/OVjCcFh+b5IIoGLomBkpnUePQ79zOop/GxoV+h3UXZ/ BOV5kpAk+PNBiCLVc2M2u0f0TeuloYMcyuGxkHrqqcafXMH/118D4xaVkFZ/VUwGrOSh 8Ux3uuu6lbwdrYxZNB8lo7fa83CXJ4ib7ro+7vk29wntr17mujsG9V8dUchH+QX2IF03 KLfQ== X-Received: by 10.236.69.67 with SMTP id m43mr2951435yhd.40.1361530891687; Fri, 22 Feb 2013 03:01:31 -0800 (PST) Received: from [172.17.170.14] ([190.213.6.210]) by mx.google.com with ESMTPS id f29sm2665677anj.17.2013.02.22.03.01.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 03:01:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <20130222054700.2A7232FF489B@drugs.dv.isc.org> Date: Fri, 22 Feb 2013 07:01:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQm7S6SlyfH3xORTRrPobA/erdQciy1HpX+0Y6yXJ2s0KeqGUgSAUEm/i1YgFfnbPz15/WCd Cc: Erik Kline , Peter Koch , IETF DNSOP WG , George Michaelson Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:01:36 -0000 On 2013-02-22, at 01:47, Mark Andrews wrote: > In message , George = Michaels > on writes: >=20 >> On 21/02/2013, at 6:46 AM, Mark Andrews wrote: >>=20 >>> * it changes the response from NXDOMAIN to NOERROR NODATA. >>=20 >> And why is that "wrong" ? I dont understand what you see as the = outcomes.=20 >> more query? bad DNS? load? >=20 > For much the same reason that *.COM was bad. You *will* break things > that you are unaware of. For clarity, the reason why the spec specifies NOERROR NODATA rather = than NXDOMAIN is that the enclosing SOA is synthesised from the QNAME. Returning an NXDOMAIN with an SOA owner name of . was where we started, = and (as pointed out by many) that breaks negative caching for most/all = resolvers which is the opposite of what we want. Returning an NXDOMAIN with SOA owner name =3D=3D QNAME seems wrong, = since we're simultaneously saying that the name doesn't exist and = returning an RRSet with the same name. Guessing at a different owner name for the SOA seems bad because at this = point we're just making stuff up and surely it'll be wrong at least some = of the time, and break negative caching again. Returning NOERROR NODATA with SOA owner name =3D=3D QNAME seemed like = the best option. It's still a form of negative response, which = (according to our testing) is cached in a way that makes sense. For the record, we realise this is a hack. But it's a hack that = facilitates new delegations to AS112 without risking lame delegations, = which would be bad in their own way (lame delegations are to be expected = when we have no central control over AS112 operators, and don't even = know where they are in general, never mind how to contact the people who = run them or check that they are not lame). Joe= From paul@redbarn.org Fri Feb 22 03:57:48 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7D621F8EAF for ; Fri, 22 Feb 2013 03:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRv7bVrMJiHL for ; Fri, 22 Feb 2013 03:57:47 -0800 (PST) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id AEEA421F8E95 for ; Fri, 22 Feb 2013 03:57:47 -0800 (PST) Received: from [172.17.201.142] (unknown [80.67.104.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 6977AEBCE3; Fri, 22 Feb 2013 11:57:37 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <51275D39.1070806@redbarn.org> Date: Fri, 22 Feb 2013 03:57:45 -0800 From: Paul Vixie User-Agent: Postbox 3.0.7 (Windows/20130120) MIME-Version: 1.0 To: Joe Abley References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: George Michaelson , Erik Kline , Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:57:48 -0000 if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. noerror/nodata is the wrong answer. From mansaxel@besserwisser.org Fri Feb 22 04:07:53 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F5B21F8EE6 for ; Fri, 22 Feb 2013 04:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpo9CIKvQmWk for ; Fri, 22 Feb 2013 04:07:51 -0800 (PST) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id ECD2521F8EDC for ; Fri, 22 Feb 2013 04:07:40 -0800 (PST) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 085989E59; Fri, 22 Feb 2013 13:07:38 +0100 (CET) Date: Fri, 22 Feb 2013 13:07:38 +0100 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Paul Vixie Message-ID: <20130222120738.GA2473@besserwisser.org> References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <51275D39.1070806@redbarn.org> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IETF DNSOP WG , Erik Kline , Peter Koch , Joe Abley , George Michaelson Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 12:07:53 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [DNSOP] Adoption of as a WG work item? Date: Fri, Feb 22, 2013 at 03:57:45AM -0800 Quoting = Paul Vixie (paul@redbarn.org): > if we can't return nxdomain, then i'm opposed to the omniscient spec, > and we should continue as before, enumerating on the responding servers > every zone to which we wish to delegate. >=20 > noerror/nodata is the wrong answer. As Randy Bush suggested, some 10 years ago, accept dynupdates, and serve th= at ;-)=20 An U-turn for fertilizer.=20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Hand me a pair of leather pants and a CASIO keyboard -- I'm living for toda= y! --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlEnX4oACgkQ02/pMZDM1cU60wCeNS/ch+Z1vgXiBL7o9u6K51QU qBgAoI8PVlqgX6G5KnKr+BdMDMZ3bG5n =Rnfb -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From jabley@hopcount.ca Fri Feb 22 04:41:24 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9192621F8EBE for ; Fri, 22 Feb 2013 04:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.222 X-Spam-Level: X-Spam-Status: No, score=-101.222 tagged_above=-999 required=5 tests=[AWL=-0.792, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVhvushpLGDt for ; Fri, 22 Feb 2013 04:41:23 -0800 (PST) Received: from mail-gg0-x22b.google.com (mail-gg0-x22b.google.com [IPv6:2607:f8b0:4002:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CA2A521F8EB3 for ; Fri, 22 Feb 2013 04:41:23 -0800 (PST) Received: by mail-gg0-f171.google.com with SMTP id j1so97769ggn.16 for ; Fri, 22 Feb 2013 04:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=kde8NZL/aR9kkykGAqmda1Y6XrZB9ixfHggRhkwmNCs=; b=cXqluhv+TxTlgvQqbbQ6zh/P5mskOsOIaSSLgCEv31eljbCagjykjZjUVGoamLiCLW zJjo3juqsXIFifwdPGE+S5Zo8yE2536/ce1OeGlKixtrcU0WjWQMN7Jrt1sQYksJi+Wy 6OctOELmwUpWTUqroaIWpaFw5pYwC+vMqd8PA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=kde8NZL/aR9kkykGAqmda1Y6XrZB9ixfHggRhkwmNCs=; b=cfI3yApUUO98vr2FPBY0Wtz8QrUP99wqJIFbP+eSEZrpQVhhhZUozVFYtk/J9eLan/ /65wlqjEdH89E5rZwZg7uK+vOqni6jcgwHybPENM8dWHyXp3+cy5Eq4wjGUwVmQn41jF f4z28ZVkmHC202gf/iVqNsgRjwkB42mZ+rPyR2/UyFXU7nNUlTZ0SH8X1qWWjJsVZbjK WeqY0PC0bilhNk4SSKt/YNvNS2xi18OxZ/CcggJboOMxTORpdAX8LtaQ9+NCX25LAhGS 8bEpCkYUtPKLeZZ86m2fvN12umi9ObHO2CrwH+uWWxf2xS8eXHt52qP2dvaW3BTnPxqf csiw== X-Received: by 10.236.69.67 with SMTP id m43mr3510566yhd.40.1361536883337; Fri, 22 Feb 2013 04:41:23 -0800 (PST) Received: from [10.10.0.105] ([190.213.2.61]) by mx.google.com with ESMTPS id y14sm3024853anm.14.2013.02.22.04.41.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 04:41:22 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <51275D39.1070806@redbarn.org> Date: Fri, 22 Feb 2013 08:41:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnG8WzykDiAW536TM0bNu8xp8e/nydkk+JJLryO+xHnVhw3YFl6xi+QvS1KAGCPQM+vTWVF Cc: George Michaelson , Erik Kline , Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 12:41:24 -0000 On 2013-02-22, at 07:57, Paul Vixie wrote: > if we can't return nxdomain, then i'm opposed to the omniscient spec, > and we should continue as before, enumerating on the responding = servers > every zone to which we wish to delegate. >=20 > noerror/nodata is the wrong answer. It does smell a bit wrong, but I'm interested in more details of why you = think that if it's more than just the smell. I'll note that the proposal is to assign new nameservers to be = omniscient, and not to convert the existing ones. We are then in a = position to delegate other local-zoneish zones to the new servers and = review the impact. So, the suggestion is not to replace the existing AS112 servers = (blackhole-1, blackhole-2 and prisoner) out of the gate. Any such = replacement would happen later, once there was some degree of comfort = that it was safe to do that. Joe= From marka@isc.org Fri Feb 22 05:39:18 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B6C21F8E2E for ; Fri, 22 Feb 2013 05:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrtpu17spKNX for ; Fri, 22 Feb 2013 05:39:17 -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 B782421F8E2C for ; Fri, 22 Feb 2013 05:39:17 -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 3A93D5F98F4; Fri, 22 Feb 2013 13:39:06 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361540356; bh=a92rQ4cK/gdTTiBbv9EmGZ68abOLI2wmzFxmnYyUjbc=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=rFvoDcKC8RdG48ClR0xKP5Z4Yrw3IRUFi0r5hYvrMlMiuv/i9Y2nnCZytkdt1QPUb ksaF0BIa5TPqI+/EEd1CcDjnb50tqZqFKoPxPNqNuq0Ggjk4oygLY0bRk3C2apEvS2 ZS1Xk6lKKFHssMH2LRMIYgDkod2mtvKFd6QpdQ/s= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 80D4A216C3B; Fri, 22 Feb 2013 13:39:04 +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 9544F2FF9F2A; Sat, 23 Feb 2013 00:39:01 +1100 (EST) To: Nick Hilliard From: Mark Andrews References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51274721.1030308@inex.ie> In-reply-to: Your message of "Fri, 22 Feb 2013 10:23:29 -0000." <51274721.1030308@inex.ie> Date: Sat, 23 Feb 2013 00:39:01 +1100 Message-Id: <20130222133901.9544F2FF9F2A@drugs.dv.isc.org> Cc: IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:39:18 -0000 In message <51274721.1030308@inex.ie>, Nick Hilliard writes: > On 22/02/2013 05:47, Mark Andrews wrote: > > For much the same reason that *.COM was bad. > > *.com was certainly evil, but I don't think it's necessarily fair to > compare the two, given the different usage scope of forward and reverse > domains. > > > You *will* break things that you are unaware of. > > can you quantify / clarify any things which you think it will break? I can well imagine a machine doing a reverse lookup on a proposed address and not proceeding with that address if it doesn't get a NXDOMAIN. NODATA -> unsafe NXDOMAIN -> may be safe The problem is that we don't know what changing the status quo will do. We have to be very cautious about doing that. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jabley@hopcount.ca Fri Feb 22 05:49:15 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA7C21F8E17 for ; Fri, 22 Feb 2013 05:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.957 X-Spam-Level: X-Spam-Status: No, score=-100.957 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm5CyPoYhCMP for ; Fri, 22 Feb 2013 05:49:15 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id D9E9921F8EAF for ; Fri, 22 Feb 2013 05:49:14 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id q3so111105yhf.12 for ; Fri, 22 Feb 2013 05:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=OxvJ0K6/lE6OBPWGIkrl/sk3XGAAAsdQNJ1q+1MDH78=; b=foM1GJ5ICKnpfsG77uXrnb4Wilq6LaINDzmZ93aHdi5IqwlqNxf5NOvI0mGnVhMJiE /qjD5K64NFxGiHpRaBwfb2snOWjh15CJrvVINpRzrPp03vLzisgiVhipWgcS/jMvE9my +7mVoL4zKLjkF/FhTVihKAuXUxnnkZu9aLMpY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=OxvJ0K6/lE6OBPWGIkrl/sk3XGAAAsdQNJ1q+1MDH78=; b=FnfGXcvbEOZhXShVFdjH6fmpxXftFR1SIPyyzKJh4H7qnmd1gHIVIjbtaTh9GELsBB LrVe0FgE7zPmnrVbayxYmw/yDtUU2fryWH1c4QvK81GawNbrmvsrk5e086rt7Or/wGjw 2v+5UNILzzJv5CoqVsn1AVcKmaqpE3C2vfImz7SFDE5mZA6/50OlbyIb3wlX4hvNad36 8Ot8J+tg9Y+WVp6cUEb/Q+DG/8Yz7XP1Hq6E0MKdw1GnlFpEJeXb4B4W8EPB3b+GFLkC S2ytQch8SQTE3bwXWzwj63YqIjW1/tbnEgARh0q+sxs2MgLLHwaf3stsTiTFkCB77F7p dxYA== X-Received: by 10.101.143.14 with SMTP id v14mr1078899ann.59.1361540954369; Fri, 22 Feb 2013 05:49:14 -0800 (PST) Received: from [10.10.0.105] ([190.213.2.61]) by mx.google.com with ESMTPS id o8sm3275717ani.4.2013.02.22.05.49.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 05:49:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <20130222133901.9544F2FF9F2A@drugs.dv.isc.org> Date: Fri, 22 Feb 2013 09:49:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D64BE69-A3B3-4D6E-8D78-24A3F13DCA59@hopcount.ca> References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51274721.1030308@inex.ie> <20130222133901.9544F2FF9F2A@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkQ2Op69NftzSgA6ynM+Ij8SkoPBkenAZFCDUtL8RCrg3gFkFy3BoifnUNk+Y4xCVek020l Cc: IETF DNSOP WG , Nick Hilliard Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:49:15 -0000 On 2013-02-22, at 09:39, Mark Andrews wrote: > I can well imagine a machine doing a reverse lookup on a proposed > address and not proceeding with that address if it doesn't get a > NXDOMAIN. >=20 > NODATA -> unsafe > NXDOMAIN -> may be safe So, out of interest, do you think it's legitimate for an omniscient = server to return something like this? (note the RCODE and the SOA RRSet = returned in the authority section) ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41208 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;1.1.1.10.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 1.1.1.10.in-addr.arpa. 604800 IN SOA prisoner.iana.org. = hostmaster.root-servers.org. 1 1800 900 604800 604800 ;; Query time: 3 msec ;; SERVER: 192.175.48.6#53(192.175.48.6) ;; WHEN: Fri Feb 22 13:45:36 2013 ;; MSG SIZE rcvd: 116 That would be a simple change to the spec. We chose NOERROR/ANSWER:0 = because we thought it didn't make sense to say NXDOMAIN whilst at the = same time synthesising an authority-section SOA with the same owner name = as the QNAME when the RCODE we're returning indicates that that owner = name doesn't exist. As someone familiar with implementing the receiver side of this hack, = would/should this negative answer be cached? Joe= From nick@inex.ie Fri Feb 22 06:42:27 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B30421F8E74 for ; Fri, 22 Feb 2013 06:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89Tcf114FSSM for ; Fri, 22 Feb 2013 06:42:27 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id A537121F8E4E for ; Fri, 22 Feb 2013 06:42:25 -0800 (PST) X-Envelope-To: dnsop@ietf.org Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r1MEdd4a061318 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Feb 2013 14:39:40 GMT (envelope-from nick@inex.ie) Message-ID: <512783D0.1020007@inex.ie> Date: Fri, 22 Feb 2013 14:42:24 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mark Andrews References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51274721.1030308@inex.ie> <20130222133901.9544F2FF9F2A@drugs.dv.isc.org> In-Reply-To: <20130222133901.9544F2FF9F2A@drugs.dv.isc.org> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:42:27 -0000 On 22/02/2013 13:39, Mark Andrews wrote: > The problem is that we don't know what changing the status quo will > do. We have to be very cautious about doing that. I agree we should be cautious. So why not run it on some as112 servers on a pilot basis and see what happens? Full logging would be required, as well as some idea of what sort of problems to look for (e.g. multiple repeated queries from the same source, etc). Does this seem sensible? Nick From jabley@hopcount.ca Fri Feb 22 06:50:02 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2B921F867D for ; Fri, 22 Feb 2013 06:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.101 X-Spam-Level: X-Spam-Status: No, score=-102.101 tagged_above=-999 required=5 tests=[AWL=0.879, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AImUa6N9IzgS for ; Fri, 22 Feb 2013 06:50:01 -0800 (PST) Received: from mail-ye0-f170.google.com (mail-ye0-f170.google.com [209.85.213.170]) by ietfa.amsl.com (Postfix) with ESMTP id 96FD021F865D for ; Fri, 22 Feb 2013 06:50:01 -0800 (PST) Received: by mail-ye0-f170.google.com with SMTP id r5so57569yen.15 for ; Fri, 22 Feb 2013 06:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=MqBVilvYWXczqXMBlG8sX2GXgRHghCg5vOPZtRE1fbM=; b=c6B1iRycrhm2uqLuet57JFn9aSHRpju3/rUhLh/OajkLtIqicXztTrHEbXV3oKRd5P Ku9/UsiE7rl770Pm+YOxF99A30LJkPBCeg6PtzTSoHyo7WqcE9HuBgpHhfeJvRbrcp8u LQdUPCxBE75j82mldaBNeMdENugrFeD+FQOr0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MqBVilvYWXczqXMBlG8sX2GXgRHghCg5vOPZtRE1fbM=; b=ljtc7I+WSIluhtF/KAi3Bxler3xwYk2U50l4MBaYNZu7Q/WVvoH0DhVqEotpvEJuRk asoErWDgjLrlU1YblZMn+qOkvAqwH81BsoqOywuanSs2cEDx0GK3DrzCOvkCd9GCY+BZ z5NZbtSVEhuEeX5DYkaRULWUQ5llIScU/G0+gYTkMrwOO4u9vraXLGTLvSlyEkQ4l3f3 SKaAak5NL62S5Wg+BHd6mBW+ZWSnYp7WQu0LuySlUJRD16lY+ATDE11rE+R5tAZ8WUON K60tnyGkSAQkjLM+OotXU4WFG3dICpkHfMUcljWn9USbKXRcsueahdBrWrcWdj7OEIcT 8AwA== X-Received: by 10.236.129.72 with SMTP id g48mr4115800yhi.102.1361544600989; Fri, 22 Feb 2013 06:50:00 -0800 (PST) Received: from [10.10.0.105] ([190.213.2.61]) by mx.google.com with ESMTPS id s74sm6267002yhh.5.2013.02.22.06.49.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 06:49:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <512783D0.1020007@inex.ie> Date: Fri, 22 Feb 2013 10:49:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51274721.1030308@inex.ie> <20130222133901.9544F2FF9F2A@drugs.dv.isc.org> <512783D0.1020007@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmRmaKWT3b1T1CY4kxVljgDgHYDngV5br2pYdxaxGy9B/JUIKn1H9wSY3aHGVgkcQg91A2a Cc: IETF DNSOP WG Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:50:02 -0000 On 2013-02-22, at 10:42, Nick Hilliard wrote: > I agree we should be cautious. So why not run it on some as112 = servers on > a pilot basis and see what happens? Full logging would be required, = as > well as some idea of what sort of problems to look for (e.g. multiple > repeated queries from the same source, etc). Does this seem sensible? I think an even more cautious approach would be to run it for zones that = are not currently served by AS112 (e.g. those in the locally-served = zones registry that are not currently delegated to AS112 servers). Providing omniscient servers on different addresses (so, a different = anycast cloud, but presumably with overlaps with the current one) and = leaving the existing AS112 servers untouched would give us some field = experience with zero jeopardy for existing assumptions about AS112 = service. Joe= From bdickson@verisign.com Fri Feb 22 08:33:45 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0BE21F84D5 for ; Fri, 22 Feb 2013 08:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xkyghp7x+av8 for ; Fri, 22 Feb 2013 08:33:44 -0800 (PST) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id D2D9921F84C7 for ; Fri, 22 Feb 2013 08:33:40 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUSed4ciHrvMvjarRepePR60t+LD6wz7V@postini.com; Fri, 22 Feb 2013 08:33:44 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r1MGXQlu028476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 11:33:30 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 22 Feb 2013 11:33:26 -0500 From: "Dickson, Brian" To: Joe Abley , Mark Andrews Thread-Topic: [DNSOP] Adoption of as a WG work item? Thread-Index: AQHOERpWz0IiVTnK+EycGmjd8mjiRA== Date: Fri, 22 Feb 2013 16:33:25 +0000 Message-ID: In-Reply-To: <8D64BE69-A3B3-4D6E-8D78-24A3F13DCA59@hopcount.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E5E31B1519FBB4D8469C62C54BB1691@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF DNSOP WG , Nick Hilliard Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:33:45 -0000 One question/caveat: What would the practical impact be, if the TTL on the SOA were the same as the default negative caching TTL (for the NXDOMAIN)? I think it would be slightly less sniffy, to have the NXDOMAIN and the synthesized SOA both disappear at the same time. IIRC, the TTL would then need to be 900 rather than 604800. Brian On 2/22/13 8:49 AM, "Joe Abley" wrote: > >On 2013-02-22, at 09:39, Mark Andrews wrote: > >> I can well imagine a machine doing a reverse lookup on a proposed >> address and not proceeding with that address if it doesn't get a >> NXDOMAIN. >>=20 >> NODATA -> unsafe >> NXDOMAIN -> may be safe > >So, out of interest, do you think it's legitimate for an omniscient >server to return something like this? (note the RCODE and the SOA RRSet >returned in the authority section) > >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41208 >;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >;; WARNING: recursion requested but not available > >;; QUESTION SECTION: >;1.1.1.10.in-addr.arpa. IN PTR > >;; AUTHORITY SECTION: >1.1.1.10.in-addr.arpa. 604800 IN SOA prisoner.iana.org. >hostmaster.root-servers.org. 1 1800 900 604800 604800 > >;; Query time: 3 msec >;; SERVER: 192.175.48.6#53(192.175.48.6) >;; WHEN: Fri Feb 22 13:45:36 2013 >;; MSG SIZE rcvd: 116 > >That would be a simple change to the spec. We chose NOERROR/ANSWER:0 >because we thought it didn't make sense to say NXDOMAIN whilst at the >same time synthesising an authority-section SOA with the same owner name >as the QNAME when the RCODE we're returning indicates that that owner >name doesn't exist. > >As someone familiar with implementing the receiver side of this hack, >would/should this negative answer be cached? > > >Joe >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop From jabley@hopcount.ca Fri Feb 22 08:43:48 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165C621F85FE for ; Fri, 22 Feb 2013 08:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSrphUo8ssPe for ; Fri, 22 Feb 2013 08:43:47 -0800 (PST) Received: from mail-ye0-f175.google.com (mail-ye0-f175.google.com [209.85.213.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0F421F85D0 for ; Fri, 22 Feb 2013 08:43:47 -0800 (PST) Received: by mail-ye0-f175.google.com with SMTP id j12so149284yeg.20 for ; Fri, 22 Feb 2013 08:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=EMvd+BXNqNBEOLxuXpC7wMPSwsXFgcJxWm7M2pkkj2Q=; b=ATckZppRWWRt5yAGJB3CIlToOUFb57U9xhO9Q0AVADu+Q1JP0dp3YKKb0SRXhouhtM BZyQtecAlkoFEQLu0CG3dq1T6ydPiLzLAQqmecK+gbg5TdS1fu8NT8THFMne6JK1ZEcT 8OAtXMdFCqV+Nhm4TBqGVXXxmRIGGyh+Xdr2M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=EMvd+BXNqNBEOLxuXpC7wMPSwsXFgcJxWm7M2pkkj2Q=; b=hzmYeMvSIi+OEoUYLJPeBcRnlLt/Kxm+Q+SQVG6yVTSEONYgYgO+x/idM//KQipYF3 AYweCim9aY5XQy9cp/f2Pskh1Qb9KLh3wQScThy7Uln/l7Sr7WiveB284Zs1l7vNOxqG AafoiLi4H8r+ihHdC+QInvdgUPdxP2xgKZ+Ah56Oe+LC3XM+wT6xZvEVJacTuT0ZdwhY ypsH8waW1ap87aAJwqZLlqYfwMX3jyiybLI1so2EWw3SbGL318sOUv3rXFUFfG51Fl4c vIQYbBSlacSTFBfuoKqmkDeLQcPVDnwrQcDbHayyIj0Y8FgZusUAhhFYVOXl2FQWvmbk MPkw== X-Received: by 10.101.132.8 with SMTP id j8mr1442788ann.68.1361551426570; Fri, 22 Feb 2013 08:43:46 -0800 (PST) Received: from [10.10.0.105] ([190.213.2.61]) by mx.google.com with ESMTPS id y14sm3818603anm.14.2013.02.22.08.43.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 08:43:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: Date: Fri, 22 Feb 2013 12:43:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <106ACB87-8EC5-4248-A785-4FDFC74E509B@hopcount.ca> References: To: "Dickson, Brian" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnv3LSCkEkIakrVxkmqypL3Up09Dse7DorVSFStboGVF98uAoxR89GRR4ge9Q/CabmUgXxh Cc: IETF DNSOP WG , Nick Hilliard Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:43:48 -0000 On 2013-02-22, at 12:33, "Dickson, Brian" wrote: > One question/caveat: >=20 > What would the practical impact be, if the TTL on the SOA were the = same as > the default negative caching TTL (for the NXDOMAIN)? The longevity of the negative answer in the cache is defined as min(SOA = TTL, SOA MINIMUM). There is no magic, here. > I think it would be slightly less sniffy, to have the NXDOMAIN and the > synthesized SOA both disappear at the same time. >=20 > IIRC, the TTL would then need to be 900 rather than 604800. The existing AS112 servers return SOA TTL =3D SOA MINIMUM =3D 604800, = per RFC 6304. Setting the SOA TTL to 900 would reduce the longevity of = both the SOA and the NOERROR/NODATA to 900 seconds from a week. I don't = think that's desirable for these zones. Note I'm assuming that = NOERROR/NODATA are cached the same way as NXDOMAIN. draft-kumari-omniscient-as112-01 specifies SOA MINIMUM =3D 604800 but = doesn't specify the SOA TTL. Should probably fix that. Joe From cet1@hermes.cam.ac.uk Fri Feb 22 09:02:14 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD2D21F8EB8 for ; Fri, 22 Feb 2013 09:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKbdQyvOw6kC for ; Fri, 22 Feb 2013 09:02:13 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 992D021F8E93 for ; Fri, 22 Feb 2013 09:02:13 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:49263) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1U8w0g-0003rc-sa (Exim 4.72) (return-path ); Fri, 22 Feb 2013 17:02:10 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1U8w0g-00056t-Sy (Exim 4.72) (return-path ); Fri, 22 Feb 2013 17:02:10 +0000 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 22 Feb 2013 17:02:10 +0000 Date: 22 Feb 2013 17:02:10 +0000 From: Chris Thompson To: Mark Andrews Message-ID: In-Reply-To: <20130222133901.9544F2FF9F2A@drugs.dv.isc.org> References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51274721.1030308@inex.ie> <20130222133901.9544F2FF9F2A@drugs.dv.isc.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: Chris Thompson Cc: IETF DNSOP WG , Nick Hilliard Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:02:14 -0000 On Feb 22 2013, Mark Andrews wrote: >I can well imagine a machine doing a reverse lookup on a proposed >address and not proceeding with that address if it doesn't get a >NXDOMAIN. > >=09NODATA -> unsafe >=09NXDOMAIN -> may be safe So when I do a reverse lookup of 255.255.255.255 or ::0, and BIND gives me a "NODATA" response from its automatic empty zones that cover just those specific addresses and no others, then it is=20 being "unsafe"? --=20 Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From bdickson@verisign.com Fri Feb 22 11:05:23 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3D821F86F6 for ; Fri, 22 Feb 2013 11:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQvD3hzc5NCO for ; Fri, 22 Feb 2013 11:05:22 -0800 (PST) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACBD21F8689 for ; Fri, 22 Feb 2013 11:05:19 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUSfBbKFK5MuK2E2znKRoqG/D8PVzuet/@postini.com; Fri, 22 Feb 2013 11:05:22 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r1MJ5BDw017340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 14:05:11 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 22 Feb 2013 14:05:11 -0500 From: "Dickson, Brian" To: Joe Abley Thread-Topic: [DNSOP] Adoption of as a WG work item? Thread-Index: AQHOERpWz0IiVTnK+EycGmjd8mjiRJiGaSeA///TtYA= Date: Fri, 22 Feb 2013 19:05:10 +0000 Message-ID: In-Reply-To: <106ACB87-8EC5-4248-A785-4FDFC74E509B@hopcount.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <49B6DE171E8EE04A9FC6A25E05CBA5C7@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF DNSOP WG , Nick Hilliard Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:05:23 -0000 Good point, indirectly referencing RFC 2308 (I always seem to forget about that one). So, other than SOA TTL going into the draft, I think it's all good, and please ignore everything else I said (e.g. 900). Brian On 2/22/13 11:43 AM, "Joe Abley" wrote: > >On 2013-02-22, at 12:33, "Dickson, Brian" wrote: > >> One question/caveat: >>=20 >> What would the practical impact be, if the TTL on the SOA were the same >>as >> the default negative caching TTL (for the NXDOMAIN)? > >The longevity of the negative answer in the cache is defined as min(SOA >TTL, SOA MINIMUM). There is no magic, here. > >> I think it would be slightly less sniffy, to have the NXDOMAIN and the >> synthesized SOA both disappear at the same time. >>=20 >> IIRC, the TTL would then need to be 900 rather than 604800. > >The existing AS112 servers return SOA TTL =3D SOA MINIMUM =3D 604800, per = RFC >6304. Setting the SOA TTL to 900 would reduce the longevity of both the >SOA and the NOERROR/NODATA to 900 seconds from a week. I don't think >that's desirable for these zones. Note I'm assuming that NOERROR/NODATA >are cached the same way as NXDOMAIN. > >draft-kumari-omniscient-as112-01 specifies SOA MINIMUM =3D 604800 but >doesn't specify the SOA TTL. Should probably fix that. > > >Joe > From warren@kumari.net Fri Feb 22 11:13:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D12B21F8625 for ; Fri, 22 Feb 2013 11:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.941 X-Spam-Level: X-Spam-Status: No, score=-100.941 tagged_above=-999 required=5 tests=[AWL=-1.636, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyVHvK1IQ2cD for ; Fri, 22 Feb 2013 11:13:45 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79ACA21F85FD for ; Fri, 22 Feb 2013 11:13:45 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id D09361B40136; Fri, 22 Feb 2013 14:13:44 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <8D64BE69-A3B3-4D6E-8D78-24A3F13DCA59@hopcount.ca> Date: Fri, 22 Feb 2013 14:13:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51274721.1030308@inex.ie> <20130222133901.9544F2FF9F2A@drugs.dv.isc.org> <8D64BE69-A3B3-4D6E-8D78-24A3F13DCA59@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.1499) Cc: IETF DNSOP WG , Nick Hilliard Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:13:46 -0000 On Feb 22, 2013, at 8:49 AM, Joe Abley wrote: >=20 > On 2013-02-22, at 09:39, Mark Andrews wrote: >=20 >> I can well imagine a machine doing a reverse lookup on a proposed >> address and not proceeding with that address if it doesn't get a >> NXDOMAIN. >>=20 >> NODATA -> unsafe >> NXDOMAIN -> may be safe >=20 > So, out of interest, do you think it's legitimate for an omniscient = server to return something like this? (note the RCODE and the SOA RRSet = returned in the authority section) >=20 > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41208 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available >=20 > ;; QUESTION SECTION: > ;1.1.1.10.in-addr.arpa. IN PTR >=20 > ;; AUTHORITY SECTION: > 1.1.1.10.in-addr.arpa. 604800 IN SOA = prisoner.iana.org. hostmaster.root-servers.org. 1 1800 900 604800 604800 >=20 > ;; Query time: 3 msec > ;; SERVER: 192.175.48.6#53(192.175.48.6) > ;; WHEN: Fri Feb 22 13:45:36 2013 > ;; MSG SIZE rcvd: 116 >=20 > That would be a simple change to the spec. We chose NOERROR/ANSWER:0 = because we thought it didn't make sense to say NXDOMAIN whilst at the = same time synthesising an authority-section SOA with the same owner name = as the QNAME when the RCODE we're returning indicates that that owner = name doesn't exist. Yup, the change to the spec and the change to the code are both simple. I also changed the TTLs to match what I got when querying AS112 (not = because I necessarily think that they are the right numbers, just as an = example) ---------------------------- wkumari@dns-test:~/tmp/evldns$ diff -Naur oas112d.c oas112d.c.orig=20 --- oas112d.c 2013-02-22 19:02:36.875829849 +0000 +++ oas112d.c.orig 2013-02-22 18:35:52.546628018 +0000 @@ -33,7 +33,7 @@ #include #include =20 -static char *t_soa =3D "@ SOA a.as112.net. hostmaster.as112.net. 1 1800 = 900 0604800 604800"; +static char *t_soa =3D "@ SOA a.as112.net. hostmaster.as112.net. 1 = 604800 2592000 0604800 604800"; static char *t_ns1 =3D "@ NS b.as112.net."; static char *t_ns2 =3D "@ NS c.as112.net."; =20 @@ -57,7 +57,7 @@ ldns_pkt *req =3D srq->request; =20 /* the default response packet */ - ldns_pkt *resp =3D srq->response =3D evldns_response(req, = LDNS_RCODE_NXDOMAIN); + ldns_pkt *resp =3D srq->response =3D evldns_response(req, = LDNS_RCODE_NOERROR); =20 /* copy the question and determine qtype and qname */ ldns_rr *question =3D ldns_rr_list_rr(ldns_pkt_question(req), = 0); ------------------------- The NOERROR version can be seen by querying scratch-monkey.kumari.net, = the NXDOMAIN by querying dns-test.snozzages.com > As someone familiar with implementing the receiver side of this hack, = would/should this negative answer be cached? Folk are welcome to test against these and see how their particualr = resolvers cache=85. W >=20 >=20 > Joe > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 --=20 No man is an island, But if you take a bunch of dead guys and tie them = together, they make a pretty good raft. --Anon. From warren@kumari.net Fri Feb 22 11:27:14 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A2921F8CAB for ; Fri, 22 Feb 2013 11:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUZtTl8i+Zei for ; Fri, 22 Feb 2013 11:27:13 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57F521F84DF for ; Fri, 22 Feb 2013 11:27:13 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id F344E1B40136; Fri, 22 Feb 2013 14:27:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <51275D39.1070806@redbarn.org> Date: Fri, 22 Feb 2013 14:27:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.1499) Cc: IETF DNSOP WG , Peter Koch , George Michaelson , Erik Kline , Joe Abley Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:27:14 -0000 On Feb 22, 2013, at 6:57 AM, Paul Vixie wrote: > if we can't return nxdomain, then i'm opposed to the omniscient spec, > and we should continue as before, enumerating on the responding = servers > every zone to which we wish to delegate. >=20 If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR = was more appropriate, but 'its entirely possible we are wrong. W (If folk feel sufficiently strongly we *could* even strip a label off, = so that the synthesized SOA is not the same as the NXD. *This* feel = really hacks, but putting it out there...)=20 > noerror/nodata is the wrong answer. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 -- "I think perhaps the most important problem is that we are trying to = understand the fundamental workings of the universe via a language = devised for telling one another when the best fruit is." --Terry = Prachett=20 From jason_livingood@cable.comcast.com Fri Feb 22 11:52:31 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20CE21F8936 for ; Fri, 22 Feb 2013 11:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPWDKd3zTcXS for ; Fri, 22 Feb 2013 11:52:30 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 64D3B21F88FD for ; Fri, 22 Feb 2013 11:52:30 -0800 (PST) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44346194; Fri, 22 Feb 2013 14:40:06 -0500 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Fri, 22 Feb 2013 14:52:22 -0500 From: "Livingood, Jason" To: Warren Kumari , Paul Hoffman Thread-Topic: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 Thread-Index: AQHODJPPOyz08eCDbE2+MzTLR2FPJph9il2AgAR+gwCABEo6AA== Date: Fri, 22 Feb 2013 19:52:21 +0000 Message-ID: <10229F86C86EB444898E629583FD417161667E24@PACDCEXMB06.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8AA3510EEA590A44991C40371DEA027D@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:52:31 -0000 Ack. Tracking the need for examples in the open issues log for the I-D. On 2/19/13 4:21 PM, "Warren Kumari" wrote: > >On Feb 16, 2013, at 7:43 PM, Paul Hoffman wrote: > >> Ted's misunderstanding of what you are proposing is a valid one. You >>don't actually say what a negative trust anchor is, and what it is a >>trust anchor for, until section 7. Readers such as Ted (and myself!) >>will have strong prejudices by then. >>=20 >> I would want to see something in the Introduction saying something like: >>=20 >> This document discusses trust anchors for DNSSEC. A "negative trust >>anchor" is equivalent to a "regular" DNSSEC trust anchor for a >>particular instance of a recursive validating resolver. A negative trust >>anchor is quite different from regular DNSSEC trust anchors in that they >>are local, temporary, and definitely not distributed by IANA. They are >>trust anchors only for DNSSEC, not for PKIX. >>=20 >> That should help set the tone for the following sections that say how >>to use them, and then the much later sections on what they actually are. > > >I also think that it would be very helpful to actually show *how* this is >used, with e.g and example in an Appendix, for here>. > >The document contains a lot of really useful content about why you might >use one, how to minimize damage, etc but (IMO) does't do a great job of >explaining *how* to actually do so=8A > >But yes, I think it should be considered for adoption / if this is a CfA >I support it :-P >I'd also like to see it presented / discussed at the meeting... > >W > > >>=20 >> --Paul Hoffman >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >>=20 > >-- >"Build a man a fire, and he'll be warm for a day. Set a man on fire, and >he'll be warm for the rest of his life." -- Terry Pratchett > > From jason_livingood@cable.comcast.com Fri Feb 22 11:56:11 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB6721F8A6C for ; Fri, 22 Feb 2013 11:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.436 X-Spam-Level: X-Spam-Status: No, score=-104.436 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt11KGsthCqd for ; Fri, 22 Feb 2013 11:56:11 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id F27BE21F8956 for ; Fri, 22 Feb 2013 11:56:10 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57636494; Fri, 22 Feb 2013 12:25:26 -0700 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Fri, 22 Feb 2013 14:55:45 -0500 From: "Livingood, Jason" To: Richard Lamb , "dnsop@ietf.org" Thread-Topic: New draft-livingood-negative-trust-anchors-04 Thread-Index: AQHODSKYanCs4foReEyzUdtSJHXGsJiDFSJQgAM9zIA= Date: Fri, 22 Feb 2013 19:55:45 +0000 Message-ID: <10229F86C86EB444898E629583FD417161667E8D@PACDCEXMB06.cable.comcast.com> In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B15EFE3B5477@EXVPMBX100-1.exc.icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.56.165] Content-Type: multipart/alternative; boundary="_000_10229F86C86EB444898E629583FD417161667E8DPACDCEXMB06cabl_" MIME-Version: 1.0 Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:56:11 -0000 --_000_10229F86C86EB444898E629583FD417161667E8DPACDCEXMB06cabl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 2/20/13 1:50 PM, "Richard Lamb" > wrote: As I am late to looking at this draft please take this only as a comment fr= om a narrow minded engineer ;-) After the rationale, explanations and cav= eats I kept looking for how to implement a NTA. After initially thinking t= his would be the introduction of some new functionality and RRset manipulat= ion, I only found a reference to how Unbound implements it. Ack. Warren suggested the same. I will add to open issues in the next updat= e and will add it to a future update of the doc! So it might be useful to have section 2 =93Definition ..=94 make that clear= for slow people like me - that the NTA is not an RR and is more of a confi= guration. Maybe simply replacing =93placed=94 with =93implemented=94 in se= ction 2? =93This NTA can potentially be [placed][implemented] at any level= within the chain of trust=85=94 Will do =96 added this to my open issues tracker as well. JL Feel free to ignore of this thread has already been covered. Regardless o= f whether my comment makes sense, I do this this is a useful draft to have. --_000_10229F86C86EB444898E629583FD417161667E8DPACDCEXMB06cabl_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 2/20/13 1:50 PM, "Richard Lamb" <richard.lamb@icann.org> wrote:

As I am late to looking at this draft please take this only as a com= ment from a narrow minded engineer ;-)   After the rationale, exp= lanations and caveats I kept looking for how to implement a NTA.  After initially thinking this would be the introduc= tion of some new functionality and RRset manipulation, I only found a refer= ence to how Unbound implements it.
Ack. Warren suggested the same. I will add to open issues in the next = update and will add it to a future update of the doc!

So it might be useful to have sect= ion 2 =93Definition ..=94 make that clear for slow people like me - that th= e NTA is not an RR and is more of a configuration.  Maybe simply replacing =93placed=94 with =93implemented=94 in section 2? &= nbsp;=93This NTA can potentially be [placed][implemented] at any level with= in the chain of trust=85=94
Will do =96 added this to my open issues tracker as well.

JL

Feel free to ignore of this thread= has already been covered.   Regardless of whether my comment mak= es sense, I do this this is a useful draft to have.

 --_000_10229F86C86EB444898E629583FD417161667E8DPACDCEXMB06cabl_-- From jason_livingood@cable.comcast.com Fri Feb 22 12:05:55 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB1121F8ABC for ; Fri, 22 Feb 2013 12:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.481 X-Spam-Level: X-Spam-Status: No, score=-104.481 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-QaKIJsX2sT for ; Fri, 22 Feb 2013 12:05:54 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 3F96921F8652 for ; Fri, 22 Feb 2013 12:05:52 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57639154; Fri, 22 Feb 2013 12:35:31 -0700 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Fri, 22 Feb 2013 15:05:50 -0500 From: "Livingood, Jason" To: Olafur Gudmundsson , "dnsop@ietf.org" Thread-Topic: [DNSOP] New draft-livingood-negative-trust-anchors-04 Thread-Index: AQHODSKYanCs4foReEyzUdtSJHXGsJiAZXGAgAXwTYA= Date: Fri, 22 Feb 2013 20:05:49 +0000 Message-ID: <10229F86C86EB444898E629583FD417161667F24@PACDCEXMB06.cable.comcast.com> In-Reply-To: <51228DFB.3070005@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <3A37BC199BEFDE45AD6024DC186048D6@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:05:55 -0000 On 2/18/13 3:24 PM, "Olafur Gudmundsson" wrote: >Jason, in section 10 you talk about possible early removal the NTA when >validation succeeds but there may be instances where validation succeeds >when using a sub-set of the authoritative servers thus NTA should only >be removed if all servers are providing "good" signatures. Excellent point! We have certainly see cases where 2 of 3 name servers are fine and one of them is acting wonky. I will add that to the open issue tracker for a future substantive update! >Furthermore what to do if some names work but others do not, for example >I remember a case where the records at the apex worked but all names >below the apex were signed by a key not in the DNSKEY RRset, thus it is >possible that either human or automated checks may assume there is no >problem when there actually is one. >What this is bringing to my mind is maybe you want a new section with >guidelines on how to test for failures and in what cases failure >justifies NTA and what tests MUST pass before preemttive removal of an >NTA. Good question - will address in a future version as well. >Also should there be guidance that removal of NTA should include >cleaning the caches of all RRsets below the name? I think so, yes. I will add this as well - can't hurt. Thank you, Jason From jason_livingood@cable.comcast.com Fri Feb 22 12:07:54 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEEA21F8A56 for ; Fri, 22 Feb 2013 12:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.52 X-Spam-Level: X-Spam-Status: No, score=-104.52 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMiq+8XiC7V1 for ; Fri, 22 Feb 2013 12:07:53 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC9721F8652 for ; Fri, 22 Feb 2013 12:07:53 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57639249; Fri, 22 Feb 2013 12:35:54 -0700 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Fri, 22 Feb 2013 15:06:13 -0500 From: "Livingood, Jason" To: Joe Abley , Richard Lamb Thread-Topic: [DNSOP] New draft-livingood-negative-trust-anchors-04 Thread-Index: AQHODSKYanCs4foReEyzUdtSJHXGsJiDFSJQgABbNoCAAuWDgA== Date: Fri, 22 Feb 2013 20:06:13 +0000 Message-ID: <10229F86C86EB444898E629583FD417161667F31@PACDCEXMB06.cable.comcast.com> In-Reply-To: <0E50A016-54F0-473A-B1C9-9C1111275C96@hopcount.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <86FB984D654BF4478AC295FFBB9F86BD@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:07:54 -0000 On 2/20/13 1:52 PM, "Joe Abley" wrote: > >On 2013-02-20, at 14:50, Richard Lamb wrote: > >> FWIW: The -04 draft looks good. It is clear and well written and I >>think it is a valuable resource. >> As I am late to looking at this draft please take this only as a >>comment from a narrow minded engineer ;-) After the rationale, >>explanations and caveats I kept looking for how to implement a NTA. > >+1 > >The text seems to lead in that direction, and then end abruptly leaving >the reader wondering what happened. Leaving room for a sequel? :-) Ack - will address in a future rev. :-) JL From jason_livingood@cable.comcast.com Fri Feb 22 12:09:04 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A969B21F8DEF for ; Fri, 22 Feb 2013 12:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=-1.492, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8hSs5xThvQU for ; Fri, 22 Feb 2013 12:09:04 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2720821F8759 for ; Fri, 22 Feb 2013 12:09:04 -0800 (PST) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44348831; Fri, 22 Feb 2013 14:56:37 -0500 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.77]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Fri, 22 Feb 2013 15:08:59 -0500 From: "Livingood, Jason" To: Mark Andrews , Olafur Gudmundsson Thread-Topic: [DNSOP] New draft-livingood-negative-trust-anchors-04 Thread-Index: AQHODSKYanCs4foReEyzUdtSJHXGsJiAZXGA///F/wuABisyAA== Date: Fri, 22 Feb 2013 20:08:59 +0000 Message-ID: <10229F86C86EB444898E629583FD417161667F68@PACDCEXMB06.cable.comcast.com> In-Reply-To: <20130218215627.425852FCB39B@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <5CC2C986D1497E4EA583706747D24786@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] New draft-livingood-negative-trust-anchors-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:09:04 -0000 On 2/18/13 4:56 PM, "Mark Andrews" wrote: >In message <51228DFB.3070005@ogud.com>, Olafur Gudmundsson writes: >> Jason, in section 10 you talk about possible early removal the NTA when >>validation succeeds but there may be instances where validation succeeds >>when using a sub-set of the authoritative servers thus NTA should only >>be removed if all servers are providing "good" signatures. > >Why? This is no different to a server being down. Validators are >expected to ignore bad answers so a conforming resolver will find >the working copies of the zone. I suppose it is sometimes hard to verify - as each auth NS must be checked. It is a corner case, but seen in the wild. I'll take a stab at trying to address it, and if you think it goes into too much detail or is too obvious, please say so. :-) >=20 >>What this is bringing to my mind is maybe you want a new section with >> guidelines on how to test for failures and in what cases failure >> justifies NTA and what tests MUST pass before preemttive removal of an >> NTA. Also should there be guidance that removal of NTA should include >> cleaning the caches of all RRsets below the name? >There are lots of ways to stuff up DNSSEC. There are different steps >that can be taken to cleanup after such stuff ups. We don't need to >describe those steps. Quite so! I think this can be addressed simply in one or two sentences. If it seems unnecessary (as above) once I add it, say so. Thanks! Jason From bdickson@verisign.com Fri Feb 22 12:15:43 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB91521F8DDA for ; Fri, 22 Feb 2013 12:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtJpL8CLn+kQ for ; Fri, 22 Feb 2013 12:15:43 -0800 (PST) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 18ACE21F8DDB for ; Fri, 22 Feb 2013 12:15:05 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUSfRxDfBkwXZuvOBpje7rvmQqDzY6fSD@postini.com; Fri, 22 Feb 2013 12:15:42 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r1MKEniY007513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 15:14:49 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 22 Feb 2013 15:14:48 -0500 From: "Dickson, Brian" To: Warren Kumari , Paul Vixie Thread-Topic: [DNSOP] Adoption of as a WG work item? Thread-Index: AQHOETlDX3NIooTBpUOWp2gcK0s1dw== Date: Fri, 22 Feb 2013 20:14:48 +0000 Message-ID: In-Reply-To: <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Erik Kline , IETF DNSOP WG , Peter Koch , George Michaelson , Joe Abley Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:15:44 -0000 On 2/22/13 2:27 PM, "Warren Kumari" wrote: > >(If folk feel sufficiently strongly we *could* even strip a label off, so >that the synthesized SOA is not the same as the NXD. *This* feel really >hacks, but putting it out there...) Uh, definitely not. The whole point is you don't know from where the delegation comes, e.g. at what depth in the label tree. However, there is another UGLY, EVIL way that might achieve what you're thinking of: Instead of delegating to omniscient AS112 servers, what about doing a DNAME to a specific target "foo" (replace "foo" with what you will) in the DNS tree? Then, that location "foo" can be the SOA to use (which does not change regardless of the original question), along with any synthesized NXDOMAIN response. I did say it was evil. :-) Brian P.S. Example case: 10.in-addr.arpa. DNAME as112-leaf.prisoner.iana.org. Imagine the recursive wants an answer for the question: 1.1.1.10.in-addr.arpa. IN PTR Any root provides the above DNAME The local omniscient-112 server sees the question: 1.1.1.as112-leaf.prisoner.iana.org. The local omniscient-112 server gives the following answer: ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41208 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;1.1.1.as112-leaf.prisoner.iana.org. IN PTR ;; AUTHORITY SECTION: as112-leaf.prisoner.iana.org. 604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 1 604800 900 604800 604800 ;; Query time: 3 msec ;; SERVER: 192.175.48.6#53(192.175.48.6) ;; WHEN: Fri Feb 22 13:45:36 2013 ;; MSG SIZE rcvd: 116 And the recursive resolver would give the following answer (or something like it) to the client: (The CNAME is synthesized from the question and the DNAME, if I understand the relevant RFCs.) (I'm not sure if the recursive would send the SOA/Authority component) ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41208 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;1.1.1.as112-leaf.prisoner.iana.org. IN PTR ;; ANSWER SECTION 10.in-addr.arpa. DNAME as112-leaf.prisoner.iana.org. 1.1.1.10.in-addr.arpa. CNAME 1.1.1.as112-leaf.prisoner.iana.org. ;; AUTHORITY SECTION: as112-leaf.prisoner.iana.org. 604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 1 604800 900 604800 604800 ;; Query time: 3 msec ;; SERVER: 192.175.48.6#53(192.175.48.6) ;; WHEN: Fri Feb 22 13:45:36 2013 ;; MSG SIZE rcvd: xxxx From paul@redbarn.org Fri Feb 22 12:38:59 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E817921F86D3 for ; Fri, 22 Feb 2013 12:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.356 X-Spam-Level: X-Spam-Status: No, score=-7.356 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MY3iNRLzn+An for ; Fri, 22 Feb 2013 12:38:59 -0800 (PST) Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6024E21F86BC for ; Fri, 22 Feb 2013 12:38:59 -0800 (PST) Received: from [192.168.33.245] (230.Red-2-139-211.staticIP.rima-tde.net [2.139.211.230]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 7F9ABEBD60; Fri, 22 Feb 2013 20:38:57 +0000 (UTC) (envelope-from paul@redbarn.org) User-Agent: K-9 Mail for Android In-Reply-To: <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----MTFU23O8Q8BZ2VJVDR4NEN7KAZ0V5O" From: P Vixie Date: Fri, 22 Feb 2013 12:38:53 -0800 To: Warren Kumari Message-ID: <2b96f0c0-f05e-4547-83b1-dcaa329617c8@email.android.com> Cc: Erik Kline , IETF DNSOP WG , Peter Koch , George Michaelson , Joe Abley Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:39:00 -0000 ------MTFU23O8Q8BZ2VJVDR4NEN7KAZ0V5O Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I'd like to be able to implement this with a standard authority server, no special code, just a root zone that's empty other than its apex. So please no requirements for the soa other than that it be at or above the qname. Paul Warren Kumari wrote: > >On Feb 22, 2013, at 6:57 AM, Paul Vixie wrote: > >> if we can't return nxdomain, then i'm opposed to the omniscient spec, >> and we should continue as before, enumerating on the responding >servers >> every zone to which we wish to delegate. >> > >If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR >was more appropriate, but 'its entirely possible we are wrong. > >W > >(If folk feel sufficiently strongly we *could* even strip a label off, >so that the synthesized SOA is not the same as the NXD. *This* feel >really hacks, but putting it out there...) >> noerror/nodata is the wrong answer. >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > >-- >"I think perhaps the most important problem is that we are trying to >understand the fundamental workings of the universe via a language >devised for telling one another when the best fruit is." --Terry >Prachett > > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------MTFU23O8Q8BZ2VJVDR4NEN7KAZ0V5O Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I'd like to be able to implement this with a standard authority server, no special code, just a root zone that's empty other than its apex. So please no requirements for the soa other than that it be at or above the qname.

Paul

Warren Kumari <warren@kumari.net> wrote:

On Feb 22, 2013, at 6:57 AM, Paul Vixie <paul@redbarn.org> wrote:

if we can't return nxdomain, then i'm opposed to the omniscient spec,
and we should continue as before, enumerating on the responding servers
every zone to which we wish to delegate.


If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more appropriate, but 'its entirely possible we are wrong.

W

(If folk feel sufficiently strongly we *could* even strip a label off, so that the synthesized SOA is not the same as the NXD. *This* feel really hacks, but putting it out there...) 
noerror/nodata is the wrong answer.

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


--
"I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is." --Terry Prachett 



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

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------MTFU23O8Q8BZ2VJVDR4NEN7KAZ0V5O-- From jabley@hopcount.ca Fri Feb 22 12:44:05 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252C921F8E7E for ; Fri, 22 Feb 2013 12:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWi1IH963WFo for ; Fri, 22 Feb 2013 12:44:04 -0800 (PST) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1093821F8EA2 for ; Fri, 22 Feb 2013 12:44:00 -0800 (PST) Received: by mail-qe0-f44.google.com with SMTP id a11so584976qen.31 for ; Fri, 22 Feb 2013 12:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type; bh=/pFgg+yEgRW6bsZgt3fqa5T8ToaLbN1Mu2cUYU9EdnA=; b=JRLSGGfIv9DiYrUanrIVHze9UidAKND7Mw6pj6pJcVS/KGitu6w2BnKdtU53Nq8ZIj wllSwi4iOX32xcjk8bAqkwVLivIY/64KY4hoRvJU6QZQgNzELi4kcZcpN25SYEqyQW3N a/3yLaO5a/Yl50wVIZoI8NcxDYuyvxnvyVXsQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=/pFgg+yEgRW6bsZgt3fqa5T8ToaLbN1Mu2cUYU9EdnA=; b=IBGDXDjLYIFzd3JogdvWoXc/iS4UxYgNwKeRDB262RruO5E0kW0MEla6TkU6ch3tID +F9v52DgonZGJ1V7XjGnWzdqi/dQ/HH97ZuLe2+upJV38jIZPQdf70AzeajM1tSzlsOw //w0zdGQ/Q7WEQIhvHiOGh1U8DPeLa7y6bBMkQPHR77dMljoDQ44LxsOI0XNIKndoOjl 7SFlvAUFy5OrwNb/a1Z1UlBkh889Be/BCx5/ipKEE6waQxG+/9XVKU4MPCrMWciplHCt r+PNxk4KhfCjclFqmQLESoG3jls+7ZiTXZadl/sNXWULVmhuxMPuuPCsa3bBSm8vMnti 00AA== X-Received: by 10.224.203.131 with SMTP id fi3mr1798663qab.77.1361565840365; Fri, 22 Feb 2013 12:44:00 -0800 (PST) References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> <2b96f0c0-f05e-4547-83b1-dcaa329617c8@email.android.com> From: Joe Abley Mime-Version: 1.0 (1.0) In-Reply-To: <2b96f0c0-f05e-4547-83b1-dcaa329617c8@email.android.com> Date: Fri, 22 Feb 2013 16:43:55 -0400 Message-ID: <-7471011247182684274@unknownmsgid> To: P Vixie Content-Type: multipart/alternative; boundary=20cf300512c240d80d04d65640f9 X-Gm-Message-State: ALoCoQlFJZjuEbTYzbt2gF1ieBoESsv0173zV1YkPnVd+/hHc0t2hfskFOjGUV6V+fasTf1fOONS Cc: Erik Kline , IETF DNSOP WG , Peter Koch , George Michaelson Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:44:05 -0000 --20cf300512c240d80d04d65640f9 Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, That was our starting point; however, it turned out that resolvers wouldn't cache the name error, I think because the SOA returned with the name error in the authority section was clearly bogus (i.e. conflicted with the root zone SOA presumably already cached by the resolver client). I too have always preferred the idea of specifying configuration for standard software over custom code (neat though the custom code Warren is running is). We just couldn't figure out how to do it. Did we miss something? Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-22, at 16:39, P Vixie wrote: I'd like to be able to implement this with a standard authority server, no special code, just a root zone that's empty other than its apex. So please no requirements for the soa other than that it be at or above the qname. Paul Warren Kumari wrote: > > > On Feb 22, 2013, at 6:57 AM, Paul Vixie wrote: > > if we can't return nxdomain, then i'm opposed to the omniscient spec, >> and we should continue as before, enumerating on the responding servers >> every zone to which we wish to delegate. > > > > If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more appropriate, but 'its entirely possible we are wrong. > > W > > (If folk feel sufficiently strongly we *could* even strip a label off, so that the synthesized SOA is not the same as the NXD. *This* feel really hacks, but putting it out there...) > >> noerror/nodata is the wrong answer. >> ------------------------------ >> >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > "I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is." --Terry Prachett > > > ------------------------------ > > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. --20cf300512c240d80d04d65640f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Paul,

= That was our starting point; however, it turned out that resolvers wouldn&#= 39;t cache the name error, I think because the SOA returned with the name e= rror in the authority section was clearly bogus (i.e. conflicted with the r= oot zone SOA presumably already cached by the resolver client).

I too have always preferred the idea of specifying conf= iguration for standard software over custom code (neat though the custom co= de Warren is running is). We just couldn't figure out how to do it.=A0<= /div>

Did we miss something?


Joe

Aue Te Ariki! He toki ki roto taku mahuna!
On 2013-02-22, at 16:39, P Vixie <p= aul@redbarn.org> wrote:

I'd like to be able to impleme= nt this with a standard authority server, no special code, just a root zone= that's empty other than its apex. So please no requirements for the so= a other than that it be at or above the qname.

Paul

Warren Kumari <warren@kumari.net> wrote:

On Feb 22, 2013, at 6:57 AM, Paul Vixie <paul@redbarn.org> wrote:


if we can't return nxdomain, then i'm opposed to the omniscient spe=
c,
and we should continue as before, enumerating on the responding serve=
rs
every zone to which we wish to delegate.


If the W= G consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more ap= propriate, but 'its entirely possible we are wrong.

W

(If folk feel sufficiently strongly we *could* even strip a la= bel off, so that the synthesized SOA is not the same as the NXD. *This* fee= l really hacks, but putting it out there...)
noerror/nodata is the wrong answer.

DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop<= /a>


--
"I think perhaps the most important problem is that we a= re trying to understand the fundamental workings of the universe via a lang= uage devised for telling one another when the best fruit is." --Terry = Prachett



DNSOP mailing list
DNS= OP@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsop

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--20cf300512c240d80d04d65640f9-- From paul@redbarn.org Fri Feb 22 12:53:25 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D5921F87AA for ; Fri, 22 Feb 2013 12:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[AWL=-3.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3mkgfuF00YD for ; Fri, 22 Feb 2013 12:53:24 -0800 (PST) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 31F0E21F871E for ; Fri, 22 Feb 2013 12:53:24 -0800 (PST) Received: from [192.168.33.245] (230.Red-2-139-211.staticIP.rima-tde.net [2.139.211.230]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 6C50FEBC93; Fri, 22 Feb 2013 20:53:22 +0000 (UTC) (envelope-from paul@redbarn.org) User-Agent: K-9 Mail for Android In-Reply-To: References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----GICZ3LUNGU2Y8BBMI1PSSP44P7L8LI" From: P Vixie Date: Fri, 22 Feb 2013 12:52:41 -0800 To: Joe Abley Message-ID: <000d82bb-2dba-44a8-9221-5b7842f41cfd@email.android.com> Cc: Erik Kline , Peter Koch , IETF DNSOP WG , George Michaelson Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:53:25 -0000 ------GICZ3LUNGU2Y8BBMI1PSSP44P7L8LI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sorry to be late on this, missed it earlier. Nxd says there is no such name, no matter what the type was, and there are no children. No data/noerror says there are either other types or children or both. We know what the truth must be and we know which implications we want the requestor to follow. Right? Is there any doubt at all or any ambiguity in what we want said? ... Paul Joe Abley wrote: > >On 2013-02-22, at 07:57, Paul Vixie wrote: > >> if we can't return nxdomain, then i'm opposed to the omniscient spec, >> and we should continue as before, enumerating on the responding >servers >> every zone to which we wish to delegate. >> >> noerror/nodata is the wrong answer. > >It does smell a bit wrong, but I'm interested in more details of why >you think that if it's more than just the smell. > >I'll note that the proposal is to assign new nameservers to be >omniscient, and not to convert the existing ones. We are then in a >position to delegate other local-zoneish zones to the new servers and >review the impact. > >So, the suggestion is not to replace the existing AS112 servers >(blackhole-1, blackhole-2 and prisoner) out of the gate. Any such >replacement would happen later, once there was some degree of comfort >that it was safe to do that. > > >Joe >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------GICZ3LUNGU2Y8BBMI1PSSP44P7L8LI Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Sorry to be late on this, missed it earlier.

Nxd says there is no such name, no matter what the type was, and there are no children. No data/noerror says there are either other types or children or both. We know what the truth must be and we know which implications we want the requestor to follow. Right? Is there any doubt at all or any ambiguity in what we want said? ... Paul

Joe Abley <jabley@hopcount.ca> wrote:

On 2013-02-22, at 07:57, Paul Vixie <paul@redbarn.org> wrote:

if we can't return nxdomain, then i'm opposed to the omniscient spec,
and we should continue as before, enumerating on the responding servers
every zone to which we wish to delegate.

noerror/nodata is the wrong answer.

It does smell a bit wrong, but I'm interested in more details of why you think that if it's more than just the smell.

I'll note that the proposal is to assign new nameservers to be omniscient, and not to convert the existing ones. We are then in a position to delegate other local-zoneish zones to the new servers and review the impact.

So, the suggestion is not to replace the existing AS112 servers (blackho
 le-1,
blackhole-2 and prisoner) out of the gate. Any such replacement would happen later, once there was some degree of comfort that it was safe to do that.


Joe

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

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------GICZ3LUNGU2Y8BBMI1PSSP44P7L8LI-- From paul@redbarn.org Fri Feb 22 12:53:30 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470F621F8EB5 for ; Fri, 22 Feb 2013 12:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=1.523, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWP+xzKRpOaw for ; Fri, 22 Feb 2013 12:53:28 -0800 (PST) Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id 207B321F87D3 for ; Fri, 22 Feb 2013 12:53:28 -0800 (PST) Received: from [192.168.33.245] (230.Red-2-139-211.staticIP.rima-tde.net [2.139.211.230]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 78713EBC96; Fri, 22 Feb 2013 20:53:26 +0000 (UTC) (envelope-from paul@redbarn.org) User-Agent: K-9 Mail for Android In-Reply-To: <-7471011247182684274@unknownmsgid> References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> <2b96f0c0-f05e-4547-83b1-dcaa329617c8@email.android.com> <-7471011247182684274@unknownmsgid> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----DH78M62ZQYX5NW3WT9B7MJI9SL22MU" From: P Vixie Date: Fri, 22 Feb 2013 12:47:50 -0800 To: Joe Abley Message-ID: Cc: Erik Kline , IETF DNSOP WG , Peter Koch , George Michaelson Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:53:31 -0000 ------DH78M62ZQYX5NW3WT9B7MJI9SL22MU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sounds like you want it to return the nxd with no 2308 proof which means most receives will cache it because the erroneous delegation isn't present. Bind calls this a minimal response I think. ... Paul Joe Abley wrote: >Hi Paul, > >That was our starting point; however, it turned out that resolvers >wouldn't >cache the name error, I think because the SOA returned with the name >error >in the authority section was clearly bogus (i.e. conflicted with the >root >zone SOA presumably already cached by the resolver client). > >I too have always preferred the idea of specifying configuration for >standard software over custom code (neat though the custom code Warren >is >running is). We just couldn't figure out how to do it. > >Did we miss something? > > >Joe > >Aue Te Ariki! He toki ki roto taku mahuna! > >On 2013-02-22, at 16:39, P Vixie wrote: > >I'd like to be able to implement this with a standard authority server, >no >special code, just a root zone that's empty other than its apex. So >please >no requirements for the soa other than that it be at or above the >qname. > >Paul > >Warren Kumari wrote: >> >> >> On Feb 22, 2013, at 6:57 AM, Paul Vixie wrote: >> >> if we can't return nxdomain, then i'm opposed to the omniscient spec, >>> and we should continue as before, enumerating on the responding >servers >>> every zone to which we wish to delegate. >> >> >> >> If the WG consensus is NXDOMAIN, we can do that. *We* felt that >NOERROR was more appropriate, but 'its entirely possible we are wrong. >> >> W >> >> (If folk feel sufficiently strongly we *could* even strip a label >off, so that the synthesized SOA is not the same as the NXD. *This* >feel really hacks, but putting it out there...) >> >>> noerror/nodata is the wrong answer. >>> ------------------------------ >>> >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> >> >> -- >> "I think perhaps the most important problem is that we are trying to >understand the fundamental workings of the universe via a language >devised for telling one another when the best fruit is." --Terry >Prachett >> >> >> ------------------------------ >> >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> >-- >Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------DH78M62ZQYX5NW3WT9B7MJI9SL22MU Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Sounds like you want it to return the nxd with no 2308 proof which means most receives will cache it because the erroneous delegation isn't present. Bind calls this a minimal response I think. ... Paul

Joe Abley <jabley@hopcount.ca> wrote:
Hi Paul,

That was our starting point; however, it turned out that resolvers wouldn't cache the name error, I think because the SOA returned with the name error in the authority section was clearly bogus (i.e. conflicted with the root zone SOA presumably already cached by the resolver client).

I too have always preferred the idea of specifying configuration for standard software over custom code (neat though the custom code Warren is running is). We just couldn't figure out how to do it. 

Did we miss something?


Joe

Aue Te Ariki! He toki ki roto taku mahuna!

On 2013-02-22, at 16:39, P Vixie <paul@redbarn.org> wrote:

I'd like to be able to implement this with a standard authority server, no special code, just a root zone that's empty other than its apex. So please no requirements for the soa other than that it be at or above the qname.

Paul

Warren Kumari <warren@kumari.net> wrote:

On Feb 22, 2013, at 6:57 AM, Paul Vixie <paul@redbarn.org> wrote:


if we can't return nxdomain, then i'm opposed to the omniscient spec,
and we should continue as before, enumerating on the responding servers
every zone to which we wish to delegate.


If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more appropriate, but 'its entirely possible we are wrong.


W

(If folk feel sufficiently strongly we *could* even strip a label off, so that the synthesized SOA is not the same as the NXD. *This* feel really hacks, but putting it out there...) 

noerror/nodata is the wrong answer.

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



--
"I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is." --Terry Prachett 




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

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------DH78M62ZQYX5NW3WT9B7MJI9SL22MU-- From jabley@hopcount.ca Fri Feb 22 13:11:59 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C6A21F8EBE for ; Fri, 22 Feb 2013 13:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j1cypssa4wR for ; Fri, 22 Feb 2013 13:11:58 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 14A6521F8EB5 for ; Fri, 22 Feb 2013 13:11:57 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id b40so476993qcq.38 for ; Fri, 22 Feb 2013 13:11:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type; bh=Gyej4hLa0vsfZ66csV4U5upxU4aOF6Hupfzr7vBtPnI=; b=SGm0ZCt2g9RoDc8fu07ZrV/x8QrF1BTV5f/EirMkFmT8/t2sgyp9Z2uc92lIMzPoi0 6IfvPWS8YqiIXvzIKUAM/tTDuO2XhtAGhPk/9LCWUizgiwFBuHLRG/KSEMKKiFa2pA2Q ssS7LaMfDjDp5Tm8g4ITf0Up5Wo2shIoGqNLc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Gyej4hLa0vsfZ66csV4U5upxU4aOF6Hupfzr7vBtPnI=; b=NabV3j42/URNHeJz5pkb1LVikJy/6tlFHG3zxrukUE8AN/LCyapuL5bW+doBjap9xQ Pi4xAbkvb0R+9i6ai6AzzJF8lzUqFTWpsnEKsppKAIaqPmAZI5seIQfVyixJWSHvjghJ HbwR01MKpqdsIS6mpPz8cbpKCUtN1r6UCDl8So8LNvgUTuUJrwUJoIs2hoQWw7Wcpq8q IrxYNX1n96gwWcUkBbpPp6UcyGNDueWOGEPmTRhrgmBreAab35C7BohcwyuWKakJ+ZHe q3n/IINfnzbZo0K4uGmqTEDTbBTkuxA8OF7hjcx+oxoDkYRSj26XoMvJbjX9gQq+pX0V 5Ebg== X-Received: by 10.224.174.129 with SMTP id t1mr1453258qaz.15.1361567517391; Fri, 22 Feb 2013 13:11:57 -0800 (PST) References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <000d82bb-2dba-44a8-9221-5b7842f41cfd@email.android.com> From: Joe Abley Mime-Version: 1.0 (1.0) In-Reply-To: <000d82bb-2dba-44a8-9221-5b7842f41cfd@email.android.com> Date: Fri, 22 Feb 2013 17:11:53 -0400 Message-ID: <-3494992631400138005@unknownmsgid> To: P Vixie Content-Type: multipart/alternative; boundary=20cf303640d7363a7604d656a401 X-Gm-Message-State: ALoCoQnTtojMwO4c1V/fq4SQ0flP5FN5hi5wqzlE/QIxh3dIGY3EJI8WyaYlE337uYrp4ZxHvAOl Cc: Erik Kline , Peter Koch , IETF DNSOP WG , George Michaelson Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:11:59 -0000 --20cf303640d7363a7604d656a401 Content-Type: text/plain; charset=ISO-8859-1 We want the absence of (qname, qtype) to be cached by resolvers who follow a delegation to an omniscient as112 server for all (qname, qtype). Given that requirement the thought was that NOERROR/no data and NXDOMAIN were equally plausible. However, I see now that the lack of "no children" signalling has the potential to cause increased query load, since resolvers will re-query for children despite an earlier query for a parent. My feeling is that this is not a big deal and the ability to add/drop with no coordination with server operators represents a greater win, but I have no science behind my words. The current scheme (witness Warren's code) seems to do this (modulo extra queries for children) for all (qname, qtype) where qtype != SOA. Which is not perfect, but, I think pretty good. We could servfail on qtype == SOA I guess, which is crazy nasty but which I think for all practical purposes would work. I like your other message's "minimal response" notion, though. When I'm not sitting on a plane headed for a beach, I will play with that. Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-22, at 16:53, P Vixie wrote: Sorry to be late on this, missed it earlier. Nxd says there is no such name, no matter what the type was, and there are no children. No data/noerror says there are either other types or children or both. We know what the truth must be and we know which implications we want the requestor to follow. Right? Is there any doubt at all or any ambiguity in what we want said? ... Paul Joe Abley wrote: > > > On 2013-02-22, at 07:57, Paul Vixie wrote: > > if we can't return nxdomain, then i'm opposed to the omniscient spec, >> and we should continue as before, enumerating on the responding servers >> every zone to which we wish to delegate. >> >> noerror/nodata is the wrong answer. > > > It does smell a bit wrong, but I'm interested in more details of why you think that if it's more than just the smell. > > I'll note that the proposal is to assign new nameservers to be omniscient, and not to convert the existing ones. We are then in a position to delegate other local-zoneish zones to the new servers and review the impact. > > So, the suggestion is not to replace the existing AS112 servers (blackhole-1, > blackhole-2 and prisoner) out of the gate. Any such replacement would happen later, once there was some degree of comfort that it was safe to do that. > > > Joe > ------------------------------ > > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. --20cf303640d7363a7604d656a401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We want the absence of (qname, qty= pe) to be cached by resolvers who follow a delegation to an omniscient as11= 2 server for all (qname, qtype).

Given that requirement the thought was that NOERROR/no = data and NXDOMAIN were equally plausible. However, I see now that the lack = of "no children" signalling has the potential to cause increased = query load, since resolvers will re-query for children despite an earlier q= uery for a parent. My feeling is that this is not a big deal and the abilit= y to add/drop with no coordination with server operators represents a great= er win, but I have no science behind my words.=A0

The current scheme (witness Warren's code) seems to= do this (modulo extra queries for children) for all (qname, qtype) where q= type !=3D SOA. Which is not perfect, but, I think pretty good. We could ser= vfail on qtype =3D=3D SOA I guess, which is crazy nasty but which I think f= or all practical purposes would work.=A0

I like your other message's "minimal response&= quot; notion, though. When I'm not sitting on a plane headed for a beac= h, I will play with that.=A0


Joe
Aue Te Ariki! He toki ki roto taku mahuna!

On 2013-02-22,= at 16:53, P Vixie <paul@redbarn.org= > wrote:

Sorry to be lat= e on this, missed it earlier.

Nxd says there is no such name, no matter what the type was, and there are = no children. No data/noerror says there are either other types or children = or both. We know what the truth must be and we know which implications we w= ant the requestor to follow. Right? Is there any doubt at all or any ambigu= ity in what we want said? ... Paul

Joe Abley <jabley@hopcount.ca> wrote:

On 2013-02-22, at 07:57, Paul Vixie <paul@redbarn.org> wrote:


if we can't return nxdomain, then i'm opposed to the omniscient spe=
c,
and we should continue as before, enumerating on the responding serve=
rs
every zone to which we wish to delegate.

noerror/nodata is the=
 wrong answer.


It does smell a bit wrong, but I'm interested in more details of wh=
y you think that if it's more than just the smell.

I'll note=
 that the proposal is to assign new nameservers to be omniscient, and not t=
o convert the existing ones. We are then in a position to delegate other lo=
cal-zoneish zones to the new servers and review the impact.


So, the suggestion is not to replace the existing AS112 servers (blackh=
ole-1,
blackhole-2 and prisoner) out of the gate. Any such replacement would happe=
n later, once there was some degree of comfort that it was safe to do that.=



Joe

DNSOP mailing list
DNSOP@ietf.org

https://www.ietf.or=
g/mailman/listinfo/dnsop

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--20cf303640d7363a7604d656a401-- From paul@redbarn.org Fri Feb 22 13:26:31 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DE121F8EFA for ; Fri, 22 Feb 2013 13:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=1.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B+q4rCjvNIy for ; Fri, 22 Feb 2013 13:26:22 -0800 (PST) Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id F358F21F8ED5 for ; Fri, 22 Feb 2013 13:26:19 -0800 (PST) Received: from [192.168.33.245] (230.Red-2-139-211.staticIP.rima-tde.net [2.139.211.230]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 44BB4EBCE3; Fri, 22 Feb 2013 21:26:18 +0000 (UTC) (envelope-from paul@redbarn.org) User-Agent: K-9 Mail for Android In-Reply-To: <-3494992631400138005@unknownmsgid> References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <000d82bb-2dba-44a8-9221-5b7842f41cfd@email.android.com> <-3494992631400138005@unknownmsgid> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----ZG221J3SE9LTLWFEQBGQ8T2WOLGI2W" From: P Vixie Date: Fri, 22 Feb 2013 13:25:43 -0800 To: Joe Abley Message-ID: <0fd790d5-6789-430b-a6e2-d5c539c84a18@email.android.com> Cc: Erik Kline , Peter Koch , IETF DNSOP WG , George Michaelson Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:26:33 -0000 ------ZG221J3SE9LTLWFEQBGQ8T2WOLGI2W Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I think your requirement is wrong, or misstated. You ought not want to imply there could be other types, except at the apex. The semantics of an empty riot zone in a disconnected name space suit you perfectly. If I get ambitious and revive resimprove then the no children exist signaling will also matter. Why get cute? Paul Joe Abley wrote: >We want the absence of (qname, qtype) to be cached by resolvers who >follow >a delegation to an omniscient as112 server for all (qname, qtype). > >Given that requirement the thought was that NOERROR/no data and >NXDOMAIN >were equally plausible. However, I see now that the lack of "no >children" >signalling has the potential to cause increased query load, since >resolvers >will re-query for children despite an earlier query for a parent. My >feeling is that this is not a big deal and the ability to add/drop with >no >coordination with server operators represents a greater win, but I have >no >science behind my words. > >The current scheme (witness Warren's code) seems to do this (modulo >extra >queries for children) for all (qname, qtype) where qtype != SOA. Which >is >not perfect, but, I think pretty good. We could servfail on qtype == >SOA I >guess, which is crazy nasty but which I think for all practical >purposes >would work. > >I like your other message's "minimal response" notion, though. When I'm >not >sitting on a plane headed for a beach, I will play with that. > > >Joe > >Aue Te Ariki! He toki ki roto taku mahuna! > >On 2013-02-22, at 16:53, P Vixie wrote: > >Sorry to be late on this, missed it earlier. > >Nxd says there is no such name, no matter what the type was, and there >are >no children. No data/noerror says there are either other types or >children >or both. We know what the truth must be and we know which implications >we >want the requestor to follow. Right? Is there any doubt at all or any >ambiguity in what we want said? ... Paul > >Joe Abley wrote: >> >> >> On 2013-02-22, at 07:57, Paul Vixie wrote: >> >> if we can't return nxdomain, then i'm opposed to the omniscient spec, >>> and we should continue as before, enumerating on the responding >servers >>> every zone to which we wish to delegate. >>> >>> noerror/nodata is the wrong answer. >> >> >> It does smell a bit wrong, but I'm interested in more details of why >you think that if it's more than just the smell. >> >> I'll note that the proposal is to assign new nameservers to be >omniscient, and not to convert the existing ones. We are then in a >position to delegate other local-zoneish zones to the new servers and >review the impact. >> >> So, the suggestion is not to replace the existing AS112 servers >(blackhole-1, >> blackhole-2 and prisoner) out of the gate. Any such replacement would >happen later, once there was some degree of comfort that it was safe to >do that. >> >> >> Joe >> ------------------------------ >> >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> >-- >Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------ZG221J3SE9LTLWFEQBGQ8T2WOLGI2W Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I think your requirement is wrong, or misstated.

You ought not want to imply there could be other types, except at the apex.

The semantics of an empty riot zone in a disconnected name space suit you perfectly.

If I get ambitious and revive resimprove then the no children exist signaling will also matter.

Why get cute?

Paul

Joe Abley <jabley@hopcount.ca> wrote:
We want the absence of (qname, qtype) to be cached by resolvers who follow a delegation to an omniscient as112 server for all (qname, qtype).

Given that requirement the thought was that NOERROR/no data and NXDOMAIN were equally plausible. However, I see now that the lack of "no children" signalling has the potential to cause increased query load, since resolvers will re-query for children despite an earlier query for a parent. My feeling is that this is not a big deal and the ability to add/drop with no coordination with server operators represents a greater win, but I have no science behind my words. 

The current scheme (witness Warren's code) seems to do this (modulo extra queries for children) for all (qname, qtype) where qtype != SOA. Which is not perfect, but, I think pretty good. We could servfail on qtype == SOA I guess, which is crazy nasty but which I think for all practical purposes would work. 

I like your other message's "minimal response" notion, though. When I'm not sitting on a plane headed for a beach, I will play with that. 


Joe

Aue Te Ariki! He toki ki roto taku mahuna!

On 2013-02-22, at 16:53, P Vixie <paul@redbarn.org> wrote:

Sorry to be late on this, missed it earlier.

Nxd says there is no such name, no matter what the type was, and there are no children. No data/noerror says there are either other types or children or both. We know what the truth must be and we know which implications we want the requestor to follow. Right? Is there any doubt at all or any ambiguity in what we want said? ... Paul

Joe Abley <jabley@hopcount.ca> wrote:

On 2013-02-22, at 07:57, Paul Vixie <paul@redbarn.org> wrote:


if we can't return nxdomain, then i'm opposed to the omniscient spec,
and we should continue as before, enumerating on the responding servers
every zone to which we wish to delegate.

noerror/nodata is the wrong answer.


It does smell a bit wrong, but I'm interested in more details of why you think that if it's more than just the smell.

I'll note that the proposal is to assign new nameservers to be omniscient, and not to convert the existing ones. We are then in a position to delegate other local-zoneish zones to the new servers and review the impact.


So, the suggestion is not to replace the existing AS112 servers (blackhole-1,
blackhole-2 and prisoner) out of the gate. Any such replacement would happen later, once there was some degree of comfort that it was safe to do that.


Joe

DNSOP mailing list
DNSOP@ietf.org

https://www.ietf.org/mailman/listinfo/dnsop

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------ZG221J3SE9LTLWFEQBGQ8T2WOLGI2W-- From sm@resistor.net Sun Feb 24 09:15:03 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C09A21F9063 for ; Sun, 24 Feb 2013 09:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbvSDqa+uIpS for ; Sun, 24 Feb 2013 09:15:02 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0702C21F9069 for ; Sun, 24 Feb 2013 09:15:01 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1OHEspi011123 for ; Sun, 24 Feb 2013 09:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361726101; bh=S92AEIC73DRrdceD9oz9HF3NapyleJ5Rz0UVlSOSdlA=; h=Date:To:From:Subject:In-Reply-To:References; b=M8HqF3JS01mkMAA2ovl7iBg/K/IJUll5KpYTLhGyXgvY5koAP7i5wymsZFM+s3UmO X12f90W/w/g/hSIAskCPRroiX9PJ4vepP4NcYZBk7gHIHQjlorsPbkbGmbsfe0tCC/ WK8obIOGcq/Y+6DgLT8jyIq4XaKzMPe9WRcj7bZM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1361726101; i=@resistor.net; bh=S92AEIC73DRrdceD9oz9HF3NapyleJ5Rz0UVlSOSdlA=; h=Date:To:From:Subject:In-Reply-To:References; b=hFNuq3UN3uvzDJsIBBXakKeonkaZteL1mHSis63d5EYJG17s8jl74IltcFEwz3iyo ccYbhIfoX5fLJEni4WJR/nkbG36NQVUxIpQrN0hA+gDw6/EJ0A+X47U8+xSuIR9tEi io7T3k10dGCLU2XIbIaosdmdbz+/a5OIZLb+o0LM= Message-Id: <6.2.5.6.2.20130224084244.0afd0be8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 24 Feb 2013 08:46:04 -0800 To: dnsop@ietf.org From: SM In-Reply-To: <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:15:03 -0000 At 11:27 22-02-2013, Warren Kumari wrote: >If the WG consensus is NXDOMAIN, we can do that. *We* felt that >NOERROR was more appropriate, but 'its entirely possible we are wrong. The subject line says "Adoption as WG item". Has draft-wkumari-dnsop-omniscient-as112-01 been adopted yet? Regards, -sm From jabley@hopcount.ca Sun Feb 24 14:35:23 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84DE21F8F58 for ; Sun, 24 Feb 2013 14:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fjocQyxzgF7 for ; Sun, 24 Feb 2013 14:35:23 -0800 (PST) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3184021F8F1F for ; Sun, 24 Feb 2013 14:35:22 -0800 (PST) Received: by mail-qe0-f44.google.com with SMTP id x7so184899qeu.3 for ; Sun, 24 Feb 2013 14:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type; bh=8i5donNIqMEcpy2FV+XSzy5S+DcPjdDCeJwnvBnue1g=; b=FjWcoA932gSkjCSV105dz7n1UxidARAnXJp3uay3d6iAZo1Qvknir6Fp3fPdSodCRD 5VorVapc/6gfAAWx2xHMwF3W4+8Xkgoe7Jf3jRoTd2aB8MWCMpmqkoL/1q+qa5apF7Cs jSMiW9quAiwL+71WiVDF6hJqPHtbe7PazES90= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=8i5donNIqMEcpy2FV+XSzy5S+DcPjdDCeJwnvBnue1g=; b=CeFJXvEYRyMslQNG7UIZNZ0QuS59r+hG4fxmr1U1+bmYEBmYsg/+JZzd1vLvkHaKil wLvV+13xrEe92VrS+BPO5N/fRt2/LEzIoLf+iFvq1ISIM+vh/kbAD7bZiTNQFCqzAK7g 8/o3iBCyPj+0rWTG3ZOswnkMZ6dAd25tA5oL3jWJ4n7X8z6inAkzuEXcVCJuBWAm8CWm OMFHysNT5m8Oog7boAGI4cBtYYDErJWexO4UMB3Jb0HabE/Fmm9B/tboxrzrMst226z6 IKIM5qKPF1lrFrEMkhxgzKWc23d/lxMav9B3GT9WdsaN+5MN0LY/hRAddArPvS5g/JYh 6STw== X-Received: by 10.224.174.129 with SMTP id t1mr7933246qaz.15.1361745321819; Sun, 24 Feb 2013 14:35:21 -0800 (PST) References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> <6.2.5.6.2.20130224084244.0afd0be8@resistor.net> From: Joe Abley Mime-Version: 1.0 (1.0) In-Reply-To: <6.2.5.6.2.20130224084244.0afd0be8@resistor.net> Date: Sun, 24 Feb 2013 18:35:21 -0400 Message-ID: <-7632368423442499756@unknownmsgid> To: SM Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnMYh292WnljmU+Da67tryl/KAfKrKpAUn08hbG5ig/FyHpqXnp+BejM4gKVZTG6LUKhyph Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 22:35:24 -0000 The most recent decision that I saw from the chairs was that it should not be adopted. I do not agree that that is the best path forward. Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-24, at 13:15, SM wrote: > At 11:27 22-02-2013, Warren Kumari wrote: >> If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more appropriate, but 'its entirely possible we are wrong. > > The subject line says "Adoption as WG item". Has draft-wkumari-dnsop-omniscient-as112-01 been adopted yet? > > Regards, > -sm > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From Antoin.Verschuren@sidn.nl Mon Feb 25 02:03:17 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8DB21F9257 for ; Mon, 25 Feb 2013 02:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.489 X-Spam-Level: X-Spam-Status: No, score=-4.489 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAl70Xa3SPRj for ; Mon, 25 Feb 2013 02:03:16 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4F34621F9259 for ; Mon, 25 Feb 2013 02:03:16 -0800 (PST) Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id r1PA3FWq028031-r1PA3FWs028031 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Mon, 25 Feb 2013 11:03:15 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 25 Feb 2013 11:03:14 +0100 Received: from [94.198.152.222] (94.198.152.222) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 25 Feb 2013 11:03:14 +0100 Message-ID: <512B36E1.3020305@sidn.nl> Date: Mon, 25 Feb 2013 11:03:13 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "dnsop@ietf.org WG" References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.222] Subject: Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 10:03:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 19-02-13 18:20, Jacques Latour schreef: > Another "what if scenario" for bypassing the EPP keyrelay with > automation, what if there was a CKEYRELAY record pointing to the > gaining DNS operator name servers, where the parent zone operator > can grab the new DS record to be pre-published prior DNS operator > transfer? This does not work as there is no chain of trust yet to the gaining DNS operator. This proposal only works when changes are made that are in the current chain of trust with the current DNS operator. The challenge with EPP keyrelay is to get the key from the gaining dns operator delivered to the current operator so that it becomes a second chain of trust after it is inserted in the current delegated zone. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRKzbZAAoJEDqHrM883Agn0pUIAMNWf9Zf61CHAquOAfx8bRia jK81GhCJVMlGgSPJIMddP+8vyFcKZcZZ9DxDiOypm46xCPNRwGTFi8TFjCTlocDj 3br/HlwklbyfPRie1BMvNt2T0VN1OfZIqpc9JLrHm+aI1gnRn7+O27WcY//8pTVb bcnOf6NN0ix1kVdgknQ2OaKXIj+onpJYbYkFp1YXsqL+kVTbiynYO7oWN+RQjeiL dT7c2tTBCQXNUR0b3NNodQAeuL67tFLyLBbK/bL9gKBZ2n37gVJCgGATGmsw/Ay/ ocD7F4wO0wSehSwLmUDW+Jlen+Ss6M2A5y6QNylqTS5MeO8hfttfuFKpwj8CwuI= =AXsW -----END PGP SIGNATURE----- From warren@kumari.net Mon Feb 25 09:52:38 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977C821E8053 for ; Mon, 25 Feb 2013 09:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UbpfXwXQVtB for ; Mon, 25 Feb 2013 09:52:36 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D4121E804E for ; Mon, 25 Feb 2013 09:52:35 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id EB4931B417F7; Mon, 25 Feb 2013 12:52:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <0fd790d5-6789-430b-a6e2-d5c539c84a18@email.android.com> Date: Mon, 25 Feb 2013 12:52:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <000d82bb-2dba-44a8-9221-5b7842f41cfd@email.android.com> <-3494992631400138005@unknownmsgid> <0fd790d5-6789-430b-a6e2-d5c539c84a18@email.android.com> To: P Vixie X-Mailer: Apple Mail (2.1499) Cc: IETF DNSOP WG , Peter Koch , George Michaelson , Erik Kline , Joe Abley Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:52:38 -0000 On Feb 22, 2013, at 4:25 PM, P Vixie wrote: > I think your requirement is wrong, or misstated. >=20 > You ought not want to imply there could be other types, except at the = apex.=20 >=20 > The semantics of an empty riot zone in a disconnected name space suit = you perfectly. >=20 > If I get ambitious and revive resimprove then the no children exist = signaling will also matter. >=20 > Why get cute? Were not trying to get cute -- the initial version of the draft had an = empty root = (http://tools.ietf.org/html/draft-wkumari-dnsop-omniscient-as112-00 = Section 6.2 Fig 3 ), but, as Mark correctly pointed out, the answers = were not cached. I'll retest with "minimal responses" soon, but for now will simply = s/NOERROR/NXDOMAIN/ in the draft (so I can squeeze it in before the = revision cutoff). W >=20 > Paul >=20 > Joe Abley wrote: > We want the absence of (qname, qtype) to be cached by resolvers who = follow a delegation to an omniscient as112 server for all (qname, = qtype). >=20 > Given that requirement the thought was that NOERROR/no data and = NXDOMAIN were equally plausible. However, I see now that the lack of "no = children" signalling has the potential to cause increased query load, = since resolvers will re-query for children despite an earlier query for = a parent. My feeling is that this is not a big deal and the ability to = add/drop with no coordination with server operators represents a greater = win, but I have no science behind my words.=20 >=20 > The current scheme (witness Warren's code) seems to do this (modulo = extra queries for children) for all (qname, qtype) where qtype !=3D SOA. = Which is not perfect, but, I think pretty good. We could servfail on = qtype =3D=3D SOA I guess, which is crazy nasty but which I think for all = practical purposes would work.=20 >=20 > I like your other message's "minimal response" notion, though. When = I'm not sitting on a plane headed for a beach, I will play with that.=20 >=20 >=20 > Joe >=20 > Aue Te Ariki! He toki ki roto taku mahuna! >=20 > On 2013-02-22, at 16:53, P Vixie wrote: >=20 >> Sorry to be late on this, missed it earlier. >>=20 >> Nxd says there is no such name, no matter what the type was, and = there are no children. No data/noerror says there are either other types = or children or both. We know what the truth must be and we know which = implications we want the requestor to follow. Right? Is there any doubt = at all or any ambiguity in what we want said? ... Paul >>=20 >> Joe Abley wrote: >>=20 >> On 2013-02-22, at 07:57, Paul Vixie wrote: >>=20 >>=20 >> if we can't return nxdomain, then i'm opposed to the omniscient spec, >>=20 >> and we should continue as before, enumerating on the responding = servers >> every zone to which we wish to delegate. >>=20 >> noerror/nodata is the wrong answer. >>=20 >>=20 >> It does smell a bit wrong, but I'm interested in more details of why = you think that if it's more than just the smell. >>=20 >> I'll note that the proposal is to assign new nameservers to be = omniscient, and not to convert the existing ones. We are then in a = position to delegate other local-zoneish zones to the new servers and = review the impact. >>=20 >>=20 >> So, the suggestion is not to replace the existing AS112 servers = (blackhole-1, >> blackhole-2 and prisoner) out of the gate. Any such replacement would = happen later, once there was some degree of comfort that it was safe to = do that. >>=20 >>=20 >>=20 >> Joe >>=20 >> DNSOP mailing list >> DNSOP@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/dnsop >>=20 >> --=20 >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >=20 > --=20 > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Credo quia absurdum est. From warren@kumari.net Mon Feb 25 10:53:18 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130F321E8063 for ; Mon, 25 Feb 2013 10:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djugTNpQ3-in for ; Mon, 25 Feb 2013 10:53:16 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4AD21E8034 for ; Mon, 25 Feb 2013 10:53:15 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id ADAF01B40B78; Mon, 25 Feb 2013 13:53:06 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Mon, 25 Feb 2013 13:53:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0AD7699A-2206-4398-BA86-3A6DC7E08F87@kumari.net> References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> <2b96f0c0-f05e-4547-83b1-dcaa329617c8@email.android.com> <-7471011247182684274@unknownmsgid> To: P Vixie X-Mailer: Apple Mail (2.1499) Cc: IETF DNSOP WG , Peter Koch , George Michaelson , Erik Kline , Joe Abley Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 18:53:18 -0000 On Feb 22, 2013, at 3:47 PM, P Vixie wrote: > Sounds like you want it to return the nxd with no 2308 proof which = means most receives will cache it because the erroneous delegation isn't = present. Bind calls this a minimal response I think. =85 Paul Hmmm=85 'minimal-responses yes' doesn't seem to change the response -- = the ARM says: "If yes the server will only add records to the authority and additional = data sections when they are required, for instance, delegations and = negative responses. This may improve the performance of the server by = reducing outgoing data volumes. The BIND default is no. This statement = may be used in a view or a global options clause." Couldn't find any other hopeful sounding options, but will look a little = more / poke the code... I tried testing anyway, but answer didn't seem to get cached. Did it all = in a bit of a rush, so entirely possible my testing is flawed (it often = is :-P) I have a box configured with 'minimal-responses yes' at = minimal.superficialinjurymonkey.com. (204.194.22.106) if folk want to = test against it=85 W=20 >=20 > Joe Abley wrote: > Hi Paul, >=20 > That was our starting point; however, it turned out that resolvers = wouldn't cache the name error, I think because the SOA returned with the = name error in the authority section was clearly bogus (i.e. conflicted = with the root zone SOA presumably already cached by the resolver = client). >=20 > I too have always preferred the idea of specifying configuration for = standard software over custom code (neat though the custom code Warren = is running is). We just couldn't figure out how to do it.=20 >=20 > Did we miss something? >=20 >=20 > Joe >=20 > Aue Te Ariki! He toki ki roto taku mahuna! >=20 > On 2013-02-22, at 16:39, P Vixie wrote: >=20 >> I'd like to be able to implement this with a standard authority = server, no special code, just a root zone that's empty other than its = apex. So please no requirements for the soa other than that it be at or = above the qname.=20 >>=20 >> Paul >>=20 >> Warren Kumari wrote: >>=20 >> On Feb 22, 2013, at 6:57 AM, Paul Vixie wrote: >>=20 >>=20 >> if we can't return nxdomain, then i'm opposed to the omniscient spec, >>=20 >> and we should continue as before, enumerating on the responding = servers >> every zone to which we wish to delegate. >>=20 >>=20 >> If the WG consensus is NXDOMAIN, we can do that. *We* felt that = NOERROR was more appropriate, but 'its entirely possible we are wrong. >>=20 >>=20 >> W >>=20 >> (If folk feel sufficiently strongly we *could* even strip a label = off, so that the synthesized SOA is not the same as the NXD. *This* feel = really hacks, but putting it out there...)=20 >>=20 >> noerror/nodata is the wrong answer. >>=20 >>=20 >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >>=20 >>=20 >>=20 >> -- >> "I think perhaps the most important problem is that we are trying to = understand the fundamental workings of the universe via a language = devised for telling one another when the best fruit is." --Terry = Prachett=20 >>=20 >>=20 >>=20 >>=20 >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >>=20 >> --=20 >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >=20 > --=20 > Sent from my Android phone with K-9 Mail. Please excuse my brevity. --=20 Do not meddle in the affairs of wizards, for they are subtle and quick = to anger. =20 -- J.R.R. Tolkien From warren@kumari.net Mon Feb 25 11:50:10 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2BA21E80A3 for ; Mon, 25 Feb 2013 11:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOgv3yi18GFv for ; Mon, 25 Feb 2013 11:50:09 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926C721E804D for ; Mon, 25 Feb 2013 11:50:09 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id BEA5C1B417F7; Mon, 25 Feb 2013 14:50:08 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari Date: Mon, 25 Feb 2013 14:50:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8933D4D3-D327-4A25-9D48-B1A3D14A8AE4@kumari.net> References: <20130225191447.27885.83545.idtracker@ietfa.amsl.com> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1499) Subject: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-omniscient-as112-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:50:10 -0000 Hi there, Changed are detailed in the "B.4. Change History", but the 10,000ft = view is NoError was replaced with NXDomain. Draft was about to expire, and submission deadline was fast approaching, = so submitted in a bit of a rush. Apologies for that=85 W Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-wkumari-dnsop-omniscient-as112-02.txt > Date: February 25, 2013 2:14:47 PM EST > To: warren@kumari.net > Cc: ray.bellis@nominet.org.uk, wfms@ryouko.imsb.nrc.ca, = joe.abley@icann.org >=20 >=20 > A new version of I-D, draft-wkumari-dnsop-omniscient-as112-02.txt > has been successfully submitted by Warren Kumari and posted to the > IETF repository. >=20 > Filename: draft-wkumari-dnsop-omniscient-as112 > Revision: 02 > Title: Omniscient AS112 Servers > Creation date: 2013-02-25 > Group: Individual Submission > Number of pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-omniscient-as112-0= 2.txt > Status: = http://datatracker.ietf.org/doc/draft-wkumari-dnsop-omniscient-as112 > Htmlized: = http://tools.ietf.org/html/draft-wkumari-dnsop-omniscient-as112-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-wkumari-dnsop-omniscient-as112-02= >=20 > Abstract: > The AS112 Project loosely coordinates Domain Name System (DNS) > servers to which DNS zones corresponding to private use addresses = are > delegated. Queries for names within those zones have no useful > responses in a global context. The purpose of this project is to > reduce the load of such junk queries on the authoritative name > servers that would otherwise receive them, and instead direct the > load to name servers operated within the AS112 project. >=20 > Adding and dropping zones from the AS112 servers is difficult, due = to > the loosely-coordinated nature of the project. This document > proposes a mechanism by which AS112 name servers could answer > authoritatively for all possible zones. This eliminates the = add/drop > problem, changing it to a matter of delegation within the DNS and > requiring no operational changes on the servers themselves. >=20 > This document updates RFC 6304. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 -- After you'd known Christine for any length of time, you found yourself = fighting a desire to look into her ear to see if you could spot daylight = coming the other way. -- (Terry Pratchett, Maskerade) From ogud@ogud.com Mon Feb 25 13:50:09 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE11D21E80C7 for ; Mon, 25 Feb 2013 13:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUoDAG+EspL4 for ; Mon, 25 Feb 2013 13:50:06 -0800 (PST) Received: from smtp145.iad.emailsrvr.com (smtp145.iad.emailsrvr.com [207.97.245.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6AC21E8040 for ; Mon, 25 Feb 2013 13:50:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp44.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id E899E128399 for ; Mon, 25 Feb 2013 16:50:05 -0500 (EST) X-Virus-Scanned: OK Received: by smtp44.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id CA1B612840D for ; Mon, 25 Feb 2013 16:50:04 -0500 (EST) Message-ID: <512BDC8B.3070602@ogud.com> Date: Mon, 25 Feb 2013 16:50:03 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: dnsop@ietf.org References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Fwd: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:50:09 -0000 I just posted a new version: http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-01.txt On 19/02/2013 11:07, Paul Wouters wrote: > On Mon, 18 Feb 2013, Warren Kumari wrote: > >> The basic idea remains the same -- allow operators to publish new (and >> standby) DS records at the parent by publishing them in their zone, >> signed with their current key. > > I of course hope this draft or something similar will go through. The > fact that the older CDS draft got stuck was for me the motivation > behind draft-wouters-dnsop-secure-update-use-cases but that seems > stalled by people being ver nervous about the RRR model. I had to > carefully not mention any technology I prefered in that draft, but > this kind of mechanism always had my preference, as it requires no > direct parent-child port 53 access, and signaling between parent > and child an be done my helpers that are not in the actual path of > serving DNS data, so it is also the most secure method of doing it. > > What is missing in this draft doing the same for other parent-child > data, such as NS and glue records. Since we have an authenticated > parent-child relationship now, why not extend this draft to include > CNS/GLUEA/GLUEAAAA ? To me it makes sense to integrate it here, because > the mechanism will be basically identical, although perhaps some more > prevention for shooting one's foot might be required. > In new version this will be hinted at but not explained to constrain scope. > In many environments (for example, gTLDs) the parent will be a > registry, and is expected to not have direct contact with the child > (registrant). > > I recommend removing ANY kind of language that ties anything to the RRR > model, as just mentioning it is what more or less killed the use-cases > draft. That includes mentioning TLDs or "Registry interface". Specify the > protocol, leave out the administration/politics and don't tell people > how to integrate the implementation. Well the new version has more text not less but hopefully as it all examples this will not cause problems. > > In this case the parental agent will query each child zone that has a > DS RRset, looking for CDS RRset > > That's a good mechanism to leave the initial auth specification (tied to > RRR or not) out of the spec! Bravo! > > If the validation succeeds with a DNSKEY that is represented > in the current DS RRset in parent. > > You have to be more strict then just "validation succeeds". You MUST > ensure the proper DNSKEY's matching the CDS records exist on ALL > secondary servers, and must wait AT LEAST a TTL time before being > willing to update the DS record. New version says: If present the Parental Agent MUST validate [] the CDS RRset. If the validation succeeds with a DNSKEY that is represented in the current DS RRset in parent. Hope that is strong enough > > The parenteral agent should > submit a request to the registry to publish the contents of the CDS > RR(s) as the new a DS record(s) for that zone. > > But here you go wrong. Rewrite it to not mention "registry". Just talk > about the parent zone manager. You could be talking about an inline > bind, a cron job, some perl code, a database ...whatever the parent is. Attempted to fix this. > > The registry should log if possible the source of the update, > user interface/CDS etc. > > Same here. > > > IN CDS 0 0 0 > > I really dislike this idea. An attacker that has no access to the keys, > but does have access to unsigned zone data could put such a record in > the zone to fully remove the security added by the DNSSEC signer to > which they might not have access (yet). This can cause an escalation > from "needing a still-compromised server" to "only need to compromise a > server briefly and then leave without a trace". > If they have that access what stops them then from publishing anything in the zone, including forged DNAME records? > I believe you should stick to out of band communication for both secure-> > insecure and insecure -> secure. > thanks for the good comments. Olafur From sm@resistor.net Mon Feb 25 13:55:04 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8106421E80F4 for ; Mon, 25 Feb 2013 13:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzM+3ziYSuEI for ; Mon, 25 Feb 2013 13:54:53 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3B21E80EE for ; Mon, 25 Feb 2013 13:54:53 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1PLsi6r028853; Mon, 25 Feb 2013 13:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361829289; bh=ANqJ6pDknwoeoiUrtHdL+uX8fv9g3is5xvqWIW3hbds=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Rv3+/CwtEN+zJs3j4xRcdURV3gIdryJ9OMIy8n65aIpFEd97I73DX+NKRUu7o97Mh LnTC3oPQsIwdL4x0dN8GXq+RLIeI5opRJI84yjinvKUqjeFKrjsEU0Ghe0fJjVSGpC RAh/5BVS857px8C20f7Zq/KKagwpaHxcqxyOTHNE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1361829289; i=@resistor.net; bh=ANqJ6pDknwoeoiUrtHdL+uX8fv9g3is5xvqWIW3hbds=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=g4t3pxdim1/Ln+OlIPAc3vjzA6KNh+Qbg/W+XAECpHNZn74HDsO4fxfNZGO7yT2zA TLjDg8Ggtw9QCwV6dLtFlL1Heqka6M2KOYPQ+zQ9IlIptFRRxnlc2nPKCrovNdUDMe YVgi6he9lQUOleurnJRKs5Y+gyNqCynEWXHeaKFY= Message-Id: <6.2.5.6.2.20130225133630.0a862de0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Feb 2013 13:52:49 -0800 To: Joe Abley From: SM In-Reply-To: <-7632368423442499756@unknownmsgid> References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> <6.2.5.6.2.20130224084244.0afd0be8@resistor.net> <-7632368423442499756@unknownmsgid> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:55:05 -0000 Hi Joe, At 14:35 24-02-2013, Joe Abley wrote: >The most recent decision that I saw from the chairs was that it should >not be adopted. I do not agree that that is the best path forward. The draft might have crossed the review threshold after the deadline. Authors are usually given an opportunity to cross that threshold. That tends to fail when there isn't adequate socialization. Regards, -sm From paul@nohats.ca Mon Feb 25 14:28:09 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C20C21F924F for ; Mon, 25 Feb 2013 14:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lryjh-BGnrKV for ; Mon, 25 Feb 2013 14:28:07 -0800 (PST) Received: from mx.nohats.ca (unknown [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5258021F9239 for ; Mon, 25 Feb 2013 14:28:02 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZFHq35fpHz9Xr; Mon, 25 Feb 2013 17:27:59 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BsTkH6H3KCkN; Mon, 25 Feb 2013 17:27:58 -0500 (EST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 25 Feb 2013 17:27:58 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 37CAA80D3D; Mon, 25 Feb 2013 17:27:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 150D780D3C; Mon, 25 Feb 2013 17:27:58 -0500 (EST) Date: Mon, 25 Feb 2013 17:27:58 -0500 (EST) From: Paul Wouters To: Olafur Gudmundsson In-Reply-To: <512BDC8B.3070602@ogud.com> Message-ID: References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net> <512BDC8B.3070602@ogud.com> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] Fwd: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:28:09 -0000 On Mon, 25 Feb 2013, Olafur Gudmundsson wrote: >> You have to be more strict then just "validation succeeds". You MUST >> ensure the proper DNSKEY's matching the CDS records exist on ALL >> secondary servers, and must wait AT LEAST a TTL time before being >> willing to update the DS record. > > New version says: > If present the Parental Agent MUST validate [ target="RFC4035">] the CDS RRset. If the validation succeeds > with a DNSKEY that is represented in the current DS RRset in > parent. > > Hope that is strong enough I'm not sure. I don't see RFC 4035 talking about what a recursor should do when it needs to find DNSKEY x1 and it contacts a (random) child name server and x1 is not there. Is that a bogus response, or will it try the other child name servers in an attempt to find the x1 DNSKEY? I think for a name server to roll its DS for the child, it should really ensure the CDS records point to DNSKEYs that have been available in the child zone for TTL(DNSKEY) time on _all_ child zone name servers. This might be different from the "regular" policy of DNSSEC capable resolvers. Paul From warren@kumari.net Mon Feb 25 14:48:26 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708D521E8119 for ; Mon, 25 Feb 2013 14:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roxys-4z-yUs for ; Mon, 25 Feb 2013 14:48:25 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95D021E810D for ; Mon, 25 Feb 2013 14:48:25 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 1FEE91B40C36; Mon, 25 Feb 2013 17:48:25 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <6.2.5.6.2.20130225133630.0a862de0@resistor.net> Date: Mon, 25 Feb 2013 17:48:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> <6.2.5.6.2.20130224084244.0afd0be8@resistor.net> <-7632368423442499756@unknownmsgid> <6.2.5.6.2.20130225133630.0a862de0@resistor.net> To: SM X-Mailer: Apple Mail (2.1499) Cc: dnsop@ietf.org, Joe Abley Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:48:26 -0000 On Feb 25, 2013, at 4:52 PM, SM wrote: > Hi Joe, > At 14:35 24-02-2013, Joe Abley wrote: >> The most recent decision that I saw from the chairs was that it = should >> not be adopted. I do not agree that that is the best path forward. >=20 > The draft might have crossed the review threshold after the deadline. = Authors are usually given an opportunity to cross that threshold. That = tends to fail when there isn't adequate socialization. >=20 Yup -- the call for adoption on Saturday the 9th, and ended on Monday = the 18th, which was a public holiday / long weekend in the USA. This = means that US folk only had 4 or 5 working days to read and comment. If = it had been run for the more traditional 2 weeks (and if folk had = realized that they specifically had to state that they would be a = reviewer) thing might have gone differently. But yes, fully agree that we could have socialized this better=85. W > Regards, > -sm >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 -- It is impossible to sharpen a pencil with a blunt axe. It is equally = vain to try to do it with ten blunt axes instead. -- E.W Dijkstra, 1930-2002 From fanf2@hermes.cam.ac.uk Mon Feb 25 16:29:12 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E82221E8198 for ; Mon, 25 Feb 2013 16:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.744 X-Spam-Level: X-Spam-Status: No, score=-3.744 tagged_above=-999 required=5 tests=[AWL=-1.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AER5Rq8Dte4g for ; Mon, 25 Feb 2013 16:29:11 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id C300E21E8165 for ; Mon, 25 Feb 2013 16:29:11 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38456) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1UA8Pn-0006Ix-7s (Exim 4.80_167-5a66dd3) (return-path ); Tue, 26 Feb 2013 00:29:03 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UA8Pn-0005Hq-DU (Exim 4.72) (return-path ); Tue, 26 Feb 2013 00:29:03 +0000 Date: Tue, 26 Feb 2013 00:29:03 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "Dickson, Brian" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: IETF DNSOP WG , Paul Vixie , Peter Koch , George Michaelson , Erik Kline , Joe Abley Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:29:12 -0000 Dickson, Brian wrote: > > However, there is another UGLY, EVIL way that might achieve what you're > thinking of: > > Instead of delegating to omniscient AS112 servers, what about doing a > DNAME to a specific target "foo" (replace "foo" with what you will) in the > DNS tree? Like this? We have had (afaik) one interop problem with this setup: there was a mail server on a network with DNAMEd reverse DNS, and some recipient sites objected to this. ; <<>> DiG 9.9.2-vjs340.03-P1 <<>> @authdns0.csx.cam.ac.uk -x 128.232.255.255 ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47436 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;255.255.232.128.in-addr.arpa. IN PTR ;; ANSWER SECTION: 255.232.128.in-addr.arpa. 86400 IN DNAME 255.232.128.in-addr.arpa.cam.ac.uk. 255.255.232.128.in-addr.arpa. 86400 IN CNAME 255.255.232.128.in-addr.arpa.cam.ac.uk. ;; AUTHORITY SECTION: in-addr.arpa.cam.ac.uk. 14400 IN SOA authdns0.csx.cam.ac.uk. hostmaster.ucs.cam.ac.uk. 1361480354 14400 3600 604800 14400 ;; Query time: 0 msec ;; SERVER: 2001:630:212:8::d:a0#53(2001:630:212:8::d:a0) ;; WHEN: Tue Feb 26 00:25:59 2013 ;; MSG SIZE rcvd: 187 Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From fanf2@hermes.cam.ac.uk Mon Feb 25 16:31:29 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2DE21E8165 for ; Mon, 25 Feb 2013 16:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.64 X-Spam-Level: X-Spam-Status: No, score=-3.64 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLuNxwkCl42i for ; Mon, 25 Feb 2013 16:31:20 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id F29C721E8170 for ; Mon, 25 Feb 2013 16:31:19 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38658) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1UA8Ry-0006qU-8P (Exim 4.80_167-5a66dd3) (return-path ); Tue, 26 Feb 2013 00:31:18 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UA8Ry-0005Uf-Iy (Exim 4.72) (return-path ); Tue, 26 Feb 2013 00:31:18 +0000 Date: Tue, 26 Feb 2013 00:31:18 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Joe Abley In-Reply-To: <-7471011247182684274@unknownmsgid> Message-ID: References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> <2b96f0c0-f05e-4547-83b1-dcaa329617c8@email.android.com> <-7471011247182684274@unknownmsgid> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Erik Kline , IETF DNSOP WG , P Vixie , Peter Koch , George Michaelson Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:31:30 -0000 Joe Abley wrote: > > I too have always preferred the idea of specifying configuration for > standard software over custom code (neat though the custom code Warren is > running is). We just couldn't figure out how to do it. Why not something like Paul's metazone idea to automate the configuration of which zones the server should answer for? Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From paul@redbarn.org Mon Feb 25 16:45:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9C221E818F for ; Mon, 25 Feb 2013 16:45:46 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46lRwtJh4llr for ; Mon, 25 Feb 2013 16:45:33 -0800 (PST) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 97BA021E80D6 for ; Mon, 25 Feb 2013 16:45:33 -0800 (PST) Received: from [IPv6:2001:4f8:3:30:d0c5:c2b1:2ea8:716e] (unknown [IPv6:2001:4f8:3:30:d0c5:c2b1:2ea8:716e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 02270EBC88 for ; Tue, 26 Feb 2013 00:45:32 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <512C05AC.2050501@redbarn.org> Date: Mon, 25 Feb 2013 16:45:32 -0800 From: Paul Vixie User-Agent: Postbox 3.0.7 (Windows/20130120) MIME-Version: 1.0 To: IETF DNSOP WG References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de> <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org> <20130222054700.2A7232FF489B@drugs.dv.isc.org> <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> <2b96f0c0-f05e-4547-83b1-dcaa329617c8@email.android.com> <-7471011247182684274@unknownmsgid> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/alternative; boundary="------------000404060106070000060907" Subject: Re: [DNSOP] Adoption of as a WG work item? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:45:46 -0000 This is a multi-part message in MIME format. --------------000404060106070000060907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ... Tony Finch wrote: > ... > Why not something like Paul's metazone idea to automate the configuration > of which zones the server should answer for? for reference: http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html paul --------------000404060106070000060907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ...

Tony Finch wrote:
... 
Why not something like Paul's metazone idea to automate the configuration
of which zones the server should answer for?

for reference: 
http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html



paul



--------------000404060106070000060907--

From paul@redbarn.org  Mon Feb 25 16:48:45 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FB321E818B for ; Mon, 25 Feb 2013 16:48:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Dcnf8OJ5nuf for ; Mon, 25 Feb 2013 16:48:42 -0800 (PST)
Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1B76421E80B6 for ; Mon, 25 Feb 2013 16:48:41 -0800 (PST)
Received: from [IPv6:2001:4f8:3:30:d0c5:c2b1:2ea8:716e] (unknown [IPv6:2001:4f8:3:30:d0c5:c2b1:2ea8:716e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id D1A28EBC88 for ; Tue, 26 Feb 2013 00:48:40 +0000 (UTC) (envelope-from paul@redbarn.org)
Message-ID: <512C0668.5000809@redbarn.org>
Date: Mon, 25 Feb 2013 16:48:40 -0800
From: Paul Vixie 
User-Agent: Postbox 3.0.7 (Windows/20130120)
MIME-Version: 1.0
To: IETF DNSOP WG 
References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de>  <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org>  <20130222054700.2A7232FF489B@drugs.dv.isc.org>  <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> <2b96f0c0-f05e-4547-83b1-dcaa329617c8@email.android.com> <-7471011247182684274@unknownmsgid>  <512C05AC.2050501@redbarn.org>
In-Reply-To: <512C05AC.2050501@redbarn.org>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/alternative; boundary="------------000700000605060008050607"
Subject: Re: [DNSOP] Adoption of  as a WG work item?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 00:48:45 -0000

This is a multi-part message in MIME format.
--------------000700000605060008050607
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

...

Paul Vixie wrote:
> ...
>
> Tony Finch wrote:
>> ...
>> Why not something like Paul's metazone idea to automate the configuration
>> of which zones the server should answer for?
> for reference:
> http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html
>

that message's pdf attachment appears to have been corrupted. another
copy is here: 

paul

--------------000700000605060008050607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



...



Paul Vixie wrote:


  

...


  


Tony Finch wrote:
  
...
  
Why not something like Paul's metazone idea to automate the configuration
of which zones the server should answer for?



for reference: 
  http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html


  





that message's pdf attachment appears to have been corrupted. another 
copy is here: <http://ss.vix.su/~vixie/mz.pdf>



paul



--------------000700000605060008050607--

From ed.lewis@neustar.biz  Tue Feb 26 00:54:25 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01421F89B3 for ; Tue, 26 Feb 2013 00:54:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.4
X-Spam-Level: 
X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[AWL=0.598,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AnJC7iD4uRG for ; Tue, 26 Feb 2013 00:54:20 -0800 (PST)
Received: from eastrmfepo202.cox.net (eastrmfepo202.cox.net [68.230.241.217]) by ietfa.amsl.com (Postfix) with ESMTP id 7C85A21F88BE for ; Tue, 26 Feb 2013 00:54:20 -0800 (PST)
Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130226085409.JVVG6475.eastrmfepo202.cox.net@eastrmimpo210> for ; Tue, 26 Feb 2013 03:54:09 -0500
Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id 4wu71l0033cuADQ01wu7i0; Tue, 26 Feb 2013 03:54:09 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020203.512C7831.00C9,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=NvcPhbhJ c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=y5nnOHSi8JIA:10 a=J2G14JED2TEA:10 a=hGBaWAWWAAAA:8 a=PdPjSeL30ToA:10 a=DKEz6YOjHAnnLqRsNw4A:9 a=pILNOxqGKmIA:10 a=OJQOOm8YCWIFU25CaJAA:9 a=_W_S_7VecoQA:10 a=QTag9Hu9I2Z-9ex8:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7DC0E1FD-74B8-46F4-AF40-197EE7CEA64A"
From: Edward Lewis 
In-Reply-To: 
Date: Tue, 26 Feb 2013 16:54:06 +0800
Message-Id: 
References: <20130209204558.GA12175@x28.adm.denic.de> 
To: IETF DNSOP WG 
X-Mailer: Apple Mail (2.1283)
Cc: Edward Lewis 
Subject: [DNSOP] Comment on 
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 08:54:25 -0000

--Apple-Mail=_7DC0E1FD-74B8-46F4-AF40-197EE7CEA64A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Suggested change to draft-wkumari-dnsop-omniscient-as112-01.txt.

From:

   AS112 Servers do not respond to AXFR (QTYPE=3D252) or IXFR =
(QTYPE=3D251)
   requests.

To:

   AS112 Servers respond to AXFR (QTYPE=3D252) or IXFR (QTYPE=3D251) =
with RCODE=3DREFUSED.

But I am not sure if the existing is just an explanation of what is =
defined elsewhere or whether it is setting the "standard."  I'd =
discourage any attempt to define "no response" as the default response =
to any query in DNS.  (I'm fine with so-called rate-limit-caused no =
responses, but not blanket no responses.)=

--Apple-Mail=_7DC0E1FD-74B8-46F4-AF40-197EE7CEA64A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Suggested change to =
draft-wkumari-dnsop-omniscient-as112-01.txt.

From:
<=
div>
   =
AS112 Servers do not respond to AXFR (QTYPE=3D252) or IXFR (QTYPE=3D251)
   requests.
=


To:

<=
div>
   AS112 Servers respond to AXFR =
(QTYPE=3D252) or IXFR (QTYPE=3D251) with RCODE=3DREFUSED.


But I am not sure if the existing =
is just an explanation of what is defined elsewhere or whether it is =
setting the "standard."  I'd discourage any attempt to define "no =
response" as the default response to any query in DNS.  (I'm fine =
with so-called rate-limit-caused no responses, but not blanket no =
responses.)
=

--Apple-Mail=_7DC0E1FD-74B8-46F4-AF40-197EE7CEA64A--

From sm@resistor.net  Tue Feb 26 01:35:46 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6BF21F89D3 for ; Tue, 26 Feb 2013 01:35:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.578
X-Spam-Level: 
X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JlZzeCVAo-B for ; Tue, 26 Feb 2013 01:35:45 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EC521F89DA for ; Tue, 26 Feb 2013 01:35:44 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1Q9ZaDe028782; Tue, 26 Feb 2013 01:35:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361871341; bh=CDKa8sxrAWm1VZbYuN3DrIp8rEFqyeShQYXQqcaYKz0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bYk86JLsr6sjuXwy7DTBCBuhSjXKmA3BGRn3F+Jsb7Vev78t0HHqngAQb/WFrApob xZ+uMO9TO8itGrgkUPMqxNETcks40HjJdOK/ytDuQ4XklSragrS7bnEI7cC+4jxGoG hSlDW1QqqD59XoORBukfjIridJz8wfMPUAEzubxw=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1361871341; i=@resistor.net; bh=CDKa8sxrAWm1VZbYuN3DrIp8rEFqyeShQYXQqcaYKz0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MmZrmvau1HR38fUK5WuX7X6/lnsm/4MZiTZNqIUArV9xA/p1HuxzDHMjWzfRCh/dk khS7IXcgaP5GNDr7NTOaUIckl3Wa6yKPmxLgpQ04abNI/oBVBOsw1q4NJemSOdivWS ORCjdfeZYz+vjPfd+hNlohe0cPJxC+Xy9Rd124bI=
Message-Id: <6.2.5.6.2.20130226011556.099c9438@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 26 Feb 2013 01:34:17 -0800
To: Peter Koch , Stephen Morris 
From: SM 
In-Reply-To: 
References: <20130209204558.GA12175@x28.adm.denic.de> <20130218171639.GC27968@x28.adm.denic.de>  <20130220083647.GA8527@miek.nl> <20130220204654.8ABD02FEA123@drugs.dv.isc.org>  <20130222054700.2A7232FF489B@drugs.dv.isc.org>  <51275D39.1070806@redbarn.org> <7B96E4B6-E1E5-4517-9D7D-0383170A6820@kumari.net> <6.2.5.6.2.20130224084244.0afd0be8@resistor.net> <-7632368423442499756@unknownmsgid> <6.2.5.6.2.20130225133630.0a862de0@resistor.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Adoption of  as a WG work item?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 09:35:46 -0000

Hi Peter, Stephen,
At 14:48 25-02-2013, Warren Kumari wrote:
>Yup -- the call for adoption on Saturday the 9th, and ended on 
>Monday the 18th, which was a public holiday / long weekend in the 
>USA. This means that US folk only had 4 or 5 working days to read 
>and comment.  If it had been run for the more traditional 2 weeks 
>(and if folk had realized that they specifically had to state that 
>they would be a reviewer) thing might have gone differently.

There seems to have been a glitch during the call for adoption of 
draft-wkumari-dnsop-omniscient-as112-01.  Would it be possible for 
you to look into whether anything could be done?

Thanks,
-sm 


From ogud@ogud.com  Tue Feb 26 07:03:19 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2DD21F8691 for ; Tue, 26 Feb 2013 07:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpCSIk8w1db4 for ; Tue, 26 Feb 2013 07:03:19 -0800 (PST)
Received: from smtp185.iad.emailsrvr.com (smtp185.iad.emailsrvr.com [207.97.245.185]) by ietfa.amsl.com (Postfix) with ESMTP id 41FE521F868B for ; Tue, 26 Feb 2013 07:03:19 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id A3B72E0A89; Tue, 26 Feb 2013 10:03:18 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp28.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 79A79E0AFD;  Tue, 26 Feb 2013 10:03:18 -0500 (EST)
Message-ID: <512CCEB4.3040403@ogud.com>
Date: Tue, 26 Feb 2013 10:03:16 -0500
From: Olafur Gudmundsson 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Paul Wouters 
References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net>  <512BDC8B.3070602@ogud.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 15:03:20 -0000

On 25/02/2013 17:27, Paul Wouters wrote:
> On Mon, 25 Feb 2013, Olafur Gudmundsson wrote:
>
>>> You have to be more strict then just "validation succeeds". You MUST
>>> ensure the proper DNSKEY's matching the CDS records exist on ALL
>>> secondary servers, and must wait AT LEAST a TTL time before being
>>> willing to update the DS record.
>>
>> New version says:
>>          If present the Parental Agent MUST validate [>          target="RFC4035">] the CDS RRset. If the validation 
>> succeeds
>>          with a DNSKEY that is represented in the current DS RRset in 
>> parent.
>>
>> Hope that is strong enough
>
> I'm not sure. I don't see RFC 4035 talking about what a recursor should
> do when it needs to find DNSKEY x1 and it contacts a (random) child name
> server and x1 is not there. Is that a bogus response, or will it try the
> other child name servers in an attempt to find the x1 DNSKEY?

local policy for each validator implementation possibly configurable and 
possibly
affected on what is observed, the general principle is "If it validates: 
done"
in your example it is not clear if the DNSKEY RRset validates
     but is missing the key you are looking for.
     or if you expect the set to be validated by key x1.
>
> I think for a name server to roll its DS for the child, it should really
> ensure the CDS records point to DNSKEYs that have been available in the
> child zone for TTL(DNSKEY) time on _all_ child zone name servers.
>
I realized that while we can add that as guidance there is a missing 
part of the rule in the draft:
The Parental Agent MUST/SHOULD make sure that replacing the DS with the 
CDS will not break the
delegation. (Principle: Child can shoot itself in the foot but Parent 
should avoid to harm Child)

> This might be different from the "regular" policy of DNSSEC capable
> resolvers.
>
> Paul

     Olafur


From bdickson@verisign.com  Tue Feb 26 08:31:59 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6471E21F8952 for ; Tue, 26 Feb 2013 08:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WliD++o+EOmO for ; Tue, 26 Feb 2013 08:31:58 -0800 (PST)
Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id D846B21F88C8 for ; Tue, 26 Feb 2013 08:31:11 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKUSzjSydIsC7NC8BQ74PR3/DBhocQs8NY@postini.com; Tue, 26 Feb 2013 08:31:49 PST
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r1QGUodE030530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Feb 2013 11:30:50 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 26 Feb 2013 11:30:50 -0500
From: "Dickson, Brian" 
To: Tony Finch 
Thread-Topic: [DNSOP] Adoption of  as a WG work item?
Thread-Index: AQHOETlDX3NIooTBpUOWp2gcK0s1d5iLoe2AgAC45AA=
Date: Tue, 26 Feb 2013 16:30:49 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15B3A59804EEF24189B3671508C159CE@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF DNSOP WG , Paul Vixie , Peter Koch , George Michaelson , Erik Kline , Joe Abley 
Subject: Re: [DNSOP] Adoption of  as a WG work item?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 16:31:59 -0000

On 2/25/13 7:29 PM, "Tony Finch"  wrote:

>Dickson, Brian  wrote:
>>
>> However, there is another UGLY, EVIL way that might achieve what you're
>> thinking of:
>>
>> Instead of delegating to omniscient AS112 servers, what about doing a
>> DNAME to a specific target "foo" (replace "foo" with what you will) in
>>the
>> DNS tree?
>
>Like this?

Yes. Except, of course, for AS112 domains, and for some agreed-upon target.

While mail servers doing PTR look-up having problems is a potential
concern,
keep in mind that AS112 is meant to be used for "local"-ish zones, like
10.in-addr.arpa.

If a mail server is doing PTR look-up for net-10, in a way that leaks,
IMHO,
failure _is_ an option. :-)

(Hint - public mail servers establishing TCP to/from a net-10 address is
already pretty bad.
Behind firewalls/closed-doors, net-10 is fine, but reverse DNS on that
should be handled
both privately and properly.)

Brian


>
>We have had (afaik) one interop problem with this setup: there was a mail
>server on a network with DNAMEd reverse DNS, and some recipient sites
>objected to this.
>
>; <<>> DiG 9.9.2-vjs340.03-P1 <<>> @authdns0.csx.cam.ac.uk -x
>128.232.255.255
>; (2 servers found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47436
>;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
>;; WARNING: recursion requested but not available
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 4096
>;; QUESTION SECTION:
>;255.255.232.128.in-addr.arpa.	IN	PTR
>
>;; ANSWER SECTION:
>255.232.128.in-addr.arpa.
>86400	IN	DNAME	255.232.128.in-addr.arpa.cam.ac.uk.
>255.255.232.128.in-addr.arpa. 86400
>IN	CNAME	255.255.232.128.in-addr.arpa.cam.ac.uk.
>
>;; AUTHORITY SECTION:
>in-addr.arpa.cam.ac.uk.	14400	IN	SOA	authdns0.csx.cam.ac.uk.
>hostmaster.ucs.cam.ac.uk. 1361480354 14400 3600 604800 14400
>
>;; Query time: 0 msec
>;; SERVER: 2001:630:212:8::d:a0#53(2001:630:212:8::d:a0)
>;; WHEN: Tue Feb 26 00:25:59 2013
>;; MSG SIZE  rcvd: 187
>
>Tony.
>--=20
>f.anthony.n.finch    http://dotat.at/
>Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at
>first.
>Rough, becoming slight or moderate. Showers, rain at first. Moderate or
>good,
>occasionally poor at first.


From warren@kumari.net  Tue Feb 26 09:56:20 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EB521F87E9 for ; Tue, 26 Feb 2013 09:56:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.238
X-Spam-Level: 
X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkryWKgPRFP2 for ; Tue, 26 Feb 2013 09:56:20 -0800 (PST)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id F071721F8812 for ; Tue, 26 Feb 2013 09:56:19 -0800 (PST)
Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 52DFF1B41867; Tue, 26 Feb 2013 12:56:19 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Warren Kumari 
In-Reply-To: 
Date: Tue, 26 Feb 2013 12:56:18 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <951F3D61-8D1C-4D94-BBFD-4D63017B9B14@kumari.net>
References: <20130209204558.GA12175@x28.adm.denic.de>  
To: Edward Lewis 
X-Mailer: Apple Mail (2.1499)
Cc: IETF DNSOP WG 
Subject: Re: [DNSOP] Comment on 
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 17:56:20 -0000

On Feb 26, 2013, at 3:54 AM, Edward Lewis  wrote:

> Suggested change to draft-wkumari-dnsop-omniscient-as112-01.txt.
>=20
> From:
>=20
>    AS112 Servers do not respond to AXFR (QTYPE=3D252) or IXFR =
(QTYPE=3D251)
>    requests.
>=20
>=20
> To:
>=20
>    AS112 Servers respond to AXFR (QTYPE=3D252) or IXFR (QTYPE=3D251) =
with RCODE=3DREFUSED.
>=20
>=20
> But I am not sure if the existing is just an explanation of what is =
defined elsewhere or whether it is setting the "standard."  I'd =
discourage any attempt to define "no response" as the default response =
to any query in DNS.  (I'm fine with so-called rate-limit-caused no =
responses, but not blanket no responses.)

Oh, yeah, nice catch -- and, as always, thanks for providing text.

W

--=20
"Does Emacs have the Buddha nature? Why not? It has bloody well =
everything else..."




From fanf2@hermes.cam.ac.uk  Tue Feb 26 11:38:40 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3176F21F87BB for ; Tue, 26 Feb 2013 11:38:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.553
X-Spam-Level: 
X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[AWL=1.045,  BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZM1klDNu4qQ for ; Tue, 26 Feb 2013 11:38:39 -0800 (PST)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1EC21F861A for ; Tue, 26 Feb 2013 11:38:39 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:60943) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1UAQMC-0007BE-sa (Exim 4.72) (return-path ); Tue, 26 Feb 2013 19:38:32 +0000
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UAQMC-0005fX-Sz (Exim 4.72) (return-path ); Tue, 26 Feb 2013 19:38:32 +0000
Date: Tue, 26 Feb 2013 19:38:32 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: "Dickson, Brian" 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Cc: IETF DNSOP WG , Paul Vixie , Peter Koch , George Michaelson , Erik Kline , Joe Abley 
Subject: Re: [DNSOP] Adoption of  as a WG work item?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 19:38:40 -0000

Dickson, Brian  wrote:
>
> While mail servers doing PTR look-up having problems is a potential
> concern, keep in mind that AS112 is meant to be used for "local"-ish
> zones, like 10.in-addr.arpa.

Right. I probably should have said more clearly that it works pretty well
if that is the worst interop problem.

I just remembered another problem, that many unices have antediluvian stub
resolvers that write to syslog when they see a DNAME record, e.g.

gethostby*.getanswer: asked for "42.143.232.128.in-addr.arpa IN PTR", got type "39"

Apart from logging, the code ignores the DNAME record and happily
processes the synthesized CNAME record, so it is mostly a benign bug apart
from the annoying noise in the logs. If AS112 were to use DNAME this is
likely to become a tiresome FAQ.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

From alexander.mayrhofer@nic.at  Wed Feb 27 05:18:14 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0245821F8479 for ; Wed, 27 Feb 2013 05:18:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.43
X-Spam-Level: 
X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COV+eiw0ORhh for ; Wed, 27 Feb 2013 05:18:13 -0800 (PST)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0D121F85B2 for ; Wed, 27 Feb 2013 05:18:07 -0800 (PST)
Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Wed, 27 Feb 2013 14:18:05 +0100
Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Wed, 27 Feb 2013 14:18:01 +0100
From: Alexander Mayrhofer 
To: "dnsop@ietf.org" 
Thread-Topic: DS without NS in a delegation?
Thread-Index: Ac4U7AfI1Hqu9W75RlSYtWWR8w0g+w==
Date: Wed, 27 Feb 2013 13:18:01 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE0750980645F@NICS-EXCH.sbg.nic.at>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.10.0.162]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-XWALL-BCKS: auto
Subject: [DNSOP] DS without NS in a delegation?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 13:18:14 -0000

Hi,

We've been discussing internally whether or not including DS records into a=
 zone without respective NS record(s) makes any sense (assuming that there =
are no other RRSETs for the respective label in the zone itself - pure "del=
egation" scenario)... My personal assumption is that it does not, since the=
 DS record can never be used to verify the information in the (unreachable)=
 delegated zone?=20

On a related (although slightly off topic) issue, we were also assuming tha=
t EPP status values "serverHold" as well as "clientHold" do affect both NS =
as well as DS records.

Comments appreciated.

thanks,
Alex Mayrhofer


From roy@dnss.ec  Wed Feb 27 05:50:36 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C02121F859D for ; Wed, 27 Feb 2013 05:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJuH9uA7xrVx for ; Wed, 27 Feb 2013 05:50:34 -0800 (PST)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 241E021F857A for ; Wed, 27 Feb 2013 05:50:31 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id hi8so6284467wib.1 for ; Wed, 27 Feb 2013 05:50:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=x5axGH0aCFpjdPb0nyxKrFnN5DC5e248Sj5YNmL2Tcg=; b=Zepmu9rqJLdUcEBjLS7b456WKtGFVAdjjmJrtR8mU2SFmwdESwRDrlhOMxvv/bW5zs t7IPZ95ctbc0OISBuc8czi98yXZDzvK+f+bZxbkH0BCZYimTaf3+SPtmU+gx93DAE9W3 3yNKxG44lW5RbXTARylEsDfo3jRVx9SvZS8+I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=x5axGH0aCFpjdPb0nyxKrFnN5DC5e248Sj5YNmL2Tcg=; b=AQKpZkXezS5jb4jovYzFqXHpJSZj42jtViKgGDmqTWxfjA2hL0PIKeAzj9hSGaF0hM jnZGlAs/umCPxc+vPN82svo5wW1LSPyDOLobQEXdIfrWwNc7ZafmWCzGjUKCVcRvZ+Xn EZUaKiyG7N5Y4Qv8pOsKgteU5O3ne4O8u4imTk3FTY6v7T0YcQtf3ieUjZjt99RUFt1Y JEEhR1asxRuvONTHJtcvy/2EExABmnkACq8whRLu7ZUfpjX9LRhENcft82qw0vh7KPvX 3gi53Jz6xMj3hdWekNq73cKDz3dpUfcQZ072P9RhjG2lhw6U5lL5Ur9/yuWyTnMZsJDT 1HHA==
X-Received: by 10.181.12.5 with SMTP id em5mr3955154wid.24.1361973031244; Wed, 27 Feb 2013 05:50:31 -0800 (PST)
Received: from roysmacbookpro.home (host109-150-70-204.range109-150.btcentralplus.com. [109.150.70.204]) by mx.google.com with ESMTPS id bs6sm8882746wib.4.2013.02.27.05.50.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 05:50:30 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=us-ascii
From: Roy Arends 
In-Reply-To: <19F54F2956911544A32543B8A9BDE0750980645F@NICS-EXCH.sbg.nic.at>
Date: Wed, 27 Feb 2013 13:50:29 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <19F54F2956911544A32543B8A9BDE0750980645F@NICS-EXCH.sbg.nic.at>
To: Alexander Mayrhofer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmtmlFqrEiCRrzZgatCSxYR6tq1UM9PdXzBLGqKpN28DUCaGl5jXzyZbUkqwgJZ3ql+Cq5D
Cc: "dnsop@ietf.org" 
Subject: Re: [DNSOP] DS without NS in a delegation?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 13:50:36 -0000

On Feb 27, 2013, at 1:18 PM, Alexander Mayrhofer =
 wrote:

> Hi,
>=20
> We've been discussing internally whether or not including DS records =
into a zone without respective NS record(s) makes any sense (assuming =
that there are no other RRSETs for the respective label in the zone =
itself - pure "delegation" scenario)... My personal assumption is that =
it does not, since the DS record can never be used to verify the =
information in the (unreachable) delegated zone?=20

When a parent and child zone are served from the same server set, like =
co.uk and uk, you could have _in_theory_ DS records without NS records =
in the parent zone. A resolver would never observe the delegation point =
NS record. A validating resolver would need to explicitly ask for the DS =
record. If the DS record is present, the DS plus signatures will be =
returned. However, absence of the DS record is problematic, as there is =
no NSEC(3) record indicating presence of NS, absence of SOA+DS.=20

I think you'd need to implement these specifics though, as current =
authoritative servers and signers might throw an error when observing a =
DS without NS, but I haven't checked.

I wouldn't recommend it though, it might introduce corner cases. See =
RFC6840, section 4.1 as an example of what such a corner case might look =
like.

Hope this helps,

Roy Arends
Nominet Research Fellow=

From bortzmeyer@nic.fr  Wed Feb 27 08:00:40 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D0621F8539 for ; Wed, 27 Feb 2013 08:00:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.825
X-Spam-Level: 
X-Spam-Status: No, score=-101.825 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-iYXixHoPEF for ; Wed, 27 Feb 2013 08:00:35 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id EF76621F8519 for ; Wed, 27 Feb 2013 08:00:34 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 290D82802D6; Wed, 27 Feb 2013 17:00:02 +0100 (CET)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 244592802C0; Wed, 27 Feb 2013 17:00:02 +0100 (CET)
Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay2.nic.fr (Postfix) with ESMTP id 22617B38066; Wed, 27 Feb 2013 16:59:32 +0100 (CET)
Date: Wed, 27 Feb 2013 16:59:32 +0100
From: Stephane Bortzmeyer 
To: Tony Finch 
Message-ID: <20130227155931.GA8931@nic.fr>
References: <20130207111446.GM1320@x28.adm.denic.de> <20130218100517.GA12211@nic.fr> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Operating-System: Debian GNU/Linux 7.0
X-Kernel: Linux 3.2.0-4-686-pae i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] DNS in JSON (Was: DNSOP Meeting in Orlando/IETF86
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 16:00:40 -0000

On Tue, Feb 19, 2013 at 12:48:25AM +0000,
 Tony Finch  wrote 
 a message of 15 lines which said:

> about a formal mechanism for documenting the field names of DNS
> RDATA, ought to be answered by draft-levine-dnsextlang.

draft-levine-dnsextlang is not published yet and, more important, it
is not implemented. The rrtype.arpa and rrname.arpa zones have not
been created and therefore we do not have the DNS records describing
the existing RR types.

Also, the descriptions in draft-levine-dnsextlang are optional (if
they are missing, what name to use for the JSON members?)

Finally, the syntax for the descriptions in draft-levine-dnsextlang
will not always yield "friendly" JSON members (for instance because of
white space). So, we need at least to specify a derivation algorithm
(s/\s+/_/ ?)


From fanf2@hermes.cam.ac.uk  Wed Feb 27 08:09:32 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D5621F862B for ; Wed, 27 Feb 2013 08:09:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.329
X-Spam-Level: 
X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=-1.330, BAYES_00=-2.599, J_CHICKENPOX_64=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC1kTF5ReBZn for ; Wed, 27 Feb 2013 08:09:32 -0800 (PST)
Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id C01B121F8545 for ; Wed, 27 Feb 2013 08:09:31 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43887) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1UAjZS-000191-96 (Exim 4.80_167-5a66dd3) (return-path ); Wed, 27 Feb 2013 16:09:30 +0000
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UAjZS-0000m4-Q3 (Exim 4.72) (return-path ); Wed, 27 Feb 2013 16:09:30 +0000
Date: Wed, 27 Feb 2013 16:09:30 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Stephane Bortzmeyer 
In-Reply-To: <20130227155931.GA8931@nic.fr>
Message-ID: 
References: <20130207111446.GM1320@x28.adm.denic.de> <20130218100517.GA12211@nic.fr>  <20130227155931.GA8931@nic.fr>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] DNS in JSON (Was: DNSOP Meeting in Orlando/IETF86
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 16:09:33 -0000

Stephane Bortzmeyer  wrote:
> On Tue, Feb 19, 2013 at 12:48:25AM +0000,
>  Tony Finch  wrote
>  a message of 15 lines which said:
>
> > about a formal mechanism for documenting the field names of DNS
> > RDATA, ought to be answered by draft-levine-dnsextlang.

I should clarify that by "ought" I meant that the problem it is trying to
solve is extremely close to the problem that you have, and I think both
problems should have the same solution.

> draft-levine-dnsextlang is not published yet and, more important, it
> is not implemented. The rrtype.arpa and rrname.arpa zones have not
> been created and therefore we do not have the DNS records describing
> the existing RR types.
>
> Also, the descriptions in draft-levine-dnsextlang are optional (if
> they are missing, what name to use for the JSON members?)

Perhaps they should not be optional.

> Finally, the syntax for the descriptions in draft-levine-dnsextlang
> will not always yield "friendly" JSON members (for instance because of
> white space). So, we need at least to specify a derivation algorithm
> (s/\s+/_/ ?)

Better I think to adjust dnsextlang to be closer to the needs of
programming languages including JSON.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

From paul.hoffman@vpnc.org  Wed Feb 27 08:24:39 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559E121F8667 for ; Wed, 27 Feb 2013 08:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level: 
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmKJHm7MctRx for ; Wed, 27 Feb 2013 08:24:37 -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 3378721F8613 for ; Wed, 27 Feb 2013 08:24:37 -0800 (PST)
Received: from [192.168.1.111] (173-13-170-161-sfba.hfc.comcastbusiness.net [173.13.170.161]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1RGOYCr033179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Feb 2013 09:24:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman 
In-Reply-To: <20130227155931.GA8931@nic.fr>
Date: Wed, 27 Feb 2013 08:24:37 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130207111446.GM1320@x28.adm.denic.de> <20130218100517.GA12211@nic.fr>  <20130227155931.GA8931@nic.fr>
To: "dnsop@ietf.org WG" 
X-Mailer: Apple Mail (2.1499)
Subject: Re: [DNSOP] DNS in JSON (Was: DNSOP Meeting in Orlando/IETF86
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 16:24:39 -0000

On Feb 27, 2013, at 7:59 AM, Stephane Bortzmeyer  =
wrote:

> On Tue, Feb 19, 2013 at 12:48:25AM +0000,
> Tony Finch  wrote=20
> a message of 15 lines which said:
>=20
>> about a formal mechanism for documenting the field names of DNS
>> RDATA, ought to be answered by draft-levine-dnsextlang.
>=20
> draft-levine-dnsextlang is not published yet and, more important, it
> is not implemented. The rrtype.arpa and rrname.arpa zones have not
> been created and therefore we do not have the DNS records describing
> the existing RR types.

But, even more significantly, draft-levine-dnsextlang is for defining =
the structure of RDATA, not the entire value of an RR. A JSON format for =
RRs would have data that is not in RDATA, such as TTL. The two proposals =
are for very different things.

--Paul Hoffman=

From fanf2@hermes.cam.ac.uk  Wed Feb 27 08:27:57 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D01921F8751 for ; Wed, 27 Feb 2013 08:27:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.546
X-Spam-Level: 
X-Spam-Status: No, score=-5.546 tagged_above=-999 required=5 tests=[AWL=1.053,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73l4hM6+opky for ; Wed, 27 Feb 2013 08:27:57 -0800 (PST)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id D8F2421F8468 for ; Wed, 27 Feb 2013 08:27:56 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40616) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1UAjrH-0008Rq-ru (Exim 4.72) (return-path ); Wed, 27 Feb 2013 16:27:55 +0000
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UAjrH-0003YO-M4 (Exim 4.72) (return-path ); Wed, 27 Feb 2013 16:27:55 +0000
Date: Wed, 27 Feb 2013 16:27:55 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Paul Hoffman 
In-Reply-To: 
Message-ID: 
References: <20130207111446.GM1320@x28.adm.denic.de> <20130218100517.GA12211@nic.fr>  <20130227155931.GA8931@nic.fr> 
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Cc: "dnsop@ietf.org WG" 
Subject: Re: [DNSOP] DNS in JSON (Was: DNSOP Meeting in Orlando/IETF86
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 16:27:57 -0000

Paul Hoffman  wrote:
>
> But, even more significantly, draft-levine-dnsextlang is for defining
> the structure of RDATA, not the entire value of an RR. A JSON format for
> RRs would have data that is not in RDATA, such as TTL. The two proposals
> are for very different things.

But you can't describe the structure of an RR without describing its
RDATA. They aren't different things: one is a sub-part of the other.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

From paul.hoffman@vpnc.org  Wed Feb 27 08:50:03 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A0421F84F5 for ; Wed, 27 Feb 2013 08:50:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU6OMDysQegh for ; Wed, 27 Feb 2013 08:50:03 -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 B528721F84BB for ; Wed, 27 Feb 2013 08:50:02 -0800 (PST)
Received: from [192.168.1.111] (173-13-170-161-sfba.hfc.comcastbusiness.net [173.13.170.161]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1RGnUv7038062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2013 09:49:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman 
In-Reply-To: 
Date: Wed, 27 Feb 2013 08:49:28 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B4FEC0C-2B91-434B-81D8-1B44462840E8@vpnc.org>
References: <20130207111446.GM1320@x28.adm.denic.de> <20130218100517.GA12211@nic.fr>  <20130227155931.GA8931@nic.fr>  
To: Tony Finch 
X-Mailer: Apple Mail (2.1499)
Cc: "dnsop@ietf.org WG" 
Subject: Re: [DNSOP] DNS in JSON (Was: DNSOP Meeting in Orlando/IETF86
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 16:50:03 -0000

On Feb 27, 2013, at 8:27 AM, Tony Finch  wrote:

> Paul Hoffman  wrote:
>>=20
>> But, even more significantly, draft-levine-dnsextlang is for defining
>> the structure of RDATA, not the entire value of an RR. A JSON format =
for
>> RRs would have data that is not in RDATA, such as TTL. The two =
proposals
>> are for very different things.
>=20
> But you can't describe the structure of an RR without describing its
> RDATA. They aren't different things: one is a sub-part of the other.

Of course. For the RDATA part of a JSON structure, you can be very =
JSON-y, or very masterfile-y like draft-levine-dnsextlang has gone. I =
would prefer being JSON-y because the rest of the data we are talking =
about is already in that format, and we would not be reliant on anyone =
understanding the new proposed format from draft-levine-dnsextlang.

--Paul Hoffman=

From cet1@hermes.cam.ac.uk  Wed Feb 27 08:57:40 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CE221F877A for ; Wed, 27 Feb 2013 08:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.134
X-Spam-Level: 
X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNoUVfRlCLo9 for ; Wed, 27 Feb 2013 08:57:39 -0800 (PST)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFC221F87F6 for ; Wed, 27 Feb 2013 08:57:39 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51461) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1UAkK0-0004J5-rs (Exim 4.72) (return-path ); Wed, 27 Feb 2013 16:57:36 +0000
Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1UAkK0-0007l2-M0 (Exim 4.72) (return-path ); Wed, 27 Feb 2013 16:57:36 +0000
Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 27 Feb 2013 16:57:36 +0000
Date: 27 Feb 2013 16:57:36 +0000
From: Chris Thompson 
To: Tony Finch 
Message-ID: 
In-Reply-To: 
References:  
X-Mailer: Prayer v1.3.5
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Sender: Chris Thompson 
Cc: IETF DNSOP WG , Paul Vixie , "Dickson, Brian" , Peter Koch , George Michaelson , Erik Kline , Joe Abley 
Subject: Re: [DNSOP] Adoption of  as a WG work item?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cet1@cam.ac.uk
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 16:57:40 -0000

On Feb 26 2013, Tony Finch wrote:

>Dickson, Brian  wrote:
[...]
>> Instead of delegating to omniscient AS112 servers, what about doing a
>> DNAME to a specific target "foo" (replace "foo" with what you will) in the
>> DNS tree?
>
>Like this?
>
>We have had (afaik) one interop problem with this setup: there was a mail
>server on a network with DNAMEd reverse DNS, and some recipient sites
>objected to this.

Including in particular those for c*m*a*t.n*t, to whom we wrote in March 2011

| It appears that your servers fail to cope with this sort of result,
| and respond with an immediate
|
|   421 [hostname] comcast Reverse DNS failure : Try again later
|
| to an SMTP connection.
|
| What surprises us is that they do not behave like this if reverse
| lookup returns just a CNAME and a PTR record, in the style originally
| envisaged by RFC 2317. The extra DNAME seems to make the difference,
| but it ought to be ignored if not understood, and the "synthesised
| CNAME" acted on instead.

We never heard back from them, and we had to paper over the problem
by replacing the DNAME for 233.232.128.in-addr.arpa with 256 CNAMEs.

Still, this shouldn't be an issue if the intent is to generate
a negative answer to a reverse lookup. More to the current point
is that (unfortunately) few DNS registries support putting DNAMEs
in parent zones in place of delegations.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: cet1@ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

From paf@frobbit.se  Wed Feb 27 08:59:29 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4482421F8613 for ; Wed, 27 Feb 2013 08:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpYWeHVKviNR for ; Wed, 27 Feb 2013 08:59:28 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 7D70C21F84A4 for ; Wed, 27 Feb 2013 08:59:28 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::69cc:2fa1:394c:a3d8] (unknown [IPv6:2a02:80:3ffc:0:69cc:2fa1:394c:a3d8]) by mail.frobbit.se (Postfix) with ESMTPSA id 923E321BD3; Wed, 27 Feb 2013 17:59:27 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: <19F54F2956911544A32543B8A9BDE0750980645F@NICS-EXCH.sbg.nic.at>
Date: Wed, 27 Feb 2013 17:59:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <376A55F0-E636-400D-8A82-FCF9B42869B9@frobbit.se>
References: <19F54F2956911544A32543B8A9BDE0750980645F@NICS-EXCH.sbg.nic.at>
To: Alexander Mayrhofer 
X-Mailer: Apple Mail (2.1499)
Cc: "dnsop@ietf.org" 
Subject: Re: [DNSOP] DS without NS in a delegation?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 16:59:29 -0000

On 27 feb 2013, at 14:18, Alexander Mayrhofer =
 wrote:

> We've been discussing internally whether or not including DS records =
into a zone without respective NS record(s) makes any sense (assuming =
that there are no other RRSETs for the respective label in the zone =
itself - pure "delegation" scenario)... My personal assumption is that =
it does not, since the DS record can never be used to verify the =
information in the (unreachable) delegated zone?=20

It sort of does not make any sense, but I would be nervous if you set a =
policy that force the NS to exist before you publish DS. This because =
adding NS and adding DS are two different epp operations, and you would =
set a constraint on in what order such things could happen. And for =
example that removing NS would not be allowed if not DS is removed first =
(or DS implicitly be removed if NS is removed). That in turn would =
create race conditions in the case NS is changed completely because even =
for a fraction of a section a domain name that is registered might exist =
in the registry without any NS records, but with DS.

So, I this "makes no real sense" be one of acceptable things that domain =
name holders should be allowed to do if they want. And/or the registrar =
of course that have their internal algorithms regarding in what order =
various epp commands are made.

   paf


From cet1@hermes.cam.ac.uk  Wed Feb 27 09:13:50 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5434A21F8546 for ; Wed, 27 Feb 2013 09:13:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.289
X-Spam-Level: 
X-Spam-Status: No, score=-4.289 tagged_above=-999 required=5 tests=[AWL=-1.691, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOD3+FT8JMBZ for ; Wed, 27 Feb 2013 09:13:49 -0800 (PST)
Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD8221F853C for ; Wed, 27 Feb 2013 09:13:49 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:36147) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:cet1) id 1UAkZa-0003Gl-8m (Exim 4.80_167-5a66dd3) (return-path ); Wed, 27 Feb 2013 17:13:42 +0000
Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1UAkZa-0001b7-FN (Exim 4.72) (return-path ); Wed, 27 Feb 2013 17:13:42 +0000
Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 27 Feb 2013 17:13:42 +0000
Date: 27 Feb 2013 17:13:42 +0000
From: Chris Thompson 
To: IETF DNSOP WG 
Message-ID: 
In-Reply-To: 
References:  
X-Mailer: Prayer v1.3.5
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Sender: Chris Thompson 
Cc: Tony Finch 
Subject: Re: [DNSOP] Adoption of  as a WG work item?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cet1@cam.ac.uk
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 17:13:50 -0000

On Feb 26 2013, Tony Finch wrote:

[...]
>I just remembered another problem, that many unices have antediluvian stub
>resolvers that write to syslog when they see a DNAME record, e.g.
>
>gethostby*.getanswer: asked for "42.143.232.128.in-addr.arpa IN PTR", got type "39"
>
>Apart from logging, the code ignores the DNAME record and happily
>processes the synthesized CNAME record, so it is mostly a benign bug apart
>from the annoying noise in the logs. If AS112 were to use DNAME this is
>likely to become a tiresome FAQ.

Or it might speed up the phasing out of these old glibc versions,
which would be a boon to all of us deploying DNAMEs in reverse lookup
contexts.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: cet1@ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

From fanf2@hermes.cam.ac.uk  Wed Feb 27 09:18:35 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C05F21F84A2 for ; Wed, 27 Feb 2013 09:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.608
X-Spam-Level: 
X-Spam-Status: No, score=-5.608 tagged_above=-999 required=5 tests=[AWL=0.991,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8PQouNcUKXp for ; Wed, 27 Feb 2013 09:18:34 -0800 (PST)
Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0593E21F84A8 for ; Wed, 27 Feb 2013 09:18:34 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39923) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1UAkeG-0007iv-RC (Exim 4.72) (return-path ); Wed, 27 Feb 2013 17:18:32 +0000
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UAkeG-0002Ir-D6 (Exim 4.72) (return-path ); Wed, 27 Feb 2013 17:18:32 +0000
Date: Wed, 27 Feb 2013 17:18:32 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Paul Hoffman 
In-Reply-To: <1B4FEC0C-2B91-434B-81D8-1B44462840E8@vpnc.org>
Message-ID: 
References: <20130207111446.GM1320@x28.adm.denic.de> <20130218100517.GA12211@nic.fr>  <20130227155931.GA8931@nic.fr>   <1B4FEC0C-2B91-434B-81D8-1B44462840E8@vpnc.org>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Cc: "dnsop@ietf.org WG" 
Subject: Re: [DNSOP] DNS in JSON (Was: DNSOP Meeting in Orlando/IETF86
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 17:18:35 -0000

Paul Hoffman  wrote:
>
> Of course. For the RDATA part of a JSON structure, you can be very
> JSON-y, or very masterfile-y like draft-levine-dnsextlang has gone. I
> would prefer being JSON-y because the rest of the data we are talking
> about is already in that format, and we would not be reliant on anyone
> understanding the new proposed format from draft-levine-dnsextlang.

I don't see draft-levine-dnsextlang as being particularly masterfile-y.
What it gives you is a sequence of type + name pairs. These can be used to
serialize to/from wire format or presentation format. They should be
equally useful for serializing to/from JSON. Or to/from a web form for
user-friendly editing.

(Several RR types are too complicated so will need special handling; but
you can just view this as extending the set of RDATA field types that the
description language knows about.)

A key advantage to having machine-readable RDATA descriptions is that they
should be general-purpose so you don't have to keep reinventing the wheel
each time you want a new representation: you can re-use the mapping
between RR types and seqences of fields, and just add a new mapping
between fields and your new representation.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

From johnl@iecc.com  Wed Feb 27 09:54:27 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD89721F8833 for ; Wed, 27 Feb 2013 09:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.046
X-Spam-Level: 
X-Spam-Status: No, score=-111.046 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgrPPvIvncnr for ; Wed, 27 Feb 2013 09:54:26 -0800 (PST)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 30F5B21F8630 for ; Wed, 27 Feb 2013 09:54:23 -0800 (PST)
Received: (qmail 54371 invoked from network); 27 Feb 2013 17:54:23 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Feb 2013 17:54:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=512e484f.xn--9vv.k1302; i=johnl@user.iecc.com; bh=ITvSo7CrMWwkItKPgl6V0khVDb79Bz8NAKhJOrS3VhQ=; b=JuAj6FdN2pLav90M1h7EeodTjlGvd9ub7J7dWfOgiRmPFG4vNsWPWciY0QbZuQvYY6BJHOnPx89R3LXHrUsge0FQicUUi+52/X720CDnxwFVqiW/YLaVRybcaUEGdzGphYKo237CfY9wK33UJUNJ6Xcq2OD5Gu82njkUgTJFEm0=
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=512e484f.xn--9vv.k1302; olt=johnl@user.iecc.com; bh=ITvSo7CrMWwkItKPgl6V0khVDb79Bz8NAKhJOrS3VhQ=; b=A1KNFrT9rkJb9ON/Q7Dat+zfg5sbLykD8HQblNeMR7Pr4RVQJS7kKc34AMRJiYA/BsGHdBvi1Xf1N8GMnCqDxhP2fXgFcgPcb5C6Xjn23bwhjcOMkqkKg/yizyZZjRyxOnfTfmEGzukIHVi66zu9qQUOG5GMxKPIlGIq8PnJXE0=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 27 Feb 2013 17:54:01 -0000
Message-ID: <20130227175401.31689.qmail@joyce.lan>
From: "John Levine" 
To: dnsop@ietf.org
In-Reply-To: 
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: dot@dotat.at
Subject: Re: [DNSOP] DNS in JSON (Was: DNSOP Meeting in Orlando/IETF86
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 17:54:28 -0000

>> Finally, the syntax for the descriptions in draft-levine-dnsextlang
>> will not always yield "friendly" JSON members (for instance because of
>> white space). So, we need at least to specify a derivation algorithm
>> (s/\s+/_/ ?)
>
>Better I think to adjust dnsextlang to be closer to the needs of
>programming languages including JSON.

It's a draft.  I'd be delighted to change it to make it more useful to
people.

R's,
John

From ed.lewis@neustar.biz  Wed Feb 27 17:35:14 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5107621F8461 for ; Wed, 27 Feb 2013 17:35:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.151
X-Spam-Level: 
X-Spam-Status: No, score=-101.151 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi3jiSPESviz for ; Wed, 27 Feb 2013 17:35:13 -0800 (PST)
Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net [68.230.241.218]) by ietfa.amsl.com (Postfix) with ESMTP id 548BC21F8A38 for ; Wed, 27 Feb 2013 17:23:01 -0800 (PST)
Received: from eastrmimpo209 ([68.230.241.224]) by eastrmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130228012205.FKXR21186.eastrmfepo203.cox.net@eastrmimpo209> for ; Wed, 27 Feb 2013 20:22:05 -0500
Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo209 with cox id 5dN21l00D3cuADQ01dN2kD; Wed, 27 Feb 2013 20:22:05 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020205.512EB13D.005A,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=aIYuX8Bm c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=0MXgu1D-icwA:10 a=hGBaWAWWAAAA:8 a=eTUXI9l3KO8A:10 a=IwJLMM-DenzLj9Bpz68A:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=hAvH61bkIBh3HPGR:21 a=oexVYqFSw12-DHsL:21 a=oA89zpRWXlEUEuS9i1sA:9 a=_W_S_7VecoQA:10 a=Lu1KU8ME9tF28246:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_EFD8DA48-E21A-44A8-B7EB-AB4742E013E5"
From: Edward Lewis 
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747492240@mbx-01.win.nominum.com>
Date: Thu, 28 Feb 2013 09:22:02 +0800
Message-Id: <2D5DB73B-6459-4062-8C79-6586614BC0FA@neustar.biz>
References: <10229F86C86EB444898E629583FD417161653510@PACDCEXMB06.cable.comcast.com> <8D23D4052ABE7A4490E77B1A012B630747492240@mbx-01.win.nominum.com>
To: "dnsop@ietf.org WG" 
X-Mailer: Apple Mail (2.1283)
Cc: Jason Livingood , Edward Lewis , Ted Lemon 
Subject: Re: [DNSOP] Posted draft-livingood-negative-trust-anchors-03
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 01:35:14 -0000

--Apple-Mail=_EFD8DA48-E21A-44A8-B7EB-AB4742E013E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Feb 17, 2013, at 23:19, Ted Lemon wrote:

> What's local?

DNSSEC set out to step cache poisoning.  Look at it from the cache's =
point of view.

Local means "whatever the owner/operator of the cache" controls.  =46rom =
the time we began to develop validation, decision points were all =
covered by "local policy rules."

DNSSEC is popularly known by it's supply side activity - how many zones =
are signed, etc.  But that's a red herring when it comes to what DNSSEC =
is all about.

So, local is what the operator of the cache (caching server[s]) wants it =
to be.

> How does the local authority know to set a negative trust anchor?  =
This seems very labor-intensive and failure-prone.

There is already a commercial market trading on the reputation of domain =
names.  There are various of commercial sources that will recommend =
disrupting traffic to and from sources of, say, spam.  This is in =
addition to the labor intensive process of investigating everything =
"yourself."

The first step that is needed is to be able to have name servers turn =
off DNSSEC validation per domain name (=3Dzone at times) and then back =
on.

The next step is to figure out when should DNSSEC be turned off and on.

The next step is to make this scaleable in some reasonable sense.

I don't know "much" about this, in the sense I haven't been paying close =
attention.  But I have been surprised to find that there's more progress =
on the first step that I'd have thought.  I also know there's quite a =
bit of maturity in the latter two steps.  But just not (the maturity =
that is) in publicly available documents.

Again, because I haven't actually read the trust-anchors document(*), I =
can't honestly register support for it but it's probably (or I hope is) =
a first step into making what's already in play commercially appear in a =
publicly available document.  (To date I'm just catching up on the mail =
list thread.)

(*) - =46rom a conversation a decade ago, I've learned it's best to be =
completely honest about whether you've actually read a document =
thoroughly when responding to a question from Ted. ;)

Ok, so to be honest I might have read the draft in an earlier form, I =
certainly don't recall if I did.

=
-=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            =20
NeuStar                    You can leave a voice message at =
+1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.


--Apple-Mail=_EFD8DA48-E21A-44A8-B7EB-AB4742E013E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


What's =
local?

DNSSEC set out to step =
cache poisoning.  Look at it from the cache's point of =
view.

Local means "whatever the owner/operator =
of the cache" controls.  =46rom the time we began to develop =
validation, decision points were all covered by "local policy =
rules."

DNSSEC is popularly known by it's =
supply side activity - how many zones are signed, etc.  But that's =
a red herring when it comes to what DNSSEC is all =
about.

So, local is what the operator of the =
cache (caching server[s]) wants it to be.

 How does the local authority know to set a negative =
trust anchor?  This seems very labor-intensive and =
failure-prone.

There is already a =
commercial market trading on the reputation of domain names.  There =
are various of commercial sources that will recommend disrupting traffic =
to and from sources of, say, spam.  This is in addition to the =
labor intensive process of investigating everything =
"yourself."

The first step that is needed is to =
be able to have name servers turn off DNSSEC validation per domain name =
(=3Dzone at times) and then back on.

The next =
step is to figure out when should DNSSEC be turned off and =
on.

The next step is to make this scaleable in =
some reasonable sense.

I don't know "much" =
about this, in the sense I haven't been paying close attention. =
 But I have been surprised to find that there's more progress on =
the first step that I'd have thought.  I also know there's quite a =
bit of maturity in the latter two steps.  But just not (the =
maturity that is) in publicly available =
documents.

Again, because I haven't actually =
read the trust-anchors document(*), I can't honestly register support =
for it but it's probably (or I hope is) a first step into making what's =
already in play commercially appear in a publicly available document. =
 (To date I'm just catching up on the mail list =
thread.)

(*) - =46rom a conversation a decade =
ago, I've learned it's best to be completely honest about whether you've =
actually read a document thoroughly when responding to a question from =
Ted. ;)

Ok, so to be honest I might have read =
the draft in an earlier form, I certainly don't recall if I =
did.



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

There are no answers - just tradeoffs, decisions, =
and responses.




=

--Apple-Mail=_EFD8DA48-E21A-44A8-B7EB-AB4742E013E5--

From ed.lewis@neustar.biz  Wed Feb 27 17:35:19 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E5621F8771 for ; Wed, 27 Feb 2013 17:35:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.012
X-Spam-Level: 
X-Spam-Status: No, score=-101.012 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72NESaN7lNfg for ; Wed, 27 Feb 2013 17:35:18 -0800 (PST)
Received: from eastrmfepo103.cox.net (eastrmfepo103.cox.net [68.230.241.215]) by ietfa.amsl.com (Postfix) with ESMTP id 81C6221F84D9 for ; Wed, 27 Feb 2013 17:27:53 -0800 (PST)
Received: from eastrmimpo209 ([68.230.241.224]) by eastrmfepo103.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130228012722.KCCA23841.eastrmfepo103.cox.net@eastrmimpo209> for ; Wed, 27 Feb 2013 20:27:22 -0500
Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo209 with cox id 5dTJ1l00U3cuADQ01dTKTf; Wed, 27 Feb 2013 20:27:21 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020208.512EB27A.0003,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=aIYuX8Bm c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=6ZeQdt_PKGEA:10 a=hGBaWAWWAAAA:8 a=iUZu4aIZSiQA:10 a=48vgC7mUAAAA:8 a=os6bg4KTVYXJ61ynz1EA:9 a=wPNLvfGTeEIA:10 a=9k6G2--EmesA:10 a=lZB815dzVvQA:10 a=_W_S_7VecoQA:10 a=uSlumYuAb2QgzcQV:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F1FAFFD4-B28A-4003-A813-2BB5CE8D37C5"
From: Edward Lewis 
In-Reply-To: <376A55F0-E636-400D-8A82-FCF9B42869B9@frobbit.se>
Date: Thu, 28 Feb 2013 09:27:18 +0800
Message-Id: <5BE3A61E-8529-4F16-A3E0-07647B410662@neustar.biz>
References: <19F54F2956911544A32543B8A9BDE0750980645F@NICS-EXCH.sbg.nic.at> <376A55F0-E636-400D-8A82-FCF9B42869B9@frobbit.se>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Alexander Mayrhofer 
X-Mailer: Apple Mail (2.1283)
Cc: "dnsop@ietf.org WG" , Edward Lewis 
Subject: Re: [DNSOP] DS without NS in a delegation?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 01:35:19 -0000

--Apple-Mail=_F1FAFFD4-B28A-4003-A813-2BB5CE8D37C5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

I don't know if there's a smoking gun "MUST NOT" but we did discuss a =
NS-less DS.  Unreliably I'd say it would be a protocol-level error to =
have.

But I did find this, which in as much as an RFC is ever a spec, infers =
that NS-less DS's aren't to be seen.  =46rom RFC 4035:
3.1.4.1.  Responding to Queries for DS RRs

   The DS resource record type is unusual in that it appears only on the
   parent zone's side of a zone cut.

On Feb 28, 2013, at 0:59, Patrik F=E4ltstr=F6m wrote:

>=20
> On 27 feb 2013, at 14:18, Alexander Mayrhofer =
 wrote:
>=20
>> We've been discussing internally whether or not including DS records =
into a zone without respective NS record(s) makes any sense (assuming =
that there are no other RRSETs for the respective label in the zone =
itself - pure "delegation" scenario)... My personal assumption is that =
it does not, since the DS record can never be used to verify the =
information in the (unreachable) delegated zone?=20
>=20
> It sort of does not make any sense, but I would be nervous if you set =
a policy that force the NS to exist before you publish DS. This because =
adding NS and adding DS are two different epp operations, and you would =
set a constraint on in what order such things could happen. And for =
example that removing NS would not be allowed if not DS is removed first =
(or DS implicitly be removed if NS is removed). That in turn would =
create race conditions in the case NS is changed completely because even =
for a fraction of a section a domain name that is registered might exist =
in the registry without any NS records, but with DS.
>=20
> So, I this "makes no real sense" be one of acceptable things that =
domain name holders should be allowed to do if they want. And/or the =
registrar of course that have their internal algorithms regarding in =
what order various epp commands are made.
>=20
>   paf
>=20
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

=
-=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            =20
NeuStar                    You can leave a voice message at =
+1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.


--Apple-Mail=_F1FAFFD4-B28A-4003-A813-2BB5CE8D37C5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1



But I did find =
this, which in as much as an RFC is ever a spec, infers that NS-less =
DS's aren't to be seen.  From RFC 4035:
3.1.4.1.  Responding to Queries for DS RRs

   The DS resource record type is unusual in that it appears only on the
   parent zone's side of a zone =
cut.

On Feb 28, 2013, at 0:59, =
Patrik F=E4ltstr=F6m wrote:


On =
27 feb 2013, at 14:18, Alexander Mayrhofer <alexander.mayrhofer@nic.at&=
gt; wrote:

We've been discussing =
internally whether or not including DS records into a zone without =
respective NS record(s) makes any sense (assuming that there are no =
other RRSETs for the respective label in the zone itself - pure =
"delegation" scenario)... My personal assumption is that it does not, =
since the DS record can never be used to verify the information in the =
(unreachable) delegated zone? 

It sort of does not =
make any sense, but I would be nervous if you set a policy that force =
the NS to exist before you publish DS. This because adding NS and adding =
DS are two different epp operations, and you would set a constraint on =
in what order such things could happen. And for example that removing NS =
would not be allowed if not DS is removed first (or DS implicitly be =
removed if NS is removed). That in turn would create race conditions in =
the case NS is changed completely because even for a fraction of a =
section a domain name that is registered might exist in the registry =
without any NS records, but with DS.

So, I this "makes no real =
sense" be one of acceptable things that domain name holders should be =
allowed to do if they want. And/or the registrar of course that have =
their internal algorithms regarding in what order various epp commands =
are made.

 =
  paf

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


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

There are no answers - just tradeoffs, decisions, =
and responses.




=

--Apple-Mail=_F1FAFFD4-B28A-4003-A813-2BB5CE8D37C5--

From paf@frobbit.se  Wed Feb 27 22:17:10 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8E221F8B4A for ; Wed, 27 Feb 2013 22:17:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co1UMNxe+sCa for ; Wed, 27 Feb 2013 22:17:09 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id F1E9021F8B47 for ; Wed, 27 Feb 2013 22:17:08 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::69cc:2fa1:394c:a3d8] (unknown [IPv6:2a02:80:3ffc:0:69cc:2fa1:394c:a3d8]) by mail.frobbit.se (Postfix) with ESMTPSA id 0FF2D21370; Thu, 28 Feb 2013 07:17:08 +0100 (CET)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A90DD4B0-0730-4816-90C3-46C86B929DC4"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: <5BE3A61E-8529-4F16-A3E0-07647B410662@neustar.biz>
Date: Thu, 28 Feb 2013 07:16:53 +0100
Message-Id: 
References: <19F54F2956911544A32543B8A9BDE0750980645F@NICS-EXCH.sbg.nic.at> <376A55F0-E636-400D-8A82-FCF9B42869B9@frobbit.se> <5BE3A61E-8529-4F16-A3E0-07647B410662@neustar.biz>
To: Edward Lewis 
X-Mailer: Apple Mail (2.1499)
Cc: Alexander Mayrhofer , "dnsop@ietf.org WG" 
Subject: Re: [DNSOP] DS without NS in a delegation?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 06:17:10 -0000

--Apple-Mail=_A90DD4B0-0730-4816-90C3-46C86B929DC4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Ok, let me phrase my statement differently then.

IF people do not want DS in the parent zone of a zone cut, then the =
registry should not publish the DS they have for domain names they do =
not have NS.

My only point was to not use this as an argument to make the epp =
transactions even more complicated and "stateful".

   Patrik

On 28 feb 2013, at 02:27, Edward Lewis  wrote:

> I don't know if there's a smoking gun "MUST NOT" but we did discuss a =
NS-less DS.  Unreliably I'd say it would be a protocol-level error to =
have.
>=20
> But I did find this, which in as much as an RFC is ever a spec, infers =
that NS-less DS's aren't to be seen.  =46rom RFC 4035:
> 3.1.4.1.  Responding to Queries for DS RRs
>=20
>    The DS resource record type is unusual in that it appears only on =
the
>    parent zone's side of a zone cut.
>=20
> On Feb 28, 2013, at 0:59, Patrik F=E4ltstr=F6m wrote:
>=20
>>=20
>> On 27 feb 2013, at 14:18, Alexander Mayrhofer =
 wrote:
>>=20
>>> We've been discussing internally whether or not including DS records =
into a zone without respective NS record(s) makes any sense (assuming =
that there are no other RRSETs for the respective label in the zone =
itself - pure "delegation" scenario)... My personal assumption is that =
it does not, since the DS record can never be used to verify the =
information in the (unreachable) delegated zone?=20
>>=20
>> It sort of does not make any sense, but I would be nervous if you set =
a policy that force the NS to exist before you publish DS. This because =
adding NS and adding DS are two different epp operations, and you would =
set a constraint on in what order such things could happen. And for =
example that removing NS would not be allowed if not DS is removed first =
(or DS implicitly be removed if NS is removed). That in turn would =
create race conditions in the case NS is changed completely because even =
for a fraction of a section a domain name that is registered might exist =
in the registry without any NS records, but with DS.
>>=20
>> So, I this "makes no real sense" be one of acceptable things that =
domain name holders should be allowed to do if they want. And/or the =
registrar of course that have their internal algorithms regarding in =
what order various epp commands are made.
>>=20
>>   paf
>>=20
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>=20
> =
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
> Edward Lewis            =20
> NeuStar                    You can leave a voice message at =
+1-571-434-5468
>=20
> There are no answers - just tradeoffs, decisions, and responses.
>=20


--Apple-Mail=_A90DD4B0-0730-4816-90C3-46C86B929DC4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Ok, =
let me phrase my statement differently then.

IF =
people do not want DS in the parent zone of a zone cut, then the =
registry should not publish the DS they have for domain names they do =
not have NS.

My only point was to not use this =
as an argument to make the epp transactions even more complicated and =
"stateful".

  =
 Patrik

On 28 feb 2013, at 02:27, Edward =
Lewis <ed.lewis@neustar.biz> =
wrote:

I don't know if =
there's a smoking gun "MUST NOT" but we did discuss a NS-less DS. =
 Unreliably I'd say it would be a protocol-level error to =
have.

But I did find this, which in as much as =
an RFC is ever a spec, infers that NS-less DS's aren't to be seen. =
 From RFC 4035:
3.1.4.1.  Responding to =
Queries for DS RRs

   The DS resource record type is unusual in that it appears only on the
   parent zone's side of a zone =
cut.

On Feb 28, 2013, at 0:59, =
Patrik F=E4ltstr=F6m wrote:


On 27 =
feb 2013, at 14:18, Alexander Mayrhofer <alexander.mayrhofer@nic.at&=
gt; wrote:

We've been discussing =
internally whether or not including DS records into a zone without =
respective NS record(s) makes any sense (assuming that there are no =
other RRSETs for the respective label in the zone itself - pure =
"delegation" scenario)... My personal assumption is that it does not, =
since the DS record can never be used to verify the information in the =
(unreachable) delegated zone? 

It sort of does not =
make any sense, but I would be nervous if you set a policy that force =
the NS to exist before you publish DS. This because adding NS and adding =
DS are two different epp operations, and you would set a constraint on =
in what order such things could happen. And for example that removing NS =
would not be allowed if not DS is removed first (or DS implicitly be =
removed if NS is removed). That in turn would create race conditions in =
the case NS is changed completely because even for a fraction of a =
section a domain name that is registered might exist in the registry =
without any NS records, but with DS.

So, I this "makes no real =
sense" be one of acceptable things that domain name holders should be =
allowed to do if they want. And/or the registrar of course that have =
their internal algorithms regarding in what order various epp commands =
are made.

 =
  paf

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


=
-=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-

In-Reply-To: <512CCEB4.3040403@ogud.com>
Date: Thu, 28 Feb 2013 14:56:25 +0800
Message-Id: <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz>
References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net>  <512BDC8B.3070602@ogud.com>  <512CCEB4.3040403@ogud.com>
To: "dnsop@ietf.org WG" 
X-Mailer: Apple Mail (2.1283)
Cc: Edward Lewis 
Subject: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 06:56:32 -0000

--Apple-Mail=_CB031696-47D3-487F-B678-3040AF00CC06
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Having quickly read the -01 for Automating DNSSEC delegation trust =
maintenance:

I'd like to propose a twist.  Comparing to X.509, a CDS record is kinda =
sorta like a key signing request.  For that reason I want to see an =
explicit "request" in the RDATA and not have anything implied.

I would suggest that the RDATA of it *not* be the same as the DS record. =
 There should be an explicit RDATA element instructing the parent what =
to do with the request.  Probably some other ancillary data will be =
needed too.

I would not specify how the parent "discovers" the CDS.  Just as for =
AXFR, knowing how AXFR works is different from why it is called.  I say =
this because in some scenarios I can see the parent scanning the =
children and in others there will be an event driven reason to look for =
the CDS set at a child.  In some cases "scraping" is optimal, in some =
cases "explicit" is optimal.

The CDS has to do this:

1. Let the parent know whether it is a request for new DS records or =
whether this is a request to delete DS records.  (Plural referring to =
the fact that a SEP might have more than one DS record.)

2. Let the parent know when this request was first posted (so that the =
parent can tell if it did this one before).  I.e., a 32 bit timestamp =
viewed as a yyymm-etc. like the RRSIGs do.  Or it could be the serial =
number of the zone when the request was added (although that might be =
hard for a tool to determine).  But - goal is - something to let the =
parent know when this request appeared so that the parent can guess =
whether it has already responded to it.

3. Let the parent know the RDATA of the DS records that are desired.

What #3 hints at is the case where DS records are requested for a DNSKEY =
that is not (yet) published in the child zone.  There is a DS record in =
the root zone for a ccTLD that points to no existing record - an example =
that this is done.

I'd like to see one CDS per DNSKEY state change.  It is up to the child =
to groom the CDS set, that is, once the parent has granted the request =
(which can be seen by asking the parent) the child has the onus to =
remove the CDS - but as protocol designers we have to account for the =
case where a child does not remove a CDS (ever), and might in fact have =
a CDS to add a key and another to delete the key.

Other considerations.  I left off "urgent" or "due time" because those =
features generally are overkill.  For urgent matters, that falls under =
the "why" category  and not the "how" category.  And "how" is what we =
need to define.

For example, a zone has KSKs with footprints/ids of 11111 and 22222 and =
is flipping to the latter:

zone.tld.   1800  IN  CDS   DELETE 20130201000000 11111 7 1 =
DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2 =
4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 1 =
DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2 =
4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7

The hash in the DELETE is over kill.  Perhaps for that just the =
footprint is needed (unless you want to delete one or the other hash =
only).

Here's a meltdown case that I want to smooth over (with hashes elided):

zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 ...
zone.tld.   1800  IN  CDS   DELETE 20130301000000 22222 ...

In this case, the child forgot to remove the add request when it decided =
to do the delete.  (No intention of allowing the timestamp to be a =
schedule - even though I show a future date in the example, I did that =
just for convenience.)  The parent should know then to delete what it =
has for 22222, whether or not it ever added the DS.  (E.g., if the two =
records popped up together with the same timestamp.)

PS - looking at the email addresses for the authors: so it is true, =
Warren and George are the same person!


--Apple-Mail=_CB031696-47D3-487F-B678-3040AF00CC06
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Having quickly read the -01 =
for Automating DNSSEC delegation trust =
maintenance:

I'd like to propose a twist. =
 Comparing to X.509, a CDS record is kinda sorta like a key signing =
request.  For that reason I want to see an explicit "request" in =
the RDATA and not have anything implied.

I =
would suggest that the RDATA of it *not* be the same as the DS record. =
 There should be an explicit RDATA element instructing the parent =
what to do with the request.  Probably some other ancillary data =
will be needed too.

I would not specify how the =
parent "discovers" the CDS.  Just as for AXFR, knowing how AXFR =
works is different from why it is called.  I say this because in =
some scenarios I can see the parent scanning the children and in others =
there will be an event driven reason to look for the CDS set at a child. =
 In some cases "scraping" is optimal, in some cases "explicit" is =
optimal.

The CDS has to do =
this:

1. Let the parent know whether it is a =
request for new DS records or whether this is a request to delete DS =
records.  (Plural referring to the fact that a SEP might have more =
than one DS record.)

2. Let the parent know =
when this request was first posted (so that the parent can tell if it =
did this one before).  I.e., a 32 bit timestamp viewed as a =
yyymm-etc. like the RRSIGs do.  Or it could be the serial number of =
the zone when the request was added (although that might be hard for a =
tool to determine).  But - goal is - something to let the parent =
know when this request appeared so that the parent can guess whether it =
has already responded to it.

3. Let the parent =
know the RDATA of the DS records that are =
desired.

What #3 hints at is the case where DS =
records are requested for a DNSKEY that is not (yet) published in the =
child zone.  There is a DS record in the root zone for a ccTLD that =
points to no existing record - an example that this is =
done.

I'd like to see one CDS per DNSKEY state =
change.  It is up to the child to groom the CDS set, that is, once =
the parent has granted the request (which can be seen by asking the =
parent) the child has the onus to remove the CDS - but as protocol =
designers we have to account for the case where a child does not remove =
a CDS (ever), and might in fact have a CDS to add a key and another to =
delete the key.

Other considerations.  I =
left off "urgent" or "due time" because those features generally are =
overkill.  For urgent matters, that falls under the "why" category =
 and not the "how" category.  And "how" is what we need to =
define.

For example, a zone has KSKs with =
footprints/ids of 11111 and 22222 and is flipping to the =
latter:

zone.tld.   1800  IN  CDS   DELETE =
20130201000000 11111 7 1 DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 =
2 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
zone.tld.   1800  IN  CDS   ADD =
20130201000000 22222 7 1 DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 =
2 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7

The hash in the DELETE is over =
kill.  Perhaps for that just the footprint is needed (unless you =
want to delete one or the other hash =
only).

Here's a meltdown case that I want to =
smooth over (with hashes =
elided):

zone.tld.   1800 =
 IN  CDS   ADD 20130201000000 22222 7 =
...
zone.tld.   1800 =
 IN  CDS   DELETE 20130301000000 22222 =
...

In this case, the child =
forgot to remove the add request when it decided to do the delete. =
 (No intention of allowing the timestamp to be a schedule - even =
though I show a future date in the example, I did that just for =
convenience.)  The parent should know then to delete what it has =
for 22222, whether or not it ever added the DS.  (E.g., if the two =
records popped up together with the same =
timestamp.)

PS - looking at the email addresses =
for the authors: so it is true, Warren and George are the same =
person!

=

--Apple-Mail=_CB031696-47D3-487F-B678-3040AF00CC06--

From ed.lewis@neustar.biz  Wed Feb 27 23:03:46 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51D521F8B47 for ; Wed, 27 Feb 2013 23:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.032
X-Spam-Level: 
X-Spam-Status: No, score=-101.032 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEpnxHL9dcWL for ; Wed, 27 Feb 2013 23:03:40 -0800 (PST)
Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net [68.230.241.218]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC4421F8B07 for ; Wed, 27 Feb 2013 23:03:40 -0800 (PST)
Received: from eastrmimpo305 ([68.230.241.237]) by eastrmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130228070339.ZWTU21186.eastrmfepo203.cox.net@eastrmimpo305> for ; Thu, 28 Feb 2013 02:03:39 -0500
Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo305 with cox id 5j3c1l00A3cuADQ01j3dbD; Thu, 28 Feb 2013 02:03:39 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020201.512F014B.00A5,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=IelZrxWa c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=6ZeQdt_PKGEA:10 a=hGBaWAWWAAAA:8 a=iUZu4aIZSiQA:10 a=3wnY-gf1iuX_Qccu31QA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=jLS77cK3vc0_HVO-:21 a=PqAhYN1egkR7Bo4v:21 a=I20D6wHoAAAA:8 a=WCYG6s8XVWnh5GpVGCAA:9 a=_W_S_7VecoQA:10 a=m-SBBFYz7VBJmfEV:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DB0778CC-0187-4994-9F2A-8F24D2B73BA4"
From: Edward Lewis 
In-Reply-To: 
Date: Thu, 28 Feb 2013 15:03:35 +0800
Message-Id: <0B1A6F4F-8B7D-42EA-A956-7D8A790D24BF@neustar.biz>
References: <19F54F2956911544A32543B8A9BDE0750980645F@NICS-EXCH.sbg.nic.at> 
To: "dnsop@ietf.org WG" 
X-Mailer: Apple Mail (2.1283)
Cc: Alexander Mayrhofer , Roy Arends , Edward Lewis 
Subject: Re: [DNSOP] DS without NS in a delegation?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 07:03:47 -0000

--Apple-Mail=_DB0778CC-0187-4994-9F2A-8F24D2B73BA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Feb 27, 2013, at 21:50, Roy Arends wrote:


> When a parent and child zone are served from the same server set, like =
co.uk and uk, you could have _in_theory_ DS records without NS records =
in the parent zone. A resolver would never observe the delegation point =
NS record. A validating resolver would need to explicitly ask for the DS =
record. If the DS record is present, the DS plus signatures will be =
returned. However, absence of the DS record is problematic, as there is =
no NSEC(3) record indicating presence of NS, absence of SOA+DS.=20

Roy, that idea bothers me.

It's true, if all of the name servers for the parent are all of the name =
servers for a child, the NS set is not necessary.  But claiming then you =
could have DS records means the same name would have to own DNSKEY =
records (for the DS to reference) and then an SOA to allow the owner to =
appear in the RRSIG's signer name field.  Sure you don't need the NS, =
but you need everything else that makes a zone cut.  But wait, there's =
more.  The NSEC/NSEC3 record really ought to indicate that there's a =
delegation there and for that the NS bit has to be turned on - so =
there's a need for an NS.

> I think you'd need to implement these specifics though, as current =
authoritative servers and signers might throw an error when observing a =
DS without NS, but I haven't checked.

Without specifically saying what error would be thrown (and when, on =
zone load?), current servers should have issues with a name owning a DS =
and no NS.

=
-=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            =20
NeuStar                    You can leave a voice message at =
+1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.


--Apple-Mail=_DB0778CC-0187-4994-9F2A-8F24D2B73BA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


When a parent and child zone are served from the same =
server set, like co.uk and uk, you could =
have _in_theory_ DS records without NS records in the parent zone. A =
resolver would never observe the delegation point NS record. A =
validating resolver would need to explicitly ask for the DS record. If =
the DS record is present, the DS plus signatures will be returned. =
However, absence of the DS record is problematic, as there is no NSEC(3) =
record indicating presence of NS, absence of SOA+DS. =


Roy, that idea bothers =
me.

It's true, if all of the name servers for =
the parent are all of the name servers for a child, the NS set is not =
necessary.  But claiming then you could have DS records means the =
same name would have to own DNSKEY records (for the DS to reference) and =
then an SOA to allow the owner to appear in the RRSIG's signer name =
field.  Sure you don't need the NS, but you need everything else =
that makes a zone cut.  But wait, there's more.  The =
NSEC/NSEC3 record really ought to indicate that there's a delegation =
there and for that the NS bit has to be turned on - so there's a need =
for an NS.

I =
think you'd need to implement these specifics though, as current =
authoritative servers and signers might throw an error when observing a =
DS without NS, but I haven't =
checked.

Without specifically =
saying what error would be thrown (and when, on zone load?), current =
servers should have issues with a name owning a DS and no =
NS.



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

There are no answers - just tradeoffs, decisions, =
and responses.




=

--Apple-Mail=_DB0778CC-0187-4994-9F2A-8F24D2B73BA4--

From marc.lampo.ietf@gmail.com  Wed Feb 27 23:23:06 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA02221F8AF2 for ; Wed, 27 Feb 2013 23:23:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrIm8nyikN8s for ; Wed, 27 Feb 2013 23:23:06 -0800 (PST)
Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id C913721F8ACE for ; Wed, 27 Feb 2013 23:23:05 -0800 (PST)
Received: by mail-ve0-f182.google.com with SMTP id ox1so1473706veb.41 for ; Wed, 27 Feb 2013 23:23:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pS6QPL3nYr5kv6pRFw0XmG/zqdNbxrtr2+XnrBR6YzU=; b=YqNuzs5B+ibhmx7YOxtVwuDWJI5QJ8UjiR41J5B+s4uqtPWa325HfwyFU5bsIvZw6d 8uPr160jZoc/34j8PqWA72eL7sSmS/Y9ETY5x4HXdxL7KowrKDmaj7HhbhHHv88MpjMT ldfY9APcDHZPnZxdtaL/9hc0q0MzWkIV+NlyiGGDOiTxPanxPpGezK6ZIjWqVaaKQOap 2NzSuBXmUB6FLDFMOuGV92c2gAXVuEQcrCxfCtVbrbY+VUDWhFQaWC3wqeFple5fXoYA A+a2x/TH6B9TC5z2fwJCQ+bLfUxhBUQwXfb4iaL3JgPbnYMLZZvj4lwb9+yl5/ColN5n 3pxA==
MIME-Version: 1.0
X-Received: by 10.220.40.9 with SMTP id i9mr2122780vce.23.1362036185314; Wed, 27 Feb 2013 23:23:05 -0800 (PST)
Received: by 10.58.163.100 with HTTP; Wed, 27 Feb 2013 23:23:05 -0800 (PST)
In-Reply-To: <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz>
References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net>  <512BDC8B.3070602@ogud.com>  <512CCEB4.3040403@ogud.com> <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz>
Date: Thu, 28 Feb 2013 08:23:05 +0100
Message-ID: 
From: Marc Lampo 
To: Edward Lewis 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "dnsop@ietf.org WG" 
Subject: Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 07:23:07 -0000

Hello,

somewhat more words but in line with what I was suggesting, a couple
of days ago,
about adding "operation code" to CDS RDATA.

This still feel like a good idea, worth elaborating, I'd see.
I support this.

Kind regards,

Marc Lampo


On Thu, Feb 28, 2013 at 7:56 AM, Edward Lewis  wrote:
> Having quickly read the -01 for Automating DNSSEC delegation trust
> maintenance:
>
> I'd like to propose a twist.  Comparing to X.509, a CDS record is kinda
> sorta like a key signing request.  For that reason I want to see an explicit
> "request" in the RDATA and not have anything implied.
>
> I would suggest that the RDATA of it *not* be the same as the DS record.
> There should be an explicit RDATA element instructing the parent what to do
> with the request.  Probably some other ancillary data will be needed too.
>
> I would not specify how the parent "discovers" the CDS.  Just as for AXFR,
> knowing how AXFR works is different from why it is called.  I say this
> because in some scenarios I can see the parent scanning the children and in
> others there will be an event driven reason to look for the CDS set at a
> child.  In some cases "scraping" is optimal, in some cases "explicit" is
> optimal.
>
> The CDS has to do this:
>
> 1. Let the parent know whether it is a request for new DS records or whether
> this is a request to delete DS records.  (Plural referring to the fact that
> a SEP might have more than one DS record.)
>
> 2. Let the parent know when this request was first posted (so that the
> parent can tell if it did this one before).  I.e., a 32 bit timestamp viewed
> as a yyymm-etc. like the RRSIGs do.  Or it could be the serial number of the
> zone when the request was added (although that might be hard for a tool to
> determine).  But - goal is - something to let the parent know when this
> request appeared so that the parent can guess whether it has already
> responded to it.
>
> 3. Let the parent know the RDATA of the DS records that are desired.
>
> What #3 hints at is the case where DS records are requested for a DNSKEY
> that is not (yet) published in the child zone.  There is a DS record in the
> root zone for a ccTLD that points to no existing record - an example that
> this is done.
>
> I'd like to see one CDS per DNSKEY state change.  It is up to the child to
> groom the CDS set, that is, once the parent has granted the request (which
> can be seen by asking the parent) the child has the onus to remove the CDS -
> but as protocol designers we have to account for the case where a child does
> not remove a CDS (ever), and might in fact have a CDS to add a key and
> another to delete the key.
>
> Other considerations.  I left off "urgent" or "due time" because those
> features generally are overkill.  For urgent matters, that falls under the
> "why" category  and not the "how" category.  And "how" is what we need to
> define.
>
> For example, a zone has KSKs with footprints/ids of 11111 and 22222 and is
> flipping to the latter:
>
> zone.tld.   1800  IN  CDS   DELETE 20130201000000 11111 7 1
> DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2
> 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
> zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 1
> DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2
> 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
>
> The hash in the DELETE is over kill.  Perhaps for that just the footprint is
> needed (unless you want to delete one or the other hash only).
>
> Here's a meltdown case that I want to smooth over (with hashes elided):
>
> zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 ...
> zone.tld.   1800  IN  CDS   DELETE 20130301000000 22222 ...
>
> In this case, the child forgot to remove the add request when it decided to
> do the delete.  (No intention of allowing the timestamp to be a schedule -
> even though I show a future date in the example, I did that just for
> convenience.)  The parent should know then to delete what it has for 22222,
> whether or not it ever added the DS.  (E.g., if the two records popped up
> together with the same timestamp.)
>
> PS - looking at the email addresses for the authors: so it is true, Warren
> and George are the same person!
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

From ed.lewis@neustar.biz  Thu Feb 28 00:11:22 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBBE21F8BA6 for ; Thu, 28 Feb 2013 00:11:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.283
X-Spam-Level: 
X-Spam-Status: No, score=-100.283 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, TRACKER_ID=2.003, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DefjJwqXJwNA for ; Thu, 28 Feb 2013 00:11:21 -0800 (PST)
Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net [68.230.241.218]) by ietfa.amsl.com (Postfix) with ESMTP id 69E9D21F8BA4 for ; Thu, 28 Feb 2013 00:11:08 -0800 (PST)
Received: from eastrmimpo305 ([68.230.241.237]) by eastrmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130228081107.EVNV21186.eastrmfepo203.cox.net@eastrmimpo305> for ; Thu, 28 Feb 2013 03:11:07 -0500
Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo305 with cox id 5kB41l0033cuADQ01kB4Ad; Thu, 28 Feb 2013 03:11:07 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020209.512F111B.00DF,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=IelZrxWa c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=27vuUybe-asA:10 a=hGBaWAWWAAAA:8 a=3D5Z4wfiauwA:10 a=48vgC7mUAAAA:8 a=8J2YExhBDe3U8LfEMcsA:9 a=wPNLvfGTeEIA:10 a=9k6G2--EmesA:10 a=lZB815dzVvQA:10 a=o5yLqAGLZ62R13-s:21 a=O3VQ5AZ1xsGssdBG:21 a=ddR1uikaDK-VElcf72oA:9 a=_W_S_7VecoQA:10 a=63RCkiJRISP8e4fW:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1CD4422C-ADC1-4845-8D90-BF3B3A1921BA"
From: Edward Lewis 
In-Reply-To: 
Date: Thu, 28 Feb 2013 16:11:02 +0800
Message-Id: 
References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net>  <512BDC8B.3070602@ogud.com>  <512CCEB4.3040403@ogud.com> <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz> 
To: Marc Lampo , "dnsop@ietf.org WG" 
X-Mailer: Apple Mail (2.1283)
Cc: Edward Lewis 
Subject: Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 08:11:22 -0000

--Apple-Mail=_1CD4422C-ADC1-4845-8D90-BF3B3A1921BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Ahh, yes.  I went back to see your message.

I'll address the points in your message here

1)  Telling the parent "this is a new KSK and it will have a DS in the =
future" (code 0) is unnecessary.  This is state the parent should not =
track and not have the burden of tracking.  The other two states map to =
my "ADD" and "DELETE" but in mine I hide semantics (or reasons why).  So =
for the most part we agree.

2) All that is needed is the CDS be signed as any other RRSET.  When the =
parent elects to do so, it would do a query +DO to get the records and =
hope to see "ad" in the flags.

3) I don't think the parent ought to have to do a periodic check (it's =
up to the parent).  Either way, that doesn't belong in the document.

4) Good question - I would assume that a well-run zone would have =
in-sync servers.  Given that the document assumes the parent could =
"scrape" this, the concern is understood.  But my assumption is that =
this would be event driven (prompt up the tree somehow) and that lessens =
the concern of an out of sync server.  OTOH, I have the idea that there =
needs to be some way of tagging the request to get it's freshness. OYTOH =
(On yet the third hand), there's always out of band ways to ask for a =
retry.

5) Kind of agree - why not.  If the domain name is registered via a =
method that has a half-dozen pre-delegation checks and credit checks, =
what more armoring is needed?

6) Ahh, and I thought I was the only one that noticed.  (Sorry, Marc, =
evidently I hadn't read all of your message. ;))

What I have in mind is a smaller definition for CDS, but use it in a way =
where the client has the responsibility to check whether the parent has =
granted the request.


On Feb 28, 2013, at 15:23, Marc Lampo wrote:

> Hello,
>=20
> somewhat more words but in line with what I was suggesting, a couple
> of days ago,
> about adding "operation code" to CDS RDATA.
>=20
> This still feel like a good idea, worth elaborating, I'd see.
> I support this.
>=20
> Kind regards,
>=20
> Marc Lampo
>=20
>=20
> On Thu, Feb 28, 2013 at 7:56 AM, Edward Lewis  =
wrote:
>> Having quickly read the -01 for Automating DNSSEC delegation trust
>> maintenance:
>>=20
>> I'd like to propose a twist.  Comparing to X.509, a CDS record is =
kinda
>> sorta like a key signing request.  For that reason I want to see an =
explicit
>> "request" in the RDATA and not have anything implied.
>>=20
>> I would suggest that the RDATA of it *not* be the same as the DS =
record.
>> There should be an explicit RDATA element instructing the parent what =
to do
>> with the request.  Probably some other ancillary data will be needed =
too.
>>=20
>> I would not specify how the parent "discovers" the CDS.  Just as for =
AXFR,
>> knowing how AXFR works is different from why it is called.  I say =
this
>> because in some scenarios I can see the parent scanning the children =
and in
>> others there will be an event driven reason to look for the CDS set =
at a
>> child.  In some cases "scraping" is optimal, in some cases "explicit" =
is
>> optimal.
>>=20
>> The CDS has to do this:
>>=20
>> 1. Let the parent know whether it is a request for new DS records or =
whether
>> this is a request to delete DS records.  (Plural referring to the =
fact that
>> a SEP might have more than one DS record.)
>>=20
>> 2. Let the parent know when this request was first posted (so that =
the
>> parent can tell if it did this one before).  I.e., a 32 bit timestamp =
viewed
>> as a yyymm-etc. like the RRSIGs do.  Or it could be the serial number =
of the
>> zone when the request was added (although that might be hard for a =
tool to
>> determine).  But - goal is - something to let the parent know when =
this
>> request appeared so that the parent can guess whether it has already
>> responded to it.
>>=20
>> 3. Let the parent know the RDATA of the DS records that are desired.
>>=20
>> What #3 hints at is the case where DS records are requested for a =
DNSKEY
>> that is not (yet) published in the child zone.  There is a DS record =
in the
>> root zone for a ccTLD that points to no existing record - an example =
that
>> this is done.
>>=20
>> I'd like to see one CDS per DNSKEY state change.  It is up to the =
child to
>> groom the CDS set, that is, once the parent has granted the request =
(which
>> can be seen by asking the parent) the child has the onus to remove =
the CDS -
>> but as protocol designers we have to account for the case where a =
child does
>> not remove a CDS (ever), and might in fact have a CDS to add a key =
and
>> another to delete the key.
>>=20
>> Other considerations.  I left off "urgent" or "due time" because =
those
>> features generally are overkill.  For urgent matters, that falls =
under the
>> "why" category  and not the "how" category.  And "how" is what we =
need to
>> define.
>>=20
>> For example, a zone has KSKs with footprints/ids of 11111 and 22222 =
and is
>> flipping to the latter:
>>=20
>> zone.tld.   1800  IN  CDS   DELETE 20130201000000 11111 7 1
>> DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2
>> 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
>> zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 1
>> DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2
>> 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
>>=20
>> The hash in the DELETE is over kill.  Perhaps for that just the =
footprint is
>> needed (unless you want to delete one or the other hash only).
>>=20
>> Here's a meltdown case that I want to smooth over (with hashes =
elided):
>>=20
>> zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 ...
>> zone.tld.   1800  IN  CDS   DELETE 20130301000000 22222 ...
>>=20
>> In this case, the child forgot to remove the add request when it =
decided to
>> do the delete.  (No intention of allowing the timestamp to be a =
schedule -
>> even though I show a future date in the example, I did that just for
>> convenience.)  The parent should know then to delete what it has for =
22222,
>> whether or not it ever added the DS.  (E.g., if the two records =
popped up
>> together with the same timestamp.)
>>=20
>> PS - looking at the email addresses for the authors: so it is true, =
Warren
>> and George are the same person!
>>=20
>>=20
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>=20

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

There are no answers - just tradeoffs, decisions, and responses.


--Apple-Mail=_1CD4422C-ADC1-4845-8D90-BF3B3A1921BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1



2) All that is needed =
is the CDS be signed as any other RRSET.  When the parent elects to =
do so, it would do a query +DO to get the records and hope to see "ad" =
in the flags.

3) I don't think the parent ought =
to have to do a periodic check (it's up to the parent).  Either =
way, that doesn't belong in the document.

4) =
Good question - I would assume that a well-run zone would have in-sync =
servers.  Given that the document assumes the parent could "scrape" =
this, the concern is understood.  But my assumption is that this =
would be event driven (prompt up the tree somehow) and that lessens the =
concern of an out of sync server.  OTOH, I have the idea that there =
needs to be some way of tagging the request to get it's freshness. OYTOH =
(On yet the third hand), there's always out of band ways to ask for a =
retry.

5) Kind of agree - why not.  If the =
domain name is registered via a method that has a half-dozen =
pre-delegation checks and credit checks, what more armoring is =
needed?

6) Ahh, and I thought I was the only =
one that noticed.  (Sorry, Marc, evidently I hadn't read all of =
your message. ;))

What I have in mind is a =
smaller definition for CDS, but use it in a way where the client has the =
responsibility to check whether the parent has granted the =
request.


On Feb 28, 2013, at 15:23, =
Marc Lampo wrote:

Hello,

somewhat more words but in line with =
what I was suggesting, a couple
of days ago,
about adding =
"operation code" to CDS RDATA.

This still feel like a good idea, =
worth elaborating, I'd see.
I support this.

Kind =
regards,

Marc Lampo


On Thu, Feb 28, 2013 at 7:56 AM, =
Edward Lewis <ed.lewis@neustar.biz> =
wrote:
Having quickly read the -01 for =
Automating DNSSEC delegation trust
maintenance:

I'd like to =
propose a twist.  Comparing to X.509, a CDS record is =
kinda
sorta like a key signing =
request.  For that reason I want to see an =
explicit
"request" in the =
RDATA and not have anything implied.

I would suggest =
that the RDATA of it *not* be the same as the DS =
record.
There should be an =
explicit RDATA element instructing the parent what to =
do
with the request. =
 Probably some other ancillary data will be needed =
too.

I would not =
specify how the parent "discovers" the CDS.  Just as for =
AXFR,
knowing how AXFR works =
is different from why it is called.  I say =
this
because in some scenarios =
I can see the parent scanning the children and =
in
others there will be an =
event driven reason to look for the CDS set at =
a
child.  In some cases =
"scraping" is optimal, in some cases "explicit" =
is
optimal.

The CDS has to =
do this:

1. Let the =
parent know whether it is a request for new DS records or =
whether
this is a request to =
delete DS records.  (Plural referring to the fact =
that
a SEP might have more =
than one DS record.)

2. Let the =
parent know when this request was first posted (so that =
the
parent can tell if it did =
this one before).  I.e., a 32 bit timestamp =
viewed
as a yyymm-etc. like =
the RRSIGs do.  Or it could be the serial number of =
the
zone when the request was =
added (although that might be hard for a tool =
to
determine).  But - =
goal is - something to let the parent know when =
this
request appeared so that =
the parent can guess whether it has already
responded to it.

3. Let the =
parent know the RDATA of the DS records that are =
desired.

What #3 hints =
at is the case where DS records are requested for a =
DNSKEY
that is not (yet) =
published in the child zone.  There is a DS record in =
the
root zone for a ccTLD that =
points to no existing record - an example =
that
this is =
done.

I'd like to see =
one CDS per DNSKEY state change.  It is up to the child =
to
groom the CDS set, that is, =
once the parent has granted the request =
(which
can be seen by asking =
the parent) the child has the onus to remove the CDS =
-
but as protocol designers we =
have to account for the case where a child =
does
not remove a CDS (ever), =
and might in fact have a CDS to add a key =
and
another to delete the =
key.

Other =
considerations.  I left off "urgent" or "due time" because =
those
features generally are =
overkill.  For urgent matters, that falls under =
the
"why" category  and =
not the "how" category.  And "how" is what we need =
to
define.

For example, a =
zone has KSKs with footprints/ids of 11111 and 22222 and =
is
flipping to the =
latter:

zone.tld. =
  1800  IN  CDS   DELETE 20130201000000 =
11111 7 1
DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 =
2
4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011=
E0A7
zone.tld. =
  1800  IN  CDS   ADD 20130201000000 22222 =
7 1
DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 =
2
4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011=
E0A7

The hash in the =
DELETE is over kill.  Perhaps for that just the footprint =
is
needed (unless you want to =
delete one or the other hash only).

Here's a =
meltdown case that I want to smooth over (with hashes =
elided):

zone.tld. =
  1800  IN  CDS   ADD 20130201000000 22222 =
7 ...
zone.tld. =
  1800  IN  CDS   DELETE 20130301000000 =
22222 ...

In this case, =
the child forgot to remove the add request when it decided =
to
do the delete.  (No =
intention of allowing the timestamp to be a schedule =
-
even though I show a future =
date in the example, I did that just for
convenience.)  The parent should know then to delete =
what it has for 22222,
whether =
or not it ever added the DS.  (E.g., if the two records popped =
up
together with the same =
timestamp.)

PS - looking at =
the email addresses for the authors: so it is true, =
Warren
and George are the same =
person!


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




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

There are no answers - just tradeoffs, decisions, =
and responses.




=

--Apple-Mail=_1CD4422C-ADC1-4845-8D90-BF3B3A1921BA--

From roy@dnss.ec  Thu Feb 28 01:44:23 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8CC21F8B7D for ; Thu, 28 Feb 2013 01:44:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.671
X-Spam-Level: 
X-Spam-Status: No, score=0.671 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, J_CHICKENPOX_32=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEiSmv9YUQSU for ; Thu, 28 Feb 2013 01:44:17 -0800 (PST)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id F3E6321F8B33 for ; Thu, 28 Feb 2013 01:44:16 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id d7so1308345wer.36 for ; Thu, 28 Feb 2013 01:44:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=5kD+a5BcWEzJBku5ET2hqq45Hbp3782Xldod8DpjB5s=; b=NdNPl0LaFJ3xMNKo3f4KPFXL4YS5R86wZOEUF2wRO/Y5ztcMiXQywgjs7WpGasbdu9 Xw182gElu+IxRI17KzXQTPQcdqz6fbKc+No0yging6dl8FaU2RU+he0pgiWnACkLtBVY qV9r9BsMNR/u/cZVc2vjF7mhPDMtMzTfwV4SI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=5kD+a5BcWEzJBku5ET2hqq45Hbp3782Xldod8DpjB5s=; b=jNGAcMRp1GF3rX83IrcvwS26dM2bCEp0GlUq0XKD0WzAikUq1wZeO7Jqj0lIPRJknK C+FKY7lKCRuRFAucNn8HZuL5Ijux42VJjinLA8Vu7ShiME1CJ5IIedINCVhnxmwdj/bM mvWzdLn55mPkguwbNJ7rtOauFWu/7AN5xvodhdowJrAjkqYNJ6KsZ9ui9cJHbouMHZnp fF9Y2faA5xLf77UVD8YRC4qLfk0JxWty7yPJ3SLz0n+eYUwXdcKWquFq3wTTvrmVtJdi uadTlIe7jK98JEXSlGfjucIuaOUBhvrJgnNTglaqD+M4mODonYWMeYyzjIP/N/AvefcA oPYA==
X-Received: by 10.194.11.70 with SMTP id o6mr9546280wjb.39.1362044655980; Thu, 28 Feb 2013 01:44:15 -0800 (PST)
Received: from [213.248.192.76] ([213.248.192.76]) by mx.google.com with ESMTPS id gy2sm14157790wib.3.2013.02.28.01.44.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 01:44:15 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=us-ascii
From: Roy Arends 
In-Reply-To: <0B1A6F4F-8B7D-42EA-A956-7D8A790D24BF@neustar.biz>
Date: Thu, 28 Feb 2013 09:44:13 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <19F54F2956911544A32543B8A9BDE0750980645F@NICS-EXCH.sbg.nic.at>  <0B1A6F4F-8B7D-42EA-A956-7D8A790D24BF@neustar.biz>
To: Edward Lewis 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQk9JU0s40FXVhNUfoQcK0uA/k66w5BEG0rUFKUJLRU0UsmHgnI3bVhHgqj62+8zegSGDmwT
Cc: Alexander Mayrhofer , "dnsop@ietf.org WG" 
Subject: Re: [DNSOP] DS without NS in a delegation?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 09:44:23 -0000

On Feb 28, 2013, at 7:03 AM, Edward Lewis  wrote:

> On Feb 27, 2013, at 21:50, Roy Arends wrote:
>=20
>=20
>> When a parent and child zone are served from the same server set, =
like co.uk and uk, you could have _in_theory_ DS records without NS =
records in the parent zone. A resolver would never observe the =
delegation point NS record. A validating resolver would need to =
explicitly ask for the DS record. If the DS record is present, the DS =
plus signatures will be returned. However, absence of the DS record is =
problematic, as there is no NSEC(3) record indicating presence of NS, =
absence of SOA+DS.=20
>=20
> Roy, that idea bothers me.
>=20
> It's true, if all of the name servers for the parent are all of the =
name servers for a child, the NS set is not necessary.  But claiming =
then you could have DS records means the same name would have to own =
DNSKEY records (for the DS to reference) and then an SOA to allow the =
owner to appear in the RRSIG's signer name field.

The DS record, in the parent zone, refers to the DNSKEY in the child =
zone. The RRSIG over the DS record contains a signer name of the DNSKEY =
of the parent. Both SOA's at child and parent do exist.

>  Sure you don't need the NS, but you need everything else that makes a =
zone cut.  But wait, there's more.  The NSEC/NSEC3 record really ought =
to indicate that there's a delegation there and for that the NS bit has =
to be turned on - so there's a need for an NS.

When parent and child are served from the same set, what does a resolver =
need to ask in order to see the parent side NSEC/NSEC3 record that =
proves presence or absence of the NS. IMHO, it won't be able to form a =
request so that the authoritative server would return the NSEC[3] that =
shows that there really was a zone cut (that is, served from the parent =
zone).

>=20
>> I think you'd need to implement these specifics though, as current =
authoritative servers and signers might throw an error when observing a =
DS without NS, but I haven't checked.
>=20
> Without specifically saying what error would be thrown (and when, on =
zone load?), current servers should have issues with a name owning a DS =
and no NS.

I think we're in complete agreement. Mixing a gun, a bullet and a foot =
in an unintended way will have unintended consequences, many of them not =
really desirable :-)

Roy=

From fanf2@hermes.cam.ac.uk  Thu Feb 28 03:43:37 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933AE21F8B14 for ; Thu, 28 Feb 2013 03:43:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.663
X-Spam-Level: 
X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=0.936,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFfdu+0QgC+N for ; Thu, 28 Feb 2013 03:43:36 -0800 (PST)
Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 99F5521F8B0A for ; Thu, 28 Feb 2013 03:43:36 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35279) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1UB1tf-00079U-QQ (Exim 4.72) (return-path ); Thu, 28 Feb 2013 11:43:35 +0000
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UB1tf-0001jF-56 (Exim 4.72) (return-path ); Thu, 28 Feb 2013 11:43:35 +0000
Date: Thu, 28 Feb 2013 11:43:35 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Edward Lewis 
In-Reply-To: <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz>
Message-ID: 
References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net>  <512BDC8B.3070602@ogud.com>  <512CCEB4.3040403@ogud.com> <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Cc: "dnsop@ietf.org WG" 
Subject: Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 11:43:37 -0000

Edward Lewis  wrote:
>
> Let the parent know when this request was first posted (so that the
> parent can tell if it did this one before).

The update logic ought to be idempotent, i.e. the instructions from the
child should be of the form "make it look like this" not "perform this
action". Then the parent needs no state other than the CDS RRset and the
DS RRset.

It might be desirable to be able to say "like this before such-and-such a
time, and like that afterwards". So maybe CDS RRs need inception and
expiry dates?

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

From paul@cypherpunks.ca  Thu Feb 28 05:49:19 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E151721F87F6 for ; Thu, 28 Feb 2013 05:49:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.792
X-Spam-Level: 
X-Spam-Status: No, score=-0.792 tagged_above=-999 required=5 tests=[AWL=0.257,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+5iAWsTuSv8 for ; Thu, 28 Feb 2013 05:49:19 -0800 (PST)
Received: from mx.nohats.ca (unknown [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 42E4621F87EA for ; Thu, 28 Feb 2013 05:49:17 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZGw9061vWz7r; Thu, 28 Feb 2013 08:49:08 -0500 (EST)
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1n9fV2z0JKX0; Thu, 28 Feb 2013 08:49:07 -0500 (EST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 28 Feb 2013 08:49:07 -0500 (EST)
Received: by bofh.nohats.ca (Postfix, from userid 500) id B3D91805B1; Thu, 28 Feb 2013 08:49:03 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A82B0805AD; Thu, 28 Feb 2013 08:49:03 -0500 (EST)
Date: Thu, 28 Feb 2013 08:49:03 -0500 (EST)
From: Paul Wouters 
X-X-Sender: paul@bofh.nohats.ca
To: Tony Finch 
In-Reply-To: 
Message-ID: 
References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net>  <512BDC8B.3070602@ogud.com>  <512CCEB4.3040403@ogud.com> <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz> 
User-Agent: Alpine 2.03 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: "dnsop@ietf.org WG" , Edward Lewis 
Subject: Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 13:49:20 -0000

On Thu, 28 Feb 2013, Tony Finch wrote:

> It might be desirable to be able to say "like this before such-and-such a
> time, and like that afterwards". So maybe CDS RRs need inception and
> expiry dates?

But that seems to be local policy of the parent. Not something the child
should have any say over?

Paul

From fanf2@hermes.cam.ac.uk  Thu Feb 28 06:26:54 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843AB21F853C for ; Thu, 28 Feb 2013 06:26:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.712
X-Spam-Level: 
X-Spam-Status: No, score=-3.712 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMN+4-wQGvxH for ; Thu, 28 Feb 2013 06:26:47 -0800 (PST)
Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id E8F3021F84D9 for ; Thu, 28 Feb 2013 06:26:46 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:50619) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1UB4RW-0001y2-9Q (Exim 4.80_167-5a66dd3) (return-path ); Thu, 28 Feb 2013 14:26:42 +0000
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UB4RW-0007xc-So (Exim 4.72) (return-path ); Thu, 28 Feb 2013 14:26:42 +0000
Date: Thu, 28 Feb 2013 14:26:42 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Paul Wouters 
In-Reply-To: 
Message-ID: 
References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net>  <512BDC8B.3070602@ogud.com>  <512CCEB4.3040403@ogud.com> <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz>  
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Cc: "dnsop@ietf.org WG" , Edward Lewis 
Subject: Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 14:26:54 -0000

Paul Wouters  wrote:
> On Thu, 28 Feb 2013, Tony Finch wrote:
>
> > It might be desirable to be able to say "like this before such-and-such a
> > time, and like that afterwards". So maybe CDS RRs need inception and
> > expiry dates?
>
> But that seems to be local policy of the parent. Not something the child
> should have any say over?

You are probably right.

The ideal is for the admin to trigger a key rollover and the rest happens
automatically. The scheduling idea (above) is sort of based on exposing
BIND's key timing parameters (dnssec-settime) so that the parent can
follow along. But this requires quite a lot of faith that the parent will
actually follow along as requested, so it probably isn't robust enough.

So whatever is co-ordinating the key rollover at the child needs to
monitor the parent to see when the DS RRset changes so that the rest of
the schedule can be adjusted accordingly. And if you are doing that, you
might as well alter the CDS RRset like you do with the DNSKEY RRset, and
wait for the parent to notice and act on the change.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

From paul@cypherpunks.ca  Thu Feb 28 10:29:25 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5176A21F8855 for ; Thu, 28 Feb 2013 10:29:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level: 
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[AWL=0.128,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y9K3Alm-ltN for ; Thu, 28 Feb 2013 10:29:24 -0800 (PST)
Received: from mx.nohats.ca (unknown [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id EDE4021F8853 for ; Thu, 28 Feb 2013 10:29:23 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZH2NF56J3z8k; Thu, 28 Feb 2013 13:29:17 -0500 (EST)
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KkCAhhrfwpkU; Thu, 28 Feb 2013 13:29:16 -0500 (EST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 28 Feb 2013 13:29:16 -0500 (EST)
Received: by bofh.nohats.ca (Postfix, from userid 500) id C25BD805B1; Thu, 28 Feb 2013 13:29:16 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B94A8805AE; Thu, 28 Feb 2013 13:29:16 -0500 (EST)
Date: Thu, 28 Feb 2013 13:29:16 -0500 (EST)
From: Paul Wouters 
X-X-Sender: paul@bofh.nohats.ca
To: Tony Finch 
In-Reply-To: 
Message-ID: 
References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net>  <512BDC8B.3070602@ogud.com>  <512CCEB4.3040403@ogud.com> <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz>   
User-Agent: Alpine 2.03 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "dnsop@ietf.org WG" , Edward Lewis 
Subject: Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 18:29:25 -0000

On Thu, 28 Feb 2013, Tony Finch wrote:

>> But that seems to be local policy of the parent. Not something the child
>> should have any say over?
>
> You are probably right.
>
> The ideal is for the admin to trigger a key rollover and the rest happens
> automatically. The scheduling idea (above) is sort of based on exposing
> BIND's key timing parameters (dnssec-settime) so that the parent can
> follow along. But this requires quite a lot of faith that the parent will
> actually follow along as requested, so it probably isn't robust enough.
>
> So whatever is co-ordinating the key rollover at the child needs to
> monitor the parent to see when the DS RRset changes so that the rest of
> the schedule can be adjusted accordingly. And if you are doing that, you
> might as well alter the CDS RRset like you do with the DNSKEY RRset, and
> wait for the parent to notice and act on the change.

I'm just trying to avoid another round of "Triggers vs Timers" :)

Paul

From ogud@ogud.com  Thu Feb 28 15:02:32 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55AB21F863C for ; Thu, 28 Feb 2013 15:02:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZj6vHl741vd for ; Thu, 28 Feb 2013 15:02:31 -0800 (PST)
Received: from smtp93.ord1c.emailsrvr.com (smtp93.ord1c.emailsrvr.com [108.166.43.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBF521F859A for ; Thu, 28 Feb 2013 15:02:31 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id E2D8D14008F; Thu, 28 Feb 2013 18:02:30 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id A2AB1140083;  Thu, 28 Feb 2013 18:02:30 -0500 (EST)
Message-ID: <512FE202.20505@ogud.com>
Date: Thu, 28 Feb 2013 18:02:26 -0500
From: Olafur Gudmundsson 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Edward Lewis 
References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net>  <512BDC8B.3070602@ogud.com>  <512CCEB4.3040403@ogud.com> <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz>
In-Reply-To: <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "dnsop@ietf.org WG" 
Subject: Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 23:02:32 -0000

Ed,

Thank you for your review from the "parent perspective".

CDS is designed to be as simple as possible to operate for both parents 
and child.
CDS is designed around the "Replace" operation, you and Marc are
proposing to change that to Add/Delete operations.

In the draft a Parental Agent can simply sort and compare
	the RDATA of CD to the RDATA of CDS
if there is a difference it can either
	- figure out the diff and translate that to ADD/DELETE actions
	- or simply say "Delete  DS *; Add  DS ...."

Yes I can envision a tool that looks a the "proposed DS" in a file at
child compares to current DS and creates "CDS action records"
as you propose and then takes these actions out after the parent
reflects the update.

It think this discussion broils where does the complexity lives and if
the different choices make life significantly simpler for one party or
the other.

I'm not sure that the ADD/DELETE model is simpler for the parent as in
both cases the Parental Agent needs to check some "back end" as when it
last performed an action for the Child and or if the action is redundant.

Thus before we go into discussion into details of record formats, lets
have the REPLACE vs ADD/DELETE discussion.

	Olafur

On 28/02/2013 01:56, Edward Lewis wrote:
> Having quickly read the -01 for Automating DNSSEC delegation trust
> maintenance:
>
> I'd like to propose a twist.  Comparing to X.509, a CDS record is
> kinda sorta like a key signing request.  For that reason I want to
> see an explicit "request" in the RDATA and not have anything
> implied.
>
> I would suggest that the RDATA of it *not* be the same as the DS
> record. There should be an explicit RDATA element instructing the
> parent what to do with the request.  Probably some other ancillary
> data will be needed too.
>
> I would not specify how the parent "discovers" the CDS.  Just as for
>  AXFR, knowing how AXFR works is different from why it is called.  I
>  say this because in some scenarios I can see the parent scanning the
>  children and in others there will be an event driven reason to look
>  for the CDS set at a child.  In some cases "scraping" is optimal, in
>  some cases "explicit" is optimal.
>
> The CDS has to do this:
>
> 1. Let the parent know whether it is a request for new DS records or
>  whether this is a request to delete DS records.  (Plural referring
> to the fact that a SEP might have more than one DS record.)
>
> 2. Let the parent know when this request was first posted (so that
> the parent can tell if it did this one before).  I.e., a 32 bit
> timestamp viewed as a yyymm-etc. like the RRSIGs do.  Or it could be
>  the serial number of the zone when the request was added (although
> that might be hard for a tool to determine).  But - goal is -
> something to let the parent know when this request appeared so that
> the parent can guess whether it has already responded to it.
>
> 3. Let the parent know the RDATA of the DS records that are desired.
>
> What #3 hints at is the case where DS records are requested for a
> DNSKEY that is not (yet) published in the child zone.  There is a DS
>  record in the root zone for a ccTLD that points to no existing
> record - an example that this is done.
>
> I'd like to see one CDS per DNSKEY state change.  It is up to the
> child to groom the CDS set, that is, once the parent has granted the
>  request (which can be seen by asking the parent) the child has the
> onus to remove the CDS - but as protocol designers we have to account
> for the case where a child does not remove a CDS (ever), and might in
> fact have a CDS to add a key and another to delete the key.
>
> Other considerations.  I left off "urgent" or "due time" because
> those features generally are overkill.  For urgent matters, that
> falls under the "why" category  and not the "how" category.  And
> "how" is what we need to define.
>
> For example, a zone has KSKs with footprints/ids of 11111 and 22222
> and is flipping to the latter:
>
> zone.tld.   1800  IN  CDS   DELETE 20130201000000 11111 7 1
> DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2
> 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
> zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 1
> DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2
> 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
>
> The hash in the DELETE is over kill.  Perhaps for that just the
> footprint is needed (unless you want to delete one or the other hash
>  only).
>
> Here's a meltdown case that I want to smooth over (with hashes
> elided):
>
> zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 ... zone.tld.
>  1800  IN  CDS   DELETE 20130301000000 22222 ...
>
> In this case, the child forgot to remove the add request when it
> decided to do the delete.  (No intention of allowing the timestamp to
> be a schedule - even though I show a future date in the example, I
> did that just for convenience.)  The parent should know then to
> delete what it has for 22222, whether or not it ever added the DS.
> (E.g., if the two records popped up together with the same
> timestamp.)
>
> PS - looking at the email addresses for the authors: so it is true,
> Warren and George are the same person!
>


From ed.lewis@neustar.biz  Thu Feb 28 17:37:08 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B43221F8700 for ; Thu, 28 Feb 2013 17:37:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.176
X-Spam-Level: 
X-Spam-Status: No, score=-101.176 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ug2bFR3vJTz for ; Thu, 28 Feb 2013 17:37:07 -0800 (PST)
Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by ietfa.amsl.com (Postfix) with ESMTP id 63BA721F86FB for ; Thu, 28 Feb 2013 17:37:07 -0800 (PST)
Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130301013706.XZJF17456.eastrmfepo201.cox.net@eastrmimpo210> for ; Thu, 28 Feb 2013 20:37:06 -0500
Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id 61d31l00o3cuADQ011d4Nd; Thu, 28 Feb 2013 20:37:06 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020203.51300642.00DB,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=NvcPhbhJ c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=27vuUybe-asA:10 a=hGBaWAWWAAAA:8 a=3D5Z4wfiauwA:10 a=pTmQ8MPrlF5yCmu7RboA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=IImdNFC7GeW2gY9j8qUA:9 a=_W_S_7VecoQA:10 a=gT07zXWq2zRjHTUY:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D0802126-33BB-442C-897C-CDC6DC6BDE0C"
From: Edward Lewis 
In-Reply-To: 
Date: Fri, 1 Mar 2013 09:37:04 +0800
Message-Id: <060433C4-BA40-4BF3-B970-026B4E468372@neustar.biz>
References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net>  <512BDC8B.3070602@ogud.com>  <512CCEB4.3040403@ogud.com> <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz> 
To: Tony Finch 
X-Mailer: Apple Mail (2.1283)
Cc: "dnsop@ietf.org WG" , Edward Lewis 
Subject: Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Mar 2013 01:37:08 -0000

--Apple-Mail=_D0802126-33BB-442C-897C-CDC6DC6BDE0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Feb 28, 2013, at 19:43, Tony Finch wrote:
>=20
> The update logic ought to be idempotent, i.e. the instructions from =
the
> child should be of the form "make it look like this" not "perform this
> action". Then the parent needs no state other than the CDS RRset and =
the
> DS RRset.

I'd considered that.  My experience is that this goal is admirable but =
can cause a request to become large in size and hard to understand.

I'm hoping to avoid yet another too-large RRset that could cause =
problems in abuse situations.  And we do have an interested party here, =
the client, that should have already automated the KSK change event.

> It might be desirable to be able to say "like this before =
such-and-such a
> time, and like that afterwards". So maybe CDS RRs need inception and
> expiry dates?


Oh, great scott no!

Sigh, sorry.  I spent many years (in the 90's) playing with the =
semantics of having RRSIGs for a set with varying spans of validity.  =
It's a waste!

Note - my assumption is that I'll layer over the CDS a tool that will =
manage the key roll and that tool will be managed by some sort of =
calendar.  Part of this maps to what I've seen in an open source DNS =
product that will allow users to schedule key changes now.

(Poorly worded way of saying - given how I've seen changes happen in =
operator settings, I think embedding times and trying to be idempotent =
detract from the experience.  Again, this is opinion, not based on =
factual logic.)

=
-=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            =20
NeuStar                    You can leave a voice message at =
+1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.


--Apple-Mail=_D0802126-33BB-442C-897C-CDC6DC6BDE0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



The update =
logic ought to be idempotent, i.e. the instructions from the
child =
should be of the form "make it look like this" not "perform =
this
action". Then the parent needs no state other than the CDS RRset =
and the
DS RRset.

I'd considered =
that.  My experience is that this goal is admirable but can cause a =
request to become large in size and hard to =
understand.

I'm hoping to avoid yet another =
too-large RRset that could cause problems in abuse situations.  And =
we do have an interested party here, the client, that should have =
already automated the KSK change event.

It might be desirable to be able to say "like this =
before such-and-such a
time, and like that afterwards". So maybe CDS =
RRs need inception and
expiry =
dates?

Oh, great scott =
no!

Sigh, sorry.  I spent many years (in the =
90's) playing with the semantics of having RRSIGs for a set with varying =
spans of validity.  It's a waste!

Note - =
my assumption is that I'll layer over the CDS a tool that will manage =
the key roll and that tool will be managed by some sort of calendar. =
 Part of this maps to what I've seen in an open source DNS product =
that will allow users to schedule key changes =
now.

(Poorly worded way of saying - given how =
I've seen changes happen in operator settings, I think embedding times =
and trying to be idempotent detract from the experience.  Again, =
this is opinion, not based on factual logic.)



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

There are no answers - just tradeoffs, decisions, =
and responses.




=

--Apple-Mail=_D0802126-33BB-442C-897C-CDC6DC6BDE0C--

From ed.lewis@neustar.biz  Thu Feb 28 18:30:50 2013
Return-Path: 
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C422F21F855A for ; Thu, 28 Feb 2013 18:30:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.179
X-Spam-Level: 
X-Spam-Status: No, score=-101.179 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtLRwkprMRUW for ; Thu, 28 Feb 2013 18:30:50 -0800 (PST)
Received: from eastrmfepo202.cox.net (eastrmfepo202.cox.net [68.230.241.217]) by ietfa.amsl.com (Postfix) with ESMTP id EFE5E21F854C for ; Thu, 28 Feb 2013 18:30:49 -0800 (PST)
Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130301023049.YSPO6475.eastrmfepo202.cox.net@eastrmimpo210> for ; Thu, 28 Feb 2013 21:30:49 -0500
Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id 62Wn1l0073cuADQ012Wn3C; Thu, 28 Feb 2013 21:30:49 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A02020A.513012D9.0032,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=NvcPhbhJ c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=27vuUybe-asA:10 a=hGBaWAWWAAAA:8 a=3D5Z4wfiauwA:10 a=BMKi58c_48jn46fH-CMA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=TH-9XRYfb9FLGgT56n8A:9 a=_W_S_7VecoQA:10 a=aRnVD5U987WYUJAH:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E910B4D1-463F-4B28-8820-4361C54958FC"
From: Edward Lewis 
In-Reply-To: <512FE202.20505@ogud.com>
Date: Fri, 1 Mar 2013 10:30:47 +0800
Message-Id: 
References: <20130218210600.19691.97544.idtracker@ietfa.amsl.com> <31B601E4-AE9E-48B2-8D6F-5E8FE6044FE2@kumari.net>  <512BDC8B.3070602@ogud.com>  <512CCEB4.3040403@ogud.com> <4AAE2A31-DBD9-4D4D-B233-FFF5A44D4041@neustar.biz> <512FE202.20505@ogud.com>
To: "dnsop@ietf.org WG" 
X-Mailer: Apple Mail (2.1283)
Cc: Edward Lewis 
Subject: Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Mar 2013 02:30:50 -0000

--Apple-Mail=_E910B4D1-463F-4B28-8820-4361C54958FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I had sent a more detailed off-list reply, but I should address this:

On Mar 1, 2013, at 7:02, Olafur Gudmundsson wrote:

> Thus before we go into discussion into details of record formats, lets
> have the REPLACE vs ADD/DELETE discussion.


My starting assumption is that the CDS will be a tool used inside a =
script or procedure (which may already exist in operating zones) that =
performs the change of the SEP.  These tools vary by operator because of =
the myriad of combinations of requirements in place.

In my opinion, for the CDS to be useful in all of the various =
environments if has to avoid getting beyond the most basic primitives.  =
No assumption that the adds and deletes are parts of a replace, no =
expression of timing, no expression of any other policy-like thing.

Leave the semantics to the scripts and policies already in place.  Even =
if you just do that, CDS cuts down on having to transport the keying =
material via something like cut and paste from a dig or web page to a =
web form.  (To use the situation I have most in mind.)

=
-=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            =20
NeuStar                    You can leave a voice message at =
+1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.


--Apple-Mail=_E910B4D1-463F-4B28-8820-4361C54958FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Thus before we =
go into discussion into details of record formats, lets
have the =
REPLACE vs ADD/DELETE =
discussion.

My starting =
assumption is that the CDS will be a tool used inside a script or =
procedure (which may already exist in operating zones) that performs the =
change of the SEP.  These tools vary by operator because of the =
myriad of combinations of requirements in place.

In =
my opinion, for the CDS to be useful in all of the various environments =
if has to avoid getting beyond the most basic primitives.  No =
assumption that the adds and deletes are parts of a replace, no =
expression of timing, no expression of any other policy-like =
thing.

Leave the semantics to the scripts and =
policies already in place.  Even if you just do that, CDS cuts down =
on having to transport the keying material via something like cut and =
paste from a dig or web page to a web form.  (To use the situation =
I have most in mind.)



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

There are no answers - just tradeoffs, decisions, =
and responses.




=

--Apple-Mail=_E910B4D1-463F-4B28-8820-4361C54958FC--