From dnsext-bounces@ietf.org Fri Mar 2 04:07:45 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BA621F8A73; Fri, 2 Mar 2012 04:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330690065; bh=CSiGUgOLVmB+IYXAGBjGIz03rzivaQU+nsJAz9Ow2Lc=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=qUlEgJRbMpi3uQEcdM8FYaMFl6Zlnz0Rh1whyiRcxbbGoR2AkLDQaPSYxQHrV5sdB Iow69su6B5q7O54Lq/VMRw1lg23+eFLirH1VOqcD9wTBmM/yvGyIuq2nIUrkWI4CbK ziSAwXG0aVzMq9XPM+IJRtZSkfvZd74iyY0T8rdQ= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D06A21F8A72 for ; Fri, 2 Mar 2012 04:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z364aknBsu8f for ; Fri, 2 Mar 2012 04:07:42 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id A060E21F8A73 for ; Fri, 2 Mar 2012 04:07:42 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q22C7fDP011846 for ; Fri, 2 Mar 2012 07:07:41 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F50B80A.9010303@ogud.com> Date: Fri, 02 Mar 2012 07:07:38 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: [dnsext] ECDSA approved and codes allocated X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org FYI: it is safe to release code that uses the code points below. Olafur ACTION 1: IANA has assigned the following DS RR Type Digest Algorithm: 4 SHA-384 OPTIONAL [draft-ietf-dnsext-ecdsa] Please see http://www.iana.org/assignments/ds-rr-types ACTION 2: IANA has assigned the following DNS Security Algorithm Numbers: 13 ECDSA Curve P-256 with SHA-256 ECDSAP256SHA256Y * [draft-ietf-dnsext-ecdsa][standards track] 14 ECDSA Curve P-384 with SHA-384 ECDSAP384SHA384Y * [draft-ietf-dnsext-ecdsa][standards track] Please see http://www.iana.org/assignments/dns-sec-alg-numbers _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Mar 4 12:53:55 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0221F8648; Sun, 4 Mar 2012 12:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330894435; bh=7SkcqY4RG4+k+OAup3JXKkDlnDnwHZKp55pIcfb1h+Q=; h=Date:From:To:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=qgW0idXKkjqRdEkVlcY17OwJCtL4sTTsBf4UeSrOVeBozI6DfxnR+uM0Qyjb14LKv vRojWcb9i2inGnv5Rrr+OP1HXcNlo9FKtVfjvvqfTFyFl2XEDc5ULgMo5G9VOdPCbe srS2s5pzzvdPhCExfgryzaXEgrQo1CUwvahvbZNs= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA1121F8630 for ; Sun, 4 Mar 2012 12:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_05=-1.11, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NysLHmiZGaq7 for ; Sun, 4 Mar 2012 12:53:52 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id B5D2A21F862F for ; Sun, 4 Mar 2012 12:53:52 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id B13193FF30; Sun, 4 Mar 2012 21:53:47 +0100 (CET) Date: Sun, 4 Mar 2012 21:53:47 +0100 From: Miek Gieben To: dnsext list Message-ID: <20120304205347.GA17454@miek.nl> Mail-Followup-To: dnsext list MIME-Version: 1.0 User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: [dnsext] AD bit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8408982216934539332==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============8408982216934539332== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, As RFC 4035 obsoletes both RFC 3655 and RFC 2535, what document should be used to find the definition of the AD and CD bits in the message header? Regards, --=20 Miek Gieben --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9T1lsACgkQJYuFzziA0Pa7hQCgighKQt37IqbIqLvHWTJr17y5 aDwAn23kgdTDkjnmKGZUjY5ibNF5m+AB =OMPL -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- --===============8408982216934539332== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============8408982216934539332==-- From dnsext-bounces@ietf.org Sun Mar 4 14:12:15 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF22021F8611; Sun, 4 Mar 2012 14:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330899134; bh=P9xhyoAw38tYQQGmVqm2Zetf2ib4R7/ynV2XaQ/mPig=; h=To:From:References:In-reply-to:Date:Message-Id:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=Z+typqdLVzmgwtnRCjBhzPdrgmNp2ZBuN6rLSC/G9Xf+QAKMPgQwBpaUHigkslW75 ije0ZAF2qNJcAKFu2rDGG4KpFyKBMZrmwqiegIji3cm8s7ZBgTumpKiJSp8iDtfeAV vUQqyg5JdnBVXrAnTZ7rUHEJBgJqQLpINFHgY3E0= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788B621F8611 for ; Sun, 4 Mar 2012 14:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv2Brf5YB10W for ; Sun, 4 Mar 2012 14:12:13 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 09E8321F8604 for ; Sun, 4 Mar 2012 14:12:13 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id B4DFDC9427 for ; Sun, 4 Mar 2012 22:11:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:405b:2f42:dc09:6594]) (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 5B4C5216C33 for ; Sun, 4 Mar 2012 22:11: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 B1AA41E090DB for ; Mon, 5 Mar 2012 09:11:52 +1100 (EST) To: dnsext list From: Mark Andrews References: <20120304205347.GA17454@miek.nl> Mail-Followup-To: dnsext list In-reply-to: Your message of "Sun, 04 Mar 2012 21:53:47 BST." <20120304205347.GA17454@miek.nl> Date: Mon, 05 Mar 2012 09:11:52 +1100 Message-Id: <20120304221152.B1AA41E090DB@drugs.dv.isc.org> Subject: Re: [dnsext] AD bit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In message <20120304205347.GA17454@miek.nl>, Miek Gieben writes: > Hello, > > As RFC 4035 obsoletes both RFC 3655 and RFC 2535, what document should > be used to find the definition of the AD and CD bits in the message header? > > Regards, > > -- > Miek Gieben Currently RFC 2535. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 5 14:08:54 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA3D21E8017; Mon, 5 Mar 2012 14:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330985334; bh=nHUR0p0w/ed6ANc1zm0vMLDDgeU83kjOlXxpC5FYAhI=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=w6m2LCuvVuIa+HeXp9uiaDrlUGLw395VTy0e1L0ZBoEJGuXCkCX87354Q15O9rY4o 43UX8teOYuhU0njvNIMajVBxIzPY4/k02StaiBQezxBZOq9BpJI+RJbTRMjhLFEkDN XV9PCvGd2m5r2crkAGQNngdW2c+XXfJlDQWh4R28= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B0821F888D; Mon, 5 Mar 2012 14:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qyR8GPNAhBc; Mon, 5 Mar 2012 14:08:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E146E21F8891; Mon, 5 Mar 2012 14:08:49 -0800 (PST) MIME-Version: 1.0 From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120305220849.26596.7806.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2012 14:08:49 -0800 Cc: dnsext chair , dnsext mailing list , RFC Editor Subject: [dnsext] Protocol Action: 'Elliptic Curve DSA for DNSSEC' to Proposed Standard (draft-ietf-dnsext-ecdsa-07.txt) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org The IESG has approved the following document: - 'Elliptic Curve DSA for DNSSEC' (draft-ietf-dnsext-ecdsa-07.txt) as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-ecdsa/ Technical Summary This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. Working Group Summary Working group has not had any issues with this document, there was some disucussion during the drafts adoption if this was needed. The document editors have been good about addressing any points raised. Consensus is solid. Document Quality The document is well written, there are at least 2 implementations and they interoperate. The document has been stable since being adopted by the working group most of the versions have been to incorporate textual changes of the clarificaiton kind, and the last one addressed ID-nits. Personnel Olafur Gudmundsson is the Document Shepherd. Ralph Droms is the Responsible AD. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Mar 6 08:29:39 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBC721E804A; Tue, 6 Mar 2012 08:29:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331051379; bh=+gH7OC4O6nHx651lPePDqsmBDukNqR8nTeTtqa+27vE=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=URHQu/r+/jNHAeZLu+/fAfW7ki3E+LQzpSnf4O3E2167eS7qAfBkErMR/6r3BGzTP ExgLZjFJhxFf9apy6AFe+e9U/8eVYOq70+AoEDRyvoBjWVyihF/vmB/gNQSyfE4HdJ 5L2Q9un4n+DwUOWwspw6btE6THcR1wBnLbJyKm5o= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2A21F87B6; Tue, 6 Mar 2012 08:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA28QFiYPw-U; Tue, 6 Mar 2012 08:29:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D2F21F8777; Tue, 6 Mar 2012 08:29:35 -0800 (PST) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 08:29:35 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Signaling Cryptographic Algorithm Understanding in DNSSEC Author(s) : Steve Crocker Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-signal-04.txt Pages : 8 Date : 2012-03-06 The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms and hash algorithms they support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Mar 7 00:54:42 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254C621F86A0; Wed, 7 Mar 2012 00:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331110482; bh=xSrZobJl5JaKXRf1Mzue1ZL9pbB6wXhdHPsmMXTF1mg=; h=From:Cc:References:In-Reply-To:Date:Message-ID:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=e3muR3qHsbL/cw9RpJxosdMFiXWnhiCDkX1te2HcqwOe7tyY04Eqx+7rhmJ7ouuED ab9ZwZGwZtemqRMjHZIGjwzofmvFDh6ovzfS0Z4jK79f7dii++Bt6vjDrRpRXhJdaB MYbM5ngeDGpPy4v9xOchyxMp5owmS1saMBIFVrZI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CA121F86A0 for ; Wed, 7 Mar 2012 00:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, MISSING_HEADERS=1.292, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM-r4UX+yv41 for ; Wed, 7 Mar 2012 00:54:40 -0800 (PST) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id ECF8021F85DA for ; Wed, 7 Mar 2012 00:54:39 -0800 (PST) X-ASG-Debug-ID: 1331110760-0369490e9a59570001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id cDNvOpFiajGaEZA5 for ; Wed, 07 Mar 2012 09:59:20 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id E7801E4078 for ; Wed, 7 Mar 2012 09:54:36 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBFyiQ0sGTPA for ; Wed, 7 Mar 2012 09:54:36 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id D5F07E4053 for ; Wed, 7 Mar 2012 09:54:36 +0100 (CET) From: "Marc Lampo" Cc: References: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> In-Reply-To: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> Date: Wed, 7 Mar 2012 09:54:36 +0100 (CET) X-ASG-Orig-Subj: RE: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt Message-ID: <008b01ccfc3f$ec6e69e0$c54b3da0$@lampo@eurid.eu> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Acz7tlEXRY5EuTLJQlOlwrinL3+ZSAAiQL0Q Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1331110760 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Hello, Suggestion. In 6. Traffic Analysis Considerations "... should monitor DNS query traffic and record the values of the DAU/DHU/N3U option(s) in queries. ..." --> Suggest to add that also monitored are : - (number of) DNS Queries, with EDNS0 OPT record, but without any signalling done Motivation : The difference in number of queries with and without Algo-Signalling shows how reliable the signalling information is. Kind regards, Marc Lampo Security Officer EURid (for .eu) -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: 06 March 2012 05:30 PM To: i-d-announce@ietf.org Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Signaling Cryptographic Algorithm Understanding in DNSSEC Author(s) : Steve Crocker Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-signal-04.txt Pages : 8 Date : 2012-03-06 The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms and hash algorithms they support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Mar 7 06:39:19 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8BD21F87F7; Wed, 7 Mar 2012 06:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331131159; bh=fV6FM1PnJgyTHIGA2XLJt6SCZE7sg5qk11MxYBZj5BA=; h=Date:From:To:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=bHAJB1/rtXyoHIgYgohJXx+CTX3O/+jX+77ZbpqqXt8WYlAMitrADggJ+Kk3mBLZD X5NouI+5EtFM651CTXGGqIts3ZszgVwhbQtJYEZqdYvBVBlBaJCVvl/tBSSLoNoUz5 ro4D6uGAzw47U1yfh9yz4GMIZujZgzRjQr5nRXms= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92A921F8633 for ; Wed, 7 Mar 2012 06:39:18 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jRGQ3fNubt7 for ; Wed, 7 Mar 2012 06:39:18 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8A91121F87F7 for ; Wed, 7 Mar 2012 06:39:16 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:55532) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1S5I1L-0000us-DJ (Exim 4.72) for dnsext@ietf.org (return-path ); Wed, 07 Mar 2012 14:39:15 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S5I1L-0003VR-2Z (Exim 4.67) for dnsext@ietf.org (return-path ); Wed, 07 Mar 2012 14:39:15 +0000 Date: Wed, 7 Mar 2012 14:39:15 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: dnsext@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Subject: [dnsext] historical question re WKS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org RFC 2136 specifies some odd special case handling of WKS records, to prevent a name from having more than one WKS record for a given IP address and protocol pair. Where did this requirement come from? I can't find anything along those lines in RFC 1035. Tony. -- f.anthony.n.finch http://dotat.at/ East Dogger, Fisher, German Bight, Humber, Thames, Dover, Wight: Southerly or southwesterly 6 to gale 8, occasionally severe gale 9 at first in Thames and Dover veering westerly or northwesterly 5 to 7. Moderate or rough, occasionally very rough in Fisher. Rain then showers. Moderate or poor, becoming mainly good. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Mar 7 09:27:46 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1995F21E808A; Wed, 7 Mar 2012 09:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331141266; bh=gAlTiqGP4QU5McjUkesG6L4X1M3PE5GXKtzAJR1SCno=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=UKmW9xedGhu6gKmOUavvNn5HzVdebRpqCAUGMG3r5s5env9fu7vttbzVEmmdFdGyX XM2jaW+YlBwSHO0iSygWnkFsiH2e2NHuHMxT9JPDv7TbqQ63+V2Wn05o6ry9DKAUm6 c/X5rVtVWNwwOzCH/rLDP7nGi2f6dUDk8vpsd42A= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871D221E808A for ; Wed, 7 Mar 2012 09:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.324 X-Spam-Level: X-Spam-Status: No, score=-106.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fkAhBpqR1Zj for ; Wed, 7 Mar 2012 09:27:44 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCE121E8035 for ; Wed, 7 Mar 2012 09:27:43 -0800 (PST) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q27HRdoY062391; Wed, 7 Mar 2012 12:27:40 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.178] by Work-Laptop-2.local (PGP Universal service); Wed, 07 Mar 2012 12:27:40 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 07 Mar 2012 12:27:40 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 7 Mar 2012 12:27:34 -0500 To: Tony Finch From: Edward Lewis X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsext@ietf.org Subject: [dnsext] was Re: historical question re WKS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org off-list...because it's not all that useful a reply Generally I know DNS history, but for this I don't. I'd say that 1035 implies there should be only one per IP/protocol from this in 3.4.2: "The WKS record is used to describe the well known services supported by a particular protocol on a particular internet address." Admittedly, that isn't a smoking gun, but it does talk about "particular" protocol and address. You've read the rest. No other hint. I'd chalk this up to the poor documentation native to RFCs. I'd bug Vixie directly if you want to know. At 14:39 +0000 3/7/12, Tony Finch wrote: >RFC 2136 specifies some odd special case handling of WKS records, to >prevent a name from having more than one WKS record for a given IP address >and protocol pair. Where did this requirement come from? I can't find >anything along those lines in RFC 1035. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Mar 7 10:04:14 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991E121E8094; Wed, 7 Mar 2012 10:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331143454; bh=/eMaDZeKN/z5IFq4FWSZbJi+Jq6b80g+sfjR5sFkhao=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=xU89J2YCj1FZgXJvJ65nY652D9nzD2vvSYUex4imne9eOSJet86FdC1IKThzppcE3 SaeSEkP8VdrymyO/6CS/3s7UhFT+9K8Mu9hxd3e2WNygILl3e1JyUj3N+cAyIb+BZv QNe/lHgMHSza3jp3Y6k2Dit23tlTEaJAEQqcDlsI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A13221E80C2 for ; Wed, 7 Mar 2012 10:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.336 X-Spam-Level: X-Spam-Status: No, score=-106.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTHk++xtjB01 for ; Wed, 7 Mar 2012 10:04:12 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 44BA721E80ED for ; Wed, 7 Mar 2012 10:04:10 -0800 (PST) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q27I453x062731; Wed, 7 Mar 2012 13:04:06 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.178] by Work-Laptop-2.local (PGP Universal service); Wed, 07 Mar 2012 13:04:07 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 07 Mar 2012 13:04:07 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 7 Mar 2012 13:03:59 -0500 To: Edward Lewis From: Edward Lewis X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] was Re: historical question re WKS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Oops on-list...still all not that useful. ;) At 12:27 -0500 3/7/12, Edward Lewis wrote: >off-list...because it's not all that useful a reply > >Generally I know DNS history, but for this I don't. I'd say that >1035 implies there should be only one per IP/protocol from this in >3.4.2: > >"The WKS record is used to describe the well known services supported by >a particular protocol on a particular internet address." > >Admittedly, that isn't a smoking gun, but it does talk about >"particular" protocol and address. You've read the rest. No other >hint. I'd chalk this up to the poor documentation native to RFCs. > >I'd bug Vixie directly if you want to know. > >At 14:39 +0000 3/7/12, Tony Finch wrote: >>RFC 2136 specifies some odd special case handling of WKS records, to >>prevent a name from having more than one WKS record for a given IP address >>and protocol pair. Where did this requirement come from? I can't find >>anything along those lines in RFC 1035. > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis >NeuStar You can leave a voice message at +1-571-434-5468 > >2012...time to reuse those 1984 calendars! >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Mar 7 16:50:48 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E897021E801C; Wed, 7 Mar 2012 16:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331167848; bh=wL9WFYc0xEoBQjhE8DQAHJo15u4ARG+ybzC8hGgMGWM=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=B091YqVdoHq5Ww6VXC8Q5xOJkGdDsxw9aJrF1DnZPL1SqPYV9FnHx+FOcKUnJYZka fOiKCLxd7r7wOkO//7/FJF5MywZEIx+z0OOVZD/xO4IFLX+GC+SMvD2+kfLN0TYE69 qlXHd2o2U3luRgjwCComh8vQUa4sakhEe2dlfYtQ= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28B221F8595; Wed, 7 Mar 2012 16:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrv6I73Z819z; Wed, 7 Mar 2012 16:50:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D946111E809F; Wed, 7 Mar 2012 16:50:42 -0800 (PST) MIME-Version: 1.0 From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308005042.21613.5937.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2012 16:50:42 -0800 Cc: dnsext chair , dnsext mailing list , RFC Editor Subject: [dnsext] Protocol Action: 'xNAME RCODE and Status Bits Clarification' to Proposed Standard (draft-ietf-dnsext-xnamercode-00.txt) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org The IESG has approved the following document: - 'xNAME RCODE and Status Bits Clarification' (draft-ietf-dnsext-xnamercode-00.txt) as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-xnamercode/ Technical Summary This memo clarifies how to set the RCODE and how to handle the AD and AA bits when processing chains of CNAMEs, DNAMEs, or any other similar (as yet uninvented) RRTYPE that performs name redirection. It addresses an ambiguity that has persisted in handling of these RRTYPEs since RFC 1034 was published. Working Group Summary This memo was reviewed by five reviewers of the DNS Extensions Working Group. It agrees with other discussions on the DNSEXT mailing list about how to handle these cases. Document Quality The memo agrees with the actual behaviour of many deployed DNS resolvers. Personnel Andrew Sullivan is the Document Shepherd. Ralph Droms is the Responsible AD. RFC Editor Note Please edit the headers for this document to reflect that it updates RFC1035, RFC2672, and RFC2308. Please make the following edits before publication: Rename Section 2: OLD 2. Status Bits NEW 2. Restatement of Status Bits and What They Mean Extend text is first part of Section 2: OLD relate to the first, possible intermediate, and/or last queries, as follows: NEW relate to the first, possible intermediate, and/or last queries, as below. Note that the following is unchanged from RFC 1035 and RFC 4035. The meaning of these bits is simply restated here for clarity, because of observations of released implementations that did not follow these meanings. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Mar 8 02:17:26 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA52A21F8661; Thu, 8 Mar 2012 02:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331201846; bh=GaaVdre9Mdg21TKvSuJD4YJYFSVjbKrOs9CaFBEZkaI=; h=Date:From:To:Message-ID:References:Mime-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=hUdOTEVgLynFnKjP5pHnIxBBJlpjquAV6BVgB7nwMgvHzS15sUUN0VFaIo7Wqwr7E 3c3Ob4wu5vN9TthDBSlLuBpgP2n8U+/e6A96szHPNTt92xlSf0Kw5lLIqkdo0fw4/p H98lc2OlHkSp1Bh4tAYwy5Qx5pqizr4S1E9WIYn8= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733EB21F8661 for ; Thu, 8 Mar 2012 02:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTP8tDyedAaC for ; Thu, 8 Mar 2012 02:17:22 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id C4A9421F8634 for ; Thu, 8 Mar 2012 02:17:21 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q28AHF2D013891; Thu, 8 Mar 2012 10:17:20 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q28AHFw4013890; Thu, 8 Mar 2012 10:17:15 GMT Date: Thu, 8 Mar 2012 10:17:15 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Message-ID: <20120308101715.GA13874@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: dnsext@ietf.org Subject: Re: [dnsext] was Re: historical question re WKS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Wed, Mar 07, 2012 at 01:03:59PM -0500, Edward Lewis wrote: > Oops on-list...still all not that useful. ;) > > >"The WKS record is used to describe the well known services supported by > >a particular protocol on a particular internet address." > > > >I'd bug Vixie directly if you want to know. > > actually, the person to bug would be Mocapetris. WKS predates vixie by several years. this was back when hosts had mutliple NICs and multiple internet addresses. /bill _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Mar 8 06:08:10 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8BF21F870F; Thu, 8 Mar 2012 06:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331215690; bh=QhZ4ch+Sb9JMjYGyJkkqxVVFDzb3nSOZrCs9Zs9An5o=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=S3V7kwHMs+HGPiPEaOam7wAn7yN7J0EOBiUTo5fkyOd+sWHLNJuPSHazqJEMWm/jZ c4zlvV25iXDm2jrGYUPWC0mAigGcPHS6Kgx2pP+CVP4Oa4CoDr21jcAyDxo6Pxq/ny z3FoAvU71m4ujxdd7IcnNl1o3eWJCBfyb2OYXSYU= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD9621F870F for ; Thu, 8 Mar 2012 06:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.348 X-Spam-Level: X-Spam-Status: No, score=-106.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuvo+vQKuw1a for ; Thu, 8 Mar 2012 06:08:07 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id A1FA621F8699 for ; Thu, 8 Mar 2012 06:08:07 -0800 (PST) Received: from jpasq-lt510.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q28E85lK070789; Thu, 8 Mar 2012 09:08:06 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.113] by jpasq-lt510.cis.neustar.com (PGP Universal service); Thu, 08 Mar 2012 09:08:06 -0500 X-PGP-Universal: processed; by jpasq-lt510.cis.neustar.com on Thu, 08 Mar 2012 09:08:06 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120308101715.GA13874@vacation.karoshi.com.> References: <20120308101715.GA13874@vacation.karoshi.com.> Date: Thu, 8 Mar 2012 09:00:14 -0500 To: From: Edward Lewis X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] was Re: historical question re WKS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org At 10:17 +0000 3/8/12, wrote: I meant for knowing what went on with writing 2136, Paul would be as good a source as any - as he co-authored it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Mar 8 07:33:24 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2396F21F877D; Thu, 8 Mar 2012 07:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331220804; bh=DE9iHwqxGrKfz+KXA14/B1j78BgFE4psLJvUhoqi+ho=; h=From:Message-Id:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Bf6HV0NFQ1iOugmdUGJedIySQ3G/QiOn6dmuA1GtLjUzKfez7tvh07EZmIP34m7N0 guFgW1CmBtmfyb5RLDClFobaD8Kiuz3+lZejEEjxS7/niso7G8XLQMVoEGLK89oPIR H0DKvb+INVZyqSI4NU9/3ujeYkI4NsJiGCoJBASg= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EFE21F877D for ; Thu, 8 Mar 2012 07:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.425 X-Spam-Level: X-Spam-Status: No, score=-98.425 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQWwbiQv3OnV for ; Thu, 8 Mar 2012 07:33:21 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id AB91F21F8762 for ; Thu, 8 Mar 2012 07:33:17 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA143780715; Thu, 8 Mar 2012 16:31:55 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA22801; Thu, 8 Mar 2012 16:31:53 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203081531.QAA22801@TR-Sys.de> To: dnsext@ietf.org Date: Thu, 8 Mar 2012 16:31:53 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: Re: [dnsext] AD bit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org At Mon, 05 Mar 2012 09:11:52 +1100, Mark Andrews wrote: > In message <20120304205347.GA17454 at miek.nl>, Miek Gieben writes: >> Hello, >> >> As RFC 4035 obsoletes both RFC 3655 and RFC 2535, what document should >> be used to find the definition of the AD and CD bits in the message header? >> >> Regards, >> >> -- >> Miek Gieben > > Currently RFC 2535. I don't think so. RFCs 4033 and 4035 have obsoleted RFCs 2535 and 3655. We should not give citations of obsolete documents as normative sources. And we _do_ have such sources in this case: Section 3 of RFC 4033 says (emphasis added): |3. Services Provided by DNS Security | | The Domain Name System (DNS) security extensions provide origin | authentication and integrity assurance services for DNS data, | including mechanisms for authenticated denial of existence of DNS | data. These mechanisms are described below. | |> These mechanisms require changes to the DNS protocol. DNSSEC adds | four new resource record types: Resource Record Signature (RRSIG), | DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure |> (NSEC). It also adds two new message header bits: Checking Disabled |> (CD) and Authenticated Data (AD). In order to support the larger DNS | message sizes that result from adding the DNSSEC RRs, DNSSEC also | requires EDNS0 support ([RFC2671]). Finally, DNSSEC requires support | for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a | security-aware resolver can indicate in its queries that it wishes to | receive DNSSEC RRs in response messages. | | [...] RFCs 4033-4035 (+ some more) are the current DNSSEC specifications, and this should make clear that this document set is authoritative for these bits now. RFC 4035 contains copious text in multiple sections specifying the AD and CD bits, in particular Sections 3.1.6, 3.2.2, 3.2.3, 4.6, 4.9.2, 4.9.3. Furthermore, RFC 4035 contains (emphasis added): |6. IANA Considerations | | [RFC4034] contains a review of the IANA considerations introduced by | DNSSEC. The following are additional IANA considerations discussed | in this document: | |> [RFC2535] reserved the CD and AD bits in the message header. The |> meaning of the AD bit was redefined in [RFC3655], and the meaning of |> both the CD and AD bit are restated in this document. No new bits in |> the DNS message header are defined in this document. | | [...] I guess this qualifies for quoting RFC 4035 (or RFCs 4033 and 4035) as the authoritative definition of these bits. The IANA assigned placement information for both bits has been maintained in RFC 6195 and its predecessors as well. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Mar 8 08:11:20 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A2E21F852E; Thu, 8 Mar 2012 08:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331223080; bh=L+T/1Xdzg+AG/aBrX+54MVIzJRaMAdsa0MO31KKfQuI=; h=From:Date:Message-Id:To:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=oM7FkfT5HW+yOVjRU0iB5at8Xg2RJxMP7DJKWCF/iEZwnHd56JiW6TZNEs9I67x/V agfHJIqWHhpmQ9Q0kcqOT/Zzznv8bbw+hvB3Tx3XC1V8T/JDP/UN6m6AS/xR6ITMqX WY1CMEaPPNugV31wrDkKhEtcQKsAJ4pDyP3dwzm0= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D81121F852E for ; Thu, 8 Mar 2012 08:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeYBHgnODSE7 for ; Thu, 8 Mar 2012 08:11:17 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCEE21F8516 for ; Thu, 8 Mar 2012 08:11:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id EC20BB84C8 for ; Thu, 8 Mar 2012 09:11:16 -0700 (MST) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fki2rLMdIdno; Thu, 8 Mar 2012 09:11:16 -0700 (MST) Received: from [10.138.15.14] (unknown [192.168.254.4]) by zimbra.secure64.com (Postfix) with ESMTPSA id 3A2D7B84BD for ; Thu, 8 Mar 2012 09:11:16 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1331223076; bh=ZMbbpR35mXCH2hPka42T7Mal78ovZRQl2kuTFhFRqbs=; h=From:Content-Type:Subject:Date:Message-Id:To:Mime-Version; b=n6LK l2NdrbFHDWxvsWg2QEBorTa1rHVaEviGHZig7neCdId11CuABCYqDiEm3P8u5LHCRI/ cDg+wWenWSosmlB69YvRoEsuknM/yI7swFu/pspvZiLNx0kHtq+fTryVouyXTj4O8L0 RbyqIOfGYfBQ/2mpmWlCgTQSwt7o6t1Yk= From: Joseph Gersch Date: Thu, 8 Mar 2012 09:11:14 -0700 Message-Id: To: dnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dnsext] 2 new drafts relevant to DNS-EXT X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0200783920029965698==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============0200783920029965698== Content-Type: multipart/alternative; boundary="Apple-Mail=_63F94325-22A2-4800-9D4C-C79C74F09F5A" --Apple-Mail=_63F94325-22A2-4800-9D4C-C79C74F09F5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii DNS-EXT members, We have recently submitted two internet drafts for review at the = Paris IETF meeting. =20 The first document, "draft-gersch-dnsop-revdns-cidr-01" describes a = reverse-DNS naming method to specify CIDR address blocks. We will be = presenting this proposal, its motivation and its purpose at the DNS-OP = session on Friday, March 30. The second document, "draft-gersch-grow-revdns-bgp-00" was also = submitted. It describes two new DNS record types that can be used to = specify BGP route origins in the reverse DNS. It uses the domain naming = method described earlier. We will be presenting this at the GROW = session on Friday, March 30, and possibly at the SIDR session on = Wednesday, March 28 as well. Although neither of these drafts were directly submitted to DNS-EXT, = they do propose a DNS naming convention and new DNS record types that = could benefit from the expert review by the members in DNS-EXT. We = encourage you to review these internet drafts and to submit comments to = the DNS-EXT mailing list. =20 If you want to know more about the use of the names and record types, = a live testbed is available at the web site "rover.secure64.com". This = web site contains various documents and slide sets explaining the BGP = publishing and verification methods, as well as the testbed itself with = over 390,000 routes published in an in-addr.arpa shadow zone. You can = submit your own BGP data into the shadow zones if you wish. The web = site also lets you perform queries to verify the origin authenticity of = a BGP announcement. If anyone wants a demo of the testbed during the IETF week, we will be = happy to show how it works; or you can simply create an account and try = it out for yourself at any time. Thanks, Joseph Gersch Dan Massey Eric Osterweil Lixia Zhang --Apple-Mail=_63F94325-22A2-4800-9D4C-C79C74F09F5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
DNS-EXT = members,

   We have recently submitted two = internet drafts for review at the Paris IETF meeting. =  

   The first document, = "draft-gersch-dnsop-revdns-cidr-01" describes a reverse-DNS naming = method to specify CIDR address blocks.  We will be presenting this = proposal, its motivation and its purpose at the DNS-OP session on = Friday, March 30.

  The second document, = "draft-gersch-grow-revdns-bgp-00" was also submitted.  It describes = two new DNS record types that can be used to specify BGP route origins = in the reverse DNS.  It uses the domain naming method described = earlier.   We will be presenting this at the GROW session on = Friday, March 30, and possibly at the SIDR session on Wednesday, March = 28 as well.

  Although neither of these drafts were = directly submitted to DNS-EXT, they do propose a DNS naming convention = and new DNS record types that could benefit from the expert review by = the members in DNS-EXT.  We encourage you to review these internet = drafts  and to submit comments to the DNS-EXT mailing list. =  

  If you want to know more about the use of the = names and record types, a live testbed is available at the web site "rover.secure64.com".  This = web site contains various documents and slide sets explaining the BGP = publishing and verification methods, as well as the testbed itself with = over 390,000 routes published in an in-addr.arpa shadow zone.  You = can submit your own BGP data into the shadow zones if you wish. =   The web site also lets you perform queries to verify the = origin authenticity of a BGP announcement.
If anyone wants a demo of = the testbed during the IETF week, we will be happy to show how it works; = or you can simply create an account and try it out for yourself at any = time.

 Thanks,

Joseph Gersch
Dan Massey
Eric = Osterweil
Lixia Zhang

= --Apple-Mail=_63F94325-22A2-4800-9D4C-C79C74F09F5A-- --===============0200783920029965698== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============0200783920029965698==-- From dnsext-bounces@ietf.org Thu Mar 8 11:16:34 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9636921F85D9; Thu, 8 Mar 2012 11:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331234194; bh=bNgCyDY7lYIKtop9j0fuQD8wzGxWQoOqgr9XszCu0eM=; h=MIME-Version:Date:Message-ID:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=MzdSS7zNDzqPKstacn5rGPVpGy0TBsnxC6pqiuxkc938dG75U/iavnFXF85GT9i0H d5cMjam9nMuCOaPYVUD16wwGgohkTWHmhQNicFzw4EprQOcrs8myaDlI9C2LrrZEko rMi1yKmIzWR1gLgWd2esaCjRuDx6fnLTnSnAi7Ig= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C129721F85D9 for ; Thu, 8 Mar 2012 11:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.347 X-Spam-Level: X-Spam-Status: No, score=-4.347 tagged_above=-999 required=5 tests=[AWL=0.652, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2MpTEMtsXRu for ; Thu, 8 Mar 2012 11:16:32 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A468621F858D for ; Thu, 8 Mar 2012 11:16:32 -0800 (PST) Received: by vbbez10 with SMTP id ez10so796671vbb.31 for ; Thu, 08 Mar 2012 11:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=K6yuc21uO15UzoHFz1ReqH1IAS4ZJZvklGpq871hl20=; b=lyAXSVYwHq2+TOCQTveFqzsw9ozGvIfxnTVAmAlcrLV/qrV22KJwOO3BEs/iQWv1/e z6KczU2E2GLAPJG8Ae4V0yRe544yHAozfcCQaQ3BIIozwZoSxqkiwHxPY2meKVlzDxz6 tfMHxy0227gsFYzkWtIujJ0/TbAlVNMQNlbAg0a598QhvtNwD3692mNBKjVp6y7gVFsb c4lyD7AUf+GQvR5yF9jjb9ggoibawmwK4DsiZ9TVJk7sKjL8mLBz4rHhe5Yw6m/gwD+2 VkXrofpzmSOLdLaC9AZDQYazTOEchm1W+zbk9ix/WZav7+v3V3MTGgatDShEu1g+y6Od Zc2Q== MIME-Version: 1.0 Received: by 10.52.34.65 with SMTP id x1mr11782557vdi.122.1331234192171; Thu, 08 Mar 2012 11:16:32 -0800 (PST) Received: by 10.52.115.66 with HTTP; Thu, 8 Mar 2012 11:16:32 -0800 (PST) Date: Thu, 8 Mar 2012 11:16:32 -0800 Message-ID: From: Ted Hardie To: DNSEXT Working Group Subject: [dnsext] RR review request X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Somewhat amusingly, given the ongoing discussion on whether new RRs are possible/useful/unicorn-friendly, I just published a -00 version of a request for a new RR: draft-hardie-rm-rr (http://tools.ietf.org/html/draft-hardie-rm-rr-00). Comments are welcome; Olaf happened upon it a day or so ago, and his review is below, along with my comments. Google has filed an IPR declaration for this, which is at: https://datatracker.ietf.org/ipr/1702/ . As the document notes, the overall draft structure and some specifics of this draft are lifted wholesale from the URI RR draft that Olaf and Patrik published, and I thank them for the work it saved me. Further in-line. On Wed, Mar 7, 2012 at 3:21 AM, Olaf Kolkman wrote: > > Hello Ted, > > > I stumbled upon draft-hardie-rm-rr-00. > > Hereby a few comments/questions. > > 1. > > =A0"This draft proposes a > =A0 DNS Resource Record for this purpose, with the assumption that it > =A0 would be made available on the public side of any split DNS." > > This seems to suggest that only the public side of a split DNS is where t= he RR gets published. It occurs to me that making that distinction is not n= eeded. > Maybe: > =A0"This draft proposes a DNS RR for publishing how a resource on a LRD c= an be reached." Fair enough. I was not intending to say that it would be available only on the public side of split DNS, so it may be clearer to elide any mention of split DNS here. > > 2. > > =A0"Reachability Method (RM) records can be queried directly, but it is > =A0 expected that they will commonly be returned as additional data by > =A0 servers relating information about hosts that are located within a > =A0 limited reachability domain (e.g. with queries for the A or AAAA > =A0 record associated with a host within an enterprise network). " > > > That is a unrealistic expectation. In order to add RRs to an additional s= ection servers (both authoritative and recursive) need to have the logic to= add these records. > > FWIW, and maybe worth mentioning is that in the split DNS case I can imag= ine that there are no A and AAAA records registered at the external side of= a public DNS (which does not exclude that with the empty-answer section in= the DNS come RRs in the additional section). > > I suggest that you drop the 'additional data' expectation and just count = on the additional query loop. Possibly > It's a good point that recursive servers would also have to have the logic. Obviously you can query for the base record and an RM record in two queries sent at the same time, which limits the timing hit but may make for some coordination issues. wonder if reversing this so that you query for the RM record and get the address itself in the additional section would make this more likely. Any thoughts on that? > =A0 Reachability Method (RM) records are, in general, to be queried direc= tly although > =A0 they might be returned as additional data by > =A0 servers relating information about hosts that are located within a > =A0 limited reachability domain (e.g. with queries for the A or AAAA > =A0 record associated with a host within an enterprise network). > > > > 3. > =A0"If the reachability method varies over time, the TTL of the RM RR > =A0 will need to be managed to match and coordinated with the TTL of the > =A0 resource to be reached. =A0If the reachability method varies according > =A0 to other characteristics, something akin to split DNS must be > =A0 managed, with the usual conflicts with the DNS's core loose > =A0 consistency model." > > What other characteristics are you thinking off? > > One example would be varying the ingress regionally, based on the querier's address; you might do that if the actual resource was actually anycast inside the enterprise network. > > > 4. > > =A0"The target is a URI, enclosed in double-quote characters ('"'). > =A0 Resolution of the URI is according to the definitions for the Scheme > =A0 of the URI. =A0The URI is encoded as one or more > =A0 RFC1035 section 3.3 [RFC1035]" > > Are there i18n aspects to how the domain name portion of the URI is to be= encoded? (Possibly easily solved by a reference). > I think this is covered in the IRI text, but if it is not, please let me kn= ow. > > 5. > > =A0RM as mnemonic > > Although there is no real problem on the wire there might be some confusi= on when using troubleshooting tools like "dig" where the mnemonic might cla= sh with a CCTLD code. > > e.g. > 'dig MX IN CH RM' =A0 =A0(Not that that is a new problem). > > I would suggest a mnemonic that is somewhat longer and has a more limited= chance of clashing with a TLD (although with a gazillion new TLDs that cha= nce might increase)... REACHM might not be that popular as a 180kUS$ TLD. > All the ones I thought of had the similar issues, though not with cctlds (adjunct reachability method=3DARM etc.). If this is judged to be a serious problem, I'll be happy to change it, but I think it's basically possible to hit the problem elsewhere. RM at least is not yet allocated as an ISO 3166 two letter code. Thanks again for the review, Ted > > > --Olaf > > > Feel free to forward to any list on which this is discussed. > > > > > ________________________________________________________ > > Olaf M. Kolkman =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NLnet Labs > http://www.nlnetlabs.nl/ > _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Mar 8 13:13:26 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB36021E8061; Thu, 8 Mar 2012 13:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331241206; bh=gcYVUi46y/wRf64HOBjjvl/y0AkV2d+uIzG9xDPuJUc=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=YyMPVe/gmcEZB5JfU1Iv/XC4B/Y1G1LzZJtuGLAMO54S3kta/nG+oyEsGupoLyLjx uXJ3UXXQeO7GT0HkOlwT8fDe9ZU/0+Oklp0vjhdYIOTcyHNy5bR9MQ67pAoNxVA1J+ IwDiy9R2/5jjxSkTQ9GwMOksbn1V4XpnJeklhnJM= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70F321E8062 for ; Thu, 8 Mar 2012 13:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5hEX7zkWw7Q for ; Thu, 8 Mar 2012 13:13:24 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 26D0021E805D for ; Thu, 8 Mar 2012 13:13:24 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 2DF1D5F9891; Thu, 8 Mar 2012 21:13:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5df4:2bae:698c:ea04]) (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 7489A216C33; Thu, 8 Mar 2012 21:13:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0C4571E33AF8; Fri, 9 Mar 2012 08:12:53 +1100 (EST) To: Alfred =?hp-roman8?B?SM5uZXM=?= From: Mark Andrews References: <201203081531.QAA22801@TR-Sys.de> In-reply-to: Your message of "Thu, 08 Mar 2012 16:31:53 BST." <201203081531.QAA22801@TR-Sys.de> Date: Fri, 09 Mar 2012 08:12:52 +1100 Message-Id: <20120308211254.0C4571E33AF8@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] AD bit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In message <201203081531.QAA22801@TR-Sys.de>, Alfred =?hp-roman8?B?SM5uZXM=?= w rites: > At Mon, 05 Mar 2012 09:11:52 +1100, Mark Andrews wrote: > > In message <20120304205347.GA17454 at miek.nl>, Miek Gieben writes: > >> Hello, > >> > >> As RFC 4035 obsoletes both RFC 3655 and RFC 2535, what document should > >> be used to find the definition of the AD and CD bits in the message header > ? > >> > >> Regards, > >> > >> -- > >> Miek Gieben > > > > Currently RFC 2535. > > I don't think so. > > RFCs 4033 and 4035 have obsoleted RFCs 2535 and 3655. We should > not give citations of obsolete documents as normative sources. [snip] > The IANA assigned placement information for both bits has been > maintained in RFC 6195 and its predecessors as well. I wasn't worried about the use, just the location. The bits locations were defined in RFC 2535. RFC 2535 -> RFC 2929 -> RFC5395 -> RFC6195 When 403[45] replaced RFC 2535 the definition of the location of the bits got orphaned. I guess RFC 4034 should have had RFC 2929 as a normative reference for the location of AD and CD. The rest of the header bits are defined in RFC 1035. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Mar 8 15:36:01 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D3621E802D; Thu, 8 Mar 2012 15:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331249761; bh=RL3nUHZsRlI2q6tPrtBWawBebnIs3Gu+T6gHrI2RIv0=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=vDRZkr1lRf/spcsurTH+DhcW6KoTwujlQTUiEtESMhhsGjSSXaEJGEHLUy/+zZ1lJ Goc76/GuD87cSTQ2HVxycSOHY/ARiMsKpCFWeqhA1kvbTzAtGqxIpHrGV699e4qQx1 fJ1YB/EWfwLETyFudAdNU6vZiMc0Bdon5JGRFIn0= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59C721E802D for ; Thu, 8 Mar 2012 15:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYWtlmDn5NC7 for ; Thu, 8 Mar 2012 15:35:59 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACE821F8607 for ; Thu, 8 Mar 2012 15:35:27 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q28NZN82000832; Thu, 8 Mar 2012 18:35:23 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q28NZMvK000826; Thu, 8 Mar 2012 18:35:23 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 8 Mar 2012 18:35:19 -0500 (EST) From: Samuel Weiler To: Andrew Sullivan In-Reply-To: <20120207151820.GE9478@crankycanuck.ca> Message-ID: References: <20120207151820.GE9478@crankycanuck.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 08 Mar 2012 18:35:24 -0500 (EST) Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org I know that Andrew posted a closing summary of this discussion. I'm quoting the opening message since it provides much more context. There are a couple of these default actions that I'm uneasy with. On Tue, 7 Feb 2012, Andrew Sullivan wrote: > ISSUE 3: Alter section 5.10 > > Paul Hoffman requests a change to section 5.10 in > http://www.ietf.org/mail-archive/web/dnsext/current/msg12173.html. > Speaking only personally, I cannot see any objection to the proposed > sentence, "If a site has only a single trust anchor, the information > in this entire section can safely be skipped." I'm less sure about > the motivational sentences; I'm not even sure they're true. Does > anyone have any thoughts? > > DEFAULT ACTION: Include the "If a site has only a single trust > anchor ?" sentence, and exclude the other proposed sentences. If this document were aimed at operators, the above would make more sense. Since this is a doc for implementers, the "ignore this section" guidance is dangerous -- the implementer of a validating resolver does not know what trust anchor(s) an operator will configure. I prefer to not include this sentence. > ISSUE 4: Request to change the language in 5.6 > > This is also a request from Paul Hoffman, in the same review. Is > there any objection to his first formulation? I believe his second > formulation would actually be a significant change to the protocol, > and as shepherd I cannot accept it without a fairly strong signal from > the WG. > > DEFAULT ACTION: Use the first formulation proposed ("In order to > interoperate with implementations that ignore this rule on > sending, resolvers need to allow either the DO bit to be set or > unset when receiving responses.") I think the two formulations are equivalent, except that the second is stated in clearer and more normative language. Yes, this is a change, but it's one we need to make. Let's use the less muddled form of it. -- Sam _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Mar 8 16:25:37 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E4B21E801B; Thu, 8 Mar 2012 16:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331252737; bh=K5EQ18GFCga0ApRrsnYUuxhUXdSvxzlOdUcPhRCfljM=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=mHkCuy+8KVrKl48OfpiKPsSw7RP6lPuAT/g+ed3vac63IlABJftFfXrdEsrJkhxUk xsAcp3wgP1RhQbcIGUR+OT18MTQKnsatlsXz6M32IJXyz51zwz26CBvRUnZn7h5je+ qwcpf7EoSXY2v0jLSTps7X9Yx2DyWdKcoE63lHlc= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D3021E801B for ; Thu, 8 Mar 2012 16:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFu4Toxv2DTF for ; Thu, 8 Mar 2012 16:25:35 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CF3C621E800C for ; Thu, 8 Mar 2012 16:25:35 -0800 (PST) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q290PVfn085150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Mar 2012 17:25:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Thu, 8 Mar 2012 16:25:30 -0800 Message-Id: References: <20120207151820.GE9478@crankycanuck.ca> To: Samuel Weiler X-Mailer: Apple Mail (2.1257) Cc: dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mar 8, 2012, at 3:35 PM, Samuel Weiler wrote: > I know that Andrew posted a closing summary of this discussion. I'm quoting the opening message since it provides much more context. > > There are a couple of these default actions that I'm uneasy with. > > > On Tue, 7 Feb 2012, Andrew Sullivan wrote: > >> ISSUE 3: Alter section 5.10 >> >> Paul Hoffman requests a change to section 5.10 in >> http://www.ietf.org/mail-archive/web/dnsext/current/msg12173.html. >> Speaking only personally, I cannot see any objection to the proposed >> sentence, "If a site has only a single trust anchor, the information >> in this entire section can safely be skipped." I'm less sure about >> the motivational sentences; I'm not even sure they're true. Does >> anyone have any thoughts? >> >> DEFAULT ACTION: Include the "If a site has only a single trust >> anchor ?" sentence, and exclude the other proposed sentences. > > If this document were aimed at operators, the above would make more sense. Since this is a doc for implementers, the "ignore this section" guidance is dangerous -- the implementer of a validating resolver does not know what trust anchor(s) an operator will configure. I prefer to not include this sentence. This is actually a good point. I withdraw my previous wording, and suggest instead that the following be added as a separate paragraph before 5.10.1: When not presented with the situation that more than one trust anchor is configured, DNSSEC validators SHOULD NOT expose policy choices such as those shown in these subsections in configuration options. That is, these policy choices SHOULD only be exposed when there are multiple options. >> ISSUE 4: Request to change the language in 5.6 >> >> This is also a request from Paul Hoffman, in the same review. Is >> there any objection to his first formulation? I believe his second >> formulation would actually be a significant change to the protocol, >> and as shepherd I cannot accept it without a fairly strong signal from >> the WG. >> >> DEFAULT ACTION: Use the first formulation proposed ("In order to >> interoperate with implementations that ignore this rule on >> sending, resolvers need to allow either the DO bit to be set or >> unset when receiving responses.") > > I think the two formulations are equivalent, except that the second is stated in clearer and more normative language. Yes, this is a change, but it's one we need to make. Let's use the less muddled form of it. FWIW, I agree with Sam here: my second proposal ("Because some implementations ignore this rule on sending, the rule for receivers is now that they MUST NOT expect the DO bit to be set as it was sent.") is the one I prefer. I proposed the first because I thought the second would be hard for some people to swallow. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Mar 8 17:05:21 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A801021E8061; Thu, 8 Mar 2012 17:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331255121; bh=1VM2LI+qWYqXduhoJ8hQlZhw4lmymYHE+9JIvqMew0Q=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ciD4jYNu5C43JIkfoS9eX91ZMJ6js/fcgo3FCehq/KPBGntsMmWzo1+6E7IxG1cQP BY6X2tHUowjj81Qlc7CMcpMk/Vk1e2W+G0r8DV/sDIh9yriUJPG77spyZ9Fo68GO4g nbkzEPtjhpBMri7IY3G/zhNnpO0KwHfZxAmHtOYY= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC17021E801A for ; Thu, 8 Mar 2012 17:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+HjENPMaY32 for ; Thu, 8 Mar 2012 17:05:19 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1277821E8010 for ; Thu, 8 Mar 2012 17:05:18 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3E8931ECB420; Fri, 9 Mar 2012 01:05:17 +0000 (UTC) Date: Thu, 8 Mar 2012 20:05:15 -0500 From: Andrew Sullivan To: Paul Hoffman Message-ID: <20120309010514.GD88825@mail.yitter.info> References: <20120207151820.GE9478@crankycanuck.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Samuel Weiler , dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Thu, Mar 08, 2012 at 04:25:30PM -0800, Paul Hoffman wrote: > On Mar 8, 2012, at 3:35 PM, Samuel Weiler wrote: > > This is actually a good point. I withdraw my previous wording, and suggest instead that the following be added as a separate paragraph before 5.10.1: > > When not presented with the situation that more than one trust > anchor is configured, DNSSEC validators SHOULD NOT expose policy > choices such as those shown in these subsections in configuration > options. That is, these policy choices SHOULD only be exposed > when there are multiple options. I am opposed to that text. If the WG really strongly wants it, I'll withdraw my objection, but I'm strongly opposed to it because I find it both confusing and untestable. I know what this is about, and I still had to read that twice to parse it. Also, what would be a case where a validator might permit this? When is it ok? And so on. Moreover, I don't think we should be trying to boss around people and tell them how to make their software: if 50 years of evidence in favour of eliminating pointless options in software hasn't taught us to do it yet, I see no hope that a confusing paragraph in an RFC is going to push us over the top. > >> DEFAULT ACTION: Use the first formulation proposed ("In order to > >> interoperate with implementations that ignore this rule on > >> sending, resolvers need to allow either the DO bit to be set or > >> unset when receiving responses.") > > > > I think the two formulations are equivalent, except that the > > second is stated in clearer and more normative language. Yes, > > this is a change, but it's one we need to make. Let's use the > > less muddled form of it. > > > FWIW, I agree with Sam here: my second proposal ("Because some > implementations ignore this rule on sending, the rule for receivers > is now that they MUST NOT expect the DO bit to be set as it was > sent.") is the one I prefer. I proposed the first because I thought > the second would be hard for some people to swallow. > My reasoning was that the first formulation, though more awkward and so on, is not actually a protocol change. The second formulation is. The first one says, "People are violating this bit of the protocol, and you should know about that and act according to how you think best." The second one says, "The protocol said that you could rely on this, and now you MUST NOT." I think that an actual protocol change, no matter how teensy we might think it is, needs evidence that the WG agrees; so far, we have one commenter and two document editors, but nobody else who's spoken on it. Therefore, WG participants, if you agree with Sam's proposed change please weigh in. Otherwise, I don't feel very comfortable sending it to the IESG, and will have to highlight this change in the PROTO write-up. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Mar 8 18:07:45 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FD221F84EF; Thu, 8 Mar 2012 18:07:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331258865; bh=IKWuEl+jdPAPXewjs/SEM+fyRgvcK1T1rkq4hvKRi3Y=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lDbRkze5jD5BQOP441WdwBgSKGNHTdeiSPJj7Pe+9d1JQnw2ImYQHInP0iqBQ/ax1 j8A6019UoJWyvtp8PsOMyW0uEv+gHvUGiJrAKWr8Sf9i58/umCyYWZlSquBBN9NCWb 11hG5fPvxPf7CFiSogTt1TZpPYMTeVO8G2iNMx8Y= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B714021F84EF for ; Thu, 8 Mar 2012 18:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbTbsk0MLFmV for ; Thu, 8 Mar 2012 18:07:43 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD3621F84E7 for ; Thu, 8 Mar 2012 18:07:43 -0800 (PST) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2927cHU088143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Mar 2012 19:07:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <20120309010514.GD88825@mail.yitter.info> Date: Thu, 8 Mar 2012 18:07:38 -0800 Message-Id: References: <20120207151820.GE9478@crankycanuck.ca> <20120309010514.GD88825@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: Samuel Weiler , dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mar 8, 2012, at 5:05 PM, Andrew Sullivan wrote: > On Thu, Mar 08, 2012 at 04:25:30PM -0800, Paul Hoffman wrote: >> On Mar 8, 2012, at 3:35 PM, Samuel Weiler wrote: >> >> This is actually a good point. I withdraw my previous wording, and suggest instead that the following be added as a separate paragraph before 5.10.1: >> >> When not presented with the situation that more than one trust >> anchor is configured, DNSSEC validators SHOULD NOT expose policy >> choices such as those shown in these subsections in configuration >> options. That is, these policy choices SHOULD only be exposed >> when there are multiple options. > > I am opposed to that text. If the WG really strongly wants it, I'll > withdraw my objection, but I'm strongly opposed to it because I find > it both confusing and untestable. I know what this is about, and I > still had to read that twice to parse it. Also, what would be a case > where a validator might permit this? When is it ok? And so on. > > Moreover, I don't think we should be trying to boss around people and > tell them how to make their software: if 50 years of evidence in > favour of eliminating pointless options in software hasn't taught us > to do it yet, I see no hope that a confusing paragraph in an RFC is > going to push us over the top. OK, I can see that. Maybe we should just drop my original objection. >>>> DEFAULT ACTION: Use the first formulation proposed ("In order to >>>> interoperate with implementations that ignore this rule on >>>> sending, resolvers need to allow either the DO bit to be set or >>>> unset when receiving responses.") >>> >>> I think the two formulations are equivalent, except that the >>> second is stated in clearer and more normative language. Yes, >>> this is a change, but it's one we need to make. Let's use the >>> less muddled form of it. >> >> >> FWIW, I agree with Sam here: my second proposal ("Because some >> implementations ignore this rule on sending, the rule for receivers >> is now that they MUST NOT expect the DO bit to be set as it was >> sent.") is the one I prefer. I proposed the first because I thought >> the second would be hard for some people to swallow. >> > > My reasoning was that the first formulation, though more awkward and > so on, is not actually a protocol change. The second formulation is. > The first one says, "People are violating this bit of the protocol, > and you should know about that and act according to how you think > best." The second one says, "The protocol said that you could rely on > this, and now you MUST NOT." I think that an actual protocol change, > no matter how teensy we might think it is, needs evidence that the WG > agrees; so far, we have one commenter and two document editors, but > nobody else who's spoken on it. Therefore, WG participants, if you > agree with Sam's proposed change please weigh in. Otherwise, I don't > feel very comfortable sending it to the IESG, and will have to > highlight this change in the PROTO write-up. I agree with Andrew that this is a protocol change. I agree with Sam that this proposed change is clearer than the wording Andrew chose from my first message. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Mar 8 19:57:08 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A6A21E803D; Thu, 8 Mar 2012 19:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331265427; bh=VH1pgqYugHyA5HxMg94Y9ZUsG2fyN6eZxH/NDPlOuY4=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=doivx3qgSfbAiBg6oAYQ85cvOSeuBZOeD8KNSEYRbDbGGT2U1ZdFHnztSrBqqpOIA r4x2pcpA2k/fbhOTyEg7eLfYiXK1UAJfTc4olTos7hTzQCWiZ5vy4GgenZPe8g2JL8 6wFQUyboTWA3azM03hlRY8aX/cdxnd3RzyJPIBAM= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A5821E8043 for ; Thu, 8 Mar 2012 19:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkSLznGpuqFf for ; Thu, 8 Mar 2012 19:57:06 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E1521E801C for ; Thu, 8 Mar 2012 19:57:05 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 857DC1DA; Thu, 8 Mar 2012 19:57:04 -0800 (PST) From: Wes Hardaker To: Paul Hoffman References: <20120207151820.GE9478@crankycanuck.ca> Date: Thu, 08 Mar 2012 19:57:01 -0800 In-Reply-To: (Paul Hoffman's message of "Thu, 8 Mar 2012 16:25:30 -0800") Message-ID: <0lipieh1f6.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Cc: Samuel Weiler , dnsext@ietf.org Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org >>>>> On Thu, 8 Mar 2012 16:25:30 -0800, Paul Hoffman said: PH> When not presented with the situation that more than one trust PH> anchor is configured, DNSSEC validators SHOULD NOT expose policy PH> choices such as those shown in these subsections in configuration PH> options. That is, these policy choices SHOULD only be exposed PH> when there are multiple options. The problem with the wording is that you're really trying to say something that dictates software implementation practices. And this is nearly impossible to get right because most software stacks really can't do what you want. Specifically, if a software stack accepts a configuration file as an input for policy knobs there is no way you "SHOULD NOT expose" knobs based on the number of trust anchors defined somewhere else in the file. Wouldn't it be better to state your actual intentions? It is recommended (RECOMMENDED?) that the policy options in the following subsections only be configured when multiple trust anchors are also configured. If someone is writing a GUI configuration set (ha ha, like those exist), then they can actually hide things. Otherwise it's up to the operator to not use the knobs in the section when writing a config file. -- Wes Hardaker SPARTA, Inc. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 9 01:07:54 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798C421F85F1; Fri, 9 Mar 2012 01:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331284074; bh=FP/1FjQGfznkHvPHg4HeJ+jwBm5r/rGle6twh4tTDq4=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=Hex3Bi5J2YBDkjOswbGr2Vd/JattMJ+Pi01z9viIyV18ZuDugQ3ijya0QRLkD+/rE oo2Z3FEWUo1bgU2apbe6naUX7c7SrKzgZzJ1k4WqImUV3OBDAVyPARxLmfoG2UgEbM BAhPQfcwzL9R7v8lAayAj1WMvI2nlsVoww6yDsX4= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21CB21F85AE for ; Fri, 9 Mar 2012 01:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDBf9uX6ZcyU for ; Fri, 9 Mar 2012 01:07:52 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4127E21F85F1 for ; Fri, 9 Mar 2012 01:07:51 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 93A3540004; Fri, 9 Mar 2012 10:07:48 +0100 (CET) Date: Fri, 9 Mar 2012 10:07:48 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120309090748.GA20102@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> MIME-Version: 1.0 In-Reply-To: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2836241423611916510==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============2836241423611916510== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting at 08:29 on Mar 6 in "[dnsext] I-D Ac= tion:..." ] >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the DNS Extensions Working Group of the= IETF. >=20 > Title : Signaling Cryptographic Algorithm Understanding in DNS= SEC > Author(s) : Steve Crocker > Scott Rose > Filename : draft-ietf-dnsext-dnssec-algo-signal-04.txt > Pages : 8 > Date : 2012-03-06 >=20 > The DNS Security Extensions (DNSSEC) were developed to provide origin > authentication and integrity protection for DNS data by using digital > signatures. These digital signatures can be generated using > different algorithms. This draft sets out to specify a way for > validating end-system resolvers to signal to a server which > cryptographic algorithms and hash algorithms they support. I read a comment in the draft that this option list can get very long, which indeed is true.=20 How about the following scheme: A resolver indicates the highest algorithm number it understands and thus *= also* all *previous* algorithms. This way the whole option can be shortened to 4 bytes: 0: OPTION-CODE 1: DAU byte value 2: DHU byte value 3: N3U byte value And maybe this option can be renamed to Crypto Understood. A drawback is that a number of current specified features aren't available with this scheme. Regards, Miek Gieben --DocE+STaALJfprDB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9ZyGQACgkQJYuFzziA0PaxvgCgiP42YKhLVMRSFoOIwT2fXz62 JH4AoPdXKkHvZG0h6sQ66GlBFoXxvt06 =vTtF -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- --===============2836241423611916510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============2836241423611916510==-- From dnsext-bounces@ietf.org Fri Mar 9 05:11:35 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D4A21F865D; Fri, 9 Mar 2012 05:11:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331298695; bh=hXys6Ud/BssN8CKruyLzeSmNJUF4VpD5qtc52iKUvhA=; h=From:Message-Id:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=hD3VO7VhAEGhgpsSJqGGtaQQhD4FH3pque/8WjxDbOCJa0bklDrxc9vukMOpzZHhQ IF8bQ0uIEB3NL4grw0wmRGiUWq6gH7gvQ/9NUzEMjazhDgOr44qwbJB94jHE2krdxF DqLj+jAlvYLSy7b/ZV2tixbjxnbRrKfjp4xna3ks= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F41521F865D for ; Fri, 9 Mar 2012 05:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.446 X-Spam-Level: X-Spam-Status: No, score=-98.446 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eub2T2-kaDGV for ; Fri, 9 Mar 2012 05:11:33 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id A687321F865C for ; Fri, 9 Mar 2012 05:11:32 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA149248628; Fri, 9 Mar 2012 14:10:28 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA28601; Fri, 9 Mar 2012 14:10:27 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203091310.OAA28601@TR-Sys.de> To: dnsext@ietf.org Date: Fri, 9 Mar 2012 14:10:26 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-03.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Rm9sa3MsCkkgaGF2ZSBzdWJtaXR0ZWQgYSByZXZpc2VkIHZlcnNpb24gb2Ygb3VyIFJGQyAxOTk1 YmlzIChJWFJGKSBkcmFmdC4KCkFzIGRpc2N1c3NlZCBhdCB0aGUgTWFhc3RyaWNodCAoSUVURiA3 OCkgYW5kIFByYWd1ZSAoSUVURiA4MCkKRE5TRVhUIHNlc3Npb25zLCB0aGlzIHRvcGljIGlzIHJl Z2FyZGVkIGFzIGNvdmVyZWQgYnkgdGhlCmNoYXJ0ZXJlZCB3b3JrIGl0ZW0gZm9yIEROU0VYVCB2 b3ZlcmluZyBJWEZSLU9OTFkuCgpUaGUgbmV3IHZlcnNpb24gdHJpZXMgdG8gY2FwdHVyZSB0aGUg b3V0Y29tZSBvZiB0aGUgb24tbGlzdApkaXNjdXNzaW9uIChhbmQgc29tZSBpbnRlcm5hbCBjb252 ZXJzYXRpb25zKSBzaW5jZSB0aGUgcG9zdGluZwpvZiB0aGUgLTAyIHZlcnNpb24gbGFzdCBzcHJp bmcsIGFmdGVyIElFVEYgODAsIGluIHBhcnRpY3VsYXIKdGhlIHJlbGF0ZWQgdGhyZWFkcyBvbiBu YW1lZHJvcHBlcnMgaW4gSnVuZS9BdWd1c3QgMjAxMS4KTXkgYXBvbG9naWVzIGZvciB0aGUgZGVs YXlzIGluIHRoZSBlZGl0b3JpYWwgd29yay4KClRvIGFsbG93IGJldHRlciB0aHJlYWRpbmcgb2Yg cmVsYXRlZCBsaXN0IHN1Ym1pc3Npb25zLCBJIHdpbGwgcG9zdAp0d28gbW9yZSBtZXNzYWdlcyBy ZWdhcmRpbmc6CgphKSB0aGUgY2hhbmdlcyBmcm9tIC0wMiB0byAtMDMgOyBhbmQKCmIpIHRoZSBu ZXh0IHN0ZXBzIHdpdGggdGhpcyBkcmFmdC4KCgpQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQg dGhlIGNoYW5nZXMgYW5kIG9wdCBmb3IgdGhlIG5leHQgc3RlcHMKdG8gdW5kZXJ0YWtlIHdpdGgg dGhlIEktRCwgYXMgd2lsbCBiZSBkZXRhaWxlZCBzb29uIGluIHRoZXNlCnVwY29taW5nIG1lc3Nh Z2VzLgoKCi0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIGZyb20gaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIC0tLS0tCgo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZwo+IFRvOiBhaEBUUi1T eXMuZGUKPiBDYzogb25kcmVqLnN1cnlAbmljLmN6Cj4gTWVzc2FnZS1JZDogPDIwMTIwMzA5MTIx MjI3LjIxMzQxLjk3NzcuaWR0cmFja2VyQGlldGZhLmFtc2wuY29tPgo+IERhdGU6IEZyaSwgMDkg TWFyIDIwMTIgMDQ6MTI6MjcgLTA4MDAKPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWFoLWRuc2V4dC1yZmMxOTk1YmlzLWl4ZnItMDMudHh0Cj4KPiBBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtYWgtZG5zZXh0LXJmYzE5OTViaXMtaXhmci0wMy50eHQKPiBo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFsZnJlZCBIb2VuZXMgYW5kIHBvc3Rl ZAo+IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuCj4KPiBGaWxlbmFtZTogICAgICAgIGRyYWZ0LWFo LWRuc2V4dC1yZmMxOTk1YmlzLWl4ZnIKPiBSZXZpc2lvbjogICAgICAgIDAzCj4gVGl0bGU6ICAg ICAgICAgICBETlMgSW5jcmVtZW50YWwgWm9uZSBUcmFuc2ZlciBQcm90b2NvbCAoSVhGUikKPiBD cmVhdGlvbiBkYXRlOiAgIDIwMTItMDMtMDkKPiBXRyBJRDogICAgICAgICAgIEluZGl2aWR1YWwg U3VibWlzc2lvbgo+IE51bWJlciBvZiBwYWdlczogMzIKPgo+IEFic3RyYWN0Ogo+ICAgIFRoZSBz dGFuZGFyZCBtZWFucyB3aXRoaW4gdGhlIERvbWFpbiBOYW1lIFN5c3RlbSBwcm90b2NvbCBmb3IK PiAgICBtYWludGFpbmluZyBjb2hlcmVuY2UgYW1vbmcgYSB6b25lJiMzOTtzIGF1dGhvcml0YXRp dmUgbmFtZSBzZXJ2ZXJzCj4gICAgY29uc2lzdHMgb2YgdGhyZWUgbWVjaGFuaXNtcy4gIEluY3Jl bWVudGFsIFpvbmUgVHJhbnNmZXIgKElYRlIpIGlzCj4gICAgb25lIG9mIHRoZSBtZWNoYW5pc21z IGFuZCBvcmlnaW5hbGx5IHdhcyBkZWZpbmVkIGluIFJGQyAxOTk1Lgo+Cj4gICAgVGhpcyBkb2N1 bWVudCBhaW1zIHRvIHByb3ZpZGUgYSBtb3JlIGRldGFpbGVkIGFuZCB1cC10by1kYXRlCj4gICAg c3BlY2lmaWNhdGlvbiBvZiB0aGUgSVhGUiBtZWNoYW5pc20gYW5kIHRvIGFsaWduIGl0IHdpdGgg dGhlIGN1cnJlbnQKPiAgICBzcGVjaWZpY2F0aW9uIG9mIHRoZSBwcmltYXJ5IHpvbmUgdHJhbnNm ZXIgbWVjaGFuaXNtLCBBWEZSLCBnaXZlbiBpbgo+ICAgIFJGQyA1OTM2LiAgRnVydGhlciwgYmFz ZWQgb24gb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSwgdGhpcyBkb2N1bWVudAo+ICAgIGp1eHRhcG9z ZXMgdG8gdGhlIG9yaWdpbmFsIElYRlIgcXVlcnkgYSBuZXcgcXVlcnkgdHlwZSwgSVhGUi1PTkxZ LAo+ICAgIHRoYXQgd2lsbCBsaWtlbHkgYmUgcHJlZmVycmVkIG92ZXIgSVhGUiBpbiBzcGVjaWZp YyBkZXBsb3ltZW50cy4KPgo+ICAgIFRoaXMgZG9jdW1lbnQgb2Jzb2xldGVzIGFuZCByZXBsYWNl cyBSRkMgMTk5NS4KPgo+Cj4gVGhlIElFVEYgU2VjcmV0YXJpYXQKCi0tLS0tIEVuZCBvZiBmb3J3 YXJkZWQgbWVzc2FnZSBmcm9tIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyAtLS0tLQoKClRoZSBk cmFmdCBhbmQgZGlmZnMgYXJlIGF2YWlsYWJsZSBvbmxpbmUgYXQgdGhlIGNvbW1vbiBsb2NhdGlv bnMsCmluY2x1ZGluZyB0aGUgSUVURiBUb29scyBwYWdlOgogIDxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1haC1kbnNleHQtcmZjMTk5NWJpcy1peGZyLTAzPgoKCktpbmQgcmVnYXJk cywKICBBbGZyZWQgSM5uZXMuCgotLSAKCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnwgVFItU3lzIEFsZnJlZCBI b2VuZXMgICB8ICBBbGZyZWQgSG9lbmVzICAgRGlwbC4tTWF0aC4sIERpcGwuLVBoeXMuICB8Cnwg R2VybGluZ2VyIFN0cmFzc2UgMTIgICB8ICBQaG9uZTogKCs0OSk3MTU2Lzk2MzUtMCwgRmF4OiAt MTggICAgICAgICB8CnwgRC03MTI1NCAgRGl0emluZ2VuICAgICB8ICBFLU1haWw6ICBhaEBUUi1T eXMuZGUgICAgICAgICAgICAgICAgICAgICB8CistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkbnNleHQgbWFpbGluZyBsaXN0CmRu c2V4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ruc2V4 dAo= From dnsext-bounces@ietf.org Fri Mar 9 05:22:27 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9206221F8642; Fri, 9 Mar 2012 05:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331299347; bh=U/34Jt7W7O7MoNIgZniePvWCRQkTKXhDiKpBD6LGMow=; h=From:Message-Id:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=fkwHfJ0Tj8Txh6PgqvHvsKmCN8DbinDu6Y+oSl+2QKrpt+r24zRrMOxUJZO0YTAG0 k7JDqOD9sLIfB0JG4F/BWi5yCJQuRvGqh75d3egLyMGTQv1vSFy/O8tLO5IbfOQ/C6 jscZxavoTD4KdIkkwesFi1y8QU5cd+9Z/iA4OXQI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E0521F8642 for ; Fri, 9 Mar 2012 05:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.463 X-Spam-Level: X-Spam-Status: No, score=-99.463 tagged_above=-999 required=5 tests=[AWL=1.286, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlEBgX6hpAKe for ; Fri, 9 Mar 2012 05:22:26 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id F026821F85D2 for ; Fri, 9 Mar 2012 05:22:24 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA149379281; Fri, 9 Mar 2012 14:21:21 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA28689; Fri, 9 Mar 2012 14:21:20 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203091321.OAA28689@TR-Sys.de> To: dnsext@ietf.org Date: Fri, 9 Mar 2012 14:21:20 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- next steps? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org DNSEXT folks, draft-ah-dnsext-rfc1995bis-ixfr-03 represents the latest step in the process started with the IETF 78 meeting discussion that lead to the encouragement/invitation to me and Ondrej to prepare an updated specification document for IXFR that at once integrates Ondrej Sury and Shane Kerr's IXFR-ONLY proposal, in fulfillment of a chartered work item thence calling for work on revised specifications for DNS zone synchronization mechanisms (in the interim re-worded to explicitly mention IXFR-ONLY). On the mailing list and at the Prague meeting, the draft has repeatedly been offered to the WG for adoption as a WG draft, but the discussion every time has prematurely evaded into elaborations on details instead of deciding on adaption first, as envisioned in the Working Group Procedures RFCs. Now, given the efforts already put into the development of the document, and given the impending closure of DNSEXT, we see two possible paths to follow: A) The WG quickly (on-list and/or in Paris) comes to affirmative consensus on I-D adaption. In this case, we can quickly re-post the I-D as a WG draft (once I-D submission re-opens during IETF), if that is deemed necessary under the given circumstances. We would then like the chairs to immediately issue a formal WGLC call for the document, in order to quickly proceed in the fulfillment of the last open chartered work item of DNSEXT. B) Otherwise. In this case, we intend to proceed with the draft as an individual, AD-sponsored draft -- and Andrew already has indicated his willingness to actively support this path. We'd then like the chairs to organize and quickly execute a pseudo-WGLC for the present draft version on the dnsext list. Given the perceived exhaustiveness of the discussion last held summer and the apparent rough technical consensus achieved, and also seeing the support of multiple active operators and implementers for the draft, we do not expect significant changes to be necessary, but are willing to quickly produce one more draft version before approching a suitable AD with a publication request for the draft. We hope that, backed by the pseudo-WGLC, the process could be smooth and fast, leading to an IETF-wide LC before IESG processing. To this end, we'd like to solicit quick feedback on how to proceed. Also speaking for Ondrej (and inofficially for Shane Kerr as well, the co-author of the original IXFR-ONLY proposal backing us up a bit behind the scenes), Alfred. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 9 07:27:27 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CF721F86AA; Fri, 9 Mar 2012 07:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331306847; bh=ZdpN64bwDo1IvUWOVRfsH8o9sFkAWjgZxhELdW4Exw8=; h=From:Message-Id:To:Date:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=XyRkZTnjZMKf9ga8qK2zEKnQ3DWs1MNcBtbFEJJWtRjV9Jrf28qOHP6YpvbG7W39N tUjCQTNrrNAvgpbYY/gAlnnDB/5BpYw/AKSUgVCqfmaWFC25oeNfvKr9muwBcImdq0 1HNdlRBVLqvNQRwORpAHoYz/PLyzW6Hrct46116M= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD6D21F8483 for ; Fri, 9 Mar 2012 05:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.535 X-Spam-Level: X-Spam-Status: No, score=-98.535 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ8-d3RwaQL0 for ; Fri, 9 Mar 2012 05:23:37 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id C98E821F8645 for ; Fri, 9 Mar 2012 05:23:35 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA149339206; Fri, 9 Mar 2012 14:20:06 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA28674; Fri, 9 Mar 2012 14:20:04 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203091320.OAA28674@TR-Sys.de> To: dnsext@ietf.org Date: Fri, 9 Mar 2012 14:20:04 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 X-Mailman-Approved-At: Fri, 09 Mar 2012 07:27:25 -0800 Cc: vixie@isc.org, Ed.Lewis@neustar.biz, fweimer@bfk.de Subject: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- changes since -02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org For quick information, below I present some excerpts from the draft, giving: o the newly added Ack clause; o Appendix B, the essential change summary since RFC 1995; and o Appendix C, which presents the list discussion evaluation and change record since version -02. My apologies again for not being able to respond in time to the postings of last summer; I hope this summary represents a valid substitute for belated answer messages to all the list participants listed in the quoted new paragraph of the Acknowledgements Section. -------- excerpts from draft-ah-dnsext-rfc1995bis-ixfr-03 -------- 11. Acknowledgements [...] {newly added:} Discussions of the draft on the dnsext list have directed the evolution of this document; in particular, we acknowledge (in alphabetical order) Mark Andrews, Brian Dickson, Shane Kerr, Edward Lewis, Josh Littlefield, Masataka Ohta, Paul Vixie, and Wouter Wijngaards for their comments and reviews. [...] Appendix B. Substantial Changes Since RFC 1995 This is a summary of the substantial changes since RFC 1995 [RFC1995]. o Corrected a few technical flaws: incorrect comparison with AXFR; improper impled requirement of performing SOA query over UDP; improper reference to transfer of partial RRs in a response message corrected (to be read as transfer of partial RRsets in a response message -- as it has always been understood by implementers, since STD 13 requires only entire RRs to be present in DNS messages). o New specification based on the revised AXFR specification, RFC 5936 [RFC5936]. o Many clarifications and details supplied, text vastly reorganized and expanded, but no (intentional) technical deviation from the previous specification, as understood by implementers. o Addition of new IXFR-ONLY protocol variant, based on operational experience and perceived need. o Major additions to Security Considerations. o Historical example dropped (incompatible with IESG policy on examples). Instead, abstract examples have been added to Section 2. Appendix C. Evaluation of List Discussion, Draft Changes since -02 [[ Temporary Section, to be deleted in next draft version. ]] The previous (-02) version of this draft has been extensively discussed on the dnsext mailing list during the June through August 2011 timeframe. Due to temporary unavailability of the primary author, the concensus-building based on that discussion is summed up below, instead of flooding the mailing list with a bunch of (very belated) response messages. Messages are quoted below as "{msgNNNNN}", based on the message numbers (NNNNN -- a 5-digit number) assigned in the list archive using URIs following the pattern . {msg11353}, item 1: It is claimed frequently that IETF documents are too "microscopic" in their perspective and do not give the "glue" context information allowing even a non-specialized reader to see how the specified functionality relates to other parts of protocols, deployment, and common usage. Therefore, like in the kindred AXFR document, RFC 5936, context information for the invocation of IXFR is given in the draft -- btw, in a style that resembles descriptions given in the basic DNS Standards, RFCs 1034 and 1035. If zones don't change, and no NOTIFYs are sent, IXFR isn't needed. As RFC 1996 (NOTIFY) indicates, NOTIFY was intended as the primary trigger for IXFR requests, and that's what this draft re-states from the perspective of IXFR. Minor editorial changes have been performed. {msg11353}, item 2, {msg11359} and more messages down the thread: As has been pointed out by Brian D. (et al.) in {msg11354}, {msg11363} (and follow-up discussion), the term "Fallback to AXFR" describes IXFR server behavior specified in RFC 1995 and present in all major DNS server implementations. Overall, substantial discussion apparently has been caused by confusion about the (admittedly a bit colloquial) term "Fallback to AXFR". Another thread on this behavior was started by Mark A. ({msg11373} ff.). To clarify and resolve this issue, a definition for this term has been added to Section 1.4. The justification for clarifications to the present IXFR specification and the need for interoperably specified IXFR-ONLY has been reinforced by several contributors, e.g. Brian D., Mark A., and Masataka O. ({msg11354}, {msg11355}, {msg11356}, {msg11365}, ff.). We have not found any indications in the draft text where the detailed specification of (classical) IXFR would contradict RFC 1995, and it has been indicated on the list that the draft also correctly reflects the on-the-wire IXFR behavior of all major implementations represented by active participants on the list. {msg11353}, final item: IMO, RFC 1995 would have deserved at least 3 Technical Errata and roughly a dozen Editorial Errata, and it lacks a lot of precidion, so we agree that a refresh of this original specification should be welcome. The suggested additional test by DNSSEC-aware IXFR clients of the RRSIG(SOA) RRset now is mentioned in a newly added paragraph of Section 7.1 (that section is referred to in the Security Considerations). {msg11373}, {msg11374} and follow-ups: The draft already represents in detail the different possible responses on an IXFR query that have been inherent in RFC 1995. If (and only if) the IXFR server can respond with a single DNS response packet, the IXFR transaction can be carried out successfully over UDP, and hence is a "single response mechanism". Otherwise, the IXFR client has to be redirected to TCP, as described in (RFC 1995 and) the draft. This is independent of whether the IXFR server then has to fall back to full-zone transfer. There might be a (very unlikely) corner case, where the IXFR server wants to fall back to full-zone transfer *and* this transfer can be performed in a single response packet. Admittedly, that's rather unlikely, and in this case, IXFR-ONLY behavior would be causing additional overhead and message exchanges. Therefore, clauses has been added to Section 2 and Section 3.2 that in this corner case, the response to IXFR-ONLY MAY be a full-zone transfer over UDP, for the sake of overall performance. Otherwise, no significant changes to the text have been performed in this respect. {msg11376} ff.: Aborting an IXFR session over TCP likely does not waste so much resources on the IXFR client side (which initiates the premature closing of the TCP connection), but it takes much more time for the IXFR server to be notified of this closure, and up to then, it will have wasted resources to generate and buffer response packets that will either never be received or not even sent. Further, if a persistent TCP connection is desired, e.g. for an IXFR client that regularly has to update numerous zones from the same (candidate) IXFR server, re-establishment and subsequent TCP slow-start of a new TCP connection will be actually detrimental to the overall zone update performance. This is another reason why IXFR-ONLY promises substantial performance improvements that cannot be achieved without protocol enhancements. Since only modern DNS implementations are expected to implement IXFR-ONLY (which are expected to support EDNS anyway), because extended message sizes are very useful for IXFR in general (which also requires EDNS), and to reduce the pressure on the narrow basic RCODE namespace (only 5 codepoints still available for assignment), the draft now assumes that an extended RCODE value for CannotIXFR will suffice. The running text and IANA Considerations have been adjusted accordingly. Consequentially, the draft now specifies that an IXFR-ONLY query without an OPT RR will be rejected by the IXFR server with FormErr. Paul V. ({msg13379}) pointed out the detriments of message sizes above 16k (loss of ability to perform message compression). Added Note to Section 3 explaining this hint. A few adjustments regarding use of RFC 2119 language have been performed. Appendix B, which sums up the important changes since RFC 1995, has been added, as needed per IESG policy. References have been updated. Numerous editorial changes and enhancements have been applied. Vertical spacing tweeked to avoid dangling orphan lines at page breaks. ------ end of excerpts from draft-ah-dnsext-rfc1995bis-ixfr-03 ------ Please review the changes and/or the entire document if you haven't before. Comments are welcome in response to this message, on dnsext and/or in off-list messages to the authors. The next steps for this draft should be discussed in a parallel thread that will be started immediately, with suitable Subject: . Kind regards, Alfred. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 9 07:52:59 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33F821F86E4; Fri, 9 Mar 2012 07:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331308379; bh=0O2zvxJGST4DGp13xhxinpv7oBFbbIeFV4O2TGCbuf4=; h=From:Message-Id:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=W1Xxr5GEcrF83l4yyva8F4TTolpiZ3IA8E0e72UYYxGbG5Zy3ysRI3girSFIxBCmM 3pMJEbq1eK01PX957QwiPsmCHmnbv9Iy5hbjnEy2S+oY9f3s9SSeonjxX8DSRsPRfo aX5RQOnZzhKqwySyyRONlty4rN6aL2QuHOmwdnvs= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD9521F86E4 for ; Fri, 9 Mar 2012 07:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.546 X-Spam-Level: X-Spam-Status: No, score=-98.546 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZN7KYf7aoZ-8 for ; Fri, 9 Mar 2012 07:52:42 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5852621F865C for ; Fri, 9 Mar 2012 07:52:40 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA151468297; Fri, 9 Mar 2012 16:51:37 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA29718 for dnsext@ietf.org; Fri, 9 Mar 2012 16:51:36 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203091551.QAA29718@TR-Sys.de> To: dnsext@ietf.org Date: Fri, 9 Mar 2012 16:51:35 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- changes since -02 [resent] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Resent due to original message getting caught in moderation; sorry for duplicates! -------- For quick information, below I present some excerpts from the draft, giving: o the newly added Ack clause; o Appendix B, the essential change summary since RFC 1995; and o Appendix C, which presents the list discussion evaluation and change record since version -02. My apologies again for not being able to respond in time to the postings of last summer; I hope this summary represents a valid substitute for belated answer messages to all the list participants listed in the quoted new paragraph of the Acknowledgements Section. -------- excerpts from draft-ah-dnsext-rfc1995bis-ixfr-03 -------- 11. Acknowledgements [...] {newly added:} Discussions of the draft on the dnsext list have directed the evolution of this document; in particular, we acknowledge (in alphabetical order) Mark Andrews, Brian Dickson, Shane Kerr, Edward Lewis, Josh Littlefield, Masataka Ohta, Paul Vixie, and Wouter Wijngaards for their comments and reviews. [...] Appendix B. Substantial Changes Since RFC 1995 This is a summary of the substantial changes since RFC 1995 [RFC1995]. o Corrected a few technical flaws: incorrect comparison with AXFR; improper impled requirement of performing SOA query over UDP; improper reference to transfer of partial RRs in a response message corrected (to be read as transfer of partial RRsets in a response message -- as it has always been understood by implementers, since STD 13 requires only entire RRs to be present in DNS messages). o New specification based on the revised AXFR specification, RFC 5936 [RFC5936]. o Many clarifications and details supplied, text vastly reorganized and expanded, but no (intentional) technical deviation from the previous specification, as understood by implementers. o Addition of new IXFR-ONLY protocol variant, based on operational experience and perceived need. o Major additions to Security Considerations. o Historical example dropped (incompatible with IESG policy on examples). Instead, abstract examples have been added to Section 2. Appendix C. Evaluation of List Discussion, Draft Changes since -02 [[ Temporary Section, to be deleted in next draft version. ]] The previous (-02) version of this draft has been extensively discussed on the dnsext mailing list during the June through August 2011 timeframe. Due to temporary unavailability of the primary author, the concensus-building based on that discussion is summed up below, instead of flooding the mailing list with a bunch of (very belated) response messages. Messages are quoted below as "{msgNNNNN}", based on the message numbers (NNNNN -- a 5-digit number) assigned in the list archive using URIs following the pattern . {msg11353}, item 1: It is claimed frequently that IETF documents are too "microscopic" in their perspective and do not give the "glue" context information allowing even a non-specialized reader to see how the specified functionality relates to other parts of protocols, deployment, and common usage. Therefore, like in the kindred AXFR document, RFC 5936, context information for the invocation of IXFR is given in the draft -- btw, in a style that resembles descriptions given in the basic DNS Standards, RFCs 1034 and 1035. If zones don't change, and no NOTIFYs are sent, IXFR isn't needed. As RFC 1996 (NOTIFY) indicates, NOTIFY was intended as the primary trigger for IXFR requests, and that's what this draft re-states from the perspective of IXFR. Minor editorial changes have been performed. {msg11353}, item 2, {msg11359} and more messages down the thread: As has been pointed out by Brian D. (et al.) in {msg11354}, {msg11363} (and follow-up discussion), the term "Fallback to AXFR" describes IXFR server behavior specified in RFC 1995 and present in all major DNS server implementations. Overall, substantial discussion apparently has been caused by confusion about the (admittedly a bit colloquial) term "Fallback to AXFR". Another thread on this behavior was started by Mark A. ({msg11373} ff.). To clarify and resolve this issue, a definition for this term has been added to Section 1.4. The justification for clarifications to the present IXFR specification and the need for interoperably specified IXFR-ONLY has been reinforced by several contributors, e.g. Brian D., Mark A., and Masataka O. ({msg11354}, {msg11355}, {msg11356}, {msg11365}, ff.). We have not found any indications in the draft text where the detailed specification of (classical) IXFR would contradict RFC 1995, and it has been indicated on the list that the draft also correctly reflects the on-the-wire IXFR behavior of all major implementations represented by active participants on the list. {msg11353}, final item: IMO, RFC 1995 would have deserved at least 3 Technical Errata and roughly a dozen Editorial Errata, and it lacks a lot of precidion, so we agree that a refresh of this original specification should be welcome. The suggested additional test by DNSSEC-aware IXFR clients of the RRSIG(SOA) RRset now is mentioned in a newly added paragraph of Section 7.1 (that section is referred to in the Security Considerations). {msg11373}, {msg11374} and follow-ups: The draft already represents in detail the different possible responses on an IXFR query that have been inherent in RFC 1995. If (and only if) the IXFR server can respond with a single DNS response packet, the IXFR transaction can be carried out successfully over UDP, and hence is a "single response mechanism". Otherwise, the IXFR client has to be redirected to TCP, as described in (RFC 1995 and) the draft. This is independent of whether the IXFR server then has to fall back to full-zone transfer. There might be a (very unlikely) corner case, where the IXFR server wants to fall back to full-zone transfer *and* this transfer can be performed in a single response packet. Admittedly, that's rather unlikely, and in this case, IXFR-ONLY behavior would be causing additional overhead and message exchanges. Therefore, clauses has been added to Section 2 and Section 3.2 that in this corner case, the response to IXFR-ONLY MAY be a full-zone transfer over UDP, for the sake of overall performance. Otherwise, no significant changes to the text have been performed in this respect. {msg11376} ff.: Aborting an IXFR session over TCP likely does not waste so much resources on the IXFR client side (which initiates the premature closing of the TCP connection), but it takes much more time for the IXFR server to be notified of this closure, and up to then, it will have wasted resources to generate and buffer response packets that will either never be received or not even sent. Further, if a persistent TCP connection is desired, e.g. for an IXFR client that regularly has to update numerous zones from the same (candidate) IXFR server, re-establishment and subsequent TCP slow-start of a new TCP connection will be actually detrimental to the overall zone update performance. This is another reason why IXFR-ONLY promises substantial performance improvements that cannot be achieved without protocol enhancements. Since only modern DNS implementations are expected to implement IXFR-ONLY (which are expected to support EDNS anyway), because extended message sizes are very useful for IXFR in general (which also requires EDNS), and to reduce the pressure on the narrow basic RCODE namespace (only 5 codepoints still available for assignment), the draft now assumes that an extended RCODE value for CannotIXFR will suffice. The running text and IANA Considerations have been adjusted accordingly. Consequentially, the draft now specifies that an IXFR-ONLY query without an OPT RR will be rejected by the IXFR server with FormErr. Paul V. ({msg13379}) pointed out the detriments of message sizes above 16k (loss of ability to perform message compression). Added Note to Section 3 explaining this hint. A few adjustments regarding use of RFC 2119 language have been performed. Appendix B, which sums up the important changes since RFC 1995, has been added, as needed per IESG policy. References have been updated. Numerous editorial changes and enhancements have been applied. Vertical spacing tweeked to avoid dangling orphan lines at page breaks. ------ end of excerpts from draft-ah-dnsext-rfc1995bis-ixfr-03 ------ Please review the changes and/or the entire document if you haven't before. Comments are welcome in response to this message, on dnsext and/or in off-list messages to the authors. The next steps for this draft should be discussed in a parallel thread that will be started immediately, with suitable Subject: . Kind regards, Alfred. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 9 09:37:12 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1410021E8027; Fri, 9 Mar 2012 09:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331314632; bh=3ejoggV6MmGo4vRVBmYz0DY51kIXq9wa7eOH4WgRxw8=; h=MIME-Version:Message-ID:Date:To:In-Reply-To:References:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=x+gRqB4o80S5aPSglMT/OSqyNndVBBmyFvsjzCefu2SOCzj1QYRN1LDUrrNYvHBqC 7dp5Um6CCJhjoBb3syUUoNH5NhqUHQ08G6M0BYfE/yRawPAANvTc8aojGQ/p25g8X2 Fc6AKfMD02eP34KWd2PysFp4t6HviGRGAvWkJhfs= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481FF21E8027 for ; Fri, 9 Mar 2012 09:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUBJDQVX62Jn for ; Fri, 9 Mar 2012 09:37:09 -0800 (PST) Received: from gunk.araneus.fi (gunk.araneus.fi [166.84.6.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6044121F86D5 for ; Fri, 9 Mar 2012 09:37:09 -0800 (PST) Received: from guava.gson.org (guava.gson.org [10.0.11.2]) by gunk.araneus.fi (Postfix) with ESMTP id 966F31D0C03; Fri, 9 Mar 2012 17:37:04 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 0392675E5E; Fri, 9 Mar 2012 19:37:01 +0200 (EET) MIME-Version: 1.0 Message-ID: <20314.16317.950807.748833@guava.gson.org> Date: Fri, 9 Mar 2012 19:37:01 +0200 To: Alfred Hoenes In-Reply-To: Re: <201203091310.OAA28601@TR-Sys.de> References: <201203091310.OAA28601@TR-Sys.de> X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf) From: Andreas Gustafsson Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Alfred Hoenes wrote: > I have submitted a revised version of our RFC 1995bis (IXRF) draft. Regrettably, I haven't had time to respond to the previous versions of the draft, but based on a quick review of the -03 version, I think it still has problems. In particular, Section 4 (Response Contents) specifies client behavior where decisions are made based on an RR occurring alone in a message, or multiple RRs occurring in the same message, which makes the locations of the boundaries between messages significant. For example, the draft says: > An IXFR client that receives over connection-oriented transport > an IXFR response message (as the first response message related > to its IXFR query) that contains only a single SOA RR with sn_n > unequal to sn_o MUST discard the response message (see below). and: > c. The server serial (sn_n) differs from the client serial (sn_o) > sent in the Authority section of the IXFR query, and this SOA RR > is followed by another SOA RR in the same response message. The way I have always interpreted RFC 1995 is that the message boundaries have no significance to the protocol, and that a server can break up the ordered stream of RRs forming the IXFR response into messages at arbitrary points without affecting client behavior. This interpretation seems consistent with AXFR, and with the following text in the draft: > The conceptional "answer" carried in a multi-message response is the > concatenation of the content of the Answer sections in these response > messages, in the order they are sent I don't think the current Section 4 accurately describes the behavior of existing implementations (at least not the ones I am familiar with), nor does it appear to be fully interoperable with those implementations. For example, existing servers will send a message of the form described in the first quoted paragraph above when the second RR in the transfer is too large to fit in the same message as the initial SOA, and may conceivably also do it in other circumstances, such as when that second RR exceeds the 16k compression limit. Existing clients will accept such a response, but a client following the draft will not. -- Andreas Gustafsson, gson@araneus.fi _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 9 10:07:05 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1EB21E806F; Fri, 9 Mar 2012 10:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331316425; bh=ag6N7cqlDmCspz8PFuNvhNMtN79HQDY+WgIBcIZwxMc=; h=From:Message-Id:To:Date:In-Reply-To:Mime-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Ls8cHKSENHHDLCHoqeb8I7MVpmaHL5h3F00T+BD7ji7DhxNCIUK/LUzyPsCgqI1ei t2GZNB43YgUDCw7W1ngbglOJWSi+y09GVoUMZNvW86bz6oFHCxWgy2yfNUMCfwEYi+ XyKLfZ6FAXgPoFvGiS+VjcAWEf311afCmQGpH+Ss= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A541F21E806F for ; Fri, 9 Mar 2012 10:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.556 X-Spam-Level: X-Spam-Status: No, score=-98.556 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXjAp4ydO-Cc for ; Fri, 9 Mar 2012 10:07:03 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id E1C0B21E806C for ; Fri, 9 Mar 2012 10:07:01 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA152216358; Fri, 9 Mar 2012 19:05:58 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA00481; Fri, 9 Mar 2012 19:05:57 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203091805.TAA00481@TR-Sys.de> To: gson@araneus.fi Date: Fri, 9 Mar 2012 19:05:56 +0100 (MEZ) In-Reply-To: <20314.16317.950807.748833@guava.gson.org> from Andreas Gustafsson at Mar "9, " 2012 "07:37:01" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Andreas, thanks for your taking time so quickly now to look into the I-D. Before entering into the details of later Sections, I think we should establish a solid base. So to start with there, my questions are: Is the high-level description given in Section 2 ... a) logically correct (from your point of view) ? b) consistent with the terse text in RFC 1995 ? c) consistent observed on-the-wire format, and hence with implementations ? If you disagree, please give the details. But if that's correct, we have the problem that the established response syntax unfortunately does not allow precise parsing without knowledge of where the end of the response is. Based on this insight, the draft tries to describe behavior that depends on a minimum amount of timing/grouping requirements, yet still allows "fast" determination of the response mode and correct parsing of the IXFR response in all corner cases, without having to rely on precious waiting time in order to determine whether the last response packet received is indeed the last response packet the server has sent. IMO, unfortunately, not all response modes defined in RFC 1995 carry an implied "end tag" (sentinel SOA RR, as in AXFR). So please allow me to defer going into the details below until we have established consensus on the above basic points as laid out in Section 2. Once this has been done, the client's parsing behavior model described in Section 4 can be discussed much more efficiently. Kind regards, Alfred. > Alfred Hoenes wrote: >> I have submitted a revised version of our RFC 1995bis (IXRF) draft. > > Regrettably, I haven't had time to respond to the previous versions of > the draft, but based on a quick review of the -03 version, I think it > still has problems. > > In particular, Section 4 (Response Contents) specifies client behavior > where decisions are made based on an RR occurring alone in a message, > or multiple RRs occurring in the same message, which makes the > locations of the boundaries between messages significant. For > example, the draft says: > >> An IXFR client that receives over connection-oriented transport >> an IXFR response message (as the first response message related >> to its IXFR query) that contains only a single SOA RR with sn_n >> unequal to sn_o MUST discard the response message (see below). > > and: > >> c. The server serial (sn_n) differs from the client serial (sn_o) >> sent in the Authority section of the IXFR query, and this SOA RR >> is followed by another SOA RR in the same response message. > > The way I have always interpreted RFC 1995 is that the message > boundaries have no significance to the protocol, and that a server can > break up the ordered stream of RRs forming the IXFR response into > messages at arbitrary points without affecting client behavior. This > interpretation seems consistent with AXFR, and with the following text > in the draft: > >> The conceptional "answer" carried in a multi-message response is the >> concatenation of the content of the Answer sections in these response >> messages, in the order they are sent > > I don't think the current Section 4 accurately describes the behavior > of existing implementations (at least not the ones I am familiar > with), nor does it appear to be fully interoperable with those > implementations. For example, existing servers will send a message of > the form described in the first quoted paragraph above when the second > RR in the transfer is too large to fit in the same message as the > initial SOA, and may conceivably also do it in other circumstances, > such as when that second RR exceeds the 16k compression limit. > Existing clients will accept such a response, but a client following > the draft will not. > -- > Andreas Gustafsson, gson@araneus.fi > _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 9 11:01:57 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669DF21E807E; Fri, 9 Mar 2012 11:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331319717; bh=UZdTUXhbjvW4iXmrdv410lcFTBmMxe0Z/2fR6V8C5m4=; h=From:Message-Id:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=A8tK+7WsvpfdxseBRGyg0Ph2vYmpt/TKLi4ky8hI/BD15BfrG7tr9yXHCqazU+oVd SgHv50S9wVCMMoLW/tmTuxPNLBvi6PcTSKAGNqE1UhYTc642LSnFjjoGaCM/YKSYKi obbe2JvaK6i6hLUWuT9FQWrw89VQ3dZvpuQItxa8= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C172221E8095 for ; Fri, 9 Mar 2012 11:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.565 X-Spam-Level: X-Spam-Status: No, score=-98.565 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E2vqIw89Wbm for ; Fri, 9 Mar 2012 11:01:54 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5C06221E804B for ; Fri, 9 Mar 2012 11:01:53 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA152519632; Fri, 9 Mar 2012 20:00:32 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA00760; Fri, 9 Mar 2012 20:00:31 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203091900.UAA00760@TR-Sys.de> To: dnsext@ietf.org Date: Fri, 9 Mar 2012 20:00:31 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- questions on s3.2.3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Folks -- in particular implementers, A point has been raised, and for qualified action, the draft authors need more information and opinions on this part of the draft: |3.2. IXFR Response | |[...] | |3.2.3. Answer Section | | The Answer section MUST be populated with the zone change information | or, in the case of fallback to AXFR, the full zone contents. | | For multi-message IXFR responses, the conceptional answer is split | into segments that are sent in order. Each segment is comprised of |> an integer number of full RRs, and for transport efficiency, the |> response messages should be filled up with answer RRs as much as ^^^^^^ |> possible for the response message size chosen by the IXFR server, |> taking into account the space needed for the other sections in the |> messages. | | [...] Questions: a) Does the behavior described in the emphasized sentence make sense, given the optimisation goals underlying the IXFR design ? b) Do existing implementations follow this direction ? c) Shall we replace the tagged "should" by a "SHOULD", to make the recommendation even stronger ? Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 9 11:20:29 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED7B21F8673; Fri, 9 Mar 2012 11:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331320828; bh=ilDhqiT1L5a4Ncd3oIcZSuqWEw8ignToWslxstfBCH8=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lSDeuz/B0wFFU+Bg9i9Zzs3WAV/PScXHHrn7kZ9Tnrvxjc7eAL3sPCP1KhKZVPmZO fx15K9NolSb9maA3Y/aDDqjWa8C+yInbsNOLtRS+6qxxpN7ZB8UV9KTPx96o6xsXer uO5966XvSC/01RW0n804nG1LZpf9Ny/frOv3jQ/k= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F288321F8629 for ; Fri, 9 Mar 2012 11:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.337 X-Spam-Level: X-Spam-Status: No, score=-106.337 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAG6yn-wTRKo for ; Fri, 9 Mar 2012 11:20:27 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 9901321F8617 for ; Fri, 9 Mar 2012 11:20:26 -0800 (PST) Received: from dhcp-172-19-119-93.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id BFF1B1B41BBA; Fri, 9 Mar 2012 14:20:25 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) From: Warren Kumari In-Reply-To: <201203091321.OAA28689@TR-Sys.de> Date: Fri, 9 Mar 2012 14:20:23 -0500 Message-Id: <99A58E22-5626-42EA-9C95-D9C884D095E9@kumari.net> References: <201203091321.OAA28689@TR-Sys.de> To: =?iso-8859-1?Q?Alfred_H=CEnes?= X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- next steps? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mar 9, 2012, at 8:21 AM, Alfred H=CEnes wrote: > DNSEXT folks, > = > [ SNIP ] > = > A) The WG quickly (on-list and/or in Paris) comes to affirmative > consensus on I-D adaption. I have read (and discussed) the draft and (still) support adoption.... W > = > In this case, we can quickly re-post the I-D as a WG draft > (once I-D submission re-opens during IETF), if that is deemed > necessary under the given circumstances. > = > We would then like the chairs to immediately issue a formal > WGLC call for the document, in order to quickly proceed in > the fulfillment of the last open chartered work item of DNSEXT. > = > B) Otherwise. > = > In this case, we intend to proceed with the draft as an > individual, AD-sponsored draft -- and Andrew already has > indicated his willingness to actively support this path. > = > We'd then like the chairs to organize and quickly execute a > pseudo-WGLC for the present draft version on the dnsext list. > = > Given the perceived exhaustiveness of the discussion last held > summer and the apparent rough technical consensus achieved, > and also seeing the support of multiple active operators and > implementers for the draft, we do not expect significant changes > to be necessary, but are willing to quickly produce one more > draft version before approching a suitable AD with a publication > request for the draft. We hope that, backed by the pseudo-WGLC, > the process could be smooth and fast, leading to an IETF-wide LC > before IESG processing. > = > = > To this end, we'd like to solicit quick feedback on how to proceed. > = > = > Also speaking for Ondrej (and inofficially for Shane Kerr as well, > the co-author of the original IXFR-ONLY proposal backing us up a bit > behind the scenes), > = > Alfred. > = > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > = _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 9 12:35:04 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A592B21E8040; Fri, 9 Mar 2012 12:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331325304; bh=9W4ilWOMV/9d6LjGqoFeVlyCkVYPSfMLc7IGAXqrRuQ=; h=From:Message-Id:To:Date:In-Reply-To:Mime-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=aN+ALnUw/FysrimEYBDNGrJlxsE8vI5NCusqdhYRnlfZIoxgfIOAD6iNEwmHrAxT7 XyF9gV+EOk13MX3sktX6mQousceVLsY2iUWj7lS2yQhq9zSKdmwZPUpowEDOCLZlbE iIK1UH3/YpG3UvFONcuSnpgWJ++oQjpdfItz5XEc= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC6721E8084 for ; Fri, 9 Mar 2012 12:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.574 X-Spam-Level: X-Spam-Status: No, score=-98.574 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoDs9ZxiAR+W for ; Fri, 9 Mar 2012 12:35:02 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 87C3D21E8080 for ; Fri, 9 Mar 2012 12:35:01 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA153045238; Fri, 9 Mar 2012 21:33:58 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA02764; Fri, 9 Mar 2012 21:33:56 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203092033.VAA02764@TR-Sys.de> To: mohta@necom830.hpcl.titech.ac.jp Date: Fri, 9 Mar 2012 21:33:56 +0100 (MEZ) In-Reply-To: <4F5A582E.8090902@necom830.hpcl.titech.ac.jp> from Masataka Ohta at Mar "10, " 2012 "04:21:18" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- changes since -02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Masataka Ohta just wrote: > Alfred wrote: > >> ... > > Do you mean you gave up presenting any meaningful use cases? Masataka-san, There have been complaints that the draft already shows much too much context and it should better be stripped down to a pure specification document ignoring any applicability questions. I have argued in favor of keeping this "glue" text showing how IXFR fits into the entire picture. Are you now saying it should also present some kind of detailed use case analysis or applicability statement, far beyond what is said in Section 1 and Appendix A (motivation -- by existing use cases -- for IXFR-ONLY)? I fear this would likely disqualify the document for Standards Track. Do you want that? Otherwise, someone else might undertake the effort of writing a companion applicability statement draft targeting Informational RFC. Listening to operators so far, I have not heard about perceived need for such a document, but you are cordially invited to submit a draft, if you think it is needed and worth the effort. > Then, we have no reason to waste our time to read the unrevised > draft. > > Masataka Ohta Readers are invited to independently evaluate the question whether the draft is "unrevised" based on the draft diffs readily available from: Kind regards, Alfred. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sat Mar 10 01:31:16 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C0821F8613; Sat, 10 Mar 2012 01:31:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331371876; bh=/XF4whSwkiYZiAmuo4NUGK79FdOreuczK6fwCvp+NoQ=; h=Message-ID:Date:MIME-Version:To:In-Reply-To:References:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=SAMk+M+JH49tcWLP0mH5W/ZU5FblGF2NGWP5jw+1ANnyvBy8SIjaD3cYltWxe4Uef Gj1caIVxmvt7f0sF6VuuHlUs164kJNF98lHt+asRToxlZvHywF0PXgQIObpQO1JRVU F/YK2XrttcvwkqW5wInOAJAfQvwbOtSd5SCvZ/9E= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD0621F8613 for ; Sat, 10 Mar 2012 01:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8qVB42f1V6i for ; Sat, 10 Mar 2012 01:31:14 -0800 (PST) Received: from gunk.araneus.fi (gunk.araneus.fi [166.84.6.82]) by ietfa.amsl.com (Postfix) with ESMTP id CC90A21F84DA for ; Sat, 10 Mar 2012 01:31:13 -0800 (PST) Received: from guava.gson.org (guava.gson.org [10.0.11.2]) by gunk.araneus.fi (Postfix) with ESMTP id BB80B1D01FF; Sat, 10 Mar 2012 09:31:14 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id B3D2E75E5D; Sat, 10 Mar 2012 11:31:11 +0200 (EET) Message-ID: <20315.8031.421902.340349@guava.gson.org> Date: Sat, 10 Mar 2012 11:31:11 +0200 MIME-Version: 1.0 To: Alfred Hoenes In-Reply-To: <201203091805.TAA00481@TR-Sys.de> References: <20314.16317.950807.748833@guava.gson.org> <201203091805.TAA00481@TR-Sys.de> X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf) From: Andreas Gustafsson Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Alfred Hoenes wrote: > Before entering into the details of later Sections, > I think we should establish a solid base. > > So to start with there, my questions are: > > Is the high-level description given in Section 2 ... > a) logically correct (from your point of view) ? > b) consistent with the terse text in RFC 1995 ? > c) consistent observed on-the-wire format, and hence with > implementations ? There are some issues with section 2 also, such as defining the condition of a client being up-to-date as sn_o = sn_n, when it should be sn_o >= sn_n (in the RFC 1982 sense). But apart from that, I think it is sufficiently correct to be used as a basis for the present discussion regarding the significance of message boundaries in classifying responses. > But if that's correct, we have the problem that the established > response syntax unfortunately does not allow precise parsing > without knowledge of where the end of the response is. It has been a long time since I last implemented IXFR, but I think the following procedure should work: If the response is over UDP, and the first RR in the response is a SOA whose serial is greater than the client serial, and the response contains no further RRs, then we have case (b) of the draft, "response too large for UDP". This is the only place where we must determine whether or not an RR is followed by further RRs, and although that is not possible in the TCP case (without making message boundaries significant, or by resorting to timeouts or such), it is possible in the UDP case because UDP responses can only consist of a single message. Otherwise, examine the first RR in the response, which must be a SOA. If its serial is less than or equal to the client serial, we have case (a), "up to date". Otherwise, examine the second RR in the response. If it is not a SOA, we have case (d), "fallback to AXFR". Otherwise, we have a response beginning with two SOA RRs, which is case (c), with sub-cases as discussed in the draft. Some of the sub-cases of (c) may need further discussion, but let's first see if we can come to an agreement regarding the overall algorithm for classifying responses into the four classes (a) through (d) in the draft. -- Andreas Gustafsson, gson@araneus.fi _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Mar 11 03:02:37 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653B621F8665; Sun, 11 Mar 2012 03:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331460157; bh=oSEEceMZntb+4sq9HEW2sdfPv8dyFAgD4q0yNPc4mdo=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=JOkwmf1b6X43RMAHrnuYinHMaITbDRqgJuN3jh7DiPhtcNKZu5ZmEbZudpJDr/ygB ZJPCbutdbh+Z5jO/0dFh1iQ2c6u658/42rXb4aA4L8OP6uKo/AR5OfJffeDjdYwaxr AJ1ErZ8ZKIWMYwx99oXNSRVbnXN12FJMO16a0hsY= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B8921F8665 for ; Sun, 11 Mar 2012 03:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcp6gIOUsOSt for ; Sun, 11 Mar 2012 03:02:35 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4165A21F8664 for ; Sun, 11 Mar 2012 03:02:34 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id A49A440034; Sun, 11 Mar 2012 11:02:32 +0100 (CET) Date: Sun, 11 Mar 2012 11:02:32 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120311100232.GB23576@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> MIME-Version: 1.0 In-Reply-To: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5114472141490609468==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============5114472141490609468== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline --5I6of5zJg18YgZEa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting at 08:29 on Mar 6 in "[dnsext] I-D Ac= tion:..." ] > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-= 04.txt I've read the draft and I support it. Below are a few things I found. (And I still have this question: http://www.ietf.org/mail-archive/web/dnsext/current/msg12286.html) | These signaling options can be | used by zone administrators as a gauge to measure the successful | deployment of code that implements a newly deployed digital signature | and hash algorithm, DS hash and NSEC3 hash algorithm used with | DNSSEC. =20 =20 This sentence has some funny wording. =20 | A validating stub resolver already (usually) sets the DO bit =20 already (usually), either already of usually? =20 | 5. Server Considerations =20 =20 What if the server can not comply to the clients wishes? Does it need to send back an empty DUA edns0? =20 | The goal of this option is these options are to signal new algorithm | uptake in client code to allow zone administrators to know when it is | possible to complete an algorithm rollover in a DNSSEC signed zone. =20 It this the goal? Because with this option we can also facilitate hash rollovers in nsec3. Regards, --=20 Miek Gieben --5I6of5zJg18YgZEa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9ceDgACgkQJYuFzziA0PZgVwCguH19gebShpSW++BJb7Ptab3V 2nsAn0lkOQXW2aByF+P60kSvqoxIVK01 =p5wd -----END PGP SIGNATURE----- --5I6of5zJg18YgZEa-- --===============5114472141490609468== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============5114472141490609468==-- From dnsext-bounces@ietf.org Sun Mar 11 06:38:29 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AE221F8630; Sun, 11 Mar 2012 06:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331473109; bh=CKNBTWjUtf8Jl8le2c8DytfXX4UqeaxV+NDEqIw6QMc=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=H5do1jhWxlnIDwbJBb38ArV4mt6sHsZg3B4nW4uZP8tF2pGGu+NIhJNPxTEVC8q+V ejkUKO9jbdUfZyrsFiY624f9CISo580GAp1ENcX7dV44ee25sgKFhS5KzJ83UEr3ow gcawP1cvmlNymxVlt1tW8gTdkfQ4vdTh6gmEvtZU= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EED21F8630 for ; Sun, 11 Mar 2012 06:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.175 X-Spam-Level: X-Spam-Status: No, score=0.175 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gvsyMAAE0fA for ; Sun, 11 Mar 2012 06:38:27 -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 67A5B21F861A for ; Sun, 11 Mar 2012 06:38:24 -0700 (PDT) Received: (qmail 46478 invoked from network); 11 Mar 2012 14:01:03 -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; 11 Mar 2012 14:01:03 -0000 Message-ID: <4F5CAA8A.6010406@necom830.hpcl.titech.ac.jp> Date: Sun, 11 Mar 2012 22:37:14 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201203092033.VAA02764@TR-Sys.de> In-Reply-To: <201203092033.VAA02764@TR-Sys.de> Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- changes since -02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Alfred wrote: > There have been complaints that the draft already shows much too > much context and it should better be stripped down to a pure > specification document ignoring any applicability questions. That's not mine. The problem I saw was that the draft lacked use case. > Are you now saying it should also present some kind of detailed > use case analysis or applicability statement, far beyond what is > said in Section 1 and Appendix A (motivation -- by existing use > cases -- for IXFR-ONLY)? I can see no meaningful use cases in Section 1 nor Appendix A. While your draft seemingly assumes zones should be purposelessly condensed, RFC1995 already says: But, this feature may not be so useful if an IXFR client has access to two IXFR servers: A and B, with inconsistent condensation results. and Information about older versions should be purged if the total length of an IXFR response would be longer than that of an AXFR response. that's why I can't see any meaningful use cases > I fear this would likely disqualify the document for Standards Track. Not even BCP, because RFC1995 already stated enough as a practical BCP. > Do you want that? Want what? Masataka Ohta _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Mar 11 22:14:32 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D834521F8559; Sun, 11 Mar 2012 22:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331529271; bh=L2YgF76AXSKKskKE/T0LJD32E9LmY4gSX5HSxxcsdKI=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ji50R1VSZsVtPGBQro6aeT/DtVjJ8v8uBNPR7f5POom7Iztll2PkFzbUkSX7iZqJ2 nrK1MNTFGn+kd/MDRaftCdYOsprg6vWfp+2kaSG2r6Eq54JmSvRgsLX05AAvd9h1Ss i6vp3aeiccZvopj3qu1B3U5UAOBlrrutkd4ukiNI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D5421F8559; Sun, 11 Mar 2012 22:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-oDnmFD1Y21; Sun, 11 Mar 2012 22:14:29 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD7021F854F; Sun, 11 Mar 2012 22:14:29 -0700 (PDT) Received: from [192.168.1.3] (unknown [201.204.76.162]) by vimes.kumari.net (Postfix) with ESMTPSA id D8BEB1B40C76; Mon, 12 Mar 2012 01:14:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Warren Kumari In-Reply-To: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 23:14:26 -0600 Message-Id: References: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> To: Internet-Drafts@ietf.org X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org, i-d-announce@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org I supported this draft and provided some comments^w nits back in version -0= 2 (http://www.ietf.org/mail-archive/web/dnsext/current/msg11472.html) I still support this draft, and find the current (-04) version cleaner and = easier to read=85 W On Mar 6, 2012, at 10:29 AM, Internet-Drafts@ietf.org wrote: > = > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the DNS Extensions Working Group of the= IETF. > = > Title : Signaling Cryptographic Algorithm Understanding in DNS= SEC > Author(s) : Steve Crocker > Scott Rose > Filename : draft-ietf-dnsext-dnssec-algo-signal-04.txt > Pages : 8 > Date : 2012-03-06 > = > The DNS Security Extensions (DNSSEC) were developed to provide origin > authentication and integrity protection for DNS data by using digital > signatures. These digital signatures can be generated using > different algorithms. This draft sets out to specify a way for > validating end-system resolvers to signal to a server which > cryptographic algorithms and hash algorithms they support. > = > = > = > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-= 04.txt > = > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > = > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-0= 4.txt > = > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > = -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Mar 11 22:26:54 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05BE21F850D; Sun, 11 Mar 2012 22:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331530014; bh=xXPS/4OaYm3cxzxZoawFttg/xkgi0l1fWJ2iBKJhDj0=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=pBVG+JVMl+fsja2i5QLDAmyK3/Yx42k4gJmlrhUhaof1oSQDX7qm3zo7tuHm0u/nS KMNyG01REg/7ktCsK9+VyC2Q0Mb5aWqRPc9hjUmsPrc5yajMbwo9Bde4ACjhewOQf8 ItgyycfPLjTYN8ZNFFqgCg7bfiEzzvoWeXD27H/A= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E8221F850D; Sun, 11 Mar 2012 22:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_81=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0ai4trJZu37; Sun, 11 Mar 2012 22:26:52 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 777CA21F84FC; Sun, 11 Mar 2012 22:26:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id A479D1350B984; Mon, 12 Mar 2012 06:26:50 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhoNOTf-dhtT; Mon, 12 Mar 2012 06:26:50 +0100 (CET) Received: from [10.0.1.3] (unknown [201.204.76.162]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id C69441350B97E; Mon, 12 Mar 2012 06:26:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Sun, 11 Mar 2012 23:26:44 -0600 Message-Id: <43D8FA8A-5FBC-40F8-ABF2-CAB1F7A85406@frobbit.se> References: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.1257) Cc: Internet-Drafts@ietf.org, dnsext@ietf.org, i-d-announce@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Thanks! FWIW, as the individual that (still) has the task of verifying the consensu= s around this draft, I have started walking around the individuals I have s= een commenting and asked them to explicitly look at this -04 version and le= t this list, me and/or the editors know their view. So if you have comments, positive or constructive negative, please let me, = the editors and/or the list know. But ensure you read the latest version, which at the moment is -04. Patrik On 11 mar 2012, at 23:14, Warren Kumari wrote: > I supported this draft and provided some comments^w nits back in version = -02 (http://www.ietf.org/mail-archive/web/dnsext/current/msg11472.html) > = > I still support this draft, and find the current (-04) version cleaner an= d easier to read=85 > = > W > = > On Mar 6, 2012, at 10:29 AM, Internet-Drafts@ietf.org wrote: > = >> = >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. This draft is a work item of the DNS Extensions Working Group of th= e IETF. >> = >> Title : Signaling Cryptographic Algorithm Understanding in DN= SSEC >> Author(s) : Steve Crocker >> Scott Rose >> Filename : draft-ietf-dnsext-dnssec-algo-signal-04.txt >> Pages : 8 >> Date : 2012-03-06 >> = >> The DNS Security Extensions (DNSSEC) were developed to provide origin >> authentication and integrity protection for DNS data by using digital >> signatures. These digital signatures can be generated using >> different algorithms. This draft sets out to specify a way for >> validating end-system resolvers to signal to a server which >> cryptographic algorithms and hash algorithms they support. >> = >> = >> = >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal= -04.txt >> = >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> = >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-= 04.txt >> = >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >> = > = > -- > Don't be impressed with unintelligible stuff said condescendingly. > -- Radia Perlman. > = > = > = > = > = > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > = _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 06:08:22 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFF321F879A; Mon, 12 Mar 2012 06:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331557698; bh=Nq5+ceyNSb64MqhA3JRHsBhHR8wREqeUcOjy+sibVgo=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=OnNbiqOO+8/GqOw47LwL3jfTyVy5mpmLO4acl5NmY8vNjHUwFf07WNAt61qQbJyJ8 Ej1mB3uQkqTVGKR6BIW8fO5kE1/Ak3DG209E9DKb+ugW+Wk8ixNi6xVVjaEbwncBhc vlbQp2jJWJnZkIWDlVt/2oBUuwsEReVIT38QcIZ4= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CDC21F879A for ; Mon, 12 Mar 2012 06:08:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGg1tQ5TYsy1 for ; Mon, 12 Mar 2012 06:08:16 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 52E0B21F8779 for ; Mon, 12 Mar 2012 06:08:16 -0700 (PDT) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q2CD86ox019174; Mon, 12 Mar 2012 09:08:07 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Scott Rose In-Reply-To: <20120309090748.GA20102@miek.nl> Date: Mon, 12 Mar 2012 09:08:06 -0400 Message-Id: <3B318BC7-749C-4885-A6B9-8BE91479D0F9@gmail.com> References: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> <20120309090748.GA20102@miek.nl> To: Miek Gieben X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mar 9, 2012, at 4:07 AM, Miek Gieben wrote: > I read a comment in the draft that this option list can get very long, which > indeed is true. > > How about the following scheme: > > A resolver indicates the highest algorithm number it understands and thus *also* > all *previous* algorithms. This way the whole option can be shortened to 4 > bytes: > > 0: OPTION-CODE > 1: DAU byte value > 2: DHU byte value > 3: N3U byte value > > And maybe this option can be renamed to Crypto Understood. > That was the layout of the previous versions, but without the NSEC3 hash understood (only added it this version). The problem was that it violated the basic format for EDNS options (Code, Length, Data). It could be: 0: OPTION-CODE 1: DATA LENGTH 2: DAU byte length 3: DHU byte length 4: N3U byte length One reason we made it three unique options was so clients could mix and match if they wanted. Especially since there is only one NSEC3 hash algorithm code assigned for now. Scott > A drawback is that a number of current specified features aren't available > with this scheme. > > Regards, > Miek Gieben > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 07:22:27 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB62821F87F2; Mon, 12 Mar 2012 07:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331562146; bh=pVzWX8fbFZTz/7RNC8+POcdR06y6oycl5Lm5N2Nfk9Y=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=QI8XaXSwn+eMi19EOtOU+yahg0iwa8k2pbgPyGQO8sAyq+dzEhQOwVhSs3wCFkpx0 lZRn0arAfi/rBAULsrgUWBuH2ubM6BHemsnrCbAm4nIyAO3xcHVKJ6k4rBcCSOi4Bd xSEeT043FRToFI7Qxo8ekPG83ieyHI+UPsExunR8= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCE321F87F4 for ; Mon, 12 Mar 2012 07:22:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id natWre20d6S2 for ; Mon, 12 Mar 2012 07:22:23 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 20BF221F87F2 for ; Mon, 12 Mar 2012 07:22:19 -0700 (PDT) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q2CEM85e024902; Mon, 12 Mar 2012 10:22:09 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Scott Rose In-Reply-To: <20120311100232.GB23576@miek.nl> Date: Mon, 12 Mar 2012 10:22:07 -0400 Message-Id: <4E328F58-C269-4EE3-8651-8ED97DFAE393@gmail.com> References: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> <20120311100232.GB23576@miek.nl> To: Miek Gieben X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mar 11, 2012, at 6:02 AM, Miek Gieben wrote: > [ Quoting at 08:29 on Mar 6 in "[dnsext] I-D Action:..." ] >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt > > I've read the draft and I support it. Below are a few things I found. > (And I still have this question: > http://www.ietf.org/mail-archive/web/dnsext/current/msg12286.html) > > | These signaling options can be > | used by zone administrators as a gauge to measure the successful > | deployment of code that implements a newly deployed digital signature > | and hash algorithm, DS hash and NSEC3 hash algorithm used with > | DNSSEC. > > This sentence has some funny wording. > > | A validating stub resolver already (usually) sets the DO bit > > already (usually), either already of usually? > Yes, both are poorly written. I'll re-write in next version. The second should be: "A validating stub resolver already sets the DO bit..." > | 5. Server Considerations > > What if the server can not comply to the clients wishes? Does > it need to send back an empty DUA edns0? > > | The goal of this option is these options are to signal new algorithm > | uptake in client code to allow zone administrators to know when it is > | possible to complete an algorithm rollover in a DNSSEC signed zone. > > It this the goal? Because with this option we can also facilitate > hash rollovers in nsec3. > Correct - that was left out and should be re-added. Thanks, Scott > Regards, > > -- > Miek Gieben > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 11:11:54 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2135A21F8979; Mon, 12 Mar 2012 11:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331575914; bh=K+LYMTZa9HMXf5101stgO5oF2LgvmOrW8UKI1S4Dd8Q=; h=From:Date:Message-Id:To:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=uHKqC+yCvfrUyrewN0XjuaI8YX+fTzbUqWV9fPxPiQ3LRaGUWXyYcj5HaRHpuVKNy p/QI6neFvelg/p6Klfu/hnQbuPM21EpLKsV8gXRs4CWaNiplqKw0MlFdQqf1cxa9kV Zq+yckT1U+OniRSnNjfFGoQ+1ocNsS0GvBZqpIuc= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CED21F8979 for ; Mon, 12 Mar 2012 11:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EU0Q5Ua5BZQ for ; Mon, 12 Mar 2012 11:11:52 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 67D2E21F8968 for ; Mon, 12 Mar 2012 11:11:50 -0700 (PDT) Received: from [10.196.208.139] (unknown [199.91.193.1]) by vimes.kumari.net (Postfix) with ESMTPSA id D2AF91B407FB for ; Mon, 12 Mar 2012 14:11:49 -0400 (EDT) From: Warren Kumari Date: Mon, 12 Mar 2012 12:11:48 -0600 Message-Id: To: dnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dnsext] Requesting Expert review for RRTYPE application for draft-ietf-dane-protocol-18. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Hi dnsext. I am requesting Expert review for an RRTYPE allocation for draft-ietf-dane-= protocol-18. I have CCed this to dns-rrtype-applications@ietf.org (listed in rfc6195), b= ut seem to remember that posting to DNSEXT is the new, correct(er) process= =85. W I have included the completed template below: ------- A. Submission Date: 12 March 2012 B. Submission Type: [X] New RRTYPE [ ] Modification to existing RRTYPE C. Contact Information for submitter (will be publicly posted): Name: Warren Kumari = Email Address: warren@kumari.net International telephone number: +1-571-748-4373 Other contact handles: D. Motivation for the new RRTYPE application. Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. The allocation of this RRTYPE will improve this situation by= enabling the administrator of a domain name to certify the keys used in that domain's TLS servers by publishing information in the DNS. E. Description of the proposed RR type. A description of tge RR type is in draft-ietf-dane-protocol-18.txt, S= ection 2 The TLSA Resource Record ( http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt ) = F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? The CERT (37) RR, RFC 4398 is closest. It is not suitable for this pa= rticular use as it is not flexible enough. It *would* be possiable to shoehorn this into the CE= RT RR, but would be very kludgy. G. What mnemonic is requested for the new RRTYPE (optional)? TLSA H. Does the requested RRTYPE make use of any existing IANA registry or require the creation of a new IANA sub-registry in DNS Parameters? If so, please indicate which registry is to be used or created. If a new sub-registry is needed, specify the allocation policy for it and its initial contents. Also include what the modification procedures will be. This is in the the draft (http://tools.ietf.org/id/draft-ietf-dane-pr= otocol-18.txt). It is included here for completeness, but reviewers are encouraged to= consult the draft as the formatting is cleaner. #1: TLSA Usages. A new registry, "Certificate Usages for TLSA Resource Records". The registry policy is "RFC Required". The initial entries in the registry are: Value Short description Reference ---------------------------------------------------------- 0 CA constraint [This] 1 Service certificate constraint [This] 2 Trust anchor assertion [This] 3 Domain-issued certificate [This] 4-254 Unassigned 255 Private use #2: TLSA Selectors A new registry, "Selectors for TLSA Resource Records". The registry policy is "Specification Required". The initial entries in the registry are: Value Short description Reference ---------------------------------------------------------- 0 Full Certificate [This] 1 SubjectPublicKeyInfo [This] 2-254 Unassigned 255 Private use #3: TLSA Matching Types A new registry, "Matching Types for TLSA Resource Records". The registry policy is "Specification Required". The initial entries in the registry are: Value Short description Reference -------------------------------------------------------- 0 No hash used [This] 1 SHA-256 RFC 6234 2 SHA-512 RFC 6234 3-254 Unassigned 255 Private use I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No. J. Comments: A number of participants in DNSEXT / DNSOPS (and the DNS Directorate)= have been involved in / following / are aware of this work. = -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 11:42:01 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D760121E804A; Mon, 12 Mar 2012 11:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331577720; bh=DrzwFCzLymkJZyqEQxBCUAT5R6hFTZYIwkDeeuUpVBo=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=dxEJaH5BU0Vj4YfNdjySBi+Mkvtp4id7lBua2kMJi67cpf9P8lIXXt+SXBEmSR4hn KzuXBevhenTeLYHCkoTkXXO78ummoSar0uuwMdmxMF2WYpg3saFDD+URuN46ETVZ7D 4Y1iSMpq7VSiQcmxWi4OwJmZ3tJagXKwlZGhdJVY= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD3021E804A for ; Mon, 12 Mar 2012 11:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJ17si6X6VGb for ; Mon, 12 Mar 2012 11:41:58 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA4C21E803B for ; Mon, 12 Mar 2012 11:41:58 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2CIfu7h012251 for ; Mon, 12 Mar 2012 14:41:57 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4F5E4375.4000207@ogud.com> Date: Mon, 12 Mar 2012 14:41:57 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dnsext@ietf.org References: <4F15C183.2090001@ogud.com> In-Reply-To: <4F15C183.2090001@ogud.com> X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] DNSEXT at IETF@83 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Just a reminder if you have any more items you want on the agenda drop me a line. Current draft agenda is at http://www.ietf.org/proceedings/83/agenda/agenda-83-dnsext.txt or http://tools.ietf.org/wg/dnsext/agenda Olafur On 17/01/2012 13:44, Olafur Gudmundsson wrote: > > We have requested a short session at the Paris meeting. > Current Agenda, > a) WG status, > b) Resolving any Existing Document issues ? > c-y) other items ? > z) Toast the universal deployment of DNSSEC and closure of DNSEXT > > if you have requests for agenda items, send that request to > dnsext-chairs@tools.ietf.org > > > Olafur & Andrew > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > > _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 11:57:59 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B6221E8078; Mon, 12 Mar 2012 11:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331578679; bh=7BSH4YteE5ZAxlOT7BrmnfJh6fdV2ks0GmVFRWdpWDk=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=dieHpgFwMr5Y/hr4SlIxzU+580rTOeO06uK+q5rWA9rIxNLbCXB3LO3o5CNdEOcpW B2pJHCaOY8xE3C+jJFys3uSpXf+lFlWP1+N4nD6ObIMgSj1xcFO6u0s424XWsWd9dv br/iLddDW81aJDxc9u81Il8gZ77DoOYRLjfzWrZI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0C821E8070; Mon, 12 Mar 2012 11:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYLugpSdUrFZ; Mon, 12 Mar 2012 11:57:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD1321E8053; Mon, 12 Mar 2012 11:57:53 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312185753.18115.78790.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 11:57:53 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-registry-update-01.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates Author(s) : Scott Rose Filename : draft-ietf-dnsext-dnssec-registry-update-01.txt Pages : 6 Date : 2012-03-12 The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA maintained registry. This document presents a set of changes for some entries of the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-update-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-update-01.txt _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 12:04:17 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEB421F8A24; Mon, 12 Mar 2012 12:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331579057; bh=yDrBD33SyUpwRkUnt3JGHUDmW/pG0Qu1jxhYDqegYCI=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Wy5RtRfXCgfT+ckNqh/3bMRdCfAwE056EOyX28IdGgqcAXsoVQXY7euKx4PB6aH8m U8dtRFcKFlDI5nwGRi79wwy7b5JNAQsjcAszzjrfQJr7VEZlyZD227LIpWZzyukZbf HvhpoKieNz9VzHCq2PmiNqNP48IFmD8dxOyGOGZU= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574C421F8A24 for ; Mon, 12 Mar 2012 12:04:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7r7ub6iiP9l for ; Mon, 12 Mar 2012 12:04:15 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id B836621F8A23 for ; Mon, 12 Mar 2012 12:04:15 -0700 (PDT) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q2CJ3x5t014316; Mon, 12 Mar 2012 15:04:01 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Scott Rose In-Reply-To: Date: Mon, 12 Mar 2012 15:03:58 -0400 Message-Id: <8C3528B6-ECD9-4094-B67D-AF9C2F641142@gmail.com> References: <20120109222905.GW1820@crankycanuck.ca> To: Samuel Weiler X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Cc: dnsext@ietf.org Subject: Re: [dnsext] Follow up on draft-ietf-dnsext-dnssec-registry-fixes X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Jan 12, 2012, at 11:11 PM, Samuel Weiler wrote: > Looking just at draft-srose-dnssec-registry-update-00: > > 1) the propsoed replacement registry no longer mentions that algorithm 1 has been deprecated (as currently indicated in the IANA registry). If that flag is to be removed, perhaps that should be called out in section 2.1 as a change. > Fixed - re-added comments in -01 version. > 2) The original IANA registry contains some trailing data re: DH primes. It might be worth explaining/mentioning that. > > 3) Three algorithms continue to have asterisks in the transaction security column (here renamed to Transaction Sign), with a footnote (originally from RFC5702) saying "There has been no determination of standardization of the use of this algorithm with Transaction Security." Can we say anything more re: these three algorithms' usefulness for SIG(0) or TSIG? If not, we at least need to leave that footnote expansion in the registry. Added note that the other tables (2) are not changed. Same with (3) unless there is something the WG wants added or changed in the current note associated with the registry table. The only other change in -01 is I removed the entire table and only concentrating on the changed entries. That is to clean up the table in the text (make it more readable) and reduce the need to keep up to date with respect to ECDSA addition and other new additions that might take place before completion of this draft. Scott > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 12:08:52 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C23521F884F; Mon, 12 Mar 2012 12:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331579332; bh=RXuWDhBU9vt+ni+e5s9k2621Dqh2cmcXac+2F/TG+2s=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=y9ynbHjxYg/mWAo+t7qjIfdGCHs9joMkxbsMb8mgejvjOvCqKA4QObJQQuK0jmMAI Say0qkpn3OreIMCqLKyhelUjOI5tGTUK1A/RWEH33r4qs/sAQoDbWQdnOl9qp8Ab6t Nfu3f79H4sBgiz65rW2TUpyDZq4ypt1xLnMoRY7c= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FBC21F884F for ; Mon, 12 Mar 2012 12:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIfs7YwKCgy4 for ; Mon, 12 Mar 2012 12:08:49 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id A640521F87E2 for ; Mon, 12 Mar 2012 12:08:43 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2CJ8gL5068285; Mon, 12 Mar 2012 15:08:42 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2CJ8giQ068278; Mon, 12 Mar 2012 15:08:42 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 12 Mar 2012 15:08:42 -0400 (EDT) From: Samuel Weiler To: Edward Lewis In-Reply-To: Message-ID: References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 12 Mar 2012 15:08:42 -0400 (EDT) Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Most of the WGLC comments in this thread were addressed in Andrew's "issues" thread and are addressed, in some form, in the forthcoming -17. I'm trying to catch any others. On Fri, 20 Jan 2012, Edward Lewis wrote: > In 2005 it was too soon to publish, now it is not. And at this point there > may be more and more wrinkles in the DNSSEC specs, but we need to get out at > least this (first) update. Thank you. > Pressence has a presence in the document. It shouldn't (the spelling, I > mean). Fixed (and thanks to the others who also caught this). > 5.9's title is misleading. The content is good, it's about answering from > cache in the face of a CD query. But "always doing CD" only applies to > elements that will do their own validation. Doesn't it also apply to a non-validating box in the middle? That box may still need to return +CD data if something downstream wants it. The only place I see it not applying is stub resolvers. Rather than alter the title (since I couldn't think of a good way to do it), I propose adding a paragraph saying "this doesn't apply to stub resolvers". > 5.4 could optionally make the point that a validator that expects all > signatures to be good and/or all chains to work is vulnerable to malicious > insertions of gibberish-based signatures. It's harder to construct a good > chain than a false chain. Added a line. -- Sam _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 12:20:42 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFF621F899A; Mon, 12 Mar 2012 12:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331580042; bh=q+p3sz3m/zTCxpIjtiDxH1HuW+UXqDhcxlUA8dvsINg=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=QS6agySFDZ8r8MS3vfC86tHPTs9qdp0vLtvTBjNGF2ZEwfrPK9dZhyp8B8DjO4jYY H4tJYI6D/loa8WuULWD682mkO1HC/Ounb5IRTzVW8BhTmm3/DXaZs94E0dL1ZWqlYA ytpqkt3MVf9SlVY/KthK9FMGTLWlia+37R4ZdhxQ= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688CA21F899F for ; Mon, 12 Mar 2012 12:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMW4pF37QhUu for ; Mon, 12 Mar 2012 12:20:39 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA7B21F8992 for ; Mon, 12 Mar 2012 12:20:38 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2CJKbCU074580; Mon, 12 Mar 2012 15:20:37 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2CJKbM5074576; Mon, 12 Mar 2012 15:20:37 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 12 Mar 2012 15:20:37 -0400 (EDT) From: Samuel Weiler To: "W.C.A. Wijngaards" In-Reply-To: <4F1FEB8D.1080703@nlnetlabs.nl> Message-ID: References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> <4F1FEB8D.1080703@nlnetlabs.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 12 Mar 2012 15:20:37 -0400 (EDT) Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Wed, 25 Jan 2012, W.C.A. Wijngaards wrote: > The section and appendix on CD bits are long. Not wrong, but long. > With the root trust anchor deployed, not having a covering trust anchor > is unlikely. I know. As Andrew said in the summary thread, he insisted. > Section 6.2 is correct. But its tone is loose. It is about lenient > acceptance of the SEP flag. Please say that, or say that the proper > setting of the SEP flag is defined in its RFC. There are actually two things in here: one is about the SEP bit, the other is about using DNSKEYs in odd ways. I think both need to stay, but your point about loose language is well taken. I propose to reword the first two paragraphs to clean that up. Thank you for your review. -- Sam _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 12:32:55 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3713121E8086; Mon, 12 Mar 2012 12:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331580775; bh=nVgS2L4Q2bVtILPqX+nJk5wv6DvA8EBAesecKLTi6M4=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=o9rWlDfryBfThXdH/0ahP4wCCXY4uuMxr8EKvknAQuj/smSWEEx/XJVGAfIVuT/ty nOSKoqcF2oqULCYZ2AehWAEGcMSpAW+B8SVJE/7EA7ai4xZZ9dE/1YF7I4DhrUFh7L AqnlXgJrp7lFXzwWNpZ2pDs7qsjOvk1PZkQMNsF0= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D4821F890A for ; Mon, 12 Mar 2012 12:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS2rAEH+z3bP for ; Mon, 12 Mar 2012 12:32:53 -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 B574721F8902 for ; Mon, 12 Mar 2012 12:32:53 -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-2.csi.cam.ac.uk ([131.111.8.54]:42400) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1S7AzE-0001zh-Pz (Exim 4.72) (return-path ); Mon, 12 Mar 2012 19:32:52 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S7AzE-0004CV-0h (Exim 4.67) (return-path ); Mon, 12 Mar 2012 19:32:52 +0000 Date: Mon, 12 Mar 2012 19:32:52 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Warren Kumari In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Cc: dnsext@ietf.org Subject: Re: [dnsext] Requesting Expert review for RRTYPE application for draft-ietf-dane-protocol-18. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Warren Kumari wrote: > > I am requesting Expert review for an RRTYPE allocation for draft-ietf-dane-protocol-18. I have looked at it from the point of view of John Levine's DNS RDATA description language and I'm pleased to see it'll be easily accommodated. (This is equivalent to saying that translating TLSA between wire format and presentation format it is nice and simple.) Tony. -- f.anthony.n.finch http://dotat.at/ North Utsire: Westerly 3 or 4. Moderate. Mainly fair. Moderate or good, occasionally poor at first. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 12:55:45 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2096621E80C5; Mon, 12 Mar 2012 12:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331582145; bh=kDLwe2x1/KWWNZ2Ga9YU1onC0AnWM2wGC9fWpFYs0Lg=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=LyM9i68Yfi6KgM6ZQT0M4iIPVH6OBuiCTUWPPAw8XAwrC/4KVcpJjjfoKagKn1Vra WVkDVeBD+r27FV+TD3VXV/mN8uCUU67pKxgkAbo/bQLZ3WPii5A3LwBjLvLXZW2XNb GJOWzjHO12ngWeIvLKqTu5iiaMPCFjzs2NWlg9Wk= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C230221E808F for ; Mon, 12 Mar 2012 12:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3jhoEa-P2eu for ; Mon, 12 Mar 2012 12:55:35 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB0121E809B for ; Mon, 12 Mar 2012 12:55:32 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2CJtVbK093688; Mon, 12 Mar 2012 15:55:31 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2CJtVwF093684; Mon, 12 Mar 2012 15:55:31 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 12 Mar 2012 15:55:31 -0400 (EDT) From: Samuel Weiler To: Matthijs Mekking In-Reply-To: <4F2967EF.8070502@nlnetlabs.nl> Message-ID: References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> <4F2967EF.8070502@nlnetlabs.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 12 Mar 2012 15:55:32 -0400 (EDT) Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Wed, 1 Feb 2012, Matthijs Mekking wrote: > 1a. Nit > The second paragraph raises concerns when a resolver adopts a more > restrictive security policy. On the first read, it is not immediately > obvious why there can be unnecessary validation failures. Perhaps a > small explanation is needed, that the restrictive policy is requiring > all signatures to validate? Perhaps. I decided not to change anything on this pass. > 2b. > The section states that a signed zone MUST include a DNSKEY for each > algorithm present in the zone's DS RRset and expected trust anchors for > the zone. I argue if MUST is too strong, and would vote for SHOULD, for > the reason that the expected trust anchors and DS RRset are being > maintained outside the administrative boundaries of the zone owner. The MUST should stay. (The MUST must stay?) You're right about administrative boundaries, but things break if these rules aren't followed. They really are a MUST. > 3. Section 6.4. Erros in RFC 5155 > > I would like to see some clarifying or guiding text about the > contradiction in this RFC on the Flags field I posted earlier to this list: > > Section 8.2 of RFC 5155 states that a validator MUST ignore NSEC3 RRs > with a Flag fields value other than zero or one. But in the IANA > Considerations section, bits 0-6 are available for assignment. > > However, assigning a meaning to one of the bits 0-6 would break NSEC3 > conformance because that would allow for Flag fields value larger than > one and that conflicts with the rule in Section 8.2 . As a result, > assigning a meaning to one of the bits 0-6 in the NSEC3 Flag fields > would require an update at the resolver side to ignore the bits it does > not implement, regardless of the total outcome value of the Flag fields. > Such a requirement allows for a more flexible approach for future > updates of the NSEC3 Flag fields, with a nice backwards compatibility > property. I understand the reasoning, but I'm not entirely sure what you're proposing. And it does sound like a real change. And one that may not match current code. I'm not sure this is a great idea. -- Sam _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 13:05:01 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1B521F8928; Mon, 12 Mar 2012 13:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331582701; bh=yCAefBD/eFBhsth3sCxs4IJGpU0/hYC0OhMZp0zZwR4=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=vJBA9gevTO/EpxYg+pqvQJRjAEVQAammU0+0cZ47TuoIFozXeSg8o9SGLrIOuosGw OgiTJYPfihfaxq2KMfIHPqrGwUJ7ZihVSKIXlw163Cr3uvDjbMIsbg3o0lGFDB6ipj 3u4qXMGBJUB5fqvtrd76rH/eWMRh9RI3BWsrJR1M= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FA521F8928 for ; Mon, 12 Mar 2012 13:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3-32dc7vkQY for ; Mon, 12 Mar 2012 13:05:00 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 02B6521F844B for ; Mon, 12 Mar 2012 13:04:59 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2CJfwPF086242; Mon, 12 Mar 2012 15:41:58 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2CJfwRu086238; Mon, 12 Mar 2012 15:41:58 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 12 Mar 2012 15:41:58 -0400 (EDT) From: Samuel Weiler To: Mohan Parthasarathy In-Reply-To: Message-ID: References: <20120120054939.GD4365@mail.yitter.info> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 12 Mar 2012 15:41:58 -0400 (EDT) Cc: DNSEXT Working Group Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Fri, 27 Jan 2012, Mohan Parthasarathy wrote: > - Section 4.4 Insecure Delegation proofs last sentence is very > confusing. An example as to what attack this is describing would be > helpful to the implementer. Here's an example of the attack we're trying to avoid. Consider a signed zone that contains the names: alfa.example.com. and bravo.alfa.example.com. alfa.example.com is NOT a delegation. Instead, it has this NSEC record: alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 ) The quesion is: could an attacker use this NSEC record in reply to a query for bravo.alfa.example.com, replying with either a spoofed bravo.alfa.example.com or even claiming the name doesn't exist? Under the old rules, read literally, that attack would work: the NSEC does not have a DS or SOA bit. It also does not have an NS bit, but the rules did not say to check for that. The forthcoming -17 has that section somewhat reworked. There still is no example in. Let us know if you really want that. (note: the error is also broken, since bravo.alfa.example.com sorts before host.example.com. maybe there are multiple ways to catch this attack.) > - The "Security Considerations" section says: > > This document adds two cryptographic features to the core DNSSEC protocol. > > Is this referring to the algorithms mentioned in section 2.2 ( > which actually lists three) or something else ? clarified. -- Sam _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 13:23:07 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB02821F89AC; Mon, 12 Mar 2012 13:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331583786; bh=VRMcO5l3jJ5Fr1mMSaPswi4GtVSTS6DMdSdz8Vb3f/Y=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=GifdqfaPpyrQAIa0cp7qKrePj6ylHvIh7wjVLk3wm586jbnJqt6sIuudwxduXhR0b MM0BrcznvQ1yAL7kPZSKzVn9Na4D+G1puhCUwoHaUnePnRLuVGJw3e2hXWApVQ1vHl /4XhBZQYtrMoBTApBYEhAY7bBVcBKgNm/4GznP04= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949A321F89AB for ; Mon, 12 Mar 2012 13:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGU0CeSODElU for ; Mon, 12 Mar 2012 13:23:05 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E059F21F899F for ; Mon, 12 Mar 2012 13:23:04 -0700 (PDT) Received: from [10.196.208.139] (unknown [199.91.193.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 60FD41B41080; Mon, 12 Mar 2012 16:23:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Warren Kumari In-Reply-To: Date: Mon, 12 Mar 2012 14:23:03 -0600 Message-Id: <76E4554E-D94A-4FA3-82AD-162CB27A9E98@kumari.net> References: To: Tony Finch X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] Requesting Expert review for RRTYPE application for draft-ietf-dane-protocol-18. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mar 12, 2012, at 1:32 PM, Tony Finch wrote: > Warren Kumari wrote: >> = >> I am requesting Expert review for an RRTYPE allocation for draft-ietf-da= ne-protocol-18. > = > I have looked at it from the point of view of John Levine's DNS RDATA > description language and I'm pleased to see it'll be easily accommodated. > (This is equivalent to saying that translating TLSA between wire format > and presentation format it is nice and simple.) Excellent, thank you. And Olafur pointed out that, even though I *said* that I was CCing dns-rrty= pe-applications@ietf.org, I forgot to. So, I have just forwarded it to them=85. W > = > Tony. > -- = > f.anthony.n.finch http://dotat.at/ > North Utsire: Westerly 3 or 4. Moderate. Mainly fair. Moderate or good, > occasionally poor at first. > = -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 13:36:54 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5133B11E80C5; Mon, 12 Mar 2012 13:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331584614; bh=tE0B3shmBrbiKVkYRTRcB0xuxfLZn7LH4u8Uqux7/wg=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=NzubDR1nOYFi0uCeGbExL3roXMeA/O8isqYxSRjNJBmPZ+B1v7f6mtt1+z7dqIGbf xHFphO4LB6xCQ6yagFJgfNekBC1ObSUQTa+H/SIHt7854VEnX+YCm2AvRAMtz4wQA8 d0JHL17dX34b+Xe8f6QSXaZIyqQKeJ/+nRv7JNJg= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27E611E80B1 for ; Mon, 12 Mar 2012 13:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bvfXhqriuaF for ; Mon, 12 Mar 2012 13:36:51 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC9A11E80C5 for ; Mon, 12 Mar 2012 13:36:51 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKT15eYOUd65Enomxx02I4IxfnkLpBD29+@postini.com; Mon, 12 Mar 2012 13:36:51 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2CKaiHO013398; Mon, 12 Mar 2012 16:36:47 -0400 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 16:36:44 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 16:36:43 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 12 Mar 2012 16:36:43 -0400 From: "Blacka, David" To: Mohan Parthasarathy Thread-Topic: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 Thread-Index: AQHM1zdYhpCbZbKrbEeeiLsTMPAht5YhbICAgEY4fgCAAA9KgA== Date: Mon, 12 Mar 2012 20:36:42 +0000 Message-ID: References: <20120120054939.GD4365@mail.yitter.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2012 20:36:43.0436 (UTC) FILETIME=[D60186C0:01CD008F] Cc: Samuel Weiler , DNSEXT Working Group Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1147232778155567482==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============1147232778155567482== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_F50BD115-BE30-468F-8B45-E7470FF61FCC"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_F50BD115-BE30-468F-8B45-E7470FF61FCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 12, 2012, at 3:41 PM, Samuel Weiler wrote: > On Fri, 27 Jan 2012, Mohan Parthasarathy wrote: >=20 >> - Section 4.4 Insecure Delegation proofs last sentence is very >> confusing. An example as to what attack this is describing would be >> helpful to the implementer. >=20 > Here's an example of the attack we're trying to avoid. Consider a = signed zone that contains the names: > alfa.example.com. > and > bravo.alfa.example.com. >=20 > alfa.example.com is NOT a delegation. Instead, it has this NSEC = record: >=20 > alfa.example.com. 86400 IN NSEC host.example.com. ( > A MX RRSIG NSEC TYPE1234 ) >=20 > The quesion is: could an attacker use this NSEC record in reply to a = query for bravo.alfa.example.com, replying with either a spoofed = bravo.alfa.example.com or even claiming the name doesn't exist? Under = the old rules, read literally, that attack would work: the NSEC does not = have a DS or SOA bit. It also does not have an NS bit, but the rules = did not say to check for that. Actually, the question is: could an attacker use this NSEC record to = spoof away actual signed records for alfa.example.com. The attacker = could return: ANSWER: AUTHORITY: alfa.example.com IN NS my.bad.server. alfa.example.com IN NS my.other.bad.server. alfa.example.com IN NSEC bravo.alfa.example.com A MX RRSIG NSEC = TYPE1234 alfa.example.com IN RRSIG NSEC =85 ADDITIONAL: ... This looks superficially like a normal insecure delegation. The NSEC = record verifies and proves that there is no DS RRset. The attacker = then, on my.bad.server, can return whatever it likes for = alfa.example.com A, or other types. Thus, 4.4 says that you MUST check that the NS bit is set. >=20 > The forthcoming -17 has that section somewhat reworked. There still = is no example in. Let us know if you really want that. >=20 > (note: the error is also broken, since bravo.alfa.example.com sorts = before host.example.com. maybe there are multiple ways to catch this = attack.) >=20 >> - The "Security Considerations" section says: >>=20 >> This document adds two cryptographic features to the core DNSSEC = protocol. >>=20 >> Is this referring to the algorithms mentioned in section 2.2 ( >> which actually lists three) or something else ? >=20 > clarified. >=20 > -- Sam >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- David Blacka =20 Principal Verisign Infrastructure Engineering --Apple-Mail=_F50BD115-BE30-468F-8B45-E7470FF61FCC Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMpzCCBhow ggUCoAMCAQICEBc0Avppt6vT9KJWAKLsKTAwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDMwMzAwMDAwMFoXDTE5MDMwMjIzNTk1OVowgbAxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZBVVIHbQdG81jb1cp+jOE4D5vUIaST JqKfkRcKNC8Q7l/sEuBplO3NRos9MRwdagtQtfeTiZC8NwQ1IfbPIAtd3BO4u5WRzWdD2G4BRTbK C/nkXDtJYGVgFD2m+OXsS31p4ryXlZo2OhbKQvXZof0qUWI/79smv37sOG9jRsPHUPVeMVtqtuHf YoG0PBNOfyu0Qq2W4a2RzYToKLekE4cJejlMLIsq8fk5J3Vb/hicWuNA9nVS8K5OZJ7dmNVxiqA6 yvWTt5u0lDLCRjYBUWuQ95AIG3yyTnCP8A39k3jlP24fYcIe1r1By2Fk7uzH/L9sOnrSFL8Aq9WS zws+u0UCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMHAGA1Ud IARpMGcwZQYLYIZIAYb4RQEHFwIwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTA3MB0GA1UdDgQWBBTVH5Sm O27W26S0sXCieoiKViFvFTCB8AYDVR0jBIHoMIHloYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IQYXDLSYxfmEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAFTXCpaBB Rq5kc0XwUen7u5EsOzy7iiwvAHrsd7PKLCHg0NSbZKWg4Tzk/Yl5HRl59esmG7e6avTxiEaDG7OV 2+BX5sEfFvKQmtTFyiI3sozDNs+nCFQ+ksSzNVS0msKRSX22qik6AH6diXmQvcb0PIM4QuZadhb+ qwxac5AvA8IKgfPkaXdnIpcotuqtKaqHe60qUw7hnCpN9gamcUoNDVx0Gu1nObq2usSjCVvXWiYY ohDin9MHLkmJ1uYOoRzsQA4WXVAa11UpMXsnd6JotLVKLnrjgZEdK0id0RTBpVbcI9VgxP1LCEaw rYgwfjsT08wUtdampqUUPcljHG4SzDCCBoUwggVtoAMCAQICECvwr+5g4ykMmRdZyEk9APUwDQYJ KoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNz IDIgRW1wbG95ZWUgQ0EgLSBHMzAeFw0xMTA1MTEwMDAwMDBaFw0xMjA1MTAwMDAwMDBaMGsxaTAQ BgNVBAsUCVZDT1JQIFVBUzAUBgNVBAMTDUJsYWNrYSwgRGF2aWQwHQYDVQQKFBZWZXJpU2lnbiBJ bmMuIFZDT1JQVUFTMCAGCSqGSIb3DQEJARYTZGF2aWRiQHZlcmlzaWduLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOFr4D6qtYX78Fwj5I+EKxkemPlg5PON2FAMElOxon6vuLv7 yRUPr7FdNu1RDd0QYni5EMQ/2cNpjQVRSrfrCNqoWkJ9y3iUHnQH+/29uOuafcxjZ11BaUo1AwpB ifMJD4PgPv4aP3kuusxY0lI3rVXJKnezejgRRGO+6n68VYQnbunJ0P0cdJvU+ZNpOkKj9y8eTG0h ynFnBP0UAgQ2f+E0c3u67ie54rHbdDNVMGECvjXjWs5KhXMR68tGCE2K7roer2v27N8VIWq5jrIU q9PLx8zjI6FThbu9ZzQCoToc7UGmeHV/oUiWKheAavj/D4iVupdZ07SPYUEnGGd5wYsCAwEAAaOC At0wggLZMAkGA1UdEwQCMAAwSAYDVR0RBEEwP4ETZGF2aWRiQHZlcmlzaWduLmNvbaAoBgorBgEE AYI3FAIDoBoMGGRhdmlkYkB2Y29ycC5hZC52cnNuLmNvbTAmBgkrBgEEAYI3FQcEGTAXBg9ghkgB hvhFAQ0EiGeB6AUCAWQCAQMwYQYDVR0fBFowWDBWoFSgUoZQaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vY2FfMzBlMmNkOGJhMjkzMDljYTAyMDJkMTVkNGJjZGYzZjAvTGF0ZXN0Q1JMLmNy bAAwggEGBgNVHSMEgf4wgfuAFNUflKY7btbbpLSxcKJ6iIpWIW8VoYHQpIHNMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQFzQC+mm3q9P0olYAouwpMDBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgkqhkiG9w0BCQ8EbjBs MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAHBgUrDgMCGjAKBggqhkiG9w0C AjAKBggqhkiG9w0CBDAKBggqhkiG9w0CBTALBgkqhkiG9w0BAQUwCwYJKoZIhvcNAQEEMA0GCSqG SIb3DQEBBQUAA4IBAQBFpX/mFvxKbdeTruA4rSlIv9JREutn5/MiOpRqhvuuAEnei3ltZ2AdURZ/ 2dvNTfEeQphSCD/l9+rVxbZKEcaKxBYeV3sSAEsOVhsc+ruZKFLnwAzEm7u/rTfkyO+qYV2zWjqA Bq9UoIDTQ9ogjYZ7A0JWnYwj8VpTA2gqBqe6ya+k9/l/GuWyVm2PW/b8OGBzi4VsQYy2WE8KGHr1 nn5znY3KZswuyRQLnzlhSdwowUFDg/yaqolSWgP1HyJGs4Ek1ZL/9DGyH/QmfxCURP2Q7CIJSUYn yDNus5pZbifQbIOBA399fc0ASqM5lKbmIrAln3FQNIoX2P0RB+Hqg1HvMYIEAjCCA/4CAQEwgcUw gbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUg Q0EgLSBHMwIQK/Cv7mDjKQyZF1nIST0A9TAJBgUrDgMCGgUAoIICETAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAzMTIyMDM2NDJaMCMGCSqGSIb3DQEJBDEWBBTO ujRQJyaagYVrr80k0KL/kA5y1DCB1gYJKwYBBAGCNxAEMYHIMIHFMIGwMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MSowKAYDVQQDEyFWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCECvwr+5g4ykM mRdZyEk9APUwgdgGCyqGSIb3DQEJEAILMYHIoIHFMIGwMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MSowKAYD VQQDEyFWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCECvwr+5g4ykMmRdZyEk9APUw DQYJKoZIhvcNAQEBBQAEggEAk2da3IYXy463p7KKoQ5CLpDfc6giRPbvw5PgFVL9wJLRc8Nr+wQP ZVeRnnO43wVa2toOI2cTsHzLS5DAkQ1AGeeBYR/Ow4yfwcX5Wlq2BO1e+LbudzBtOYV6rm4IC/xf OszcBosq7Gu60DNcLmv8rgsxAFixcBcAer/UVBWqifU5aiBEFZkmNw2MuUYK+QKOdbXkskbi6CuE 1CBtXH5ehuDjhtwb4rcti2TbbIUbasI8NjTjPt8ui1Yr8LTXtMjPmHHL7bCIlRcUbrmhXhXxAM7E vNDNXr92Zx+kWnsx0hll0UTMBlR3qGSudQV5ZLdafrDC77TfTw7fJS6jnIMdMgAAAAAAAA== --Apple-Mail=_F50BD115-BE30-468F-8B45-E7470FF61FCC-- --===============1147232778155567482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============1147232778155567482==-- From dnsext-bounces@ietf.org Mon Mar 12 14:24:09 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36AE11E8088; Mon, 12 Mar 2012 14:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331587449; bh=tKux4Qk3IexcasPekHereSdBnIlMarl0yxoes7QBs+Q=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=qQoE1RtqRoaOVb8zuY3I5mnCFr/LIGSwwnQJvLs075m/rgiX5pImm/ZLnDEjJa/JO 5GFBpi1MCZ5wKDmtb4WfQ4gt32cxsRHDYwBDpLuPWaO6dbcRkHQqaqxc27G99qeinh o9XqWIff1pOTWxq4MTLoLsIFerhVSW7nyh0AXmKM= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBF521F87C8 for ; Mon, 12 Mar 2012 14:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5srtz67CLJR for ; Mon, 12 Mar 2012 14:24:07 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id EA38C21F8981 for ; Mon, 12 Mar 2012 14:24:06 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2CLO6VL043625; Mon, 12 Mar 2012 17:24:06 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2CLO502043621; Mon, 12 Mar 2012 17:24:05 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 12 Mar 2012 17:24:05 -0400 (EDT) From: Samuel Weiler To: Paul Hoffman In-Reply-To: <4A30B716-F051-41F5-B237-29C6397289A5@vpnc.org> Message-ID: References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> <4F2967EF.8070502@nlnetlabs.nl> <4A30B716-F051-41F5-B237-29C6397289A5@vpnc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 12 Mar 2012 17:24:06 -0400 (EDT) Cc: DNSEXT Working Group Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Wed, 1 Feb 2012, Paul Hoffman wrote: > 5.10 is long, scary, and useless for most environments because most > environments will have just one trust anchor. It is long and scary. Earlier discussion on list discarded several ways of helping with that. David and I came up with a new one: we stuck most of the text in an appendix. It's still long, but maybe it will now be less scary. I think this change is purely editorial; if we need to back it out later, we can. Please let us know if you like it. > 5.6 (setting the DO bit in replies) suggests resolvers should "be > liberal in what they accept". That's a bit vague. Instead, say ... > "Because some implementations ignore this rule on sending, the rule > for receivers is now that they MUST NOT expect the DO bit to be set > as it was sent." We have added normative language. I know Andrew was uneasy with that, having only heard from three of us (you, me, and David Blacka), but I continue to contend that this is the clearer way to say what we were saying anyway. Andrew, if you need to flag this in the proto write-up, feel free. -- Sam _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 14:24:21 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BEA11E8106; Mon, 12 Mar 2012 14:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331587461; bh=ipgd7+7em1N2gkhFWhHqnCTGTB1J4RGkceSDUHbbVvU=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=bMI9LUcnOTzXZV8O84rJUcURcfz8N7zJU1f/sPOwjPXa2eY0+0HWhnMsZHcerVb5c gIsJZ14IPW1xgiefe0qozEVxJgOYf96ICgTOUaxV3laxFU7gnOdoE2lbELo3U+oYih TP4AQkzO+Zigb2jZvwd21XOo+FcffDQRl5rt4E5Y= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CD811E80F0; Mon, 12 Mar 2012 14:24:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEAAP0iwyy73; Mon, 12 Mar 2012 14:24:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2967A11E80E3; Mon, 12 Mar 2012 14:24:19 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312212419.15127.4817.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 14:24:19 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-bis-updates-17.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Clarifications and Implementation Notes for DNSSECbis Author(s) : Samuel Weiler David Blacka Filename : draft-ietf-dnsext-dnssec-bis-updates-17.txt Pages : 20 Date : 2012-03-12 This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. This document updates the core DNSSECbis documents (RFC4033, RFC4034, and RFC4035) as well as the NSEC3 specification (RFC5155). It also defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-17.txt _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 17:18:52 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2DB21F8973; Mon, 12 Mar 2012 17:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331597932; bh=9YGjR9Wt4gf+heM3N6m6gmcihKjApAYNv7xYqX08pfc=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=Le7G1x6uiUsHfCrnbch6MBOU1p9Xc/Rg4EmVAGQ8nZ3ZYpj6PIv9B2QPrA0xXSaCj U+ZZLMp2QfQADuPi8Oh5kbsrStyluuguoeLSudljsLENaDyjFDGLBkZ5gB2aP5YA2H gqRs0sQv4uZgaQDnrJd/zDp+fXr5kroo1X6KdpGs= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65EE21F896E for ; Mon, 12 Mar 2012 17:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vaLKDAYuWEu for ; Mon, 12 Mar 2012 17:18:50 -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 53B5221F894E for ; Mon, 12 Mar 2012 17:18:50 -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 80920C942B; Tue, 13 Mar 2012 00:18:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7c2f:c400:f438:c0b]) (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 49AA7216C31; Tue, 13 Mar 2012 00:18:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 40A631E6C15E; Tue, 13 Mar 2012 11:18:32 +1100 (EST) To: Samuel Weiler From: Mark Andrews References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> <4F2967EF.8070502@nlnetlabs.nl> <4A30B716-F051-41F5-B237-29C6397289A5@vpnc.org> In-reply-to: Your message of "Mon, 12 Mar 2012 17:24:05 EDT." Date: Tue, 13 Mar 2012 11:18:32 +1100 Message-Id: <20120313001832.40A631E6C15E@drugs.dv.isc.org> Cc: Paul Hoffman , DNSEXT Working Group Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org I am still not happy with setion "5.9. Always set the CD bit on Queries" in draft-ietf-dnsext-dnssec-bis-updates-17. The recommendation to always set CD is flawed. Recommending that CD always be set fails to take into account normal expected operations issues and as such I do NOT recommend that this document be published as is. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 12 20:55:15 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9721521F8878; Mon, 12 Mar 2012 20:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331610915; bh=goViBQShYqmlsY08321MykMJR9HgMGQ0FG9A8K85nvg=; h=Date:From:To:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=n4GRLBr0IZHa1ZkKxaub6i8OBIUByYjR+WYFCHoanuqmqVYUCbIvyfdvjjX+zhlb5 U8eNfxUHyR08jHC8coSq9nv3d2cNPOQjRiEGQQCwJEs2CPNtBDBnRuJm/iOtp1IXKj 42/0smomR8XrIUbiTQ7BDKq1mbh3oSXd/FD/dvKE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BBE21F8878 for ; Mon, 12 Mar 2012 20:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvifBijR46zh for ; Mon, 12 Mar 2012 20:55:12 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 878D421F8877 for ; Mon, 12 Mar 2012 20:55:12 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id A34B4E0518; Tue, 13 Mar 2012 00:55:08 -0300 (BRT) Date: Tue, 13 Mar 2012 00:55:08 -0300 From: Frederico A C Neves To: dnsext@ietf.org Message-ID: <20120313035508.GA77638@registro.br> MIME-Version: 1.0 Content-Disposition: inline Subject: [dnsext] TLSA RRTYPE review - Comments period end Apr 3rd X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Dear Colleagues, Bellow is a completed template requesting a new RRTYPE assignment under the procedures of RFC6195. This message starts a 3 weeks period for an expert-review of the DNS RRTYPE parameter allocation for TLSA specified in http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt IANA #550878 If you have comments regarding this request please post them here before Apr 3rd 18:00 UTC. Best Regards, Frederico Neves --begin 6195 template TLSA-- A. Submission Date: 12 March 2012 B. Submission Type: [X] New RRTYPE [ ] Modification to existing RRTYPE C. Contact Information for submitter (will be publicly posted): Name: Warren Kumari Email Address: warren@kumari.net International telephone number: +1-571-748-4373 Other contact handles: D. Motivation for the new RRTYPE application. Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. The allocation of this RRTYPE will improve this situation by enabling the administrator of a domain name to certify the keys used in that domain's TLS servers by publishing information in the DNS. E. Description of the proposed RR type. A description of the RRtype is in draft-ietf-dane-protocol-18.txt, Section 2 The TLSA Resource Record ( http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt ) F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? The CERT (37) RR, RFC 4398 is closest. It is not suitable for this particular use as it is not flexible enough. It *would* be possible to shoehorn this into the CERT RR, but would be very kludgy. G. What mnemonic is requested for the new RRTYPE (optional)? TLSA H. Does the requested RRTYPE make use of any existing IANA registry or require the creation of a new IANA sub-registry in DNS Parameters? If so, please indicate which registry is to be used or created. If a new sub-registry is needed, specify the allocation policy for it and its initial contents. Also include what the modification procedures will be. This is in the the draft (http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt). It is included here for completeness, but reviewers are encouraged to consult the draft as the formatting is cleaner. #1: TLSA Usages. A new registry, "Certificate Usages for TLSA Resource Records". The registry policy is "RFC Required". The initial entries in the registry are: Value Short description Reference ---------------------------------------------------------- 0 CA constraint [This] 1 Service certificate constraint [This] 2 Trust anchor assertion [This] 3 Domain-issued certificate [This] 4-254 Unassigned 255 Private use #2: TLSA Selectors A new registry, "Selectors for TLSA Resource Records". The registry policy is "Specification Required". The initial entries in the registry are: Value Short description Reference ---------------------------------------------------------- 0 Full Certificate [This] 1 SubjectPublicKeyInfo [This] 2-254 Unassigned 255 Private use #3: TLSA Matching Types A new registry, "Matching Types for TLSA Resource Records". The registry policy is "Specification Required". The initial entries in the registry are: Value Short description Reference -------------------------------------------------------- 0 No hash used [This] 1 SHA-256 RFC 6234 2 SHA-512 RFC 6234 3-254 Unassigned 255 Private use I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No. J. Comments: A number of participants in DNSEXT / DNSOPS (and the DNS Directorate) have been involved in / following / are aware of this work. --end 6195 template TLSA-- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Mar 13 00:58:25 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7FB21F8876; Tue, 13 Mar 2012 00:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331625505; bh=oMWl7hM1uX9g2en3+KKzfAZ9NsunS1FlHH/eOHqS6k0=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=lnLXlG38i24GncLnY2UyBcYpoD9+heUsR2QlrZeSZrFWRvrTmBpR6tnrfe7YTKgsK EQGzK3/ASEIttQNVgWrB6aA6IoMkHu+Q41HuVe7Awo+GRChCCpmQ1HMdzo2RbXrfNQ jW6P13Fr4Mjrvs76gTWb9+dmzw1/bNrt23BixKFU= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7071421F8876 for ; Tue, 13 Mar 2012 00:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwUf7U3aVjje for ; Tue, 13 Mar 2012 00:58:23 -0700 (PDT) Received: from cuda.eurid.eu (cuda.eurid.eu [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id DA46021F883B for ; Tue, 13 Mar 2012 00:58:22 -0700 (PDT) X-ASG-Debug-ID: 1331625499-02dadd0668262bf0001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id gAnwtg4In6njd5nb for ; Tue, 13 Mar 2012 08:58:19 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id D8C13E406F for ; Tue, 13 Mar 2012 08:58:19 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbg8DFSu0KcP for ; Tue, 13 Mar 2012 08:58:19 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id C4213E4050 for ; Tue, 13 Mar 2012 08:58:19 +0100 (CET) From: "Marc Lampo" To: Date: Tue, 13 Mar 2012 08:58:19 +0100 (CET) X-ASG-Orig-Subj: FW: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt Message-ID: <016901cd00ef$0e09cf00$2a1d6d00$@lampo@eurid.eu> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Acz7tlEXRY5EuTLJQlOlwrinL3+ZSAAiQL0QASvgXsA= Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1331625499 X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: [dnsext] FW: I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org (resend, not sure if my original email made it to the list ?) -----Original Message----- From: Marc Lampo [mailto:marc.lampo@eurid.eu] Sent: 07 March 2012 09:55 AM Cc: 'dnsext@ietf.org' Subject: RE: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt Hello, Suggestion. In 6. Traffic Analysis Considerations "... should monitor DNS query traffic and record the values of the DAU/DHU/N3U option(s) in queries. ..." --> Suggest to add that also monitored are : - (number of) DNS Queries, with EDNS0 OPT record, but without any signalling done Motivation : The difference in number of queries with and without Algo-Signalling shows how reliable the signalling information is. Kind regards, Marc Lampo Security Officer EURid (for .eu) -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: 06 March 2012 05:30 PM To: i-d-announce@ietf.org Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Signaling Cryptographic Algorithm Understanding in DNSSEC Author(s) : Steve Crocker Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-signal-04.txt Pages : 8 Date : 2012-03-06 The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms and hash algorithms they support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Mar 13 01:07:41 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3F321F8847; Tue, 13 Mar 2012 01:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331626060; bh=wpiJ0j4cVQai69eCjLiXNlm+77D/qKitAVudDdZ+p9s=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=bRrzSeht/xdYyaedJ8KnLH9qqJ/oDXLZ650Ym56kzEkz7vMKakTze8tzBP4ziuj24 kDEgOjivPE5Um9fOAjkxReXAamZ8vqI9Z79+UUQ+WRHMFBLeeiaQA66AV9HO5VeyJF HNYEHkjKMDvsLUF+hCPZB+bBh3wbmOTTGCCAfkRg= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244AD21F8847 for ; Tue, 13 Mar 2012 01:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYtf-OZlQYhq for ; Tue, 13 Mar 2012 01:07:38 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8178521F8846 for ; Tue, 13 Mar 2012 01:07:38 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 7DFFF40034; Tue, 13 Mar 2012 09:07:31 +0100 (CET) Date: Tue, 13 Mar 2012 09:07:31 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120313080731.GA12019@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> <20120309090748.GA20102@miek.nl> <3B318BC7-749C-4885-A6B9-8BE91479D0F9@gmail.com> MIME-Version: 1.0 In-Reply-To: <3B318BC7-749C-4885-A6B9-8BE91479D0F9@gmail.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7105539736622653826==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============7105539736622653826== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting at 09:08 on Mar 12 in "Re: [dnsext] I-D A= ct..." ] > One reason we made it three unique options was so clients could mix > and match if they wanted. Especially since there is only one NSEC3 > hash algorithm code assigned for now. Upgrading hashes in NSEC3 is hard, upgrading NSEC3 (to whatever) is harder still. How about an extra option that lists which authenticated denial of existence records are understood. Something along the lines: An option code that signals which negative resource records an resolver can handle. When DNSSEC was first designed NXT, was defined, this was later renamed to NSEC. Later still NSEC3 was defined. Upgrading to a new authenticated denial of existence record is very hard. The upgrade to NSEC3 involved an algorithm roll, which is not desirable as we only have 8 bits in the algorithm field. So we define to following: NXU (NXDOMAIN Understood) 2 (length is always 2 octect) Type code of the highext NX=20 record understood. =20 This defaults to '50'. Regards, --=20 Miek Gieben --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9fAEMACgkQJYuFzziA0Pb0fQCfdNCQS/by4A9E3NWzIzL6ZQcV TP4AoNvn3hFBvM9KaJhsrARgQIBJIEgA =DHvx -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- --===============7105539736622653826== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============7105539736622653826==-- From dnsext-bounces@ietf.org Tue Mar 13 01:21:53 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA52821F8873; Tue, 13 Mar 2012 01:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331626913; bh=vTCGeIEkrGhbXvGsFgYDdBMWuwVMZ78kod4HHM2LaBc=; h=To:From:References:In-reply-to:Date:Message-Id:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=K7p9B1n7bYek34rzqEYJRn6MgI5QCsd8fiT7txQBiHqmmzwRPJpW3TbIhDzTpXyjE 6MnQ7RpMKFRBrkOkCkrfAgf8HyHEO4fxOZcJzI28l04gRUIac7wckwuWTIYRrSzowQ mZiP55x5tDITzAMrj0C4JaG0Yqq01n5J9UWf+mfE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6410E21F8873 for ; Tue, 13 Mar 2012 01:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvlbhvjNjkqU for ; Tue, 13 Mar 2012 01:21:50 -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 D2FA821F885A for ; Tue, 13 Mar 2012 01:21:50 -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 C8C3CC9424 for ; Tue, 13 Mar 2012 08:21:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7c2f:c400:f438:c0b]) (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 AC749216C31 for ; Tue, 13 Mar 2012 08:21:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 172C01E76A51 for ; Tue, 13 Mar 2012 19:21:23 +1100 (EST) To: dnsext@ietf.org From: Mark Andrews References: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> <20120309090748.GA20102@miek.nl> <3B318BC7-749C-4885-A6B9-8BE91479D0F9@gmail.com> <20120313080731.GA12019@miek.nl> Mail-Followup-To: dnsext@ietf.org In-reply-to: Your message of "Tue, 13 Mar 2012 09:07:31 BST." <20120313080731.GA12019@miek.nl> Date: Tue, 13 Mar 2012 19:21:22 +1100 Message-Id: <20120313082123.172C01E76A51@drugs.dv.isc.org> Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In message <20120313080731.GA12019@miek.nl>, Miek Gieben writes: > [ Quoting at 09:08 on Mar 12 in "Re: [dnsext] I-D A= > ct..." ] > > One reason we made it three unique options was so clients could mix > > and match if they wanted. Especially since there is only one NSEC3 > > hash algorithm code assigned for now. > > Upgrading hashes in NSEC3 is hard, upgrading NSEC3 (to whatever) is harder > still. > > How about an extra option that lists which authenticated denial of existence > records are understood. Something along the lines: > > An option code that signals which negative resource records an resolver > can handle. When DNSSEC was first designed NXT, was defined, this was > later renamed to NSEC. Later still NSEC3 was defined. Upgrading to a new > authenticated denial of existence record is very hard. The upgrade to NSEC3 > involved an algorithm roll, which is not desirable as we only have 8 bits in > the algorithm field. So we define to following: > > NXU (NXDOMAIN Understood) > 2 (length is always 2 octect) > Type code of the highext NX=20 > record understood. > =20 > This defaults to '50'. > > Regards, > > --=20 > Miek Gieben If you want to solve upgrading NSEC3's hash algorithm or BNAME etc. then that needs to be carried in the DS record so the zone can be treated as insecure. Defining DS hash types which have additional fields would be one way forward that is backwards compatible. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Mar 13 01:39:29 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6DA21F86C6; Tue, 13 Mar 2012 01:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331627969; bh=NBr6hNfaji2HcZSjQddFClcxsq6q2gaF4t90XVs9qBE=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=uiNTfJTUCt/1dbi/K+JfDB5Ub7tcGoNIICBdJ7iCMiPCfl/BmnODhUP0oPDky9RYN hyHg7pWi1oiSdyuMc1C0GrHr5AdObsW6LGQ1NkeG2mAl/2kqeCgmoXEvFN+6IFxsyX QSxhZ9bHYkYFZDE925g8qqmlBSsLQGlFCpl2qKqo= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DC821F86C6 for ; Tue, 13 Mar 2012 01:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaGH4db7Qxrh for ; Tue, 13 Mar 2012 01:39:27 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 70D2621F86C4 for ; Tue, 13 Mar 2012 01:39:27 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id BD7993FF30; Tue, 13 Mar 2012 09:39:26 +0100 (CET) Date: Tue, 13 Mar 2012 09:39:26 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120313083926.GB12019@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> <20120309090748.GA20102@miek.nl> <3B318BC7-749C-4885-A6B9-8BE91479D0F9@gmail.com> <20120313080731.GA12019@miek.nl> <20120313082123.172C01E76A51@drugs.dv.isc.org> MIME-Version: 1.0 In-Reply-To: <20120313082123.172C01E76A51@drugs.dv.isc.org> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0643114882370067138==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============0643114882370067138== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting at 19:21 on Mar 13 in "Re: [dnsext] I-D Act..." ] > > 2 (length is always 2 octect) > > Type code of the highext NX=3D20 > > record understood. > > =3D20 > > This defaults to '50'. > =20 > If you want to solve upgrading NSEC3's hash algorithm or BNAME etc. > then that needs to be carried in the DS record so the zone can be > treated as insecure. Defining DS hash types which have additional > fields would be one way forward that is backwards compatible. That's even better. Regards, Miek Gieben --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9fB74ACgkQJYuFzziA0PZZVwCeNFohvqB56Ihkz1PJFGYIPQlD AjYAn0DqqIKeyD6gAEy/4+4MfAmZ1B1+ =UJP5 -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- --===============0643114882370067138== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============0643114882370067138==-- From dnsext-bounces@ietf.org Tue Mar 13 07:24:32 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA6521F8824; Tue, 13 Mar 2012 07:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331648672; bh=3rRfDxW1oec65QG/NKBjWoj3S4wz/0wofsdJtzLxm3k=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Coshr6fIvCqF/34oIgX0run6NOZKHKoS1qFZrwpFu2GQUfX5tWPDipYr3ihmnqe68 D7imL/g2fgiBhYfUataxj6pdlQ/rrL9y5upqTRwDQU3D0xdxdpOrw1lAtAsTkTlmEa aZs7gGrv9Gr0cxFvzNfdQ+GJBP3qABa7HjA7xLX8= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F375C21F8824 for ; Tue, 13 Mar 2012 07:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVrPLP9KdVcB for ; Tue, 13 Mar 2012 07:24:30 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 094ED21F881F for ; Tue, 13 Mar 2012 07:24:29 -0700 (PDT) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q2DEMjkv007258; Tue, 13 Mar 2012 10:22:46 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Scott Rose In-Reply-To: <4f5efe2f.42c52a0a.3569.ffff81a7SMTPIN_ADDED@mx.google.com> Date: Tue, 13 Mar 2012 10:22:45 -0400 Message-Id: References: <4f5efe2f.42c52a0a.3569.ffff81a7SMTPIN_ADDED@mx.google.com> To: Marc Lampo X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Cc: dnsext@ietf.org Subject: Re: [dnsext] FW: I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Marc, Ok, Section 6 needs a revision and I will include your comment. Thanks for the review, Scott On Mar 13, 2012, at 3:58 AM, Marc Lampo wrote: > (resend, not sure if my original email made it to the list ?) > > -----Original Message----- > From: Marc Lampo [mailto:marc.lampo@eurid.eu] > Sent: 07 March 2012 09:55 AM > Cc: 'dnsext@ietf.org' > Subject: RE: [dnsext] I-D Action: > draft-ietf-dnsext-dnssec-algo-signal-04.txt > > Hello, > > Suggestion. > > In 6. Traffic Analysis Considerations > > "... should monitor DNS query > traffic and record the values of the DAU/DHU/N3U option(s) in > queries. ..." > > --> Suggest to add that also monitored are : > - (number of) DNS Queries, with EDNS0 OPT record, but without any > signalling done > > Motivation : > The difference in number of queries with and without Algo-Signalling > shows how reliable the signalling information is. > > Kind regards, > > Marc Lampo > Security Officer > EURid (for .eu) > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 06 March 2012 05:30 PM > To: i-d-announce@ietf.org > Cc: dnsext@ietf.org > Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the DNS Extensions Working Group > of the IETF. > > Title : Signaling Cryptographic Algorithm Understanding in DNSSEC > Author(s) : Steve Crocker > Scott Rose > Filename : draft-ietf-dnsext-dnssec-algo-signal-04.txt > Pages : 8 > Date : 2012-03-06 > > The DNS Security Extensions (DNSSEC) were developed to provide origin > authentication and integrity protection for DNS data by using digital > signatures. These digital signatures can be generated using > different algorithms. This draft sets out to specify a way for > validating end-system resolvers to signal to a server which > cryptographic algorithms and hash algorithms they support. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Mar 13 10:38:26 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6192521E8043; Tue, 13 Mar 2012 10:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331660306; bh=UEo5gVbQqBhDwZ0rpZoQpR3D4dyMdE2dD1mKnTRgRWA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=cDP3V5F4TUhkIS1RmHggfTfseWVUqbOd4FOPmmnsUVgoQhispMH6N8Bv+v4ePV1Pe H39Nwr1tJ2EMncakP4atOG/hX4ZuLi0Cl+iSByy8jshHO8DsqFbKSntKul/xaOUL9b LbBE0GiVdgavEqLdqiX2+ntGray7IZWiQ8jS7wlw= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A1D21E8050 for ; Tue, 13 Mar 2012 10:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dbm+93aFSF-9 for ; Tue, 13 Mar 2012 10:38:21 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2B921E8040 for ; Tue, 13 Mar 2012 10:38:21 -0700 (PDT) Received: by ggmi1 with SMTP id i1so941967ggm.31 for ; Tue, 13 Mar 2012 10:38:20 -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:content-transfer-encoding; bh=a3IoWWCJMmAHX4dr8uKvoX3cE23Pi6CcznrxgHqeKDY=; b=YOzV89sN4LvN6M9/JcFnBYr7hG3dcJlxO6FJRcVdFtQLClwPC7gncl/qJ4JOYxUW3Q fYpCD6EsckxzeCHOHSFJNkEDOGVs8BLpAXEt4i7NC7q7YKmqmqfgO63eigFJJ2aNjQAH bANpb44hy6HiufhwjjRq+sNzb6KtTtw4f3T9NRK2FV4DDy4q5BsXQibLYp2IlF64vNgN 5omZK2IMkcgB/N/6cP05eWr/MCd1SNRGxV9hRo+8WTNlP5KgCAIVdUm5IWJrEhfP/6OE DdQ4BUKxrrmB95CY1zsCFC8wfmW+s8PsATbOoy1DbEjL7ElTN+Hqhh+Ko05mSlerVCSz N5Cg== MIME-Version: 1.0 Received: by 10.224.184.10 with SMTP id ci10mr84427qab.4.1331660300614; Tue, 13 Mar 2012 10:38:20 -0700 (PDT) Received: by 10.229.234.67 with HTTP; Tue, 13 Mar 2012 10:38:20 -0700 (PDT) In-Reply-To: References: <20120120054939.GD4365@mail.yitter.info> Date: Tue, 13 Mar 2012 10:38:20 -0700 Message-ID: From: Mohan Parthasarathy To: Samuel Weiler Cc: DNSEXT Working Group Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mon, Mar 12, 2012 at 12:41 PM, Samuel Weiler wrote: > On Fri, 27 Jan 2012, Mohan Parthasarathy wrote: > >> - Section 4.4 Insecure Delegation proofs last sentence is very >> confusing. An example as to what attack this is describing would be >> helpful to the implementer. > > > Here's an example of the attack we're trying to avoid. =A0Consider a sign= ed > zone that contains the names: > =A0alfa.example.com. > and > =A0bravo.alfa.example.com. > > alfa.example.com is NOT a delegation. =A0Instead, it has this NSEC record: > > =A0 =A0 =A0 =A0alfa.example.com. 86400 IN NSEC host.example.com. ( > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A MX RRSIG NSEC TYPE1234 ) > > The quesion is: could an attacker use this NSEC record in reply to a query > for bravo.alfa.example.com, replying with either a spoofed > bravo.alfa.example.com or even claiming the name doesn't exist? =A0Under = the > old rules, read literally, that attack would work: the NSEC does not have= a > DS or SOA bit. =A0It also does not have an NS bit, but the rules did not = say > to check for that. > When proving that the delegation is not secure (which is what this section is talking about), the NSEC record has to match the name that is being looked up. If the names don't match, then it can't be a delegation. David's response clarified this. > The forthcoming -17 has that section somewhat reworked. =A0There still is= no > example in. =A0Let us know if you really want that. > This is the new text: 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. Though the text is improved, it is easy to understand if you read this text along with the example. -mohan > (note: the error is also broken, since bravo.alfa.example.com sorts before > host.example.com. =A0maybe there are multiple ways to catch this attack.) > > >> - The "Security Considerations" section says: >> >> =A0 =A0This document adds two cryptographic features to the core DNSSEC >> protocol. >> >> =A0 Is this referring to the algorithms mentioned in section 2.2 ( >> which actually lists three) =A0or something else ? > > > clarified. > > -- Sam > _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 16 10:47:38 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146D921E8056; Fri, 16 Mar 2012 10:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331920058; bh=hSxAUmDPoPDlAag951rDmrAteSomzhlJyzoV9s+NiIQ=; h=From:Date:Message-Id:To:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Zt9l1J/dp+NHIpD1U4l9Cf9PWZ7MNNmh2S7O8JAfTTn7Mv+bBM1Uf6IlXfLQfjjkX GpGy1aJpaTIOTlHOH7rqNZyK4N8UJbJdzRUvjmRQKYTsyyaUm70+XeBmod7V8Xjtsq m6J5jl3GkJ+lvo6uL6HZ5Q2tWrt6+B6B6esxpciU= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13ABA21E8056 for ; Fri, 16 Mar 2012 10:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17FcB5XTYRMT for ; Fri, 16 Mar 2012 10:47:36 -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 99E8221E8012 for ; Fri, 16 Mar 2012 10:47:36 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2GHlYgQ047335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 16 Mar 2012 10:47:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Date: Fri, 16 Mar 2012 10:47:33 -0700 Message-Id: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> To: DNSEXT Working Group Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Over on the dns-operations list, the issue of zone cuts has come up, and even normally-careful people have gotten it wrong. Is there a readable introduction to zone cuts and how they affect zone operators? If not, someone should really consider writing a two-page informational RFC on the subject and have it reviewed here (even if it is after this WG shuts down) before publication. I suspect that such an RFC will be more valuable to the Internet than many of the ones we have done here. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 16 12:34:17 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947BE21F86F3; Fri, 16 Mar 2012 12:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331926457; bh=LKTHf3ByQjL6Dog7YsOQdWf/IsT7yCbTKqNBS7bmj2g=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=HxYPvpFiRjx+MGkC/Qu/C6KXCxkDeKe9XlCL9tJScSEYqDIeXikgbgJZauWXnO9lR B4CH7w5YWSwbuPoEDQFFnBGJzO+Wg5zO77mZh2coAtv7jThd08WcS7B4EWh1yhK3LM N+q+xgXar7fg0/wBU2GmkFOvEPrjct4m/+pRktsg= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E16221E8071; Fri, 16 Mar 2012 12:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCyVidz4EKtq; Fri, 16 Mar 2012 12:34:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC00721E801A; Fri, 16 Mar 2012 12:34:15 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120316193415.13655.92458.idtracker@ietfa.amsl.com> Date: Fri, 16 Mar 2012 12:34:15 -0700 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS0)) to Full Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Extension Mechanisms for DNS (EDNS0)' as a Full Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-30. 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 EDNS0 specification (RFC 2671) based on feedback from deployment experience in several implementations. It also closes the IANA registry for extended labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name System") which depends on the existence of extended labels. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2671bis-edns0/ Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2671bis-edns0/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 16 16:36:44 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC2E21E8083; Fri, 16 Mar 2012 16:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331941004; bh=fAHOd1cjqrRPhDhJ00ayftUKvpH56RU8sFAMYq6NYOI=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=PMhwQWIF0nmY2/LZDSuURao+ByHbR+/qAATCYWWz+MDGLN9b39Xnd7usdd6+PTIuA eXPWi2r0E2bBPT9lfQXew3VbSILU0Ykbi3fVnGaZqCin0CY2OL4ON5eButokY0L5yf T7Xd+nTEGwRy4EzxXoyX5Pt89YbstbScaJoXbQAY= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41121E8083 for ; Fri, 16 Mar 2012 16:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, MANGLED_REALLY=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL1TH95nAlEF for ; Fri, 16 Mar 2012 16:36:43 -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 D480521E8014 for ; Fri, 16 Mar 2012 16:36:42 -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 198085F9865; Fri, 16 Mar 2012 23:36:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:d1fb:f2c0:5ce0:8d7d]) (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 29C62216C36; Fri, 16 Mar 2012 23:36:21 +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 16C831E9F8E3; Sat, 17 Mar 2012 10:36:18 +1100 (EST) To: Paul Hoffman From: Mark Andrews References: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> In-reply-to: Your message of "Fri, 16 Mar 2012 10:47:33 PDT." <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> Date: Sat, 17 Mar 2012 10:36:18 +1100 Message-Id: <20120316233618.16C831E9F8E3@drugs.dv.isc.org> Cc: DNSEXT Working Group Subject: Re: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In message <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org>, Paul Hoffman writes : > Over on the dns-operations list, the issue of zone cuts has come up, and even > normally-careful people have gotten it wrong. Is there a readable introducti > on to zone cuts and how they affect zone operators? If not, someone should re > ally consider writing a two-page informational RFC on the subject and have it > reviewed here (even if it is after this WG shuts down) before publication. I > suspect that such an RFC will be more valuable to the Internet than many of > the ones we have done here. > > --Paul Hoffman RFC 1034 say all you need to say for zone operators about NS record. Nameserver developer need to know more. Section 4.2.2. "Administrative considerations" covers just about all that one needs to know in particular "As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so." This apply to both registries and registrars as the are the administators of the relevent zones. Failure to follow that advice causes most of the operational problems we see in the DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sat Mar 17 06:31:28 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E9421F85EA; Sat, 17 Mar 2012 06:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331991088; bh=4Mb0jQLISGsWiYRNkY7awg14QDWm4BgfosEgZTba4oU=; h=From:To:Date:Message-ID:References:In-Reply-To:Content-ID: MIME-Version:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type: Content-Transfer-Encoding:Sender; b=faAEJAvLFNWsdrVyuSW0vybZ6IFy9DvhozsWjkZnaxJs5FQq1PzLSwUFgrczVbjXF HySSQNhmOa2Lf77d9QlW+YLCMEAXwzNetg8wxoQTvpSTqB/q9JC0Hc/+qxvvBx6Oon DUO6C7QH02MmdTCtH5K8omdIM0YkZxHZAGhFCoPc= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E73621F8604 for ; Sat, 17 Mar 2012 06:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.552 X-Spam-Level: X-Spam-Status: No, score=-9.552 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpxsKrFv9ZMl for ; Sat, 17 Mar 2012 06:31:24 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id F2B9321F85EA for ; Sat, 17 Mar 2012 06:31:23 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=eQ5/sGNOsNfvR0DyHIjZpnEtI9QPMnOmFxISkKyn1N4EqcymdmcevqhW dPcy1/REgl2UHIfX2gIOtoTaeBQOccuIhUFxQuLk3+NYelFs9wencZvAi lMIuNzV7G5l2YDu; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1331991084; x=1363527084; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[dnsext]=20Short=20introduction=20to=20 zone=20cuts?|Date:=20Sat,=2017=20Mar=202012=2013:31:40=20 +0000|Message-ID:=20<8D53F412-A917-4DB2-9B7F-527B8FDD6779 @nominet.org.uk>|To:=20Mark=20Andrews=20 |CC:=20Paul=20Hoffman=20,=20DNSEXT =20Working=20Group=0D=0A=09 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20|In-Reply-To:=20<20120316233618.16C831E9F8E3@drugs.d v.isc.org>|References:=20<946E9EC4-9872-4A98-BCEB-3CD7420 929A1@vpnc.org>=0D=0A=20<20120316233618.16C831E9F8E3@drug s.dv.isc.org>; bh=SqV7xb/VN7yiagUsqbcP38U1iPESyTxexdMJI8KKlRE=; b=sTlW5sAZsx+Zt0Ns613YLeuClyAZON1VoLqeQB59XfXnI+ZPlTVoLYY0 GFUytzR4UN37Jl1FRMhuNbCC3aGh17MAx8HLu55v4LKgVGJcNcxsh7q6X CP5zA3ENoY2YAxV; X-IronPort-AV: E=Sophos;i="4.73,602,1325462400"; d="scan'208";a="38937199" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 17 Mar 2012 13:31:21 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Sat, 17 Mar 2012 13:31:21 +0000 From: Ray Bellis To: Mark Andrews Thread-Topic: [dnsext] Short introduction to zone cuts? Thread-Index: AQHNA5zsYFL40qEpS0Ktdz4KXCtF9ZZtlCQkgADpMwA= Date: Sat, 17 Mar 2012 13:31:40 +0000 Message-ID: <8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet.org.uk> References: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> <20120316233618.16C831E9F8E3@drugs.dv.isc.org> In-Reply-To: <20120316233618.16C831E9F8E3@drugs.dv.isc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: MIME-Version: 1.0 Cc: Paul Hoffman , DNSEXT Working Group Subject: Re: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 16 Mar 2012, at 23:36, Mark Andrews wrote: > RFC 1034 say all you need to say for zone operators about NS record. IMHO, there's more to it than that. For example, if you have this in a parent zone: 1.1.1.1.5.5.5.3.0.2.1.e164.arpa. IN NS ns1.example.com and this in the child zone: $ORIGIN 5.5.5.3.0.2.1.e164.arpa. @ SOA ... @ NS ns1.example.com 0.0.0.0 NAPTR ... 1.0.0.0 NAPTR ... it currently works - the parent zone points to the right server, but the parent and child disagree on where the zone cut is. However with DNSSEC that is no longer possible. There's nowhere to put the DS record. For various historic reasons, the UK public ENUM tree has per-number NS records as shown above. To make the parent and child consistent (without changing the parent) the child server would need to have a separate zone file _per number_. Ray _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sat Mar 17 07:41:13 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9260021F858E; Sat, 17 Mar 2012 07:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331995273; bh=MDr6aBpJB8IwkavmLQPUsSZ+Jz5O1J5q+UmCc8B9VjQ=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=FKMdoSic7VEipjRAF1YZf/6YoAduHBUj6hAvB3Ds90azwhLF9tT6y/JYYAK6L1sEw TPUhfZUT2EYNqJwHNQ6gf60pzEv56WZnIWsmF4Q1elZGwRE++2b609xPq3tIHH2T0F uoXwu0j76NBP9N6A8noq0WW0UgQSuh2kBkxHRLzQ= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B812C21F858E for ; Sat, 17 Mar 2012 07:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.54 X-Spam-Level: X-Spam-Status: No, score=-101.54 tagged_above=-999 required=5 tests=[AWL=-1.241, BAYES_00=-2.599, MANGLED_REALLY=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoTyMtg53aTc for ; Sat, 17 Mar 2012 07:41:11 -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 DFAF021F8589 for ; Sat, 17 Mar 2012 07:41:10 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2HEf7Pa080725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 17 Mar 2012 07:41:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <20120316233618.16C831E9F8E3@drugs.dv.isc.org> Date: Sat, 17 Mar 2012 07:41:08 -0700 Message-Id: <68D9EB4A-78FB-428D-B312-165343DDB9FF@vpnc.org> References: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> <20120316233618.16C831E9F8E3@drugs.dv.isc.org> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1257) Subject: Re: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mar 16, 2012, at 4:36 PM, Mark Andrews wrote: > > In message <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org>, Paul Hoffman writes > : >> Over on the dns-operations list, the issue of zone cuts has come up, and even >> normally-careful people have gotten it wrong. Is there a readable introducti >> on to zone cuts and how they affect zone operators? If not, someone should re >> ally consider writing a two-page informational RFC on the subject and have it >> reviewed here (even if it is after this WG shuts down) before publication. I >> suspect that such an RFC will be more valuable to the Internet than many of >> the ones we have done here. >> >> --Paul Hoffman > > RFC 1034 say all you need to say for zone operators about NS record. As we have seen, the text in RFC 1034 has not been sufficient to prevent errors. A clearly-written document might help prevent errors. Some of us would prefer to prevent errors rather than just criticize the people who cannot read the source documents as well as you can. > Nameserver developer need to know more. And, as such, would be valuable to document in an informational RFC, given that we see errors in that all the time. The two sets of information are quite related. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sat Mar 17 16:37:43 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4EE21F85EE; Sat, 17 Mar 2012 16:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332027463; bh=dU2voAaIrh3s2N/X9YC8kgOkz48xlyH7cYp7Cvu3Tjw=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=TJosJQFNelY0Ce2xQj8Uv8Rclpk8x3X4dNrwZemASDEbCZRgYpfjkwEtQQ3FgU+aB BlF/9x1SG3xKOqvsl8TphdwroYGAXQoBavoVTEJelPPmnB1gXSOS2WjG8P0BLlc6CT ZgDMRKlt+Tcy/9ghdANcQHj7zv7XxHseIMKyfdmE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C748F21F85EE for ; Sat, 17 Mar 2012 16:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwxDwh9X1ML9 for ; Sat, 17 Mar 2012 16:37:41 -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 EAD5721F85ED for ; Sat, 17 Mar 2012 16:37:40 -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 14E55C9423; Sat, 17 Mar 2012 23:37:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:8568:13ff:fc38:4b7]) (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 C6F9F216C31; Sat, 17 Mar 2012 23:37:21 +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 A52EB1EA2B98; Sun, 18 Mar 2012 10:37:14 +1100 (EST) To: Paul Hoffman From: Mark Andrews References: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> <20120316233618.16C831E9F8E3@drugs.dv.isc.org> <68D9EB4A-78FB-428D-B312-165343DDB9FF@vpnc.org> In-reply-to: Your message of "Sat, 17 Mar 2012 07:41:08 PDT." <68D9EB4A-78FB-428D-B312-165343DDB9FF@vpnc.org> Date: Sun, 18 Mar 2012 10:37:14 +1100 Message-Id: <20120317233714.A52EB1EA2B98@drugs.dv.isc.org> Cc: DNSEXT Working Group Subject: Re: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In message <68D9EB4A-78FB-428D-B312-165343DDB9FF@vpnc.org>, Paul Hoffman writes : > On Mar 16, 2012, at 4:36 PM, Mark Andrews wrote: > > > > > In message <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org>, Paul Hoffman wr > ites > > : > >> Over on the dns-operations list, the issue of zone cuts has come up, and e > ven > >> normally-careful people have gotten it wrong. Is there a readable introduc > ti > >> on to zone cuts and how they affect zone operators? If not, someone should > re > >> ally consider writing a two-page informational RFC on the subject and have > it > >> reviewed here (even if it is after this WG shuts down) before publication. > I > >> suspect that such an RFC will be more valuable to the Internet than many o > f > >> the ones we have done here. > >> > >> --Paul Hoffman > > > > RFC 1034 say all you need to say for zone operators about NS record. > > As we have seen, the text in RFC 1034 has not been sufficient to prevent erro > rs. A clearly-written document might help prevent errors. Some of us would pr > efer to prevent errors rather than just criticize the people who cannot read > the source documents as well as you can. Please go survey those that have made errors and ask them if there are supposed to be matching NS records in the parent and child zones. I know that ISC's error a couple of weeks back were not due to lack of knowledge. There are lots of documents on the net on how to delegate a zone. Of those I've checked they all say to add matching NS records to the parent zone. One more won't help. People either don't read, make a mistake, or deliberately choose to do the wrong thing. > > Nameserver developer need to know more. > > And, as such, would be valuable to document in an informational RFC, given th > at we see errors in that all the time. The two sets of information are quite > related. We already have documents that tell implementors what to do. > --Paul Hoffman > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sat Mar 17 18:36:49 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA5B21F85C2; Sat, 17 Mar 2012 18:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332034609; bh=52wOFhdbrg+ieAGxmu+VvXQ9L+QvGIERYQGaD4P7iPI=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=vRU95+Shgx+rsfKqu4xICdjZqguv6bqii+g6h9kdTU+7cxbP+ITeEdyNrLzXKycUA QLQhrG8EQaWQj/GXwG4VGkvQFpqRgYmc39yDbaFE9Wt7g18M1GzVAS+E+twxs/MlZZ 76hHAXlMFjWpIBiJYgzXyNQtcrKpfjOOIJuqaHWo= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5906921F85C2 for ; Sat, 17 Mar 2012 18:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsb09D+sr0CQ for ; Sat, 17 Mar 2012 18:36:47 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id A170B21F85C0 for ; Sat, 17 Mar 2012 18:36:47 -0700 (PDT) Received: (qmail 25548 invoked by uid 399); 18 Mar 2012 01:36:43 -0000 Received: from unknown (HELO opti.dougb.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 18 Mar 2012 01:36:43 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F653C29.2070103@dougbarton.us> Date: Sat, 17 Mar 2012 18:36:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ray Bellis References: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> <20120316233618.16C831E9F8E3@drugs.dv.isc.org> <8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet.org.uk> In-Reply-To: <8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet.org.uk> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Cc: Paul Hoffman , DNSEXT Working Group Subject: Re: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 03/17/2012 06:31, Ray Bellis wrote: > > On 16 Mar 2012, at 23:36, Mark Andrews wrote: > >> RFC 1034 say all you need to say for zone operators about NS record. > > IMHO, there's more to it than that. > > For example, if you have this in a parent zone: > > 1.1.1.1.5.5.5.3.0.2.1.e164.arpa. IN NS ns1.example.com > > and this in the child zone: > > $ORIGIN 5.5.5.3.0.2.1.e164.arpa. > @ SOA ... > @ NS ns1.example.com > 0.0.0.0 NAPTR ... > 1.0.0.0 NAPTR ... > > it currently works - the parent zone points to the right server, but the parent and child disagree on where the zone cut is. I'm not sure what you mean by "works" here. If you mean that anyone using ns1.example.com directly will see those records, then yes, it works -- for those users. But assuming that ns1.example.com is not included in the NS set of the parent zone, no one else will see the 2 NAPTR records you listed above. So in that sense it doesn't work ... at least, it doesn't work the way that the administrator of ns1.example.com wants it to. Doug -- If you're never wrong, you're not trying hard enough _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 19 07:58:25 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A064121F8857; Mon, 19 Mar 2012 07:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332169105; bh=HXT87bTJA0TA3eSSXYHQLnhx7WG7UBnPBvc+lyXRdOE=; h=From:To:Date:Message-ID:References:In-Reply-To:Content-ID: MIME-Version:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type: Content-Transfer-Encoding:Sender; b=QOXb67QnKw01la16WNDzELPDa/SEQInifECJY+AwcTP44EzFWZ0S240jpVCWsZpOe W8h+yZBA/ObN/4L0ygT+kP/odATuOB25Y3VvROYNV9ioi8z8jeWo8pDELUt+FvvOtz R1iV98KBnJvmcM3XbbdlUWYUwEiSPMb4le7jc6tE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DFE21F8844 for ; Mon, 19 Mar 2012 07:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.303 X-Spam-Level: X-Spam-Status: No, score=-10.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcHmV9R96mbN for ; Mon, 19 Mar 2012 07:58:23 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id D06E021F87A0 for ; Mon, 19 Mar 2012 07:58:21 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=uiFgnPNOgSF2j2vZmxo9y4jlhj2kmIUpmyGPJXGxYIEiE8Mgu/UkwL51 5ulvaHDu4V2iXu4e1IIU33XjQMxBXCAY0xwO6/cKaFfo/shUr1tx47Mvy MC2QMP0mCuQoe3p; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1332169103; x=1363705103; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[dnsext]=20Short=20introduction=20to=20 zone=20cuts?|Date:=20Mon,=2019=20Mar=202012=2014:58:19=20 +0000|Message-ID:=20|To:=20Doug=20Barton=20|CC:=20Mark=20Andrews=20,=20Paul=20Hoff man=20,=20DNSEXT=0D=0A=20Working =20Group=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<19cde0a1-3f7b-48a0-a400-ef478ffc4de1> |In-Reply-To:=20<4F653C29.2070103@dougbarton.us> |References:=20<946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc .org>=0D=0A=20<20120316233618.16C831E9F8E3@drugs.dv.isc.o rg>=0D=0A=20<8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet .org.uk>=0D=0A=20<4F653C29.2070103@dougbarton.us>; bh=Sbe4jmZwm5yj1+IQTMs+2/e7JbwKE7wE3VrK52fgMT0=; b=xEwRphvkDmBstn+oHR2Ozyoo7A++a5DpD4DXu2AJgQxv9sM55qBc+gW7 ZZz/ZZX49XS+W91a2rgLacsEKMDN0pVuivkIFPrdykEelU3lzW0/084V7 9xy+Ug9QzBFiHpi; X-IronPort-AV: E=Sophos;i="4.73,612,1325462400"; d="scan'208";a="32068607" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 19 Mar 2012 14:58:20 +0000 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Mon, 19 Mar 2012 14:58:20 +0000 From: Ray Bellis To: Doug Barton Thread-Topic: [dnsext] Short introduction to zone cuts? Thread-Index: AQHNA5zsYFL40qEpS0Ktdz4KXCtF9ZZtlCQkgADpMwCAAMqSgIACck6A Date: Mon, 19 Mar 2012 14:58:19 +0000 Message-ID: References: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> <20120316233618.16C831E9F8E3@drugs.dv.isc.org> <8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet.org.uk> <4F653C29.2070103@dougbarton.us> In-Reply-To: <4F653C29.2070103@dougbarton.us> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <19cde0a1-3f7b-48a0-a400-ef478ffc4de1> MIME-Version: 1.0 Cc: Paul Hoffman , DNSEXT Working Group Subject: Re: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 18 Mar 2012, at 01:36, Doug Barton wrote: > I'm not sure what you mean by "works" here. I mean the NAPTR records correctly resolve. > If you mean that anyone > using ns1.example.com directly will see those records, then yes, it > works -- for those users. But assuming that ns1.example.com is not > included in the NS set of the parent zone, no one else will see the 2 > NAPTR records you listed above. So in that sense it doesn't work ... at > least, it doesn't work the way that the administrator of ns1.example.com > wants it to. No, in this case "ns1.example.com" _is_ found via the parent zone, but the delegation is four nodes further down the DNS tree than the child's SOA / NS records would indicate. Ray _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 19 08:41:13 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AEC21F8841; Mon, 19 Mar 2012 08:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332171673; bh=68cnv4SGJhp38haHXoIiaJTSUDFxXSPFM23gk+nX6K8=; h=From:Date:Message-Id:To:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=JUh4RqkB53dXtE5Bap1ag71TxCQSAO+xgC+8TbfScGz83pHWxMZ0pq+LDJpa/DWJo a038bJc3Z0R8aKXcvt6HpnO7l+a6XaqasDFEwPAB+C+66oYhCsJsfTZDlUwZ8EMWeP wtEByRIUiuY1IAMx3xLcGEQRYn/w6fr1vlfVu+Uw= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C6821F8841 for ; Mon, 19 Mar 2012 08:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-t7m6LTZDKk for ; Mon, 19 Mar 2012 08:41:08 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 73F1421F8834 for ; Mon, 19 Mar 2012 08:41:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 6170A2C4029 for ; Mon, 19 Mar 2012 08:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FMFS7a9SfERF; Mon, 19 Mar 2012 08:41:07 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 31D282C4002; Mon, 19 Mar 2012 08:41:07 -0700 (PDT) From: Nicholas Weaver Date: Mon, 19 Mar 2012 08:41:07 -0700 Message-Id: To: dnsext List Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dnsext] Capture signature chain? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Is there currently a standard wire/storage format for capturing the entire DNSSEC signature chain required for validation in a single transaction? _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 19 09:11:17 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC8621F8865; Mon, 19 Mar 2012 09:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332173477; bh=cWsjQVpfxHAskE5inBuS+epSd7NL1G5ukM+9Co4SxHo=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=jkEGCR97MJMzHd0n+ivvylKXn7VV4Wd33dlexMnfQHYMjyEDJtiXq1VcVMSEK3Kl9 iEOR2Xfz9ObT2kCLfZHMhOg5aVL9hIe7l5iHa+lNdqKZp2rJtWV+bRdMlNEpx9mqAj Df/3jFM9QFga0C32ARVL3IPNHDEPY6J5GWZ6YvEg= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1773721F8865 for ; Mon, 19 Mar 2012 09:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcObftq3jTIG for ; Mon, 19 Mar 2012 09:11:10 -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 5B80E21F885B for ; Mon, 19 Mar 2012 09:11:10 -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-2.csi.cam.ac.uk ([131.111.8.54]:60367) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1S9fAq-0002iA-rR (Exim 4.72) (return-path ); Mon, 19 Mar 2012 16:11:08 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S9fAq-000816-Hb (Exim 4.67) (return-path ); Mon, 19 Mar 2012 16:11:08 +0000 Date: Mon, 19 Mar 2012 16:11:08 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nicholas Weaver In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Cc: dnsext List Subject: Re: [dnsext] Capture signature chain? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Nicholas Weaver wrote: > Is there currently a standard wire/storage format for capturing the > entire DNSSEC signature chain required for validation in a single > transaction? No. I would recommend just listing all the relevant RRsets in DNS wire format. There is also http://tools.ietf.org/html/draft-agl-dane-serializechain-01 which tries to omit unnecessary data. Tony. -- f.anthony.n.finch http://dotat.at/ Northwest FitzRoy, Sole: Mainly southwesterly 4 or 5, increasing 6 at times in west. Moderate or rough. Fair. Good. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 19 09:29:15 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A83D21F881D; Mon, 19 Mar 2012 09:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332174555; bh=kIFf/9GvVZPxpuBQDSuctxQtLHP1v8n6uge36jxjqaM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=DQclzz2alYttMLvptOLBuFF8WFdiP95qmLm1MqDenwGXAlWcmWNCwI3z3ErkV/flI Q9d5AuyIP3PQ0iSuAVA5GJwpCA+e3OqxjijBYMuFN9RGEBhyKxU1bglb+Tm1EWCbS0 uTeJ5i5qP6PyoSMsoIwaFb6N0XiSNOFjbjpq4SNk= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0183321F881D for ; Mon, 19 Mar 2012 09:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.398 X-Spam-Level: X-Spam-Status: No, score=-104.398 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R30jx7JOaSIh for ; Mon, 19 Mar 2012 09:29:13 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEB121F874C for ; Mon, 19 Mar 2012 09:29:12 -0700 (PDT) Received: by lagj5 with SMTP id j5so5750044lag.31 for ; Mon, 19 Mar 2012 09:29:12 -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 :content-type:content-transfer-encoding; bh=w/Pm2e1XYxZUnFfTVRSl8St3zjCwEQDidy1TQiwRNpc=; b=RnpdGdUmRl9uzYH9tKZVQtlUuatlyiaHjKupEG2lAmxFTjHO65s81ztdBrrwS40SAp pJyd/A8klTa6p6j409IhlR7Zuo4dmJbBfPlQPJLnhNfRNCx22ozs63qoK+hPJXMCOWHq gfdjFqJFllIvnyt6/qWcAbUxrJgITSHw3CQcYxXIV7x5sdVMnriOXXgVmJdPUE7bdu4j RmJhGC/sVJBkGiylhs99zkVY+b6xHVHUt0lSGzmUZhS+7lBIvz9ruznynBOB0T8BqfPG tQbvFuEaFNv8edUVgzvaTmAMAoF+eaeVmygUdY3gim9sY52RmRWADaOzqwD/ON/INRee /dxw== Received: by 10.112.41.169 with SMTP id g9mr3841951lbl.59.1332174551985; Mon, 19 Mar 2012 09:29:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.128.40 with HTTP; Mon, 19 Mar 2012 09:28:51 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Mon, 19 Mar 2012 12:28:51 -0400 Message-ID: To: dnsext List Subject: Re: [dnsext] Capture signature chain? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org There is always RFC 2540. 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 On Mon, Mar 19, 2012 at 12:11 PM, Tony Finch wrote: > Nicholas Weaver wrote: > >> Is there currently a standard wire/storage format for capturing the >> entire DNSSEC signature chain required for validation in a single >> transaction? > > No. I would recommend just listing all the relevant RRsets in DNS wire > format. There is also > http://tools.ietf.org/html/draft-agl-dane-serializechain-01 > which tries to omit unnecessary data. > > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > Northwest FitzRoy, Sole: Mainly southwesterly 4 or 5, increasing 6 at tim= es in > west. Moderate or rough. Fair. Good. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 19 10:15:33 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1FD21F888D; Mon, 19 Mar 2012 10:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332177333; bh=XpLLD4BUShyJ4NQe6snqmusmHi4hlXzP4bbnzeuUPpI=; h=Message-ID:Date:From:MIME-Version:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=fqMIjsQT8FHC7y1QhZgrQ9Rr2nvJN8PW/OUCf5s6mi+NqiWVrzOzJRA1FVjjR3M9q vVeDvmHwI1nP8SP77iQOvB+f2sR92c4501+b97uTgo/9YgbCjEfTnlLHzzDRbm9l+k /hGCqy9SltqwMsCAfmjbjci0RALSDIQAIe+ORQTE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A268D21F888D for ; Mon, 19 Mar 2012 10:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.865 X-Spam-Level: X-Spam-Status: No, score=-98.865 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVol5HIDRrQa for ; Mon, 19 Mar 2012 10:15:30 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id B32B021F887D for ; Mon, 19 Mar 2012 10:15:30 -0700 (PDT) Received: (qmail 12678 invoked by uid 0); 19 Mar 2012 17:15:30 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 19 Mar 2012 17:15:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Fvhhb65y3D2OMX0OWUnOzMon99nK5jo5qWboXpLr6Yg=; b=QSSpDTv9z6ZmvXJeU/ay2FQlXZTIGqiWeVyjZyOlfq7QMth4F4hkaKPZZVc0LHyHqH+fOf8yO4LFDqHcpbZdwYxrkDARLQE/ZArBmAziKp8Bq1V9yZsNpjsate8S1agx; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.56]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1S9gB5-0000cm-Re; Mon, 19 Mar 2012 11:15:27 -0600 Message-ID: <4F6769AD.8020501@KingsMountain.com> Date: Mon, 19 Mar 2012 10:15:25 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Nicholas Weaver X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: dnsext List Subject: Re: [dnsext] Capture signature chain? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org > Is there currently a standard wire/storage format for capturing the entire > DNSSEC signature chain required for validation in a single transaction? Nothing standardized as yet (AFAIK), tho there's this proposal.. Serializing DNS Records with DNSSEC Authentication https://tools.ietf.org/html/draft-agl-dane-serializechain-01 HTH, =JeffH _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 19 15:48:14 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFFF21E8051; Mon, 19 Mar 2012 15:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332197294; bh=V13uVJAmJ8DDnR2Qbw0Vxo6lFyiSAz5qEvaHWxmU4AI=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=S5JrsIMUYcSmXlVkAYMnzOnSZo+5Z4JlKi5e3OzWUIz4cVRKeip8rjx6msdsyqSDT fPQ8P/5f9QFfcxk/Xa1HhDNPmGKDGyHxV7raVWs/fosHNz6IJMFijk+3V6y0ChNqLJ S5fN/768I/gLnW9Koinv7d/614X94MP3heUkfAQY= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218DF21E8048 for ; Mon, 19 Mar 2012 15:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.657 X-Spam-Level: X-Spam-Status: No, score=-3.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naYmxmugVIcv for ; Mon, 19 Mar 2012 15:48:12 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF9D21E8034 for ; Mon, 19 Mar 2012 15:48:12 -0700 (PDT) Received: (qmail 17042 invoked by uid 399); 19 Mar 2012 22:48:07 -0000 Received: from unknown (HELO ?172.17.198.245?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 19 Mar 2012 22:48:07 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F67B7A7.1000608@dougbarton.us> Date: Mon, 19 Mar 2012 15:48:07 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ray Bellis References: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> <20120316233618.16C831E9F8E3@drugs.dv.isc.org> <8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet.org.uk> <4F653C29.2070103@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.4 Cc: Paul Hoffman , DNSEXT Working Group Subject: Re: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 3/19/2012 7:58 AM, Ray Bellis wrote: > > On 18 Mar 2012, at 01:36, Doug Barton wrote: > >> I'm not sure what you mean by "works" here. > > I mean the NAPTR records correctly resolve. > >> If you mean that anyone using ns1.example.com directly will see >> those records, then yes, it works -- for those users. But assuming >> that ns1.example.com is not included in the NS set of the parent >> zone, no one else will see the 2 NAPTR records you listed above. So >> in that sense it doesn't work ... at least, it doesn't work the way >> that the administrator of ns1.example.com wants it to. > > No, in this case "ns1.example.com" _is_ found via the parent zone, > but the delegation is four nodes further down the DNS tree than the > child's SOA / NS records would indicate. Right, and that's the devious subtlety of your message. :) No one would ever query ns1.example.com iteratively for the sample records in the zone you posted because they would have no way of knowing that ns1.example.com thought it was authoritative for those records. Clients querying it directly would get an answer (think in-house resolvers with various in-house zones slaved to it) but no one else would. Doug -- If you're never wrong, you're not trying hard enough _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 19 16:13:25 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBE521F8691; Mon, 19 Mar 2012 16:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332198805; bh=ng831N/xqOfFVgEzFPqJ7RWOZGLvfkDYu84Dii5DQns=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=lCazTLSuh4DB32ZG5J5v4icXNvKCIFZujWYQVO7Cf/c2K38GPP1y3jW2mdyQZ0lRB 6h5YefWGel5q7cz35lEywwjfQoy6vvBQo1h7erjdezf1kmncTIRTJ0BDwB3bxEsVGC kSoTCYpWGuW0IDVvHf3rxw/QI9e1GW8d94n1ddsY= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85E921F8691 for ; Mon, 19 Mar 2012 16:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xVtHfDJM6vv for ; Mon, 19 Mar 2012 16:13:24 -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 327A021F8690 for ; Mon, 19 Mar 2012 16:13:24 -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 ADF91C9422; Mon, 19 Mar 2012 23:13:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:645b:31fe:90c7:4d73]) (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 717E7216C31; Mon, 19 Mar 2012 23:13: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 2D0501EAD8EC; Tue, 20 Mar 2012 10:13:01 +1100 (EST) To: Ray Bellis From: Mark Andrews References: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> <20120316233618.16C831E9F8E3@drugs.dv.isc.org> <8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet.org.uk> In-reply-to: Your message of "Sat, 17 Mar 2012 13:31:40 -0000." <8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet.org.uk> Date: Tue, 20 Mar 2012 10:13:00 +1100 Message-Id: <20120319231301.2D0501EAD8EC@drugs.dv.isc.org> Cc: Paul Hoffman , DNSEXT Working Group Subject: Re: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In message <8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet.org.uk>, Ray Bellis wr ites: > > On 16 Mar 2012, at 23:36, Mark Andrews wrote: > > > RFC 1034 say all you need to say for zone operators about NS record. > > IMHO, there's more to it than that. > > For example, if you have this in a parent zone: > > 1.1.1.1.5.5.5.3.0.2.1.e164.arpa. IN NS ns1.example.com > > and this in the child zone: > > $ORIGIN 5.5.5.3.0.2.1.e164.arpa. > @ SOA ... > @ NS ns1.example.com > 0.0.0.0 NAPTR ... > 1.0.0.0 NAPTR ... > > it currently works - the parent zone points to the right server, but the pa= > rent and child disagree on where the zone cut is. > > However with DNSSEC that is no longer possible. There's nowhere to put the= > DS record. > > For various historic reasons, the UK public ENUM tree has per-number NS rec= > ords as shown above. To make the parent and child consistent (without chan= > ging the parent) the child server would need to have a separate zone file _= > per number_. No. It needs the data to be available. With traditional servers this has required a zone file. But even with named this could come from a single database that defines the zones and their content using DLZ. dbjdns does this with a single flat file. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Mar 20 02:31:38 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB2421F87F7; Tue, 20 Mar 2012 02:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332235898; bh=Ltj2u5A2mQixr01XDggyozAFAkFQuLqWYnT8Xk5AP8w=; h=From:To:Date:Message-ID:References:In-Reply-To:Content-ID: MIME-Version:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type: Content-Transfer-Encoding:Sender; b=RH/hz9iCyh1psNERWsfs4IMcyLCx6TNTrPMOCkqjujr1t/RCrl50xUu9YhvP8fsut 5v1A9hrVEiQILWTqkdVsvz/22mBG4X5fU39n0v4020gvnMlBxl0GdSDfewRw6mm7hA unDZ6VsecIMDibpcJRMe4gLiFkp1FV6jhYIRkSbo= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC0021F87F7 for ; Tue, 20 Mar 2012 02:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.313 X-Spam-Level: X-Spam-Status: No, score=-10.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BOOcx8bV20D for ; Tue, 20 Mar 2012 02:31:35 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9507D21F87F5 for ; Tue, 20 Mar 2012 02:31:34 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=P0e79fe4Iopx59uO8J4nA0fVVzGF+f6H3VIX+JZ02CfiDfVyQYdbePOl moYzFQDzpM60XklZBJHv474lZi5860EZJ21/IdhS9VMNqLSp63jY7kvlj 2YehVYePcYr3gol; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1332235895; x=1363771895; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[dnsext]=20Short=20introduction=20to=20 zone=20cuts?|Date:=20Tue,=2020=20Mar=202012=2009:31:29=20 +0000|Message-ID:=20<90DCCEAC-DBBF-423E-99DE-46D21D078F66 @nominet.org.uk>|To:=20Doug=20Barton=20|CC:=20DNSEXT=20Working=20Group=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20|In-Reply-To:=20<4F67B7A7.1000608@dougbarton.us> |References:=20<946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc .org>=0D=0A=20<20120316233618.16C831E9F8E3@drugs.dv.isc.o rg>=0D=0A=20<8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet .org.uk>=0D=0A=20<4F653C29.2070103@dougbarton.us>=0D=0A =20 =0D=0A=20<4F67B7A7.1000608@dougbarton.us>; bh=FGCc1Oooltuk7Iz58ZDQ+qwb8vag/V718cBL/YuF2b4=; b=WT73Jq8lZZyoRfHuZBC2vpRahFnBsGzBUyshZB+VuwIxo/yqi5qfRcP5 VQ6eaa76AuatXXB9K94XDxKVT92wY3A2fzU5xGsp+5cmGySzKQDY9U6xZ l1mkz/WaJXWkc/r; X-IronPort-AV: E=Sophos;i="4.73,617,1325462400"; d="scan'208";a="39233778" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 20 Mar 2012 09:31:31 +0000 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Tue, 20 Mar 2012 09:31:31 +0000 From: Ray Bellis To: Doug Barton Thread-Topic: [dnsext] Short introduction to zone cuts? Thread-Index: AQHNA5zsYFL40qEpS0Ktdz4KXCtF9ZZtlCQkgADpMwCAAMqSgIACck6AgACDQoCAALPCgA== Date: Tue, 20 Mar 2012 09:31:29 +0000 Message-ID: <90DCCEAC-DBBF-423E-99DE-46D21D078F66@nominet.org.uk> References: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> <20120316233618.16C831E9F8E3@drugs.dv.isc.org> <8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet.org.uk> <4F653C29.2070103@dougbarton.us> <4F67B7A7.1000608@dougbarton.us> In-Reply-To: <4F67B7A7.1000608@dougbarton.us> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: MIME-Version: 1.0 Cc: DNSEXT Working Group Subject: Re: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 19 Mar 2012, at 22:48, Doug Barton wrote: > > Right, and that's the devious subtlety of your message. :) No one would > ever query ns1.example.com iteratively for the sample records in the > zone you posted because they would have no way of knowing that > ns1.example.com thought it was authoritative for those records. Sure they would! You can try it: % dig +short @8.8.8.8 1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa. NAPTR 100 20 "u" "E2U+pstn:tel" "!^(.*)$!tel:\\1!" . 100 10 "u" "E2U+sip" "!^\\+441865332(.*)$!sip:\\1@nominet.org.uk!" . > Clients querying it directly would get an answer (think in-house > resolvers with various in-house zones slaved to it) but no one else would. Yes, they would. The recursive server without an entry in cache ends up at the NS for 4.4.e164.arpa, at which point we send a referral _for the whole domain name_ pointing at ns1.example.com. The query arrives there, and is duly answered. Sans DNSSEC, the mismatch in the zone cut between parent and child is never noticed. Ray _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Mar 20 04:45:09 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC83D21F8664; Tue, 20 Mar 2012 04:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332243908; bh=A14OxisVnZzb/2vPANge3K93bJQLrfSg13p4kTL2hEY=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=g+d6DgGCmiT+847seUkESQrbZiki53knDUqm6ZZSTI4x9O32czojDWb9KcSILLAMb 5F7CulT46DAlNrEKWKifvY0je+xJ8L3OSjApNe+GmfBoJXbQXNIfDOnuSPMFF7NGcb bDbUvI/PXeeAUo8ZgkBfJj/3J16oSTYFiPYqXa88= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98A721F865F for ; Tue, 20 Mar 2012 04:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3O-7iRqi+Do for ; Tue, 20 Mar 2012 04:45:05 -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 B0D9E21F8659 for ; Tue, 20 Mar 2012 04:45:04 -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-2.csi.cam.ac.uk ([131.111.8.54]:54575) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1S9xUs-0007fH-qe (Exim 4.72) (return-path ); Tue, 20 Mar 2012 11:45:02 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S9xUs-0000rZ-92 (Exim 4.67) (return-path ); Tue, 20 Mar 2012 11:45:02 +0000 Date: Tue, 20 Mar 2012 11:45:02 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ray Bellis In-Reply-To: <90DCCEAC-DBBF-423E-99DE-46D21D078F66@nominet.org.uk> Message-ID: References: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> <20120316233618.16C831E9F8E3@drugs.dv.isc.org> <8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet.org.uk> <4F653C29.2070103@dougbarton.us> <4F67B7A7.1000608@dougbarton.us> <90DCCEAC-DBBF-423E-99DE-46D21D078F66@nominet.org.uk> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Cc: DNSEXT Working Group Subject: Re: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Ray Bellis wrote: > > You can try it: > > % dig +short @8.8.8.8 1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa. NAPTR > 100 20 "u" "E2U+pstn:tel" "!^(.*)$!tel:\\1!" . > 100 10 "u" "E2U+sip" "!^\\+441865332(.*)$!sip:\\1@nominet.org.uk!" . However BIND gets upset by negative responses (noerror/nodata) because the authority section of replies is wrong. $ dig a 1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa. ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42870 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 $ dig a 1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa. @nom-ns1.nominet.org.uk. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7348 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 20-Mar-2012 11:33:57.577 resolver: notice: DNS format error from 2a01:40:1001:37::2#53 resolving 1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa/A for client 127.0.0.1#53299: invalid response 20-Mar-2012 11:33:57.577 lame-servers: info: error (FORMERR) resolving '1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa/A/IN': 2a01:40:1001:37::2#53 Tony. -- f.anthony.n.finch http://dotat.at/ East Sole, Lundy, Fastnet, Irish Sea: Southwesterly 4 or 5, occasionally 6 in Irish Sea. Slight or moderate, occasionally rough in Fastnet. Mainly fair. Good. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Mar 20 22:48:52 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EB021F84D7; Tue, 20 Mar 2012 22:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332308932; bh=svsnDg7Iu/sw5UBOt7V7EuaFsMS07L8crTiE8S5K2JE=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=KHx0TzJc0XoPOBwzqgETN25MSid/u9Zd2+yls9hqjnbm7v1GIt5aym72EBLvueUy6 SC603Fgn3hIQfCFKW1R0RhRwRb8kxC0K1vew+IBha22pmk3KDphPOqHCOCVI0lCROE 7blUdKsPpnq0hfobbq2Nu1zMw7XE+tfpt4holPKs= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB7F21F84D3 for ; Tue, 20 Mar 2012 22:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.655 X-Spam-Level: X-Spam-Status: No, score=-3.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNKN947vhDFs for ; Tue, 20 Mar 2012 22:48:51 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 56BE521F84D7 for ; Tue, 20 Mar 2012 22:48:50 -0700 (PDT) Received: (qmail 6166 invoked by uid 399); 21 Mar 2012 05:48:49 -0000 Received: from unknown (HELO ?172.17.198.245?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 21 Mar 2012 05:48:49 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F696BBE.8010209@dougbarton.us> Date: Tue, 20 Mar 2012 22:48:46 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ray Bellis References: <946E9EC4-9872-4A98-BCEB-3CD7420929A1@vpnc.org> <20120316233618.16C831E9F8E3@drugs.dv.isc.org> <8D53F412-A917-4DB2-9B7F-527B8FDD6779@nominet.org.uk> <4F653C29.2070103@dougbarton.us> <4F67B7A7.1000608@dougbarton.us> <90DCCEAC-DBBF-423E-99DE-46D21D078F66@nominet.org.uk> In-Reply-To: <90DCCEAC-DBBF-423E-99DE-46D21D078F66@nominet.org.uk> X-Enigmail-Version: 1.4 Cc: DNSEXT Working Group Subject: Re: [dnsext] Short introduction to zone cuts? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 3/20/2012 2:31 AM, Ray Bellis wrote: > > On 19 Mar 2012, at 22:48, Doug Barton wrote: > >> >> Right, and that's the devious subtlety of your message. :) No one would >> ever query ns1.example.com iteratively for the sample records in the >> zone you posted because they would have no way of knowing that >> ns1.example.com thought it was authoritative for those records. > > Sure they would! In your original post you posited something like this, if I understood you correctly: Parent: $ORIGIN 4.3.2.1.foo. 8.7.6.5 NS ns1.example.com. ns1.example.com (child): $ORIGIN 4.3.2.1.foo. 0.0.0.0 A blah.example.com. 1.1.1.1 A baz.example.com. Under that scenario clients in the cloud would never query ns1.example.com for 0.0.0.0.4.3.2.1.foo or 1.1.1.1.4.3.2.1.foo because they'd have no delegation to it. If I misunderstood, sorry for the noise. Doug -- If you're never wrong, you're not trying hard enough _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 23 08:42:16 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB1021F8568; Fri, 23 Mar 2012 08:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332517336; bh=aEAO67e7TNNfzaRxDGZXB3GAPZEfbeBfl47IekrHPYU=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=xutjPcCL+0/+1fsSZQ3AIg6BOzieq9qxSKAzL9QR8Ka9CMhLp0YP3zMR+E4mR+Jux O0nqPERY068AR3Kcv4f1AidlVh8WNLeycJej7W58V08CQqa33MALQU/8H3fnQtgFww Y8wAL6nxZIjLahk8PKuCRxONPkAWi/HtiPZ76AK8= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954D921F8568 for ; Fri, 23 Mar 2012 08:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ1eTrlRZabj for ; Fri, 23 Mar 2012 08:42:10 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 200CD21F8557 for ; Fri, 23 Mar 2012 08:42:10 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2NFg8Wl037363 for ; Fri, 23 Mar 2012 11:42:08 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4F6C99CB.7080806@ogud.com> Date: Fri, 23 Mar 2012 11:42:03 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: [dnsext] Validator assumptions: what algorithms need to properly sign a zone? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Following configuration was detected in the wild recently: Notation: A is algorithm x B is algorithm y An is key n of algorithm A Parent: DS 1 A1 DS 2 A1 Child: DNSKEY A1,B1 signed by A1 and B1 SOA signed by A1 and B1 all other records signed by A2 and B1 Notice that A2 signs records w/o being in the DNSKEY RRset. Some validators returned AD others return SERVFAIL for the RRsets signed by A2 + B1. The validators that return AD make the jump from algorithm A to B when validating the zone, the ones that SERVFAIL expect that the zone be properly signed by algorithm A (which it is not). Both positions are arguable, but it is bad for resolver vendors to be put in this position to argue with customers why they disagree on the right answer, and DNSSEC operators need a strong message what is allowed. In the case of a validator that supports A but not B SERVFAIL is the right answer as the zone is not properly signed for that algorithm. In this particular case the validators supported both algorithms. Background: The zone seems to be in compliance with the list in RFC4035 section 2.2 i.e. there exists a valid signature by a key in the DNSKEY RRset. But in the final paragraph that seems to be contradicted and does require the a signing key for all algorithms to be in the DNSKEY RRset. Section 5.4 of dnssec-bis seems skirts on this issue. Section 5.11 of dnssec-bis seems to strongly say that any algorithm in the DNSKEY should work: without saying what to do if not all the algorithms are supported or that at least one algorithm in the DS MUST work. Some people in this working group have argued that use/order of algorithms should be local policy and it is outside the documents scope to talk about this, others argue that will lead to unpredictability in resolution status. Fundamental question: What algorithms can a validator use to validate records from a zone 1) only algorithms in DS RRset 2) any algorithm in the validated DNSKEY RRset Doodle poll available at: http://www.doodle.com/7v5vmzvaerb2n8sb Please fill in the poll, chairs will judge if any changes are needed in DNSSECbis. Olafur _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 23 11:13:24 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F109B21F866A; Fri, 23 Mar 2012 11:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332526404; bh=ConbulncfeRmRNiRS3aq8UiAqyB3o9fBUpDGRqPa+AU=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=ORhECFcUvfXsyvVMzER2uAhCOC/l+KkC+z9ITmKGs/wS/TQfOSHdaeTAW3QdeTjDj PSoF9oqCYyImJmh73pDNo0za0b++dZndLmKZMU/3mtBsJWoOOSW7MkUYXBiw2ElsTu xPD3lHVnGYh9zJkxJBwFWmugl1VXC4rkBwxIHWIo= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8443021F866A for ; Fri, 23 Mar 2012 11:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihGxEy-8bjKg for ; Fri, 23 Mar 2012 11:13:18 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B621F864F for ; Fri, 23 Mar 2012 11:13:18 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2NIDGL0059241; Fri, 23 Mar 2012 14:13:16 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2NIDGkI059237; Fri, 23 Mar 2012 14:13:16 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 23 Mar 2012 14:13:16 -0400 (EDT) From: Samuel Weiler To: Olafur Gudmundsson In-Reply-To: <4F6C99CB.7080806@ogud.com> Message-ID: References: <4F6C99CB.7080806@ogud.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 23 Mar 2012 14:13:16 -0400 (EDT) Cc: "" Subject: Re: [dnsext] Validator assumptions: what algorithms need to properly sign a zone? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Reordering Olafur's message. On Fri, 23 Mar 2012, Olafur Gudmundsson wrote: > Fundamental question: > What algorithms can a validator use to validate records from a zone > 1) only algorithms in DS RRset > 2) any algorithm in the validated DNSKEY RRset I'm not sure how you got to that as the final question, but it's an easy one to answer: #2. We decided to have algorithm signalling happening in BOTH the DS RRset and the DNSKEY RRset. The DNSKEY RRset can add algorithms but not remove them. It sounds like what you're trying to ask, though, is "MUST a resolver try all algorithms, even to the point of jumping between algorithms?". bis-updates 5.4 says SHOULD, not MUST, without explictly saying anything about jumping between algorithms. There is going to be unpredictability in this case. Some resolvers won't support B, whether through implementation choice or configuration choice (B might be weak, hence turned off). And it's probably sane, though certainly not necessary, for a validator to impose a no-alogrithm-jumping rule. Hence limiting 5.4 to a SHOULD, not a MUST. > Doodle poll available at: > http://www.doodle.com/7v5vmzvaerb2n8sb A Doodle poll seems like a poor tool for something such as this. > Section 5.11 of dnssec-bis seems to strongly say that any algorithm in the > DNSKEY should work: > without saying what to do if not all the algorithms are supported > or that at least one algorithm in the DS MUST work. Both this and 4035 section 2.2 may not explicitly say "and the chain of trust has to work within each algorithm". Is that not said or implied elsewhere? Are these sections really so ambiguous that we need to clarify them? Please re-read bis-updates 5.11 and ponder. -- Sam _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 23 11:17:43 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A70C21F866D; Fri, 23 Mar 2012 11:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332526663; bh=RDTfbgqpvsYGNYlPEbnTwwoZ1RSLk3cZz0cxLt9kG6o=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=fO6LXQaxKMl70AbQd/z6lg2+sCm1ban7+lai/ZfD/zxJEcK+EjJAf2Ae+wu0rv68t V9xR4d3908H7xDbi38NYdoXtEaMZfVPOYrGF38RaK9sJUyghwOZ9GHy1VnKJ76dpmF p0V7zXfTLvFmq8MZjPG+5muJZjkDRGewq2RECaxI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BFF21F8671 for ; Fri, 23 Mar 2012 11:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGquPIYq5SCa for ; Fri, 23 Mar 2012 11:17:40 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id B409F21F866E for ; Fri, 23 Mar 2012 11:17:40 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2NIHeIr061645; Fri, 23 Mar 2012 14:17:40 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2NIHdI8061640; Fri, 23 Mar 2012 14:17:39 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 23 Mar 2012 14:17:39 -0400 (EDT) From: Samuel Weiler To: Olafur Gudmundsson In-Reply-To: Message-ID: References: <4F6C99CB.7080806@ogud.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 23 Mar 2012 14:17:40 -0400 (EDT) Cc: "" Subject: Re: [dnsext] Validator assumptions: what algorithms need to properly sign a zone? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Fri, 23 Mar 2012, Samuel Weiler wrote: > There is going to be unpredictability in this case. Some resolvers won't > support B, whether through implementation choice or configuration choice (B > might be weak, hence turned off). And it's probably sane, though certainly > not necessary, for a validator to impose a no-alogrithm-jumping rule. Hence > limiting 5.4 to a SHOULD, not a MUST. And I should clarify: there is going to be unpredictability because the zone is not properly signed. The chain of trust in alg A is broken. -- Sam _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 23 11:23:58 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F4A21F8501; Fri, 23 Mar 2012 11:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332527038; bh=kgE1zo96aimnqcv+GQein0+2ecigR8J/Prp19pjkLhg=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=LUNvtXJN55LL2WtdgwRCj/uT/NZV6E2yBrPG8ZiN1JfuFvKJu3ODX7zg4eAgNhRt9 2EUOsItqvbC5rwbMEZfUfW0DKKynWwSVj8Yuo7uk+ICumiWMM3E+b7Avfr/ylGMYaH xZQAac6xM9su2hcS2CUQfmYJ3WRlKElESrUnoEaI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44EB21F84E1 for ; Fri, 23 Mar 2012 11:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm+GPfaqsjCn for ; Fri, 23 Mar 2012 11:23:51 -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 80EE621F84F2 for ; Fri, 23 Mar 2012 11:23: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-2.csi.cam.ac.uk ([131.111.8.54]:53212) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1SB99R-0004Cj-rj (Exim 4.72) (return-path ); Fri, 23 Mar 2012 18:23:49 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SB99R-0002G1-It (Exim 4.67) (return-path ); Fri, 23 Mar 2012 18:23:49 +0000 Date: Fri, 23 Mar 2012 18:23:49 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Olafur Gudmundsson In-Reply-To: <4F6C99CB.7080806@ogud.com> Message-ID: References: <4F6C99CB.7080806@ogud.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Cc: "" Subject: Re: [dnsext] Validator assumptions: what algorithms need to properly sign a zone? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Olafur Gudmundsson wrote: > > The zone seems to be in compliance with the list in RFC4035 section 2.2 i.e. > there exists a valid signature by a key in the DNSKEY RRset. > But in the final paragraph that seems to be contradicted and does > require the a signing key for all algorithms to be in the DNSKEY RRset. I believe the consensus is that that requirement applies to the signer not the validator. > What algorithms can a validator use to validate records from a zone > 2) any algorithm in the validated DNSKEY RRset Tony. -- f.anthony.n.finch http://dotat.at/ Portland: Mainly easterly 3 or 4, occasionally 5 later. Smooth or slight, occasionally moderate later. Fog patches. Good, occasionally very poor. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Mar 23 13:59:01 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2542F21F844D; Fri, 23 Mar 2012 13:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332536341; bh=pt89ijRj1DI0cD48//aPVFNmmSSRFPWElIAk88OmWVo=; h=From:Message-Id:To:Date:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ZqKZQqz3bLscyBU0bzti7EBEGCfAmydeH3cJtDaZ537U3QsW4+4KT3QBILsMc7ZvC vheiGcoZEvsgs+PcdEPyWfpamawdh3fqybi3qoqZ/aMG9L3d4pn0vKaenDvo/QIRhl 56JtKPfAUcsFdHwu6g2ApappZjRm3tGf6X7aJIhQ= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9483C21F844D; Fri, 23 Mar 2012 13:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.6 X-Spam-Level: X-Spam-Status: No, score=-98.6 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWHXp5HhD6Ah; Fri, 23 Mar 2012 13:59:00 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 85DF121F8444; Fri, 23 Mar 2012 13:58:58 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA246666270; Fri, 23 Mar 2012 21:57:50 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA08984; Fri, 23 Mar 2012 21:57:48 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203232057.VAA08984@TR-Sys.de> To: joao@isc.org, mgraff@isc.org, vixie@isc.org Date: Fri, 23 Mar 2012 21:57:48 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: ietf@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Last Call: ... to Full 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: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org SSBoYXZlIHJldmlld2VkIGRyYWZ0LWlldGYtZG5zZXh0LXJmYzI2NzFiaXMtZWRuczAtMDgKYW5k IHdvdWxkIGxpa2UgdG8gc3VibWl0IGEgZmV3IExDIGNvbW1lbnRzLgoKU3VtbWFyeToKPT09PT09 PQoKVGhlIGRyYWZ0IGlzIGFsbW9zdCByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgYQooRnVsbCkg SW50ZXJuZXQgU3RhbmRhcmQgUkZDLgoKKE5vdGU6IFNob3VsZG4ndCB0aGUgTGFzdCBDYWxsIHRl bXBsYXRlIG5vdyBiZSBhbGlnbmVkIHdpdGggdGhlClJGQyA2NDEwIG1hdHVyaXR5IGxldmVsIGRl c2lnbmF0aW9ucyBhbmQgdXNlICJJbnRlcm5ldCBTdGFuZGFyZCIKaW4gcGxhY2Ugb2YgIkZ1bGwg U3RhbmRhcmQiIC0tIGJvdGggaW4gdGhlIGhlYWRsaW5lIGFuZCBpbiB0aGUgYm9keT8pCgpUaGUg dGVjaG5pY2FsIGNvbnRlbnQgaXMgc291bmQgYW5kIHN0YWJsZSBhbmQgc3VwcG9ydGVkIGJ5IGNv bnNlbnN1cwppbiB0aGUgRE5TIGNvbW11bml0eSwgaW5jbHVkaW5nIGFsbCBtYWpvciBETlMgaW1w bGVtZW50ZXJzOyBpdCBpcyBhbHNvCndlbGwgYWxpZ25lZCB3aXRoIG90aGVyIHJlY2VudCBkb2N1 bWVudHMgLyBkb2N1bWVudHMgaW4gdGhlIHBpcGVsaW5lLgpBRkFJQ1QsIHRoZSBkb2N1bWVudCBm dWxmaWxscyB0aGUgY3JpdGVyaWEgcG9zZWQgaW4gU2VjdGlvbiAyLjIgb2YKUkZDIDY0MTAgZm9y ICJJbnRlcm5ldCBTdGFuZGFyZCIuCgpJIG9ubHkgZm91bmQgYSBmZXcgbWlub3IgdGV4dHVhbCBp c3N1ZXMgKHNlZSBiZWxvdykgYW5kIGEgY291cGxlIG9mCmVkaXRvcmlhbCBuaXRzIChiZWluZyBj b21tdW5pY2F0ZWQgdG8gYSBzbWFsbGVyIGRpc3RyaWJ1dGlvbiBsaXN0KQp0aGF0IGFsbCBjb3Vs ZCBiZSBlYXNpbHkgYWRkcmVzc2VkIGR1cmluZyBmaW5hbCBwcm9jZXNzaW5nIHN0YWdlcy4KCgpN aW5vciB0ZXh0dWFsIGlzc3VlczoKPT09PT09PT09PT09PT09PT09PT0KCmEpICBTZWN0aW9uIDMs IGxhc3QgbGluZQoKSSBzdXNwZWN0IHRoYXQgIi4uLiBnZW5lcmFsaXplZCB1c2Ugb2YgVENQIGZv ciBETlMgdHJhbnNwb3J0LiIKaXMgbm90IHdoYXQgdGhlIGF1dGhvcnMgaGFkIGluIG1pbmQsIGl0 IGxpa2VseSBzaG91bGQgYmUKIi4uLiBnZW5lcmFsIHVzZSBvZiBUQ1AgZm9yIEROUyB0cmFuc3Bv cnQuIgoKKG9yIHMvZ2VuZXJhbC9tb3JlIGZyZXF1ZW50LykKCgpiKSAgU2VjdGlvbiA2LjEuMiAt LSBwcm9jZWR1cmFsIGNsYXJpZmljYXRpb24KCkkgc3VnZ2VzdCB0byBzbGlnaHRseSBhbWVuZCB0 aGUgdmVyeSBsYXN0IHNlbnRlbmNlIG9mIHM2LjEuMiA6CgpPTEQ6CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbLi4uXS4gIEZvciBleGFtcGxlLCBhbgogICBvcHRp b24gc3BlY2lmaWNhdGlvbiBtaWdodCBzYXkgdGhhdCBpZiBhIHJlc3BvbmRlciBzZWVzIG9wdGlv biBYWVosCiAgIGl0IE1VU1QgaW5jbHVkZSBvcHRpb24gWFlaIGluIGl0cyByZXNwb25zZS4KCk5F VzoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsuLi5dLiAgRm9y IGV4YW1wbGUsIGFuCiAgIG9wdGlvbiBzcGVjaWZpY2F0aW9uIG1pZ2h0IHNheSB0aGF0IGlmIGEg cmVzcG9uZGVyIHNlZXMgYW5kCiAgIHVuZGVyc3RhbmRzIG9wdGlvbiBYWVosIGl0IE1VU1QgaW5j bHVkZSBvcHRpb24gWFlaIGluIGl0cyByZXNwb25zZS4KCihvciBhZGQgImFuZCBzdXBwb3J0cyIg aW4gcGxhY2Ugb2YgImFuZCB1bmRlcnN0YW5kcyIpCgoKYykgIFNlY3Rpb24gNi4yLjIgLS0gdGVy bWlub2xvZ2ljYWwgY2xhcmlmaWNhdGlvbgoKU2luY2UgRUROUyBpcyAtLSBhdCBsZWFzdCBpbiBw cmluY2lwbGUgLS0gZGVzaWduZWQgdG8gYmUgYSB2ZXJzaW9uZWQKZmFtaWx5IG9mIEROUyBwcm90 b2NvbCBleHRlbnNpb25zIGJhc2VkIG9uIHRoZSBPUFQgUlIsIGFuZCBzdWNoCnZlcnNpb25zIGFy ZSBleHBlY3RlZCB0byBiZSB1cHdhcmQgY29tcGF0aWJsZSwgdGhlIHNlY29uZCBtZW50aW9uCm9m ICJFTkRTMCIgaW4gdGhhdCBwYXJhZ3JhcGggc2hvdWxkIGJldHRlciBzYXkgIkVETlMiICh3aXRo b3V0IHRoZQp2ZXJzaW9uICcwJywgc2VlIGJlbG93KSBvciAobGVzcyBwcmVmZXJhYmx5KSAiRURO UygwKSIuCgpPTEQ6CiAgIElmIGEgcmVxdWVzdG9yIGRldGVjdHMgdGhhdCB0aGUgcmVtb3RlIGVu ZCBkb2VzIG5vdCBzdXBwb3J0IEVETlMwLCBpdAogICBNQVkgaXNzdWUgcXVlcmllcyB3aXRob3V0 IGFuIE9QVCByZWNvcmQuICBJdCBNQVkgY2FjaGUgdGhpcyBrbm93bGVkZ2UKICAgZm9yIGEgYnJp ZWYgdGltZSBpbiBvcmRlciB0byBhdm9pZCBmYWxsYmFjayBkZWxheXMgaW4gdGhlIGZ1dHVyZS4K ICAgSG93ZXZlciwgaWYgRE5TU0VDIG9yIGFueSBmdXR1cmUgb3B0aW9uIHVzaW5nIEVETlMgaXMg cmVxdWlyZWQsIG5vCnwgIGZhbGxiYWNrIHNob3VsZCBiZSBwZXJmb3JtZWQgYXMgdGhleSBhcmUg b25seSBzaWduYWxlZCB0aHJvdWdoIEVETlMwLgogICBJZiBhbiBpbXBsZW1lbnRhdGlvbiBkZXRl Y3RzIHRoYXQgc29tZSBzZXJ2ZXJzIGZvciB0aGUgem9uZSBzdXBwb3J0CiAgIEVETlMoMCkgd2hp bGUgb3RoZXJzIHdvdWxkIGZvcmNlIHRoZSB1c2Ugb2YgVENQIHRvIGZldGNoIGFsbCBkYXRhLAog ICBwcmVmZXJlbmNlIFNIT1VMRCBiZSBnaXZlbiB0byB0aG9zZSBzdXBwb3J0IEVETlMoMCkuCgpO RVc6CiAgIElmIGEgcmVxdWVzdG9yIGRldGVjdHMgdGhhdCB0aGUgcmVtb3RlIGVuZCBkb2VzIG5v dCBzdXBwb3J0IEVETlMwLCBpdAogICBNQVkgaXNzdWUgcXVlcmllcyB3aXRob3V0IGFuIE9QVCBy ZWNvcmQuICBJdCBNQVkgY2FjaGUgdGhpcyBrbm93bGVkZ2UKICAgZm9yIGEgYnJpZWYgdGltZSBp biBvcmRlciB0byBhdm9pZCBmYWxsYmFjayBkZWxheXMgaW4gdGhlIGZ1dHVyZS4KICAgSG93ZXZl ciwgaWYgRE5TU0VDIG9yIGFueSBmdXR1cmUgb3B0aW9uIHVzaW5nIEVETlMgaXMgcmVxdWlyZWQs IG5vCnwgIGZhbGxiYWNrIHNob3VsZCBiZSBwZXJmb3JtZWQgYXMgdGhleSBhcmUgb25seSBzaWdu YWxlZCB0aHJvdWdoIEVETlMuCiAgIElmIGFuIGltcGxlbWVudGF0aW9uIGRldGVjdHMgdGhhdCBz b21lIHNlcnZlcnMgZm9yIHRoZSB6b25lIHN1cHBvcnQKICAgRUROUygwKSB3aGlsZSBvdGhlcnMg d291bGQgZm9yY2UgdGhlIHVzZSBvZiBUQ1AgdG8gZmV0Y2ggYWxsIGRhdGEsCiAgIHByZWZlcmVu Y2UgU0hPVUxEIGJlIGdpdmVuIHRvIHRob3NlIHN1cHBvcnQgRUROUygwKS4KCgpkKSAgU2VjdGlv biA3IC0tIHRlcm1pbm9sb2d5IGFuZCBhZGRpdGlvbmFsIFJlZmVyZW5jZQoKSSBzdWdnZXN0IHRv IGNhcGl0YWxpemUgdGhlIFJGQyA1MjI2IHRlcm0gdXNlZCBoZXJlIGFuZCBhZGQgYSByZWYuIHRv ClJGQyA1MjI2LgpGdXJ0aGVyIGluIHRlcm1pbm9sb2d5OiB3aXRoIHJlZ2FyZCB0byBJQU5BLCAi YWxsb2NhdGlvbiIgdXN1YWxseQppbmRpY2F0ZXMgaGFuZGluZyBvdXQgYSBibG9jayBvZiBjb2Rl cG9pbnRzIC0tIGZvciBpbnN0YW5jZSBmb3IKYXNzaWdtZW50IG9mIGNvZGUgcG9pbnRzIGNvbnRh aW5lZCB3aXRoaW4gdGhhdCBibG9jayB0byBzcGVjaWZpYwpwdXJwb3NlcyBieSB0aGUgZW50aXR5 IHRoYXQgc2Vla3MgdGhlIGFsbG9jYXRpb24gKGUuZy46IElQIGFkZHJlc3NlcykKLS0gd2hlcmVh cyAiYXNzaWdubWVudCIgcmVmZXJzIHRvIHRoZSBhc3NpZ25tZW50IG9mIHNwZWNpZmljIGNvZGUK cG9pbnRzOyB0aGVyZm9yZSwgSSBzdWdnZXN0IHRvIHN3aXRjaCB0aGUgdGVybXMgdXNlZC4KCk9M RDoKCiA3LiAgT1BUIE9wdGlvbiBDb2RlIEFsbG9jYXRpb24gUHJvY2VkdXJlCgogICBBbGxvY2F0 aW9ucyBhcmUgYXNzaWduZWQgYnkgZXhwZXJ0IHJldmlldy4KCiAgIEFzc2lnbm1lbnQgb2YgT3B0 aW9uIENvZGVzIHNob3VsZCBiZSBsaWJlcmFsLCBidXQgZHVwbGljYXRlCiAgIGZ1bmN0aW9uYWxp dHkgaXMgdG8gYmUgYXZvaWRlZC4KCk5FVzoKCnw3LiAgT1BUIE9wdGlvbiBDb2RlIEFzc2lnbm1l bnQgUHJvY2VkdXJlCgp8ICBPUFQgT3B0aW9uIENvZGVzIGFyZSBhc3NpZ25lZCBieSBFeHBlcnQg UmV2aWV3IFtSRkM1MjI2XS4KCiAgIEFzc2lnbm1lbnQgb2YgT3B0aW9uIENvZGVzIHNob3VsZCBi ZSBsaWJlcmFsLCBidXQgZHVwbGljYXRlCiAgIGZ1bmN0aW9uYWxpdHkgaXMgdG8gYmUgYXZvaWRl ZC4KCgplKSAgU2VjdGlvbiAxMCAoSUFOQSBDb25zaWRlcmF0aW9ucykKCkJlY2F1c2UgdGhlIHR3 byBzZW50ZW5jZXMgY29udGFpbmVkIGluIGl0IGFyZSByZWxhdGVkIHRvIHR3byBkaWZmZXJlbnQK bmFtZXNwYWNlcyBtYW5hZ2VkIGJ5IElBTkEsIGZvciB1bmlmb3JtaXR5IG9mIHRoZSBwcmVzZW50 YXRpb24gaW4gdGhpcwpzZWN0aW9uLCBJIHN1Z2dlc3QgdG8gc3BsaXQgdGhlIGxhc3QgcGFyYWdy YXBoIG9mIHRoYXQgc2VjdGlvbiBpbnRvCnR3bzoKCk9MRDoKCiAgIElFVEYgU3RhbmRhcmRzIEFj dGlvbiBpcyByZXF1aXJlZCB0byBjcmVhdGUgbmV3IGVudHJpZXMgaW4gdGhlIEVETlMKICAgVmVy c2lvbiBOdW1iZXIgcmVnaXN0cnkuICBFeHBlcnQgUmV2aWV3IGlzIHJlcXVpcmVkIGZvciBhbGxv Y2F0aW9uIG9mCiAgIGFuIEVETlMgT3B0aW9uIENvZGUuCgpORVc6CgogICBJRVRGIFN0YW5kYXJk cyBBY3Rpb24gaXMgcmVxdWlyZWQgdG8gY3JlYXRlIG5ldyBlbnRyaWVzIGluIHRoZSBFRE5TCnwg IFZlcnNpb24gTnVtYmVyIHJlZ2lzdHJ5Lgp8CiAgIEV4cGVydCBSZXZpZXcgaXMgcmVxdWlyZWQg Zm9yIGFsbG9jYXRpb24gb2YgYW4gRUROUyBPcHRpb24gQ29kZS4KCgoKS2luZCByZWdhcmRzLAog IEFsZnJlZCBIzm5lcy4KCi0tIAoKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKfCBUUi1TeXMgQWxmcmVkIEhvZW5l cyAgIHwgIEFsZnJlZCBIb2VuZXMgICBEaXBsLi1NYXRoLiwgRGlwbC4tUGh5cy4gIHwKfCBHZXJs aW5nZXIgU3RyYXNzZSAxMiAgIHwgIFBob25lOiAoKzQ5KTcxNTYvOTYzNS0wLCBGYXg6IC0xOCAg ICAgICAgIHwKfCBELTcxMjU0ICBEaXR6aW5nZW4gICAgIHwgIEUtTWFpbDogIGFoQFRSLVN5cy5k ZSAgICAgICAgICAgICAgICAgICAgIHwKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRuc2V4dCBtYWlsaW5nIGxpc3QKZG5zZXh0 QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0Cg== From dnsext-bounces@ietf.org Fri Mar 23 14:00:44 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47CB21E804E; Fri, 23 Mar 2012 14:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332536444; bh=CK/og2JjnzjLBZvhuFzg6cEa+aoGxnWETWnpt+RrFH4=; h=From:Message-Id:To:Date:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=dZm1BFkVr/ZqmNqbzTnWR2lVBXj2RdeXz0tqurz4agRmDV09N16OsSZ98hMCrQSjL Lx03iuzGe/APShiXGQTWyK1TPoDeIxU1Js7UcdSTh7ZEjXri0iIoVIlMcut7u6UwYi 0MZM6p/IXHpJ/NkXmUUNnWOw3F15C2JJJ7fbS9Ys= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B467221E804E for ; Fri, 23 Mar 2012 14:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.605 X-Spam-Level: X-Spam-Status: No, score=-98.605 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B4u-e1SnDWh for ; Fri, 23 Mar 2012 14:00:42 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8089F21F8577 for ; Fri, 23 Mar 2012 14:00:34 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA246726366; Fri, 23 Mar 2012 21:59:26 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA09002; Fri, 23 Mar 2012 21:59:25 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203232059.VAA09002@TR-Sys.de> To: joao@isc.org, mgraff@isc.org, vixie@isc.org Date: Fri, 23 Mar 2012 21:59:25 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: ... part 2: Editorials X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org CkFzIG1lbnRpb25lZCBpbiB0aGUgZmlyc3QgcGFydCBvZiBteSBJRVRGIExDIHJldmlldyBvZgpk cmFmdC1pZXRmLWRuc2V4dC1yZmMyNjcxYmlzLWVkbnMwLTA4ICBhbHNvIHNlbnQgdG8gdGhlIElF VEYKbWFpbiBsaXN0LCBJIGFsc28gZm91bmQgYSBjb3VwbGUgb2YgZWRpdG9yaWFscyB0aGF0IHNo b3VsZCBiZQphZGRyZXNzZWQgYmVmb3JlIHB1YmxpY2F0aW9uIC0tIG1heWJlIGF0IHRoZSBSRkMg RWRpdG9yLgoKRWRpdG9yaWFscwo9PT09PT09PT09CgpBKSBSZWN1cnJpbmcgZGV0YWlscywgZ3Jv dXBlZCBieSB0b3BpYzoKCjEpICB1c2FnZSBvZiBhcnRpY2xlIHdpdGggIkROUyIKCklmIHVzZWQg YXMgYSBub3VuLCAiRE5TIiBzaG91bGQgYmV0dGVyIGJlIGFjY29tcGFuaWVkIGJ5IGFuIGFydGlj bGUuCkluIHBhcnRpY3VsYXI6CgotIGluIFNlY3Rpb24gMSwgMm5kIHBhcmE6Cgp8ICBbUkZDMjY3 MV0gYWRkZWQgYW4gZXh0ZW5zaW9uIG1lY2hhbmlzbSB0byBETlMuICBbLi4uXQotLS0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZ2dnZ2CnwgIFtSRkMyNjcxXSBhZGRl ZCBhbiBleHRlbnNpb24gbWVjaGFuaXNtIHRvIHRoZSBETlMuICBbLi4uXQoKLSBpbiBTZWN0aW9u IDMsIDFzdCBwYXJhOgoKfCAgRUROUyBwcm92aWRlcyBhIG1lY2hhbmlzbSB0byBpbXByb3ZlIHRo ZSBzY2FsYWJpbGl0eSBvZiBETlMgYXMgaXRzCiAgIHVzZXMgZ2V0IG1vcmUgZGl2ZXJzZSBvbiB0 aGUgSW50ZXJuZXQuICBbLi4uXQotLS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdnZ2dnYKfCAgRUROUyBwcm92aWRlcyBhIG1lY2hhbmlzbSB0 byBpbXByb3ZlIHRoZSBzY2FsYWJpbGl0eSBvZiB0aGUgRE5TIGFzCiAgIGl0cyB1c2VzIGdldCBt b3JlIGRpdmVyc2Ugb24gdGhlIEludGVybmV0LiAgWy4uLl0KCi0gaW4gU2VjdGlvbiAzLCAybmQg cGFyYToKCnwgIFdpdGggdGltZSwgc29tZSBhcHBsaWNhdGlvbnMgb2YgRE5TIGhhdmUgbWFkZSBF RE5TIGEgcmVxdWlyZW1lbnQgZm9yCiAgIHRoZWlyIGRlcGxveW1lbnQuICBbLi4uXQotLS0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdnZ2dnYKfCAgV2l0aCB0aW1lLCBzb21lIGFwcGxp Y2F0aW9ucyBvZiB0aGUgRE5TIGhhdmUgbWFkZSBFRE5TIGEgcmVxdWlyZW1lbnQKICAgZm9yIHRo ZWlyIGRlcGxveW1lbnQuICBbLi4uXQoKCjIpICBwcmVjaXNlIHVzYWdlIG9mICJ0aGF0IiB2cy4g IndoaWNoIgoKQWNjb3JkaW5nIHRvIHRoZSBSRkMgRWRpdG9yIGV4cGxhbmF0aW9ucywgaW4gdGhl IGZvbGxvd2luZyBpbnN0YW5jZXMKSSBmb3VuZCB0aGUgIndoaWNoIiB1c2VkIGluIHRoZSBkcmFm dCBuZWVkcyB0byBiZSByZXBsYWNlZCBieSAidGhhdCI6CgotIFNlY3Rpb24gMiwgMXN0IHBhcmE6 ICAgIm90aGVyIEROUyBjb21wb25lbnQgdGhhdCByZXNwb25kcyAuLi4iCgotIFNlY3Rpb24gNi4y LjMsIDNyZCBwYXJhICgyIGluc3RhbmNlcyk6CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2dnZ2CnwgICAgWy4uLl0uICBGb3Ig ZXhhbXBsZSwgaWYgYSByZXF1ZXN0b3Igc2l0cyBiZWhpbmQgYSBmaXJld2FsbCB0aGF0CiAgIHdp bGwgYmxvY2sgZnJhZ21lbnRlZCBJUCBwYWNrZXRzLCBhIHJlcXVlc3RvciBTSE9VTEQgTk9UIGNo b29zZSBhCnwgIHZhbHVlIHRoYXQgd2lsbCBjYXVzZSBmcmFnbWVudGF0aW9uLiAgWy4uLl0KICAg ICAgICAgXl5eXgotIFNlY3Rpb24gNi4yLjQ6ICAiLi4uIGFuIFVQREFURSB0aGF0IHRha2VzIGFk dmFudGFnZSBvZiAuLi4iCgotIFNlY3Rpb24gNi4yLjUsIDJuZCBwYXJhOiAgIi4uLiBhIGZhbGxi YWNrIG1lY2hhbmlzbSB0aGF0IGJlZ2lucyAuLi4iCgotIFNlY3Rpb24gNi4yLjYsIDNyZCBwYXJh OiAgIk1pZGRsZWJveGVzIHRoYXQgc2ltcGx5IGZvcndhcmQgLi4uIgoKLSBTZWN0aW9uIDYuMi42 LCA0dGggcGFyYTogICJNaWRkbGVib3hlcyB0aGF0IGhhdmUgYWRkaXRpb25hbCAuLi4iCgotIFNl Y3Rpb24gOCwgM3JkIHBhcmE6ICAiUmVzcG9uZGVycyB0aGF0IGNob29zZSBub3QgdG8gLi4uIgoK LSBTZWN0aW9uIDgsIDR0aCBwYXJhOiAgIi4uLiBzZXJ2ZXJzIHRoYXQgZG8gbm90IGltcGxlbWVu dCAuLi4iCgoKMykgICJyYXRpb25hbCBxdW90YXRpb24iIHN0eWxlCgpQbGVhc2UgYWRqdXN0Cgot IGluIFNlY3Rpb24gMSwgbGFzdCBwYXJhOgoKICAgW1JGQzI2NzFdIHNwZWNpZmllZCBleHRlbmRl ZCBsYWJlbCB0eXBlcy4gIFRoZSBvbmx5IG9uZSBwcm9wb3NlZCB3YXMKfCAgaW4gW1JGQzI2NzNd IGZvciBhIGxhYmVsIHR5cGUgY2FsbGVkICJCaXRzdHJpbmcgTGFiZWxzLiIgIFsuLi5dCi0tLSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eCiAg IFtSRkMyNjcxXSBzcGVjaWZpZWQgZXh0ZW5kZWQgbGFiZWwgdHlwZXMuICBUaGUgb25seSBvbmUg cHJvcG9zZWQgd2FzCnwgIGluIFtSRkMyNjczXSBmb3IgYSBsYWJlbCB0eXBlIGNhbGxlZCAiQml0 c3RyaW5nIExhYmVscyIuICBbLi4uXQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBeXgotIGluIFNlY3Rpb24gNi4xLjMsIGV4cGxhbmF0aW9u IG9mIFZFUlNJT046CgogICAgICAgICBJbmRpY2F0ZXMgdGhlIGltcGxlbWVudGF0aW9uIGxldmVs IG9mIHRoZSBzZXR0ZXIuICBGdWxsCiAgICAgICAgIGNvbmZvcm1hbmNlIHdpdGggdGhpcyBzcGVj aWZpY2F0aW9uIGlzIGluZGljYXRlZCBieSB2ZXJzaW9uCnwgICAgICAgIGBgMC4nJyAgUmVxdWVz dG9ycyBhcmUgZW5jb3VyYWdlZCB0byBbLi4uXQotLS0gICAgICAgICBeXl4KICAgICAgICAgSW5k aWNhdGVzIHRoZSBpbXBsZW1lbnRhdGlvbiBsZXZlbCBvZiB0aGUgc2V0dGVyLiAgRnVsbAogICAg ICAgICBjb25mb3JtYW5jZSB3aXRoIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBpbmRpY2F0ZWQgYnkg dmVyc2lvbgp8ICAgICAgICBgYDAnJy4gIFJlcXVlc3RvcnMgYXJlIGVuY291cmFnZWQgdG8gWy4u Ll0KICAgICAgICAgICAgXl5eCgogIEJ1dCB0aGVyZSBzZWVtcyBubyBuZWVkIHRvIHF1b3RlIHRo ZSBWRVJTSU9OIHZhbHVlIDAgLS0gaW4gdGhlCiAgc2FtZSBwYXJhZ3JhcGggYW5kIGluIG90aGVy IHBhcnRzIG9mIHRoZSBtZW1vLCBmaWVsZCB2YWx1ZXMgYXJlCiAgcmVndWxhcmx5IHNob3duIGxp dGVyYWxseSBvciBzeW1ib2xpY2FsbHkgd2l0aG91dCBhbnkgcXVvdGVzLgogIFNvIGl0IHdvdWxk IGJlIGV2ZW4gbW9yZSBwcmVmZXJhYmxlIHRvIHNpbXBsaWZ5IHRoaXMgdG86CgogICAgICAgICBJ bmRpY2F0ZXMgdGhlIGltcGxlbWVudGF0aW9uIGxldmVsIG9mIHRoZSBzZXR0ZXIuICBGdWxsCiAg ICAgICAgIGNvbmZvcm1hbmNlIHdpdGggdGhpcyBzcGVjaWZpY2F0aW9uIGlzIGluZGljYXRlZCBi eSB2ZXJzaW9uIDAuCiAgICAgICAgIFJlcXVlc3RvcnMgYXJlIGVuY291cmFnZWQgdG8gWy4uLl0K Cgo0KSBIeXBoZW5hdGlvbgoKUGxlYXNlIHVzZSBoeXBoZW5zIGluIHdvcmQgY29tYmluYXRpb25z IHVzZWQgYXMgYXR0cmlidXRlczoKCi0gaW4gU2VjdGlvbiA4LCA0dGggcGFyYToKCiAgcy9vdXQg b2YgcmFuZ2UgdmFsdWVzL291dC1vZi1yYW5nZSB2YWx1ZXMvCgotIGluIFNlY3Rpb24gOSwgMXN0 IHBhcmE6CgogIHMvYSBETlMgZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrL2EgRE5TIGRlbmlhbC1v Zi1zZXJ2aWNlIGF0dGFjay8KCgpCKSBzaW5ndWxhciBkZXRhaWxzOgoKNSkgIFNlY3Rpb24gNC4x CgpUaGVyZSBzZWVtcyB0byBiZSBhIHNwdXJpb3VzIGNvbW1hLCBhbmQgdHdvIGluc3RhbmNlcyBv ZiAib2YiIGFyZQptaXNzaW5nOgoKICAgVGhlIEROUyBNZXNzYWdlIEhlYWRlcidzIHNlY29uZCBm dWxsIDE2LWJpdCB3b3JkIGlzIGRpdmlkZWQgaW50byBhCnwgIDQtYml0IE9QQ09ERSwgYSA0LWJp dCBSQ09ERSwgYW5kIGEgbnVtYmVyIG9mIDEtYml0IGZsYWdzIChzZWUgLAogICAgICAgICAgICAg ICAgdiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl4KfCAg c2VjdGlvbiA0LjEuMSBbUkZDMTAzNV0pLiAgU29tZSBvZiB0aGVzZSB3ZXJlIG1hcmtlZCBmb3Ig ZnV0dXJlIHVzZSwKfCAgYW5kIG1vc3QgdGhlc2UgaGF2ZSBzaW5jZSBiZWVuIGFsbG9jYXRlZC4g IFsuLi5dCi0tLSAgICAgICAgXgogICBUaGUgRE5TIE1lc3NhZ2UgSGVhZGVyJ3Mgc2Vjb25kIGZ1 bGwgMTYtYml0IHdvcmQgaXMgZGl2aWRlZCBpbnRvIGEKfCAgNC1iaXQgT1BDT0RFLCBhIDQtYml0 IFJDT0RFLCBhbmQgYSBudW1iZXIgb2YgMS1iaXQgZmxhZ3MgKHNlZSBzZWN0aW9uCnwgIDQuMS4x IG9mIFtSRkMxMDM1XSkuICBTb21lIG9mIHRoZXNlIHdlcmUgbWFya2VkIGZvciBmdXR1cmUgdXNl LCBhbmQKfCAgbW9zdCBvZiB0aGVzZSBoYXZlIHNpbmNlIGJlZW4gYWxsb2NhdGVkLiAgWy4uLl0K Cgo2KSAgU2VjdGlvbiA1LCAzcmQgcGFyYSAtLSBwdW5jdHVhdGlvbgoKRm9yIGNsYXJpdHksIHR3 byBjb21tYXMgc2hvdWxkIGJlIGFkZGVkIGFzIGZvbGxvd3MgdG8gZGVsaW5lYXRlCnRoZSBmaXJz dCBzdWItY2xhdXNlIHN0YXJ0aW5nIHdpdGggIndoaWNoIjoKCiAgIEV4dGVuZGVkIExhYmVsIFR5 cGVzIGFyZSBkaWZmaWN1bHQgdG8gdXNlIGR1ZSB0byBzdXBwb3J0IGluIGNsaWVudHMKfCAgYW5k IGludGVybWVkaWF0ZSBnYXRld2F5cyBhcyBkZXNjcmliZWQgaW4gW1JGQzMzNjRdLCB3aGljaCBt b3ZlcyB0aGVtCnwgIHRvIGV4cGVyaW1lbnRhbCBzdGF0dXMsIGFuZCBbUkZDMzM2M10sIHdoaWNo IGRlc2NyaWJlcyB0aGUgcHJvcyBhbmQKICAgY29ucy4KCkFsdGVybmF0aXZlbHksIHRoZSAid2hp Y2giIHN1Yi1jbGF1c2VzIG1pZ2h0IGJlIHBsYWNlZCBwYXJlbnRoZXNlczoKCiAgIEV4dGVuZGVk IExhYmVsIFR5cGVzIGFyZSBkaWZmaWN1bHQgdG8gdXNlIGR1ZSB0byBzdXBwb3J0IGluIGNsaWVu dHMKfCAgYW5kIGludGVybWVkaWF0ZSBnYXRld2F5cyBhcyBkZXNjcmliZWQgaW4gW1JGQzMzNjRd ICh3aGljaCBtb3ZlcyB0aGVtCnwgIHRvIGV4cGVyaW1lbnRhbCBzdGF0dXMpIGFuZCBbUkZDMzM2 M10gKHdoaWNoIGRlc2NyaWJlcyB0aGUgcHJvcyBhbmQKICAgY29ucykuCgo3KSAgU2VjdGlvbiA2 LjEuMywgZXhwbGFuYXRpb24gb2YgVkVSU0lPTgoKICBzL3J1biB0aW1lIGNvbmZpZ3VyYXRpb24g b3B0aW9uL3J1bnRpbWUgY29uZmlndXJhdGlvbiBvcHRpb24vCiAgICAgICBeCgo4KSAgU2VjdGlv biA2LjIuNgoKLSBJbiB0aGUgZmlyc3QgcGFyYSwgYSBjb21tYSBzaG91bGQgYmUgcGxhY2VkIGZv ciBjbGFyaXR5IGluIHRoZQogIDFzdCBsaW5lOgoKfCAgSW4gYSBuZXR3b3JrIHRoYXQgY2Fycmll cyBETlMgdHJhZmZpYywgdGhlcmUgY291bGQgLi4uCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBeCi0gQXQgdGhlIHZlcnkgZW5kIG9mIHRoZSBsYXN0IHBhcmEsIHRoZSB0 cmFpbGluZyBwZXJpb2QgaXMgbWlzc2luZy4KCgo5KSAgU2VjdGlvbiA4LCA0dGggcGFyYSAtLSBw dW5jdHVhdGlvbgoKSSBzdWdnZXN0IHRvIHBsYWNlIGEgY29tbWEgZm9yIGNsYXJpdHk6Cgp8ICAg ICAgIFsuLi5dICBJZiB0aGlzIG9jY3VycywgdGhlIHJlc3BvbmRlciBNVVNUIC4uLgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgIF4KCjEwKSAgU2VjdGlvbiAxMCAtLSBncmFtbWFyIC8gdHlw b3MKCi0gQXQgYWJvdXQgb25lIHRoaXJkIG9mIHRoZSBzZWN0aW9uOgogICAgICAgICAgICAgICAg ICAgICAgICAgICB2dgp8ICBJQU5BIGlzIGFkdmlzZWQgdG8gdWRwYXRlcyByZWZlcmVuY2VzIHRv IFtSRkMyNjcxXSBpbiB0aGVzZSBlbnRyaWVzCiAgIGFuZCBzdWItcmVnaXN0cmllcyB0byB0aGlz IGRvY3VtZW50LgotLS0gICAgICAgICAgICAgICAgICAgICAgICB2CnwgIElBTkEgaXMgYWR2aXNl ZCB0byB1ZHBhdGUgcmVmZXJlbmNlcyB0byBbUkZDMjY3MV0gaW4gdGhlc2UgZW50cmllcwogICBh bmQgc3ViLXJlZ2lzdHJpZXMgdG8gdGhpcyBkb2N1bWVudC4KCi0gSW4gdGhlIHNlY29uZC10by1s YXN0IHBhcmE6Cgp8ICAgICBbLi4uXS4gIEZvciBtYW55IHVzZXMsIGEgRUROUyBPcHRpb24gQ29k ZSBtYXkgYmUgcHJlZmVycmVkLgotLS0gICAgICAgICAgICAgICAgICAgICAgICAgIHZ2CnwgICAg IFsuLi5dLiAgRm9yIG1hbnkgdXNlcywgYW4gRUROUyBPcHRpb24gQ29kZSBtYXkgYmUgcHJlZmVy cmVkLgoKCktpbmQgcmVnYXJkcywKICBBbGZyZWQgSM5uZXMuCgotLSAKCistLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r CnwgVFItU3lzIEFsZnJlZCBIb2VuZXMgICB8ICBBbGZyZWQgSG9lbmVzICAgRGlwbC4tTWF0aC4s IERpcGwuLVBoeXMuICB8CnwgR2VybGluZ2VyIFN0cmFzc2UgMTIgICB8ICBQaG9uZTogKCs0OSk3 MTU2Lzk2MzUtMCwgRmF4OiAtMTggICAgICAgICB8CnwgRC03MTI1NCAgRGl0emluZ2VuICAgICB8 ICBFLU1haWw6ICBhaEBUUi1TeXMuZGUgICAgICAgICAgICAgICAgICAgICB8CistLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkbnNl eHQgbWFpbGluZyBsaXN0CmRuc2V4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Ruc2V4dAo= From dnsext-bounces@ietf.org Fri Mar 23 14:06:52 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F9D21F85DB; Fri, 23 Mar 2012 14:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332536812; bh=IHoKV8twAWktP8DrSfkI60BeUAmvClq6hEsy54YqBEk=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=k5WCpAU560Mjm+jitqeWoxENr4o/YV03vRzl901SxugGJOsJDYS7BytBTn8hLol3o Ya7RuP67fUOk8qkGXwobG3a4I2aRmSt2fq1SxJzVuConkyjsbInaCxmMPcjGV4Riaz eDDrDEnalSU9iLqhmKalhDA1lK4S+Oe+UekT/2kI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A859921F85DA for ; Fri, 23 Mar 2012 14:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.515 X-Spam-Level: X-Spam-Status: No, score=-106.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0kVR7B+nu0B for ; Fri, 23 Mar 2012 14:06:50 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 02D4B21F85D8 for ; Fri, 23 Mar 2012 14:06:49 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2NL6k6C040156; Fri, 23 Mar 2012 17:06:46 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4F6CE5E0.1090309@ogud.com> Date: Fri, 23 Mar 2012 17:06:40 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Tony Finch References: <4F6C99CB.7080806@ogud.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: "" Subject: Re: [dnsext] Validator assumptions: what algorithms need to properly sign a zone? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 23/03/2012 14:23, Tony Finch wrote: > Olafur Gudmundsson wrote: >> >> The zone seems to be in compliance with the list in RFC4035 section 2.2 i.e. >> there exists a valid signature by a key in the DNSKEY RRset. >> But in the final paragraph that seems to be contradicted and does >> require the a signing key for all algorithms to be in the DNSKEY RRset. > > I believe the consensus is that that requirement applies to the signer > not the validator. > >> What algorithms can a validator use to validate records from a zone >> 2) any algorithm in the validated DNSKEY RRset > > Tony. but the validator needs to take into account what the signer is allowed/required to do we cannot have totally disjoint requirements/assumptions. Olafur _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Mar 25 17:38:23 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5517321F844C; Sun, 25 Mar 2012 17:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332722303; bh=6TrmgsaZtno8UgykWnldWH0cXmwdS4zlvOoIkmpZZXA=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=eJWQfUInLTcYYlr7dIEu4BMKSsuWfgGRAyiGuK2750n81sOIYHBLJJ9p+CvnU4eht s32ns96MAcDfRxKwnp+aQu6mcqwbNrwWmKK4Kh9eZeqL8UsK8ycI/AL4gqQEdbe4E6 fhYnj6faRsoNGEf/+4ROinOIGqAYZmhS6aOYgtYU= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA7F21F844C for ; Sun, 25 Mar 2012 17:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4QAYTnzXuy4 for ; Sun, 25 Mar 2012 17:38:20 -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 B751021F844B for ; Sun, 25 Mar 2012 17:38: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 8AD245F98A2; Mon, 26 Mar 2012 00:37:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:e86d:a799:6830:7731]) (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 88A11216C33; Mon, 26 Mar 2012 00:37:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C4BB31F082F8; Mon, 26 Mar 2012 11:37:47 +1100 (EST) To: Olafur Gudmundsson From: Mark Andrews References: <4F6C99CB.7080806@ogud.com> <4F6CE5E0.1090309@ogud.com> In-reply-to: Your message of "Fri, 23 Mar 2012 17:06:40 EDT." <4F6CE5E0.1090309@ogud.com> Date: Mon, 26 Mar 2012 11:37:47 +1100 Message-Id: <20120326003747.C4BB31F082F8@drugs.dv.isc.org> Cc: "" Subject: Re: [dnsext] Validator assumptions: what algorithms need to properly sign a zone? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In message <4F6CE5E0.1090309@ogud.com>, Olafur Gudmundsson writes: > On 23/03/2012 14:23, Tony Finch wrote: > > Olafur Gudmundsson wrote: > >> > >> The zone seems to be in compliance with the list in RFC4035 section 2.2 i. > e. > >> there exists a valid signature by a key in the DNSKEY RRset. > >> But in the final paragraph that seems to be contradicted and does > >> require the a signing key for all algorithms to be in the DNSKEY RRset. > > > > I believe the consensus is that that requirement applies to the signer > > not the validator. > > > >> What algorithms can a validator use to validate records from a zone > >> 2) any algorithm in the validated DNSKEY RRset > > > > Tony. > > but the validator needs to take into account what the signer is > allowed/required to do we cannot have totally disjoint > requirements/assumptions. We don't have disjoint requirement. The DS records / configured trust anchors for the zone set up a expection for the zones contents by listing the algorithms that are expected to work. The signer meets those expections by ensuring that each RRset is signed as described. This takes in to account the affects of caching associated with introducing new signing algorithm to a zone. It is NOT the signers job to check that every RRSIG set contains every algorithm listed in the DNSKEY RRset as the contents of these can and often will be from different versions of the zone signed at different times. If the validator is paranoid it MAY check every algorithm listed in the DS RRset/trust anchors is present and it MAY ignore algorithms not in the DS RRset/trust anchors. The validator however MUST NOT check that every algorithm listed in the DNSKEY RRset is present in every RRSIG set. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Mar 25 17:52:00 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738BD21E805E; Sun, 25 Mar 2012 17:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332723120; bh=xGdHcvkjZ2q20djMfsMx04gcgWzCNsEzTQBp/Re8qpI=; h=From:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=bHJ9GEbGh/jai74AlCQ7c0iajBmgljR46YyFxRkjJawLc8VxEH8qezbDfabiC0pZe OeUHwudjOLg9aofLbgoZej10zuam3/4mA3eeVjJlP2S6sO1A0fY1qmMfNA+QtuI991 +qVyBpab6eFDH1mavjZGyXGa0i+f8u7xQMucS13s= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B189D21E805E for ; Sun, 25 Mar 2012 17:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWyiCexwzLch for ; Sun, 25 Mar 2012 17:51:59 -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 2F0C621E8018 for ; Sun, 25 Mar 2012 17:51:59 -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 7D1B35F98B7; Mon, 26 Mar 2012 00:51:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5cb:e520:9c28:3efd]) (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 89166216C33; Mon, 26 Mar 2012 00:51: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 51C041F083DE; Mon, 26 Mar 2012 11:51:41 +1100 (EST) From: Mark Andrews In-reply-to: Your message of "Mon, 26 Mar 2012 11:37:47 +1100." Date: Mon, 26 Mar 2012 11:51:40 +1100 Message-Id: <20120326005141.51C041F083DE@drugs.dv.isc.org> Cc: "" , Olafur Gudmundsson Subject: Re: [dnsext] Validator assumptions: what algorithms need to properly sign a zone? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Mark Andrews writes: > > In message <4F6CE5E0.1090309@ogud.com>, Olafur Gudmundsson writes: > > On 23/03/2012 14:23, Tony Finch wrote: > > > Olafur Gudmundsson wrote: > > >> > > >> The zone seems to be in compliance with the list in RFC4035 section 2.2 > i. > > e. > > >> there exists a valid signature by a key in the DNSKEY RRset. > > >> But in the final paragraph that seems to be contradicted and does > > >> require the a signing key for all algorithms to be in the DNSKEY RRset. > > > > > > I believe the consensus is that that requirement applies to the signer > > > not the validator. > > > > > >> What algorithms can a validator use to validate records from a zone > > >> 2) any algorithm in the validated DNSKEY RRset > > > > > > Tony. > > > > but the validator needs to take into account what the signer is > > allowed/required to do we cannot have totally disjoint > > requirements/assumptions. > > We don't have disjoint requirement. The DS records / configured > trust anchors for the zone set up a expection for the zones contents > by listing the algorithms that are expected to work. The signer > meets those expections by ensuring that each RRset is signed as > described. This takes in to account the affects of caching associated > with introducing new signing algorithm to a zone. The "must sign with every algorithm in the DNSKEY RRset" was a *simple* rule for the *signer* to follow to ensure that there wouldn't be validation failures. We could have written a much more complicated rule about when a signature was required or not but it would have been complicated to describe and would likely not be implemented properly. > It is NOT the signers job to check that every RRSIG set contains > every algorithm listed in the DNSKEY RRset as the contents of these > can and often will be from different versions of the zone signed > at different times. If the validator is paranoid it MAY check every > algorithm listed in the DS RRset/trust anchors is present and it > MAY ignore algorithms not in the DS RRset/trust anchors. > > The validator however MUST NOT check that every algorithm listed > in the DNSKEY RRset is present in every RRSIG set. > > -- > 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Mar 25 17:56:30 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9FA21E8064; Sun, 25 Mar 2012 17:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332723390; bh=sSTX8V6mfkf7+nomRTFRDgmvidHhC03F9szya2H3GLA=; h=From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=Tur0CANMqe8b/7atCKK11nWiiIkWCbfF9YAN1VZ5XV0vsUE0tTfjAKFTk0+J66ojF E8ay5RIAielmCZMLwDBPjUJd8Cay5VnLgrJy+R9Hs/RTpO28bL3hxqcE4zglRYI/tx XvL3zr70JnV4sTJxU1hQmWTvdGeya22peEe4sajw= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F27221E8051 for ; Sun, 25 Mar 2012 17:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLGBKUkbnx9a for ; Sun, 25 Mar 2012 17:56:28 -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 D25F821E8064 for ; Sun, 25 Mar 2012 17:56:27 -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 F2DDD5F98B6; Mon, 26 Mar 2012 00:56:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5cb:e520:9c28:3efd]) (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 07917216C31; Mon, 26 Mar 2012 00:56:11 +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 9FEDD1F08557; Mon, 26 Mar 2012 11:56:08 +1100 (EST) From: Mark Andrews References: <4F6C99CB.7080806@ogud.com> <4F6CE5E0.1090309@ogud.com> <20120326003747.C4BB31F082F8@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 26 Mar 2012 11:37:47 +1100." <20120326003747.C4BB31F082F8@drugs.dv.isc.org> Date: Mon, 26 Mar 2012 11:56:08 +1100 Message-Id: <20120326005608.9FEDD1F08557@drugs.dv.isc.org> Cc: "" , Olafur Gudmundsson Subject: Re: [dnsext] Validator assumptions: what algorithms need to properly sign a zone? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In message <20120326003747.C4BB31F082F8@drugs.dv.isc.org>, Mark Andrews writes: > > In message <4F6CE5E0.1090309@ogud.com>, Olafur Gudmundsson writes: > > On 23/03/2012 14:23, Tony Finch wrote: > > > Olafur Gudmundsson wrote: > > >> > > >> The zone seems to be in compliance with the list in RFC4035 section 2.2 > i. > > e. > > >> there exists a valid signature by a key in the DNSKEY RRset. > > >> But in the final paragraph that seems to be contradicted and does > > >> require the a signing key for all algorithms to be in the DNSKEY RRset. > > > > > > I believe the consensus is that that requirement applies to the signer > > > not the validator. > > > > > >> What algorithms can a validator use to validate records from a zone > > >> 2) any algorithm in the validated DNSKEY RRset > > > > > > Tony. > > > > but the validator needs to take into account what the signer is > > allowed/required to do we cannot have totally disjoint > > requirements/assumptions. > > We don't have disjoint requirement. The DS records / configured > trust anchors for the zone set up a expection for the zones contents > by listing the algorithms that are expected to work. The signer > meets those expections by ensuring that each RRset is signed as > described. This takes in to account the affects of caching associated > with introducing new signing algorithm to a zone. > > It is NOT the signers job to check that every RRSIG set contains s/signers/validator's/ > every algorithm listed in the DNSKEY RRset as the contents of these > can and often will be from different versions of the zone signed > at different times. If the validator is paranoid it MAY check every > algorithm listed in the DS RRset/trust anchors is present and it > MAY ignore algorithms not in the DS RRset/trust anchors. > > The validator however MUST NOT check that every algorithm listed > in the DNSKEY RRset is present in every RRSIG set. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 26 01:55:41 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0EB21F84A2; Mon, 26 Mar 2012 01:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332752141; bh=FSm41nlJKqcRZ1uoeat8vPO1LhYdkRZVZ9bZPs+YT9g=; h=From:Content-Type:Date:Message-Id:To:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Sender; b=H8+ZrdS7cvD9DPS6UUB8MdJPYwicRrkqsNwy6qqEnV7CmbIjYB30DDnjFLxVmr29F DTJHSjHIupEPs0Lzi8PHwLcBUKz/1kATBA4dWUl2lJwCncTpgN9MiKMVnWNoQL+D4x T+7zFDi7A7iAvqecN4n/0i2hGhinf692dDiHMyW0= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A314921F84A2 for ; Mon, 26 Mar 2012 01:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29M86Lao30sO for ; Mon, 26 Mar 2012 01:55:39 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD7521F8474 for ; Mon, 26 Mar 2012 01:55:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 79B9C136C8E1A for ; Mon, 26 Mar 2012 10:55:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3dFboVblAsK for ; Mon, 26 Mar 2012 10:55:35 +0200 (CEST) Received: from dyn-fg104.sth.netnod.se (dyn-fg104.sth.netnod.se [77.72.226.104]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id D4997136C8E11 for ; Mon, 26 Mar 2012 10:55:35 +0200 (CEST) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/mixed; boundary="Apple-Mail=_78AA4F11-4CD2-44C2-9793-32A7AF19007B" Date: Mon, 26 Mar 2012 10:55:35 +0200 Message-Id: <18D7F4C6-544F-40CE-91EF-45C77E80AE5F@frobbit.se> To: "" Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-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: , Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --Apple-Mail=_78AA4F11-4CD2-44C2-9793-32A7AF19007B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, First of all, please note the version number I want you to (re-)read. It = is posted basically "now", but for the ones that want to check before it = ends up in the repository, I have also attached a copy. This version is, I think, answering all questions all individuals have = had that I have managed to track. I have had private conversation with = many of you that had comments after version -02, and your comments have = been passed to the editors. I already have enough individuals that have said they have read this = draft and support it to be able to forward it towards the IESG, so this = WGLC only have as a goal to ensure there are no more issues. I would like to thank, among others, Miek Gieben, Mark Andrews, Marc = Lampo, Bill Manning, Warren Kumari, Ed Lewis and Dick Franks for the = review and suggested changes. Patrik --Apple-Mail=_78AA4F11-4CD2-44C2-9793-32A7AF19007B Content-Disposition: attachment; filename=draft-ietf-dnsext-dnssec-algo-signal-05.txt Content-Type: text/plain; name="draft-ietf-dnsext-dnssec-algo-signal-05.txt" Content-Transfer-Encoding: quoted-printable DNS Extensions Working Group S. Crocker Internet-Draft Shinkuro Inc. Intended status: Standards Track S. Rose Expires: September 21, 2012 NIST March 20, 2012 Signaling Cryptographic Algorithm Understanding in DNSSEC draft-ietf-dnsext-dnssec-algo-signal-05 Abstract The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms and hash algorithms they support. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 21, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Crocker & Rose Expires September 21, 2012 [Page 1] =0C Internet-Draft Algorithm-Signal March 2012 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Signaling DNSSEC Algorithm Understood (DAU), DS Hash Understood (DHU) and NSEC3 Hash Understood (N3U) Using EDNS . . 3 3. Client Considerations . . . . . . . . . . . . . . . . . . . . . 5 3.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Validating Stub Resolvers . . . . . . . . . . . . . . . . . 5 3.3. Non-Validating Stub Resolvers . . . . . . . . . . . . . . . 5 3.4. Recursive Resolvers . . . . . . . . . . . . . . . . . . . . 5 3.4.1. Validating Recursive Resolvers . . . . . . . . . . . . 5 3.4.2. Non-validating Recursive Resolvers . . . . . . . . . . 6 4. Intermediate System Considerations . . . . . . . . . . . . . . 6 5. Server Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Traffic Analysis Considerations . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Crocker & Rose Expires September 21, 2012 [Page 2] =0C Internet-Draft Algorithm-Signal March 2012 1. Introduction The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and [RFC4035] were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. Each digital signature RR (RRSIG) contains an algorithm code number. These algorithm codes tells validators which cryptographic algorithm was used to generate the digital signature. Likewise, Delegated Signer (DS) RR's and NSEC3 RR's use a hashed value as part of their RDATA and like digital signature algorithms, these hash algorithms have code numbers. All three algorithm codes (RRSIG/DNSKEY, DS and NSEC3) are maintained in unique IANA registries. This draft sets out to specify a way for validating end-system resolvers to tell a server which cryptographic and/or hash algorithms they support in a DNS query. This is done using the EDNS attribute values in the OPT meta-RR [RFC2671]. These proposed EDNS options serve to measure the acceptance and use of new digital signing algorithms. These signaling options can be used by zone administrators as a gauge to measure the successful deployment of code that implements a newly deployed digital signature and hash algorithm, DS hash and NSEC3 hash algorithm used with DNSSEC. A zone administrator may be able to determine when to stop signing with the old algorithm(s) when the server sees that a significant number of its clients signal that they are able to accept the new algorithm. Note that this survey may be conducted over the period of years before a tipping point is seen. This draft does not seek to introduce another process for including new algorithms for use with DNSSEC. It also does not address the question of which algorithms are to be included in any official list of mandatory or recommended cryptographic algorithms for use with DNSSEC. Rather, this document specifies a means by which a client query can signal a set of algorithms and hashes it implements. 2. Signaling DNSSEC Algorithm Understood (DAU), DS Hash Understood (DHU) and NSEC3 Hash Understood (N3U) Using EDNS The ENDS0 specification outlined in [RFC2671] defines a way to include new options using a standardized mechanism. These options are contained in the RDATA of the OPT meta-RR. This document defines three new EDNS0 options for a client to signal which digital signature and/or hash algorithms the client supports. These options can be used independly of each other and MAY appear in any order in the OPT RR. Crocker & Rose Expires September 21, 2012 [Page 3] =0C Internet-Draft Algorithm-Signal March 2012 The figure below shows how each option is defined in the RDATA of the OPT RR specified in [RFC2671]: 0 8 16 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OPTION-CODE (TBD) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | LIST-LENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ALG-CODE | ... \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ OPTION-CODE is the code for the given signaling option. They are: o DNSSEC Algorithm Understood (DAU) option for DNSSEC digital signing algorithms. Its value is fixed at TBD1. o DS Hash Understood (DHU) option for DS RR hash algorithms. Its value is fixed at TBD2. o NSEC3 Hash Understood (N3U) option for NSEC3 hash algorithms. Its value is fixed at TBD3. LIST-LENGTH is the length of the list of digital signature or hash algorithms in octets. Since each algorithm and hash codes are 1 octet long so this value is the number of octets. ALG-CODE is the list of assigned values of DNSSEC zone signing algorithms, DS hash algorithms, or NSEC3 hash algorithms (depending on the OPTION-CODE in use) that the client indicates as understood. The values SHOULD be in descending order of preference, with the most preferred algorithm first. For example, if a validating client signals the DAU option and RSA/SHA-1, RSA/SHA-256 and prefers the latter, the values of ALG-CODE would be: 8 (RSA/SHA-256), 5 (RSA/ SHA-1). If all three options are included in the OPT RR, there is a potential for the OPT RR to take up considerable size in the DNS message. However, in practical terms including all three options are likely to take up 16-24 octets (average of 6-10 digital signature algorithms, 3-5 DS hash algorithms and 1-5 NSEC3 hash algorithms) including the EDNS option codes and option lengths in a reasonable potential future example. Crocker & Rose Expires September 21, 2012 [Page 4] =0C Internet-Draft Algorithm-Signal March 2012 3. Client Considerations A validating end-system resolver sets the DAU, DHU and/or N3U option, or combination thereof in the OPT meta-RR when sending a query. The validating end-system resolver sets the value(s) in the order of preference, with the most preferred algorithm(s) first as described in section 2. The end-system resolver SHOULD also set the DNSSEC-OK bit [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the response. Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital signature codes for cover a potentially wide range of algorithms and are likely not useful to a server. There is no compelling reason for a client to include these codes in its list of the DAU. Likewise, clients MUST NOT include RESERVED codes in any of the options. 3.1. Stub Resolvers Typically, stub resolvers rely on an upstream recursive server (or cache) to provide a response. So optimal setting of the DAU, DSU and N3U options depends on whether the stub resolver performs its own DNSSEC validation or doesn't perform its own validation. 3.2. Validating Stub Resolvers A validating stub resolver already (usually) sets the DO bit [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs (i.e. RRSIG RR's) in the response. Such validating resolvers SHOULD include the DAU, DHU and/or the N3U option(s) in the OPT RR when sending a query. This way thee validating stub resolver indicates which cryptographic algorithm(s) it supports by setting the values(s) in the order of preference, with the most preferred algorithm(s) first as described in Section 2. 3.3. Non-Validating Stub Resolvers The DAU, DHU and N3U EDNS options are NOT RECOMMENDED for non- validating stub resolvers. 3.4. Recursive Resolvers 3.4.1. Validating Recursive Resolvers A validating recursive resolver sets the DAU, DHU and/or N3U option(s) when performing recursion based on the DO and CD flags in the client request [RFC4035]. If the client of the recursive resolver did not include the DO bit in the query the recursive resolver SHOULD include the option(s) according to its own local Crocker & Rose Expires September 21, 2012 [Page 5] =0C Internet-Draft Algorithm-Signal March 2012 policy. If the client did include the DO and CD bits, but did not include the DAU, DHU and/or N3U option(s) in the query, the validating recursive resolver SHOULD NOT include the option(s) to avoid conflicts. If the client did set the DO bit and the option(s) in the query, the validating recursive resolver SHOULD include the option(s) based on the setting of the CD bit. If the CD bit is set, the validating recursive resolver SHOULD include the option(s) based on the client query or a superset of the client option(s) list and the validator's own list (if different). If the CD bit is not set, the validating recursive resolver MAY copy the client option(s) or substitute its own option list. 3.4.2. Non-validating Recursive Resolvers Recursive resolvers that do not do validation SHOULD copy the DAU, DHU and/or N3U option(s) seen in received queries as they represent the wishes of the validating downstream resolver that issued the original query. 4. Intermediate System Considerations Intermediate proxies [RFC5625] that understand DNS SHOULD behave like a comparable recursive resolver when dealing with the DAU, DHU and N3U options. 5. Server Considerations When an authoritative server sees the DAU, DHU and/or N3U option(s) in the OPT meta-RR in a request the normal algorithm for servicing requests is followed. The options does not trigger any special processing on the server side. If the options are present but the DNSSEC-OK (OK) bit is not set, the server does not do any DNSSEC processing, including any recording of the option(s). 6. Traffic Analysis Considerations Zone administrators that are planning or are in the process of a cryptographic algorithm rollover operation should monitor DNS query traffic and record the number of queries, the presense of the OPT RR in queries and the values of the DAU/DHU/N3U option(s) (if present). This monitoring can be used to measure the deployment of client code that implements (and signals) certain algorithms. The Exactly how to capture DNS traffic and measure new algorithm adoption is beyond the Crocker & Rose Expires September 21, 2012 [Page 6] =0C Internet-Draft Algorithm-Signal March 2012 scope of this document. Zone administrators that need to comply with changes to their organization's security policy (with regards to cryptographic algorithm use) can use this data to set milestone dates for performing an algorithm rollover. For example, zone administrators can use the data to determine when older algorithms can be phased out without disrupting a significant number of clients. In order to keep this disruption to a minimum, zone administrators should wait to complete an algorithm rollover until a large majority of clients signal that they understand the new algorithm. This may be in the order of years rather than months. Note that clients that do not implement these options are likely to be older implementations which would also not implement any newly deployed algorithm. 7. IANA Considerations The algorithm codes used to identify DNSSEC algorithms, DS RR hash algorithms and NSEC3 hash algorithms have already been established by IANA. This document does not seek to alter that registry in any way. This draft seeks to update the "DNS EDNS0 Options" registry by adding the DAU, DHU and N3U options and referencing this document. The code for these options are TBD1, TBD2 and TBD3 respectively. 8. Security Considerations This document specifies a way for a client to signal its cryptographic and hash algorithm knowledge to a cache or server. It is not meant to be a discussion on algorithm superiority. The signals are optional codes contained in the OPT meta-RR used with EDNS0. The goal of these options are to signal new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC signed zone. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Crocker & Rose Expires September 21, 2012 [Page 7] =0C Internet-Draft Algorithm-Signal March 2012 Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009. Authors' Addresses Steve Crocker Shinkuro Inc. 5110 Edgemoor Lane Bethesda, MD 20814 USA EMail: steve@shinkuro.com Scott Rose NIST 100 Bureau Dr. Gaithersburg, MD 20899 USA Phone: +1-301-975-8439 EMail: scottr.nist@gmail.com Crocker & Rose Expires September 21, 2012 [Page 8] =0C --Apple-Mail=_78AA4F11-4CD2-44C2-9793-32A7AF19007B Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --Apple-Mail=_78AA4F11-4CD2-44C2-9793-32A7AF19007B-- From dnsext-bounces@ietf.org Mon Mar 26 02:14:08 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E5521F8584; Mon, 26 Mar 2012 02:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332753248; bh=tZShbdU0v9vXCcJUgbYKoayqC6i8jTw8ddPurBtxM3Q=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=TPCkrLXx8mOuLgRHPHsucOWiTVHOAVWn1hSySFS0tVg3m/xc4br8Yi0Ax/6o4wNfE xbqVrmJ3jrBlHcTvxJpJzFP2W1rW+aJ3CXow4Nx5IhAASafaOfjl9q8/ftEgCV03R2 mKcTL2AtXjmWUzW0cJQ9NB9Xl2wkkrmYhGyVOzGo= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754E421F8525 for ; Mon, 26 Mar 2012 02:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.52 X-Spam-Level: X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-ELnW2WYV+P for ; Mon, 26 Mar 2012 02:14:06 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8358D21F84FD for ; Mon, 26 Mar 2012 02:14:05 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2Q9E3Cb062230 for ; Mon, 26 Mar 2012 05:14:04 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4F703356.8090003@ogud.com> Date: Mon, 26 Mar 2012 11:13:58 +0200 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: [dnsext] DNSEXT current WG status X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Dear Colleagues We are not going to meet our plan to be able to close down the group at this meeting. The main reason is that we have not completed all the documents that are on our plate. The reasons are many but the chairs and the AD have agreed to keep working on cleaning out our queue and be able to close down the WG around the July IETF-84 meeting. Document Status: New RFC's None. Document status: advanced documents rfc2671bis-edns0: In IETF Last call rfc2672bis-dname ecdsa: RFC Editors queue IANA action complete xnamercode: RFC Editors queue no IANA actions Document Status: Documents in group dnssec-bis-updates: WG will advance this week to IESG dnssec-algo-signal: Quick last call started to confirm consensus from first LC, expect to advance in April. dnssec-registry-fixes: Document was split into two documents and this one is obsolete. algo-impl-status: ready for WG LC will start next week dnssec-registry-update: Ready for WG LC will start next week eastlake-rfc6195bis: to become dnsext-rfc6195bis rfc6195bis: A update to current IANA instructions document, this one simplifies the expert review, and closes an unused registry. WG Last call planned at the end of April ah-dnsext-rfc1995bis-ixfr: document is actually a WG document, editors submitted latest version under the old name. We think this document is getting close and we plan to push for a WG LC by May. Document Status: Individual Submissions related to WG andrews-dnsext-udp-fragmentation: Editor asked for adoption. Adopt or tell editor to submit to independent RFC stream. levine-dnsextlang-02: Document proposes a "language" to specify RR types RDATA. This draft has the potential to automate the translation of new RR types to/from presentation format to wire or unknown formats. As DNSEXT owns DNS presentation format this document is inside our charter and we may want to adopt it and advance it before we close the group down. Andrew and Olafur _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 26 02:44:11 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AEC21F85FB; Mon, 26 Mar 2012 02:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332755051; bh=Pa0cV3uOGXFHiLN5Zip5xaNCUnSQe5/wMUXGUNhyo+c=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=EdX/DHj+uGMKmS7PkT4tcgFELV6Vdkn3cq1u8uROIfkluBJzXERZAPMVN9RFpBtpv zGZt/0zWaxSUDClbxyxk+FNyjO7tapChjAoVd1WobKiMSM4kJjI84OTrjuE768mPdM 4NYEkp5cuGp4ksC/EktH4nEaf+yw3/bEesKbo3Q4= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FD921F8600 for ; Mon, 26 Mar 2012 02:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJYV3MK4gTzJ for ; Mon, 26 Mar 2012 02:44:09 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id C296821F85FB for ; Mon, 26 Mar 2012 02:44:08 -0700 (PDT) Received: from dhcp-45d4.meeting.ietf.org (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2Q9i5fj062537; Mon, 26 Mar 2012 05:44:06 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [130.129.69.212] by dhcp-45d4.meeting.ietf.org (PGP Universal service); Mon, 26 Mar 2012 11:44:06 +0200 X-PGP-Universal: processed; by dhcp-45d4.meeting.ietf.org on Mon, 26 Mar 2012 11:44:06 +0200 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F6C99CB.7080806@ogud.com> References: <4F6C99CB.7080806@ogud.com> Date: Mon, 26 Mar 2012 11:43:47 +0200 To: Olafur Gudmundsson From: Edward Lewis X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: "" Subject: Re: [dnsext] Validator assumptions: what algorithms need to properly sign a zone? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org At 11:42 -0400 3/23/12, Olafur Gudmundsson wrote: >Both positions are arguable, but it is bad for resolver vendors to >be put in this position to argue with customers why they disagree on >the right answer, and DNSSEC operators need a strong message what is >allowed. I disagree. There should be no argument. A validator needs to be as liberal as possible in building a secure "chain" to a trust anchor. Liberal means using as many valid options as possible including jumping algorithms. Liberal does not mean bending the rules, accepting invalid signatures nor accepting expired signatures. The reason for the need to be liberal is that DNSSEC is an "add on" which inherently makes the underlying system more brittle. By declaring once valid states of the DNS protocol to be dead states (SERVFAIL) DNSSEC is choking off parts of the protocol. To correct for that, at least in the name of reliability, resiliency, and availability, DNSSEC has to be as liberal (rugged is another word) as possible. Looking at the example, the A2 signatures would be consider not germane by any validator that lacks an A2 trust anchor that was the key doing the A2 signing. The lack of A1 signatures would mean any validator could rightly assume that something removed the signatures ("rightly assume" is not equal to "be right in assuming") and treat the response as suspect/invalid *if not* for the presence of a valid chain via the B1 algorithm. A valid chain is harder to construct that an invalid one. Make it it harder for a malicious agent by recognizing that fact. Don't make it trivial to cause a denial of service. >In the case of a validator that supports A but not B SERVFAIL is the >right answer as the zone is not properly signed for that algorithm. That is true. In this case, the validator's failure to speak algorithm B is a testament to a lack of ruggedness. >Some people in this working group have argued that use/order of algorithms >should be local policy and it is outside the documents scope to talk about >this, others argue that will lead to unpredictability in resolution status. Everything is trumped by local policy. And if local policy is not rely on an algorithm, that is a fact of life. DNSSEC does not guarantee the data will get though, it guarantees that is what is received can be tested. (Positive, validation isn't guaranteed, just that the receiver will have the means to test.) >Doodle poll available at: > http://www.doodle.com/7v5vmzvaerb2n8sb Filled in the poll, but still reject voting. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 26 03:00:46 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F68221F8606; Mon, 26 Mar 2012 03:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332756046; bh=HHGNJ1PJ/tmBLGHQ0wp0bpbR2UDub8WpeeKThQ366nU=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=rvyvHEm4ZTfreLwc06LltbMFpGTl/OoJmP3Tc8uG3l0OGfqSFChext1XE/nNx4p7j 7WlAI8z8fa/kGQUr4PsUR9vW5H/v/GTOAyvfrX6KaeU16e3AqBQTeoNOtCK88wny26 aVHnn/I1Luj6kx+xJd3cbuWIflYkyf49ybnx7MoA= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0A21F8603 for ; Mon, 26 Mar 2012 03:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0xZKrkAA1es for ; Mon, 26 Mar 2012 03:00:41 -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 898E421F8606 for ; Mon, 26 Mar 2012 03:00:40 -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-2.csi.cam.ac.uk ([131.111.8.54]:53389) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SC6j9-000680-Q4 (Exim 4.72) (return-path ); Mon, 26 Mar 2012 11:00:39 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SC6j9-0006CZ-1D (Exim 4.67) (return-path ); Mon, 26 Mar 2012 11:00:39 +0100 Date: Mon, 26 Mar 2012 11:00:39 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Olafur Gudmundsson In-Reply-To: <4F6CE5E0.1090309@ogud.com> Message-ID: References: <4F6C99CB.7080806@ogud.com> <4F6CE5E0.1090309@ogud.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Cc: "" Subject: Re: [dnsext] Validator assumptions: what algorithms need to properly sign a zone? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Olafur Gudmundsson wrote: > On 23/03/2012 14:23, Tony Finch wrote: > > Olafur Gudmundsson wrote: > > > > > > The zone seems to be in compliance with the list in RFC4035 section 2.2 > > > i.e. > > > there exists a valid signature by a key in the DNSKEY RRset. > > > But in the final paragraph that seems to be contradicted and does > > > require the a signing key for all algorithms to be in the DNSKEY RRset. > > > > I believe the consensus is that that requirement applies to the signer > > not the validator. > > but the validator needs to take into account what the signer is > allowed/required to do we cannot have totally disjoint > requirements/assumptions. They aren't disjoint. I think it makes more sense if who takes what into account is the opposite way round to what you suggest. The validation algorithm allows for a lot of flexibility and makes validation possible despite some kinds of brokenness; the requirements on the signer keep it well within the range of what validators allow. Robustness principle. Tony. -- f.anthony.n.finch http://dotat.at/ Fisher, German Bight: Northwesterly 3 or 4, increasing 5 or 6 in east Fisher. Moderate in east Fisher, otherwise slight. Fog patches. Moderate or good, occasionally very poor. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 26 04:00:40 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFE621F8601; Mon, 26 Mar 2012 04:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332759640; bh=ItF/YANSDSGQ9tDZ84eVnhtw8wpZnb9Q347MaR0keuw=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=sdtAWq2CYRpxs7Fm1PUqixQKJnHiYBq2qsvdTFtabpPacZvyXRnAiubWWD1K81zzl Lk0h6suyEC+j28EnQmsxS/N9uuRoMKOi1npI6/LmiTH7woGjLLu+djmTCX7y8P5/pv jOLt1BZFrHzcQBRl126nwgrXyy4jdbWwW8LfLuvc= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE29421F8601 for ; Mon, 26 Mar 2012 04:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7MkRajZn6Yy for ; Mon, 26 Mar 2012 04:00:37 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 15A6921F859A for ; Mon, 26 Mar 2012 04:00:36 -0700 (PDT) Received: from dhcp-45d4.meeting.ietf.org (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2QB0ZLk063260; Mon, 26 Mar 2012 07:00:35 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [130.129.69.212] by dhcp-45d4.meeting.ietf.org (PGP Universal service); Mon, 26 Mar 2012 13:00:35 +0200 X-PGP-Universal: processed; by dhcp-45d4.meeting.ietf.org on Mon, 26 Mar 2012 13:00:35 +0200 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4F6C99CB.7080806@ogud.com> <4F6CE5E0.1090309@ogud.com> Date: Mon, 26 Mar 2012 12:55:22 +0200 To: "" From: Edward Lewis X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Validator assumptions: what algorithms need to properly sign a zone? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org At 11:00 +0100 3/26/12, Tony Finch wrote: >They aren't disjoint. I think it makes more sense if who takes what into >account is the opposite way round to what you suggest. The validation >algorithm allows for a lot of flexibility and makes validation possible >despite some kinds of brokenness; the requirements on the signer keep it >well within the range of what validators allow. Robustness principle. Yup. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 26 04:06:15 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC3F21F8619; Mon, 26 Mar 2012 04:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332759975; bh=xY6sGn7CUpXKrI2FncDM5+02xJUo+Nl0RtJC5wSOBl0=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=Sc7Z5qlKya+csuNYU2eYIpZzEWqda5uBFRFpErndxhTG/VEH2HZWBcCU+JGfXVttH gkG6ESG9YkdvA3Dpkk2vw0RA9TwbhNoTTEwIqSEqg6o/9NDg7lRS58J0e2c36ANxRU Oi9JT+9vtfvvuOgwH1xFsOyvBv2h7dyURkxtiHUE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A41121F859A for ; Mon, 26 Mar 2012 04:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-WZZSZ5zAwc for ; Mon, 26 Mar 2012 04:06:13 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id C124C21F8613 for ; Mon, 26 Mar 2012 04:06:13 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 31A7D3FEF4; Mon, 26 Mar 2012 13:06:10 +0200 (CEST) Date: Mon, 26 Mar 2012 13:06:10 +0200 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120326110610.GA29525@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <18D7F4C6-544F-40CE-91EF-45C77E80AE5F@frobbit.se> MIME-Version: 1.0 In-Reply-To: <18D7F4C6-544F-40CE-91EF-45C77E80AE5F@frobbit.se> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-05.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0039435149206819305==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============0039435149206819305== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "[dnsext] WGLC on draft-ietf-dnsext-..." ] > All, >=20 > First of all, please note the version number I want you to (re-)read. It = is > posted basically "now", but for the ones that want to check before it end= s up > in the repository, I have also attached a copy. Looks good to me. One nit though: > 3.2. Validating Stub Resolvers >=20 > A validating stub resolver already (usually) sets the DO bit > [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs > (i.e. RRSIG RR's) in the response. Such validating resolvers SHOULD > include the DAU, DHU and/or the N3U option(s) in the OPT RR when > sending a query. This way thee validating stub resolver indicates ^^^^ the grtz Miek --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9wTaIACgkQJYuFzziA0PbX2QCdFpMbQf48YUSY5qolgT3rtNDN UK0An1e2teeDBY0WfPfok2qOKtIGs/Tu =vZPJ -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- --===============0039435149206819305== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============0039435149206819305==-- From dnsext-bounces@ietf.org Mon Mar 26 06:52:08 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7FA21F846A; Mon, 26 Mar 2012 06:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332769928; bh=K4hpKxDVc3CpurFy2Z/a62IuW5fMYgdbWiZWjV7JipA=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=LdnxmHuVTJI23XH74z/ZsoYwM/di+l38FUS26DFcZofQSWGYa6pes/ngftq+RZaqf vjzRsNNDTcx2Oq5ifoWPUAaKbPYZIHf0bUKF11V1mP9ZzXZ3UNpaNglRqMC4WV7n2y JpBoKwvYA2MemgUtPg6M4BjFegbFkjyZiyqUJCms= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3E121F8452; Mon, 26 Mar 2012 06:52:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id httoyMjZajfF; Mon, 26 Mar 2012 06:52:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62E621E8013; Mon, 26 Mar 2012 06:52:05 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326135205.13984.7755.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 06:52:05 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-05.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Signaling Cryptographic Algorithm Understanding in DNSSEC Author(s) : Steve Crocker Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-signal-05.txt Pages : 8 Date : 2012-03-26 The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms and hash algorithms they support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-05.txt _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Mar 26 07:14:59 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD3A21F8512; Mon, 26 Mar 2012 07:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332771298; bh=OqkwiJRaMC4o20Uc8djfHBxYQl1KOE6oje/up6Kfp3k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=aB+TiJsz/IMk1JKiAHY7NBvS1xiCgjtOo/QyL9NTuSiWjXtNLlWxlPoC+/njtXHTI k1CxrbsX09GyN6v9Zm9uD1NuQ53V6p9SjDE2auTq0dWX1/qfgbU/MbJ7qVSl68h3Kd fD90lZvbW5xIGN6+qG+lKdmnDlPBDwHYtz15IOFc= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B570121F8469 for ; Mon, 26 Mar 2012 07:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gpDMHVXZxhG for ; Mon, 26 Mar 2012 07:14:55 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64F2F21F8512 for ; Mon, 26 Mar 2012 07:14:55 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3841180qcs.31 for ; Mon, 26 Mar 2012 07:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=2t33DnTy9hVnmPBS5zJ6k+TdDXc8P2hlPCy1WFQAlaE=; b=iPWo2VZfx7E8Vy+ufrElu2OFjOXH+3ymQz3n6rdxU3shewySMMZd5LhB/4XkGP0JSU OAORw18oQk8lrnXrjk2Jj7a6J/B15QDeDkMCCSeo4mOvpyZxUNuHF2MgN9rduhRaYY50 LcW8avPtUPOat/j1MVsxylA6JY0TaOvh9KyM7b2CZ6w8ml5kQ8HA2X59ER3jETB3DNja qtOESvR2TA7TCjFGN/0A/cuQtuaofj4WbuGRxfNig7lOqRaTnUt5rz72IIQoYFpdJ48E IYicjlO1QMwpVS9Q9kbZX5RBx8ugYdcG+GQT18/fdHUxai6JD4c6kk59vIBA7CRc2ei6 OO7A== Received: by 10.224.98.3 with SMTP id o3mr27580832qan.62.1332771294945; Mon, 26 Mar 2012 07:14:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.92.71 with HTTP; Mon, 26 Mar 2012 07:14:33 -0700 (PDT) In-Reply-To: <18D7F4C6-544F-40CE-91EF-45C77E80AE5F@frobbit.se> References: <18D7F4C6-544F-40CE-91EF-45C77E80AE5F@frobbit.se> From: Dick Franks Date: Mon, 26 Mar 2012 15:14:33 +0100 X-Google-Sender-Auth: gXr0OLnjhdCbIKaIvjpRhp2xVh0 Message-ID: To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Cc: "" Subject: Re: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-05.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4992081234402294907==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============4992081234402294907== Content-Type: multipart/alternative; boundary=20cf3074d9e29a23f804bc25ff8e --20cf3074d9e29a23f804bc25ff8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Patrik, Editorial nits [1. para 4, line 7] revise wording ... determine when to stop signing with the old algorithm(s) when the server sees ... ... determine when to stop signing with a superseded algorithm when the server sees ... [1. para 5, last line] revise wording ... can signal a set of algorithms and hashes it implements. ... client query can signal the set of algorithms and hashes which it implements. [2. para 1, line 6] spelling independly independently [2. para 4] simplify wording LIST-LENGTH is the length of the list of digital signature or hash algorithms in octets. Since each algorithm and hash codes are 1 octet long so this value is the number of octets. LIST-LENGTH is the length of the list of digital signature or hash algorithm codes. Each algorithm code occupies a single octet. [2. para 5, line 3] revise wording ... that the client indicates as understood. ... that the client declares to be supported. [2. para 6, last line] delete redundant words ... in a reasonable potential future example. The reasonableness of the example is a matter of taste, flavoured by uncertain numbers. [3.1. line 3] simplify wording ... depends on whether the stub resolver performs its own DNSSEC validation or doesn't perform its own validation. ... depends on whether the stub resolver elects to perform its own DNSSEC validation. [3.2. line 5] key bounce This way thee validating ... [3.2. line 7] revise wording ... order of preference, with the most preferred algorithm(s) first ... ... order of preference, with the most preferred algorithm first ... This is describing the ordering direction of each (singular) list; first element is singular. [6. para 1, line 6] fix garbled wording This monitoring can be used to measure the deployment of client code that implements (and signals) certain algorithms. The Exactly how to capture DNS traffic and measure new algorithm adoption is beyond the scope of this document. This monitoring can be used to measure the deployment of client code that implements (and signals) specific algorithms. Description of the techniques used to capture DNS traffic and measure new algorithm adoption is beyond the scope of this document. [6. para 2, line 9] ... until a large majority of clients signal that they understand the new algorithm. ... until a large majority of clients signal that they recognise the new algorithm. --Dick 2012/3/26 Patrik F=C3=A4ltstr=C3=B6m > All, > > First of all, please note the version number I want you to (re-)read. It > is posted basically "now", but for the ones that want to check before it > ends up in the repository, I have also attached a copy. > > This version is, I think, answering all questions all individuals have ha= d > that I have managed to track. I have had private conversation with many o= f > you that had comments after version -02, and your comments have been pass= ed > to the editors. > > I already have enough individuals that have said they have read this draf= t > and support it to be able to forward it towards the IESG, so this WGLC on= ly > have as a goal to ensure there are no more issues. > > I would like to thank, among others, Miek Gieben, Mark Andrews, Marc > Lampo, Bill Manning, Warren Kumari, Ed Lewis and Dick Franks for the revi= ew > and suggested changes. > > Patrik > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > --20cf3074d9e29a23f804bc25ff8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Patrik,

Editorial nits


[1. para 4, line 7] revise wording= 
  ... determine when to stop signing with the old algorithm(s) whe=
n the server sees ...
=C2=A0=C2=A0 ... determine when to stop signing = with a superseded algorithm when the server sees ...


[1. para 5, last line] revise wording
  ... can signal a se=
t of algorithms and hashes it implements.
=C2=A0=C2=A0 ... client quer= y can signal the set of algorithms and hashes which it implements.

<= br>[2. para 1, line 6] spelling
   independly
=C2=A0=C2=A0=C2=A0 independently
[2. para 4] simplify wording
   LIST-LENGTH is the length of the l=
ist of digital signature or hash
   algorithms in octets.  Since each algorithm and hash codes are 1
   octet long so this value is the number of octets.

=C2=A0=C2=A0=
=C2=A0 LIST-LENGTH is the length of the list of digital signature or hash
   algorithm codes.
=C2=A0 =C2=A0 Each algorithm code occupies a single =
octet.

[2. para 5, line 3] revise wording
  ... t=
hat the client indicates as understood.
=C2=A0=C2=A0 ... that the clie=
nt declares to be supported.






[2. para 6, last line] delete redundant words

   ... in=
 a reasonable potential future example.

=C2=A0=C2=A0=C2=A0 The reasonableness of the example is a matter of t=
aste, flavoured by uncertain numbers.


[3.1. line 3] simplify wor=
ding
   ... depends on whether the stub resolver performs its own
   DNSSEC validation or doesn't perform its own validation.
=C2=A0=
=C2=A0=C2=A0 ... depends on whether the stub resolver elects to perform its=
 own
   DNSSEC validation.


[3.2. line 5] key bounce
   This w=
ay thee validating ...

[3.2. line 7] revise wording
   ...=
 order of preference, with the most preferred algorithm(s) first ...




=C2=A0=C2=A0=C2=A0 ... order of preference, with the most preferred algorit=
hm
   first ...

=C2=A0=C2=A0=C2=A0 This is describing the ordering dire=
ction of each (singular) list; first element is singular.


[6. pa=
ra 1, line 6] fix garbled wording
   This monitoring can be used to=
 measure the deployment of client code
   that implements (and signals) certain algorithms.  The Exactly how to
   capture DNS traffic and measure new algorithm adoption is beyond the
=
  =C2=A0scope of this document.

=C2=A0=C2=A0=C2=A0 This monitoring can be used to measure the deploym=
ent of client code
=C2=A0 =C2=A0 that implements (and signals) specific =
algorithms.  Description of the
=C2=A0=C2=A0=C2=A0 techniques used to
   capture DNS traffic and measure new algorithm
=C2=A0 =C2=A0 adoption =
is beyond the scope of this document.



[6. para 2, line 9]
   ... until a large majority of cl=
ients signal that they understand the new algorithm.
=C2=A0=C2=A0=C2=
=A0 ... until a large majority of clients
   signal that they recognise the new algorithm.



--Dick





2012/3/26 Patrik F=C3=A4ltstr=C3=B6m <paf@=
frobbit.se>




All,



First of all, please note the version number I want you to (re-)read. It is=
 posted basically "now", but for the ones that want to check befo=
re it ends up in the repository, I have also attached a copy.



This version is, I think, answering all questions all individuals have had =
that I have managed to track. I have had private conversation with many of =
you that had comments after version -02, and your comments have been passed=
 to the editors.







I already have enough individuals that have said they have read this draft =
and support it to be able to forward it towards the IESG, so this WGLC only=
 have as a goal to ensure there are no more issues.



I would like to thank, among others, Miek Gieben, Mark Andrews, Marc Lampo,=
 Bill Manning, Warren Kumari, Ed Lewis and Dick Franks for the review and s=
uggested changes.



 =C2=A0 =C2=A0Patrik




_______________________________________________

dnsext mailing list

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





--20cf3074d9e29a23f804bc25ff8e--

--===============4992081234402294907==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============4992081234402294907==--

From dnsext-bounces@ietf.org  Mon Mar 26 07:26:12 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EA421E80A1; Mon, 26 Mar 2012 07:26:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332771972; bh=0eJ50VpD3XvHaEwbALPuY3R8wnHb3sgs/kXBXuFlFM8=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=eazONqyHGFqo+Exl0vDGbndF0apgx4+qGdum1CJJu2IFoPKpet3WXXRG9gnnbHyqn xUFWBtQJXIAba+KO8PGD9nEMUzNYVyxfg9Qy8j9tjjVq9+dR6hzR+jk0T69+oAZ+nS R8XbBn3sHV7plRdnb6azG32mUIbqemnIxdjJ0FkM=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD4421E809B; Mon, 26 Mar 2012 07:26:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08CfuE1ynZQm; Mon, 26 Mar 2012 07:26:07 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F0921E8013; Mon, 26 Mar 2012 07:26:07 -0700 (PDT)
MIME-Version: 1.0
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120326142607.26742.59731.idtracker@ietfa.amsl.com>
Date: Mon, 26 Mar 2012 07:26:07 -0700
Cc: dnsext@ietf.org
Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-01.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

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

	Title           : Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status
	Author(s)       : Scott Rose
	Filename        : draft-ietf-dnsext-dnssec-algo-imp-status-01.txt
	Pages           : 6
	Date            : 2012-03-26

   The DNS Security Extensions (DNSSEC) requires the use of
   cryptographic algorithm suites for generating digital signatures over
   DNS data.  There is currently an IANA registry for these algorithms
   that is incomplete in that it lacks the recommended implementation
   status of each algorithm.  This document provides an applicability
   statement on algorithm implementation status for DNSSEC component
   software.  This document lists each algorithm's status based on the
   current reference.  In the case that an algorithm is specified
   without an implementation status, this document assigns one.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-status-01.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-status-01.txt

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

From dnsext-bounces@ietf.org  Mon Mar 26 07:33:20 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DF321E80AA; Mon, 26 Mar 2012 07:33:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332772400; bh=OYueiNUPo9HBfZ1izwDb+PiDnKoJY9Ii2pW6gkXagdg=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=tHD4SeogbmlQwS7bHgeCcb+56lw18j/7PduWKWktMw3MxRVIudvJRzxfIylAOyWAP iBW740KkYCgA4RuiFqFgKHwbKZpD/7JqP1SBR1djpdtgOo2tb5QYC9iUfu8RWuuM5J gpICEWM7MgEgr3IL16pip6T6SZ1cf5yoCQDY932s=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3E321E80AA for ; Mon, 26 Mar 2012 07:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdhKNs4o3Hik for ; Mon, 26 Mar 2012 07:33:17 -0700 (PDT)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2E51221E809C for ; Mon, 26 Mar 2012 07:33:16 -0700 (PDT)
Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q2QEX1R9001935 for ; Mon, 26 Mar 2012 10:33:01 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
From: Scott Rose 
In-Reply-To: <20120326142607.26742.59731.idtracker@ietfa.amsl.com>
Date: Mon, 26 Mar 2012 10:33:01 -0400
Message-Id: <8CC420BD-C5B6-4444-AC48-A0D127DE7B83@gmail.com>
References: <20120326142607.26742.59731.idtracker@ietfa.amsl.com>
To: DNSEXT Working Group 
X-Mailer: Apple Mail (2.1084)
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: scottr.nist@gmail.com
Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-01.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

This version addresses Sam Weiler's comments on the -00 version and adds the ECDSA algorithms.  If the group thinks any of the assigned implementation status for entries should be changed - please state so. Personally, I'm thinking ECDSA might be moved to "Recommended..." since there are some advantages, but willing to leave it as is.

Scott


On Mar 26, 2012, at 10:26 AM, Internet-Drafts@ietf.org wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF.
> 
> 	Title           : Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status
> 	Author(s)       : Scott Rose
> 	Filename        : draft-ietf-dnsext-dnssec-algo-imp-status-01.txt
> 	Pages           : 6
> 	Date            : 2012-03-26
> 
>   The DNS Security Extensions (DNSSEC) requires the use of
>   cryptographic algorithm suites for generating digital signatures over
>   DNS data.  There is currently an IANA registry for these algorithms
>   that is incomplete in that it lacks the recommended implementation
>   status of each algorithm.  This document provides an applicability
>   statement on algorithm implementation status for DNSSEC component
>   software.  This document lists each algorithm's status based on the
>   current reference.  In the case that an algorithm is specified
>   without an implementation status, this document assigns one.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-status-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-status-01.txt
> 
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext

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

From dnsext-bounces@ietf.org  Mon Mar 26 15:39:44 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C86D21E8012; Mon, 26 Mar 2012 15:39:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332801584; bh=iGb5wxWKNVNUJvbv/w91wDP9dpuaZHCHzkwkbxbIzU0=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=qUxi0V4k1wviwxT5vrjLdyHDjab5CjgkUtensv0nv97WyIlPGGxJii+3gpBUBn5DE 69IaiL+FR2h7uvu2IEOnbiZmJ5Ft7mJDJsjE9eyqubaqS7hakrNLaLuZOSQBCv/Xiu JiMbQ72/Y3gOULT3uiFXfkw7vcBGG8K/DjuNsi0E=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C222321E801F for ; Mon, 26 Mar 2012 15:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level: 
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[AWL=0.002,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do-JPRRJbQJj for ; Mon, 26 Mar 2012 15:29:24 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0F97E21E8020 for ; Mon, 26 Mar 2012 15:29:23 -0700 (PDT)
Received: by qaea16 with SMTP id a16so2500902qae.10 for ; Mon, 26 Mar 2012 15:29:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; bh=WBUsEPMpIpGVAODPdpa2JzWOJyUfSIsUwMkyFHjbNfI=; b=Yk7ybtCcVoIrnsYOLQsHm9ai6UxImpmke8NhI+3yiAOJ3yHhIpBFmRQa8Uw72qGE2h WXLEvBMBC8tG89iDNU4Z95Nx7yLZHYpW1vwDupV6s91I1y1cx6eyXS0Ijaf03hM9ZqJP vP/IrxSS4An1/E4lLFkH7noLuf5hqdxICAgLzmqGqf8UJ8xbk4/CM6uneb347L+GtzzY xc0wdka88FWNllHKouacuxa8WCaxgBDFiHPoHsQR4qPxM5t1pzG1PrLZ/5sKg7LCipCR X29bGkq2i8mUDDG9Np+7+wDlVwM0l11CBa39KuYzcjd9Cu0ZgN6L6J7eccA8rZiZYw2t 3mMg==
Received: by 10.229.137.18 with SMTP id u18mr6662966qct.87.1332800963460; Mon, 26 Mar 2012 15:29:23 -0700 (PDT)
Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id ha10sm32241638qab.14.2012.03.26.15.29.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Mar 2012 15:29:22 -0700 (PDT)
From: RJ Atkinson 
Date: Mon, 26 Mar 2012 18:29:20 -0400
To: dnsext@ietf.org
Message-Id: <4DE8BF39-7E68-4F10-BFBE-F4D408628929@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
X-Mailman-Approved-At: Mon, 26 Mar 2012 15:39:43 -0700
Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-01
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

On Monday, 26th March 2012, Scott Rose wrote, in part:
> If the group thinks any of the assigned implementation status
> for entries should be changed - please state so.
> 
> Personally, I'm thinking ECDSA might be moved to "Recommended..."
> since there are some advantages, but willing to leave it as is.

All,

I support the idea of moving ECDSA to "Recommended".

Most of us are likely to end up deploying ECDSA eventually,
we might as well encourage folks to support it sooner
rather than later.  An earlier start to implementation
enables earlier widespread interoperability, which in 
turn enables widespread deployment.  These things all
take time.  There is no value in delay.

* The financial sector already seems to be migrating 
  from RSA to EC for a wide range of things.  

* Separately, the published literature indicates that 
  MUCH shorter EC keys have strength equivalent to 
  MUCH longer RSA keys, so EC appears to scale better.[1][2]
  For example, [2] indicates that an ECC key size of
  163 bits has strength equivalent to an RSA key size
  of 1024 bits.

* Published literature also indicates that EC is less
  computationally expensive than RSA for equivalent-strength
  key sizes.  So EC is better for systems with smaller CPUs
  or that need to perform higher volumes of transactions.[3]

Yours,

Ran



REFERENCES:

[1] K. Lauter, "The Advantages of Elliptic Curve Cryptography for
    Wireless Security", IEEE Wireless Communications, Volume 11,
    Issue 1, IEEE, Piscataway, NJ, USA, February 2004.

[2] V. Gupta, et alia, "Performance Analysis of Elliptic Curve
    Cryptography for SSL", Proceedings of 1st ACM Workshop on
    Wireless Security, ACM, Atlanta, GA, September 2002.

[3] Nils Gura, et alia, "Comparing Elliptical Curve Cryptography
    and RSA on 8-bit CPUs", Proceedings of 6th International Workshop
    on Cryptographic Hardware and Embedded Systems '04, published in 
    Volume 3156, Lecture Notes in Computer Science, Springer-Verlag, 
    Berlin, DE, 2004.

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

From dnsext-bounces@ietf.org  Mon Mar 26 16:15:31 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0055421E8012; Mon, 26 Mar 2012 16:15:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332803731; bh=jjMcTnqrj86XZmBVxTHRoSMhrIzgD+j5cDDzpyRrV2A=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=d6jIRHMaG5nh/k8qj0jyYDhFL7Dda1Osi6tQmK11fEBvT61w49iA55ioBndQ/js8q PkSd72dGbjPJvDZQoDXvBR9QBB2czTxS4Vb408SgJLt46kjYX2NBnvp/GJZHmqXvzp Xu2rBhdDQMucDRSWLaGufwLsai6eGeq8rbkwesIw=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F7D21E8012 for ; Mon, 26 Mar 2012 16:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Level: 
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXHf0X7zes23 for ; Mon, 26 Mar 2012 16:15:29 -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 A9BF421E800C for ; Mon, 26 Mar 2012 16:15:29 -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 4A906C9422; Mon, 26 Mar 2012 23:15:16 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:352f:8a01:b8c3:b367]) (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 06C67216C31; Mon, 26 Mar 2012 23:15:16 +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 0A6761F0EA27; Tue, 27 Mar 2012 10:15:06 +1100 (EST)
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
From: Mark Andrews 
References: <18D7F4C6-544F-40CE-91EF-45C77E80AE5F@frobbit.se>
In-reply-to: Your message of "Mon, 26 Mar 2012 10:55:35 +0200." <18D7F4C6-544F-40CE-91EF-45C77E80AE5F@frobbit.se>
Date: Tue, 27 Mar 2012 10:15:06 +1100
Message-Id: <20120326231507.0A6761F0EA27@drugs.dv.isc.org>
Cc: "" 
Subject: Re: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-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: , 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

In message <18D7F4C6-544F-40CE-91EF-45C77E80AE5F@frobbit.se>, =?iso-8859-1?Q?Pa
trik_F=E4ltstr=F6m?= writes:
> All,
> 
> First of all, please note the version number I want you to (re-)read. It =
> is posted basically "now", but for the ones that want to check before it =
> ends up in the repository, I have also attached a copy.
> 
> This version is, I think, answering all questions all individuals have =
> had that I have managed to track. I have had private conversation with =
> many of you that had comments after version -02, and your comments have =
> been passed to the editors.
> 
> I already have enough individuals that have said they have read this =
> draft and support it to be able to forward it towards the IESG, so this =
> WGLC only have as a goal to ensure there are no more issues.
> 
> I would like to thank, among others, Miek Gieben, Mark Andrews, Marc =
> Lampo, Bill Manning, Warren Kumari, Ed Lewis and Dick Franks for the =
> review and suggested changes.
> 
>     Patrik

Patrik,
	The draft really should explictly state whether a server can
use this information to filter RRSIG records or not.  This need to be
a MAY or a MUST NOT.  As currently written I would say this needs to
be a MUST NOT.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Mon Mar 26 16:34:36 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C7C21F853A; Mon, 26 Mar 2012 16:34:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332804876; bh=klMrHB4KcbEHejLZ6nSXzbbQs6hrq12YWGuPESJC3+k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=zMTHRq1EnDFYWZK2xsiOsyuxHfgY67TX85OWqPDcb8mqPkXWwTUX1cGZ8Tm5w1v41 wulDegygrM/aOzyJYo4dGoLhkEvSBy+xtzjGdyD56xTF5qs900XdptNZz/iRoHlNmt 1+DN3kJNvSsGGEPG6qbg+uYIfj8zX1a9rqE9t+BA=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D61321E8018 for ; Mon, 26 Mar 2012 16:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.425
X-Spam-Level: 
X-Spam-Status: No, score=-104.425 tagged_above=-999 required=5 tests=[AWL=-0.826, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZpnNu6kHFlg for ; Mon, 26 Mar 2012 16:34:34 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5A921E8012 for ; Mon, 26 Mar 2012 16:34:33 -0700 (PDT)
Received: by lbol12 with SMTP id l12so4813441lbo.31 for ; Mon, 26 Mar 2012 16:34:30 -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 :content-type:content-transfer-encoding; bh=WdAbHR+b8apw2csq0hI1d1T3W+nfJgx3DV6IBEhaSfg=; b=aQKpulUnyWq3cfIHtk8yp63NwEerou5Dtaqslz7KH2kpJpboDjAToj4Zn70Bnrnb6i mF5Y2utIVM6Z7PtBqsV5hI9OhX3XfdUIj3ls9jqzqwUfyhdN3kryPT/feQWAsjQfrgKE uLtlNjQBed9JjTOo/i6vo+LS1i2TL8p9+olv+TQOrOdifn/qq6YjdMwjaove/0wymn9A +z4RsMXirwzEIfDg6RvyXvzOMEWP7iqT8FZlcU84iZowOiY4fSEZ1riZzZspvrnUwjiU 5h2WvKhFP2mxlA3X8qNE4fR0GOQIKqFCDrJjlLIBZUJv8JNehIghMN7shKO9qXFfy4LN iR+A==
Received: by 10.112.36.167 with SMTP id r7mr8888799lbj.32.1332804870119; Mon, 26 Mar 2012 16:34:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.21.162 with HTTP; Mon, 26 Mar 2012 16:34:09 -0700 (PDT)
In-Reply-To: <4DE8BF39-7E68-4F10-BFBE-F4D408628929@gmail.com>
References: <4DE8BF39-7E68-4F10-BFBE-F4D408628929@gmail.com>
From: Donald Eastlake 
Date: Mon, 26 Mar 2012 19:34:09 -0400
Message-ID: 
To: dnsext@ietf.org
Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-01
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

>From the very first days of DNSSEC, I've always thought the EC crypto,
with its more compact keys and signatures, was the way to go
eventually...

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

On Mon, Mar 26, 2012 at 6:29 PM, RJ Atkinson  wrote:
> On Monday, 26th March 2012, Scott Rose wrote, in part:
>> If the group thinks any of the assigned implementation status
>> for entries should be changed - please state so.
>>
>> Personally, I'm thinking ECDSA might be moved to "Recommended..."
>> since there are some advantages, but willing to leave it as is.
>
> All,
>
> I support the idea of moving ECDSA to "Recommended".
>
> Most of us are likely to end up deploying ECDSA eventually,
> we might as well encourage folks to support it sooner
> rather than later. =A0An earlier start to implementation
> enables earlier widespread interoperability, which in
> turn enables widespread deployment. =A0These things all
> take time. =A0There is no value in delay.
>
> * The financial sector already seems to be migrating
> =A0from RSA to EC for a wide range of things.
>
> * Separately, the published literature indicates that
> =A0MUCH shorter EC keys have strength equivalent to
> =A0MUCH longer RSA keys, so EC appears to scale better.[1][2]
> =A0For example, [2] indicates that an ECC key size of
> =A0163 bits has strength equivalent to an RSA key size
> =A0of 1024 bits.
>
> * Published literature also indicates that EC is less
> =A0computationally expensive than RSA for equivalent-strength
> =A0key sizes. =A0So EC is better for systems with smaller CPUs
> =A0or that need to perform higher volumes of transactions.[3]
>
> Yours,
>
> Ran
>
>
>
> REFERENCES:
>
> [1] K. Lauter, "The Advantages of Elliptic Curve Cryptography for
> =A0 =A0Wireless Security", IEEE Wireless Communications, Volume 11,
> =A0 =A0Issue 1, IEEE, Piscataway, NJ, USA, February 2004.
>
> [2] V. Gupta, et alia, "Performance Analysis of Elliptic Curve
> =A0 =A0Cryptography for SSL", Proceedings of 1st ACM Workshop on
> =A0 =A0Wireless Security, ACM, Atlanta, GA, September 2002.
>
> [3] Nils Gura, et alia, "Comparing Elliptical Curve Cryptography
> =A0 =A0and RSA on 8-bit CPUs", Proceedings of 6th International Workshop
> =A0 =A0on Cryptographic Hardware and Embedded Systems '04, published in
> =A0 =A0Volume 3156, Lecture Notes in Computer Science, Springer-Verlag,
> =A0 =A0Berlin, DE, 2004.
>
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Tue Mar 27 00:32:11 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F05A21F853D; Tue, 27 Mar 2012 00:32:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332833531; bh=MAEhG/KzP8+7AGtSaLEek8Z5s4oCbyRgr46t0BO1DlE=; h=From:Message-Id:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ypr/NnjuLpu1HbzaXAvTX6+ZHLrp46fmi4fhbyi17IaEECg0SAV89pVop7BZ4CZpr mccLv1VL6Mqg+2NlbmF9sb7BxoHFfPOzcXHwNJiz1no4EDla2rtHsz4EerxSRGMqlq z1+mvGwpypzw8z56bMRNxHZJdv3L814tONY2jzVA=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44ED021F8510 for ; Tue, 27 Mar 2012 00:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.63
X-Spam-Level: 
X-Spam-Status: No, score=-98.63 tagged_above=-999 required=5 tests=[AWL=0.119,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILwCb9zTRGET for ; Tue, 27 Mar 2012 00:32:08 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1750921F849C for ; Tue, 27 Mar 2012 00:32:06 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA267593440; Tue, 27 Mar 2012 09:30:40 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id JAA01332; Tue, 27 Mar 2012 09:30:38 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= 
Message-Id: <201203270730.JAA01332@TR-Sys.de>
To: dnsext@ietf.org
Date: Tue, 27 Mar 2012 09:30:38 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Subject: [dnsext] rfc1995bis-ixfr draft is being posted as a WG -00 draft
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Olafur has notified the authors that
        draft-ah-dnsext-rfc1995bis-ixfr-03
has been adopted as a WG draft and called for quick resubmission
as such.

This just has been done;  draft-ietf-dnsext-rfc1995bis-ixfr-00
has been uploaded and will be available soon in the usual
repositories (at the time of writing it's still awaiting
completion of the formal steps).


The only changes since the individual -03 draft version are as follows:

* Front and Back matter:

- change of draft name and dates;
- Shane Kerr now "officially" listed as an author;

* Appendix C:

- headline of modified to clarify relationship to individual draft
  predecessor,
- added a new (temporal) first paragraph for the record:

-------- begin excerpt --------

 Appendix C.  Evaluation of List Discussion, Draft Changes since
|            Individual Draft -02

   [[ Temporary Section, to be deleted in next draft version. ]]
|
|  On Chair request, draft-ah-dnsext-rfc1995bis-ixfr-03 re-posted as
|  draft-ietf-dnsext-rfc1995bis-ixfr-00 without textual changes, but
|  Shane Kerr now listed as an Author.  Recent list dicussion will be
|  reflected in -01 version due soon after IETF 83.  The paragraphs
|  below describe the changes in indiviual draft -02 to -03 and have
|  been kept unchanged for this initial WG draft version.

-------- end excerpt --------


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+

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

From dnsext-bounces@ietf.org  Tue Mar 27 01:07:15 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B2521F866B; Tue, 27 Mar 2012 01:07:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332835635; bh=Bp2b067HBSbH2JOKtRds+nR1jFtqk63N9u1MbFQaU9E=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=h6A/GC6+OTAyW9iyTYlVt1Swfq/u4I0Izv9EJJMSSmtEkyDQgtGBrXXx3Ho8YYMj3 7wP82H42tFVf/Fkx5FOLxh+9bgX2RN3nITXMVeLai+Lh0KzCnhdLPcCdKn0VfLCWje mx+EjI7HdI68KARadsZ8ABujkCvb6KxbtTfuyYRo=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2092821F8665; Tue, 27 Mar 2012 01:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.441
X-Spam-Level: 
X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5c-UXAjgKru; Tue, 27 Mar 2012 01:07:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8603A21F8652; Tue, 27 Mar 2012 01:07:11 -0700 (PDT)
MIME-Version: 1.0
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120327080711.16297.49879.idtracker@ietfa.amsl.com>
Date: Tue, 27 Mar 2012 01:07:11 -0700
Cc: dnsext@ietf.org
Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc1995bis-ixfr-00.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

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

	Title           : DNS Incremental Zone Transfer Protocol (IXFR)
	Author(s)       : Alfred Hoenes
                          Ondrej Sury
                          Shane Kerr
	Filename        : draft-ietf-dnsext-rfc1995bis-ixfr-00.txt
	Pages           : 32
	Date            : 2012-03-27

   The standard means within the Domain Name System protocol for
   maintaining coherence among a zone's authoritative name servers
   consists of three mechanisms.  Incremental Zone Transfer (IXFR) is
   one of the mechanisms and originally was defined in RFC 1995.

   This document aims to provide a more detailed and up-to-date
   specification of the IXFR mechanism and to align it with the current
   specification of the primary zone transfer mechanism, AXFR, given in
   RFC 5936.  Further, based on operational experience, this document
   juxtaposes to the original IXFR query a new query type, IXFR-ONLY,
   that will likely be preferred over IXFR in specific deployments.

   This document obsoletes and replaces RFC 1995.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1995bis-ixfr-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1995bis-ixfr-00.txt

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

From dnsext-bounces@ietf.org  Tue Mar 27 01:30:08 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2642521F88B3; Tue, 27 Mar 2012 01:30:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332837008; bh=ToJ52k66uzeSY7TW06aQM13cfLPA+eXXg5uNZyEY1eU=; h=From:To:Date:Message-ID:References:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=o+Ys10+Gfo06xdYygqNVd3aNV9CZj4oXvJzaHswaOqYwmdI/skIL2fch274vWpT7J Q2QCYhQpv4Ei29mTFdwuJldIEeGoRYKsZkT8hIGVsavOQYZl6/6S4yQyELVZ1Ohi+a qCakwVh5c0x9bcM7QQ00a4Q6ABpsG0EI2sm++mzQ=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139BC21F88BB for ; Tue, 27 Mar 2012 01:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.347
X-Spam-Level: 
X-Spam-Status: No, score=-10.347 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geczvSkte89w for ; Tue, 27 Mar 2012 01:29:52 -0700 (PDT)
Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4B921F88B4 for ; Tue, 27 Mar 2012 01:29:39 -0700 (PDT)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:Content-Type:MIME-Version; b=r6mN3s2v/fRTmsLeldROpmeSsqh6monLWyRzhIomGDFN3/bM0dmA78eA 5ZrT68dAIfkOu3Cx6ARdagtWppsQBCEesTM+jjcDen9Y0hrTchFCvF8TJ 6LZynlP9kvDoYUM;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1332836985; x=1364372985; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Fwd:=20New=20Version=20Notification=20for=0D =0A=20draft-bellis-dnsext-multi-qtypes-01.txt|Date:=20Tue ,=2027=20Mar=202012=2008:29:36=20+0000|Message-ID:=20|To:=20D NSEXT=20Working=20Group=20|MIME-Version: =201.0|References:=20<20120327082614.22953.96097.idtracke r@ietfa.amsl.com>; bh=s7v0y1HVFeNAumeMUIDJDrj/eCwoHDoFD0jEV68J91g=; b=nsc2lw9J0us5Ph7Y2OIOhWbzWt1TuQYWlGJFQ7izAwf5vX63qr1HACWx TV1JKNBrwt6QzBqOyh4dymVdQivU2N81J5fidN6Dq4TQRKUrezlDMF0on Orlvlr7vv0wfNFP;
X-IronPort-AV: E=Sophos;i="4.75,325,1330905600"; d="scan'208,217";a="32204211"
Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 27 Mar 2012 09:29:35 +0100
Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Tue, 27 Mar 2012 09:29:35 +0100
From: Ray Bellis 
To: DNSEXT Working Group 
Thread-Topic: New Version Notification for draft-bellis-dnsext-multi-qtypes-01.txt
Thread-Index: AQHNC/NIpg6YLQCKSECuij00XoGXfg==
Date: Tue, 27 Mar 2012 08:29:36 +0000
Message-ID: 
References: <20120327082614.22953.96097.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
Subject: [dnsext] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-01.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============7995592606981283437=="
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

--===============7995592606981283437==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_DD6C7261806F4F338CF3D9A16FBD4B8Cnominetorguk_"

--_000_DD6C7261806F4F338CF3D9A16FBD4B8Cnominetorguk_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


A new version of I-D, draft-bellis-dnsext-multi-qtypes-01.txt has been succ=
essfully submitted by Ray Bellis and posted to the IETF repository.

Filename: draft-bellis-dnsext-multi-qtypes
Revision: 01
Title: Title
Creation date: 2012-03-27
WG ID: Individual Submission
Number of pages: 7

Abstract:
  This document specifies a method for a DNS client to request
  additional DNS record types to be delivered alongside the primary
  record type specified in the question section of a DNS query.

Following discussions on this topic on the DNSOP list a couple of weeks ago=
 I decided I ought to post this previously unsubmitted draft for the record=
.

https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/

There was (very briefly) a -00 of this posted this morning but I realised I=
 had an incorrect reference in it.

Ray


--_000_DD6C7261806F4F338CF3D9A16FBD4B8Cnominetorguk_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable




A new version of I-D, draft-bellis-dnsext-multi-qtypes-01.txt has been s=
uccessfully submitted by Ray Bellis and posted to the IETF repository.
<=
br>Filename:	 draft-bellis-dnsext-multi-qtypes
Revision:	 01
Title:		 Title
Creation date:	 2012-03-27
WG ID:		 Individual Submission
Num=
ber of pages: 7

Abstract:
   This document specifies a =
method for a DNS client to request
   additional DNS record ty=
pes to be delivered alongside the primary
   record type speci=
fied in the question section of a DNS query.

Following discussions on this topic on the DNSOP list a c=
ouple of weeks ago I decided I ought to post this previously unsubmitted dr=
aft for the record.

https://datatracker.ietf.org/do=
c/draft-bellis-dnsext-multi-qtypes/

There was (very briefl=
y) a -00 of this posted this morning but I realised I had an incorrect refe=
rence in it.

Ray

=
=

--_000_DD6C7261806F4F338CF3D9A16FBD4B8Cnominetorguk_--

--===============7995592606981283437==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============7995592606981283437==--

From dnsext-bounces@ietf.org  Tue Mar 27 01:47:33 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABBD21F882F; Tue, 27 Mar 2012 01:47:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332838053; bh=eSVKtyzZDSycAWzp9Ca++KFUHd75kyYamauTwE4Qm1E=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=cMZUOZE9f8uZIMGYCU8PGo+XgYVZxugEi0RWygEDaXKI4Kj8ims0fGsQ+81+/Rvpb 68DUwzxzOgXQJpQMFTaSFxpxw7+oUkD80oy2+FiOa8KYyZGqfeN8IgOOW2v8B5vvau T2Er3Mjp75jBjAYghfctb1DneqbI1tJe/DhbUIEQ=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1D321F886F; Tue, 27 Mar 2012 01:47:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2NOGVn6Rugc; Tue, 27 Mar 2012 01:47:31 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2702C21F87FA; Tue, 27 Mar 2012 01:47:31 -0700 (PDT)
MIME-Version: 1.0
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120327084731.30282.35216.idtracker@ietfa.amsl.com>
Date: Tue, 27 Mar 2012 01:47:31 -0700
Cc: dnsext@ietf.org
Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-00.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

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

	Title           : Domain Name System (DNS) IANA Considerations
	Author(s)       : Donald E. Eastlake
	Filename        : draft-ietf-dnsext-rfc6195bis-00.txt
	Pages           : 19
	Date            : 2012-03-27

   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.




A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc6195bis-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc6195bis-00.txt

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

From dnsext-bounces@ietf.org  Tue Mar 27 04:29:30 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E732421E8186; Tue, 27 Mar 2012 04:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332847770; bh=aSvMw+7tUPL7DXdfdGCowY5VlFNr7HnoOeaFYLHafGI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=fTtuWHhlf9SMrtauyu9yRwZlDLSK3+hBvgFQtj52q5ikhxdLAipPfpAFciyZUZYLo 7ie47pafXVWkKkVosUmZjtKUw80fl2a2Jy919m4NzbrZUM80GE0Iz2+Nh6PeMBmYZx p+MXnbsZpokomN2n6lk1M+g2T8TJxQTGo8H4W1t4=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC2121E8167 for ; Tue, 27 Mar 2012 04:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.826
X-Spam-Level: 
X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOIcOyCzvlXb for ; Tue, 27 Mar 2012 04:29:27 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E95A21E817C for ; Tue, 27 Mar 2012 04:29:27 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so4542143qcs.31 for ; Tue, 27 Mar 2012 04:29:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=QILDMqax1nrHtQec5rc3GgKQm7n01zyqA1o+Q3wePlU=; b=WDGUSH5/DggKifr7czJlsrLH/6SRz5jWRLzLgFhKI4F2HkMBTyJcffO/EXN1lYrKz5 bcGyyO8YXud9/5TnGVP6yOwzlexBSeY4CwLGWay4+WyhXop1lLc6WXDh8EsPdj2xLiFn 7hDMfkdI8dmEgeaqtxKIrT+d87nFBZmLaaBu/SMgUoGEOM2RpaqUXbpjAWr7Am0xASOx Mg8deDuOOfRF20I/UfPb0QDMvQP/K/j1GF1rLDTLGYLenaGf0lrMUVzBOM4v/zoYBsBr gzrT5mdzdcw9IdlJ2S7te0BtqNEJNPXSvjr8Vk3zVMAfmsdFfBRCdSmZZ3KeYzHN3stM xe6A==
Received: by 10.224.98.3 with SMTP id o3mr31907271qan.62.1332847766731; Tue, 27 Mar 2012 04:29:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.92.71 with HTTP; Tue, 27 Mar 2012 04:29:06 -0700 (PDT)
In-Reply-To: 
References: <20120327082614.22953.96097.idtracker@ietfa.amsl.com> 
From: Dick Franks 
Date: Tue, 27 Mar 2012 12:29:06 +0100
X-Google-Sender-Auth: CprSKipGhQOlk-4nFfT9D-076sc
Message-ID: 
To: Ray Bellis 
Cc: DNSEXT Working Group 
Subject: Re: [dnsext] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-01.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============4955857394165421467=="
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

--===============4955857394165421467==
Content-Type: multipart/alternative; boundary=20cf3074d9e2acfab204bc37cd83

--20cf3074d9e2acfab204bc37cd83
Content-Type: text/plain; charset=UTF-8

Ray,

IMHO data format is horribly overcomplicated.


[3.1] redundant OPTION-DATA content


 OPTION-DATA: Option specific, as below:

                    +0 (MSB)                            +1 (LSB)
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: |QTD|   reserved    |  QTCOUNT  |           QT1 (MSB)           |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    2: |           QT1 (LSB)           |              ...              |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |              ...             ///          QTn (MSB)           |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |           QTn (LSB)           |
       +---+---+---+---+---+---+---+---+

   QTD: this bit indicates the direction of the packet.  It MUST be
   clear (0) in a query and set (1) in a response.


Redundant: packet direction determined by QR flag in packet header.


   QTCOUNT: a 3 bit field with range 0 .. 7 specifying the number of QT
   fields to follow.

Redundant: easily calculated from OPTION-LENGTH.


OPTION-DATA then becomes:

 OPTION-DATA: Option specific, as below:

                    +0 (MSB)                            +1 (LSB)
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: |                             QTYPE1                            |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |                              ...
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |                             QTYPEn                            |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   QTYPEn: a 2 octet field specifying a DNS RR type.  The RR type MUST
   be for a real resource record, and MUST NOT refer to a pseudo RR type
   such as "OPT", "IXFR", "TSIG", etc.




--Dick



On 27 March 2012 09:29, Ray Bellis  wrote:

>
> A new version of I-D, draft-bellis-dnsext-multi-qtypes-01.txt has been
> successfully submitted by Ray Bellis and posted to the IETF repository.
>
> Filename: draft-bellis-dnsext-multi-qtypes
> Revision: 01
> Title:  Title
> Creation date: 2012-03-27
> WG ID:  Individual Submission
> Number of pages: 7
>
> Abstract:
>   This document specifies a method for a DNS client to request
>   additional DNS record types to be delivered alongside the primary
>   record type specified in the question section of a DNS query.
>
>
> Following discussions on this topic on the DNSOP list a couple of weeks
> ago I decided I ought to post this previously unsubmitted draft for the
> record.
>
> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
>
> There was (very briefly) a -00 of this posted this morning but I realised
> I had an incorrect reference in it.
>
> Ray
>
>
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
>
>

--20cf3074d9e2acfab204bc37cd83
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Ray,

IMHO data format is horribly overcomplicated.


[=
3.1] redundant OPTION-DATA content


 OPTION-DATA: Option specific=
, as below:

                    +0 (MSB)                            +1 (LSB)
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: |QTD|   reserved    |  QTCOUNT  |           QT1 (MSB)           |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    2: |           QT1 (LSB)           |              ...              |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |              ...             ///          QTn (MSB)           |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |           QTn (LSB)           |
       +---+---+---+---+---+---+---+---+

   QTD: this bit indicates the direction of the packet.  It MUST be
   clear (0) in a query and set (1) in a response.
   
Redundant: packet direction determined by QR flag in packet he=
ader.
=C2=A0
   QTCOUNT: a 3 bit field with range 0 .. 7 specify=
ing the number of QT
   fields to follow.

Redundant: easily calculated from OPTION-LENGTH.


OPTION-DA=
TA then becomes:

 OPTION-DATA: Option specific, as below:

                    +0 (MSB)                            +1 (LSB)
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: |                             QTYPE1                            |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |                              ...
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |                             QTYPEn                            |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   QTYPEn: a 2 octet field specifying a DNS RR type.  The RR type MUST<=
br>  =C2=A0be for a real resource record, and MUST NOT refer to a pseudo RR=
 type
  =C2=A0such as "OPT", "IXFR", "TSIG"=
;, etc.






--Dick





On 27 March 2012 09:29, Ray Bellis <Ray.Bellis@nominet.org.uk> wrote:






A new version of I-D, draft-bellis-dnsext-multi-qtypes-01.txt has been suc=
cessfully submitted by Ray Bellis and posted to the IETF repository.



Filename:	 draft-bellis-dnsext-=
multi-qtypes
Revision:	 01Title:		 Title



Creation date:	 2012-03-27
W=
G ID:		 Individual Submission
Number of pages: 7

Abs=
tract:



 =C2=A0=C2=A0This document specifies a method for a DNS client to request =C2=A0=C2=A0additional DNS record types to be delivered alongside the pr=
imary
 =C2=A0=C2=A0record type specified in the question section of a DN=
S query.





Following discussions on this topic on the DNSOP =
list a couple of weeks ago I decided I ought to post this previously unsubm=
itted draft for the record.

https=
://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/




There was (very briefly) a -00 of this posted this morning but I r=
ealised I had an incorrect reference in it.

Ray



_______________________________________________

dnsext mailing list

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





--20cf3074d9e2acfab204bc37cd83--

--===============4955857394165421467==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============4955857394165421467==--

From dnsext-bounces@ietf.org  Tue Mar 27 04:51:51 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0303F21F898C; Tue, 27 Mar 2012 04:51:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332849111; bh=GD5kv/Ri3RrSlxh/T1tGYXaHHfIuz6fSsU0Om781sOk=; h=From:To:Date:Message-ID:References:In-Reply-To:Content-ID: MIME-Version:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type: Content-Transfer-Encoding:Sender; b=jLiVjmlrpfFpGnjzO57RoTI4mRrK55Arj+o4PEHBG/jkU6D6oGuinEl1PWeM6Sd1p ydKRbVUqqEjXT9LSJITWK/5ELS5+SbLQw8CRW5iql5FSJjlTU7tIcp2BnAuqhu6M/7 MvMA1OvWsWS9SHGae6ZJTgX+zp0RrmXjd5NR6ctU=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC4721E809C for ; Tue, 27 Mar 2012 04:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.367
X-Spam-Level: 
X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD8spLX9jYqq for ; Tue, 27 Mar 2012 04:51:48 -0700 (PDT)
Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id B79EB21F898B for ; Tue, 27 Mar 2012 04:51:47 -0700 (PDT)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns;  h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=XBpNq+PUM9ELBTtGJ30OtJaiq7OegteudybpKTNAsx5TLsRamyZCV6yb r/obn04tzBDKiJk5ra5ToGRX2i2q1Fai+/Go6V/wRy/5yp+TLOnGAvy3x eQ1HhaE9CUPQCtD;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1332849107; x=1364385107; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[dnsext]=20Fwd:=20New=20Version=20Notif ication=20for=0D=0A=20draft-bellis-dnsext-multi-qtypes-01 .txt|Date:=20Tue,=2027=20Mar=202012=2011:51:47=20+0000 |Message-ID:=20|To:=20Dick=20Franks=20|CC: =20DNSEXT=20Working=20Group=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<8ebdd17b-82fe-4270-af85-4078e647 447e>|In-Reply-To:=20|References:=20<201203270 82614.22953.96097.idtracker@ietfa.amsl.com>=0D=0A=20=0D=0A=20 ; bh=BAWqAha2o1CatQJOnlBx/4vvAnKO/R9JFxC0kumytTk=; b=NUw5PEvsGTkxqoXrJ2WkeTNXBgeGz9o96Lx26AG5f4KHh5P6O1jqhQBr 3i3Onl4nNIqSYbaz+Y9eJaUYmOEY52JQZJJky5oEmZ2/zWaG1rvS9OtGo WDnV8IbT0Zh6cZs;
X-IronPort-AV: E=Sophos;i="4.75,325,1330905600"; d="scan'208";a="39349772"
Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx3.nominet.org.uk with ESMTP; 27 Mar 2012 12:51:46 +0100
Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Tue, 27 Mar 2012 12:51:46 +0100
From: Ray Bellis 
To: Dick Franks 
Thread-Topic: [dnsext] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-01.txt
Thread-Index: AQHNDAzec1LrRGUoBUOhT/oyBZ3oR5Z99xyA
Date: Tue, 27 Mar 2012 11:51:47 +0000
Message-ID: 
References: <20120327082614.22953.96097.idtracker@ietfa.amsl.com>  
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-ID: <8ebdd17b-82fe-4270-af85-4078e647447e>
MIME-Version: 1.0
Cc: DNSEXT Working Group 
Subject: Re: [dnsext] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-01.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

On 27 Mar 2012, at 13:29, Dick Franks wrote:

> Ray,
> 
> IMHO data format is horribly overcomplicated.
> 
> 
> [3.1] redundant OPTION-DATA content
> Redundant: packet direction determined by QR flag in packet header.

Not at all, per the text the intention of the QTD bit is to distinguish between a server which correctly parsed the option, and one that simply echoed it.
 
>    QTCOUNT: a 3 bit field with range 0 .. 7 specifying the number of QT
>    fields to follow.
> Redundant: easily calculated from OPTION-LENGTH.

That may be fair - it's a year since I wrote the draft so I need to recall what the rationale was for not relying on the OPTION LENGTH.

kind regards,

Ray

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

From dnsext-bounces@ietf.org  Tue Mar 27 04:58:49 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFC521F8870; Tue, 27 Mar 2012 04:58:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332849527; bh=4qdL58MEMUrZK3CqZj+lgYiLhw0dZbxGRkUaYadfPng=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=D0/wO7BNxD2MvTexY/PKzkr+ky5To+OMDn6bBUDIcT/rIMbOYBvrjtNQDxcyqOqKc h4KLDVDitMh8D67N8sMbFxgBGI39xVThUmFaq8EWYNwP2hx+xFT8WzDHBAelynSV/S wx+Jz6PODnLlhC+J1mjAFFSaYutFGtvPnQFuEk34=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0123821F89CA for ; Tue, 27 Mar 2012 04:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.519
X-Spam-Level: 
X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_20=-0.74]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9194-78Zy1kF for ; Tue, 27 Mar 2012 04:58:41 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3AA21F8870 for ; Tue, 27 Mar 2012 04:58:41 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id C87882C404B; Tue, 27 Mar 2012 04:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZwOZHluB+EpA; Tue, 27 Mar 2012 04:58:40 -0700 (PDT)
Received: from [10.0.1.7] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 5B0972C4046; Tue, 27 Mar 2012 04:58:40 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
From: Nicholas Weaver 
In-Reply-To: 
Date: Tue, 27 Mar 2012 04:58:38 -0700
Message-Id: <12F4D2BD-644B-435A-9C61-DB091B5548F4@icsi.berkeley.edu>
References: <20120327082614.22953.96097.idtracker@ietfa.amsl.com>  
To: DNSEXT Working Group 
X-Mailer: Apple Mail (2.1257)
Subject: Re: [dnsext] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-01.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

I think this is a bad idea:  


There are two kinds of secondary resource records: ones that can be asked in parallel (e.g. A and AAAA records associated with the same name), and ones that are sequentialized (e.g. the A and AAAA records corresponding to MX entries).

As far as I can tell, this draft only addresses the former, not the latter, as for the latter the client doesn't know yet which question to ASK, so it can't construct a multiple question query.


And in the former case, the efficiency savings are actually negative:  It imposes a needless sequentialization on what was previously a parallel activity of asking both questions separately.  

If the server has one record in the cache but not the other, it will have to wait until it has the other record.  This slows "happy eyeballs" approaches where A and AAAA records are looked up simultaneously, and then the contacts also proceed in parallel.

So this approach can NEVER be faster for the server to compute, only equal time or slower, thus the only speedups can occur if this made communication substantially smaller.


But it doesn't.  You only save the packet framing one one question and one response per additional RTYPE queried, which is, in practice, roughly 200B of traffic when one includes ALL overhead (including interframe gaps, ethernet framing and minimum packet sizes).  On a slow 1 Mbps home connection, this still represents ONLY a 1.6 ms savings.


The only case where this would have more than a 10ms savings is on a <200 Kbps link, and such a link is so slow that nobody will care about the savings because everything else is so glacial, and such links are likely to not be querying for AAAA records anyway (the most common case)



Thus I think this proposal is a bad idea:  It adds a substantial amount of complexity for something that can substantially slow things down by removing parallelization, and even when everything works right, is only 1.6ms of savings on a 1 Mbps link (and .16ms savings on a 10 Mbps link).

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

From dnsext-bounces@ietf.org  Tue Mar 27 07:03:47 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976F721E81ED; Tue, 27 Mar 2012 07:03:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332857027; bh=qX1H7ZNbRPoaygWYYtmUGWbvAKWnHjGdEqFOiD7prMk=; h=From:Message-Id:To:Date:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=X0tsLizTlRKE1LzY6mgTZpk4C7XAsi8OayyZEi5Vc+/cxoOvIsOOmbvcSfuXEAq1x YAqJMCIRWDBXPako8+EBhiRSsD3ER+u7sCyGxxrOfHHIcsSSQ70GwlDUBe8mfMghTJ bThcoTMkNiQT8XBBp45dGyoENok9Og8thOP0k0hg=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E41121E81DA for ; Tue, 27 Mar 2012 07:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.633
X-Spam-Level: 
X-Spam-Status: No, score=-98.633 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AcUYSwWb9ZC for ; Tue, 27 Mar 2012 07:03:45 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF3F21E81CD for ; Tue, 27 Mar 2012 07:03:44 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA269916954; Tue, 27 Mar 2012 16:02:34 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA03645; Tue, 27 Mar 2012 16:02:33 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= 
Message-Id: <201203271402.QAA03645@TR-Sys.de>
To: steve@shinkuro.com, scottr.nist@gmail.com
Date: Tue, 27 Mar 2012 16:02:32 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Cc: dnsext@ietf.org
Subject: Re: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-05
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

A have a few more, mostly editorial comments on
          draft-ietf-dnsext-dnssec-algo-signal-05
(trying to avoid duplicates of items already mentioned this week
in review comments on the list):


1)  General Terminology  (mostly in Section 1), and some nits

* Sect. 1, 2nd para:

"DS" should be spelled out "Delegation Signer", not "Delegated Signer"
-- cf. RFC 3034, sect. 2, "Definition of DNSSEC Terms").
Also, a comma should be placed in front of "like" in that para.

* Sect. 1, 3rd para:

The draft should not say "EDNS attribute" in one place, always more
precisely "EDNS option" (see snippet below).

* Sect. 1, 3rd para, and Sect. 8, 2nd line:

The hashes used in DNSSEC are cryptographic functions/algorithms as
well. Using "cryptographic algorithm" in some places as a substitute
for "[cryptographic|digital] signature algorithm" seems confusing.
This should be fixed.

Additionally, for enhanced clarity, I suggest to shuffle the words
a bit and improve the language in the 3rd para of Section 1:

OLD:
   This draft sets out to specify a way for validating end-system
   resolvers to tell a server which cryptographic and/or hash algorithms
   they support in a DNS query.  This is done using the EDNS attribute
   values in the OPT meta-RR [RFC2671].

NEW:
   This draft sets out to specify a way for validating end-system
   resolvers to tell a server in a DNS query which digital signature
   and/or hash algorithms they support.  This is done using the new
   EDNS options specified below in Section 2 for use in the OPT meta-RR
   [RFC2671].


2)  "EDNS" vs. "EDNS0"

The EDNS framework is designed to allow expansion while maintaining
backward compatibility, and one method to achieve this is based on
the versioning rules from RFC 2671[bis].  Therefore, we should better
avoid referring specifically to "EDNS0" or "EDNS(0)" when mentioning
facts that are expected to remain strictly unchanged in future EDNS
versions (however unlikely their occurrence may seem now).

In particular, I suggest to  s/EDNS0/EDNS/  twice in the 1st para
of Sect. 2, once in the 2nd para of Sect. 6, and once in Sect. 8.


3)  error in example ??

In the last para of Section 2, the byte counts given apparently
do not match the other information.  I suspect the figures have
inadvertently not been updated upon the change in the EDNS option
structure the draft has undergone.
IMHO, "16-24 octets" should read "24-34 octets":

OLD:

   However, in practical terms including all three options are likely to
|  take up 16-24 octets (average of 6-10 digital signature algorithms,
           ^^^^^
   3-5 DS hash algorithms and 1-5 NSEC3 hash algorithms) including the
   EDNS option codes and option lengths in a reasonable potential future
   example.

NEW:
                              v                             vv
|  However, in practical terms, including all three options is likely to
|  take up 24-34 octets (average of 6-10 digital signature algorithms,
           ^^^^^
   3-5 DS hash algorithms and 1-5 NSEC3 hash algorithms) including the
   EDNS option codes and option lengths in a reasonable potential future
   example.

(Note that "including" acts as the subject in this sentence, so the
verb "are" needs to be in singular form, "is"; I also added a comma.)

The lower bound (22) corresponds to the lower counts mentioned,
and the upper bound to the upper counts each:

-  fixed overhead for DAU:    4 octets  \
-  code list for DAU:      6-10 octets  / 10-16 octets
-  fixed overhead for DHU:    4 octets  \
-  code list for DHU:       3-5 octets  /  7-9  octets
-  fixed overhead for N3U:    4 octets  \
-  code list for N3U:       3-5 octets  /  7-9  octets
++++++++++++++++++++++++++++++++++++++++++++++++++++++
total:                                    24-34 octets


4)  typo in Sect. 3, 2nd para

OLD:

   Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital
|  signature codes for cover a potentially wide range of algorithms and
                   ^^^
   are likely not useful to a server.  [...]

NEW:

   Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital
|  signature codes both cover a potentially wide range of algorithms and
                   ^^^^
   are likely not useful to a server.  [...]


5)  Section structure

The current sections 3.2 and 3.3 are, from a logical/semantical
perspective, subordinate to the current Section 3.1 in the same
way as Sections 3.4.1 and 3.4.2 are subordinate to Section 3.4.
I suggest to restructure s3.1-3.3 and renumber the rest of s3:

    3.2    -->  3.1.1
    3.3    -->  3.1.2
    3.4    -->  3.2
    3.4.1  -->  3.2.1
    3.4.2  -->  3.2.2


6)  Reference update

The revised EDNS0 specification is ahead in the IESG, therefore I
suggest to update the citations to RFC 2671 toward the 'bis' document.


Best regards,
  Alfred.

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

From dnsext-bounces@ietf.org  Tue Mar 27 09:32:08 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D352A21F842A; Tue, 27 Mar 2012 09:32:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332865927; bh=EYUAt+ey1MMo2L+WjEE1BPKGQA0MZeRPHbkUYGRdy3w=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=k8MkBajIbQ5mM2H5Epxmscm8Xl/ltpUwiNZOPjFCC/oOuwdxchrGlRM9SN+Um+jbs ZvMhKAGwkH9gYfjo+hBf+pVUp2DI6gfwq7BtuA7iXolTYgRer/+zp6ohDq2F1iQiNc a4QG/x/f/pXr/dQkkEbKzmMR3pyWaHNgeTz6HX0s=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486F221F8546 for ; Tue, 27 Mar 2012 09:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.512
X-Spam-Level: 
X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVxvG22OtPAN for ; Tue, 27 Mar 2012 09:31:49 -0700 (PDT)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 939F021E8168 for ; Tue, 27 Mar 2012 09:31:49 -0700 (PDT)
Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q2RGVewM021832 for ; Tue, 27 Mar 2012 12:31:40 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
From: Scott Rose 
In-Reply-To: 
Date: Tue, 27 Mar 2012 12:31:40 -0400
Message-Id: <42D1FE92-AC0C-43F8-8253-3D663C931D3D@gmail.com>
References: <4DE8BF39-7E68-4F10-BFBE-F4D408628929@gmail.com> 
To: DNSEXT Working Group 
X-Mailer: Apple Mail (2.1084)
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: scottr.nist@gmail.com
Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-01
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Suits me - we have a push to use ECDSA for digital signing (by 2015 for DNSSEC), so I don't have a problem with it.  I just wanted WG consensus before making the change.

Scott

On Mar 26, 2012, at 7:34 PM, Donald Eastlake wrote:

> From the very first days of DNSSEC, I've always thought the EC crypto,
> with its more compact keys and signatures, was the way to go
> eventually...
> 
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com
> 
> On Mon, Mar 26, 2012 at 6:29 PM, RJ Atkinson  wrote:
>> On Monday, 26th March 2012, Scott Rose wrote, in part:
>>> If the group thinks any of the assigned implementation status
>>> for entries should be changed - please state so.
>>> 
>>> Personally, I'm thinking ECDSA might be moved to "Recommended..."
>>> since there are some advantages, but willing to leave it as is.
>> 
>> All,
>> 
>> I support the idea of moving ECDSA to "Recommended".
>> 
>> Most of us are likely to end up deploying ECDSA eventually,
>> we might as well encourage folks to support it sooner
>> rather than later.  An earlier start to implementation
>> enables earlier widespread interoperability, which in
>> turn enables widespread deployment.  These things all
>> take time.  There is no value in delay.
>> 
>> * The financial sector already seems to be migrating
>>  from RSA to EC for a wide range of things.
>> 
>> * Separately, the published literature indicates that
>>  MUCH shorter EC keys have strength equivalent to
>>  MUCH longer RSA keys, so EC appears to scale better.[1][2]
>>  For example, [2] indicates that an ECC key size of
>>  163 bits has strength equivalent to an RSA key size
>>  of 1024 bits.
>> 
>> * Published literature also indicates that EC is less
>>  computationally expensive than RSA for equivalent-strength
>>  key sizes.  So EC is better for systems with smaller CPUs
>>  or that need to perform higher volumes of transactions.[3]
>> 
>> Yours,
>> 
>> Ran
>> 
>> 
>> 
>> REFERENCES:
>> 
>> [1] K. Lauter, "The Advantages of Elliptic Curve Cryptography for
>>    Wireless Security", IEEE Wireless Communications, Volume 11,
>>    Issue 1, IEEE, Piscataway, NJ, USA, February 2004.
>> 
>> [2] V. Gupta, et alia, "Performance Analysis of Elliptic Curve
>>    Cryptography for SSL", Proceedings of 1st ACM Workshop on
>>    Wireless Security, ACM, Atlanta, GA, September 2002.
>> 
>> [3] Nils Gura, et alia, "Comparing Elliptical Curve Cryptography
>>    and RSA on 8-bit CPUs", Proceedings of 6th International Workshop
>>    on Cryptographic Hardware and Embedded Systems '04, published in
>>    Volume 3156, Lecture Notes in Computer Science, Springer-Verlag,
>>    Berlin, DE, 2004.
>> 
>> _______________________________________________
>> dnsext mailing list
>> dnsext@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsext
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext

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

From dnsext-bounces@ietf.org  Tue Mar 27 09:44:29 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944E321E820F; Tue, 27 Mar 2012 09:44:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332866669; bh=DQlp/V+RaVppVey5D/fPhAy3fiCyrtP3i9MfRpv08V0=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=WvmGNmJyjzTk9jsXNvcWk/1Ato/IbhrfRHIJSIQmOh213xoEkRWGPmxuPfK7Ii9i2 BU2wH3UwTT9g59gyOeghGqZazXcocyHXoAH1X+SqN9MnlXI7yepkuaLvr9MOmqOxoh U+3dkfJIhsiFVonHI4YGeiaIiGO+SBfgiee2TJXM=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DABB21E8209 for ; Tue, 27 Mar 2012 09:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.371
X-Spam-Level: 
X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOnV2ed92mdd for ; Tue, 27 Mar 2012 09:44:27 -0700 (PDT)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 51F2421E81F0 for ; Tue, 27 Mar 2012 09:44:27 -0700 (PDT)
Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q2RGiFLR022682; Tue, 27 Mar 2012 12:44:16 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
From: Scott Rose 
In-Reply-To: <201203271402.QAA03645@TR-Sys.de>
Date: Tue, 27 Mar 2012 12:44:15 -0400
Message-Id: <2E875509-4B39-4876-806D-E8FE49F83B9E@gmail.com>
References: <201203271402.QAA03645@TR-Sys.de>
To: =?iso-8859-1?Q?Alfred_H=CEnes?= 
X-Mailer: Apple Mail (2.1084)
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: scottr.nist@gmail.com
Cc: dnsext@ietf.org
Subject: Re: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-05
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Thanks - we will fix those comments in the next revision.

Scott

On Mar 27, 2012, at 10:02 AM, Alfred H=CEnes wrote:

> A have a few more, mostly editorial comments on
>          draft-ietf-dnsext-dnssec-algo-signal-05
> (trying to avoid duplicates of items already mentioned this week
> in review comments on the list):
> =

> =

> 1)  General Terminology  (mostly in Section 1), and some nits
> =

> * Sect. 1, 2nd para:
> =

> "DS" should be spelled out "Delegation Signer", not "Delegated Signer"
> -- cf. RFC 3034, sect. 2, "Definition of DNSSEC Terms").
> Also, a comma should be placed in front of "like" in that para.
> =

> * Sect. 1, 3rd para:
> =

> The draft should not say "EDNS attribute" in one place, always more
> precisely "EDNS option" (see snippet below).
> =

> * Sect. 1, 3rd para, and Sect. 8, 2nd line:
> =

> The hashes used in DNSSEC are cryptographic functions/algorithms as
> well. Using "cryptographic algorithm" in some places as a substitute
> for "[cryptographic|digital] signature algorithm" seems confusing.
> This should be fixed.
> =

> Additionally, for enhanced clarity, I suggest to shuffle the words
> a bit and improve the language in the 3rd para of Section 1:
> =

> OLD:
>   This draft sets out to specify a way for validating end-system
>   resolvers to tell a server which cryptographic and/or hash algorithms
>   they support in a DNS query.  This is done using the EDNS attribute
>   values in the OPT meta-RR [RFC2671].
> =

> NEW:
>   This draft sets out to specify a way for validating end-system
>   resolvers to tell a server in a DNS query which digital signature
>   and/or hash algorithms they support.  This is done using the new
>   EDNS options specified below in Section 2 for use in the OPT meta-RR
>   [RFC2671].
> =

> =

> 2)  "EDNS" vs. "EDNS0"
> =

> The EDNS framework is designed to allow expansion while maintaining
> backward compatibility, and one method to achieve this is based on
> the versioning rules from RFC 2671[bis].  Therefore, we should better
> avoid referring specifically to "EDNS0" or "EDNS(0)" when mentioning
> facts that are expected to remain strictly unchanged in future EDNS
> versions (however unlikely their occurrence may seem now).
> =

> In particular, I suggest to  s/EDNS0/EDNS/  twice in the 1st para
> of Sect. 2, once in the 2nd para of Sect. 6, and once in Sect. 8.
> =

> =

> 3)  error in example ??
> =

> In the last para of Section 2, the byte counts given apparently
> do not match the other information.  I suspect the figures have
> inadvertently not been updated upon the change in the EDNS option
> structure the draft has undergone.
> IMHO, "16-24 octets" should read "24-34 octets":
> =

> OLD:
> =

>   However, in practical terms including all three options are likely to
> |  take up 16-24 octets (average of 6-10 digital signature algorithms,
>           ^^^^^
>   3-5 DS hash algorithms and 1-5 NSEC3 hash algorithms) including the
>   EDNS option codes and option lengths in a reasonable potential future
>   example.
> =

> NEW:
>                              v                             vv
> |  However, in practical terms, including all three options is likely to
> |  take up 24-34 octets (average of 6-10 digital signature algorithms,
>           ^^^^^
>   3-5 DS hash algorithms and 1-5 NSEC3 hash algorithms) including the
>   EDNS option codes and option lengths in a reasonable potential future
>   example.
> =

> (Note that "including" acts as the subject in this sentence, so the
> verb "are" needs to be in singular form, "is"; I also added a comma.)
> =

> The lower bound (22) corresponds to the lower counts mentioned,
> and the upper bound to the upper counts each:
> =

> -  fixed overhead for DAU:    4 octets  \
> -  code list for DAU:      6-10 octets  / 10-16 octets
> -  fixed overhead for DHU:    4 octets  \
> -  code list for DHU:       3-5 octets  /  7-9  octets
> -  fixed overhead for N3U:    4 octets  \
> -  code list for N3U:       3-5 octets  /  7-9  octets
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> total:                                    24-34 octets
> =

> =

> 4)  typo in Sect. 3, 2nd para
> =

> OLD:
> =

>   Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital
> |  signature codes for cover a potentially wide range of algorithms and
>                   ^^^
>   are likely not useful to a server.  [...]
> =

> NEW:
> =

>   Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital
> |  signature codes both cover a potentially wide range of algorithms and
>                   ^^^^
>   are likely not useful to a server.  [...]
> =

> =

> 5)  Section structure
> =

> The current sections 3.2 and 3.3 are, from a logical/semantical
> perspective, subordinate to the current Section 3.1 in the same
> way as Sections 3.4.1 and 3.4.2 are subordinate to Section 3.4.
> I suggest to restructure s3.1-3.3 and renumber the rest of s3:
> =

>    3.2    -->  3.1.1
>    3.3    -->  3.1.2
>    3.4    -->  3.2
>    3.4.1  -->  3.2.1
>    3.4.2  -->  3.2.2
> =

> =

> 6)  Reference update
> =

> The revised EDNS0 specification is ahead in the IESG, therefore I
> suggest to update the citations to RFC 2671 toward the 'bis' document.
> =

> =

> Best regards,
>  Alfred.
> =


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

From dnsext-bounces@ietf.org  Tue Mar 27 10:11:59 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56D921F873D; Tue, 27 Mar 2012 10:11:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332868319; bh=mGeTFvAy3M6SV+dMsT4bSXXxTQAwgA2grkfhnuzKA/I=; h=From:Message-Id:To:Date:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=cErhebheqM0PFoOPWIZSVDCLJn1AvjbJ7EXmc3+kYC2xjXyaylm+Or0CsP+WJAHtu EVYXlxO4t/eQySxYSye+EC5FdGK9gcchT20J0qHz2K2rgPUX02YQfUZUb9H8RiEd0Q +dzGykphfPHHorKb3yRQ75JVjsEv6+8LWqSDeNT8=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D97E21F86F3 for ; Tue, 27 Mar 2012 10:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.636
X-Spam-Level: 
X-Spam-Status: No, score=-98.636 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9QwIvWzMRje for ; Tue, 27 Mar 2012 10:11:57 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE1F21F873A for ; Tue, 27 Mar 2012 10:11:55 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA271078246; Tue, 27 Mar 2012 19:10:46 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA05008; Tue, 27 Mar 2012 19:10:45 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= 
Message-Id: <201203271710.TAA05008@TR-Sys.de>
To: scottr.nist@gmail.com
Date: Tue, 27 Mar 2012 19:10:44 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Cc: dnsext@ietf.org
Subject: [dnsext] editorials in draft-ietf-dnsext-dnssec-registry-update-01
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

I observed a few editorial nits in
  draft-ietf-dnsext-dnssec-registry-update-01
that should be fixed before publication as an RFC.


(1)  Section 1

* 1st para:

Similarly as in the algo-signal I-D,
   "... digital signature algorithms (consisting of a cryptographic
    algorithm and one-way hash function)."
is an unfortunate verbiage.  My suggestion here is to insert
"public key-based " or  "asymmetrical " in front of
"cryptographic algorithm", to properly qualify the latter term.
In the last line, "a" should be added after "and" to balance the
language.

Further there is a singular/plural mismatch in the 2nd line:
"Extensions" (plural) <==> "uses" (singular)
Better:
   The DNS ... Extensions ... use digital signatures ...
                              ^^^

Finally I suggest to include the list of DNSSEC citations in the
parentheses in the 1st two lines and add the explanatory words
", defined by" before that list.

Altogether, after application of these suggestions, the 1st para
would look like:

|  The Domain Name System (DNS) Security Extensions (DNSSEC, defined by
|  [RFC4033], [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702])
   use digital signatures over DNS data to provide source authentication
   and integrity protection.  DNSSEC uses an IANA registry to list codes
|  for digital signature algorithms (consisting of an asymmetrical
   cryptographic algorithm and a one-way hash function).

* last para:

Typo:   s/auxillery/auxiliary/
               ^^        ^^

(2)  Section 2.1, last para

The preceding text does not reproduce the description values
currently found in the registry table.  Therefore, the beginning
of the 2nd para does not make much sense:

|  The above values are changed to "Reserved" because ...
             ^^^^^^
I suggest to replace "values" by "entries" or "assignments"
to achieve a proper logical connection to the preceding text.


(3)  Table in Section 2.2

* The 1st heading line of the table is misaligned relative to
  the 2nd heading line and the body of the table; it should be
  shifted to the left by two places.

* In the Description column for Algo # 1, please correct the typo:
  s/Depricated/Deprecated/
        ^          ^

Best regards,
  Alfred.

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

From dnsext-bounces@ietf.org  Tue Mar 27 13:19:12 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BF321F8731; Tue, 27 Mar 2012 13:19:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332879552; bh=GMsvqHCAGvIZNrMWHVajvvVl/CLuSSLkIZnVudYZ0tE=; h=From:Message-Id:To:Date:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=R8ajilp9f0fWuskHmxXv6WFLxM2lOuLGmivkMmo+BB6GeJQZnjNwMfCf8bmiQBWF3 IYESDJGQh3lpyJJ6tZBOegDzGte3Vykq5PwQDpqGaUiHud0VD8Xsa8nirw/qZkyenN arnRlXf3rsEQ1Hw7X1rqs5ShF/o4EBMd5xd334yo=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8E721F8731 for ; Tue, 27 Mar 2012 13:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.338
X-Spam-Level: 
X-Spam-Status: No, score=-98.338 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GE6YRfZr343 for ; Tue, 27 Mar 2012 13:19:10 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8A12321F872E for ; Tue, 27 Mar 2012 13:19:09 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA271769480; Tue, 27 Mar 2012 22:18:00 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA07471; Tue, 27 Mar 2012 22:17:58 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= 
Message-Id: <201203272017.WAA07471@TR-Sys.de>
To: standards@taugh.com
Date: Tue, 27 Mar 2012 22:17:58 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Cc: dnsext@ietf.org
Subject: [dnsext] draft-levine-dnsextlang-02 interop w/ rfc3597[bis]
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Hi,

I spent a few thoughts on operational considerations and
interoperability with implementations that wouldn't support
your proposal of a RRtype description language (btw: the AAA
folks call such decription for RADIUS attributes a "dictionary").

If an implementation of your I-D has to import zone data
in presentation format produced by a system that "only" supports
RFC 3597 (or the stalled 'bis' version), I think a conformant
receiving system SHOULD automatically recognize RFC 3597
"Unknown RR Format" even for RRtypes for which it has been configured
with a description of the RRtype-specific presentation format.
(The source system could be another DNS implementation or a
provisioning system.)

So far, so fine.

But what happens if the implementation supporting Ext'lang and
having been configured with the friendly format for a specific
"Unknown RRtype" (as listed in RFC 3597) has operational needs
to _export_ data to a non-upgraded recipient system, in a specific
operational environment?

Maybe the extension language could be amended by a (per-RRtype)
indicator that, on data _export_, the RFC 3597 format needs to be
used, and/or implement some (global) trigger to cause this behavior
for a particular operation for the tagged RRtypes, or for _all_
RFC 3597 Unknown RRtypes.
This fine-grained interop-configuration would help to accommodate
interaction with systems that (hard-coded) support the specific
presentation format for _some_ "Unknown RRtypes" in the best
human-friendly manner possible in a specific operational setting.

Note that the RRtype descriptions would be needed anyway for
communications (at least import from) upgraded systems, so just
leaving out some descriptions would be counter-productive.
Such additional tags in the language would thus make the gradual
deployment of Ext'lang within an operational domain much more
easier and hence might further actual acceptance, implementation,
and deployment of the proposal.

(For instance, a provisioning system could be upgraded to accept
human-friendly presentation format for Unknown RRtypes, but might
still have the need to produce RFC 3597 format to be fed to the
authoritative servers or other operational support systems until
these also support the Ext'lang.)


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+

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

From dnsext-bounces@ietf.org  Tue Mar 27 15:36:28 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFE521E802A; Tue, 27 Mar 2012 15:36:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332887788; bh=xYLeqzmnXKduhW24YVq5teM6xGlr9XkfvRikTAVM1pM=; h=From:Message-Id:To:Date:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Airvzwo7Mq0mF39TbwEEiHWbJjt0vjk7paC8xXJpMPf3T6vjsNjtCjf2q9Y8IRsbk YG+gR2OKtrRY6DPfStZ9pgRq1xI/Nfgx/lqbRXFsB3bRkNCiQJqVci5la6GsCYAmzV 0uKcuo7OoX6F3V6snRlxnBTKNrKJiRwAhVOsz9YU=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BF121E802A for ; Tue, 27 Mar 2012 15:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.634
X-Spam-Level: 
X-Spam-Status: No, score=-98.634 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2LJMabIwmtf for ; Tue, 27 Mar 2012 15:36:26 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id D13A621E8011 for ; Tue, 27 Mar 2012 15:36:24 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA272237715; Wed, 28 Mar 2012 00:35:15 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA08022; Wed, 28 Mar 2012 00:35:14 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= 
Message-Id: <201203272235.AAA08022@TR-Sys.de>
To: cheshire@apple.com, marc@apple.com
Date: Wed, 28 Mar 2012 00:35:13 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Cc: dnsext@ietf.org
Subject: [dnsext] A quick review of draft-cheshire-dnsext-special-names-02
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: base64
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

SGksCkkndmUgcGVyZm9ybWVkIGEgcXVpY2sgcmV2aWV3IG9mIHRoZSBETlNFWFQtcmVsYXRlZCBJ
LUQsCiAgICBkcmFmdC1jaGVzaGlyZS1kbnNleHQtc3BlY2lhbC1uYW1lcy0wMgphbmQgd291bGQg
bGlrZSB0byBzdWJtaXQgYSBmZXcgbm90ZXMuCgoKKEEpICBTaWduaWZpY2FudCBpc3N1ZXMKCihB
LjEpCkZpcnN0bHksIEknbSBzdXJwcmlzZWQgYnkgdGhlIG5vbi10cml2aWFsIG92ZXJsYXAgb2Yg
dGhpcyB3b3JrCndpdGggUkZDIDYzMDMgYW5kIHRoZSBJQU5BIFJlZ2lzdHJ5IGNyZWF0ZWQgYnkg
aXQsIHRoZSAiQVMxMTIiIFJGQ3MsCmFuZCB0aGUgb25nb2luZyB3b3JrLWluLXByb2dyZXNzIHRv
IGFkZHJlc3MgbW9yZSBlbWVyZ2luZyBvdmVybG9hZApyZWFzb25zIGZvciB0aGUgYXV0aG9yaXRh
dGl2ZSByb290L2luZnJhc3RydWN0dXJlIEROUyBzZXJ2ZXJzIGJ5CmV4dGVuZGluZyB0aGUgc2Nv
cGUgb2YgdGhlIEFTMTEyIHByb2plY3QsIHJlZ2lzdGVyaW5nIG1vcmUgInNwZWNpYWwiCmRvbWFp
biBuYW1lcyBpbiB0aGF0ICJMb2NhbGx5IFNlcnZlZCBETlMgWm9uZXMiIElBTkEgcmVnaXN0cnks
IGFuZApzcGVjaWZ5aW5nIHRoYXQgdGhleSBiZSB0cmVhdGVkIGFzIHNwZWNpZmllZCBpbiBSRkMg
NjMwMy4KClRoZSBwcmVzZW50IGRyYWZ0IG5vdCBldmVuIHF1b3RlcyBSRkMgNjMwMyBmb3IgU2Vj
dC4gNS4xLCB3aGVyZQp0aGUgbGFyZ2VzdCBvdmVybGFwIHdpdGggUkZDIDYzMDMgb2NjdXJzLiAg
KEkgaGF2ZSBub3QgeWV0IHN0dWRpZWQKaW4gZGV0YWlsIGluaG93ZmFyIHRoZSBuZXcgc3BlY2lm
aWNhdGlvbiBpbiB0aGF0IHNlY3Rpb24gaXMKY29tcGF0aWJsZSBvciBjb2xsaWRlcyB3aXRoIHRo
ZSBub3JtYXRpdmUgYmVoYXZpb3Igc3BlY2lmaWVkIGluClJGQyA2MzAzLikKCgooQS4yKQpTZWNv
bmQsIHRoZSBuZXcgZHJhZnQgdmVyc2lvbiBoYXMgZXhwYW5kZWQgdGhlIHNjb3BlIG9mIHRoZSBJ
LUQKc2lnbmlmaWNhbnRseSwgYW5kIHRoYXQgaGFzIG5vdCBiZWVuIHJlZmxlY3RlZCBpbiB0aGUg
QWJzdHJhY3QuCk1heWJlIHRoYXQgc2hvdWxkIGJlIGFtZW5kZWQgbGlrZSB0aGlzOgoKT0xEOgoK
fEFic3RyYWN0CnwKfCAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgd2hhdCBpdCBtZWFucyB0byBz
YXkgdGhhdCBhIEROUyBuYW1lIGlzCnwgIHJlc2VydmVkIGZvciBzcGVjaWFsIHVzZSwgd2hlbiBy
ZXNlcnZpbmcgc3VjaCBhIG5hbWUgaXMgYXBwcm9wcmlhdGUsCnwgIGFuZCB0aGUgcHJvY2VkdXJl
IGZvciBkb2luZyBzby4KCk5FVzoKCnxBYnN0cmFjdAp8CnwgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp
YmVzIHdoYXQgaXQgbWVhbnMgdG8gc2F5IHRoYXQgYSBETlMgbmFtZSBpcwp8ICByZXNlcnZlZCBm
b3Igc3BlY2lhbCB1c2UsIHdoZW4gcmVzZXJ2aW5nIHN1Y2ggYSBuYW1lIGlzIGFwcHJvcHJpYXRl
LAp8ICBhbmQgdGhlIHByb2NlZHVyZSBmb3IgZG9pbmcgc28uICBJdCBlc3RhYmxpc2hlcyBhbiBJ
QU5BIHJlZ2lzdHJ5IGZvcgp8ICBzdWNoIGRvbWFpbiBuYW1lcyBhbmQgc2VlZHMgaXQgd2l0aCBz
b21lIG9mIHRoZSBzcGVjaWFsIGRvbWFpbiBuYW1lcwp8ICBlc3RhYmxpc2hlZCBieSBleGlzdGlu
ZyBSRkNzLgoKCihBLjMpICBUZXJtaW5vbG9neSwgdXNlIG9mIGxlYWRpbmcvdHJhaWxpbmcgZG90
cyB3aXRoIGRvbWFpbiBuYW1lcwoKRGVzcGl0ZSB0aGUgY29sbG9xdWlhbCAiZG90LWNvbSIgc3Bl
YWssIGEgZG90IHNob3VsZCBub3QgYmUgdXNlZApvbiB0aGUgbGVmdC1oYW5kIHNpZGUgb2YgZG9t
YWluIG5hbWVzIC0tIG1heWJlIGV4Y2VwdCB3aGVuIHVzZWQgYXMKYW4gaW5kaWNhdGlvbiBmb3Ig
c3ViZG9tYWlucywgYnV0IHRoYXQgY2FuIGJlIGhhbmRsZWQgYmV0dGVyIGJ5CnN1aXRhYmxlIHRl
eHQuICBEZXRhaWxlZCBleGFtcGxlcyBhcmUgc2hvd24gaW4gdGhlIHdhbGstdGhyb3VnaCBiZWxv
dy4KCkluIHByYWN0aWNlLCB0aGUgcHJlc2VuY2Ugb3IgYWJzZW5zZSBvZiBhIHRyYWlsaW5nIHBl
cmlvZCBpcyB1c2VkIHRvCmRpc3Rpbmd1aXNoIGJldHdlZW4gZnVsbHkgcXVhbGlmaWVkIGFuZCBy
ZWxhdGl2ZSBkb21haW4gbmFtZXMgKHdoaWNoCm1pZ2h0IGJlIHN1YmplY3RlZCB0byAiZG9tYWlu
IHN1ZmZpeCBsaXN0IiBleHBhbnNpb24gaW4gY29tbW9uIEFQSXMsCm9yIHdoaWNoIGNhbiBhcHBl
YXIgaW4gaW5kdXN0cnkgc3RhbmRhcmQgem9uZSBmaWxlcyB1bmRlciBlZmZlY3Qgb2YKJE9SSUdJ
TiBkaXJlY3RpdmVzKSAtLSBjZi4gU2VjdGlvbiAzLjEsIHBhZ2UgOCBvZiBSRkMgMTAzNC4KClNp
bWlsYXJseSwgaXQgbWlnaHQgYmUgd29ydGggdXNpbmcgdGhlIG1vcmUgcHJlY2lzZSwgY29tbW9u
IEROUyB0ZXJtcwoiU3R1YiBSZXNvbHZlciIsIGFuZCAiSXRlcmF0aXZlIFJlc29sdmVyIiAoaW5z
dGVhZCBvZiAiQ2FjaGluZyBETlMKc2VydmVycyIpIHRocm91Z2hvdXQgdGhlIGRyYWZ0IC0tIGF1
dGhvcml0YXRpdmUgRE5TIHNlcnZlcnMsIEROUwpwcm94aWVzLCBhbmQgZXZlbiBzdHViIHJlc29s
dmVycyBjb21tb25seSB1c2Ugc29tZSBjYWNoaW5nIGFzIHdlbGwhCgoKKEEuNCkgIFNlY3Rpb24g
NS4xCgpBcyBhbHJlYWR5IG1lbnRpb25lZCBhYm92ZSwgdGhpcyBjb2xsaWRlcyB3aXRoIFJGQyA2
MzAzIGFuZCB0aGUKSUFOQSByZWdpc3RyeSBlc3RhYmxpc2hlZCBieSBpdC4KCkkgc3Ryb25nbHkg
cmVjb21tZW5kIHRvIHJlbW92ZSBfYWxsXyBkb21haW4gbmFtZXMgZnJvbSB0aGlzIHNlY3Rpb24K
YW5kIGluc3RlYWQgaW5jbHVkZSBieSByZWZlcmVuY2UgdGhlIGRvbWFpbiBuYW1lcyByZWdpc3Rl
cmVkIGluIHRoZQoiTG9jYWxseSBTZXJ2ZWQgRE5TIFpvbmVzIiBJQU5BIFJlZ2lzdHJ5IGVzdGFi
bGlzaGVkIGJ5IFJGQyA2MzAzLgpJdCBsb29rcyBsaWtlIGFsbCBkb21haW4gbmFtZXMgc3VpdGFi
bGUgZm9yIHJlZ2lzdHJhdGlvbiB0aGVyZQotLSBub3Qgb25seSB0aGUgcmV2ZXJzZSBETlMgem9u
ZSBuYW1lcyBmb3IgUkZDIDE4MTIgYWRkcmVzc2VzIC0tCmRlc2VydmUgdGhlIHNhbWUgYmVoYXZp
b3IuCkFsc28sIHRvIGF2b2lkIGNvbGxpc2lvbnMgd2l0aCBiZWhhdmlvciBzcGVjaWZpZWQgaW4g
UkZDIDYzMDMsClNlY3Rpb25zIDIgYW5kIDMgb2YgUkZDIDYzMDMgc2hvdWxkIGJlIGNhcmVmdWxs
eSBldmFsdWF0ZWQgYW5kIGFueQpvdmVybGFwcGluZyBvciBjb2xsaWRpbmcgdGV4dCAtLSBpbiBw
YXJ0aWN1bGFyIGluIGJ1bGxldCA0LiAtLQpzaG91bGQgYmUgcmVtb3ZlZCBhbmQgcmVwbGFjZWQg
YnkgYSBwb2ludGVyIHRvIHRoZSBub3JtYXRpdmUgdGV4dAppbiBSRkMgNjMwMy4KCgooQikgZWRp
dG9yaWFsIGxpbmVhciB3YWxrLXRocm91Z2gKCihCLjEpIFNlY3Rpb24gMSwgMm5kIHBhcmEKClRo
ZSBkcmFmdCBzaG91bGQgYmV0dGVyIHVzZSB0aGUgZGVmaW5pdGUgYXJ0aWNsZSB3aGVuICJETlMi
IGlzIHVzZWQKYXMgYSBub3VuOgoKfCAgQW5hbG9nb3VzIHRvIFNwZWNpYWwtVXNlIElQdjQgQWRk
cmVzc2VzIFtSRkM1NzM1XSwgRE5TIGhhcyBpdHMgb3duCiAgIGNvbmNlcHQgb2YgcmVzZXJ2ZWQg
bmFtZXMsIFsuLi5dCi0tLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHZ2dnYKfCAgQW5hbG9nb3VzIHRvIFNwZWNpYWwtVXNlIElQdjQgQWRkcmVzc2Vz
IFtSRkM1NzM1XSwgdGhlIEROUyBoYXMgaXRzCiAgIG93biBjb25jZXB0IG9mIHJlc2VydmVkIG5h
bWVzLCBbLi4uXQoKCihCLjIpIFNlY3Rpb24gNCwgbGlzdCBpdGVtIDYuCgpJIHN1Z2dlc3QgdG8g
YWRkIGEgY29tbWEgZm9yIGNsYXJpdHk6CgogICAgICBEb2VzIHRoaXMgcmVzZXJ2ZWQgU3BlY2lh
bC1Vc2UgRG9tYWluIE5hbWUgaGF2ZSBhbnkgcG90ZW50aWFsCiAgICAgIGltcGFjdCBvbiBETlMg
c2VydmVyIG9wZXJhdG9ycz8gSWYgdGhleSB0cnkgdG8gY29uZmlndXJlIHRoZWlyCnwgICAgIGF1
dGhvcml0YXRpdmUgRE5TIHNlcnZlciBhcyBhdXRob3JpdGF0aXZlIGZvciB0aGlzIHJlc2VydmVk
IG5hbWUKICAgICAgd2lsbCBjb21wbGlhbnQgbmFtZSBzZXJ2ZXIgc29mdHdhcmUgcmVqZWN0IGl0
IGFzIGludmFsaWQ/IFsuLi5dCi0tLQogICAgICBEb2VzIHRoaXMgcmVzZXJ2ZWQgU3BlY2lhbC1V
c2UgRG9tYWluIE5hbWUgaGF2ZSBhbnkgcG90ZW50aWFsCiAgICAgIGltcGFjdCBvbiBETlMgc2Vy
dmVyIG9wZXJhdG9ycz8gSWYgdGhleSB0cnkgdG8gY29uZmlndXJlIHRoZWlyCnwgICAgIGF1dGhv
cml0YXRpdmUgRE5TIHNlcnZlciBhcyBhdXRob3JpdGF0aXZlIGZvciB0aGlzIHJlc2VydmVkIG5h
bWUsCiAgICAgIHdpbGwgY29tcGxpYW50IG5hbWUgc2VydmVyIHNvZnR3YXJlIHJlamVjdCBpdCBh
cyBpbnZhbGlkPyBbLi4uXQoKCihCLjMpICBTZWN0aW9ucyA1LjIgdGhyb3VnaCA1LjUsIGxlYWRp
bmcgdGV4dCBlYWNoCgoqICBUaGUgdGV4dCBpbiBTZWN0aW9uIDUuNCBzYXlzOgoKfCAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFsuLi5dICBJbiB0aGUgdGV4dCBiZWxvdyB0aGUgdGVybQp8
ICAiaW52YWxpZCIgaXMgdXNlZCBpbiBxdW90ZXMgdG8gc2lnbmlmeSBzdWNoIG5hbWVzLCBhcyBv
cHBvc2VkIHRvCnwgIG5hbWVzIHRoYXQgbWF5IGJlIGludmFsaWQgZm9yIG90aGVyIHJlYXNvbnMg
KGUuZy4gYmVpbmcgdG9vIGxvbmcpLgoKVGhpcyBpcyBhIHVzZWZ1bCBjb252ZW50aW9uLCBhbmQg
YWx0aG91Z2ggImludmFsaWQiIGlzIGxpa2VseSB0aGUKbW9zdCBzZXJpb3VzIGNhc2UsIEkgc3Ry
b25nbHkgc3VnZ2VzdCB0byBleHRlbmQgdGhpcyBjb252ZW50aW9uCmFuZCBzdHlsZSB1bmlmb3Jt
bHkgdG8gU2VjdGlvbnMgNS4yLCA1LjMsIGFuZCA1LjUgYXMgd2VsbC4KKEJlc2lkZXMsIGluIHRo
ZSBxdW90ZSBhYm92ZSwgYSBjb21tYSBzaG91bGQgYmUgcGxhY2VkIGZvciBpbXByb3ZlZAogcmVh
ZGFiaWxpdHkgYWZ0ZXIgImJlbG93Ii4pCgoqICBBcyBtZW50aW9uZWQgYWJvdmUgYWJvdmUsIHRo
ZSBwbGFjZW1lbnQgb2YgbGVhZGluZy90cmFpbGluZyBwZXJpb2RzCiAgIGluIGRvbWFpbiBuYW1l
cyBzaG91bGQgYmUgYWxpZ25lZCB3b3RoIFJGQ3MgMTAzNCwgMTAzNSwgYW5kIDIxODEuCgpTbywg
Zm9yIGluc3RhbmNlLCBJIHJlY29tbWVuZCB0byBjaGFuZ2UgdGhlICJoZWFkIiBvZiBTZWN0aW9u
IDUuNAphcyBmb2xsb3dzOgoKT0xEOgoKfDUuNC4gIERvbWFpbiBOYW1lIFJlc2VydmF0aW9uIENv
bnNpZGVyYXRpb25zIGZvciAiLmludmFsaWQuIgp8CnwgIFRoZSBkb21haW4gIi5pbnZhbGlkLiIs
IGFuZCBhbnkgbmFtZXMgZmFsbGluZyB3aXRoaW4gIi5pbnZhbGlkLiIsIGFyZQp8ICBzcGVjaWFs
IGluIHRoZSB3YXlzIGxpc3RlZCBiZWxvdy4gSW4gdGhlIHRleHQgYmVsb3cgdGhlIHRlcm0KfCAg
ImludmFsaWQiIGlzIHVzZWQgaW4gcXVvdGVzIHRvIHNpZ25pZnkgc3VjaCBuYW1lcywgYXMgb3Bw
b3NlZCB0bwp8ICBuYW1lcyB0aGF0IG1heSBiZSBpbnZhbGlkIGZvciBvdGhlciByZWFzb25zIChl
LmcuIGJlaW5nIHRvbyBsb25nKS4KCk5FVzoKCnw1LjQuICBEb21haW4gTmFtZSBSZXNlcnZhdGlv
biBDb25zaWRlcmF0aW9ucyBmb3IgImludmFsaWQuIgp8CnwgIFRoZSBkb21haW4gImludmFsaWQu
IiwgYW5kIGFueSBuYW1lcyBmYWxsaW5nIHdpdGhpbiAiaW52YWxpZC4iLCBhcmUKfCAgc3BlY2lh
bCBpbiB0aGUgd2F5cyBsaXN0ZWQgYmVsb3cuIEluIHRoZSB0ZXh0IGJlbG93LCB0aGUgdGVybQp8
ICAiaW52YWxpZCIgaXMgdXNlZCBpbiBxdW90ZXMgdG8gc2lnbmlmeSBzdWNoIG5hbWVzLCBhcyBv
cHBvc2VkIHRvCnwgIG5hbWVzIHRoYXQgbWF5IGJlIGludmFsaWQgZm9yIG90aGVyIHJlYXNvbnMg
KGUuZy4gYmVpbmcgdG9vIGxvbmcpLgoKCkkgcmVjb21tZW5kIHRoYXQgdGhlICJoZWFkcyIgb2Yg
U2VjdGlvbnMgNS4yLCA1LjMsIGFuZCA1LjUgYXJlCm1vZGlmaWVkIGluIGEgc2ltaWxhciBtYW5u
ZXIsIGFuZCB0aGUgZG91YmxlLXF1b3Rpbmcgb2YgdGhlCnJlc3BlY3RpdmUgZG9tYWluIG5hbWVz
IGJlIGludHJvZHVjZWQgdGhyb3VnaG91dCB0aGVzZSBzZWN0aW9ucy4KRm9yIGV4YW1wbGU6CgpO
RVc6Cgp8NS4yLiAgRG9tYWluIE5hbWUgUmVzZXJ2YXRpb24gQ29uc2lkZXJhdGlvbnMgZm9yICJ0
ZXN0LiIKfAp8ICBUaGUgZG9tYWluICJ0ZXN0LiIsIGFuZCBhbnkgbmFtZXMgZmFsbGluZyB3aXRo
aW4gInRlc3QuIiwgYXJlCnwgIHNwZWNpYWwgaW4gdGhlIHdheXMgbGlzdGVkIGJlbG93LiAgRm9y
IGNsYXJpdHksIGluIHRoZSB0ZXh0IGJlbG93LAp8ICB0aGlzIGRvbWFpbiBuYW1lIGlzIGFsd2F5
cyB1c2VkIGluIGRvdWJsZS1xdW90ZWQgZm9ybS4KCgooQi40KQpGb2xsb3dpbmcgZXN0YWJsaXNo
ZWQgcHJhY3RpY2UsIHByb3RvY29sIGZpZWxkIG5hbWVzIGFuZCBwcm90b2NvbAp2YWx1ZXMgc2hv
dWxkIGJlIHNwZWxsZWQgYXMgaW4gdGhlIG5vcm1hdGl2ZSBzcGVjaWZpY2F0aW9ucy4KCkhlbmNl
LCB0aHJvdWdob3V0IHRoZSBkcmFmdCAoaS5lLiBpbiBTZWN0aW9ucyA1LjMsIDUuNCwgYW5kIDUu
NSAtLQpidWxsZXQgNi4gZWFjaCksIHBsZWFzZSAgcy9yZGF0YS9SREFUQS8gLgoKCktpbmQgcmVn
YXJkcywKICBBbGZyZWQgSM5uZXMuCgotLSAKCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnwgVFItU3lzIEFsZnJl
ZCBIb2VuZXMgICB8ICBBbGZyZWQgSG9lbmVzICAgRGlwbC4tTWF0aC4sIERpcGwuLVBoeXMuICB8
CnwgR2VybGluZ2VyIFN0cmFzc2UgMTIgICB8ICBQaG9uZTogKCs0OSk3MTU2Lzk2MzUtMCwgRmF4
OiAtMTggICAgICAgICB8CnwgRC03MTI1NCAgRGl0emluZ2VuICAgICB8ICBFLU1haWw6ICBhaEBU
Ui1TeXMuZGUgICAgICAgICAgICAgICAgICAgICB8CistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkbnNleHQgbWFpbGluZyBsaXN0
CmRuc2V4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ru
c2V4dAo=

From dnsext-bounces@ietf.org  Tue Mar 27 17:12:20 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAF021F852D; Tue, 27 Mar 2012 17:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332893540; bh=RVpj04kqXpTgWZfVjR+grlZQ0juf4gGwqaClHG64IzU=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=mCZ7HHON/ufNsw7kV6A+BSMdo4fhTWA1zQnLHfm+mblF4A2zV/J+07QXsz/WiZqYv s/dxDehXLsm8sObsMRhtqX7KdFJRMzncrtzzV/BCObH9yDYSXzw7DNkgmm1YRU3ITJ 64U5uKBaMLMWLQkg384CwnfHTFNhI+yTk5aVeDWs=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D202921F8526 for ; Tue, 27 Mar 2012 17:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level: 
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfRUgVGR5R5k for ; Tue, 27 Mar 2012 17:12:18 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id BCD0D21F8525 for ; Tue, 27 Mar 2012 17:12:18 -0700 (PDT)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2S0CHqk051825 for ; Tue, 27 Mar 2012 20:12:17 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2S0CHmk051819 for ; Tue, 27 Mar 2012 20:12:17 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Tue, 27 Mar 2012 20:12:17 -0400 (EDT)
From: Samuel Weiler 
To: dnsext@ietf.org
In-Reply-To: <20120327084731.30282.35216.idtracker@ietfa.amsl.com>
Message-ID: 
References: <20120327084731.30282.35216.idtracker@ietfa.amsl.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 27 Mar 2012 20:12:17 -0400 (EDT)
Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-00.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

As I said at the microphone in Paris, I would strongly prefer to see 
typecode templates posted publicly in all cases.  I see no need to 
shorten the review period beyond the current three weeks.

Furthermore, as I pointed out on this list on 7 October, IANA seems to 
not be maintaining the archive of templates as requested in both 
RFC5395 and RFC6195.  If we're are going to keep using this template 
system to allocate typecodes, we need that archive.  Absent a 
commitment from IANA to maintain that archive, preferably backed up 
with evidence that they have populated that archive with the old 
templates, I would prefer to see us back out the RFC5395 changes to 
the typecode allocation process and revert to the RFC2929 rules.

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

From dnsext-bounces@ietf.org  Wed Mar 28 02:19:31 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F5321E80C5; Wed, 28 Mar 2012 02:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332926371; bh=8S3gl3wIdqoZXNfuJWAdx5AHwSYZzDjvO6rCnU4R4fM=; h=Date:Message-ID:From:To:In-Reply-To:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=lslgZ6spgvl+pHNkU8aLPKPsCNFEL7va9cE749JzRaEcIAkHqSPab3H3AvBJxKNis i1Py2stT4DD0LQ+/IqUKmlYzuh1LO7cdvaxfXjswAhOaYnthPEhWXP3PakaE0NLFMa HV3jx0wf2PUMLmAyTEwloYH1uVRaZ1v1qrpTDkMY=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1E021E80A6 for ; Wed, 28 Mar 2012 02:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.196
X-Spam-Level: 
X-Spam-Status: No, score=-102.196 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdgY6rmH7RvO for ; Wed, 28 Mar 2012 02:19:28 -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 33E1521E809E for ; Wed, 28 Mar 2012 02:19:28 -0700 (PDT)
Received: (qmail 38646 invoked from network); 28 Mar 2012 09:19:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=96f5.4f72d79d.k1203; bh=ohVNjv7ZiN5OGnTv0SZ5ttr+cLF2SObCxTkZxwg4ba0=; b=RU6nUCnSOJJ83yk1MIlAvOSP0IoNwOYeXzOtFkDpSROZIb9W40OWQMhN84N0PI67y/Orbp0D/sArPzA6KpbT6SklRFMTu4yxTeB27HCEYCLjHs6W5UY3EmIBshpiJkTFSh7N1PY390GDPOzqaOkIU+Fw0Cv9FfrIGM5pPtb2Diw=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Received: (ofmipd 127.0.0.1); 28 Mar 2012 09:19:03 -0000
Date: 28 Mar 2012 11:19:23 +0200
Message-ID: 
From: "John R. Levine" 
To: "Alfred H?nes" 
In-Reply-To: <201203272017.WAA07471@TR-Sys.de>
References: <201203272017.WAA07471@TR-Sys.de>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Cc: dnsext@ietf.org
Subject: Re: [dnsext] [taugh.com-standards] draft-levine-dnsextlang-02 interop w/ rfc3597[bis]
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

> But what happens if the implementation supporting Ext'lang and
> having been configured with the friendly format for a specific
> "Unknown RRtype" (as listed in RFC 3597) has operational needs
> to _export_ data to a non-upgraded recipient system, in a specific
> operational environment?

It uses AXFR or something similar.  This is not a new problem, since there 
are plenty of DNS servers that use RFC 1034 master file format and haven't 
been upgraded to handle recently defined RR types.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Wed Mar 28 03:44:36 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9BD21F8A19; Wed, 28 Mar 2012 03:44:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332931476; bh=DcGq4riXag9LKAI/kDi4INbF5f5OP838KSHz5Z6zTgE=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=L9CLw/p4ZxEbY8zy8ERSi9fwWrWjiQqWHeWTKwkPiqwz2t6k9gTX+uIDcejKLRw5u a3FfNuYOwIb40OwK8UgudcFGtgNMhrvix1c8LzN3uLo14ewuDdHl9+kTuPZnAJQaMy b2MVi0Y7p/PsQjknjqZHoDrr8rvndHmUoeljyfWA=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A693721F8A2B for ; Wed, 28 Mar 2012 03:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.502
X-Spam-Level: 
X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.098,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MCagyZyEHEu for ; Wed, 28 Mar 2012 03:44:34 -0700 (PDT)
Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 2008321F8A16 for ; Wed, 28 Mar 2012 03:44:34 -0700 (PDT)
Received: by clone.registro.br (Postfix, from userid 1000) id 767D7E044E; Wed, 28 Mar 2012 07:44:33 -0300 (BRT)
Date: Wed, 28 Mar 2012 07:44:33 -0300
From: Frederico A C Neves 
To: dnsext@ietf.org
Message-ID: <20120328104433.GD26343@registro.br>
References: <20120327084731.30282.35216.idtracker@ietfa.amsl.com> 
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-00.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

On Tue, Mar 27, 2012 at 08:12:17PM -0400, Samuel Weiler wrote:
> As I said at the microphone in Paris, I would strongly prefer to see 
> typecode templates posted publicly in all cases.  I see no need to 
> shorten the review period beyond the current three weeks.

I agree with that and for the purpose of not depending on a dying
working group mailing list, I would suggest the creation of an
specific public list for this registry.

IANA or the acting experts on the past allocations could post the old
templates and the registry could simply reference this list archive as
a way to maintain the history of this allocations.

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

From dnsext-bounces@ietf.org  Wed Mar 28 09:51:29 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8469A21E80DD; Wed, 28 Mar 2012 09:51:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332953489; bh=EJvSMiR9TTZnQtM4d4xuIUbKaQnfYrdactZabVF18QY=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=HF3/a4WtBxdGsJQ1CvebcJfGcFlc8BngwhQh7Kxo53CUUoH/VTHTwR4Y9nkH0BYXv BcfXBlAXJlnF1OJi5VxmpZ8XQzLB0rcYA60GMfacWld0GNd47H9N/uJa1mQLdoNOrx 9ndfjtBFfWKojW/Cz6eiVWkXY8O3PzEmsyt8/0fU=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B64121E80DD for ; Wed, 28 Mar 2012 09:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.881
X-Spam-Level: 
X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xmf2eIP9eYUA for ; Wed, 28 Mar 2012 09:51:26 -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 49EB521E8091 for ; Wed, 28 Mar 2012 09:51:26 -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-2.csi.cam.ac.uk ([131.111.8.54]:45330) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1SCw5i-0002N5-pf (Exim 4.72) (return-path ); Wed, 28 Mar 2012 17:51:22 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SCw5h-0005w3-Vp (Exim 4.67) (return-path ); Wed, 28 Mar 2012 17:51:21 +0100
Date: Wed, 28 Mar 2012 17:51:21 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Alfred H?nes 
In-Reply-To: <201203272017.WAA07471@TR-Sys.de>
Message-ID: 
References: <201203272017.WAA07471@TR-Sys.de>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Cc: standards@taugh.com, dnsext@ietf.org
Subject: Re: [dnsext] draft-levine-dnsextlang-02 interop w/ rfc3597[bis]
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Alfred H?nes  wrote:
>
> But what happens if the implementation supporting Ext'lang and
> having been configured with the friendly format for a specific
> "Unknown RRtype" (as listed in RFC 3597) has operational needs
> to _export_ data to a non-upgraded recipient system, in a specific
> operational environment?

My immediate reaction was to say this is a matter for the configuration of
these systems, but then the question is where this configuration should
live and what form it should take.

I have been working on this proposal from the point of view of making
RR editors extensible, which brings up some related issues: whether RRs of
a particular type are human-editable or whether they should normally be
hidden. This mainly applies to DNSSEC records, so the question is whether
this should be hardcoded or supported by a generic mechanism. (There's a
similar question about name compression, for which John has specified a
generic mechanism but which can also be hardcoded according to the rules
in RFC 3597.) The generic mechanism would basically be per-RRtype
qualifiers (c.f. John's per-RDATA-field qualifiers) which could also be
used to say what format to use in master file exports.

Alternatively John's "AXFR or something similar" covers RFC 3597 generic
format master files - you can use the generic format for all records if
you want.

Another question this raises is whether the /etc/rrtypes file should be a
representation of the IANA RR type registry (like /etc/services and
/etc/protocols) or whether it is more system-specific. I have a
half-finished proposal for attaching descriptive text to RDATA fields for
user interfaces, which implies there will at least be per-language
versions, so perhaps it should be thought of as a per-package
configuration file rather than a fairly static part of the OS.

Any opinions on this vague rambling are welcome :-)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Viking, North Utsire: Northwesterly 5 to 7. Moderate or rough. Rain or
showers. Moderate or good, occasionally poor at first.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Wed Mar 28 15:12:26 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DA421E8106; Wed, 28 Mar 2012 15:12:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332972746; bh=L66uyQruvMdCdv306F22v8Z1FH5GJKOhT0+EjhA8i54=; h=From:Message-Id:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=QdKUEJVv3/1Nh/dW1gEvRyA6CPc9thgLLhuoa0a8awiswIjmpKzIiy/z2S2U6zeYb mSmy/xbmIti5kF+AfckIJzMY6dGDqYcZ7ACw/8TVHTF+6EQmSmc8hxiaAVrxvuDWxz yN/vpKZ+ruKn44fyGJpDSXAVYwTE2gxdoAkr/4EE=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADD121E80FB for ; Wed, 28 Mar 2012 15:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.039
X-Spam-Level: 
X-Spam-Status: No, score=-98.039 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itWjH3G8X5aC for ; Wed, 28 Mar 2012 15:12:23 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id AB80A21E8106 for ; Wed, 28 Mar 2012 15:12:22 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA280042673; Thu, 29 Mar 2012 00:11:13 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA14627; Thu, 29 Mar 2012 00:11:11 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= 
Message-Id: <201203282211.AAA14627@TR-Sys.de>
To: dnsext@ietf.org
Date: Thu, 29 Mar 2012 00:11:11 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Subject: [dnsext] rfc6195bis draft : thoughts on CLASS sub-registry
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Reconsidering the section on the DNS CLASSes sub-registry in the
rfc6195bis draft, some thoughts came to my mind.

I'd like to emphasize that this is a rough sketch to solicit
discussion, not a request to change the draft (at this stage).


* RFC 6410 (2-track) emphasizes the criteria for Internet Standard,
  which include removal of unused protocol options that complicate
  implementations and thereby increase the risk of security flaws.

* The only Data CLASSES registered were originally specified in
  RFCs 882+883 (November 1983) and finally standardized in STD 13,
  RFCs 1034+1035 (November 1987), and in non-IETF documents listed
  in the IANA registry with references dating back to June 1981
  and April 1987.  The only other change to the set of assigned
  DNS CLASS codepoints was the addition of QCLASS NONE by RFC 2136
  (April 1997).

  The only Data CLASS in public use is IN, the other registered
  Data CLASSes are used in the contemporary Internet in some
  obscure, implementation-specific manner (with strictly local
  scope) by diagnostic functions built into DNS servers.
  (This clearly is a hack, but it obviously works sufficiently for
  those who know how to use that.)

* Therefore, the addition of new Data CLASSes seems to be a feature
  that does not fulfill a perceived need of the Internet community
  and isn't expected to happen in the foreseeable future.
  Given the significant potential issues with QCLASSes (see below),
  there alse does not seem to exist a need for new QCLASSes, since
  selection among an essentially one-element set of Data CLASSes
  does not admit a great variety of choices anyway.

  Does that mean that we also should *close* the DNS CLASSes IANA
  subregistry with the rfc6195bis draft ?

  Doing so would allow to significantly shorten the text in the
  draft on CLASS value assignment policy.

  Note that there is a CLASS range dedicated for Private Use, which
  could be used anyway for proprietary functions, if deemed useful.

* Delegation in the DNS happens within the namespace of a Data CLASS.
  The current global, unique DNS root only delegates for CLASS=IN.
  Therefore, the QCLASS=* (ANY) defined in STD 13 is rather
  problematic and complicates implementations much more than it
  might be regarded justified by occasional use for curiosity.
  The basic reason is that, due to the independent delegation trees
  for domain names per Data CLASS, queries with QCLASS=* are of no
  practical value, and might even be regarded as conceptionally
  inappropriate.  This already has been observed repeatedly in the
  past, *very long* ago.

  Both RFC 1034 and RFC 1035 already scratch at that idiosyncrasy
  and specify that responses to QCLASS=* can never be authoritative;
  these clauses already were present in RFCs 882+883.

  STD 3, RFC 1123 (s6.1.2.2) says:
   "A query with "QCLASS=*" SHOULD NOT be used unless the requestor
    is seeking data from more than one class. In particular, if the
    requestor is only interested in Internet data types, QCLASS=IN
    MUST be used."
  (Note that the summary table in s6.1.5 contradicts the above;
   the respective check ('X') should be in the "SHOULD NOT" column,
   not in the "SHOULD" column.)
  Use of the DNS on the public Internet per definition is "interested
  in Internet data types" only, so the "SHOULD NOT already applies
  since October 1989.

* Thus, in the sense of RFC 6410, RFCs 1034 and 1035 contain protocol
  elements that complicate implementations, are of no practical
  benefit and de facto not in use -- since two and a half decades.
  Thereby, any revision to STD 13 would have to eliminate such
  feature as QTYPE=* in order to pass the IESG today.

  So the question arises whether it would be wise to now formally
  deprecate QCLASS=* (maybe declare it HISTORIC and NOT RECOMMENDED
  for implementation).

  This could be done in rfc6195bis or in an independent Standards
  Track RFC, but procedurally it would be much less work if done
  in rfc6195bis.  (Note that the I-D targets BCP status and hence
  actually can update Standards Track RFCs.)


Thoughts, opinions?


Kind regards,
  Alfred.

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

From dnsext-bounces@ietf.org  Wed Mar 28 17:16:07 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F407821E8024; Wed, 28 Mar 2012 17:16:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332980167; bh=aLUZmojMJnXjxPtaBHCfq2J7ReWJY3MHm5PoB5q2qxQ=; h=MIME-Version:Date:Message-ID:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=QnFTigX+DcLKoNOm3+vVTiDvIQIMxOZFc6KO70V3hd0ZYZthUgyYkz4fIBQWdEnww X2NaGlHOFOaJu/oZADt5odM83bcgPJ5Sxueuzucx/7dktSXk6v827OPFNUruSzzS1r P33cO7r4+8fErjgJPia27mezX2a463uD+0GnaO6M=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2D321E8020 for ; Wed, 28 Mar 2012 17:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.287
X-Spam-Level: 
X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=0.313,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRXj34YQJ0XM for ; Wed, 28 Mar 2012 17:16:04 -0700 (PDT)
Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2842E21E8024 for ; Wed, 28 Mar 2012 17:16:04 -0700 (PDT)
Received: by iabz21 with SMTP id z21so938805iab.1 for ; Wed, 28 Mar 2012 17:16:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gtR60o4qRAAoAWliTvanFMQ71zG2yzdl1JXVHxlePD4=; b=KrF4+gUXw0axbHXWUl1bjug/2BklK6oD9554/2vaTivCj/8SnnPPcTaJXOxXNsDvYp DbFI/PNcRUnith3mUjNDRGQIEdrV2PjmZkbIY/OOkR1f/+MwYOhnRkokwZt5HZ3GsD9e ILlvq/Rtndrn9RYq8Bdw6QVNJ6k1itHU8P8vkVugIjMHHCSU7LtZndqrWgV/6c0dBYXk zkx7p1Q57xJh6fExF90ab3nGRMCbs6AmYdFPKkAE3sjCz8Nmgi2Ip1KrzQEi7UAiazBF K5i3hTtB7fL/131rhvNp/lMpfcpTBp29eg93ynLFZyLa4e8OI9xoAI1s+f7/4z9kyrxm 3RQQ==
MIME-Version: 1.0
Received: by 10.43.126.68 with SMTP id gv4mr18815328icc.30.1332980163657; Wed, 28 Mar 2012 17:16:03 -0700 (PDT)
Received: by 10.50.171.38 with HTTP; Wed, 28 Mar 2012 17:16:03 -0700 (PDT)
Date: Wed, 28 Mar 2012 19:16:03 -0500
Message-ID: 
From: Jim Fleming 
To: dnsext@ietf.org
Subject: [dnsext] IETF.Fact.Check "The only Data CLASS in public use is IN" ??
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

ZOOM://IETF.Fact.Check "The only Data CLASS in public use is IN" ??

"The only Data CLASS in public use is IN, the other registered
  Data CLASSes are used in the contemporary Internet in some
  obscure, implementation-specific manner (with strictly local
  scope) by diagnostic functions built into DNS servers.
  (This clearly is a hack, but it obviously works sufficiently for
  those who know how to use that.)"

There are 80-bits returned with a typical DNS A-Record Request

32 for the IP Address
32 for the TTL
16 for the CLASS

There are also fields that can be deprecated (re-purposed) in the SOA Record

There is information such as the Top Level Domain that is lost
(tossed) in a DNS Query. The TLD can be encoded in the 16-bit Class
field.

The right-most bits of the 32-bit TTL can be re-purposed because a few
seconds of lost resolution does not matter.

Two A-Records can also combine to provide 64 bits of information.

AAAA Records are handy for generic 128-bit ZOOM Objects

AAAA DNS ~ 60+68 ~ VRHL+000.T1.111+PORT12+ASN30+FRAG6 + LAN4+60+CPE4

V-Version R-Ring(Cloud) HL=01 TTL=0|1 PORT12(P2P .COM 3133)...
(ASN30+FRAG6)
30 = 6x5 ~ Construct Your FREE unique 30-bit ASNs

The Official ZOOM://DNS 5-bit (bbbbb) Alphabets
"0ABCDEFGHIJKLMNOPQRSTUVWXYZ123-."
"0ABCDEFGHIJKLMNOPQRSTUVWXYZ12389"
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 01:01:07 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF83521F897D; Thu, 29 Mar 2012 01:01:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333008067; bh=+q2DFZl/cf+UrnEpYhuN/lNN0n6BTucqc+ieg1Qqt5k=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=eux1mnajLJpSFtRtlfxIk9EkUqqP5Ja84XueHpDXO0b4L8edo1PMgJTAltVOqc4F3 ECQGHFLIl3aUk4hZL/MHPSra4vkObI/wbtTMI6nAIYzIFoXyXxKbphUHrnkphWgKYB zfV9343tK+OnAJB1sMkqnQL3TgX8D5Dp1LudaNWs=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEAA21F897D for ; Thu, 29 Mar 2012 01:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.371
X-Spam-Level: 
X-Spam-Status: No, score=-106.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR3EQvAiqFHU for ; Thu, 29 Mar 2012 01:01:06 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1D621F86BD for ; Thu, 29 Mar 2012 01:01:06 -0700 (PDT)
Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2T810r5095777; Thu, 29 Mar 2012 04:01:01 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [192.168.130.74] by Work-Laptop-2.local (PGP Universal service); Thu, 29 Mar 2012 10:01:02 +0200
X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 29 Mar 2012 10:01:02 +0200
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <2E875509-4B39-4876-806D-E8FE49F83B9E@gmail.com>
References: <201203271402.QAA03645@TR-Sys.de> <2E875509-4B39-4876-806D-E8FE49F83B9E@gmail.com>
Date: Thu, 29 Mar 2012 09:55:12 +0200
To: Scott Rose 
From: Edward Lewis 
X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4
Cc: dnsext@ietf.org
Subject: Re: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-05
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Okay, I admit that this is a derailment attempt.

This document started out as an effort to negotiate what information 
was sent in a DNS message exchange.  The document now describes a 
means for a querier to signal something about its capability.

Sitting around the venue and gabbing, what if we expand on this?  Why 
limit the capability advertisement to just DNSSEC algorithms.  An 
idea that was floated was to represent the RFCs the querier complies 
with (ohh, that "c" word).  Further expanding on this, conformance 
with a general (i.e., not-an-RFC) document could be done via a 
reference in some new IANA document registry.

Compliance - this would require a means to, in a binary way, define 
compliance with an RFC.  That would take some ground breaking work.

These comments aren't meant to stop the current document processing 
bureaucracy from proceeding but offered as food for thought.  It it 
foreseeable that in 10-15 years we will have lots of things change in 
the DNS.  We know that we lack any version management capability (the 
RFC that defined SHA256 for DS hashes mentions this).  Although it 
will be an eon before we have one, we have to start somewhere.  And 
maybe the current document, such as it is, is the first step.  But in 
talking to people here this week, we could expand the idea.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 01:43:17 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F55E21F891E; Thu, 29 Mar 2012 01:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333010597; bh=SUNzLnLe0HapywZA6S3Bz00i8/SqDJNyAAH6ck6qILY=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=CML/+k9Wr24KuSZ0HmEZzujM+C1zkG+m6KeLIfhEM3EKtM/v1NcgLzS1IkDNDENXt /NfxFX5y1dHbnRBU91JFB4jphWVHYZl32IcHEeCQ7Da/GOEeRjnvCzeBEtc4ZcuC7I xiusuCRdSAxwJD5n5Qp79/pfRQmylonfgXMK/LT0=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42A821F891E for ; Thu, 29 Mar 2012 01:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level: 
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+iNaH-wBOuN for ; Thu, 29 Mar 2012 01:43:16 -0700 (PDT)
Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2B621F88D8 for ; Thu, 29 Mar 2012 01:43:15 -0700 (PDT)
Received: by elektron.atoom.net (Postfix, from userid 1000) id AB24E3FECD; Thu, 29 Mar 2012 10:43:13 +0200 (CEST)
Date: Thu, 29 Mar 2012 10:43:13 +0200
From: Miek Gieben 
To: dnsext@ietf.org
Message-ID: <20120329084313.GC10653@miek.nl>
Mail-Followup-To: dnsext@ietf.org
References: <201203271402.QAA03645@TR-Sys.de> <2E875509-4B39-4876-806D-E8FE49F83B9E@gmail.com> 
MIME-Version: 1.0
In-Reply-To: 
User-Agent: Vim/Mutt/Linux
X-Home: http://www.miek.nl
Subject: Re: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-05
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============2727130987625932493=="
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

--===============2727130987625932493==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="Bu8it7iiRSEf40bY"
Content-Disposition: inline


--Bu8it7iiRSEf40bY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

[ Quoting  in "Re: [dnsext] WGLC on draft-ietf-dns..." ]
> These comments aren't meant to stop the current document processing
> bureaucracy from proceeding but offered as food for thought.  It it
> foreseeable that in 10-15 years we will have lots of things change in
> the DNS.  We know that we lack any version management capability (the
> RFC that defined SHA256 for DS hashes mentions this).  Although it
> will be an eon before we have one, we have to start somewhere.  And
> maybe the current document, such as it is, is the first step.  But in
> talking to people here this week, we could expand the idea.

I, for one, like this. Another IANA registry is one step too far I guess, but
re-using RFC numbers like this seems like an elegant solution.

Regards,
Miek Gieben

--Bu8it7iiRSEf40bY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk90IKEACgkQJYuFzziA0PackwCbBNdFbfg1QXgBmudAEkDwhjxi
phcAn06bNApQXRrZC4LMtEkwdh8EvMpL
=rrLu
-----END PGP SIGNATURE-----

--Bu8it7iiRSEf40bY--

--===============2727130987625932493==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============2727130987625932493==--

From dnsext-bounces@ietf.org  Thu Mar 29 01:55:19 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3B921F89D5; Thu, 29 Mar 2012 01:55:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333011318; bh=akxdyy4bZvlpGMLLVteFNpNsbVZ6jaPknftKOQ3zaz0=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=FwbDXZoGagcNJ7rNx76jGir4S7xWHOH2tX9uENr89U+KETr20YIvzwqu19n6c6tXz bBlKeV0ycbOxpPgoQVBfyDjp/1S6dtME7pXFuTAvrD0PORZ+V6fs/dQTBmF07eCjSY 7JTVP1mdWxL9ukfHIx1tHuYe5TK9MQ0KXs6Q8Tks=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0FF21F89D5 for ; Thu, 29 Mar 2012 01:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.47
X-Spam-Level: 
X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abQQ5lZVPiTQ for ; Thu, 29 Mar 2012 01:55:16 -0700 (PDT)
Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id E83FA21F89D3 for ; Thu, 29 Mar 2012 01:55:15 -0700 (PDT)
Received: from [217.39.12.114] (HELO pc0179.pcad.btopenzone.com) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 20366045; Thu, 29 Mar 2012 08:56:50 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
From: Steve Crocker 
In-Reply-To: <20120329084313.GC10653@miek.nl>
Date: Thu, 29 Mar 2012 09:55:15 +0100
Message-Id: <70F4F18F-1615-4481-A5E1-3246FB5BABCD@shinkuro.com>
References: <201203271402.QAA03645@TR-Sys.de> <2E875509-4B39-4876-806D-E8FE49F83B9E@gmail.com>  <20120329084313.GC10653@miek.nl>
To: dnsext@ietf.org
X-Mailer: Apple Mail (2.1084)
Subject: Re: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-05
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Miek and Ed,

I'm all in favor of longer term of supporting smooth transitions in the future.  We're paying a huge price with IPv6 for not having done so with addresses, and we are and will continue to have similar problems in other areas.  That said, two comments:

1. I think it's worth moving the present document forward so we can measure the uptake of new algorithms in DNSSEC.  I think the need for algorithm transition is coming sooner than many expect.

2. The specific suggestion of referencing RFCs instead of IANA registry tables is intriguing.  I can see advantages, but I can also see possible problems.  I think the proposed scheme needs a bit of discussion and a design note before moving this forward.

Thanks,

Steve


On Mar 29, 2012, at 9:43 AM, Miek Gieben wrote:

> [ Quoting  in "Re: [dnsext] WGLC on draft-ietf-dns..." ]
>> These comments aren't meant to stop the current document processing
>> bureaucracy from proceeding but offered as food for thought.  It it
>> foreseeable that in 10-15 years we will have lots of things change in
>> the DNS.  We know that we lack any version management capability (the
>> RFC that defined SHA256 for DS hashes mentions this).  Although it
>> will be an eon before we have one, we have to start somewhere.  And
>> maybe the current document, such as it is, is the first step.  But in
>> talking to people here this week, we could expand the idea.
> 
> I, for one, like this. Another IANA registry is one step too far I guess, but
> re-using RFC numbers like this seems like an elegant solution.
> 
> Regards,
> Miek Gieben
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext

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

From dnsext-bounces@ietf.org  Thu Mar 29 02:17:58 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36AC21F88AE; Thu, 29 Mar 2012 02:17:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333012677; bh=gBej7eqyAj408PsCLCOKj1hKThUG8GDFW+Xf2EEgzhk=; h=Mime-Version:Message-Id:Date:To:From:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=h9a4Tf7neEcX0ggIhA5Uk7C2DurKQEl4gLKFxbacMJpr8Fm3IjWq1ugD5IVXXn0UN Sjo3BohHSjrLoa1pipLSs3mLCobDCgXOyKb2ss+1wWfWrj9wV7ge/t/u4o7txQ4JU7 kK8JrhfG5MeKrlnHVbhI4shHIPx8ua/bn40y9keo=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043BB21F886C for ; Thu, 29 Mar 2012 02:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.379
X-Spam-Level: 
X-Spam-Status: No, score=-106.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAe2gs838yT9 for ; Thu, 29 Mar 2012 02:17:55 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id BC31A21F888D for ; Thu, 29 Mar 2012 02:17:54 -0700 (PDT)
Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2T9HXXU096747; Thu, 29 Mar 2012 05:17:53 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [192.168.130.74] by Work-Laptop-2.local (PGP Universal service); Thu, 29 Mar 2012 11:17:53 +0200
X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 29 Mar 2012 11:17:53 +0200
Mime-Version: 1.0
Message-Id: 
Date: Thu, 29 Mar 2012 11:17:30 +0200
To: dnsext@ietf.org
From: Edward Lewis 
X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4
Cc: ed.lewis@neustar.biz
Subject: [dnsext] Want this to be a WG doc?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Any thoughts on whether the following would be a DNSEXT document? 
I'm asking DNSOP too.

http://tools.ietf.org/html/draft-lewis-dns-undocumented-types-01

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

2012...time to reuse those 1984 calendars!
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 04:07:09 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33AE21F850B; Thu, 29 Mar 2012 04:07:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333019229; bh=Rjp6yb7wXPKMSewMOJmLdIoZxh6RywjqRqGiftL1uOk=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=UBy3mBcql6b4/IY8qvT5gftMJRM4AN2RqWsmmnyIYq8UlNOzJPx5oa1H2j09hxWHa Lwajxq8+c6muBD7D+0XyuFHkizvnyKMbIiszg0KpKvVvE6h8y94eFXjF7GLAtowUe0 /EWBrj/ezUeC5S2QubjJGWLnvw5kyjDsSZF88ZQo=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A328121F84EC for ; Thu, 29 Mar 2012 04:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.526
X-Spam-Level: 
X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVITP9Q6HxLz for ; Thu, 29 Mar 2012 04:07:07 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id E58F521F88F2 for ; Thu, 29 Mar 2012 04:07:06 -0700 (PDT)
Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2TB74hJ097635 for ; Thu, 29 Mar 2012 07:07:05 -0400 (EDT) (envelope-from ogud@ogud.com)
Message-ID: <4F744259.3000906@ogud.com>
Date: Thu, 29 Mar 2012 13:07:05 +0200
From: Olafur Gudmundsson 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: dnsext@ietf.org
References: 
In-Reply-To: 
X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4
Subject: Re: [dnsext] Want this to be a WG doc?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

On 29/03/2012 11:17, Edward Lewis wrote:
> Any thoughts on whether the following would be a DNSEXT document? I'm
> asking DNSOP too.
>
> http://tools.ietf.org/html/draft-lewis-dns-undocumented-types-01
>


FWIW, this document is inside the WG scope,
Consider this an official request for comments if there are people in 
this group willing to work on reviewing and assisting Ed in pushing this 
document out.

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

From dnsext-bounces@ietf.org  Thu Mar 29 04:18:40 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98CC21F893E; Thu, 29 Mar 2012 04:18:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333019920; bh=zv+1ULCSP9Rf2OnUpj1RZp7jJHb+4veT42/J3m97gKw=; h=Date:From:To:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=f3rz0sY6WALnLvPWUNjhZlVf/Iyn105zwsZ6FpM3ayxGD6VNF3+tkTz4irwOiEkR2 +RKv6pAqb4nnDlMWXABZ8kkZVSbnr7yZGvHsDUaJoINeaviGFtrFcNY5OsL6mze4XM K1E2zrgKYu1sdxW8DMmYtEmmw/9tM4bJHvTnpiL4=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B257321F893E for ; Thu, 29 Mar 2012 04:18:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.336
X-Spam-Level: 
X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.264,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UICEqm+XxrPY for ; Thu, 29 Mar 2012 04:18:38 -0700 (PDT)
Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E27621F893B for ; Thu, 29 Mar 2012 04:18:38 -0700 (PDT)
Received: by elektron.atoom.net (Postfix, from userid 1000) id 6CDFA3FF43; Thu, 29 Mar 2012 13:18:37 +0200 (CEST)
Date: Thu, 29 Mar 2012 13:18:37 +0200
From: Miek Gieben 
To: dnsext list 
Message-ID: <20120329111837.GB17832@miek.nl>
Mail-Followup-To: dnsext list 
MIME-Version: 1.0
User-Agent: Vim/Mutt/Linux
X-Home: http://www.miek.nl
Subject: [dnsext] draft-levine-dnsextlang-02
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============6932361656479215131=="
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

--===============6932361656479215131==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t"
Content-Disposition: inline


--mojUlQ0s9EVzWg2t
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

I've read the draft and it's a nice idea. I have a couple of questions/rema=
rks though.

* Base32 should be supported in the rdata (for NSEC3).
* There probably should be an rdata type called BitMap (for NSEC/NSEC3).
* NSEC3 has a salt length which isn't used in the text representation of the
  record. How is this handled?
* The HIP record also has fields not used in the text representation: "PK l=
ength
  field".
* The HIP record ends with an array of domain names. How should that be enc=
oded?
  Same holds true for TXT records.
* The HIP contains a base64 field that can not contain spaces in the
  presentation format (unlike all other b64 fields in other RRs). How to de=
al
  with that?
* The IPSECKEY RR uses some internal subtyping: if "gatewaytype" is 0 there=
 is no
  gateway. If it is 1 or 2 its an IP address and if its 3 the gateway is a
  domain name. How to encode that?

Kind regards,

--=20
    Miek Gieben

--mojUlQ0s9EVzWg2t
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk90RQ0ACgkQJYuFzziA0PYahACg1pqL8F4xOaEvBdca2lLK7SWr
0a4AniVbuf6elrGGaR4YdL5MGUE9jGAU
=ECjr
-----END PGP SIGNATURE-----

--mojUlQ0s9EVzWg2t--

--===============6932361656479215131==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============6932361656479215131==--

From dnsext-bounces@ietf.org  Thu Mar 29 04:24:02 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7074221F8812; Thu, 29 Mar 2012 04:24:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333020242; bh=aya8sRYr3CExsx9ycbHGv4D6hRp0Nlw61GPFPkiWqXk=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=d3D577GsqKFillhOVGsFihqAIEvmc70Wdulfdt4371cImQmnVmpaJAx0OAbnFYVGb u0n1jLUC3fuwVoaoDfq47JuIvzzTjPkjsFqQi+C7yc44i/B0XhzwyXpPZL1DpMBbcX JBH+igMKdMx2Iq+PWZro4JLi7NbCjAXPvs1WNP0E=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1C021F8913 for ; Thu, 29 Mar 2012 04:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.472
X-Spam-Level: 
X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hYHG5gZXqCO for ; Thu, 29 Mar 2012 04:23:53 -0700 (PDT)
Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEB721F880C for ; Thu, 29 Mar 2012 04:23:53 -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-2.csi.cam.ac.uk ([131.111.8.54]:35299) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SDDSJ-0003EW-EM (Exim 4.72) (return-path ); Thu, 29 Mar 2012 12:23:51 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SDDSJ-0007LY-DD (Exim 4.67) (return-path ); Thu, 29 Mar 2012 12:23:51 +0100
Date: Thu, 29 Mar 2012 12:23:51 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Edward Lewis 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Want this to be a WG doc?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Edward Lewis  wrote:

> Any thoughts on whether the following would be a DNSEXT document? I'm asking
> DNSOP too.
>
> http://tools.ietf.org/html/draft-lewis-dns-undocumented-types-01

Having gone through the IANA RR type registry recently, this is quite a
useful document :-)

There's a nit in section 2.0: there is no need to consider downcasing or
compression, since RFCs 3597 and 4034 completely specify which RRs are
subject to these modifications.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Plymouth, Biscay: Northeast 3 or 4, occasionally 5 in Biscay. Slight or
moderate. Mainly fair. Moderate, occasionally poor.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 04:45:32 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FF121F897D; Thu, 29 Mar 2012 04:45:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333021532; bh=PdOJOGQEzFigM52VyH8MnsECOMcBdvdxfR6yupyrdPs=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=c5r40BdphvzWJJcOkB8x3k6FiE2ENfgCMaSjsMiSuBc1f6CfapF0UXraQ3QZGVgVN Xix/7cPmHu2zzELT90G/YmKLbR4gVItAslRY+uwkZxA1jhNroBbkEEaCGpFfVeSjdr JiP/sX8mokiwzdkmhqCs19zXbJMCKMvtqZgTxD6o=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16B021F8913 for ; Thu, 29 Mar 2012 04:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.474
X-Spam-Level: 
X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHO8NDX2YpEx for ; Thu, 29 Mar 2012 04:45:28 -0700 (PDT)
Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id EDB8621F89E2 for ; Thu, 29 Mar 2012 04:45:25 -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-2.csi.cam.ac.uk ([131.111.8.54]:52987) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SDDn8-0007yv-Fa (Exim 4.72) (return-path ); Thu, 29 Mar 2012 12:45:23 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SDDn8-00029m-7m (Exim 4.67) (return-path ); Thu, 29 Mar 2012 12:45:22 +0100
Date: Thu, 29 Mar 2012 12:45:22 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Miek Gieben 
In-Reply-To: <20120329111837.GB17832@miek.nl>
Message-ID: 
References: <20120329111837.GB17832@miek.nl>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Cc: dnsext list 
Subject: Re: [dnsext] draft-levine-dnsextlang-02
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Miek Gieben  wrote:
>
> * Base32 should be supported in the rdata (for NSEC3).
> * There probably should be an rdata type called BitMap (for NSEC/NSEC3).

Yes.

> * NSEC3 has a salt length which isn't used in the text representation of the
>   record. How is this handled?

There should probably be a qualifier for a length prefix on hex data, as
there is for base64.

> * The HIP record also has fields not used in the text representation: "PK length
>   field".
> * The HIP record ends with an array of domain names. How should that be encoded?
> * The HIP contains a base64 field that can not contain spaces in the
>   presentation format (unlike all other b64 fields in other RRs). How to deal
>   with that?

HIP RDATA is horrible. It would be slightly easier if the length fields
prefixed the data they describe. The non-standard base64 restriction is
ugly. The rendezvois servers should probably be listed in separate RRs of
a different type, which would also solve the base64 problem. I think that
awkward RRtypes like this should have special case handling, e.g. describe
the RDATA as a single field of HIP type, or just leave it to RFC 3597
generic representation.

Ideally in the future RRDATA layouts will be simpler than this.

>   Same holds true for TXT records.

There are qualifiers to specify multi-field textual data.

> * The IPSECKEY RR uses some internal subtyping: if "gatewaytype" is 0 there is no
>   gateway. If it is 1 or 2 its an IP address and if its 3 the gateway is a
>   domain name. How to encode that?

Again I think this has to be handled in special case code. Really they
should have used a different RR type for each layout.

Another awkward case is the variable-length IPv6 address field in A6
records, but that has been deprecated forcefully enough that it is no
problem to handle with RFC 3597 generic layout.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Dogger: Northwesterly 5 or 6, occasionally 7 in northeast. Moderate or rough.
Fair. Moderate or good.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 04:47:55 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43E321F8790; Thu, 29 Mar 2012 04:47:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333021675; bh=r3zbaVzOuVEa1cvVVZiYHUhoCxZx7X2BKbIMm2Q4QY4=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=TZOiJJBeEEX2rOif75FFEYaLflKX6fW6GnFtOWiqa2iVJ4FURe//DJvO/LvhH+S+H SW9efAkAUC8EqK+8D1UOoKiGR2ZlG1PBb//YUVLoz/G3hd/h2ilqDtVV60xG8EX7mF Jom4YKhd8u9LPxnMxMNRl3wa+Akm173VhVghY7PU=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C107421F8790 for ; Thu, 29 Mar 2012 04:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.392
X-Spam-Level: 
X-Spam-Status: No, score=-106.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 632zoifsp06z for ; Thu, 29 Mar 2012 04:47:54 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id B3F7821F878A for ; Thu, 29 Mar 2012 04:47:53 -0700 (PDT)
Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2TBlmLt098082; Thu, 29 Mar 2012 07:47:49 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [192.168.130.74] by Work-Laptop-2.local (PGP Universal service); Thu, 29 Mar 2012 13:47:50 +0200
X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 29 Mar 2012 13:47:50 +0200
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  
Date: Thu, 29 Mar 2012 13:47:46 +0200
To: Tony Finch 
From: Edward Lewis 
X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4
Cc: Edward Lewis , dnsext@ietf.org
Subject: Re: [dnsext] Want this to be a WG doc?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

At 12:23 +0100 3/29/12, Tony Finch wrote:
>Edward Lewis  wrote:
>
>>  Any thoughts on whether the following would be a DNSEXT document? I'm asking
>>  DNSOP too.
>>
>>  http://tools.ietf.org/html/draft-lewis-dns-undocumented-types-01
>
>Having gone through the IANA RR type registry recently, this is quite a
>useful document :-)
>
>There's a nit in section 2.0: there is no need to consider downcasing or
>compression, since RFCs 3597 and 4034 completely specify which RRs are
>subject to these modifications.

3597 and 4034 only mention if you have to do compression/down casing, 
not where in the RDATA the domain names appear.

I should have rephrased that as a question...I mean, given that, do 
you still think there's no need to mention?

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

2012...time to reuse those 1984 calendars!
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 04:55:38 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5095F21F89B3; Thu, 29 Mar 2012 04:55:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333022138; bh=k6ap2R6WTBkwgmDWv9IeV7c8x3C9fPoqdbihPkhrWW4=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=jWTQEFQFv/FMS4Db5Ljurbxg1JTWSN2cHcQI2QnoV408/VVUQG7OEB+uWrfjpjA/y Ds8TYTBgsBXEHGnWed8x9oHzpdb38fGLC0VrR6oN16yE/CkVCRKaq9Fvfk6IIFYj/M 5EJPrDUD4ZRiq2LnCpMOSYaTu4aUg+Bz35eaq5d0=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9A821F89B7 for ; Thu, 29 Mar 2012 04:55:35 -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.243,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKNihMppcgVs for ; Thu, 29 Mar 2012 04:55:33 -0700 (PDT)
Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7277421F89AB for ; Thu, 29 Mar 2012 04:55:31 -0700 (PDT)
Received: by elektron.atoom.net (Postfix, from userid 1000) id 23FBB3FEB4; Thu, 29 Mar 2012 13:55:30 +0200 (CEST)
Date: Thu, 29 Mar 2012 13:55:30 +0200
From: Miek Gieben 
To: dnsext list 
Message-ID: <20120329115529.GD17832@miek.nl>
Mail-Followup-To: dnsext list 
References: <20120329111837.GB17832@miek.nl> 
MIME-Version: 1.0
In-Reply-To: 
User-Agent: Vim/Mutt/Linux
X-Home: http://www.miek.nl
Subject: Re: [dnsext] draft-levine-dnsextlang-02
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============5994567891568749375=="
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

--===============5994567891568749375==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="+KJYzRxRHjYqLGl5"
Content-Disposition: inline


--+KJYzRxRHjYqLGl5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[ Quoting  in "Re: [dnsext] draft-levine-dnsextlan..." ]
> > * NSEC3 has a salt length which isn't used in the text representation o=
f the
> >   record. How is this handled?
>=20
> There should probably be a qualifier for a length prefix on hex data, as
> there is for base64.

Can you just say "this is length of the NEXT item"? Or does it need to be
generic "this is the length of item , which is more of a poin=
ter.
=20
> HIP RDATA is horrible. It would be slightly easier if the length fields
> prefixed the data they describe. The non-standard base64 restriction is
> ugly. The rendezvois servers should probably be listed in separate RRs of
> a different type, which would also solve the base64 problem. I think that
> awkward RRtypes like this should have special case handling, e.g. describe
> the RDATA as a single field of HIP type, or just leave it to RFC 3597
> generic representation.

Agreed, using 3597 syntax for such ugly RRs is probably the best.

> Ideally in the future RRDATA layouts will be simpler than this.

Well, an idea I have floating in my mind is: if your (new) RR can not
be described in terms of dnsextlang, you should think of a different
syntax. Not supporting the HIP record would help in that regard.

> > * The IPSECKEY RR uses some internal subtyping: if "gatewaytype" is 0 t=
here is no
> >   gateway. If it is 1 or 2 its an IP address and if its 3 the gateway i=
s a
> >   domain name. How to encode that?
>=20
> Again I think this has to be handled in special case code. Really they
> should have used a different RR type for each layout.

As you said, why not avoid this whole mess and use 3597?

> Another awkward case is the variable-length IPv6 address field in A6
> records, but that has been deprecated forcefully enough that it is no
> problem to handle with RFC 3597 generic layout.

Are we now creating a hall of shame for badly designed RRs? :)

 Regards,

--=20
    Miek Gieben

--+KJYzRxRHjYqLGl5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk90TbEACgkQJYuFzziA0PbkAQCeP/V7Sri2NLYM9MeYTG5HFxs6
NkYAn3MrCuQj4gHV46DSzrIqLA+aN78c
=RPB1
-----END PGP SIGNATURE-----

--+KJYzRxRHjYqLGl5--

--===============5994567891568749375==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============5994567891568749375==--

From dnsext-bounces@ietf.org  Thu Mar 29 04:57:10 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1EA21F84EE; Thu, 29 Mar 2012 04:57:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333022230; bh=cAsZ9Agd8zIWUHDGJfCxE6rd5FOfUulEEiEorw4F2Ig=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=n/Qx3/G4gK9FREMLVlWYJNZEIqBT4NY0KjJ+ciY3Fgjkjgy/F2Yc6QLXXaAkRE0e0 CfzV0eCFzc/z9DId/888vWGAfTn1a47+nypdUJBtdugD0bsvd0xHXY2TyqIkprVrzh ggXVdkc8QNqOzJtsWvLMpzQSbjYpYvnR9+zqtLrA=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B3621F84EE for ; Thu, 29 Mar 2012 04:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.476
X-Spam-Level: 
X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA7dUf7y7ZuS for ; Thu, 29 Mar 2012 04:57:08 -0700 (PDT)
Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 75E4821F84DA for ; Thu, 29 Mar 2012 04:57:08 -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-2.csi.cam.ac.uk ([131.111.8.54]:45228) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SDDyV-0004mf-FR (Exim 4.72) (return-path ); Thu, 29 Mar 2012 12:57:07 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SDDyV-0003qP-OJ (Exim 4.67) (return-path ); Thu, 29 Mar 2012 12:57:07 +0100
Date: Thu, 29 Mar 2012 12:57:07 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Edward Lewis 
In-Reply-To: 
Message-ID: 
References:   
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Want this to be a WG doc?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Edward Lewis  wrote:
>
> 3597 and 4034 only mention if you have to do compression/down casing, not
> where in the RDATA the domain names appear.
>
> I should have rephrased that as a question...I mean, given that, do you still
> think there's no need to mention?

Yes I think there is no need to mention compresstion and downcasing since
they do not apply to any of these RR types. From the point of the DNS they
are all blobs.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Fair Isle, Faeroes: Northwest 5 to 7. Moderate or rough. Rain and drizzle then
fair. Moderate or good, occasionally poor.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 05:01:36 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817DA21F8A2D; Thu, 29 Mar 2012 05:01:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333022496; bh=baMwSdbDwQRtdYqPAhSeiqyO9OXEoAA3cGr5sKnKo78=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=b1vOu5Wvo82NS0OzX0QVPToIAefcBs3eJFkEZwGx2i87g1GtvffjTZMRUfyn5vyc1 B66mDAm4eVkEgfmOxlNTupjBvfdvCrheq8OoEB9rhb2KMIcjs9mJTPmer8PwnOaAxr 2BPB1SUaBXEh0/jEjdo5HhhlU3dGd5yON3Na1T90=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C21621F8A2D for ; Thu, 29 Mar 2012 05:01:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.478
X-Spam-Level: 
X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyK9pz6o2e3f for ; Thu, 29 Mar 2012 05:01:34 -0700 (PDT)
Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 4531C21F8A2C for ; Thu, 29 Mar 2012 05:01:34 -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-2.csi.cam.ac.uk ([131.111.8.54]:43594) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SDE2n-0007xx-Eg (Exim 4.72) (return-path ); Thu, 29 Mar 2012 13:01:33 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SDE2n-0004Za-9W (Exim 4.67) (return-path ); Thu, 29 Mar 2012 13:01:33 +0100
Date: Thu, 29 Mar 2012 13:01:33 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Miek Gieben 
In-Reply-To: <20120329115529.GD17832@miek.nl>
Message-ID: 
References: <20120329111837.GB17832@miek.nl>  <20120329115529.GD17832@miek.nl>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Cc: dnsext list 
Subject: Re: [dnsext] draft-levine-dnsextlang-02
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Miek Gieben  wrote:
>
> Can you just say "this is length of the NEXT item"? Or does it need to be
> generic "this is the length of item , which is more of a pointer.

Maybe. At the moment there's a very nice one-to-one correspondence between
fields described by the language and as they appear in master files, and
on the wire if you regard a length prefix as part of the field.

> Well, an idea I have floating in my mind is: if your (new) RR can not
> be described in terms of dnsextlang, you should think of a different
> syntax. Not supporting the HIP record would help in that regard.

Yes :-)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Forties, Cromarty: Northwesterly 5 to 7. Moderate or rough. Mainly fair. Good,
occasionally poor.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 05:09:23 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E7A21F8A62; Thu, 29 Mar 2012 05:09:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333022963; bh=KExnIi5cO3umqtaLYCY0PpY5/R+NCNjSwA0Mbp9t9d8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=OB6J9uWs7as+Dc6eh/4al8fbNBLd82vqTQAFGM3wPNTAl8ThFwJBAMy+mJGCiwle7 hr1wbyGkTg5DEk7qeNUDbmyZnwMhE7gpt81qsIm+goF8VZ/i4Zz3nOvFzivuTzVs7h icq7L4ie1861VII3ajg5icLugB/LOWBEl28LblVY=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66D421F8A62 for ; Thu, 29 Mar 2012 05:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.65
X-Spam-Level: 
X-Spam-Status: No, score=-103.65 tagged_above=-999 required=5 tests=[AWL=-1.551, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC4mzcvSmWbz for ; Thu, 29 Mar 2012 05:09:22 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E8CDE21F8A2C for ; Thu, 29 Mar 2012 05:09:17 -0700 (PDT)
Received: by lagj5 with SMTP id j5so2858779lag.31 for ; Thu, 29 Mar 2012 05:09:16 -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:content-transfer-encoding; bh=dCmUXTwR3WAM4V4yg0DSGEXEiDHYNx5pwzyBwrwnJyM=; b=iwRqaAnhAci1i3mK2YHGKOB9tAGt9bPylhEdYrldqVQcwmWpYb7ftadig3cOq+yzFN G8i2wKHMP0H4wqxz9jXy6Ww6SSqGwF6B8ezBagJVC7H+DZfyAqzBYOtGO254FEjH1/KP dp5AVFssZ7bo8s79caLdi6vVJB1viAo7nrtMXydIhtsbu/6CJyI48N3T7C1lKqHSTbm1 DE8KJ9lRaK5Z1q8ZEoAul/q2+FEMlL+iKuWuSWNUJX7rMMkXzjGutduO6TsWPwbcglK5 ywpTcP3OZDKMfyT5dE5ZR5W7DxkKrjAGqTa4pWo3ES2coOFpqlP00YT8+W2hAG7wyr13 bT9Q==
Received: by 10.152.146.39 with SMTP id sz7mr27707542lab.3.1333022956845; Thu, 29 Mar 2012 05:09:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.21.162 with HTTP; Thu, 29 Mar 2012 05:08:56 -0700 (PDT)
In-Reply-To: <201203282211.AAA14627@TR-Sys.de>
References: <201203282211.AAA14627@TR-Sys.de>
From: Donald Eastlake 
Date: Thu, 29 Mar 2012 08:08:56 -0400
Message-ID: 
To: =?ISO-8859-1?Q?Alfred_H=CEnes?= 
Cc: dnsext@ietf.org
Subject: Re: [dnsext] rfc6195bis draft : thoughts on CLASS sub-registry
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

I am opposed to closes the CLASS registry. The key feature of
alternative data CLASSes is that each CLASS can have independent
roots. The availability of this escape from monolithic control of
CLASS=3DIN is, in my mind, very important even if it has not yet been
used.

Don't bother telling me about how impractical you think it would be to
actually use, say, CLASS=3D42. If there were a big enough problem,
people who care would be motived to make it work and would probably be
just the same sort of people who could evade or avoid problematic
middle-boxes.

I don't care that much either way about deprecating use/implementation
of CLASS=3D* in queries but the use of new meta CLASS values in other
operations may be useful.

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

On Wed, Mar 28, 2012 at 6:11 PM, Alfred H=CEnes  wrote:
> Reconsidering the section on the DNS CLASSes sub-registry in the
> rfc6195bis draft, some thoughts came to my mind.
>
> I'd like to emphasize that this is a rough sketch to solicit
> discussion, not a request to change the draft (at this stage).
>
>
> * RFC 6410 (2-track) emphasizes the criteria for Internet Standard,
> =A0which include removal of unused protocol options that complicate
> =A0implementations and thereby increase the risk of security flaws.
>
> * The only Data CLASSES registered were originally specified in
> =A0RFCs 882+883 (November 1983) and finally standardized in STD 13,
> =A0RFCs 1034+1035 (November 1987), and in non-IETF documents listed
> =A0in the IANA registry with references dating back to June 1981
> =A0and April 1987. =A0The only other change to the set of assigned
> =A0DNS CLASS codepoints was the addition of QCLASS NONE by RFC 2136
> =A0(April 1997).
>
> =A0The only Data CLASS in public use is IN, the other registered
> =A0Data CLASSes are used in the contemporary Internet in some
> =A0obscure, implementation-specific manner (with strictly local
> =A0scope) by diagnostic functions built into DNS servers.
> =A0(This clearly is a hack, but it obviously works sufficiently for
> =A0those who know how to use that.)
>
> * Therefore, the addition of new Data CLASSes seems to be a feature
> =A0that does not fulfill a perceived need of the Internet community
> =A0and isn't expected to happen in the foreseeable future.
> =A0Given the significant potential issues with QCLASSes (see below),
> =A0there alse does not seem to exist a need for new QCLASSes, since
> =A0selection among an essentially one-element set of Data CLASSes
> =A0does not admit a great variety of choices anyway.
>
> =A0Does that mean that we also should *close* the DNS CLASSes IANA
> =A0subregistry with the rfc6195bis draft ?
>
> =A0Doing so would allow to significantly shorten the text in the
> =A0draft on CLASS value assignment policy.
>
> =A0Note that there is a CLASS range dedicated for Private Use, which
> =A0could be used anyway for proprietary functions, if deemed useful.
>
> * Delegation in the DNS happens within the namespace of a Data CLASS.
> =A0The current global, unique DNS root only delegates for CLASS=3DIN.
> =A0Therefore, the QCLASS=3D* (ANY) defined in STD 13 is rather
> =A0problematic and complicates implementations much more than it
> =A0might be regarded justified by occasional use for curiosity.
> =A0The basic reason is that, due to the independent delegation trees
> =A0for domain names per Data CLASS, queries with QCLASS=3D* are of no
> =A0practical value, and might even be regarded as conceptionally
> =A0inappropriate. =A0This already has been observed repeatedly in the
> =A0past, *very long* ago.
>
> =A0Both RFC 1034 and RFC 1035 already scratch at that idiosyncrasy
> =A0and specify that responses to QCLASS=3D* can never be authoritative;
> =A0these clauses already were present in RFCs 882+883.
>
> =A0STD 3, RFC 1123 (s6.1.2.2) says:
> =A0 "A query with "QCLASS=3D*" SHOULD NOT be used unless the requestor
> =A0 =A0is seeking data from more than one class. In particular, if the
> =A0 =A0requestor is only interested in Internet data types, QCLASS=3DIN
> =A0 =A0MUST be used."
> =A0(Note that the summary table in s6.1.5 contradicts the above;
> =A0 the respective check ('X') should be in the "SHOULD NOT" column,
> =A0 not in the "SHOULD" column.)
> =A0Use of the DNS on the public Internet per definition is "interested
> =A0in Internet data types" only, so the "SHOULD NOT already applies
> =A0since October 1989.
>
> * Thus, in the sense of RFC 6410, RFCs 1034 and 1035 contain protocol
> =A0elements that complicate implementations, are of no practical
> =A0benefit and de facto not in use -- since two and a half decades.
> =A0Thereby, any revision to STD 13 would have to eliminate such
> =A0feature as QTYPE=3D* in order to pass the IESG today.
>
> =A0So the question arises whether it would be wise to now formally
> =A0deprecate QCLASS=3D* (maybe declare it HISTORIC and NOT RECOMMENDED
> =A0for implementation).
>
> =A0This could be done in rfc6195bis or in an independent Standards
> =A0Track RFC, but procedurally it would be much less work if done
> =A0in rfc6195bis. =A0(Note that the I-D targets BCP status and hence
> =A0actually can update Standards Track RFCs.)
>
>
> Thoughts, opinions?
>
>
> Kind regards,
> =A0Alfred.
>
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 06:55:25 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB24A21F8B9D; Thu, 29 Mar 2012 06:55:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333029320; bh=8UJDEpehYvKNTLN07yb4s4u0nwlyd8I0DOqvLj7cj5o=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=E1aa0rZbRgOH33Sk3t5COxl3Pz/4uXxtOdB5YwtsmQGABPH8C71DrMjJS5o1a5Fil Jm5QnADeBidtBVrm/RxQgOFGtb5/DNAbCIpo0FUsj/5JydQQBI7/oBJkwHL4vqLUjH 0htZP5EwhhjJbd1mRCzru6XM7v6haAzGw8sAJ+CI=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F9921F8B9C for ; Thu, 29 Mar 2012 06:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.398
X-Spam-Level: 
X-Spam-Status: No, score=-106.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo+7nP6zIBIk for ; Thu, 29 Mar 2012 06:55:18 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7A53921F8B9B for ; Thu, 29 Mar 2012 06:55:18 -0700 (PDT)
Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2TDtCcO099494; Thu, 29 Mar 2012 09:55:14 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [192.168.130.74] by Work-Laptop-2.local (PGP Universal service); Thu, 29 Mar 2012 15:55:14 +0200
X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 29 Mar 2012 15:55:14 +0200
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:    
Date: Thu, 29 Mar 2012 15:55:09 +0200
To: Tony Finch 
From: Edward Lewis 
X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4
Cc: Edward Lewis , dnsext@ietf.org
Subject: Re: [dnsext] Want this to be a WG doc?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

At 12:57 +0100 3/29/12, Tony Finch wrote:

>Yes I think there is no need to mention compresstion and downcasing since
>they do not apply to any of these RR types. From the point of the DNS they
>are all blobs.

Ok, the -01++ version (which might be a WG -00) will have this 
(unless edited again), let me know if...

2.0 Documenting the types

In this section, each type will be presented, including a basic description
of the syntax.  The basic description is presented because it might be
helpful to implementers that merely want convert the data into a viewable
format.  For applications wanting to process this data, consulting a more
thorough description is encouraged.  It has been pointed out that none of
these types are impacted by message compression or DNSSEC alteration.

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

2012...time to reuse those 1984 calendars!
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 07:04:46 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CEF21E801B; Thu, 29 Mar 2012 07:04:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333029885; bh=JNgzuPk8lxYiJotlzZY4W01q99mUmtastzxDgAT+qzs=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=BBFonSlkdd56saVE8vw/1WB0cvZzW6zUf1Oov4qOHOFbpAhCyhD3sXl4RAUjt8jOS qZiXS/D+4+vKFTqyJPHkETUMMeCcvsru3HalV10RGEesZwKKyHMWKoyrpwHFhx2Zwv CpbysH8oC1+dl0UNC3r57Mtgspkr5Dpt1vXIhiLU=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C235521F8B39 for ; Thu, 29 Mar 2012 07:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.48
X-Spam-Level: 
X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwAnVZ1koRBc for ; Thu, 29 Mar 2012 07:04:42 -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 5E45C21F8B0E for ; Thu, 29 Mar 2012 07:04:42 -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-2.csi.cam.ac.uk ([131.111.8.54]:44860) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SDFxx-0006a5-QR (Exim 4.72) (return-path ); Thu, 29 Mar 2012 15:04:41 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SDFxx-0005zx-09 (Exim 4.67) (return-path ); Thu, 29 Mar 2012 15:04:41 +0100
Date: Thu, 29 Mar 2012 15:04:41 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Edward Lewis 
In-Reply-To: 
Message-ID: 
References:     
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Want this to be a WG doc?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Edward Lewis  wrote:
>
> 2.0 Documenting the types
>
> In this section, each type will be presented, including a basic description
> of the syntax.  The basic description is presented because it might be
> helpful to implementers that merely want convert the data into a viewable
> format.  For applications wanting to process this data, consulting a more
> thorough description is encouraged.  It has been pointed out that none of
> these types are impacted by message compression or DNSSEC alteration.

I suggest replacing the last sentence with:

  All of these types can correctly be treated as unstructured binary data,
  as described in section 3 of RFC 3597 (handling unknown DNS RR types).

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Fisher: Northwesterly 5 to 7, occasionally gale 8 in east. Rough. Fair.
Moderate or good.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 08:33:00 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1221B21E821F; Thu, 29 Mar 2012 08:33:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333035180; bh=XNcu751u73XP2EWvY9DikcKpPmGr1wZ6TtQS3DIZwkQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=P+jjXutI4yamejcC1qQFkKYwCUsmRWiYK0nCc0TTgAlcD3iqLEyI6UVw19F7UX/qF OHjOFhoAzfXvwoZ1HJnwFe0DE54n3hrj1O8tf/V1FHiAs6a4zsBKrfzwobvDi753O0 Li0tIVTNspbKRKbqL4RFJfRSImvLGzZbKMuiv55Q=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC06A21E821F for ; Thu, 29 Mar 2012 08:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.901
X-Spam-Level: 
X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKO9FQodbyYF for ; Thu, 29 Mar 2012 08:32:58 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44ECD21E8200 for ; Thu, 29 Mar 2012 08:32:58 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so1676435qcs.31 for ; Thu, 29 Mar 2012 08:32:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=oUeCry3QBnrcGMyJSR+k0IQephJ0xJjR/w9hFBwdPHU=; b=EGcYdlSDqAGyYcbVP6ZcpioRTTit5rEAnQ9EDSpMfuRjci7vsWQgPbtMT7X4zlc9DB 3o79JWzLRYvjnI2GbmH13aauQfJe58hkgsNUp6pk/wVhM1DJu+jRUZ05fGqZL/tZcn2T LFQu2VA1he2kuV25p5S292heutcRcd51+iVSZBKeVa81ep5V2x2/1ZZHOk1tEFa3OsBN 3TdmvZECpM3jBDBDF0U4J9OcBit4YV04erpCxQWRc6Dub2BgEOd/N14S2QW2wPIZdX2y 3N4izJDyPgaZWDSyyK9FQVdvssY5KGp2p3HpkAJucV/u2mF+0QgeFofq/3O4FJIUySle Qazg==
Received: by 10.224.58.147 with SMTP id g19mr701498qah.58.1333035175984; Thu, 29 Mar 2012 08:32:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.92.71 with HTTP; Thu, 29 Mar 2012 08:32:35 -0700 (PDT)
In-Reply-To: 
References: <20120327082614.22953.96097.idtracker@ietfa.amsl.com>   
From: Dick Franks 
Date: Thu, 29 Mar 2012 16:32:35 +0100
X-Google-Sender-Auth: hGHxZdZfoa9dn-fejEc0h4M4RH4
Message-ID: 
To: Ray Bellis 
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-01.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============8076104252859912805=="
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

--===============8076104252859912805==
Content-Type: multipart/alternative; boundary=20cf3074d248233ec804bc63706f

--20cf3074d248233ec804bc63706f
Content-Type: text/plain; charset=UTF-8

On 27 March 2012 12:51, Ray Bellis  wrote:


> > Redundant: packet direction determined by QR flag in packet header.
>
> Not at all, per the text the intention of the QTD bit is to distinguish
> between a server which correctly parsed the option, and one that simply
> echoed it.
>

 I neglected to say that separate inbound/outbound option codes would be a
more convincing solution to the echo problem.


--Dick

--20cf3074d248233ec804bc63706f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On 27 March 2012 12:51, Ray Bellis <Ray.Bellis@nominet.org.uk> wrote:
=C2=A0





> Redundant: packet direction determined by QR flag in packet heade=
r.




Not at all, per the text the intention of the QTD bit is to distingui=
sh between a server which correctly parsed the option, and one that simply =
echoed it.

=C2=A0I neglected to say that separate =
inbound/outbound option codes would be a more convincing solution to the ec=
ho problem.




--Dick


--20cf3074d248233ec804bc63706f--

--===============8076104252859912805==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============8076104252859912805==--

From dnsext-bounces@ietf.org  Thu Mar 29 08:50:53 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4691521E813F; Thu, 29 Mar 2012 08:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333036253; bh=wvsxjSUsiijDxxoOemJDNfzLmOu7eY0EhJtXWmn5h5c=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=w6eSDUEcD0/kKFF+F5FoC02WOxa38Nu17Uy16rfcGMW9Vi9f4TuCv6ryq65Bfu+eg e2+dNrNN+RGlpDIrZzfy1e14glS6KuucfJubdqOCXL4a0qQQLaMgjngW8N2U9eupis oRgKxyf2DfvQnqQNomyxQtykpvtKFCRb+l25Xy2g=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA31B21E80C9 for ; Thu, 29 Mar 2012 08:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Level: 
X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=0.249,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sC8K7KDTWaT7 for ; Thu, 29 Mar 2012 08:50:51 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE5521E81E8 for ; Thu, 29 Mar 2012 08:50:50 -0700 (PDT)
Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id A13BF14124E; Thu, 29 Mar 2012 17:50:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333036249; bh=bbmCoN9jWNyGGlAsTFGfeIjmskGpt5T1wM4MAkTSBZo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=C3M8TnMRYewBtumBTdKM1sVQFBs5lPgy/mzCzVAsK+eUedviqSQB9zs6rE6/yuRXe jP1nruBSz62sI4BITLQEe4ORDbxjXPFAE2C5+nbbDsbr7rYh4eJPiKGzXVIUikfKGI QGb6oiLB98PZ7o6hyfpAOCGIAh1GDsV1Se5/ozJ8=
Mime-Version: 1.0 (Apple Message framework v1257)
From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= 
In-Reply-To: <20120327080711.16297.49879.idtracker@ietfa.amsl.com>
Date: Thu, 29 Mar 2012 17:50:52 +0200
Message-Id: 
References: <20120327080711.16297.49879.idtracker@ietfa.amsl.com>
To: dnsext@ietf.org, =?iso-8859-1?Q?Alfred_H=CEnes?= , Shane Kerr 
X-Mailer: Apple Mail (2.1257)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Subject: [dnsext] Review of draft-ietf-dnsext-rfc1995bis-ixfr-00.txt (from Knot DNS team)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

SGksCgpJIGdvdCBvdXIgaGVhZCBlbmdpbmVlciBvZiBLbm90IEROUyAoTHVib3MgU2xvdmFrIGhl
J3MgaW4gQ2M6KSwgd2hvIGFsc28gaW1wbGVtZW50b3IgSVhGUiAoZnJvbSBzY3JhdGNoKSB0byBy
ZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBoZXJlJ3MgdGhlIHJlc3VsdCAoY29weWluZyB2ZXJiYXRp
bSwganVzdCBhZGRlZCByZWZlcmVuY2VzIHRvIHNlY3Rpb25zIGFuZCAnbml0JyB3b3Jkcyk6Cgox
KSBzZWN0aW9uIDEuNCAtIG5pdDogIm1ha2VzIGZyZWVseSB1c2UiIC0+IHMvZnJlZWx5L2ZyZWUK
CjIpIFNlY3Rpb24gMiwgcGFnZSA4IC0gbml0OiAiVGhlcmVmb3JlLCBpcyBiZWNvbWVzIGFwcGFy
ZW50IiAtPiBzL2lzL2l0CgozKSBTZWN0aW9uIDIsIGxhc3QgcGFyYWdyYXBoIC0gd2h5IGhhcyB0
byBSUlNJRyhTT0EpIGZvbGxvdyB0aGUgU09BIGluIHRoZW4gQVhGUi1mYWxsYmFjayBleGFtcGxl
PwoKNCkgU2VjdGlvbiA2LjIgLSBtaXNzaW5nIFJGQzIxMTkgbGFuZ3VhZ2U7IHNob3VsZHMgYW5k
IG1heXMgYXJlIHNtYWxsIGNhcHMsIGlzIHRoYXQgaW50ZW50aW9uYWw/Cgo1KSBBbmQgdG9kYXkg
bmV3IHF1ZXN0aW9uIGhhdmUgYXJyaXNlZDogIldoYXQgc2hvdWxkIElYRlIgY2xpZW50IGRvIGlm
IGl0IHJlY2VpdmVzIGluY29tcGxldGUgbXVsdGljaHVua2VkIElYRlIgcmVzcG9uc2U/IiAgQSkg
ZGlzY2FyZCB3aG9sZSB0cmFuc2ZlciBhbmQgc3RhcnQgb3ZlcjsgQikgc2F2ZSB1c2FibGUgY2h1
bmtzIChlLmcuIHVzZSBkYXRhIHRvIHVwZGF0ZSB6b25lIGZyb20gc25fbyB0byBzbl9vK3gsIHdo
ZXJlIHNuX28reCA8IHNuX24pCgpPbmRyZWogb24gYmVoYWxmIG9mIEx1Ym9zClAuUy46IE91ciBL
bm90IEROUyB0ZWFtIChkaWZmZXJlbnQgcGVvcGxlIHRoYW4gb25lIG9mIHRoZSBhdXRob3JzIG9m
IHRoaXMgZG9jdW1lbnQpIHdpbGwgZG8gYSBmdWxsIHJldmlldyBpbiBXR0xDLgoKT24gMjcuIDMu
IDIwMTIsIGF0IDEwOjA3LCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6Cgo+IAo+IEEg
TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0
LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRE5T
IEV4dGVuc2lvbnMgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4KPiAKPiAJVGl0bGUgICAgICAg
ICAgIDogRE5TIEluY3JlbWVudGFsIFpvbmUgVHJhbnNmZXIgUHJvdG9jb2wgKElYRlIpCj4gCUF1
dGhvcihzKSAgICAgICA6IEFsZnJlZCBIb2VuZXMKPiAgICAgICAgICAgICAgICAgICAgICAgICAg
T25kcmVqIFN1cnkKPiAgICAgICAgICAgICAgICAgICAgICAgICAgU2hhbmUgS2Vycgo+IAlGaWxl
bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRuc2V4dC1yZmMxOTk1YmlzLWl4ZnItMDAudHh0Cj4g
CVBhZ2VzICAgICAgICAgICA6IDMyCj4gCURhdGUgICAgICAgICAgICA6IDIwMTItMDMtMjcKPiAK
PiAgIFRoZSBzdGFuZGFyZCBtZWFucyB3aXRoaW4gdGhlIERvbWFpbiBOYW1lIFN5c3RlbSBwcm90
b2NvbCBmb3IKPiAgIG1haW50YWluaW5nIGNvaGVyZW5jZSBhbW9uZyBhIHpvbmUncyBhdXRob3Jp
dGF0aXZlIG5hbWUgc2VydmVycwo+ICAgY29uc2lzdHMgb2YgdGhyZWUgbWVjaGFuaXNtcy4gIElu
Y3JlbWVudGFsIFpvbmUgVHJhbnNmZXIgKElYRlIpIGlzCj4gICBvbmUgb2YgdGhlIG1lY2hhbmlz
bXMgYW5kIG9yaWdpbmFsbHkgd2FzIGRlZmluZWQgaW4gUkZDIDE5OTUuCj4gCj4gICBUaGlzIGRv
Y3VtZW50IGFpbXMgdG8gcHJvdmlkZSBhIG1vcmUgZGV0YWlsZWQgYW5kIHVwLXRvLWRhdGUKPiAg
IHNwZWNpZmljYXRpb24gb2YgdGhlIElYRlIgbWVjaGFuaXNtIGFuZCB0byBhbGlnbiBpdCB3aXRo
IHRoZSBjdXJyZW50Cj4gICBzcGVjaWZpY2F0aW9uIG9mIHRoZSBwcmltYXJ5IHpvbmUgdHJhbnNm
ZXIgbWVjaGFuaXNtLCBBWEZSLCBnaXZlbiBpbgo+ICAgUkZDIDU5MzYuICBGdXJ0aGVyLCBiYXNl
ZCBvbiBvcGVyYXRpb25hbCBleHBlcmllbmNlLCB0aGlzIGRvY3VtZW50Cj4gICBqdXh0YXBvc2Vz
IHRvIHRoZSBvcmlnaW5hbCBJWEZSIHF1ZXJ5IGEgbmV3IHF1ZXJ5IHR5cGUsIElYRlItT05MWSwK
PiAgIHRoYXQgd2lsbCBsaWtlbHkgYmUgcHJlZmVycmVkIG92ZXIgSVhGUiBpbiBzcGVjaWZpYyBk
ZXBsb3ltZW50cy4KPiAKPiAgIFRoaXMgZG9jdW1lbnQgb2Jzb2xldGVzIGFuZCByZXBsYWNlcyBS
RkMgMTk5NS4KPiAKPiAKPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoKPiBodHRw
Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRuc2V4dC1yZmMxOTk1
YmlzLWl4ZnItMDAudHh0Cj4gCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi
eSBhbm9ueW1vdXMgRlRQIGF0Ogo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv
Cj4gCj4gVGhpcyBJbnRlcm5ldC1EcmFmdCBjYW4gYmUgcmV0cmlldmVkIGF0Ogo+IGZ0cDovL2Z0
cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNleHQtcmZjMTk5NWJpcy1p
eGZyLTAwLnR4dAo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fCj4gZG5zZXh0IG1haWxpbmcgbGlzdAo+IGRuc2V4dEBpZXRmLm9yZwo+IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0CgotLQogT25kxZllaiBTdXLDvQog
dmVkb3Vjw60gdsO9emt1bXUvSGVhZCBvZiBSJkQgZGVwYXJ0bWVudAogLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogQ1ouTklDLCB6LnMucC5vLiAgICAtLSAgICBM
YWJvcmF0b8WZZSBDWi5OSUMKIEFtZXJpY2thIDIzLCAxMjAgMDAgUHJhaGEgMiwgQ3plY2ggUmVw
dWJsaWMKIG1haWx0bzpvbmRyZWouc3VyeUBuaWMuY3ogICAgaHR0cDovL25pYy5jei8KIHRlbDor
NDIwLjIyMjc0NTExMCAgICAgICBmYXg6KzQyMC4yMjI3NDUxMTIKIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fCmRuc2V4dCBtYWlsaW5nIGxpc3QKZG5zZXh0QGlldGYub3JnCmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0Cg==

From dnsext-bounces@ietf.org  Thu Mar 29 11:48:23 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B0521F85F8; Thu, 29 Mar 2012 11:48:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333046902; bh=l6uXYRV5CQrcILQOufVT5NDKYHl5q1kiSAeY9aSetAc=; h=From:Message-Id:To:Date:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=kA/2ppzCv07k9x9+v8gYJEinRM4NYhgzU+Oly/DooGBVpvtrd9aP4xl5FlOdZA2fC 1hFICbCivGjHVLuNlbzQw7WOHm3VsdUWVUkHG2/iDpS/yxtulTL2hbGoeUWSiFm8pP M7bqeal9elQpnZVpLqqHY8a+uzmcevwS909gpekw=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FB621F85F6 for ; Thu, 29 Mar 2012 11:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.629
X-Spam-Level: 
X-Spam-Status: No, score=-98.629 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh+TbZwXdKHZ for ; Thu, 29 Mar 2012 11:48:20 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id A345921F85F3 for ; Thu, 29 Mar 2012 11:48:19 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA285976829; Thu, 29 Mar 2012 20:47:09 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA20098; Thu, 29 Mar 2012 20:47:07 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= 
Message-Id: <201203291847.UAA20098@TR-Sys.de>
To: Ed.Lewis@neustar.biz, dot@dotat.at
Date: Thu, 29 Mar 2012 20:47:06 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Want this to be a WG doc?  (dns-undocumented-types)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

At 29 Mar 2012 15:04:41 +0100, Tony Finch wrote:
> Edward Lewis  wrote:
>>
[[ next phrase restored for clarity from referenced message -- AH ]]
>> ... Ok, the -01++ version (which might be a WG -00) will have
>> this (unless edited again), let me know if... 
>>
>> 2.0 Documenting the types
>>
>> In this section, each type will be presented, including a basic description
>> of the syntax.  The basic description is presented because it might be
>> helpful to implementers that merely want convert the data into a viewable
>> format.  For applications wanting to process this data, consulting a more
>> thorough description is encouraged.  It has been pointed out that none of
>> these types are impacted by message compression or DNSSEC alteration.
>
> I suggest replacing the last sentence with:
>
>   All of these types can correctly be treated as unstructured binary data,
>   as described in section 3 of RFC 3597 (handling unknown DNS RR types).
>
> Tony.

a) missing "to" :     ... want to convert ...

b) I suggest to be even more precise in amending Tony's text to say:

|   The RDATA of all of these types can correctly be treated as
    ^^^^^^^^^^^^^^
|   unstructured binary data, as described in Section 3 of RFC 3597
|   [RFC3597], "Handling of Unknown DNS RR Types".
    ^^^^^^^^^^^^^       ^^^^^              ^    ^


More basically:
I appreciate this document and would like to see it published in an
(Informational) RFC.
This can be done as an individual submission (either AD sponsored
or as an Independent Submission via the ISE) or as a WG document;
another way to deal with that aim would be to include its body as
an Informative Appendix into the DNS IANA Considerations, rfc6195bis
draft.

Caveat:
I fear we will have to severely struggle with IESG and RFC Editor
policy regarding the many (necessary) references to "work in progress"
that is not considered eligible for citation in RFCs.  With these
citations blurred out in the common style, most of the worth of the
document would be lost.
In seeking success in that matter, having a WG document might help
a bit, but I'm reluctant in estimating success probability.
OTOH, if rfc6195bis succeeds in obliging IANA to provide escrow
copies of registration documents, and this is done retrosctively
for past registrations, using this draft as a guideline, much
clarity would be won already.

Best regards,
  Alfred.

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

From dnsext-bounces@ietf.org  Thu Mar 29 12:43:27 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC8A21F881F; Thu, 29 Mar 2012 12:43:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333050206; bh=RGvZWp5+aYp4jLaZFaz9XvhimqbINia/D5NqgYvz67A=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lfVqIz5EsATp872NFK8HVLUMbqms3iHRShhKCL3Qoyd3inPgx72pxkwBUva+q1uUt omzU4nEdAymOgycBG2n+LRHu66qF7FwcJ5xRr0WymBUB+IW6Z7lVv1S6n+yyw8QBkp duKmxr0rs2k+bGN3oJZKySHPVm70op9kJI198bPg=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F3921F86B0 for ; Thu, 29 Mar 2012 12:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.027
X-Spam-Level: 
X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.222,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u07S6DvdNCTI for ; Thu, 29 Mar 2012 12:43:25 -0700 (PDT)
Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 116D921F881F for ; Thu, 29 Mar 2012 12:43:24 -0700 (PDT)
Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1SDLFb-00006n-La for dnsext@ietf.org; Thu, 29 Mar 2012 21:43:15 +0200
Received: from fw by deneb.enyo.de with local (Exim 4.72) (envelope-from ) id 1SDLFb-0005CU-EU for dnsext@ietf.org; Thu, 29 Mar 2012 21:43:15 +0200
From: Florian Weimer 
To: dnsext list 
References: <20120329111837.GB17832@miek.nl>  <20120329115529.GD17832@miek.nl>
Date: Thu, 29 Mar 2012 21:43:15 +0200
In-Reply-To: <20120329115529.GD17832@miek.nl> (Miek Gieben's message of "Thu,  29 Mar 2012 13:55:30 +0200")
Message-ID: <87zkazkxbg.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Subject: Re: [dnsext] draft-levine-dnsextlang-02
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

* Miek Gieben:

>> Again I think this has to be handled in special case code. Really they
>> should have used a different RR type for each layout.
>
> As you said, why not avoid this whole mess and use 3597?

You need to add a presentation layer somewhere.

We might better off to define a DOM and implement the encoding and
decoding in Javascript.  Honestly.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 12:59:51 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CA221F87A2; Thu, 29 Mar 2012 12:59:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333051191; bh=OZWMBgVavCjdlfDptGhEuxXJA+Uy4pzU0fnoK+wrF2M=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ZW8WZqqB6+Bh199U2KcK9pB2yO5OCWzyrkIKPVAtFDWm0lmHJI5gJi15V8oG5pXaM /ZqF6axvzbia+IlyCcNY059fgfQegwAbQX1sz1lj9nssTGZwxus47+39vCZtNG9pZQ khU9y4tHa9u11r6k7cIFYHIA/Ie7fF5Om1oswqHk=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1E221F87A2; Thu, 29 Mar 2012 12:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.158
X-Spam-Level: 
X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvjeEI9HkhQ6; Thu, 29 Mar 2012 12:59:49 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5557B21F8795; Thu, 29 Mar 2012 12:59:48 -0700 (PDT)
Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 5CBD5141255; Thu, 29 Mar 2012 21:59:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333051187; bh=/t/CsfjJ+rnzgQMaoSyxsMOGEwMsiuGeoNszVrsz2QQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CUVWr3XaFQoEKP4jjUm02uOKw05jFdzDKxro7tNh+XHp/llW6b6EthhFdQruAGxA7 uX2bVKdTvALTkCUR6Y5UjYVARgPPB3OyHiXZzHgKSOh3lWVF3MzPm/BEN6twGRmn/D AB87DNR0U2x9jeeiu04SRA7tImo2PX95gVu2flmE=
Mime-Version: 1.0 (Apple Message framework v1257)
From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= 
In-Reply-To: <20120301150930.GA69334@mail.yitter.info>
Date: Thu, 29 Mar 2012 21:59:49 +0200
Message-Id: <5B2D527E-D62A-444B-BC21-4565F5AC4FE7@nic.cz>
References: <4F4BCD01.2090401@isdg.net>  <4F4C24A0.2010804@redbarn.org> <20120228100227.214bb6ef@shane-desktop> <4F4D1F9E.5090003@redbarn.org> <20120229102255.74fa4291@shane-desktop> <20120301150930.GA69334@mail.yitter.info>
To: dnsop@ietf.org, dnsext@ietf.org, dnsext-chairs chairs 
X-Mailer: Apple Mail (2.1257)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Subject: [dnsext] DNS-NG (Re: [DNSOP] Batch Multiple Query Packet)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

W2Nyb3NzLXBvc3Rpbmc6IGRuc2V4dCByZWFkZXJzIHBsZWFzZSBjaGVjayB0aGUgZnVsbCB0aHJl
YWQgb24gZG5zb3BdCk9uIDEuIDMuIDIwMTIsIGF0IDE2OjA5LCBBbmRyZXcgU3VsbGl2YW4gd3Jv
dGU6Cj4gSWYgZG5zLW5nIGlzIGEgc3VwZXJzZXQgb2YgdXNlZnVsIGRucyBmdW5jdGlvbmFsaXR5
LCBidXQgY2xlYW5zIHVwCj4gY2VydGFpbiBpc3N1ZXMgd2l0aCBkbnMsIHRoZW4gdGhlIGludGVy
bWVkaWF0ZSByZXNvbHZlcnMgaW4gKDIpIGNhbiBhcwo+IGVhc2lseSB1c2UgYSBuZXcgcG9ydCBh
cyB0aGV5IGNhbiB1c2UgbW9yZSBjb21wbGljYXRlZCBkbnMgaGFuZGxpbmcuCj4gU28gSSBoYXZl
IHRvIGFncmVlIHdpdGggUGF1bCBWaXhpZTogaWYgd2UncmUgZ29pbmcgdG8gd29yayBvbgo+IHJl
cGxhY2luZyB0aGUgcHJvdG9jb2wsIGxldCdzIHJlcGxhY2UgaXQgZm9yIHJlYWwuICAoRldJVywg
SSB0aGluawo+IHRoaXMgaXMgYSBub2JsZSBnb2FsIGRvb21lZCB0byBmYWlsdXJlLiAgQnV0IEkn
dmUgYmVlbiB3cm9uZyBiZWZvcmUuCj4gUHJvYmFibHkgdGhyZWUgdGltZXMganVzdCB0aGlzIG1v
cm5pbmcuKQoKCk9uIHRoZSBvdGhlciBoYW5kLCBpdCBtaWdodCBiZSBqdXN0IHRoZSByaWdodCB0
aW1lIHRvIGRvIHRoaXMuICBXaXRoCmRuc2V4dCBjbG9zdXJlIHdlIGNhbiBzdGFydCB3aXRoIGNs
ZWFuIHRhYmxlIGFuZCByZWRlc2lnbiB0aGUgdW5kZXJseWluZwptZWNoYW5pc21zIGhvcGVmdWxs
eSB3aXRoIGxlc3NvbnMgbGVhcm5lZCBzbyBmYXIuCgpJIGxpa2UgdGhlIGlkZWEgdmVyeSBtdWNo
IGFuZCBJIHdvdWxkIGxpa2UgdG8gaW5pdGlhdGUgQm9GIGluIFZhbmNvdXZlcgppZiB0aGVyZSBp
cyBhbiBpbnRlcmVzdCB0byBwdXJzdWUgdGhpcyBkbnMtbmcgdGhpbmcuICBBbmQgbm8gaXQgaXMg
bm90Cm1lYW50IGFzIHJlcGxhY2VtZW50IGZvciBkbnNleHQuICBUaGUgV0cgc2hvdWxkIGRvIGl0
J3Mgam9iLCBwcm9kdWNlIFdHCmRvY3VtZW50KHMpIGFuZCBjbG9zZS4gIEkgYW0gbm90IHRyeWlu
ZyB0byBnZXQgbWFkLCB5J2tub3cgOi0pLgoKTy4KUC5TLjogSSBrbm93IEkgYW0gcmVzcG9uZGlu
ZyB0byBhIG1vbnRoLW9sZCBlbWFpbCwgYnV0IGJldHRlciBub3cgdGhhbiBuZXZlci4uLgotLQog
T25kxZllaiBTdXLDvQogdmVkb3Vjw60gdsO9emt1bXUvSGVhZCBvZiBSJkQgZGVwYXJ0bWVudAog
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogQ1ouTklDLCB6LnMu
cC5vLiAgICAtLSAgICBMYWJvcmF0b8WZZSBDWi5OSUMKIEFtZXJpY2thIDIzLCAxMjAgMDAgUHJh
aGEgMiwgQ3plY2ggUmVwdWJsaWMKIG1haWx0bzpvbmRyZWouc3VyeUBuaWMuY3ogICAgaHR0cDov
L25pYy5jei8KIHRlbDorNDIwLjIyMjc0NTExMCAgICAgICBmYXg6KzQyMC4yMjI3NDUxMTIKIC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRuc2V4dCBtYWlsaW5nIGxpc3QKZG5z
ZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0
Cg==

From dnsext-bounces@ietf.org  Thu Mar 29 13:11:47 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6C921E80B9; Thu, 29 Mar 2012 13:11:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333051907; bh=tr5bBpDFnu0mUPIkjjMzMPyQMFofaN+eClWAQWq0MH0=; h=From:Message-Id:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=QPnvN1xRSzIH5WEO92xhNqtVzMpzOgKg7BOVGratuJPfNKCke0FS15KNmtetpdd+h ubcM4jSD6rqn1k+jVOBe80kpj3KiCn6c+vZHYP8cmF5LSTyZ+iVmfUcakGBNapyrBN XQjepN6YHyG9P7mZJ1NKT9KPzDflBATZqxqf+6c0=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B2821E80B7 for ; Thu, 29 Mar 2012 13:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.631
X-Spam-Level: 
X-Spam-Status: No, score=-98.631 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znqO6uiPQFdK for ; Thu, 29 Mar 2012 13:11:45 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4528721E80B1 for ; Thu, 29 Mar 2012 13:11:44 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA286311832; Thu, 29 Mar 2012 22:10:32 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA20455; Thu, 29 Mar 2012 22:10:30 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= 
Message-Id: <201203292010.WAA20455@TR-Sys.de>
To: dnsext@ietf.org
Date: Thu, 29 Mar 2012 22:10:30 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Subject: Re: [dnsext] Signaling ENDS option understanding in draft-bellis-dnsext-multi-qtypes-01
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

On 27 Mar 2012 12:29:06 +0100, Dick Franks
noted that the QTD bit proposed in Section 3.1 of
draft-bellis-dnsext-multi-qtypes-01 seems redundant.

That indeed is the case, and, after discussion on a side-track of
the seminal suggestions for this proposal I had made (*) before the
Hiroshima IETF, this WG has formed consensus that no additional
signaling of "understanding of EDNS options" is desired.
To this end, IIRC the WG has decided that RFC 2671 contains enough
specification, and the rfc2671bis draft again clarifies that DNS
servers recieving an OPT RR in a query MUST ignore unknown options.
The WG consensus in 2009 was that "ignore" also means to not copy
the option into the OPT RR in the response (if any), and
implementers had confirmed those days that this was the behavior
of state-of-the-art EDNS implementations.

Thus, according to my understanding, a conformant recipient of an
OPT RR in a DNS query behaves as follows:

a) no support for EDNS present
   (either not built-in or disabled by config):
   ignore entire OPT RR, do not include OPT RR into response;
   possible legacy alternative: return FormErr;
b) support for EDNS present, but no support present for a particular
   option received: ignore it, do not include it in response;
c) support for particular EDNS option present:
   behave according to the specification of that option
   (which may be: echo the received option unchanged, or otherwise).

Since the QTCOUNT is redundant as well, the first octect of the
proposed option format is indeed redundant.

Note however, that rfc2671bis allows additional handshaking.
So it's a matter of simplicity vs. redundancy and actual gain.


(*)  Please see my initial "RRGQ" proposal and its variations,
as suggested in messages to the former namedroppers list and
archived at
  http://www.ietf.org/mail-archive/web/dnsext/current/msg05291.html
and
  http://www.ietf.org/mail-archive/web/dnsext/current/msg05305.html,
and the entire thread started by the former message.

The variant in the design choice mentioned in the 3rd-to-last para
of the latter message -- combining a query for a Data RRtype with
an EDNS option (there dubbed 'RGMASK') -- is now followed by this I-D.

Unfortunately, I've never found the time to write this up properly
as an I-D (as promised), and I thank Ray for eventually having done
this now (with a bare RRtype list instead of an NSEC-like bitmask
in the OPTION-DATA).


Best regards,
  Alfred.

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

From dnsext-bounces@ietf.org  Thu Mar 29 13:26:26 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C4F21E80CA; Thu, 29 Mar 2012 13:26:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333052786; bh=/ByfATQZFjSrhocTVnWRlGdUT3yF03tOWuUIbBUtPp4=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=knvc1E/U7sig5iuUWLBJDl0T4lYDaeNnWH6n5F1haJn6XzLd6uUM1bKe20QlNYqHt om20rjUuUV9SinNgbRhEBhaNMg2uUcW0mI1vxdgRVjxkq2rwLJlNInENfw0GQMCZps 5erAqnYMcrG5tyQuNBeWYoRd5yyu+lzOtRswA3Ws=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8321E80CA for ; Thu, 29 Mar 2012 13:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.914
X-Spam-Level: 
X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.035,  BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf3rxmUy1n-G for ; Thu, 29 Mar 2012 13:26:24 -0700 (PDT)
Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 67E6C21E801F for ; Thu, 29 Mar 2012 13:26:24 -0700 (PDT)
Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1SDLvK-0000Nd-0Z; Thu, 29 Mar 2012 22:26:22 +0200
Received: from fw by deneb.enyo.de with local (Exim 4.72) (envelope-from ) id 1SDLvJ-0005WK-Pd; Thu, 29 Mar 2012 22:26:21 +0200
From: Florian Weimer 
To: Alfred =?iso-8859-1?Q?H=F6nes?= 
References: <201203292010.WAA20455@TR-Sys.de>
Date: Thu, 29 Mar 2012 22:26:21 +0200
In-Reply-To: <201203292010.WAA20455@TR-Sys.de> ("Alfred =?iso-8859-1?Q?H?= =?iso-8859-1?Q?=F6nes=22's?= message of "Thu, 29 Mar 2012 22:10:30 +0200 (MESZ)")
Message-ID: <87bonfkvbm.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Signaling ENDS option understanding in draft-bellis-dnsext-multi-qtypes-01
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

* Alfred H=F6nes:

> To this end, IIRC the WG has decided that RFC 2671 contains enough
> specification, and the rfc2671bis draft again clarifies that DNS
> servers recieving an OPT RR in a query MUST ignore unknown options.

I think this is rewriting history.  BIND used to respond with RCODE=3D1
to queries carrying the new NSID option, for example.  And I'm sorry
to say that this obnoxious behavior is even suggested by the language
in RFC 2671.

> Thus, according to my understanding, a conformant recipient of an
> OPT RR in a DNS query behaves as follows:
>
> a) no support for EDNS present
>    (either not built-in or disabled by config):
>    ignore entire OPT RR, do not include OPT RR into response;
>    possible legacy alternative: return FormErr;

RFC 2671bis requires the RCODE=3D1 response, see:

From: Florian Weimer 
Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt
To: Olafur Gudmundsson 
Cc: dnsext@ietf.org
Date: Mon, 13 Feb 2012 16:06:02 +0100
Message-ID: <871upyept1.fsf@mid.deneb.enyo.de>

> b) support for EDNS present, but no support present for a particular
>    option received: ignore it, do not include it in response;
> c) support for particular EDNS option present:
>    behave according to the specification of that option
>    (which may be: echo the received option unchanged, or otherwise).

b) and c) seem correct to me, with the caveat that reflecting the
query with the original OPT RR does not mean the server supports your
protocol extension.  You need to bits to tell an active implementor
from a reflector.  (Kind of what was done with ECN for TCP,
eventually.)
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Thu Mar 29 16:36:43 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA1D21E8026; Thu, 29 Mar 2012 16:36:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333064203; bh=bwmpZKyyGE/9EoVymaMH/fsQazocflTPNYKBB5le4po=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=hCMA4U56yv3pJ70XxLF1LESllfgOMG9FX5Kh9SXD0C2gJJEB2grTrEsvswjo9hNno A6R4rS+4M5VY6lZeybJQbXZTds8H7N6gdieErI3X896stjtHaJKibujN7SftnxZhsE iqkg6z41rJxagFi60AaHSPbDLdmTOsoOAfcE3IYA=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4847721F86B2 for ; Thu, 29 Mar 2012 16:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.515
X-Spam-Level: 
X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbSkkPn-P-jW for ; Thu, 29 Mar 2012 16:36:40 -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 A3A8121F86A5 for ; Thu, 29 Mar 2012 16:36:40 -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 B74B5C944A; Thu, 29 Mar 2012 23:36:20 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b9d2:d2a7:a07b:5597]) (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 602C1216C33; Thu, 29 Mar 2012 23:36: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 C6CD21F3B95D; Fri, 30 Mar 2012 10:36:08 +1100 (EST)
To: Florian Weimer 
From: Mark Andrews 
References: <201203292010.WAA20455@TR-Sys.de> <87bonfkvbm.fsf@mid.deneb.enyo.de>
In-reply-to: Your message of "Thu, 29 Mar 2012 22:26:21 +0200." <87bonfkvbm.fsf@mid.deneb.enyo.de>
Date: Fri, 30 Mar 2012 10:36:07 +1100
Message-Id: <20120329233608.C6CD21F3B95D@drugs.dv.isc.org>
Cc: Alfred =?iso-8859-1?Q?H=F6nes?= , dnsext@ietf.org
Subject: Re: [dnsext] Signaling ENDS option understanding in draft-bellis-dnsext-multi-qtypes-01
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

In message <87bonfkvbm.fsf@mid.deneb.enyo.de>, Florian Weimer writes:
> * Alfred H=F6nes:
> 
> > To this end, IIRC the WG has decided that RFC 2671 contains enough
> > specification, and the rfc2671bis draft again clarifies that DNS
> > servers recieving an OPT RR in a query MUST ignore unknown options.
> 
> I think this is rewriting history.  BIND used to respond with RCODE=1
> to queries carrying the new NSID option, for example.  And I'm sorry
> to say that this obnoxious behavior is even suggested by the language
> in RFC 2671.

Which version of BIND?  Not 9.1.0 nor 9.2.0 nor 9.3.0 nor 9.4.0 which
are the early BIND 9 production releases.  I don't believe BIND 8
returned FORMERR based on code inspection.
 
> > Thus, according to my understanding, a conformant recipient of an
> > OPT RR in a DNS query behaves as follows:
> >
> > a) no support for EDNS present
> >    (either not built-in or disabled by config):
> >    ignore entire OPT RR, do not include OPT RR into response;
> >    possible legacy alternative: return FormErr;
> 
> RFC 2671bis requires the RCODE=1 response, see:
> 
> From: Florian Weimer 
> Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt
> To: Olafur Gudmundsson 
> Cc: dnsext@ietf.org
> Date: Mon, 13 Feb 2012 16:06:02 +0100
> Message-ID: <871upyept1.fsf@mid.deneb.enyo.de>
> 
> > b) support for EDNS present, but no support present for a particular
> >    option received: ignore it, do not include it in response;
> > c) support for particular EDNS option present:
> >    behave according to the specification of that option
> >    (which may be: echo the received option unchanged, or otherwise).
> 
> b) and c) seem correct to me, with the caveat that reflecting the
> query with the original OPT RR does not mean the server supports your
> protocol extension.  You need to bits to tell an active implementor
> from a reflector.  (Kind of what was done with ECN for TCP,
> eventually.)
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

From dnsext-bounces@ietf.org  Fri Mar 30 02:27:24 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967C421F8644; Fri, 30 Mar 2012 02:27:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333099644; bh=x+0YsTK8Y6RJRlx8lioLa6I6XnuhUayDl/KyvWbxY/s=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=PmBtEyzWiM8ptgNTX0grUXNJokgcGONGuHJEthua1I01ZbVuKWM1A/JeRLaJL9wUO B4kerTmYxgtuzoC9FsvKzpvRCe+c62y9Gg4anJQvXDF75vvyYmqUl/WK3DO/pw90Tv oejTMmnZ/ZvX8dXtQ+k2a4uMjAvAUb/rwzkVBXLk=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A2721F8705 for ; Fri, 30 Mar 2012 02:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level: 
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ6qKX9IYn15 for ; Fri, 30 Mar 2012 02:27:21 -0700 (PDT)
Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 99E0D21F84B4 for ; Fri, 30 Mar 2012 02:27:19 -0700 (PDT)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns;  h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=Z7rkYxRVoCooFIdJfsyx9BLN1u3vsU7gc2tdMbBy+/TfZRlVlLat5FhC M692pOr2dqKvw5+ihmEifGbQU/ZKI8cvgYUpZEQIA6MvCJyeIK29+amtg cFm2Aelj1+TfOgS;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1333099640; x=1364635640; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20Signaling=20ENDS=20option=20understandi ng=20in=0D=0A=20draft-bellis-dnsext-multi-qtypes-01|Date: =20Fri,=2030=20Mar=202012=2009:27:17=20+0000|Message-ID: =20 |To:=20=3D?iso-8859-1?Q?Alfred_H=3DCEnes?=3D=20|CC:=20""=20,=20""=0D=0A=09 |MIME-Version:=201.0|In-Reply-To:=20<201203292010.WAA2045 5@TR-Sys.de>|References:=20<201203292010.WAA20455@TR-Sys. de>; bh=02FKIvnOFMCbVIZChQj0sLzQMF9DI9VijHZX08eYBKk=; b=fqz2zKIRb0VG0O6VB13KzAeRZWGaf0Zo9b68umZlgBYbxeiPRcbyWcnz pr9+Z2BY+p4tbt+TkIPRkZPNl1UVS5nufX2bV1g8x4+zeHHRpPPVCuVuZ Sdt5UNZYi3PHH4d;
X-IronPort-AV: E=Sophos;i="4.75,343,1330905600"; d="scan'208,217";a="39407318"
Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 30 Mar 2012 10:27:18 +0100
Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Fri, 30 Mar 2012 10:27:18 +0100
From: Ray Bellis 
To: =?iso-8859-1?Q?Alfred_H=CEnes?= 
Thread-Topic: Signaling ENDS option understanding in draft-bellis-dnsext-multi-qtypes-01
Thread-Index: AQHNDegpIusgLPL1QkiMhMIGsZkKiJaCggSA
Date: Fri, 30 Mar 2012 09:27:17 +0000
Message-ID: 
References: <201203292010.WAA20455@TR-Sys.de>
In-Reply-To: <201203292010.WAA20455@TR-Sys.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
Cc: "" 
Subject: Re: [dnsext] Signaling ENDS option understanding in draft-bellis-dnsext-multi-qtypes-01
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0217255608208258586=="
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

--===============0217255608208258586==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_DBC3C50C10A749808B9764FC7F1CAA8Fnominetorguk_"

--_000_DBC3C50C10A749808B9764FC7F1CAA8Fnominetorguk_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


On 29 Mar 2012, at 22:10, Alfred H=CEnes wrote:

On 27 Mar 2012 12:29:06 +0100, Dick Franks
noted that the QTD bit proposed in Section 3.1 of
draft-bellis-dnsext-multi-qtypes-01 seems redundant.

That indeed is the case, and, after discussion on a side-track of
the seminal suggestions for this proposal I had made (*) before the
Hiroshima IETF, this WG has formed consensus that no additional
signaling of "understanding of EDNS options" is desired.

Is that documented anywhere?  2671bis (per your note below) appears to sugg=
est otherwise.

To this end, IIRC the WG has decided that RFC 2671 contains enough
specification, and the rfc2671bis draft again clarifies that DNS
servers recieving an OPT RR in a query MUST ignore unknown options.

Yes, that's explicit.

The WG consensus in 2009 was that "ignore" also means to not copy
the option into the OPT RR in the response (if any), and
implementers had confirmed those days that this was the behavior
of state-of-the-art EDNS implementations.

Yes, that's right.  I'm worried about non state-of-the-art implementations =
;-)

Thus, according to my understanding, a conformant recipient of an
OPT RR in a DNS query behaves as follows:

a) no support for EDNS present
  (either not built-in or disabled by config):
  ignore entire OPT RR, do not include OPT RR into response;
  possible legacy alternative: return FormErr;
b) support for EDNS present, but no support present for a particular
  option received: ignore it, do not include it in response;
c) support for particular EDNS option present:
  behave according to the specification of that option
  (which may be: echo the received option unchanged, or otherwise).

Since the QTCOUNT is redundant as well, the first octect of the
proposed option format is indeed redundant.

Note however, that rfc2671bis allows additional handshaking.
So it's a matter of simplicity vs. redundancy and actual gain.

Indeed - =A76.1.2

"Specifications of such options might wish to

 include some kind of signaled acknowledgement"

I do think such signalled acknowledgement is sensible, given my experiences=
 with various middleboxes that will blithely ignore many things written in =
the RFCs.  At least with a signalling bit you can have an _explicit_ confir=
mation that the far end knows what it's doing.

That said, I'm _kind of_ OK with Dick's proposal that the response use a di=
fferent option code instead of using the QTD bit.  That's consistent with I=
CMP, although off the top of my head I'm not aware of any other part of DNS=
 that does this.

kind regards,

Ray




--_000_DBC3C50C10A749808B9764FC7F1CAA8Fnominetorguk_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <00dbca99-94f6-4085-b151-82a006857556>
Content-Transfer-Encoding: quoted-printable



On 29 Mar 2012, at 22=
:10, Alfred H=CEnes wrote:

On 27 Mar 2012 12:29:06 +0100, Dick Franks<=
br>noted that the QTD bit proposed in Section 3.1 of
draft-bellis-dnsext=
-multi-qtypes-01 seems redundant.

That indeed is the case, and, afte=
r discussion on a side-track of
the seminal suggestions for this proposa=
l I had made (*) before the
Hiroshima IETF, this WG has formed consensus=
 that no additional
signaling of "understanding of EDNS options&quo=
t; is desired.

Is that documented anyw=
here?  2671bis (per your note below) appears to suggest otherwise.

To this end, IIRC the WG has deci=
ded that RFC 2671 contains enough
specification, and the rfc2671bis draf=
t again clarifies that DNS
servers recieving an OPT RR in a query MUST i=
gnore unknown options.

Yes, that's exp=
licit.

The WG consensus in 200=
9 was that "ignore" also means to not copy
the option into the=
 OPT RR in the response (if any), and
implementers had confirmed those d=
ays that this was the behavior
of state-of-the-art EDNS implementations.=


Yes, that's right.  I'm worried =
about non state-of-the-art implementations ;-)

Thus, according to my understanding, a conformant recipien=
t of an
OPT RR in a DNS query behaves as follows:

a) no support f=
or EDNS present
   (either not built-in or disabled by config)=
:
   ignore entire OPT RR, do not include OPT RR into response=
;
   possible legacy alternative: return FormErr;
b) suppor=
t for EDNS present, but no support present for a particular
   =
;option received: ignore it, do not include it in response;
c) support f=
or particular EDNS option present:
   behave according to the =
specification of that option
   (which may be: echo the receiv=
ed option unchanged, or otherwise).

Since the QTCOUNT is redundant a=
s well, the first octect of the
proposed option format is indeed redunda=
nt.

Note however, that rfc2671bis allows additional handshaking.
=
So it's a matter of simplicity vs. redundancy and actual gain.

Indeed - =A76.1.2

"<=
span class=3D"Apple-style-span" style=3D"font-family: monospace; font-size:=
 13px; white-space: pre; ">Specifications of such options might wish to
 include some kind of sign=
aled acknowledgement"

I do think such signalled acknowledgement is sensible,=
 given my experiences with various middleboxes that will blithely ignore ma=
ny things written in the RFCs.  At least with a signalling bit you can=
 have an _explicit_ confirmation that the far end knows what it's doing.

That said, I'm _kind of_ OK with Dick's proposal tha=
t the response use a different option code instead of using the QTD bit. &n=
bsp;That's consistent with ICMP, although off the top of my head I'm not aw=
are of any other part of DNS that does this.

kind =
regards,

Ray



=

--_000_DBC3C50C10A749808B9764FC7F1CAA8Fnominetorguk_--

--===============0217255608208258586==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0217255608208258586==--

From dnsext-bounces@ietf.org  Fri Mar 30 06:59:17 2012
Return-Path: 
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DB421F86D0; Fri, 30 Mar 2012 06:59:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333115956; bh=3g6Obe54SYpvti/gTRe68UtacqreeEfGVJSWjbH84eQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=HkvdPRmVCzpMu/nYUMYFDJmE6vekmPLFcUh7IsQOLRwTSnjLjOx9gKffQSqNRhvLZ tqNAaEHyQzF77meYsW94+CwCKJNGdD1+FOxw8wO+lPRXbgPIJM7VzDTKsJqBP/t1M7 e/TJRgXVuNpdth/M/lep9BL3CSLmnEH+8hU0NoqI=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1028F21F86D0 for ; Fri, 30 Mar 2012 06:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.926
X-Spam-Level: 
X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0cG06vQZvJL for ; Fri, 30 Mar 2012 06:59:15 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA3621F86CA for ; Fri, 30 Mar 2012 06:59:15 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so448600qcs.31 for ; Fri, 30 Mar 2012 06:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=g+W4NXmNgqg0D2BcH5GQGPDbEDHK4daFA2VvhXuNqQ0=; b=xBT3am1S91NPsmkTRoZjXuRdZ/BLx0c2Uyx3p8MkvmOsmxsvZ3wmnUo1C4Fn+i0vNS mfxl3alrWI2s/zdSzDA6uBBdakZGm9DVdSjQjmy8UE6kIhM7QktfRvCI3msV+4vM0Qpn dFDQrfyIbWVIchWNuarrKr1xkoG9lNQTlO+uIvfiX1sY1Y/Jssj/zb1z0JpSOUILi20j AC7SYCrnQXIIYqXhfYaoe0yTreDD/kwWq5ApnMCXnZc6p4ySHIO6nmafTlKi0dRYAyBP f28gVfWkRMbMSywJ15vjHRJo8hCmJttI756bLuT/H6NxHPQxNrl3/bWwwXmENsfeopqN CMuQ==
Received: by 10.224.221.146 with SMTP id ic18mr5452312qab.71.1333115954687; Fri, 30 Mar 2012 06:59:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.92.71 with HTTP; Fri, 30 Mar 2012 06:58:54 -0700 (PDT)
In-Reply-To: 
References: <201203292010.WAA20455@TR-Sys.de> 
From: Dick Franks 
Date: Fri, 30 Mar 2012 14:58:54 +0100
X-Google-Sender-Auth: 6OJ7wdmn6mu4LreMEOOZDIlX4Mc
Message-ID: 
To: Ray Bellis 
Cc: =?UTF-8?Q?Alfred_H=C3=8Enes?= , "" 
Subject: Re: [dnsext] Signaling ENDS option understanding in draft-bellis-dnsext-multi-qtypes-01
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============3068368182389692537=="
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

--===============3068368182389692537==
Content-Type: multipart/alternative; boundary=20cf3074b4eeec6f6304bc763e8e

--20cf3074b4eeec6f6304bc763e8e
Content-Type: text/plain; charset=UTF-8

Ray,

On 30 March 2012 10:27, Ray Bellis  wrote:

>
> That said, I'm _kind of_ OK with Dick's proposal that the response use a
> different option code instead of using the QTD bit.  That's consistent with
> ICMP, although off the top of my head I'm not aware of any other part of
> DNS that does this.
>

ICMP ECHO was indeed the model I had in mind.

Regards
--Dick

--20cf3074b4eeec6f6304bc763e8e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ray,

On 30 March 2012 10:27, Ray Bellis <=
span dir=3D"ltr"><Ray.Belli=
s@nominet.org.uk> wrote:





That said, I'm _kind of_ O=
K with Dick's proposal that the response use a different option code in=
stead of using the QTD bit. =C2=A0That's consistent with ICMP, although=
 off the top of my head I'm not aware of any other part of DNS that doe=
s this.



=C2=A0
ICMP ECHO was indeed the model I had in m=
ind. 

Regards
--Dick


--20cf3074b4eeec6f6304bc763e8e--

--===============3068368182389692537==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============3068368182389692537==--