From ogud@ogud.com Fri Mar 2 04:07:43 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 02 Mar 2012 12:07:43 -0000 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 From miekg@atoom.net Sun Mar 4 12:53:53 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline 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: , X-List-Received-Date: Sun, 04 Mar 2012 20:53:53 -0000 --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-- From marka@isc.org Sun Mar 4 14:12:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , X-List-Received-Date: Sun, 04 Mar 2012 22:12:13 -0000 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 From iesg-secretary@ietf.org Mon Mar 5 14:08:50 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 05 Mar 2012 22:08:51 -0000 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. From internet-drafts@ietf.org Tue Mar 6 08:29:35 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <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: , X-List-Received-Date: Tue, 06 Mar 2012 16:29:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. 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 From marc.lampo@eurid.eu Wed Mar 7 00:54:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: 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: , X-List-Received-Date: Wed, 07 Mar 2012 08:54:41 -0000 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 From fanf2@hermes.cam.ac.uk Wed Mar 7 06:39:18 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch 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: , X-List-Received-Date: Wed, 07 Mar 2012 14:39:18 -0000 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. From Ed.Lewis@neustar.biz Wed Mar 7 09:27:45 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , X-List-Received-Date: Wed, 07 Mar 2012 17:27:45 -0000 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! From Ed.Lewis@neustar.biz Wed Mar 7 10:04:12 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , X-List-Received-Date: Wed, 07 Mar 2012 18:04:12 -0000 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! From iesg-secretary@ietf.org Wed Mar 7 16:50:44 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Thu, 08 Mar 2012 00:50:44 -0000 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. From bmanning@karoshi.com Thu Mar 8 02:17:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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-Type: text/plain; charset=us-ascii 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: , X-List-Received-Date: Thu, 08 Mar 2012 10:17:24 -0000 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 From Ed.Lewis@neustar.biz Thu Mar 8 06:08:08 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , X-List-Received-Date: Thu, 08 Mar 2012 14:08:08 -0000 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! From A.Hoenes@TR-Sys.de Thu Mar 8 07:33:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Thu, 08 Mar 2012 15:33:22 -0000 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 | +------------------------+--------------------------------------------+ From Joe.Gersch@Secure64.com Thu Mar 8 08:11:18 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: multipart/alternative; boundary="Apple-Mail=_63F94325-22A2-4800-9D4C-C79C74F09F5A" 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: , X-List-Received-Date: Thu, 08 Mar 2012 16:11:18 -0000 --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-- From ted.ietf@gmail.com Thu Mar 8 11:16:33 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Thu, 08 Mar 2012 19:16:33 -0000 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 accordin= g > =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/ > From marka@isc.org Thu Mar 8 13:13:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , X-List-Received-Date: Thu, 08 Mar 2012 21:13:25 -0000 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 From weiler@watson.org Thu Mar 8 15:35:59 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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: , X-List-Received-Date: Thu, 08 Mar 2012 23:36:00 -0000 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 From paul.hoffman@vpnc.org Thu Mar 8 16:25:36 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 8 Mar 2012 16:25:30 -0800 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Fri, 09 Mar 2012 00:25:36 -0000 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. >=20 > There are a couple of these default actions that I'm uneasy with. >=20 >=20 > On Tue, 7 Feb 2012, Andrew Sullivan wrote: >=20 >> ISSUE 3: Alter section 5.10 >>=20 >> 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? >>=20 >> DEFAULT ACTION: Include the "If a site has only a single trust >> anchor ?" sentence, and exclude the other proposed sentences. >=20 > 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. =20 >> ISSUE 4: Request to change the language in 5.6 >>=20 >> 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. >>=20 >> 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.") >=20 > 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 From ajs@anvilwalrusden.com Thu Mar 8 17:05:19 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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-Type: text/plain; charset=us-ascii 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: , X-List-Received-Date: Fri, 09 Mar 2012 01:05:20 -0000 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 From paul.hoffman@vpnc.org Thu Mar 8 18:07:43 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120309010514.GD88825@mail.yitter.info> Date: Thu, 8 Mar 2012 18:07:38 -0800 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Fri, 09 Mar 2012 02:07:43 -0000 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: >>=20 >> 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: >>=20 >> 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. >=20 > 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. >=20 > 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.") >>>=20 >>> 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. >>=20 >>=20 >> 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. >>=20 >=20 > 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 From wjhns1@hardakers.net Thu Mar 8 19:57:06 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain 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: , X-List-Received-Date: Fri, 09 Mar 2012 03:57:06 -0000 >>>>> 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. From miekg@atoom.net Fri Mar 9 01:07:52 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline 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: , X-List-Received-Date: Fri, 09 Mar 2012 09:07:52 -0000 --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-- From A.Hoenes@TR-Sys.de Fri Mar 9 05:11:34 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit 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: , X-List-Received-Date: Fri, 09 Mar 2012 13:11:34 -0000 Folks, I have submitted a revised version of our RFC 1995bis (IXRF) draft. As discussed at the Maastricht (IETF 78) and Prague (IETF 80) DNSEXT sessions, this topic is regarded as covered by the chartered work item for DNSEXT vovering IXFR-ONLY. The new version tries to capture the outcome of the on-list discussion (and some internal conversations) since the posting of the -02 version last spring, after IETF 80, in particular the related threads on namedroppers in June/August 2011. My apologies for the delays in the editorial work. To allow better threading of related list submissions, I will post two more messages regarding: a) the changes from -02 to -03 ; and b) the next steps with this draft. Please review the draft and the changes and opt for the next steps to undertake with the I-D, as will be detailed soon in these upcoming messages. ----- Forwarded message from internet-drafts@ietf.org ----- > From: internet-drafts@ietf.org > To: ah@TR-Sys.de > Cc: ondrej.sury@nic.cz > Message-Id: <20120309121227.21341.9777.idtracker@ietfa.amsl.com> > Date: Fri, 09 Mar 2012 04:12:27 -0800 > Subject: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-03.txt > > A new version of I-D, draft-ah-dnsext-rfc1995bis-ixfr-03.txt > has been successfully submitted by Alfred Hoenes and posted > to the IETF repository. > > Filename: draft-ah-dnsext-rfc1995bis-ixfr > Revision: 03 > Title: DNS Incremental Zone Transfer Protocol (IXFR) > Creation date: 2012-03-09 > WG ID: Individual Submission > Number of pages: 32 > > Abstract: > 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. > > > The IETF Secretariat ----- End of forwarded message from internet-drafts@ietf.org ----- The draft and diffs are available online at the common locations, including the IETF Tools page: Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | 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 | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Fri Mar 9 05:22:26 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 09 Mar 2012 13:22:26 -0000 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. From A.Hoenes@TR-Sys.de Fri Mar 9 05:23:38 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 09 Mar 2012 13:23:38 -0000 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. From A.Hoenes@TR-Sys.de Fri Mar 9 07:52:42 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 09 Mar 2012 15:52:42 -0000 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. From gson@araneus.fi Fri Mar 9 09:37:10 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 09 Mar 2012 17:37:10 -0000 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 From A.Hoenes@TR-Sys.de Fri Mar 9 10:07:03 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 09 Mar 2012 18:07:03 -0000 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 > From A.Hoenes@TR-Sys.de Fri Mar 9 11:01:55 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 09 Mar 2012 19:01:55 -0000 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 | +------------------------+--------------------------------------------+ From warren@kumari.net Fri Mar 9 11:20:28 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset=iso-8859-1 From: Warren Kumari In-Reply-To: <201203091321.OAA28689@TR-Sys.de> Date: Fri, 9 Mar 2012 14:20:23 -0500 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Fri, 09 Mar 2012 19:20:28 -0000 On Mar 9, 2012, at 8:21 AM, Alfred H=CEnes wrote: > DNSEXT folks, >=20 > [ SNIP ] >=20 > 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 >=20 > 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. >=20 > 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. >=20 > B) Otherwise. >=20 > 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. >=20 > We'd then like the chairs to organize and quickly execute a > pseudo-WGLC for the present draft version on the dnsext list. >=20 > 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. >=20 >=20 > To this end, we'd like to solicit quick feedback on how to proceed. >=20 >=20 > 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), >=20 > Alfred. >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 From A.Hoenes@TR-Sys.de Fri Mar 9 12:35:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 09 Mar 2012 20:35:03 -0000 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. From gson@araneus.fi Sat Mar 10 01:31:14 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Sat, 10 Mar 2012 09:31:14 -0000 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 From miekg@atoom.net Sun Mar 11 03:02:35 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline 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: , X-List-Received-Date: Sun, 11 Mar 2012 10:02:36 -0000 --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-- From mohta@necom830.hpcl.titech.ac.jp Sun Mar 11 06:38:28 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Sun, 11 Mar 2012 13:38:28 -0000 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 From warren@kumari.net Sun Mar 11 22:14:30 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <20120306162935.4172.91398.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 23:14:26 -0600 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 12 Mar 2012 05:14:30 -0000 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 = and easier to read=85 W On Mar 6, 2012, at 10:29 AM, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the DNS Extensions Working = Group of the IETF. >=20 > 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 >=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. >=20 >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-0= 4.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04= .txt >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From paf@frobbit.se Sun Mar 11 22:26:53 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Sun, 11 Mar 2012 23:26:44 -0600 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 12 Mar 2012 05:26:53 -0000 Thanks! FWIW, as the individual that (still) has the task of verifying the = consensus around this draft, I have started walking around the = individuals I have seen commenting and asked them to explicitly look at = this -04 version and let 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) >=20 > I still support this draft, and find the current (-04) version cleaner = and easier to read=85 >=20 > W >=20 > On Mar 6, 2012, at 10:29 AM, Internet-Drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the DNS Extensions Working = Group of the IETF. >>=20 >> Title : 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 >>=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. >>=20 >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-0= 4.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04= .txt >>=20 >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >>=20 >=20 > -- > Don't be impressed with unintelligible stuff said condescendingly. > -- Radia Perlman. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 From scottr.nist@gmail.com Mon Mar 12 06:08:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset=us-ascii From: Scott Rose In-Reply-To: <20120309090748.GA20102@miek.nl> Date: Mon, 12 Mar 2012 09:08:06 -0400 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 12 Mar 2012 13:08:17 -0000 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.=20 >=20 > How about the following scheme: >=20 > 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: >=20 > 0: OPTION-CODE > 1: DAU byte value > 2: DHU byte value > 3: N3U byte value >=20 > And maybe this option can be renamed to Crypto Understood. >=20 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. >=20 > Regards, > Miek Gieben > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From scottr.nist@gmail.com Mon Mar 12 07:22:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset=us-ascii From: Scott Rose In-Reply-To: <20120311100232.GB23576@miek.nl> Date: Mon, 12 Mar 2012 10:22:07 -0400 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 12 Mar 2012 14:22:25 -0000 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-0= 4.txt >=20 > 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) >=20 > | 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 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 =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. >=20 Correct - that was left out and should be re-added. Thanks, Scott > Regards, >=20 > --=20 > Miek Gieben > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From warren@kumari.net Mon Mar 12 11:11:52 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 12 Mar 2012 18:11:52 -0000 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), but 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=20 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, Section 2 The TLSA Resource Record ( http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt )=20 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 possiable 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. =20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From ogud@ogud.com Mon Mar 12 11:41:59 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 12 Mar 2012 18:41:59 -0000 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 > > > From internet-drafts@ietf.org Mon Mar 12 11:57:54 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <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: , X-List-Received-Date: Mon, 12 Mar 2012 18:57:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Upd= ates 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-updat= e-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 From scottr.nist@gmail.com Mon Mar 12 12:04:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset=us-ascii From: Scott Rose In-Reply-To: Date: Mon, 12 Mar 2012 15:03:58 -0400 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 12 Mar 2012 19:04:16 -0000 On Jan 12, 2012, at 11:11 PM, Samuel Weiler wrote: > Looking just at draft-srose-dnssec-registry-update-00: >=20 > 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. >=20 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. >=20 > 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 From weiler@watson.org Mon Mar 12 12:08:50 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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: , X-List-Received-Date: Mon, 12 Mar 2012 19:08:50 -0000 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 From weiler@watson.org Mon Mar 12 12:20:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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: , X-List-Received-Date: Mon, 12 Mar 2012 19:20:40 -0000 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 From fanf2@hermes.cam.ac.uk Mon Mar 12 12:32:54 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch 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: , X-List-Received-Date: Mon, 12 Mar 2012 19:32:54 -0000 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. From weiler@watson.org Mon Mar 12 12:55:36 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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: , X-List-Received-Date: Mon, 12 Mar 2012 19:55:36 -0000 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 From weiler@watson.org Mon Mar 12 13:05:00 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: , X-List-Received-Date: Mon, 12 Mar 2012 20:05:00 -0000 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 From warren@kumari.net Mon Mar 12 13:23:05 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Mon, 12 Mar 2012 14:23:03 -0600 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 12 Mar 2012 20:23:05 -0000 On Mar 12, 2012, at 1:32 PM, Tony Finch wrote: > Warren Kumari wrote: >>=20 >> I am requesting Expert review for an RRTYPE allocation for = draft-ietf-dane-protocol-18. >=20 > 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-rrtype-applications@ietf.org, I forgot to. So, I have just forwarded it to them=85. W >=20 > Tony. > --=20 > f.anthony.n.finch http://dotat.at/ > North Utsire: Westerly 3 or 4. Moderate. Mainly fair. Moderate or = good, > occasionally poor at first. >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From davidb@verisign.com Mon Mar 12 13:36:53 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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] Content-Type: multipart/signed; boundary="Apple-Mail=_F50BD115-BE30-468F-8B45-E7470FF61FCC"; protocol="application/pkcs7-signature"; micalg=sha1 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: , X-List-Received-Date: Mon, 12 Mar 2012 20:36:53 -0000 --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-- From weiler@watson.org Mon Mar 12 14:24:07 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: , X-List-Received-Date: Mon, 12 Mar 2012 21:24:07 -0000 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 From internet-drafts@ietf.org Mon Mar 12 14:24:19 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <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: , X-List-Received-Date: Mon, 12 Mar 2012 21:24:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. 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 From marka@isc.org Mon Mar 12 17:18:50 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , X-List-Received-Date: Tue, 13 Mar 2012 00:18:50 -0000 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 From fneves@registro.br Mon Mar 12 20:55:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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-Type: text/plain; charset=us-ascii 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: , X-List-Received-Date: Tue, 13 Mar 2012 03:55:13 -0000 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-- From marc.lampo@eurid.eu Tue Mar 13 00:58:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: 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: , X-List-Received-Date: Tue, 13 Mar 2012 07:58:23 -0000 (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 From miekg@atoom.net Tue Mar 13 01:07:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline 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: , X-List-Received-Date: Tue, 13 Mar 2012 08:07:39 -0000 --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-- From marka@isc.org Tue Mar 13 01:21:51 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , X-List-Received-Date: Tue, 13 Mar 2012 08:21:51 -0000 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 From miekg@atoom.net Tue Mar 13 01:39:28 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline 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: , X-List-Received-Date: Tue, 13 Mar 2012 08:39:28 -0000 --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-- From scottr.nist@gmail.com Tue Mar 13 07:24:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset=us-ascii From: Scott Rose In-Reply-To: <4f5efe2f.42c52a0a.3569.ffff81a7SMTPIN_ADDED@mx.google.com> Date: Tue, 13 Mar 2012 10:22:45 -0400 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Tue, 13 Mar 2012 14:24:31 -0000 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 ?) >=20 > -----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:=20 > draft-ietf-dnsext-dnssec-algo-signal-04.txt >=20 > Hello, >=20 > Suggestion. >=20 > In 6. Traffic Analysis Considerations >=20 > "... should monitor DNS query > traffic and record the values of the DAU/DHU/N3U option(s) in > queries. ..." >=20 > --> Suggest to add that also monitored are : > - (number of) DNS Queries, with EDNS0 OPT record, but without any=20= > signalling done >=20 > Motivation : > The difference in number of queries with and without Algo-Signalling > shows how reliable the signalling information is. >=20 > Kind regards, >=20 > Marc Lampo > Security Officer > EURid (for .eu) >=20 >=20 > -----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 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. This draft is a work item of the DNS Extensions Working = Group=20 > of the IETF. >=20 > 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 >=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. >=20 >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-0= 4.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04= .txt >=20 >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From suruti94@gmail.com Tue Mar 13 10:38:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Tue, 13 Mar 2012 17:38:25 -0000 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 quer= y > 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 befor= e > 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 > From paul.hoffman@vpnc.org Fri Mar 16 10:47:37 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Fri, 16 Mar 2012 17:47:37 -0000 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 From iesg-secretary@ietf.org Fri Mar 16 12:34:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 16 Mar 2012 19:34:16 -0000 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. From marka@isc.org Fri Mar 16 16:36:43 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , X-List-Received-Date: Fri, 16 Mar 2012 23:36:43 -0000 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 From Ray.Bellis@nominet.org.uk Sat Mar 17 06:31:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Sat, 17 Mar 2012 13:31:25 -0000 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_. Ray From paul.hoffman@vpnc.org Sat Mar 17 07:41:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) Content-Type: text/plain; charset=us-ascii 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 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Sat, 17 Mar 2012 14:41:11 -0000 On Mar 16, 2012, at 4:36 PM, Mark Andrews wrote: >=20 > 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=20 >> the ones we have done here. >>=20 >> --Paul Hoffman >=20 > 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 From marka@isc.org Sat Mar 17 16:37:41 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , X-List-Received-Date: Sat, 17 Mar 2012 23:37:41 -0000 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 From dougb@dougbarton.us Sat Mar 17 18:36:48 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Sun, 18 Mar 2012 01:36:48 -0000 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 From Ray.Bellis@nominet.org.uk Mon Mar 19 07:58:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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-Type: text/plain; charset="iso-8859-1" Content-ID: <19cde0a1-3f7b-48a0-a400-ef478ffc4de1> Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 19 Mar 2012 14:58:24 -0000 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 / N= S records would indicate. Ray From nweaver@icsi.berkeley.edu Mon Mar 19 08:41:12 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 19 Mar 2012 15:41:12 -0000 Is there currently a standard wire/storage format for capturing the = entire DNSSEC signature chain required for validation in a single = transaction? From fanf2@hermes.cam.ac.uk Mon Mar 19 09:11:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch 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: , X-List-Received-Date: Mon, 19 Mar 2012 16:11:16 -0000 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. From d3e3e3@gmail.com Mon Mar 19 09:29:14 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 19 Mar 2012 16:29:14 -0000 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 From Jeff.Hodges@KingsMountain.com Mon Mar 19 10:15:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 19 Mar 2012 17:15:31 -0000 > 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 From dougb@dougbarton.us Mon Mar 19 15:48:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 19 Mar 2012 22:48:13 -0000 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 From marka@isc.org Mon Mar 19 16:13:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , X-List-Received-Date: Mon, 19 Mar 2012 23:13:24 -0000 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 From Ray.Bellis@nominet.org.uk Tue Mar 20 02:31:36 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Tue, 20 Mar 2012 09:31:36 -0000 On 19 Mar 2012, at 22:48, Doug Barton wrote: >=20 > 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.e1= 64.arpa, at which point we send a referral _for the whole domain name_ poin= ting at ns1.example.com. The query arrives there, and is duly answered. Sans DNSSEC, the mismatch i= n the zone cut between parent and child is never noticed. Ray From fanf2@hermes.cam.ac.uk Tue Mar 20 04:45:06 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch 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: , X-List-Received-Date: Tue, 20 Mar 2012 11:45:06 -0000 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. From dougb@dougbarton.us Tue Mar 20 22:48:52 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Wed, 21 Mar 2012 05:48:52 -0000 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 From ogud@ogud.com Fri Mar 23 08:42:14 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 23 Mar 2012 15:42:14 -0000 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 From weiler@watson.org Fri Mar 23 11:13:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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: , X-List-Received-Date: Fri, 23 Mar 2012 18:13:22 -0000 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 From weiler@watson.org Fri Mar 23 11:17:41 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: , X-List-Received-Date: Fri, 23 Mar 2012 18:17:41 -0000 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 From fanf2@hermes.cam.ac.uk Fri Mar 23 11:23:55 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch 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: , X-List-Received-Date: Fri, 23 Mar 2012 18:23:55 -0000 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. From A.Hoenes@TR-Sys.de Fri Mar 23 13:59:00 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit 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: , X-List-Received-Date: Fri, 23 Mar 2012 20:59:00 -0000 I have reviewed draft-ietf-dnsext-rfc2671bis-edns0-08 and would like to submit a few LC comments. Summary: ======= The draft is almost ready for publication as a (Full) Internet Standard RFC. (Note: Shouldn't the Last Call template now be aligned with the RFC 6410 maturity level designations and use "Internet Standard" in place of "Full Standard" -- both in the headline and in the body?) The technical content is sound and stable and supported by consensus in the DNS community, including all major DNS implementers; it is also well aligned with other recent documents / documents in the pipeline. AFAICT, the document fulfills the criteria posed in Section 2.2 of RFC 6410 for "Internet Standard". I only found a few minor textual issues (see below) and a couple of editorial nits (being communicated to a smaller distribution list) that all could be easily addressed during final processing stages. Minor textual issues: ==================== a) Section 3, last line I suspect that "... generalized use of TCP for DNS transport." is not what the authors had in mind, it likely should be "... general use of TCP for DNS transport." (or s/general/more frequent/) b) Section 6.1.2 -- procedural clarification I suggest to slightly amend the very last sentence of s6.1.2 : OLD: [...]. For example, an option specification might say that if a responder sees option XYZ, it MUST include option XYZ in its response. NEW: [...]. For example, an option specification might say that if a responder sees and understands option XYZ, it MUST include option XYZ in its response. (or add "and supports" in place of "and understands") c) Section 6.2.2 -- terminological clarification Since EDNS is -- at least in principle -- designed to be a versioned family of DNS protocol extensions based on the OPT RR, and such versions are expected to be upward compatible, the second mention of "ENDS0" in that paragraph should better say "EDNS" (without the version '0', see below) or (less preferably) "EDNS(0)". OLD: If a requestor detects that the remote end does not support EDNS0, it MAY issue queries without an OPT record. It MAY cache this knowledge for a brief time in order to avoid fallback delays in the future. However, if DNSSEC or any future option using EDNS is required, no | fallback should be performed as they are only signaled through EDNS0. If an implementation detects that some servers for the zone support EDNS(0) while others would force the use of TCP to fetch all data, preference SHOULD be given to those support EDNS(0). NEW: If a requestor detects that the remote end does not support EDNS0, it MAY issue queries without an OPT record. It MAY cache this knowledge for a brief time in order to avoid fallback delays in the future. However, if DNSSEC or any future option using EDNS is required, no | fallback should be performed as they are only signaled through EDNS. If an implementation detects that some servers for the zone support EDNS(0) while others would force the use of TCP to fetch all data, preference SHOULD be given to those support EDNS(0). d) Section 7 -- terminology and additional Reference I suggest to capitalize the RFC 5226 term used here and add a ref. to RFC 5226. Further in terminology: with regard to IANA, "allocation" usually indicates handing out a block of codepoints -- for instance for assigment of code points contained within that block to specific purposes by the entity that seeks the allocation (e.g.: IP addresses) -- whereas "assignment" refers to the assignment of specific code points; therfore, I suggest to switch the terms used. OLD: 7. OPT Option Code Allocation Procedure Allocations are assigned by expert review. Assignment of Option Codes should be liberal, but duplicate functionality is to be avoided. NEW: |7. OPT Option Code Assignment Procedure | OPT Option Codes are assigned by Expert Review [RFC5226]. Assignment of Option Codes should be liberal, but duplicate functionality is to be avoided. e) Section 10 (IANA Considerations) Because the two sentences contained in it are related to two different namespaces managed by IANA, for uniformity of the presentation in this section, I suggest to split the last paragraph of that section into two: OLD: IETF Standards Action is required to create new entries in the EDNS Version Number registry. Expert Review is required for allocation of an EDNS Option Code. NEW: IETF Standards Action is required to create new entries in the EDNS | Version Number registry. | Expert Review is required for allocation of an EDNS Option Code. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | 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 | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Fri Mar 23 14:00:42 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit 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: , X-List-Received-Date: Fri, 23 Mar 2012 21:00:42 -0000 As mentioned in the first part of my IETF LC review of draft-ietf-dnsext-rfc2671bis-edns0-08 also sent to the IETF main list, I also found a couple of editorials that should be addressed before publication -- maybe at the RFC Editor. Editorials ========== A) Recurring details, grouped by topic: 1) usage of article with "DNS" If used as a noun, "DNS" should better be accompanied by an article. In particular: - in Section 1, 2nd para: | [RFC2671] added an extension mechanism to DNS. [...] --- vvvvv | [RFC2671] added an extension mechanism to the DNS. [...] - in Section 3, 1st para: | EDNS provides a mechanism to improve the scalability of DNS as its uses get more diverse on the Internet. [...] --- vvvvv | EDNS provides a mechanism to improve the scalability of the DNS as its uses get more diverse on the Internet. [...] - in Section 3, 2nd para: | With time, some applications of DNS have made EDNS a requirement for their deployment. [...] --- vvvvv | With time, some applications of the DNS have made EDNS a requirement for their deployment. [...] 2) precise usage of "that" vs. "which" According to the RFC Editor explanations, in the following instances I found the "which" used in the draft needs to be replaced by "that": - Section 2, 1st para: "other DNS component that responds ..." - Section 6.2.3, 3rd para (2 instances): vvvv | [...]. For example, if a requestor sits behind a firewall that will block fragmented IP packets, a requestor SHOULD NOT choose a | value that will cause fragmentation. [...] ^^^^ - Section 6.2.4: "... an UPDATE that takes advantage of ..." - Section 6.2.5, 2nd para: "... a fallback mechanism that begins ..." - Section 6.2.6, 3rd para: "Middleboxes that simply forward ..." - Section 6.2.6, 4th para: "Middleboxes that have additional ..." - Section 8, 3rd para: "Responders that choose not to ..." - Section 8, 4th para: "... servers that do not implement ..." 3) "rational quotation" style Please adjust - in Section 1, last para: [RFC2671] specified extended label types. The only one proposed was | in [RFC2673] for a label type called "Bitstring Labels." [...] --- ^^ [RFC2671] specified extended label types. The only one proposed was | in [RFC2673] for a label type called "Bitstring Labels". [...] ^^ - in Section 6.1.3, explanation of VERSION: Indicates the implementation level of the setter. Full conformance with this specification is indicated by version | ``0.'' Requestors are encouraged to [...] --- ^^^ Indicates the implementation level of the setter. Full conformance with this specification is indicated by version | ``0''. Requestors are encouraged to [...] ^^^ But there seems no need to quote the VERSION value 0 -- in the same paragraph and in other parts of the memo, field values are regularly shown literally or symbolically without any quotes. So it would be even more preferable to simplify this to: Indicates the implementation level of the setter. Full conformance with this specification is indicated by version 0. Requestors are encouraged to [...] 4) Hyphenation Please use hyphens in word combinations used as attributes: - in Section 8, 4th para: s/out of range values/out-of-range values/ - in Section 9, 1st para: s/a DNS denial of service attack/a DNS denial-of-service attack/ B) singular details: 5) Section 4.1 There seems to be a spurious comma, and two instances of "of" are missing: The DNS Message Header's second full 16-bit word is divided into a | 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see , v ^^ | section 4.1.1 [RFC1035]). Some of these were marked for future use, | and most these have since been allocated. [...] --- ^ The DNS Message Header's second full 16-bit word is divided into a | 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see section | 4.1.1 of [RFC1035]). Some of these were marked for future use, and | most of these have since been allocated. [...] 6) Section 5, 3rd para -- punctuation For clarity, two commas should be added as follows to delineate the first sub-clause starting with "which": Extended Label Types are difficult to use due to support in clients | and intermediate gateways as described in [RFC3364], which moves them | to experimental status, and [RFC3363], which describes the pros and cons. Alternatively, the "which" sub-clauses might be placed parentheses: Extended Label Types are difficult to use due to support in clients | and intermediate gateways as described in [RFC3364] (which moves them | to experimental status) and [RFC3363] (which describes the pros and cons). 7) Section 6.1.3, explanation of VERSION s/run time configuration option/runtime configuration option/ ^ 8) Section 6.2.6 - In the first para, a comma should be placed for clarity in the 1st line: | In a network that carries DNS traffic, there could ... ^ - At the very end of the last para, the trailing period is missing. 9) Section 8, 4th para -- punctuation I suggest to place a comma for clarity: | [...] If this occurs, the responder MUST ... ^ 10) Section 10 -- grammar / typos - At about one third of the section: vv | IANA is advised to udpates references to [RFC2671] in these entries and sub-registries to this document. --- v | IANA is advised to udpate references to [RFC2671] in these entries and sub-registries to this document. - In the second-to-last para: | [...]. For many uses, a EDNS Option Code may be preferred. --- vv | [...]. For many uses, an EDNS Option Code may be preferred. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | 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 | +------------------------+--------------------------------------------+ From ogud@ogud.com Fri Mar 23 14:06:50 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 23 Mar 2012 21:06:50 -0000 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 From marka@isc.org Sun Mar 25 17:38:21 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , X-List-Received-Date: Mon, 26 Mar 2012 00:38:22 -0000 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 From marka@isc.org Sun Mar 25 17:51:59 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , X-List-Received-Date: Mon, 26 Mar 2012 00:51:59 -0000 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 From marka@isc.org Sun Mar 25 17:56:28 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , X-List-Received-Date: Mon, 26 Mar 2012 00:56:28 -0000 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 From paf@frobbit.se Mon Mar 26 01:55:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , X-List-Received-Date: Mon, 26 Mar 2012 08:55:40 -0000 --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-- From ogud@ogud.com Mon Mar 26 02:14:06 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 26 Mar 2012 09:14:06 -0000 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 From Ed.Lewis@neustar.biz Mon Mar 26 02:44:10 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , X-List-Received-Date: Mon, 26 Mar 2012 09:44:10 -0000 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! From fanf2@hermes.cam.ac.uk Mon Mar 26 03:00:44 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch 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: , X-List-Received-Date: Mon, 26 Mar 2012 10:00:44 -0000 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. From Ed.Lewis@neustar.biz Mon Mar 26 04:00:37 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [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: , X-List-Received-Date: Mon, 26 Mar 2012 11:00:37 -0000 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! From miekg@atoom.net Mon Mar 26 04:06:14 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline 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: , X-List-Received-Date: Mon, 26 Mar 2012 11:06:14 -0000 --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-- From internet-drafts@ietf.org Mon Mar 26 06:52:06 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <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: , X-List-Received-Date: Mon, 26 Mar 2012 13:52:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. 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 From rwfranks@gmail.com Mon Mar 26 07:14:56 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Sender: rwfranks@gmail.com 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?= Content-Type: multipart/alternative; boundary=20cf3074d9e29a23f804bc25ff8e 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: , X-List-Received-Date: Mon, 26 Mar 2012 14:14:56 -0000 --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--

