From bmanning@karoshi.com Wed Feb 1 04:11:34 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BDF21F86A3 for ; Wed, 1 Feb 2012 04:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlPzSGJnGCou for ; Wed, 1 Feb 2012 04:11:33 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id D461621F858B for ; Wed, 1 Feb 2012 04:11:32 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q11CBSFB009034 for ; Wed, 1 Feb 2012 12:11:28 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q11CBSZx009033 for dnsop@ietf.org; Wed, 1 Feb 2012 12:11:28 GMT Date: Wed, 1 Feb 2012 12:11:28 +0000 From: bmanning@vacation.karoshi.com To: dnsop@ietf.org Message-ID: <20120201121128.GD8952@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [DNSOP] draft of RFC 2870-bis for consideration 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, 01 Feb 2012 12:11:34 -0000 The Root Server System Advisory Committee of ICANN has been working on a revision to RFC 2870. It is currently posted as: ------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Root Name Server Operational Requirements Author(s) : Root Server System Advisory Committee Filename : draft-rssac-dnsop-rfc2870bis-03.txt Pages : 9 Date : 2012-01-31 As the Internet has become critical to the world's social and economic infrastructure, attention has focused on the correct, safe, reliable, and secure operation of the Internet infrastructure itself. The DNS is considered a crucial part of that technical infrastrcuture. The root domain and its authoritative name servers are a part of that technical infrastructure. The primary focus of this document is to provide guidelines for secure, stable, and resilient authoritative name service for the root zone. Additionally it will look into some specifics for the operation of the name servers. Other operators of authoritative name servers such as those for generic top-level domains (gTLDs), country code top-level domains (ccTLDs) and other zones may also find it useful. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rssac-dnsop-rfc2870bis-03.txt ------------ Your comments would be appreciated. /bill From jad@sinodun.com Wed Feb 1 09:08:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504B211E811B for ; Wed, 1 Feb 2012 09:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WDmw+FkmmG2 for ; Wed, 1 Feb 2012 09:08:06 -0800 (PST) Received: from cpanelsmarthost3.zen.co.uk (cpanelsmarthost3.zen.co.uk [82.71.204.227]) by ietfa.amsl.com (Postfix) with ESMTP id 11A3A11E8115 for ; Wed, 1 Feb 2012 09:08:05 -0800 (PST) Received: from [88.98.24.67] (helo=shcp01.hosting.zen.net.uk) by cpanelsmarthost3.zen.co.uk with esmtp (Exim 4.72) (envelope-from ) id 1Rsdf0-0000Dn-3w for dnsop@ietf.org; Wed, 01 Feb 2012 17:07:54 +0000 Received: from 82-68-198-190.dsl.in-addr.zen.co.uk ([82.68.198.190] helo=[10.0.1.2]) by shcp01.hosting.zen.net.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Rsdeo-00072n-Un; Wed, 01 Feb 2012 17:07:43 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: John Dickinson In-Reply-To: <20120201121128.GD8952@vacation.karoshi.com.> Date: Wed, 1 Feb 2012 17:07:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120201121128.GD8952@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1251.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sinodun.com Cc: dnsop@ietf.org Subject: Re: [DNSOP] draft of RFC 2870-bis for consideration 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, 01 Feb 2012 17:08:07 -0000 On Feb 1, 2012, at 12:11 PM, bmanning@vacation.karoshi.com wrote: >=20 > The Root Server System Advisory Committee of ICANN has been working on = a revision to RFC 2870. > It is currently posted as: >=20 > ------------ > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Root Name Server Operational Requirements > Author(s) : Root Server System Advisory Committee > Filename : draft-rssac-dnsop-rfc2870bis-03.txt > Pages : 9 > Date : 2012-01-31 >=20 =85 > Your comments would be appreciated. Hi, The document is good and useful, here are a few nits and comments. Abstract: Remove the word "safe" - what does it mean? Reword and correct spelling in last two sentences to say "The DNS is = considered a crucial part of the Internet infrastructure. The root zone = and its authoritative name servers are a key part of that DNS = infrastructure." 1. Background: Inconsistent use of 1 or 2 spaces after a full stop. Sentence 1: As before, remove the word "safe". Also s/domain/zone/ Sentence 3: mentions "... name service known by its letter, ...". Remove = the words "known by its letter," and add a sentence before this one = saying "Each of the 13 authoritative root name servers are identified by = a letter A - M.". 1.5. Sentence 2: s/transit are be considered/transit are considered/ Penultimate paragraph: This repeats text that is already in the = beginning of this section. 2. The Servers Themselves 2.2 modify to read "... the IETF standards relating to authoritative = DNS, ..." 2.3 modify to read "... able to handle a load of DNS queries which ..." = or even "... able to handle a packet load which ..." 2.6 last sentence: I don't really get this sentence - isn't it covered by just saying = something like "Send the response to the source address of the query"? 3.2.1: Sentence 1: Network time protocol should not be acting as a server on root servers = (as stated in 3.2.5). Routing daemons may be needed on the name server to allow 1.6 and 4.4. Sentence 2: remove 1 space from between the words "likely" and "there". I think the last sentence is too restrictive (As long as secure = authentication and encryption are available). 3.3.5 is hard to parse. Also sections 3.3.7 and 3.3.8, Can these not = refer to the root zone DPS and other similar documents? I note that there is no mention of the root DPS anywhere in this draft. 3.3.9 Should this start "Each root operator ..." 4.1 Last sentence is wrong or I don't understand it - "Root server nodes = be numbered (v4 and v6) using addresses ..." and I am not sure of the = correct wording. 4.2 I am not an anycast expert but should this read "Each of a root = server's anycast instances MUST be sourced ..."? HTH John --- jad@sinodun.com http://sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From bmanning@karoshi.com Fri Feb 3 21:53:47 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C0021F84F4 for ; Fri, 3 Feb 2012 21:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.183 X-Spam-Level: X-Spam-Status: No, score=-5.183 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ze6qKsZjAx6 for ; Fri, 3 Feb 2012 21:53:46 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id DB1B421F84EC for ; Fri, 3 Feb 2012 21:53:45 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q11H9WFB010080; Wed, 1 Feb 2012 17:09:32 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q11H9WYf010079; Wed, 1 Feb 2012 17:09:32 GMT Date: Wed, 1 Feb 2012 17:09:32 +0000 From: bmanning@vacation.karoshi.com To: John Dickinson Message-ID: <20120201170932.GC9580@vacation.karoshi.com.> References: <20120201121128.GD8952@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dnsop@ietf.org Subject: Re: [DNSOP] draft of RFC 2870-bis for consideration 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, 04 Feb 2012 05:53:47 -0000 thanks. will fold in your comments. /bill From warren@kumari.net Sun Feb 5 08:34:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AAC21F8547 for ; Sun, 5 Feb 2012 08:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwCgVpdGzAqz for ; Sun, 5 Feb 2012 08:34:09 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id EEE3C21F84EB for ; Sun, 5 Feb 2012 08:34:08 -0800 (PST) Received: from [192.168.1.3] (unknown [38.96.24.2]) by vimes.kumari.net (Postfix) with ESMTPSA id B275F1B402A0; Sun, 5 Feb 2012 11:34:07 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <20120201121128.GD8952@vacation.karoshi.com.> Date: Sun, 5 Feb 2012 11:34:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1D787F0C-62A5-4770-BF0D-FC5E90C2D6A9@kumari.net> References: <20120201121128.GD8952@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1084) Cc: dnsop@ietf.org Subject: Re: [DNSOP] draft of RFC 2870-bis for consideration 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, 05 Feb 2012 16:34:09 -0000 Nits and notes: Abstract:=20 O: The DNS is considered a crucial part of that technical = infrastrcuture. P: The DNS is considered a crucial part of that technical = infrastructure. C: s/infrastrcuture/infrastructure/ -- typo. Background: O: ...servers to enable robust dand resilient=85 P: ...servers to enable robust and resilient=85 C: s/dand/and/ -- typo. 1.4: O: ...temporary simulatneous loss of many=85 P: ...temporary simultaneous loss of many=85 C: s/simulatneous/simultaneous/ -- typo. 3.2.1: O: ...for TSIG and DNSSEC syncronization=85 P: ...for TSIG and DNSSEC synchronization=85 C: s/syncronization/synchronization/ -- typo. 3.2.6: O: Servers must log in UTC to facilitate log comparison. C: Seems a little strong -- If I want to log in fortnights since lunar = eclipse, that's my business -- as long as I'm willing to convert the log = to UTC before handing it to be analyzed. 3.2.8: O: "The server should be protected from attacks based on source routing. = The server must not soley rely on address- or name-based = authentication." C: Seems like it should have more text. Not entirely sure what is being = said here. also: s/soley/solely/ -- typo. 3.3.6: O: ...based on the currnet update cycle=85 P: ...based on the current update cycle=85 C: s/currnet/current/ -- typo. 3.3.10: O: These monitoring processes could be automated.=20 P: These monitoring processes should be automated.=20 4.2: C: See "draft-mcpherson-unique-origin-as-00" (expired). Neither = supporting nor opposing the draft, just mentioning it. 5.1:=20 O: ... a scheduled maintaince window=85 P: ... a scheduled maintenance window=85 C: s/maintaince/maintenance/ --typo. W On Feb 1, 2012, at 7:11 AM, bmanning@vacation.karoshi.com wrote: >=20 > The Root Server System Advisory Committee of ICANN has been working on = a revision to RFC 2870. > It is currently posted as: >=20 > ------------ > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Root Name Server Operational Requirements > Author(s) : Root Server System Advisory Committee > Filename : draft-rssac-dnsop-rfc2870bis-03.txt > Pages : 9 > Date : 2012-01-31 >=20 > As the Internet has become critical to the world's social and = economic > infrastructure, attention has focused on the correct, safe, reliable, = and > secure operation of the Internet infrastructure itself. The DNS is = considered > a crucial part of that technical infrastrcuture. The root domain and = its > authoritative name servers are a part of that technical = infrastructure. >=20 > The primary focus of this document is to provide guidelines for = secure, stable, > and resilient authoritative name service for the root zone. = Additionally it will > look into some specifics for the operation of the name servers. = Other operators > of authoritative name servers such as those for generic top-level = domains (gTLDs), > country code top-level domains (ccTLDs) and other zones may also find = it useful. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-rssac-dnsop-rfc2870bis-03.txt > ------------ >=20 > Your comments would be appreciated. >=20 > /bill > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From bmanning@karoshi.com Sun Feb 5 14:02:42 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD4A21F8489 for ; Sun, 5 Feb 2012 14:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[AWL=-1.715, BAYES_00=-2.599, MIME_ASCII0=1.5, NULL_IN_BODY=2.425, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxtStEsPl-i1 for ; Sun, 5 Feb 2012 14:02:38 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6F21F8480 for ; Sun, 5 Feb 2012 14:02:38 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q15M2baB011565; Sun, 5 Feb 2012 22:02:38 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q15M2XWP011562; Sun, 5 Feb 2012 22:02:33 GMT Date: Sun, 5 Feb 2012 22:02:33 +0000 From: bmanning@vacation.karoshi.com To: Warren Kumari Message-ID: <20120205220233.GA9268@vacation.karoshi.com.> References: <20120201121128.GD8952@vacation.karoshi.com.> <1D787F0C-62A5-4770-BF0D-FC5E90C2D6A9@kumari.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1D787F0C-62A5-4770-BF0D-FC5E90C2D6A9@kumari.net> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dnsop@ietf.org Subject: Re: [DNSOP] draft of RFC 2870-bis for consideration 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, 05 Feb 2012 22:02:42 -0000 will fold them in, thanks. /bill On Sun, Feb 05, 2012 at 11:34:06AM -0500, Warren Kumari wrote: > Nits and notes: > > Abstract: > O: The DNS is considered a crucial part of that technical infrastrcuture. > P: The DNS is considered a crucial part of that technical infrastructure. > C: s/infrastrcuture/infrastructure/ -- typo. > > Background: > O: ...servers to enable robust dand resilientb& > P: ...servers to enable robust and resilientb& > C: s/dand/and/ -- typo. > > 1.4: > O: ...temporary simulatneous loss of manyb& > P: ...temporary simultaneous loss of manyb& > C: s/simulatneous/simultaneous/ -- typo. > > 3.2.1: > O: ...for TSIG and DNSSEC syncronizationb& > P: ...for TSIG and DNSSEC synchronizationb& > C: s/syncronization/synchronization/ -- typo. > > 3.2.6: > O: Servers must log in UTC to facilitate log comparison. > C: Seems a little strong -- If I want to log in fortnights since lunar eclipse, that's my business -- as long as I'm willing to convert the log to UTC before handing it to be analyzed. > > 3.2.8: > O: "The server should be protected from attacks based on source routing. The server must not soley rely on address- or name-based authentication." > C: Seems like it should have more text. Not entirely sure what is being said here. > also: s/soley/solely/ -- typo. > > 3.3.6: > O: ...based on the currnet update cycleb& > P: ...based on the current update cycleb& > C: s/currnet/current/ -- typo. > > 3.3.10: > O: These monitoring processes could be automated. > P: These monitoring processes should be automated. > > 4.2: > C: See "draft-mcpherson-unique-origin-as-00" (expired). Neither supporting nor opposing the draft, just mentioning it. > > 5.1: > O: ... a scheduled maintaince windowb& > P: ... a scheduled maintenance windowb& > C: s/maintaince/maintenance/ --typo. > > > W > > > > > > On Feb 1, 2012, at 7:11 AM, bmanning@vacation.karoshi.com wrote: > > > > > The Root Server System Advisory Committee of ICANN has been working on a revision to RFC 2870. > > It is currently posted as: > > > > ------------ > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : Root Name Server Operational Requirements > > Author(s) : Root Server System Advisory Committee > > Filename : draft-rssac-dnsop-rfc2870bis-03.txt > > Pages : 9 > > Date : 2012-01-31 > > > > As the Internet has become critical to the world's social and economic > > infrastructure, attention has focused on the correct, safe, reliable, and > > secure operation of the Internet infrastructure itself. The DNS is considered > > a crucial part of that technical infrastrcuture. The root domain and its > > authoritative name servers are a part of that technical infrastructure. > > > > The primary focus of this document is to provide guidelines for secure, stable, > > and resilient authoritative name service for the root zone. Additionally it will > > look into some specifics for the operation of the name servers. Other operators > > of authoritative name servers such as those for generic top-level domains (gTLDs), > > country code top-level domains (ccTLDs) and other zones may also find it useful. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-rssac-dnsop-rfc2870bis-03.txt > > ------------ > > > > Your comments would be appreciated. > > > > /bill > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > Don't be impressed with unintelligible stuff said condescendingly. > -- Radia Perlman. > > > > > From drc@virtualized.org Sun Feb 5 19:40:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A041321F84EF for ; Sun, 5 Feb 2012 19:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YklKVCb8kRN0 for ; Sun, 5 Feb 2012 19:40:53 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 95DF721F8491 for ; Sun, 5 Feb 2012 19:40:53 -0800 (PST) Received: from [10.0.1.3] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 89B451705A; Mon, 6 Feb 2012 03:40:52 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20120201121128.GD8952@vacation.karoshi.com.> Date: Sun, 5 Feb 2012 19:40:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <02383F13-44C8-47AE-A40B-44B7A57548CB@virtualized.org> References: <20120201121128.GD8952@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1257) Cc: dnsop@ietf.org Subject: Re: [DNSOP] draft of RFC 2870-bis for consideration 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, 06 Feb 2012 03:40:54 -0000 Bill, Comments/nits/etc. Regards, -drc -------- Last sentence of Abstract: "... zones may also find it useful." Might suggest "... zones may also find this document useful." --- 1. Background, second sentence: "The Internet Assigned Numbers Authority (IANA) publishes ..." Should be: "The Internet Assigned Numbers Authority functions operator (IANA) = publishes ..."=20 --- 1. Background, next sentence: "... refer to the many ways a root operator provisions to provide root = name service known by its letter, ..." Since the naming convention of the root servers isn't introduced to this = point (or discussed later or even germane to the discussion), I'd = suggest dropping "known by its letter," --- 1. Background, last sentence of first paragraph: Typo "dand". --- The sub-points of section 1 aren't really introduced, they just sort of = show up. Perhaps before 1.1, putting something like "At a high level, = the root servers operate under the following general characteristics:" = or somesuch.=20 --- 1.2 "For legacy reasons, some of the root servers have also served other = important zones, In the future, the data served by root servers may = change after careful review by RSSAC and ICANN." The second comma should probably be a period. The use of a past-tense = verb suggests that some of the root servers are not now serving other = important zones. Since those root servers still serve those zones, it = would be clearer to state: "For legacy reasons, some of the root servers serve other important = zones. In the future ..." --- 1.4 "The domain name system has proven to be sufficiently robust that = the temporary simulatneous loss of many of the root server instances = does not significantly affect secure and stable operation of the = Internet. [citeation]" I'm not sure the ambiguous term "many" is warranted, particularly = without a citation. Perhaps "loss of a number of" and "has not ... = affected" instead of "does not ... affect" since that suggests loss = occurs with some frequency. Also typo: "simultaneous". --- 1.5 "Authentication, validation, and security of these data and the = communications channels they transit are be considered possible attack = vectors." "are to be" or "should be" and I think you want the term = "vulnerabilities", not "attack vectors". --- 1.5 "... equal-cost multipath routing and Anycast routing. (Anycast is = discussed further in Section 4.)" Probably should provide a citation to the documents that define anycast = here, e.g., RFC 3258 (as opposed to later). --- "For simplicity, this document uses the term "server" to refer to = however many hosts a root operator provisions to provide root name = service at a single address per address family." Duplicative of wording in the first paragraph of this section. --- "2. The Servers Themselves" Given there is no mechanism for enforcement, these aren't = "requirements". They are better termed "suggestions" or perhaps couched = in terms of "best current practices". --- 2.1 Not phrased as an imperative. It also isn't clear as to whether = this is discussing the root server _system_ or an individual root server = operator's implementation of their part of the system. Assuming the = former, perhaps: "In order to improve overall robustness, the root server system SHOULD = utilize heterogeneous hardware, operating systems, network topology, and = name serving software across the root name servers." --- 2.2 Not phrased as an imperative. Perhaps: "While there are no accepted, formal test suites for standards = compliance, the maintainers of software used on root servers SHOULD take = all reasonable actions to ensure their DNS server software correctly = implements the IETF standards for authoritative DNS, including = RFC1035[2], RFC2181[3], RFC4035[14] and others that conform to the = IETF's then-current documented expectations." --- 2.3 "... each server must be able ..." s/must/SHOULD/ --- 2.4 "Connectivity to the Internet should be as diverse as possible." Expansion/clarification of this sentence would probably be helpful. = Diversity in terms of what? --- 2.5 s/must/SHOULD/ Also, I might quibble about overgeneralizing. There are authoritative = name servers that cache responses in order to improve performance. As = the root zone grows, this may become more important. It might be = prudent to clarify what sort of caching this suggestion is recommending = against. --- 2.6 s/must/SHOULD/ Also, clarification of "valid IP address" is probably warranted, e.g., = "allocated IP address". I think it appropriate for root servers to NOT = respond to queries from (e.g.) IPv4 10/8 or anything in IPv6 outside of = the current FP. --- 2.8 s/must/SHOULD/ --- 3.1 s/will/SHOULD/ --- 3.1.1 s/must/SHOULD/ --- 3.1.2 s/must/SHOULD/ --- 3.1.3 s/must/SHOULD/ --- 3.1.4 s/must/SHOULD/ --- 3.2.1 "routing daemons" My understanding is that this would preclude some (many? all?) root = server instances from withdrawing their internal /32 (/128?) route = should their DNS server be observed to crash. s/must/SHOULD/ "and locations from which remote login is allowed must be protected and = hardened" s/must/SHOULD/ Also, might be worthwhile documenting the presumption that remote login = from non-protected/hardened locations would be assumed to go through a = bastion host of some kind (if that is the presumption). --- 3.2.2 s/must/SHOULD/ --- 3.2.4 "The broadcast domain(s) in which a root server node is located = should be separately firewalled or packet filtered to prohibit network = access to any port other than those needed for name service." This would seem to preclude people ssh'ing into a root server instance. = Perhaps "... for name service and administration of the name server." --- 3.2.5 Might also suggest servers could use external (e.g., GPS-based) = clocks. --- 3.2.8 s/must/SHOULD/ --- 3.3 "Protocol authentication and security are required to ..." As before, since there is no mechanism for enforcement, I'd recommend = rephrasing this to "Protocol authentication and security should be used = to ..." --- 3.3.1 is not a requirement for root server operators (and besides, as = written, this is wrong -- the root zone is signed and maintained by the = U.S. Dept. of Commerce contractor, currently Verisign, not the IANA = functions operator). --- 3.3.2 s/must/SHOULD/ --- 3.3.3 s/must/SHOULD/ --- 3.3.7 12 hours seems a bit long for an 'emergency update'. --- 3.3.8 s/must/SHOULD/ --- 3.3.10 s/must/SHOULD/ --- 4.1 To give the dead horse another whack, given the challenges = associated with renumbering root name servers (specifically the long = half-life of the old addresses and, as a result, the inability to reuse = those address) and the requirement inherent in the DNS protocol to avoid = the chicken-or-egg problem in resolving root server addresses, I believe = we should treat root server IP addresses as "golden addresses" a la RFC = 3068 and not the "property" of the root server operators.=20 --- 4.3 s/must/SHOULD/ --- 4.6 The last sentence probably shouldn't be a question. --- 5.4 is missing --- 5.5 s/must/SHOULD/ On Feb 1, 2012, at 4:11 AM, bmanning@vacation.karoshi.com wrote: >=20 > The Root Server System Advisory Committee of ICANN has been working on = a revision to RFC 2870. > It is currently posted as: >=20 > ------------ > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Root Name Server Operational Requirements > Author(s) : Root Server System Advisory Committee > Filename : draft-rssac-dnsop-rfc2870bis-03.txt > Pages : 9 > Date : 2012-01-31 >=20 > As the Internet has become critical to the world's social and = economic > infrastructure, attention has focused on the correct, safe, reliable, = and > secure operation of the Internet infrastructure itself. The DNS is = considered > a crucial part of that technical infrastrcuture. The root domain and = its > authoritative name servers are a part of that technical = infrastructure. >=20 > The primary focus of this document is to provide guidelines for = secure, stable, > and resilient authoritative name service for the root zone. = Additionally it will > look into some specifics for the operation of the name servers. = Other operators > of authoritative name servers such as those for generic top-level = domains (gTLDs), > country code top-level domains (ccTLDs) and other zones may also find = it useful. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-rssac-dnsop-rfc2870bis-03.txt > ------------ >=20 > Your comments would be appreciated. >=20 > /bill > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From bmanning@karoshi.com Sun Feb 5 19:42:55 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B0621F8530 for ; Sun, 5 Feb 2012 19:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.88 X-Spam-Level: X-Spam-Status: No, score=-6.88 tagged_above=-999 required=5 tests=[AWL=1.119, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaVRd7Znok4j for ; Sun, 5 Feb 2012 19:42:54 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2820421F8512 for ; Sun, 5 Feb 2012 19:42:52 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q163gkaB012463; Mon, 6 Feb 2012 03:42:48 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q163giR3012462; Mon, 6 Feb 2012 03:42:44 GMT Date: Mon, 6 Feb 2012 03:42:43 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Message-ID: <20120206034243.GA12355@vacation.karoshi.com.> References: <20120201121128.GD8952@vacation.karoshi.com.> <02383F13-44C8-47AE-A40B-44B7A57548CB@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02383F13-44C8-47AE-A40B-44B7A57548CB@virtualized.org> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dnsop@ietf.org Subject: Re: [DNSOP] draft of RFC 2870-bis for consideration 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, 06 Feb 2012 03:42:55 -0000 thanks! will fold in accordingly. /bill On Sun, Feb 05, 2012 at 07:40:49PM -0800, David Conrad wrote: > Bill, > > Comments/nits/etc. > > Regards, > -drc > -------- > Last sentence of Abstract: > > "... zones may also find it useful." > > Might suggest "... zones may also find this document useful." > --- > 1. Background, second sentence: > > "The Internet Assigned Numbers Authority (IANA) publishes ..." > > Should be: > > "The Internet Assigned Numbers Authority functions operator (IANA) publishes ..." > --- > 1. Background, next sentence: > > "... refer to the many ways a root operator provisions to provide root name service known by its letter, ..." > > Since the naming convention of the root servers isn't introduced to this point (or discussed later or even germane to the discussion), I'd suggest dropping "known by its letter," > --- > 1. Background, last sentence of first paragraph: > > Typo "dand". > --- > The sub-points of section 1 aren't really introduced, they just sort of show up. Perhaps before 1.1, putting something like "At a high level, the root servers operate under the following general characteristics:" or somesuch. > --- > 1.2 "For legacy reasons, some of the root servers have also served other important zones, In the future, the data served by root servers may change after careful review by RSSAC and ICANN." > > The second comma should probably be a period. The use of a past-tense verb suggests that some of the root servers are not now serving other important zones. Since those root servers still serve those zones, it would be clearer to state: > > "For legacy reasons, some of the root servers serve other important zones. In the future ..." > --- > 1.4 "The domain name system has proven to be sufficiently robust that the temporary simulatneous loss of many of the root server instances does not significantly affect secure and stable operation of the Internet. [citeation]" > > I'm not sure the ambiguous term "many" is warranted, particularly without a citation. Perhaps "loss of a number of" and "has not ... affected" instead of "does not ... affect" since that suggests loss occurs with some frequency. Also typo: "simultaneous". > --- > 1.5 "Authentication, validation, and security of these data and the communications channels they transit are be considered possible attack vectors." > > "are to be" or "should be" and I think you want the term "vulnerabilities", not "attack vectors". > --- > 1.5 "... equal-cost multipath routing and Anycast routing. (Anycast is discussed further in Section 4.)" > > Probably should provide a citation to the documents that define anycast here, e.g., RFC 3258 (as opposed to later). > --- > "For simplicity, this document uses the term "server" to refer to however many hosts a root operator provisions to provide root name service at a single address per address family." > > Duplicative of wording in the first paragraph of this section. > --- > "2. The Servers Themselves" > > Given there is no mechanism for enforcement, these aren't "requirements". They are better termed "suggestions" or perhaps couched in terms of "best current practices". > --- > 2.1 Not phrased as an imperative. It also isn't clear as to whether this is discussing the root server _system_ or an individual root server operator's implementation of their part of the system. Assuming the former, perhaps: > > "In order to improve overall robustness, the root server system SHOULD utilize heterogeneous hardware, operating systems, network topology, and name serving software across the root name servers." > --- > 2.2 Not phrased as an imperative. Perhaps: > > "While there are no accepted, formal test suites for standards compliance, the maintainers of software used on root servers SHOULD take all reasonable actions to ensure their DNS server software correctly implements the IETF standards for authoritative DNS, including RFC1035[2], RFC2181[3], RFC4035[14] and others that conform to the IETF's then-current documented expectations." > --- > 2.3 "... each server must be able ..." > > s/must/SHOULD/ > --- > 2.4 "Connectivity to the Internet should be as diverse as possible." > > Expansion/clarification of this sentence would probably be helpful. Diversity in terms of what? > --- > 2.5 s/must/SHOULD/ > > Also, I might quibble about overgeneralizing. There are authoritative name servers that cache responses in order to improve performance. As the root zone grows, this may become more important. It might be prudent to clarify what sort of caching this suggestion is recommending against. > --- > 2.6 s/must/SHOULD/ > > Also, clarification of "valid IP address" is probably warranted, e.g., "allocated IP address". I think it appropriate for root servers to NOT respond to queries from (e.g.) IPv4 10/8 or anything in IPv6 outside of the current FP. > --- > 2.8 s/must/SHOULD/ > --- > 3.1 s/will/SHOULD/ > --- > 3.1.1 s/must/SHOULD/ > --- > 3.1.2 s/must/SHOULD/ > --- > 3.1.3 s/must/SHOULD/ > --- > 3.1.4 s/must/SHOULD/ > --- > 3.2.1 "routing daemons" > > My understanding is that this would preclude some (many? all?) root server instances from withdrawing their internal /32 (/128?) route should their DNS server be observed to crash. > > s/must/SHOULD/ > > "and locations from which remote login is allowed must be protected and hardened" > > s/must/SHOULD/ > > Also, might be worthwhile documenting the presumption that remote login from non-protected/hardened locations would be assumed to go through a bastion host of some kind (if that is the presumption). > --- > 3.2.2 s/must/SHOULD/ > --- > 3.2.4 "The broadcast domain(s) in which a root server node is located should be separately firewalled or packet filtered to prohibit network access to any port other than those needed for name service." > > This would seem to preclude people ssh'ing into a root server instance. Perhaps "... for name service and administration of the name server." > --- > 3.2.5 Might also suggest servers could use external (e.g., GPS-based) clocks. > --- > 3.2.8 s/must/SHOULD/ > --- > 3.3 "Protocol authentication and security are required to ..." > > As before, since there is no mechanism for enforcement, I'd recommend rephrasing this to "Protocol authentication and security should be used to ..." > --- > 3.3.1 is not a requirement for root server operators (and besides, as written, this is wrong -- the root zone is signed and maintained by the U.S. Dept. of Commerce contractor, currently Verisign, not the IANA functions operator). > --- > 3.3.2 s/must/SHOULD/ > --- > 3.3.3 s/must/SHOULD/ > --- > 3.3.7 12 hours seems a bit long for an 'emergency update'. > --- > 3.3.8 s/must/SHOULD/ > --- > 3.3.10 s/must/SHOULD/ > --- > 4.1 To give the dead horse another whack, given the challenges associated with renumbering root name servers (specifically the long half-life of the old addresses and, as a result, the inability to reuse those address) and the requirement inherent in the DNS protocol to avoid the chicken-or-egg problem in resolving root server addresses, I believe we should treat root server IP addresses as "golden addresses" a la RFC 3068 and not the "property" of the root server operators. > --- > 4.3 s/must/SHOULD/ > --- > 4.6 The last sentence probably shouldn't be a question. > --- > 5.4 is missing > --- > 5.5 s/must/SHOULD/ > > > On Feb 1, 2012, at 4:11 AM, bmanning@vacation.karoshi.com wrote: > > > > The Root Server System Advisory Committee of ICANN has been working on a revision to RFC 2870. > > It is currently posted as: > > > > ------------ > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : Root Name Server Operational Requirements > > Author(s) : Root Server System Advisory Committee > > Filename : draft-rssac-dnsop-rfc2870bis-03.txt > > Pages : 9 > > Date : 2012-01-31 > > > > As the Internet has become critical to the world's social and economic > > infrastructure, attention has focused on the correct, safe, reliable, and > > secure operation of the Internet infrastructure itself. The DNS is considered > > a crucial part of that technical infrastrcuture. The root domain and its > > authoritative name servers are a part of that technical infrastructure. > > > > The primary focus of this document is to provide guidelines for secure, stable, > > and resilient authoritative name service for the root zone. Additionally it will > > look into some specifics for the operation of the name servers. Other operators > > of authoritative name servers such as those for generic top-level domains (gTLDs), > > country code top-level domains (ccTLDs) and other zones may also find it useful. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-rssac-dnsop-rfc2870bis-03.txt > > ------------ > > > > Your comments would be appreciated. > > > > /bill > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > From bmanning@karoshi.com Mon Feb 6 11:15:12 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14ABF21F86C2 for ; Mon, 6 Feb 2012 11:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSqKfpx3H3J0 for ; Mon, 6 Feb 2012 11:15:10 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC9721F869A for ; Mon, 6 Feb 2012 11:15:10 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q16JCvaB014896; Mon, 6 Feb 2012 19:12:57 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q16JCuCC014895; Mon, 6 Feb 2012 19:12:56 GMT Date: Mon, 6 Feb 2012 19:12:56 +0000 From: bmanning@vacation.karoshi.com To: rssac@icann.org, dnsop@ietf.org Message-ID: <20120206191256.GA14871@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 19:15:12 -0000 Thanks to Warren, Ed, John D., David C. and Kato-san for their comments/corrections. Any more? /bill From: internet-drafts@ietf.org Date: Mon, 06 Feb 2012 09:01:00 -0800 Subject: I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Root Name Server Operational Requirements Author(s) : Root Server System Advisory Committee Filename : draft-rssac-dnsop-rfc2870bis-04.txt Pages : 10 Date : 2012-02-06 As the Internet has become critical to the world's social and economic infrastructure, attention has focused on the correct, safe, reliable, and secure operation of the Internet infrastructure itself. The DNS is considered a crucial part of that technical infrastructure. The root domain and its authoritative name servers are a part of that technical infrastructure. The primary focus of this document is to provide guidelines for secure, stable, and resilient authoritative name service for the root zone. Additionally it will look into some specifics for the operation of the name servers. Other operators of authoritative name servers such as those for generic top-level domains (gTLDs), country code top-level domains (ccTLDs) and other zones may also find this document useful. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rssac-dnsop-rfc2870bis-04.txt From paul.hoffman@vpnc.org Mon Feb 6 12:49:27 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4F121F8755 for ; Mon, 6 Feb 2012 12:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYRrjwIwoCC2 for ; Mon, 6 Feb 2012 12:49:26 -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 8948A21F873D for ; Mon, 6 Feb 2012 12:49:26 -0800 (PST) Received: from [192.168.11.124] ([12.239.109.3]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q16Kn34i038181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Feb 2012 13:49:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120206191256.GA14871@vacation.karoshi.com.> Date: Mon, 6 Feb 2012 15:49:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1F781ED0-0198-4771-9ECA-D5785850C8CD@vpnc.org> References: <20120206191256.GA14871@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1251.1) Cc: rssac@icann.org, dnsop@ietf.org Subject: [DNSOP] Comments on draft-rssac-dnsop-rfc2870bis-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 20:49:28 -0000 Greetings again. This looks much better than the -00, but still needs = more effort. The language in the text is still very rough (larger than "nits", not = quite as bad as "confusing"). I believe that the amount of copy editing = done by the RFC Editor depends on the stream through which you submit = the document. If anyone in the root server operator community can spare = <5 hours of an in-house copy editor, you should strongly consider it = before turning the document in; otherwise, the AUTH48 comments will = either be extensive enough to make finding newly-introduced mistakes = difficult, or too few so as to make the document seem unprofessional = (particularly when compared to RFC 2870). The paragraph at the end of section 1 (the "isn't really 2119 language" = text) is quite cute and will cause you a world of pain and delay. You = have de-capped everything, so remove the paragraph. (Unless you're just = trying to make John Klensin even grumpier, which is also quite cute but = will also cause you a world of pain and delay). The intro to section 3 says: The servers need both physical and protocol security as well as unambiguous authentication of their responses. Physical security = focuses on the machines and their locations, Protocol security and response=20= authentication are covered by Internet Protocol standards. However, there are three subsections, the middle being "network = security". Further, much of the protocol security is covered by by = transport layer security, not IP security. Proposed new wording: The servers need to be protected by physical and protocol security = for their administration and communications. They also need to be = protected by network security to reduce their vulnerability to attack. Physical security focuses on the machines and their locations, network = security focuses on the way that the root servers are connected to the = Internet, and protocol security focuses on administrative communication with = the servers as well as integrity protection for the messages from the servers to the public. The text in 3.2.5 doesn't make sense. NTP can't be on the list if the = operator is expected to get time updates "in as secure manner as = possible". A proposed rewording would be to just remove that phrase = because you describe what operationally is needed to use NTP in a = non-crypto secure manner. Security Considerations are supposed to be just before references, so = things are going to be reordered and renumbered by the RFC Editor unless = you do it yourself sooner. Given the fact that you use sectional = cross-references, doing this yourself is probably better than waiting = for the RFC Editor to do it for you. Using numbers for reference instead of something useful is allowed and = makes it hard to understand the document. Consider making the references = more useful. For example, references 8, 9, and 10 are (soonesqe) going = to be expanded to also include draft-ietf-dnsext-dnssec-bis and RFC = 5011; this would be clearer if it was clear what you were referring to. For the author reference, consider adding the URL = , given that mail to the address listed = will often be automatically lost. (Bonus points for updating that page = to eliminate the decade-old presentations and just leave the news!) --Paul Hoffman From bmanning@karoshi.com Mon Feb 6 14:22:12 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8158821F86E3 for ; Mon, 6 Feb 2012 14:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03zRLmkWt+pF for ; Mon, 6 Feb 2012 14:22:08 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2783721F86F1 for ; Mon, 6 Feb 2012 14:22:06 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q16MK1aB015370; Mon, 6 Feb 2012 22:20:04 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q16MJvrA015369; Mon, 6 Feb 2012 22:19:57 GMT Date: Mon, 6 Feb 2012 22:19:56 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Message-ID: <20120206221956.GB15278@vacation.karoshi.com.> References: <20120206191256.GA14871@vacation.karoshi.com.> <1F781ED0-0198-4771-9ECA-D5785850C8CD@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F781ED0-0198-4771-9ECA-D5785850C8CD@vpnc.org> User-Agent: Mutt/1.4.1i Cc: dnsop@ietf.org, bmanning@vacation.karoshi.com, rssac@icann.org Subject: Re: [DNSOP] Comments on draft-rssac-dnsop-rfc2870bis-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 22:22:12 -0000 Hello Paul. First off, this is an RSSAC document so it is not clear why you think someone from the root opserator community should do the copy editing. > The paragraph at the end of section 1 (the "isn't really 2119 language" text) is quite cute and will cause you a world of pain and delay. You have de-capped everything, so remove the paragraph. (Unless you're just trying to make John Klensin even grumpier, which is also quite cute but will also cause you a world of pain and delay). IETF tools complains when that text is removed. Will see if there is a clean way around it. > The intro to section 3 says: > The servers need both physical and protocol security as well as > unambiguous authentication of their responses. Physical security focuses > on the machines and their locations, Protocol security and response > authentication are covered by Internet Protocol standards. > However, there are three subsections, the middle being "network security". Further, much of the protocol security is covered by by transport layer security, not IP security. Proposed new wording: > The servers need to be protected by physical and protocol security for > their administration and communications. They also need to be protected > by network security to reduce their vulnerability to attack. Physical > security focuses on the machines and their locations, network security > focuses on the way that the root servers are connected to the Internet, > and protocol security focuses on administrative communication with the > servers as well as integrity protection for the messages from the > servers to the public. Going back to the document to see which parts you quoted and which were your suggested changes. Will fold in the intent of your suggestion. > The text in 3.2.5 doesn't make sense. NTP can't be on the list if the operator is expected to get time updates "in as secure manner as possible". A proposed rewording would be to just remove that phrase because you describe what operationally is needed to use NTP in a non-crypto secure manner. or ... update the text to describe secure NTP - which is not uniformly used. or the use of local "clocks". > For the author reference, consider adding the URL , given that mail to the address listed will often be automatically lost. (Bonus points for updating that page to eliminate the decade-old presentations and just leave the news!) again, this is an RSSAC work product, not just root-operators. and the URL listed is not uniformly used by all operators. so will likely just leave it as RSSAC. That said, if URLs are accepted in author references (and I have to admit not seeing that used previously) then a link to the RSSAC page might be in order. > > --Paul Hoffman > From paul.hoffman@vpnc.org Mon Feb 6 14:52:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A747521F862A for ; Mon, 6 Feb 2012 14:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgIZ2oKARFKV for ; Mon, 6 Feb 2012 14:52:41 -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 E632221F8622 for ; Mon, 6 Feb 2012 14:52:40 -0800 (PST) Received: from [192.168.11.124] ([12.239.109.3]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q16MqDqH041864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Feb 2012 15:52:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120206221956.GB15278@vacation.karoshi.com.> Date: Mon, 6 Feb 2012 17:52:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <73A22CEC-28AD-417A-9912-9DD3D3CC2E34@vpnc.org> References: <20120206191256.GA14871@vacation.karoshi.com.> <1F781ED0-0198-4771-9ECA-D5785850C8CD@vpnc.org> <20120206221956.GB15278@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1251.1) Cc: rssac@icann.org, dnsop@ietf.org Subject: Re: [DNSOP] Comments on draft-rssac-dnsop-rfc2870bis-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 22:52:41 -0000 On Feb 6, 2012, at 5:19 PM, bmanning@vacation.karoshi.com wrote: > First off, this is an RSSAC document so it is not clear why you think = someone from the root > opserator community should do the copy editing. There is a large/complete overlap between the RSSAC and the root server = operators. Many of the companies that operate root servers have staff = doing many things, such as technical writing. Some have copy editors. = The fact that ICANN has not done a copy edit pass on the document after = five rounds says that maybe you should look to others. Waiting for ICANN = to do this might be futile, given that it doesn't involve making policy. >> The paragraph at the end of section 1 (the "isn't really 2119 = language" text) is quite cute and will cause you a world of pain and = delay. You have de-capped everything, so remove the paragraph. (Unless = you're just trying to make John Klensin even grumpier, which is also = quite cute but will also cause you a world of pain and delay). >=20 > IETF tools complains when that text is removed. Will see if there is = a clean way around it. The tool might complain, but it should not prevent submission. You are = now not using 2119 language, so you shouldn't need to put in the = not-really-2119 preamble. >> The text in 3.2.5 doesn't make sense. NTP can't be on the list if the = operator is expected to get time updates "in as secure manner as = possible". A proposed rewording would be to just remove that phrase = because you describe what operationally is needed to use NTP in a = non-crypto secure manner. >=20 > or ... update the text to describe secure NTP - which is not = uniformly used. > or the use of local "clocks". You can't say "can use NTP" and "in as secure manner as possible": they = don't match. >> For the author reference, consider adding the URL = , given that mail to the address listed = will often be automatically lost. (Bonus points for updating that page = to eliminate the decade-old presentations and just leave the news!) >=20 > again, this is an RSSAC work product, not just root-operators. = and the URL > listed is not uniformly used by all operators. so will likely = just leave > it as RSSAC. That said, if URLs are accepted in author = references (and I have > to admit not seeing that used previously) then a link to the = RSSAC page might > be in order. You can use URLs in author references. However, the RSSAC web page is = mostly worthless unless you like bureaucratic history. The = root-servers.org page is useful. If you don't want to provide a useful = URL, that's fine. --Paul Hoffman From bmanning@karoshi.com Mon Feb 6 21:16:20 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD07E11E80EC for ; Mon, 6 Feb 2012 21:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.33 X-Spam-Level: X-Spam-Status: No, score=-6.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i7ud+dcoy5P for ; Mon, 6 Feb 2012 21:16:16 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id B7CF311E80E0 for ; Mon, 6 Feb 2012 21:16:15 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q175EiaB016690; Tue, 7 Feb 2012 05:14:50 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q175EdOV016689; Tue, 7 Feb 2012 05:14:39 GMT Date: Tue, 7 Feb 2012 05:14:38 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Message-ID: <20120207051438.GB16640@vacation.karoshi.com.> References: <20120206191256.GA14871@vacation.karoshi.com.> <1F781ED0-0198-4771-9ECA-D5785850C8CD@vpnc.org> <20120206221956.GB15278@vacation.karoshi.com.> <73A22CEC-28AD-417A-9912-9DD3D3CC2E34@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73A22CEC-28AD-417A-9912-9DD3D3CC2E34@vpnc.org> User-Agent: Mutt/1.4.1i Cc: dnsop@ietf.org, bmanning@vacation.karoshi.com, rssac@icann.org Subject: Re: [DNSOP] Comments on draft-rssac-dnsop-rfc2870bis-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 05:16:20 -0000 On Mon, Feb 06, 2012 at 05:52:12PM -0500, Paul Hoffman wrote: > On Feb 6, 2012, at 5:19 PM, bmanning@vacation.karoshi.com wrote: > > > First off, this is an RSSAC document so it is not clear why you think someone from the root > > opserator community should do the copy editing. > > There is a large/complete overlap between the RSSAC and the root server operators. Many of the companies that operate root servers have staff doing many things, such as technical writing. Some have copy editors. The fact that ICANN has not done a copy edit pass on the document after five rounds says that maybe you should look to others. Waiting for ICANN to do this might be futile, given that it doesn't involve making policy. You are mistaken. while all root server operators are part of RSSAC, RSSAC is a much larger community with membership from all the RIRs, ISOC, Research Facilities, and Governments. I'll note that ISOC, through the IAB has a presence on RSSAC. Perhaps we could have ISOC provide copy editing? > >> The text in 3.2.5 doesn't make sense. NTP can't be on the list if the operator is expected to get time updates "in as secure manner as possible". A proposed rewording would be to just remove that phrase because you describe what operationally is needed to use NTP in a non-crypto secure manner. > > > > or ... update the text to describe secure NTP - which is not uniformly used. > > or the use of local "clocks". > > You can't say "can use NTP" and "in as secure manner as possible": they don't match. then you recommend we strike SNTP from the document? There are ways to harden and NTP only system without going completely to a secured NTP (SNTP) system. And from my experience, if one takes proper precautions and prudent design choices one can deploy a resistant NTP strucuture without the crypto overhead on the SNTP datagrams or channels. So I am confident that we can, in fact, say with a straight face say that servers should use NTP or SNTP in as secure a mnner as practical/possible. Its being done. > You can use URLs in author references. However, the RSSAC web page is mostly worthless unless you like bureaucratic history. The root-servers.org page is useful. If you don't want to provide a useful URL, that's fine. again, RSSAC is not just the root operators. If you want us to include a tangentially related URL, we could just as easily use www.ietf.org as www.root-servers.org in as far as the RSSAC represents either of those groups. > --Paul Hoffman > From bortzmeyer@nic.fr Thu Feb 9 05:04:45 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1967521F86B7; Thu, 9 Feb 2012 05:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-mJSEo5svPV; Thu, 9 Feb 2012 05:04:44 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4AB21F864E; Thu, 9 Feb 2012 05:04:44 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 5B6D01C00E1; Thu, 9 Feb 2012 14:04:43 +0100 (CET) Received: by mx2.nic.fr (Postfix, from userid 500) id 46B751C00F5; Thu, 9 Feb 2012 14:04:43 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [IPv6:2001:67c:2218:9::4:163]) by mx2.nic.fr (Postfix) with ESMTP id 3329E1C00E1; Thu, 9 Feb 2012 14:04:43 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay2.nic.fr (Postfix) with ESMTP id 16DC8B38370; Thu, 9 Feb 2012 14:04:41 +0100 (CET) Date: Thu, 9 Feb 2012 14:04:43 +0100 From: Stephane Bortzmeyer To: IAB Chair Message-ID: <20120209130443.GA28346@nic.fr> References: <053c01cce6ad$7f29fa90$7d7defb0$@iab.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <053c01cce6ad$7f29fa90$7d7defb0$@iab.org> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.1.0-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: No, tests=bogofilter, spamicity=0.000001, version=1.1.5 X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2012.2.9.125118 X-PerlMx-Spam: Gauge=IIIIIII, Probability=8%, Report='MULTIPLE_RCPTS 0.1, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0' Cc: dnsop@ietf.org, ietf@ietf.org Subject: Re: [DNSOP] IAB statement: "The interpretation of rules in the ICANN gTLD Applicant Guidebook" 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, 09 Feb 2012 13:04:45 -0000 On Wed, Feb 08, 2012 at 02:03:31PM -0800, IAB Chair wrote a message of 116 lines which said: > The IAB has issued a statement entitled "The interpretation of rules > in the ICANN gTLD Applicant Guidebook". This is a very bad statement. When work started on document draft-liman-tld-names, there were no IDN TLD in the root and some expressed concern that the digits (in their Punycode encoding) could create a problem. Also, draft-liman-tld-names was disputed because it created new rules (explicitely forbidding all-digits TLDs) without a good reason. The document has fallen in disinterest and I'm quite surprised to see it resurfacing now: we have IDN TLDs in the root for a long time and the sky has not fallen. I hope that ICANN will ignore this statement. From joe.abley@icann.org Thu Feb 9 13:17:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA32021E804B for ; Thu, 9 Feb 2012 13:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzZkSnSFbp8i for ; Thu, 9 Feb 2012 13:17:54 -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 0819D21E8036 for ; Thu, 9 Feb 2012 13:17:54 -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; Thu, 9 Feb 2012 13:17:53 -0800 From: Joe Abley To: " " Date: Thu, 9 Feb 2012 13:17:52 -0800 Thread-Topic: [rssac] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] Thread-Index: AczncEjVqUnJrqZxSHOtg/dyMSPvuQ== Message-ID: <41C93A31-8D64-4220-9CC9-3F7F47E28877@icann.org> References: <20120206191256.GA14871@vacation.karoshi.com.> In-Reply-To: <20120206191256.GA14871@vacation.karoshi.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: "rssac@icann.org" , "dnsop@ietf.org" Subject: Re: [DNSOP] [rssac] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 21:17:55 -0000 Hi Bill, On 2012-02-06, at 14:12, wrote: > Thanks to Warren, Ed, John D., David C. and Kato-san for their comments/c= orrections. > Any more?=20 I see you added some text based on our conversation in sunny Christchurch, = thanks for that. As promised, here's a summary of that conversation for the= list(s). I think the document requires some substantial copy-editing. I've avoided p= roducing a list of spelling and grammar nits, since I think the clean-up wo= uld be easier to do as a single pass through rather than by correcting indi= vidual words and sentences. Substantive comments relating only to content f= ollow. 1. Despite the definition of "server" in section 1, there are numerous exam= ples of text in following sections that use the word server in its original= 2870 sense (i.e. with an implication that we're talking about individual, = discrete servers) despite the fact that architecture has moved on in the re= al root server system since then. I recommend re-casting the whole document= to talk about the DNS service provided by root server operators as a servi= ce, and focussing on the way that service is delivered rather than how "ser= vers" are operated. 2. I think this document should aim to provide recommendations and/or docum= ent best current practice, rather than declaring that it provides requireme= nts. There is little or no contractual relationship between the organisatio= ns that manage the root zone and the root server operators that serve it, a= nd setting requirements that by definition have no teeth seems out of sync = with reality. Providing recommendations that root server operators can conf= irm that they follow seems entirely reasonable, however. Related, I don't u= nderstand why there is 2119 normative language in this document. 3. In many places I find the "requirements" far too detailed; in my view th= ey impose specific architectural and operational choices on root server ope= rators when diversity in the root server system is desirable, and more obvi= ously achieved by a diversity of such choices. I think this document should= limit itself to carefully specifying the service being provided, and the d= esired performance characteristics of that service. For example, specifying that TSIG be used to secure zone transfers is ill-a= dvised, I think (I know that TSIG is used today). Specifying rather that ne= w root zone serials be authenticated and made available promptly (and defin= ing what promptly means) across each deployed root server service seems bet= ter. The former is an implementation detail of the service as a whole; the = latter restricts the concern to what we actually care about, that changes p= ropagate swiftly and that unauthenticated updates never make it to the quer= y-answering edge. I would like to see this document specify key performance indicators and sp= ecify corresponding ranges of values that represent adequate service. I wou= ld also like to see a recommendation that root server operators commit to p= ublish data corresponding to those KPIs, so that the community can gain con= fidence that the root server system as a whole is performing adequately. I = guess I'm talking about something like a Service Level Agreement (although = perhaps Service Level Commitment would be better language, given the lack o= f contractual relationships). 4. When it comes to security, different security policies would seem to fit= different deployment approaches. I think it's better to specify that indiv= idual root server operators publish their security policy, and that this do= cument should outline what that security policy should contain. I don't thi= nk it's useful to attempt to define a security policy that fits all deploye= d infrastructure. In summary, I think the document should be substantially reorganised. This = makes it difficult to provide a meaningful line-by-line critique. However, = I am very happy to put my money where my mouth is and copy-edit/reorganise = along the lines I'm thinking if that seems like a useful way to explain mys= elf. I don't think the -04 draft, even with copy-editing, is useful to publ= ish as-is. Joe= From bmanning@karoshi.com Fri Feb 10 22:14:20 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB31D21F8603 for ; Fri, 10 Feb 2012 22:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Wpb383Mteo2 for ; Fri, 10 Feb 2012 22:14:16 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id B3C0721F85FD for ; Fri, 10 Feb 2012 22:14:05 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q19LdOaB007896; Thu, 9 Feb 2012 21:39:25 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q19LdNF4007895; Thu, 9 Feb 2012 21:39:23 GMT Date: Thu, 9 Feb 2012 21:39:17 +0000 From: bmanning@vacation.karoshi.com To: Joe Abley Message-ID: <20120209213917.GA7849@vacation.karoshi.com.> References: <20120206191256.GA14871@vacation.karoshi.com.> <41C93A31-8D64-4220-9CC9-3F7F47E28877@icann.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41C93A31-8D64-4220-9CC9-3F7F47E28877@icann.org> User-Agent: Mutt/1.4.1i Cc: "dnsop@ietf.org" , " " , "rssac@icann.org" Subject: Re: [DNSOP] [rssac] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 06:14:20 -0000 On Thu, Feb 09, 2012 at 01:17:52PM -0800, Joe Abley wrote: > Hi Bill, > > On 2012-02-06, at 14:12, wrote: > > > Thanks to Warren, Ed, John D., David C. and Kato-san for their comments/corrections. > > Any more? > > I see you added some text based on our conversation in sunny Christchurch, thanks for that. As promised, here's a summary of that conversation for the list(s). > [elided] > > In summary, I think the document should be substantially reorganised. This makes it difficult to provide a meaningful line-by-line critique. However, I am very happy to put my money where my mouth is and copy-edit/reorganise along the lines I'm thinking if that seems like a useful way to explain myself. I don't think the -04 draft, even with copy-editing, is useful to publish as-is. > > > Joe I had a similar conversation with Terry (check the thread archives). Effectively what you propose is a "clean slate" instead of building off existing work and actual practice. I think that is a fabulou idea but it has a couple of caveats: ) it will take considerable time to reach consensus within the operator community, let alone the large community. ) it will not reflect actual practice but an ideal to be achieved. I think that starting work on such a draft is a great idea -BUT- in the mean time do not let "perfect" get in the way of "good enough". I beleive Terry agreed with that line of thnking. Of the existing Operators, A, B, E, G, H, J, L, and M have made positive comments and worked on upgrading this base text provided by one of the Operators. Is your opinion / argument strong enough to stop work on this draft? That said, I'd love to see a revamped version, if youhave the time to copy-edit/reorgnize the document. /bill From paul.hoffman@vpnc.org Sat Feb 11 09:25:53 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8960A21F850F for ; Sat, 11 Feb 2012 09:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNtgePzXBtTq for ; Sat, 11 Feb 2012 09:25: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 273EF21F8501 for ; Sat, 11 Feb 2012 09:25:53 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1BHPTdQ010352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Feb 2012 10:25:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120209213917.GA7849@vacation.karoshi.com.> Date: Sat, 11 Feb 2012 09:25:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6714BA4B-00A3-4E5F-94FB-F2F9A6C0144E@vpnc.org> References: <20120206191256.GA14871@vacation.karoshi.com.> <41C93A31-8D64-4220-9CC9-3F7F47E28877@icann.org> <20120209213917.GA7849@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org" , Joe Abley , "rssac@icann.org" Subject: Re: [DNSOP] [rssac] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 17:25:53 -0000 On Feb 9, 2012, at 1:39 PM, bmanning@vacation.karoshi.com wrote: > I think that starting work on such a draft is a great idea -BUT- = in the mean time > do not let "perfect" get in the way of "good enough". Just to be clear: a good handful of people, me included, have said that = the wording in the current doc is not good enough, or only good enough = if you squint hard. It is clearly much worse than the document that this = is supposed to replace. --Paul Hoffman From drc@virtualized.org Sat Feb 11 11:52:48 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DCB21F848F for ; Sat, 11 Feb 2012 11:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4ugMJ+9teKx for ; Sat, 11 Feb 2012 11:52:47 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2821F847B for ; Sat, 11 Feb 2012 11:52:47 -0800 (PST) Received: from [10.0.1.3] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 065141705A; Sat, 11 Feb 2012 19:52:45 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <6714BA4B-00A3-4E5F-94FB-F2F9A6C0144E@vpnc.org> Date: Sat, 11 Feb 2012 11:52:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <928DD46D-BA37-4C86-9F78-DA958554C65D@virtualized.org> References: <20120206191256.GA14871@vacation.karoshi.com.> <41C93A31-8D64-4220-9CC9-3F7F47E28877@icann.org> <20120209213917.GA7849@vacation.karoshi.com.> <6714BA4B-00A3-4E5F-94FB-F2F9A6C0144E@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) Cc: IETF DNSOP WG , Root Server System Advisory Committee Subject: Re: [DNSOP] [rssac] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 19:52:48 -0000 On Feb 11, 2012, at 9:25 AM, Paul Hoffman wrote: > On Feb 9, 2012, at 1:39 PM, bmanning@vacation.karoshi.com wrote: >> I think that starting work on such a draft is a great idea -BUT- = in the mean time >> do not let "perfect" get in the way of "good enough". >=20 > Just to be clear: a good handful of people, me included, have said = that the wording in the current doc is not good enough, or only good = enough if you squint hard. It is clearly much worse than the document = that this is supposed to replace. To be honest, I'm unclear as to the point of the document. Could = someone clarify? What exactly is revising 2870 supposed to do? Thanks, -drc From paul@redbarn.org Sat Feb 11 18:59:52 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA09821F8588 for ; Sat, 11 Feb 2012 18:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sesh2A2SKAs7 for ; Sat, 11 Feb 2012 18:59:35 -0800 (PST) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A58021F8549 for ; Sat, 11 Feb 2012 18:59:35 -0800 (PST) Received: from [IPv6:2001:559:8000:cb:39e6:757e:b2f:a6d1] (unknown [IPv6:2001:559:8000:cb:39e6:757e:b2f:a6d1]) by ss.vix.com (Postfix) with ESMTP id D4E52EDAE6; Sun, 12 Feb 2012 02:59:33 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F372B15.6050604@redbarn.org> Date: Sun, 12 Feb 2012 02:59:33 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 References: <20120206191256.GA14871@vacation.karoshi.com.> <41C93A31-8D64-4220-9CC9-3F7F47E28877@icann.org> <20120209213917.GA7849@vacation.karoshi.com.> <6714BA4B-00A3-4E5F-94FB-F2F9A6C0144E@vpnc.org> In-Reply-To: <6714BA4B-00A3-4E5F-94FB-F2F9A6C0144E@vpnc.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bmanning@vacation.karoshi.com, "rssac@icann.org" , "dnsop@ietf.org" Subject: Re: [DNSOP] [rssac] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 02:59:52 -0000 On 2/11/2012 5:25 PM, Paul Hoffman wrote: > On Feb 9, 2012, at 1:39 PM, bmanning@vacation.karoshi.com wrote: > >> I think that starting work on such a draft is a great idea -BUT- in the mean time >> do not let "perfect" get in the way of "good enough". > Just to be clear: a good handful of people, me included, have said that the wording in the current doc is not good enough, or only good enough if you squint hard. It is clearly much worse than the document that this is supposed to replace. wearing my rfc 2010 co-author hat: +1. paul From bortzmeyer@nic.fr Mon Feb 13 00:33:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1F621F8717 for ; Mon, 13 Feb 2012 00:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FggzjBrE4-Aa for ; Mon, 13 Feb 2012 00:33:07 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id 47A5121F8711 for ; Mon, 13 Feb 2012 00:33:06 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 9D7CA1C001A; Mon, 13 Feb 2012 09:33:05 +0100 (CET) Received: by mx2.nic.fr (Postfix, from userid 500) id 84E961C0029; Mon, 13 Feb 2012 09:33:05 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [IPv6:2001:67c:2218:9::4:163]) by mx2.nic.fr (Postfix) with ESMTP id 652071C001A; Mon, 13 Feb 2012 09:33:05 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay2.nic.fr (Postfix) with ESMTP id 1D10FB381C4; Mon, 13 Feb 2012 09:33:03 +0100 (CET) Date: Mon, 13 Feb 2012 09:33:05 +0100 From: Stephane Bortzmeyer To: bmanning@vacation.karoshi.com Message-ID: <20120213083305.GA1760@nic.fr> References: <20120206191256.GA14871@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120206191256.GA14871@vacation.karoshi.com.> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.1.0-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.1.5 X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2012.2.13.82414 X-PerlMx-Spam: Gauge=IIIIIII, Probability=8%, Report='MULTIPLE_RCPTS 0.1, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1100_1199 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CP_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0' Cc: rssac@icann.org, dnsop@ietf.org Subject: Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 08:33:08 -0000 On Mon, Feb 06, 2012 at 07:12:56PM +0000, bmanning@vacation.karoshi.com wrote a message of 49 lines which said: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Root Name Server Operational Requirements > Author(s) : Root Server System Advisory Committee > Filename : draft-rssac-dnsop-rfc2870bis-04.txt Section 3.2.1 : I do not understand why you need synced time for DNSSEC. The root name servers do not generate signatures. Section 3.2.1 : Several root name servers, such as B, reply to ICMP echo requests, which I think is a good thing, but it seems disallowed in your document. Section 4.2 : This advice directly contradicts RFC 6382. Do you plan to reclassify it as Historic? Section 5.1 : "Announcement of planned outages also keeps other operators from investigated a scheduled maintenance window." My english parser broke here. Should I upgrade it or should you rewrite the sentence? (For the record, I agree with most of Joe Abley's remarks on high-level issues with this document.) From internet-drafts@ietf.org Tue Feb 14 02:46:28 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C8D21F87AB; Tue, 14 Feb 2012 02:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya0560j-Cqq9; Tue, 14 Feb 2012 02:46:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668A121F8798; Tue, 14 Feb 2012 02:46:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214104628.24649.69250.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 02:46:28 -0800 Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-09.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, 14 Feb 2012 10:46:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Domain Name System Operations Working= Group of the IETF. Title : DNSSEC Operational Practices, Version 2 Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename : draft-ietf-dnsop-rfc4641bis-09.txt Pages : 70 Date : 2012-02-14 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-09.txt From matthijs@nlnetlabs.nl Tue Feb 14 02:50:17 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4499A21F87AE for ; Tue, 14 Feb 2012 02:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmpGnA8KnBu3 for ; Tue, 14 Feb 2012 02:50:15 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EDF21F87B5 for ; Tue, 14 Feb 2012 02:50:15 -0800 (PST) Received: from [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8] (zoidberg.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q1EAoCEv023893 for ; Tue, 14 Feb 2012 11:50:13 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1329216614; bh=jOkfNdH4PTnduFedhexfQ75Q/HdynxcOOn72XKaiJak=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=t1MyNAs0rEv9+x8AHu3prDUKb9eiNo8vw3bfCe7/PyhN5F9mzZIbTBfZJaDNWN/OJ EIvnugH52NpIboUxjm1CtsdWTH+10QpGvNepMZv7pu8qZGd5TODUErB5SC0cvDhUuO 6Gcq3bvD5v3vD/LBnYLLduKUPtKN5yNZjjVia2Ao= Message-ID: <4F3A3C64.4050408@nlnetlabs.nl> Date: Tue, 14 Feb 2012 11:50:12 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120214104628.24649.69250.idtracker@ietfa.amsl.com> In-Reply-To: <20120214104628.24649.69250.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 14 Feb 2012 11:50:13 +0100 (CET) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-09.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, 14 Feb 2012 10:50:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi WG, Review from Stephen and Peter resulted in a new version of DNSSEC Operational Practices, Version 2. Besides editorial changes, the most important changes are: * The third school of thought for rolling a KSK that is not a trust anchor (in section 3.2.1), that it should only be done when it is known or strongly suspected that the key can be or has been compromised, is extended with: or when a new algorithm or key storage is required. * In section 4.1.1.2 on Double Signature Zone Signing Key Rollover, a recommendation on the duration on the "new DNSKEY" phase was removed, it was being too conservative. * Section 4.3.5.1. on Cooperating DNS operators adds clarifying text for Figure 9: Rollover for cooperating operators. * An additional, clarifying diagram for the alternative approach on rollover for cooperating operators is given in Figure 14, Appendix D. Best regards, Matthijs On 02/14/2012 11:46 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Domain Name System > Operations Working Group of the IETF. > > Title : DNSSEC Operational Practices, Version 2 Author(s) > : Olaf M. Kolkman W. (Matthijs) Mekking Filename : > draft-ietf-dnsop-rfc4641bis-09.txt Pages : 70 Date > : 2012-02-14 > > This document describes a set of practices for operating the DNS > with security extensions (DNSSEC). The target audience is zone > administrators deploying DNSSEC. > > The document discusses operational aspects of using keys and > signatures in the DNS. It discusses issues of key generation, key > storage, signature generation, key rollover, and related policies. > > This document obsoletes RFC 4641 as it covers more operational > ground and gives more up-to-date requirements with respect to key > sizes and the DNSSEC operations. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-09.txt > > _______________________________________________ DNSOP mailing > list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPOjxkAAoJEA8yVCPsQCW5AH0H/AyvPq0j8IZ2mgbh7B03I9ES jn75pcNuWfP1Cmk62BvuZKO1ij4geDYS6PlX0Lyyk+uJpkBn/ataRABfm0BnpOyp ermVMEHyZs7n7bld6N1GuUXKRVADFT+jxZ5ZtovUu+2Ft6+RgERNsC+3B4g0NBfl UaawuOo3hZ29JYu0aofIk4oI1j2ARhiJ39j4MN4/6iYSEygdH/qW5hirg2MdnImR lhkNVA+uynhb0ZhLEop6R6yG8DsIilGHlg6nQ8yk/dJfvkAtsKrcQXXJxBH6Sh7N /8SieCLLlXnCym46r41O/tKkT/JVWk146CPSkX7n/tbRGELEOJF4xzzy5B4GS8U= =m7XX -----END PGP SIGNATURE----- From Ed.Lewis@neustar.biz Tue Feb 14 06:17:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B866821F8767 for ; Tue, 14 Feb 2012 06:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.238 X-Spam-Level: X-Spam-Status: No, score=-106.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNLxQH8-S2aJ for ; Tue, 14 Feb 2012 06:17:07 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1773721F875E for ; Tue, 14 Feb 2012 06:17:06 -0800 (PST) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q1EEH5sl019850; Tue, 14 Feb 2012 09:17:05 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.246] by Work-Laptop-2.local (PGP Universal service); Tue, 14 Feb 2012 09:17:05 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 14 Feb 2012 09:17:05 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120209213917.GA7849@vacation.karoshi.com.> References: <20120206191256.GA14871@vacation.karoshi.com.> <41C93A31-8D64-4220-9CC9-3F7F47E28877@icann.org> <20120209213917.GA7849@vacation.karoshi.com.> Date: Tue, 14 Feb 2012 09:17:02 -0500 To: "dnsop@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 14:17:07 -0000 At 21:39 +0000 2/9/12, wrote: >I think that starting work on such a draft is a great idea -BUT- in the >mean time do not let "perfect" get in the way of "good enough". I beleive >Terry agreed with that line of thnking. Of the existing Operators, A, B, >E, G, H, J, L, and M have made positive comments and worked on upgrading this >base text provided by one of the Operators. Is your opinion / argument strong >enough to stop work on this draft? As David says, why is this document being republished? Is there some deadline? This is a document not code, and not even a first document but a revision. If a revision is not "perfect" at the time it is published, it's pretty much not worth publishing. Especially an update document - we already have an RFC on this, why update it with another RFC that inaccurately describes the state of the world. My concern is that future RFPs and contracts will cite this as a document to comply with. That is when it becomes my pain, even if the job at hand is not operating a root server. I especially like Joe's point #3. >That said, I'd love to see a revamped version, if you have the time to >copy-edit/reorgnize the document. I do not recommend publishing the document as is. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From acooper@cdt.org Tue Feb 14 07:23:28 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C39421F85B6 for ; Tue, 14 Feb 2012 07:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR6Se7cWt+dt for ; Tue, 14 Feb 2012 07:23:27 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2B21F8738 for ; Tue, 14 Feb 2012 07:23:27 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for dnsop@ietf.org; Tue, 14 Feb 2012 10:23:24 -0500 From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Feb 2012 10:23:23 -0500 References: <8A9F06B9-5486-4D63-99A8-B5CA5C278553@cdt.org> To: dnsop@ietf.org Message-Id: <1DC8228A-BAA3-452F-8167-D39E2AF2A9E3@cdt.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [DNSOP] Fwd: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02 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, 14 Feb 2012 15:23:28 -0000 Folks on this list might be interested in this draft that is in WGLC in = GEOPRIV. Please send comments to the GEOPRIV list if you have them. Thanks, Alissa Begin forwarded message: > From: Alissa Cooper > Date: February 14, 2012 10:20:28 AM EST > To: GEOPRIV WG > Subject: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02 >=20 > This is a GEOPRIV Working Group Last Call for comments on > draft-ietf-geopriv-res-gw-lis-discovery-02 >=20 > Please send your comments to the GEOPRIV list by 27 February 2012. As = always, please remember to send a note in if you've read the document = and have no other comments other than "its ready to go" - we need those = as much as we need "I found a problem." > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv >=20 From bortzmeyer@nic.fr Tue Feb 14 08:34:48 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3014D21F86EB for ; Tue, 14 Feb 2012 08:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEm1rQEtvdfj for ; Tue, 14 Feb 2012 08:34:47 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id A1A9521F86E5 for ; Tue, 14 Feb 2012 08:34:47 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 719101C006A; Tue, 14 Feb 2012 17:34:46 +0100 (CET) Received: by mx2.nic.fr (Postfix, from userid 500) id 5F9AE1C007E; Tue, 14 Feb 2012 17:34:46 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [IPv6:2001:67c:2218:9::4:163]) by mx2.nic.fr (Postfix) with ESMTP id 535771C006A; Tue, 14 Feb 2012 17:34:46 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay2.nic.fr (Postfix) with ESMTP id E5966B38061; Tue, 14 Feb 2012 17:34:43 +0100 (CET) Date: Tue, 14 Feb 2012 17:34:46 +0100 From: Stephane Bortzmeyer To: bmanning@vacation.karoshi.com Message-ID: <20120214163446.GA10162@nic.fr> References: <20120206191256.GA14871@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120206191256.GA14871@vacation.karoshi.com.> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.1.0-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.1.5 X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2012.2.14.162415 X-PerlMx-Spam: Gauge=IIIIIII, Probability=8%, Report='MULTIPLE_RCPTS 0.1, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_500_599 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0' Cc: rssac@icann.org, dnsop@ietf.org Subject: Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:34:48 -0000 On Mon, Feb 06, 2012 at 07:12:56PM +0000, bmanning@vacation.karoshi.com wrote a message of 49 lines which said: > Any more? One governance question. As far as I know (I am not a root name server operator), several of the root name servers already comply with the (very strong) requirments of this document. But not all. If the document is published, what will happen of them? In other words, what is the goal of the document? Exercice some pressure or more? From jim@rfc1035.com Tue Feb 14 08:56:11 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C3021F8793 for ; Tue, 14 Feb 2012 08:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nKq5LHiXeOb for ; Tue, 14 Feb 2012 08:56:10 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id C617921F8790 for ; Tue, 14 Feb 2012 08:56:09 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 41DBACBC451; Tue, 14 Feb 2012 16:56:08 +0000 (GMT) Message-Id: <9C1BBBFD-D3F7-4A66-ABE4-A25839D657BA@rfc1035.com> From: Jim Reid To: Stephane Bortzmeyer In-Reply-To: <20120214163446.GA10162@nic.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 14 Feb 2012 16:56:07 +0000 References: <20120206191256.GA14871@vacation.karoshi.com.> <20120214163446.GA10162@nic.fr> X-Mailer: Apple Mail (2.936) Cc: dnsop@ietf.org, bmanning@vacation.karoshi.com, rssac@icann.org Subject: Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:56:11 -0000 On 14 Feb 2012, at 16:34, Stephane Bortzmeyer wrote: > One governance question. As far as I know (I am not a root name server > operator), several of the root name servers already comply with the > (very strong) requirments of this document. But not all. If the > document is published, what will happen of them? We report them to the Internet Police's Root Server Department. :-) To be less flippant, I would assume that someone who has a concern about root server operations will ask each RSO if their server meets or exceeds the requirements in RFC2870bis and if the answer is no, they'll ask why not. > In other words, what is the goal of the document? Exercice some > pressure or more? IMO RFC2870bis is probably never going to be aligned with what is actually done to run a real root server. Discussion of some of those practices probably won't be in the public domain for a while anyway. That said, it's good to update and revise those guidelines from time to time. IMO the value of this document is to describe the general principles and suggest to others how an "important" DNS server should be operated. For instance, it can (and has) been used in RFPs for DNS service for TLDs. From drc@virtualized.org Tue Feb 14 09:04:30 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B6321E8060 for ; Tue, 14 Feb 2012 09:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPkIrI2UuZjy for ; Tue, 14 Feb 2012 09:04:29 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8C66B21E803C for ; Tue, 14 Feb 2012 09:04:29 -0800 (PST) Received: from [192.168.2.159] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 306CA1705A; Tue, 14 Feb 2012 17:04:19 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Tue, 14 Feb 2012 08:19:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120206191256.GA14871@vacation.karoshi.com.> <41C93A31-8D64-4220-9CC9-3F7F47E28877@icann.org> <20120209213917.GA7849@vacation.karoshi.com.> To: Edward Lewis X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:04:30 -0000 On Feb 14, 2012, at 6:17 AM, Edward Lewis wrote: > At 21:39 +0000 2/9/12, wrote: >> Is your opinion / argument strong enough to stop work on this draft? > As David says, why is this document being republished? =20 A question I'll note has not been answered. > My concern is that future RFPs and contracts will cite this as a = document to comply with. Agreed. A BCP on how best to provide a highly resilient DNS service = would probably be useful. The document in question isn't close. At = best, it feels like a bit of self-congradulatory back-patting for those = root server operators that actually come close to what the document = describes. At worst, it can be seen as an attempt at obfuscation of the = fact that the root server operators (with one notable exception) are = _NOT_ subject to RFPs, contracts, or any other form of enforcement. >> That said, I'd love to see a revamped version, if you have the time = to >> copy-edit/reorgnize the document. > I do not recommend publishing the document as is. +1 Regards, -drc= From drc@virtualized.org Tue Feb 14 09:20:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130EE21F8620 for ; Tue, 14 Feb 2012 09:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU92e+nsYC6Z for ; Tue, 14 Feb 2012 09:20:53 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id BD31021F85F2 for ; Tue, 14 Feb 2012 09:20:50 -0800 (PST) Received: from [192.168.2.159] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 65C891705A; Tue, 14 Feb 2012 17:20:50 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <9C1BBBFD-D3F7-4A66-ABE4-A25839D657BA@rfc1035.com> Date: Tue, 14 Feb 2012 09:20:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6E70E2DF-718B-4AB0-BF20-F4F8C4E28DFD@virtualized.org> References: <20120206191256.GA14871@vacation.karoshi.com.> <20120214163446.GA10162@nic.fr> <9C1BBBFD-D3F7-4A66-ABE4-A25839D657BA@rfc1035.com> To: Jim Reid X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:20:54 -0000 On Feb 14, 2012, at 8:56 AM, Jim Reid wrote: > I would assume that someone who has a concern about root server = operations will ask each RSO if their server meets or exceeds the = requirements in RFC2870bis and if the answer is no, they'll ask why not. And if no acceptable answer is provided? Sorry, rhetorical question: = can't stop myself from kicking the brown stain that used to be a dead = horse. > That said, it's good to update and revise those guidelines from time = to time. IMO the value of this document is to describe the general = principles and suggest to others how an "important" DNS server should be = operated. For instance, it can (and has) been used in RFPs for DNS = service for TLDs. I agree, however I'd think a better approach would be to write a BCP for = "important" DNS servers, not a document that sets up false expectations = or assumptions. Regards, -drc From paul@redbarn.org Tue Feb 14 09:22:13 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D8A21E807E for ; Tue, 14 Feb 2012 09:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYkIXwOKJCuQ for ; Tue, 14 Feb 2012 09:22:08 -0800 (PST) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id CAF3121E8091 for ; Tue, 14 Feb 2012 09:22:05 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id DFECFA1072 for ; Tue, 14 Feb 2012 17:22:02 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from [IPv6:2001:4f8:3:30:f080:5063:adb5:d719] (unknown [IPv6:2001:4f8:3:30:f080:5063:adb5:d719]) by nsa.vix.com (Postfix) with ESMTP id B9841A1068 for ; Tue, 14 Feb 2012 17:22:02 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F3A9839.7050801@redbarn.org> Date: Tue, 14 Feb 2012 17:22:01 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "dnsop@ietf.org" References: <20120206191256.GA14871@vacation.karoshi.com.> <41C93A31-8D64-4220-9CC9-3F7F47E28877@icann.org> <20120209213917.GA7849@vacation.karoshi.com.> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:22:13 -0000 On 2/14/2012 4:19 PM, David Conrad wrote: > ... At worst, it can be seen as an attempt at obfuscation of the fact > that the root server operators (with one notable exception) are _NOT_ > subject to RFPs, contracts, or any other form of enforcement. are you sharing insider knowledge from your time as IANA GM here? i thought that ICANN and VeriSign were both under enforceable contracts with respect to their role as root name server operators. but i've not been an insider and i'm only guessing. inside baseball warning. the agreement signed between ISC and ICANN on january 23 2008 is not "enforceable" in that it does not specify any recourse for either party due to any nonperformance by the other party. see http://www.icann.org/en/announcements/announcement-23jan08.htm for details. paul From paul@redbarn.org Tue Feb 14 09:28:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870EF21E8086 for ; Tue, 14 Feb 2012 09:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDAjcH4WuZJo for ; Tue, 14 Feb 2012 09:28:09 -0800 (PST) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE7F21E807E for ; Tue, 14 Feb 2012 09:28:09 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9748AA1067 for ; Tue, 14 Feb 2012 17:28:08 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from [IPv6:2001:4f8:3:30:f080:5063:adb5:d719] (unknown [IPv6:2001:4f8:3:30:f080:5063:adb5:d719]) by nsa.vix.com (Postfix) with ESMTP id 793A6A1072 for ; Tue, 14 Feb 2012 17:28:08 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F3A99A6.5000604@redbarn.org> Date: Tue, 14 Feb 2012 17:28:06 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "dnsop@ietf.org WG" References: <20120206191256.GA14871@vacation.karoshi.com.> <20120214163446.GA10162@nic.fr> <9C1BBBFD-D3F7-4A66-ABE4-A25839D657BA@rfc1035.com> <6E70E2DF-718B-4AB0-BF20-F4F8C4E28DFD@virtualized.org> In-Reply-To: <6E70E2DF-718B-4AB0-BF20-F4F8C4E28DFD@virtualized.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:28:09 -0000 On 2/14/2012 5:20 PM, David Conrad wrote: > ... > I agree, however I'd think a better approach would be to write a BCP for "important" DNS servers, not a document that sets up false expectations or assumptions. +1. there are a lot of important non-root dns servers, and the collected wisdom of all of there operators would be a good thing to gather and peer-review and publish. From drc@virtualized.org Tue Feb 14 09:30:59 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB6921E8092 for ; Tue, 14 Feb 2012 09:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqPbM4oL1AAK for ; Tue, 14 Feb 2012 09:30:59 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 70FA921E8091 for ; Tue, 14 Feb 2012 09:30:40 -0800 (PST) Received: from [192.168.2.159] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id F2F7B1705A; Tue, 14 Feb 2012 17:30:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <4F3A9839.7050801@redbarn.org> Date: Tue, 14 Feb 2012 09:30:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <08F87D12-957A-4D97-B9BD-B01A22E766BE@virtualized.org> References: <20120206191256.GA14871@vacation.karoshi.com.> <41C93A31-8D64-4220-9CC9-3F7F47E28877@icann.org> <20120209213917.GA7849@vacation.karoshi.com.> <4F3A9839.7050801@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:31:00 -0000 On Feb 14, 2012, at 9:22 AM, Paul Vixie wrote: > are you sharing insider knowledge from your time as IANA GM here? Nope. > i > thought that ICANN and VeriSign were both under enforceable contracts > with respect to their role as root name server operators. As far as I'm aware (and happy for any of the root operators to correct = me), the only actual contract is between U.S. Dept. of Commerce and = VeriSign for the operation of the "A" (and "J"?) root server(s). That's = part of the irrationality of root service -- it isn't even clear between = whom contracts should be. > inside baseball warning. the agreement signed between ISC and ICANN on > january 23 2008 is not "enforceable" in that it does not specify any > recourse for either party due to any nonperformance by the other = party. Yep. "We acknowledge you exist, you acknowledge we exist, and we might = think about discussing the possibility of perhaps considering doing some = undefined stuff someday in the future. Or maybe not." With that said, = it was a step in the right direction. Not aware of any further steps, = but I haven't been paying attention. Regards, -drc From rbarnes@bbn.com Tue Feb 14 09:12:31 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E0821F85CE; Tue, 14 Feb 2012 09:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.302 X-Spam-Level: X-Spam-Status: No, score=-106.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NrimWZ6X3Pe; Tue, 14 Feb 2012 09:12:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 55A0E21F8596; Tue, 14 Feb 2012 09:12:30 -0800 (PST) Received: from ros-dhcp192-1-51-43.bbn.com ([192.1.51.43]:61524) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RxLvY-000FHo-52; Tue, 14 Feb 2012 12:12:28 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "Richard L. Barnes" Date: Tue, 14 Feb 2012 12:12:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0F6D0103-8837-4AC1-AA94-AD73F80FE09B@bbn.com> References: <8A9F06B9-5486-4D63-99A8-B5CA5C278553@cdt.org> To: dnsop@ietf.org, dnsext@ietf.org X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 14 Feb 2012 10:14:44 -0800 Cc: geopriv-ads@tools.ietf.org, geopriv-chairs@tools.ietf.org, draft-ietf-geopriv-res-gw-lis-discovery@tools.ietf.org Subject: [DNSOP] Fwd: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02 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, 14 Feb 2012 17:12:31 -0000 Dear DNS community, FYI: There is currently a document in GEOPRIV WGLC that makes use of = NAPTR records in the reverse DNS hierarchy, and employs a "tree-walking" = algorithm to locate records at points other than terminal points in the = hierarchy (e.g., /32 and /48 instead of /128).=20 If you have comments on this draft, please reply to geopriv@ietf.org by = 27 Feb 2012. Thanks a lot, --Richard Begin forwarded message: > From: Alissa Cooper > Date: February 14, 2012 10:20:28 AM EST > To: GEOPRIV WG > Subject: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02 >=20 > This is a GEOPRIV Working Group Last Call for comments on > draft-ietf-geopriv-res-gw-lis-discovery-02 >=20 > Please send your comments to the GEOPRIV list by 27 February 2012. As = always, please remember to send a note in if you've read the document = and have no other comments other than "its ready to go" - we need those = as much as we need "I found a problem." > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From jim@rfc1035.com Tue Feb 14 10:16:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B08E21F8786 for ; Tue, 14 Feb 2012 10:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXZTZivONECE for ; Tue, 14 Feb 2012 10:16:04 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id AE65621F862D for ; Tue, 14 Feb 2012 10:16:04 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 96135CBC451; Tue, 14 Feb 2012 18:16:03 +0000 (GMT) Message-Id: <3452B1D5-A8BD-428F-80B3-9E6219E1A10F@rfc1035.com> From: Jim Reid To: David Conrad In-Reply-To: <6E70E2DF-718B-4AB0-BF20-F4F8C4E28DFD@virtualized.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 14 Feb 2012 18:16:03 +0000 References: <20120206191256.GA14871@vacation.karoshi.com.> <20120214163446.GA10162@nic.fr> <9C1BBBFD-D3F7-4A66-ABE4-A25839D657BA@rfc1035.com> <6E70E2DF-718B-4AB0-BF20-F4F8C4E28DFD@virtualized.org> X-Mailer: Apple Mail (2.936) Cc: "dnsop@ietf.org WG" Subject: [DNSOP] BCP for "important" name servers? 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, 14 Feb 2012 18:16:05 -0000 On 14 Feb 2012, at 17:20, David Conrad wrote: >> That said, it's good to update and revise those guidelines from >> time to time. IMO the value of this document is to describe the >> general principles and suggest to others how an "important" DNS >> server should be operated. For instance, it can (and has) been used >> in RFPs for DNS service for TLDs. > > I agree, however I'd think a better approach would be to write a BCP > for "important" DNS servers, not a document that sets up false > expectations or assumptions. +1 Though until that comes along RFC2870(bis) is probably the best hammer- shaped object for that nail-shaped problem. From paul.hoffman@vpnc.org Tue Feb 14 10:33:10 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D985F21E8092 for ; Tue, 14 Feb 2012 10:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTRqOIYtvt1F for ; Tue, 14 Feb 2012 10:33:10 -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 F3AD721E8058 for ; Tue, 14 Feb 2012 10:33:08 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1EIX8P6068449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2012 11:33:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <3452B1D5-A8BD-428F-80B3-9E6219E1A10F@rfc1035.com> Date: Tue, 14 Feb 2012 10:33:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120206191256.GA14871@vacation.karoshi.com.> <20120214163446.GA10162@nic.fr> <9C1BBBFD-D3F7-4A66-ABE4-A25839D657BA@rfc1035.com> <6E70E2DF-718B-4AB0-BF20-F4F8C4E28DFD@virtualized.org> <3452B1D5-A8BD-428F-80B3-9E6219E1A10F@rfc1035.com> To: Jim Reid X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] BCP for "important" name servers? 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, 14 Feb 2012 18:33:11 -0000 On Feb 14, 2012, at 10:16 AM, Jim Reid wrote: > On 14 Feb 2012, at 17:20, David Conrad wrote: >=20 >>> That said, it's good to update and revise those guidelines from time = to time. IMO the value of this document is to describe the general = principles and suggest to others how an "important" DNS server should be = operated. For instance, it can (and has) been used in RFPs for DNS = service for TLDs. >>=20 >> I agree, however I'd think a better approach would be to write a BCP = for "important" DNS servers, not a document that sets up false = expectations or assumptions. >=20 > +1 >=20 > Though until that comes along RFC2870(bis) is probably the best = hammer-shaped object for that nail-shaped problem. A few people have asked, but we haven't gotten any real answer, on what = the nail-shaped problem is. --Paul Hoffman From tglassey@certichron.com Thu Feb 16 04:30:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE3521F87DF; Thu, 16 Feb 2012 04:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMsInlqKnDPO; Thu, 16 Feb 2012 04:30:50 -0800 (PST) Received: from m1plsmtpa01-07.prod.mesa1.secureserver.net (m1plsmtpa01-07.prod.mesa1.secureserver.net [64.202.165.186]) by ietfa.amsl.com (Postfix) with ESMTP id A85CF21F87C7; Thu, 16 Feb 2012 04:30:50 -0800 (PST) Received: from [192.168.1.100] ([67.180.133.66]) by m1plsmtpa01-07.prod.mesa1.secureserver.net with id acWp1i0031S6wJB01cWpr5; Thu, 16 Feb 2012 05:30:49 -0700 Message-ID: <4F3CF6F8.6030804@certichron.com> Date: Thu, 16 Feb 2012 04:30:48 -0800 From: Todd Glassey Organization: certichron.com User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dnsop@ietf.org, IETF Discussion Mailing List X-Opacus-Archived: none X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Feb 2012 08:07:31 -0800 Subject: [DNSOP] SEARS - Search Engine Address Resolution Service (and Protocol) 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, 16 Feb 2012 12:30:54 -0000 So SEARS is a method of replacing the DNS roots with a well-known service portal providing a Google or other SE based access model. The session can interface with traditional HTTP or DNS-Lookup Ports to deliver content or addresses to a browser in the form of a HTTP redirection. The protocol specification is almost done and is intended to make threats of attacks against the DNS roots less of an issue. Todd -- Todd S. Glassey - CISM CIFI CTO Certichron Inc This message contains information which may be confidential and/or privileged. Unless you are the intended recipient (or authorized to receive for the intended recipient), you may not read, use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message and any attachment(s) thereto without retaining any copies. Further we have a formal OPT OUT Policy posted on our website pertaining to the use of any Email Addresses gleaned or taken from any source, web, mailing lists, previous customer lists etc. In all instances we choose to formally OPT OUT and this notice constitutes formal disclosure that you may not collect, buy or sell or provide access to this email address or any pertaining to our DNS MX Record Publication License posted on the web at http://www-wp.certichron.com/?page_id=3947. From beldmit@gmail.com Thu Feb 16 10:17:21 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0632821E802E; Thu, 16 Feb 2012 10:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPdUzEvxeKEz; Thu, 16 Feb 2012 10:17:14 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF7BC21E801F; Thu, 16 Feb 2012 10:17:14 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2943257pbc.31 for ; Thu, 16 Feb 2012 10:17:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WZ9x7SeqtGOU/Hju8RaHzZfHvlZC9FgSOr0rSQN5fD0=; b=V/NwR6njpo3gAi0VxHvQzEVHSGX71EtOsvayd+y+Q4UYRU7w6MHgT1Ggl2BwOENUVu I2QNIyu8E8GImIFk9rsvm7MJ5O99pqESrpxrvon0t0CGX2tG04DoDLDx8Ou2VbjzoLRU jkwSkGFWrvE9MH3idFjsj1nuaNRz50HrOj17U= MIME-Version: 1.0 Received: by 10.68.130.233 with SMTP id oh9mr16156018pbb.92.1329416234507; Thu, 16 Feb 2012 10:17:14 -0800 (PST) Received: by 10.68.230.103 with HTTP; Thu, 16 Feb 2012 10:17:14 -0800 (PST) In-Reply-To: <4F3CF6F8.6030804@certichron.com> References: <4F3CF6F8.6030804@certichron.com> Date: Thu, 16 Feb 2012 22:17:14 +0400 Message-ID: From: Dmitry Belyavsky To: Todd Glassey Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsop@ietf.org, IETF Discussion Mailing List Subject: Re: [DNSOP] SEARS - Search Engine Address Resolution Service (and Protocol) 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, 16 Feb 2012 18:17:21 -0000 Greetings! Is there a more or less complete description of SEARS? Google can't find anything instead this or that trade companies, Wikipedia shows some people and some trade companies too... On Thu, Feb 16, 2012 at 4:30 PM, Todd Glassey wro= te: > So SEARS is a method of replacing the DNS roots with a well-known > service portal providing a Google or other SE based access model. =C2=A0T= he > session can interface with traditional HTTP or DNS-Lookup Ports to > deliver content or addresses to a browser in the form of a HTTP redirecti= on. > > The protocol specification is almost done and is intended to make > threats of attacks against the DNS roots less of an issue. > > Todd > > -- > Todd S. Glassey - CISM CIFI > CTO Certichron Inc > > This message contains information which may be confidential and/or > privileged. Unless you are the intended recipient (or authorized to > receive for the intended recipient), you may not read, use, copy or > disclose to anyone the message or any information contained in the > message. If you have received the message in error, please advise the > sender by reply e-mail and delete the message and any attachment(s) > thereto without retaining any copies. > > Further we have a formal OPT OUT Policy posted on our website pertaining > to the use of any Email Addresses gleaned or taken from any source, web, > mailing lists, previous customer lists etc. In all instances we choose > to formally OPT OUT and this notice constitutes formal disclosure that > you may not collect, buy or sell or provide access to this email address > or any pertaining to our DNS MX Record Publication License posted on the > web at http://www-wp.certichron.com/?page_id=3D3947. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 SY, Dmitry Belyavsky From joe.gersch@secure64.com Fri Feb 17 09:16:59 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C345521F853B for ; Fri, 17 Feb 2012 09:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDDrEFiihqCt for ; Fri, 17 Feb 2012 09:16:59 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id DE58921F8545 for ; Fri, 17 Feb 2012 09:16:58 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 5D07DB84B3 for ; Fri, 17 Feb 2012 10:16:59 -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 R7IxuHJ4KsSQ; Fri, 17 Feb 2012 10:16:58 -0700 (MST) Received: from [10.138.15.34] (unknown [192.168.254.4]) by zimbra.secure64.com (Postfix) with ESMTPSA id 14B84B8495 for ; Fri, 17 Feb 2012 10:16:58 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1329499018; bh=14l6M7RGb30NE16MwWg0kuQTRZRDJTOycL4F+CRQZNg=; h=From:Content-Type:Subject:Date:References:To:Message-Id: Mime-Version; b=kTop2/waWqbNxSQfsLvagl+YqY8a602xVKxHZ42ATyFxklmIl7 84thcCJ4zs0OP5bBgaa4Wx2kRv/vw53w6dNm6fwtfBYoD0PATh4V/GhViCaNu2/oEoC bzq90Szvvtw+t+4Y//L/i5hiMeYOuamlfl0SWSiXLi2ouVsYv+QE2M= From: Joseph Gersch Content-Type: multipart/signed; boundary=Apple-Mail-182--995501968; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 17 Feb 2012 10:16:56 -0700 References: <20120217000918.22307.43753.idtracker@ietfa.amsl.com> To: dnsop@ietf.org Message-Id: <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [DNSOP] Fwd: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:16:59 -0000 --Apple-Mail-182--995501968 Content-Type: multipart/alternative; boundary=Apple-Mail-181--995502060 --Apple-Mail-181--995502060 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All,=20 we have submitted a new draft that will be presented at the Paris IETF = meeting. =20 Please take the time to send any comments and suggestions regarding this = idea on naming CIDR address blocks in the Reverse DNS. Best regards, - Joe Gersch and Dan Massey Begin forwarded message: > From: internet-drafts@ietf.org > Date: February 16, 2012 5:09:18 PM MST > To: joe.gersch@secure64.com > Cc: joe.gersch@secure64.com, massey@cs.colostate.edu > Subject: New Version Notification for = draft-gersch-dnsop-revdns-cidr-00.txt >=20 > A new version of I-D, draft-gersch-dnsop-revdns-cidr-00.txt has been = successfully submitted by Joe Gersch and posted to the IETF repository. >=20 > Filename: draft-gersch-dnsop-revdns-cidr > Revision: 00 > Title: Reverse DNS Naming Convention for CIDR Address = Blocks > Creation date: 2012-02-14 > WG ID: Individual Submission > Number of pages: 19 >=20 > Abstract: > The current reverse DNS naming method is used to specify a complete > IP address. It has not been used to handle address ranges; for > example, there is no formal mechanism for specifying a reverse DNS > name for the block of addresses specified by the IPv4 prefix > 129.82.0.0/16. Defining such a reverse DNS naming convention would > be useful for a number of applications. These include applications > for secure BGP routing, and applications that need host-information > for a device owning a complete IPv6 address block. This draft > proposes a naming convention for encoding CIDR address blocks in the > reverse DNS. >=20 >=20 >=20 >=20 > The IETF Secretariat Joseph Gersch Chief Operating Officer Secure64 Software Corporation --Apple-Mail-181--995502060 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: February 16, 2012 5:09:18 PM MST
Subject: New Version Notification for = draft-gersch-dnsop-revdns-cidr-00.txt

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

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

