From jabley@hopcount.ca Mon Oct 1 06:39:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F141F0D00 for ; Mon, 1 Oct 2012 06:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xX5TArkZiu2 for ; Mon, 1 Oct 2012 06:39:11 -0700 (PDT) Received: from mail.hopcount.ca (mail.hopcount.ca [IPv6:2001:4900:1:392::37]) by ietfa.amsl.com (Postfix) with ESMTP id 8974D1F0D33 for ; Mon, 1 Oct 2012 06:39:11 -0700 (PDT) Received: from [2001:4900:1042:100:11a3:218b:5f2f:2470] by mail.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TIgDE-0007R5-MO for dnsext@ietf.org; Mon, 01 Oct 2012 13:39:10 +0000 From: Joe Abley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Oct 2012 09:39:07 -0400 References: To: "dnsext@ietf.org" Message-Id: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: [dnsext] publishing policy attributes in the DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 13:39:13 -0000 Hi all, This (below) came up in the last-call comments for = draft-ietf-dnsop-dnssec-dps-framework. I seem to recall numerous ad-hoc suggestions for publishing policy = attributes in the DNS, over the years. For example: - (for signed zones) what DPS revision corresponds to the way this zone = was signed? - (for signed zones) what observed signature validity can be considered = normal, as an aid to those who do automatic surveys of remaining = signature validity and alarm on possible problems? - what second-level, third-level, etc subdomains are operated as part = of this registry? No doubt there are others. It seems to me that we might consider = standardising some kind of POLICY RRtype (or multiple RRTypes) that = could be used to signal these kinds of things. Such RRSets would be = informational and optional, and would not change existing query = processing rules. (I realise that this working group is either already dead, or is being = encouraged to die, but this mailing list seems like a reasonable venue = to discuss the idea.) Good idea? Bad idea? Joe Begin forwarded message: > From: Fredrik Ljunggren > Subject: Re: [DNSOP] I-D Action: = draft-ietf-dnsop-dnssec-dps-framework-10.txt > Date: 30 September 2012 13:10:14 EDT > To: SM > Cc: dnsop@ietf.org > X-Mailer: Apple Mail (2.1486) >=20 >=20 > On 2012-09-30, at 18:09, SM wrote: >=20 >> I found the following text from the Introduction Section more = informative: >>=20 >> 'users who rely on signed responses from the DNS ("relying parties") >> to evaluate the strength and security of the DNSSEC chain of trust' >>=20 >> 'for scrutinizing the trustworthiness of the system'. >>=20 >> It doesn't make sense to say "Interested parties must stay informed" = as the "advance notice of amendments" in Section 4.1.4 sounds like a = minor detail. >>=20 >> I don't have any strong opinion about any of this. The document is = useful to me irrespective of what's in Section 7. >=20 >=20 > I think it is a fair point to make from Russ, that there are = (currently) no standardized in-band methods to determine under what = policy a zone manager i currently operating. To find a DPS for a = particular zone you may have too google it. I'm all for standardizing a = DP/DPS pointer which can be published at the apex of the zone, but = that's another RFC, in another WG, another day. First we need to build = the concept of the DP/DPS. >=20 > Thanks for your support. >=20 > - Fredrik >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 From ogud@ogud.com Mon Oct 1 07:15:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7D411E8117 for ; Mon, 1 Oct 2012 07:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXRuXqS5oRKP for ; Mon, 1 Oct 2012 07:15:00 -0700 (PDT) Received: from smtp168.iad.emailsrvr.com (smtp168.iad.emailsrvr.com [207.97.245.168]) by ietfa.amsl.com (Postfix) with ESMTP id 9117C1F0CD6 for ; Mon, 1 Oct 2012 07:15:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp46.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id F1D19E82FA for ; Mon, 1 Oct 2012 10:14:59 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp46.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id CE14EE81C0 for ; Mon, 1 Oct 2012 10:14:59 -0400 (EDT) Message-ID: <5069A563.3070603@ogud.com> Date: Mon, 01 Oct 2012 10:14:59 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> In-Reply-To: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] publishing policy attributes in the DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 14:15:02 -0000 This topic is within scope of the mailing list, so discuss away. Olafur On 01/10/2012 09:39, Joe Abley wrote: > Hi all, > > This (below) came up in the last-call comments for draft-ietf-dnsop-dnssec-dps-framework. > > I seem to recall numerous ad-hoc suggestions for publishing policy attributes in the DNS, over the years. For example: > > - (for signed zones) what DPS revision corresponds to the way this zone was signed? > - (for signed zones) what observed signature validity can be considered normal, as an aid to those who do automatic surveys of remaining signature validity and alarm on possible problems? > - what second-level, third-level, etc subdomains are operated as part of this registry? > > No doubt there are others. It seems to me that we might consider standardising some kind of POLICY RRtype (or multiple RRTypes) that could be used to signal these kinds of things. Such RRSets would be informational and optional, and would not change existing query processing rules. > > (I realise that this working group is either already dead, or is being encouraged to die, but this mailing list seems like a reasonable venue to discuss the idea.) > > Good idea? Bad idea? > > > Joe > > Begin forwarded message: > >> From: Fredrik Ljunggren >> Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-dps-framework-10.txt >> Date: 30 September 2012 13:10:14 EDT >> To: SM >> Cc: dnsop@ietf.org >> X-Mailer: Apple Mail (2.1486) >> >> >> On 2012-09-30, at 18:09, SM wrote: >> >>> I found the following text from the Introduction Section more informative: >>> >>> 'users who rely on signed responses from the DNS ("relying parties") >>> to evaluate the strength and security of the DNSSEC chain of trust' >>> >>> 'for scrutinizing the trustworthiness of the system'. >>> >>> It doesn't make sense to say "Interested parties must stay informed" as the "advance notice of amendments" in Section 4.1.4 sounds like a minor detail. >>> >>> I don't have any strong opinion about any of this. The document is useful to me irrespective of what's in Section 7. >> >> >> I think it is a fair point to make from Russ, that there are (currently) no standardized in-band methods to determine under what policy a zone manager i currently operating. To find a DPS for a particular zone you may have too google it. I'm all for standardizing a DP/DPS pointer which can be published at the apex of the zone, but that's another RFC, in another WG, another day. First we need to build the concept of the DP/DPS. >> >> Thanks for your support. >> >> - Fredrik >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > From paul.hoffman@vpnc.org Mon Oct 1 07:30:58 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708461F0CD6 for ; Mon, 1 Oct 2012 07:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOnHZADSkLuy for ; Mon, 1 Oct 2012 07:30:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D9DE61F0C7E for ; Mon, 1 Oct 2012 07:30:57 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q91EUm5P026394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Oct 2012 07:30:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> Date: Mon, 1 Oct 2012 07:30:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43CBAE1F-2C19-4F51-84F1-EE57BB2FDE69@vpnc.org> References: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.1498) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] publishing policy attributes in the DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 14:30:58 -0000 On Oct 1, 2012, at 6:39 AM, Joe Abley wrote: > Hi all, >=20 > This (below) came up in the last-call comments for = draft-ietf-dnsop-dnssec-dps-framework. >=20 > I seem to recall numerous ad-hoc suggestions for publishing policy = attributes in the DNS, over the years. For example: >=20 > - (for signed zones) what DPS revision corresponds to the way this = zone was signed? > - (for signed zones) what observed signature validity can be = considered normal, as an aid to those who do automatic surveys of = remaining signature validity and alarm on possible problems? > - what second-level, third-level, etc subdomains are operated as part = of this registry? >=20 > No doubt there are others. It seems to me that we might consider = standardising some kind of POLICY RRtype (or multiple RRTypes) that = could be used to signal these kinds of things. Such RRSets would be = informational and optional, and would not change existing query = processing rules. Then what value would they have? This is a serious question. Every time = someone brings up the idea of "non-normative policy publication" in = security WGs, there is an agreement that we could probably describe some = policy well enough to publish it, and we could probably describe an = interoperable transport for the policy. Then there is general agreement = that it is worse than useless because no only does no one want it = actionable (as you say above, "informational and optional, and would not = change existing query processing rules"), but some implementations will = ignore that and try to enforce some things anyway. So its security that = breaks some things without helping any others. > (I realise that this working group is either already dead, or is being = encouraged to die, but this mailing list seems like a reasonable venue = to discuss the idea.) >=20 > Good idea? Bad idea? Bad idea unless the policy information is actionable in a way that = everyone agrees would help security. If that is the case, an individual = submission that is discussed on this list after the WG dies should be = just fine. --Paul Hoffman= From jabley@hopcount.ca Mon Oct 1 07:43:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E271F0CF9 for ; Mon, 1 Oct 2012 07:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOVWhjbss0aS for ; Mon, 1 Oct 2012 07:43:39 -0700 (PDT) Received: from mail.hopcount.ca (mail.hopcount.ca [IPv6:2001:4900:1:392::37]) by ietfa.amsl.com (Postfix) with ESMTP id 84F671F0CCD for ; Mon, 1 Oct 2012 07:43:39 -0700 (PDT) Received: from [2001:4900:1042:100:11a3:218b:5f2f:2470] by mail.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TIhDY-000BsW-Cz; Mon, 01 Oct 2012 14:43:38 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Joe Abley In-Reply-To: <43CBAE1F-2C19-4F51-84F1-EE57BB2FDE69@vpnc.org> Date: Mon, 1 Oct 2012 10:43:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> <43CBAE1F-2C19-4F51-84F1-EE57BB2FDE69@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1498) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] publishing policy attributes in the DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 14:43:40 -0000 On 2012-10-01, at 10:30, Paul Hoffman wrote: > On Oct 1, 2012, at 6:39 AM, Joe Abley wrote: >=20 >> Such RRSets would be informational and optional, and would not change = existing query processing rules. >=20 > Then what value would they have? This is a serious question. Your question (and following commentary) suggests that non-compulsory = extensions to the DNS have no value, and also assumes that there needs = to be a security benefit to this kind of idea for it to be worth = pursuing. There are other places where (for some TLDs) optional protocol elements = can be made mandatory. There's also no shortage of examples of zone = operators doing optional things because they are perceived to be useful, = not because some RFC says they are mandatory. The three examples I gave were measures that I think would have non-zero = operational benefit, even if they were not universally deployed. (I presume your comment related to the "informational and optional" = aspect, and did not speak to the specific utility of the three = examples.) Joe From ajs@anvilwalrusden.com Mon Oct 1 08:07:53 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811761F0D3F for ; Mon, 1 Oct 2012 08:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Lv1FD06h+JS for ; Mon, 1 Oct 2012 08:07:53 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE8B1F0D17 for ; Mon, 1 Oct 2012 08:07:53 -0700 (PDT) Received: from mx1.yitter.info (nat-04-mht.dyndns.com [216.146.45.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E1C238A031 for ; Mon, 1 Oct 2012 15:07:50 +0000 (UTC) Date: Mon, 1 Oct 2012 11:07:58 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20121001150758.GA11975@mx1.yitter.info> References: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] publishing policy attributes in the DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:07:53 -0000 Emphatically no hat. On Mon, Oct 01, 2012 at 09:39:07AM -0400, Joe Abley wrote: > No doubt there are others. It seems to me that we might consider standardising some kind of POLICY RRtype (or multiple RRTypes) that could be used to signal these kinds of things. Such RRSets would be informational and optional, and would not change existing query processing rules. > For one proposal along these lines, see http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-01. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Mon Oct 1 10:02:56 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901B61F0D17 for ; Mon, 1 Oct 2012 10:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8ZRrz6OqqIz for ; Mon, 1 Oct 2012 10:02:56 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D20111F0CCD for ; Mon, 1 Oct 2012 10:02:55 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q91H2k0x031284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Oct 2012 10:02:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: Date: Mon, 1 Oct 2012 10:02:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <218ACE7B-04F9-4E8D-8013-53BB2EB79F97@vpnc.org> References: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> <43CBAE1F-2C19-4F51-84F1-EE57BB2FDE69@vpnc.org> To: Joe Abley X-Mailer: Apple Mail (2.1498) Cc: DNSEXT Working Group Subject: Re: [dnsext] publishing policy attributes in the DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 17:02:56 -0000 On Oct 1, 2012, at 7:43 AM, Joe Abley wrote: >=20 > On 2012-10-01, at 10:30, Paul Hoffman wrote: >=20 >> On Oct 1, 2012, at 6:39 AM, Joe Abley wrote: >>=20 >>> Such RRSets would be informational and optional, and would not = change existing query processing rules. >>=20 >> Then what value would they have? This is a serious question. >=20 > Your question (and following commentary) suggests that non-compulsory = extensions to the DNS have no value, and also assumes that there needs = to be a security benefit to this kind of idea for it to be worth = pursuing. That is not what it is meant to suggest. > There are other places where (for some TLDs) optional protocol = elements can be made mandatory. Please say more. > There's also no shortage of examples of zone operators doing optional = things because they are perceived to be useful, not because some RFC = says they are mandatory. And no shortage of examples where applications and DNS implementations = misinterpret these "useful" things. > The three examples I gave were measures that I think would have = non-zero operational benefit, even if they were not universally = deployed. - (for signed zones) what DPS revision corresponds to the way this zone = was signed? What is the operational benefit of this? Do you want a validating = resolver to give different answers based on different values? - (for signed zones) what observed signature validity can be considered = normal, as an aid to those who do automatic surveys of remaining = signature validity and alarm on possible problems? This is the type of policy that the websec WG has grappled with for = years; they are getting close to being finished. - what second-level, third-level, etc subdomains are operated as part of = this registry? Andrew Sullivan has proposed this, but few people have commented on it. > (I presume your comment related to the "informational and optional" = aspect, and did not speak to the specific utility of the three = examples.) It speaks directly to the first one, and probably to the second. I think = the third is important but don't understand why others don't. I would say that "informational" is harmful unless you specify exactly = how the information is used by someone who sees it. --Paul Hoffman= From jabley@hopcount.ca Mon Oct 1 10:10:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AE421F8806 for ; Mon, 1 Oct 2012 10:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPW+dFz4f96F for ; Mon, 1 Oct 2012 10:10:31 -0700 (PDT) Received: from mail.hopcount.ca (mail.hopcount.ca [IPv6:2001:4900:1:392::37]) by ietfa.amsl.com (Postfix) with ESMTP id 14A0121F8804 for ; Mon, 1 Oct 2012 10:10:31 -0700 (PDT) Received: from [2001:4900:1042:100:11a3:218b:5f2f:2470] by mail.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TIjVi-000Mf5-6B; Mon, 01 Oct 2012 17:10:30 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Joe Abley In-Reply-To: <218ACE7B-04F9-4E8D-8013-53BB2EB79F97@vpnc.org> Date: Mon, 1 Oct 2012 13:10:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4087B69F-476E-4D24-BCE5-2BBBE4A1A0B9@hopcount.ca> References: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> <43CBAE1F-2C19-4F51-84F1-EE57BB2FDE69@vpnc.org> <218ACE7B-04F9-4E8D-8013-53BB2EB79F97@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1498) Cc: DNSEXT Working Group Subject: Re: [dnsext] publishing policy attributes in the DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 17:10:31 -0000 On 2012-10-01, at 13:02, Paul Hoffman wrote: > On Oct 1, 2012, at 7:43 AM, Joe Abley wrote: >=20 >> There are other places where (for some TLDs) optional protocol = elements can be made mandatory. >=20 > Please say more. As an example, gTLDs are operated by registries under contract with = ICANN. Those contracts can specify that particular protocol-optional = elements are included in their published zones. >> There's also no shortage of examples of zone operators doing optional = things because they are perceived to be useful, not because some RFC = says they are mandatory. >=20 > And no shortage of examples where applications and DNS implementations = misinterpret these "useful" things. That's why it's great to have standards! >> The three examples I gave were measures that I think would have = non-zero operational benefit, even if they were not universally = deployed. >=20 > - (for signed zones) what DPS revision corresponds to the way this = zone was signed? >=20 > What is the operational benefit of this? Do you want a validating = resolver to give different answers based on different values? Nope, I want operators to be able to locate the DPS that corresponds to = a particular signed zone easily. Right now you have to fight with search = engines, and there's no real guarantee that whatever you find is the = policy used to sign that particular zone. > I would say that "informational" is harmful unless you specify exactly = how the information is used by someone who sees it. Then let me clarify; the goal is to allow information to be published = (hence "informational") in a structured and well-defined way, to = minimise confusion and maximise the possibility that consumers of that = information will understand its meaning and intended use. Joe= From paul.hoffman@vpnc.org Mon Oct 1 10:25:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02891F0CD1 for ; Mon, 1 Oct 2012 10:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZejKfc+eCzh for ; Mon, 1 Oct 2012 10:25:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 614E41F0CCD for ; Mon, 1 Oct 2012 10:25:13 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q91HP8cY032117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Oct 2012 10:25:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: <4087B69F-476E-4D24-BCE5-2BBBE4A1A0B9@hopcount.ca> Date: Mon, 1 Oct 2012 10:25:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C1E4718-A615-430F-B5DF-99BA1A44A042@vpnc.org> References: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> <43CBAE1F-2C19-4F51-84F1-EE57BB2FDE69@vpnc.org> <218ACE7B-04F9-4E8D-8013-53BB2EB79F97@vpnc.org> <4087B69F-476E-4D24-BCE5-2BBBE4A1A0B9@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.1498) Cc: DNSEXT Working Group Subject: Re: [dnsext] publishing policy attributes in the DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 17:25:14 -0000 On Oct 1, 2012, at 10:10 AM, Joe Abley wrote: >> - (for signed zones) what DPS revision corresponds to the way this = zone was signed? >>=20 >> What is the operational benefit of this? Do you want a validating = resolver to give different answers based on different values? >=20 > Nope, I want operators to be able to locate the DPS that corresponds = to a particular signed zone easily. Right now you have to fight with = search engines, and there's no real guarantee that whatever you find is = the policy used to sign that particular zone. Ah! I have no problem with that. Sorry if I got twitchy about the = security aspect; I've been in too many IETF meetings where the purpose = of publishing a security policy was the eventual automatic processing of = it. >> I would say that "informational" is harmful unless you specify = exactly how the information is used by someone who sees it. >=20 > Then let me clarify; the goal is to allow information to be published = (hence "informational") in a structured and well-defined way, to = minimise confusion and maximise the possibility that consumers of that = information will understand its meaning and intended use. Works for me. There's no reason why these shouldn't be individual submissions of new = RRtypes. --Paul Hoffman= From sm@resistor.net Mon Oct 1 10:35:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449421F0CCD for ; Mon, 1 Oct 2012 10:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+2pgunBVfYZ for ; Mon, 1 Oct 2012 10:35:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AAE11E8117 for ; Mon, 1 Oct 2012 10:35:01 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q91HYonD014393; Mon, 1 Oct 2012 10:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349112895; bh=gOV7vDquEbJ3P8zWZPvu+hMxAW2Kl4FzcttXqWn4zhM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sFWZSrD5hwaelDqRKS6UwH0qQSKZWNq5UiZGCL9b+wuYaVS/yDvBE9GgoVa228622 uoWNuLRhekmMuuUMT2vT/fn0LuuKWEfX1nOGpiC3inzAOy9ECG9x7t++Aswt5oHqq1 KvsT1ATA1mFz9yVFbvWQWW98/ybN+T0iauwFtmqg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349112895; i=@resistor.net; bh=gOV7vDquEbJ3P8zWZPvu+hMxAW2Kl4FzcttXqWn4zhM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cGGGAMKm6E8dSovWevv1YSyzT7s3bJwYvVT6yrlOkUXHXgl4Qeeja6PjUJJHUPynD v+OCPqnxGVreliX28KsANrQ1n5Y6ia/H621OyI/Nqq7IxhwajHKiODoHtyHmeJ9RNv o0NgSYzjsMsozwdcL5+VL9I3q1HaSU3RvWYgvM8I= Message-Id: <6.2.5.6.2.20121001102016.0b3404b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 01 Oct 2012 10:30:18 -0700 To: Joe Abley From: SM In-Reply-To: <4087B69F-476E-4D24-BCE5-2BBBE4A1A0B9@hopcount.ca> References: <82ADB7D5-4F2F-44F1-B465-66ABB3DDCB21@hopcount.ca> <43CBAE1F-2C19-4F51-84F1-EE57BB2FDE69@vpnc.org> <218ACE7B-04F9-4E8D-8013-53BB2EB79F97@vpnc.org> <4087B69F-476E-4D24-BCE5-2BBBE4A1A0B9@hopcount.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: DNSEXT Working Group Subject: Re: [dnsext] publishing policy attributes in the DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 17:35:02 -0000 At 10:10 01-10-2012, Joe Abley wrote: >signed zone easily. Right now you have to fight with search engines, >and there's no real guarantee that whatever you find is the policy >used to sign that particular zone. Yes. >Then let me clarify; the goal is to allow information to be >published (hence "informational") in a structured and well-defined >way, to minimise confusion and maximise the possibility that >consumers of that information will understand its meaning and intended use. The problem with "Informational" is that's it is not a "standard" [1]. To answer the question asked in a previous message, it's a good idea. It would be quite an effort to move the idea forward as it has the word "policy" in it. Regards, -sm 1. I'll skip the long explanation. From john-ietf@jck.com Mon Oct 1 12:48:54 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BA721F843A; Mon, 1 Oct 2012 12:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbb0J3jnz4et; Mon, 1 Oct 2012 12:48:53 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 41A5621F852C; Mon, 1 Oct 2012 12:48:37 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TIlym-0006ce-EW; Mon, 01 Oct 2012 15:48:36 -0400 Date: Mon, 01 Oct 2012 15:48:31 -0400 From: John C Klensin To: ietf@ietf.org Message-ID: <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> In-Reply-To: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 01 Oct 2012 13:02:08 -0700 Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 19:48:54 -0000 --On Sunday, September 30, 2012 07:53 -0700 The IESG wrote: > > The IESG has received a request from the DNS Extensions WG > (dnsext) to consider the following document: > - 'Extension Mechanisms for DNS (EDNS(0))' > as Internet > Standard > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@ietf.org mailing lists by > 2012-10-29. Exceptionally, comments may be sent to > iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The Domain Name System's wire protocol includes a number of > fixed fields whose range has been or soon will be exhausted > and does not allow requestors to advertise their > capabilities to responders. This document describes > backward compatible mechanisms for allowing the protocol to > grow. > > This document updates the EDNS(0) specification (and > obsoletes RFC 2671) based on feedback from deployment > experience in several implementations. It also closes the > IANA registry for extended labels created as part of RFC > 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain > Name System") which depends on the existence of extended > labels. >... Hi. Apologies for not noticing this earlier, but this specification's deprecation of label types raises an issue that the document doesn't seem to address. Deprecating RFC 2673 is one thing. Given deployment and operational experience, I don't know of anyone who would offer a strong defense of binary labels today. However, the document doesn't offer a strong justification for deprecating label types entirely other than, it seems, that there has been only one example of their use and that failed. If that were the only motivation, it would be a rather weak one, especially since having a capability that we don't use (but conceivably might in the future) would not appear to cause any harm. With the understanding that this is an example, not a proposal, it may be useful to review some of the history and context for IDNs. IDNA represents community consensus as to the right way to proceed, but that consensus includes both people who believe it is a good permanent strategy and people who believe it is a good temporary/transition strategy until a better plan can be developed and deployed. In particular, some of that latter group were painfully aware of the rate at which EDNS0 was deploying in the first half of the last decade, making them more receptive to IDNA (or other strategies that did not depend on changes to DNS servers or resolvers). So suppose the community really does decide that it wants DNS-based IDNs and that it wants to see if they can be developed and deployed within the existing DNS rather than moving to what some have called DNSng. It is reasonably clear that what would be called "just send 8" in the email community would not be acceptable if only because there are DNS uses outside the public network that use UTF-8 directly and others that use ISO 8859-1 or other character coding and repertoires (RFC 6055 discusses some related issues). The proposal/thought piece I produced in 2001-2002 (with urging from some DNS-expert colleagues) to transition to a new, i18n-sensitive, Class might be part of the solution, but it is now clear that it would not be sufficient (at least without considerable special-casing that would violate both 1034/1035 and current trends). A different label type that would permit specialized interpretations of the labels might be an important part of the puzzle. Would that be a good idea? I don't know. Personally, I believe that some of the expectations of and demand for IDNs cannot be met in the current DNS and that we should not try to go much further than IDNA: if more is really needed, then it should be accomplished either in an "above DNS" solution or by designing and deploying DNS2. But I think it would be terribly unwise to eliminate a facility that might be useful for i18n simply because someone tried to use it for something entirely different and that effort did not succeed. Therefore: (1) Did the WG consider i18n and other issues and possibilities before deciding to deprecate extended label types entirely? If so, why aren't those considerations described in the document? We don't have a lot of codes left in the RFC 1035 space on which other label type models might be constructed. (2) Is there strong justification for deprecating extended label types, e.g., evidence that they would cause harm? (3) If the answer to either of both of the above questions is "no", wouldn't it be wiser to simply deprecate the use of binary labels, urge great caution in allocating and using other label types, and then move on rather than eliminating the facility? thanks, john From marka@isc.org Mon Oct 1 19:22:34 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B331F0D67; Mon, 1 Oct 2012 19:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuU+4jVur2UA; Mon, 1 Oct 2012 19:22:33 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 73C5F1F0D44; Mon, 1 Oct 2012 19:22:33 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7062F5F9954; Tue, 2 Oct 2012 02:22:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:1c89:b24e:dc8f:2933]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0DC06216C3B; Tue, 2 Oct 2012 02:22:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D7B2A282EC28; Tue, 2 Oct 2012 12:22:12 +1000 (EST) To: John C Klensin From: Mark Andrews References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> In-reply-to: Your message of "Mon, 01 Oct 2012 15:48:31 -0400." <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> Date: Tue, 02 Oct 2012 12:22:12 +1000 Message-Id: <20121002022212.D7B2A282EC28@drugs.dv.isc.org> Cc: ietf@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 02:22:34 -0000 In message <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com>, John C Klensin writes : > > > --On Sunday, September 30, 2012 07:53 -0700 The IESG > wrote: > > > > > The IESG has received a request from the DNS Extensions WG > > (dnsext) to consider the following document: > > - 'Extension Mechanisms for DNS (EDNS(0))' > > as Internet > > Standard > > > > The IESG plans to make a decision in the next few weeks, and > > solicits final comments on this action. Please send > > substantive comments to the ietf@ietf.org mailing lists by > > 2012-10-29. Exceptionally, comments may be sent to > > iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > The Domain Name System's wire protocol includes a number of > > fixed fields whose range has been or soon will be exhausted > > and does not allow requestors to advertise their > > capabilities to responders. This document describes > > backward compatible mechanisms for allowing the protocol to > > grow. > > > > This document updates the EDNS(0) specification (and > > obsoletes RFC 2671) based on feedback from deployment > > experience in several implementations. It also closes the > > IANA registry for extended labels created as part of RFC > > 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain > > Name System") which depends on the existence of extended > > labels. > >... > > Hi. Apologies for not noticing this earlier, but this > specification's deprecation of label types raises an issue that > the document doesn't seem to address. > > Deprecating RFC 2673 is one thing. Given deployment and > operational experience, I don't know of anyone who would offer a > strong defense of binary labels today. However, the document > doesn't offer a strong justification for deprecating label types > entirely other than, it seems, that there has been only one > example of their use and that failed. If that were the only > motivation, it would be a rather weak one, especially since > having a capability that we don't use (but conceivably might in > the future) would not appear to cause any harm. > > With the understanding that this is an example, not a proposal, > it may be useful to review some of the history and context for > IDNs. IDNA represents community consensus as to the right way > to proceed, but that consensus includes both people who believe > it is a good permanent strategy and people who believe it is a > good temporary/transition strategy until a better plan can be > developed and deployed. In particular, some of that latter > group were painfully aware of the rate at which EDNS0 was > deploying in the first half of the last decade, making them more > receptive to IDNA (or other strategies that did not depend on > changes to DNS servers or resolvers). > > So suppose the community really does decide that it wants > DNS-based IDNs and that it wants to see if they can be developed > and deployed within the existing DNS rather than moving to what > some have called DNSng. It is reasonably clear that what would > be called "just send 8" in the email community would not be > acceptable if only because there are DNS uses outside the public > network that use UTF-8 directly and others that use ISO 8859-1 > or other character coding and repertoires (RFC 6055 discusses > some related issues). The proposal/thought piece I produced in > 2001-2002 (with urging from some DNS-expert colleagues) to > transition to a new, i18n-sensitive, Class might be part of the > solution, but it is now clear that it would not be sufficient > (at least without considerable special-casing that would violate > both 1034/1035 and current trends). A different label type that > would permit specialized interpretations of the labels might be > an important part of the puzzle. > > Would that be a good idea? I don't know. Personally, I believe > that some of the expectations of and demand for IDNs cannot be > met in the current DNS and that we should not try to go much > further than IDNA: if more is really needed, then it should be > accomplished either in an "above DNS" solution or by designing > and deploying DNS2. But I think it would be terribly unwise to > eliminate a facility that might be useful for i18n simply > because someone tried to use it for something entirely different > and that effort did not succeed. > > Therefore: > (1) Did the WG consider i18n and other issues and possibilities > before deciding to deprecate extended label types entirely? If > so, why aren't those considerations described in the document? > We don't have a lot of codes left in the RFC 1035 space on which > other label type models might be constructed. > > (2) Is there strong justification for deprecating extended label > types, e.g., evidence that they would cause harm? > > (3) If the answer to either of both of the above questions is > "no", wouldn't it be wiser to simply deprecate the use of binary > labels, urge great caution in allocating and using other label > types, and then move on rather than eliminating the facility? > > thanks, > john I don't think we need to do this in label types. An EDNS option would be sufficient to specify alternate normalisation rules should be applied to the QNAME when looking for data and when normalising the owner names when performing DNSSEC validation. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From john-ietf@jck.com Mon Oct 1 19:57:06 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BA421F8A2D; Mon, 1 Oct 2012 19:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tAq4cgmFo5C; Mon, 1 Oct 2012 19:57:06 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 266A121F8A2B; Mon, 1 Oct 2012 19:57:06 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TIsfR-00070V-5X; Mon, 01 Oct 2012 22:57:05 -0400 Date: Mon, 01 Oct 2012 22:56:59 -0400 From: John C Klensin To: Mark Andrews Message-ID: <818904DB9902CFA1AB4DCB8F@JcK-HP8200.jck.com> In-Reply-To: <20121002022212.D7B2A282EC28@drugs.dv.isc.org> References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <20121002022212.D7B2A282EC28@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ietf@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 02:57:06 -0000 --On Tuesday, October 02, 2012 12:22 +1000 Mark Andrews wrote: >> Therefore: >> (1) Did the WG consider i18n and other issues and >> possibilities before deciding to deprecate extended label >> types entirely? If so, why aren't those considerations >> described in the document? We don't have a lot of codes left >> in the RFC 1035 space on which other label type models might >> be constructed. >> >> (2) Is there strong justification for deprecating extended >> label types, e.g., evidence that they would cause harm? >> >> (3) If the answer to either of both of the above questions is >> "no", wouldn't it be wiser to simply deprecate the use of >> binary labels, urge great caution in allocating and using >> other label types, and then move on rather than eliminating >> the facility? >... > I don't think we need to do this in label types. An EDNS > option would be sufficient to specify alternate normalisation > rules should be applied to the QNAME when looking for data and > when normalising the owner names when performing DNSSEC > validation. Mark, First, it was just an example. As I thought I made clear, my main concern is about completely eliminating a facility because one instance of trying to use it had not turned out to be as useful as expected. Absent demonstration that all possible uses of the facility are actually useless or that the facility is harmful, I don't think the case has been made for deprecating it. As far as that example is concerned, I don't think this is the right place to review everything we've learned about i18n, identifiers, and comparisons in the last couple of decades, but normalization is just not a very large fraction of the problem. john From marka@isc.org Mon Oct 1 20:33:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E0E1F0D5B; Mon, 1 Oct 2012 20:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfiSC5tRDJIT; Mon, 1 Oct 2012 20:33:15 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 17F591F0D64; Mon, 1 Oct 2012 20:33:14 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 862615F989F; Tue, 2 Oct 2012 03:33:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 88377216C3B; Tue, 2 Oct 2012 03:32:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id AA10F283536B; Tue, 2 Oct 2012 13:32:53 +1000 (EST) To: John C Klensin From: Mark Andrews References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <20121002022212.D7B2A282EC28@drugs.dv.isc.org> <818904DB9902CFA1AB4DCB8F@JcK-HP8200.jck.com> In-reply-to: Your message of "Mon, 01 Oct 2012 22:56:59 -0400." <818904DB9902CFA1AB4DCB8F@JcK-HP8200.jck.com> Date: Tue, 02 Oct 2012 13:32:52 +1000 Message-Id: <20121002033253.AA10F283536B@drugs.dv.isc.org> Cc: ietf@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 03:33:15 -0000 Closing the registry is not irreversable if it needs to be reversed. It's not like we can forget that there were assigned code points and anything that attempted to use those code points would have to consider the fact that they were used at one time. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rafiee@hpi.uni-potsdam.de Tue Oct 2 07:58:57 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FD721F8472 for ; Tue, 2 Oct 2012 07:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[AWL=0.802, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2eUI3OeEUMx for ; Tue, 2 Oct 2012 07:58:56 -0700 (PDT) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id 99CFA21F850D for ; Tue, 2 Oct 2012 07:58:56 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id 6EBE8D2CA5 for ; Tue, 2 Oct 2012 16:58:53 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Tue, 2 Oct 2012 16:58:53 +0200 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" Date: Tue, 2 Oct 2012 16:58:52 +0200 Thread-Topic: draft-rafiee-cga-tsig-00 Thread-Index: Ac2grABLkAHDL9i3QIaIWyaaK/MNLwAAP72w Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [dnsext] draft-rafiee-cga-tsig-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:58:57 -0000 SGVsbG8sDQpJIGhhdmUgc3VibWl0dGVkIGFuIFJGQyBkcmFmdCB0byB0aGUgZm9sbG93IGxpbms6 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJhZmllZS1jZ2EtdHNp Zy0wMC50eHQuIFBsZWFzZSB0YWtlIGEgbG9vayBhdCBpdCBhbmQgc2hhcmUgeW91IGNvbW1lbnRz IHNvIHRoYXQgSSBtaWdodCBpbXByb3ZlIGl0Lg0KVGhhbmtzLA0KSG9zbmllaA0K From ogud@ogud.com Tue Oct 2 08:01:44 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E48A21F8472 for ; Tue, 2 Oct 2012 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hanVKiIP70nW for ; Tue, 2 Oct 2012 08:01:43 -0700 (PDT) Received: from smtp148.iad.emailsrvr.com (smtp148.iad.emailsrvr.com [207.97.245.148]) by ietfa.amsl.com (Postfix) with ESMTP id 74C8A21F850C for ; Tue, 2 Oct 2012 08:01:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id D77E92D0007; Tue, 2 Oct 2012 11:01:38 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 809331A051E; Tue, 2 Oct 2012 11:01:38 -0400 (EDT) Message-ID: <506B01D1.9080708@ogud.com> Date: Tue, 02 Oct 2012 11:01:37 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> In-Reply-To: <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: john-ietf@jck.com Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:01:45 -0000 On 01/10/2012 15:48, John C Klensin wrote: > > > --On Sunday, September 30, 2012 07:53 -0700 The IESG > wrote: > >> >> The IESG has received a request from the DNS Extensions WG (dnsext) >> to consider the following document: - 'Extension Mechanisms for DNS >> (EDNS(0))' as Internet >> Standard >> >> The IESG plans to make a decision in the next few weeks, and >> solicits final comments on this action. Please send substantive >> comments to the ietf@ietf.org mailing lists by 2012-10-29. >> Exceptionally, comments may be sent to iesg@ietf.org instead. In >> either case, please retain the beginning of the Subject line to >> allow automated sorting. >> >> Abstract >> >> >> The Domain Name System's wire protocol includes a number of fixed >> fields whose range has been or soon will be exhausted and does not >> allow requestors to advertise their capabilities to responders. >> This document describes backward compatible mechanisms for >> allowing the protocol to grow. >> >> This document updates the EDNS(0) specification (and obsoletes RFC >> 2671) based on feedback from deployment experience in several >> implementations. It also closes the IANA registry for extended >> labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary >> Labels in the Domain Name System") which depends on the existence >> of extended labels. ... > > Hi. Apologies for not noticing this earlier, but this > specification's deprecation of label types raises an issue that the > document doesn't seem to address. > > Deprecating RFC 2673 is one thing. Given deployment and operational > experience, I don't know of anyone who would offer a strong defense > of binary labels today. However, the document doesn't offer a > strong justification for deprecating label types entirely other than, > it seems, that there has been only one example of their use and that > failed. If that were the only motivation, it would be a rather weak > one, especially since having a capability that we don't use (but > conceivably might in the future) would not appear to cause any harm. John, We learned two main things from binary labels: a) the specification of them caused expensive processing, and the utility of binary labels w/o A6 record was none. b) In order to introduce a new label type: All DNS infrastructure needs to understand the new label type before it is can be reliability used. Lots of DNS processing elements barf at labels that they do not expect. For example number of firewalls drop answers if the name of the first answer record is not compressed (a protocol violation) Based on this experience the DNSEXT felt that the best message to send out is new label types do not work, in the current Internet. Deploying a new label type requires an effort similar to what we are going through right now with DNSSEC, upgrade all DNS protocol processing elements, plus systems and processes that feed and operate the DNS systems. Personally at the time of introduction of the label registry I thought it was a good idea, but operational realities demonstrated that its time had passed, i.e. if we had defined more label types in RFC1034/5 then there might have been a chance. But given how many implementations are based on coding against what that implementor sees in traffic dumps rather than what is in the RFC's makes extending DNS much harder than it should be, upgrading the installed base takes decades. If you think the text in the document does not reflect the lessons learned strongly enough I will be happy work with you on putting better text in the document. Olafur > > With the understanding that this is an example, not a proposal, it > may be useful to review some of the history and context for IDNs. > IDNA represents community consensus as to the right way to proceed, > but that consensus includes both people who believe it is a good > permanent strategy and people who believe it is a good > temporary/transition strategy until a better plan can be developed > and deployed. In particular, some of that latter group were > painfully aware of the rate at which EDNS0 was deploying in the first > half of the last decade, making them more receptive to IDNA (or other > strategies that did not depend on changes to DNS servers or > resolvers). > > So suppose the community really does decide that it wants DNS-based > IDNs and that it wants to see if they can be developed and deployed > within the existing DNS rather than moving to what some have called > DNSng. It is reasonably clear that what would be called "just send > 8" in the email community would not be acceptable if only because > there are DNS uses outside the public network that use UTF-8 directly > and others that use ISO 8859-1 or other character coding and > repertoires (RFC 6055 discusses some related issues). The > proposal/thought piece I produced in 2001-2002 (with urging from some > DNS-expert colleagues) to transition to a new, i18n-sensitive, Class > might be part of the solution, but it is now clear that it would not > be sufficient (at least without considerable special-casing that > would violate both 1034/1035 and current trends). A different label > type that would permit specialized interpretations of the labels > might be an important part of the puzzle. > > Would that be a good idea? I don't know. Personally, I believe that > some of the expectations of and demand for IDNs cannot be met in the > current DNS and that we should not try to go much further than IDNA: > if more is really needed, then it should be accomplished either in an > "above DNS" solution or by designing and deploying DNS2. But I think > it would be terribly unwise to eliminate a facility that might be > useful for i18n simply because someone tried to use it for something > entirely different and that effort did not succeed. > > Therefore: (1) Did the WG consider i18n and other issues and > possibilities before deciding to deprecate extended label types > entirely? If so, why aren't those considerations described in the > document? We don't have a lot of codes left in the RFC 1035 space on > which other label type models might be constructed. > > (2) Is there strong justification for deprecating extended label > types, e.g., evidence that they would cause harm? > > (3) If the answer to either of both of the above questions is "no", > wouldn't it be wiser to simply deprecate the use of binary labels, > urge great caution in allocating and using other label types, and > then move on rather than eliminating the facility? > > thanks, john > > > _______________________________________________ dnsext mailing list > dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > > From john-ietf@jck.com Tue Oct 2 08:09:34 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D718021F84A0; Tue, 2 Oct 2012 08:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gpj77GrGRO99; Tue, 2 Oct 2012 08:09:33 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 115A921F8471; Tue, 2 Oct 2012 08:09:33 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJ46G-0009Ze-21; Tue, 02 Oct 2012 11:09:32 -0400 Date: Tue, 02 Oct 2012 11:09:25 -0400 From: John C Klensin To: Mark Andrews Message-ID: <352FF2F3A9C6DE5B0203ABDD@JcK-HP8200.jck.com> In-Reply-To: <20121002033253.AA10F283536B@drugs.dv.isc.org> References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <20121002022212.D7B2A282EC28@drugs.dv.isc.org> <818904DB9902CFA1AB4DCB8F@JcK-HP8200.jck.com> <20121002033253.AA10F283536B@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ietf@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:09:34 -0000 --On Tuesday, October 02, 2012 13:32 +1000 Mark Andrews wrote: > Closing the registry is not irreversable if it needs to be > reversed. It's not like we can forget that there were assigned > code points and anything that attempted to use those code > points would have to consider the fact that they were used at > one time. Actually, Mark, we very rarely close registries if there is any possibility of reopening them. We may raise the threshold for registration, etc. (in this case, new types already require standards action, which should make it adequately easy to head off bad or frivolous ideas), but closing is a big step. Telling implementers that they don't need to pay attention to the relevant codes and fields (and might even be able to use them for a different, even if private, purpose) is an even more serious step. But I'd like to ask that this discussion move up a level. My question was about what the WG considered and whether, in the light of those discussions, there was really justification to take the serious step of abandoning a facility and consensus on that justification. It seems to me that your responses have addressed different questions entirely: your opinion about alternate approaches in the earlier note and a suggestion about the possibility of reopening registries in this one. Because the questions I asked are tightly connected to what the WG discussed and on what basis the presumably-consensus decision was made, I would hope that I (and, more important, the IESG and the community) would hear from the WG Chairs and other participants, not only from someone who, coincidentally or not, is part of the same organization as the three authors of the draft (a draft that does not indicate the active participation of any other people or organizations by the presence of an Acknowledgments section). best regards, john From john-ietf@jck.com Tue Oct 2 09:38:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF2B21F845D for ; Tue, 2 Oct 2012 09:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K45OjAJK2JLK for ; Tue, 2 Oct 2012 09:38:29 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A731A21F8460 for ; Tue, 2 Oct 2012 09:38:29 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJ5UL-0009fP-3N; Tue, 02 Oct 2012 12:38:29 -0400 Date: Tue, 02 Oct 2012 12:38:22 -0400 From: John C Klensin To: Olafur Gudmundsson , dnsext@ietf.org Message-ID: <8F3DCBA9A3AF566810CD1061@JcK-HP8200.jck.com> In-Reply-To: <506B01D1.9080708@ogud.com> References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <506B01D1.9080708@ogud.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:38:31 -0000 --On Tuesday, October 02, 2012 11:01 -0400 Olafur Gudmundsson wrote: >... >>> The IESG has received a request from the DNS Extensions WG >>> (dnsext) to consider the following document: - 'Extension >>> Mechanisms for DNS (EDNS(0))' >>> as Internet >>> Standard >... > John, > > We learned two main things from binary labels: > a) the specification of them caused expensive processing, and > the > utility of binary labels w/o A6 record was none. Huh? While I certainly agree that the binary label experiment failed, RFC 2673 didn't seem to me to have anything to do with A6 records and a quick review just now doesn't convince me otherwise. As I recall, it came out of the period in which we were evolving to classless IPv4 addresses (with prefix lengths/netmasks on arbitrary bit boundaries) and was intended to permit address delegation entities to easily delegate ranges of reverse-mapping records to the appropriate address-holding entities for management. The failure of that idea (for the reasons you outline) contributed, IMO, to PTR records being much less useful today than they were pre-CIDR. Conversely, if a significant reason for getting rid of binary labels was the link to A6 records, why doesn't the document just say "these existed solely to support A6 records, A6 records have been deprecated, therefore these are too". All of us could be spared the discussion of why they failed relative to deployment issues, etc. But the question of whether it is appropriate to get rid of label types would remain. > b) In order to introduce a new label type: All DNS > infrastructure > needs to understand the new label type before it is can be > reliability used. Lots of DNS processing elements barf at > labels that > they do not expect. For example number of firewalls drop > answers > if the name of the first answer record is not compressed (a > protocol violation) Understood. Of course, some of the same things could be said about EDNS0 itself. > Based on this experience the DNSEXT felt that the best message > to send > out is new label types do not work, in the current Internet. > Deploying a new label type requires an effort similar to what > we are > going through right now with DNSSEC, upgrade all DNS protocol > processing elements, plus systems and processes that feed and > operate the DNS systems. But, coming back to my example, this is exactly the problem with internationalization. If one is willing to settle for keeping ASCII primary and applying a hack to accommodate non-ASCII characters, then one can avoid that very long and expensive transition effort. We have such a solution in IDNA. Some parts of the external community (including, albeit largely for historical reasons, a couple of very significant vendors) do not believe that is a satisfactory solution and that it would be better to have all characters that are considered valid treated equally. That puts your DNSSEC comparison into an interesting light. I believe that, when the DNSSEC effort started, the community would have been appalled at how long deployment would take and how painful it would be (with or without allowances were made for reduced expectations). But, as far as I know, we didn't have a good alternative way to do the job even in retrospect, so, presumably, the community decided that the pain and slow deployment associated with DNSSEC was (and is) worth it. Is a clean i18n model on a par with that? I don't know (and I'm personally willing to live with IDNA forever if we have to). But I'm sure that some people would be willing to make the case that such an i18n model is at least as important as DNSSEC and worth whatever effort it would take. As I've tried to say to Mark, based on the experience with binary labels, I would have no problem if the document deprecated binary labels, noted that deployment of different label types is horrendously difficult and/or very slow and hence not recommended unless the requirement is really important and there are no plausible alternatives, and then just moved on. There just doesn't seem to be nearly enough documented support for moving beyond "we had a bad experience" to "completely discard the feature/ capability". I also note that part of what you said is "...do not work, in the current Internet". I'm not sure what that means. If it means that the WG has reached the conclusion that there are some set of possible extensions that are sufficiently problematic (including different label interpretation models) that they are simply incompatible with the current DNS, i.e., that those who want them should be working on a plausible strategy for what is variously called DNSng or DNS2, I think that would be great and an extremely useful contribution, especially as expectations for things that DNS should do/support that lie well outside the original design assumptions continue to increase... but the document doesn't say that, much less describe that boundary. > Personally at the time of introduction of the label registry I > thought > it was a good idea, but operational realities demonstrated > that its time > had passed, i.e. if we had defined more label types in > RFC1034/5 then > there might have been a chance. But given how many > implementations are > based on coding against what that implementor sees in traffic > dumps > rather than what is in the RFC's makes extending DNS much > harder than it should be, upgrading the installed base takes > decades. Absolutely. But those same comments couple be an argument for closing EDS down entirely except for the facilities needed to support DNSSEC and maybe DNAME, i.e., "closing the registries" as far as new options, header flags, etc., are concerned. What you've said is a strong argument for caution, but I'm trying to understand what makes label types so special as to require this special treatment and to either get that understanding into the document or to back away from the drastic measure. > > > > If you think the text in the document does not reflect the > lessons > learned strongly enough I will be happy work with you on > putting better text in the document. From ogud@ogud.com Tue Oct 2 15:34:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6144D21F85EF for ; Tue, 2 Oct 2012 15:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8aJ3mQuu57p for ; Tue, 2 Oct 2012 15:34:18 -0700 (PDT) Received: from smtp148.iad.emailsrvr.com (smtp148.iad.emailsrvr.com [207.97.245.148]) by ietfa.amsl.com (Postfix) with ESMTP id 844F321F8549 for ; Tue, 2 Oct 2012 15:34:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 10AC31A0411; Tue, 2 Oct 2012 18:34:18 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id A613E1A0480; Tue, 2 Oct 2012 18:34:17 -0400 (EDT) Message-ID: <506B6BE9.2000805@ogud.com> Date: Tue, 02 Oct 2012 18:34:17 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: John C Klensin References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <506B01D1.9080708@ogud.com> <8F3DCBA9A3AF566810CD1061@JcK-HP8200.jck.com> In-Reply-To: <8F3DCBA9A3AF566810CD1061@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, 'IETF-Discussion list' Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 22:34:24 -0000 My original message was not copied to ietf mailing list. John quoted all of my text so I'm sending this follow-up to ietf as well as dnsext mailing lists. On 02/10/2012 12:38, John C Klensin wrote: > > --On Tuesday, October 02, 2012 11:01 -0400 Olafur Gudmundsson > wrote: > >> ... >>>> The IESG has received a request from the DNS Extensions WG >>>> (dnsext) to consider the following document: - 'Extension >>>> Mechanisms for DNS (EDNS(0))' >>>> as Internet >>>> Standard >> ... >> John, >> >> We learned two main things from binary labels: >> a) the specification of them caused expensive processing, and >> the >> utility of binary labels w/o A6 record was none. > Huh? While I certainly agree that the binary label experiment > failed, RFC 2673 didn't seem to me to have anything to do with > A6 records and a quick review just now doesn't convince me > otherwise. As I recall, it came out of the period in which we > were evolving to classless IPv4 addresses (with prefix > lengths/netmasks on arbitrary bit boundaries) and was intended > to permit address delegation entities to easily delegate ranges > of reverse-mapping records to the appropriate address-holding > entities for management. The failure of that idea (for the > reasons you outline) contributed, IMO, to PTR records being much > less useful today than they were pre-CIDR. > > Conversely, if a significant reason for getting rid of binary > labels was the link to A6 records, why doesn't the document just > say "these existed solely to support A6 records, A6 records have > been deprecated, therefore these are too". All of us could be > spared the discussion of why they failed relative to deployment > issues, etc. But the question of whether it is appropriate to > get rid of label types would remain. > >> b) In order to introduce a new label type: All DNS >> infrastructure >> needs to understand the new label type before it is can be >> reliability used. Lots of DNS processing elements barf at >> labels that >> they do not expect. For example number of firewalls drop >> answers >> if the name of the first answer record is not compressed (a >> protocol violation) > Understood. Of course, some of the same things could be said > about EDNS0 itself. > >> Based on this experience the DNSEXT felt that the best message >> to send >> out is new label types do not work, in the current Internet. >> Deploying a new label type requires an effort similar to what >> we are >> going through right now with DNSSEC, upgrade all DNS protocol >> processing elements, plus systems and processes that feed and >> operate the DNS systems. > But, coming back to my example, this is exactly the problem with > internationalization. If one is willing to settle for keeping > ASCII primary and applying a hack to accommodate non-ASCII > characters, then one can avoid that very long and expensive > transition effort. We have such a solution in IDNA. Some parts > of the external community (including, albeit largely for > historical reasons, a couple of very significant vendors) do not > believe that is a satisfactory solution and that it would be > better to have all characters that are considered valid treated > equally. > > That puts your DNSSEC comparison into an interesting light. I > believe that, when the DNSSEC effort started, the community > would have been appalled at how long deployment would take and > how painful it would be (with or without allowances were made > for reduced expectations). But, as far as I know, we didn't > have a good alternative way to do the job even in retrospect, > so, presumably, the community decided that the pain and slow > deployment associated with DNSSEC was (and is) worth it. Is a > clean i18n model on a par with that? I don't know (and I'm > personally willing to live with IDNA forever if we have to). > But I'm sure that some people would be willing to make the case > that such an i18n model is at least as important as DNSSEC and > worth whatever effort it would take. > > As I've tried to say to Mark, based on the experience with > binary labels, I would have no problem if the document > deprecated binary labels, noted that deployment of different > label types is horrendously difficult and/or very slow and hence > not recommended unless the requirement is really important and > there are no plausible alternatives, and then just moved on. > There just doesn't seem to be nearly enough documented support > for moving beyond "we had a bad experience" to "completely > discard the feature/ capability". > > I also note that part of what you said is "...do not work, in > the current Internet". I'm not sure what that means. If it > means that the WG has reached the conclusion that there are some > set of possible extensions that are sufficiently problematic > (including different label interpretation models) that they are > simply incompatible with the current DNS, i.e., that those who > want them should be working on a plausible strategy for what is > variously called DNSng or DNS2, I think that would be great and > an extremely useful contribution, especially as expectations for > things that DNS should do/support that lie well outside the > original design assumptions continue to increase... but the > document doesn't say that, much less describe that boundary. Well as if DNS has reached some limits to extensibility this document points out the label types. Talking about other limitations is outside the documents scope. >> Personally at the time of introduction of the label registry I >> thought >> it was a good idea, but operational realities demonstrated >> that its time >> had passed, i.e. if we had defined more label types in >> RFC1034/5 then >> there might have been a chance. But given how many >> implementations are >> based on coding against what that implementor sees in traffic >> dumps >> rather than what is in the RFC's makes extending DNS much >> harder than it should be, upgrading the installed base takes >> decades. > Absolutely. But those same comments couple be an argument for > closing EDS down entirely except for the facilities needed to > support DNSSEC and maybe DNAME, i.e., "closing the registries" > as far as new options, header flags, etc., are concerned. What > you've said is a strong argument for caution, but I'm trying to > understand what makes label types so special as to require this > special treatment and to either get that understanding into the > document or to back away from the drastic measure. Labels only work when all the severs for a zone that has a new label type, in ADDITION sufficient fraction servers in all zones above that zone MUST understand the new label type. in ADDITION all resolvers uses MUST understand the label type or treat it as unknown label type. This is even harder problem than DNSSEC as it was possible to fetch data via most resolvers and configure local trust anchors or use TAR/DLV to create islands of trust. Olafur >> >> >> >> If you think the text in the document does not reflect the >> lessons >> learned strongly enough I will be happy work with you on >> putting better text in the document. From marka@isc.org Tue Oct 2 18:16:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF23821F8588; Tue, 2 Oct 2012 18:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIdXdKasC812; Tue, 2 Oct 2012 18:16:13 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 609E321F8574; Tue, 2 Oct 2012 18:16:13 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4D39C5F99EB; Wed, 3 Oct 2012 01:16:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:a001:3387:3ce7:5925]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 74A37216C59; Wed, 3 Oct 2012 01:16:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 526A82873A5E; Wed, 3 Oct 2012 11:15:56 +1000 (EST) To: Olafur Gudmundsson From: Mark Andrews References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <506B01D1.9080708@ogud.com> <8F3DCBA9A3AF566810CD1061@JcK-HP8200.jck.com> <506B6BE9.2000805@ogud.com> In-reply-to: Your message of "Tue, 02 Oct 2012 18:34:17 -0400." <506B6BE9.2000805@ogud.com> Date: Wed, 03 Oct 2012 11:15:56 +1000 Message-Id: <20121003011556.526A82873A5E@drugs.dv.isc.org> Cc: John C Klensin , dnsext@ietf.org, 'IETF-Discussion list' Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 01:16:14 -0000 > Labels only work when all the severs for a zone that has a new label type, > in ADDITION sufficient fraction servers in all zones above that zone > MUST understand the new > label type. Not true. Binary labels could have been made to work by removing the left hand label until the remaining suffix consisted of only RFC 1035 labels, looking up the servers for that domain, then resuming query processing using those servers similar to what we do with DS lookups. Such processing would be required for any new label type used in a QNAME and would be a significant change to the standard query logic. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From john-ietf@jck.com Wed Oct 3 05:10:52 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8748021F86B8; Wed, 3 Oct 2012 05:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhrJEpS+SHWX; Wed, 3 Oct 2012 05:10:51 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id BA31F21F86BD; Wed, 3 Oct 2012 05:10:51 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJNmo-000C7p-Dh; Wed, 03 Oct 2012 08:10:46 -0400 Date: Wed, 03 Oct 2012 08:10:41 -0400 From: John C Klensin To: =?UTF-8?Q?Jo=C3=A3o_Damas?= , Mark Andrews Message-ID: <396CFDC14B6FEF29A37A2FFF@JcK-HP8200.jck.com> In-Reply-To: <84187E41-0CEC-4CA2-801D-5AB1171FFF9B@bondis.org> References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <506B01D1.9080708@ogud.com> <8F3DCBA9A3AF566810CD1061@JcK-HP8200.jck.com> <506B6BE9.2000805@ogud.com> <20121003011556.526A82873A5E@drugs.dv.isc.org> <84187E41-0CEC-4CA2-801D-5AB1171FFF9B@bondis.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: dnsext@ietf.org, Olafur Gudmundsson , 'IETF-Discussion list' Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 12:10:52 -0000 --On Wednesday, October 03, 2012 10:43 +0200 Jo=C3=A3o Damas wrote: > I believe you are saying the same things when you are both > saying that for this to work there may be more than one way to > do it but all options require completely new functionality in > implementations (either by implementing support for new labels > types or by implementing new fall back behavior). The > conclusion is still the same. Hmm. I'm not completely sure who "you" was intended to include, but my conclusion from the above is that there is no substantial justification for eliminating, at this time, a capability that might prove better on balance when and if new capabilities are considered and tradeoffs evaluated. To summarize my perspective on this as of now: (1) No one is making a case for retaining binary labels (2) The case has not been made, at least in the document, for eliminating label types. An argument that there are other ways to do a particular type of label is not persuasive unless there is a comprehensive and written analysis of what other labels might be considered and what the tradeoffs among approaches would be. And an argument that almost any significant added functionality would be very slow and costly to deploy may be an argument for not approving such functionality, but it is not an argument for eliminating one, but not all, of the underlying capabilities. IMO, this discussion has turned up two ways in which the case for eliminating the possibility of additional label types could be made: (2.1) Demonstrating that simply having the capability defined and available in principle is somehow harmful. (2.2) The WG has consensus on a bright line that defines the nature of proposals that would require going to DNSng rather than EDNSx-type extensions to the current model, has concluded that any extensions or alterations to the label definition of 1034/1035 would require crossing that line, and is prepared to document that line and get IETF consensus on it (either as part of this document or one normatively referenced from it). best, john From anicoll@cert.org Wed Oct 3 05:28:14 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD8721F86AF for ; Wed, 3 Oct 2012 05:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pvv9c7jWZtC for ; Wed, 3 Oct 2012 05:28:13 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 44D0121F86AA for ; Wed, 3 Oct 2012 05:28:13 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id q93CSClX010101 for ; Wed, 3 Oct 2012 08:28:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1349267292; bh=p4hY7RxXRjPoNwgrimUsD1SXclUL59RwbHF0lo5unLY=; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=ASHPkiuse/ahIEWQSYuMbYlquukPDMtk+/1LpTqrvWmalIRZZfbAAmgGU25G1eXYT dG6XdB+I603Z4ClmoP7oHpwWFJHkCVB7vIae1IzdBpO3egbCUgNyHVRQkZo90qeAeV 0TlWC8WIeKHSNtSNkOhYhgnimDRF0y0eF/As2NWs= Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id q93CSBLv027652 for ; Wed, 3 Oct 2012 08:28:12 -0400 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.13]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Wed, 3 Oct 2012 08:28:11 -0400 From: Alex Nicoll To: "dnsext@ietf.org" Date: Wed, 3 Oct 2012 08:28:10 -0400 Thread-Topic: [Slightly OT] Past DNSEXT actions? Thread-Index: Ac2hYV5y9GGudM35TY6W4AHc4ebc/Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-encoding-format: MIME x-pgp-encoding-version: 2.0.2 x-pgp-mapi-encoding-version: 2.5.0 acceptlanguage: en-US Content-Type: multipart/signed; boundary="PGP_Universal_2B4872A3_350BF52B_C0A130C7_06A41F9C"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Subject: [dnsext] [Slightly OT] Past DNSEXT actions? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 12:28:14 -0000 --PGP_Universal_2B4872A3_350BF52B_C0A130C7_06A41F9C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: QUOTED-PRINTABLE One of the problems inherent in an eclectic system like the IETF is a recor= d of just what has happened when. While I realize I can search past mailin= g lists and discussion forums, it usually isn't an optimal way to find the = information I'm looking for - which is usually in the head of one of the pe= ople on this list. So - my apologies if this isn't exactly on topic for th= e list, but I'm betting you guys know the answer. I was told recently that NS records in a parent domain should be authoritat= ive and be used in preference to NS records that exist at a child domain. = The reason for this was "disaster recovery techniques." I couldn't find mu= ch on this on DNSOP, but RFC 1034 says: --- RFC1034 Section 4.2.1: The RRs that describe cuts around the bottom of the zone are NS RRs that name the servers for the subzones. Since the cuts are between nodes, these RRs are NOT part of the authoritative data of the zone, and should be exactly the same as the corresponding RRs in the top node of the subzone. Since name servers are always associated with zone boundaries, NS RRs are only found at nodes which are the top node of some zone. In the data that makes up a zone, NS RRs are found at the top node of the zone (and are authoritative) and at cuts around the bottom of the zone (where they are not authoritative), but never in between. --- This statement seems to say that the NS records at a parent that point to a= child domain are NOT authoritative under any circumstance. =20 So - my question (sorry for the long background) - has DNSEXT taken or know= of any action on the part of the IETF that would override that clause to m= ake NS records at a parent authoritative? Thanks in advance! -Alex Alex Nicoll Senior Cybersecurity Analyst=20 CERT Carnegie Mellon University/Software Engineering Institute anicoll@cert.org (412)268-9205 (USA) Vaporware: A much discussed piece of software that doesn=E2=80=99t actuall= y exist. Cloud: Condensed Vapor. --PGP_Universal_2B4872A3_350BF52B_C0A130C7_06A41F9C Content-Type: application/pgp-signature; name="PGP.sig" Content-Transfer-Encoding: 7BIT Content-Disposition: attachment; filename="PGP.sig" -----BEGIN PGP SIGNATURE----- Version: 10.1.1 (Build 10) iQEVAwUBUGwvWpbgQy4yHE0eAQidwQf9EqkgDIetOl08vgMsqzOl5h6Gl3fzuLNa 2AS6dYzXyE77IXHUSc1uLZde12660D73lk9YoKGk3DLBk75GyOMXVOEtLymb/wh0 Gxd5cyrOyjuDRy2yJe+t5ldIV6d75JS3U4p7MsDWA1Ye2l9tPStgrWNgdD4rSUma m28b0azQ6qIgUXMW+Sex+KqmRJ5Uvpy+lS0i74hQzx7wHr2PvjZAHa9+GgCXbw7u ttQiIOCvRrRCi+G9y5IJXV6ahBXEGwQoonMOCDIHr6DaWNpogNEK0iV4FF3E6xq1 pqFv0hUXL/8fxtnJkmlDjuUeKbz6G3CFlLz3z7AcS1ludqUszfCSnw== =h2Xp -----END PGP SIGNATURE----- --PGP_Universal_2B4872A3_350BF52B_C0A130C7_06A41F9C-- From fanf2@hermes.cam.ac.uk Wed Oct 3 05:49:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEACD21F86D5 for ; Wed, 3 Oct 2012 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.205 X-Spam-Level: X-Spam-Status: No, score=-5.205 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKHR2VxTT1EH for ; Wed, 3 Oct 2012 05:49:38 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id B16D721F86D4 for ; Wed, 3 Oct 2012 05:49:38 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:33027) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1TJOOO-0006aB-rW (Exim 4.72) (return-path ); Wed, 03 Oct 2012 13:49:36 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TJOOO-0007mp-IE (Exim 4.72) (return-path ); Wed, 03 Oct 2012 13:49:36 +0100 Date: Wed, 3 Oct 2012 13:49:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alex Nicoll In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dnsext@ietf.org" Subject: Re: [dnsext] [Slightly OT] Past DNSEXT actions? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 12:49:39 -0000 Alex Nicoll wrote: > > This statement seems to say that the NS records at a parent that point > to a child domain are NOT authoritative under any circumstance. > > So - my question (sorry for the long background) - has DNSEXT taken or > know of any action on the part of the IETF that would override that > clause to make NS records at a parent authoritative? No, it has been reinforced. In particulat, DNSSEC makes it extra clear that delegation records are not authoritative. See RFC 2181 section 5.4.1 especially the last paragraph, and RFC 4035 section 2.2. There are probably other instances. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From rwfranks@gmail.com Wed Oct 3 06:41:08 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A56B21F84EA for ; Wed, 3 Oct 2012 06:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9CAUP+tOvE2 for ; Wed, 3 Oct 2012 06:41:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C56BB21F84B6 for ; Wed, 3 Oct 2012 06:41:07 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so8939444vbb.31 for ; Wed, 03 Oct 2012 06:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b+W3S/g6RMHRJgtf+Eu/HTB1iL9X/RLZDUNb2HXxVHg=; b=KN1zBkZzD7KpGl/LJt32zZsjYmKMP3m7Yn1BP1xNnD4vqnAExO3mtMosLfF2giDBaq 7SwgTzlUNCq4c2nb5j2KDJIhw51Li7qVyR1AYiuQTyu7gnbZa1vKH9AvEDxVC+9PK9g9 RCP+ULSum6Hgx+ts8HUD4cy0KMV3Em1HML6lafFGbOam2TAiGJB/InUzK9n0fNWf8oaa PsDK+IXy0+NsSwGICE2UZLAHID+B3URffN49d1lWnHFtDQgtrkuvjtZdZE2hAIXOM7JG +avHJJy/caW3muEpXSdaNhjqkEV7X4ux+br7gvwVjAIju54FSUqkvbGD26PgoSHfGJ1n JAeQ== Received: by 10.52.33.130 with SMTP id r2mr927722vdi.43.1349271667308; Wed, 03 Oct 2012 06:41:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.55.166 with HTTP; Wed, 3 Oct 2012 06:40:46 -0700 (PDT) In-Reply-To: References: From: Dick Franks Date: Wed, 3 Oct 2012 14:40:46 +0100 Message-ID: To: Alex Nicoll Content-Type: text/plain; charset=UTF-8 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] [Slightly OT] Past DNSEXT actions? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:41:08 -0000 On 3 October 2012 13:28, Alex Nicoll wrote: > > I was told recently that NS records in a parent domain should be authoritative and be used in preference to NS records that exist at a child domain Sadly, you were misinformed. RFC2181, 6.1 says: ... The NS records that indicate a zone cut are the property of the child zone created, as are any other records for the origin of that child zone, or any sub-domains of it. A server for a zone should not return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone. Dick -- From marka@isc.org Wed Oct 3 06:58:30 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0F421F84BF for ; Wed, 3 Oct 2012 06:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztlgrcIrbEDe for ; Wed, 3 Oct 2012 06:58:28 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 6A50621F84B5 for ; Wed, 3 Oct 2012 06:58:28 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 38A09C95DD; Wed, 3 Oct 2012 13:58:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 01450216C40; Wed, 3 Oct 2012 13:58:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6997F2878CE9; Wed, 3 Oct 2012 23:58:15 +1000 (EST) To: Tony Finch From: Mark Andrews References: In-reply-to: Your message of "Wed, 03 Oct 2012 13:49:36 +0100." Date: Wed, 03 Oct 2012 23:58:15 +1000 Message-Id: <20121003135815.6997F2878CE9@drugs.dv.isc.org> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] [Slightly OT] Past DNSEXT actions? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:58:30 -0000 In message , Tony Fi nch writes: > Alex Nicoll wrote: > > > > This statement seems to say that the NS records at a parent that point > > to a child domain are NOT authoritative under any circumstance. > > > > So - my question (sorry for the long background) - has DNSEXT taken or > > know of any action on the part of the IETF that would override that > > clause to make NS records at a parent authoritative? > > No, it has been reinforced. In particulat, DNSSEC makes it extra clear > that delegation records are not authoritative. See RFC 2181 section 5.4.1 > especially the last paragraph, and RFC 4035 section 2.2. There are > probably other instances. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, > occasionally poor at first. The child is authoritative for the contents of the NS records. The parent is authoritative for the existance of the delegation. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rafiee@hpi.uni-potsdam.de Wed Oct 3 10:06:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819E621F8673 for ; Wed, 3 Oct 2012 10:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EkMJ59HNZWQ for ; Wed, 3 Oct 2012 10:06:22 -0700 (PDT) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id C3FB921F867F for ; Wed, 3 Oct 2012 10:06:21 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id 982D7D2C95 for ; Wed, 3 Oct 2012 19:06:19 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Wed, 3 Oct 2012 19:06:19 +0200 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" Date: Wed, 3 Oct 2012 19:06:15 +0200 Thread-Topic: draft-rafiee-cga-tsig-00 - request for comments Thread-Index: Ac2hiQXKnXZ+GspkRJ6N8oLgvD0ccAAAD8KQ Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924CD4EAD308MXMA1Rhpiuni_" MIME-Version: 1.0 Subject: [dnsext] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:06:22 -0000 --_000_EA738325B0580041A50A364F5F76B68924CD4EAD308MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have submitted an RFC draft to the follow link: http://www.ietf.org/inter= net-drafts/draft-rafiee-cga-tsig-00.txt. Please take a look at it and share= you comments so that I might improve it. Thanks, Hosnieh Filename: draft-rafiee-cga-tsig Revision: 00 Title: Transaction SIGnature (TSIG) using CGA Algorith= m in IPv6 Creation date: 2012-09-30 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-rafiee-cga-tsig-= 00.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-cga-tsig Htmlized: http://tools.ietf.org/html/draft-rafiee-cga-tsig-00 --_000_EA738325B0580041A50A364F5F76B68924CD4EAD308MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I have submitted an RFC draft to the follow= link: http://www.ietf.org/internet-drafts/draft-rafiee-cga-tsig-00.txt. Please take a look at it and share you comments so that I might improve= it.

 

Thanks,

Hosnieh

 

Fil= ename:            dr= aft-rafiee-cga-tsig

Revision: &n= bsp;            00

Title:     &n= bsp;            = ;    Transaction SIGnature (TSIG) using CGA Algorithm in IPv= 6

Creation date:   2012-09-= 30

WG ID:    &nbs= p;             = Individual Submission

Number of pages= : 13

URL:    &nbs= p;        http://www.ietf.org/internet= -drafts/draft-rafiee-cga-tsig-00.txt

Status:          http://datatrack= er.ietf.org/doc/draft-rafiee-cga-tsig

Htmlized:        http://tools.ietf.org/html/dr= aft-rafiee-cga-tsig-00

 

 

 

= --_000_EA738325B0580041A50A364F5F76B68924CD4EAD308MXMA1Rhpiuni_-- From marka@isc.org Wed Oct 3 20:10:58 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1A911E80D1 for ; Wed, 3 Oct 2012 20:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IuSHxU+V+yF for ; Wed, 3 Oct 2012 20:10:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AC3AE11E80C5 for ; Wed, 3 Oct 2012 20:10:57 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 36960C947D for ; Thu, 4 Oct 2012 03:10:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:71db:ded4:5bca:c9a1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D89C0216C7B for ; Thu, 4 Oct 2012 03:10:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 05A3E287FA2C for ; Thu, 4 Oct 2012 13:10:51 +1000 (EST) To: dnsext@ietf.org From: Mark Andrews Date: Thu, 04 Oct 2012 13:10:50 +1000 Message-Id: <20121004031051.05A3E287FA2C@drugs.dv.isc.org> Subject: [dnsext] Corner case: KEY and DNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 03:10:58 -0000 Since KEY and CNAME can co-exist (RFC 4035, Section 2.5), what should the response to a KEY query below a DNAME produce, especially w.r.t. DNSSEC. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Wed Oct 3 23:45:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9C421F8617 for ; Wed, 3 Oct 2012 23:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS60H3cQ6w-z for ; Wed, 3 Oct 2012 23:45:23 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 320DD21F85B8 for ; Wed, 3 Oct 2012 23:45:23 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 522F0C9598; Thu, 4 Oct 2012 06:45:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:71db:ded4:5bca:c9a1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 10F4E216C7B; Thu, 4 Oct 2012 06:45:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id AF18D2886943; Thu, 4 Oct 2012 16:45:17 +1000 (EST) To: "Rafiee, Hosnieh" From: Mark Andrews References: In-reply-to: Your message of "Wed, 03 Oct 2012 19:06:15 +0200." Date: Thu, 04 Oct 2012 16:45:17 +1000 Message-Id: <20121004064517.AF18D2886943@drugs.dv.isc.org> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 06:45:23 -0000 Why are the CGA parameters not part of other data? That field was added to TSIG to hold stuff similar to CGA parameters. By making it a seperate field you break all existing TSIG parsers. The CGA parameters could just be defined to be the initial part of other data. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rafiee@hpi.uni-potsdam.de Thu Oct 4 00:02:21 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF95D21F863C for ; Thu, 4 Oct 2012 00:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-XH8UeIdJvu for ; Thu, 4 Oct 2012 00:02:21 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 25F0521F8630 for ; Thu, 4 Oct 2012 00:02:20 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 8F67B169EA1; Thu, 4 Oct 2012 09:02:16 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Thu, 4 Oct 2012 09:02:16 +0200 From: "Rafiee, Hosnieh" To: Mark Andrews Date: Thu, 4 Oct 2012 09:02:12 +0200 Thread-Topic: [dnsext] draft-rafiee-cga-tsig-00 - request for comments Thread-Index: Ac2h+9YD0/fs4iafROmGqpZxb6nDAQAAKJ2g Message-ID: References: <20121004064517.AF18D2886943@drugs.dv.isc.org> In-Reply-To: <20121004064517.AF18D2886943@drugs.dv.isc.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 07:02:21 -0000 Hello Mark, Thank you for your comment. Yes can be,=20 But the reason is the TSIG parsers need to be adapted with this new algori= thm and it is not different whether to put it in Other DATA or after Other = DATA field. Because Other Data has variable length too like the CGA-TSIG DA= TA. If I missed something please advise. Thank you. Hosnieh -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Thursday, October 04, 2012 8:45 AM To: Rafiee, Hosnieh Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments Why are the CGA parameters not part of other data? That field was added to= TSIG to hold stuff similar to CGA parameters. By making it a seperate fie= ld you break all existing TSIG parsers. The CGA parameters could just be d= efined to be the initial part of other data. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Thu Oct 4 00:15:35 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044EC21F8628 for ; Thu, 4 Oct 2012 00:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0BO-T4jqoUk for ; Thu, 4 Oct 2012 00:15:34 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 58ED621F8624 for ; Thu, 4 Oct 2012 00:15:34 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id BCC465F991B; Thu, 4 Oct 2012 07:15:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:71db:ded4:5bca:c9a1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 24FD4216C7B; Thu, 4 Oct 2012 07:15:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 143482886BA5; Thu, 4 Oct 2012 17:15:21 +1000 (EST) To: "Rafiee, Hosnieh" From: Mark Andrews References: <20121004064517.AF18D2886943@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 04 Oct 2012 09:02:12 +0200." Date: Thu, 04 Oct 2012 17:15:20 +1000 Message-Id: <20121004071521.143482886BA5@drugs.dv.isc.org> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 07:15:35 -0000 In message , "Rafiee, Hosnieh" writes: > Hello Mark, > Thank you for your comment. Yes can be,=20 > But the reason is the TSIG parsers need to be adapted with this new algori= > thm and it is not different whether to put it in Other DATA or after Other = > DATA field. Because Other Data has variable length too like the CGA-TSIG DA= > TA. > If I missed something please advise. It is different. Examine the behaviour of CGA-TSIG client talking to a non CGA-TSIG aware server. The response to using a unknown algorithm should be BADKEY not FORMERR because the server couldn't parse the TSIG record. Mark > Thank you. > Hosnieh > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org]=20 > Sent: Thursday, October 04, 2012 8:45 AM > To: Rafiee, Hosnieh > Cc: dnsext@ietf.org > Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments > > > Why are the CGA parameters not part of other data? That field was added to= > TSIG to hold stuff similar to CGA parameters. By making it a seperate fie= > ld you break all existing TSIG parsers. The CGA parameters could just be d= > efined to be the initial part of other data. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rafiee@hpi.uni-potsdam.de Thu Oct 4 00:27:56 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FF821F85B8 for ; Thu, 4 Oct 2012 00:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOnPIKPcnjXh for ; Thu, 4 Oct 2012 00:27:55 -0700 (PDT) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id 23E9921F8487 for ; Thu, 4 Oct 2012 00:27:54 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id C9D3ED2C9F; Thu, 4 Oct 2012 09:27:52 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Thu, 4 Oct 2012 09:27:52 +0200 From: "Rafiee, Hosnieh" To: Mark Andrews Date: Thu, 4 Oct 2012 09:27:49 +0200 Thread-Topic: [dnsext] draft-rafiee-cga-tsig-00 - request for comments Thread-Index: Ac2iAAv/xkLSnljIRl+2zRi3xbFtAQAAYutQ Message-ID: References: <20121004064517.AF18D2886943@drugs.dv.isc.org> <20121004071521.143482886BA5@drugs.dv.isc.org> In-Reply-To: <20121004071521.143482886BA5@drugs.dv.isc.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 07:27:56 -0000 Thank you, I will change it and move the whole CGA-TSIG DATA inside the Other DATA. -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Thursday, October 04, 2012 9:15 AM To: Rafiee, Hosnieh Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments In message , "Rafiee, Hosnieh" writes: > Hello Mark, > Thank you for your comment. Yes can be,=3D20 But the reason is the TSIG= =20 > parsers need to be adapted with this new algori=3D thm and it is not=20 > different whether to put it in Other DATA or after Other =3D DATA field.= =20 > Because Other Data has variable length too like the CGA-TSIG DA=3D TA. > If I missed something please advise. It is different. Examine the behaviour of CGA-TSIG client talking to a non= CGA-TSIG aware server. The response to using a unknown algorithm should b= e BADKEY not FORMERR because the server couldn't parse the TSIG record. Mark > Thank you. > Hosnieh > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org]=3D20 > Sent: Thursday, October 04, 2012 8:45 AM > To: Rafiee, Hosnieh > Cc: dnsext@ietf.org > Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments >=20 >=20 > Why are the CGA parameters not part of other data? That field was=20 > added to=3D TSIG to hold stuff similar to CGA parameters. By making it= =20 > a seperate fie=3D ld you break all existing TSIG parsers. The CGA=20 > parameters could just be d=3D efined to be the initial part of other data= . >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ogud@ogud.com Thu Oct 4 09:51:43 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04CC21F86E4 for ; Thu, 4 Oct 2012 09:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyT9Dqi-LfQZ for ; Thu, 4 Oct 2012 09:51:42 -0700 (PDT) Received: from smtp118.iad.emailsrvr.com (smtp118.iad.emailsrvr.com [207.97.245.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC9D21F85F0 for ; Thu, 4 Oct 2012 09:51:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp51.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id CC0FF200B1; Thu, 4 Oct 2012 12:51:41 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp51.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id A116C20118; Thu, 4 Oct 2012 12:51:40 -0400 (EDT) Message-ID: <506DBE9B.3070209@ogud.com> Date: Thu, 04 Oct 2012 12:51:39 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mark Andrews References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <506B01D1.9080708@ogud.com> <8F3DCBA9A3AF566810CD1061@JcK-HP8200.jck.com> <506B6BE9.2000805@ogud.com> <20121003011556.526A82873A5E@drugs.dv.isc.org> In-Reply-To: <20121003011556.526A82873A5E@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John C Klensin , dnsext@ietf.org, 'IETF-Discussion list' Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 16:51:43 -0000 On 02/10/2012 21:15, Mark Andrews wrote: >> Labels only work when all the severs for a zone that has a new label type, >> in ADDITION sufficient fraction servers in all zones above that zone >> MUST understand the new >> label type. > > Not true. Binary labels could have been made to work by removing > the left hand label until the remaining suffix consisted of only > RFC 1035 labels, looking up the servers for that domain, then > resuming query processing using those servers similar to what we > do with DS lookups. > > Such processing would be required for any new label type used in a > QNAME and would be a significant change to the standard query logic. > > Mark > Mark, This will only work if all the recursive resolvers that "consumers" for this new label types have been updated AND the new label type is the left most label(s) in the name. Olafur From jinmei@isc.org Thu Oct 4 11:33:03 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAB91F0C94 for ; Thu, 4 Oct 2012 11:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEnrLadjt3A7 for ; Thu, 4 Oct 2012 11:33:03 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 193F41F0C8F for ; Thu, 4 Oct 2012 11:33:03 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id C7B025F990B for ; Thu, 4 Oct 2012 18:32:48 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (dhcp-57.sql1.isc.org [149.20.50.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E162A216C7B for ; Thu, 4 Oct 2012 18:32:46 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Thu, 04 Oct 2012 11:32:44 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dnsext@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [dnsext] type NSEC query at a parent's zone cut X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:33:03 -0000 I have a quick and simple question: what should an authoritative server return to a query for an NSEC RR(set) at the parent side of a zone cut? For example, what should a root server return to the query "com/NSEC"? I'm asking this because different root servers actually return different answers (and based on initial offlist communication this didn't seem to be a very known topic). It may depend on from where you query, but from the location I'm writing this message, the E, H, K and L root servers return a referral to .com (just like when asking for com/AAAA). Others return an authoritative answer that has the com/NSEC RR in the answer section (just like when asking for com/DS). According to Section 2.6 of RFC4035, the latter behavior seems to be correct: This specification updates the original DNS specification to allow NSEC and DS RR types at the parent side of a zone cut. These RRsets are authoritative for the parent when they appear at the parent side of a zone cut. Also, Section 4.2 of the RFC even seems to suggest the difference could lead to interoperability problems: When attempting to retrieve missing NSEC RRs that reside on the parental side at a zone cut, a security-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone. because if the parent zone's authoritative server returns a referral, the resolver cannot get what it tries to retrieve - although this may not be a serious problem due to the note in the preceding paragraph: Security-aware resolvers MAY query for missing security RRs in an attempt to perform validation; implementations that choose to do so must be aware that the answers received may not be sufficient to validate the original response. For example, a zone update may have changed (or deleted) the desired information between the original and follow-up queries. In any case, it's not clear to me whether the RFC specifies what the authoritative server should do at the parent side. It's very specific about the case for DS (Section 3.1.4.1), but it seems to be mostly silent about the NSEC case. Is this described somewhere (if so, which behavior is correct)? Or was there a consensus it can be an implementation dependent behavior? Any clarification is appreciated. Thanks, --- JINMEI, Tatuya From jinmei@isc.org Thu Oct 4 11:33:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30991F0C9E for ; Thu, 4 Oct 2012 11:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eLN12GcIfRQ for ; Thu, 4 Oct 2012 11:33:15 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 907E11F0C9D for ; Thu, 4 Oct 2012 11:33:15 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 864985F990D for ; Thu, 4 Oct 2012 18:33:07 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:64:70c6:d36f:991:7faa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0385F216C80 for ; Thu, 4 Oct 2012 18:33:06 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Thu, 04 Oct 2012 11:33:04 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dnsext@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [dnsext] type NSEC query at a parent's zone cut X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:33:16 -0000 I have a quick and simple question: what should an authoritative server return to a query for an NSEC RR(set) at the parent side of a zone cut? For example, what should a root server return to the query "com/NSEC"? I'm asking this because different root servers actually return different answers (and based on initial offlist communication this didn't seem to be a very known topic). It may depend on from where you query, but from the location I'm writing this message, the E, H, K and L root servers return a referral to .com (just like when asking for com/AAAA). Others return an authoritative answer that has the com/NSEC RR in the answer section (just like when asking for com/DS). According to Section 2.6 of RFC4035, the latter behavior seems to be correct: This specification updates the original DNS specification to allow NSEC and DS RR types at the parent side of a zone cut. These RRsets are authoritative for the parent when they appear at the parent side of a zone cut. Also, Section 4.2 of the RFC even seems to suggest the difference could lead to interoperability problems: When attempting to retrieve missing NSEC RRs that reside on the parental side at a zone cut, a security-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone. because if the parent zone's authoritative server returns a referral, the resolver cannot get what it tries to retrieve - although this may not be a serious problem due to the note in the preceding paragraph: Security-aware resolvers MAY query for missing security RRs in an attempt to perform validation; implementations that choose to do so must be aware that the answers received may not be sufficient to validate the original response. For example, a zone update may have changed (or deleted) the desired information between the original and follow-up queries. In any case, it's not clear to me whether the RFC specifies what the authoritative server should do at the parent side. It's very specific about the case for DS (Section 3.1.4.1), but it seems to be mostly silent about the NSEC case. Is this described somewhere (if so, which behavior is correct)? Or was there a consensus it can be an implementation dependent behavior? Any clarification is appreciated. Thanks, --- JINMEI, Tatuya From rafiee@hpi.uni-potsdam.de Thu Oct 4 11:38:29 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CF121F852B for ; Thu, 4 Oct 2012 11:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD8UMKLCvNMb for ; Thu, 4 Oct 2012 11:38:29 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 62EB921F851C for ; Thu, 4 Oct 2012 11:38:29 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 702C6169EA4 for ; Thu, 4 Oct 2012 20:38:25 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Thu, 4 Oct 2012 20:38:25 +0200 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" Date: Thu, 4 Oct 2012 20:38:21 +0200 Thread-Topic: [dnsext] draft-rafiee-cga-tsig-00 - request for comments Thread-Index: Ac2iXsCwkM2C+G5ATWOUUJMWKjs1owAAI18w Message-ID: References: <20121004064517.AF18D2886943@drugs.dv.isc.org> In-Reply-To: <20121004064517.AF18D2886943@drugs.dv.isc.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:38:30 -0000 Thank you, I will change it and move the whole CGA-TSIG DATA inside the Other DATA. -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Thursday, October 04, 2012 9:15 AM To: Rafiee, Hosnieh Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments In message , "Rafiee, Hosnieh" writes: > Hello Mark, > Thank you for your comment. Yes can be,=3D20 But the reason is the TSIG= =20 > parsers need to be adapted with this new algori=3D thm and it is not=20 > different whether to put it in Other DATA or after Other =3D DATA field.= =20 > Because Other Data has variable length too like the CGA-TSIG DA=3D TA. > If I missed something please advise. It is different. Examine the behaviour of CGA-TSIG client talking to a non= CGA-TSIG aware server. The response to using a unknown algorithm should b= e BADKEY not FORMERR because the server couldn't parse the TSIG record. Mark > Thank you. > Hosnieh -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Thursday, October 04, 2012 8:45 AM To: Rafiee, Hosnieh Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments Why are the CGA parameters not part of other data? That field was added to= TSIG to hold stuff similar to CGA parameters. By making it a seperate fie= ld you break all existing TSIG parsers. The CGA parameters could just be d= efined to be the initial part of other data. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From casey@deccio.net Thu Oct 4 13:41:51 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B5021F8759 for ; Thu, 4 Oct 2012 13:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40hBpmy10WPj for ; Thu, 4 Oct 2012 13:41:48 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8FEE21F875E for ; Thu, 4 Oct 2012 13:41:48 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1286764vcb.31 for ; Thu, 04 Oct 2012 13:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=uj51uPNMQqSiEHniPnSPp56W++B8aIaDxX1m/RU/OeU=; b=iFRBpe1n2/fPH/0qlGyk99EZAQBSZJRLbKtvGEBsfpIcQiK4kmnrz95n6G8AW7tKTA /IDttWtxxjeDynZzt3Mm8Siu5mHw7S5Hx9n14mwke/HmWyXPdV2XtzC7rarsss6uVZET q/x5BxftkTWOvlKNNr1fLwxwHIvxGxGKmIdgw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=uj51uPNMQqSiEHniPnSPp56W++B8aIaDxX1m/RU/OeU=; b=DDVXPbzcSm9cSgCkqX+QgGKbYMSiye/CPshlE3IKaK2j3rlqtfABEDJFamltH5GygW JbZVM+uHrgCBbcf6ScbrdXdjj+2JY20cEkJRPZDXs334m4PKZ2WgyG5hUfvPuBzrKNBP hSrZdjMcq5SVj7nGnuPHSt8PdJow/yfVXaYrs9zXiSUqNPtKvNBQ3TuvxF0IfpZq/b4E XD6QlPmkiqS84Py2I0Ich02U5BR+7Ssk3v7itTLRv/y1edhUqNjknad0CGEHkLVz03EX AcPNEEv0fbQNOWJjiX59z7KLcuqZeqRQwFxdbBZ85qWV59Yv9w5lnQF+ksQmJCkP3KGA 5z8A== MIME-Version: 1.0 Received: by 10.220.225.138 with SMTP id is10mr3907782vcb.24.1349383303566; Thu, 04 Oct 2012 13:41:43 -0700 (PDT) Received: by 10.58.32.234 with HTTP; Thu, 4 Oct 2012 13:41:43 -0700 (PDT) Date: Thu, 4 Oct 2012 13:41:43 -0700 Message-ID: From: Casey Deccio To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=14dae9ccd47679961a04cb41c804 X-Gm-Message-State: ALoCoQlL7NafEnuVo+YbJVkuP5+JlKA8gakARn8TGNcWtFXW82x/B0kZMhO/Wj162pxHX4/aY/pO Subject: [dnsext] SOA without NS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 20:41:51 -0000 --14dae9ccd47679961a04cb41c804 Content-Type: text/plain; charset=ISO-8859-1 What is the proper way to handle resolution of names within a "zone" in which an SOA exists but there are no NS records (neither in the delegating parent nor in the child itself)? Is it really a zone since there is no delegation via NS records? More specifically, where is the zone cut, as it pertains to DNSSEC? If the undelegated zone is signed with DNSKEY RRs co-existing with the SOA, do/should resolvers treat names in that namespace like: 1) names that have no legitimate RRSIGs (they point to the DNSKEYs whose name is not at the zone apex) and are therefore "bogus"; 2) signed names in a "zone" without any DS records and therefore "insecure"; or something else? As far as I can tell with a little experimentation, BIND and unbound both treat it as insecure. DNSViz is a little more harsh, but only because I hadn't considered the case (and the DNSKEYs aren't being retrieved... yet). But I'd like to throw a warning or error as appropriate. One example of this is buero.former03.de. Cheers, Casey --14dae9ccd47679961a04cb41c804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What is the proper way to handle resolution of names within a "zone&qu= ot; in which an SOA exists but there are no NS records (neither in the dele= gating parent nor in the child itself)? =A0Is it really a zone since there = is no delegation via NS records? =A0More specifically, where is the zone cu= t, as it pertains to DNSSEC? =A0If the undelegated zone is signed with DNSK= EY RRs co-existing with the SOA, do/should resolvers treat names in that na= mespace like: 1) names that have no legitimate RRSIGs (they point to the DN= SKEYs whose name is not at the zone apex) and are therefore "bogus&quo= t;; 2) signed names in a "zone" without any DS records and theref= ore "insecure"; or something else? =A0As far as I can tell with a= little experimentation, BIND and unbound both treat it as insecure. =A0DNS= Viz is a little more harsh, but only because I hadn't considered the ca= se (and the DNSKEYs aren't being retrieved... yet). =A0But I'd like= to throw a warning or error as appropriate. =A0One example of this is buero.former03.de.

Cheers,
Casey
--14dae9ccd47679961a04cb41c804-- From jim@rfc1035.com Thu Oct 4 14:32:36 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5511F0C54 for ; Thu, 4 Oct 2012 14:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc8BDHcDpFcB for ; Thu, 4 Oct 2012 14:32:36 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id CED2D1F0425 for ; Thu, 4 Oct 2012 14:32:35 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id BBA83CBC41C; Thu, 4 Oct 2012 22:32:33 +0100 (BST) Message-Id: <0C2D2E8E-0E36-4C4B-82BA-9536748B9AAE@rfc1035.com> From: Jim Reid To: Casey Deccio In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Oct 2012 22:32:33 +0100 References: X-Mailer: Apple Mail (2.936) Cc: dnsext@ietf.org Subject: Re: [dnsext] SOA without NS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:32:36 -0000 On 4 Oct 2012, at 21:41, Casey Deccio wrote: > What is the proper way to handle resolution of names within a "zone" > in > which an SOA exists but there are no NS records (neither in the > delegating > parent nor in the child itself)? Remedial lessons in DNS school for the admin and whoever implemented a broken name server that allowed such brokenness. :-) A zone cannot exist unless it has a SOA record and at least one NS record. A zone has exactly one SOA record. BIND9's named-checkzone will show what errors are reported when you try to load a zone file that breaks these fundamental rules. Other DNS software is available and may (or may not) be more forgiving about this level of brokenness. When a zone has no NS records, it can't be resolved. [Well, not unless there's zone-specific forwarding in place in some name server's configuration.] Lookups for names in such a zone will return NXDOMAIN since the zone does not exist. SERVFAILs might be returned if there is a delegation for such a zone in the parent and no NS record(s) in the child. A broken DNS implementation might answer authoritively and return "normal" answers when one of its zones has no NS records. It depends. > More specifically, where is the zone cut, as it pertains to DNSSEC? DNSSEC has no impact on the location of a zone cut. The zone cut is found in the parent at the place where it has NS records for the child, just as it's always been. Those NS records (and any related glue) are beneath the zone cut. Everything else is above it. The child should have a SOA record, signifying the start of a new zone of authority, and an NS RRset that's identical to (best case) or has at least one record in common with (worst case) those at the zone cut in the parent. > One example of this is buero.former03.de This "domain" is badly broken. Fixing it is a topic for another list. From casey@deccio.net Thu Oct 4 14:48:51 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115BC21F8513 for ; Thu, 4 Oct 2012 14:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM7X-s00Ator for ; Thu, 4 Oct 2012 14:48:49 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11C8C21F8514 for ; Thu, 4 Oct 2012 14:48:48 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1368817vcb.31 for ; Thu, 04 Oct 2012 14:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QBvFlPGF2gjJmOW6Dpt7i07jumYmiRohEZh1UW66634=; b=Vz3/bBfQn9UKnhdKAMucm9KrZ1Hx0xkEgp+jfBf+BIAWoO6KxVnhXZAiLOnc/Xv8U9 kPOPgJIReqvFPtN4H3TSQ3Ws8OD/RpebiRpRSL74/Lywxku5jQmXtpqJsm0SgSo6Du5P gvhOkd7RvQ0j3KDZkpZs0pnHes0NehHwx6PoE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=QBvFlPGF2gjJmOW6Dpt7i07jumYmiRohEZh1UW66634=; b=kjjsDu036MAVaauID9AjKRIh0S4eTpY2Hi0imT+zxXhgpIsXDFsP93g9IkZhscGmL9 ju7OWhJgQ8UAEXEVRq8PELvMEWxw8Q6mpdhiL8bUis1ueMFgA7bPWG9aE0bqFGZqYWdZ 0BOpPjn8RpeEkEn6z/hXXggkIC1ZJaFK+lhwVkfmZgUXhsqeLgR0uUPdY/NQ4Sajrf+P UL8/qYMORT/ipqMg7Q18w3O45Z7QRPRjEHZE9IPNBDI+h8LL8rI0Bwgm9TXQWJb6RbOX Cgpiqu8Jz9kEo2sAW6/NeLUpOMCvVUKoOhcV+Lsayjhl3DKdlo05DJrgMcibT9RSMsch qb3A== MIME-Version: 1.0 Received: by 10.220.225.138 with SMTP id is10mr4007487vcb.24.1349387328398; Thu, 04 Oct 2012 14:48:48 -0700 (PDT) Received: by 10.58.32.234 with HTTP; Thu, 4 Oct 2012 14:48:48 -0700 (PDT) In-Reply-To: <0C2D2E8E-0E36-4C4B-82BA-9536748B9AAE@rfc1035.com> References: <0C2D2E8E-0E36-4C4B-82BA-9536748B9AAE@rfc1035.com> Date: Thu, 4 Oct 2012 14:48:48 -0700 Message-ID: From: Casey Deccio To: Jim Reid Content-Type: multipart/alternative; boundary=14dae9ccd4765fa5a604cb42b8d3 X-Gm-Message-State: ALoCoQm6cisY0JaEywPUdzkm/Mp+HCyhIcrQG18Ow1TbRNqB4k50NxlsUTo6MChyqsROH25lzyJr Cc: dnsext@ietf.org Subject: Re: [dnsext] SOA without NS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:48:51 -0000 --14dae9ccd4765fa5a604cb42b8d3 Content-Type: text/plain; charset=ISO-8859-1 Hi Jim, On Thu, Oct 4, 2012 at 2:32 PM, Jim Reid wrote: > On 4 Oct 2012, at 21:41, Casey Deccio wrote: > > More specifically, where is the zone cut, as it pertains to DNSSEC? >> > > DNSSEC has no impact on the location of a zone cut. The zone cut is found > in the parent at the place where it has NS records for the child, just as > it's always been. What I'm referring to is proper validation of RRSIGs by the resolver, as documented in RFC 4035 5.3.1: "The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset." Unless this is loosely interpreted to mean that the signer's name field must be a superdomain of the owner name, then there must be some determination made by the resolver as to whether the signer is the name of the zone or not. Those NS records (and any related glue) are beneath the zone cut. > Everything else is above it. The child should have a SOA record, signifying > the start of a new zone of authority, and an NS RRset that's identical to > (best case) or has at least one record in common with (worst case) those at > the zone cut in the parent. > > I would suggest that more important than names is the addresses they point to (i.e., the resulting SLIST from glue and/or resolved addresses), rather than the names themselves. Additionally, I would think that in the worst case there is *no* intersection between SLISTs generated from names in the parent and those in the child. > > One example of this is buero.former03.de >> > > This "domain" is badly broken. Fixing it is a topic for another list. > Agreed--merely an example that brought the issue to my attention. Casey --14dae9ccd4765fa5a604cb42b8d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jim,

On Thu, Oct 4, 2012 at 2:32 PM, Jim Reid <= span dir=3D"ltr"><j= im@rfc1035.com> wrote:
On 4 Oct 2012, at 21:41, Casey Deccio wrote:

More specifically, where is the zone cut, as it pertains to DNSSEC?

DNSSEC has no impact on the location of a zone cut. The zone cut is found i= n the parent at the place where it has NS records for the child, just as it= 's always been.

What I'm referring = to is proper validation of RRSIGs by the resolver, as documented in RFC 403= 5 5.3.1:

"The RRSIG RR's Signer's Name field M= UST be the name of the zone
that contains the RRset."
<= /div>

Unless this is loosely interpreted to mean that th= e signer's name field must be a superdomain of the owner name, then the= re must be some determination made by the resolver as to whether the signer= is the name of the zone or not.

Those NS records (and any re= lated glue) are beneath the zone cut. Everything else is above it. The chil= d should have a SOA record, signifying the start of a new zone of authority= , and an NS RRset that's identical to (best case) or has at least one r= ecord in common with (worst case) those at the zone cut in the parent.


I would suggest that more import= ant than names is the addresses they point to (i.e., the resulting SLIST fr= om glue and/or resolved addresses), rather than the names themselves. =A0Ad= ditionally, I would think that in the worst case there is *no* intersection= between SLISTs generated from names in the parent and those in the child.<= /div>
=A0

One example of this is buero.former03.de

This "domain" is badly broken. Fixing it is a topic for another l= ist.

Agreed--merely an example that brought the issu= e to my attention.

Casey
--14dae9ccd4765fa5a604cb42b8d3-- From marka@isc.org Thu Oct 4 15:22:29 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA03821F84CF for ; Thu, 4 Oct 2012 15:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8i7EP2+WqMv for ; Thu, 4 Oct 2012 15:22:25 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id CCF8121F84CE for ; Thu, 4 Oct 2012 15:22:23 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 460A35F9947; Thu, 4 Oct 2012 22:22:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c08d:34a0:a875:f71b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 9AFB7216C7B; Thu, 4 Oct 2012 22:22:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5433A28961E2; Fri, 5 Oct 2012 08:22:08 +1000 (EST) To: Casey Deccio From: Mark Andrews References: <0C2D2E8E-0E36-4C4B-82BA-9536748B9AAE@rfc1035.com> In-reply-to: Your message of "Thu, 04 Oct 2012 14:48:48 MST." Date: Fri, 05 Oct 2012 08:22:08 +1000 Message-Id: <20121004222208.5433A28961E2@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] SOA without NS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:22:29 -0000 The parent zone is signed using NSEC3 + OPTOUT. The "delegation" fails into a optout range. At this point it is irrelevent if the child zone is properly delegated, signed etc. Even if the parent zone used NSEC records as long as there is a DS record it would still validate for almost all queries. You have signature from a DNSKEY which has a DS which is signed by the parent zone. As the two zones are on the same server the resolver will never need to do a NS query. In message , Casey Deccio writes: > > Hi Jim, > > On Thu, Oct 4, 2012 at 2:32 PM, Jim Reid wrote: > > > On 4 Oct 2012, at 21:41, Casey Deccio wrote: > > > > More specifically, where is the zone cut, as it pertains to DNSSEC? > >> > > > > DNSSEC has no impact on the location of a zone cut. The zone cut is found > > in the parent at the place where it has NS records for the child, just as > > it's always been. > > > What I'm referring to is proper validation of RRSIGs by the resolver, as > documented in RFC 4035 5.3.1: > > "The RRSIG RR's Signer's Name field MUST be the name of the zone > that contains the RRset." It is. > Unless this is loosely interpreted to mean that the signer's name field > must be a superdomain of the owner name, then there must be some > determination made by the resolver as to whether the signer is the name of > the zone or not. You take the signer, look for a DNSKEY, look for a DS, look for the DNSKEY of its signer .... A DS's signer MUST NOT match the owner of the DS. You follow the zone cuts using DS + DNSKEY rather than NS. > Those NS records (and any related glue) are beneath the zone cut. > > Everything else is above it. The child should have a SOA record, signifying > > the start of a new zone of authority, and an NS RRset that's identical to > > (best case) or has at least one record in common with (worst case) those at > > the zone cut in the parent. > > > > > I would suggest that more important than names is the addresses they point > to (i.e., the resulting SLIST from glue and/or resolved addresses), rather > than the names themselves. Additionally, I would think that in the worst > case there is *no* intersection between SLISTs generated from names in the > parent and those in the child. > > > > > > One example of this is buero.former03.de > >> > > > > This "domain" is badly broken. Fixing it is a topic for another list. > > > > Agreed--merely an example that brought the issue to my attention. > > Casey > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From casey@deccio.net Thu Oct 4 15:45:19 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C9A21F8607 for ; Thu, 4 Oct 2012 15:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SKYdDdvtKUM for ; Thu, 4 Oct 2012 15:45:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD12E21F85F9 for ; Thu, 4 Oct 2012 15:45:17 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1361383vbb.31 for ; Thu, 04 Oct 2012 15:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hQD517EzbVuYQOQ/S2lOqtm6dQeNbrqMp6fgiCxoroQ=; b=BYGV9puHrtd26n0n0uiP6sT08SagNirXD1nGjvuS2g1s5EFMBDqrhoY+obkGklFcGt VQ5wDpLJVAOE/Til90T7z3NfVwtgFVwkKsOV9T7z7yTxmlaUobDqrsdYat3pzNCjj2Nz Hn1qwTqQrO/8GVVNg4F3rl8XAhXkZ/nhf+vEY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=hQD517EzbVuYQOQ/S2lOqtm6dQeNbrqMp6fgiCxoroQ=; b=BGJ0cGv5f1zEKIsEyX5FAjszYsnsV4/EHa2MbZPSxxBhsgzKcIF7vKPKewvaXSvObq fU4PR9xqc1qRbe9w/7DcWKhIyy/RXPvgks8rVgFdyvbRxn3Az/Gou81cxu5+qP82f+Iy qacw0mfOn9RgUD1o+ndPe3cfSEteeXD7gvWpUZSqwvFXyMrBgW5tDt3OfTOxjQ3SC0Vh g2ni7CqEEOV1/XJKuPlkhI2Xid9EXhzdu7mU90zJHOKeRbHQo/DN8W3NC1XzJi2YLE4n KdtqpbKq9/71eOW16sukV5kN+USYkl/o90yTulk9781dNMOGRmxvhTHXSPtjsstrECgO V0/A== MIME-Version: 1.0 Received: by 10.52.92.11 with SMTP id ci11mr3303770vdb.7.1349390717107; Thu, 04 Oct 2012 15:45:17 -0700 (PDT) Received: by 10.58.32.234 with HTTP; Thu, 4 Oct 2012 15:45:17 -0700 (PDT) In-Reply-To: <20121004222208.5433A28961E2@drugs.dv.isc.org> References: <0C2D2E8E-0E36-4C4B-82BA-9536748B9AAE@rfc1035.com> <20121004222208.5433A28961E2@drugs.dv.isc.org> Date: Thu, 4 Oct 2012 15:45:17 -0700 Message-ID: From: Casey Deccio To: Mark Andrews Content-Type: multipart/alternative; boundary=20cf3071ce0a5b3f1104cb43823b X-Gm-Message-State: ALoCoQlhf7B/kVNSYpw0dL0OkeKJhN/KOvntcU6ta8r6Ao1DeRTuLFwFfgFt8V7mru+oicUOqWz5 Cc: dnsext@ietf.org Subject: Re: [dnsext] SOA without NS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:45:19 -0000 --20cf3071ce0a5b3f1104cb43823b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 4, 2012 at 3:22 PM, Mark Andrews wrote: > Even if the parent zone used NSEC records as long as there is a DS > record it would still validate for almost all queries. Perhaps in theory, although both my BIND and unbound resolvers return responses without the AD bit set: $ dig +dnssec @localhost mail.buero.former03.de | grep flags ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 5 ; EDNS: version: 0, flags: do; udp: 4096 $ dig +dnssec @localhost mail.buero.former03.de | grep flags ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ; EDNS: version: 0, flags: do; udp: 4096 > You take the signer, look for a DNSKEY, look for a DS, look for the > DNSKEY of its signer .... A DS's signer MUST NOT match the owner > of the DS. You follow the zone cuts using DS + DNSKEY rather than > NS. > > If this is the case for complete chains of trust, then perhaps it should this be clarified further in dnssec-bis. However, for insecure delegations this violates dnssec-bis 4.4: "The validator also MUST check for the presence of the NS bit in the matching NSEC (or NSEC3) RR (proving that there is, indeed, a delegation), or alternately make sure that the delegation is covered by an NSEC3 RR with the Opt-Out flag set. Without this check, an attacker could reuse an NSEC or NSEC3 RR matching a non-delegation name to spoof an unsigned delegation at that name. This would claim that an existing signed RRset (or set of signed RRsets) is below an unsigned delegation, thus not signed and vulnerable to further attack." Of course the above example also lacks DS records, but because it's covered in the opt-out range there's not check for the NS bit. Casey --20cf3071ce0a5b3f1104cb43823b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 4, 2012 at 3:22 PM, Mark Andrews <marka@isc.org> wr= ote:
Even if the parent zone used NSEC records as long as there is a DS
record it would still validate for almost all queries.
Perhaps in theory, although both my BIND and unbound resolvers = return responses without the AD bit set:

$ dig +dn= ssec @localhost mail.buero.former= 03.de | grep flags
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONA= L: 5
; EDNS: version: 0, flags: do; udp: 4096
$ dig +dnssec @localhost mail.buero.former03.de | grep flags
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 4096


You take the signer, look for a DNSKEY, look for a DS, look for the DNSKEY of its signer .... =A0A DS's signer MUST NOT match the owner
of the DS. =A0You follow the zone cuts using DS + DNSKEY rather than
NS.

<= br>
If this is the case for complete chains of trust, then perhap= s it should this be clarified further in dnssec-bis.

However, for insecure delegations this violates dnssec-bis 4.4:
<= br>
=A0 =A0"The validator also
=A0 =A0MUST ch= eck for the presence of the NS bit in the matching NSEC (or
=A0 = =A0NSEC3) RR (proving that there is, indeed, a delegation), or
=A0 =A0alternately make sure that the delegation is covered by an NSEC= 3 RR
=A0 =A0with the Opt-Out flag set.

= =A0 =A0Without this check, an attacker could reuse an NSEC or NSEC3 RR
=A0 =A0matching a non-delegation name to spoof an unsigned delegation= at
=A0 =A0that name. =A0This would claim that an existing signed RRset (o= r set of
=A0 =A0signed RRsets) is below an unsigned delegation, t= hus not signed and
=A0 =A0vulnerable to further attack."

Of course the above example also lacks DS records, but becau= se it's covered in the opt-out range there's not check for the NS b= it.

Casey=A0
--20cf3071ce0a5b3f1104cb43823b-- From jim@rfc1035.com Thu Oct 4 15:47:46 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC02021F8615 for ; Thu, 4 Oct 2012 15:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EktT-eqUbCT1 for ; Thu, 4 Oct 2012 15:47:45 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 9E80021F8607 for ; Thu, 4 Oct 2012 15:47:45 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id ED29BCBC41C; Thu, 4 Oct 2012 23:47:41 +0100 (BST) Message-Id: From: Jim Reid To: Casey Deccio In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Oct 2012 23:47:41 +0100 References: <0C2D2E8E-0E36-4C4B-82BA-9536748B9AAE@rfc1035.com> X-Mailer: Apple Mail (2.936) Cc: dnsext@ietf.org Subject: Re: [dnsext] SOA without NS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:47:46 -0000 On 4 Oct 2012, at 22:48, Casey Deccio wrote: > What I'm referring to is proper validation of RRSIGs by the > resolver, as > documented in RFC 4035 5.3.1: > > "The RRSIG RR's Signer's Name field MUST be the name of the zone > that contains the RRset." > > Unless this is loosely interpreted to mean that the signer's name > field > must be a superdomain of the owner name, then there must be some > determination made by the resolver as to whether the signer is the > name of > the zone or not. Not really. The signer has to be the name of the enclosing zone so there's nothing for the validating resolver to determine about whether that constitutes a zone cut or not. The name of the signer must be the name of the zone. QED. DNSSEC validation doesn't care about zone cut semantics at all. Provided of course the relevant DNSSEC RRs are in their proper places at the zone cut. The text you quoted does not mention zone cuts, so I don't know why you mentioned them or thought they mattered to DNSSEC. Zone cuts are still where they've always been. DNSSEC just complicates their semantics. What RFC4035 is saying is there are key(s) which sign the zone as a whole and there can be no discrete keys which sign individual RRsets. ie in the foo.com zone, there can't be a key bar.foo.com which only signs foobar.foo.com or some RRset of bar.foo.com or foo.com. In other words, the signer's name field of an RRSIG could be a superdomain of the owner-name (as you say) but it is always the name of the closest enclosing zone. DNSSEC validation works by finding the DS record(s) for the DNSKEY(s) identified by and RRSIG's Signer's Name field(s). You then find the DNSKEY(s) for the RRSIG(s) which signed those DS record(s) in the parent zone and validate those signatures. This process iterates up the name space until the validator hits a trust anchor or something breaks. It's a wee bit more complex than this -- ZSKs and KSKs -- but that detail is not germane to this discussion, so please let's not rake over those nits. >> Everything else is above it. The child should have a SOA record, >> signifying >> the start of a new zone of authority, and an NS RRset that's >> identical to >> (best case) or has at least one record in common with (worst case) >> those at >> the zone cut in the parent. >> >> > I would suggest that more important than names is the addresses they > point > to (i.e., the resulting SLIST from glue and/or resolved addresses), > rather > than the names themselves. Of course, but you're just picking nits that are somewhat off-topic. It would have been more precise of me to repeatedly mention NS records and accompanying A and AAAA records. However I had hoped that it wasn't necessary to explicitly spell out things that should be self- evident to the membership of this list. > Additionally, I would think that in the worst case there is *no* > intersection between SLISTs generated from names in the parent and > those in the child. We had already discussed and eliminated that irredeemably broken possibility. But if you want to pick that nit too, be my guest. From marka@isc.org Thu Oct 4 16:38:47 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E50B21F84D8; Thu, 4 Oct 2012 16:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxEGEvo34SwC; Thu, 4 Oct 2012 16:38:47 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CFDEF21F84C4; Thu, 4 Oct 2012 16:38:46 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id AB707C95C0; Thu, 4 Oct 2012 23:38:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6E468216C80; Thu, 4 Oct 2012 23:38:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2BE952896B88; Fri, 5 Oct 2012 09:38:37 +1000 (EST) To: Olafur Gudmundsson From: Mark Andrews References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <506B01D1.9080708@ogud.com> <8F3DCBA9A3AF566810CD1061@JcK-HP8200.jck.com> <506B6BE9.2000805@ogud.com> <20121003011556.526A82873A5E@drugs.dv.isc.org> <506DBE9B.3070209@ogud.com> In-reply-to: Your message of "Thu, 04 Oct 2012 12:51:39 -0400." <506DBE9B.3070209@ogud.com> Date: Fri, 05 Oct 2012 09:38:37 +1000 Message-Id: <20121004233837.2BE952896B88@drugs.dv.isc.org> Cc: John C Klensin , dnsext@ietf.org, 'IETF-Discussion list' Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 23:38:47 -0000 In message <506DBE9B.3070209@ogud.com>, Olafur Gudmundsson writes: > On 02/10/2012 21:15, Mark Andrews wrote: > >> Labels only work when all the severs for a zone that has a new label type, > >> in ADDITION sufficient fraction servers in all zones above that zone > >> MUST understand the new > >> label type. > > > > Not true. Binary labels could have been made to work by removing > > the left hand label until the remaining suffix consisted of only > > RFC 1035 labels, looking up the servers for that domain, then > > resuming query processing using those servers similar to what we > > do with DS lookups. > > > > Such processing would be required for any new label type used in a > > QNAME and would be a significant change to the standard query logic. > > > > Mark > > > > Mark, > > This will only work if all the recursive resolvers that "consumers" for > this new label types have been updated AND the new label type is the > left most label(s) in the name. This works regardless of the position of the label. If a TLD label is a binary label then you strip back the labels until you reach the root. Resolvers involved in the lookup need to be updated and I didn't dispute that. > Olafur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From casey@deccio.net Thu Oct 4 17:13:04 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B6721F862B for ; Thu, 4 Oct 2012 17:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ntvpl3r1NeYt for ; Thu, 4 Oct 2012 17:13:03 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8B2421F8622 for ; Thu, 4 Oct 2012 17:13:03 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1429082vbb.31 for ; Thu, 04 Oct 2012 17:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BVubuZFJpkW+CV+8j5uJeTJUYm+BjWcqKgDftNf0ESQ=; b=XRMxHeoRgiO4RGjH0gbnk09e7biJiivDVqjO8KExcMCFMsywLAW22+q6vyDNTa6NN1 J/mhVjZHBRwkbSBGIVoIGlcGkqq5mIwX9qGiNcQcjXlIrgd3lFFx4zgHR7unURvdxyBl h1QHRglTUBhrgSpalfDtJg9qf3ZqlEDfnES7M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=BVubuZFJpkW+CV+8j5uJeTJUYm+BjWcqKgDftNf0ESQ=; b=Q9LUTsY250y72QHS0c3fTAiub9E3wxDW1mZ0i9FA9F/Eze2VHHLu+YC7WE6jIWAscM D3e1aw/fpwxrLdZGvbVijEh6DyAa31gXT4PjR4jmXArlVt61sfRsoHLheVak4JMo5Bej JKJeUWozHUXyPlJyozoJxAPDRkelV3Rz6C1JDM81ErucpnKOi3afYXIM5ui0BUkrWlBR gqwCbP4S7YkT6AmaBAEGu/72uO3luFF9/viebUWXQHBnSZDc1wa84E1LpPTa4Y0F59fj GwtWbe8aHjkSJoHltnAcYecamMm9vbE2Ad1B0JR+kxzfmRskIEDNPJmFD/UWusFO4Jrq 2JHQ== MIME-Version: 1.0 Received: by 10.220.205.200 with SMTP id fr8mr4129173vcb.34.1349395983160; Thu, 04 Oct 2012 17:13:03 -0700 (PDT) Received: by 10.58.32.234 with HTTP; Thu, 4 Oct 2012 17:13:03 -0700 (PDT) In-Reply-To: References: <0C2D2E8E-0E36-4C4B-82BA-9536748B9AAE@rfc1035.com> Date: Thu, 4 Oct 2012 17:13:03 -0700 Message-ID: From: Casey Deccio To: Jim Reid Content-Type: multipart/alternative; boundary=14dae9ccd4b63cd66804cb44bc79 X-Gm-Message-State: ALoCoQm7Q9VEwMCYRuXFBTOCgvIWPWfvmPgtN0/Z8Y+n2m9Q0Fim7MXAY/EAtT0Nl0Yst/ZMChfS Cc: dnsext@ietf.org Subject: Re: [dnsext] SOA without NS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 00:13:04 -0000 --14dae9ccd4b63cd66804cb44bc79 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 4, 2012 at 3:47 PM, Jim Reid wrote: > Not really. The signer has to be the name of the enclosing zone so there's > nothing for the validating resolver to determine about whether that > constitutes a zone cut or not. The name of the signer must be the name of > the zone. QED. DNSSEC validation doesn't care about zone cut semantics at > all. Provided of course the relevant DNSSEC RRs are in their proper places > at the zone cut. The text you quoted does not mention zone cuts, so I don't > know why you mentioned them or thought they mattered to DNSSEC. Zone cuts > are still where they've always been. DNSSEC just complicates their > semantics. > It appears to me from dnssec-bis section 4.4 that zone cuts are indeed relevant to validators, particularly when using NSEC and NSEC3 for determining insecure delegations. Anyway, the problem with the domain I was troubleshooting was obvious (lack of NS RRs), but my objective in bringing this up to this group was to ensure that I was understanding the consequences accurately, so I can effectively describe both the problem and consequences to administrators troubleshooting DNS(SEC) configurations. And if additional clarification to specification is needed, then it can be added appropriately. Casey --14dae9ccd4b63cd66804cb44bc79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 4, 2012 at 3:47 PM, Jim Reid <jim@rfc1035.com> wro= te:
Not really. The signer has to be the name of the enclosin= g zone so there's nothing for the validating resolver to determine abou= t whether that constitutes a zone cut or not. The name of the signer must b= e the name of the zone. QED. DNSSEC validation doesn't care about zone = cut semantics at all. Provided of course the relevant DNSSEC RRs are in the= ir proper places at the zone cut. The text you quoted does not mention zone= cuts, so I don't know why you mentioned them or thought they mattered = to DNSSEC. Zone cuts are still where they've always been. DNSSEC just c= omplicates their semantics.

It appears to me from dnssec-bis section 4= .4 that zone cuts are indeed relevant to validators, particularly when usin= g NSEC and NSEC3 for determining insecure delegations. =A0Anyway, the probl= em with the domain I was troubleshooting was obvious (lack of NS RRs), but = my objective in bringing this up to this group was to ensure that I was und= erstanding the consequences accurately, so I can effectively describe both = the problem and consequences to administrators troubleshooting DNS(SEC) con= figurations. =A0And if additional clarification to specification is needed,= then it can be added appropriately.

Casey
--14dae9ccd4b63cd66804cb44bc79-- From marka@isc.org Thu Oct 4 17:33:20 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC7921F862A for ; Thu, 4 Oct 2012 17:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l97V9Va4an5m for ; Thu, 4 Oct 2012 17:33:19 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D4E9C21F8628 for ; Thu, 4 Oct 2012 17:33:18 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id F23845F9948; Fri, 5 Oct 2012 00:33:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:916d:5083:65e8:ed62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 51526216C7B; Fri, 5 Oct 2012 00:33:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5B9FB28971C0; Fri, 5 Oct 2012 10:33:03 +1000 (EST) To: Casey Deccio From: Mark Andrews References: <0C2D2E8E-0E36-4C4B-82BA-9536748B9AAE@rfc1035.com> <20121004222208.5433A28961E2@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 04 Oct 2012 15:45:17 MST." Date: Fri, 05 Oct 2012 10:33:03 +1000 Message-Id: <20121005003303.5B9FB28971C0@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] SOA without NS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 00:33:20 -0000 In message , Casey Deccio writes: > > On Thu, Oct 4, 2012 at 3:22 PM, Mark Andrews wrote: > > > Even if the parent zone used NSEC records as long as there is a DS > > record it would still validate for almost all queries. > > > Perhaps in theory, although both my BIND and unbound resolvers return > responses without the AD bit set: Which is because the zones are not set up as described in the hypothetical situation introduced with "Even if". > $ dig +dnssec @localhost mail.buero.former03.de | grep flags > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 5 > ; EDNS: version: 0, flags: do; udp: 4096 > > $ dig +dnssec @localhost mail.buero.former03.de | grep flags > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > ; EDNS: version: 0, flags: do; udp: 4096 > > > > You take the signer, look for a DNSKEY, look for a DS, look for the > > DNSKEY of its signer .... A DS's signer MUST NOT match the owner > > of the DS. You follow the zone cuts using DS + DNSKEY rather than > > NS. > > If this is the case for complete chains of trust, then perhaps it should > this be clarified further in dnssec-bis. > > However, for insecure delegations this violates dnssec-bis 4.4: > > "The validator also > MUST check for the presence of the NS bit in the matching NSEC (or > NSEC3) RR (proving that there is, indeed, a delegation), or > alternately make sure that the delegation is covered by an NSEC3 RR > with the Opt-Out flag set. > > Without this check, an attacker could reuse an NSEC or NSEC3 RR > matching a non-delegation name to spoof an unsigned delegation at > that name. This would claim that an existing signed RRset (or set of > signed RRsets) is below an unsigned delegation, thus not signed and > vulnerable to further attack." > > Of course the above example also lacks DS records, but because it's covered > in the opt-out range there's not check for the NS bit. > > Casey Remember the point of DNSSEC it to prevent spoofed answers being accepted not to ensure that every DNS zone is properly constructed. If you don't properly construct the zones involved then you may or may not have failures. Additionally the validator needs to work with zones that are in the process of being changed through caches which may have RRsets that were cached at different points in time. If the parent presents a signed DS that validates then a validator can legitimately deduce that there is a zone cut at that name without seeing the NS RRset. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ogud@ogud.com Thu Oct 4 18:02:36 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB8411E8097 for ; Thu, 4 Oct 2012 18:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v59gV9djxT2a for ; Thu, 4 Oct 2012 18:02:35 -0700 (PDT) Received: from smtp138.iad.emailsrvr.com (smtp138.iad.emailsrvr.com [207.97.245.138]) by ietfa.amsl.com (Postfix) with ESMTP id 82C1111E8091 for ; Thu, 4 Oct 2012 18:02:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp53.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 1A82B5842F; Thu, 4 Oct 2012 21:02:34 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp53.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 1F69C58419; Thu, 4 Oct 2012 21:02:32 -0400 (EDT) Message-ID: <506E31A6.5050605@ogud.com> Date: Thu, 04 Oct 2012 21:02:30 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ogud@ogud.com Subject: Re: [dnsext] type NSEC query at a parent's zone cut X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 01:02:36 -0000 On 04/10/2012 14:32, JINMEI Tatuya / 神明é”哉 wrote: > I have a quick and simple question: what should an authoritative > server return to a query for an NSEC RR(set) at the parent side of a zone > cut? For example, what should a root server return to the query > "com/NSEC"? > > I'm asking this because different root servers actually return > different answers (and based on initial offlist communication this > didn't seem to be a very known topic). It may depend on from where > you query, but from the location I'm writing this message, the E, H, K > and L root servers return a referral to .com (just like when asking > for com/AAAA). Others return an authoritative answer that has the > com/NSEC RR in the answer section (just like when asking for com/DS). > If the server is only authoritative for the parent then: As the type NSEC exists in the zone you are asking for at the name you are asking for the servers should return it. Just like if the query was for RRSIG or NS or DS at that point. For type ANY the servers should return NS + [DS] + NSEC + RRSIG If the server is authoritative for both parent and child it gets much grayer to answer the question. Based on the different behavior of nameservers that I have seen I use RFC4471 names to probe for NSEC records at delegations. Olafur > According to Section 2.6 of RFC4035, the latter behavior seems to be > correct: > > This specification updates the original DNS specification to allow > NSEC and DS RR types at the parent side of a zone cut. These RRsets > are authoritative for the parent when they appear at the parent side > of a zone cut. > > Also, Section 4.2 of the RFC even seems to suggest the difference > could lead to interoperability problems: > > When attempting to retrieve missing NSEC RRs that reside on the > parental side at a zone cut, a security-aware iterative-mode resolver > MUST query the name servers for the parent zone, not the child zone. > > because if the parent zone's authoritative server returns a referral, > the resolver cannot get what it tries to retrieve - although this may > not be a serious problem due to the note in the preceding paragraph: > > Security-aware resolvers MAY query for missing security RRs in an > attempt to perform validation; implementations that choose to do so > must be aware that the answers received may not be sufficient to > validate the original response. For example, a zone update may have > changed (or deleted) the desired information between the original and > follow-up queries. > > In any case, it's not clear to me whether the RFC specifies what the > authoritative server should do at the parent side. It's very specific > about the case for DS (Section 3.1.4.1), but it seems to be mostly > silent about the NSEC case. > > Is this described somewhere (if so, which behavior is correct)? Or > was there a consensus it can be an implementation dependent behavior? > > Any clarification is appreciated. Thanks, > > --- > JINMEI, Tatuya > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From jefsey@jefsey.com Thu Oct 4 20:51:03 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3DA21F84EB; Thu, 4 Oct 2012 20:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyBVqdxN3o26; Thu, 4 Oct 2012 20:51:02 -0700 (PDT) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id AABEC21F84EE; Thu, 4 Oct 2012 20:51:02 -0700 (PDT) Received: from i03v-62-35-238-138.d4.club-internet.fr ([62.35.238.138]:60901 helo=MORFIN-PC.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.77) (envelope-from ) id 1TJywE-0005ju-Eg; Thu, 04 Oct 2012 20:50:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 05 Oct 2012 05:50:53 +0200 To: John C Klensin ,dnsext@ietf.org From: JFC Morfin In-Reply-To: <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20121005035102.AABEC21F84EE@ietfa.amsl.com> Cc: IESG , "iab@iab.org IAB" , iucg , IUTF Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 03:51:03 -0000 John, Thank you for this mail which has brought my attention to this critical issue. I fully support your position for two reasons: 1. It logically makes sense. It establishes a reasonable position while calling for at least some explanation. 2. I thought the key target was to keep the whole digital ecosystem name space consistent. I have engaged in the preparation of a complete review of the digital naming from the point of view of the IETF RFCs. The target is to consider how it could be kept interoperational with other technologies and needs, such as ML-DNS, semantic addressing, and content centric networking, etc. We (IUTF) globally call this work "IUse specifications" (Intelligent Use of available resources). This work is not trivial on the technical side or the linguistic side, as it studies naming from what it permits now, and not from what it was planned for. Extended label types are Internet DNS features that will certainly be retained in these specs and the current prototyping work does include the support of Binary labels for testing. The proposed sentence "This document obsoletes the use of the 2-bit combination defined by [RFC2671] to identify extended label types" is, therefore, at least premature. It would make the Internet DNS incompatible with the integrated universal digital naming syntax independent contribution that we planned to introduce in the coming months, but we can quickly produce a first draft if we feel that the IETF DNS might progressively, arbitrarily disintegrate in the meanwhile. jfc At 21:48 01/10/2012, John C Klensin wrote: >--On Sunday, September 30, 2012 07:53 -0700 The IESG > wrote: > > > > > The IESG has received a request from the DNS Extensions WG > > (dnsext) to consider the following document: > > - 'Extension Mechanisms for DNS (EDNS(0))' > > as Internet > > Standard > > > > The IESG plans to make a decision in the next few weeks, and > > solicits final comments on this action. Please send > > substantive comments to the ietf@ietf.org mailing lists by > > 2012-10-29. Exceptionally, comments may be sent to > > iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > The Domain Name System's wire protocol includes a number of > > fixed fields whose range has been or soon will be exhausted > > and does not allow requestors to advertise their > > capabilities to responders. This document describes > > backward compatible mechanisms for allowing the protocol to > > grow. > > > > This document updates the EDNS(0) specification (and > > obsoletes RFC 2671) based on feedback from deployment > > experience in several implementations. It also closes the > > IANA registry for extended labels created as part of RFC > > 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain > > Name System") which depends on the existence of extended > > labels. > >... > >Hi. Apologies for not noticing this earlier, but this >specification's deprecation of label types raises an issue that >the document doesn't seem to address. > >Deprecating RFC 2673 is one thing. Given deployment and >operational experience, I don't know of anyone who would offer a >strong defense of binary labels today. However, the document >doesn't offer a strong justification for deprecating label types >entirely other than, it seems, that there has been only one >example of their use and that failed. If that were the only >motivation, it would be a rather weak one, especially since >having a capability that we don't use (but conceivably might in >the future) would not appear to cause any harm. > >With the understanding that this is an example, not a proposal, >it may be useful to review some of the history and context for >IDNs. IDNA represents community consensus as to the right way >to proceed, but that consensus includes both people who believe >it is a good permanent strategy and people who believe it is a >good temporary/transition strategy until a better plan can be >developed and deployed. In particular, some of that latter >group were painfully aware of the rate at which EDNS0 was >deploying in the first half of the last decade, making them more >receptive to IDNA (or other strategies that did not depend on >changes to DNS servers or resolvers). > >So suppose the community really does decide that it wants >DNS-based IDNs and that it wants to see if they can be developed >and deployed within the existing DNS rather than moving to what >some have called DNSng. It is reasonably clear that what would >be called "just send 8" in the email community would not be >acceptable if only because there are DNS uses outside the public >network that use UTF-8 directly and others that use ISO 8859-1 >or other character coding and repertoires (RFC 6055 discusses >some related issues). The proposal/thought piece I produced in >2001-2002 (with urging from some DNS-expert colleagues) to >transition to a new, i18n-sensitive, Class might be part of the >solution, but it is now clear that it would not be sufficient >(at least without considerable special-casing that would violate >both 1034/1035 and current trends). A different label type that >would permit specialized interpretations of the labels might be >an important part of the puzzle. > >Would that be a good idea? I don't know. Personally, I believe >that some of the expectations of and demand for IDNs cannot be >met in the current DNS and that we should not try to go much >further than IDNA: if more is really needed, then it should be >accomplished either in an "above DNS" solution or by designing >and deploying DNS2. But I think it would be terribly unwise to >eliminate a facility that might be useful for i18n simply >because someone tried to use it for something entirely different >and that effort did not succeed. > >Therefore: >(1) Did the WG consider i18n and other issues and possibilities >before deciding to deprecate extended label types entirely? If >so, why aren't those considerations described in the document? >We don't have a lot of codes left in the RFC 1035 space on which >other label type models might be constructed. > >(2) Is there strong justification for deprecating extended label >types, e.g., evidence that they would cause harm? > >(3) If the answer to either of both of the above questions is >"no", wouldn't it be wiser to simply deprecate the use of binary >labels, urge great caution in allocating and using other label >types, and then move on rather than eliminating the facility? > >thanks, > john From fanf2@hermes.cam.ac.uk Fri Oct 5 03:19:00 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A2D21F855A for ; Fri, 5 Oct 2012 03:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4qo+GN3+J6N for ; Fri, 5 Oct 2012 03:18:59 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id BC93B21F854F for ; Fri, 5 Oct 2012 03:18:57 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57871) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1TK4ze-0007yf-rq (Exim 4.72) (return-path ); Fri, 05 Oct 2012 11:18:54 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TK4ze-0003jb-Kd (Exim 4.72) (return-path ); Fri, 05 Oct 2012 11:18:54 +0100 Date: Fri, 5 Oct 2012 11:18:54 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Olafur Gudmundsson In-Reply-To: <506E31A6.5050605@ogud.com> Message-ID: References: <506E31A6.5050605@ogud.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] type NSEC query at a parent's zone cut X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 10:19:00 -0000 Olafur Gudmundsson wrote: > If the server is only authoritative for the parent then: > As the type NSEC exists in the zone you are asking for at the name you > are asking for the servers should return it. > Just like if the query was for RRSIG or NS or DS at that point. > For type ANY the servers should return NS + [DS] + NSEC + RRSIG If you query the root servers for com IN ANY you get NS DS RRSIG(DS) but not NSEC RRSIG(NSEC). All the servers behave the same. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From joao@bondis.org Fri Oct 5 03:59:18 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3F121F8620; Fri, 5 Oct 2012 03:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85W5HHKIsoxi; Fri, 5 Oct 2012 03:59:18 -0700 (PDT) Received: from smtp1.bondis.org (unknown [IPv6:2001:ac0:1003::1]) by ietfa.amsl.com (Postfix) with ESMTP id D642F21F8609; Fri, 5 Oct 2012 03:59:17 -0700 (PDT) Received: from core.c-l-i.net (187.red-80-29-62.adsl.static.ccgg.telefonica.net [80.29.62.187]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: joao) by smtp1.bondis.org (Postfix) with ESMTPSA id 3887D6202F1; Fri, 5 Oct 2012 10:29:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Jo=E3o_Damas?= In-Reply-To: <396CFDC14B6FEF29A37A2FFF@JcK-HP8200.jck.com> Date: Fri, 5 Oct 2012 10:29:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <506B01D1.9080708@ogud.com> <8F3DCBA9A3AF566810CD1061@JcK-HP8200.jck.com> <506B6BE9.2000805@ogud.com> <20121003011556.526A82873A5E@drugs.dv.isc.org> <84187E41-0CEC-4CA2-801D-5AB1171FFF9B@bondis.org> <396CFDC14B6FEF29A37A2FFF@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1283) Cc: 'IETF-Discussion list' , Olafur Gudmundsson , dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 10:59:19 -0000 On 3 Oct 2012, at 14:10, John C Klensin wrote: >=20 >=20 > --On Wednesday, October 03, 2012 10:43 +0200 Jo=E3o Damas > wrote: >=20 >> I believe you are saying the same things when you are both >> saying that for this to work there may be more than one way to >> do it but all options require completely new functionality in >> implementations (either by implementing support for new labels >> types or by implementing new fall back behavior). The >> conclusion is still the same. >=20 > Hmm. I'm not completely sure who "you" was intended to include, Yourself and Olafur > but my conclusion from the above is that there is no substantial > justification for eliminating, at this time, a capability that > might prove better on balance when and if new capabilities are > considered and tradeoffs evaluated. >=20 > To summarize my perspective on this as of now: >=20 > (1) No one is making a case for retaining binary labels >=20 > (2) The case has not been made, at least in the document, for > eliminating label types. An argument that there are other ways > to do a particular type of label is not persuasive unless there > is a comprehensive and written analysis of what other labels > might be considered and what the tradeoffs among approaches > would be. And an argument that almost any significant added > functionality would be very slow and costly to deploy may be an > argument for not approving such functionality, but it is not an > argument for eliminating one, but not all, of the underlying > capabilities. fair enough. The groups consensus over the last years and after the = experience with binary labels has been that new label types are = basically undeployable because they require a complete renewal of all = deployed resolvers. On the other hand the use of EDNS extension mechanisms can be = incrementally deployed (e.g. see some of DNSSEC features that leverage = EDNS) > IMO, this discussion has turned up two ways in which the case > for eliminating the possibility of additional label types could > be made: >=20 > (2.1) Demonstrating that simply having the capability defined > and available in principle is somehow harmful. >=20 People here can correct me, as my memory is fuzzy, but binary labels did = cause harm to several deployed implementations. Don't know if this is = just case in favour of natural selection. > (2.2) The WG has consensus on a bright line that defines the > nature of proposals that would require going to DNSng rather > than EDNSx-type extensions to the current model, has concluded > that any extensions or alterations to the label definition of > 1034/1035 would require crossing that line, and is prepared to > document that line and get IETF consensus on it (either as part > of this document or one normatively referenced from it). Pretty much, that is my understanding. It is quite possible that this = has been a position reached over many iterations of discussions and is = not actually documented anywhere. Joao= From joao@bondis.org Fri Oct 5 03:59:18 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC0021F8609 for ; Fri, 5 Oct 2012 03:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FalMW673ZWt0 for ; Fri, 5 Oct 2012 03:59:18 -0700 (PDT) Received: from smtp1.bondis.org (unknown [IPv6:2001:ac0:1003::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CCF21F860B for ; Fri, 5 Oct 2012 03:59:18 -0700 (PDT) Received: from core.c-l-i.net (187.red-80-29-62.adsl.static.ccgg.telefonica.net [80.29.62.187]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: joao) by smtp1.bondis.org (Postfix) with ESMTPSA id 432976205AF; Tue, 2 Oct 2012 17:08:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Jo=E3o_Damas?= In-Reply-To: <506B01D1.9080708@ogud.com> Date: Tue, 2 Oct 2012 17:08:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3CA4BBD2-79B1-4747-A18C-0A482B412EA9@bondis.org> References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <506B01D1.9080708@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1283) Cc: john-ietf@jck.com, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 10:59:19 -0000 On 2 Oct 2012, at 17:01, Olafur Gudmundsson wrote: >=20 > >=20 > If you think the text in the document does not reflect the lessons > learned strongly enough I will be happy work with you on putting > better text in the document. Also would text pointing out the preference to expand DNS's capabilities = through EDNS rather than things like extended labels be seen as useful? = That could be added to clarify this point if it helps to reduce the = number of people left wondering and helps with pointing them in the = preferred direction Joao= From joao@bondis.org Fri Oct 5 03:59:19 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DBF21F8609; Fri, 5 Oct 2012 03:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue7lLs880BB6; Fri, 5 Oct 2012 03:59:19 -0700 (PDT) Received: from smtp1.bondis.org (unknown [IPv6:2001:ac0:1003::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0141521F860B; Fri, 5 Oct 2012 03:59:19 -0700 (PDT) Received: from core.c-l-i.net (187.red-80-29-62.adsl.static.ccgg.telefonica.net [80.29.62.187]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: joao) by smtp1.bondis.org (Postfix) with ESMTPSA id 9A9BE6203CA; Wed, 3 Oct 2012 10:43:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Jo=E3o_Damas?= In-Reply-To: <20121003011556.526A82873A5E@drugs.dv.isc.org> Date: Wed, 3 Oct 2012 10:43:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84187E41-0CEC-4CA2-801D-5AB1171FFF9B@bondis.org> References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <506B01D1.9080708@ogud.com> <8F3DCBA9A3AF566810CD1061@JcK-HP8200.jck.com> <506B6BE9.2000805@ogud.com> <20121003011556.526A82873A5E@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1283) Cc: John C Klensin , dnsext@ietf.org, Olafur Gudmundsson , 'IETF-Discussion list' Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 10:59:19 -0000 I believe you are saying the same things when you are both saying that = for this to work there may be more than one way to do it but all options = require completely new functionality in implementations (either by = implementing support for new labels types or by implementing new fall = back behavior). The conclusion is still the same. Joao On 3 Oct 2012, at 03:15, Mark Andrews wrote: >=20 >> Labels only work when all the severs for a zone that has a new label = type, >> in ADDITION sufficient fraction servers in all zones above that zone=20= >> MUST understand the new >> label type. >=20 > Not true. Binary labels could have been made to work by removing > the left hand label until the remaining suffix consisted of only > RFC 1035 labels, looking up the servers for that domain, then > resuming query processing using those servers similar to what we > do with DS lookups. >=20 > Such processing would be required for any new label type used in a > QNAME and would be a significant change to the standard query logic. >=20 > Mark > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From wouter@nlnetlabs.nl Fri Oct 5 04:41:32 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F062721F8650 for ; Fri, 5 Oct 2012 04:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnvPzw8j607Z for ; Fri, 5 Oct 2012 04:41:31 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8343121F864A for ; Fri, 5 Oct 2012 04:41:31 -0700 (PDT) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q95BfOd1088404 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 5 Oct 2012 13:41:25 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q95BfOd1088404 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1349437286; bh=CdQ8wAk5/SY4fE3SoDbUFpXRb7cNLJ9kNzqWmYVR2+4=; h=Date:From:To:Subject:References:In-Reply-To; b=nFs+Cv7mtbtN/iQTL1PdYRkXMdI4VAIdFNhS7Q2xFozCen3X71AgIhWMIi6NIARlj 6jEaOb7yGLr46A9kt++zDqdvOQekRlZXCFq3fR3h0lBxsT8laaks7gWoiNJz0OE3kt OfjETvGl5SwI9MzbTcR/DHXfsOiNTdJykQtQQKwk= Message-ID: <506EC767.60908@nlnetlabs.nl> Date: Fri, 05 Oct 2012 13:41:27 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <0C2D2E8E-0E36-4C4B-82BA-9536748B9AAE@rfc1035.com> <20121004222208.5433A28961E2@drugs.dv.isc.org> <20121005003303.5B9FB28971C0@drugs.dv.isc.org> In-Reply-To: <20121005003303.5B9FB28971C0@drugs.dv.isc.org> X-Enigmail-Version: 1.4.4 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]); Fri, 05 Oct 2012 13:41:25 +0200 (CEST) Subject: Re: [dnsext] SOA without NS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:41:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Casey, On 10/05/2012 02:33 AM, Mark Andrews wrote: > > In message > > > , Casey Deccio writes: >> >> On Thu, Oct 4, 2012 at 3:22 PM, Mark Andrews >> wrote: >> >>> Even if the parent zone used NSEC records as long as there is a >>> DS record it would still validate for almost all queries. >> >> >> Perhaps in theory, although both my BIND and unbound resolvers >> return responses without the AD bit set: > > Which is because the zones are not set up as described in the > hypothetical situation introduced with "Even if". So, what unbound thinks as it validates this, is that this data falls inside the optout span of an NSEC3 (which is valid) above it. And no zone cut was observed, thus, these zones are co-hosted on the same server, it is in insecure-space. It does not 'check' the zone-cut for misconfiguration, because it was already insecure. Realistically, the data does not conform to the RFC text that you quote; it is misconfigured. It could also be bogus, if the parent did not use optout (or NSEC) and also did not make a zone-cut (the misconfiguration), then the validator sees the data, but cannot get an optout span NSEC3 above it. Instead finds out 'the zone cut does not exist', and data from the child zone is bogus. To make it work, the operator needs to insert NS records for the lower-zone into the parent-zonefile (and child DS record if it exists). This (after signing) creates the proper NSEC/NSEC3s. For buero.former03 this means inserting DS records for buero.former03 into the former03 zone (and NS records). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQbsdnAAoJEJ9vHC1+BF+Ni2gQAIMY6k4tUlv0IwGE6syun/Xf 72H5QIJw5OBA1rMZKdY/+VjVBwLiH9RSf5StNFQeHdYymDqvgKXKews6KBBRVd3c Mq+OJ16anDjcxWN2yoAXIIOy8XtItoDv2YOyVwPo6nc+xs0H9faedWKUdLxDPsz8 NlQ5YsGgBGaMRQJEAKEoJGL1crBx0Epk0z6fW5W7WVMkZUNEH3V+CpJ6WoiziKAt 6qG7XjJlnZQ5uRTNSh05f/0HKjX3xyLtka02yRZrNxXz+zFxJ2+ddlEmT0crRuRR II1K/jLU0jXOJOTvAdVEeYZXQGavtr3GU9h3EOMqnEyyPHQIdL8Z+5rkW/WyMSiO bryWXANnxDKdMqzs9Dp0wv0i0RBpQ+xbYn0l9nqexQLBlduM4P49QehH2VEjgawR 0vA3EPnNNuMOP8TrsZM2dFeqHoeihE1/ztpAjDUoBsomRAKw1zslGQbyFvUpchva jv8m8Q41izXgW9l0SCQrlAzNV4RcjAg0dCSvZuRyoBFo4ZKavyph01K/3SP2cKXv QHH0V/ogcXRzVv89NacfACFMJ3q5lp8nRVLr2aez59sbqD3HN4OAxD1x8+bsu2Mf qFSw8tSSDzi3lpby1GPHvQS7N69q7J2ckDjAx0zEnD2KKUt7RFkxfFuLDSBnvLx2 Y6JTjx6l6UkDFLyq6faZ =w4Y3 -----END PGP SIGNATURE----- From marka@isc.org Fri Oct 5 04:57:54 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B66121F86B7 for ; Fri, 5 Oct 2012 04:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x923efMVm3ms for ; Fri, 5 Oct 2012 04:57:53 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0CB21F86B3 for ; Fri, 5 Oct 2012 04:57:53 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id BCCE2C9494; Fri, 5 Oct 2012 11:57:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:1cf:ccb7:9c14:9dd4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 69751216C7B; Fri, 5 Oct 2012 11:57:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3CA4428BDF12; Fri, 5 Oct 2012 21:57:39 +1000 (EST) To: Tony Finch From: Mark Andrews References: <506E31A6.5050605@ogud.com> In-reply-to: Your message of "Fri, 05 Oct 2012 11:18:54 +0100." Date: Fri, 05 Oct 2012 21:57:39 +1000 Message-Id: <20121005115739.3CA4428BDF12@drugs.dv.isc.org> Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] type NSEC query at a parent's zone cut X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:57:54 -0000 In message , Tony Fi nch writes: > Olafur Gudmundsson wrote: > > > If the server is only authoritative for the parent then: > > As the type NSEC exists in the zone you are asking for at the name you > > are asking for the servers should return it. > > Just like if the query was for RRSIG or NS or DS at that point. > > For type ANY the servers should return NS + [DS] + NSEC + RRSIG > > If you query the root servers for com IN ANY you get NS DS RRSIG(DS) but > not NSEC RRSIG(NSEC). All the servers behave the same. You get a referral which what Olafur was trying to say. > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, > occasionally poor at first. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From iesg-secretary@ietf.org Fri Oct 5 07:48:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61FD21F861E; Fri, 5 Oct 2012 07:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9FqbREHG3ZT; Fri, 5 Oct 2012 07:48:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD9921F8593; Fri, 5 Oct 2012 07:48:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121005144802.1972.16798.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 07:48:02 -0700 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: RFC 5011 (Automated Updates of DNS Security (DNSSEC) Trust Anchors) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:48:02 -0000 The IESG has received a request from the author to consider the following document: = 'Automated Updates of DNS Security (DNSSEC) Trust Anchors,' RFC 5011 as an Internet Standard. RFC 6410 specifies 4 criteria for reclassifying a document as Internet Standard: (1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. 1. RFC 5011 support is built in to BIND, the most widely deployed DNS server/resolver as of version 9.7. = 2. RFC 5011 support is built in to MS Active Directory. http://technet.microsoft.com/en-us/library/jj200224.aspx = There appears to be sufficient support in zone signing tools for the REVOKE bit. = RFC5011 is specified as the root key rollover protocol. Other zones appear have adopted this astheir mechanism for updating their trust anchors. RFC5011 is a hybrid of operational practices (by the zone owner to signal key changes) and implementations (by the zone owner to sign new keys and revocations, and by the client to automatically update the trust store). There appear to be more than two implementations on the client side. = There is anecdotal evidence that successful operational key rollovers have been made with this protocol. (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. There are no outstanding errata for RFC 5011. (3) There are no unused features in the specification that greatly increase implementation complexity. There are no such unused features in RFC 5011. (4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. The IPR claims against RFC 5011 are non-specific and do not appear to have affected the implementation of the protocol. Note that RFC 5011 does include normative references to RFC 3755, RFC 4033, RFC 4034 and RFC 4035 that will become down-refs if RFC 5011 is reclassified as "Internet Standard." These down-refs do not preclude reclassification of RFC 5011 under the criteria of RFC 6410. = The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. = The file can be obtained via = http://www.ietf.org/rfc/rfc5011.txt = = IESG discussion can be tracked via = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D5011&rfc_flag=3D1=20 From jnc@mercury.lcs.mit.edu Fri Oct 5 08:00:42 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6721F8718; Fri, 5 Oct 2012 08:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L943r41kuM37; Fri, 5 Oct 2012 08:00:41 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 84CCB21F86CA; Fri, 5 Oct 2012 08:00:41 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BCCED18C136; Fri, 5 Oct 2012 11:00:40 -0400 (EDT) To: ietf@ietf.org Message-Id: <20121005150040.BCCED18C136@mercury.lcs.mit.edu> Date: Fri, 5 Oct 2012 11:00:40 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailman-Approved-At: Fri, 05 Oct 2012 08:40:02 -0700 Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: RFC 5011 (Automated Updates of DNS Security (DNSSEC) Trust Anchors) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 15:00:42 -0000 > The IESG has received a request from the author to consider the > following document: > 'Automated Updates of DNS Security (DNSSEC) Trust Anchors,' RFC 5011 > as an Internet Standard. > ... > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. I strongly support this requested action. This specification is both i) well designed (not to mention very clever :-), and ii) fulfils a real, major need. Noel From suruti94@gmail.com Fri Oct 5 09:22:08 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC66E21F8794 for ; Fri, 5 Oct 2012 09:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRAa18zTsjwm for ; Fri, 5 Oct 2012 09:22:07 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C787321F86F5 for ; Fri, 5 Oct 2012 09:22:07 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2073967pbb.31 for ; Fri, 05 Oct 2012 09:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kv2ciEfSbf4cKV24eG2JZBCu0tPMmbbWpUSDsXItSjI=; b=pAS9I8DbK8SFMbs2IygGPpClcBNggoiGJ3jL6Kf8PyP1clUVqIhpVZNASnh8D5vooR nHPLaDqxgF3DKWgR1TzOx6W/FsYQlPmIQR7A72dC4bIy8xHINlOuOOiiFXMvki3+RTNF Roednb/JChw82TPAkwoa3wfwvo3lCzX5IB6LgUa6QigPxTwy2WdMhWq2NMLvzvRWtQj+ lNVlPZAbi9JASkZqS4CXY+dQOdTxJQoRELGWN9Rf8XIMsmpuj+xigseixJM2B2EJYLhp tp2HSMxHk0IZqEXFTgGvLEh8kha+CM/T118y8l9jkFWY2gmMY1/HjRDZZ43UCbLoVV1j BIpg== MIME-Version: 1.0 Received: by 10.68.195.226 with SMTP id ih2mr32656034pbc.9.1349454127532; Fri, 05 Oct 2012 09:22:07 -0700 (PDT) Received: by 10.68.47.136 with HTTP; Fri, 5 Oct 2012 09:22:07 -0700 (PDT) In-Reply-To: <506EC767.60908@nlnetlabs.nl> References: <0C2D2E8E-0E36-4C4B-82BA-9536748B9AAE@rfc1035.com> <20121004222208.5433A28961E2@drugs.dv.isc.org> <20121005003303.5B9FB28971C0@drugs.dv.isc.org> <506EC767.60908@nlnetlabs.nl> Date: Fri, 5 Oct 2012 09:22:07 -0700 Message-ID: From: Mohan Parthasarathy To: "W.C.A. Wijngaards" Content-Type: multipart/alternative; boundary=047d7b10ca61e98bda04cb52457e Cc: dnsext@ietf.org Subject: Re: [dnsext] SOA without NS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 16:22:09 -0000 --047d7b10ca61e98bda04cb52457e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 5, 2012 at 4:41 AM, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Casey, > > On 10/05/2012 02:33 AM, Mark Andrews wrote: > > > > In message > > > > > > > , Casey Deccio writes: > >> > >> On Thu, Oct 4, 2012 at 3:22 PM, Mark Andrews > >> wrote: > >> > >>> Even if the parent zone used NSEC records as long as there is a > >>> DS record it would still validate for almost all queries. > >> > >> > >> Perhaps in theory, although both my BIND and unbound resolvers > >> return responses without the AD bit set: > > > > Which is because the zones are not set up as described in the > > hypothetical situation introduced with "Even if". > > So, what unbound thinks as it validates this, is that this data falls > inside the optout span of an NSEC3 (which is valid) above it. And no > zone cut was observed, thus, these zones are co-hosted on the same > server, it is in insecure-space. It does not 'check' the zone-cut for > misconfiguration, because it was already insecure. Realistically, the > data does not conform to the RFC text that you quote; it is misconfigured. > > NS bit check does come into play if there is a matching NSEC or NSEC3 record in the parent zone. That's how you know it is a insecure delegation in the case of an exact match. I agree that in the case of NSEC3 opt-out, misconfiguration is ignored. -mohan > It could also be bogus, if the parent did not use optout (or NSEC) and > also did not make a zone-cut (the misconfiguration), then the > validator sees the data, but cannot get an optout span NSEC3 above it. > Instead finds out 'the zone cut does not exist', and data from the > child zone is bogus. > > To make it work, the operator needs to insert NS records for the > lower-zone into the parent-zonefile (and child DS record if it > exists). This (after signing) creates the proper NSEC/NSEC3s. For > buero.former03 this means inserting DS records for buero.former03 into > the former03 zone (and NS records). > > Best regards, > Wouter > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJQbsdnAAoJEJ9vHC1+BF+Ni2gQAIMY6k4tUlv0IwGE6syun/Xf > 72H5QIJw5OBA1rMZKdY/+VjVBwLiH9RSf5StNFQeHdYymDqvgKXKews6KBBRVd3c > Mq+OJ16anDjcxWN2yoAXIIOy8XtItoDv2YOyVwPo6nc+xs0H9faedWKUdLxDPsz8 > NlQ5YsGgBGaMRQJEAKEoJGL1crBx0Epk0z6fW5W7WVMkZUNEH3V+CpJ6WoiziKAt > 6qG7XjJlnZQ5uRTNSh05f/0HKjX3xyLtka02yRZrNxXz+zFxJ2+ddlEmT0crRuRR > II1K/jLU0jXOJOTvAdVEeYZXQGavtr3GU9h3EOMqnEyyPHQIdL8Z+5rkW/WyMSiO > bryWXANnxDKdMqzs9Dp0wv0i0RBpQ+xbYn0l9nqexQLBlduM4P49QehH2VEjgawR > 0vA3EPnNNuMOP8TrsZM2dFeqHoeihE1/ztpAjDUoBsomRAKw1zslGQbyFvUpchva > jv8m8Q41izXgW9l0SCQrlAzNV4RcjAg0dCSvZuRyoBFo4ZKavyph01K/3SP2cKXv > QHH0V/ogcXRzVv89NacfACFMJ3q5lp8nRVLr2aez59sbqD3HN4OAxD1x8+bsu2Mf > qFSw8tSSDzi3lpby1GPHvQS7N69q7J2ckDjAx0zEnD2KKUt7RFkxfFuLDSBnvLx2 > Y6JTjx6l6UkDFLyq6faZ > =w4Y3 > -----END PGP SIGNATURE----- > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --047d7b10ca61e98bda04cb52457e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 5, 2012 at 4:41 AM, W.C.A. W= ijngaards <wouter@nlnetlabs.nl> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Casey,

On 10/05/2012 02:33 AM, Mark Andrews wrote:
>
> In message
> <CAEKtLiS8pBeW=3D=3Dx=3DztngFvD0y8d+v=3DhF+jCX-WsD689N03-eVw@mail.gmail.com> >
>
, Casey Deccio writes:
>>
>> On Thu, Oct 4, 2012 at 3:22 PM, Mark Andrews <marka@isc.org>
>> wrote:
>>
>>> Even if the parent zone used NSEC records as long as there is = a
>>> DS record it would still validate for almost all queries.
>>
>>
>> Perhaps in theory, although both my BIND and unbound resolvers
>> return responses without the AD bit set:
>
> Which is because the zones are not set up as described in the
> hypothetical situation introduced with "Even if".

So, what unbound thinks as it validates this, is that this data falls=
inside the optout span of an NSEC3 (which is valid) above it. =A0And no
zone cut was observed, thus, these zones are co-hosted on the same
server, it is in insecure-space. =A0It does not 'check' the zone-cu= t for
misconfiguration, because it was already insecure. =A0Realistically, the data does not conform to the RFC text that you quote; it is misconfigured.<= br>
NS bit check does come into play if there is a matchi= ng NSEC or NSEC3 record in the parent zone. That's how you know it is a= insecure delegation in the case of an exact match. I agree that in the cas= e of NSEC3 opt-out, misconfiguration is ignored.

-mohan
=A0=A0
It could also be bogus, if the parent did not use optout (or NSEC) and
also did not make a zone-cut (the misconfiguration), then the
validator sees the data, but cannot get an optout span NSEC3 above it.
=A0Instead finds out 'the zone cut does not exist', and data from t= he
child zone is bogus.

To make it work, the operator needs to insert NS records for the
lower-zone into the parent-zonefile (and child DS record if it
exists). =A0This (after signing) creates the proper NSEC/NSEC3s. =A0For
buero.former03 this means inserting DS records for buero.former03 into
the former03 zone (and NS records).

Best regards,
=A0 =A0Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQbsdnAAoJEJ9vHC1+BF+Ni2gQAIMY6k4tUlv0IwGE6syun/Xf
72H5QIJw5OBA1rMZKdY/+VjVBwLiH9RSf5StNFQeHdYymDqvgKXKews6KBBRVd3c
Mq+OJ16anDjcxWN2yoAXIIOy8XtItoDv2YOyVwPo6nc+xs0H9faedWKUdLxDPsz8
NlQ5YsGgBGaMRQJEAKEoJGL1crBx0Epk0z6fW5W7WVMkZUNEH3V+CpJ6WoiziKAt
6qG7XjJlnZQ5uRTNSh05f/0HKjX3xyLtka02yRZrNxXz+zFxJ2+ddlEmT0crRuRR
II1K/jLU0jXOJOTvAdVEeYZXQGavtr3GU9h3EOMqnEyyPHQIdL8Z+5rkW/WyMSiO
bryWXANnxDKdMqzs9Dp0wv0i0RBpQ+xbYn0l9nqexQLBlduM4P49QehH2VEjgawR
0vA3EPnNNuMOP8TrsZM2dFeqHoeihE1/ztpAjDUoBsomRAKw1zslGQbyFvUpchva
jv8m8Q41izXgW9l0SCQrlAzNV4RcjAg0dCSvZuRyoBFo4ZKavyph01K/3SP2cKXv
QHH0V/ogcXRzVv89NacfACFMJ3q5lp8nRVLr2aez59sbqD3HN4OAxD1x8+bsu2Mf
qFSw8tSSDzi3lpby1GPHvQS7N69q7J2ckDjAx0zEnD2KKUt7RFkxfFuLDSBnvLx2
Y6JTjx6l6UkDFLyq6faZ
=3Dw4Y3
-----END PGP SIGNATURE-----
___________________________________= ____________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext

--047d7b10ca61e98bda04cb52457e-- From jinmei@isc.org Fri Oct 5 10:38:30 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D9C21F844B for ; Fri, 5 Oct 2012 10:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYhfoYj0qn1G for ; Fri, 5 Oct 2012 10:38:30 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 1051C21F8444 for ; Fri, 5 Oct 2012 10:38:30 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id F37405F9957; Fri, 5 Oct 2012 17:38:20 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 16668216C7B; Fri, 5 Oct 2012 17:38:19 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Fri, 05 Oct 2012 10:38:18 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Olafur Gudmundsson In-Reply-To: <506E31A6.5050605@ogud.com> References: <506E31A6.5050605@ogud.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: dnsext@ietf.org Subject: Re: [dnsext] type NSEC query at a parent's zone cut X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:38:30 -0000 Hello, Thanks for the comments. At Thu, 04 Oct 2012 21:02:30 -0400, Olafur Gudmundsson wrote: > > I have a quick and simple question: what should an authoritative > > server return to a query for an NSEC RR(set) at the parent side of a zone > > cut? For example, what should a root server return to the query > > "com/NSEC"? > > > > I'm asking this because different root servers actually return > > different answers (and based on initial offlist communication this > > didn't seem to be a very known topic). It may depend on from where > > you query, but from the location I'm writing this message, the E, H, K > > and L root servers return a referral to .com (just like when asking > > for com/AAAA). Others return an authoritative answer that has the > > com/NSEC RR in the answer section (just like when asking for com/DS). > > > If the server is only authoritative for the parent then: I should have been clearer, but I meant this simple case. > As the type NSEC exists in the zone you are asking for at the name you > are asking for the servers should return it. > Just like if the query was for RRSIG or NS or DS at that point. That was my interpretation of RFC4035 too, but does the RFC clearly specify so (or at least is that the community's consensus even if not explicitly documented)? And, should we send a report to developers of the authoritative servers that behave differently (like the E/H/K/L root servers that are reachable from my place)? What should new implementors do? > If the server is authoritative for both parent and child it gets much > grayer to answer the question. Probably, but I didn't even think about the trickier case because I saw different behaviors even in the simpler case:-) Talking about grayer cases, one other subtle case is what the server should do if it receives a type NSEC query at a parent's zone cut but there's no NSEC at that point, like the case of example.com/NSEC at the .com zone. Considering it would be treated as authoritative if it were exist, it might have to be an authoritative negative answer. But based on my experiments all deployed servers return a referral in this case. > Based on the different behavior of nameservers that I have seen I use > RFC4471 names to probe for NSEC records at delegations. Sorry, I'm afraid I don't understand this part...is it related to my question? --- JINMEI, Tatuya Internet Systems Consortium, Inc. From john-ietf@jck.com Fri Oct 5 11:06:44 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7FC21F87E4; Fri, 5 Oct 2012 11:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFLzYmXv1Dfm; Fri, 5 Oct 2012 11:06:43 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5F32721F87DC; Fri, 5 Oct 2012 11:06:43 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TKCIF-000IeJ-Rs; Fri, 05 Oct 2012 14:06:35 -0400 Date: Fri, 05 Oct 2012 14:06:26 -0400 From: John C Klensin To: =?UTF-8?Q?Jo=C3=A3o_Damas?= Message-ID: <1E32ACCB0F8FA9E01D3DCB5B@JcK-HP8200.jck.com> In-Reply-To: References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <506B01D1.9080708@ogud.com> <8F3DCBA9A3AF566810CD1061@JcK-HP8200.jck.com> <506B6BE9.2000805@ogud.com> <20121003011556.526A82873A5E@drugs.dv.isc.org> <84187E41-0CEC-4CA2-801D-5AB1171FFF9B@bondis.org> <396CFDC14B6FEF29A37A2FFF@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: 'IETF-Discussion list' , Olafur Gudmundsson , dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:06:44 -0000 --On Friday, October 05, 2012 10:29 +0200 Jo=C3=A3o Damas wrote: >... >> IMO, this discussion has turned up two ways in which the case >> for eliminating the possibility of additional label types >> could be made: >>=20 >> (2.1) Demonstrating that simply having the capability defined >> and available in principle is somehow harmful. > People here can correct me, as my memory is fuzzy, but binary > labels did cause harm to several deployed implementations. > Don't know if this is just case in favour of natural = selection. Again, I'm not defending binary labels. Many people thought they were a good idea at the time. But, just as "binary labels failed" is a good argument for deprecating binary labels but not a good argument for deprecating label types generally, "binary labels caused harm" (assuming that is the case) would not be a basis for inferring that all labels types would cause harm, much less that retaining the capability for using extended label types would be harmful. Just as "some cows are brown and all cows are animals" doesn't tell you a thing about the color of all animals, "binary labels were a bad idea and binary labels are an instance of extended label types" doesn't constitute an argument for deprecating label types. >> (2.2) The WG has consensus on a bright line that defines the >> nature of proposals that would require going to DNSng rather >> than EDNSx-type extensions to the current model, has = concluded >> that any extensions or alterations to the label definition of >> 1034/1035 would require crossing that line, and is prepared = to >> document that line and get IETF consensus on it (either as >> part of this document or one normatively referenced from it). =20 > Pretty much, that is my understanding. It is quite possible > that this has been a position reached over many iterations of > discussions and is not actually documented anywhere. If there is a bright line, it would definitely benefit the broader community to be able to see a description and discuss it. If there is only a general feeling in the WG... well, that doesn't count for much, especially given the history of disagreements about what the base DNS specifications say and what assorted terminology means. john From john-ietf@jck.com Fri Oct 5 11:07:34 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E7721F87FB; Fri, 5 Oct 2012 11:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM+N0BMU7LgT; Fri, 5 Oct 2012 11:07:34 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id CC48A21F87F9; Fri, 5 Oct 2012 11:07:33 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TKCJ8-000IeU-Sv; Fri, 05 Oct 2012 14:07:30 -0400 Date: Fri, 05 Oct 2012 14:07:21 -0400 From: John C Klensin To: JFC Morfin , dnsext@ietf.org Message-ID: <28FF79F3EE9E12A52095F3CC@JcK-HP8200.jck.com> References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IESG , "iab@iab.org IAB" , iucg , IUTF Subject: Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:07:35 -0000 Hi. Jefsey's note shows me that I should clarify why I think the topic of deprecating labels types is worth the effort to discuss. Let me suggest a little calibration about one aspect of this discussion and its possible interactions with the plans Jefsey mentions and plans others might have. --On Friday, October 05, 2012 05:50 +0200 JFC Morfin wrote: >... > Extended label types are Internet DNS features that will > certainly be retained in these specs and the current > prototyping work does include the support of Binary labels for > testing. Because extended label types have never been successfully deployed and used, it would be better to describe them as a design opportunity than as a DNS feature. More important, what everyone who has looked closely at the "extended DNS" landscape seems to agree on is that the practical deployment time for new features is almost certain to be a decade or more. Some new features, like DNAME, can be designed so that upgraded servers have a mechanism for dealing with un-upgraded clients (resolvers and recursive servers) without loss of information or functionality. Others, like DNSSEC an binary labels, cannot. Even one decade is a rather long time in Internet years. Few communities have shown a willingness to sit around and wait that long for good solutions. Kludges and poor solutions that address only part of the problem are much more attractive and much more common. However, deploying a necessarily-incompatible DNSng would almost certainly take even longer. I assume that is one of the reasons we have so much interest in (or toleration for) EDNSx and incremental extension mechanisms. If there is any plausible possibility of developing new extensions that build on label types in the future, then I think it is a bad idea to deprecate the feature, no matter how many arguments are made about alternate mechanisms or the failure of one attempt. On the other hand, if the intent is to get rid of extension models that cannot be effectively deployed and used in a few years, then any future EDNS0 extension that would require a long deployment time before becoming useful should be prohibited by the spec too. I just don't see how one can have it both ways... again, unless it can be demonstrated that the existence of the label-type capability causes harm even if unused. best, john From ogud@ogud.com Fri Oct 5 12:24:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9820A21F8671 for ; Fri, 5 Oct 2012 12:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj94OtkppNte for ; Fri, 5 Oct 2012 12:24:15 -0700 (PDT) Received: from smtp188.iad.emailsrvr.com (smtp188.iad.emailsrvr.com [207.97.245.188]) by ietfa.amsl.com (Postfix) with ESMTP id 11C4021F85EA for ; Fri, 5 Oct 2012 12:24:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp58.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2808730856E; Fri, 5 Oct 2012 15:24:14 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp58.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 16662308586; Fri, 5 Oct 2012 15:24:12 -0400 (EDT) Message-ID: <506F33DA.8000007@ogud.com> Date: Fri, 05 Oct 2012 15:24:10 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: <506E31A6.5050605@ogud.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] type NSEC query at a parent's zone cut X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 19:24:15 -0000 1 On 05/10/2012 13:38, JINMEI Tatuya / 神明é”哉 wrote: >> Based on the different behavior of nameservers that I have seen I use >> >RFC4471 names to probe for NSEC records at delegations. > Sorry, I'm afraid I don't understand this part...is it related to my > question? If you want the NSEC record for foo.bar. asking for foo!!!!!!!!!!!!!!!!!!!!.bar is likely to give you what you want :-) (! is the first displayable character in the ascii table but not a valid hostname character) Olafur From marka@isc.org Fri Oct 5 16:31:54 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3569121F8504 for ; Fri, 5 Oct 2012 16:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXskzoM3Zrec for ; Fri, 5 Oct 2012 16:31:53 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id DCA3D21F84F8 for ; Fri, 5 Oct 2012 16:31:51 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4BF225F9891; Fri, 5 Oct 2012 23:31:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b45e:699c:b294:f8d1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1A49E216C87; Fri, 5 Oct 2012 23:31:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id E80A128C4113; Sat, 6 Oct 2012 09:31:35 +1000 (EST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Mark Andrews References: <506E31A6.5050605@ogud.com> In-reply-to: Your message of "Fri, 05 Oct 2012 10:38:18 MST." Date: Sat, 06 Oct 2012 09:31:35 +1000 Message-Id: <20121005233135.E80A128C4113@drugs.dv.isc.org> Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] type NSEC query at a parent's zone cut X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 23:31:54 -0000 In message , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP 0BMQEMjOkgbKEI=?= writes: > Hello, > > Thanks for the comments. > > At Thu, 04 Oct 2012 21:02:30 -0400, > Olafur Gudmundsson wrote: > > > > I have a quick and simple question: what should an authoritative > > > server return to a query for an NSEC RR(set) at the parent side of a zone > > > cut? For example, what should a root server return to the query > > > "com/NSEC"? > > > > > > I'm asking this because different root servers actually return > > > different answers (and based on initial offlist communication this > > > didn't seem to be a very known topic). It may depend on from where > > > you query, but from the location I'm writing this message, the E, H, K > > > and L root servers return a referral to .com (just like when asking > > > for com/AAAA). Others return an authoritative answer that has the > > > com/NSEC RR in the answer section (just like when asking for com/DS). > > > > > If the server is only authoritative for the parent then: > > I should have been clearer, but I meant this simple case. > > > As the type NSEC exists in the zone you are asking for at the name you > > are asking for the servers should return it. > > Just like if the query was for RRSIG or NS or DS at that point. > > That was my interpretation of RFC4035 too, but does the RFC clearly > specify so (or at least is that the community's consensus even if not > explicitly documented)? And, should we send a report to developers of > the authoritative servers that behave differently (like the E/H/K/L > root servers that are reachable from my place)? What should new > implementors do? Nameservers and validators have no need to query for NSEC records directly. I'm tempted to say, just let both behaviours exist. Unless you are talking directly to the server you can't be sure about which set of NSEC records will be returned and if both are returned to a NSEC query you need split them in two and also split the RRSIG sets. > > If the server is authoritative for both parent and child it gets much > > grayer to answer the question. > > Probably, but I didn't even think about the trickier case because I > saw different behaviors even in the simpler case:-) Talking about > grayer cases, one other subtle case is what the server should do if it > receives a type NSEC query at a parent's zone cut but there's no NSEC > at that point, like the case of example.com/NSEC at the .com zone. > Considering it would be treated as authoritative if it were exist, it > might have to be an authoritative negative answer. But based on my > experiments all deployed servers return a referral in this case. > > > Based on the different behavior of nameservers that I have seen I use > > RFC4471 names to probe for NSEC records at delegations. > > Sorry, I'm afraid I don't understand this part...is it related to my > question? > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@iecc.com Sat Oct 6 18:46:41 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E39F21F84AF for ; Sat, 6 Oct 2012 18:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.937 X-Spam-Level: X-Spam-Status: No, score=-109.937 tagged_above=-999 required=5 tests=[AWL=-1.197, BAYES_20=-0.74, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_23=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIvary3uQIlz for ; Sat, 6 Oct 2012 18:46:40 -0700 (PDT) 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 27F2821F8499 for ; Sat, 6 Oct 2012 18:46:39 -0700 (PDT) Received: (qmail 57383 invoked from network); 7 Oct 2012 01:46:34 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Oct 2012 01:46:34 -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=5070defa.xn--yuvv84g.k1208; i=johnl@user.iecc.com; bh=myJ+invVFdggZmLZThRLY9TZoVOTG+dDngcdpf1rzUk=; b=i5ZO4kd+W45xOmZeANFp2AduiMpprfBkswKDhJx8WiiJi0YU1povkyQZaJY8QxApC+dQRH+buDZllfLme8cJbaFtubXqM2yZeRexxCbF/AtgC1sExd1smCQOsQyXbEpMgW1ZnfSB2PLdug7JznwwldyoERUry2Rr8Zzsjn3fBus= 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=5070defa.xn--yuvv84g.k1208; olt=johnl@user.iecc.com; bh=myJ+invVFdggZmLZThRLY9TZoVOTG+dDngcdpf1rzUk=; b=sTVfPqgeXoWBwaG3TF6atLC6J/yqznHJkHVxslQG2tobitNtRlKCGGJ5pc/lqokUS4xFcxOojgNbMx1OTmQJQeIlUTbymk8sjrxRWmvahb2Ae1xFRu1LlZWcdKGa8kPPVlAmYIhiCgAv2QoyQI4Cf+O6+k+dzK+eFywR+eHIjCg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 Oct 2012 01:46:12 -0000 Message-ID: <20121007014612.32491.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [dnsext] Glue at the zone cut ? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 01:46:41 -0000 I see that DNS provisioning systems generally won't let you put a glue record at the zone, cut, e.g. you can't do this: $ORIGIN example. foo NS foo foo A 10.1.2.3 but you have to do this instead foo NS ns.foo ns.foo A 10.1.2.3 Is there a technical reason not to allow the glue at the zone cut, or is it just that it's ugly? I know it's ugly, you don't have to tell me that, the question is whether it breaks stuff. R's, John From regnauld@x0.dk Sat Oct 6 19:01:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B645A21F849D for ; Sat, 6 Oct 2012 19:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbiHOaidtetu for ; Sat, 6 Oct 2012 19:01:24 -0700 (PDT) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by ietfa.amsl.com (Postfix) with ESMTP id 331BA21F849B for ; Sat, 6 Oct 2012 19:01:23 -0700 (PDT) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id C12774D1DD9; Sun, 7 Oct 2012 04:01:21 +0200 (CEST) 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 wmPqWspSta3m; Sun, 7 Oct 2012 04:01:21 +0200 (CEST) Received: from macbook.bluepipe.net (x0.dk [194.19.205.214]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTPA id 451F44D1DD4; Sun, 7 Oct 2012 04:01:19 +0200 (CEST) Received: by macbook.bluepipe.net (Postfix, from userid 1001) id 1CF3D241497C; Sun, 7 Oct 2012 04:01:19 +0200 (CEST) Date: Sun, 7 Oct 2012 04:01:19 +0200 From: Phil Regnauld To: John Levine Message-ID: <20121007020119.GJ4233@macbook.bluepipe.net> References: <20121007014612.32491.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121007014612.32491.qmail@joyce.lan> X-Operating-System: Darwin 12.2.0 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org Subject: Re: [dnsext] Glue at the zone cut ? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 02:01:24 -0000 John Levine (johnl) writes: > I see that DNS provisioning systems generally won't let you put a glue > record at the zone, cut, e.g. you can't do this: Having written such software, I can say it's not something that was ever forbidden or treated any differently... > Is there a technical reason not to allow the glue at the zone cut, or > is it just that it's ugly? I know it's ugly, you don't have to tell > me that, the question is whether it breaks stuff. I don't know about ugly, after all some people think A records at the zone apex are inelegant But it doesn't break anything, as far as I've tested. Cheers, Phil From mohta@necom830.hpcl.titech.ac.jp Sun Oct 7 01:57:01 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E0621F84F8 for ; Sun, 7 Oct 2012 01:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIjOGERn5j1c for ; Sun, 7 Oct 2012 01:57:01 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id C6CA321F84F5 for ; Sun, 7 Oct 2012 01:57:00 -0700 (PDT) Received: (qmail 85061 invoked from network); 7 Oct 2012 09:11:02 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 7 Oct 2012 09:11:02 -0000 Message-ID: <507143A8.5030503@necom830.hpcl.titech.ac.jp> Date: Sun, 07 Oct 2012 17:56:08 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20121007014612.32491.qmail@joyce.lan> In-Reply-To: <20121007014612.32491.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Glue at the zone cut ? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 08:57:01 -0000 John Levine wrote: > I see that DNS provisioning systems generally won't let you put a glue > record at the zone, cut, e.g. you can't do this: > > $ORIGIN example. > foo NS foo > foo A 10.1.2.3 that is a problem. > but you have to do this instead > > foo NS ns.foo > ns.foo A 10.1.2.3 in addition, with the following example: foo NS ns.foo NS ns.bar ns.foo A 10.1.2.3 bar NS ns.foo NS ns2.foo if ns.foo is down, neither foo nor bar is resolvable unless the following glue ns2.foo A 10.1.2.4 is added to zone bar. > Is there a technical reason not to allow the glue at the zone cut, or > is it just that it's ugly? The fundamental problem is zone content defined by rfc1034 is broken a little. That is, in zone foo, the following inconsistent glue A a.foo NS ns.bar ns.bar A 10.1.2.3 b.foo NS ns.bar ns.bar A 192.168.1.2 should be able to be specified. That is, glue A should be tagged with referral point as: ns.bar A 10.1.2.3 (to be used for a.foo only) ns.bar A 192.168.1.2 (to be used for b.foo only) Masataka Ohta From mansaxel@besserwisser.org Mon Oct 8 03:52:21 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF1F21F8530 for ; Mon, 8 Oct 2012 03:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_25=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfPhozjrKXZ2 for ; Mon, 8 Oct 2012 03:52:20 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id 68A7421F853B for ; Mon, 8 Oct 2012 03:52:19 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 76F18A1F9; Mon, 8 Oct 2012 12:52:16 +0200 (CEST) Date: Mon, 8 Oct 2012 12:52:16 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: John Levine Message-ID: <20121008105216.GB9181@besserwisser.org> References: <20121007014612.32491.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline In-Reply-To: <20121007014612.32491.qmail@joyce.lan> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] Glue at the zone cut ? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 10:52:21 -0000 --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [dnsext] Glue at the zone cut ? Date: Sun, Oct 07, 2012 at 01:46:1= 2AM -0000 Quoting John Levine (johnl@taugh.com): > Is there a technical reason not to allow the glue at the zone cut, or > is it just that it's ugly? I know it's ugly, you don't have to tell > me that, the question is whether it breaks stuff. I run this in production and it is=20 * a matter of taste.=20 * technically correct.=20 * to the best of my knowledge not a problem for dns software.=20 The only things that break are badly designed provisioning systems.=20 ; <<>> DiG 9.6-ESV-R4-P3 <<>> @primary.se primary.se AXFR ; (2 servers found) ;; global options: +cmd primary.se. 3600 IN SOA casper.besserwisser.org. mansaxel.besserwisser.org= =2E 2011102301 600 1800 3600000 300 primary.se. 3600 IN NS ns.cafax.se. primary.se. 3600 IN NS ns1.frobbit.se. primary.se. 3600 IN NS primary.se. primary.se. 3600 IN NS secondary.se. primary.se. 3600 IN NS xn--domnhanteraren-r-buggig-x7b.primary.se. primary.se. 3600 IN A 192.36.115.53 primary.se. 3600 IN AAAA 2a01:298:4::53 primary.se. 10 IN MX 10 mx1.besserwisser.org. www.primary.se. 3600 IN CNAME jaja.besserwisser.org. xn--domnhanteraren-r-buggig-x7b.primary.se. 3600 IN A 192.36.115.53 xn--domnhanteraren-r-buggig-x7b.primary.se. 3600 IN TXT "v=3Dspf1 ip6:0::/0= -all" xn--domnhanteraren-r-buggig-x7b.primary.se. 3600 IN TXT "v=3Dspf1 ip4:0.0.0= =2E0/0 -all" primary.se. 3600 IN SOA casper.besserwisser.org. mansaxel.besserwisser.org= =2E 2011102301 600 1800 3600000 300 ;; Query time: 12 msec ;; SERVER: 2a01:298:4::53#53(2a01:298:4::53) ;; WHEN: Mon Oct 8 12:47:28 2012 ;; XFR size: 14 records (messages 1, bytes 440) (the 5'th NS record points to a host name that post decoding says the equivalent of "The DNS provisioning system at IIS.SE is b0rkened." Now it's your turn to guess why I put that there ;-)) --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I know th'MAMBO!! I have a TWO-TONE CHEMISTRY SET!! --lEGEL1/lMxI0MVQ2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlBysGAACgkQ02/pMZDM1cUGewCgqGmD2gUN90sCLIfiuKhjtPa2 6PIAn2n4mYXeNCpS96YsQucBkg0v/iax =4pJ6 -----END PGP SIGNATURE----- --lEGEL1/lMxI0MVQ2-- From peter@denic.de Mon Oct 8 06:38:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C148521F8445 for ; Mon, 8 Oct 2012 06:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stTxyvBtg92c for ; Mon, 8 Oct 2012 06:38:11 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3F02821F842D for ; Mon, 8 Oct 2012 06:38:10 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1TLDX6-0005bi-Am; Mon, 08 Oct 2012 15:38:08 +0200 Received: from localhost by x27.adm.denic.de with local id 1TLDX6-0002wj-7D; Mon, 08 Oct 2012 15:38:08 +0200 Date: Mon, 8 Oct 2012 15:38:08 +0200 From: Peter Koch To: dnsext@ietf.org Message-ID: <20121008133808.GC16852@x28.adm.denic.de> References: <20121007014612.32491.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121007014612.32491.qmail@joyce.lan> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dnsext] Glue at the zone cut ? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 13:38:11 -0000 On Sun, Oct 07, 2012 at 01:46:12AM +0000, John Levine wrote: > I see that DNS provisioning systems generally won't let you put a glue > record at the zone, cut, e.g. you can't do this: could you be a bit more specific about 'generally'? Is it registry/registrar systems you are talking about or user interfaces for feeding (provisioning) data into some DNS server? > Is there a technical reason not to allow the glue at the zone cut, or They are not special, just maybe counter intuitive. -Peter From benl@google.com Mon Oct 8 06:38:28 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF25221F84F1 for ; Mon, 8 Oct 2012 06:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzaJT+f7AFwp for ; Mon, 8 Oct 2012 06:38:27 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01021F84EA for ; Mon, 8 Oct 2012 06:38:26 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2475197wgb.13 for ; Mon, 08 Oct 2012 06:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=SimJFbiQYSsNiJtyTwW6R0EQYh2pRnjqIGfFizGyBAY=; b=iOA5EWduGILBm78GzA3xVdPXqJFNoYh0P/8pVJJM8PsJq8bKiysxe4EFBLZ25du6jx HHEnGU5ToaiXWmHW6BC760zG+CpbDS+m20hbgoxVPNQjmlmnJS2z79Yoous4zX+ah8WK jaT3pbgvScy94rd0jptbkiMNLohT0YXx4TapkNhIMgKQJMtwvVGhvuSN+1ahnQZakio/ wT0EFHxFdgIBEnOrSryhkRvzCLWzdH/wAT9G9daNygSVwURx7HZaD2++6WUANYs9Yi1T 0UTUkzohkuUrCja1FEq2V5yVIqk5+vU6gRLabpUjzRCx79v9QQo5TkAjOY3I/gTbxZwt bnwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=SimJFbiQYSsNiJtyTwW6R0EQYh2pRnjqIGfFizGyBAY=; b=Zy5FIldcZvRT10m1FfY3kvyxURm91zNq47p0wDmq/+OVhgbY59fTbUx7QxoS3sOE5G hZSO0qoKVSrudPdccCfqDqX5vklonIbqQIcpLfrK0tlOyCqP51fUFeFasUf614ED2V1l U9GfGdXysPahKPsPbG1RZcpaMyUU0srwvg3nCwe4rheNVN36Ous+9ySfDphfBdBFM+kO 6ByAHQpf+JBnKJYpSWQsk8QPs8PiPTuyeR/ODHqamH6TFfAHO4iHUJYW+9IUJ84eOfUl q7GJgp3zVPHJVdUuy7FfaMzgPGJbq/SZ40kBvER2n4Us6ObFR7i3DSAMkO9ad+eN3UPW luyQ== MIME-Version: 1.0 Received: by 10.216.119.6 with SMTP id m6mr9237573weh.215.1349703506070; Mon, 08 Oct 2012 06:38:26 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Mon, 8 Oct 2012 06:38:25 -0700 (PDT) Date: Mon, 8 Oct 2012 14:38:25 +0100 Message-ID: From: Ben Laurie To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQncQmF3Zn3rxsA+w46RByhdEMyRQdzZb32NKTmcyK2estdut2BFLA+r+MH/Fb7/7Id07Gil+OZYAuVCQxMImkNU0F3qg+SL0AS4pMQq0AHyzQZAn4mpmQVcyswf8ORibBSAvWHogfWFCe4v+n7aXAd+U+61ZKss6poQ3gq/spGPXSrfCY/eR4EeMwJGFGJE6Dvj+nPi Subject: [dnsext] Problem with draft-ietf-dnsext-dnssec-bis-updates-19 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 13:38:28 -0000 http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-19#section-5.1 says "When canonicalizing DNS names (for both ordering and signing), DNS names in the RDATA section of NSEC resource records are not downcased. DNS names in the RDATA section of RRSIG resource records are downcased." This appears to be true, but it caused us some confusion: DNS names in NSEC _are_ still downcased for ordering purposes, and need to be or there's not much point in NSEC. It'd be nice you have a clarifying comment in 5.1... BTW, at some point I appear to have fallen off this list, but not sure why... From fanf2@hermes.cam.ac.uk Mon Oct 8 06:46:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BCB21F8585 for ; Mon, 8 Oct 2012 06:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.234 X-Spam-Level: X-Spam-Status: No, score=-5.234 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPj2qBz0wv2M for ; Mon, 8 Oct 2012 06:46:30 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3444B21F857E for ; Mon, 8 Oct 2012 06:46:30 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46490) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1TLDf5-0006jX-RY (Exim 4.72) (return-path ); Mon, 08 Oct 2012 14:46:23 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TLDf5-0003LG-Gn (Exim 4.72) (return-path ); Mon, 08 Oct 2012 14:46:23 +0100 Date: Mon, 8 Oct 2012 14:46:23 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20121005233135.E80A128C4113@drugs.dv.isc.org> Message-ID: References: <506E31A6.5050605@ogud.com> <20121005233135.E80A128C4113@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] type NSEC query at a parent's zone cut X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 13:46:31 -0000 Mark Andrews wrote: > Nameservers and validators have no need to query for NSEC records > directly. > > I'm tempted to say, just let both behaviours exist. Unless you are > talking directly to the server you can't be sure about which set > of NSEC records will be returned and if both are returned to a NSEC > query you need split them in two and also split the RRSIG sets. I find it odd that none of the root servers respond to an ANY query at a delegation point in a way I would consider correct, i.e. by returning all the records held by the server at that owner name. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From marka@isc.org Mon Oct 8 06:48:46 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B3221F851E for ; Mon, 8 Oct 2012 06:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr33tUSD8KUz for ; Mon, 8 Oct 2012 06:48:46 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 080C621F84CF for ; Mon, 8 Oct 2012 06:48:46 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id EAADBC94F5; Mon, 8 Oct 2012 13:48:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B3DE3216C81; Mon, 8 Oct 2012 13:48:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 9AA9828EDD88; Tue, 9 Oct 2012 00:48:33 +1100 (EST) To: Ben Laurie From: Mark Andrews References: In-reply-to: Your message of "Mon, 08 Oct 2012 14:38:25 BST." Date: Tue, 09 Oct 2012 00:48:33 +1100 Message-Id: <20121008134833.9AA9828EDD88@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Problem with draft-ietf-dnsext-dnssec-bis-updates-19 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 13:48:46 -0000 In message , Ben Laurie writes: > http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-19#section-5. > 1 > says > > "When canonicalizing DNS names (for both ordering and signing), DNS > names in the RDATA section of NSEC resource records are not > downcased. DNS names in the RDATA section of RRSIG resource records > are downcased." > > This appears to be true, but it caused us some confusion: DNS names in > NSEC _are_ still downcased for ordering purposes, and need to be or > there's not much point in NSEC. Given that NSEC records are singletons there is nothing to order. > It'd be nice you have a clarifying comment in 5.1... > > BTW, at some point I appear to have fallen off this list, but not sure why... > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From benl@google.com Mon Oct 8 06:49:29 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC8721F85B4 for ; Mon, 8 Oct 2012 06:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYyAaAA4z0Nv for ; Mon, 8 Oct 2012 06:49:28 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD8521F85AF for ; Mon, 8 Oct 2012 06:49:28 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so3083335wib.13 for ; Mon, 08 Oct 2012 06:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=/f0g7oJO0RhlhowG9BeDLmaEV6yhBLbVCD2s8bzaLZ8=; b=kdm2WXlF+prmO85o7fzXzhXgjEAGskrwEMFsmvWgdF+zexCxxxm+0CggPvnmU3yM6H 5UsBxEVarjalTzAps7qR8TMDHkHmx6GoFAT0WPbob6zuT78qhG1veo4eJVFC5R1P9KW5 3Gs2+mAGwGzpD1Op5/W35y+Wc7+zrANuB07aoS7WVzItfGatW2xLPmjR2pssP7xX5OFr eycLiyvhbee0fuSwE9zpGL+NhWRhupUXcfj4k1kZ8nDTM+GcLzC3WgST4pNNnmkhuvLI I0bTxxrNm6dNVpRVDCxprkIG3J+a7qmMYM5u8S/CurVtfD70CgJd4lYJ/f3P9BMn704s aV4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=/f0g7oJO0RhlhowG9BeDLmaEV6yhBLbVCD2s8bzaLZ8=; b=cZZWBnn2Pv867LfTCWEOWkj6eEJxpLvFoFum/xFVjqeCL5BK+kgd1pWCPbyfzNi6e/ qWNpKvdapIHx1G4T8g3pFV1XL38wWAA6TbCFXfDJ4ovzWRTMGKRgkVSonV6Whh9auEwK ah1DqfKmkb8komQiGDjKsMqsuCDpS2qeD7fEPk8ujriQcH21aC4HZ3Qdwui9lsCK1gLe DwC+ANwXyslVbdeXd2BFjkkuRXNGortKVWvo+ro+Pnzyr+RdWGhxGkEcLIDmFYmLoC5Z aeidnRguTTXhrbT2P2+drUrx44FygHkd3CZ4quXe+ikCyzUsp8fYdfGUBL5dZfscxULS Yjhw== MIME-Version: 1.0 Received: by 10.180.85.99 with SMTP id g3mr22104425wiz.5.1349704167159; Mon, 08 Oct 2012 06:49:27 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Mon, 8 Oct 2012 06:49:27 -0700 (PDT) In-Reply-To: <20121008134833.9AA9828EDD88@drugs.dv.isc.org> References: <20121008134833.9AA9828EDD88@drugs.dv.isc.org> Date: Mon, 8 Oct 2012 14:49:27 +0100 Message-ID: From: Ben Laurie To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnm4Z17/gWkixi/nx7HlkZ/nyp1RfXK4sW8U03ZAigIEEbN10MkMkfR8/7R5YWkxvnPHlG+Hve5cCxri5nV1BUvSRgsbMIpDW0RwYcQcsXfvZGPIbm8aslzQ5MWeh/pgEhQ7oUOBBivLUWRaPHjbgqsvWlrs/9fIiQujxVjhovz63dx7Gqws5R9G3FP/cLgBq7i93jc Cc: dnsext@ietf.org Subject: Re: [dnsext] Problem with draft-ietf-dnsext-dnssec-bis-updates-19 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 13:49:29 -0000 On 8 October 2012 14:48, Mark Andrews wrote: > > In message > , Ben Laurie writes: >> http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-19#section-5. >> 1 >> says >> >> "When canonicalizing DNS names (for both ordering and signing), DNS >> names in the RDATA section of NSEC resource records are not >> downcased. DNS names in the RDATA section of RRSIG resource records >> are downcased." >> >> This appears to be true, but it caused us some confusion: DNS names in >> NSEC _are_ still downcased for ordering purposes, and need to be or >> there's not much point in NSEC. > > Given that NSEC records are singletons there is nothing to order. The owner and the next owner are ordered... > >> It'd be nice you have a clarifying comment in 5.1... >> >> BTW, at some point I appear to have fallen off this list, but not sure why... >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Oct 8 08:04:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078BA21F86FD for ; Mon, 8 Oct 2012 08:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDB4m4VKypJY for ; Mon, 8 Oct 2012 08:04:39 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3C321F86E0 for ; Mon, 8 Oct 2012 08:04:39 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 9EFA85F998F; Mon, 8 Oct 2012 15:04:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id EBD4C216C7B; Mon, 8 Oct 2012 15:04:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id BEA2928EE277; Tue, 9 Oct 2012 02:04:11 +1100 (EST) To: Ben Laurie From: Mark Andrews References: <20121008134833.9AA9828EDD88@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 08 Oct 2012 14:49:27 BST." Date: Tue, 09 Oct 2012 02:04:11 +1100 Message-Id: <20121008150411.BEA2928EE277@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Problem with draft-ietf-dnsext-dnssec-bis-updates-19 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 15:04:40 -0000 In message , Ben Laurie writes: > On 8 October 2012 14:48, Mark Andrews wrote: > > > > In message com> > > , Ben Laurie writes: > >> http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-19#section > -5. > >> 1 > >> says > >> > >> "When canonicalizing DNS names (for both ordering and signing), DNS > >> names in the RDATA section of NSEC resource records are not > >> downcased. DNS names in the RDATA section of RRSIG resource records > >> are downcased." > >> > >> This appears to be true, but it caused us some confusion: DNS names in > >> NSEC _are_ still downcased for ordering purposes, and need to be or > >> there's not much point in NSEC. > > > > Given that NSEC records are singletons there is nothing to order. > > The owner and the next owner are ordered... But ordering of RDATA is to sort records in the RRset. > > > >> It'd be nice you have a clarifying comment in 5.1... > >> > >> BTW, at some point I appear to have fallen off this list, but not sure why > ... > >> _______________________________________________ > >> dnsext mailing list > >> dnsext@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsext > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From benl@google.com Mon Oct 8 08:55:59 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B49021F880D for ; Mon, 8 Oct 2012 08:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m9Y-X-AhrgT for ; Mon, 8 Oct 2012 08:55:58 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7684221F86B5 for ; Mon, 8 Oct 2012 08:55:58 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2921326wey.31 for ; Mon, 08 Oct 2012 08:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=Yoe1T2eM1b/qyLrwC3YXdyzBhkVj04lFwK2QcX7Yncs=; b=FpCuR7dja7i70L+lcE3dcfdldK8kKw+pzYE0nBtVPeB/NcS+eR8WJTOwIBaaM7gruy LaMRnskKxHKXJjwNQgGHP3Xm1ZbJSH+BbgZ/Mkolzc+fdjgAQkpofNWRL9fqirtX98XJ c0C1g4CMfGEkQH1F8FLc+v2pyC5Rrm9820vXD56mMbFaekM0OWHU+1YKEsnUO8d0Ni/B HXhJbP0KmjfqktCgNmb+voYjTlXTTIqhdXEddnFvaF29j7JQTiSEap4oaMrQ5AsVf7XC gURY4PbtUlZ3o5MKNLYUhDQMw+2dVYUstzKXHNzpcKieW5B4+OCJk8hFLeWFB5ow90hv WKUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Yoe1T2eM1b/qyLrwC3YXdyzBhkVj04lFwK2QcX7Yncs=; b=TYe3XzsAh3hvgPv+Sg/f45+NLI1ej9JiuNvvZqRCFwnvESPgvNpkLDSn6VHorih1b0 QM+BAX26TFyRn29hvBPdxuevGq/oJttZNDT7hq3mByewuCml2ythDmU4LKdA8sa/gHXv +LflIz7yYLCwq9wDdxRDNMX70CxJBd9+sKlE6qta2w1tRiXOedSPWwemE/YqImFg2llK J4wbN+t6ikJ/KAvZ1Sqhvgz7TFMUwGTfm4J1frTEHrcL0E1qtLPENl2WvXwOMCa7J0+c l2LPxNG4Gh0J0wRFA82yyqgFygrjlOEHrn9e24hjuXSI06376yAZKP3cfaSvSJCzSo1A hx1g== MIME-Version: 1.0 Received: by 10.180.87.34 with SMTP id u2mr22975928wiz.4.1349711757231; Mon, 08 Oct 2012 08:55:57 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Mon, 8 Oct 2012 08:55:57 -0700 (PDT) In-Reply-To: <20121008150411.BEA2928EE277@drugs.dv.isc.org> References: <20121008134833.9AA9828EDD88@drugs.dv.isc.org> <20121008150411.BEA2928EE277@drugs.dv.isc.org> Date: Mon, 8 Oct 2012 16:55:57 +0100 Message-ID: From: Ben Laurie To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlvoTfqqZUrkU9Ps8+vS0xfRflV3+RRf3wSABsiuydBK9R60UnXfKESIOmKXh1P03JSwmXmkdafS9yhyoXFkiYY/FxgoQ7HlLJwMUnzpGKmp//iiv/JNe/v8KTnRJRr7Xd/pt6lBCzoh08h3SQ/AxdhqohoAmsxgj0mkQewATHPE6OriWLAokYIEoaTk1hNP32WqnmC Cc: dnsext@ietf.org Subject: Re: [dnsext] Problem with draft-ietf-dnsext-dnssec-bis-updates-19 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 15:55:59 -0000 On 8 October 2012 16:04, Mark Andrews wrote: > > In message > , Ben Laurie writes: >> On 8 October 2012 14:48, Mark Andrews wrote: >> > >> > In message > com> >> > , Ben Laurie writes: >> >> http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-19#section >> -5. >> >> 1 >> >> says >> >> >> >> "When canonicalizing DNS names (for both ordering and signing), DNS >> >> names in the RDATA section of NSEC resource records are not >> >> downcased. DNS names in the RDATA section of RRSIG resource records >> >> are downcased." >> >> >> >> This appears to be true, but it caused us some confusion: DNS names in >> >> NSEC _are_ still downcased for ordering purposes, and need to be or >> >> there's not much point in NSEC. >> > >> > Given that NSEC records are singletons there is nothing to order. >> >> The owner and the next owner are ordered... > > But ordering of RDATA is to sort records in the RRset. I agree that you can pedant away the need for any statement, I am just suggesting that it would be nice to avoid any doubt or confusion by saying something about it. It certainly confused me when I first read it. > >> > >> >> It'd be nice you have a clarifying comment in 5.1... >> >> >> >> BTW, at some point I appear to have fallen off this list, but not sure why >> ... >> >> _______________________________________________ >> >> dnsext mailing list >> >> dnsext@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dnsext >> > -- >> > Mark Andrews, ISC >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia >> > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Mon Oct 8 09:43:59 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC30D21F84D7 for ; Mon, 8 Oct 2012 09:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNXvvI0Nuygy for ; Mon, 8 Oct 2012 09:43:59 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEBA21F84D3 for ; Mon, 8 Oct 2012 09:43:59 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id EAD8E8A033 for ; Mon, 8 Oct 2012 16:43:55 +0000 (UTC) Date: Mon, 8 Oct 2012 12:44:26 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20121008164425.GA38933@mx1.yitter.info> References: <20121008134833.9AA9828EDD88@drugs.dv.isc.org> <20121008150411.BEA2928EE277@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Problem with draft-ietf-dnsext-dnssec-bis-updates-19 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 16:43:59 -0000 On Mon, Oct 08, 2012 at 04:55:57PM +0100, Ben Laurie wrote: > I agree that you can pedant away the need for any statement, I am just > suggesting that it would be nice to avoid any doubt or confusion by > saying something about it. It certainly confused me when I first read > it. Perhaps you could suggest text, because I'm still not clear on what problem you think there is or why it needs to be added. It appears you didn't remain confused, so what is the issue? A (as document shepherd) -- Andrew Sullivan ajs@anvilwalrusden.com From rafiee@hpi.uni-potsdam.de Mon Oct 8 13:15:44 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0354E21F86F7 for ; Mon, 8 Oct 2012 13:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdPyug+wwhoO for ; Mon, 8 Oct 2012 13:15:43 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 6D46C21F86F6 for ; Mon, 8 Oct 2012 13:15:42 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 171A7169E9B for ; Mon, 8 Oct 2012 22:15:37 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Mon, 8 Oct 2012 22:15:37 +0200 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" Date: Mon, 8 Oct 2012 22:15:33 +0200 Thread-Topic: [dnsext] draft-rafiee-cga-tsig-00 - call for more comments Thread-Index: Ac2lkN6YCNqEW9kdTEm8XD7GV2kI9A== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - call for more comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 20:15:44 -0000 More ideas and comments would be greatly apprecitated as I want to upload a= new version of my draft RFC in which I will incorporate applicable comment= s. -----Original Message----- From: Rafiee, Hosnieh=20 Sent: Thursday, October 04, 2012 9:28 AM To: 'Mark Andrews' Cc: dnsext@ietf.org Subject: RE: [dnsext] draft-rafiee-cga-tsig-00 - request for comments Thank you, I will change it and move the whole CGA-TSIG DATA inside the Other DATA. -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Thursday, October 04, 2012 9:15 AM To: Rafiee, Hosnieh Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments In message , "Rafiee, Hosnieh" writes: > Hello Mark, > Thank you for your comment. Yes can be,=3D20 But the reason is the TSIG= =20 > parsers need to be adapted with this new algori=3D thm and it is not=20 > different whether to put it in Other DATA or after Other =3D DATA field.= =20 > Because Other Data has variable length too like the CGA-TSIG DA=3D TA. > If I missed something please advise. It is different. Examine the behaviour of CGA-TSIG client talking to a non= CGA-TSIG aware server. The response to using a unknown algorithm should b= e BADKEY not FORMERR because the server couldn't parse the TSIG record. Mark > Thank you. > Hosnieh > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org]=3D20 > Sent: Thursday, October 04, 2012 8:45 AM > To: Rafiee, Hosnieh > Cc: dnsext@ietf.org > Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments >=20 >=20 > Why are the CGA parameters not part of other data? That field was=20 > added to=3D TSIG to hold stuff similar to CGA parameters. By making it= =20 > a seperate fie=3D ld you break all existing TSIG parsers. The CGA=20 > parameters could just be d=3D efined to be the initial part of other data= . >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jinmei@isc.org Mon Oct 8 22:31:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4BA21F8834 for ; Mon, 8 Oct 2012 22:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4n+JUS8EDjO for ; Mon, 8 Oct 2012 22:31:16 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id E586921F8832 for ; Mon, 8 Oct 2012 22:31:15 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 98E055F98B9; Tue, 9 Oct 2012 05:31:03 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C4E30216C7B; Tue, 9 Oct 2012 05:31:01 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Mon, 08 Oct 2012 22:30:53 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Olafur Gudmundsson In-Reply-To: <506F33DA.8000007@ogud.com> References: <506E31A6.5050605@ogud.com> <506F33DA.8000007@ogud.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: dnsext@ietf.org Subject: Re: [dnsext] type NSEC query at a parent's zone cut X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 05:31:16 -0000 At Fri, 05 Oct 2012 15:24:10 -0400, Olafur Gudmundsson wrote: > >> Based on the different behavior of nameservers that I have seen I use > >> >RFC4471 names to probe for NSEC records at delegations. > > Sorry, I'm afraid I don't understand this part...is it related to my > > question? > > If you want the NSEC record for foo.bar. asking for > foo!!!!!!!!!!!!!!!!!!!!.bar is likely to give you what you want :-) > > (! is the first displayable character in the ascii table but not a valid > hostname character) Ah, so this is about how a resolver (or any client in general) can get such an NSEC from an arbitrary implementation of authoritative server. This is a different topic from my original question (which is what the authoritative server should do), but thanks for the tip. Regarding my original question, based on the few responses I've seen, people seem to don't care and do accept the current inconsistent authoritative server behaviors as "de facto". --- JINMEI, Tatuya Internet Systems Consortium, Inc. From benl@google.com Tue Oct 9 03:40:30 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7CA21F889C for ; Tue, 9 Oct 2012 03:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Exnzxtz1VhdB for ; Tue, 9 Oct 2012 03:40:29 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD0D21F88A2 for ; Tue, 9 Oct 2012 03:40:29 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so3042136wgb.13 for ; Tue, 09 Oct 2012 03:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=QhrXBYwlEkqEiUbDpoHgu/zA1aMzlTLRjVEim3D1DC0=; b=OIZyQSgD/dtKGM+Iy6iyv7m0F49rmYOL7wtLD9SrWCjhdLUFtATgsAzRweKAAgtvci 44iKbhvBdtgGpGNqzF1Ze72Mi6tu1D9p+vwmhLfRHsYVxJkaMJnKkH3sobPA3xKvWl8j 02WwJmFQ9uUFKiUD0FnnwmhKBg+/N9s2SLa7AWbWwtxt5k+87ucXnawInhkMNqWzDd+0 lsS3eIAG0ALxt609N99ekjyLUbXd/C2wdwlsTSzgFAsjF9YxMAmbdysTt8dIYptDSrDu Is7o2lkPX6xLGgWi6ZbPQ4+Grwri3Nb36nzknVGYohSlXlj23wB+YhzWgYLFx141I91o viQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=QhrXBYwlEkqEiUbDpoHgu/zA1aMzlTLRjVEim3D1DC0=; b=RtxIaAAS8yA5pAt24hT0XaP1Ew362HqtQAJ5bBte+3fz3mBmiPHtczBqgupKqKkD/L gdVacsft5gm7G4PCB3GurE4ujzqnqoiGOsP81IHltxDt3F9uwpFNaFfCPYCjp/1Lwykw NYF4me93uHYRjQC11JhpJ+wcfyemdJ1FiG3WT7YoXYDIz2gw5HDT9Jy3/0TqfWb+W1QI WmWGGwYzDePM7CHJXhO0SEcNe86rkDf+9SF99XWahRTLkjjejLJaWi86t1xNLEBdQU09 SQIliGVCu+F27fYvVeh1pkNhjqWyO8r1e09aF4in6uKJuoKK3a9NIzgD4IbYV/9DtaeQ sbEw== MIME-Version: 1.0 Received: by 10.217.6.12 with SMTP id x12mr10803863wes.176.1349779228686; Tue, 09 Oct 2012 03:40:28 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Tue, 9 Oct 2012 03:40:28 -0700 (PDT) In-Reply-To: <20121008164425.GA38933@mx1.yitter.info> References: <20121008134833.9AA9828EDD88@drugs.dv.isc.org> <20121008150411.BEA2928EE277@drugs.dv.isc.org> <20121008164425.GA38933@mx1.yitter.info> Date: Tue, 9 Oct 2012 11:40:28 +0100 Message-ID: From: Ben Laurie To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl4a7qCp9A3w9DFME1+2RgpJbSURuz4m4QNwWu6jF5ay+JS+IdFcst8VIx/rhuClbY+EO9TypQOiKbmqFF7pjs9EwuE1opNY1aL7D5UJ1eJyxkOoD4t4dvFlTZClKqLOhO/uIaSxL6oXtShUisdPSYPQ01he0x/pUVadduWeawVB1FqN5ldAlUWpznaEFNBORsC9L94 Cc: dnsext@ietf.org Subject: Re: [dnsext] Problem with draft-ietf-dnsext-dnssec-bis-updates-19 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 10:40:30 -0000 On 8 October 2012 17:44, Andrew Sullivan wrote: > On Mon, Oct 08, 2012 at 04:55:57PM +0100, Ben Laurie wrote: >> I agree that you can pedant away the need for any statement, I am just >> suggesting that it would be nice to avoid any doubt or confusion by >> saying something about it. It certainly confused me when I first read >> it. > > Perhaps you could suggest text, because I'm still not clear on what > problem you think there is or why it needs to be added. It appears > you didn't remain confused, so what is the issue? The problem is that the text says "When canonicalizing DNS names (for both ordering and signing)". NSEC involves an ordering step, which this text appears to apply to. But it turns out not to. This wasted considerable time figuring out what was going on. So, one way to fix it could be to add: "Note that NSEC records contain names ordered according to their canonical form, even though they may appear in non-canonical form in the NSEC RR." IMO it would've been better to break those implementations that got this wrong, rather than introduce this confusion, but whatever. From rafiee@hpi.uni-potsdam.de Tue Oct 9 04:13:42 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1921F84F0; Tue, 9 Oct 2012 04:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNGaPDApEs1w; Tue, 9 Oct 2012 04:13:41 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id F349F21F84F1; Tue, 9 Oct 2012 04:13:38 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 6B774169E7B; Tue, 9 Oct 2012 13:13:33 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Tue, 9 Oct 2012 13:13:33 +0200 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" Date: Tue, 9 Oct 2012 13:13:32 +0200 Thread-Topic: [dnsext] draft-rafiee-cga-tsig-00 - call for more comments Thread-Index: Ac2lkN6YCNqEW9kdTEm8XD7GV2kI9AAfe1VA Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "DNSOP@ietf.org" , "Int-area@ietf.org" , "v6ops@ietf.org" , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - call for more comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:13:42 -0000 More ideas and comments would be greatly apprecitated as I want to upload a= new version of my draft RFC in which I will incorporate applicable comment= s. -----Original Message----- From: Rafiee, Hosnieh=20 Sent: Thursday, October 04, 2012 9:28 AM To: 'Mark Andrews' Cc: dnsext@ietf.org Subject: RE: [dnsext] draft-rafiee-cga-tsig-00 - request for comments Thank you, I will change it and move the whole CGA-TSIG DATA inside the Other DATA. -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Thursday, October 04, 2012 9:15 AM To: Rafiee, Hosnieh Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments In message , "Rafiee, Hosnieh" writes: > Hello Mark, > Thank you for your comment. Yes can be,=3D20 But the reason is the TSIG= =20 > parsers need to be adapted with this new algori=3D thm and it is not=20 > different whether to put it in Other DATA or after Other =3D DATA field.= =20 > Because Other Data has variable length too like the CGA-TSIG DA=3D TA. > If I missed something please advise. It is different. Examine the behaviour of CGA-TSIG client talking to a non= CGA-TSIG aware server. The response to using a unknown algorithm should b= e BADKEY not FORMERR because the server couldn't parse the TSIG record. Mark > Thank you. > Hosnieh > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org]=3D20 > Sent: Thursday, October 04, 2012 8:45 AM > To: Rafiee, Hosnieh > Cc: dnsext@ietf.org > Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments >=20 >=20 > Why are the CGA parameters not part of other data? That field was=20 > added to=3D TSIG to hold stuff similar to CGA parameters. By making it= =20 > a seperate fie=3D ld you break all existing TSIG parsers. The CGA=20 > parameters could just be d=3D efined to be the initial part of other data= . >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From internet-drafts@ietf.org Sat Oct 13 16:59:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFB921F847B; Sat, 13 Oct 2012 16:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeOMS1wdWDBE; Sat, 13 Oct 2012 16:59:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BEB21F8471; Sat, 13 Oct 2012 16:59:39 -0700 (PDT) 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.34 Message-ID: <20121013235939.12808.64470.idtracker@ietfa.amsl.com> Date: Sat, 13 Oct 2012 16:59:39 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-05.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 23:59:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) IANA Considerations Author(s) : Donald E. Eastlake Filename : draft-ietf-dnsext-rfc6195bis-05.txt Pages : 22 Date : 2012-10-13 Abstract: This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsext-rfc6195bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-rfc6195bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rafiee@hpi.uni-potsdam.de Tue Oct 16 03:26:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEB721F871D; Tue, 16 Oct 2012 03:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWab2aF8vXyW; Tue, 16 Oct 2012 03:26:23 -0700 (PDT) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id CDD0721F8700; Tue, 16 Oct 2012 03:26:22 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id F370CD2C9A; Tue, 16 Oct 2012 12:26:20 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Tue, 16 Oct 2012 12:26:20 +0200 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" , "int-area@ietf.org" Date: Tue, 16 Oct 2012 12:26:20 +0200 Thread-Topic: New Version Notification for draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2riK8aBEOBC++rS/u1w0cFMfAWRQ== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D44652B98MXMA1Rhpiuni_" MIME-Version: 1.0 Subject: [dnsext] New Version Notification for draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 10:26:25 -0000 --_000_EA738325B0580041A50A364F5F76B68924D44652B98MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Our new version of cga-tsig is available. Please review and share your comm= ents with us. http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-00.txt In this version: - We moved the CGA-TSIG DATA into the Other DATA field to improve = it (Regarding the comment received) - We explained the situation where a host does not support CGA-TSI= G algorithm Thank you H. R. --_000_EA738325B0580041A50A364F5F76B68924D44652B98MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Our new version = of cga-tsig is available. Please review and share your comments with us.

  http://www.ietf.org/inter= net-drafts/draft-rafiee-intarea-cga-tsig-00.txt

 

In this version:

-     &nb= sp;    We mov= ed the CGA-TSIG DATA into the Other DATA field to improve it (Regarding the= comment received)

-  = ;        We explained the situation where a host does not support CG= A-TSIG algorithm

 

Thank you

H. R.<= /o:p>

 

 

= --_000_EA738325B0580041A50A364F5F76B68924D44652B98MXMA1Rhpiuni_-- From lubos.slovak@nic.cz Wed Oct 17 00:55:04 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0D521F8771 for ; Wed, 17 Oct 2012 00:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpMBZ3ipMcHq for ; Wed, 17 Oct 2012 00:55:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BA91021F8783 for ; Wed, 17 Oct 2012 00:55:03 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:222:19ff:fe31:432a] (unknown [IPv6:2001:1488:ac14:1400:222:19ff:fe31:432a]) by mail.nic.cz (Postfix) with ESMTPSA id 09F8F13F701 for ; Wed, 17 Oct 2012 09:55:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1350460501; bh=Ecb6MyafeL9z6R3A42VhXbfY2oBke+V4tO4yjO/xH+8=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=ZGUBkKTITK+4Cz30LgRHXckK2bzzvnaHIuqSP7i5Qa2ceRemT0yeX39KEA2ron/5X yjIjKiAlrX99o3FZ5JmMA3xwUA+J/3dB6lciQvL6xipTCS/kk/daZhnLEaIiix+ku4 8O6Sz7tIny5kSgg2tMKQX+/4dmiPhxSTK4/POdKs= Message-ID: <507E6454.9030400@nic.cz> Date: Wed, 17 Oct 2012 09:55:00 +0200 From: Lubos Slovak User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dnsext] DDNS - multi-packet? + SERIAL autoincrement X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 07:55:04 -0000 Hello, we're currently implementing Dynamic Updates into Knot DNS and I still wonder about two things: 1) Is it possible that the update is divided into multiple DNS packets, similarly as AXFR/IXFR? If so, what is the format? Should there be all Prerequisities first (in one or more packets) and all Update RRs afterwards (in another one or more packets), or each DNS packet may contain both the Prerequisities section and the Update section and the server should wait for the last packet before it starts to process it in any way? I found no clue about this in the RFC. 2) Section 3.2 of RFC 2136 gives quite a lot of options when to autoincrement SERIAL if it was not updated by the operation. However, it seems to me, that implementing anything other than option (1) (incrementing after each update operation) is too much hassle with little effect. Does someone know how it is implemented in other servers? Thanks a lot, Lubos -- ĽuboÅ¡ Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak@nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org From miekg@atoom.net Wed Oct 17 01:26:57 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A2A21F857D for ; Wed, 17 Oct 2012 01:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPc9FUdv6eul for ; Wed, 17 Oct 2012 01:26:56 -0700 (PDT) Received: from elektron.atoom.net (elektron.atoom.net [85.223.71.124]) by ietfa.amsl.com (Postfix) with ESMTP id 4C84721F877C for ; Wed, 17 Oct 2012 01:26:56 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 3CA21401BD; Wed, 17 Oct 2012 10:26:55 +0200 (CEST) Date: Wed, 17 Oct 2012 10:26:55 +0200 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20121017082655.GC4603@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <507E6454.9030400@nic.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8w3uRX/HFJGApMzv" Content-Disposition: inline In-Reply-To: <507E6454.9030400@nic.cz> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] DDNS - multi-packet? + SERIAL autoincrement X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 08:26:57 -0000 --8w3uRX/HFJGApMzv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "[dnsext] DDNS - multi-packet? + SER..."= ] > Hello, >=20 > we're currently implementing Dynamic Updates into Knot DNS and I > still wonder about two things: >=20 > 1) Is it possible that the update is divided into multiple DNS > packets, similarly as AXFR/IXFR? If so, what is the format? Should What text in 2136 makes you want to ask this question? Regards, --=20 Miek Gieben http://mi= ek.nl --8w3uRX/HFJGApMzv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlB+a88ACgkQJYuFzziA0PZhBACgpb8i4DKzc3pxTd8Pyvxg6LSl DY4AniN/ZguB93a2vELRr3K5ku3S8UmO =2Dwo -----END PGP SIGNATURE----- --8w3uRX/HFJGApMzv-- From lubos.slovak@nic.cz Wed Oct 17 01:31:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5A421F87A4 for ; Wed, 17 Oct 2012 01:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMMjKDT9oDhe for ; Wed, 17 Oct 2012 01:31:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D85AA21F87B8 for ; Wed, 17 Oct 2012 01:31:11 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:222:19ff:fe31:432a] (unknown [IPv6:2001:1488:ac14:1400:222:19ff:fe31:432a]) by mail.nic.cz (Postfix) with ESMTPSA id 3CF4F14104A for ; Wed, 17 Oct 2012 10:31:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1350462671; bh=IdwFqknrhEuI+qXEz7qhvEN0LshafYuOw6F+F+63A3A=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=NI4KEnr1wW6DQ2+QRU5cPbn3RYELUwsv85Q076vaKIoL2b1EjEaFH8zVd3qC+O0ke YU7njf/piVwaYFFMJkNEzeigSB6bebUzXVjtIo2kxu0fEm6W+Y8E4SXE34Y9mGD3cQ ZzqTRAPP4RqDKD3IdVseoJVWMakcavWZcYGd+e6o= Message-ID: <507E6CCF.9020607@nic.cz> Date: Wed, 17 Oct 2012 10:31:11 +0200 From: Lubos Slovak User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <507E6454.9030400@nic.cz> <20121017082655.GC4603@miek.nl> In-Reply-To: <20121017082655.GC4603@miek.nl> Content-Type: multipart/alternative; boundary="------------000107070500040708000708" X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dnsext] DDNS - multi-packet? + SERIAL autoincrement X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 08:31:13 -0000 This is a multi-part message in MIME format. --------------000107070500040708000708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit None at all, but there is also none that would forbid such behaviour. And the old RFCs are often very unclear on what can or cannot be done. On 10/17/2012 10:26 AM, Miek Gieben wrote: > [ Quoting in "[dnsext] DDNS - multi-packet? + SER..." ] >> Hello, >> >> we're currently implementing Dynamic Updates into Knot DNS and I >> still wonder about two things: >> >> 1) Is it possible that the update is divided into multiple DNS >> packets, similarly as AXFR/IXFR? If so, what is the format? Should > What text in 2136 makes you want to ask this question? > > Regards, > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- L(ubos( Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak@nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org --------------000107070500040708000708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit None at all, but there is also none that would forbid such behaviour. And the old RFCs are often very unclear on what can or cannot be done.

On 10/17/2012 10:26 AM, Miek Gieben wrote: 
[ Quoting <lubos.slovak@nic.cz> in "[dnsext] DDNS - multi-packet? + SER..." ]

Hello,

we're currently implementing Dynamic Updates into Knot DNS and I
still wonder about two things:

1) Is it possible that the update is divided into multiple DNS
packets, similarly as AXFR/IXFR? If so, what is the format? Should

What text in 2136 makes you want to ask this question?

 Regards,




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


-- 
 Ľuboš Slovák                       Knot DNS
 CZ.NIC Labs          http://www.knot-dns.cz
 -------------------------------------------
 Americká 23, 120 00 Praha 2, Czech Republic

 Email: lubos.slovak@nic.cz
 WWW: http://labs.nic.cz   http://www.nic.cz
 -------------------------------------------

 Please consider the environment before printing this email.
 Join the campaign at http://thinkBeforePrinting.org
--------------000107070500040708000708-- From kcd@chrysler.com Wed Oct 17 08:20:12 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE3721F856D for ; Wed, 17 Oct 2012 08:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I--SvTBeLIYh for ; Wed, 17 Oct 2012 08:20:11 -0700 (PDT) Received: from odbmap01.extra.chrysler.com (odbmap01.out.extra.chrysler.com [129.9.40.25]) by ietfa.amsl.com (Postfix) with ESMTP id 911A721F8567 for ; Wed, 17 Oct 2012 08:20:10 -0700 (PDT) Received: from odbmap04.oddc.chrysler.com (Unknown_Domain [53.28.32.58]) by odbmap01.extra.chrysler.com (Symantec Messaging Gateway) with SMTP id 17.66.02940.9ACCE705; Wed, 17 Oct 2012 11:20:09 -0400 (EDT) X-AuditID: 81092818-b7f8a6d000000b7c-24-507ecca9cffd Received: from shmsp070.shdc.chrysler.com (shmsp070.shdc.chrysler.com [53.231.161.247]) by odbmap04.oddc.chrysler.com (Symantec Messaging Gateway) with SMTP id 7E.96.15188.8ACCE705; Wed, 17 Oct 2012 11:20:08 -0400 (EDT) Received: from [10.143.0.242] (CITMNCNU1410TPT.cg.chrysler.com [10.143.0.242]) by shmsp070.shdc.chrysler.com (8.13.8+Sun/8.13.8/chrysler-relay-1.4-kcd) with ESMTP id q9HFK8tr020804 for ; Wed, 17 Oct 2012 11:20:08 -0400 (EDT) Message-ID: <507ECCA3.9080400@chrysler.com> Date: Wed, 17 Oct 2012 11:20:03 -0400 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <507E6454.9030400@nic.cz> In-Reply-To: <507E6454.9030400@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA12TfUgTYRzHe7Y5b+Zjt1tuj1PTjoxezUJFe8MMQihiEURFZLftcsup426X iihmarEgqj8CJUvF0qw0q2VlIVlEmmJvEEivEkVGUPRChr08z7bTW//97vP9Pc/39/veHaVm uikz5Sz08EIh52K1EZq0uMTli88OVlhSvnWBjJ6q0bAskNPSMq6ygO0RK+28y7mXF5as3hXh aBu+qnU3R5d0HM+uBDdoL9BRiE5Ffy98DQvURvTwZaeW1Aw9DNDQ9US559ivcxoviMD8BUAN dZ2qwMN3gO79qVKTLkgvRE2XT+IuitLQSai3w2+gpeegGyOt4aSOprej049ehwfa9ai/7q2/ fSZtQAdrTAQb6DXo4/lBEJghCZ0YOqMitY6ei3z3n/m5mk5HXp83WCeg7k8n1GQcRB8KR1ea m7RHAFOvsKhXnKlXnGkE6nYQW2S3FnDulKXJfIlH4JJtDqFUdPFCsq2o4BLA8e7TzUPXwGgD 7AP5lIqNhnf6KyxMlLXIXurgREeuILl4kZ0JqQcYw0lslVz5rBlqCTVM0kK+GF/uwS+PnQXj mXILY5rUREl0O23OIknMlQRXH4ilNKwJTmvcYWHoPM7D5/O8mxcCfn2gmKJYBCvJ9XqBz+NL djtdHlnG53wDWKGVin+ieHgqCwtGpaAYajYstmLZrJT/n0tF6fpAHhWJdy4hJlB0cwWiMy9o bYA3CY2Uqd82BnYQyMhQYRkPa0gORlkKtRsApWYTtJI1adLhkAontzQbYb4dCzMUAnEzx0Gd DfNoBZ8yNCdCDVFjFGqop/xTjQEbBfA+ZcQ9Ev9yU0sysI3sMz0I/Tsi6CFfhj7IFCvGQePN MjxPUAl1G8NZqnCW3p4ykqWH8yiz3EYORso0mOUGAhkZhmS5iUhGWQp1MlcCVn/48brRP783 vpkftW8Hs+32BFy0qrl2T3vq0y3F4zlp1Qe6pajMJz9T3p/pv5aWvrZxT60vcyRXWpwRW/3u g/T8c3mvaslIjarH0GJ/lXKL2S8mVM3u1if8bn199Htp14CpbuLc4OYvOxNXlN3tfezbenE8 e+879Ysfy9bbm8faY5JYjejgli5QCyL3D1yp28bKBAAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAIsWRmVeSWpSXmKPExsVi+nzhd90VZ+oCDNbsMLfY3fSI1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGSvOb2MrWCRasW6aUwPjLoEuRk4OCQETiUm/VrNA2GISF+6t Z+ti5OIQErjLKDF35nomCOcro8Sxf03MIFW8AtoSCzfPA+rg4GARUJXYvw5sEJuAisSuW8vZ QWxRgSiJpRcfsEOUC0qcnPkErFxEQFiio1UcJCws4Cjxes0ZRhBbCGjKnLPLmEBsTgE1ia0n roPFmQXMJLq2dkHZ8hLb385hnsDIPwvJ1FlIymYhKVvAyLyKUSo/JSk3scDARC8/JSVZLzmj qLI4J7VILzk/dxMjKOBkFCx3MM69IX+IUYCDUYmHNzKpLkCINbGsuDL3EKMkB5OSKO/hk0Ah vqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwty4ByvCmJlVWpRfkwKWkOFiVxXpdDpQFCAumJJanZ qakFqUUwWRkODiUJXo/TQI2CRanpqRVpmTklCGkmDk6Q4TxAwytOgQwvLkjMLc5Mh8ifYlSU EudNAmkWAElklObB9cISwitGcaBXhHkdQKp4gMkErvsV0GAmoMFdu6tBBpckIqSkGhg1+88q ubtM0Jwaey6H8/WN5PW77slfY1+RGaFtYvm5I618uZFD7e0ZTCod5zzK1vFZC+UYt9WdeqJQ tOPE5QdP3t+3WSUd/TbX6u2fLQ8XfODsnW0pdHb1xIX3Y1n8NN59lqgNOL/FqnxPzXILzcMK fFHOM2a3Knb+fpdb+e9rad/uSxvP3OxUYinOSDTUYi4qTgQABl9kOOMCAAA= Subject: Re: [dnsext] DDNS - multi-packet? + SERIAL autoincrement X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:20:12 -0000 Dude, The RFC says "An update transaction may be carried in a UDP datagram, if the request fits, or in a TCP connection (at the discretion of the requestor). When TCP is used, the message is in the format described in [RFC1035 4.2.2].". "A" is singular. So there is no such thing as a Dynamic Update in multiple UDP packets. As for TCP, if you follow the reference to RFC 1035, you see that a stream of data is presented to the server. Once you're dealing with a connection-oriented transport, packet boundaries don't matter any more. Or, to put it another way, the algorithm reads as much of the input stream as it needs to process. If there isn't enough data yet, it waits for more. How this is handled at the packet level is not the concern of the Dynamic Update processing algorithm. If the algorithm tries to read data from the stream, and the end of the stream is reached, then the algorithm detects that and processes what it has. If there's an error, it detects that too. Reading from a stream socket is not that much different from reading from a file. On Unix platforms, at least, the whole "socket" concept was and is part of the abstraction of "files". One of the downsides of incrementing serial for every operation, is that if you do thousands of operations a second, you could end up wrapping within an EXPIRE interval, which might cause problems for traditional master/slave replication (sometimes slaves can't talk to their master for an extended periods of time, so EXPIRE is the worst-case scenario for serial wrap, not REFRESH). - Kevin On 10/17/2012 3:55 AM, Lubos Slovak wrote: > Hello, > > we're currently implementing Dynamic Updates into Knot DNS and I still > wonder about two things: > > 1) Is it possible that the update is divided into multiple DNS > packets, similarly as AXFR/IXFR? If so, what is the format? Should > there be all Prerequisities first (in one or more packets) and all > Update RRs afterwards (in another one or more packets), or each DNS > packet may contain both the Prerequisities section and the Update > section and the server should wait for the last packet before it > starts to process it in any way? I found no clue about this in the RFC. > > 2) Section 3.2 of RFC 2136 gives quite a lot of options when to > autoincrement SERIAL if it was not updated by the operation. However, > it seems to me, that implementing anything other than option (1) > (incrementing after each update operation) is too much hassle with > little effect. Does someone know how it is implemented in other servers? > > Thanks a lot, > Lubos > From lubos.slovak@nic.cz Wed Oct 17 08:36:28 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE4121F86C5 for ; Wed, 17 Oct 2012 08:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqq4F9cXyDGG for ; Wed, 17 Oct 2012 08:36:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 289FC21F85D5 for ; Wed, 17 Oct 2012 08:36:24 -0700 (PDT) Received: from [195.113.93.57] (b57.eduroam.cuni.cz [195.113.93.57]) by mail.nic.cz (Postfix) with ESMTPSA id 3D63813F701 for ; Wed, 17 Oct 2012 17:36:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1350488183; bh=J9VUsOEuNGdwtZP2AMX+mH/GZmV7sAjlPl1pML6qjbU=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bmCV0GHEGdqugYNAWLXfj0Tq/tO14aoFClo4xT+Pe4M99qEO5HFsF8YqFnRgpPO2O RKZmwO1LCI8iFcMcSvWLfBgsJ04poKatlZDdsAh32NiQEAojCLcB9IFlppIfl0Bn/x 0Xa3fNAZ/Y/G6e1gOBS4/BrIRMk3lH/F94CPSrCc= Message-ID: <507ED07A.4040209@nic.cz> Date: Wed, 17 Oct 2012 17:36:26 +0200 From: Lubos Slovak User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: dnsext@ietf.org References: <507E6454.9030400@nic.cz> <507ECCA3.9080400@chrysler.com> In-Reply-To: <507ECCA3.9080400@chrysler.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dnsext] DDNS - multi-packet? + SERIAL autoincrement X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:36:28 -0000 On 17-Oct-12 17:20, Kevin Darcy wrote: > Dude, > The RFC says "An update transaction may be carried in a UDP datagram, > if the request fits, or in a TCP connection (at the discretion of the > requestor). When TCP is used, the message is in the format described > in [RFC1035 4.2.2].". "A" is singular. So there is no such thing as a > Dynamic Update in multiple UDP packets. I thought so, just want to be sure. I did not consider the indefinite article a proper indicator. > As for TCP, if you follow the reference to RFC 1035, you see that a > stream of data is presented to the server. Once you're dealing with a > connection-oriented transport, packet boundaries don't matter any more. They do, indeed - the two-byte length field limits the DNS packet to 64k. That's why large A-/IXFR comes in more DNS packets (though in one data stream). The transport protocol does not bother me at all, it's the DNS packets that do. > Or, to put it another way, the algorithm reads as much of the input > stream as it needs to process. If there isn't enough data yet, it > waits for more. How this is handled at the packet level is not the > concern of the Dynamic Update processing algorithm. If the algorithm > tries to read data from the stream, and the end of the stream is > reached, then the algorithm detects that and processes what it has. If > there's an error, it detects that too. Reading from a stream socket is > not that much different from reading from a file. On Unix platforms, > at least, the whole "socket" concept was and is part of the > abstraction of "files". > > One of the downsides of incrementing serial for every operation, is > that if you do thousands of operations a second, you could end up > wrapping within an EXPIRE interval, which might cause problems for > traditional master/slave replication (sometimes slaves can't talk to > their master for an extended periods of time, so EXPIRE is the > worst-case scenario for serial wrap, not REFRESH). OK, will consider that. > > - Kevin > > On 10/17/2012 3:55 AM, Lubos Slovak wrote: >> Hello, >> >> we're currently implementing Dynamic Updates into Knot DNS and I >> still wonder about two things: >> >> 1) Is it possible that the update is divided into multiple DNS >> packets, similarly as AXFR/IXFR? If so, what is the format? Should >> there be all Prerequisities first (in one or more packets) and all >> Update RRs afterwards (in another one or more packets), or each DNS >> packet may contain both the Prerequisities section and the Update >> section and the server should wait for the last packet before it >> starts to process it in any way? I found no clue about this in the RFC. >> >> 2) Section 3.2 of RFC 2136 gives quite a lot of options when to >> autoincrement SERIAL if it was not updated by the operation. However, >> it seems to me, that implementing anything other than option (1) >> (incrementing after each update operation) is too much hassle with >> little effect. Does someone know how it is implemented in other servers? >> >> Thanks a lot, >> Lubos >> > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak@nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org From fanf2@hermes.cam.ac.uk Wed Oct 17 08:46:48 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3FB21F860E for ; Wed, 17 Oct 2012 08:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.007 X-Spam-Level: X-Spam-Status: No, score=-6.007 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJrpY2tJhXTO for ; Wed, 17 Oct 2012 08:46:47 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE9D21F85F4 for ; Wed, 17 Oct 2012 08:46:47 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53378) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1TOVpW-0006eM-Qe (Exim 4.72) (return-path ); Wed, 17 Oct 2012 16:46:46 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TOVpW-0003I4-7k (Exim 4.72) (return-path ); Wed, 17 Oct 2012 16:46:46 +0100 Date: Wed, 17 Oct 2012 16:46:46 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Lubos Slovak In-Reply-To: <507ED07A.4040209@nic.cz> Message-ID: References: <507E6454.9030400@nic.cz> <507ECCA3.9080400@chrysler.com> <507ED07A.4040209@nic.cz> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] DDNS - multi-packet? + SERIAL autoincrement X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:46:48 -0000 Lubos Slovak wrote: > They do, indeed - the two-byte length field limits the DNS packet to > 64k. That's why large A-/IXFR comes in more DNS packets (though in one > data stream). The transport protocol does not bother me at all, it's the > DNS packets that do. It is best to call them "DNS messages" which makes it more clear that you are not talking about TCP segments or UDP datagrams or IP fragments. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From lubos.slovak@nic.cz Wed Oct 17 08:56:38 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674B821F867A for ; Wed, 17 Oct 2012 08:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5C-pVmKAK6X for ; Wed, 17 Oct 2012 08:56:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE4721F865C for ; Wed, 17 Oct 2012 08:56:37 -0700 (PDT) Received: from [195.113.93.57] (b57.eduroam.cuni.cz [195.113.93.57]) by mail.nic.cz (Postfix) with ESMTPSA id 36BCE13F701; Wed, 17 Oct 2012 17:56:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1350489396; bh=C7eMbo/fAzkNq2uvvpR1GUgOMqmQQgnKqFlLthg3vV4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Mo689U7VMg+nqBH04V1KwMkobzHHv9MtC5Ds7m5M8VnF5qd05TA1vVN/2swsd4s7O pr9WjWXEknAWOi+lUjAXv6lhke4b80dwgbK6fxsGz9K4dNivJxlT9c8ArCYUECtZf4 QHZp7oaq9SfF1EjK0toYPb4P/mXdqd2m+QkMMXvk= Message-ID: <507ED536.5050005@nic.cz> Date: Wed, 17 Oct 2012 17:56:38 +0200 From: Lubos Slovak User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Tony Finch References: <507E6454.9030400@nic.cz> <507ECCA3.9080400@chrysler.com> <507ED07A.4040209@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dnsext@ietf.org Subject: Re: [dnsext] DDNS - multi-packet? + SERIAL autoincrement X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:56:38 -0000 Right, sorry for that! So the question stands: Is it possible for an UPDATE operation to be larger than 64k and thus divided into more DNS messages, when sent over TCP? If so, what's the format (see my first post)? Lubos On 17-Oct-12 17:46, Tony Finch wrote: > Lubos Slovak wrote: > > >> They do, indeed - the two-byte length field limits the DNS packet to >> 64k. That's why large A-/IXFR comes in more DNS packets (though in one >> data stream). The transport protocol does not bother me at all, it's the >> DNS packets that do. >> > It is best to call them "DNS messages" which makes it more clear that you > are not talking about TCP segments or UDP datagrams or IP fragments. > > Tony. > -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak@nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org From fanf2@hermes.cam.ac.uk Wed Oct 17 09:19:52 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991AB21F85A1 for ; Wed, 17 Oct 2012 09:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.035 X-Spam-Level: X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfI2ObFutFmo for ; Wed, 17 Oct 2012 09:19:51 -0700 (PDT) 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 BB34B21F859C for ; Wed, 17 Oct 2012 09:19:51 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:49438) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1TOWLW-0001La-XD (Exim 4.72) (return-path ); Wed, 17 Oct 2012 17:19:50 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TOWLW-00085C-8l (Exim 4.72) (return-path ); Wed, 17 Oct 2012 17:19:50 +0100 Date: Wed, 17 Oct 2012 17:19:50 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Lubos Slovak In-Reply-To: <507ED536.5050005@nic.cz> Message-ID: References: <507E6454.9030400@nic.cz> <507ECCA3.9080400@chrysler.com> <507ED07A.4040209@nic.cz> <507ED536.5050005@nic.cz> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] DDNS - multi-packet? + SERIAL autoincrement X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 16:19:52 -0000 Lubos Slovak wrote: > > Is it possible for an UPDATE operation to be larger than 64k and thus divided > into more DNS messages, when sent over TCP? No :-) (The obvious consequence is that you have to do some kind of higher-level hack to split very large updates into separate operations, and multiple updates are not atomic in the way that individual ones are.) Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From lubos.slovak@nic.cz Wed Oct 17 13:45:03 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA1321F8700 for ; Wed, 17 Oct 2012 13:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQE7ImxGRalx for ; Wed, 17 Oct 2012 13:45:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B73F221F86FE for ; Wed, 17 Oct 2012 13:45:02 -0700 (PDT) Received: from [192.168.0.103] (ip-213-220-224-170.net.upcbroadband.cz [213.220.224.170]) by mail.nic.cz (Postfix) with ESMTPSA id F3AD713F701; Wed, 17 Oct 2012 22:45:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1350506701; bh=m3H5J3i0S37igbRqMiQ43H0/SODllb4nasxH2IAJaMk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KvQxXwC8qNkGoilOkC9PF6aLAncn0WbLQmJaUff2T9OBXmNAfkGURB3Pbf4O9XDFn qNJuC0QpZXwUUncp1lUSHczVm3tbgttzMA3uDWCGrM7A0OKRihnXlHcJ3zeBTHrhIU u15k+aNZQgjE8jdC91FtbzrYJI6aefzriMo6IYEg= Message-ID: <507F18CF.4030207@nic.cz> Date: Wed, 17 Oct 2012 22:45:03 +0200 From: Lubos Slovak User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Tony Finch References: <507E6454.9030400@nic.cz> <507ECCA3.9080400@chrysler.com> <507ED07A.4040209@nic.cz> <507ED536.5050005@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dnsext@ietf.org Subject: Re: [dnsext] DDNS - multi-packet? + SERIAL autoincrement X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:45:03 -0000 Very well, thanks for all responses! Lubos On 17-Oct-12 18:19, Tony Finch wrote: > Lubos Slovak wrote: > >> Is it possible for an UPDATE operation to be larger than 64k and thus divided >> into more DNS messages, when sent over TCP? >> > No :-) > > (The obvious consequence is that you have to do some kind of higher-level > hack to split very large updates into separate operations, and multiple > updates are not atomic in the way that individual ones are.) > > Tony. > -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak@nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org From msheldon@godaddy.com Thu Oct 18 13:47:07 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D038C21F8648 for ; Thu, 18 Oct 2012 13:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwuyDknNp2Vh for ; Thu, 18 Oct 2012 13:47:07 -0700 (PDT) Received: from smtpoutwbe10.prod.mesa1.secureserver.net (smtpoutwbe10.prod.mesa1.secureserver.net [208.109.78.26]) by ietfa.amsl.com (Postfix) with ESMTP id 30BA421F8501 for ; Thu, 18 Oct 2012 13:47:07 -0700 (PDT) Received: from gem-wbe37.prod.mesa1.secureserver.net ([64.202.189.51]) by smtpoutwbe10.prod.mesa1.secureserver.net with bizsmtp id Ckn11k00116ysEw01kn1Ew; Thu, 18 Oct 2012 13:47:01 -0700 Received: (qmail 13166 invoked by uid 99); 18 Oct 2012 20:47:01 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 172.19.38.144 User-Agent: Workspace Webmail 5.6.26 Message-Id: <20121018134700.205a61dff9fc1684c258b274662bb912.cffff531f1.wbe@email00.secureserver.net> From: "Michael Sheldon" To: dnsext@ietf.org Date: Thu, 18 Oct 2012 13:47:00 -0700 Mime-Version: 1.0 Subject: [dnsext] IXFR over UDP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 20:47:07 -0000 RFC 1995 says that servers *may* respond to IXFR via UDP.=0A=0AAre there an= y server implementations out there that actually do? BIND=0Aapparently does= not.=0A=0AWith EDNS0, it would seem that many IXFR responses would easily = fit in a=0AUDP packet.=0A=0AMichael Sheldon=0ADev-DNS Services=0AGoDaddy.co= m=0A From matthijs@nlnetlabs.nl Fri Oct 19 01:05:50 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D588821F88C4 for ; Fri, 19 Oct 2012 01:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpmPodVMMyhB for ; Fri, 19 Oct 2012 01:05:49 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F7F21F8825 for ; Fri, 19 Oct 2012 01:05:48 -0700 (PDT) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q9J85XBa013336 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 10:05:34 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q9J85XBa013336 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1350633937; bh=rML9pDrITJJObrqPap5mxi+DZi+mXypjYS/j0QTT3UY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=xaNFlfNeGE+GCi9wwy5J/N3XzcUwvHIUB/RFqL0O+O5dLAdkwxl9KgaCyKagjENVY +TP0kN8sOTWr0niFRmlDy7ltFQpWT9LW9v9YB/jSkzj7l9AxY+9YWnfN93/ewhZXg5 zwtwmevTPsK9ID7Tc56LXUqJfmyk2P90feajlPvk= Message-ID: <508109D1.5050306@nlnetlabs.nl> Date: Fri, 19 Oct 2012 10:05:37 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Michael Sheldon References: <20121018134700.205a61dff9fc1684c258b274662bb912.cffff531f1.wbe@email00.secureserver.net> In-Reply-To: <20121018134700.205a61dff9fc1684c258b274662bb912.cffff531f1.wbe@email00.secureserver.net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Fri, 19 Oct 2012 10:05:34 +0200 (CEST) Cc: dnsext@ietf.org Subject: Re: [dnsext] IXFR over UDP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 08:05:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NSD will try to do IXFR over TCP by default. You can configure to allow UDP. In the zone settings of the configuration file, use: request-xfr: UDP OpenDNSSEC 1.4 will try to do IXFR over UDP first. Best regards, Matthijs On 10/18/2012 10:47 PM, Michael Sheldon wrote: > RFC 1995 says that servers *may* respond to IXFR via UDP. > > Are there any server implementations out there that actually do? > BIND apparently does not. > > With EDNS0, it would seem that many IXFR responses would easily fit > in a UDP packet. > > Michael Sheldon Dev-DNS Services GoDaddy.com > > _______________________________________________ dnsext mailing > list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQgQnRAAoJEA8yVCPsQCW5mVgH/3W+jZf6knXabRMQ/j/T5V/C jgyByVf+rF5vjmJfOBzzfUJ2l2B8ohf4l+dDVsxb9UhlcjYnx6zPp0w998tl5JHH MefUKQ+0dtUfmUhVwq7xta1GhQB9FGjNyLf/D7c6u8lkFDWSOdgEoZz9tGxxV7wY 1cRRgmZuhOR48ruvU0pVdH2JbldNbl2Taz9I4EC167JJc8OXQwASxd+M40dCLAKT Vg9UKJj46L7tPsafMTjP4LZOBUnLaXFGBwhDR819OwphldkcL8hNPiSCCsT+mX2Q jJJGgD9HSA+/vxNrJiro/sZd+Xcp9is1WHKH1rEQ97lIDqTvjrF1gJd3SpCeOVU= =oJMo -----END PGP SIGNATURE----- From rafiee@hpi.uni-potsdam.de Tue Oct 23 08:06:46 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9CA11E80CC; Tue, 23 Oct 2012 08:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EOT5aRJwt9V; Tue, 23 Oct 2012 08:06:46 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 0973311E80C5; Tue, 23 Oct 2012 08:06:46 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 16118169E73; Tue, 23 Oct 2012 17:06:43 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Tue, 23 Oct 2012 17:06:42 +0200 From: "Rafiee, Hosnieh" To: "Int-area@ietf.org" Date: Tue, 23 Oct 2012 17:06:42 +0200 Thread-Topic: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2rFSiGjyyz01Y/QQq74El/UneB+gFbhdAw Message-ID: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> In-Reply-To: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:06:46 -0000 SGVsbG8sDQoNClRoaXMgaXMgb3VyICJsYXN0IGNhbGwiIHJlcXVlc3QgZm9yIGNvbW1lbnRzIGNv bmNlcm5pbmcgb3VyIGRyYWZ0LCBSRkMgIkNHQS1UU0lHIi4gSWYgeW91IGZlZWwgc28gaW5jbGlu ZWQsIHBsZWFzZSBmZWVsIGZyZWUgdG8gY29tbWVudCBvbiBpdC4gQW55IGFuZCBhbGwgY29tbWVu dHMgYXJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQpUaGFuayB5b3UsDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1y YWZpZWUtaW50YXJlYS1jZ2EtdHNpZy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgSG9zbmllaCBSYWZpZWUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5 Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXJhZmllZS1pbnRhcmVhLWNnYS10c2lnDQpSZXZpc2lvbjoJ IDAwDQpUaXRsZToJCSBUcmFuc2FjdGlvbiBTSUduYXR1cmUgKFRTSUcpIHVzaW5nIENHQSBBbGdv cml0aG0gaW4gSVB2Ng0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMTAtMTUNCldHIElEOgkJIEluZGl2 aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMw0KVVJMOiAgICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yYWZpZWUtaW50YXJlYS1j Z2EtdHNpZy0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1yYWZpZWUtaW50YXJlYS1jZ2EtdHNpZw0KSHRtbGl6ZWQ6ICAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yYWZpZWUtaW50YXJlYS1jZ2EtdHNpZy0w MA0KDQoNCkFic3RyYWN0Og0KICAgVGhlIGZpcnN0IHN0ZXAgb2YgVHJhbnNhY3Rpb24gU0lHbmF0 dXJlIChUU0lHKSAoUkZDIDI4NDUpIGlzIHRvDQogICBnZW5lcmF0ZSBhIHNoYXJlZCBzZWNyZXQg YW5kIGV4Y2hhbmdlIGl0IG1hbnVhbGx5IGJldHdlZW4gYSBETlMNCiAgIHNlcnZlciBhbmQgYSBo b3N0LiBUaGlzIGRvY3VtZW50LCBDR0EtVFNJRywgcHJvcG9zZXMgYSBwb3NzaWJsZSB3YXkNCiAg IHRvIGF1dG9tYXRlIHRoZSBub3cgbWFudWFsIHByb2Nlc3MgZm9yIHRoZSBhdXRoZW50aWNhdGlv biBvZiBhIG5vZGUNCiAgIHdpdGggYSBETlMgc2VydmVyIGR1cmluZyB0aGUgRE5TIFVwZGF0ZSBw cm9jZXNzIGJ5IHVzaW5nIHRoZSBzYW1lDQogICBwYXJhbWV0ZXJzIGFzIGFyZSB1c2VkIGluIGdl bmVyYXRpbmcgYSBzZWN1cmUgYWRkcmVzcyBpbiBJUHY2DQogICBuZXR3b3JrcywgaS5lLiwgQ3J5 cHRvZ3JhcGhpY2FsbHkgR2VuZXJhdGVkIEFkZHJlc3NlcyAoQ0dBKSAoUkZDDQogICAzOTcyKS4g Q0dBLVRTSUcgZmFjaWxpdGF0ZXMgdGhpcyBhdXRoZW50aWNhdGlvbiBwcm9jZXNzIGFuZCByZWR1 Y2VzDQogICB0aGUgdGltZSBuZWVkZWQgZm9yIEROUyBVcGRhdGVzLiBUaGUgY3VycmVudCBzaWdu YXR1cmUgZ2VuZXJhdGlvbg0KICAgcHJvY2VzcyBhbmQgdmVyaWZpY2F0aW9uIG1lY2hhbmlzbSBp biBUU0lHIGFyZSB0aHVzIHJlcGxhY2VkIHdpdGgNCiAgIENHQS4gVGhpcyBhbGdvcml0aG0gaXMg YWRkZWQsIGFzIGFuIGV4dGVuc2lvbiwgdG8gVFNJRyB0byBlbGltaW5hdGUNCiAgIHRoZSBodW1h biBpbnRlcnZlbnRpb24gbmVlZGVkIGZvciBnZW5lcmF0aW9uIGFuZCBleGNoYW5nZSBvZiBrZXlz DQogICBiZXR3ZWVuIGEgRE5TIHNlcnZlciBhbmQgYSBob3N0IHdoZW4gU0VjdXJlIE5laWdoYm9y IERpc2NvdmVyeSAoU0VORCkNCiAgIChSRkMgMzk3MSkgaXMgdXNlZC4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From rafiee@hpi.uni-potsdam.de Wed Oct 24 02:09:00 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1A321F8B71 for ; Wed, 24 Oct 2012 02:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg3aV3mLUq8f for ; Wed, 24 Oct 2012 02:08:59 -0700 (PDT) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id EDF5721F8B73 for ; Wed, 24 Oct 2012 02:08:58 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id C243ED2CA1; Wed, 24 Oct 2012 11:08:56 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Wed, 24 Oct 2012 11:08:56 +0200 From: "Rafiee, Hosnieh" To: Miek Gieben Date: Wed, 24 Oct 2012 11:08:55 +0200 Thread-Topic: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2xwBadXyfxvONgQ3ekKIYHnoB9XQAAKqEQ Message-ID: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> In-Reply-To: <20121024081757.GB17765@miek.nl> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 09:09:00 -0000 Dear Miek, Thank you so much for your comments and careful review.=20 >First up: it seems you have written this draft by hand? I.e., didn't use X= ML2RFC? There is some markup that is different than normal (i.e. no ^L in t= he page header/footer). If you don't like XML, you >could use my pandoc2rfc >tooling: https://github.com/miekg/pandoc2rfc It was not written in text editor, we first used word template and we reali= zed that it is not easy to convert it to text, so again we used another pro= gram, i.e., NroffEdit. we have no problem using xml but also welcome the ot= her editors that simplify this formatting.=20 For converting Nroff file to txt , we used linux command and followed instr= uction of the following link http://www.rfc-editor.org/nroff.html. But it a= ppears that it left some special character. Again thanks for your careful r= eview. I will use your comment in next version and will take care of such s= pecial characters. >In the section 1. you talk about 'named server' I suppose you mean 'name s= erver'? >Also is there a reason not to mention: rfc 6494? RFC 6494 focused on Certification management for SEND. In our draft we are = interested in the CGA option of SEND. The more details of this option can b= e found in RFC 3971. This is the why we referred to that rfc=20 >"Convention used in this document", section 2, tells about lines starting = with >C: and S:, which don't actually appear in the document? It was added as a default from the word template. I will remove it.=20 >"3.2.1. Modified TSIG Record format ", first sentence. You make a hint th= at TSIG is found in RFC1035 (which it isn't)? The format of all DNS RRs are the same. TSIG also uses the same format as o= ur modified version. This format can be found in RFC 1035. In the our draft in this sentence "The modified TSIG RR uses the same forma= t as other RRs in use in the DNS field. This is explained in section 3.2.1 = RFC-1035... " We wanted just to confirm the same format as the other DNS Re= source Records. You cannot find something about TSIG or modified TSIG in RF= C 1035. I will change "this is explained " to "the DNS RR format is explain= ed..." . It might clear the case. >what does the last sentence of section 6 mean: > However ,the first step should be done manually the first time it is u= sed to > afford greater security for this process. >Are you now saying a manual step is still needed? It is Not required for the authentication of a client to a DNS server and i= t automates the whole process for them. But to have more secure communicati= on between two or more DNS servers (masters and slaves or ...), we recommen= ded to use one of the 3 mentioned scenarios in section 3.2.1.1 of this draf= t RFC (especially a. and b.).=20 Thank you again, Best Regards, Hosnieh From d3e3e3@gmail.com Wed Oct 24 06:26:10 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E1021F889A for ; Wed, 24 Oct 2012 06:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.386 X-Spam-Level: X-Spam-Status: No, score=-103.386 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WWXDLkHDzRE for ; Wed, 24 Oct 2012 06:26:09 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D98E21F8847 for ; Wed, 24 Oct 2012 06:26:08 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so753616iec.31 for ; Wed, 24 Oct 2012 06:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M49/ZwtTaclgqe4uWF0xDzpiOcaznlqQFDObxyCs2co=; b=pqHK96hAqp+rVmB/7W/xme4wgSspfpzktQH8d0I0rBjvUqxKAspCUYZuPFZWG9TtwM OF+jf6mADD4vQrFf4jySgcoG7gpUHkDsaB2EFta2pFJIhsk2oQtanKSktAKj8C19bDrI IcUw3VF+dg1Z/qnwAPQus5IwCAU71VFrcwg4+PPH4rhI4x+zVdsNcsX6/HOj3lSXMHke AuMfTztO+oIjhQs5nt6JU5o73xcFJj09hvwn3iGyNoW4Gw9qeZzAEA1jiVPLTyjFrRAB 6kOWZHSaATxIUsjYjz+flpvQYLtJZmQZst85OmEYBPUvwh62ol2LS70R+BJ8Zy0iwL2k uRrw== MIME-Version: 1.0 Received: by 10.50.33.147 with SMTP id r19mr836055igi.73.1351085168623; Wed, 24 Oct 2012 06:26:08 -0700 (PDT) Received: by 10.64.176.134 with HTTP; Wed, 24 Oct 2012 06:26:08 -0700 (PDT) In-Reply-To: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> Date: Wed, 24 Oct 2012 09:26:08 -0400 Message-ID: From: Donald Eastlake To: "Rafiee, Hosnieh" Content-Type: multipart/alternative; boundary=f46d04462ec8897fb104ccce073f Cc: "dnsext@ietf.org" Subject: Re: [dnsext] [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 13:26:10 -0000 --f46d04462ec8897fb104ccce073f Content-Type: text/plain; charset=ISO-8859-1 On getting rid of "special characters" in your output, you probably need to add a " -Tascii " or the like to your command line. Donald from iPhone On Wednesday, October 24, 2012, Rafiee, Hosnieh wrote: > Dear Miek, > > Thank you so much for your comments and careful review. > > > >First up: it seems you have written this draft by hand? I.e., didn't use > XML2RFC? There is some markup that is different than normal (i.e. no ^L in > the page header/footer). If you don't like XML, you >could use my pandoc2rfc > >tooling: https://github.com/miekg/pandoc2rfc > It was not written in text editor, we first used word template and we > realized that it is not easy to convert it to text, so again we used > another program, i.e., NroffEdit. we have no problem using xml but also > welcome the other editors that simplify this formatting. > For converting Nroff file to txt , we used linux command and followed > instruction of the following link http://www.rfc-editor.org/nroff.html. > But it appears that it left some special character. Again thanks for your > careful review. I will use your comment in next version and will take care > of such special characters. > > > >In the section 1. you talk about 'named server' I suppose you mean 'name > server'? > >Also is there a reason not to mention: rfc 6494? > RFC 6494 focused on Certification management for SEND. In our draft we are > interested in the CGA option of SEND. The more details of this option can > be found in RFC 3971. This is the why we referred to that rfc > > >"Convention used in this document", section 2, tells about lines starting > with > >C: and S:, which don't actually appear in the document? > It was added as a default from the word template. I will remove it. > > > >"3.2.1. Modified TSIG Record format ", first sentence. You make a hint > that TSIG is found in RFC1035 (which it isn't)? > The format of all DNS RRs are the same. TSIG also uses the same format as > our modified version. This format can be found in RFC 1035. > In the our draft in this sentence "The modified TSIG RR uses the same > format as other RRs in use in the DNS field. This is explained in section > 3.2.1 RFC-1035... " We wanted just to confirm the same format as the other > DNS Resource Records. You cannot find something about TSIG or modified TSIG > in RFC 1035. I will change "this is explained " to "the DNS RR format is > explained..." . It might clear the case. > > >what does the last sentence of section 6 mean: > > > However ,the first step should be done manually the first time it is > used to > > afford greater security for this process. > > >Are you now saying a manual step is still needed? > It is Not required for the authentication of a client to a DNS server and > it automates the whole process for them. But to have more secure > communication between two or more DNS servers (masters and slaves or ...), > we recommended to use one of the 3 mentioned scenarios in section 3.2.1.1 > of this draft RFC (especially a. and b.). > > Thank you again, > Best Regards, > Hosnieh > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --f46d04462ec8897fb104ccce073f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On getting rid of "special characters" in your output, you probab= ly need to add a " -Tascii " or the like to your command line.
Donald=A0

from iPhone

On Wednesday, O= ctober 24, 2012, Rafiee, Hosnieh wrote:
Dear Miek,

Thank you so much for your comments and careful review.


>First up: it seems you have written this draft by hand? I.e., didn'= t use XML2RFC? There is some markup that is different than normal (i.e. no = ^L in the page header/footer). If you don't like XML, you >could use= my pandoc2rfc
>tooling: https://github.com/miekg/pandoc2rfc
It was not written in text editor, we first used word template and we reali= zed that it is not easy to convert it to text, so again we used another pro= gram, i.e., NroffEdit. we have no problem using xml but also welcome the ot= her editors that simplify this formatting.
For converting Nroff file to txt , we used linux command and followed instr= uction of the following link http://www.rfc-editor.org/nroff.html. But it appea= rs that it left some special character. Again thanks for your careful revie= w. I will use your comment in next version and will take care of such speci= al characters.


>In the section 1. you talk about 'named server' I suppose you m= ean 'name server'?
>Also is there a reason not to mention: rfc 6494?
RFC 6494 focused on Certification management for SEND. In our draft we are = interested in the CGA option of SEND. The more details of this option can b= e found in RFC 3971. This is the why we referred to that rfc

>"Convention used in this document", section 2, tells about li= nes starting with
>C: and S:, which don't actually appear in the document?
It was added as a default from the word template. I will remove it.


>"3.2.1. =A0Modified TSIG Record format ", first sentence. You= make a hint that TSIG is found in RFC1035 (which it isn't)?
The format of all DNS RRs are the same. TSIG also uses the same format as o= ur modified version. This format can be found in RFC 1035.
In the our draft in this sentence "The modified TSIG RR uses the same = format as other RRs in use in the DNS field. This is explained in section 3= .2.1 RFC-1035... " We wanted just to confirm the same format as the ot= her DNS Resource Records. You cannot find something about TSIG or modified = TSIG in RFC 1035. I will change "this is explained " to "the= DNS RR format is explained..." . It might clear the case.

>what does the last sentence of section 6 mean:

> =A0 =A0However ,the first step should be done manually the first time = it is used to
=A0> =A0 afford greater security for this process.

>Are you now saying a manual step is still needed?
It is Not required for the authentication of a client to a DNS server and i= t automates the whole process for them. But to have more secure communicati= on between two or more DNS servers (masters and slaves or ...), we recommen= ded to use one of the 3 mentioned scenarios in section 3.2.1.1 of this draf= t RFC (especially a. and b.).

Thank you again,
Best Regards,
Hosnieh
_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext


--
Thanks,
Donald
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell)
=A0155 = Beaver Street,=A0Milford, MA 01757 USA
=A0d3e3e3@gmail.com
--f46d04462ec8897fb104ccce073f-- From rafiee@hpi.uni-potsdam.de Wed Oct 24 07:48:05 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE32421F8A9F for ; Wed, 24 Oct 2012 07:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YREnhYx0kf4K for ; Wed, 24 Oct 2012 07:48:03 -0700 (PDT) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id E4E9621F8818 for ; Wed, 24 Oct 2012 07:48:02 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id 96F20D2CAE; Wed, 24 Oct 2012 16:48:01 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Wed, 24 Oct 2012 16:48:01 +0200 From: "Rafiee, Hosnieh" To: Donald Eastlake Date: Wed, 24 Oct 2012 16:48:00 +0200 Thread-Topic: [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2x6yIKAbcnQHbdQo67lQSVD4m3VgACYUVw Message-ID: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D44657358MXMA1Rhpiuni_" MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 14:48:06 -0000 --_000_EA738325B0580041A50A364F5F76B68924D44657358MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Donald, Thank you so much. The command I used was nroff -ms myfile | specialcharRemover.pl > output I will try this parameter "-Tascii" in the command. Hosnieh From: Donald Eastlake [mailto:d3e3e3@gmail.com] Sent: Mittwoch, 24. Oktober 2012 15:26 To: Rafiee, Hosnieh Cc: Miek Gieben; dnsext@ietf.org Subject: Re: [Int-area] Last Call before IETF meeting: draft-rafiee-intarea= -cga-tsig-00.txt On getting rid of "special characters" in your output, you probably need to= add a " -Tascii " or the like to your command line. Donald from iPhone On Wednesday, October 24, 2012, Rafiee, Hosnieh wrote: Dear Miek, Thank you so much for your comments and careful review. >First up: it seems you have written this draft by hand? I.e., didn't use X= ML2RFC? There is some markup that is different than normal (i.e. no ^L in t= he page header/footer). If you don't like XML, you >could use my pandoc2rfc >tooling: https://github.com/miekg/pandoc2rfc It was not written in text editor, we first used word template and we reali= zed that it is not easy to convert it to text, so again we used another pro= gram, i.e., NroffEdit. we have no problem using xml but also welcome the ot= her editors that simplify this formatting. For converting Nroff file to txt , we used linux command and followed instr= uction of the following link http://www.rfc-editor.org/nroff.html. But it a= ppears that it left some special character. Again thanks for your careful r= eview. I will use your comment in next version and will take care of such s= pecial characters. >In the section 1. you talk about 'named server' I suppose you mean 'name s= erver'? >Also is there a reason not to mention: rfc 6494? RFC 6494 focused on Certification management for SEND. In our draft we are = interested in the CGA option of SEND. The more details of this option can b= e found in RFC 3971. This is the why we referred to that rfc >"Convention used in this document", section 2, tells about lines starting = with >C: and S:, which don't actually appear in the document? It was added as a default from the word template. I will remove it. >"3.2.1. Modified TSIG Record format ", first sentence. You make a hint th= at TSIG is found in RFC1035 (which it isn't)? The format of all DNS RRs are the same. TSIG also uses the same format as o= ur modified version. This format can be found in RFC 1035. In the our draft in this sentence "The modified TSIG RR uses the same forma= t as other RRs in use in the DNS field. This is explained in section 3.2.1 = RFC-1035... " We wanted just to confirm the same format as the other DNS Re= source Records. You cannot find something about TSIG or modified TSIG in RF= C 1035. I will change "this is explained " to "the DNS RR format is explain= ed..." . It might clear the case. >what does the last sentence of section 6 mean: > However ,the first step should be done manually the first time it is u= sed to > afford greater security for this process. >Are you now saying a manual step is still needed? It is Not required for the authentication of a client to a DNS server and i= t automates the whole process for them. But to have more secure communicati= on between two or more DNS servers (masters and slaves or ...), we recommen= ded to use one of the 3 mentioned scenarios in section 3.2.1.1 of this draf= t RFC (especially a. and b.). Thank you again, Best Regards, Hosnieh _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext -- Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --_000_EA738325B0580041A50A364F5F76B68924D44657358MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Donald, T= hank you so much.

The com= mand I used was nroff -ms myfile | specialcharRemover.pl > output

I will try this parameter “= ;-Tascii” in the command.

=  

Hosnieh=

 

From: Donald Eastlake [mailto:d3e3e3@gmail.com] <= br>Sent: Mittwoch, 24. Oktober 2012 15:26
To: Rafiee, Hosn= ieh
Cc: Miek Gieben; dnsext@ietf.org
Subject: Re: [Int-= area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt

 

On getting rid of "special characters" in your outp= ut, you probably need to add a " -Tascii " or the like to your co= mmand line.

Donald 

 

from iPhone


On Wednesday, October 24, 2012, Rafiee= , Hosnieh wrote:

Dear Miek,

Thank= you so much for your comments and careful review.


>First up:= it seems you have written this draft by hand? I.e., didn't use XML2RFC? Th= ere is some markup that is different than normal (i.e. no ^L in the page he= ader/footer). If you don't like XML, you >could use my pandoc2rfc
>= ;tooling: https://github.com/miekg/pandoc2rfc
It was not written in text edit= or, we first used word template and we realized that it is not easy to conv= ert it to text, so again we used another program, i.e., NroffEdit. we have = no problem using xml but also welcome the other editors that simplify this = formatting.
For converting Nroff file to txt , we used linux command and= followed instruction of the following link http://www.rfc-editor.org/nroff.html. But it appears that it left some special character. Again thanks for you= r careful review. I will use your comment in next version and will take car= e of such special characters.


>In the section 1. you talk abo= ut 'named server' I suppose you mean 'name server'?
>Also is there a = reason not to mention: rfc 6494?
RFC 6494 focused on Certification manag= ement for SEND. In our draft we are interested in the CGA option of SEND. T= he more details of this option can be found in RFC 3971. This is the why we= referred to that rfc

>"Convention used in this document&quo= t;, section 2, tells about lines starting with
>C: and S:, which don'= t actually appear in the document?
It was added as a default from the wo= rd template. I will remove it.


>"3.2.1.  Modified T= SIG Record format ", first sentence. You make a hint that TSIG is foun= d in RFC1035 (which it isn't)?
The format of all DNS RRs are the same. T= SIG also uses the same format as our modified version. This format can be f= ound in RFC 1035.
In the our draft in this sentence "The modified T= SIG RR uses the same format as other RRs in use in the DNS field. This is e= xplained in section 3.2.1 RFC-1035... " We wanted just to confirm the = same format as the other DNS Resource Records. You cannot find something ab= out TSIG or modified TSIG in RFC 1035. I will change "this is explaine= d " to "the DNS RR format is explained..." . It might clear = the case.

>what does the last sentence of section 6 mean:

= >    However ,the first step should be done manually the first= time it is used to
 >   afford greater security for this p= rocess.

>Are you now saying a manual step is still needed?
It = is Not required for the authentication of a client to a DNS server and it a= utomates the whole process for them. But to have more secure communication = between two or more DNS servers (masters and slaves or ...), we recommended= to use one of the 3 mentioned scenarios in section 3.2.1.1 of this draft R= FC (especially a. and b.).

Thank you again,
Best Regards,
Hosn= ieh
_______________________________________________
dnsext mailing li= st
dnsext@ietf.org
https://www.ietf.org/= mailman/listinfo/dnsext


--
Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd&= nbsp;  +1-508-333-2270 (cell)
 155 Beaver Street, Milford= , MA 01757 USA
 d3e3e3@gmail.com

= --_000_EA738325B0580041A50A364F5F76B68924D44657358MXMA1Rhpiuni_-- From suruti94@gmail.com Wed Oct 24 09:41:42 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C1A21F8C6E for ; Wed, 24 Oct 2012 09:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsCBOUvIMEiX for ; Wed, 24 Oct 2012 09:41:41 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFF121F8C48 for ; Wed, 24 Oct 2012 09:41:41 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so335138dan.31 for ; Wed, 24 Oct 2012 09:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0enxEGjJ8U07/MLGju4KD/z0H7g4zYghPC74xSVarJo=; b=hGaj00VS67hBEN3EurEJmHECz9XMfGtzsRm6LFZnHxBgMsJXf5llImz+ry4rtrbW4b b6LI+3ZPDn2uo5X7XAq7GGSWsy4XMGxtCmoGgfHAtkqH8vYEADQycht04hsLe+tuLmX2 Mmjfu07py4JZKbOkdmcziRGnWKBRtgOvpbmNHFauRcY3E10hSgm0X3igI7g+TZcm5j7+ 77NLRxLEKwtGx3CMmsZz2VDaoskncSv0BlhfQjjj/WpM6d76dcscbApSMFIzB4c8IJ6W FKvhkPZHoXcQ3Lav1ypROrTaFe7h1yj/X1hCMCvRKgFXJ+Dxh4OEdtrTRpaBoNlXYkUv b/xA== MIME-Version: 1.0 Received: by 10.68.216.131 with SMTP id oq3mr50613253pbc.147.1351096901200; Wed, 24 Oct 2012 09:41:41 -0700 (PDT) Received: by 10.68.130.68 with HTTP; Wed, 24 Oct 2012 09:41:41 -0700 (PDT) In-Reply-To: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> Date: Wed, 24 Oct 2012 09:41:41 -0700 Message-ID: From: Mohan Parthasarathy To: "Rafiee, Hosnieh" Content-Type: multipart/alternative; boundary=e89a8ff242d1da6bca04ccd0c261 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 16:41:42 -0000 --e89a8ff242d1da6bca04ccd0c261 Content-Type: text/plain; charset=ISO-8859-1 > >what does the last sentence of section 6 mean: > > > However ,the first step should be done manually the first time it is > used to > > afford greater security for this process. > > >Are you now saying a manual step is still needed? > It is Not required for the authentication of a client to a DNS server and > it automates the whole process for them. But to have more secure > communication between two or more DNS servers (masters and slaves or ...), > we recommended to use one of the 3 mentioned scenarios in section 3.2.1.1 > of this draft RFC (especially a. and b.). > > If you are just using CGAs, what prevents any client from updating *any* DNS server ? Any rogue client can generate a CGA and send an update to the DNS server. What prevents this ? It looks like the latest version of your draft has this: 7. Verify the public key The DNS server checks whether or not the public key retrieved from the TSIG Other DATA is the same as what was saved manually by the administrator. If it is the same, step 8 is executed, otherwise, the message should be discarded without further action. So, you need manual configuration. -mohan > Thank you again, > Best Regards, > Hosnieh > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --e89a8ff242d1da6bca04ccd0c261 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
>what does the last sentence of section 6 mean:

> =A0 =A0However ,the first step should be done manually the first time = it is used to
=A0> =A0 afford greater security for this process.

>Are you now saying a manual step is still needed?
It is Not required for the authentication of a client to a DNS server and i= t automates the whole process for them. But to have more secure communicati= on between two or more DNS servers (masters and slaves or ...), we recommen= ded to use one of the 3 mentioned scenarios in section 3.2.1.1 of this draf= t RFC (especially a. and b.).

If you are just using CGAs, what prevents any client = from updating *any* DNS server ? Any rogue client can generate a CGA and se= nd an update to the DNS server. What prevents this ? It looks like the late= st version of your draft has this:

7. Verify the public key=20

   The DNS server checks whether or not the public key retrieved from
   the TSIG Other DATA is the same as what was saved manually by the
   administrator. If it is the same, step 8 is executed, otherwise, the
   message should be discarded without further action.

So, you need manual configuration.

-mohan
=A0
Thank you again,
Best Regards,
Hosnieh
___________________________________= ____________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext

--e89a8ff242d1da6bca04ccd0c261-- From rafiee@hpi.uni-potsdam.de Wed Oct 24 11:10:57 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4564221F8823 for ; Wed, 24 Oct 2012 11:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wh6jktCO8o6s for ; Wed, 24 Oct 2012 11:10:52 -0700 (PDT) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id 35BC621F8778 for ; Wed, 24 Oct 2012 11:10:52 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id 34705D2CB4; Wed, 24 Oct 2012 20:10:51 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Wed, 24 Oct 2012 20:10:51 +0200 From: "Rafiee, Hosnieh" To: Mohan Parthasarathy Date: Wed, 24 Oct 2012 20:10:45 +0200 Thread-Topic: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2yBnQB1TCO2N37Qh6Wi9u/ZGx64wAAkSGg Message-ID: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D44657528MXMA1Rhpiuni_" MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 18:10:57 -0000 --_000_EA738325B0580041A50A364F5F76B68924D44657528MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Mohan, >>what does the last sentence of section 6 mean: >> However ,the first step should be done manually the first time it is = used to >> afford greater security for this process. >>Are you now saying a manual step is still needed? >>It is Not required for the authentication of a client to a DNS server and= it automates the whole process for them. But to have more secure communica= tion between two or more DNS servers (masters and >>slaves or ...), we reco= mmended to use one of the 3 mentioned scenarios in section 3.2.1.1 of this = draft RFC (especially a. and b.). >If you are just using CGAs, what prevents any client from updating *any* D= NS server ? Any rogue client can generate a CGA and send an update to the D= NS server. What prevents this ? It looks like the >latest version of your d= raft has this: For a client and a DNS server, as I explained before, there is no need for = manual settings. CGA can prove the address ownership by finding the binding= between a sender's public key and its (sender's) IP address. No attackers = can thus spoof other IP addresses. If an attacker wants to do that, he need= s to do a brute force attack against the CGA. This means that a host can on= ly update its own RRs in any DNS server that accepts source IP authenticati= on, and no other hosts' RRs. This prevents IP spoofing attacks. The second scenario is between DNS servers. Often a DNS server wants to upd= ate several RRs that are located on other DNS servers, even though he might= not own those RRs. In this particular scenario, it becomes necessary to up= date the authorized list of that specific zone file with the IP address of = this DNS server (IP address of the update requestor). but this occurs only = once. If the IP address of that DNS server changes, other DNS servers will = have a way of verifying the update requestor. This is done by saving the up= date requestor's public key when the first verification occurs. In all futu= re requests, after generation of a new IP address, other DNS servers can us= e CGA for the verification process. A benefit of this mechanism is the reduction in the number of messages nece= ssary to establish a secure channel between two DNS servers. Moreover, the = manual process is needed only once. It does not need to be repeated every t= ime the node changes its IP address. Compared with other security mechanism= , the manual intervention required in this procedure is minimal. >7. Verify the public key This verification step need only be done for the second scenario, as I stat= ed in the prior answer. --_000_EA738325B0580041A50A364F5F76B68924D44657528MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Mohan,=

>>what = does the last sentence of section 6 mean:

>>    Howe= ver ,the first step should be done manually the first time it is used to >>   afford greater security for this process.

>= ;>Are you now saying a manual step is still needed?
>>It is Not= required for the authentication of a client to a DNS server and it automat= es the whole process for them. But to have more secure communication betwee= n two or more DNS servers (masters and >>slaves or ...), we recommend= ed to use one of the 3 mentioned scenarios in section 3.2.1.1 of this draft= RFC (especially a. and b.).

 =

>If you are just using CGAs, what prevent= s any client from updating *any* DNS server ? Any rogue client can generate= a CGA and send an update to the DNS server. What prevents this ? It looks = like the >latest version of your draft has this:

 

For a client and a D= NS server, as I explained before, there is no need for manual settings. CGA= can prove the address ownership by finding the binding between a sender= 217;s public key and its (sender’s) IP address. No attackers can thus= spoof other IP addresses. If an attacker wants to do that, he needs to do = a brute force attack against the CGA. This means that a host can only updat= e its own RRs in any DNS server that accepts source IP authentication, and = no other hosts’ RRs. This prevents IP spoofing attacks.

The second scenario is between DNS servers. Often a D= NS server wants to update several RRs that are located on other DNS servers= , even though he might not own those RRs. In this particular scenario, it b= ecomes necessary to update the authorized list of that specific zone file w= ith the IP address of this DNS server (IP address of the update requestor).= but this occurs only once. If the IP address of that DNS server changes, o= ther DNS servers will have a way of verifying the update requestor. This is= done by saving the update requestor’s public key when the first veri= fication occurs. In all future requests, after generation of a new IP addre= ss, other DNS servers can use CGA for the verification process. =

A benefit of this mechanism is the reduction in th= e number of messages necessary to establish a secure channel between two DN= S servers. Moreover, the manual process is needed only once. It does not ne= ed to be repeated every time the node changes its IP address. Compared with= other security mechanism, the manual intervention required in this procedu= re is minimal.

 

>7. Verify the public key

This verification step need only be done for the second scen= ario, as I stated in the prior answer.

 

= --_000_EA738325B0580041A50A364F5F76B68924D44657528MXMA1Rhpiuni_-- From suruti94@gmail.com Wed Oct 24 15:51:08 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FE521F8C93 for ; Wed, 24 Oct 2012 15:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYyH7UTlKdpl for ; Wed, 24 Oct 2012 15:51:08 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27F3C21F8C92 for ; Wed, 24 Oct 2012 15:51:08 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so688557pad.31 for ; Wed, 24 Oct 2012 15:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tjZn7TEE1UFtswX5ROwMq8xPfBPNFCsqecUZ1J05Kw0=; b=h4VnA0Z2TT9imy8Btpmu0FLSW0jfA+MRv5/bcDjTeskzF1YGqT+MNvbMPTqqLFstQm P5BqR+rNgf5Nb/JrhryqQ5NaIPrL8MlnWS6Qh7R4lWFQ+pWwee/Wn4GY6aMd0Kw179gw Q4POrC3Y4YKtNz4JL/4DGuCNBu0blgh07BYBSzZ1sDewCHYteg4g2wJ3HenOlaQLy24M xjgCR7uECxZ10hXvPJ4E4Ttr/53wQP3mOtyZNYyfdItJjIfRJO8zpvfVGJYJAR5YbvE1 XxewwDL/JObWdPJNeGh0X+6+f0Z59735dMkVVuaDN/ilrKmShtQ3YZ/1UZc6sopI611x vBeA== MIME-Version: 1.0 Received: by 10.66.85.8 with SMTP id d8mr48136521paz.30.1351119067970; Wed, 24 Oct 2012 15:51:07 -0700 (PDT) Received: by 10.68.130.68 with HTTP; Wed, 24 Oct 2012 15:51:07 -0700 (PDT) In-Reply-To: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> Date: Wed, 24 Oct 2012 15:51:07 -0700 Message-ID: From: Mohan Parthasarathy To: "Rafiee, Hosnieh" Content-Type: multipart/alternative; boundary=e89a8f235093187bf904ccd5ec03 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 22:51:09 -0000 --e89a8f235093187bf904ccd5ec03 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Oct 24, 2012 at 11:10 AM, Rafiee, Hosnieh wrote: > Dear Mohan,**** > > >>what does the last sentence of section 6 mean: > > >> However ,the first step should be done manually the first time it i= s > used to > >> afford greater security for this process. > > >>Are you now saying a manual step is still needed? > >>It is Not required for the authentication of a client to a DNS server > and it automates the whole process for them. But to have more secure > communication between two or more DNS servers (masters and >>slaves or > ...), we recommended to use one of the 3 mentioned scenarios in section > 3.2.1.1 of this draft RFC (especially a. and b.).**** > > ** ** > > >If you are just using CGAs, what prevents any client from updating *any* > DNS server ? Any rogue client can generate a CGA and send an update to th= e > DNS server. What prevents this ? It looks like the >latest version of you= r > draft has this:**** > > ** ** > > For a client and a DNS server, as I explained before, there is no need fo= r > manual settings. CGA can prove the address ownership by finding the bindi= ng > between a sender=92s public key and its (sender=92s) IP address. No attac= kers > can thus spoof other IP addresses. If an attacker wants to do that, he > needs to do a brute force attack against the CGA. This means that a host > can only update its own RRs in any DNS server that accepts source IP > authentication, and no other hosts=92 RRs. This prevents IP spoofing atta= cks. > What do you mean by "its own RRs" ? A/AAAA and PTR records ? I doubt any DNS server would accept update from any client just because it can verify the CGA. All I have to do is to generate a CGA (using random subnet prefix if there is no ingress filtering) , send an update and keep repeating this forever. > **** > > The second scenario is between DNS servers. Often a DNS server wants to > update several RRs that are located on other DNS servers, even though he > might not own those RRs. In this particular scenario, it becomes necessar= y > to update the authorized list of that specific zone file with the IP > address of this DNS server (IP address of the update requestor). but this > occurs only once. If the IP address of that DNS server changes, other DNS > servers will have a way of verifying the update requestor. This is done b= y > saving the update requestor=92s public key when the first verification > occurs. In all future requests, after generation of a new IP address, oth= er > DNS servers can use CGA for the verification process. **** > > A benefit of this mechanism is the reduction in the number of messages > necessary to establish a secure channel between two DNS servers. Moreover= , > the manual process is needed only once. It does not need to be repeated > every time the node changes its IP address. Compared with other security > mechanism, the manual intervention required in this procedure is minimal.= * > *** > > ** ** > > >7. Verify the public key **** > > This verification step need only be done for the second scenario, as I > stated in the prior answer.**** > > ** ** > This is not clear in the draft. You also need it for first scenario. -mohan --e89a8f235093187bf904ccd5ec03 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 24, 2012 at 11:10 AM, Rafiee= , Hosnieh <rafiee@hpi.uni-potsdam.de> wrote:

Dear Mohan,

>>what does the last sentence of sectio= n 6 mean:

>> =A0 =A0However ,the first step should be done manually the fir= st time it is used to
=A0>> =A0 afford greater security for this p= rocess.

>>Are you now saying a manual step is still needed?>>It is Not required for the authentication of a client to a DNS ser= ver and it automates the whole process for them. But to have more secure co= mmunication between two or more DNS servers (masters and >>slaves or = ...), we recommended to use one of the 3 mentioned scenarios in section 3.2= .1.1 of this draft RFC (especially a. and b.).

=A0

>If y= ou are just using CGAs, what prevents any client from updating *any* DNS se= rver ? Any rogue client can generate a CGA and send an update to the DNS se= rver. What prevents this ? It looks like the >latest version of your dra= ft has this:

=A0

Fo= r a client and a DNS server, as I explained before, there is no need for ma= nual settings. CGA can prove the address ownership by finding the binding b= etween a sender=92s public key and its (sender=92s) IP address. No attacker= s can thus spoof other IP addresses. If an attacker wants to do that, he ne= eds to do a brute force attack against the CGA. This means that a host can = only update its own RRs in any DNS server that accepts source IP authentica= tion, and no other hosts=92 RRs. This prevents IP spoofing attacks.

=A0
What do you mean by "its o= wn RRs" ? A/AAAA and PTR records ? I doubt any DNS server would accept= update from any client just because it can verify the CGA. =A0All I have t= o do is to generate a CGA (using random subnet prefix if there is no ingres= s filtering) , send an update and keep repeating this forever.=A0

=A0

<= /u>

The second scenario is between DNS servers. Often a DNS server wants to upd= ate several RRs that are located on other DNS servers, even though he might= not own those RRs. In this particular scenario, it becomes necessary to up= date the authorized list of that specific zone file with the IP address of = this DNS server (IP address of the update requestor). but this occurs only = once. If the IP address of that DNS server changes, other DNS servers will = have a way of verifying the update requestor. This is done by saving the up= date requestor=92s public key when the first verification occurs. In all fu= ture requests, after generation of a new IP address, other DNS servers can = use CGA for the verification process.

A benefit of this mechanism is the reduction in the = number of messages necessary to establish a secure channel between two DNS = servers. Moreover, the manual process is needed only once. It does not need= to be repeated every time the node changes its IP address. Compared with o= ther security mechanism, the manual intervention required in this procedure= is minimal.

=A0

>7. Verify the public key

This verification step need only be do= ne for the second scenario, as I stated in the prior answer.<= /span>

=A0<= /p>

This is not clear in the draft. You also = need it for first scenario.

-mohan

--e89a8f235093187bf904ccd5ec03-- From marka@isc.org Wed Oct 24 16:03:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286E321F8C11 for ; Wed, 24 Oct 2012 16:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vmmFJX-Gh-1 for ; Wed, 24 Oct 2012 16:03:30 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 859A421F8B8B for ; Wed, 24 Oct 2012 16:03:30 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0C9F85F9953; Wed, 24 Oct 2012 23:03:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:bcb1:6c62:7192:d78f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 62C37216C40; Wed, 24 Oct 2012 23:03:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D90D82A3951A; Thu, 25 Oct 2012 10:03:15 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> In-reply-to: Your message of "Wed, 24 Oct 2012 15:51:07 PDT." Date: Thu, 25 Oct 2012 10:03:15 +1100 Message-Id: <20121024230315.D90D82A3951A@drugs.dv.isc.org> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 23:03:31 -0000 In message , Mohan Parthasarathy writes: > > What do you mean by "its own RRs" ? A/AAAA and PTR records ? I doubt any > DNS server would accept update from any client just because it can verify > the CGA. All I have to do is to generate a CGA (using random subnet > prefix > if there is no ingress filtering) , send an update and keep repeating this > forever. I can see PTR being updated based on CGA. Named can be configured to update PTR if the request comes in over TCP from the matching address. It can also be configures to update NS and DNAME records if the request comes in over TCP from a address within the matching /48 (and is is trivial to extend the code to support other nibble boundaries). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@resistor.net Wed Oct 24 16:09:47 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0B321F8E9D for ; Wed, 24 Oct 2012 16:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZHan7FCHMoH for ; Wed, 24 Oct 2012 16:09:46 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2244A21F8E90 for ; Wed, 24 Oct 2012 16:09:46 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9ON9cg6029481; Wed, 24 Oct 2012 16:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351120182; bh=X13iytNp+X/kJX9kDWnuNTca6XnXuD62U5aZJ7MkjVY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=km5wxPFgQIOYA7BPKOKIvHE5T7wV6/hVfR/pl9QrqTLq9sg3AR9LNABVjgyJlk64w VgO10xbbh/kwvY9hWFWGc9OXRyEEp4qqJslLrcCFqmJJptIcKM7nLV+EK5HehmAcc3 hmz0QYwVwVPKTs0sbRZEREqMNmXKAQkFNMa/0zww= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351120182; i=@resistor.net; bh=X13iytNp+X/kJX9kDWnuNTca6XnXuD62U5aZJ7MkjVY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bt96xGBDM6i6HtW2KEcUBPxXmK3kmvx8Dx53it+CZ8zYzktaeGR8dKHWGV1UOfmVb WsrGnHbBoMpX7Fwc/nY9uAhYs/Sdm1lnGFGEbWtSzjsHhv/4P21Y8sh3Ceh93a8KPU HHDRKIyvQfQQkCmsZkWyY4Yb/w49Jb03ashpBDek= Message-Id: <6.2.5.6.2.20121024154241.0b27f2e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Oct 2012 15:44:49 -0700 To: "Rafiee, Hosnieh" From: SM In-Reply-To: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 23:09:47 -0000 Hi Hosnieh, At 07:48 24-10-2012, Rafiee, Hosnieh wrote: >The command I used was nroff -ms myfile | specialcharRemover.pl > output See http://www.rfc-editor.org/rfc-editor/2-nroff.template.nroff You can extract the fix.pl script from 2-nroff.template.nroff. Regards, -sm From suruti94@gmail.com Wed Oct 24 16:23:09 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B32C1F0C49 for ; Wed, 24 Oct 2012 16:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh4KWhSQDeEb for ; Wed, 24 Oct 2012 16:23:08 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id D96151F0419 for ; Wed, 24 Oct 2012 16:23:08 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so702421pad.31 for ; Wed, 24 Oct 2012 16:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MgBFeOAMb+oVCGdQ0zW1WS+MyREsXvCklx/To3FSO8U=; b=P4fgmNXOKqMqcXwwaon3PPzDoOmOeKBQMfGTpghc/JpcYFLQLjlJNXwDZR6X3/eUmI OvDBZ1UXTCrd8e9+0etiXENXOhNXSmy6qZh/+7zulibhd2vDLunUyFEMzTcGWhJ4KZ4j Gr0/1+UnR/No5FQmOKcvm1trprVinq2YFwYRQQ6n3/lCNYG9ePb+XfrObwJZ9+Erehxm i0iOR+I1516/vKPX2EXNDIVN1gaNDgzP+amehZ/WlgibFuAaQjb0fNUGA6cw8SlskM3+ jfAVcRHjbiBHUwjXnFgpGmTGvpzGXnrbcrhSL6MK5lLsaDvOY7FKc8ne2Te9erzISFfv tdwA== MIME-Version: 1.0 Received: by 10.68.216.131 with SMTP id oq3mr53524696pbc.147.1351120988668; Wed, 24 Oct 2012 16:23:08 -0700 (PDT) Received: by 10.68.130.68 with HTTP; Wed, 24 Oct 2012 16:23:08 -0700 (PDT) In-Reply-To: <20121024230315.D90D82A3951A@drugs.dv.isc.org> References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> <20121024230315.D90D82A3951A@drugs.dv.isc.org> Date: Wed, 24 Oct 2012 16:23:08 -0700 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: multipart/alternative; boundary=e89a8ff242d194015704ccd65eac Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 23:23:09 -0000 --e89a8ff242d194015704ccd65eac Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 24, 2012 at 4:03 PM, Mark Andrews wrote: > > In message 4CRR56Gh3JXTL211AJezkFgbhw@mail.gmail.com>, Mohan Parthasarathy writes: > > > > What do you mean by "its own RRs" ? A/AAAA and PTR records ? I doubt any > > DNS server would accept update from any client just because it can verify > > the CGA. All I have to do is to generate a CGA (using random subnet > > prefix > > if there is no ingress filtering) , send an update and keep repeating > this > > forever. > > I can see PTR being updated based on CGA. Named can be configured to > update > PTR if the request comes in over TCP from the matching address. It can > also be configures to update NS and DNAME records if the request comes > in over TCP from a address within the matching /48 (and is is trivial to > extend the code to support other nibble boundaries). > Yes, TCP gives you the return routability check. And this can't be used as a general mechanism to update any record without additional configuration. -mohan > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --e89a8ff242d194015704ccd65eac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 24, 2012 at 4:03 PM, Mark An= drews <marka@isc.org> wrote:

In message <CACU5sDmiZcaeHUQZMtA8jH=3D+4CRR56Gh3JXTL211AJezkFgbhw@mail.gmail.com&g= t;, Mohan Parthasarathy writes:
>
> What do you mean by "its own RRs" ? A/AAAA and PTR records ?= I doubt any
> DNS server would accept update from any client just because it can ver= ify
> the CGA. =A0All I have to do is to generate a CGA (using random subnet=
> prefix
> if there is no ingress filtering) , send an update and keep repeating = this
> forever.

I can see PTR being updated based on CGA. =A0Named can be configured = to update
PTR if the request comes in over TCP from the matching address. =A0It can also be configures to update NS and DNAME records if the request comes
in over TCP from a address within the matching /48 (and is is trivial to extend the code to support other nibble boundaries).
= =A0
Yes, TCP gives you the return routability check. And this can= 't be used as a general mechanism to update any record without addition= al configuration.

-mohan


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org

--e89a8ff242d194015704ccd65eac-- From rafiee@hpi.uni-potsdam.de Thu Oct 25 07:52:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB09021F89B7 for ; Thu, 25 Oct 2012 07:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4WXhcJrt7Dl for ; Thu, 25 Oct 2012 07:52:18 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 8C53121F89A6 for ; Thu, 25 Oct 2012 07:52:17 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 32E4A169ECA; Thu, 25 Oct 2012 16:52:15 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Thu, 25 Oct 2012 16:52:14 +0200 From: "Rafiee, Hosnieh" To: Mohan Parthasarathy Date: Thu, 25 Oct 2012 16:52:13 +0200 Thread-Topic: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2yOg/g1tj/RdcGR6WEm31pdrE8hwAURO3w Message-ID: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D44657DF8MXMA1Rhpiuni_" MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:52:23 -0000 --_000_EA738325B0580041A50A364F5F76B68924D44657DF8MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Mohan, Thanks again for your review and strong comments. From: Mohan Parthasarathy [mailto:suruti94@gmail.com] >>what does the last sentence of section 6 mean: >> However ,the first step should be done manually the first time it is = used to >> afford greater security for this process. >>Are you now saying a manual step is still needed? >>It is Not required for the authentication of a client to a DNS server and= it automates the whole process for them. But to have more secure communica= tion between two or more DNS servers (masters and >>slaves or ...), we reco= mmended to use one of the 3 mentioned scenarios in section 3.2.1.1 of this = draft RFC (especially a. and b.). >If you are just using CGAs, what prevents any client from updating *any* D= NS server ? Any rogue client can generate a CGA and send an update to the D= NS server. What prevents this ? It looks like the >latest version of your d= raft has this: For a client and a DNS server, as I explained before, there is no need for = manual settings. CGA can prove the address ownership by finding the binding= between a sender's public key and its (sender's) IP address. No attackers = can thus spoof other IP addresses. If an attacker wants to do that, he need= s to do a brute force attack against the CGA. This means that a host can on= ly update its own RRs in any DNS server that accepts source IP authenticati= on, and no other hosts' RRs. This prevents IP spoofing attacks. >What do you mean by "its own RRs" ? A/AAAA and PTR records ? I doubt any D= NS server would accept update from any client just because it can verify th= e CGA. All I have to do is to generate a CGA (using random subnet prefix i= f there is no >ingress filtering) , send an update and keep repeating this = forever. If an administrator of a DNS server has enabled secure DNS update (TSIG th= at supports the CGA-TSIG algorithm) on his server, then this mechanism can = work on those DNS servers. Otherwise they will use a different policy that = only accepts a connection from local links or .... a kind of TCP filtering = as you also explained . Because CGA-TSIG is a new algorithm in TSIG. It does the same as TSIG but d= oes not need the first two messages for establish a secure channel. This me= chanism enhances the security during the authentication mechanism. It ensur= es that the DNS server, the one who would like to update a RR (resource rec= ords can be PTR, AAAA, CNAME ), is the owner of that resource record. No ho= st has the private key belonging to the other hosts, so they cannot sign th= e message. It CGA-TSIG verification steps, we also added the signature. Thi= s signature will assist the DNS server to double check the owner of that re= source records. You as a host can generate a CGA and can generate the signa= ture, but cannot spoof other's CGA. I will try to improve that section and explain it in more detail. The second scenario is between DNS servers. Often a DNS server wants to upd= ate several RRs that are located on other DNS servers, even though he might= not own those RRs. In this particular scenario, it becomes necessary to up= date the authorized list of that specific zone file with the IP address of = this DNS server (IP address of the update requestor). but this occurs only = once. If the IP address of that DNS server changes, other DNS servers will = have a way of verifying the update requestor. This is done by saving the up= date requestor's public key when the first verification occurs. In all futu= re requests, after generation of a new IP address, other DNS servers can us= e CGA for the verification process. A benefit of this mechanism is the reduction in the number of messages nece= ssary to establish a secure channel between two DNS servers. Moreover, the = manual process is needed only once. It does not need to be repeated every t= ime the node changes its IP address. Compared with other security mechanism= , the manual intervention required in this procedure is minimal. >7. Verify the public key This verification step need only be done for the second scenario, as I stat= ed in the prior answer. >This is not clear in the draft. You also need it for first scenario. When I think more about this process I am in agreement with you to a certa= in extent. I agree that the DNS server should also store the client's publ= ic key. This will allow the same client to update his own resource records = after generation of the new IP address. But for communication between a cli= ent and a DNS server, there is no need for the administrator to intercept= this process. But for two DNS servers, for the first time, it is necessar= y in order to add the IP address to the authorized list. I will edit this s= ection of the draft and try to explain this process in more detail in order= to clarify it. P.S. I am also working on the implementation of CGA-TSIG. If I can finish i= t before the IETF meeting, I will be able to demo it to those interested. Thank you Hosnieh --_000_EA738325B0580041A50A364F5F76B68924D44657DF8MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Moha= n,

 

Thanks again for your review and strong c= omments.

 =

From: Mohan Parthasarathy [mailto:suruti94@gmail.com]

>>what does the last sentence of section 6= mean:

>>    However ,the first step should be done = manually the first time it is used to
 >>   afford great= er security for this process.

>>Are you now saying a manual st= ep is still needed?
>>It is Not required for the authentication of= a client to a DNS server and it automates the whole process for them. But = to have more secure communication between two or more DNS servers (masters = and >>slaves or ...), we recommended to use one of the 3 mentioned sc= enarios in section 3.2.1.1 of this draft RFC (especially a. and b.).

 

>If you are just using CGAs, = what prevents any client from updating *any* DNS server ? Any rogue client = can generate a CGA and send an update to the DNS server. What prevents this= ? It looks like the >latest version of your draft has this:<= /p>

 

For a client and a DNS server, = as I explained before, there is no need for manual settings. CGA can prove = the address ownership by finding the binding between a sender’s publi= c key and its (sender’s) IP address. No attackers can thus spoof othe= r IP addresses. If an attacker wants to do that, he needs to do a brute for= ce attack against the CGA. This means that a host can only update its own R= Rs in any DNS server that accepts source IP authentication, and no other ho= sts’ RRs. This prevents IP spoofing attacks.

 

>What do you mean by "it= s own RRs" ? A/AAAA and PTR records ? I doubt any DNS server would acc= ept update from any client just because it can verify the CGA.  All I = have to do is to generate a CGA (using random subnet prefix if there is no = >ingress filtering) , send an updat= e and keep repeating this forever. =

If an administrator of a DNS s= erver has enabled  secure DNS update (TSIG that supports the CGA-TSIG = algorithm) on his server, then this mechanism can work on those DNS servers= . Otherwise they will use a different policy that only accepts a connection= from local links or …. a kind of TCP filtering as you also explained= .

Because CGA-TSIG is a = new algorithm in TSIG. It does the same as TSIG but does not need the first= two messages for establish a secure channel. This mechanism enhances the s= ecurity during the authentication mechanism. It ensures that the DNS server= , the one who would like to update a RR (resource records can be PTR, AAAA,= CNAME ), is the owner of that resource record. No host has the private key= belonging to the other hosts, so they cannot sign the message. It CGA-TSIG= verification steps, we also added the signature. This signature will assis= t the DNS server to double check the owner of that resource records. You as= a host can generate a CGA and can generate the signature, but cannot spoof= other’s CGA.

 

I will try to improve t= hat section and explain it in more detail.

=

 

&= nbsp;

The second scenari= o is between DNS servers. Often a DNS server wants to update several RRs th= at are located on other DNS servers, even though he might not own those RRs= . In this particular scenario, it becomes necessary to update the authorize= d list of that specific zone file with the IP address of this DNS server (I= P address of the update requestor). but this occurs only once. If the IP ad= dress of that DNS server changes, other DNS servers will have a way of veri= fying the update requestor. This is done by saving the update requestorR= 17;s public key when the first verification occurs. In all future requests,= after generation of a new IP address, other DNS servers can use CGA for th= e verification process.

A benefit of this mechanism i= s the reduction in the number of messages necessary to establish a secure c= hannel between two DNS servers. Moreover, the manual process is needed only= once. It does not need to be repeated every time the node changes its IP a= ddress. Compared with other security mechanism, the manual intervention req= uired in this procedure is minimal.

 

>7. Verify the public key

This verification step need only be done for the second = scenario, as I stated in the prior answer.

 

>This is not clear in the draft. You also need it for first scen= ario.

When I think more about this process I am in  agreement with you to a= certain extent. I agree that the DNS server should also store the  cl= ient’s public key. This will allow the same client to update his own = resource records after generation of the new IP address. But for communicat= ion between a client and a DNS server,  there is no need for  the= administrator to intercept this process. But for two DNS servers, for the = first time,  it is necessary in order to add the IP address to the aut= horized list. I will edit this section of the draft and try to explain this= process in more detail in order to clarify it.

=

 

P.S. I am also working on the implementation of CGA-TSIG. If I can finish it= before the IETF meeting, I will be able to demo it to those interested.

=  

T= hank you

Hosnieh

= --_000_EA738325B0580041A50A364F5F76B68924D44657DF8MXMA1Rhpiuni_-- From rafiee@hpi.uni-potsdam.de Thu Oct 25 07:52:33 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B94F21F89CD for ; Thu, 25 Oct 2012 07:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNHmSwRGKjmd for ; Thu, 25 Oct 2012 07:52:27 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB1021F89C1 for ; Thu, 25 Oct 2012 07:52:23 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 4C2F3169ECA; Thu, 25 Oct 2012 16:52:23 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Thu, 25 Oct 2012 16:52:23 +0200 From: "Rafiee, Hosnieh" To: SM Date: Thu, 25 Oct 2012 16:52:22 +0200 Thread-Topic: [dnsext] [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2yPKm9L/zh2SF8T1GNAIBWs9qScAAYgQFQ Message-ID: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> <6.2.5.6.2.20121024154241.0b27f2e8@resistor.net> In-Reply-To: <6.2.5.6.2.20121024154241.0b27f2e8@resistor.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:52:33 -0000 Hello, Thank you so much! Hosnieh -----Original Message----- From: SM [mailto:sm@resistor.net]=20 Sent: Donnerstag, 25. Oktober 2012 00:45 To: Rafiee, Hosnieh Cc: dnsext@ietf.org Subject: Re: [dnsext] [Int-area] Last Call before IETF meeting: draft-rafie= e-intarea-cga-tsig-00.txt Hi Hosnieh, At 07:48 24-10-2012, Rafiee, Hosnieh wrote: >The command I used was nroff -ms myfile | specialcharRemover.pl >=20 >output See http://www.rfc-editor.org/rfc-editor/2-nroff.template.nroff You can ex= tract the fix.pl script from 2-nroff.template.nroff. Regards, -sm=20 From ogud@ogud.com Fri Oct 26 06:53:54 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A424D21F84A9 for ; Fri, 26 Oct 2012 06:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.317 X-Spam-Level: X-Spam-Status: No, score=-103.317 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP-zoXxuBX3v for ; Fri, 26 Oct 2012 06:53:54 -0700 (PDT) Received: from smtp158.iad.emailsrvr.com (smtp158.iad.emailsrvr.com [207.97.245.158]) by ietfa.amsl.com (Postfix) with ESMTP id E133E21F84A2 for ; Fri, 26 Oct 2012 06:53:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 3AFB9300CF3; Fri, 26 Oct 2012 09:53:53 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp25.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id AC0F3300CCB; Fri, 26 Oct 2012 09:53:51 -0400 (EDT) Message-ID: <508A95ED.2020501@ogud.com> Date: Fri, 26 Oct 2012 09:53:49 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> <20121026131256.EF1C92A51FBD@drugs.dv.isc.org> <347ABF7A-8184-4CE4-B087-C057441F5F52@netherlabs.nl> In-Reply-To: <347ABF7A-8184-4CE4-B087-C057441F5F52@netherlabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, ogud@ogud.com Subject: Re: [dnsext] [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 13:53:54 -0000 Strictly speaking this is dnsext fodder not dnsop as the RFC's quoted are under DNSEXT change control. Please move the discussion there. On 26/10/2012 09:25, Peter van Dijk wrote: > Hello Mark, > > Thank you for your swift and accurate response. > > On Oct 26, 2012, at 15:12 , Mark Andrews wrote: > >> >> You asked a ANY query. ANY and CNAME have different processing rules. >> The query is NOT restarted with the target of the CNAME. See RFC 1034. >> >>> NSD returns the same minus the ra flag. >>> >>> PowerDNS, however, returns: >> >> You asked a different question (A != ANY). If you want to compare >> answers you need to ask IDENTICAL questions. > > My mistake. > > NSD: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34556 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; QUESTION SECTION: > ;nxd.example.com. IN A > > ;; ANSWER SECTION: > nxd.example.com. 120 IN CNAME nxdomain.example.com. This is perfectly OK as NSD in this case is not performing the optional server side CNAME processing. The cname exists thus this is a valid answer and valid RCODE. A recursive resolver now has to ask for nxdomain.example.com and will get the no name error. > > BIND, PowerDNS (same except for ra flag) > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4382 > ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 > ;; QUESTION SECTION: > ;nxd.example.com. IN A > > ;; ANSWER SECTION: > nxd.example.com. 120 IN CNAME nxdomain.example.com. > > ;; AUTHORITY SECTION: > example.com. 86400 IN SOA ns1.example.com. ahu.example.com. 2000081501 28800 7200 604800 86400 > This is fine as well but harder to understand :-) as the RCODE refers to the target of the CNAME not the qname. > > To be complete: > > - for the A query, BIND and PowerDNS return NXDOMAIN+SOA, NSD returns NOERROR. > - for the ANY query, NSD and BIND return NOERROR, PowerDNS returns > NXDOMAIN+SOA. > > Then, as far as I can tell, BIND and PowerDNS do the right thing for the A > query. NSD and BIND do the right thing for the ANY query, going from Mark's > interpretation of the RFCs. > > However, 2308 and 6604 totally ignore the ANY exception to following CNAME > chains, and one might argue that thus, 2308 and 6604 still mean that QNAME is > the end of the CNAME chain in the response, and the RCODE thus should be > NXDOMAIN. I think this argument could go either way. > s > Unless conflicting opinions come in, I will fix PowerDNS to do the right thing > for ANY, and will report the A query issue to the NSD developers. > In the case of ANY IMHO no CNAME processing should take place. And I encourage you to file errata against the RFC's that we can discuss on the dnsext mailing list, before it is approved. > Kind regards, > Good observations. thanks Olafur From peter.van.dijk@netherlabs.nl Fri Oct 26 07:10:12 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1D221F853B for ; Fri, 26 Oct 2012 07:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4u-S21l4k0b for ; Fri, 26 Oct 2012 07:10:10 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1017621F8539 for ; Fri, 26 Oct 2012 07:10:09 -0700 (PDT) Received: from [IPv6:2001:980:906e:1:e008:f489:ceeb:93a4] (unknown [IPv6:2001:980:906e:1:e008:f489:ceeb:93a4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 1AD001BB53; Fri, 26 Oct 2012 16:10:08 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Peter van Dijk In-Reply-To: Date: Fri, 26 Oct 2012 16:10:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> To: dnsext@ietf.org X-Mailer: Apple Mail (2.1278) Cc: paul@nohats.ca Subject: Re: [dnsext] [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 14:10:12 -0000 Hello Paul, moved this reply to dnsext too, as requested by Olafur. On Oct 26, 2012, at 16:01 , Paul Wouters wrote: >> nxdomain.example.com does not exist. >>=20 >>> How would offline signers deal with this? Pregenerate nsec records >>> for data that _is_ in the zone? >>=20 >> Offline signers would already have generated the NSEC(3) that denies = existence >> of nxdomain.example.com, simply by virtue of the name not existing in = the >> zone. >=20 > But wouldn't the chain be built based on LHS? Let's check opendnssec: >=20 > [root@nohats signed]# ldns-nsec3-hash cname.nohats.ca. -t 5 > javgjvs1ictdbmts0fcjome4s37kndg0. > [root@nohats signed]# grep javg nohats.ca = javgjvs1ictdbmts0fcjome4s37kndg0.nohats.ca. 3600 IN NSEC3 1 = 0 5 - jn89c3qpvavcumn3cv172r7gbu8h6ffs CNAME RRSIG = javgjvs1ictdbmts0fcjome4s37kndg0.nohats.ca. 3600 IN RRSIG = NSEC3 8 3 3600 20121109223118 20121026121347 52368 nohats.ca. = zjkB06zMPYIAdtGnWoA3wRqe2Fg5y4Y7R21qaQovhqXtijwMQJfukhKA4OWO4oj5DVL/v0WTZR= JII64XuAUzVs9RZMAcCuDceR0BdAT5CgjbkvEwgq08/PI06hXvScTjPzFSRPPfRJ3ViAinFDPd= 2JZHgMkTO9Wen0KkVPH/vhc=3D > ioukpqjt07l1b83ppfd1grdcc57864ja.nohats.ca. 3600 IN NSEC3 1 = 0 5 - javgjvs1ictdbmts0fcjome4s37kndg0 A RRSIG >=20 > So cname.nohats.ca is part of the nsec3 chain. >=20 > So in some sense, the record "exists". I guess validators would have = to > be very careful handling the NXDOMAIN, they might decide it is spoofed > because they have an existing NSEC/NSEC3 entry for it. >=20 > Odd corner case. There is no corner case. The NXDOMAIN is about the last name in the = CNAME chain (RFC2308 1) or the last lookup done in optionally following the = chain (RFC6604 3), not about the original QNAME. In your zone you have: cname.nohats.ca. 5 IN CNAME doesnotexist.nohats.ca. cname.nohats.ca exists and is an entry in your NSEC3 chain. doesnotexist.nohats.ca does not exist and is denied by your NSEC3 chain: doesnotexist.nohats.ca (5jng314a18r89qab1ilhe54l393kfu8a) denied by = 4nbrqak4o1esr5qpg452fucnh8k23d15..6hlm0p5e9c1f3haq64ci0puo97lmtp8g As for validators, they are not supposed to look at the RCODE anyway. = The actual error status ('no such record type' or 'no such name') can always = be derived from the NSEC(3) records provided. Kind regards, --=20 Peter van Dijk Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ From peter.van.dijk@netherlabs.nl Fri Oct 26 07:22:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A2321F856B for ; Fri, 26 Oct 2012 07:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=1.261, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq27oE-Rs3UH for ; Fri, 26 Oct 2012 07:22:38 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B30B21F853F for ; Fri, 26 Oct 2012 07:22:36 -0700 (PDT) Received: from [IPv6:2001:980:906e:1:e008:f489:ceeb:93a4] (unknown [IPv6:2001:980:906e:1:e008:f489:ceeb:93a4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id CAB921BB53; Fri, 26 Oct 2012 16:22:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Peter van Dijk In-Reply-To: <508A95ED.2020501@ogud.com> Date: Fri, 26 Oct 2012 16:22:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <215FC8EB-B3C5-4419-B39E-00B02BED6127@netherlabs.nl> References: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> <20121026131256.EF1C92A51FBD@drugs.dv.isc.org> <347ABF7A-8184-4CE4-B087-C057441F5F52@netherlabs.nl> <508A95ED.2020501@ogud.com> To: dnsext@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [dnsext] [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 14:22:39 -0000 Hello Olafur, On Oct 26, 2012, at 15:53 , Olafur Gudmundsson wrote: > Strictly speaking this is dnsext fodder not dnsop as the RFC's quoted = are under DNSEXT change control. > Please move the discussion there. Thanks for the pointer. I was not sure where to post but I figured I = would reach most of the right audience on either list. >> NSD: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34556 >> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >>=20 >> ;; QUESTION SECTION: >> ;nxd.example.com. IN A >>=20 >> ;; ANSWER SECTION: >> nxd.example.com. 120 IN CNAME nxdomain.example.com. >=20 > This is perfectly OK as NSD in this case is not performing the > optional server side CNAME processing. > The cname exists thus this is a valid answer and valid RCODE. > A recursive resolver now has to ask for nxdomain.example.com and will = get the no name error. I could not find a reference about CNAME processing being optional, but = I'll gladly take your word for it. I was going to protest, however, because even if CNAME processing is = optional, 2308 states that RCODE regards the end of the CNAME chain. However, 6604 = 3 restricts this to "final query" instead of "end of chain" and as such, = NOERROR is a correct response if the CNAME simply has not been followed. Under = the resolver recommendations in the last sentence of 2308 2.2.1, the = difference becomes uninteresting in any case. Now, I know that NSD will in fact follow the CNAME if the target already exists, so I doubt this NOERROR is intentional, but I agree it is within = the letter of the relevant RFCs. >> BIND, PowerDNS (same except for ra flag) >>=20 >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4382 >> ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 >> ;; QUESTION SECTION: >> ;nxd.example.com. IN A >>=20 >> ;; ANSWER SECTION: >> nxd.example.com. 120 IN CNAME nxdomain.example.com. >>=20 >> ;; AUTHORITY SECTION: >> example.com. 86400 IN SOA ns1.example.com. = ahu.example.com. 2000081501 28800 7200 604800 86400 >>=20 >=20 > This is fine as well but harder to understand :-) as the RCODE refers = to the target of the CNAME not the name. Yes, I find time and again that 2308 and 6604 confuse people, especially = as the redefinition of QNAME in 2308 1 is easy to miss. >> However, 2308 and 6604 totally ignore the ANY exception to following = CNAME >> chains, and one might argue that thus, 2308 and 6604 still mean that = QNAME is >> the end of the CNAME chain in the response, and the RCODE thus should = be >> NXDOMAIN. I think this argument could go either way. >> s >> Unless conflicting opinions come in, I will fix PowerDNS to do the = right thing >> for ANY, and will report the A query issue to the NSD developers. >>=20 >=20 > In the case of ANY IMHO no CNAME processing should take place. > And I encourage you to file errata against the RFC's that we can = discuss on the dnsext mailing list, before it is approved. Yes, I agree that this rule from 1034 makes sense. I will file against = 6604, would that be right? I am not very familiar with standards work. Kind regards, --=20 Peter van Dijk Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ From paul@nohats.ca Fri Oct 26 08:18:59 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9DD21F84AF for ; Fri, 26 Oct 2012 08:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5pMZ9etpaRF for ; Fri, 26 Oct 2012 08:18:59 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAF221F84A6 for ; Fri, 26 Oct 2012 08:18:59 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 5C0F782A2D; Fri, 26 Oct 2012 11:18:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5330A8051A; Fri, 26 Oct 2012 11:18:22 -0400 (EDT) Date: Fri, 26 Oct 2012 11:18:22 -0400 (EDT) From: Paul Wouters To: Peter van Dijk In-Reply-To: Message-ID: References: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 26 Oct 2012 08:38:52 -0700 Cc: dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 15:18:59 -0000 On Fri, 26 Oct 2012, Peter van Dijk wrote: > There is no corner case. The NXDOMAIN is about the last name in the CNAME > chain (RFC2308 1) or the last lookup done in optionally following the chain > (RFC6604 3), not about the original QNAME. > > In your zone you have: > > cname.nohats.ca. 5 IN CNAME doesnotexist.nohats.ca. > > cname.nohats.ca exists and is an entry in your NSEC3 chain. > > doesnotexist.nohats.ca does not exist and is denied by your NSEC3 chain: > > doesnotexist.nohats.ca (5jng314a18r89qab1ilhe54l393kfu8a) denied by 4nbrqak4o1esr5qpg452fucnh8k23d15..6hlm0p5e9c1f3haq64ci0puo97lmtp8g > > > As for validators, they are not supposed to look at the RCODE anyway. I was not so much thinking of the orignal query. I was thinking of the case where the NSEC3 has made it into the cache, and some new query causes the validator to check its cache to see if it has nsec(3) records proving a QNAME does or does not exist. The odd thing is that cname.nohats.ca "kinda" exists if you look at the nsec(3) chain. I guess resolvers implement a negative cache on the QNAME, so they never used this data to not even ask about a QNAME, and they still query for the QNAME despite having proof in the cache about it not existing. In which case, my issue would not come up. Paul From matthijs@nlnetlabs.nl Mon Oct 29 02:33:34 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A698121F85BB for ; Mon, 29 Oct 2012 02:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG5hmFeLfzeu for ; Mon, 29 Oct 2012 02:33:33 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8C321F857C for ; Mon, 29 Oct 2012 02:33:32 -0700 (PDT) Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q9T9XLfK024758 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 29 Oct 2012 10:33:22 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q9T9XLfK024758 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1351503206; bh=1wKjPbjE99wfXQ2Ozyz/PnSERrdRXxGxEt9Glq80UQM=; h=Date:From:To:Subject:References:In-Reply-To; b=fsOnTsu55L/jXroI+CYBBf3J+u2TOrYwlj7hZfPuC/40jyvLsgRNCkJhB+3Ns0+hP O9DHIBVmlj2jCeLSkBPPwUNyXX4O5KGJP2plL4S6iu1vrk7WZio99iEwsS7Pk9Ht6a 1cntXOrkquJ3ZtQ+sNsOktDZrweTjuJ9UDQs6oS8= Message-ID: <508E4D62.8010306@nlnetlabs.nl> Date: Mon, 29 Oct 2012 10:33:22 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> <20121026131256.EF1C92A51FBD@drugs.dv.isc.org> <347ABF7A-8184-4CE4-B087-C057441F5F52@netherlabs.nl> <508A95ED.2020501@ogud.com> In-Reply-To: <508A95ED.2020501@ogud.com> X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig272536F71D24833DD6D29358" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Mon, 29 Oct 2012 10:33:22 +0100 (CET) Subject: Re: [dnsext] [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 09:33:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig272536F71D24833DD6D29358 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On 10/26/2012 03:53 PM, Olafur Gudmundsson wrote: > > Strictly speaking this is dnsext fodder not dnsop as the RFC's quoted > are under DNSEXT change control. > Please move the discussion there. >=20 > >=20 > On 26/10/2012 09:25, Peter van Dijk wrote: >> Hello Mark, >> >> Thank you for your swift and accurate response. >> >> On Oct 26, 2012, at 15:12 , Mark Andrews wrote: >> >>> >>> You asked a ANY query. ANY and CNAME have different processing rules= =2E >>> The query is NOT restarted with the target of the CNAME. See RFC 103= 4. >>> >>>> NSD returns the same minus the ra flag. >>>> >>>> PowerDNS, however, returns: >>> >>> You asked a different question (A !=3D ANY). If you want to compare >>> answers you need to ask IDENTICAL questions. >> >> My mistake. >> >> NSD: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34556 >> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; QUESTION SECTION: >> ;nxd.example.com. IN A >> >> ;; ANSWER SECTION: >> nxd.example.com. 120 IN CNAME nxdomain.example.com. >=20 > This is perfectly OK as NSD in this case is not performing the > optional server side CNAME processing. > The cname exists thus this is a valid answer and valid RCODE. > A recursive resolver now has to ask for nxdomain.example.com and will > get the no name error. NSD does do CNAME processing. I interpret RFC 1034 that a name server should return NOERROR: If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response and exit. Otherwise just exit. However, RFC 2308 considers 1034 to be unclear and clarifies that the error refers to the final resolution of the CNAME chain. But it also mentions that some servers don't do that. So far so good. In RFC 6604 however, the RCODE clarification after xNAME (and thus CNAME) is pretty straight forwarded. To my belief, NSD should be returning NXDOMAIN there. If people think I have interpret this incorrectly, please let me know. Otherwise I will be fixing this for upcoming NSD releases. >=20 >> >> BIND, PowerDNS (same except for ra flag) >> >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4382 >> ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 >> ;; QUESTION SECTION: >> ;nxd.example.com. IN A >> >> ;; ANSWER SECTION: >> nxd.example.com. 120 IN CNAME nxdomain.example.com. >> >> ;; AUTHORITY SECTION: >> example.com. 86400 IN SOA ns1.example.com. >> ahu.example.com. 2000081501 28800 7200 604800 86400 >> >=20 > This is fine as well but harder to understand :-) as the RCODE refers t= o > the target of the CNAME not the qname. I think it is easy to understand, as the resolver sees that the NXDOMAIN cannot apply to QNAME (there is an answer RR for that). Also, the resolver can now expect an NXDOMAIN denial of exisntence proof, not a NODATA proof. Best regards, Matthijs >=20 >> >> To be complete: >> >> - for the A query, BIND and PowerDNS return NXDOMAIN+SOA, NSD returns >> NOERROR. >> - for the ANY query, NSD and BIND return NOERROR, PowerDNS returns >> NXDOMAIN+SOA. >> >> Then, as far as I can tell, BIND and PowerDNS do the right thing for >> the A >> query. NSD and BIND do the right thing for the ANY query, going from >> Mark's >> interpretation of the RFCs. >> >> However, 2308 and 6604 totally ignore the ANY exception to following >> CNAME >> chains, and one might argue that thus, 2308 and 6604 still mean that >> QNAME is >> the end of the CNAME chain in the response, and the RCODE thus should = be >> NXDOMAIN. I think this argument could go either way. >> s >> Unless conflicting opinions come in, I will fix PowerDNS to do the >> right thing >> for ANY, and will report the A query issue to the NSD developers. >> >=20 > In the case of ANY IMHO no CNAME processing should take place. > And I encourage you to file errata against the RFC's that we can discus= s > on the dnsext mailing list, before it is approved. >=20 >> Kind regards, >> >=20 > Good observations. > thanks > Olafur >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --------------enig272536F71D24833DD6D29358 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQjk1lAAoJEA8yVCPsQCW5EtgIALheYNJbM/LJ0yWUEkStY+Zg KGsbCwGNEwObBzBJuUPAA3cWCGuBLq5748pctX7dxDQtFyfxKAek6iK2K2nqRCAB ly7G6iAIPdFSKYHLWtguKkJ+mUIj2jhjIFyGGCIRiGb5vYtA/FucNkhuRvTGICFL L6adiMQ//7lcjwrIIcgocfneNEgoHKe0xt900Q36+rQvMq9y6TnlIhpSXdtQnlMn 7Twrys8m9rQhYgu2vmNdEK+D4vsjhhvrVW7MrMdCVfsKXMeE1P2tfm++BdDikkwj 3ZqB5OAlLz2MApVmpqoOgDquP+yjGf7Sfm453Qxnh3TOil/nF/sLZenzYXlMzpg= =RQEF -----END PGP SIGNATURE----- --------------enig272536F71D24833DD6D29358--