From internet-drafts@ietf.org  Mon Mar 26 07:26:08 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <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: , 
X-List-Received-Date: Mon, 26 Mar 2012 14:26:08 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the DNS Extensions Working Group of the I=
ETF.

	Title           : Applicability Statement: DNS Security (DNSSEC) DNSKEY Al=
gorithm 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-statu=
s-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


From scottr.nist@gmail.com  Mon Mar 26 07:33:17 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=us-ascii
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
Content-Transfer-Encoding: quoted-printable
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: , 
X-List-Received-Date: Mon, 26 Mar 2012 14:33:17 -0000

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:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the DNS Extensions Working =
Group of the IETF.
>=20
> 	Title           : 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
>=20
>   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.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-stat=
us-01.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-statu=
s-01.txt
>=20
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext


From rja.lists@gmail.com  Mon Mar 26 15:29:24 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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: , 
X-List-Received-Date: Mon, 26 Mar 2012 22:29:24 -0000

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.


From marka@isc.org  Mon Mar 26 16:15:30 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , 
X-List-Received-Date: Mon, 26 Mar 2012 23:15:30 -0000

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

From d3e3e3@gmail.com  Mon Mar 26 16:34:35 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: , 
X-List-Received-Date: Mon, 26 Mar 2012 23:34:35 -0000