Abstract:
  The current reverse DNS = naming method is used to specify a complete
  IP address. =  It has not been used to handle address ranges; for
=   example, there is no formal mechanism for specifying a = reverse DNS
  name for the block of addresses specified by = the IPv4 prefix
  129.82.0.0/16.  Defining such a = reverse DNS naming convention would
  be useful for a = number of applications.  These include applications
=   for secure BGP routing, and applications that need = host-information
  for a device owning a complete IPv6 = address block.  This draft
  proposes a naming = convention for encoding CIDR address blocks in the
=   reverse DNS.




The IETF = Secretariat

Joseph = Gersch
Chief Operating Officer
Secure64 = ;Software Corporation



= --Apple-Mail-181--995502060-- --Apple-Mail-182--995501968 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISyzCCA7ow ggMjoAMCAQICARUwDQYJKoZIhvcNAQEEBQAwgZsxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDTzEa MBgGA1UEBxMRR3JlZW53b29kIFZpbGxhZ2UxJjAkBgNVBAoTHVNlY3VyZTY0IFNvZnR3YXJlIENv cnBvcmF0aW9uMREwDwYDVQQDEwhTZWN1cmU2NDEoMCYGCSqGSIb3DQEJARYZZGF2ZS5oaWdnaW5z QHNlY3VyZTY0LmNvbTAeFw0wOTA5MTgxNzU4MjJaFw0xOTA5MTYxNzU4MjJaMH8xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDTzEmMCQGA1UEChMdU2VjdXJlNjQgU29mdHdhcmUgQ29ycG9yYXRpb24x EzARBgNVBAMTCkpvZSBHZXJzY2gxJjAkBgkqhkiG9w0BCQEWF2pvZS5nZXJzY2hAc2VjdXJlNjQu Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDtTJVlxgYUY9g/BtP3VR0TwmnAvL4y6XP0 7dGIKlTSTZln+wbqh/irpKN4uPEE7OUi+QSIwtBr28H9qSncqe77lHEfMJ1M15LP1TZhkZPq35bV JAZ8pJug9P2kCWP4bRAMNdUQodA5K4fEfpioAk/ANmfMdyETh7v63BtS9Wos3wIDAQABo4IBJzCC ASMwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNh dGUwHQYDVR0OBBYEFLQ6OEAHhNgqccOp2JdMpanDYjXhMIHIBgNVHSMEgcAwgb2AFLOMMetFyqei XZJRH0VFwQHMyzZboYGhpIGeMIGbMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ08xGjAYBgNVBAcT EUdyZWVud29vZCBWaWxsYWdlMSYwJAYDVQQKEx1TZWN1cmU2NCBTb2Z0d2FyZSBDb3Jwb3JhdGlv bjERMA8GA1UEAxMIU2VjdXJlNjQxKDAmBgkqhkiG9w0BCQEWGWRhdmUuaGlnZ2luc0BzZWN1cmU2 NC5jb22CAQAwDQYJKoZIhvcNAQEEBQADgYEAQQGBXYMESk/389S2pqbOjODFLbc6NMBwEH7gRqZu rjjxyKlUa7SR+IjI14N61dZ8Ig0seTi1wzpF2JiC0Kx4xiwQcWzBgPj0qYWtdbWTd3oCyGTbcSp8 IyYquS2dPGrQBH9wpjSZOGoVklDK7xuzBbGJC9NeHl0Ylx/CUrGrpyUwggcjMIIGC6ADAgECAgMD i20wDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAxMTYx MTI0NTNaFw0xMzAxMTYwNjMyMDhaMGUxGTAXBgNVBA0TEHhjVHMxVjYyNzc4UjNRbWUxIDAeBgNV BAMMF2pvZS5nZXJzY2hAc2VjdXJlNjQuY29tMSYwJAYJKoZIhvcNAQkBFhdqb2UuZ2Vyc2NoQHNl Y3VyZTY0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMkiQlbXdZVViZH48O2v 2Ebd9FqELwQVtDRs27awCsDtE2VJCeOC8RX4lkuLQINc0HORyB4R/fI1ylcBUN3V9xDxoNyq9cDG JS1Y52maHKlqURTHxPh4COoIKFKsmt62VG/8Hw53QwoCeD/tBaHAAFlhH6xFOMB1z9qV0JNIdQvK 8kvQetUl2e0Ze2xe5K1bD3yJ/J56TqkO5hqzCYbt6ZkRuVN9h8XOKyygB/6uKgoiJ9ixSoirOIHh u62Bk/6bTvt87615YFVo7mufA2eLD18I0Ps6U6cn01W5/i1MB1cJ5JuxsPlMuLiYRXrhpI7zOTwk ttYbJoqnaqGJWaAVW1kCAwEAAaOCA7IwggOuMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUmeaF0A350LAA1UznJB18eJkqkYUw HwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIgYDVR0RBBswGYEXam9lLmdlcnNjaEBz ZWN1cmU2NC5jb20wggIhBgNVHSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEF BQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUg d2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVu dHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVu ZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9u cy4wgZwGCCsGAQUFBwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQIaZExpYWJpbGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxl Z2FsIGFuZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIu Y2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20v MA0GCSqGSIb3DQEBBQUAA4IBAQCJYIzCJp9qLEJcj23IUT9YgbAl7w8yX4pWfy4FwCYYPy0c5urh srwaM9P7IFvh03iqXBKg2MTHoW1I6NFP0RNoL6L0WwVhrR+Fqn9pPDX9Fi8rl+UE1ZdBWQ6skzaH X597cLrZJorjTOaocW7nDgOq2sSXPlH6BxIzmEmGejuhphp9HheTZWbCtvozQ5LqKRT5CzZdsW/p 74RxyOPJ6mORS6AX4YU6Kck6ZLsdbdatJVvGGrn6ivxZDDKXUODNH8zgrZcyeYTCKyza79xUBYMq 4SJsGT6zzmt+syqEokCY+poDxXp0yU5L3eqfD8Se2wyioeVCbFS3lggaY+011VFsMIIH4jCCBcqg AwIBAgIBDTANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU0WhcNMTIx MDIyMjEwMTU0WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f /X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yk sq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IDWzCCA1cw DAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGC MIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEB MAkGA1UdEgQCMAAwPQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9zZnNjYS5jcnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL3Nmc2NhLWNybC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNy bDCCAV0GA1UdIASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENv bW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0 aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0ZXMw DQYJKoZIhvcNAQEFBQADggIBAKqa4eBbjM4dG/wdxiwwIKC3kyb98QK2zREovyn/xzDP/4H/Bc8F FDTgoJR+nX2Li0EP3U7TsjG+CaIi90+8YlShADpkPrfm/8SzjGtJtfM6EaluJOhpcqMr3OyzK3aY GJP5RIeZ6vLT3fQaDZsIooXl6YSFR/0HpU4FJDc0wuyFaZmFbCrjTp8RNYyRWTTX6mWSv+TraOwu j3zrrddSpgUEi2WqwM9G/5o4IXQbGHx7oXTvL6zrw9IOYO3QOKZDgFNhHeKUgqMAUiLcg/+WhcGe +Y4umKuxghtwaYsgD/bLfIfop3NC/u5JqwDCWizAJruhmbOV4LG859MFCb2w/YeY55zDPVGmQ3MZ driwdOKrhlFjOjYihmm28UHOvND2G3kK0LvnuieLqjQMc6GuUcZAQOWv96pW4BfbiQXpAqibMMeb 0PZISa7PFEzGiBc2xAuVRkM4kB9/+iieA1D/OTiRJwsf6rkoVgOsN9fCw522tzOmuVfiqDS4bFYv 00sX/dFGwasHUUf3DsLhpDSYdejb74SKjtuqLDIOuAm2bA1axA6+7kjFeNIngSU6OPSMre+xAjoc /6coaMGthFD+mimr/i/8F8wDwdyzas7oxkdCtaW8hVir8mJnbp4CbckllDMPkeQ6qQNmxSDhOeqX 1jyx2cTi/vPq+/TyxV/stlehMYIDiTCCA4UCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQIDA4ttMAkGBSsOAwIaBQCgggHJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMDIxNzE3MTY1NlowIwYJKoZIhvcNAQkEMRYEFF0jx8Yh2K011lbgYXbPDlx7 6aj6MIGyBgkrBgEEAYI3EAQxgaQwgaEwgZsxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDTzEaMBgG A1UEBxMRR3JlZW53b29kIFZpbGxhZ2UxJjAkBgNVBAoTHVNlY3VyZTY0IFNvZnR3YXJlIENvcnBv cmF0aW9uMREwDwYDVQQDEwhTZWN1cmU2NDEoMCYGCSqGSIb3DQEJARYZZGF2ZS5oaWdnaW5zQHNl Y3VyZTY0LmNvbQIBFTCBtAYLKoZIhvcNAQkQAgsxgaSggaEwgZsxCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJDTzEaMBgGA1UEBxMRR3JlZW53b29kIFZpbGxhZ2UxJjAkBgNVBAoTHVNlY3VyZTY0IFNv ZnR3YXJlIENvcnBvcmF0aW9uMREwDwYDVQQDEwhTZWN1cmU2NDEoMCYGCSqGSIb3DQEJARYZZGF2 ZS5oaWdnaW5zQHNlY3VyZTY0LmNvbQIBFTANBgkqhkiG9w0BAQEFAASCAQCK95nOiW7wyyZDXRBN 55/Q8ShRa+/I1RmAbImT9V1qOvdhm/rG9+kz0bK7gqVg8xfOn0Wm/oG6Hy2IqtcPN7KqWhzDRHO8 h/Ujnlh3TJM0MyRflBahtWGE6001SRs+pplTV1i7eMJ43U5tCBJAM3zYuEd5fiYqdBME9fduDXzV Vq1WbsrjuDlKdD+5zLuTHIfiBFzR1pW6zdMFx6acufAxUY+x9wL0yT033IesWM5fA8YZ0i9rGBMI jOy6AGRcGHhJr5rLI/dJ+STTbQlj4TUkH+iqjel45I3umlyp1yhp9AW23wE1Z+GYW8qmpR1jlu5Z ABKOrU2kALTgIcTdbugZAAAAAAAA --Apple-Mail-182--995501968-- From johnl@iecc.com Fri Feb 17 17:57:48 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398F621F85B7 for ; Fri, 17 Feb 2012 17:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.857 X-Spam-Level: X-Spam-Status: No, score=-109.857 tagged_above=-999 required=5 tests=[AWL=1.342, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Malx3+ctaMIy for ; Fri, 17 Feb 2012 17:57:47 -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 6A24621F85B6 for ; Fri, 17 Feb 2012 17:57:47 -0800 (PST) Received: (qmail 14713 invoked from network); 18 Feb 2012 01:57:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Feb 2012 01:57:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3f0599.xn--btvx9d.k1202; i=johnl@user.iecc.com; bh=j6wAunGcrIuFOOWWprp6lPWblyfSfG3nGCkk1c6RsB8=; b=uOFR/401DIGWxpCAkc6g+3OvjqI8ef+cHejGydmRwV30DVwrnMFghyTGAt6H2JYuHlFGsP0qVzgDu9lR8IamlTfPjL/l4ocqlPhd9Q7BU1xQNDEVWRhSW2k3ZU7q/d/WDAIX+YlfmMmZ9k+8+6JooDS6hj+jy302HfhxgZqOnN8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3f0599.xn--btvx9d.k1202; olt=johnl@user.iecc.com; bh=j6wAunGcrIuFOOWWprp6lPWblyfSfG3nGCkk1c6RsB8=; b=hJU42pT6IDy33J39Dmy4q6cXzwn+7+YiaYG26PK9xzQe3W0jVQh/MqZa1TbYAI+ex9wCLIthpJYtkAstynUJy1t7UPHgWN3O1f7XtjJYiTTXTtrcv5iE4QO2h4iKOShuzapMOf2e7XNG2FjJePKbts9Uba+kT2ckzusKj0YwwKE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Feb 2012 01:57:23 -0000 Message-ID: <20120218015723.84965.qmail@joyce.lan> From: "John Levine" To: dnsop@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [DNSOP] Models of DNS cache behavior? 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, 18 Feb 2012 01:57:48 -0000 Are there any models of DNS cache behavior, either analytic or simulations? What I have in mind is something that would help me see whether I should partition a cache among various kinds of traffic, or perhaps limit max TTLs, or experiment with replacement strategies. For that matter, what's the state of DNS modelling in general? I found a paper by Jung et al from 2003 on cache models which starts by asserting that caches are so big that entries only drop out due to TTL expiry, did a lot of analysis and simulation, and concluded that 15 minute TTLs got nearly the same cache benefit of 24 hr TTL. A 2010 paper by Alexiou et al. models the Kaminsky DNS poisoning attack and the port randomizing fix, which is interesting but not what I'm looking for. (They conclude that the attack is real, and the fix works OK.) Anything else I should be looking at? -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From marc.lampo@eurid.eu Mon Feb 20 05:21:55 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C628421F8760 for ; Mon, 20 Feb 2012 05:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWYAgkvJ48Kj for ; Mon, 20 Feb 2012 05:21:54 -0800 (PST) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id E063B21F8758 for ; Mon, 20 Feb 2012 05:21:53 -0800 (PST) X-ASG-Debug-ID: 1329744300-0369490e9c40690001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id OqKCdNDPzikplvWw; Mon, 20 Feb 2012 14:25:00 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 1C3FDE4075; Mon, 20 Feb 2012 14:21:51 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDUdEWqPnSKO; Mon, 20 Feb 2012 14:21:51 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 057C9E4050; Mon, 20 Feb 2012 14:21:51 +0100 (CET) From: "Marc Lampo" To: "'Joseph Gersch'" , References: <20120217000918.22307.43753.idtracker@ietfa.amsl.com> <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> In-Reply-To: <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> Date: Mon, 20 Feb 2012 14:21:51 +0100 (CET) X-ASG-Orig-Subj: RE: [DNSOP] Fwd: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt Message-ID: <014c01ccefd2$9aef5ad0$d0ce1070$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014D_01CCEFDA.FCB3C2D0" X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Acztl/MFN7p7ZtveSZKSucUcIXRhqACOicig Content-Language: en-za X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1329744300 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: Re: [DNSOP] Fwd: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 13:21:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_014D_01CCEFDA.FCB3C2D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hello, Some “typographic” remarks : 1) 5.2 IPv4 Address Block Naming à IPv6 Address Block Naming 2) In 5.2 there are 2 examples that have missing “::”, (2607:fa88:8000:/33 à 2607:fa88:8000::/33 and 2607:fa88:8000:/35 à 2607:fa88:8000::/35) in 5.3 there is 1 example with missing “::”. From: Joseph Gersch [mailto:joe.gersch@secure64.com] Sent: 17 February 2012 06:17 PM To: dnsop@ietf.org Subject: [DNSOP] Fwd: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt All, we have submitted a new draft that will be presented at the Paris IETF meeting. Please take the time to send any comments and suggestions regarding this idea on naming CIDR address blocks in the Reverse DNS. Best regards, - Joe Gersch and Dan Massey Begin forwarded message: From: internet-drafts@ietf.org Date: February 16, 2012 5:09:18 PM MST To: joe.gersch@secure64.com Cc: joe.gersch@secure64.com, massey@cs.colostate.edu Subject: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt A new version of I-D, draft-gersch-dnsop-revdns-cidr-00.txt has been successfully submitted by Joe Gersch and posted to the IETF repository. Filename: draft-gersch-dnsop-revdns-cidr Revision: 00 Title: Reverse DNS Naming Convention for CIDR Address Blocks Creation date: 2012-02-14 WG ID: Individual Submission Number of pages: 19 Abstract: The current reverse DNS naming method is used to specify a complete IP address. It has not been used to handle address ranges; for example, there is no formal mechanism for specifying a reverse DNS name for the block of addresses specified by the IPv4 prefix 129.82.0.0/16. Defining such a reverse DNS naming convention would be useful for a number of applications. These include applications for secure BGP routing, and applications that need host-information for a device owning a complete IPv6 address block. This draft proposes a naming convention for encoding CIDR address blocks in the reverse DNS. The IETF Secretariat Joseph Gersch Chief Operating Officer Secure64 Software Corporation ------=_NextPart_000_014D_01CCEFDA.FCB3C2D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

Some “typographic” remarks :

1)      = 5.2 IPv4 Address Block Naming =E0= IPv6 Address Block Naming

2)      = In 5.2 there are 2 examples that have missing = “::”,
(2607:fa88:8000:/33 =E0= 2607:fa88:8000::/33 and
2607:fa88:8000:/35 =E0= 2607:fa88:8000::/35)
in 5.3 there is 1 example with missing = “::”.

 

From:= Joseph = Gersch [mailto:joe.gersch@secure64.com]
Sent: 17 February = 2012 06:17 PM
To: dnsop@ietf.org
Subject: [DNSOP] = Fwd: New Version Notification for = draft-gersch-dnsop-revdns-cidr-00.txt

 

All, 

  we have submitted a new draft that will be = presented at the Paris IETF meeting.  

Please take the time to send any comments and = suggestions regarding this idea on naming CIDR address blocks in the = Reverse DNS.

 

Best regards,

   - Joe Gersch and Dan = Massey

 

 

Begin = forwarded message:



Date: = February = 16, 2012 5:09:18 PM MST

Subject: = New Version Notification for = draft-gersch-dnsop-revdns-cidr-00.txt

 

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

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

Abstract:
  The current reverse DNS naming method = is used to specify a complete
  IP address.  It has = not been used to handle address ranges; for
  example, = there is no formal mechanism for specifying a reverse = DNS
  name for the block of addresses specified by the IPv4 = prefix
  129.82.0.0/16.  Defining such a reverse DNS = naming convention would
  be useful for a number of = applications.  These include applications
  for secure = BGP routing, and applications that need = host-information
  for a device owning a complete IPv6 = address block.  This draft
  proposes a naming = convention for encoding CIDR address blocks in = the
  reverse DNS.