>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

From A.Hoenes@TR-Sys.de  Tue Mar 27 00:32:09 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
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: , 
X-List-Received-Date: Tue, 27 Mar 2012 07:32:09 -0000

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


From internet-drafts@ietf.org  Tue Mar 27 01:07:12 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <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: , 
X-List-Received-Date: Tue, 27 Mar 2012 08:07:12 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the DNS Extensions Working Group of the I=
ETF.

	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


From Ray.Bellis@nominet.org.uk  Tue Mar 27 01:30:03 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: 
Content-Type: multipart/alternative; boundary="_000_DD6C7261806F4F338CF3D9A16FBD4B8Cnominetorguk_"
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: , 
X-List-Received-Date: Tue, 27 Mar 2012 08:30:03 -0000

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

From internet-drafts@ietf.org  Tue Mar 27 01:47:31 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <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: , 
X-List-Received-Date: Tue, 27 Mar 2012 08:47:31 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the DNS Extensions Working Group of the I=
ETF.

	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


From rwfranks@gmail.com  Tue Mar 27 04:29:28 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Sender: rwfranks@gmail.com
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 
Content-Type: multipart/alternative; boundary=20cf3074d9e2acfab204bc37cd83
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: , 
X-List-Received-Date: Tue, 27 Mar 2012 11:29:28 -0000

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

From Ray.Bellis@nominet.org.uk  Tue Mar 27 04:51:49 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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-Type: text/plain; charset="us-ascii"
Content-ID: <8ebdd17b-82fe-4270-af85-4078e647447e>
Content-Transfer-Encoding: quoted-printable
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: , 
X-List-Received-Date: Tue, 27 Mar 2012 11:51:50 -0000

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

> Ray,
>=20
> IMHO data format is horribly overcomplicated.
>=20
>=20
> [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 bet=
ween a server which correctly parsed the option, and one that simply echoed=
 it.
=20
>    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


From nweaver@icsi.berkeley.edu  Tue Mar 27 04:58:42 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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)
Content-Type: text/plain; charset=us-ascii
From: Nicholas Weaver 
In-Reply-To: 
Date: Tue, 27 Mar 2012 04:58:38 -0700
Content-Transfer-Encoding: quoted-printable
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: , 
X-List-Received-Date: Tue, 27 Mar 2012 11:58:42 -0000

I think this is a bad idea: =20


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

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).


From A.Hoenes@TR-Sys.de  Tue Mar 27 07:03:46 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
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: , 
X-List-Received-Date: Tue, 27 Mar 2012 14:03:46 -0000

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.


From scottr.nist@gmail.com  Tue Mar 27 09:32:05 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Scott Rose 
In-Reply-To: 
Date: Tue, 27 Mar 2012 12:31:40 -0400
Content-Transfer-Encoding: quoted-printable
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: , 
X-List-Received-Date: Tue, 27 Mar 2012 16:32:05 -0000

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:

> =46rom 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...
>=20
> Thanks,
> Donald
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com
>=20
> 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.
>>>=20
>>> Personally, I'm thinking ECDSA might be moved to "Recommended..."
>>> since there are some advantages, but willing to leave it as is.
>>=20
>> All,
>>=20
>> I support the idea of moving ECDSA to "Recommended".
>>=20
>> 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.
>>=20
>> * The financial sector already seems to be migrating
>>  from RSA to EC for a wide range of things.
>>=20
>> * 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.
>>=20
>> * 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]
>>=20
>> Yours,
>>=20
>> Ran
>>=20
>>=20
>>=20
>> REFERENCES:
>>=20
>> [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.
>>=20
>> [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.
>>=20
>> [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.
>>=20
>> _______________________________________________
>> 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 scottr.nist@gmail.com  Tue Mar 27 09:44:28 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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)
Content-Type: text/plain; charset=iso-8859-1
From: Scott Rose 
In-Reply-To: <201203271402.QAA03645@TR-Sys.de>
Date: Tue, 27 Mar 2012 12:44:15 -0400
Content-Transfer-Encoding: quoted-printable
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: , 
X-List-Received-Date: Tue, 27 Mar 2012 16:44:28 -0000

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):
>=20
>=20
> 1)  General Terminology  (mostly in Section 1), and some nits
>=20
> * Sect. 1, 2nd para:
>=20
> "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.
>=20
> * Sect. 1, 3rd para:
>=20
> The draft should not say "EDNS attribute" in one place, always more
> precisely "EDNS option" (see snippet below).
>=20
> * Sect. 1, 3rd para, and Sect. 8, 2nd line:
>=20
> 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.
>=20
> Additionally, for enhanced clarity, I suggest to shuffle the words
> a bit and improve the language in the 3rd para of Section 1:
>=20
> 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].
>=20
> 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].
>=20
>=20
> 2)  "EDNS" vs. "EDNS0"
>=20
> 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).
>=20
> 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.
>=20
>=20
> 3)  error in example ??
>=20
> 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":
>=20
> OLD:
>=20
>   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.
>=20
> 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.
>=20
> (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.)
>=20
> The lower bound (22) corresponds to the lower counts mentioned,
> and the upper bound to the upper counts each:
>=20
> -  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
>=20
>=20
> 4)  typo in Sect. 3, 2nd para
>=20
> OLD:
>=20
>   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.  [...]
>=20
> NEW:
>=20
>   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.  [...]
>=20
>=20
> 5)  Section structure
>=20
> 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:
>=20
>    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
>=20
>=20
> 6)  Reference update
>=20
> The revised EDNS0 specification is ahead in the IESG, therefore I
> suggest to update the citations to RFC 2671 toward the 'bis' document.
>=20
>=20
> Best regards,
>  Alfred.
>=20


From A.Hoenes@TR-Sys.de  Tue Mar 27 10:11:58 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
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: , 
X-List-Received-Date: Tue, 27 Mar 2012 17:11:58 -0000

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.


From A.Hoenes@TR-Sys.de  Tue Mar 27 13:19:11 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
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: , 
X-List-Received-Date: Tue, 27 Mar 2012 20:19:11 -0000

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


From A.Hoenes@TR-Sys.de  Tue Mar 27 15:36:26 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
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: , 
X-List-Received-Date: Tue, 27 Mar 2012 22:36:27 -0000

Hi,
I've performed a quick review of the DNSEXT-related I-D,
    draft-cheshire-dnsext-special-names-02
and would like to submit a few notes.


(A)  Significant issues

(A.1)
Firstly, I'm surprised by the non-trivial overlap of this work
with RFC 6303 and the IANA Registry created by it, the "AS112" RFCs,
and the ongoing work-in-progress to address more emerging overload
reasons for the authoritative root/infrastructure DNS servers by
extending the scope of the AS112 project, registering more "special"
domain names in that "Locally Served DNS Zones" IANA registry, and
specifying that they be treated as specified in RFC 6303.

The present draft not even quotes RFC 6303 for Sect. 5.1, where
the largest overlap with RFC 6303 occurs.  (I have not yet studied
in detail inhowfar the new specification in that section is
compatible or collides with the normative behavior specified in
RFC 6303.)


(A.2)
Second, the new draft version has expanded the scope of the I-D
significantly, and that has not been reflected in the Abstract.
Maybe that should be amended like this:

OLD:

|Abstract
|
|  This document describes what it means to say that a DNS name is
|  reserved for special use, when reserving such a name is appropriate,
|  and the procedure for doing so.

NEW:

|Abstract
|
|  This document describes what it means to say that a DNS name is
|  reserved for special use, when reserving such a name is appropriate,
|  and the procedure for doing so.  It establishes an IANA registry for
|  such domain names and seeds it with some of the special domain names
|  established by existing RFCs.


(A.3)  Terminology, use of leading/trailing dots with domain names

Despite the colloquial "dot-com" speak, a dot should not be used
on the left-hand side of domain names -- maybe except when used as
an indication for subdomains, but that can be handled better by
suitable text.  Detailed examples are shown in the walk-through below.

In practice, the presence or absense of a trailing period is used to
distinguish between fully qualified and relative domain names (which
might be subjected to "domain suffix list" expansion in common APIs,
or which can appear in industry standard zone files under effect of
$ORIGIN directives) -- cf. Section 3.1, page 8 of RFC 1034.

Similarly, it might be worth using the more precise, common DNS terms
"Stub Resolver", and "Iterative Resolver" (instead of "Caching DNS
servers") throughout the draft -- authoritative DNS servers, DNS
proxies, and even stub resolvers commonly use some caching as well!


(A.4)  Section 5.1

As already mentioned above, this collides with RFC 6303 and the
IANA registry established by it.

I strongly recommend to remove _all_ domain names from this section
and instead include by reference the domain names registered in the
"Locally Served DNS Zones" IANA Registry established by RFC 6303.
It looks like all domain names suitable for registration there
-- not only the reverse DNS zone names for RFC 1812 addresses --
deserve the same behavior.
Also, to avoid collisions with behavior specified in RFC 6303,
Sections 2 and 3 of RFC 6303 should be carefully evaluated and any
overlapping or colliding text -- in particular in bullet 4. --
should be removed and replaced by a pointer to the normative text
in RFC 6303.


(B) editorial linear walk-through

(B.1) Section 1, 2nd para

The draft should better use the definite article when "DNS" is used
as a noun:

|  Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own
   concept of reserved names, [...]
---                                                   vvvv
|  Analogous to Special-Use IPv4 Addresses [RFC5735], the DNS has its
   own concept of reserved names, [...]


(B.2) Section 4, list item 6.

I suggest to add a comma for clarity:

      Does this reserved Special-Use Domain Name have any potential
      impact on DNS server operators? If they try to configure their
|     authoritative DNS server as authoritative for this reserved name
      will compliant name server software reject it as invalid? [...]
---
      Does this reserved Special-Use Domain Name have any potential
      impact on DNS server operators? If they try to configure their
|     authoritative DNS server as authoritative for this reserved name,
      will compliant name server software reject it as invalid? [...]


(B.3)  Sections 5.2 through 5.5, leading text each

*  The text in Section 5.4 says:

|                              [...]  In the text below the term
|  "invalid" is used in quotes to signify such names, as opposed to
|  names that may be invalid for other reasons (e.g. being too long).

This is a useful convention, and although "invalid" is likely the
most serious case, I strongly suggest to extend this convention
and style uniformly to Sections 5.2, 5.3, and 5.5 as well.
(Besides, in the quote above, a comma should be placed for improved
 readability after "below".)

*  As mentioned above above, the placement of leading/trailing periods
   in domain names should be aligned woth RFCs 1034, 1035, and 2181.

So, for instance, I recommend to change the "head" of Section 5.4
as follows:

OLD:

|5.4.  Domain Name Reservation Considerations for ".invalid."
|
|  The domain ".invalid.", and any names falling within ".invalid.", are
|  special in the ways listed below. In the text below the term
|  "invalid" is used in quotes to signify such names, as opposed to
|  names that may be invalid for other reasons (e.g. being too long).

NEW:

|5.4.  Domain Name Reservation Considerations for "invalid."
|
|  The domain "invalid.", and any names falling within "invalid.", are
|  special in the ways listed below. In the text below, the term
|  "invalid" is used in quotes to signify such names, as opposed to
|  names that may be invalid for other reasons (e.g. being too long).


I recommend that the "heads" of Sections 5.2, 5.3, and 5.5 are
modified in a similar manner, and the double-quoting of the
respective domain names be introduced throughout these sections.
For example:

NEW:

|5.2.  Domain Name Reservation Considerations for "test."
|
|  The domain "test.", and any names falling within "test.", are
|  special in the ways listed below.  For clarity, in the text below,
|  this domain name is always used in double-quoted form.


(B.4)
Following established practice, protocol field names and protocol
values should be spelled as in the normative specifications.

Hence, throughout the draft (i.e. in Sections 5.3, 5.4, and 5.5 --
bullet 6. each), please  s/rdata/RDATA/ .


Kind regards,
  Alfred HÎnes.

-- 

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


From weiler@watson.org  Tue Mar 27 17:12:19 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
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: , 
X-List-Received-Date: Wed, 28 Mar 2012 00:12:20 -0000

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

From johnl@iecc.com  Wed Mar 28 02:19:29 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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: , 
X-List-Received-Date: Wed, 28 Mar 2012 09:19:29 -0000

> 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

From fneves@registro.br  Wed Mar 28 03:44:34 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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-Type: text/plain; charset=us-ascii
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: , 
X-List-Received-Date: Wed, 28 Mar 2012 10:44:34 -0000

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

From fanf2@hermes.cam.ac.uk  Wed Mar 28 09:51:27 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
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: , 
X-List-Received-Date: Wed, 28 Mar 2012 16:51:27 -0000

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.

From A.Hoenes@TR-Sys.de  Wed Mar 28 15:12:24 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
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: , 
X-List-Received-Date: Wed, 28 Mar 2012 22:12:24 -0000

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.


From ietf.fact.check@gmail.com  Wed Mar 28 17:16:05 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=ISO-8859-1
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 00:16:05 -0000

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"

From Ed.Lewis@neustar.biz  Thu Mar 29 01:01:07 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 08:01:07 -0000

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!

From miekg@atoom.net  Thu Mar 29 01:43:16 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bu8it7iiRSEf40bY"
Content-Disposition: inline
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 08:43:16 -0000

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

From steve@shinkuro.com  Thu Mar 29 01:55:17 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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)
Content-Type: text/plain; charset=us-ascii
From: Steve Crocker 
In-Reply-To: <20120329084313.GC10653@miek.nl>
Date: Thu, 29 Mar 2012 09:55:15 +0100
Content-Transfer-Encoding: quoted-printable
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 08:55:17 -0000

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.
>=20
> 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.
>=20
> Regards,
> Miek Gieben
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext


From Ed.Lewis@neustar.biz  Thu Mar 29 02:17:56 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4
Cc: ed.lewis@neustar.biz
Subject: [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: , 
X-List-Received-Date: Thu, 29 Mar 2012 09:17:56 -0000

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!

From ogud@ogud.com  Thu Mar 29 04:07:07 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 11:07:07 -0000

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

From miekg@atoom.net  Thu Mar 29 04:18:38 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t"
Content-Disposition: inline
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 11:18:38 -0000

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

From fanf2@hermes.cam.ac.uk  Thu Mar 29 04:23:55 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 11:23:55 -0000

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.

From fanf2@hermes.cam.ac.uk  Thu Mar 29 04:45:29 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 11:45:30 -0000

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.

From Ed.Lewis@neustar.biz  Thu Mar 29 04:47:54 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 11:47:54 -0000

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!

From miekg@atoom.net  Thu Mar 29 04:55:36 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+KJYzRxRHjYqLGl5"
Content-Disposition: inline
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 11:55:36 -0000

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

From fanf2@hermes.cam.ac.uk  Thu Mar 29 04:57:09 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 11:57:09 -0000

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.

From fanf2@hermes.cam.ac.uk  Thu Mar 29 05:01:35 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 12:01:35 -0000

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.

From d3e3e3@gmail.com  Thu Mar 29 05:09:22 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 12:09:23 -0000

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

From Ed.Lewis@neustar.biz  Thu Mar 29 06:55:19 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 13:55:19 -0000

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!

From fanf2@hermes.cam.ac.uk  Thu Mar 29 07:04:44 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 14:04:44 -0000

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.

From rwfranks@gmail.com  Thu Mar 29 08:32:58 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Sender: rwfranks@gmail.com
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 
Content-Type: multipart/alternative; boundary=20cf3074d248233ec804bc63706f
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 15:32:58 -0000

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

From ondrej.sury@nic.cz  Thu Mar 29 08:50:51 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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)
Content-Type: text/plain; charset=utf-8
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
Content-Transfer-Encoding: quoted-printable
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 15:50:51 -0000

Hi,

I got our head engineer of Knot DNS (Lubos Slovak he's in Cc:), who also =
implementor IXFR (from scratch) to review the document and here's the =
result (copying verbatim, just added references to sections and 'nit' =
words):

1) section 1.4 - nit: "makes freely use" -> s/freely/free

2) Section 2, page 8 - nit: "Therefore, is becomes apparent" -> s/is/it

3) Section 2, last paragraph - why has to RRSIG(SOA) follow the SOA in =
then AXFR-fallback example?

4) Section 6.2 - missing RFC2119 language; shoulds and mays are small =
caps, is that intentional?

5) And today new question have arrised: "What should IXFR client do if =
it receives incomplete multichunked IXFR response?"  A) discard whole =
transfer and start over; B) save usable chunks (e.g. use data to update =
zone from sn_o to sn_o+x, where sn_o+x < sn_n)

Ondrej on behalf of Lubos
P.S.: Our Knot DNS team (different people than one of the authors of =
this document) will do a full review in WGLC.

On 27. 3. 2012, at 10:07, internet-drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the DNS Extensions Working =
Group of the IETF.
>=20
> 	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
>=20
>   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.
>=20
>   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.
>=20
>   This document obsoletes and replaces RFC 1995.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1995bis-ixfr-00.t=
xt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1995bis-ixfr-00.tx=
t
>=20
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext

--
 Ond=C5=99ej Sur=C3=BD
 vedouc=C3=AD v=C3=BDzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laborato=C5=99e CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:ondrej.sury@nic.cz    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------


From A.Hoenes@TR-Sys.de  Thu Mar 29 11:48:21 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 18:48:21 -0000

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.


From fw@deneb.enyo.de  Thu Mar 29 12:43:26 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=us-ascii
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 19:43:26 -0000

* 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.

From ondrej.sury@nic.cz  Thu Mar 29 12:59:50 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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)
Content-Type: text/plain; charset=utf-8
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
Content-Transfer-Encoding: quoted-printable
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 19:59:50 -0000

[cross-posting: dnsext readers please check the full thread on dnsop]
On 1. 3. 2012, at 16:09, Andrew Sullivan wrote:
> If dns-ng is a superset of useful dns functionality, but cleans up
> certain issues with dns, then the intermediate resolvers in (2) can as
> easily use a new port as they can use more complicated dns handling.
> So I have to agree with Paul Vixie: if we're going to work on
> replacing the protocol, let's replace it for real.  (FWIW, I think
> this is a noble goal doomed to failure.  But I've been wrong before.
> Probably three times just this morning.)


On the other hand, it might be just the right time to do this.  With
dnsext closure we can start with clean table and redesign the underlying
mechanisms hopefully with lessons learned so far.

I like the idea very much and I would like to initiate BoF in Vancouver
if there is an interest to pursue this dns-ng thing.  And no it is not
meant as replacement for dnsext.  The WG should do it's job, produce WG
document(s) and close.  I am not trying to get mad, y'know :-).

O.
P.S.: I know I am responding to a month-old email, but better now than =
never...
--
 Ond=C5=99ej Sur=C3=BD
 vedouc=C3=AD v=C3=BDzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laborato=C5=99e CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:ondrej.sury@nic.cz    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------


From A.Hoenes@TR-Sys.de  Thu Mar 29 13:11:46 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 20:11:46 -0000

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.


From fw@deneb.enyo.de  Thu Mar 29 13:26:25 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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: , 
X-List-Received-Date: Thu, 29 Mar 2012 20:26:25 -0000

* 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.)

From marka@isc.org  Thu Mar 29 16:36:41 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: , 
X-List-Received-Date: Thu, 29 Mar 2012 23:36:41 -0000

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

From Ray.Bellis@nominet.org.uk  Fri Mar 30 02:27:22 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: 
Content-Type: multipart/alternative; boundary="_000_DBC3C50C10A749808B9764FC7F1CAA8Fnominetorguk_"
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: , 
X-List-Received-Date: Fri, 30 Mar 2012 09:27:22 -0000

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

From rwfranks@gmail.com  Fri Mar 30 06:59:16 2012
Return-Path: 
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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
Sender: rwfranks@gmail.com
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 
Content-Type: multipart/alternative; boundary=20cf3074b4eeec6f6304bc763e8e
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: , 
X-List-Received-Date: Fri, 30 Mar 2012 13:59:16 -0000

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