The IETF = Secretariat

 

Joseph Gersch

Chief Operating Officer

Secure64 Software Corporation

 

 

 

------=_NextPart_000_014D_01CCEFDA.FCB3C2D0-- From marc.lampo@eurid.eu Mon Feb 20 05:41:18 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8669621F86FF for ; Mon, 20 Feb 2012 05:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSbJ2aCesk+A for ; Mon, 20 Feb 2012 05:41:18 -0800 (PST) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id B36F921F86EC for ; Mon, 20 Feb 2012 05:41:17 -0800 (PST) X-ASG-Debug-ID: 1329745465-0369490e9c40740001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id EsuPnDy3EADVIKE6; Mon, 20 Feb 2012 14:44:25 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 4604CE406F; Mon, 20 Feb 2012 14:41:16 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuXi2qExS3Oe; Mon, 20 Feb 2012 14:41:16 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 32E0BE4050; Mon, 20 Feb 2012 14:41:16 +0100 (CET) From: "Marc Lampo" To: "'Joseph Gersch'" , References: <20120217000918.22307.43753.idtracker@ietfa.amsl.com> <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> In-Reply-To: <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> Date: Mon, 20 Feb 2012 14:41:16 +0100 (CET) X-ASG-Orig-Subj: RE: [DNSOP] Fwd: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt Message-ID: <017101ccefd5$51790560$f46b1020$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Acztl/MFN7p7ZtveSZKSucUcIXRhqACOrjOw Content-Language: en-za X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1329745465 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: Re: [DNSOP] Fwd: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 13:41:18 -0000 Hello, (sorry – previously sent email was not finished …) Some “typographic†remarks : 1) 5.2 IPv4 Address Block Naming → IPv6 Address Block Naming 2) In 5.2 there are 2 examples that have missing “::â€, (2607:fa88:8000:/33 → 2607:fa88:8000::/33 and 2607:fa88:8000:/35 → 2607:fa88:8000::/35) in 5.3 there is 1 example with missing “::â€. (2607:fa88:8000:/36 → 2607:fa88:8000::/36) About “content†: 1) 3. Design Requirement → 2. Coverage Authority. “Any … with a data record or NXDOMAIN …†to be completed with : NODATA → “Any … with a data record or NODATA or NXDOMAIN …†2) In 5.2 IPv6 Address Block Naming Why not add some examples to show conversion from a reverse-DNS name back to CIDR ? (just like in 5.1) Globally : 1) It is implied by the content of the present draft, but should it be stated (in Design Requirements) that the proposal should be valid for both IPv4 and IPv6 addresses ? 2) In the Introduction, where you correctly state that ISP’s pre-populate reverse DNS, the problem is stated that the approach of pre-populating does not scale for IPv6. However, by itself, this draft does not solve that problem, does it ? (needs programmatic support) (this example in the Introduction made me think/assume that this draft also applies to “simple†reverse mapping. In which case I wondered how this draft does away with CNAME (a la RFC 2317). But then, after rereading it occurred to me that this draft is about storing CIDR info in revdns. → isn’t it confusing to give, in the intro, an example that does not apply to CIDR info ? (it got at least me confused, not that I’d want to be taken as a reference ;-) Kind regards, Marc Lampo Security Officer EURid From: Joseph Gersch [mailto:joe.gersch@secure64.com] Sent: 17 February 2012 06:17 PM To: dnsop@ietf.org Subject: [DNSOP] Fwd: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt All, we have submitted a new draft that will be presented at the Paris IETF meeting. Please take the time to send any comments and suggestions regarding this idea on naming CIDR address blocks in the Reverse DNS. Best regards, - Joe Gersch and Dan Massey Begin forwarded message: From: internet-drafts@ietf.org Date: February 16, 2012 5:09:18 PM MST To: joe.gersch@secure64.com Cc: joe.gersch@secure64.com, massey@cs.colostate.edu Subject: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt A new version of I-D, draft-gersch-dnsop-revdns-cidr-00.txt has been successfully submitted by Joe Gersch and posted to the IETF repository. Filename: draft-gersch-dnsop-revdns-cidr Revision: 00 Title: Reverse DNS Naming Convention for CIDR Address Blocks Creation date: 2012-02-14 WG ID: Individual Submission Number of pages: 19 Abstract: The current reverse DNS naming method is used to specify a complete IP address. It has not been used to handle address ranges; for example, there is no formal mechanism for specifying a reverse DNS name for the block of addresses specified by the IPv4 prefix 129.82.0.0/16. Defining such a reverse DNS naming convention would be useful for a number of applications. These include applications for secure BGP routing, and applications that need host-information for a device owning a complete IPv6 address block. This draft proposes a naming convention for encoding CIDR address blocks in the reverse DNS. The IETF Secretariat Joseph Gersch Chief Operating Officer Secure64 Software Corporation From emiliano.casalicchio@uniroma2.it Mon Feb 20 11:27:20 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC64F21F87DC for ; Mon, 20 Feb 2012 11:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEle3kWC-VPM for ; Mon, 20 Feb 2012 11:27:16 -0800 (PST) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2F01A21F87C7 for ; Mon, 20 Feb 2012 11:27:14 -0800 (PST) Received: from smtpauth.uniroma2.it (smtpauth.uniroma2.it [160.80.6.46]) by smtp.uniroma2.it (8.13.6/8.13.6) with ESMTP id q1KJ5Ue3014952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Feb 2012 20:05:31 +0100 Received: from [192.168.0.100] ([2.227.168.244]) (authenticated bits=0) by smtpauth.uniroma2.it (8.14.3/8.14.3/Debian-9.4) with ESMTP id q1KJR1Gt002714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Feb 2012 20:27:03 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Emiliano Casalicchio In-Reply-To: <20120218015723.84965.qmail@joyce.lan> Date: Mon, 20 Feb 2012 20:27:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120218015723.84965.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1257) X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-From: emiliano.casalicchio@uniroma2.it Cc: dnsop@ietf.org Subject: Re: [DNSOP] Models of DNS cache behavior? 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, 20 Feb 2012 19:27:21 -0000 John, may be the model described in this paper can be useful for you. Yakup Ko=E7, Almerima Jamakovic, Bart Gijsen, "A Global = Reference Model of the DNS" presented at DNS-EASY 2011. Here the proceedings: http://www.gcsec.org/sites/default/files/files/dnseasy2011_final.pdf Best Emiliano On 18 Feb 2012, at 02:57, John Levine wrote: > Are there any models of DNS cache behavior, either analytic or > simulations? What I have in mind is something that would help me see > whether I should partition a cache among various kinds of traffic, or > perhaps limit max TTLs, or experiment with replacement strategies. =20 >=20 > For that matter, what's the state of DNS modelling in general? >=20 > I found a paper by Jung et al from 2003 on cache models which starts > by asserting that caches are so big that entries only drop out due to > TTL expiry, did a lot of analysis and simulation, and concluded that > 15 minute TTLs got nearly the same cache benefit of 24 hr TTL. >=20 > A 2010 paper by Alexiou et al. models the Kaminsky DNS poisoning > attack and the port randomizing fix, which is interesting but not what > I'm looking for. (They conclude that the attack is real, and the fix > works OK.) >=20 > Anything else I should be looking at? >=20 >=20 > --=20 > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for = Dummies", > Please consider the environment before reading this e-mail. = http://jl.ly > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 From joe.gersch@secure64.com Mon Feb 20 14:33:55 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0C121F853D for ; Mon, 20 Feb 2012 14:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH-NtRIfncUC for ; Mon, 20 Feb 2012 14:33:55 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 06FAA21F853C for ; Mon, 20 Feb 2012 14:33:54 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id D8E0CB84C0; Mon, 20 Feb 2012 15:33:54 -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 XdXTB2t3cqis; Mon, 20 Feb 2012 15:33:53 -0700 (MST) Received: from [10.138.15.34] (unknown [192.168.254.4]) by zimbra.secure64.com (Postfix) with ESMTPSA id 9724DB84BE; Mon, 20 Feb 2012 15:33:52 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1329777233; bh=Qnz2oaGdoLova4zOebnYeB93P+MEOkPC4StBSyTa80k=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=My+UStvLi6y9iOkAEQeFmU6uFvw67ex3QBH3r0 A+nbostreui1KuftiRaEvNslEj8dEuYFaZaZg0ZFeKNNPxuORRG84pN97mbEgNwLcVF jateZ4j3CiGb89fsXrXn7pJ130rL9QuHVLhn0a7r2as4RVtkPNNaLBDzZdlogvwpXw= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-199--717288780; protocol="application/pkcs7-signature"; micalg=sha1 From: Joseph Gersch In-Reply-To: <017101ccefd5$51790560$f46b1020$@lampo@eurid.eu> Date: Mon, 20 Feb 2012 15:33:49 -0700 Message-Id: References: <20120217000918.22307.43753.idtracker@ietfa.amsl.com> <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> <017101ccefd5$51790560$f46b1020$@lampo@eurid.eu> To: Marc Lampo X-Mailer: Apple Mail (2.1084) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Fwd: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:33:56 -0000 --Apple-Mail-199--717288780 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Marco, Thanks for reading and commenting on our draft. We have a couple of = weeks to make corrections to draft-00 before they get frozen for the = IETF meeting. We appreciate your pointing out the typos (we found the = ipv6 one ourselves, oops.....) and the suggestions for clarification. =20 This draft on CIDR naming is mainly focused on proposing a simple, = direct way to name CIDR addresses and eliminates the need for CNAME = indirection. It can be used for a number of purposes. Regarding the intro on pre-populating the reverse-DNS... you are = correct, this is a draft on CIDR naming, not on fixing that particular = IPv6 issue. We will make that clarification in our next draft. The = ipv6 issue "might" be able to be addressed with this approach, but more = thought needs to be put in to it before a complete solution could be = proposed. We were mentioning this issue in order to give multiple = examples of the reasons why CIDR naming is a useful concept. Again, thanks, - Joe Gersch and Dan Massey On Feb 20, 2012, at 6:41 AM, Marc Lampo wrote: > Hello, >=20 > (sorry =E2=80=93 previously sent email was not finished =E2=80=A6) >=20 > Some =E2=80=9Ctypographic=E2=80=9D remarks : > 1) 5.2 IPv4 Address Block Naming =E2=86=92 IPv6 Address Block Naming > 2) In 5.2 there are 2 examples that have missing =E2=80=9C::=E2=80=9D, > (2607:fa88:8000:/33 =E2=86=92 2607:fa88:8000::/33 and > 2607:fa88:8000:/35 =E2=86=92 2607:fa88:8000::/35) > in 5.3 there is 1 example with missing =E2=80=9C::=E2=80=9D. > (2607:fa88:8000:/36 =E2=86=92 2607:fa88:8000::/36) >=20 > About =E2=80=9Ccontent=E2=80=9D : > 1) 3. Design Requirement =E2=86=92 2. Coverage Authority. > =E2=80=9CAny =E2=80=A6 with a data record or NXDOMAIN =E2=80=A6=E2=80=9D= > to be completed with : NODATA > =E2=86=92 =E2=80=9CAny =E2=80=A6 with a data record or NODATA or = NXDOMAIN =E2=80=A6=E2=80=9D >=20 > 2) In 5.2 IPv6 Address Block Naming > Why not add some examples to show conversion from a reverse-DNS name = back to=20 > CIDR ? > (just like in 5.1) >=20 > Globally : > 1) It is implied by the content of the present draft, > but should it be stated (in Design Requirements) > that the proposal should be valid for both IPv4 and IPv6 addresses ? >=20 > 2) In the Introduction, where you correctly state that ISP=E2=80=99s = pre-populate=20 > reverse DNS, > the problem is stated that the approach of pre-populating does not = scale for=20 > IPv6. > However, by itself, this draft does not solve that problem, does it ? > (needs programmatic support) > (this example in the Introduction made me think/assume that this draft > also applies to =E2=80=9Csimple=E2=80=9D reverse mapping. In which = case I wondered how > this draft does away with CNAME (a la RFC 2317). > But then, after rereading it occurred to me that this draft is about=20= > storing > CIDR info in revdns. > =E2=86=92 isn=E2=80=99t it confusing to give, in the intro, an example = that does not apply=20 > to CIDR info ? > (it got at least me confused, not that I=E2=80=99d want to be taken as = a reference=20 > ;-) >=20 > Kind regards, >=20 > Marc Lampo > Security Officer > EURid >=20 >=20 > From: Joseph Gersch [mailto:joe.gersch@secure64.com] > Sent: 17 February 2012 06:17 PM > To: dnsop@ietf.org > Subject: [DNSOP] Fwd: New Version Notification for=20 > draft-gersch-dnsop-revdns-cidr-00.txt >=20 > All, > we have submitted a new draft that will be presented at the Paris = IETF=20 > meeting. > Please take the time to send any comments and suggestions regarding = this=20 > idea on naming CIDR address blocks in the Reverse DNS. >=20 > Best regards, > - Joe Gersch and Dan Massey >=20 >=20 > Begin forwarded message: >=20 >=20 > From: internet-drafts@ietf.org > Date: February 16, 2012 5:09:18 PM MST > To: joe.gersch@secure64.com > Cc: joe.gersch@secure64.com, massey@cs.colostate.edu > Subject: New Version Notification for = draft-gersch-dnsop-revdns-cidr-00.txt >=20 > A new version of I-D, draft-gersch-dnsop-revdns-cidr-00.txt has been=20= > successfully submitted by Joe Gersch and posted to the IETF = repository. >=20 > Filename: draft-gersch-dnsop-revdns-cidr > Revision: 00 > Title: Reverse DNS Naming Convention for CIDR Address = Blocks > Creation date: 2012-02-14 > WG ID: Individual Submission > Number of pages: 19 >=20 > Abstract: > The current reverse DNS naming method is used to specify a complete > IP address. It has not been used to handle address ranges; for > example, there is no formal mechanism for specifying a reverse DNS > name for the block of addresses specified by the IPv4 prefix > 129.82.0.0/16. Defining such a reverse DNS naming convention would > be useful for a number of applications. These include applications > for secure BGP routing, and applications that need host-information > for a device owning a complete IPv6 address block. This draft > proposes a naming convention for encoding CIDR address blocks in the > reverse DNS. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > Joseph Gersch > Chief Operating Officer > Secure64 Software Corporation >=20 >=20 >=20 Joseph Gersch Chief Operating Officer Secure64 Software Corporation --Apple-Mail-199--717288780 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISyzCCA7ow ggMjoAMCAQICARUwDQYJKoZIhvcNAQEEBQAwgZsxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDTzEa MBgGA1UEBxMRR3JlZW53b29kIFZpbGxhZ2UxJjAkBgNVBAoTHVNlY3VyZTY0IFNvZnR3YXJlIENv cnBvcmF0aW9uMREwDwYDVQQDEwhTZWN1cmU2NDEoMCYGCSqGSIb3DQEJARYZZGF2ZS5oaWdnaW5z QHNlY3VyZTY0LmNvbTAeFw0wOTA5MTgxNzU4MjJaFw0xOTA5MTYxNzU4MjJaMH8xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDTzEmMCQGA1UEChMdU2VjdXJlNjQgU29mdHdhcmUgQ29ycG9yYXRpb24x EzARBgNVBAMTCkpvZSBHZXJzY2gxJjAkBgkqhkiG9w0BCQEWF2pvZS5nZXJzY2hAc2VjdXJlNjQu Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDtTJVlxgYUY9g/BtP3VR0TwmnAvL4y6XP0 7dGIKlTSTZln+wbqh/irpKN4uPEE7OUi+QSIwtBr28H9qSncqe77lHEfMJ1M15LP1TZhkZPq35bV JAZ8pJug9P2kCWP4bRAMNdUQodA5K4fEfpioAk/ANmfMdyETh7v63BtS9Wos3wIDAQABo4IBJzCC ASMwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNh dGUwHQYDVR0OBBYEFLQ6OEAHhNgqccOp2JdMpanDYjXhMIHIBgNVHSMEgcAwgb2AFLOMMetFyqei XZJRH0VFwQHMyzZboYGhpIGeMIGbMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ08xGjAYBgNVBAcT EUdyZWVud29vZCBWaWxsYWdlMSYwJAYDVQQKEx1TZWN1cmU2NCBTb2Z0d2FyZSBDb3Jwb3JhdGlv bjERMA8GA1UEAxMIU2VjdXJlNjQxKDAmBgkqhkiG9w0BCQEWGWRhdmUuaGlnZ2luc0BzZWN1cmU2 NC5jb22CAQAwDQYJKoZIhvcNAQEEBQADgYEAQQGBXYMESk/389S2pqbOjODFLbc6NMBwEH7gRqZu rjjxyKlUa7SR+IjI14N61dZ8Ig0seTi1wzpF2JiC0Kx4xiwQcWzBgPj0qYWtdbWTd3oCyGTbcSp8 IyYquS2dPGrQBH9wpjSZOGoVklDK7xuzBbGJC9NeHl0Ylx/CUrGrpyUwggcjMIIGC6ADAgECAgMD i20wDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAxMTYx MTI0NTNaFw0xMzAxMTYwNjMyMDhaMGUxGTAXBgNVBA0TEHhjVHMxVjYyNzc4UjNRbWUxIDAeBgNV BAMMF2pvZS5nZXJzY2hAc2VjdXJlNjQuY29tMSYwJAYJKoZIhvcNAQkBFhdqb2UuZ2Vyc2NoQHNl Y3VyZTY0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMkiQlbXdZVViZH48O2v 2Ebd9FqELwQVtDRs27awCsDtE2VJCeOC8RX4lkuLQINc0HORyB4R/fI1ylcBUN3V9xDxoNyq9cDG JS1Y52maHKlqURTHxPh4COoIKFKsmt62VG/8Hw53QwoCeD/tBaHAAFlhH6xFOMB1z9qV0JNIdQvK 8kvQetUl2e0Ze2xe5K1bD3yJ/J56TqkO5hqzCYbt6ZkRuVN9h8XOKyygB/6uKgoiJ9ixSoirOIHh u62Bk/6bTvt87615YFVo7mufA2eLD18I0Ps6U6cn01W5/i1MB1cJ5JuxsPlMuLiYRXrhpI7zOTwk ttYbJoqnaqGJWaAVW1kCAwEAAaOCA7IwggOuMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUmeaF0A350LAA1UznJB18eJkqkYUw HwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIgYDVR0RBBswGYEXam9lLmdlcnNjaEBz ZWN1cmU2NC5jb20wggIhBgNVHSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEF BQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUg d2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVu dHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVu ZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9u cy4wgZwGCCsGAQUFBwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQIaZExpYWJpbGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxl Z2FsIGFuZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIu Y2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20v MA0GCSqGSIb3DQEBBQUAA4IBAQCJYIzCJp9qLEJcj23IUT9YgbAl7w8yX4pWfy4FwCYYPy0c5urh srwaM9P7IFvh03iqXBKg2MTHoW1I6NFP0RNoL6L0WwVhrR+Fqn9pPDX9Fi8rl+UE1ZdBWQ6skzaH X597cLrZJorjTOaocW7nDgOq2sSXPlH6BxIzmEmGejuhphp9HheTZWbCtvozQ5LqKRT5CzZdsW/p 74RxyOPJ6mORS6AX4YU6Kck6ZLsdbdatJVvGGrn6ivxZDDKXUODNH8zgrZcyeYTCKyza79xUBYMq 4SJsGT6zzmt+syqEokCY+poDxXp0yU5L3eqfD8Se2wyioeVCbFS3lggaY+011VFsMIIH4jCCBcqg AwIBAgIBDTANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU0WhcNMTIx MDIyMjEwMTU0WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f /X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yk sq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IDWzCCA1cw DAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGC MIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEB MAkGA1UdEgQCMAAwPQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9zZnNjYS5jcnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL3Nmc2NhLWNybC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNy bDCCAV0GA1UdIASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENv bW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0 aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0ZXMw DQYJKoZIhvcNAQEFBQADggIBAKqa4eBbjM4dG/wdxiwwIKC3kyb98QK2zREovyn/xzDP/4H/Bc8F FDTgoJR+nX2Li0EP3U7TsjG+CaIi90+8YlShADpkPrfm/8SzjGtJtfM6EaluJOhpcqMr3OyzK3aY GJP5RIeZ6vLT3fQaDZsIooXl6YSFR/0HpU4FJDc0wuyFaZmFbCrjTp8RNYyRWTTX6mWSv+TraOwu j3zrrddSpgUEi2WqwM9G/5o4IXQbGHx7oXTvL6zrw9IOYO3QOKZDgFNhHeKUgqMAUiLcg/+WhcGe +Y4umKuxghtwaYsgD/bLfIfop3NC/u5JqwDCWizAJruhmbOV4LG859MFCb2w/YeY55zDPVGmQ3MZ driwdOKrhlFjOjYihmm28UHOvND2G3kK0LvnuieLqjQMc6GuUcZAQOWv96pW4BfbiQXpAqibMMeb 0PZISa7PFEzGiBc2xAuVRkM4kB9/+iieA1D/OTiRJwsf6rkoVgOsN9fCw522tzOmuVfiqDS4bFYv 00sX/dFGwasHUUf3DsLhpDSYdejb74SKjtuqLDIOuAm2bA1axA6+7kjFeNIngSU6OPSMre+xAjoc /6coaMGthFD+mimr/i/8F8wDwdyzas7oxkdCtaW8hVir8mJnbp4CbckllDMPkeQ6qQNmxSDhOeqX 1jyx2cTi/vPq+/TyxV/stlehMYIDiTCCA4UCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQIDA4ttMAkGBSsOAwIaBQCgggHJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMDIyMDIyMzM0OVowIwYJKoZIhvcNAQkEMRYEFNQqs+8BvkfIsqytrkeo+BQA YliUMIGyBgkrBgEEAYI3EAQxgaQwgaEwgZsxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDTzEaMBgG A1UEBxMRR3JlZW53b29kIFZpbGxhZ2UxJjAkBgNVBAoTHVNlY3VyZTY0IFNvZnR3YXJlIENvcnBv cmF0aW9uMREwDwYDVQQDEwhTZWN1cmU2NDEoMCYGCSqGSIb3DQEJARYZZGF2ZS5oaWdnaW5zQHNl Y3VyZTY0LmNvbQIBFTCBtAYLKoZIhvcNAQkQAgsxgaSggaEwgZsxCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJDTzEaMBgGA1UEBxMRR3JlZW53b29kIFZpbGxhZ2UxJjAkBgNVBAoTHVNlY3VyZTY0IFNv ZnR3YXJlIENvcnBvcmF0aW9uMREwDwYDVQQDEwhTZWN1cmU2NDEoMCYGCSqGSIb3DQEJARYZZGF2 ZS5oaWdnaW5zQHNlY3VyZTY0LmNvbQIBFTANBgkqhkiG9w0BAQEFAASCAQCJzCueXMyzaUjmJ/uL WVEP7kIELmQ2mDzfQpiIorgrosU+CSS9b/Cr7qCjT5urbL1rKPsL3IZYxGrt8+jTYlHbvHh2tXCO tjqIpTn5W3rN5GHV0noOmr3EeCYOOBV6qLTgAIuybdGOp0yTQ7+9YjI/04am9KqzhS/sTWoHRh7+ ++iINyPQHdO/oz60u+TLbP5JapGZ5O7S+RfgyvmxtGGo1Ce5B2hwBAb4yZblzBB4hai0PRhn1+JS au/qGBVpE+oQCPOwGVcd0x3DflU9rD9m2neWlKKYMnREdq3Ug77X5oKB6b6asYPC6mTFzy4uZrCP 0vGZbbB8QO4jK6j8BQH3AAAAAAAA --Apple-Mail-199--717288780-- From bmanning@karoshi.com Sat Feb 25 00:58:59 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0D221F86CF for ; Sat, 25 Feb 2012 00:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.081 X-Spam-Level: X-Spam-Status: No, score=-6.081 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVdxc1WLEoEQ for ; Sat, 25 Feb 2012 00:58:57 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id C74AC21F86CB for ; Sat, 25 Feb 2012 00:58:53 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q1MD3d30009149; Wed, 22 Feb 2012 13:03:40 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q1MD3bqU009148; Wed, 22 Feb 2012 13:03:37 GMT Date: Wed, 22 Feb 2012 13:03:37 +0000 From: bmanning@vacation.karoshi.com To: Stephane Bortzmeyer Message-ID: <20120222130337.GA9093@vacation.karoshi.com.> References: <20120206191256.GA14871@vacation.karoshi.com.> <20120213083305.GA1760@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120213083305.GA1760@nic.fr> User-Agent: Mutt/1.4.1i Cc: dnsop@ietf.org, bmanning@vacation.karoshi.com, rssac@icann.org Subject: Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 08:58:59 -0000 On Mon, Feb 13, 2012 at 09:33:05AM +0100, Stephane Bortzmeyer wrote: > On Mon, Feb 06, 2012 at 07:12:56PM +0000, > bmanning@vacation.karoshi.com wrote > a message of 49 lines which said: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : Root Name Server Operational Requirements > > Author(s) : Root Server System Advisory Committee > > Filename : draft-rssac-dnsop-rfc2870bis-04.txt > > Section 3.2.1 : I do not understand why you need synced time for > DNSSEC. The root name servers do not generate signatures. but they do use TSIG. And historically, channel protection via TSIG or SIG(0) was considered part of the DNSSEC tool box. Granted that DNSSEC perception has changed over the years. but the need for sync'ed clocks is becuase of TSIG. > Section 3.2.1 : Several root name servers, such as B, reply to ICMP > echo requests, which I think is a good thing, but it seems disallowed > in your document. -I- think its a good idea, but others would prefer less transparency > Section 4.2 : This advice directly contradicts RFC 6382. Do you plan > to reclassify it as Historic? It meaning RFC 6382? Not really. The draft was an attempt to document current practice - with some leanings toward future directions. > Section 5.1 : "Announcement of planned outages also keeps other > operators from investigated a scheduled maintenance window." My > english parser broke here. Should I upgrade it or should you rewrite > the sentence? investigated should be investigating. e.g. if you don't tell anyone you are doing maintance work, observers will presume the worst and start to debug why the L root has gone offline. > (For the record, I agree with most of Joe Abley's remarks on > high-level issues with this document.) There are some strong argumetns for simply stating operational goals/principles vs documenting practice. I beleive that we are working on a "mission statement" /bill From hsantos@isdg.net Mon Feb 27 10:35:56 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2AD21F87D4 for ; Mon, 27 Feb 2012 10:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_20=-0.74, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfAJV3V2Iwnu for ; Mon, 27 Feb 2012 10:35:54 -0800 (PST) Received: from mail.santronics.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE8321F87E4 for ; Mon, 27 Feb 2012 10:35:54 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1652; t=1330367751; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=qM1t+wdofTTGhx95l58R/WJSF1U=; b=uUFXvENmpncxpH1gaxfC J3HWdYjF25jNXhhVNvQq2pCq/e9NM2nVSbv4T92jyRMaYxZ3EMremkRpdC+aoW3k 8paL5HKN4C1Plc7TNgOr9qM31av7+UCdm5wUyUqA7WiDCZFbqjKYwgx28h+TLNZu TPFXJnA8QEUOPmz8R4Lfv9E= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for dnsop@ietf.org; Mon, 27 Feb 2012 13:35:51 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3569591121.93496.4712; Mon, 27 Feb 2012 13:35:50 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1652; t=1330367502; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=HOh+ang fAngsh4rRLrv2JwmFApOlQh+8lHTyfFnAEbw=; b=CgUkSzGVI8lcq5aBee1jW6J JDVo759tHr4n0hhcEO8oGKM+jf0rBSNs+krr+sF+k4n3FyMyS/AIk47klnXH2j4l hLVzNSF3l8XufNy0HReHtKdFIGFG0Q30L+gliQ5goLoHVIWW9tphuFCN6hIP7cPP x4N0Az1pGHG8ucEX4uAw= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for dnsop@ietf.org; Mon, 27 Feb 2012 13:31:42 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4168525204.19753.6036; Mon, 27 Feb 2012 13:31:41 -0500 Message-ID: <4F4BCD01.2090401@isdg.net> Date: Mon, 27 Feb 2012 13:35:45 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: dnsop@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [DNSOP] Batch Multiple Query Packet 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, 27 Feb 2012 18:35:56 -0000 I am interesting to find information about past or possible current interest regarding the support of a Batch single call of multiple query packets. If it doesn't already exist or not considered in the past as an unfeasible concept, I am interest in seeing if this is something worth pursuing. Technical Background reasoning. With the advent of new protocols, especially those offering a domain policy construct, the TXT record is used as the fastest entry point with the widest support for query resolution. Yet there are (at least were) technical concerns that this not serve to benefit DNS for large scale usage, therefore considerations are giving to include a migration path to use new registration of RR types. This migration path comes with the recognition for a short term overhead of using a dual type query concept and long term hope for the new RR type to become the non-overhead single query satisfying result. The overall issue is two folds: 1) one where publishers may have to redundantly create two records and the DNS resolvers will always have to do a two queries to maximize widest support, and 2) The continued possible dearth of DNS servers (see RFC 3597 "Handling of Unknown DNS Resource Record (RR) Types") that do not support unnamed RR types and/or the recursion requirement. If DNS server offered support for a Batch Query of multiple packets under a single call, this may help with the above migration overhead concerns. Is this something worth pursuing as a new I-D for DNS servers? Thanks -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From mohta@necom830.hpcl.titech.ac.jp Mon Feb 27 15:58:37 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D01721E8029 for ; Mon, 27 Feb 2012 15:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.19 X-Spam-Level: * X-Spam-Status: No, score=1.19 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV+BPAp6pYE4 for ; Mon, 27 Feb 2012 15:58:36 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 5C1B421E803B for ; Mon, 27 Feb 2012 15:58:35 -0800 (PST) Received: (qmail 3227 invoked from network); 28 Feb 2012 00:17:27 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 28 Feb 2012 00:17:27 -0000 Message-ID: <4F4C1868.4090909@necom830.hpcl.titech.ac.jp> Date: Tue, 28 Feb 2012 08:57:28 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dnsop@ietf.org References: <4F4BCD01.2090401@isdg.net> In-Reply-To: <4F4BCD01.2090401@isdg.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 27 Feb 2012 23:58:37 -0000 Hector Santos wrote: > I am interesting to find information about past or possible current > interest regarding the support of a Batch single call of multiple query > packets. > > If it doesn't already exist or not considered in the past as an > unfeasible concept, I am interest in seeing if this is something worth > pursuing. Having a query requesting multiple RRTYPEs is a bad idea, because only some of the RRTYPEs may be found in cache. But, it's OK to have separate queries for each RRTYPEs in a single packet. Use TCP or try to extend UDP. However, > this may help with the above migration overhead concerns. I don't think so. Masataka Ohta From Ed.Lewis@neustar.biz Mon Feb 27 16:37:14 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD0D21E8024 for ; Mon, 27 Feb 2012 16:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.185 X-Spam-Level: X-Spam-Status: No, score=-104.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBYbkwxC0HMU for ; Mon, 27 Feb 2012 16:37:14 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1552421E800C for ; Mon, 27 Feb 2012 16:37:13 -0800 (PST) Received: from 47.155.dhcp.conference.apricot.net (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q1S0bADq061772; Mon, 27 Feb 2012 19:37:11 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [220.247.155.47] by 47.155.dhcp.conference.apricot.net (PGP Universal service); Tue, 28 Feb 2012 06:07:12 +0530 X-PGP-Universal: processed; by 47.155.dhcp.conference.apricot.net on Tue, 28 Feb 2012 06:07:12 +0530 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F4BCD01.2090401@isdg.net> References: <4F4BCD01.2090401@isdg.net> Date: Tue, 28 Feb 2012 05:57:44 +0530 To: Hector Santos From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 00:37:15 -0000 At 13:35 -0500 2/27/12, Hector Santos wrote: >If it doesn't already exist or not considered in the past as an >unfeasible concept, I am interest in seeing if this is something >worth pursuing. One (not the only, Ohta replied with another) of the oft-cited obstacles is the presence of only one RCODE field in the packet. (What if one query would be NXDOMAIN and the other has an answer?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From paul@redbarn.org Mon Feb 27 16:49:39 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DBB21F8678 for ; Mon, 27 Feb 2012 16:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lue+9cd9gRK7 for ; Mon, 27 Feb 2012 16:49:38 -0800 (PST) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id B04DF21F8674 for ; Mon, 27 Feb 2012 16:49:38 -0800 (PST) Received: from [IPv6:2001:559:8000:cb:d4ad:21c8:afd4:e42e] (unknown [IPv6:2001:559:8000:cb:d4ad:21c8:afd4:e42e]) by ss.vix.com (Postfix) with ESMTP id 76599EBC8D; Tue, 28 Feb 2012 00:49:38 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F4C24A0.2010804@redbarn.org> Date: Tue, 28 Feb 2012 00:49:36 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Edward Lewis References: <4F4BCD01.2090401@isdg.net> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org, Hector Santos Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 00:49:39 -0000 On 2012-02-28 12:27 AM, Edward Lewis wrote: > At 13:35 -0500 2/27/12, Hector Santos wrote: >> If it doesn't already exist or not considered in the past as an >> unfeasible concept, I am interest in seeing if this is something >> worth pursuing. > > One (not the only, Ohta replied with another) of the oft-cited > obstacles is the presence of only one RCODE field in the packet. (What > if one query would be NXDOMAIN and the other has an answer?) > indeed, this is why multiple queries were not supported in the original DNS, and it's why EDNS doesn't have it either. the number of signalling bits needed to explain what went on with the multiple queries made folks' heads explode. the logic is still online if you want to see it: . From joe.abley@icann.org Mon Feb 27 16:55:47 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CE621F8702 for ; Mon, 27 Feb 2012 16:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8WYWZAXKT+N for ; Mon, 27 Feb 2012 16:55:47 -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 930BF21F86FD for ; Mon, 27 Feb 2012 16:55:47 -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; Mon, 27 Feb 2012 16:55:46 -0800 From: Joe Abley To: Paul Vixie Date: Mon, 27 Feb 2012 16:55:45 -0800 Thread-Topic: [DNSOP] Batch Multiple Query Packet Thread-Index: Acz1s7R3uhdbXrLISuy5IfNQwLNrMA== Message-ID: <8B79F72D-96D2-4363-A563-5397F5EA8760@icann.org> References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> In-Reply-To: <4F4C24A0.2010804@redbarn.org> 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: Hector Santos , "dnsop@ietf.org" , Edward Lewis Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 00:55:48 -0000 On 2012-02-27, at 19:49, Paul Vixie wrote: > On 2012-02-28 12:27 AM, Edward Lewis wrote: >> At 13:35 -0500 2/27/12, Hector Santos wrote: >>> If it doesn't already exist or not considered in the past as an >>> unfeasible concept, I am interest in seeing if this is something >>> worth pursuing. >>=20 >> One (not the only, Ohta replied with another) of the oft-cited >> obstacles is the presence of only one RCODE field in the packet. (What >> if one query would be NXDOMAIN and the other has an answer?) >=20 > indeed, this is why multiple queries were not supported in the original > DNS, and it's why EDNS doesn't have it either. Isn't that really an argument against multiple responses being carried in t= he same packet, rather than multiple queries? I'll observe that there are exciting amplification opportunities in a world= where a single packet could trigger multiple large responses, though :-) Joe From Ed.Lewis@neustar.biz Mon Feb 27 17:03:57 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DF821E8015 for ; Mon, 27 Feb 2012 17:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYDng7jqg6D9 for ; Mon, 27 Feb 2012 17:03:57 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id B0ED721E800C for ; Mon, 27 Feb 2012 17:03:56 -0800 (PST) Received: from 47.155.dhcp.conference.apricot.net (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q1S12vvP061958; Mon, 27 Feb 2012 20:03:45 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [220.247.155.47] by 47.155.dhcp.conference.apricot.net (PGP Universal service); Tue, 28 Feb 2012 06:33:50 +0530 X-PGP-Universal: processed; by 47.155.dhcp.conference.apricot.net on Tue, 28 Feb 2012 06:33:50 +0530 Mime-Version: 1.0 Message-Id: In-Reply-To: <8B79F72D-96D2-4363-A563-5397F5EA8760@icann.org> References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <8B79F72D-96D2-4363-A563-5397F5EA8760@icann.org> Date: Tue, 28 Feb 2012 06:32:53 +0530 To: "dnsop@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 01:03:57 -0000 At 16:55 -0800 2/27/12, Joe Abley wrote: >I'll observe that there are exciting amplification opportunities in a >world where a single packet could trigger multiple large responses, though :-) Yes, please, let's not. ;) Size amplification is already a problem. And, this would make monitoring extra hard ("how many responses were supposed to be sent?) and, well, just try to write the "re-assembly" code, trying to collect the responses to the original API call. An especially unpleasant place in the afterlife is reserved for whomever enables this. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From fanf2@hermes.cam.ac.uk Mon Feb 27 17:56:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C0D21E803D for ; Mon, 27 Feb 2012 17:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dJrQCp+HUVh for ; Mon, 27 Feb 2012 17:56:40 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id A48AA21E803B for ; Mon, 27 Feb 2012 17:56:40 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from [213.205.233.35] (port=56443 helo=[10.168.152.4]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1S2CIw-0007CF-X3 (Exim 4.72) (return-path ); Tue, 28 Feb 2012 01:56:38 +0000 References: <4F4BCD01.2090401@isdg.net> In-Reply-To: <4F4BCD01.2090401@isdg.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Tony Finch Date: Tue, 28 Feb 2012 01:56:33 +0000 To: Hector Santos Sender: Tony Finch Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 01:56:41 -0000 On 27 Feb 2012, at 18:35, Hector Santos wrote: > I am interesting to find information about past or possible current intere= st regarding the support of a Batch single call of multiple query packets. It isn't necessary to add protocol support, since you can already send multi= ple concurrent queries on a single socket. Tony. -- f.anthony.n.finch http://dotat.at/= From hsantos@isdg.net Mon Feb 27 19:28:46 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D194921F8596 for ; Mon, 27 Feb 2012 19:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89tfFz6YudI9 for ; Mon, 27 Feb 2012 19:28:46 -0800 (PST) Received: from mail.catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B464A21F8594 for ; Mon, 27 Feb 2012 19:28:45 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1876; t=1330399718; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=eFcAe+qyuAL6fz5bFJDkm02k1lQ=; b=hkbxMO3sUlp5i0Kie5In lm1RjojmK+/xW+HXrFk6ojPIIs3FN0kGOzfF33n+Dg3/qz06wahhafKHOG0MuABA IgkdJ6XeDyuLbRBfvME9Do0K+4o7SYLc5o1GqOy4wi1I2I2g4rA8utcFaUUAfWsy rwLrF66+FcPT22g9Scc2ZRU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for dnsop@ietf.org; Mon, 27 Feb 2012 22:28:38 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3601557770.93496.2892; Mon, 27 Feb 2012 22:28:37 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1876; t=1330399470; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=aRYkk50 p8W/wgJmRSZVpuz+Sb2aLUOCVxiihL1U8bUs=; b=Sv9H7+yCMrm2YLihkvAzMYI Y17mDt/s0GPSJBXrRYpyRAcblpiDJxcfqocW/RE2H7XgzQx9inU+pPM4rzWekKi+ 06Urm9P6Ox/8qCCSKVXWu8a9v74ZpOVxXYijKTGP4jyFhuKYsKgYA2OrPH48Lwkh lu3z8LoSMpM03LsbBKbs= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for dnsop@ietf.org; Mon, 27 Feb 2012 22:24:30 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4200492892.19816.7176; Mon, 27 Feb 2012 22:24:29 -0500 Message-ID: <4F4C49D3.4010300@isdg.net> Date: Mon, 27 Feb 2012 22:28:19 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: dnsop@ietf.org References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> In-Reply-To: <4F4C24A0.2010804@redbarn.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 03:28:46 -0000 Paul Vixie wrote: > On 2012-02-28 12:27 AM, Edward Lewis wrote: >> At 13:35 -0500 2/27/12, Hector Santos wrote: >>> If it doesn't already exist or not considered in the past as an >>> unfeasible concept, I am interest in seeing if this is something >>> worth pursuing. >> One (not the only, Ohta replied with another) of the oft-cited >> obstacles is the presence of only one RCODE field in the packet. (What >> if one query would be NXDOMAIN and the other has an answer?) >> > > indeed, this is why multiple queries were not supported in the original > DNS, and it's why EDNS doesn't have it either. the number of signalling > bits needed to explain what went on with the multiple queries made > folks' heads explode. the logic is still online if you want to see it: > . Thanks Paul. Great material. I'm just winging it at this point. First, I was focusing on the batching of related types, i.e. a protocol with new RR type but has an initial default intro record and fallback to TXT. The goal is to have a single call that will yield a managed result to assist with the current concerns and waste associated with the migration of TXT to the new RR type usage. Second, I considered there is no room for a packet count, but I was thinking of simply bundling two separate packets, i.e. 2*RR for the UPD send and how would the servers read this. If DNS servers will barf, then never mind. :) But if its offers a way to perform this concept with no breakage, perhaps the server will just read the first one and act on it or it will process the residual packet as well. Of course, the client will still need to manage the responses with all the potential delays. Again, just winging it. I don't like kludges. :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From marc.lampo@eurid.eu Mon Feb 27 23:35:03 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D172421F8615 for ; Mon, 27 Feb 2012 23:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtUAzTIfUTnC for ; Mon, 27 Feb 2012 23:35:01 -0800 (PST) Received: from cuda.eurid.eu (cuda.eurid.eu [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4C23721E800F for ; Mon, 27 Feb 2012 23:35:00 -0800 (PST) X-ASG-Debug-ID: 1330414498-02dadd06672211a0001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id fFs4COSBnqV8dClU; Tue, 28 Feb 2012 08:34:58 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 0EF63E408B; Tue, 28 Feb 2012 08:34:58 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHvqAT-a3AeF; Tue, 28 Feb 2012 08:34:57 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id F0367E4050; Tue, 28 Feb 2012 08:34:57 +0100 (CET) From: "Marc Lampo" To: "'Hector Santos'" , References: <4F4BCD01.2090401@isdg.net> In-Reply-To: <4F4BCD01.2090401@isdg.net> Date: Tue, 28 Feb 2012 08:34:57 +0100 (CET) X-ASG-Orig-Subj: RE: [DNSOP] Batch Multiple Query Packet Message-ID: <005001ccf5eb$78c02600$6a407200$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Acz1fp3bn863TovfRViZQf19jfDWIwAbCVGw Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1330414498 X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 07:35:03 -0000 Hello, By "single call", do you mean : ? "single query packet" (holding multiple questions) ? (I think this was part of EDNS1) ? "single TCP session" ? Where I believe there is no statement that forbids sending multiple, subsequent, queries over a single TCP connection. --> "batching multiple queries over a single TCP session" is already allowed. Beware ! Some name server implementations have implicit, sometimes configurable, maximum number of queries they accept over a single TCP session. Kind regards, Marc Lampo Security Officer EURid (for .eu) -----Original Message----- From: Hector Santos [mailto:hsantos@isdg.net] Sent: 27 February 2012 07:36 PM To: dnsop@ietf.org Subject: [DNSOP] Batch Multiple Query Packet I am interesting to find information about past or possible current interest regarding the support of a Batch single call of multiple query packets. If it doesn't already exist or not considered in the past as an unfeasible concept, I am interest in seeing if this is something worth pursuing. Technical Background reasoning. With the advent of new protocols, especially those offering a domain policy construct, the TXT record is used as the fastest entry point with the widest support for query resolution. Yet there are (at least were) technical concerns that this not serve to benefit DNS for large scale usage, therefore considerations are giving to include a migration path to use new registration of RR types. This migration path comes with the recognition for a short term overhead of using a dual type query concept and long term hope for the new RR type to become the non-overhead single query satisfying result. The overall issue is two folds: 1) one where publishers may have to redundantly create two records and the DNS resolvers will always have to do a two queries to maximize widest support, and 2) The continued possible dearth of DNS servers (see RFC 3597 "Handling of Unknown DNS Resource Record (RR) Types") that do not support unnamed RR types and/or the recursion requirement. If DNS server offered support for a Batch Query of multiple packets under a single call, this may help with the above migration overhead concerns. Is this something worth pursuing as a new I-D for DNS servers? Thanks -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From shane@isc.org Tue Feb 28 01:02:58 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BCD21F872F for ; Tue, 28 Feb 2012 01:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNvJGs9gtzd2 for ; Tue, 28 Feb 2012 01:02:57 -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 9DE5621F872A for ; Tue, 28 Feb 2012 01:02:57 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 1F3B0C941E; Tue, 28 Feb 2012 09:02:40 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-desktop (unknown [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id EAFD4216C31; Tue, 28 Feb 2012 09:02:38 +0000 (UTC) (envelope-from shane@isc.org) Date: Tue, 28 Feb 2012 10:02:27 +0100 From: Shane Kerr To: Paul Vixie Message-ID: <20120228100227.214bb6ef@shane-desktop> In-Reply-To: <4F4C24A0.2010804@redbarn.org> References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 09:02:58 -0000 Paul, (Possibly my answer belongs on dnsex not dnsop, but oh well.) On Tuesday, 2012-02-28 00:49:36 +0000, Paul Vixie wrote: > On 2012-02-28 12:27 AM, Edward Lewis wrote: > > At 13:35 -0500 2/27/12, Hector Santos wrote: > >> If it doesn't already exist or not considered in the past as an > >> unfeasible concept, I am interest in seeing if this is something > >> worth pursuing. > > > > One (not the only, Ohta replied with another) of the oft-cited > > obstacles is the presence of only one RCODE field in the packet. > > (What if one query would be NXDOMAIN and the other has an answer?) > > > > indeed, this is why multiple queries were not supported in the > original DNS, and it's why EDNS doesn't have it either. the number of > signalling bits needed to explain what went on with the multiple > queries made folks' heads explode. the logic is still online if you > want to see it: . I think we're missing a potential great opportunity here by thinking too small. Rather than mucking about with QDCOUNT and breaking old servers, why not just move additional queries into EDNS(n)? So, the idea is to support additional queries by effectively encapsulating them safely into the EDNS space. Basically, you say "here is my question, and if you know the multiple-query DNS extension then please give me those answers too". So for old servers they treat it as an old-style question, and get old-style answers. New servers will give additional information. So on the query side you'd need a field with the "real" QCOUNT, and then a set of additional QNAME/QTYPE/QCLASS entries, possibly like the normal question section, although we can also consider optimizing this a bit by requiring the same QCLASS for all questions for example. Here's the big win I think... On the answer side, you actually don't need to preserve existing DNS format at all. This is because the server knows that the client supports this wacky new multi-question format. That means that we can design a packet format that ACTUALLY MAKES SENSE!!! Consider the possibilities there! We can eliminate the ridiculous waste of 16-bit fields that only ever use one value; we can align the packet so that the variable length data always comes at the end; we can put a massive nonce in; and so on. I don't think this solves with my personal pet peeve (the need to send concurrent A and AAAA queries), but it does provide a necessary piece of the solution. -- Shane From mohta@necom830.hpcl.titech.ac.jp Tue Feb 28 02:32:39 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEEB21F85D8 for ; Tue, 28 Feb 2012 02:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.318 X-Spam-Level: X-Spam-Status: No, score=0.318 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LfKiTHpA+Y8 for ; Tue, 28 Feb 2012 02:32:39 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 0468921F85FC for ; Tue, 28 Feb 2012 02:32:37 -0800 (PST) Received: (qmail 9145 invoked from network); 28 Feb 2012 10:51:28 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 28 Feb 2012 10:51:28 -0000 Message-ID: <4F4CAD21.9080508@necom830.hpcl.titech.ac.jp> Date: Tue, 28 Feb 2012 19:32:01 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dnsop@ietf.org References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <4F4C49D3.4010300@isdg.net> In-Reply-To: <4F4C49D3.4010300@isdg.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 10:32:39 -0000 Hector Santos wrote: > First, I was focusing on the batching of related types, i.e. a protocol > with new RR type but has an initial default intro record and fallback to > TXT. The goal is to have a single call that will yield a managed result > to assist with the current concerns and waste associated with the > migration of TXT to the new RR type usage. That's doable without multiple queries with a QTYPE=NEWTYPE, which matches both NEWTYPE and TXT. However, there is a caching problem as is documented in RFC1035. Masataka Ohta From paul@redbarn.org Tue Feb 28 09:43:50 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BAA21F86BB for ; Tue, 28 Feb 2012 09:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6cUvtY76Gdl for ; Tue, 28 Feb 2012 09:43:49 -0800 (PST) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id 528D621F86B5 for ; Tue, 28 Feb 2012 09:43:49 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id AC25FA1051; Tue, 28 Feb 2012 17:43:47 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from [IPv6:2001:4f8:3:30:3060:65aa:d1b3:b558] (unknown [IPv6:2001:4f8:3:30:3060:65aa:d1b3:b558]) by nsa.vix.com (Postfix) with ESMTP id 7FA89A1049; Tue, 28 Feb 2012 17:43:47 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F4D1253.1070107@redbarn.org> Date: Tue, 28 Feb 2012 17:43:47 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Hector Santos References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <4F4C49D3.4010300@isdg.net> In-Reply-To: <4F4C49D3.4010300@isdg.net> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 17:43:50 -0000 On 2/28/2012 3:28 AM, Hector Santos wrote: > Paul Vixie wrote: >> ... . > > Thanks Paul. Great material. > > I'm just winging it at this point. > > First, I was focusing on the batching of related types, i.e. a > protocol with new RR type but has an initial default intro record and > fallback to TXT. The goal is to have a single call that will yield a > managed result to assist with the current concerns and waste > associated with the migration of TXT to the new RR type usage. the way this was handled for MX was to have A (and later AAAA) as additional data for the MX QTYPE. we should have made QTYPE AAAA include type A as additional data. we still can. we should have amended QTYPE A to include type AAAA as additional data. we still can. using additional data for this is great since if it's missing you query for it but it won't always be missing. > Second, I considered there is no room for a packet count, but I was > thinking of simply bundling two separate packets, i.e. 2*RR for the > UPD send and how would the servers read this. RCODE FORMERR. this means the initiator would have to be prepared to try again with discrete queries. this is a form of protocol negotiation -- the fact of a responder's nonsupport would have to be discovered (and cached "for a while") by each initiator. this is already happening for EDNS. i would recommend against adding more responder state to initiators. this would also mean that when it works you've got one round trip and when it doesn't work you've got either three (assuming you don't blast #2 and #3 without inter-record gap) or two round trips (if you use blast on #2 and #3.) > If DNS servers will barf, then never mind. :) yes. > But if its offers a way to perform this concept with no breakage, > perhaps the server will just read the first one and act on it or it > will process the residual packet as well. Of course, the client will > still need to manage the responses with all the potential delays. > > Again, just winging it. I don't like kludges. :) please consider additional data, or blast. paul From nweaver@icsi.berkeley.edu Tue Feb 28 09:57:49 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5F921F86EB for ; Tue, 28 Feb 2012 09:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bDmrxD+uPhm for ; Tue, 28 Feb 2012 09:57:49 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 40ED021F86F1 for ; Tue, 28 Feb 2012 09:57:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 02EF42C403B for ; Tue, 28 Feb 2012 09:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DFGsKfMAAulR; Tue, 28 Feb 2012 09:57:48 -0800 (PST) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id B6FB42C400D; Tue, 28 Feb 2012 09:57:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <4F4D1253.1070107@redbarn.org> Date: Tue, 28 Feb 2012 09:57:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <26A023FF-8E29-4737-9589-B563D84EFD66@icsi.berkeley.edu> References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <4F4C49D3.4010300@isdg.net> <4F4D1253.1070107@redbarn.org> To: dnsop@ietf.org X-Mailer: Apple Mail (2.1257) Cc: Nicholas Weaver Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 17:57:49 -0000 Just some BotE: Overhead for each DNS datagram (on an Ethernet) is 8 B = for the Ethernet Preamble, 14B for the Ethernet header, 20B for the IP = header, and 8 bytes for the UDP header, for a total of 50B. Assuming the question is 50B, and the answer is 150B, the overhead saved = is Not That Much by coalesing two requests into one packet: you only = save 100B of overhead for communicating 400B of data, which IS non zero, = but not enough to really worry about. But since if you could coalesce you could do parallel, this savings = doesn't help latency much at all: just the transit time for 50B out and = 50B back. If anything, parallel will be BETTER on the latency since = batching would probably require a coalesced response, while parallel is = just that, parallel, so if the first record is more useful, it can be = acted on immediately. From paul@redbarn.org Tue Feb 28 10:04:21 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2835821F8499 for ; Tue, 28 Feb 2012 10:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjsXD2tWx0Vz for ; Tue, 28 Feb 2012 10:04:20 -0800 (PST) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5157921F841B for ; Tue, 28 Feb 2012 10:04:20 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 7DE3BA1054; Tue, 28 Feb 2012 18:04:12 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from [IPv6:2001:4f8:3:30:3060:65aa:d1b3:b558] (unknown [IPv6:2001:4f8:3:30:3060:65aa:d1b3:b558]) by nsa.vix.com (Postfix) with ESMTP id 583C7A1051; Tue, 28 Feb 2012 18:04:12 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F4D171C.7050600@redbarn.org> Date: Tue, 28 Feb 2012 18:04:12 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Nicholas Weaver References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <4F4C49D3.4010300@isdg.net> <4F4D1253.1070107@redbarn.org> <26A023FF-8E29-4737-9589-B563D84EFD66@icsi.berkeley.edu> In-Reply-To: <26A023FF-8E29-4737-9589-B563D84EFD66@icsi.berkeley.edu> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 18:04:21 -0000 On 2/28/2012 5:57 PM, Nicholas Weaver wrote: > But since if you could coalesce you could do parallel, this savings doesn't help latency much at all: just the transit time for 50B out and 50B back. If anything, parallel will be BETTER on the latency since batching would probably require a coalesced response, while parallel is just that, parallel, so if the first record is more useful, it can be acted on immediately. parallel (what i called "blast") is great solution for things that don't run at scale. but the lock-step serialization that we get from the MX approach (where the A/AAAA RRset may be in the additional data section and so we have to wait for the first answer before we ask the second or third question) has a feedback loop effect on rate limiting. it's not as good as tcp windowing but it does tend to avoid WRED in core and edge router egress buffers. all i'm saying is, we have to be careful about too much parallelism since UDP unlike TCP has no windowing of its own. From nweaver@ICSI.Berkeley.EDU Tue Feb 28 10:08:34 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326B521F86B2 for ; Tue, 28 Feb 2012 10:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sHEDJtFfIxH for ; Tue, 28 Feb 2012 10:08:33 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id B240921F8498 for ; Tue, 28 Feb 2012 10:08:33 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A70DB2C4036; Tue, 28 Feb 2012 10:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kN-0+adeosSt; Tue, 28 Feb 2012 10:08:33 -0800 (PST) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 602862C400D; Tue, 28 Feb 2012 10:08:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <4F4D171C.7050600@redbarn.org> Date: Tue, 28 Feb 2012 10:08:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <4F4C49D3.4010300@isdg.net> <4F4D1253.1070107@redbarn.org> <26A023FF-8E29-4737-9589-B563D84EFD66@icsi.berkeley.edu> <4F4D171C.7050600@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.1257) Cc: dnsop@ietf.org, Nicholas Weaver Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 18:08:34 -0000 On Feb 28, 2012, at 10:04 AM, Paul Vixie wrote: > On 2/28/2012 5:57 PM, Nicholas Weaver wrote: >> But since if you could coalesce you could do parallel, this savings = doesn't help latency much at all: just the transit time for 50B out and = 50B back. If anything, parallel will be BETTER on the latency since = batching would probably require a coalesced response, while parallel is = just that, parallel, so if the first record is more useful, it can be = acted on immediately. >=20 > parallel (what i called "blast") is great solution for things that = don't > run at scale. but the lock-step serialization that we get from the MX > approach (where the A/AAAA RRset may be in the additional data section > and so we have to wait for the first answer before we ask the second = or > third question) has a feedback loop effect on rate limiting. it's not = as > good as tcp windowing but it does tend to avoid WRED in core and edge > router egress buffers. >=20 > all i'm saying is, we have to be careful about too much parallelism > since UDP unlike TCP has no windowing of its own. We don't need to be "careful" on this until you are talking about ~10 KB = of data or more in a single transaction with no interactions, because = before then TCP has the same dynamics due to the initial window size = (with browsers opening 4+ connections!), and this doesn't seem to bother = people. From paul@redbarn.org Tue Feb 28 10:40:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315C321F85EE for ; Tue, 28 Feb 2012 10:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbLBY-TPQcbz for ; Tue, 28 Feb 2012 10:40:31 -0800 (PST) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7334021F85D2 for ; Tue, 28 Feb 2012 10:40:31 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 98C2AA1042; Tue, 28 Feb 2012 18:40:30 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from [IPv6:2001:4f8:3:30:3060:65aa:d1b3:b558] (unknown [IPv6:2001:4f8:3:30:3060:65aa:d1b3:b558]) by nsa.vix.com (Postfix) with ESMTP id 6FC3BA1031; Tue, 28 Feb 2012 18:40:30 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F4D1F9E.5090003@redbarn.org> Date: Tue, 28 Feb 2012 18:40:30 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Shane Kerr References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <20120228100227.214bb6ef@shane-desktop> In-Reply-To: <20120228100227.214bb6ef@shane-desktop> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 28 Feb 2012 18:40:32 -0000 On 2/28/2012 9:02 AM, Shane Kerr wrote: > Paul, > > (Possibly my answer belongs on dnsex not dnsop, but oh well.) i've heard recently that dns is exy. > > . > I think we're missing a potential great opportunity here by thinking > too small. > > Rather than mucking about with QDCOUNT and breaking old servers, why > not just move additional queries into EDNS(n)? So, the idea is to > support additional queries by effectively encapsulating them safely > into the EDNS space. i'd start over with a new port number first. dns wire encoding is already wildly complicated. > Basically, you say "here is my question, and if you know the > multiple-query DNS extension then please give me those answers too". So > for old servers they treat it as an old-style question, and get > old-style answers. New servers will give additional information. if the EDNS option for this just had an array of additional QTYPE, such that the real QNAME and QCLASS pertained to all of these additional questions, then i could definitely see value in this. the response's OPT option would include the list of qtypes which were found to be non-empty. all of the rrsets would be in the answer section. > ... > Here's the big win I think... > ... > That means that we can design a packet format that ACTUALLY MAKES > SENSE!!! Consider the possibilities there! We can eliminate the > ridiculous waste of 16-bit fields that only ever use one value; we can > align the packet so that the variable length data always comes at the > end; we can put a massive nonce in; and so on. i think we'd slab the rrsets, put the signatures on as metadata to the slabs (having no names of their own), and a lot of other things. it's worth scribbling down what we'd do in the packet format if we could start over, even though i don't think we can start over. paul From shane@isc.org Wed Feb 29 01:23:35 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C495C21F87C8 for ; Wed, 29 Feb 2012 01:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv3BgpyN6rKl for ; Wed, 29 Feb 2012 01:23:35 -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 C34AF21F87B7 for ; Wed, 29 Feb 2012 01:23:34 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id C027FC9423; Wed, 29 Feb 2012 09:23:22 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-desktop (unknown [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B26FC216C31; Wed, 29 Feb 2012 09:23:21 +0000 (UTC) (envelope-from shane@isc.org) Date: Wed, 29 Feb 2012 10:22:55 +0100 From: Shane Kerr To: Paul Vixie Message-ID: <20120229102255.74fa4291@shane-desktop> In-Reply-To: <4F4D1F9E.5090003@redbarn.org> References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <20120228100227.214bb6ef@shane-desktop> <4F4D1F9E.5090003@redbarn.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 29 Feb 2012 09:23:35 -0000 Paul, On Tuesday, 2012-02-28 18:40:30 +0000, Paul Vixie wrote: > > > . > > I think we're missing a potential great opportunity here by thinking > > too small. > > > > Rather than mucking about with QDCOUNT and breaking old servers, why > > not just move additional queries into EDNS(n)? So, the idea is to > > support additional queries by effectively encapsulating them safely > > into the EDNS space. > > i'd start over with a new port number first. dns wire encoding is > already wildly complicated. Ya think? ;) The main (only?) advantage of doing it with EDNS is that you can work with existing name servers. It means adding more logic to our already fabulously complicated resolvers to get full benefit, but nobody ever said DNS was easy. So possibly the logic would work like this: 1. Send query with the magic EDNS to a server. 2. If the response is in the new format, then remember that. 3. Subsequent queries go to a different port, using a new format. > > Basically, you say "here is my question, and if you know the > > multiple-query DNS extension then please give me those answers > > too". So for old servers they treat it as an old-style question, > > and get old-style answers. New servers will give additional > > information. > > if the EDNS option for this just had an array of additional QTYPE, > such that the real QNAME and QCLASS pertained to all of these > additional questions, then i could definitely see value in this. the > response's OPT option would include the list of qtypes which were > found to be non-empty. all of the rrsets would be in the answer > section. I'm curious what use cases you are thinking of, so that you want to restrict the entire collection of questions to a single QNAME/QCLASS. One use case which I can think of which fits in here is the A/AAAA case. You'd need to cache server support for efficient operations, but I think it could be a win. Another use case which fits in is getting both SPF records and legacy TXT records when checking mail from a domain. One use case which does NOT fit in here is to translate all of the servers for an NS RRSET at once. I'd like to be able to say "here are a list of names, give me all of the A and AAAA records for all of them". Anyway, I'm curious. :) > > ... > > Here's the big win I think... > > ... > > That means that we can design a packet format that ACTUALLY MAKES > > SENSE!!! Consider the possibilities there! We can eliminate the > > ridiculous waste of 16-bit fields that only ever use one value; we > > can align the packet so that the variable length data always comes > > at the end; we can put a massive nonce in; and so on. > > i think we'd slab the rrsets, put the signatures on as metadata to the > slabs (having no names of their own), and a lot of other things. it's > worth scribbling down what we'd do in the packet format if we could > start over, even though i don't think we can start over. If we can make the equivalent of name compression more efficient, I think it could even be something that has enough operational benefit to make it worthwhile for operators. -- Shane From Ray.Bellis@nominet.org.uk Wed Feb 29 02:17:30 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E055421F88B6 for ; Wed, 29 Feb 2012 02:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.874 X-Spam-Level: X-Spam-Status: No, score=-9.874 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn-NIZvEVsvP for ; Wed, 29 Feb 2012 02:17:29 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id DAD1121F88B5 for ; Wed, 29 Feb 2012 02:17:28 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=htrTJUZVCYklJZ9R5rgh7vyAh1yA260f4h8g/cIOMkTpI6eQb39wOYJx jEIOpSRN6OUg7MZQDL5g/jE4tWLn9nBFD3VjT7T8vy1j5e3rWpgpuXoh3 DtAjmEnRPLlqDMM; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1330510649; x=1362046649; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[DNSOP]=20Batch=20Multiple=20Query=20Pa cket|Date:=20Wed,=2029=20Feb=202012=2010:17:26=20+0000 |Message-ID:=20<638707AE-5E70-43E5-921C-2F62496F7A73@nomi net.org.uk>|To:=20Paul=20Vixie=20|CC: =20Shane=20Kerr=20,=20"" =20|MIME-Version:=201.0|In-Reply-To:=20<4 F4D1F9E.5090003@redbarn.org>|References:=20<4F4BCD01.2090 401@isdg.net>=0D=0A=20=20<4F4C24A0.2010804@redbarn.org>=0D=0A=20<201202281 00227.214bb6ef@shane-desktop>=20<4F4D1F9E.5090003@redbarn .org>; bh=T3L3y8y7e9qvgAz2md+w82b7niEeuabG0uPqVl2HJ7c=; b=DcUD2JAGwtVzChJEIucrQ0+JTL+COfyG+HRFDru/wxMJ1JDAIvEDqAgd Sp4QJfLrbem7FkN+u59WMSoB0WpNIrYwZM7YRAssS3hN8/Z5ZH/+zVt2Q eapqpQZ33MbQpCv; X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="htm'217?txt'217?scan'217,208,217";a="31437436" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 29 Feb 2012 10:17:27 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Wed, 29 Feb 2012 10:17:27 +0000 From: Ray Bellis To: Paul Vixie Thread-Topic: [DNSOP] Batch Multiple Query Packet Thread-Index: AQHM9X6wUuKLAHS2PEyv0Vpsti9MOZZRdJYAgAAGHACAAImzgIAAoYEAgAEFxwA= Date: Wed, 29 Feb 2012 10:17:26 +0000 Message-ID: <638707AE-5E70-43E5-921C-2F62496F7A73@nominet.org.uk> References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <20120228100227.214bb6ef@shane-desktop> <4F4D1F9E.5090003@redbarn.org> In-Reply-To: <4F4D1F9E.5090003@redbarn.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="_005_638707AE5E7043E5921C2F62496F7A73nominetorguk_" MIME-Version: 1.0 Cc: "" , Shane Kerr Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 29 Feb 2012 10:17:31 -0000 --_005_638707AE5E7043E5921C2F62496F7A73nominetorguk_ Content-Type: multipart/alternative; boundary="_000_638707AE5E7043E5921C2F62496F7A73nominetorguk_" --_000_638707AE5E7043E5921C2F62496F7A73nominetorguk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 28 Feb 2012, at 18:40, Paul Vixie wrote: if the EDNS option for this just had an array of additional QTYPE, such that the real QNAME and QCLASS pertained to all of these additional questions, then i could definitely see value in this. the response's OPT option would include the list of qtypes which were found to be non-empty. all of the rrsets would be in the answer section. Yes, that's pretty much what was in the draft I wrote (but didn't publish) = and discussed with you during the last Prague IETF. My rationale likewise was that having constant QNAME and QCLASS but multipl= e QTYPEs should eliminate the need for multiple RCODEs. However further discussion with other folks revealed issues (ISTR around DN= SSEC?) where it would be possible to get inconsistent RCODEs for different = QTYPEs. I've attached a copy of that document. It could be resurrected if there's = sufficient interest. Ray --_000_638707AE5E7043E5921C2F62496F7A73nominetorguk_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On 28 Feb 2012, at 18:4= 0, Paul Vixie wrote:


if the EDNS option for this just had an array of additional Q= TYPE, such
that the real QNAME and QCLASS pertained to all of these addi= tional
questions, then i could definitely see value in this. the respons= e's OPT
option would include the list of qtypes which were found to benon-empty. all of the rrsets would be in the answer section.

Yes, that's pretty much what was in the draft I wrote (but didn= 't publish) and discussed with you during the last Prague IETF.
<= br>
My rationale likewise was that having constant QNAME and QCLA= SS but multiple QTYPEs should eliminate the need for multiple RCODEs.
=

However further discussion with other folks revealed is= sues (ISTR around DNSSEC?) where it would be possible to get inconsistent R= CODEs for different QTYPEs.

I've attached a c= opy of that document.  It could be resurrected if there's sufficient i= nterest.

Ray


= --_000_638707AE5E7043E5921C2F62496F7A73nominetorguk_-- --_005_638707AE5E7043E5921C2F62496F7A73nominetorguk_ Content-Type: text/plain; name="draft-bellis-dnsext-multi-qtypes.txt" Content-Description: draft-bellis-dnsext-multi-qtypes.txt Content-Disposition: attachment; filename="draft-bellis-dnsext-multi-qtypes.txt"; size=12640; creation-date="Wed, 29 Feb 2012 10:17:26 GMT"; modification-date="Wed, 29 Feb 2012 10:17:26 GMT" Content-ID: Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUi4gQmVsbGlzDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vbWluZXQgVUsNCkludGVuZGVkIHN0YXR1czog U3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyOCwgMjAxMQ0K RXhwaXJlczogU2VwdGVtYmVyIDI5LCAyMDExDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVGl0bGUNCiAgICAgICAgICAgICAgICAgIGRyYWZ0LWJlbGxpcy1kbnNleHQtbXVs dGktcXR5cGVzLTAwDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEg bWV0aG9kIGZvciBhIEROUyBjbGllbnQgdG8gcmVxdWVzdA0KICAgYWRkaXRpb25hbCBETlMgcmVj b3JkIHR5cGVzIHRvIGJlIGRlbGl2ZXJlZCBhbG9uZ3NpZGUgdGhlIHByaW1hcnkNCiAgIHJlY29y ZCB0eXBlIHNwZWNpZmllZCBpbiB0aGUgcXVlc3Rpb24gc2VjdGlvbiBvZiBhIEROUyBxdWVyeS4N Cg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1p dHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQogICBwcm92aXNpb25zIG9mIEJDUCA3 OCBhbmQgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRz IG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURikuICBOb3Rl IHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUNCiAgIHdvcmtpbmcgZG9jdW1l bnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtDQog ICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50 Ly4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBv ciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVy aWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0K ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBTZXB0ZW1iZXIgMjksIDIwMTEu DQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChjKSAyMDExIElFVEYgVHJ1c3Qg YW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQogICBkb2N1bWVudCBhdXRob3JzLiAg QWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJD UCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0KICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0 byBJRVRGIERvY3VtZW50cw0KICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5m bykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3Vt ZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMNCiAgIGNhcmVmdWxseSwgYXMgdGhl eSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdA0KICAg dG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRv Y3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMg YW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDQogICBkZXNjcmliZWQgaW4gdGhl IFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNCg0KDQoNCg0KQmVsbGlzICAgICAgICAgICAgICAg ICBFeHBpcmVzIFNlcHRlbWJlciAyOSwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgVGl0bGUgICAgICAgICAgICAgICAgICAg ICAgIE1hcmNoIDIwMTENCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMN Cg0KICAgMi4gIFRlcm1pbm9sb2d5IHVzZWQgaW4gdGhpcyBkb2N1bWVudCAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAzDQoNCiAgIDMuICBEZXNjcmlwdGlvbiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMw0KICAgICAzLjEuICBNdWx0aXBs ZSBRVFlQRSBFRE5TIE9wdGlvbiBGb3JtYXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQog ICAgIDMuMi4gIFJlc3BvbnNlIEdlbmVyYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDQNCiAgICAgICAzLjIuMS4gIFNlcnZlciBTaWRlIFByb2Nlc3NpbmcgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNA0KICAgICAgIDMuMi4yLiAgQ2xpZW50IFNp ZGUgUHJvY2Vzc2luZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1DQogICAgICAg My4yLjMuICBETlNTRUMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDUNCg0KICAgNC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2DQoNCiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25z IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNg0KDQogICA2LiAg QWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDYNCg0KICAgNy4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2DQoNCiAgIEFwcGVuZGl4IEEuICBDaGFuZ2UgTG9n IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNw0KDQogICBBdXRo b3IncyBBZGRyZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDcNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCkJlbGxpcyAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjksIDIwMTEg ICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICAgIFRpdGxlICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDExDQoNCg0KMS4gIEludHJv ZHVjdGlvbg0KDQogICBBIGNvbW1vbmx5IHJlcXVlc3RlZCBETlMgW1JGQzEwMzVdIGZlYXR1cmUg aXMgdGhlIGFiaWxpdHkgdG8gcmVjZWl2ZQ0KICAgbXVsdGlwbGUgcmVsYXRlZCByZXNvdWNlIHJl Y29yZHMgKFJScykgaW4gYSBzaW5nbGUgRE5TIHJlc3BvbnNlLg0KDQogICBGb3IgZXhhbXBsZSwg aXQgbWF5IGJlIGRlc2lyYWJsZSB0byByZWNlaXZlIGJvdGggdGhlIEEgYW5kIEFBQUENCiAgIHJl Y29yZHMgZm9yIGEgZG9tYWluIG5hbWUgdG9nZXRoZXIsIHJhdGhlciB0aGFuIGhhdmluZyB0byBp c3N1ZQ0KICAgbXVsdGlwbGUgcXVlcmllcy4NCg0KICAgVGhlIEROUyB3aXJlIHByb3RvY29sIGlu IHRoZW9yeSBzdXBwb3J0cyBoYXZpbmcgbXVsdGlwbGUgcXVlc3Rpb25zIGluDQogICBhIHNpbmds ZSBwYWNrZXQsIGJ1dCBpbiBwcmFjdGlzZSB0aGlzIGRvZXMgbm90IHdvcms6DQoNCiAgIG8gIEVh Y2ggcXVlc3Rpb24gY29uc2lzdHMgb2YgdGhlIHR1cGxlIChRTkFNRSwgUVRZUEUsIFFDTEFTUyku ICBTaW5jZQ0KICAgICAgZWFjaCBxdWVzdGlvbiBoYXMgaXRzIG93biBRTkFNRSBmaWVsZCBpdCB3 b3VsZCBiZSBwb3NzaWJsZSBmb3Igb25lDQogICAgICBuYW1lIHRvIGV4aXN0IGFuZCBhbm90aGVy IHRvIG5vdCBleGlzdCwgcmVzdWx0aW5nIGluIGFuDQogICAgICBpbmNvbnNpc3RlbnQgcmVzcG9u c2UgY29kZS4NCiAgIG8gIFRoZSBpZGVhIHRoYXQgb25seSBhIHNpbmdsZSBxdWVzdGlvbiBpcyBh bGxvd2VkIGlzIHN1ZmZpY2llbnRseQ0KICAgICAgZW50cmVuY2hlZCB0aGF0IG1hbnkgRE5TIHNl cnZlcnMgd2lsbCBzaW1wbHkgcmV0dXJuIGFuIGVycm9yIChvcg0KICAgICAgZmFpbCB0byByZXNw b25zZSBhdCBhbGwpIGlmIHRoZXkgcmVjZWl2ZSBhIHF1ZXJ5IHdpdGggYSBxdWVzdGlvbg0KICAg ICAgY291bnQgKFFEQ09VTlQpIG9mIG1vcmUgdGhhbiBvbmUuDQoNCiAgIFRvIHJlc29sdmUgYm90 aCBvZiB0aGVzZSBpc3N1ZXMsIHRoaXMgZG9jdW1lbnQgY29uc3RyYWludHMgdGhlDQogICBwcm9i bGVtIHRvIHRob3NlIGNhc2VzIHdoZXJlIG9ubHkgdGhlIFFUWVBFIHZhcmllcyBieSBzcGVjaWZ5 aW5nIGENCiAgIG5ldyBvcHRpb24gZm9yIHRoZSBFeHRlbnNpb24gTWVjaGFuaXNtcyBmb3IgRE5T IChFRE5TIFtSRkMyNjcxXSkgdGhhdA0KICAgY29udGFpbnMgYW4gYWRkaXRpb25hbCBsaXN0IG9m IFFUWVBFIHZhbHVlcyB0aGF0IHRoZSBjbGllbnQgd2lzaGVzIHRvDQogICByZWNlaXZlIGluIGFk ZGl0aW9uIHRvIHRoYXQgaW4gdGhlIHByaW1hcnkgcXVlc3Rpb24uDQoNCg0KMi4gIFRlcm1pbm9s b2d5IHVzZWQgaW4gdGhpcyBkb2N1bWVudA0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1V U1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwg IlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhp cw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZD MjExOV0uDQoNCg0KMy4gIERlc2NyaXB0aW9uDQoNCjMuMS4gIE11bHRpcGxlIFFUWVBFIEVETlMg T3B0aW9uIEZvcm1hdA0KDQogICBUaGUgb3ZlcmFsbCBmb3JtYXQgb2YgYW4gRUROUyBvcHRpb24g aXMgc2hvd24gZm9yIHJlZmVyZW5jZSBiZWxvdywNCiAgIHBlciBSRkMgMjY3MSwgZm9sbG93ZWQg YnkgdGhlIG9wdGlvbiBzcGVjaWZpYyBkYXRhOg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCZWxsaXMg ICAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI5LCAyMDExICAgICAgICAgICAgICAg W1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBUaXRsZSAgICAg ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMQ0KDQoNCiAgICAgICArLS0tKy0tLSstLS0rLS0t Ky0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKw0KICAgIDA6 IHwgICAgICAgICAgICAgICAgICAgICAgICAgIE9QVElPTi1DT0RFICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICAgICAgKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0t LSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSsNCiAgICAyOiB8ICAgICAgICAgICAgICAgICAgICAg ICAgIE9QVElPTi1MRU5HVEggICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICstLS0r LS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSst LS0rDQogICAgNDogfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAvICAgICAgICAgICAgICAgICAgICAgICAgICBP UFRJT04tREFUQSAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KICAgICAgIC8gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvDQog ICAgICAgKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0t LSstLS0rLS0tKy0tLSsNCg0KDQogICBPUFRJT04tQ09ERTogVEJEIGJ5IElBTkENCg0KICAgT1BU SU9OLUxFTkdUSDogU2l6ZSAoaW4gb2N0ZXRzKSBvZiBPUFRJT04tREFUQS4NCg0KICAgT1BUSU9O LURBVEE6IE9wdGlvbiBzcGVjaWZpYywgYXMgYmVsb3c6DQoNCg0KICAgICAgICAgICAgICAgICAg ICArMCAoTVNCKSAgICAgICAgICAgICAgICAgICAgICAgICAgICArMSAoTFNCKQ0KICAgICAgICst LS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0t LSstLS0rDQogICAgMDogfFFURHwgICByZXNlcnZlZCAgICB8ICBRVENPVU5UICB8ICAgICAgICAg ICBRVDEgKE1TQikgICAgICAgICAgIHwNCiAgICAgICArLS0tKy0tLSstLS0rLS0tKy0tLSstLS0r LS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKw0KICAgIDI6IHwgICAgICAg ICAgIFFUMSAoTFNCKSAgICAgICAgICAgfCAgICAgICAgICAgICAgLi4uICAgICAgICAgICAgICB8 DQogICAgICAgKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0t Ky0tLSstLS0rLS0tKy0tLSsNCiAgICAgICB8ICAgICAgICAgICAgICAuLi4gICAgICAgICAgICAg Ly8vICAgICAgICAgIFFUbiAoTVNCKSAgICAgICAgICAgfA0KICAgICAgICstLS0rLS0tKy0tLSst LS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rDQogICAg ICAgfCAgICAgICAgICAgUVRuIChMU0IpICAgICAgICAgICB8DQogICAgICAgKy0tLSstLS0rLS0t Ky0tLSstLS0rLS0tKy0tLSstLS0rDQoNCg0KICAgUVREOiB0aGlzIGJpdCBpbmRpY2F0ZXMgdGhl IGRpcmVjdGlvbiBvZiB0aGUgcGFja2V0LiAgSXQgTVVTVCBiZQ0KICAgY2xlYXIgKDApIGluIGEg cXVlcnkgYW5kIHNldCAoMSkgaW4gYSByZXNwb25zZS4NCg0KICAgUVRDT1VOVDogYSAzIGJpdCBm aWVsZCB3aXRoIHJhbmdlIDAgLi4gNyBzcGVjaWZ5aW5nIHRoZSBudW1iZXIgb2YgUVQNCiAgIGZp ZWxkcyB0byBmb2xsb3cuDQoNCiAgIFFUbjogYSAyIGJ5dGUgZmllbGQgKE1TQiBmaXJzdCkgc3Bl Y2lmeWluZyBhIEROUyBSUiB0eXBlLiAgVGhlIFJSDQogICB0eXBlIE1VU1QgYmUgZm9yIGEgcmVh bCByZXNvdXJjZSByZWNvcmQsIGFuZCBNVVNUIE5PVCByZWZlciB0byBhDQogICBwc2V1ZG8gUlIg dHlwZSBzdWNoIGFzICJJWEZSIiwgIlRTSUciLCBldGMuDQoNCjMuMi4gIFJlc3BvbnNlIEdlbmVy YXRpb24NCg0KMy4yLjEuICBTZXJ2ZXIgU2lkZSBQcm9jZXNzaW5nDQoNCiAgIEEgY29uZm9ybWlu ZyBzZXJ2ZXIgdGhhdCByZWNlaXZlcyBhIE11bHRpcGxlIFFUWVBFIE9wdGlvbiBpbiBhIHF1ZXJ5 DQogICBNVVNUIHJldHVybiBhIE11bHRpcGxlIFFUWVBFIG9wdGlvbiBpbiBpdHMgcmVzcG9uc2Uu DQoNCiAgIFRoZSBRVEQgYml0IGluIHRoYXQgcmVzcG9uc2UgTVVTVCBiZSBzZXQgKDEpIGFzIHBy b3RlY3Rpb24gYWdhaW5zdA0KDQoNCg0KQmVsbGlzICAgICAgICAgICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAyOSwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgICAgVGl0bGUgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIw MTENCg0KDQogICBzZXJ2ZXJzIHdoaWNoIHNpbXBseSBlY2hvIHVua25vd24gRUROUyBvcHRpb25z IHZlcmJhdGltLiAgSWYgdGhlIFFURA0KICAgYml0IGluIGEgcmVzcG9uc2UgaXMgemVybyB0aGUg Y2xpZW50IE1VU1QgdHJlYXQgdGhlIHJlc3BvbnNlIGFzIGlmDQogICB0aGlzIG9wdGlvbiBpcyB1 bnN1cHBvcnRlZC4NCg0KICAgVGhlIHNlcnZlciBTSE9VTEQgYXR0ZW1wdCB0byByZXR1cm4gYW55 IHJlc291cmNlIHJlY29yZHMga25vd24gdG8gaXQNCiAgIHRoYXQgbWF0Y2ggdGhlIGFkZGl0aW9u YWwgKFFUWVBFLCBRQ0xBU1MsIFFUbikgdHVwbGVzLiAgVGhlc2UgcmVjb3Jkcw0KICAgTVVTVCBi ZSByZXR1cm5lZCBpbiB0aGUgQW5zd2VyIFNlY3Rpb24gb2YgdGhlIHJlc3BvbnNlLCBidXQgdGhl DQogICBhbnN3ZXIgZm9yIHRoZSBwcmltYXJ5IHF1ZXN0aW9uIE1VU1QgYmUgaW5jbHVkZWQgZmly c3QuDQoNCiAgIEZvciBhbnkgcGFydGljdWxhciBRVG4gaW4gdGhlIHF1ZXJ5LCBpZiB0aGUgc2Vy dmVyIHByb3ZpZGVzIGFkZHRpb25hbA0KICAgYW5zd2Vycywgb3IgaGFzIGtub3dsZWRnZSB0aGF0 IHRoZSBSUiB0eXBlIHR5cGUgZG9lcyBub3QgZXhpc3QgZm9yDQogICB0aGF0IFFOQU1FIChhICJu ZWdhdGl2ZSBhbnN3ZXIiKSwgaXQgbXVzdCBpbmNsdWRlIHRoYXQgUVRuIHZhbHVlIGluDQogICBp dHMgcmVzcG9uc2UuDQoNCiAgIEEgbmVnYXRpdmUgYW5zd2VyIGlzIHRoZXJlZm9yZSBpbmRpY2F0 ZWQgYnkgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZQ0KICAgcHJlc2VuY2Ugb2YgYSBRVG4gdmFsdWUg aW4gdGhlIE11bHRpcGxlIFFUWVBFIE9wdGlvbiBhbmQgdGhlIGFic2VuY2UNCiAgIG9mIGEgbWF0 Y2hpbmcgcmVjb3JkIGluIHRoZSBBbnN3ZXIgU2VjdGlvbi4gIFRoaXMgaXMgbmVjZXNzYXJ5IChp bg0KICAgdGhlIGFic2VuY2Ugb2YgRE5TU0VDKSB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gYWJz ZW5jZSBvZiB0aGUgcmVjb3JkDQogICBmcm9tIHRoZSB6b25lIGFuZCBhYnNlbmNlIG9mIHRoZSBy ZWNvcmQgZnJvbSB0aGUgcmVzcG9uc2UuDQoNCiAgIEFuIGF1dGhvcml0YXRpdmUgc2VydmVyIHJl Y2VpdmluZyBhIE11bHRpcGxlIFFUWVBFIE9wdGlvbiBNVVNUDQogICBhdHRlbXB0IHRvIHJldHVy biBhbGwgc3BlY2lmaWVkIFJSIHR5cGVzIGV4Y2VwdCB3aGVyZSB0aGF0IHdvdWxkDQogICByZXN1 bHQgaW4gdHJ1bmNhdGlvbiBpbiB3aGljaCBjYXNlIGl0IG1heSBvbWl0IHNvbWUgKG9yIGFsbCkg b2YgdGhlDQogICByZWNvcmRzIGZvciB0aGUgYWRkaXRpb25hbCBSUiB0eXBlcy4gIFRob3NlIFJS IHR5cGVzIE1VU1QgdGhlbiBhbHNvDQogICBiZSBvbWl0dGVkIGZyb20gdGhlIE11bHRpcGxlIFFU WVBFIE9wdGlvbiBpbiB0aGUgcmVzcG9uc2UuDQoNCiAgIEEgY2FjaGluZyByZWN1cnNpdmUgc2Vy dmVyIHJlY2VpdmluZyBhIE11bHRpcGxlIFFUWVBFIE9wdGlvbiBTSE9VTEQNCiAgIGF0dGVtcHQg dG8gZmlsbCBpdHMgcG9zaXRpdmUgYW5kIG5lZ2F0aXZlIGNhY2hlcyB3aXRoIGFsbCBvZiB0aGUN CiAgIHNwZWNpZmllZCBSUiB0eXBlcyBiZWZvcmUgcmV0dXJuaW5nIGl0cyByZXNwb25zZSB0byB0 aGUgY2xpZW50Lg0KDQogICBUT0RPOiBpcyB0aGVyZSBhIGNhc2UgZm9yIG1hbmRhdG9yeSBhbnN3 ZXJzLCBpLmUuIHRoZSBjbGllbnQgc2F5aW5nIEkNCiAgIF9yZWFsbHlfIHdhbnQgYWxsIHRoZXNl Pw0KDQozLjIuMi4gIENsaWVudCBTaWRlIFByb2Nlc3NpbmcNCg0KICAgUmVjdXJzaXZlIHJlc29s dmVycyBNQVkgdXNlIHRoaXMgbWV0aG9kIHRvIG9idGFpbiBtdWx0aXBsZSByZWNvcmRzDQogICBm cm9tIGFuIGF1dGhvcml0YXRpdmUgc2VydmVyLiAgRm9yIHRoZSBwdXJwb3NlcyBvZiBTZWN0aW9u IDUuNC4xIG9mDQogICBbUkZDMjE4MV0gYW55IGF1dGhvcml0YXRpdmUgYW5zd2VycyByZWNlaXZl ZCBNVVNUIGJlIHJhbmtlZCB0aGUgc2FtZQ0KICAgYXMgdGhlIGFuc3dlciBmb3IgdGhlIHByaW1h cnkgcXVlc3Rpb24uDQoNCjMuMi4zLiAgRE5TU0VDDQoNCiAgIElmIHRoZSBETlMgY2xpZW50IHNl dHMgdGhlICJETlNTRUMgT0siIChETykgYml0IGluIHRoZSBxdWVyeSB0aGVuIHRoZQ0KICAgc2Vy dmVyIE1VU1QgYWxzbyByZXR1cm4gdGhlIHJlbGF0ZWQgRE5TU0VDIHJlY29yZHMgdGhhdCB3b3Vs ZCBoYXZlDQogICBiZWVuIHJldHVybmVkIGluIGEgc3RhbmRhbG9uZSBxdWVyeSBmb3IgdGhlIHNh bWUgUVRZUEUuDQoNCiAgIEEgbmVnYXRpdmUgYW5zd2VyIGZyb20gYSBzaWduZWQgem9uZSBNVVNU IGNvbnRhaW4gdGhlIGFwcHJvcHJpYXRlDQogICBhdXRoZW50aWNhdGVkIGRlbmlhbCBvZiBleGlz dGVuY2UgcmVjb3JkcywgcGVyIFJGQyAzNDAzIGFuZCBSRkMgNTE1NS4NCg0KDQoNCkJlbGxpcyAg ICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjksIDIwMTEgICAgICAgICAgICAgICBb UGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIFRpdGxlICAgICAg ICAgICAgICAgICAgICAgICBNYXJjaCAyMDExDQoNCg0KICAgSW4gYSBzaWduZWQgem9uZSB0aGVy ZSBpcyBhIHRoZW9yZXRpY2FsIHJpc2sgb2YgdmFsaWQgc2lnbmF0dXJlcyBmb3INCiAgIG9uZSBS UiB0eXBlIGFuZCBpbnZhbGlkIHNpZ25hdHVyZXMgZm9yIGFub3RoZXIuICBUaGlzIGlzIHRoZSBv bmx5DQogICBjYXNlIGtub3duIHRvIHRoZSBhdXRob3Igd2hlcmUgdGhlIHJlc3BvbnNlIGNvZGUg Zm9yIGFueSBwYXJ0aWN1bGFyDQogICBRTkFNRSBtYXkgYmUgaW5jb25zaXN0ZW50IGFjcm9zcyBk aWZmZXJlbnQgUlIgdHlwZXMuDQoNCiAgIFNob3VsZCBhIHZhbGlkYXRpbmcgcmVzb2x2ZXIgcHJv ZHVjZSBOT0VSUk9SIGZvciBzb21lIFJSIHR5cGVzIGFuZA0KICAgU0VSVkZBSUwgZm9yIG90aGVy cyBpdCBNVVNUIG9taXQgdGhlIFJSIHR5cGVzIHRoYXQgZmFpbGVkIHRvIHZhbGlkYXRlDQogICBm cm9tIGl0cyByZXNwb25zZSBhbmQgZnJvbSB0aGUgUVRuIGZpZWxkcyBvbiB0aGUgTXVsdGlwbGUg UVRZUEUNCiAgIG9wdGlvbi4gIFRoZSBjbGllbnQgTUFZIHRoZW4gaW5pdGlhdGUgc3RhbmRhbG9u ZSBxdWVyaWVzIGZvciB0aG9zZSBSUg0KICAgdHlwZXMuDQoNCg0KNC4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zDQoNCiAgIFRoZSBtZXRob2QgZG9jdW1lbnRlZCBoZXJlIGRvZXMgbm90IGNoYW5n ZSBhbnkgb2YgdGhlIHNlY3VyaXR5DQogICBwcm9wZXJ0aWVzIG9mIHRoZSBETlMgcHJvdG9jb2wg aXRzZWxmLg0KDQogICBJdCBzaG91bGQgaG93ZXZlciBiZSBub3RlZCB0aGF0IHRoaXMgbWV0aG9k IGRvZXMgaW5jcmVhc2UgdGhlDQogICBwb3RlbnRpYWwgYW1wbGlmaWNhdGlvbiBmYWN0b3Igd2hl biB0aGUgRE5TIHByb3RvY29sIGlzIHVzZWQgYXMgYQ0KICAgdmVjdG9yIGZvciBhbiBkZW5pYWwg b2Ygc2VydmljZSBhdHRhY2suDQoNCg0KNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgSUFO QSBpcyByZXF1ZXN0ZWQgdG8gYXNzaWduIGEgbmV3IHZhbHVlIGluIHRoZSBETlMgRUROUzAgT3B0 aW9ucw0KICAgcmVnc2l0cnkuDQoNCg0KNi4gIEFja25vd2xlZGdlbWVudHMNCg0KICAgVGhlIGF1 dGhvciB3aXNoZXMgdG8gdGhhbmsgdGhlIGZvbGxvd2luZyBmb3IgdGhlaXIgZmVlZGJhY2sgYW5k DQogICByZXZpZXdzIGR1cmluZyB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhpcyBkb2N1bWVudDogTWlj aGFlbCBHcmFmZiwNCiAgIE1hdHRoaWpzIE1la2tpbmcsIFBhdWwgVml4aWUuDQoNCg0KNy4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMxMDM1XSAgTW9ja2FwZXRyaXMsIFAuLCAiRG9t YWluIG5hbWVzIC0gaW1wbGVtZW50YXRpb24gYW5kDQogICAgICAgICAgICAgIHNwZWNpZmljYXRp b24iLCBTVEQgMTMsIFJGQyAxMDM1LCBOb3ZlbWJlciAxOTg3Lg0KDQogICBbUkZDMjExOV0gIEJy YWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAg ICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3 Lg0KDQogICBbUkZDMjE4MV0gIEVseiwgUi4gYW5kIFIuIEJ1c2gsICJDbGFyaWZpY2F0aW9ucyB0 byB0aGUgRE5TDQogICAgICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBSRkMgMjE4MSwgSnVseSAx OTk3Lg0KDQogICBbUkZDMjY3MV0gIFZpeGllLCBQLiwgIkV4dGVuc2lvbiBNZWNoYW5pc21zIGZv ciBETlMgKEVETlMwKSIsDQogICAgICAgICAgICAgIFJGQyAyNjcxLCBBdWd1c3QgMTk5OS4NCg0K DQoNCkJlbGxpcyAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjksIDIwMTEgICAg ICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAg IFRpdGxlICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDExDQoNCg0KQXBwZW5kaXggQS4g IENoYW5nZSBMb2cNCg0KICAgTkI6IHRvIGJlIHJlbW92ZWQgYnkgdGhlIFJGQyBFZGl0b3IgYmVm b3JlIHB1YmxpY2F0aW9uLg0KDQogICBkcmFmdC1iZWxsaXMtZG5zZXh0LW11bHRpLXF0eXBlcy0w MA0KICAgICAgSW5pdGlhbCBkcmFmdA0KDQoNCkF1dGhvcidzIEFkZHJlc3MNCg0KICAgUmF5IEJl bGxpcw0KICAgTm9taW5ldCBVSw0KICAgRWRtdW5kIEhhbGxleSBSb2FkDQogICBPeGZvcmQgIE9Y NCA0RFENCiAgIFVuaXRlZCBLaW5nZG9tDQoNCiAgIFBob25lOiArNDQgMTg2NSAzMzIyMTENCiAg IEVtYWlsOiByYXkuYmVsbGlzQG5vbWluZXQub3JnLnVrDQogICBVUkk6ICAgaHR0cDovL3d3dy5u b21pbmV0Lm9yZy51ay8NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCZWxsaXMgICAgICAgICAgICAgICAgIEV4cGlyZXMgU2Vw dGVtYmVyIDI5LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCg== --_005_638707AE5E7043E5921C2F62496F7A73nominetorguk_ Content-Type: text/html; name="ATT00001.htm" Content-Description: ATT00001.htm Content-Disposition: attachment; filename="ATT00001.htm"; size=147; creation-date="Wed, 29 Feb 2012 10:17:26 GMT"; modification-date="Wed, 29 Feb 2012 10:17:26 GMT" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj48ZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_005_638707AE5E7043E5921C2F62496F7A73nominetorguk_-- From johnl@iecc.com Wed Feb 29 08:47:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3686321F8799 for ; Wed, 29 Feb 2012 08:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCxDPEblUSpn for ; Wed, 29 Feb 2012 08:47:40 -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 EAE6321F8597 for ; Wed, 29 Feb 2012 08:47:39 -0800 (PST) Received: (qmail 47918 invoked from network); 29 Feb 2012 16:47:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Feb 2012 16:47:38 -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=4f4e56aa.xn--yuvv84g.k1202; i=johnl@user.iecc.com; bh=RH8d6AItpNQXBnBSwPvmWudboHvC8wc0fFvdczBc/cI=; b=gj8YvpqtZNCiIohANPTnVDacSIY0gXKjC+Vs9evTDL0Ft175sKyOTnjJhJJ1GwnbOaTXVsv3p4L2lOs8MaSoQAnbQlzdJTCw7wRSWx9qWOjz3S97n6dpitJoi6oA9sYevgGcmjPHK0JnpPhT4XKxLKStce0rJjhMSRRiBUsZ7jw= 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=4f4e56aa.xn--yuvv84g.k1202; olt=johnl@user.iecc.com; bh=RH8d6AItpNQXBnBSwPvmWudboHvC8wc0fFvdczBc/cI=; b=IiEs8FyiWUrBkqHxoYYlXw9qlEs/WS/QmiM8Pla/arxm4fdIOY3OD9p82R8pqkEuctYez9NAA8ZBzj5aiySEXVj8rbYNFb0zQbw3EdUrLc2LdFaPviozt5C8xNWJvev4P+519XT6l2PrIY3rP+vyo8eBRMIgQpwo6fAkmQLHmZk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 29 Feb 2012 16:47:16 -0000 Message-ID: <20120229164716.36600.qmail@joyce.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: <20120229102255.74fa4291@shane-desktop> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: shane@isc.org Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 29 Feb 2012 16:47:41 -0000 >The main (only?) advantage of doing it with EDNS is that you can work >with existing name servers. It means adding more logic to our already >fabulously complicated resolvers to get full benefit, but nobody ever >said DNS was easy. If you're adding logic to servers and clients, why couldn't some of that logic listen on a different port? But honestly, I don't see what problem is being solved here. The original motivation was to ask for SPF and TXT records at the same time, rather than sending two queries. You don't need a new version of DNS to handle that, all you need is a kludge in your server that knows that when it gets a query for one, it can return the other in the additional section. MX queries already have their kludge, returning A and AAAA records. The meta-reason for doing two queries is that it's still so hard to provision new RR types that people fake them with TXT. If we're going to hack on our DNS software, I'd rather work on that. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From ondrej.sury@nic.cz Wed Feb 29 10:03:40 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5A21F86F6; Wed, 29 Feb 2012 10:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, GB_VISITOURSITE=2, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixYJFigWgBvh; Wed, 29 Feb 2012 10:03:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 13C7121F86D3; Wed, 29 Feb 2012 10:03:39 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id A96522A2EF1; Wed, 29 Feb 2012 19:03:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330538618; bh=WsQiALbBkt8d3NrSACG9Ia0qtpCgP6lRZLpHRExqaIs=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=WxuCOe9D6DKXgnQTLXoeUAv86C5RE+qiyaAnTfOJr+YfekgAnVfP/vtZCga2y9fYi f5ufWHVMQoPTADW322fX+4ZWYm/RENYNltySh484VZ4lj+HtoYP7iFdenwq4kGRCvI 0dWcTQ5i11FYGNvWpKxH5jYED0hWfFMv6D/jq5ik= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 19:03:37 +0100 References: <4F4E4EBB.8010307@nic.cz> To: dns-operations@lists.dns-oarc.net, tech@centr.org, dns-wg@ripe.net, members@dns-oarc.net, dnsop@ietf.org, dnsext@ietf.org Message-Id: <1B14614E-0C92-4E6A-8EF5-C569686DEF4C@nic.cz> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [DNSOP] Knot DNS v1.0.0 released 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, 29 Feb 2012 18:03:40 -0000 Hi all, I wouldn't normally crosspost this, but since it's our 1.0.0 version... So sorry for duplicates and please download, enjoy, awe, test and report = bugs :). Thanks, Ondrej Begin forwarded message: > From: Lubos Slovak > Subject: [knot-dns-users] Knot DNS v1.0.0 released! > Date: 29. =C3=BAnora 2012 17:13:47 GMT+01:00 > To: knot-dns-users@lists.nic.cz >=20 > Dear Knot DNS users, >=20 > special days deserve special events and this day will surely be = extraordinary not only for us, but for the whole DNS community. CZ.NIC = Labs released first stable version of Knot DNS! >=20 > Please visit our website http://www.knot-dns.cz for more information = and all relevant links. >=20 > Source files are available here: = http://public.nic.cz/files/knot-dns/knot-1.0.0.tar.gz > (SHA256: = ab947ff09655f44bd4106da65764810ff760b646b83e9b0939ee994f943372a6) > Packages will be available shortly from usual repositories. = Instructions on how to setup them are available at = http://www.knot-dns.cz. >=20 > Lots of testing has been done in the past few weeks and we believe = Knot DNS is as stable and bugfree as possible. Thank you all for support = and feedback! >=20 > We will continue developing Knot DNS - there is still place for a lot = of optimizations, minor tweaks or new features, so stay tuned for next = releases. >=20 > Thank you again for using Knot DNS! -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From regnauld@x0.dk Wed Feb 29 02:42:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A69421F8895 for ; Wed, 29 Feb 2012 02:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB3Dmf5WI1W1 for ; Wed, 29 Feb 2012 02:42:09 -0800 (PST) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by ietfa.amsl.com (Postfix) with ESMTP id EB28621F8889 for ; Wed, 29 Feb 2012 02:42:07 -0800 (PST) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id 933BB4CEDD3; Wed, 29 Feb 2012 11:42:05 +0100 (CET) Received: from moof.catpipe.net ([194.28.252.64]) by localhost (moof.catpipe.net [194.28.252.64]) (amavisd-new, port 10024) with ESMTP id 4D5NqXnhizi2; Wed, 29 Feb 2012 11:42:05 +0100 (CET) Received: from macbook.bluepipe.net (rrcs-74-62-23-135.west.biz.rr.com [74.62.23.135]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTPA id C8A3C4CEDCE; Wed, 29 Feb 2012 11:41:59 +0100 (CET) Received: by macbook.bluepipe.net (Postfix, from userid 1001) id ACF61791DB9; Wed, 29 Feb 2012 02:41:58 -0800 (PST) Date: Wed, 29 Feb 2012 02:41:58 -0800 From: Phil Regnauld To: Shane Kerr Message-ID: <20120229104158.GF7542@macbook.bluepipe.net> References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <20120228100227.214bb6ef@shane-desktop> <4F4D1F9E.5090003@redbarn.org> <20120229102255.74fa4291@shane-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120229102255.74fa4291@shane-desktop> X-Operating-System: Darwin 11.2.0 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet 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, 29 Feb 2012 18:22:57 -0000 Shane Kerr (shane) writes: > > 1. Send query with the magic EDNS to a server. > 2. If the response is in the new format, then remember that. > 3. Subsequent queries go to a different port, using a new format. Would it be nuts to sugggest that the different port could be specified using SRV ? _dns._udp isn't that far off once you've primed the pump (and you've got dynamic port numbers to boot, yay!). Oh, that means you'd need to know the new port number, if you don't do an initial port 53 lookup. Scratch that :) Cheers, Phil From internet-drafts@ietf.org Wed Feb 29 15:56:36 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5522C21F879A; Wed, 29 Feb 2012 15:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSqWALcAvC+J; Wed, 29 Feb 2012 15:56:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0073121F84EC; Wed, 29 Feb 2012 15:56:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120229235623.3039.958.idtracker@ietfa.amsl.com> Date: Wed, 29 Feb 2012 15:56:23 -0800 Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-dps-framework-06.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, 29 Feb 2012 23:56:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Domain Name System Operations Working= Group of the IETF. Title : DNSSEC Policy & Practice Statement Framework Author(s) : Fredrik Ljunggren Tomofumi Okubo Filename : draft-ietf-dnsop-dnssec-dps-framework-06.txt Pages : 28 Date : 2012-02-29 This document presents a framework to assist writers of DNSSEC Policy and Practice Statements such as Domain Managers and Zone Operators on both the top-level and secondary level, who is managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-dps-framework-0= 6.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-dps-framework-06= .txt From fredrik@kirei.se Wed Feb 29 16:16:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D13421F866C for ; Wed, 29 Feb 2012 16:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B5nadDhihqz for ; Wed, 29 Feb 2012 16:16:39 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 3196C21F8661 for ; Wed, 29 Feb 2012 16:16:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=ltq4leZkkbWatNJdKZaEXHrWOGJnp9IusdYHw6k1TZM=; b=z2DUXm3E6I0Ct4x218m49wy3mnLp/fLO3a1zIsnq2cd0KbsDWlW/YYk7L33EjKwXTDH0vhIbpbS7x /JpitM76/TbWpn2JN6NBTku0S8Hfj3R/zWmqK/gHXL4j/mbc5QHXMjVpJ7zSS+dXq0iWc7fvJDkim9 al2WvYnpHYS1Fw2M= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Thu, 1 Mar 2012 01:16:28 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Fredrik Ljunggren In-Reply-To: <20120229235623.3039.958.idtracker@ietfa.amsl.com> Date: Thu, 1 Mar 2012 01:16:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120229235623.3039.958.idtracker@ietfa.amsl.com> To: dnsop@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-dps-framework-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 00:16:41 -0000 Friends, A new version of the DNSSEC Policy & Practice Statement Framework have = been submitted. This version includes edits from a second round of = nits-readings following the WGLC. Although the diff is fairly long, = there should be no substantial changes from the last version. Anyone interested should take a look to find out what has changed. Using = something like rfcdiff is advised! Best regards, - Fredrik On 2012-03-01, at 00:56, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Domain Name System = Operations Working Group of the IETF. >=20 > Title : DNSSEC Policy & Practice Statement Framework > Author(s) : Fredrik Ljunggren > Tomofumi Okubo > Filename : draft-ietf-dnsop-dnssec-dps-framework-06.txt > Pages : 28 > Date : 2012-02-29 >=20 > This document presents a framework to assist writers of DNSSEC = Policy > and Practice Statements such as Domain Managers and Zone Operators = on > both the top-level and secondary level, who is managing and = operating > a DNS zone with Security Extensions (DNSSEC) implemented. >=20 > In particular, the framework provides a comprehensive list of topics > that should be considered for inclusion into a DNSSEC Policy > definition and Practice Statement. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-dps-framework-= 06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-dps-framework-0= 6.txt >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop